Konsten att skriva dåliga lappar
Upcoming SlideShare
Loading in...5
×
 

Konsten att skriva dåliga lappar

on

  • 623 views

Hur väl teamet lyckas med en iteration eller sprint beror till stor del på hur väl det estimerar det kommande arbetet, samt hur indelningen i tasks görs. Det finns ett antal generella urtyper av ...

Hur väl teamet lyckas med en iteration eller sprint beror till stor del på hur väl det estimerar det kommande arbetet, samt hur indelningen i tasks görs. Det finns ett antal generella urtyper av dåliga tasks - lappar, som med stor sannolikhet försenar eller sänker leveransen. De beskrivs och exemplifieras i presentationen.

Talare är Alexander Tarnowski från Acando

Statistics

Views

Total Views
623
Views on SlideShare
616
Embed Views
7

Actions

Likes
0
Downloads
3
Comments
0

1 Embed 7

http://www.slideshare.net 7

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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

Konsten att skriva dåliga lappar Konsten att skriva dåliga lappar Presentation Transcript

  • Konsten att skriva dåliga lappar Alexander Tarnowski (alexander.tarnowski@acando.com)
  • Dåliga lappar – vadå?
    • Story planning: viktigt och knepigt
    • Skillnad mellan framgång och misslyckande?
    • … Det beror på
  • Horisontell uppdelning
    • Premierar design och eftertanke
    • Perfekt parallellisering
    • Utvecklarna väntar på varandra
    • Problem med ofärdig funktionalitet, saknade gränssnitt, integration
  • Vertikal uppdelning
    • Läxa från den horisontella uppdelningen
    • Jobba hela vägen genom alla lager
    • Bristande samordning
    • Dålig konceptuell integritet
    • Extra refactoring kan behövas
  • Förstudie/design/spike
    • Första lappen i storyn
    • Lägger grund för resten av lapparna
    • Blockerar (oftast en stor) story
    • Kan försämra planeringen, eftersom man räknar med att dålig planering kan kompenseras med ”design”
    • Kan vara resultatet av en dålig story
  • Externa beroenden
    • Lappens slutförande är beroende på interaktion med en användare, leverantör eller ett system
    • Kan inte undvikas i verkliga livet
    • Börja tidigt
    • Ha inte för många
  • Korta formuleringar
    • Exempel ”Update GUI” eller ”Implement”
    • Alla på planeringen är rörande överens om vad dessa korta formuleringar betyder
    • Vad händer om storyn kommer sent i Sprinten eller flyttas till en senare Sprint?
  • Slutlig integration eller refactoring
    • Man förstår under planeringen att summan av alla lappar inte bildar den slutliga produkten
    • En DTS 1) -lapp skapas för att säkerställa att man kommer ihåg att räkna in den tid som behövs för att få allt att fungera ihop
    • Lappar lämnas halvfärdiga, eftersom man litar på att någon städar upp
    • Svår att estimera
    • Kan göras för tidigt
    1) Do the Shit
  • Sluttest
    • Integrationstest eller något slags acceptanstest
    • Kan vara beroende av en extern resurs
    • En del team är skonade
    • Ta höjd för att Sprinten blir kortare!
  • Sammanfattning – Dolda kritiska linjer
    • Dålig början: förstudie -> implementation -> slutlig integration -> sluttest
    • Dålig fortsättning: inför en kritisk linje genom implementationslapparna också
    • Dålig dynamik och lidande arbetsglädje
    • Sträva mot hög parallellism