Our experience and our customers' experience say there is no single correct process or methodology for developing software products. Different conditions and different stages of a product's life need different management methods and different approaches to software development.
In ALM you will find not only tools for managing the software development process, but also ready-made typical ways of working that you can apply as they are and then adapt to the specific conditions of your projects.
Our typical processes fall into two main categories:
Typical processes are meant to introduce ALM capabilities. They contain preconfigured data and ways of working. From the typical processes you can create your own, oriented toward specific teams, projects, and ways of working together.
To configure your own software development management process, use the "Your process" link. This process contains a minimum of settings, so you can configure your process from a blank sheet.
Modern software production delivers a result to the end user gradually. This is called an incremental-iterative approach. The result is usually measured as implemented user requirements. To reach the result, a developer follows a certain technology: design, programming, testing, documentation, and so on.
In ALM the required result is described in primary requirements: issues, requests, and user stories, depending on the development process you choose.
The states of requirements, and tasks, are responsible for the technology of implementing primary requirements — the stages of software production.
Unlike general-purpose project or task management tools, when we manage software development we manage not only tasks but also requirements. This fundamental difference is the basis for automating development processes in ALM.
This family of processes is characterized by every participant working with primary requirementsthat come directly from the product's users, the customer, or the customer's representatives. Such requirements can be written as a request, a wish, a user story, or in some other way that is convenient for the user.
System requirements, such as information models, data models, behavior diagrams, user interface mockups, and so on, are secondary and clarify the primary requirements. At the same time, system requirements accumulate knowledge about the internal structure of the product, which is extremely useful when the team changes and when you analyze the impact of potential changes.
Once a product is in use, it becomes unacceptable to wait a whole two weeks (the length of one iteration) to fix a defect or implement a small but important enhancement. On the other hand, new requirements (features) appear whose implementation takes a long time. At this stage of the product lifecycle you need a process that lets you implement new features steadily (as in product discovery) and, at the same time, resolve urgent requests from users.
The product backlog is split into two parts: the current-release backlog and the future-release backlog. While user requirements are being clarified, we decide which backlog a requirement goes into. Urgent and simple requests go into the current release. Complex requests go into the future release. During clarification, user requirements can be supplemented with important technical decisions, for example user interface mockups, data models, and other system requirements, so this does not have to be done during development.
User requirements for the current release are managed by a Kanban-based process. The key metric here is the speed of fixing a defect or implementing a simple enhancement. These are usually small changes and can be implemented by a simplified process, for example without involving every member of the project team.
User requirements for the future release are managed by a Scrum-based process. Here, as in the "Discovering or creating a product" process, sprints are planned, requirements are broken into tasks, and the implemented functionality is demonstrated and accepted. Because the current release will draw off part of the team's effort, the date (or scope) requirements for sprints are relaxed.
| Pros |
The same as for the "Discovering or creating a product" process There is a dedicated story-clarification stage, which lets you prepare some of the system requirements in advance, before planning and before user requirements are broken into tasks. Defects and small enhancements are resolved much faster than features are released. |
| Cons |
The same as for the "Discovering or creating a product" process Because part of the team's effort goes to maintenance, sprint dates can slip or the scope of functionality can shrink. When requirements keep changing, it is not possible to agree a clear project budget in advance. |
| Requirements |
Conditions are needed for abundant communication between users (or a representative) and the team members. The simplified process for implementing defects and small enhancements (the current release) requires assignees to be more highly skilled and cross-functional, so product quality does not suffer. |
The maintenance stage is the final stage of the product lifecycle, in which the team fixes defects and implements small enhancements. Because the software system is used by the customer or by users, what becomes critical is the speed of fixing defects and of implementing small but important enhancements that get in the way of users doing their work well.
This process has no sprints (iterations) and no batch implementation. With modern technology, new versions, updates, or patches can be released for almost every user requirement (you can read more about this in the approach Continuous Delivery).
The story (or issue) board reflects the whole process chain. Each state (column on the board) corresponds to one stage of the development process: analysis, design, development, testing, and so on. One or more team members are assigned to each stage. Each user requirement passes through every stage in order, from analysis through documentation. This resembles a traditional waterfall process, except that the scope of each stage is reduced to a single user requirement.
From a project-management point of view, this process uses Software Kanban. This is a simple process from lean production (Lean Management). Its essence is:
These few principles maximize the speed of implementing user requirements, which is what the customer expects at this stage of the product lifecycle.
| Pros |
User requirements are implemented much faster, because the next update is not blocked by implementing every needed enhancement. Because the speed of resolving requests is roughly the same (or can be segmented by task class: urgent, enhancements, defects), you can effectively estimate the dates and cost of the remaining work. |
| Cons |
Complex tasks can block the implementation of simpler but no less important tasks. A longer queue tail delays the release of updates. |
| Requirements |
Conditions are needed for abundant communication between users (or a representative) and the team members, so that fewer tasks are sent back to earlier stages. Tasks should not differ greatly in size. If they do, you are most likely at the "Evolving a product" stage and the process needs to change. |
Upfront design means collecting, systematizing, analyzing, and designing the technical (system) requirements for the product before implementation starts. The amount of functionality being designed should be only a small part of the whole functionality of the future product. This fundamental difference from the waterfall approach makes it possible to organize an effective development process and deliver a quality product. Such processes are a special case of the iterative-incremental approach or the spiral development model.
The main difference from the lightweight approach is that there are two cycles: a design cycle and a development cycle.
The design stage involves:
Participants in the design cycle work with user requirements and produce system requirements, prototypes, and mockups, and they check technical hypotheses (PoC). Tasks for development are formed from the system requirements (enhancements).
The development stage involves:
Program code and test and operational documentation are traced to the source system requirements. This lets you control the integrity of the documentation and the product, control expenses, analyze impact when changes are proposed, and keep project documentation up to date effectively.
The two cycles can overlap: while a worked-out version of the product is being implemented, the design-cycle participants design the next version. Baselines and project-documentation versioning support this practice.
The process is used for contract development.
The technical specification is imported from the document provided by the customer and is supplemented with significant details inside the application. Implementation details, mockups, and technical requirements are recorded as child sections of the specification.
Detailed requirements can be estimated in advance from the expert opinion of team members. Estimation results can be recorded for each requirement in the "Estimate, h" field. The total estimate for the whole specification can be used to estimate the amount and cost of the work on the specification.
If you need a more detailed estimate that takes into account different costs for different kinds of work, create a set of tasks for each specification section whose completion implements that requirement. These can be tasks related to interface design, development, testing, and documentation. The "Effort by specification" module shows a detailed estimate of the work for this specification. The estimate can be exported to Excel and sent to the customer. If budgeting is used, each assignee can be given a rate (the cost of an hour of work), and then the "Expenses by requirement" module gives you a detailed project estimate in money.
After the estimate is approved, the planned effort for the requirements can be copied into the "Estimate, h" field, to record the agreements on the project budget.
Dates for delivering the specification are managed in the Plan module. It is better to organize delivery of the specification iteratively: create iterations and plan the work across them with the "Operational plan" module. With grouping settings, the task board can be split by assignee or by requirement.
When planning is finished, you can estimate when delivery of the specification will be completed, and how busy the participants are on this project. Participant workload is shown in the corresponding module, linked from the vertical menu, in the "Reports" section.
The backlog collects every change to the specification: new issues, comments from users, defects found during testing, and so on. The project team studies these changes and reflects them in the technical specification: new specification sections are created or existing ones are changed.
A change to the specification can lead to the effort estimate being revised up or down. Baselines let you record the agreements and the related effort estimates for the requirements, and the cost of implementing them. Comparing baselines shows changes in the cost estimates, so you can agree with the customer that they will be paid for, or use your own reserves to implement them.
| Pros |
Working out the requirements deeply and designing upfront uncovers and removes many project risks. This reduces unexpected expenses, lets you design a better architecture, and avoids spending time reworking functions that were already developed. Existing methods of estimating effort from requirements make it possible to forecast, with good accuracy, the dates for implementing large amounts of functionality. |
| Cons |
Uneven workload of project participants. A significant amount of work to plan the implementation of the specification. |
| Requirements |
The team must include specially trained professionals who take part in preparing business or system requirements. Requirements are prepared and implemented in portions (iterations). |