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