Jag har använt SCRUM i tre olika projekt under de senaste fyra åren. En av SCRUMs fördelar verkar vara dess flexibilitet och anpassningsförmåga, t.ex. till följd av förändrade kundkrav. En annan fördel är att ledningen enkelt kan spåra projektets framsteg.
SCRUMs flexibilitet kan vara en fördel t.ex när du implementerar en webbapplikation där kraven ändras väldigt snabbt och kunderna verkligen förstår vad de vill ha efter att de har sett en prototyp.
Å andra sidan finns det andra typer av mjukvaruprojekt (t.ex. inom flyg- och rymdindustrin) branschen) där kraven är ganska fasta: du får ett kravspecifikationsdokument och du måste komma tillbaka sex månader senare med arbetsprogramvara och fullständig dokumentation. För den här typen av projekt tvivlar jag på att flexibiliteten som erbjuds av SCRUM behövs (i den meningen att du inte behöver bygga prototyper och visa dem för kunden för att få feedback om kraven): du behöver snarare ett mycket strukturerat och systematiskt tillvägagångssätt, vilket antagligen upprepas om och om igen för varje projekt med lite utrymme för överraskning. / p>
Så anses SCRUM av sina förespråkare vara en metod för utveckling av programvara för allmänt ändamål eller anses den särskilt lämplig för vissa kategorier av projekt eller applikationsområden?
För Jag tittade nyligen på webbplatsen för ett företag som producerar programvara för flygindustrin och märkte att de använder V-modellen. Skulle en SCRUM-förespråkare säga att SCRUM är mindre lämpad för denna typ av projekt eller snarare föreslå att detta företag ska försöka byta till SCRUM?
Obs att jag inte frågar efter läsarna från detta forum, men jag vill veta vad som är den etablerade uppfattningen bland SCRUM-förslag: anses SCRUM vara allmänt ändamål eller snarare lämpligt för vissa klasser endast av projekt? I de senare fallen, för vilka typer av projekt?
Kommentarer
- Se stackoverflow.com / frågor / 596916 / när-ska-du-inte-scrum och eweek.com/c/a/IT-Management/…
- Att ” får ett kravspecifikationsdokument och du måste komma tillbaka sex månader senare med fungerande programvara ” sak är en myt. Även när du bygger något som en kompilator för ett formellt definierat språk (där funktionskraven verkar vara riktigt tydliga och fasta) måste du bestämma och prioritera de saker som ska implementeras, det finns icke-funktionella krav som ska diskuteras med användaren , och du har flera frihetsgrader för att man måste bestämma hur man ska lösa saker. Så ett smidigt tillvägagångssätt är till och med meningsfullt för sådana typer av projekt.
- ” Så ett smidigt tillvägagångssätt är till och med meningsfullt för sådana slags projekt. ”: Även om smidig kan vara mer flexibel, är andra metoder också flexibla. Kan vara andra metoder är tillräckligt flexibla och smidiga är för flexibla för vissa projekt. Bara brainstorming här.
- ” Att ” får ett kravspecifikationsdokument och du måste komma tillbaka sex månader senare med fungerande programvara ” saken är en myt. ”: Jag tror inte ’ tänker det . Medan du snabbt kan ändra etiketten på en knapp på en webbsida eftersom kunderna har ändrat sig efter att ha tittat på den, kan du inte lika enkelt ändra en kritisk del av en flygprogramvara som styr en rörlig del av ett flygplan. Kanske kommer sena ändringar att behövas, men jag undrar om en smidig metod är rätt sätt att hantera dem, eller om du behöver en mer komplex iteration av en annan metod (t.ex. V-modellen).
Svar
SCRUM är en allmän metod som kan fungera bra för de flesta projekt och teamstorlekar, men är mindre användbar för stora team som gör mycket stora projekt. Det stora antalet personer som är involverade i vissa projekt gör alla smidiga metoder extremt svåra till nästan omöjliga eftersom det krävs en styvare struktur för att hålla ordning. Flygindustrin är ett bra exempel på en industri som tenderar att ha enorma projekt där agila tillvägagångssätt inte alltid är möjliga.
Kommentarer
- Finns det all information om när ett projekt anses vara för stort för att kunna göras med SCRUM? Tänk på t.ex. ett 18-månadersprojekt för ett team på 15 personer: skulle ett sådant team tjäna på SCRUM eller skulle en annan modell som V-modellen också passa Anledningen till att jag frågar är att kraven och implementeringen under 18 månader har tillräckligt med tid för att mogna och stabilisera, och kanske behövs inte den flexibilitet som SCRUM ger.Snarare är en mer mellan- till långsiktig strategi lämplig här. Finns det någon litteratur om detta?
- @Giorgio tid för projektet betyder inte ’, men 15 personer räcker för att du skulle ha nytta av att göra flera scrum grupper, men det är fortfarande inom det hanterbara intervallet för SCRUM. när kommunikationshantering börjar bli ett heltidsjobb för ditt team är det dags att börja titta på en V-modell
- Är du seriös? Vi använde en V-modell tidigare och bytte till SCRUM. Vi har faktiskt en känsla av att vi ’ har blivit långsammare av exakt denna anledning: för mycket bokföring.
- @Giorgio som skulle vara sant för alla växlar, du är kommer att känna sig långsammare först eftersom det är nytt, som Pierre 303 sa att du får en bättre uppfattning efter några sprints.
- @Giorgio – det ’ är sant, massor av ” smidig ” metoder är tyngre än de tunga processerna som de ’ antas att ersätta! Uppenbarligen betyder det att de ’ har fel – agile ska vara lätt och fritt och verkar kaotiskt för utomstående. Det betyder att ditt team måste vara väldigt organiserat och disciplinerat, men att ’ i allmänhet är en fördel. Prova istället Crystal från Alistair Cockburn (en av grundarna av Agile).
Svar
Alla typer av projekt ! Det fungerar bra för både stora och små projekt.
Folk har använt det för att planera bröllop, flytta hus osv. Så inte ens bara programvaruprojekt.
Jag är övertygad om att det finns många affärsverksamheter som kan dra nytta av ett Scrum-liknande tillvägagångssätt.
Kommentarer
- Är din åsikt delad av SCRUM-förslag, dvs. av författare som har kodifierat och marknadsfört SCRUM?
- Ja – det sa nyligen av Cheryl Hammond ( blog.bsktcase.com ), en ALM-konsult med Northwest Cadence på ett föredrag som hon gav med titeln ” A Scrum Masters Day In The Life: The New Visual Studio ”. Du kan titta på det här: msevents.microsoft.com/CUI/…
Svar
Observera att Scrum inte är en metod, utan en ram.
Scrum fungerar bäst i en c ross-funktionellt team från 5 till 9 utvecklare arbetar på en medelstor till stor projekt i storlek (från 4 månader till flera år). Om ditt projekt är större kan du skala med Scrum of Scrums .
Jag kommer inte att diskutera den tvärfunktionella saken här, men här är vad den officiella Scrum Guide berättar för lagets storlek:
Optimal utveckling Lagstorleken är tillräckligt liten för att förbli smidig och tillräckligt stor för att slutföra betydande arbete. Färre än tre medlemmar i utvecklingsteamet minskar interaktionen och resulterar i mindre produktivitetsvinster. Mindre utvecklingsteam kan stöta på kunskapsbegränsningar under sprinten, vilket gör att utvecklingsteamet inte kan leverera ett potentiellt frigörbart steg. Att ha mer än nio medlemmar kräver för mycket samordning. Stora utvecklingsteam genererar för mycket komplexitet för en empirisk process att hantera. Produktägaren och rollerna Scrum Master ingår inte i denna räkning om de inte också utför arbetet i Sprint Backlog
En sprint är ungefär en månad.
Sprints är begränsade till en kalendermånad. När en Sprints horisont är för lång kan definitionen av vad som byggs förändras, komplexiteten kan öka och risken kan öka. Sprints möjliggör förutsägbarhet genom att säkerställa inspektion och anpassning av framsteg mot ett mål minst varje kalendermånad. Sprints begränsar också risken till en kalendermånad med kostnad.
Jag tror att det inte är vettigt att använda ett ramverk baserat på en iterativ process med mindre projekt än 4 månader. 4 månader = 4 sprints. Du måste också tänka på att du får en mer exakt hastighet efter 3 sprints.
Som sagt Jag använder personligen en begränsad version av Scrum för mindre projekt, men du kan inte riktigt kalla det Scrum då. I det specifika fallet använder du några kärnprinciper i Scrum för att implementera ramverket.
Svar
till att börja med , tänk på SCRUM som bara en uppsättning riktlinjer för att implementera agila metoder. Tänk aldrig på det som en ”helig bok” om hur man gör projekt. För många projekt där det krävs ett stadigt flöde av uppgifter är Kanbam till exempel mer lämpligt.
Agila projekt tenderar att falla ner där du gör projekt som kräver ett fast slutdatum eller en fast kostnad. Medan du fortfarande kan göra dessa projekt med Agile-metoder, är behovet av att planera allt fram till avgöra om det är troligt att du träffar målet inte är det vanliga smidiga sättet – i agil tenderar du att fortsätta att arbeta tills du får slut på saker att göra, eller får tid att göra det. För de flesta projekt är det ok eftersom kraven ändras ändå under projektet.
Kommentarer
- Det sätt vi agerar i vårt team är att låta kunden prioritera berättelser (från det allra viktigaste), vi uppskattar användarberättelser med hjälp av pokerkort och planerar så många berättelser som vi kan implementera fram till deadline. Om vi visar oss vara snabbare schemalägger vi fler berättelser enligt vad som kommer nästa i prioritetslistan.
- Jag läste ditt svar igen efter några månader och det är faktiskt riktigt upplysande. +1