ITT 2018 - Jakub Nabrdalik - User Stories considered harmful

Transcript

1. User Stories considered harmful Why Product Owners and Developers failed at gathering requirements and communication The lost art of analysis and testing scenarios Jakub Nabrdalik Allegro
2. whoami jakub nabrdalik team lead & senior engineer @allegro details: solidcraft.eu linkedin: pl.linkedin.com/in/jnabrdalik 15 years of exp in $dev
3. whatis allegro 10k servers 600+ engineers 700+ microservices on discovery 13.5k requests/second 200 mln visits / month 11k deployments / 6 months (~90 per day) java, groovy, scala, kotlin, go... Spring (Core/Boot/Cloud) as a common ground
4. whatis bottega
6. “As an Editor I want article categories to be updated, when allegro categories are updated, so that articles are still visible on pages” - [PO] How long will that take? - But how exactly should it work? - [PO] I don’t know, that’s why it’s on the grooming.
9. “User stories: Provide a small-scale and easy-to-use presentation of information, with little detail, thus remaining open to interpretation, through conversations with on-site customers.” “User stories are Invitation to discussion”
12. “A user story is a promise for a conversation.” (Alistair Cockburn) “User stories: […] remaining open to interpretation, through conversations with on-site customers.”
13. Do you see any on-site customer in here?
15. “I like offending people, because I think people who get offended should be offended.”
16. “You really need to have the people-people, the communicators, the warm and friendly people, who like really want to hug everybody and get you into the community, but that's not everybody. That’s not me.”
17. So how bad are we? Stackoverflow Global Developer Survey 2018 Depression and Other Common Mental Disorders Global Health Estimates: World Health Organization: 2017 Mental health issues like depression and anxiety are particularly common among our respondents [developers]. In the United States, almost 20% of respondents said they deal with either or both. Mood or emotional disorder (depression, bipolar, etc.) Developers 8.5% | Global population: 4.4% Anxiety disorder Developers 7.8% | Global population: 3.6%
19. - optimise meetings (make them shorter) - write down requirements, so we cannot get them wrong
21. Use cases “Use case flows describe sequences of interactions, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own.”
22. Alistair Cockburn - Writing Effective Use Cases Title: "an active-verb goal phrase that names the goal of the primary actor" Primary Actor Goal in Context Scope Level Stakeholders and Interests Precondition Minimal Guarantees Success Guarantees Trigger Main Success Scenario Extensions Technology & Data Variations List
23. Use cases simplified Title: "goal the use case is trying to satisfy" Main Success Scenario - Step by step, what happens Extensions: separately numbered lists, one per Extension - Step by step, ALL the corner cases, errors, bad data, and WHAT should happen
24. [...] well-specified requirements are as formal as code and can act as executable tests of that code! [Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship]
25. def "publish article successful flow"() { given: "new article data is prepared" NewArticleDto newArticleDto = sampleNewArticle() when: "new article is created" ArticleQueryDto articleQueryDto = facade.createArticle(newArticleDto) articleId = articleQueryDto.id then: "user can find this article" getArticle(articleId) != null and: "new article has an id" articleId != null when: "article's title is updated" UpdateArticleDto updateDto = updateDtoWithTitle(articleId, "updated") facade.updateArticle(updateDto) then: "returned article has a new title" getArticle(articleId).title == "updated" when: "article is previewed" PreviewResultDto previewResult = facade.previewArticle(updateDto) then: "system returns preview url" previewResult.previewUrl == "https://allegro.pl/preview/popart/preview-article/${articleId}" when: "article is submitted" facade.updateAndSubmitArticle(updateDto) then: "system changes article status to SUBMITTED" getArticle(articleId).status == "SUBMITTED" when: "article is published" facade.updateAndPublishArticle(updateDto) then: "system changes article status to PUBLISHED" getArticle(articleId).status == "PUBLISHED" when: "article is updated and republished" facade.republish(updateDtoWithTitle(articleId, "republished")) then: "system returns updated article" getArticle(articleId).title == "republished"} }
26. Story: Returns go to stock In order to keep track of stock As a store owner I want to add items back to stock when they're returned. Scenario 1: Refunded items should be returned to stock Given that a customer previously bought a black sweater from me And I have three black sweaters in stock. When he returns the black sweater for a refund Then I should have four black sweaters in stock. Scenario 2: Replaced items should be returned to stock Given that a customer previously bought a blue garment from me And I have two blue garments in stock And three black garments in stock. When he returns the blue garment for a replacement in black Then I should have three blue garments in stock And two black garments in stock.
28. Story: Returns go to stock In order to keep track of stock As a store owner I want to add items back to stock when they're returned. Scenario 1: Refunded items should be returned to stock Given that a customer previously bought a black sweater from me And I have three black sweaters in stock. When he returns the black sweater for a refund Then I should have four black sweaters in stock. Scenario 2: Replaced items should be returned to stock Given that a customer previously bought a blue garment from me And I have two blue garments in stock And three black garments in stock. When he returns the blue garment for a replacement in black Then I should have three blue garments in stock And two black garments in stock.
29. Business analyst + System analyst Typical deliverables: - Functional requirements, i.e. logical data models, use case scenarios, work instructions, reports... - Non-functional requirements - ...
30. Minimum viable analysis for non obvious features Step 1: Write Behavioural Specifications (plain english), with the customer Step 2: Write BDD scenarios (main and extensions) Step 3: Write down all non-functional requirements Step 4: Design the architecture Step 5: Get comments, ideas & approvals from all devs Step 6: Estimate (get everybody to play blinded poker)
31. Minimum viable analysis for non obvious features Step 1: Write Behavioural Specifications (plain english), with the customer Step 2: Write BDD scenarios (main and extensions) Step 3: Write down all non-functional requirements Step 4: Design the architecture Step 5: Get comments, ideas & approvals from all devs Step 6: Estimate (get everybody to play blinded poker)
32. Minimum viable analysis for non obvious features Step 1: Write Behavioural Specifications (plain english), with the customer Step 2: Write BDD scenarios (main and extensions) Step 3: Write down all non-functional requirements Step 4: Design the architecture Step 5: Get comments, ideas & approvals from all devs Step 6: Estimate (get everybody to play blinded poker)
33. “You don’t understand the problem until you have developed a solution” [Wicked Problems - Jeff Conklin]
34. Plans are useless but planning is important Do not expect to design a final solution Expect to eliminate waste and learn Thought experiments are cheaper than coding Refining requirements is a difficult art that you have to study There are many methods of gathering requirements, but POs tend to fixate on user stories, and teams follow them. And this is dangerous.
35. jakubn@gmail.com @jnabrdalik If your only tool is a hammer, every problem looks like a nail User Stories are great for discussions, but that’s about it Allegro