En agil systemutvecklingsprocess. Vattenfallsmodellen. Manifesto for Agile Software Development. Agila modellen.

Transkript

1 En agil systemutvecklingsprocess Annika Silvervarg Vattenfallsmodellen Manifesto for Agile Software Development Agila modellen Sprint 0 Strategic intake & research (Strategic intake & research) (Product statement) (Design koncept) Technical solution outline Practical agreements Setting up the room Definition of done Start on Product backlog Market and end-user Competition? Market? End-users? Brand Defined brand? tone-of-voice? Corporate visual identity? 1

2 Product statement Design koncept Template: For (target customer) who (statement of need or opportunity) the (product name) is a (product category) that (key benefit, compelling reason to buy) Graphic profile Conceptual design Example: trakz.nl is a trustworthy online music store, we are personal and passionate about music! Technical solution outline Practical agreement Can include legacy system limitations CMS characteristics When do you work? Where do you work? Contact information, , phonenumbers. When do you have stand-up meetings (and how)? When do you demo (test) and with whom? When and how do you do the retrospective? Setting up the room Definition of Done Hardware The room Supplies Software Dropbox? GIT, SVN, Scrumboard Trello, wiki, excel, google docs, Technical requirements Devices? Browsers? Documentation? How tested? User experience How does it feel? Tests with external people? Customer acceptance Who decides when done is done? 2

3 Start on product backlog User story template The backlog is a prioritized features list, containing short descriptions of all functionality desired in the product, typically in the form of User stories, which are short, simple descriptions of the desired functionality told from perspective of the user "As a shopper, I can review the items in my shopping cart before checking out so that I can see what I've already selected." Title (one line describing the story) As a [role] I want [user need] So that/because [resulting ability] OR As a [role] I can [do/view something] User story examples A good user story INVEST Independent, of other stories Negotiable, not a contract Valuable, to customer or end user Estimable, enough information and reasonable scope Small, coded and tested within half a day to two weeks Testable, clear definition of done Sprint 1-6 Release planning Release plan Iteration plan Velocity Time estimates Planning poker Prioritise Scrum board and Burn down chart Daily scrums Demo and Acceptance testing Retrospective 3

4 Release Planning Customer presents the desired features to the programmers as user stories Programmers estimate their difficulty Customer lays out a plan for the project Initial release plans are necessarily imprecise. However, even the first release plan is accurate enough for decision making and teams revise the release plan regularly Release planning Step 1: Writing user stories Customers write user stories Stories can be assigned business value: essential, highly valuable or good idea (or a more fine grained scale, eg. 1 to 10) Developers can suggest stories but the customer has always final say Stories can always be added, changed or deleted Release planning Step 2: Time esitmation Developers estimate how long the stories might take to implement Each story will get a 1, 2 or 3 days estimate in ideal development time Longer than 3 days means that the customer need to break the story down further and less than 1 day that it is at too detailed a level, combine some stories Stories can be assigned technical risk: low, medium, high Release planning Step 3: Prioritising stories Together developers and customers move the cards around on a large table to create a set of stories to be implemented as the first/next release A useable, testable system that makes good business sense delivered early is desired You may plan by time or by scope either how many stories can be implemented before a given date (time), or how long a set of stories will take to finish (scope) Iteration planning During Iteration planning, the Customer presents the features desired for the next iteration The programmers break them down into tasks, and estimate their cost (at a finer level of detail than in Release Planning) Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration Iteration planning Step 1: Project velocity and scope Project velocity is calculated based on previous iterations (initial velocity often set to 50%) Velocity = completed stories divided by actual hours 59/84h = 70% Time for next iteration = velocity * time * number of pairs 70% * 28h * 3 = 59 h (ideal time) Customer choose prioritised stories from release plan Failed stories/tasks from the previous iteration to be fixed are also selected 4

