Jag letar efter erfarenheter från personer som använt SCRUM. Jag har nämligen bristfällig rutin inom området och dåliga erfarenheter. Så jag undrar nu om du som lyckats med SCRUM som testare kan tänka dig att dela med dig av dina erfarenheter i kommentarsfältet.
Det finns några kriterier dock.
- Genomfört mer än en Sprint, helst utan att ha scope-cuttat mer än 5% av dina arbetspaket
- Mer än fem parallella sprintar i samma releaseprojekt (intresserad av hur ni löste eventuella beroenden)
- Inte ett ”web-projekt”. Jag är mer intresserad av ”produktutveckling” än ”Web-tjänster”
Mina erfarenheter är att man ”kör efter SCRUM… eller iaf vissa delar av SCRUM”. Anledningen är att när det börjar bli komplexa projektberoenden och det är mer än mjukvaru som gör sig gällande så faller flera av tankarna med SCRUM.
Jag skulle också vilja höra erfarenheter från när
- En utvecklare tog rollen som verifierare och vise versa
- Ett team var större än de rekommenderade 5- 9 personer
- När den ”sista” sprinten i releaseprojektet inte räckte till.
Som ni förstår är jag nyfiken på när ni har lyckats och vilka era nyckel faktorer var.
Jag personligen älskar SCRUM och hatar det på samma gång. Jag gillar verkligen Daily SCRUM och den breda delaktighet som alla medlemmar i projektet får. Däremot får jag utslag av den smått frireligiösa stämning som råder så fort någon skall ”Sälja” in SCRUM, och det är alltid nått litet Web-Project som ges som exempel (iaf när jag har lyssnat). För min erfarenhet är att man inte alltid ska, kan eller borde använda SCRUM.
Så kör så det ryker, ser fram emot mycket intressant läsning.
Jag förstår dig när du skriver att du älskar och samtidig hatar Scrum. Låt mig säga att det inte är Scrums fel – det börja blir fel när själva förståelsen för agila metoder brister. Som tanken bakom agil utveckling visar så handlar det om bättre produkter, smidigare samarbete och engagerade människor. Finns de bastankar inte på plats och det enbart handlar om att ”sälja in” en hype eller snabba pengar – brukar det går sned.
Jag har haft tur och varit med i flera år i några Scrum projekt – med alla smärtor och glädje när man kommer fram med en fungerande del. Projekten kördes distribuerade med upp till 35 parallella team involverade. Precis som jag nämnde tidigare – problem uppstod så snart det agila tankesätt trycktes åt sidan. En manager som bara snabb ville släppa en liten funktion till en kund, ett team som pressades för att hinna med en orimlig tidsplan eller en person som hade en dålig dag och tänkte att denna enhetstest är för nybörjare. Det tog oss ungefär 3 år tills vi hade hittat ett hyfsat fungerande system att jobba efter. Bara genom oändliga diskussioner och förklaringar var detta möjligt.
Min erfarenhet är att nästan alla involverade personer vill jobba efter agila principer – även om man kan använda många agila element i vilken utvecklingsprocess som helst. Det är väldig viktigt att alltid kolla på om det finns förutsättningar för teamen att jobba agilt. Ibland brukar det hjälpa att fråga personen som kommer med krav som står i motsats till agila principer om personen är villig att ta ”ansvaret” för konsekvenserna. I alla fall får man personen att tänka över för- och nackdelar av kravet.
Som svar på dina frågor:
1. Ja, det är möjligt att utvecklare hjälper till med test. Allt beror på om vi som team har samma mål (en fungerande produkt). Försök att undvika att utvecklarna testa sin egen kod. Ett tips till – ger utvecklarna en introduktion i test och testtänk.
2. Japp, en gång jobbade jag med ett team med 19 personer. Detta beslut togs eftersom releasen bara skulle gå n sprint till och det skulle kosta mer att splittra teamet. Lärdomen är dock att den goda kommunikationen inom teamet drabbas och att Scrum Mastern kan vara tvungen att gå in i rollen som projektledare igen för att koordinera arbetet. Slutsatsen här – försök att undvika det eller håller det verkligen kort i tid (1 sprint).
3. Frågan förstår jag inte riktigt. För mig är det så att omfattningen (scope) är flexibel i agil utvecklingen. Är omfattningen och tid fast (förbestämt) är det de facto inte agilt längre. Men, om vi antar en sådan situation är diskussionen med teamet det viktigaste. Tillsammans kan ni komma på kompromissar (sämre, men fungerande lösning eller hårdkodning av vissa delar med fix i första uppdateringen) som kan presenteras för beställaren.
Precis som du skriver – det behövs inte Scrum för alla projekt. Man kan använda continuous integration även med andra utvecklingsprocesser. Bra kommunikation genom åtminstone dagliga möten kan användas i RUP projekt också. Beslutet för en agil process besvaras för mig genom att fråga ”hur mycket flexibilitet behöver vi i projektet (hur osäker är vi)?”.
/Ronald
Många som utvecklar system med Scrum står inför liknande situationer. Det är inte så konstigt att problematiken upprepar sig m.t.p att Scrum inte ger mycket till ledning i hur man utvecklar system.
Snarare är det så att Scrum kan ge en vilseledande enkel bild av vad som krävs för att utveckla IT-system.
Frågan är, vill man börja med en simpel idé och behöva uppfinna hjulet (ex Scrum), eller vill man ha en tjock lärobok och börja skala ner (ex UP).
F.ö. så finns inte roller som “utvecklare”, “testare” eller “verifierare” i Scrum.