Information via diagram inom ett XP-team

Transkript

1 Information via diagram inom ett XP-team Staffan Åberg, Ludvig Åhlin D01, Lunds Tekniska Högskola Februari 2004 Abstrakt Detta arbete är inriktat på att förklara på vilket sätt man kan använda diagram i ett XPprojekt. Olika diagramtyper som Gantt, PERT, UML och dyl. kommer att beskrivas samt på vilket sätt man kan använda dem i ett XP-projekt. Hur de olika diagrammen fungerar och hur vissa coacher har tänkt använda olika typer av diagram kommer även att presenteras. 1

2 1 Inledning Att använda diagram för att presentera information har använts länge. Att diagram har stora fördelar jämfört med ren fakta har kanske många redan insett. Därför är det bra att kunna många typer av diagram som passar till olika tillfällen. Inom programmeringsvärlden finns det ett antal diagram som har tagits fram för att passa in på dessa situationer. Gantt, PERT och UML är exempel på sådana diagram. Hur diagram framförs och hur de anpassas till situationen är även en intressant aspekt när det gäller att använda sig av diagram på bästa sätt. 2 Bakgrund I kursen Coaching av Programvaruteam på Lunds Tekniska Högskola har vi varit coacher för två olika team. Det första teamet bestod av åtta utvecklare och två coacher och det andra med nio utvecklare och två coacher. De labbar och planeringsmöten vi haft med utvecklarna har gett oss en hel del uppslag till detta arbete. Varje vecka har vi även haft coachmöten där vi har diskuterat fortskridandet i de olika grupperna. Vi har även gjort en mindre undersökning bland några coacher för att se hur de har tänkt använda diagram i sina projekt. En del exempel har även tagits från våra egna team för att visa hur diagram kan användas och vilka som är de olika fördelarna och nackdelarna. 3 Olika Diagramtyper 3.1 Gantt Gantt-diagram är en vanlig typ av diagram för planering och uppföljning av olika typer av projekt, inte bara inom programmeringsvärlden. Det är vida spritt, kanske på grund av dess enkelhet. Det är enkelt att skapa, det är enkelt att uppdatera och det är enkelt att avläsa. Diagram av den här typen konstrueras oftast under planeringsfasen av vattenfallsprojekt. Man bör inte göra det i agila metoder såsom Extreme Programming, utan att dra nytta av att man kan kontinuerligt uppdatera diagrammet och använda det som en överskådande källa till framgång. I XP-projektet är det lämpligt att mäta framgång i antalet implementerade stories. Följande diagram är automatgenererat efter iteration 3 från Internet [11]. 2

3 Varje story upptar en rad och är färgad för att visa vem som är ansvarig. I detta fall gäller det personen som har spikat på den. Längst upp och längst ned på diagrammet syns tidslinjen. Den är markerad veckovis och symboliserar iterationstillfället. Är veckan upptagen med färg har, eller planeras den aktuella storyn att implementeras under det iterationstillfället. Eftersom vi, när diagrammet konstruerades, befann oss i iteration tre är de stories som sträcker sig till nästföljande vecka estimeringar. Man bör, för att göra diagrammet så överskådligt som möjligt, ta bort färdigimplementerade stories efter hand. Det är ett vågspel av coacherna. Ska man visa teamet hur framgångsrika de har varit eller göra det överskådligt för det aktuella läget? Vi har testat Gantt-diagram på våra två team. I det första teamet visades diagrammet ovan och en diskussion fördes om det. Utvecklarna upplevde det som väldigt positivt. Inte bara gav det en visuell upplevelse av hur mycket de faktiskt hade gjort utan gav även 3

