Now read this!
Jag har varit med i flera projekt och på ett antal företag där man propagerar Agila metoder i tid och evighet, Amen. Man har korta, dagliga, stand-up möten. Man intar en flexibel och realistisk inställning till krav och faktumet att vi inte kan veta alla parametrar innan projektets start eller ens innan iterationens start. Jag har jobbat med att skriva korta veckoplaneringar och enbart haft detta och skissartade funktions listor som test underlag. Till och med utformat testerna direkt utifrån vad kunden säger, timme för timme, och rapporterat tillbaka över telefon resultatet varefter de trillar in (just-in-time test).
Och det är allt fint. Det är flexibelt. Det är en del i den moderna testarens arsenal att tackla vardagen med. Som jag upplever det uppstår ofta problem i utkanten av detta arbetssätt.
Under projektets gång så kommer en eller flera projektledare vilja ha en rapport som på något sätt berättar hur det går. Helst gröna och fina siffror, kanske till och med nått litet stapeldiagram, som förklarar det hela så man slipper läsa så mycket.
Problemet är att ofta i ”stridens hetta” så finns inte tid för att dokumentera. Det är iaf den biten som ofta får stryka på foten. Alla testfallen får inte unika namn, spårbarheten blir i bästa fall ”ok” och återkopplingen till utvecklarna sker i form av felrapporter och muntliga rapporter.
I mitt fall tenderar det hela att sluta i en bunt gula lappar med klister och ett antal textfiler som innehåller lösa test scenarion och ännu mer summariska resultat. Saker som:
Fel build nummer i dvr:t
Load file ”all_known_types.sh” less then 50% should be 25% skriv CR….
Varför finns fyra sessioner? DB full, eller? Kolla med Nisse!!!!
Utfall på 45990 Kan vara req relaterat.
Ja ni vet saker som för dig kan vara självklara men som för någon annan ser ut som verket av en mentalt retarderad person. Jag blandar gärna Engelska och Svenska samt termer från alla typer av projektmodeller jag någonsin jobbat med. Men det viktiga är att jag förstår.
Lapparna ger mig det övertag jag behöver för att snabbt kunna svara min chef eller projektledare hur min verifiering fortskrider. Men de innehåller sällan tillräckligt med formalia och tydlighet för att kunna checkas in med resten av projektdokumentationen. Det tar ofta en dag att reda upp och sortera, formulera och presentera, för att få det hela presentabelt och nedtryckt i det nuvarande projektets mall.
Så detta är inget ovanligt vi har alla vart med om det. Vi har lärt oss av det och efter ett tag blir våra gula fusklappar mer avancerade för att kunna fungera för oss. Vi hittar ett språk som gör att vi kan återskapa mycket information från lite när det finns ”dötid” över.
För oavsett vad min projektledare/scrum-master/ systemägare säger så är det i slutändan viktigt med dokumenterade tester och resultat. För visst har även ni försökt att återskapat testfall och resultat efter att releasen har försvunnit ut genom dörren?
Det är då mina lappar verkligen blir värdefulla och en txt fil kan vara rena guldgruvan.
Så mina vänner, se alltid till att ha en packe gula lappar tillhands.
Hej Martin,
Det låter som om folk har missuppfattat vad Agilutvecklingsmetodik är. Varför skriver du din buggar på små gula post-it lappar? Lägg in dem i Jira eller liknade verktyg. Använd dock inte Jira som någon form av kommunikationskanal, då blir det lätt att man missar buggar.
I de agila projekt som jag har varit med har vi lagt in alla buggar i Jira och teamet har haft prioriteringsmöte ungefär 1 gång i veckan. Sedan när vi har haft sprintplanering har vi planerat in vilka buggar vi skall fixa i nästa sprint.. Buggar som tillhör en story, har vi fixat under sprintens gång. För agila manifestot säger att vi skall levererar fungerade programvara efter varje sprint.
Så släng dina gula post-it lappar och använd Jira eller likande verktyg.
Hej
Tack för din kommentar, det finns lite olika skäl till varför jag föredrar mina gula lappar och notepad filer.
Vad jag förstår så kostar Jira pengar och måste OK:as från högre ort innan vi kan fundera på att använda det i vår dagliga verksamhet. Man skulle säkert kunna hitta ett gratis alternativ om man behövde. På de ställen jag vart de senaste tre åren skulle det dock innebära att man skall ersätta ett redan befintligt system (ClearQuest).
Det är dock möjligt att jag skulle kunna installera det lokalt, men jag är lite osäker på hur mycket jag skulle vinna i tid och effektivitet på att först administrera eventuella buggar där för att sedan föra över dem till vårt normala system.
De gula-lapparna och notepad är mitt substitut för att hålla koll på de buggar jag hittar under en “test session”. Men även andra saker som dyker upp som kan vara Issues som inte är rena buggar, saker som dyker upp som jag behöver komma ihåg mer än ett par timmar. Det är även ett arbetssätt som fungerar för mig även om jag inte jobbar i scrum.
För vad man än tror så är det inte alla som lyckas trycka in sin utveckling i det “agila manifestot”, även om de försöker. Men det är väl kanske en annan diskution.