Specification by Example
•Télécharger en tant que PPTX, PDF•
2 j'aime•3,695 vues
Specification by Example talk given at Software Craftsmanship and Testing Camp in Germany, 2011. This talk is focused on the "why" and the "what" of Specification by Example.
Recommandé
Contenu connexe
Tendances
Tendances (12)
En vedette
En vedette (15)
Similaire à Specification by Example
Similaire à Specification by Example (20)
Plus de Sergey Shishkin
Dernier
Dernier (20)
Specification by Example
- 1. Specification by Example and a journey towards it Software Craftsmanship and Testing Camp,Germany 2011 Sergey Shishkinhttp://shishkin.org @sshishkin
- 2. ~40 people PM, DEV, QA teams 3 months releases
- 10. What is software specification?
- 11. Documentation
- 12. Validation
- 18. Conference Registration Conference price is 1000 Euro Early bird discount is 100 Euro Group 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/ Images Ruler: http://www.flickr.com/photos/sterlic/4299633060 How projects really work: http://www.projectcartoon.com Waterfall: http://www.flickr.com/photos/kayakaya/4488993689 Bananas: http://www.flickr.com/photos/sveinhal/2488796267 Books: http://www.flickr.com/photos/horiavarlan/4263328317, http://www.flickr.com/photos/horiavarlan/4264037742 Paper waste: http://www.flickr.com/photos/mwparenteau/432039783 Matrix: http://www.flickr.com/photos/trinity-of-one/20562069 Bugs: http://www.flickr.com/photos/tywak/2940451425
- 20. Sergey Shishkin http://shishkin.org sergei.shishkin@gmail.com @sshishkin
Notes de l'éditeur
- Set expectations:Real story of a software product development teamNot focused on a tool“Why” & “what”“How” in a follow-up deep-dive workshop
- The Beginning:Strict waterfall processSpecialized people organized by their functionLong release cycles
- PM’s goal was to prepare the specification document before the “specification freeze”.Working ahead of development.
- 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.
- 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?
- 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?
- 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.
- 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.
- 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.
- So what is a spec?Why do we need one?What makes it good?
- Although agile values working software more than comprehensive documentation, documentation is still an important function of a spec.Up-to-date documentation is costly.
- Spec provides a foundation for validation.Automated validation is not the goal of specification.
- 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.
- We must preserve intent at least.
- At best we aim to understand real business goals and derive the scope from them.
- Spec defines not only what the product should do, but also what it should not.
- Good spec is a lo-fi, just-in-time tool for transforming blurry ideas into crisp products.
- 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.