 |
|
Agile Software Development is an introduction to lightweight software development philosophy, thought, and recommended practices. From the inside front cover:
Agile software development centers on four values identified in the Agile Alliance's Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The development of Agile software requires innovation and responsiveness, based on generating and sharing knowledge within a development team and the customer. Agile software developers draw on the strengths of customers, users, and developers, finding just enough process to balance quality and agility.
It is obvious to every one connected to software development that most projects don't succeed, though few actually fail. The heavyweight processes attempt to remedy this with some flavor of "Big Design Up Front", getting each step complete and perfect before venturing to the next. This approach has some success, but it often produces more paperwork than working software. Much of it focuses on not making any mistakes and intermediate work products with complete and unambiguous specifications. Unfortunately, often the results are obsolete before the next phase is complete. Agile methods focus on people and communication that is good enough to proceed.
The former is like waiting for GPS to be invented, the scouts to get detailed maps to the printers, and hardcopy in hand before proceeding. The latter is like saddling up the mules as soon as the scouts return with verbal reports of a week's worth of route. If you are trying to get this year's harvest of perishables to market over the mountains, the heavyweight approach fails miserably.
Much of this book is about communications, particularly informal, as-needed communication. Much of the recommended practices are how to shorten feedback loops between people (e.g., pair programming, housing the entire team including customer/user representatives in one room), between program and programmer (test-first development, fully automated regression tests), between past and future (refactoring and barely sufficient documentation), and project and process (process reflection and process adaptation).
What I remember from my first reading was the insights and ideas. On second reading, what strikes me is how much of this is about people (how they think, work, fail, and succeed), communication ("warm" personal forms like face to face meeting and "cool" impersonal forms like paper documentation), and community (co-located teams). Also notable is what is not here - there are no forms, templates, checklists, or cookbook procedures.
I've worked in chaotic development groups (e.g., entry level people left to implement the rushed design left behind by the core of experienced designer who could see the impending death march). I've also worked in a SEI CMM Level 5 organization (the commemorative coffee mug was its most useful artifact). I appreciate the balance agile methods are advocating. And the explicit recognition that one size doesn't fit all. The author covers how to tailor the sample methodologies to larger, smaller, and more critical projects.
He also covers how the various methods work out in practice. He admits being surprised how well pair programming (two programmers side by side in front of one terminal) is accepted. My experience with it is limited, but I find it effective. I also find it tiring, like meetings. This may be because I need quiet time (certainly true of meetings) or because of the difficulty of the task (we only used it on problems that defeated a solo programmer). Programmers enjoy success as much as anyone else and pair programming leads to success.
Chapter 6 is "The Crystal Methodologies", a family of sample methodologies to be adapted for each actual project. Three samples are presented: Crystal Clear (6 project members and non-critical), Crystal Orange (40 people), and Crystal Orange Web (50 people and ongoing development). None of these have enough ceremony (reviews) for life-critical applications. The Crystal Clear description fits on a page and a half:
There is only one team, seated in one office of in adjoining offices.The roles needing separate people are
- Sponsor
- Senior designer-programmer
- Designer-programmer
- User (part-time at least)
One of of those people may pick up the assignment of being project coordinator. Someone will be the business expert, and either one of many people will share the role of requirements gather.
The senior designer-programmer is the key person on the team. The other designer-programmers may comprise some mixture of novice and medium levels, depending on what the senior designer-programmer and the problem can support. Hiring people who know their jobs well helps.
The policy standards are that
- Software is delivered incrementally and regularly, every two to three months
- Progress is tracked by milestones consisting of software deliverables or major decisions, as opposed to written documents
- There is some amount of automated regression testing of application function
- There is direct user involvement
- There are two user viewings per release
- Downstream activities start as soon as upstream is "stable enough to review"
- Product- and methodology-tuning workshops are held at the start and middle of each increment
The policy standards are mandatory, but equivalent substitution is permitted as would be the case if Scrum work scheduling , XP, or Adaptive Software Development policies were used.
The work products that are produced include:
- Release sequence
- Schedule of user viewings and deliveries
- Annotated use cases or feature descriptions
- Design sketches and notes as needed
- Screen drafts
- A common object model
- Running code
- Migration code
- Test cases
- User manual
The following are left as "local matters," to be set and maintained by the team:
- Templates for the work products
- Standards for coding and user interface
- Standards and details of regression testing
Crystal Clear does require project documentation to be created. Just what that documentation consists of is not spelled out by Crystal. That is left as a matter of local judgment. The combined team must decide how to present design notes to future team members.
The most important tools the team can own, besides a compiler, are these:
- A versioning and configuration-management system
- A printing whiteboard
You should be able to cost-justify several printing whiteboards on any project, based on just the time that people save in typing design documents and meeting summaries and in lost communication cost when people do not copy down whiteboard contents.
The techniques used by individual roles is left entirely to the discretion of the individuals
Substitution of elements from similar methodologies is permitted. For example, the team could decide to use Scrum or DSDM's timeboxing and dynamic prioritization policies, Scrum's daily stand-up meetings, pair programming from XP, and so on.
Reflection about Crystal Clear
Crystal Clear is the most tolerant, low-ceremony, small-team methodology I can find that still works.
It contains those elements claimed by my interviewees to be the cause of their success:
- Focus on close seating and close communication
- Frequent delivery
- Information from real users
- Code-versioning tools
The printing whiteboard has proven more valuable than any of its higher-tech replacements, with the possible exception of the newest generation of whiteboard-capture software (www.pixid.com). People usually start a discussion thinking it won't be worthwhile to record. They discover after their discussion that it would be good to have a record of it.
Crystal Clear provides a place to fall back if you try, and give up on, XP. Any part of XP can be substituted for Clear, because XP meets all Crystal Clear standards except for documentation. If you move from XP to Crystal Clear, you will have to add documentation. I don't think you can get any sloppier than Crystal Clear and still plan on having a better-than-even odds of completing a project successfully.
Developers who have been following the debate around Extreme Programming (XP) and other agile methods should not have much trouble following this outline. One interesting point is that XP is a high discipline method. Crystal Clear is lower discipline, but higher ceremony (the documentation). Most existing development organizations will have established practice for "local matters".
This isn't a big book, 270 pages with appendices. The Crystal Methodologies are helpful, but a vocabulary for discussing software development is more valuable for developing top-notch teams.
Who is this book for? Obviously software developers. Not so obviously, their managers. In fact, it may be more important that the technical leads and the project manager read and agree than the individual programmers. This is a book about the organization of software development, more than about the tactics of programming.
Who is this not for? Beginning programming students and entry level programmers. And lone wolf programmers - the lightest weight methodology (Crystal Clear) is targeted at six developers and explicitly requires at least four separate people. Maybe people who are satisfied with their existing process and are building very large or life-critical systems and intend to stay there through retirement. However, I think there is much here that they could use.
This book reads well the second time around, especially the early sections on ways of looking at software development. There are some deep ideas here that reward multiple readings to uncover all the layers.
Alistair Cockburn (pronounced like Coburn) is co-editor of the Agile Software Development Series. Jim Highsmith is the other co-editor. There are bits of his in this book. A friend just put Highsmith's Agile Software Development Ecosystems in my hands and I am looking forward to reading it.
-- Jeffrey Taylor (jeff.taylor@ieee.org)
|
Explanation of ERCB rating scale:
|
