10. I P C E M&C Source Rita Mulcahy 7.6.2011 - Saarbrücker Reihe
11. Product Life Cycle for IT Projects I I I I I I I I P P P P P P P P C C C C C C C C E E E E E E E E M&C M&C M&C M&C M&C M&C M&C M&C 7.6.2011 - Saarbrücker Reihe
12. Value Steam I I I I I I I I P P P P P P P P C C C C C C C C Lead Time Lead Time Lead Time E E E E E E E E M&C M&C M&C M&C M&C M&C M&C M&C Lead Time Lead Time Lead Time Lead Time 7.6.2011 - Saarbrücker Reihe
15. Winston W. Royce (1929–1995) was an American computer scientist, director at Lockheed Software Technology Center in Austin, Texas, and one of the leaders in software development in the second half of the 20th century.[1] He was the first who described the Waterfall model for software development, although Royce did not use the term "waterfall" in that article, [2] nor advocated the waterfall model as a working methodology. 7.6.2011 - Saarbrücker Reihe
16. Winston Royce’s “Grandiose” Model 7.6.2011 - Saarbrücker Reihe “Single Pass” phased model to cope with US DoDregulatory requirements “I believe in this concept, but the implementation is risky and invites failure.” Winston W. Royce, “Managing the development of large software systems”, Aug 1970 Source: SilvanaWasitova
17. Winston Royce’s Recommendation 7.6.2011 - Saarbrücker Reihe Iterations between phases, hopefully confined to successive steps Source: SilvanaWasitova
18. Winston Royce’s “Problem” Model 7.6.2011 - Saarbrücker Reihe Problem:Testing phase, at the end of Development cycle, is the first time the integrated components are “experienced”. Failure may require a major redesign, or modifying the requirements. Can expect up to 100% schedule and/or cost overrun. Source: SilvanaWasitova
27. Product Backlog High priority Sprint Medium Priority Release Future Releases 7.6.2011 - Saarbrücker Reihe
28. Assumptions The customer do only have to define the vision The customer do not really know the whole scope – wetoo! To maximize value and reducerisk, iteration planning sounds the best solution to measureeffectiveness And give us freedom to on-going change 7.6.2011 - Saarbrücker Reihe
30. Who are the stakeholders? 7.6.2011 - Saarbrücker Reihe
31. The power of Scrum comesfrom Time-boxing 4 hours 4 hours 4 hours 3hours Sprint Planning Sprint Review Retrospective Sprint Planning 15’ Daily Meetings SPRINT 30 days 7.6.2011 - Saarbrücker Reihe
32. PMBOK Strengths Process oriented Clearproject kickoff & administrative initiation Enumeration of stakeholders, formalizedcommunication plan More explicitly calls for cost management Outlinesrisk management approach: identification, qualitative and quantitative analysis, response planning 7.6.2011 - Saarbrücker Reihe Source: SilvanaWasitova
33. Scrum Strengths Empowered, self-organizing team Collaboration, cross-fertilization, shared responsibilities & commitments Allows for adjustments and learnings produce a better results Risk management smaller units of work more accurate Frequent checks fewer surprises & delays Welcomes voice of the customer 7.6.2011 - Saarbrücker Reihe Source: SilvanaWasitova
Source: SilvanaWasitovaWinston W. Royce,Managing the development of large software systemsProc. IEEE WESCON, Aug 1970Royce developed the phased delivery model to cope with regulatory requirements set out in the US DoD STD-2167 document, which was so byzantine and bureaucratic that the waterfall was the only way to cope with it;
Source: SilvanaWasitovaWinston W. Royce,Managing the development of large software systemsProc. IEEE WESCON, Aug 1970Royce’s Son:http://usability.typepad.com/confusability/2006/02/index.html
Source: SilvanaWasitovahttp://www.techdarkside.com/is-there-really-any-rigor-in-waterfallIt is sad that software development philosophies and practices developed in a world of government regulation, punch cards, and very expensive computer time still have such a strong a hold on today’s commercial software development.Ben Simohttp://QuestioningSoftware.com
Source: SilvanaWasitovaDiscipline:Structured approach,Plan aheadmodel itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand; it also provides easily markable milestones in the development process.Steve McConnell, in Code Complete, (a book that criticizes widespread use of the waterfall model) refers to design as a "wicked problem"—a problem whose requirements and limitations cannot be entirely known before completion. The implication of this is that it is impossible to perfect one phase of software development, thus it is impossible if using the waterfall model to move on to the next phase.David Parnas, in A Rational Design Process: How and Why to Fake It, writes:[5]“Many of the [system's] details only become known to us as we progress in the [system's] implementation. Some of the things that we learn invalidate our design and we must backtrack.”The idea behind the waterfall model may be "measure twice; cut once," and those opposed to the waterfall model argue that this idea tends to fall apart when the problem constantly changes due to requirement modifications and new realizations about the problem itself. A potential solution is for an experienced developer to spend time up front on refactoring to consolidate the software, and to prepare it for a possible update, no matter if such is planned already. Another approach is to use a design targeting modularity with interfaces, to increase the flexibility of the software with respect to the design.[edit] Modified modelsIn response to the perceived problems with the pure waterfall model, many modified waterfall models have been introduced. These models may address some or all of the criticisms of the pure waterfall model.[citation needed] Many different models are covered by Steve McConnell in the "lifecycle planning" chapter of his book Rapid Development: Taming Wild Software Schedules.
Source: SilvanaWasitovaDiscipline: rhythm, daily scrum, work agreements, consistentAgile approach is Great Risk Management:Risk of not pleasing the customerRisk of poor estimation and planningRisk of festering issues and delaysRisk of over-commitmentRisk of not being able to ship