Za poslední čtyři roky používám SCRUM ve třech různých projektech. Jednou z výhod SCRUM se zdá být jeho flexibilita a přizpůsobivost, např. Při změně požadavků zákazníka. Další výhodou je, že management může snadno sledovat postup projektu.
Flexibilita SCRUM může být výhodou např při implementaci webové aplikace, kde se požadavky velmi rychle mění a zákazníci po pochopení prototypu skutečně pochopí, co chtějí.
Na druhou stranu existují i jiné druhy softwarových projektů (např. v leteckém průmyslu). průmysl), kde jsou požadavky docela pevné: dostanete dokument se specifikací požadavků a musíte se vrátit o šest měsíců později s fungujícím softwarem a kompletní dokumentací. U těchto druhů projektů pochybuji, že je nutná flexibilita nabízená SCRUM (v tom smyslu, že nepotřebujete stavět prototypy a předvádět je zákazníkovi, abyste získali zpětnou vazbu o požadavcích): potřebujete spíše velmi strukturovaný a systematický přístup, který se pravděpodobně u každého projektu opakuje znovu a znovu s malým prostorem pro překvapení.
Je SCRUM podle jeho navrhovatelů metodika vývoje softwaru pro všeobecné účely nebo je považována za zvláště vhodnou pro určité kategorie projektů nebo aplikačních oblastí?
Pro například jsem se nedávno podíval na web společnosti vyrábějící software pro letecký průmysl a všiml jsem si, že používají V-model. Řekl by navrhovatel SCRUM, že SCRUM je pro tento druh projektů méně vhodný, nebo spíše navrhl, aby se tato společnost pokusila přejít na SCRUM?
Poznámka že nežádám o názor čtenářů tohoto fóra, ale chci vědět, jaký je ustálený názor mezi navrhovateli SCRUM: je SCRUM považován za univerzální nebo spíše vhodný pro určité třídy pouze projektů? V posledních případech, pro jaké druhy projektů?
Komentáře
- Viz stackoverflow.com / questions / 596916 / when-should-you-not-scrum a eweek.com/c/a/IT-Management/…
- Tím “ získáte dokument se specifikací požadavků a budete se muset vrátit o šest měsíců později s fungujícím softwarem “ věc je mýtus. I když vytvoříte něco jako kompilátor pro formálně definovaný jazyk (kde se funkční požadavky zdají být opravdu jasné a pevné), musíte se rozhodnout a upřednostnit věci, které se mají implementovat, existují nefunkční požadavky, o kterých je třeba s uživatelem diskutovat , a máte několik stupňů volnosti, protože člověk se musí rozhodnout, jak věci vyřešit. Takže agilní přístup má pro takové druhy projektů dokonce smysl.
- “ Takže agilní přístup má pro takové druhy projektů dokonce smysl. „: I když agilní může být flexibilnější, flexibilní jsou i jiné metody. Mohou být i jiné metody dostatečně pružné a agilní pro některé projekty příliš flexibilní. Jen brainstorming zde.
- “ Získáte “ dokument se specifikací požadavků a budete se muset vrátit o šest měsíců později s fungujícím softwarem “ je mýtus. „: ‚ si to nemyslím . I když můžete rychle změnit označení tlačítka na webové stránce, protože zákazníci si to po prohlížení rozmysleli, nemůžete tak snadno změnit kritickou část avionického softwaru, který ovládá pohyblivou část letadla. Možná budou nutné pozdní změny, ale zajímalo by mě, zda je agilní metoda správným způsobem, jak je spravovat, nebo zda potřebujete složitější iteraci jiné metody (např. Modelu V).
Odpověď
SCRUM je obecná metodologie, která může dobře fungovat pro většinu projektů a velikostí týmů, ale je méně užitečná pro velké týmy, které dělají velmi velké projekty. Pouhý počet lidí zapojených do některých projektů činí každou agilní metodiku extrémně obtížnou až téměř nemožnou, protože k udržení pořádku je nutná přísnější struktura. Letecký a kosmický průmysl je dobrým příkladem odvětví, které má tendenci mít obrovské projekty, kde agilní přístupy nejsou vždy možné.
Komentáře
- Existuje jakékoli informace o tom, kdy je projekt považován za příliš velký na to, aby byl proveden se SCRUM? Zvažte např. 18měsíční projekt pro tým 15 lidí: prospěl by takový tým ze SCRUM nebo by se hodil i jiný model, jako je V-model Důvodem, proč se ptám, je to, že více než 18 měsíců mají požadavky a implementace dostatek času na zrání a stabilizaci a možná flexibilita poskytovaná SCRUM není opravdu nutná.Zde je vhodný spíše střednědobý až dlouhodobý přístup. Existuje o tom nějaká literatura?
- @Giorgio čas projektu nezáleží ‚ na tom opravdu záleží, ale 15 lidí je dost na to, aby vám prospělo vícenásobné skrumování skupiny, ale stále je ve zvládnutelném rozsahu pro SCRUM. když se správa komunikace začne pro váš tým stávat prací na plný úvazek, je čas začít hledat model V
- to myslíte vážně? Předtím jsme používali V-model a přešli jsme na SCRUM. Ve skutečnosti máme pocit, že jsme ‚ zpomalili přesně z tohoto důvodu: příliš mnoho účetnictví.
- @Giorgio, což by platilo pro každý přepínač, jste zpočátku se budete cítit pomaleji, protože jeho nový, jako Pierre 303, řekl, že po několika sprintech získáte lepší nápad.
- @Giorgio – to je ‚ pravda, spousta “ agilních “ metod je těžších než těžké procesy, které ‚ předpokládají nahradit! Je zřejmé, že to znamená, že se ‚ mýlí – agilní by měl být lehký a svobodný a pro cizince působit chaoticky. Znamená to, že váš tým musí být velmi organizovaný a disciplinovaný, ale ‚ to je obecně výhoda. Zkuste místo toho Crystal od Alistaira Cockburna (jednoho ze zakladatelů společnosti Agile).
Odpovědět
Jakýkoli typ projektu ! Funguje dobře pro velké i malé projekty.
Lidé to využili k plánování svateb, stěhování atd. Takže nejen softwarové projekty.
Jsem pevně přesvědčen, že existuje mnoho obchodních operací, které by mohly těžit z přístupu podobného Scrumu.
Komentáře
- Je sdílen váš vlastní názor navrhovatelé SCRUM, tj. autoři, kteří kodifikovali a propagovali SCRUM?
- Ano – nedávno to řekla Cheryl Hammond ( blog.bsktcase.com ), konzultantka ALM se společností Northwest Cadence na přednášce s názvem “ A Scrum Masters Day In The Life: The New Visual Studio „. Můžete si je prohlédnout zde: msevents.microsoft.com/CUI/…
Odpověď
Upozorňujeme, že Scrum není metodika, ale rámec.
Scrum bude fungovat nejlépe v c ross-functional tým od 5 až 9 vývojářů pracujících na střední až velký projekt velikosti (od 4 měsíců do více let). Pokud je váš projekt větší, můžete jej škálovat pomocí Scrum of Scrums .
Nebudu zde hovořit o různých funkcích, ale zde to, co oficiální průvodce Scrum Guide říká o velikosti týmu:
Optimální rozvoj Velikost týmu je dostatečně malá na to, aby zůstala hbitá, a dostatečně velká na to, aby dokončila významnou práci. Méně než tři členové vývojového týmu snižují interakci a mají za následek menší zvýšení produktivity. Menší vývojové týmy mohou během sprintu narazit na omezení dovedností, což způsobí, že vývojový tým nebude schopen dodat potenciálně uvolnitelný přírůstek. Mít více než devět členů vyžaduje příliš mnoho koordinace. Velké vývojové týmy vytvářejí příliš velkou složitost na to, aby je bylo možné zvládnout empirickým procesem. Role vlastníka produktu a Scrum Master nejsou do tohoto počtu zahrnuty, pokud také neprovádějí práci Sprint Backlog
Sprint je přibližně jeden měsíc.
Sprinty jsou omezeny na jeden kalendářní měsíc. Je-li Sprintův horizont příliš dlouhý, definice toho, co se staví, se může změnit, může vzrůst složitost a riziko. Sprinty umožňují předvídatelnost zajištěním kontroly a přizpůsobení pokroku směrem k cíli alespoň každý kalendářní měsíc. Sprinty také omezují riziko na jeden kalendářní měsíc nákladů.
Myslím, že nemá smysl používat rámec založený na iteračním procesu s menšími projekty než 4 měsíce. 4 měsíce = 4 sprinty. Musíte také vzít v úvahu, že po 3 sprintech získáte přesnější rychlost .
To znamená , Já osobně používám omezenou verzi Scrumu pro menší projekty. Ale pak se to opravdu nedá nazvat Scrum. V tomto konkrétním případě používáte některé základní principy Scrumu při vlastní implementaci rámce.
Odpověď
pro začátečníky , uvažujte o SCRUM jako o jedné sadě pokynů pro implementaci agilních postupů. Nikdy o tom nepřemýšlejte jako o „svaté knize“ o tom, jak dělat projekty. Pro mnoho projektů, kde je vyžadován stálý tok úkolů, je vhodnější například Kanbam.
Agilní projekty mají tendenci klesat tam, kde děláte projekty, které vyžadují pevné datum ukončení nebo pevné náklady. I když tyto projekty stále můžete provádět pomocí agilních metod, je třeba vše předem naplánovat zjistit, zda „pravděpodobně zasáhnete cíl, není obvyklý agilní způsob – v agilních máte tendenci pokračovat v práci, dokud vám nedojdou věci na práci, nebo vám nedojde čas. Pro většinu projektů je to v pořádku protože se během projektu požadavky stejně mění.
Komentáře
- Způsob, jakým v našem týmu agilně pracujeme, je nechat zákazníka nastavit prioritu příběhů (od většiny po nejméně důležité) odhadujeme příběhy uživatelů pomocí pokerových karet a plánujeme tolik příběhů, kolik dokážeme implementovat, až do konce. Pokud se ukáže, že jsme rychlejší, naplánujeme více příběhů podle toho, co bude následovat v seznamu priorit.
- Přečetl jsem si vaši odpověď znovu po několika měsících a je ve skutečnosti skutečně poučný. +1