Main Page - Blog - Books - Links - Resources - About - Contact Me
This page is based on the development methodologies appendix (Appendix F) in Ship It!.
It sometimes seems as if there are as many different ways to develop software as there are developers. New ones appear all the time. Keep up-to-date with the thought leaders in the field, see what they come up with, and try it in your own shop.
One methodology to avoid: the infamous Waterfall method. This has been universally discredited in more forward-looking development circles, but itís amazing how many shops still use it. The Waterfall model assumes that you can compeletely understand every phase of your project and set a concrete schedule for each phase. The Waterfall method also expects you to set this schedule before youíve even started the project! Clueless managers who like schedules have been fans of the Waterfall for years
Agile Development- More a movement than a specific methodology, it emphasizes adaptability, communication, and iteration.
Capability Maturity Model: (CMM, SW-CMM, or CMMI)-Formal models for most facets of the software development process.
eXtreme Programming (XP)-Developed by Kent Beck, XPís rules and practices include pair programming, iterations, and lots of customer interaction.
Rational Unified Process (RUP)-A large, formal methodology with many different facets.
Scrum- An agile methodology that organizes around incremental delivery cycles called sprints.
Crystal-Crystal is a highly adaptive software process. Itís based on the idea that project is different, so every project will need a different methodology.
Phases- The series of steps you take throughout the course of your project. Different methodologies have different phases, but most include phases such as requirements gathering, coding, testing, and writing documentation.
Milestones- Specific events that occur or items you deliver during development.
Deliverables- Pieces of software that go ďout the doorĒ to interested parties (e.g., code, documentation, demos).
Schedule- When the milestones must be accomplished.
Work assignments- The members of the team are assigned specific tasks, and completion of those tasks is tracked.
Communication- Nobody on the team is allowed to work in a vacuum.
Type of product- What software are you developing? A small project needs a different sort of methodology than a big one.
Size of the team- A small team can be successful with a less formal methodology than a large one.
Type of people on the team- Some people work better with less formality, supervision, and planning than others.
Type of customer- Your customer might or might not be available for consultation during the project.
External constraints- Sometimes youíll be required to use a certain methodology (e.g., contractual, government auditing).
Past record- If your current methodology ainít broke, donít fix it!
Simplicity- Large, complex methodologies might be more than a small team can handle.
Martin Fowlerís article on The New Methodology has a great discussion of this topic.