Continuing at the IASA ITARC event in Atlanta I listened to Don Browning, Principal Architect at Turner Broadcasting, talk about Feature Driven Development. Turner considered XP, SCRUM and FDD sometime ago and found that FDD fit their waterfall-based mindset. Don started by talking about how problems with project schedules, with poor analysis, QA problems and user acceptance all roll downhill to developers. He had four main points
- Agile (especially FDD) does not mean abandoning architecture
- Agile can work on large projects
- Agile need not be risky "fly by the seat of the pants"
- A solid development methodology bring repeatability and predictability
Agile methodologies are numerous but all match up to the agile manifesto's four concepts. I have written about rules and agile before for InfoQ - Agile Business Rules (Deborah Hartmann also wrote a nice introduction When and How to Formalize Business Rules) and had a conversation with Scott Ambler on this topic. He particularly emphasized the aspect of responding to change because things never get cast in stone. The rate of change in software projects remains very high and drives many project failures (as discussed here). Agile projects make it easier to be successful by delivering smaller projects more often - expectations are managed differently.
Don started by discussing how FDD is not XP.
- FDD uses UML documentation where XP discourages documentation.
- FDD has an overall system model which XP lacks
- XP uses pair programming and test-first where FDD does not
FDD Principles (with my comments)
- Working software is the primary measure of progress
Yup. Works for me.
- Deliver working software frequently, iterations never last more than 3 weeks (smaller projects use shorter ones, customers do not necessarily get every release)
With rules you can iterate as often as you like, certainly 3 weeks is very reasonable
- Business people and developers working together
Well they aren't going to manage that if the only thing they can both look at is a set of code!
- Embrace changing requirements
Changing requirements is one thing, changing rules are another
FDD has five phases which seem both sensible and a good fit for rules:
- Develop an overall model (once)
A domain model to think about the system as a whole. The objects of the system, their interactions.
Constantly updated during subsequent phases.
- Build a feature list (once)
Set of areas, set of activities within that, each step is a feature. User story or <action> <result> <object>
- Plan by feature (once)
Rough estimate for each in terms of days from 0.5 to 8 but break up features that estimate at more than that. Find the sequence and assign to iterations.
Note that some iterations are light to allow for bug resolution and this is built into the schedule
- Design by feature (many)
Constant refinement of original domain model.
Three steps - walk through domain with users, design each feature (could use UML) and validate and review the design.
Typically 4 days at start of iteration.
- Build by feature (many)
Typically 10 days of coding ending with a build before a final day of planning for the next phase.
Implement classes, code inspection and peer review, promote fully tested code.
Each step represents an approximate percentage of completeness for a feature
I could not help feeling that using business rules to manage logic in steps 4 and 5 would keep the users more engaged, reduce errors and deliver functionality that could be subsequently evolved by users alone.
Couple of final comments. I like the way FDD separates the architect role on the team from the development manager from the project manager. Don's team found that a change control process became important in later iterations - it was OK for it to flex a lot early on but not later. I also liked the ability of the FDD model to quickly identify periods when progress stopped.