4 en god planering inför nästföljande vecka. Det gav också en återblick på tidigare stories. Man fick en repetition av de funktioner som är implementerade och hur man gjorde detta. Tack vare de staplar som ofta symboliserar svårighetsgrad, kunde teamet sätta detta i relation till nuvarande stories. Teamet upplevde däremot diagrammet som en aning rörigt. Alla färger som korsade varandra hit och dit hade kunnat göras tydligare. Kanske kan man kombinera färg och text på ett mer finurligt sätt? Eller varför inte sätta en signatur, kanske första bokstaven på den ansvariges namn, på stapeln? I det andra teamet ritades diagrammet upp på whiteboard. Eftersom utvecklingen av programmet är så kort så valdes en tidslinje på två timmar istället för labtillfällen. Eftersom ansvariga på stories hade flyttats om väldigt mycket i teamet valdes ingen färgkodning för att visa ansvarig programmerare. Diagrammet togs emot, även i detta team, väldigt positivt. Utvecklarna kunde nu jämföra med sina estimeringar på ett enkelt sätt och planera inför nästa iteration. Vi förklarade tonvikten av att få färdigt stories, som andra stories byggde på, tidigt i iterationen. Eftersom Gantt-diagramet visade att dessa stories ofta var sådana som tog lång tid kom vi tillsammans fram till att en grundlig spike skulle göras på en story av sådan karaktär. 3.2 PERT PERT-diagram är ett utmärkt sätt att förmedla en bild av projektets fortskridande och styrka prioriteringar av stories gjorda av kund och coach. Nedan visas ett exempel på ett typiskt PERT-diagram hämtat från Internet [12]. 4

5 Varje ruta representerar en aktivitet, och varje aktivitet numreras. Aktiviteten tilldelas också en estimering av hur många dagar det tar för den att bli slutförd, den ges ett planerat startdatum och även ett planerat slutdatum. Pilarna representerar möjliga vägar efter att en aktivitet har blivit slutförd. Man kan inte påbörja en aktivitet om inte alla aktiviteter som har pilar till den önskade är slutförda. En kritisk väg är den ordning man måste slutföra aktiviteter i för att nå ett givet mål. Den här typen av diagram i den här utformningen är inte särdeles användbara i ett XPteam. Det är ett fantastiskt bra sätt att visa kritiska vägar - något som vi vill använda oss av. Först behöver vi bara göra vissa modifieringar för att den ska passa vår metodik. Det är viktigt att inte planera för mycket. Man vill ha ett överskådligt diagram utan att ge för mycket statisk information. Därför är det lämpligt att bara använda aktivitetsnamnet och behålla de kritiska vägar som tas fram i samråd med team och kund. Det ligger ingen vits i att konstruera den här typen av diagram före projektets start, utan det ska vara flexibelt för nya krav från kund och designändringar som ändrar förhållandet stories emellan. Team05 utvecklade ett diagram som liknar nedanstående hämtat från Internet [13]. Här visas stories som cirklar beroendet mellan dem som streck. Tidsestimeringen ges av det övre värdet i rektangeln och den verkliga implementationstiden ges av det nedre. Våra team tyckte att den här typen av diagram var nyttiga. Som utvecklare blir man upplyst av prioriteringsordningar på ett grafiskt vis och får det understruket om hur viktigt det kan vara att just den storyn som man själv jobbar med ska bli klar i tid. Det ger förhållanden stories emellan en helt ny typ av överskådlighet. 5

6 3.3 UML För att enkelt kunna se hur ett system är uppbyggt kan man använda sig av ett UMLdiagram. UML står för Unified Modeling Language och utvecklades under 1990-talet av Grady Booch, Ivar Jacobson och James Rumbaugh. UML går ut på att man skall rita diagram av ett systems olika delar och visa hur de samverkar. De olika diagrammen kan vara: aktivitetsdiagram, klassdiagram, sekvensdiagram och tillståndsdiagram. Aktivitetsdiagram är ett diagram som visar sambandet mellan aktörer och användarfall. Detta betyder ungefär att man visar på en mindre del av systemet hur det kan användas av en viss typ av simulerad användare. Ett klassdiagram visar hur klasser, gränssnitt och dess attribut interagerar med varandra. Man ritar upp en klass genom att i tre rutor under varandra skriva in klassnamn, attribut och metoder. Mellan klasser och gränssnitt ritar man sedan pilar som visar hur klasserna hör ihop. Olika pilar visar på olika typer av beroende. Med ett sekvensdiagram ritar man upp olika händelseförlopp. Genom att fundera ut ett vanligt användarfall kan man se hur systemet är tänkt att ge utslag på detta. Man följer händelseförloppet och ser vilka objekt som skapas samt när metoder påbörjas och avslutas. Tillståndsdiagram visar hur ett objekt fungerar generellt i alla klasser. I diagrammet ritar man upp olika tillstånd och övergångar mellan dessa tillstånd. 6

