Specification by Example
Download as PPTX, PDF2 likes3,720 views
The document outlines an event focused on software craftsmanship and testing, held in Germany in 2011, with around 40 participants from project management, development, and QA teams. It discusses the concept of software specification, offers information on conference registration fees and discounts, and includes various resource links related to the topic. The author, Sergey Shishkin, provides his contact information and references materials relevant to the discussion.
Specification by Example
- 1. Specification by Exampleand a journey towards itSoftware Craftsmanship and Testing Camp,Germany 2011Sergey Shishkinhttp://shishkin.org@sshishkin
- 2. ~40 peoplePM, DEV, QA teams3 months releases
- 10. What is software specification?
- 11. Documentation
- 12. Validation
- 18. Conference RegistrationConference price is 1000 EuroEarly bird discount is 100 EuroGroup discount for 3 people or more is 10%
- 19. Links and Credits„Bridging the Communication Gap“ by GojkoAdzic:http://www.acceptancetesting.info/the-book/„Specification by Example“ by GojkoAdzic:http://specificationbyexample.com/ImagesRuler: http://www.flickr.com/photos/sterlic/4299633060How projects really work: http://www.projectcartoon.comWaterfall: http://www.flickr.com/photos/kayakaya/4488993689Bananas: http://www.flickr.com/photos/sveinhal/2488796267Books: http://www.flickr.com/photos/horiavarlan/4263328317, http://www.flickr.com/photos/horiavarlan/4264037742Paper waste: http://www.flickr.com/photos/mwparenteau/432039783Matrix: http://www.flickr.com/photos/trinity-of-one/20562069Bugs: http://www.flickr.com/photos/tywak/2940451425
Editor's Notes
- #2: Set expectations:Real story of a software product development teamNot focused on a tool“Why” & “what”“How” in a follow-up deep-dive workshop
- #3: The Beginning:Strict waterfall processSpecialized people organized by their functionLong release cycles
- #4: PM’s goal was to prepare the specification document before the “specification freeze”.Working ahead of development.
- #5: Dev’s solely responsibility was to write code.No influence on product design => creativity in code (layers, patterns, abstractions for the sake of themselves).No responsibility for quality.
- #6: Fear of blame leads to over-specificationOver-specification leads to inconsistent and outdated specs as soon as development beginsInconsistent specs cause blameHow much business value does a complete specification alone contribute?
- #7: QA’s goal was to find and file as many “bugs” as possible in the rest of the time -> much stressHow much does a filed bug contribute to quality?How much rework does it cost?
- #8: Metaphor: Ivan Krylov‘s fable about a swan, a pike (fish) and a crayfish, who teamed together to carry a wagon. Despite of their good will and effort the wagon stood still because each pulled in a different direction.PM were flying in the sky, Dev drove the product aside, while QA slowed the product down by creating rework.
- #9: At that time we started to implement Scrum.It was the same waterfall, compressed to fit into four weeks sprints.It became apparent that we could not deliver planned business value while following old habits.Specification by example helped us to “invert” our workflow and made Scrum actually work.
- #10: The “Bridging the Communication Gap” book by GojkoAdzic was a breakthrough for me:The best way to explain and specify something is to provide examples;Software specification is a collaborative effort;QA is better involved from the beginning, thus building quality in, not verifying it afterwards.
- #11: So what is a spec?Why do we need one?What makes it good?
- #12: Although agile values working software more than comprehensive documentation, documentation is still an important function of a spec.Up-to-date documentation is costly.
- #13: Spec provides a foundation for validation.Automated validation is not the goal of specification.
- #14: The main function of a spec is communication of the product intent during development.Short releases prevent big mistakes in the end of the project, but don’t save us from doing smaller mistakes each iteration.Mistakes are rework.
- #15: We must preserve intent at least.
- #16: At best we aim to understand real business goals and derive the scope from them.
- #17: Spec defines not only what the product should do, but also what it should not.
- #18: Good spec is a lo-fi, just-in-time tool for transforming blurry ideas into crisp products.
- #19: This is an example of a specification by example.Who can spot a disambiguation in it?Nevertheless provided with examples this specification leaves no room for misinterpretation.Given this example, a team will further discuss the price calculation model, discount precedence etc.A critical mind will even ask, how a group is identified? Can two separate registrations build a group for a discount?This discussion is exactly what specification is for.This time is exactly right for this type of discussions.