Dinosaur Carpaccio - How to implement valuable micro-requirements
Upcoming SlideShare
Loading in...5
×
 

Dinosaur Carpaccio - How to implement valuable micro-requirements

on

  • 188 views

Un punto chiave dello sviluppo software è dato dal rilascio continuo di valore al cliente finale e in questo scenario uno degli strumenti più attuali per descrivere i requisiti sono le user story. ...

Un punto chiave dello sviluppo software è dato dal rilascio continuo di valore al cliente finale e in questo scenario uno degli strumenti più attuali per descrivere i requisiti sono le user story. Molti team, ancora oggi, faticano a realizzare storie piccole e quando ci provano finiscono spesso con l'ottenere ‘layer’ dell’architettura orizzontale e non micro soluzioni verticali che attraversino tutti gli strati (dalla UI alla persistenza). Tale situazione fa si che l'assunto iniziale decada e il valore portato al cliente nella migliore delle ipotesi non sarà continuo (nella peggiore nullo).

Statistics

Views

Total Views
188
Views on SlideShare
188
Embed Views
0

Actions

Likes
2
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Dinosaur Carpaccio - How to implement valuable micro-requirements Dinosaur Carpaccio - How to implement valuable micro-requirements Presentation Transcript

  • ROME 11-12 april 2014ROME 11-12 april 2014 Dyno Carpaccio – come implementare micro requisiti di valore Fabio Armani Stefano Leli f.armani@open-ware.org - stefano.leli@gmail.com @fabioarmani @sleli
  • ROME 11-12 april 2014
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • Un punto chiave dello sviluppo software è dato dal rilascio continuo di valore al cliente finale e in questo scenario uno degli strumenti più attuali per descrivere i requisiti sono le user story. • Molti team, ancora oggi, faticano a realizzare storie piccole e quando ci provano finiscono spesso con l'ottenere ‘layer’quando ci provano finiscono spesso con l'ottenere ‘layer’ dell’architettura orizzontale e non micro soluzioni verticali che attraversino tutti gli strati (dalla UI alla persistenza). • Tale situazione fa si che l'assunto iniziale decada e il valore portato al cliente nella migliore delle ipotesi non sarà continuo (nelle peggiori, nullo).
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • The Dyno Carpaccio exercise is a great way for software people to practice & learn how to break stories into really thin vertical slices. It also leads to interesting discussions about quality and tech practices. • The original exercise (Elephant Carpaccio) was invented by Alistair What is this? • The original exercise (Elephant Carpaccio) was invented by Alistair Cockburn. We’ve facilitated it a bunch of times and we encourage people to run it everywhere. • This is a detailed (shu-level) facilitation guide based on how Alistair runs it plus some minor adaptations from Henrik Kniberg and us. • The exercise takes 90-120 minutes, and scales well. We normally do it with 10-20 people but have also done it with groups up to 40.
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • 2 hours is best, 1.5 hour works but feels a bit rushed. • 15’ discussion about user stories • 20’ breaking down backlog • 45’ implementing Timing • 45’ implementing • 10’ debrief • It’s possible to skip the implementing part & just practice creating the backlog. But it takes away much of the fun, and you also miss out on interesting quality discussion at the end.
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli The purpose of this workshop is to learn to split stories really small…
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • Vertical, testable, user-valuable. • Cuts across multiple architectural layers. Story GUI Client Back End
  • Slicing StoriesSlicing Stories
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • Making thinner stories (but still vertical) Story Slicing BIG SMALL monthsweekshours daysminutes
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • How big are your stories? tasks? commits? • Target: • Story = a few days • Task = a few hours Discussion • Task = a few hours • Commit = several times per hour • Why split stories?
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • How big are your stories? tasks? commits? • Target: • Story = a few days • Task = a few hours Discussion • Task = a few hours • Commit = several times per hour • Why split stories? Discuss in pairs
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • Learn faster • Deliver more often • Happier stakeholders • More in-sync with other people & teams Why split stories • More in-sync with other people & teams • Better prioritizations • Better product earlier
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • More business options • Less risk (less time “underwater”) • Sense of velocity • Easier planning Why split stories • Easier planning
  • ROME 11-12 april 2014 Big stories Small stories Waterfall Big stories
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • Decision of “how small” should not be limited by “we can’t split this story”. • In this workshop we will practice by exaggerating. • We will make stories so tiny that anything you do today seems big How Small • We will make stories so tiny that anything you do today seems big in comparison.
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • Build a simple application in 45 minutes, divided into 3 iterations x 15 minutes. • Most people would build this app in 2-3 slices, we will do it in 15-20. • Dyno Carpaccio = very thin slices, each one still dyno-shaped. What we will do • Dyno Carpaccio = very thin slices, each one still dyno-shaped. Together they form the whole dynosaur.
  • ROME 11-12 april 2014
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli
  • ROME 11-12 april 2014
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli Requisito #1 Come utente vorrei vedere dov'è l'auto più vicina rispetto alla mia posizione attuale in modo da poter individuarla velocemente e poterne fruire comodamente. Requisito #2 Come utente vorrei poter prenotare l'auto desiderata in modo da poterla ritrovare una volta giunto nel luogo dove si trova parcheggiata. The product Requisito #3 Come utente vorrei poter conoscere lo stato dell'auto (livelli di benzina, stato generale, etc) in modo da potermi fare un'idea del veicolo prima di prenderlo. Requisito #4 Come amministratore delegato vorrei consentire una tariffazione basata sull'effettivo utilizzo dell'autovettura in modo da distinguere il mio servizio dagli autonoleggi tradizionali. Requisito #5 Come addetto alla manutenzione vorrei poter conoscere (automaticamente) tutte le auto che hanno problemi in modo da poter organizzare le ispezioni e le riparazioni. Requisito #6 Come utente vorrei poter effettuare Login e Logout dell’app.
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • Split into groups of 5 or 6. Each group should have at least one designer with the POP Prototype app installed. • Pop Prototype • 10 minutes: write your backlog Create the Backlog • 10 minutes: write your backlog • Write 10-20 demo-able user stories (“slices”) that will take you from nothing to all requirements implemented. • Each should be implementable (including user interface) in 2-6 minutes. • All demos show new interfaces, and are noticeably different from last slice.
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • What is your next slice? • Key point: minimum key stroke per slice! • 5 minutes: make make your slices smaller. Try for at least 15 slices. Create the Backlog
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • This workshop is primarily about story slicing, but adding UX practices aspects gives it extra spice. How will you work?
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • 45 minutes, 3 iterations, 15 minutes per iteration. • At the end of each iteration, We will call out “demo time!”. That means stop coding, and demonstrate your app to another team. • Time doesn’t stop between iterations! So don’t spend too much time Build It • Time doesn’t stop between iterations! So don’t spend too much time on demo. • Shout “slice” whenever you finish a slice. • Go!
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • How far did you get? (mark each team’s approximate position on the value curve) • How many slices did you have? • Acceptance test: Review • Acceptance test: • Show the app in POP Prototype.
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • Non-programmers: What was it like? • Programmers: What was it like? • How is your app quality, how proud are you of your app? (each programmer hold up 1-5 fingers). Debrief
  • ROME 11-12 april 2014 Fabio Armani, Stefano Leli • Any other questions or reflections? • Round-robin: What did you learn? What will you do? • Name one take-away insight from today, and one thing you will do differently in the future. Debrief differently in the future.
  • @sleli@sleli stefano.leli@gmail.comstefano.leli@gmail.com @@fabioarmanifabioarmani f.armani@openf.armani@open--ware.orgware.org