7 I våra projekt är det främst klassdiagram som vi använder oss av. Anledningen till att de andra inte används i samma utsträckning är för att de främst är lämpade att visa funktioner i systemet som en utomstående inte känner till. Om man behöver fråga kunden hur systemet skall fungera räcker det för det mesta att ha en liten diskussion om detta. Skulle problematik uppstå så kan det vara lönsamt att använda ett tillståndsdiagram eller ett sekvensdiagram. Vad som är bra med klassdiagram är att det är lätt att överblicka systemet med dem. Man kan enkelt se om klasser har de funktioner som de är tänkta att användas till, om hierarkin inom systemet är bra osv. I våra projekt har vi låtit utvecklarna spika på att tänka efter hur designen ser ut så att de sedan kan rita upp den på en whiteboard. Vi har använt oss av väldigt simpla klassdiagram utan attribut och metoder, som diagrammet ovan som är taget från team07s release 1B. Med ett diagram på tavlan så kan man enkelt starta diskussioner om vilka designval man har tagit och hur man kanske skulle kunna ändra designen. Vill man gå djupare i designen kan man lägga till metoder och attribut i klassdiagrammen för att se om metoderna ligger i rätt klass och om vissa attribut inte är nödvändiga. I projektet är det även tänkt att ett annat team skall se över systemet. Då kommer ett UML-diagram väl tillpass. I detta fall får man dock göra ett lite mer avancerat klassdiagram eftersom det är tänkt att visa upp ett system för någon som inte är insatt i systemet. 3.4 Diagram av Stories Som utvecklare vill man se framgång. Det är viktigt att visa denna framgång för sin grupp och göra den så rättvisande som möjligt. I Extreme Programming Installed [1] föreslår man att visa detta genom ett enkelt stapeldiagram: Antalet färdiga Stories Antal Stories Iter 1 Iter 2 Iter 3 Iteration Ej Färdiga Färdiga 7

8 Diagrammet visar antalet färdiga stories i förhållande till antalet stories mottagna av kunden efter iteration tre. Syftet är att ge en överskådlig bild av framgången, och inte att ge detaljkunskap av projektet. Jeffries, Anderson och Hendrickson understryker hur viktigt det är att visa sanningen för team och kund. Man kan lätt bli frestad att fuska med designen av diagrammet så att det visar en annan bild av sanningen, exempelvis genom val av skala på axlarna. Meningen är att visa sanningen för omvärlden, hur sur eller söt den än må vara. 4. Hur tänkte Coacherna? För att få en inblick om vad coacherna har för idéer och på vilket sätt man kan använda diagram under ett XP-projekt läste vi igenom de flesta av coachernas planeringar inför projektet - hemuppgift efter föreläsning 6. Det bör understrykas att hemuppgiften inte handlade om hur de tänkte använda sig av diagram, men att det i denna text ibland även fanns information om detta. I de 14 planeringsrapporter vi läste kunde vi se tre utstuderade tankesätt. Det första är att coacherna ser vikten av att använda en whiteboard. De anser att den är lätt att visualisera saker på och har en form av dynamik som är bra. Både utvecklare och kund kan lätt se diagram som är uppritade av på whiteboarden och samtala om dem. Eftersom whiteboarden är dynamisk kan man ändra information under samtalets gång och tillsammans komma fram till en lösning. Nästa tankesätt är att använda en hemsida som visualiseringsredskap. På en hemsida kan man visa vilka stories som är påbörjade/avklarade. Man kan även visualisera hur många acceptanstester som har gått igenom och liknande. Att ha en bild t.ex. en grön eller röd lampa, som visar status för en story, ser många som en stor fördel. Många inser att en hemsida kan ha nackdelar i det att den minskar kommunikation mellan utvecklare samt kommunikationen utvecklare/kund. Att använda allt för komplicerade diagram ser många som en fara. I studien finns det ingen som har tänkt använda PERT- eller Gantt-diagram. Coacherna tycker att det tar för lång tid att lära sig använda dem och rita upp dem. 4.1 Visualisering via Webbsida Att visualisera framgång via webben har många fördelar. För det första är Internet tillgängligt för alla, så informationsförmedling går väldigt smidigt till. Utvecklare och coacher uppdaterar kontinuerligt webbsidan med hur utvecklingen fortgår och kunden kan följa det med några enkla handvändningar. Sköts det rätt får man en ständigt uppdaterad informationskälla som alla kan ta del av. Man får en överskådlig bild över vilka stories som är implementerade och över vem som är ansvarig för dem som är under utveckling. Den gröna färgen är en bra psykologisk detalj som följer XP-metodiken genom att det som är grönt, det är bra! Nedan finns ett utdrag av en webbvisualisering från team02 i XP-projektet: 8

