Specific Agile Methods

Scrum and XP are widely applied agile methods the two most common, according to at least one survey [Shine03]. However, there is anecdotal evidence indicating some "XP" adoption is misunderstood as simply "not the waterfall" and the teams are merely practicing iterative and evolutionary development or "programming without documentation" and calling this XP.

see misunderstanding XP:

Scrum

Scrum's distinctive emphasis among the methods is its strong promotion of self-organizing teams, daily team measurement, and avoidance of following predefined steps. Some key practices include a daily stand-up meeting (the Scrum meeting) with special questions, 30-calendar-day iterations, and a demo to external stakeholders at the end of each iteration.

Scrum details

XP

XP is probably the most well known agile method; it emphasizes collaboration, quick and early software creation, and skillful development practices. It is founded on four values: communication, simplicity, feedback, and courage. It includes 12 core practices, including the whole team working together in a common room, pair programming, constant refactoring, and test-driven development.

XP details

Crystal Methods

The Crystal family of agile methods were developed by Alistair Cockburn [Cockburn02]. While acknowledging the necessity of an iterative lifecycle, in this group of methods Cockburn stresses the primacy of "peopleware" issues over process: communication, education, and so on. His definition of software development shows this emphasis: "…a cooperative game of invention and communication."

Different versions of Crystal (Clear, Yellow, …) contain increasing method weight (or process ceremony in terms of defined and ordered steps, documents, reviews, etc.) as a function of staff size, criticality, and project priority. You choose size and criticality, and this maps to a particular version of Crystal with a recommended method weight. Cockburn has created a scale to illustrate matching method configurations to these factors (Figure 3.2). For example, E6 means a project of 1 6 people, where the worst that can happen from a system failure is loss of essential money. Subsequent chapters refer to this classification model, to classify Scrum, XP, UP, and Evo.

Figure 3.2. Cockburn scale

graphics/03fig02.jpg

Agile Modeling

Agile Modeling is not a complete process or agile method, but a set of principles and practices for modeling and requirements analysis that complement most any IID method [Ambler02]. Scott Ambler summarizes best practices (Figure 3.3) that skilled iterative modelers apply. Briefly, Agile Modeling promotes the collaborative "low-tech, high-touch" creation of barely good enough, disposable models to aid understanding and communication. Practices encourage speed, simplicity, and creative flow.

Figure 3.3. some agile modeling practices

graphics/03fig03.jpg

Scenario

The project room walls are exposed (no furniture against them) and covered in whiteboards and static-cling-sheet whiteboard material. It's Monday, at the start of a three-week iteration. The team of eight developers has decided to spend two or three hours at the walls to better understand and communicate some ideas. Afterwards, they will start programming. They split into groups. Group 1 explores the object design for the main scenario. On one half of one wall, they sketch UML sequence diagrams. It isn't perfect UML; liberties are taken for sketching. After 15 minutes, they move to the other half of the wall, and sketch a class diagram that complements the sequence diagram. Over three hours, they move back and forth, developing two complementary diagrams. Finally, they take pictures, print them, and erase the boards. When programming later, the printouts provide some inspiration some design ideas in code are inspired by the prior thought, and some not.

Other Methods and Practices

In addition to Scrum, XP, and the Crystal methods, there are now a host of other agile-oriented practices or methods in use or publication:

  • Adaptive Software Development (ASD) from Jim Highsmith [Highsmith00]; inspired by the complex adaptive systems viewpoint, Rapid Application Development methods, and more.

  • Dynamic Solutions Delivery Model (DSDM) from a group of 16 Rapid Application Development (RAD) experts [Stapleton97] (originally called Dynamic Systems Development Method). It continues to be refined by a member consortium.

  • Feature-Driven Development (FDD) primarily from Jeff De Luca, with contributions by Peter Coad [PF02].

  • Lean Development from Mary and Tom Poppendieck [Poppendieck03].

  • Pragmatic Programming from Andy Hunt and Dave Thomas is not a complete method, but contains development practices sympathetic to an agile development approach. See www.pragmaticprogrammer.com.



Agile and Iterative Development (Agile Software Development Serie. A Manager's Guide2003)
Agile and Iterative Development (Agile Software Development Serie. A Manager's Guide2003)
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net