Jag jobbar för tillfället som testledare i ett projekt som är en stor sponsor till Post-it lappen. Jag gillar generellt idén om att synliggöra processer för alla inblandade, ,en när det kommer till felhantering av buggar har det skapat ett litet problem för mig.
Projektgruppen jag arbetar i består av individer som förvisso är vana att jobba med ärendehanteringssystemet JIRA. Men då projektet anammat en hybrid mellan Scrum och Kanban hamnade användandet av JIRA i skymundan.
Det första jag märkte var att buggarna som rapporterades i JIRA inte fick den uppmärksamhet de förtjänade. Buggar rapporterades, utredes och tilldelades ansvariga utvecklare i JIRA, men sen hände inte mycket mer. ”Högen” med buggar bara växte och ingen kunde, eller ville se dem. Anledningen till detta visade sig vara att jag inte synliggjorde buggarna med Post-it lappar på projektets Scrum/Kanban tavlan. Det som inte syntes där fanns helt enkelt inte.
Åtgärden blev att manuellt kopiera buggarna i JIRA till fysiska Post-it lappar så alla kunde se dem. Resultatet lät inte vänta på sig. Direkt blev det full fart på buggrättningarna. Utvecklarna började även själva plocka upp buggarna i JIRA och arbeta med ärendet där efter att de sett dem på tavlan.
Men för min del skapade detta ett litet problem. Jag blev nu tvungen att manuellt underhålla två system. Två system som i grund och botten säger samma sak. När en bugg skapas eller uppdateras i JIRA måste det oftast ske samma sak på tavlan. Uppdateras buggen på tavlan måste den även uppdateras i JIRA.
Kalla mig gärna lat, men jag letar konstant efter sätt att förenkla mina egna arbetsmetoder. Tyvärr har jag inte hittat en vettig lösning på detta. Båda systemen verkar behövas och ingen av dem kan avvecklas utan konsekvenser för processens kvalité. Utan Post-it lappen ser inte projektledaren och utvecklarna vilken status systemet har, och dessutom uppstår problem kring planering av buggrättningar i iterationerna när buggar inte visualiseras. Utan JIRA förloras en mängd viktig information rörande bl.a. historik, detaljerade beskrivningar och kommentarer. Allt får helt enkelt inte platts på en liten papperslapp.
Förvisso skulle jag kunna fördela ansvaret och låta olika projektmedlemmar underhålla de båda systemen. Det vore en lätt väg att ta, och det skulle jag gärna göra om det inte vore för en sak. Jag är nämligen övertygad om att avvikelser mellan de båda verkligheterna (JIRA och tavlan) ökar om ansvaret fördelas. Med största sannolikhet ökar dessa avvikelser när ansvaret fördelas mellan olika roller. Eftersom ju fler avvikelser leder till desto sämre kvalité i felhanteringsprocessen är detta inget alternativ. Min slutsatts av detta är att ansvaret inte bör delas upp.
Så om ingen annan har en intressant idé att dela med sig av får jag snällt fortsätta underhålla min dubblerade lösning.
Kan relatera lite till detta fenomen…
Post-it är svårt att indexera och söka på men har givetvis visuella fördelar när mängden är “lagom”. Med risk för hädelse så har jag funderat på om det skulle gå att elekrifiera dessa lappar…drömvisionen är en stor, klickbar skärm som emulerar allt man kan göra på en Scrum-board med direkt koppling till godtyckliga ärendesystem…
Hej Björn,
Jag förstår verkligen att sitta och göra dubbelarbete är inget man vill ägna sig åt en längre tid. Det då bra att fråga sig om detta verkligen är värt mödan.
När jag läser din artikel tycker jag du beskriver en väl fungerande process och en haltande process.
Teamet har uppenbarligen anammat “Post-it – processen” och verkar föredra denna. Här blir saker gjorda!
Sen har du “Jira-Processen” som inte verka ses som en process som tillför någon nytta.
Du skriver att denna process är viktig för historik, beskrivningar etc.
Min fråga är, för vem är den viktig och tillför värde? Uppenbarligen inte för de närmast berörda parter då de inte använder den.
Varför är historik, beskrivningar etc viktigt att spara, hur ofta använder ni detta (eller har ni det bara för att man alltid sparat på detta så det känns tryggt)
Att ha kvar de två olika processerna som du beskriver ser jag som en ganska risig ide. Vi är inte ute efter att tillföra extra arbete som inte medför värde.
Mitt förslag behåll och finslipa er “Post-it process” skrota er “Jira-Process”. Om ni sen har loggfiler, skärmdumpar och annat som ni vill ha med i en felrapport så skaffa bara en server där ni enkelt läger upp dessa filer och på postit lappen skriver ni ett nummer på den mappen där infon finns.
För att detta ska fungera bra förutsätter det att ni har en kultur i teamet att agera på buggar omgående. Om ni fixar buggen direkt är det då värt extra arbetet med att spara undan all info om den för framtiden, eller kan man inte lika gärna bara slänga post-it lappen?
Jag skrev för längesedan lite om detta som jag tror tangerar din problematik
http://www.testzonen.se/?p=527
Som du själv nämner krävs det att buggar fixas direkt om det skall vara möjligt att skrota JIRA processen helt. Tyvärr jobbar inte mitt projekt riktigt så. Lägre prioriterade buggar kommer överlämnas till ett förvaltningsteam efter att produkten vi bygger släpps till produktion. Det rör sig i nuläget om ca 200st buggar. Om förvaltningsteamet skall har en chans göra ett effektivt jobb är det viktigt att de har bra informationsunderlag. Detta hade varit näst intill omöjligt att hantera enbart med hjälp av Post-it. Diskussioner, beslut, historik och annan detaljerad information måste således bokföras i ett elektroniskt ärendehanteringssystem.
Dessutom händer att buggar som en gång har varit av mer allvarlig karaktär nedgraderas och hamnar på ”förvaltningshögen” och viceversa. Detta kan bero på olika beslut som tas i utvecklingsprocessen. När dessa överlöpningar sker är det ganska skönt att buggen har en elektronisk version med viktig information kopplat till sig.
Jag är också inne på Henriks linje efter egen erfarenhet.
I de flesta projekt jag arbetar i använder vi ett ärendehanteringsystem och det fungerar lysande för de projektet. Men de finns vissa grupperingar för vilka det inte fungerar lika bra. Vad vi gjorde var att kapa bort systemstödet och köra post-it:s fullt ut.
Teamet som arbetade såhär var odentligt samkörda och kommunicerade bra utan att behöva bokföra allt.
Kravet blev lite större på projektledaren som fick se till att notera alla viktiga beslut och diskussioner som togs framför post-it-tavlan. Dessutom arkiverades samtliga post-it i en byrålåda om de skulle behövas i framtiden.
En av fördelarna var att teamet använde stand-up tiden på att mer effektivt sätt då allt fanns uppe på tavlan. Det gjorde att alla var mer uppdaterade i vad som var på gång och ingenting gömdes undan i en diskussion i en issue i något system.
Nackdelen var främst för mig som inte deltog 100% i projektet. Det var otroligt svårt att hålla sig uppdaterad och förstå vad varje post-it egentligen innebar. Men det hade nog kunna lösas det också om jag fått fortsatt förtroende i det teamet!
Björn, jag känner igen situationen.
Å ena sidan behöver man ofta ett verktyg som JIRA för att kunna hålla ordning på alla problemrapporter och buggar. Problemen ska beskrivas, få en prioritet och de ska tilldelas. Personligen vill jag också ha möjligheten att, för min och andras skull, kunna logga detaljer så som vilka tester som gjordes när, på vilka versioner testerna genomfördes, med vilken testdata osv. Ofta leder en problemrapport till olika beslut och då är det praktiskt att kunna logga dessa i rapporten.
Scrumtavla och Post-it lappar å andra sidan är ett väldigt visuellt och verkligt gränssnitt som jag gillar. Det blir tydligt att det finns aktiviteter som ska utföras och det är lätt att diskutera kring en tavla. Underskatta heller inte känslan av att fysiskt få flytta en lapp till Ready for test eller till Done.
Jag ser det inte så mycket som dubbelarbete heller egentligen. På Post-it lappen står ju inte hela problemet utan bara ett id och kanske en kort rubrik. Jag har heller inte varit med om att a l l a buggar hamnar på Post-it lappar utan bara de för stunden mest kritiska.
För mig är JIRA (eller motsvarande system) och Scrumtavla med Post-it lappar en perfekt combo för att kunna lagra och hantera information och samtidigt kunna arbeta med den på ett enkelt, överskådligt vis.
Likt dig hanterar inte heller jag alla buggar på Post-it. Enbart buggar som projektet prioriterar som ”allvarliga”. Beroende på vilken omsättning buggarna har (dvs, hur många nya buggar som rapporteras och hur många gamla som åtgärdas) tror jag att man kan uppleva det olika problematiskt att underhålla de båda systemen. Själv upplever jag en relativt hög omsättning och känner därför att det kan vara ganska jobbigt. För om jag tabbar mig kan det hända att buggar inte visualiseras,, och då finns de inte.
Hej,
En fråga: Varför kör ni inte med GreenHopper?
Det är ett plugin till Jira som visar alla ärenden på en scrumboard på skärmen. Sedan kan man köpa en stor skärm om man vill visa upp tavlan för alla som går förbi 🙂
Jag är den förste att hålla med om att det finns vinningar i att enbart underhålla ett system. Märker själv hur lätt det är att det uppstår skillnader mellan de båda systemen. Jag älskar idén kring GreenHopper och andra liknande verktyg. Den idén skall jag ta med mig till mitt nya uppdrag. Har tyvärr inte möjlighet att införa detta i mitt nuvarande projekt.
Hej.
Har jobbat mest mest IBM Clearcase/Clearquest. Ska nu efter nyår börja på ett jobb där jag ska bygga upp testorganisationen. Det innebär att man skriver processer om allt som har med testningen att göra, väljer verktyg osv.
Hur ser ni på valet av verktyg för tracking av felrapporter. Av det jag har läst här så verkar JIRA vara ett bra alternativ. Det JohanS nämnde om GreenHopper gör det ännu intressantare. Gillar visibilitet.
Jag gillar post-it lappar på en whiteboard men tror inte på kombon tracking verktyg/post-it lappar för att för det första finns en risk att saker hamnar mellan stolarna och för det andra att någon måste manuellt se till att dessa två är i synk.
Ser att många förespråkar kombination av dessa två men min logik fallerar att se fördelarna med dubbelarbete. Ha i åtanke dock att de projekt jag varit med om var geografiskt utspridda och fel som inte fanns i ärendehanterings systemet existerade inte.
Är det lättare i ett projekt där verksamheten, utveklarna och testarna jobbar under samma tak ?
MVH
/P
.
Projektets geografiska utspridning är som några av er nämnt en kritisk faktor till huruvida system med Post-it lappar skall fungera smärtfritt. Jag satt tidigare i ett projekt där vi testare satt i Göteborg och utvecklarna i Tyskland. Vattenfall var lag och buggar hanterades enbart via HP Quality Center. Så jag förstår vad du menar när du säger att en bugg inte finns om den inte syns i ett bugghanteringssystem.
Hej,
Jag har jobbat i projekt som sitter tillsammans hela projektet och det är såklart enklare att jobba med två system i ett sådant projekt jämfört med ett där man sitter på olika geografiska platser. Trots det så missar man ibland att uppdatera ett av systemen så att de inte alltid är synkade.
Tror man ska försöka hitta ett verktyg som uppfyller de krav man har och om det är en elektronisk scrumtavla så finns det fler alternativ än Jira+GreenHopper.
Tack för alla kommentarer och en bra diskussion. Det är roligt att läsa om era erfarenheter och åsikter kring hantering av buggar med hjälp av olika metoder och verktyg. Intressant att flera kan återkoppla till detta ”problem” (eller hur man nu väljer att se på det).
Jag har valt att ge repliker till respektive kommentar istället för att samla dem i denna kommentar.
God Jul till er alla!