9 Vad vi saknar här är tidsaspekten. Det hade varit bra om man hade kunnat se när en viss story började implementeras och när den avslutades. Webbsidan bör också ge information om tidsestimeringen och hur lång tid storyn egentligen tog att implementera. Kort sagt, vi hade önskat en variant av ett Gantt-diagram. Tycker man att det blir för krångligt med den grafiska presentationen bör man åtminstone tillhandahålla informationen som ett Gantt-diagram ger. Team02 har medvetet valt att inte implementera den här funktionaliteten. De anser att det är ett onödigt stressmoment utan ser bara webblösningen som en form av grafiskt belöningssystem och informationsbas. 9

10 Story 16 : Hantera otillåtna startnummer : Carl och Dzevdan : 2 : Tog 2h Story 17 : Variabelt antal uppgifter : Tove och Martin : 2 : Tog 3h Story 18 : Sorterad resultatlista : Hans och Tove : 3 : Tog 12 Story 19 : Etapplopp : Hans och Erik : 4 Story 20 : Specialsträckor: Simon och Dzevdan : 2 Story 21 : Felhantering : Hans och Simon Story 22 : Minimitid för etapper : Hans och Tove : 4 Story 23 : Sorterad resultatlista : Hans och Simon Story 24 : Masstart på riktigt : Hans och Tove : 4 : Tog 3h Story 25 : Stöd för konfiguration : Dzevdan och Carl : 4 : Tog 3h Story 26 : Teknisk dokumentation : Dzevdan och Martin : 2 Story 27 : Server lösning Story 28 : Html-resultat Story 29 : Integrera HTML-lösning Story 30 : Integrera server-lösning Story 31 : Teknisk dokumentation : Dzevdan och Martin Story 32 : Källkods relese 2 Story 33 : Kodkvalite och stabilitet Story 34 : Web-anmälan : Martin/spike Team04 har valt ett liknande sätt att föra grafisk notering som informationsbas. Här har man samma färgrepresentation, men kan även se en estimering av stories och hur lång tid de verkligen tog att implementera. Den enda nackdel vi ser med den här varianten är att den inte hålls uppdaterad av utvecklarna, utan av coacherna. På detta sätt finns det risk att den enbart står som informationsrepresentation externt och att den inte hålls uppdaterad. 10

11 4.2 Visualisering via Tracker Vi får ett utmärkt visuellt redskap framför våra näsor varje vecka Trackern! Den kan kopieras ut på Overhead och användas i arbetet med teamet på planeringsmötet. Man kan använda Trackern på många olika sätt. Framför allt är den ett enkelt sätt att visa det som Gantt-diagram visar, om möjligt något enklare. En av coacherna använde färger och olika geometriska symboliseringar för att klargöra framgång för sitt team. Han drog streck för att visa hur långt gruppen är kommen i relation till antalet implementerade stories, han ringade in tidsestimeringar för att visa prioriterade moment och han numrerade även stories utefter kundens prioriteringsordning. Det viktiga när man använder Tracker är att man är konsekvent. Man kan, i samråd med utvecklare och kund, komma överens om ett noteringssätt, men det är viktigt att man använder sig av just detta under hela projektets gång. I den här typen av visualiseringar kan missförstånd lätt uppstå. 11

