"Så, jag vill berätta om Agile och Scrum ."
"I början av 2000-talet vändes sättet som folk tänkte kring programmering upp och ner."
"Alla var övertygade om att långsiktig planering inte fungerade, så de bestämde sig för att överge det helt."
"Hur gjorde de det?"
"Här är hur."
"De uppfann den mest flexibla projektledningsmetoden som möjligt."
Här är huvudidéerna bakom agil utveckling :"
- människor och kommunikation är viktigare än processer och verktyg;
- en fungerande produkt är viktigare än uttömmande dokumentation;
- att samarbeta med kunden är viktigare än att uppfylla villkoren i ett kontrakt;
- förändringsvilja är viktigare än att hålla sig till den ursprungliga planen.
Här är principerna för snabb utveckling:
- tillfredsställa kunden genom att tillhandahålla värdefull programvara tidigt och kontinuerligt;
- välkomna förändringar i kraven även i slutet av utvecklingen (detta kan öka slutproduktens konkurrenskraft);
- leverera fungerande programvara ofta (varje månad eller vecka eller oftare);
- nära daglig kommunikation mellan kund och utvecklare genom hela projektet;
- projektet bearbetas av motiverade individer som ges nödvändiga arbetsförhållanden, stöd och förtroende;
- den föredragna metoden för att kommunicera information är ett personligt (ansikte mot ansikte) samtal;
- fungerande mjukvara är det bästa måttet på framsteg;
- sponsorer, utvecklare och användare bör kunna hålla en konstant takt under en obestämd period;
- konstant fokus på att förbättra teknisk excellens och användarvänlig design;
- enkelhet är konsten att inte göra överflödigt arbete;
- de bästa tekniska kraven, designen och arkitekturen kommer från ett självorganiserat team;
- ständig anpassning till förändrade omständigheter.
"Det största problemet med mjukvaruutveckling var att ingen av deltagarna i något skede hade fullständig information om vad de skulle göra."
"Kunden kan berätta hur han tänker sig programmet, men han kommer att utelämna något eller ta något för givet."
"Chefen måste i allmänhet översätta krav från programmeringsjargong till kundens språk och tillbaka igen."
"Det är för mycket osäkerhet."
"Ofta är kundens krav så här: gör det på något sätt, visa mig sedan - om jag inte gillar det kan du göra om det."
"Äh... det är hemskt."
"Enligt det nya paradigmet utvecklar inte programmerare längre en produkt eller ett program. Istället implementerar de den funktionalitet som kunden behöver."
"Vad är skillnaden?"
"Tja, anta att programutvecklingen brukade ta ett år. Och det måste gå sex månader innan det fanns något att titta på. Det är som att bygga ett stort hus: först gräver du en grop för grunden, häller sedan grunden, bygga väggar, tak, trimma, etc."
"Men nu försöker programmerare att släppa den nödvändiga funktionaliteten så snart som möjligt. Det här skulle vara som att först bygga en koja, sedan en husbil, sedan ett litet hus och först sedan ett stort hus - i omgångar."
"Med tanke på att kunden sannolikt inte riktigt vet vad han vill ha, så är detta ett mycket rimligt tillvägagångssätt."
"Anta att kunden vill ha en stor jaktstuga."
"Utvecklarna bygger en liten till honom. Han bor i den en vinter. Sedan bestämmer han sig för att han inte gillar trähus. Låt oss göra ett av tegel."
"Han bor nära sjön en sommar, men myggorna äter honom levande. Han hade hört någonstans att sjöar är svala, och så han ville ha en. Men nu vill han inte ha en sjö. Och det blir lättare att bygga huset så här: ingen sjö betyder inget hot om översvämningar, och du kan bygga huset på marken istället för på pålar, vilket kommer att vara 25% snabbare."
"En intressant analogi. Ändrar kunderna verkligen sina krav så ofta?"
"Ja, men problemet är inte kunden."
"För det första är det väldigt svårt att föreställa sig hur saker och ting kommer att bli i framtiden. Chefer, testare och programmerare gör alla detta också. De ändrar sig också beroende på hur saker och ting blir."
"För det andra, är det inte kundens krav som är viktigast? När allt kommer omkring är poängen med allt detta arbete att skapa det kunden behöver, inte vad han från början sa att han skulle skapa . "
"Det brukade faktiskt fungera så här: affärsanalytiker skulle göra en lista över alla krav. De skulle inkludera den här listan i ett kontrakt, underteckna den och arbeta bara enligt listan."
"Om listan saknade något som kunden verkligen behövde men hade glömt, skulle ingen göra något åt det."
"Jag förstår. Det är lättare att följa en plan, men allt kan inte göras enligt en plan!"
"Exakt."
"Det var därför agila utvecklingsmetoder uppfanns."
"Och idag ska jag berätta om Scrum - den mest populära bland dem.
"Den primära egenskapen hos Scrum är uppdelningen av projektutveckling i små iterationer - vanligtvis 2-4 veckor långa. Varje iteration kallas en sprint."
"I början av en sprint hålls ett sprintplaneringsmöte. Det varar i 3-4 timmar."
"I slutet finns det en demonstration av alla de fullt genomförda uppgifterna."
"Så här fungerar allt vanligtvis:"
"Innan den allra första spurten bildar kunden (eller en representant för kunden) en kravlista, det vill säga den uppsättning saker som programmet ska kunna göra. Dessa krav brukar kallas för user stories , och kunden är oftast kallas produktägaren ."
"Han kallas produktägaren , eftersom produkten är skriven för honom. Han, och han ensam, definierar listan med krav - vad, när och i vilken ordning."
"Dessutom tilldelar produktägaren vanligtvis uppgiftsprioriteringar. Uppgifter med högst prioritet kommer att implementeras först. Hela kravlistan kallas även produktbacklog . "
"När en sprint börjar samlas alla till ett möte. Scrummastern , vanligtvis en medlem av teamet, leder vanligtvis mötet. Mötet har som mål att välja uppgifterna ( user story ) för den aktuella sprinten (iteration av utveckling). "
"Först tilldelar teamet varje uppgift en grov uppskattning i abstrakta man-days, även känd som story points. Sedan bestämmer teamet hur många uppgifter de ska hinna slutföra under sprinten."
"Återigen är det laget själva som bestämmer hur många uppgifter de ska hinna slutföra under sprinten."
"Låt oss säga att produktägaren förväntade sig att teamet skulle välja de första 7 uppgifterna men det valde bara 5, sedan skjuts uppgifter 6 och 7 upp till nästa sprint. Om det inte passar produktägaren kan han höja prioriteringen av uppgifterna 6 och 7 för att säkerställa att de blir utvalda, men då kommer några av de andra uppgifterna att falla ur sprinten."
"Scrummastern kan också föreslå att dela upp några av uppgifterna i mindre och sätta olika prioriteringar för dem för att göra produktägaren så nöjd som möjligt."
"Det är poängen med mötet: uppgifter kan ändras och delas upp, prioriteringar kan ändras etc. Det här är arbetet som inte var synligt från början, men som tillför mycket värde."
"Förstår det. Det är som att köra bil. Även om du till en början tror att du bara behöver gå rakt ut, är verkligheten att du hela tiden måste undvika potthål, styra höger och vänster och passera andra eller låta dem passera dig."
"Ja, något sådant."
"Listan över uppgifter som valts ut för sprinten kallas sprintbacklog ."
"Programmerarna bestämmer vem som ska göra vad och först då börjar de jobba. "För att förbättra effektiviteten föreslår Scrum att det hålls ett 5-15 minuters möte varje dag där alla kan berätta för varandra vad de gjorde igår och vad de är ska göra idag."
"Lagarbete. Det kan jag respektera!"
"För att göra saker lättare att visualisera, rekommenderas det vanligtvis att visa aktuell sprintstatus på en speciell tavla:"
"Observera de tre kolumnerna till vänster."
"Förkortade uppgiftsnamn skrivs på klisterlappar. Och klisterlapparna placeras i olika kolumner beroende på deras status (planerad, pågående, klar)."
"Till höger kan du se ett burndown-diagram . För varje dag listar detta diagram de uppgifter som fortfarande är ogjort. Idealt sett sjunker antalet ofullständiga uppgifter till noll under sprinten."
"När sprinten är över ger scrum-mastern en demo för att visa listan över allt som är helt klart."
"Sedan håller han ett sprint retrospektivt möte , som också varar ett par timmar. Under det här mötet brukar deltagarna försöka lista ut vad som gick bra och vad (och hur) saker kunde ha gjorts bättre."
"Vanligtvis efter 2-3 sprints kan du identifiera och eliminera huvudproblemen som hindrar teamet från att arbeta mer effektivt. Detta leder till högre produktivitet utan att öka lagets arbetsbelastning. Detta var inte möjligt före eran av agila metoder. "
"Ibland hålls även ett groomingmöte under sprinten. Syftet är att planera nästa sprint. Deltagarna brukar tydliggöra uppgiftens prioriteringar i detta möte. De kan också dela upp vissa uppgifter i delar och/eller lägga till nya uppgifter till produktbackloggen . "
"Tja, det är i princip allt jag har. Det här är bara en översikt. Det är omöjligt att förklara det hela med bara några få ord, men du kan läsa en bra artikel om ämnet här:"
GO TO FULL VERSION