Introduction to DSDM
•
16 j'aime•5,928 vues
Steve Messenger, Director DSDM Consortium presented this talk on DSDM at the Agile India 2006 conference
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Introduction to DSDM
Similaire à Introduction to DSDM (20)
Plus de Naresh Jain
Plus de Naresh Jain (20)
Dernier
Dernier (20)
Introduction to DSDM
- 1. Meeting a Need Steve Messenger Director DSDM Consortium www.dsdm.org
- 2. The Next Hour… • History of Development • Where DSDM fits in • The Key Points • It’s not all theory • The bit in the middle • Offshore www.dsdm.org
- 3. Development is as Easy as ABC! Choose Vendor Throw Over the Wall Create Specification Receive Perfect System www.dsdm.org
- 4. As Easy as ABC? No User Involvement Poor Collaboration And Cooperation don’ Systems That don’t meet Requirements www.dsdm.org
- 5. What is actually being used? 7% 13% Ne ve r us e d 16% R are ly us e d S o m e tim e s us e d O fte n us e d A lways us e d 45% 19% Source: Standish Group Research Note, 1999 www.dsdm.org
- 6. RAD – The Wild West Your Your software’s on software’s on it’s way sir it’s way sir www.dsdm.org
- 7. Enter… DSDM – 1993 • Deliver Business Value from IT • Recognized: – Nothing built perfectly first time – There will be business change – People are key to success – involve all stakeholders – Can move forward as soon as enough is known • But managed – Quality – Control – User Expectation www.dsdm.org
- 8. Manifesto for Agile Software Development - 2001 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we 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, we value the items on the left more. www.dsdm.org
- 9. Individuals and interactions over processes and tools • DSDM PRINCIPLES – Active user involvement is imperative. – DSDM teams must be empowered to make decisions. www.dsdm.org
- 10. Working software over comprehensive documentation • DSDM PRINCIPLES – Fitness for business purpose is the essential criterion for acceptance of deliverables. – The focus is on frequent delivery of products – Requirements are baselined at a high level. – Testing is integrated throughout the life-cycle. www.dsdm.org
- 11. Customer collaboration over contract negotiation • DSDM PRINCIPLES – A collaborative and co-operative approach between all stakeholders is essential. www.dsdm.org
- 12. Responding to change over following a plan • DSDM PRINCIPLES – Iterative and incremental development is necessary to converge on an accurate business solution. – All changes during development are reversible www.dsdm.org
- 13. Tenets of Project Management • Frozen specs and the abominable snowman are alike: they are both myth and they both melt when sufficient heat is applied. www.dsdm.org
- 14. The DSDM Lifecycle •Scope / Prioritise Requirements •Will Proposed Solution Satisfy? •Outline Development •DSDM Suitable / Risks? •Identify User Classes •Possible technical solutions •Risks •Time / cost estimates •Technical Basis •Deliver System •Demonstrate / Agree Functionality •Train Users •Record Non-Functional Requirements •Operational Handover •Determine future requirements •Build in non-functional requirements •Make fit for delivery www.dsdm.org
- 15. Tenets of Project Management • A user will tell you anything you ask about and nothing more www.dsdm.org
- 18. Team Dynamics • Tightly-Managed Teams Self-Directed Teams Take Initiative – Take Directions Focus on team Contributions – Seek Individual Rewards Concentrate on solutions – Focus on Low-Level Cooperate Objectives Continually Improve – Compete Take steps to prevent – Stop at pre-set goals emergencies – React to emergencies Roles www.dsdm.org
- 19. Tenets of Project Management • You can con a sucker into committing to an unreasonable deadline, but you can’t bully him into meeting it www.dsdm.org
- 20. The DSDM Philosophy Prioritisation www.dsdm.org
- 21. The DSDM Philosophy Time fixed Implementation Timebox DBI Time fixed FMI Increment n Increment m Time fixed Increment 1 Project Time fixed www.dsdm.org
- 22. Prioritisation Using MoSCoW • Must – has to be done – C. 60%, < 75% • Should – important but may be worked around short-term – 20% • Could – may be left out if necessary – 20% • Won’t – add to list to be done next time www.dsdm.org
- 24. The Tenets of Project Management • What is not on paper has not been said www.dsdm.org
- 25. Quality • “Conformance to Requirements” www.dsdm.org
- 26. Quality • “Conformance to Requirements” www.dsdm.org
- 28. Quality in DSDM • Quality Planned from start – Product Quality Criteria • Facilitated Workshops • Continuous Focused User Involvement • Reviews – Prototypes – Supporting Documents • Testing Throughout Lifecycle • Base-lined Requirements • Configuration Management www.dsdm.org
- 29. Testing Principles • Validation – Product is Fit For Business Purpose • Benefit Directed – Concentrate testing on key areas • Error Centric – Purpose is to find errors • Integrated Throughout the Lifecycle – And users involved throughout • Independent • Repeatable – Test Scripts / Testing tools www.dsdm.org
- 30. Case Study – The Boston Globe • 18 Months wasted previously • One Team – Grindel’s Den! • 2 Major Deliveries – 8 Weeks – 12 weeks • Frequent Review Sessions • System also implemented in NYTimes www.dsdm.org
- 31. Case Study – Insurance Claims • Well Known City Underwriter • SSADM Project failed (2 years) • Short Business Study • Workshops • One Team • Split development • New system implemented in 9 months www.dsdm.org
- 32. Case Study – Pharmaceutical Dispensing • Heavily Controlled Environment • All principles of DSDM Used • Separate Testing Phase • System that Users Own www.dsdm.org
- 33. DSDM and Validation Validation Planning Validation Summary Validation Planning Validation Summary Reporting and Certification Reporting and Certification Response Business Process Definition and Performance Qualification Business Process Definition and Performance Qualification GMP Assessment GMP Assessment Verify Verify Design Qualification (after stepwise refinement) Design Qualification (after stepwise refinement) Cut over PROTOTYPING REVIEWS PROTOTYPING REVIEWS Check Evolving Design Installation and Operational Evolving Design Installation and Operational Qualification Qualification Verify Verify Bespoke Programming and Bespoke Programming and Configuration Configuration Check Prototyp e and Pilot www.dsdm.org
- 34. DSDM and Validation Validation Planning Validation Summary Validation Planning Validation Summary Reporting and Certification Reporting and Certification Response Business Process Definition and Performance Qualification Business Process Definition and Performance Qualification GMP Assessment GMP Assessment Verify Verify Design Qualification (after stepwise refinement) Design Qualification (after stepwise refinement) Cut over PROTOTYPING REVIEWS PROTOTYPING REVIEWS Check Evolving Design Installation and Operational Evolving Design Installation and Operational Qualification Qualification Verify Verify Bespoke Programming and Bespoke Programming and Configuration Configuration Check Prototyp e and Pilot www.dsdm.org
- 35. Bridging the Gap Starting Directing Controlling Managing Ending a Project a Project a Stage Stage Boundaries a Project Management Project Business Change Controls Mgmt. Org. Case Control Tools Quality MoSCoW Prioritisation Planning Risk Mgmt Architecture Timeboxing Estimating Feasibility Study Business Study Development Implementation Prototyping Configuration. Mgmt Modelling Testing Analysis Facilitated Workshops Project Team Org Refactoring Pair Programming Delivery Sustainable Continuous Collective Code Test-driven Simple Coding Pace Integration Ownership Development Design Standards www.dsdm.org
- 36. DSDM and PRINCE PRINCE DSDM Business Case Project Mandate Project Plan Acceptance Project Brief Outline Plan Start-up Criteria Feasibilty Study These control documents are prepared and updated throughout Feasibility Report the project as Communication required Plan Project Business Study Initiation Initiation + Planning Document Checkpoint Report Management Project Aspects Approach B.A.D. OutlinePrototyping S.A.D. Plan Management Aspects Quality Log Stage Plan Stage 1+ Planning End Stage Report Risks / Issues / Exceptions / Project may run to Lessons Logs several stages Functional Model Functional Model Work Packages / Iteration Timebox Plans Implementatinn Strategy Product Checklist Stage x + Planning Stage Plan Design and Build End Stage report Requests for Implementation Iteration Change Close End Project Report Project Review User Delivered System Design Prototypes Tested System Document Documentation Change Control Log Trained Users Post Project Post-implementation Review Specialist Management Product Mixed Product Product www.dsdm.org
- 37. Offshore • Many offshore projects fail or are delayed • Solution: DSDM Offshore – Amended standard DSDM – Only one team! – Several extra roles needed – Existing roles need additional tasks – Additional risks – Few additions to phases • Communication is vital www.dsdm.org
- 38. There Is One Team! New Roles New Responsibilities for Existing Roles www.dsdm.org
- 39. Summary • Framework for Agile Development • Flexibility with Control • Users Integrated into the process • Defined Lifecycle • Defined Products • Defined Roles • Quality not compromised www.dsdm.org • www.dsdm.org