12 5. Alternativa Visualiseringar 5.1 Balanced Scorecard Balanced Scorecard är en metod som används inom många olika branscher och det kan även användas inom ett programmeringsprojekt. Grundtanken, enligt Balanced Scorecard [2], är att man formulerar en vision och en mängd olika perpektiv som rör projektet. Med perspektiv menar man exempelvis hur man ser projektet ur ett finansiellt perspektiv, ett perspektiv från kunden eller ett processperspektiv. Nu formulerar man Strategiska mål Om vi når visionen, hur kommer vi att vara då? De strategiska målen formuleras utifrån vart och ett av de olika perspektiven. Nästa steg är att formulera Framgångsfaktorer utifrån de olika perspektiven Vilka är de kritiska framgångsfaktorerna för att nå de strategiska målen? Efter detta identifierar man Nyckelmått utifrån perspektiven Vilka är de kritiska nyckelmåtten som indikerar vår strategiska inriktning? Slutligen identifierar man en Handlingsplan Vilken handlingsplan ska vi ha för att lyckas. Denna handlingsplan används som en brygga över alla perspektiv. VISION Finansiellt Kund Process Strategiska Mål Strategiska Mål Strategiska Mål Framgångsfaktorer Framgångsfaktorer Framgångsfaktorer Nyckelmått Nyckelmått Nyckelmått Handlingsplan 12

13 Det är svårt att tillämpa den här typen av diagram inom ett XP-projekt. Det måste vara en speciell typ av organisation som förespråkar att det här ska tillämpas, men eftersom det är ett vida känt sätt att arbeta utifrån känns det relevant att kommenteras. Det är troligen mer användbart på projekt av större kaliber. Möjligtvis kan man presentera ett balanced scorecard i förhållande till XP-metodik för ett team första planeringsmötet, men då gäller det att välja perspektiv rätt. Slutkommentar Att för teamet tillhandahålla information om utvecklingen man gör är extremt viktigt. Det är viktigt ur ett moraliskt perspektiv en effektiv arbetstakt ger utvecklarna god teamkänsla. Det är även viktigt ur ett informationellt perspektiv. Man behöver upplysa teamet om vilka stories som har gjorts, hur lång tid de tog och vilka stories som måste göras för att lyckas på bästa sätt inom den närmaste framtiden. Känner utvecklarna till de kritiska vägarna som utvecklingen måste följa lär de sig också att prioritera på ett effektivt sätt. Gantt-diagram är den bästa visualiseringsmetoden i de flesta sammanhang, enligt de studier vi har gjort inom området. Det ger en lättkonstruerad och lättöverskådlig bild av det nuvarande läget i utvecklingen och man får en repetition av tidigare implementerade stories. De flesta metoder inom uppföljning och redovisning av framgång kan jämföras med Gantt-diagram. UML-diagram kan även de vara bra för att få en överblick över systemet, men de kan även användas för att få igång diskussioner inom teamet och med kund. Vi hoppas att läsaren har fått mer kött på benen när det gäller användandet av visualiseringar inom ett XP-team. Olika typer av diagram är lösningen till många informationella problem vid coachning. Som coach kan det vara bra att komma ihåg att all information är bäst i diagramform. Det sprider inte bara information utan öppnar även en ny dimension av förståelse. Tack till Tack till deltagare i Coachingkursen EDA270 för delade erfarenheter o Speciellt tack till team02 och 04 för utdrag ur Visualisering via Webbsida Tack till team05 och team07 för feedback och kommentarer Referenser [1] R Jeffries, A Anderson, C Hendrickson: Extreme Programming Installed [2] N-G Olve, J Roy, M Wetter: Balanced Scorecard, 1997 [11] [12] [13] 13