Scribd
Upload
40 views

Figures - Chapter 3

The document describes key principles and practices of agile software development methods like extreme programming (XP). It discusses principles like customer involvement, incremental delivery, valuing people over processes, and embracing change. XP practices explained include incremental planning, small releases, test-first development, pair programming, collective ownership, continuous integration, and an on-site customer. Figures provide visual examples of an XP release cycle, practices, a user story and associated tasks, and a test case description.

Uploaded by

Hà Nguyễn Hậu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
40 views

Figures - Chapter 3

The document describes key principles and practices of agile software development methods like extreme programming (XP). It discusses principles like customer involvement, incremental delivery, valuing people over processes, and embracing change. XP practices explained include incremental planning, small releases, test-first development, pair programming, collective ownership, continuous integration, and an on-site customer. Figures provide visual examples of an XP release cycle, practices, a user story and associated tasks, and a test case description.

Uploaded by

Hà Nguyễn Hậu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 10

Figures – Chapter 3

Figure 3.1 The principles of agile methods

Principle Description

Customer involvement Customers should be closely involved throughout the development


process. Their role is provide and prioritize new system
requirements and to evaluate the iterations of the system.

Incremental delivery The software is developed in increments with the customer


specifying the requirements to be included in each increment.

People, not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own ways
of working without prescriptive processes.

Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and in
the development process. Wherever possible, actively work to  
eliminate complexity from the system.
Figure 3.2 Plan-driven and agile specification
Figure 3.3 The extreme programming release cycle
Figure 3.4 Extreme programming practices (a)

Principle or practice Description

Incremental planning Requirements are recorded on story cards and the stories to be included
in a release are determined by the time available and their relative
priority. The developers break these stories into development ‘Tasks’.
See Figures 3.5 and 3.6.

Small releases The minimal useful set of functionality that provides business value is
developed first. Releases of the system are frequent and incrementally
add functionality to the first release.

Simple design Enough design is carried out to meet the current requirements and no
more.

Test-first development An automated unit test framework is used to write tests for a new piece
of functionality before that functionality itself is implemented.

Refactoring All developers are expected to refactor the code continuously as soon as
possible code improvements are found. This keeps the code simple and
maintainable.
Figure 3.4 Extreme programming practices (b)

Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.

Collective ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything.

Continuous integration As soon as the work on a task is complete, it is integrated into


the whole system. After any such integration, all the unit tests
in the system must pass.

Sustainable pace Large amounts of overtime are not considered acceptable as


the net effect is often to reduce code quality and medium term
productivity

On-site customer A representative of the end-user of the system (the customer)


should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of
the development team and is responsible for bringing system
requirements to the team for implementation.
Figure 3.5 A ‘prescribing medication’ story
Figure 3.6 Examples of task cards for prescribing medication
Figure 3. 7 Test case description for dose checking
Figure 3.8 The Scrum process

You might also like