CHAPTER OVERVIEW AND COMMENTS 4.1 What is Agility? The main point of this section is to introduce agility in the context of software development. Agility is more than change management. Agility means that customers and developers need to work together as collaborators on the development team and try to build products that can be adapted to a rapidly changing market place. Part of this adaptation is learning when and how to streamline the production of work products and focus on the development of incremental operational prototypes.
A manifesto is normally associated with an emerging political movement-one that attacks the old guard and suggests revolutionary change.
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
The most widely used agile process, originally proposed by Kent Beck. It encompasses a set of rules and practices that occur within the context of four framework activities: planning, design, coding and testing.
Begins with the creation of “user stories” and then placed on an index card.
The customer assigns a value to the story based on the overall business value of the function.
Agile “XP” team assesses each story and assigns a cost “measured in development weeks.”
If stories take more than 3 weeks to develop, the customer is asked to split the stories into smaller ones.
Stories are grouped to form a deliverable increment “done by customer and XP team.”
Once a commitment is made on delivery date, the XP team orders the stories that will be developed in one of three ways:
All stories will be implemented immediately within a few weeks.
The stories with the highest value will be moved up in the schedule and implemented first.
The riskiest stories will be moved up in the schedule and implemented first.
After the first increment (project release), “project velocity” is used to help define subsequent delivery dates for other increments.
Project velocity is the number of customer stories implemented during the first release. http://www.extremeprogramming.org/rules/velocity.html
Project velocity can be used then to:
Help estimate delivery dates and schedule for subsequent releases, and
Determine whether an over-commitment has been made for all stories across the entire development project.
XP Follows the KIS(S) principle. A simple design is always preferred over a more complex representation.
Encourage the use of CRC (class-responsibility collaboration) cards which identify and organize the O-O classes that are relevant to the current software increment.
For difficult design problems, suggests the creation of “spike solutions”—a design prototype that is implemented and evaluated. http://www.ironspeed.com/articles/Evolving%20With%20Extreme%20Programming/Article.aspx
Encourages “refactoring”—an iterative refinement of the internal program design that controls the code modifications by suggesting small design changes that may improve the design.
communicate problems or concerns in a way that leads to effective action
Learning will help them to improve their level of real understanding.
4.3.3 Dynamic System Development Method (DSDM)
Promoted by the DSDM Consortium (www.dsdm.org)
Dynamic System Development Method is an agile S/W development approach that provides a framework for building and maintaining systems which meet tight time constraints through the use of incremental prototyping in a controlled project environment.
It defines three different iterative cycles preceded by two additional life cycles activities:
Feasibility Study: Business requirements and constraints.
Business Study: Establishes req. that will allow the application to provide business value.
Functional Model Iteration: Produce iterative prototypes.
Design and build iteration: Revisit prototyping.
Implementation: Include the latest prototype into the operational environment.
Originally proposed by Schwaber and Beedle; the name derived from an activity that occurs during a rugby match.
Development work is partitioned into “packets”
Testing and documentation are on-going as the product is constructed
Work occurs in “sprints framework activities” and is derived from a “backlog requirements that provide business values” of existing requirements
Meetings are very short and sometimes conducted without chairs
“Demos” are delivered to the customer with the time-box allocated