Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 6. The Crystal Methodologies Shaping the Crystal Family
-
Часть 2
-
Core Crystal Elements
The core Crystal philosophy is:
Software development is usefully viewed as a cooperative game of invention and communication, with the primary goal of delivering useful, working software, and the secondary goal of setting up for the next game. Two consequences of that philosophy are that different projects need to be run differently, and the amount of modeling and communication that people need to do is just the amount they need to jointly move the game forward.
Members of the Crystal family share
Values and principles
On-the-fly tuning
Two values are that Crystal methodologies are intrinsically
People and communication centric High tolerance
The former means that tools, work products and processes are there only to support the human component. The latter recognizes varying human cultures. Within the tolerance of the Crystal family, though, the team can choose to work in a high-ceremony or high-discipline manner (adopting parts of PSP or XP, for example).
Seven principles were discussed in Chapter 4, "Methodologies. " The principles are roughly summarized as follows:
The team can reduce intermediate work products as it produces running code more frequently, and as they use richer communication channels between people. Because every project is different and evolves over time, the set of conventions the team adopts, must also be shaped and evolve. The shifting bottlenecks in the system determine the use of overlapped work and stick information holders.
The two rules common to the Crystal family are: The project must use incremental development, with increments of four months or less (with strong preference to one- to three-month increments). The team must hold pre- and post-increment reflection workshops (with strong preference to also hold mid-increment reflection workshops).
The two base techniques in Crystal are: The methodology tuning technique: using project interviews and a team workshop to convert a Crystal Clear is a methodology for D6-category projects. You should be able to stretch Crystal Clear to an E8 or D10 category project with some attention to communication and testing, respectively. I expect it to be difficult to extend beyond that, since Crystal Clear contains no communication structure for more people than can conveniently work in the same room, and lacks the system validation elements needed for life-critical systems.
Brief Description of Crystal Clear
There is only one team, seated in one or adjoining offices.
The roles needing separate people are: Sponsor, Senior Designer-Programmer, Designer-Programmer, User (part-time at least)
One of those people may pick up the assignment of being Project Coordinator. Some one will be the base methodology to a starter methodology for the project. The technique used to hold the reflection workshop.
You are welcome to replace those two techniques with others, if you have another way of acoomplishing their goals.
Attending to the above issues creates something that has a particular feeling. As someone wrote, it is possible to make another methodology look like a Crystal project, without making it feel like a Crystal project. A visitor to a successful Crystal project will notice communications and community in action, pragmatism in reaching the two goals of the game.
The following three sections describe the three Crystal methodologies I have so far constructed and seen used.
The structural differences between them are obvious. See if you can spot the commonalities.
Business Expert, and either one or many people will share the role of Requirements Gatherer.
The Senior Designer-Programmer is the key person on the team. The other Designer-Programmers may be at some mixture of novice and medium levels as the Senior Designer-Programmer and the problem can support. Hiring people who know their jobs of course helps.
The policy standards are that Software is delivered incrementally and regularly, every 2-3 months. Progress is tracked by milestones consisting of software deliveries 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 (Schwaber 2001), XP, or Adaptive Software Development (Highsmith 1999) 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 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 judgement. The combined team must decide how to present their design notes to future team members.
The most important tools the team can own, besides a compiler are:
A versioning and configuration management system A printing whiteboard.
You should be able to cost-justify several printiing whiteboards on any project, based on just the time people save typing design documents and meeting
Crystal Orange is a methodology for D40 category projects: up to 40 people, sitting in one building, working on a system that might cause loss of discretionary moneys, summaries, and lost communications cost when people do not copy down whiteboard contents.
The techniques used by the individual roles are left entirely to the discretion of the individuals.
Substitution of elements from from similar methodologies is permitted. For example, the team could decide to Scrum or DSDM's timeboxing and dynamic prioritization policies, Scrum's daily stand-up meetings, pair programming from XP, and so on.
Reflection on Crystal Clear
-
Закладки
The chart shows the state of the user stories being worked…
The main question is, if you were funding this project, which…
Types of Methodologies Rechtin (1997) categorizes methodologies…
Using the planning game in this way, the sponsors can properly…
After much coaching for six months, his programs still…
Accepting program modifications demanded by changing external…
Games are not just for children, although children also play…
For us as designers, it was possible to express both propositional…
The group of 17 quickly agreed on those value choices.…
Agility implies maneuverability, a characteristic that…
In arguing for the Theory Building View, the basic issue…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
Walk around your place of work. Notice · The convection…
The surprising thing about human success modes is how…
1. Project name, job of person interviewed (the interviewee…