5 Iteration planning Step 2: Creating tasks The user stories and failed tests are broken down into the programming tasks that will support them by the developers Tasks are written down on index cards like user stories While user stories are in the customer's language, tasks are in the developer's language Duplicate tasks can be removed Each story has a corresponding task card for writing an acceptance test together with the customer Iteration planning Step 3: Time estimation Estimates are made by the team and tasks divided at the end of the session, or put in a stack where developers choose tasks one at a time Each task should be estimated as 1, 2, or 3 ideal programming hours in duration Tasks which are shorter than 1 hour can be grouped together and tasks which are longer than 3 hours should be broken down farther or developers sign up to do the tasks and then estimate how long their own tasks will take to complete Planning poker Planning poker Alla i teamet estimerar en story/task Väljer ett kort/skriver en siffra Alla visar upp sitt val samtidigt Den som valt minst tid och den som valt mest tid diskuterar och enas om en estimering Finns flera varianter Finns appar att använda istället för kortlek SCRUM Board Burn down chart 5

6 Demo and Acceptance tests Acceptance test Short presentation of the process of the sprint (preconditions, constraints, impediments, etc.) Short walk through of the product, explaining decisions made (focus on what, not how) Customer (stakeholders) sit down individually and go through users stories using the system and judge if acceptance tests pass or fail Failed acceptance tests are collected for next iteration Scrum master have closing discussion with customers and bring the most important bits back to the team Acceptance tests are created from user stories During an iteration the user stories selected will be translated into acceptance tests by the customer A story can have one or many acceptance tests, each acceptance test represents some expected result from the system Customers are responsible for verifying the correctness of the acceptance tests and decide which failed tests are of highest priority to fix in the next iteration Acceptance test template Acceptance test examples Scenario 1: Title Narrative: Given [context] (And [some more context]...) When [event] Then [outcome] (And [another outcome]...) User story test Criteria for acceptance Retrospective Retrospective Inspect and adapt Draw a timeline of the sprint on a whiteboard Sit down individually (5 min) Write positive things on green post its Write negative things on pink post its Place the post its on the timeline (2 min) Look at the board and discuss what you wrote to identify patterns or clusters (5 min) Choose max 3 things you want to improve (5 min) 6

7 Sprint 0 (Strategic intake & research) (Product statement) (Design koncept) Technical solution outline Practical agreements Setting up the room Definition of done Start on Product backlog Sprint 0 Att Göra Sprint 0 Att Göra Grupp: Utse en scrum master Grupp: Gå igenom scheman och gör en detaljerad planering för vilka tider gruppen ska jobba. Bestäm ett lämpligt straff för sen ankomst (t.ex. bjuda gruppen på fika) Scrum master: Välj en lämplig yta på en stor whiteboard och rita upp en scrum board (se nedan) Grupp: Se till att ett möte med kunden äger rum. Utbyt kontaktuppgifter och kom överens med kunden om hur kommunikationen under projektet ska fungera Kund: Delta i möte med projektgruppen och gör en översiktlig beskrivning av det planerade systemet (inklusive syfte, vision, etc). Eventuella sekretessavtal skrivs lämpligtvis under vid detta möte Kund: Förbered user stories och förmedla till projektgruppen Grupp: Genomför en tekniköversikt och riskanalys gällande val av teknikplattformar (utvecklingsverktyg, programspråk, databashanterar, etc). Sprint 1-6 Release plan Iteration plan Velocity Time estimates Planning poker Prioritise Scrum board and Burn down chart Daily scrums Demo and Acceptance testing Retrospective Före sprint start Scrum master: Uppdatera backlog (justera och lägg tillbaka stories som fått fail). Scrum master: Se till att material finns på plats (pennor, postits, etc). Kund: Förbered nya user stories (vid behov) och lägg dem i Backlog. Gör en prioritering av alla user stories i Backlog. Grupp: Tidsestimera alla user stories i Backlog i prioritetsordning. 7

