We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byAdrianna Bussell
Modified about 1 year ago
v1.0 How Much Documentation Is Useful Documentation? SQNZ, April 2013, Wellington What level of documentation and when to produce it, is a hot topic in agile teams. It should be a hot topic in all developments. How much shelf-ware do you write because it's "good practise"? Who actually reads it critically and to what benefit? What could we do differently that would create greater engagement in the same content? When is best? © 2013 Smart m atix Ltd
v1.0 Which is you, in the spectrum of documentation? 2 / 11 © 2013 Smart m atix Ltd Home grown; Typically No stds, overlap, bloatware; in places, too much and too little RUP no tools; Limited definition, due to lack of tools; XP Explicitly no doc definition; Code docs only ISO / DoD 498 Clean precise definition of docs; Tailor / trim in method RUP with tools; Strong definition Scrum Limited definition; no std in itself Waterfall stages like PRINCE2 Method = 2-3 month cycles; can be 1 week! Bi-week cycle 2-5 day cycle
v1.0 What do we need? Some points to consider 3 / 11 © 2013 Smart m atix Ltd doc Business Case Close doc Maintain? Restore? SLA? RFC? Release? The more you write the harder it is to change coderefactor Templates are not forms to fill in …
v1.0 4 / 11 SR What should it be? a tree of small artefacts “Decompose”, “identify”, & don’t drown in detail … Test Artifacts UseCase / User story Test Strategy / Plan Vision HLD Interface Req. Spec’s Code Artifacts © 2013 Smart m atix Ltd
v1.0 5 / 11 Why document? – validate & communicate Problem domain UseCase Design Stake Holders (vision doc) TestCase hierarchy Code hierarchy Req. set Interface specs What is the UseCase of a car? Where is component “make …” © 2013 Smart m atix Ltd
v1.0 Documents to validate – but wait … © 2013 Smart m atix Ltd You call this Agile?
v1.0 Who actually reads it? Maintenance! © 2013 Smart m atix Ltd M S W
v1.0 8 / 11 What can we do? - what level and when?! © 2013 Smart m atix Ltd
v1.0 What can we do? – stop writing; sketch © 2013 Smart m atix Ltd 9 / 11 What’s the danger?!
v / 11 © 2012 Smart m atix Ltd Manifesto for Agile Software Development 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.
v1.0 Debating time Food for thought re documentation & purpose: ► What’s good practice (ISO XP)? ► What could we do differently that would create greater engagement? ► How to make / keep it agile? ► What information to keep? User Stories? ► What can we do with tools? 11 / 11 © 2013 Smart m atix Ltd Smart m atix - Productivity tools and know-how for IT, projects & programs
v1.0 Appendix for eventualities 12 / 10 © 2013 Smart m atix Ltd
v1.0 Large 52 week project – 26 sprints 13 / 24 © 2012 Smart m atix Ltd inceptionElaborationConstructionTransition
v / 24 Balancing specs and WBS – now robust Use Case Descript. Vision SRS IRS: UI / Report’s Glossary FPA: Basic ERD-s HLD UseCase List WBS = A deliverable oriented breakdown of work, anything on the WBS is in scope, anything not on it is out of scope. A WBS is NOT a task list Validation! System (is done) Forum (is done) Handle versions CRUD books CRUD tpls News Edit On-line Upload Manage collection 61 91 pages – 709 FP, 4 mths © 2012 Smart m atix Ltd
v1.0 © 2007 SmartMatix 15 / 39 What happens when things change? Business Req. UCs Test Plan, cases, scripts Develop Design, code, build Exe SRS Vision Software Spec. … before long no quality! Re-factor … “Agile”“Planned”
v1.0 What can we do? - Right sizing © 2012 Smart m atix Ltd 16 / 26
Copyright 2015, Robert W. Hasker. Classic Model Gathering Requirements Specification Scenarios Sequences Design Architecture Class, state models Implementation.
CompSci 230 Software Design and Construction Software Quality 2015S1 Traditional approach to testing (Waterfall)
Chapter 3 – Agile Software Development Pepper modification of Sommerville presentation & Colm O’hEocha – AgileInnovation Ltd presentation 1Chapter 3 Agile.
Feb Alten Group Started in France in 1988 Currently more than people Presence in 10 countries Active in The Netherlands since 2002.
Software Development Models: Waterfall and Spiral Sung Hee Park Department of Mathematics and Computer Science Virginia State University August 21, 2012.
Presented by Dustin Friel, PMP CSM May 6, 2009 Agile Lessons Learned 1.
Classical vs. Agile Requirements Development Svetlin Nakov Telerik Software Academy academy.telerik.com Senior Technical Trainer
Agile Methodology Paul Mohrbacher. Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through.
Introduction to Agile. Objectives High level overview o Agile o Scrum Take Home Message o Gain enough of an understanding of Agile and Scrum to see how.
Agile Process Models. Prescriptive models don’t work It is unrealistic to not have changes. Why? The Agile Manifesto: Individuals and interactions over.
Agile Software Development Matt Rice November 27, 2006.
Agile development By Sam Chamberlain. First a bit of history..
Cultivating Agile Requirements Mark Wavle, CBAP, PSM.
Iterative Development: Done Simply Emily Lynema NCSU Libraries Code4Lib 2010.
CPSC 372 John D. McGregor Process Module 1 Session 1.
CPSC 871 John D. McGregor Processes – a first iteration Module 1 Session 1.
Pfleeger and Atlee, Software Engineering: Theory and Practice CS499 Chapter 2 Modeling the Process and Life Cycle Shari L. Pfleeger Joanne M. Atlee 4 th.
Project Strategies [A&N 1,2] Wishnu Prasetya. Managing a large software project Software Development Life Cycle (SDLC) Typical phases in : Planning, Requirement,
Agile at ON.Lab Bill Snow VP of Engineering. What is waterfall? RequirementsDesignDevelopTest Or Requirements Design Develop Test Time.
SEG4911 – Projet génie logiciel en fin d’études / Software Engineering Capstone Project Thoughts about Agile Design and Release Management Timothy C. Lethbridge.
Agile Development Chapter 10 - part 2. Agile Philosophy A guiding philosophy and set of guidelines for : developing information systems in an unknown,
Project Workflow. How do you do it? -Discussion-
Dr. Rob Hasker. What if every project used Scrum? Why might Scrum not be perfect for every project? Hard to get the big picture Early choices may have.
BEFORE AGILE METHODS Other Engineering fields development models were used, ie: Waterfall Method: Intensive planning and refactoring before coding is actually.
SCRUMBAN?!?! What is it and how can it help your team?
Dr. Rob Hasker. Should every project use Scrum? When might Scrum not be an appropriate model? What are some of its limitations? Hard to get the big.
1 COMP 350: Object Oriented Analysis and Design Lecture 2Iterative, Evolutionary and Agile References: Craig Larman Chapters 1-2.
BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting July 14, Interactive Solutions Delivery Methodology What.
Marc Conrad University of Bedfordshire 1 Project Management – PMBOK® Project Management Plan Dr Marc Conrad Office: D104 – Park Square
© Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
Unified process(UP) UP is an OO system development methodology offered by Rational(Rational Rose) s/w, now a part of IBM Developed by Booach,Rambaugh,Jacobson--
Who is Gregg? 1 Mile
Chapter 2 Iterative, Evolutionary, and Agile You should use iterative development only on projects that you want to succeed. - Martin Fowler 1CS
Copyright © , RoleModel Software, Inc. The Continuous Refinement of Extreme Programming Ken Auer RoleModel Software, Inc.
The Challenge to Survive in Today’s Software Development Environment Evaluating the Agile Methodology.
Programming with eyes wide open. Your host today Subby Angelov Team
Delivering Enterprise Projects Using Agile Methods Brent Barton May 23, 2006.
CSPC 464 Fall 2014 Son Nguyen. 1. The Process of Software Architecting, Peter Eeles, Peter Cripss 2. Software Architecture for Developers, Simon Brown.
Informed Traveler Program and Applications Agile / Scrum Overview Jerry Inberg.
Rally: One Writer’s Perspective. Background 28 years in technical communications including Symantec, Autodesk, and Cisco. Participated in Rally-based.
Agile Programing Methods Drew Arrigoni. The Agile Manifesto ● Individual Interactions over Processes and Tools ● Working Software over Comprehensive Documentation.
Sofia Event Center May 2014 Martin Kulov Agile Project Management with Team Foundation Server.
Agile Methodology. -Dhanashree Kumkar -Plus91 Technologies.
Chapter 3 Agile Software Development (1/2) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
Software Development Practices and Methodologies Svetlin Nakov Telerik Corporation
1/2/12 Chapt 2 Iterative Evolutionary Agile. 1/2/12 (Rational) Unified Process A software development process – Flexible and open Other processes – XP.
Agile Software Development Robert Moore Senior Developer Curtin University.
Current Trends in Systems Develpment Satzinger, Jackson, and Burd Object-Orieneted Analsys & Design Chapter 14.
© 2017 SlidePlayer.com Inc. All rights reserved.