Presentation Transcript

1. Software Development Landscape From the well-known Standish CHAOS Report 1994 Software projects fail: Cancelled - 31%; Late or lacking of features – 53% Industry has only delivered on-time and on-budget 16% of the time! 3 top reasons for failure Lack of user (sponsor) involvement No executive management support Unclear, incomplete, & changing requirements Typical software project experiences a 25% change in requirements 45% of features defined in early specs are never used
2. Bridge to Success The Standish Group concluded that keys to success are: Shorter time frames Delivery of software components early and often Iterative process “Growing" software vs. "developing" software Engage the user earlier Clear statement and set of objectives for components Keep it simple! - Complexity = confusion and cost
3. Values of Agile Development While there is value in the items on the right, we value the items on the left more.
4. Scrum Process what did you do yesterday? what will you do today? what got in your way? Key Practices Self-directed; self-organizing teams 15 minute daily stand up meeting with 3 special questions 30-calendar day iterations Each iteration begins with adaptive planning Stakeholder demo at end of each iteration Team measures progress daily Each iteration delivers tested, fully-functional software Never more than 30-days from potential production release
5. Benefits and Challenges of Scrum Benefits Increased productivity through teamwork and focus Increased satisfaction through transparency and involvement Increased ROI through early delivery of high value functionality High quality throughout the development cycle using Test-First High energy, exciting process People know the importance of their work Opportunity to improve every 30 days Challenges Leading the change Good news, you know where you are.Bad news, you know where you are… Identifies all areas of improvement for engineering practices Change in culture Hard work
6. De-Cubiclization2004
7. Origins of Agile
8. Values: Communication Simplicity Feedback Courage Respect Practices: Pair Programming Planning Game Iteration Planning Test Driven Development Whole Team Continuous Integration Coding Standards Collective Code Ownership Simple Design Refactoring On-site Customer Open Workspace Acceptance Tests (Customer Tests) Extreme Programming
9. Common Practices Short iterations (1 week to 1 month) Continuous communication & integration Designs driven by testability User Stories Don’t over-design (YAGNI), refactoring when needed “Travel Light”
10. Short Iterations Usually 1 week (eg, XP or Evo) to 1 month (eg, Scrum) During an iteration, requirements are usually fixed This enables developers to have stability while the business gets the ability to respond to change The highest priority things are always worked on first This means that at any point in time, you’re delivering the maximum possible business value By extension, this also means that you avoid things that don’t have the highest business value Estimating things much beyond a week is “iffy”
11. Continuous Communication & Integration Follows the general “Principle of Least Surprise” Teams are “self organizing” Have the responsibility and ability to identify and remove roadblocks Autonomous – sets its own policies and procedures within the context of the larger organization’s Everyone on the team knows what everyone else is doing Use “Big Visible Charts”
12. User Stories Similar to “use cases” and “functional requirements documents”, but not… :-) The basic idea is to quickly (a sentence – a paragraph) give description of what’s needed The point is to encourage collaboration over contracts while still providing the written record of what is needed Describe external behaviors of the system understood by the custmer
13. Test Driven Development Write tests as early as possible QA helps define/ensure functionality features Use a tool to track the tests PHPUnit, Selenium Continuous Integration Environment Automate integration testing Cruise Control Testing done all the time No big “OMG, we have to test this thing now”
14. Sample Timeline Four week cycle Lots of discussion before project is “approved” and started by dev team Week one is overlap with previous cycle Working out estimates, assignments, design Week two-three heavy dev work Week four – dry runs to launch, testing
15. What Are The 3 Questions? 1. What have you completed (relative to the Backlog) since the last Scrum meeting? 2. What got in your way of completing this work? 3. What will you do between now and the next Scrum meeting?
16. At the End of a Sprint? Status meeting with all stakeholders. Increments are delivered. Surprises are reported. ANYTHING can be changed, work can be added, eliminated, re-prioritized. New estimates and team assignments are made for the next Sprint. The project can be cancelled. “Experience from earlier increments allows better estimates and planning as project progresses.It's always easier to estimate shorter development periods”
17. Planning Iteration Collect all user stories Pick one feel its easy and give it worth 1 Select all stories with same worth level 1 Select stories with twice work of worth 1 mark as worth 2 Repeat that to get stories with worth 4 Select stories with worth between 2 and 4 and mark it as worth 3 Create a card for each stories with its worth
18. Planning Iteration Count total stories point Estimate one story with worth 1 (e.g. 5 man/days) Total estimation for release = total point * (worth1 estimation) Example total estimation = (17 point) * 5 = 85 man/days If we have 2 developers then its should completed in 43 man/days
19. Planning Release Capacity Planning Sprint (Iteration) = 2 weeks = 10 days Sorties shouldn’t exceed our capacity Capacity = 10 days / (estimation for worth 1 story=5) * number of developer (2) = 4 story point for one sprint Customer should prioritize stories Customer should select stories with total point no more than 4 points E.g. story one & two = 3 points After sprint completed in two weeks, developer still need 0.5 point to complete Then team velocity is 3- 0.5 = 2.5 points per sprint instead of 4 points
20. Planning Release Now we have estimation for all release 17 (total points)/ 2.5 (velocity)= 7 sprints to complete all stories Each sprint is 2 weeks Then we have 2 * 7 = 14 week to complete release If 14 weeks are not suitable (exceed deadline) then we have to tuning scope
21. Tuning Scope If deadline will complete 12.5 story points and there is 4.5 story point out from this release We have three approaches Increase number of developer to meet deadline Take out some stories from this release Break down some stories worth by splitting card one for release 1, and one for next release