AGILE SOFTWARE DEVELOPMENT

PROCESS MODELS

How Projects Really Work

How the customer explained it

How the project leader understood it

How the analyst designed it

How the programmer wrote it

How the business consultant described it

How the project was documented

How much the project cost

What the customer really needed

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

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

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

What's wrong with “Waterfall”?

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

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

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 planThat is, while there is value in the items on the right,

they value the items on the left more.

Selected Practices

Behavior-driven development (BDD)Continuous integration (CI)Domain-driven design (DDD)Scrum boardIterative and incremental development (IID)Test-driven development (TDD)User storyExtreme Programming (XP)

Iterative Development

Iterative Development

All steps of SDLC are done at each iteration

Iterative Development

Working software produced at each iteration

– No such thing as “X% complete”, only done and not done

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 developersTalk is about something concrete, not abstract

‒ Just enough artifacts are created to produce working softwareLess waste

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

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...

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

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

A simplified XP process

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.

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.

The Scrum process

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