8 Sprint start Grupp: Välj ut en mängd user stories (i prioriteringsordning) så att den uppskattade summan av tider stämmer ungefär överens med den tillgängliga tiden för user stories denna sprint (ta hänsyn till förra sprints velocity vid beräkning av tillgänglig tid). Grupp: Bryt ner valda user stories till tasks och skriv tasklappar. Kund: Det är bra om kunden finns tillhands och kan svara på frågor då stories bryts ner till tasks (antingen på plats eller via telefon/chat). Grupp: Tidsestimera alla tasks med Planning poker. Skriv den överenskomna tiden på respektive task-lapp. Om summan av tiden för alla tasks som ingår i en story är mycket större än den uppskattade tiden för storyn, kontakt kunden för en diskussion. Ska en annan story släppas från denna sprint? Ska storyns omfång (scope) definieras om? Ska prioriteringen av stories ändras? Allt är möjligt. Scrum master: Placera lapparna för alla valda stories på tavlan. Alla stories och deras tillhörande tasks placeras i kolumnen Not Started och sorteras i prioriteringsordning med högst prioritet överst. Grupp: Kör ett kort scrum-möte för att avgöra vem som börjar med vad. Varje gruppmedlem (eller par om man kör parprogrammering) väljer en task, och skriver sitt namn på lappen och flyttar den till kolumnen Started. Scrum master: Ritar upp ny burn-down chart: x-axeln speglar antal arbetsdagar som ingår i denna sprint. Y-axeln speglar summan av tidsuppskattningarna för alla tasks som hör till utvalda stories. Under sprinten - Scrum-möten i början av varje arbetsdag Scrum master: Leder mötet och fördelar ordet. Grupp: Varje gruppmedlem besvarar kortfattat tre frågor: 1) Vad har jag gjort sedan förra mötet? 2) Vad åtar jag mig att göra till nästa planerad scrum möte? 3) Finns det något som hindrar mig i mitt åtagande (behöver jag hjälp med något)? Grupp: Alla gruppmedlemmar uppdaterar tidsuppskattningarna av de tasks de jobbar med. Om en task är färdig flyttas den till kolumnen Done. Om alla tasks för en user story är klara flyttas lappen med storyn till kolumnen Ready for Review. Scrum master: Uppdaterar burn-down chart så att den stämmer med de nya återstående tiderna. Scrum master: Om aktuell status i burn-down chart avviker väsentligt från ideallinjen, ska kunden kontaktas och informeras om läget. Tänkbara resultat från denna kontakt kan t.ex. vara att en eller flera user stories tas bort från denna sprint (eller läggs till om utvecklingen gått bättre än förväntat). Om så är fallet ska burn-down chart uppdateras så att den speglar det nya läget. Sprint end Scrum master: Allokera en timme för demon. Schemalägg med kunden i god tid. Grupp: Dema systemet för kunden, och gå igenom alla user stories som gjorts under sprinten. Kund: Avgör om det blir pass/fail för varje user story. User stories som fått fail skrivs om och läggs tillbaka i backlog. 8

9 Scrum master: Allokera en timme för retrospective. Äger rum efter demon (kunden deltar ej). Scrum master: Gå igenom sprinten som ägt rum och påminn om bra och dåliga saker som inträffat. Grupp: Varje gruppmedlem (inklusive scrum master) skriver (under tystnad) post-its med Plus (saker som gått riktigt bra under sprinten) och Delta (saker som inte fungerat under sprinten). Scrum master: Be varje medlem komma fram och sätta upp sina post-its på tavlan och kortfattat förklara vad som menas. Ingen diskussion. Scrum master: gå igenom alla positiva post-its på tavlan, summera och be om eventuella kompletterande kommentarer. Scrum master: gå igenom alla Delta post-its på tavlan, summera och diskutera igenom det hela med gruppen. Vad kan vi som grupp göra för att undvika dessa Delta? Grupp: Rösta om vilka Deltan som gruppen ska jobba med att förbättra under nästa sprint (tre röster per gruppmedlem). Tre Deltan väljs ut. Lapparna för dessa Deltan placeras på gruppens whiteboard. Dessa tas också upp för diskussion vid nästa Retrospective. Gick det bättre nu? Scrum master: Behåll lapparna för uppföljning. Scrum master: Efter retrospective rensar scrum master upp scrum board för att göra plats för nästa sprint, och beräknar den aktuella sprintens hastighet (velocity). Scrum master: Fyller i sprintformuläret och lämnar in till läraren. 9