This document discusses agile software development processes. It outlines some common reasons for challenged, failed, and successful projects. Some key problems with the traditional waterfall model are that mistakes are hard to find early on and requirements often change. The document then introduces agile concepts like iterative development, test-driven development, extreme programming, scrum, and their benefits like producing working software earlier, adapting to change, and improved communication.

1. AGILE SOFTWARE
DEVELOPMENT
PROCESS MODELS

2. How Projects Really Work

3. How the customer explained it

4. How the project leader understood
it

5. How the analyst designed it

6. How the programmer wrote it

7. How the business consultant
described it

8. How the project was
documented

9. How much the project cost

10. What the customer really
needed

12. Challenged Projects - Reasons
 Lack of User Input
 Incomplete Requirements &
Specifications
 Changing Requirements & Specifications
 Lack of Executive Support
 Technology Incompetence
 Lack of Resources
 Unrealistic Expectations
 Unclear Objectives
 Unrealistic Time Frames
 New Technology

13. Failed Projects - Reasons
 Incomplete Requirements
 Lack of User Involvement
 Lack of Resources
 Unrealistic Expectations
 Lack of Executive Support
 Changing Requirements & Specifications
 Lack of Planning
 Didn't Need It Any Longer
 Lack of IT Management
 Technology Illiteracy

14. Successful Projects - Reasons
 User involvement
 Executive management support
 Clear business objectives
 Optimizing scope
 Agile process
 Project manager expertise
 Financial management
 Skilled resources
 Formal methodology
 Standard tools and methodology

15. What's wrong with “Waterfall”?

16. What's wrong with “Waterfall”?
 Mistakes are hard to find in early stages
 Expensive to fix mistakes in later stages
 Customers don't know what they want from the
beginning
 Developers don't know how long a project will
take from the beginning
 Business needs change

17. Effects of “Waterfall”
 Death March projects
 ‒ Mis-estimated schedules lead to successive
overtime
 ‒ Delays in one stage cause delays in succeeding
stages
 Conflict between customers and developers
 ‒ Customers don't get the software that they want
 ‒ Developers don't get clear requirements
 Process and tool obsession
 ‒ People focus on creating artifacts but lose sight of
the
 goal of working software
 ‒ Processes replace natural communication

18. The Agile Manifesto
They are uncovering better ways of developing
software by doing it and helping others do it.
Through this work they have come to value:
• Individuals and interactions over processes and
tools
• Working software over comprehensive
documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right,
they value the items on the left more.

19. Selected Practices
Behavior-driven development (BDD)
Continuous integration (CI)
Domain-driven design (DDD)
Scrum board
Iterative and incremental development (IID)
Test-driven development (TDD)
User story
Extreme Programming (XP)

20. Iterative Development

21. Iterative Development
 All steps of SDLC are done at each iteration

22. Iterative Development
Working software produced at each iteration
– No such thing as “X% complete”, only done
and not done

23. Iterative Development
 Benefits
 ‒ Customers can evaluate what they want and
adjust requirements
 ‒ Developers get better estimates of future tasks
 ‒ Better communication between customer and
developers and among developers
Talk is about something concrete, not abstract
 ‒ Just enough artifacts are created to produce
working software
Less waste

24. Test-Driven Development
 Bugs are harder to find and fix when found
later
 Modifying code tends to introduce bugs
- Difficult to know if one has introduced bugs
without tests
 Manual tests are expensive to repeat and
provide limited information

25. Test-Driven Development
 Programmers should write automated tests as
they code
- Write test before implementation
 Provides immediate feedback if their code
works
 Builds suite of automated tests that can be run
each time code is modified
 Makes it safe to modify existing code
 Frameworks: JUnit, NUnit, hundreds of
others...

27. TDD Benefits
 Code is safe to modify
 Tests are excellent documentation
- Programmers hate writing documentation, but
they like to code
 Design improves
- Programmers think of their code's behavior
before coding
- Programmers see their code from a second-
person's point-of-view
• Is my code readable? Easy to use?
- Components become decoupled to facilitate
testing

28. XP
 It concentrates on the development rather than
managerial aspects of software projects
 XP projects start with a release planning
phase, followed by several iterations, each of
which concludes with user acceptance testing.
When the product has enough features to
satisfy users, the team terminates iteration and
releases the software

29. A simplified XP process

30. XP rules and concepts
 Integrate often. Development teams must
integrate changes into the development
baseline at least once a day. This concept is
also called continuous integration(CI).
 Project velocity.
 Pair programming.
 User story.

31. Scrum
 Scrum methodology includes both managerial and
development processes
 After the team completes the project scope and
high-level designs, it divides the development
process into a series of short iterations called
sprints. Each sprint aims to implement a fixed
number of backlog items.
 Before each sprint, the team members identify the
backlog items for the sprint.
 At the end of a sprint, the team reviews the sprint
to articulate lessons learned and check progress.

32. The Scrum process

33. Scrum concepts
 Burndown chart. This chart, updated every
day, shows the work remaining within the
sprint.
 Product backlog. Product backlog is the
complete list of requirements
 ScrumMaster. The ScrumMaster is the
person responsible for managing the Scrum
project.
 Sprint backlog. Sprint backlog is the list of
backlog items assigned to a sprint, but not yet
completed