A Quick Survey of Development Methods
While working on my last Open University course we were asked to talk about different software development methods with a focus on agile. I may have gone a little over the top and the post ended up being about 1000 words,so i thought I’d put it up here.
Waterfall
The standard linear sequence of steps. Feedback paths do exist to correct problems, but the costs of doing so increases exponentially as the project moves towards the Maintenance phase, making this less flexible to changes in the projects business environment after the the start of the requirements phase. Risk management is more complex as any high level problems must be clear at the start of the project. This is balanced by having clear goals to aim for so its simple to say when the project is completed.
A number of variations exist, with one of the most useful being the V model. This redraws the Waterfall matching up the development phases with the associated phase of testing. This also highlights where the customer is most involved, in defining the requirements and in performing the acceptance testing.
Incremental Development
I would was tempted to bundle incremental development with the waterfall model, as this tends to be about producing a single design at the start of the project and delivering the product in stages, allowing for some reassessment and adaptation between them. I would class this as a intermediate methodology between the waterfall and iterative methods.
Iterative development
the natural out growth of this, by performing only enough design work to decompose the project into a number of iterations that can be thought of as mini waterfall processes. That perform the whole development life cycle but only on a subset of the full functionality. aiming to create a usable system at the end of each iteration with increasing functionality as time goes on.
Spiral Model
A useful alternative view of this way of working is the spiral model, with the team iterating and refining the model over from the starting point, add more capabilities in each layer. This being particularly good for prototyping, and can be combined with waterfall based iterations. Allowing each Iteration to select the best model for that set of risks, tasks and features.
Handling Risk
Specification changes can easily be worked into schedule with flexibility and adaptability maintained for longer than waterfall models. The riskier parts of the project can be handled in earlier iterations and refined overtime. Tasks can also be ranked on there value to the customers with more important features being implemented earlier in the life of the project, so if any features need to removed because of overruns these will be ones deemed less important by the customer, so have less impact on the overall product.
Agile Methodologies
Rapid application development grew from the Iterative development ideals in the late 70s and early 80s, aiming to deliver solutions quicker without the overhead of the more heavyweight processes and in turn evolved into Agile software development, which the Agile Manifesto defines as:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Extreme Programming (XP)
The best known (at least in name) of the agile methodologies. This toolkit is very much focused on the implementation and testing phases of the development life cycle with the two techniques most often linked with XP are Pair Programming and test driven development, but both where not developed in the XP community but adopted as best practice.
It is the most lightweight of all the Methodologies. The Methodology aim to always have a working system via Continuous integration and testing with no formal role of a project manager mean it is more suited to experienced teams working together in a single location
Scrum
In contrast, the scrum manager can seen more like a traditional project manager. With the whole methodology targeted more at a higher level, the what do we do, not the how, making it a possible partner and complement to XP. each iteration is called a spirit and has a fixed time period, typical two weeks, any work not completed is added back into the backlog of prioritised tasks, which can only be changed at the end of a sprint. The burndown chart tracks the work remaining, not effort expended against the plan.
Getting Real
In the web development community Getting Real by 37 Signals also has a following. This is the internal process used inside the company to develop their well known applications Basecamp, Backpack and Ta-Da List. The method focuses on producing working prototypes and then using user feedback to refine the design.
Code Reviews
A less extreme version of pair programming is the code review, where another developer looks over your recent work before being committed to a source control system. To gain the full value both participants must engage with each other and for a person new to the technique it may take a number reviews before they become comfortable with them and reap the benefits.
Refactoring
Another important concept is refactoring, improve the design of existing code. For business and time to market reason you may implement features in a less than maintainable fashion creating Technical Debt.
Refactoring is the process in which that debt is removed without change the behaviour of the system, which where having unit tests can make verifying the before and after cases much simpler.
Design Patterns
A concept taken from the architecture in the building industry, that the same problem crops up time and again and the solution can be codified and applied in a standard way. They also have a negative version, anti-patterns, how no to do things and common mistakes.
Estimating
When a single time value is given this is often taken as a commitment not your best guess, a better way is the use of triple estimates(PDF). instead of a single value, the best case, worst case and most likely times are given for each task. This increase the visibility of the confidence levels for each task and the project overall, giving you a less fragile Plan.
So Which Methodology?
An Iterative approach, in most if not all cases, they are better at handling risk, delivers a usable product sooner, that is more likely to be fit for purpose and of a higher quality.
The particular agile approach chosen would need to tailored to the project, customer and team, an experienced team working with a long time customer maybe most productive using XP but a riskier project with a younger team may require a more formal structure like Scrum or maybe even DSDM if this will be a large project.
Agile’s Problems
Not to say that current agile processes are trouble free, the cost benefits are less than clear cut, a good agile team maybe able to generate a much better return on costs but so could a good more traditional team.
Another problem is how agile is practised today, other have touched on this. It does not matter how good the methodology is if it is practised in a half hearted way
Finally Agile methods do not have the track record of use on large projects, but since many web projects tend to be on a smaller scale, this is less of a problem, than in other areas of software development
All this points to moving over to an agile approach in stages, not all at once and finding what mix of techniques works for your organisation.
Post Agile
Some methodologies have started to address some of these problems with scaling agile and dealing with more than a single team at time,and applying those ideas to the whole business process not just the software portion.
Lean Software Development
Lean product development applied to software, related to but not the same as Lean product development, the Toyota manufacturing methodology. The focus is on the customers perception of value and aims to systematically eliminate waste and delays, with an emphasis on continual improvement.
Kanban
The new kid on the block. Breaks down tasks into smaller items, with the concept of the Minimally marketable feature MMF, what is the smallest change that can add value to the project. Instead of trying to be agile and so hopefully improving. Kanban focuses on improving and hopes to be agile as a side effect.
Tasks progress from Agreed to Ready to In progress to Done. Each developer works on a single task at a time, which once started will be finished unless it becomes blocked for some reason. The ready queue is prioritised and of limited size to focus development on the next most important tasks for the project.