Overall vision of the PLAN phase in DevOps

After our initial post about our DevOps approach to improve software development lifecycle management, this is the first in an 8-post series in which describe how we approach each of the individual phases. So today is the time for PLAN.

In the PLAN phase, the main goals are:

  • To validate all the requirements with the customer, making sure that we are on the same page. This is the most relevant friction point in the majority of software projects.
  • To define all the project tasks and to distribute them along time, so we often deliver a new software version to be tried by our customer. Most of the customers need to touch and test preliminary software releases to discover what the really want.
  • To gather all the test results for each project task, in order to validate that they have been correctly executed. Thus, the validation of the correct execution of all the tasks associated to one requirement validates that we have fulfilled this requirement.

The tool to track all the relationships among requirements-tasks-tests is a requirements traceability table, which every project management tool must offer. It must allow to define a row per each requirement, with its textual description, the project tasks that (once finished) will satisfy the requirement; and additional information such as the software components or the software versions related to each requirement.

As the numbers of requirements, project tasks, components, version and any other structure criteria grow, it is particularly important that our tool provides sorting and filtering.

The figure above shows a wireframe depicting how such a table helps us to associate requirements with project tasks. We shall typically use wireframes in our posts to help us to abstract from the exact look-and-feel and features of a specific tool.

The figure above shows how the degree of finalisation for each contributes to the degree of fulfilment of the associated requirement and how all of them contribute to the the progress degree of the overall project. For instance, requirement REQ 0001 is fulfilled after the completion of project tasks PROY-001 to PROY-005; the estimation of their completion degree (90%, 35%, 8%, 0% and 0%, respectively) allows us to estimate that REQ 0001 is at 35% of progress from being completely fulfilled, as specified in the project management tool.

At the same time, the estimation of progress in each requirement (35%, 9%, 0%, …, 0%) allows estimating the overall project progress (3%).

There are many detail aspects to be commented about planning, which we will cover in future posts. For now, we can anticipate that agile software development will be our main guide, that using a Scrum or Kanban board in a tool or on a wall is not enough, and that one of the main problems in software projects is the fallacy of closed scope and price.

The fact that the “definition” of project tasks in the figure above resembles user stories is not a chance. We shall also talk about product backlog instead of “project tasks”, and about backlog item rather than “project task”.

We shall also comment how, if we define project tasks (or backlog items) through the definition of the tests that will be used to check whether they are done, we shall be moving towards test-driven development.

And above all, we shall highlight how all the planning and technical work needs to be embedded in a truly agile culture: a self-organized and collaborative team.

We’ll be right back. Stay tuned!

Leave a Reply

Your email address will not be published.