5. Phases
Inception
• Identify details of functional and non-functional requirements and risks enough to get
started
Elaboration
• Produces a system based on desired architecture that addresses high risks
• Non-functional requirements are almost fulfilled
Construction
• Incrementally produce the functional requirements
• Analysis, design, code, and testing
Transition
• Delivers the software product to production
6. Agile Manifesto
Individuals and
Interactions over
Processes and Tools
Working Software
over
Comprehensive
Documentation
Customer
Collaboration over
Contract
Negotiation
Responding to
Change over
Following a Plan
7. Individuals and Interactions
Allocate enough time for people to think, focus and
execute their work
Allow people to collaborate with each other
Always begin with people then identify the tools
they need
• Emphasis on tools and processes is secondary
8. Working Software
Develop potentially shippable increment of product
• Use short iterations
Demo the product increment for acceptance
• Customers will notice the evolving product increment
Generate the least amount of document
• Regulatory requirements may prompt you to document more
9. Customer Collaboration
Contacts must have a flexibility for change
• Accommodate Agile process
Changing requirements may happen
• Built-in change control should accommodate changes
For fixed-priced contract, accommodate request during the sprint or
release planning
• Subject to customer’s approval
10. Responding to Change
Emphasizes on quick response on changes
Does not devalue planning
Plan should be flexible enough to accommodate changes
12. Agile Software Development Principle
Software quality
• Organize people to deliver high quality software
Increased productivity
• Delivers only the functionalities needed
Reduced cost of requirement changes
• Changes are allowed to keep the desired features
13. Short Iterations
Software product is developed in a series of short
iterations
Customer provides early feedback
Development team gets better understanding of the
product being developed
14. Software Development Activities
Coding
• Working code is the only important product of software development
Testing
• Obsessive testing – Unit testing, acceptance testing, continuous integration testing
Listening
• Understand what the customer wants
Designing
• Good design avoids dependencies that break other parts of the system
15. Values
Communication
• Collaboration of users and programmers through frequent communication and feedback
Simplicity
• Simple design and coding improves the quality of software, and of course communication
Feedback
• Feedback from tests and customers
Courage
• Code for today. Refactor your code. Throw away obsolete code.
Respect
• Respect the team’s commitment. Avoid breaking the build.
18. Product Owner
Represents the customers/stakeholders
Drives the development effort.
• Ensures that the development team delivers value to the business
Owns the user stories in the Product Backlog list
Accepts or rejects the whole or part of the product increment delivered by the
development team
19. Development Team
Composed of 3-9 individuals with cross-functional skills
Self-organizing
Uses all the necessary resources to finish the product
increment
20. Scrum Master
A servant-leader who facilitates the Scrum
• Not a traditional project manager
Enforces the rules or Scrum
Removes the impediments
• Makes the impediments visible to everyone
21. Sprint
Time boxed effort to build the product increment
Duration is between one and four weeks
• Typical is two weeks
Source: http://en.wikipedia.org/wiki/File:Scrum_process.svg
23. Sprint Planning Meeting
Held before the Sprint starts
Product Owner presents the ordered User Stories
Development Team selects User Stories
• Team’s capacity is considered
Development Team develops the Sprint Backlog list
24. Daily Scrum Meeting
Held daily and time boxed to minutes
Development team members participate
Everyone reports to the team
• Work done since the last meting
• Impediments
• Planned work for the day
25. Product Demo Meeting
Time boxed to 4 hours
Demonstrate the potentially shippable product increment to the stakeholders
Work that is not 100% done is not included in the demo
Product owner accepts or rejects any of the functionalities presented
26. Sprint Retrospective Meeting
Time boxed to 3 hours
Facilitated by Scrum Master
Development teams talks about what went well and wrong
List of actionable items is prepared
• Objective is to improve the current process/situation
28. Copyright (C) 2014. Allan Spartacus Mangune
This work is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International License.
License URL: http://creativecommons.org/licenses/by-nc-
sa/4.0/