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
Applying Agile Methodologies to Traditional Publishing Kristen McLean Bookigee, Inc. February 12 th, 2011.
Agile Software Development Robert Moore Senior Developer Curtin University.
Feb Alten Group Started in France in 1988 Currently more than people Presence in 10 countries Active in The Netherlands since 2002.
Basic SDLC Models. Agenda SDLC definition Waterfall SDLC V-Shape SDLC Spiral SDLC RUP SDLC Agile methods.
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--
Keith McMillan Principal, Adept Technologies Copyright (C) 2008, Adept Technologies llc.
Presented by Dustin Friel, PMP CSM May 6, 2009 Agile Lessons Learned 1.
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Rapid Software Development IS301.
Iterative Development: Done Simply Emily Lynema NCSU Libraries Code4Lib 2010.
My Top Ten Agile Planning Tips Mike Kuphal PMP, CSP J.J. Keller & Associates, Inc. Twitter: Welcome! Enjoy the Food.
Software Development Practices and Methodologies Svetlin Nakov Telerik Corporation
Lecture 4 Process and Method: An Introduction to the Rational Unified Process.
Unit-V -SOFTWARE QUALITY. To develop and deliver robust system, we need a high level of confidence that Each component will behave correctly Collective.
JASS 2006Agile Project Management - Scrum1 Introduction Classical methods of software development have many disadvantages: -huge effort during the planning.
Extreme Programming ( an introduction ). Software Engineering Computer programming as an engineering profession rather than an art or a craft Meet expectations:
Agile and Open Development Neil Chue Hong, OMII-UK Ross Gardler, OSS-Watch JISC e-Infrastructure Programme Meeting Birmingham, 7 Feb 2008.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Chapter 8 Software Prototyping.
Best Practices for Implementing An Information Solution By Even Brande.
Requirements analysis and specification CSE432 Object-Oriented Software Engineering.
1 Evolutionary Development T. Gilb. The Agile Alliance A group of writers, developers and consultants, mostly from the OO (object- oriented community)
Group Projects Making working software as a team Bruce Scharlau, University of Aberdeen, 2011.
Ch-11 Project Execution and Termination. System Testing This involves two different phases with two different outputs First phase is system test planning.
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps Unit - II.
Project Management in Team Software Projects The primary challenge of project management is to achieve all of the goals of the project charter while adhering.
Software Development QA Best Practices May 20, 2010 Suzette Hackl, CSM Senior Project Manager Skyline Technologies, Inc.
The. of and a to in is you that it he for.
Requirements Elicitation Requirement techniques Presentation based on courses given at SEI Carnegie Mellon (USA) and Kingston Univ (GB)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Information & Decision Support Center (IDSC) – Egypt © M. Khorshed Effective Request for Proposal for effective businesses.
Collaborative Code Construction: Code Reviews and Pair Programming CPSC 315 – Programming Studio Spring 2009.
© 2016 SlidePlayer.com Inc. All rights reserved.