Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Doc is a Four Letter Word
Ähnlich wie Doc is a Four Letter Word (20)
Mehr von Matt Badgley
Mehr von Matt Badgley (9)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Doc is a Four Letter Word
- 1. DOC Is Not a Four Letter Word 1 © 2013, VersionOne, Inc. All Rights Reserved
- 2. The Dude in Front Of You • About the speaker – Matt Badgley, CSM, CSPO, ABC – Technical Product Consultant and Agile Coach with VersionOne – 19+ year Information Technology professional • Contact Information – matthew.badgley@versionone.com – @agilemaniac, @versionone – http://www.linkedin.com/in/mattbadgley 2 © 2013, VersionOne, Inc. All Rights Reserved
- 3. Points of Discussion Contention of Agile and Documentation 3 © 2013, VersionOne, Inc. All Rights Reserved
- 4. Points of Discussion Tips For how Agile and Documentation can get along ... 4 © 2013, VersionOne, Inc. All Rights Reserved
- 5. Points of Discussion Agile Requirements 5 © 2013, VersionOne, Inc. All Rights Reserved
- 6. Exercise - Documentation You Use or Create • Write down the types of documentation that you use and or create – Use post-it notes and sharpies – use one post-it per documentation type • When finished, bring up and place your documentation in the right project state column 6 © 2013, VersionOne, Inc. All Rights Reserved
- 7. Working over Comprehensive Software Documentation That is, while there is value in the items on the right, we value the items on the left more. - agilemanifesto.org 7 © 2013, VersionOne, Inc. All Rights Reserved
- 8. So what does Agile say about Documentation? JBGE 8 © 2013, VersionOne, Inc. All Rights Reserved
- 9. Customer over Contract Collaboration Negotiation 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. - agilemanifesto.org 9 © 2013, VersionOne, Inc. All Rights Reserved
- 10. Why We Document Share Downstream Compliance Information Usage / Audit to Deliver 10 © 2013, VersionOne, Inc. All Rights Reserved
- 11. Exercise - What is your Doc For? • Back up on our board, there are three new horizontal lines: – Top Lane = Compliance / Audit – Middle Lane = Share Information to Deliver – Bottom Lane = Down Stream Usage • Sort the documentation in each column into their right horizontal lane 11 © 2013, VersionOne, Inc. All Rights Reserved
- 12. Tips for Agile Documentation Thanks to Jason Tee and Scott Ambler for this list • Focus on The Truth • Document Decisions • Who needs to know? • Use your writers appropriately – Coders code, Tech Writers write • Favor Accuracy and Brevity • Use Self-documenting Code – It’s the tests stupid • Make Documentation Transparent Uncle Bob Martin • Do the Minimum Required (a.k.a. JBGE) 12 © 2013, VersionOne, Inc. All Rights Reserved
- 13. 13 © 2013, VersionOne, Inc. All Rights Reserved
- 14. 14 © 2013, VersionOne, Inc. All Rights Reserved
- 15. TAGRI! 15 © 2013, VersionOne, Inc. All Rights Reserved
- 16. They aren’t Going to Read It (TAGRI) Examples of TAGRI How to prevent TAGRI • Requirements never read • Treat Documentation Like by Development any other Backlog Item • PowerPoint Architecture • Create for clear audience • Documentation After The • Always question how it’s Fact (DATF) going to be used • The Magical Process Doc • Long-life vs. Short-life • Mongol the User Manual • Just Barely Good Enough • Single information source 16 © 2013, VersionOne, Inc. All Rights Reserved
- 17. Agile Requirements 17 © 2013, VersionOne, Inc. All Rights Reserved
- 18. What Are Agile Requirements? • JBGE • Multiple forms – User Story (XP, Kent Beck, Mike Cohn, etc.) – Ultra-light Use Case (Alistair Cockburn) – Story Mapping (Jeff Patton) • Decomposed to the point to be “delivered” in an iteration • INVEST • Key Element - Definition of Done (DoD) 18 © 2013, VersionOne, Inc. All Rights Reserved
- 19. How to JBGE Your Requirements • Five Why your documents • Use a Wiki (with stats) • Define “Ready” 19 © 2013, VersionOne, Inc. All Rights Reserved
- 20. Examples of “Ready” • User Story defined • User Story Acceptance Criteria defined • User Story dependencies identified • User Story sized by Delivery Team • Scrum Team accepts User Experience artifacts • Performance criteria identified, where appropriate • Person who will accept the User Story is identified • Team has a good idea what it will mean to Demo the User Story 20 © 2013, VersionOne, Inc. All Rights Reserved
- 21. Life of a Story Start with a Title and add a concise 1. description Scenario: Enter Valid Information New User Registration Given I have entered test@test.com into email field And I have entered Smith into last name field As a general user, I need to be And I have entered Jane into first name field able to enter my email And I have entered goodpassword into password field address, my first name, last name, and a password so that When I press Register I can securely access the site. Then The result should be a confirmation screen And An email is sent to test@test.com And A user record is created 3. Before building software, write the acceptance criteria (how do we know when we’re done?) 2. Add other relevant notes, specifications, or sketches This is modeled after Jeff Patton’s, “Stories gain detail over time” slide. 21 © 2013, VersionOne, Inc. All Rights Reserved
- 22. Agile Requirements Life-cycle 22 © 2013, VersionOne, Inc. All Rights Reserved
- 23. Exercise - Rationalize Your Documentation • Working together – for each section – sort the pieces of documentation with the most used at the top of the section and least used at the bottom – Remove those documents that everyone agrees would be better handled via verbal communications – Flag those documents/diagrams that should be part of Ready criteria – simply write an “R” in the bottom corner 23 © 2013, VersionOne, Inc. All Rights Reserved
- 24. Wrapping UP JBGE 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 24 © 2013, VersionOne, Inc. All Rights Reserved
- 25. ? 25 © 2013, VersionOne, Inc. All Rights Reserved
- 26. Thank You 26 © 2013, VersionOne, Inc. All Rights Reserved
- 27. Credits and Resources • Jason Tee, Project Documentation and Agile Development, http://www.theserverside.com • Scott Ambler & Associates, http://www.agilemodeling.com • Scott Adams, Dilbert, http://www.dilbert.com/ • Ken Power, Definition of Ready, http://systemagility.com/2011/05/17/definition-of-ready/ • Bill Murray, Picture from the motion picture Meatballs • Pictures of Mike Cohn, Kent Beck, Jeff Patton, Bill Wake, Alistair Cockburn, Ron Jeffries, and Scott Ambler taken from the net 27 © 2013, VersionOne, Inc. All Rights Reserved
Hinweis der Redaktion
- Agile is not prescriptive about documentation, besides promoting two things – face to face communications and let’s value the completed software over creating some document that doesn’t provide value.When we are using agile, we focus on the idea of delivering sufficient information for the task at hand – or just barely good enough. This means – whatever is most effective for what we need to get done. This can be a point of contention because it is very situational – or contextually driven based on what is being produced. So – its fluid over time. Also, it does not imply low quality.The other key around agile and lean is that we want to maximize value and flow, thus optimizing speed to market – but we have to do this without impacting quality – again a challenge.Finally, I’ve already mentioned face-to-face, but most long term agile practicioners will tell you the key is that we don’t want to use documentation in leiu of face-to-face communication. When we talk, especially face-to-face – there’s more communicating going on than just the sounds we make. There are cues we exhibit by body language, tone, attentiveness – that help us figure out if we are figuring it out.