Začať. Scrum a Agile – aký je rozdiel? Stručne povedané, Agile je filozofia, rodina flexibilných prístupov k vývoju softvéru. Scrum je jedným z takýchto prístupov. Má brata - Kanbana. Je to tiež prístup používaný v Agile.

Elena Trušková hovorí:

Tento týždeň som absolvoval dvojdňový tréning Agile/Scrum (vyslovuje sa „agile“ a „scrum“). O flexibilných metodológiách vývoja softvéru sa napísalo veľa nejasnej a nie až takej literatúry, veľa som čítal. Ale až po dvoch dňoch ponorenia sa do témy som konečne základne pochopil tému, z ktorej píšem túto poznámku.

Agile a Scrum pomáhajú organizovať proces tímovej práce tak, aby pravidelne a často vydávali produkt, ktorý je pre používateľa zaujímavý.

V niektorých bankách sa vďaka agile skrátila cesta nápadu k používateľom z dvoch rokov na šesť mesiacov – v iných firmách sa šesťmesačný vývojový cyklus stlačil na tri. V tejto hektickej dobe je to skutočná konkurenčná výhoda, najmä pre menších hráčov.

Princípy scrumu sa dajú aplikovať úplne na všetko: napríklad na prácu na kreatívnom produkte. Toto, samozrejme, nie je „kanonická agilita“, evanjelisti Scrumu budú škrípať zubami, ale vaše procesy budú napredovať veselšie. Dáma alebo ísť?

Niektoré z Agile a Scrumu možno dokonca vziať do individuálnej práce. Zabezpečte pravidelné zverejňovanie príspevkov, merajte záťaž interpreta, zhodnoťte budúce úlohy z časového hľadiska a nezabudnite analyzovať kvalitu odvedenej práce - pozri, všetko už máme premyslené. Zostáva realizovať.

Agilný

(anglicky agile - "agilný, inteligentný, pohotový")

Koncept flexibility:

Nahraďte svoj typ činnosti namiesto slova „rozvoj“ – a tieto princípy sa stanú blízkymi a zrozumiteľnými.

„Fungujúci produkt je hlavným ukazovateľom pokroku“, „jednoduchosť ako umenie minimalizovať zbytočnú prácu“ a „ľudia a interakcia sú dôležitejšie ako procesy a nástroje“ – znie to rozumne?

Scrum

(angl. scrum - tlačenica v boji o loptu v rugby)

Tu je vhodné pripomenúť, že toto je môj osobný a subjektívny pohľad na Scrum. Tu sa zamýšľam nad použiteľnosťou prvkov Scrumu ako v kreatívnych projektoch ďaleko od IT, tak aj v samostatnej práci (povedzme na blogu). Mnoho presných detailov na to bude musieť byť vynechaných; Snažím sa, aby bol text jednoduchý a nepresýtil čitateľa terminológiou.

Tuhosť Scrumu spočíva v štruktúre. Existuje určitý súbor prístupov, ktoré fungujú lepšie spoločne ako oddelene. Vytiahnite niečo a použite to pre vás, dúfam, že nikto nezakazuje.

Scrum väčšinou nastáva tam, kde existuje určitý produkt, ktorý má hodnotu pre používateľov a zákazníkov a vy potrebujete na ceste k cieľu čo najrýchlejšie pochopiť, či ideme správnym smerom, alebo či potrebujeme korigovať kurz. Formát Scrum vám umožňuje vydávať ďalšiu verziu častejšie, dostávať pravidelnú spätnú väzbu a rýchlo vylepšovať produkt, ako aj zlepšovať pracovný proces.

Ak pracujete v tíme, Scrum vyžaduje, aby sa všetci účastníci procesu snažili o zameniteľnosť, schopnosť „vyzdvihnúť“ klesajúcu úlohu, ak je sused chorý, výmenu zručností a kolektívnu zodpovednosť za produkt. V Scrume je málo individualizmu. Rozhodnutia sa robia kolektívne (podľa prísnych zásad), nikto ich nemôže tlačiť a nútiť, aby zvolili iné riešenie, ak si tím je istý, že sa usadil na správnom.

Mať takú dôveru v Scrum nie je desivé, keďže každý pochod trvá presne jeden šprint (jasné časové obdobie, zvyčajne jeden až štyri týždne). Po skončení šprintu prichádza chvíľa analýzy: ako sme sa cez to dostali? Čo by sa dalo nabudúce urobiť ešte lepšie?

Preto, aj keď sme sa všetci sebavedomo rozbehli nesprávnym smerom, na konci šprintu budeme mať možnosť to napraviť a napraviť to, čo nás vedie nesprávnym smerom. Tím v Scrume sa sám organizuje a ladí.

Tím v Scrume

Štandardná veľkosť Scrum tímu je 7 plus mínus 2 ľudia. To je päť až deväť. Existuje scrum škálovanie: z 25 tímov si môžete vybudovať systém práce na obrovskej úlohe. Ale základnou jednotkou Scrumu je tím.

Každý tím má:

• účastníci (v prípade IT – vývojárov, koho máte týchto sedem ľudí – rozhodnite sa sami)
• vlastník produktu (vlastník produktu, vlastník produktu). Jeho úloha: porozumieť trhu a užívateľovi, formulovať úlohy v jazyku biznisu a užívateľov, mať na pamäti povedomie, akým smerom sa má vyvíjať hodnota a úžitok, vymýšľať a vyberať úlohy pre vývoj produktu. Niečo ako produktový (nie tímový) líder.
• scrum master (scrum master, scrum evanjelist). Jeho úloha: sledovať proces, pozorovať vnútorný život tímu, motivovať ľudí, odstraňovať prekážky. Niečo ako tréner.
  Okolo tímu sú užívatelia a stake-choleri (stakeholderi, zákazníci). Produktový vlastník si k týmto ľuďom chodí po radu.

Sprint zariadenia

Scrum práca pozostáva zo šprintov. Všetky šprinty sú nastavené rovnakým spôsobom. Predpokladá sa, že s každým ďalším šprintom sa tím stáva kooperatívnejším a efektívnejším. V Scrume sa učíte zo svojich chýb, ale rýchlo – každý šprint analyzujete, čo presne ste urobili a ako to chcete napraviť.

Vlastník produktu má zoznam podnikateľských nápadov, aby boli používatelia spokojní. Nazýva sa to „produktový backlog“ (zoznam nápadov na produkty). V nej sú nápady zoradené podľa dôležitosti a významu.

Každý sprint má backlog sprintu (backlog sprintu, zoznam úloh pre sprint) – zoradený zoznam nápadov, ktoré sa tím rozhodol urobiť v nasledujúcom sprinte. Zmyslom Scrumu je, že tím sám vyhodnotí zložitosť každej úlohy a rozhodne, ktoré úlohy budú zahrnuté do ďalšieho sprintu.

Úloha v šprinte má tímom známu váhu (vie sa, ako dlho to bude trvať), je k nej pripojený interpret, je zrozumiteľná a dôležitá. Ak neviete, ako dlho bude úloha trvať, musíte ju rozdeliť na menšie časti.

Na začiatku života si tím vždy zle naplánuje. Toto je objektívna realita. Ale vedie si štatistiku toho, čo stihne v šprinte, a časom plánuje presnejšie. Pomáha jej záverečný míting šprintu – retrospektíva. Tam môžete diskutovať o slabých stránkach odchádzajúceho sprintu a vymýšľať spôsoby, ako to urobiť inak.

Zvyčajne sa do šprintu zmestí 5 plus mínus 2 nápadov. Ak sú nápady príliš veľké, tím ich rozdelí tak, aby v každom šprinte bolo čo ukázať.

V Scrume sa nápady nazývajú užívateľské príbehy (príbehy užívateľov, príbehy o užívateľoch) a sú formulované takto: „Mám rád (rolu?) chcem (čo?), aby som (prečo?)“. Tým teda vidí nielen funkčnosť, ale aj zmysel jej tvorby a to pre konkrétnu rolu: užívateľ, zákazník, nákupca.

Výsledok šprintu je vždy čo ukázať. Zobrazuje prácu tímu na deme na konci sprintu.

Podľa môjho názoru je proces Scrum podobný práci na tímovom blogu. Takýto proces by pomohol zachovať pravidelnosť, spojiť odbornosť autorov a nenajímať toľko, aby ste to nedokázali.

Štruktúra šprintu

Šprint sa začína plánovaním: tím si sadne a diskutuje: berieme tento nápad, neberieme ten. V IT sa tento proces môže natiahnuť na niekoľko hodín, pretože diskusia ide až do detailov. V prípade práce s blogom sa to môže zmeniť na diskusiu o témach a pláne článkov, ku ktorým si potom musíte sadnúť a napísať - pochopiť, čo píšeme, kedy a prečo.

Každý deň je stand-up meeting (stand up meeting, standing meeting) na 15 minút. Je dôležité robiť to v stoji: ak niekto rozpráva, zvyšok výrečne prestúpi z nohy na nohu a poškriabe sa za uchom. Môžete použiť nejaký predmet tak, aby hovoril vždy len jeden účastník, a rozdávať ho v kruhu.

Každý stand-up účastník striedavo odpovedá na tri otázky:

• čo som robil včera
• čo budem dnes robiť
• čo ma spomaľuje

Všetky podrobné rozhovory, ktoré sú v procese spojené, presahujú hranice stand-upu. Stand-up je bod, v ktorom môžete zachytiť problémy alebo zistiť, že z nejakého dôvodu robíme s kolegom to isté v rovnakom čase, čo znamená, že jeden z nás môže robiť niečo iné.

Vo všeobecnosti by sa o dodržiavanie všetkých týchto jasných pravidiel správania mal starať Scrum Master. Väčšinou ide o ideológov techniky, ktorí jej veria a sú pripravení vybudovať proces pre maximálnu efektivitu spoločne stráveného času. Bez Scrum Mastera sa procesy zvrhnú na minimum možné, pretože človek je lenivý a ekonomický.

Na konci sprintu je demo (demo, demonštrácia) ukazujúce, čo sa nám počas sprintu podarilo vytvoriť, recenzia sprintu (recenzia sprintu, recenzia sprintu) s revíziou produktového backlogu a rozprávanie o tom, ČO robíme, ako aj retrospektíva (retro ) - čo sa nám celý šprint nepodarilo najlepšie a chceme sa ďalej zlepšovať - ​​o AKO to robíme.

"Keby som mal osem hodín na zoťanie stromu, strávil by som šesť hodín ostrením sekery." (Pripísané drevorubačovi a prezidentovi Abrahamovi Lincolnovi)

Scrum je autorská flexibilná vývojová metodika s neštandardným rozdelením rolí v tíme a unikátnou organizáciou iterácií. Scrum, podobne ako iné agilné metódy projektového manažmentu, podporuje tímový prístup, krátke iterácie a neustále zlepšovanie procesu. Tieto princípy sú implementované prostredníctvom súboru špecifických rolí, pravidiel, procesov a nástrojov, ktoré pomáhajú tímom vyrábať produkty za polovičný čas.

V Scrum tímoch sú kľúčové pozície obsadené
scrum master a vlastník produktu,
iterácia sa spustí plánovanie,
na ktorých členovia tímu "hrajú"
v poker plánovanie,
a končí demo sretrospektíva.

Metodológiu Scrumu vytvorili Američania Jeff Sutherland, výskumník a obchodný konzultant, a Ken Schwaber, praktický programátor, v roku 1993. V roku 1995 autori konceptu oficiálne predstavili jeho prístupy na vedeckej konferencii Association for Computing Machinery v Austine v Texase.

Myšlienka spoluautorov scrumu nebola nová: koncept a dokonca aj názov, ktorý prevzali z práce japonských výskumníkov v oblasti manažmentu, publikovanej v roku 1986. Už vtedy japonskí výrobcovia používali prístupy, ktoré tvorili základ Scrumu. A názov metodiky je vypožičaný zo slovnej zásoby hráčov rugby. Scrum, alebo scrum, je prvok hry, ktorý ukazuje dôležitosť tímovej práce pre víťazstvo na ihrisku.

Scrum v IT aj mimo neho

Scrum bol prvýkrát použitý v softvérových spoločnostiach. Prvým projektom, na ktorý J. Sutherland dohliadal ešte pred oficiálnym predstavením Scrumu, bolo vytvorenie softvéru pre sieť bankomatov (1983). Programátorské tímy v IT spoločnostiach a divíziách sú stále hlavnými konzumentmi scrumu. Autor metodiky však trvá na tom, že Scrum je použiteľný na riešenie akýchkoľvek problémov a uvádza príklady využitia Scrumu vo výrobe, stavebníctve, školstve, politike a dokonca aj pri riešení každodenných úloh ako generálne upratovanie alebo organizovanie dovolenky.

Podľa Scrum Alliance za rok 2016 skutočne 21 % projektov dokončených v rámci Scrumu nesúviselo s oblasťou IT. Pozrite sa, ktoré oddelenia úspešne používajú scrum:

Scrum vs. Agile vs. Waterfall

Scrum patrí do skupiny flexibilných metodík, alebo agilných metodík. Agile nie je samostatná metodika, ale celá filozofia vývoja softvéru, jej hlavné prístupy boli zaznamenané v roku 2001. V manifeste sú uvedené základné princípy agile – dôležitosť tímu, zameranie sa na produkt, nie na dokumentáciu, transparentnosť procesov, neustále zlepšovanie, rýchle výsledky.

Scrum je jedným z agilných rámcov, formalizovanú metodiku práce na projektoch. Agilné metodiky okrem scrumu zahŕňajú ďalšie moderné prístupy. Alternatívou k scrumu môže byť Scrumban a iné. To znamená, že Scrum je agilný, ale agilný nie je len Scrum.

Predstavte si, že agilné je kresťanstvo a scrum je jedným z jeho prúdov, napríklad protestantizmus. A hoci kresťania vo všeobecnosti a zvlášť protestanti vyznávajú rovnaké zásady, protestanti majú svoje vlastné jedinečné rituály na prejavovanie viery.

V súlade s tým, vizuálne rozdiely a podobnosti medziScrum aAgile môže byť reprezentovaná takto:

* Artefakty v scrume sú to objekty, ktoré vytvára tím pri práci na projekte. Patria sem produktový backlog, backlog sprintu a produktový prírastok, teda pracovný kus funkčnosti, ktorý tím demonštruje na konci sprintu.

Postupy agilného vývoja odolávajú kaskádový model (kaskáda, vodopád, vodopád), ktorý v 90. rokoch používali takmer všetky vývojárske tímy.

Podstatou vodopádového modelu je postupná realizácia projektu a práca na každej nasledujúcej fáze sa začína až po skončení predchádzajúcej. Schematicky vyzerá kaskádový model takto:

Kaskádový metodický prístup však nefungoval – tímy nedodržali termíny a vypadli z rozpočtu. Vodopádová metóda nezohľadňovala vznikajúce problémy, oneskorenia a poruchy, meniace sa požiadavky zákazníkov a prostredia. Bolo potrebné hľadať alternatívu a zmeniť postup práce – pravidelne sa obzerať späť, analyzovať vykonanú prácu a okamžite odstraňovať prekážky a robiť zmeny. Preto sa objavili flexibilné agilné metodiky a jeho deriváty.

Ako pracovať so Scrumom

Úlohy v Scrume

Scrum tím

Scrum je založený na tíme alebo skupine - dobre koordinovanom tele profesionálov. Scrum tímy sú autonómne, členovia sami rozhodujú o splnení úlohy. Sú multifunkčné – na vyriešenie problému stačia znalosti a zručnosti členov tímu.

Scrum vyžaduje malý tím: 7±2 ľudí. Pri väčšom počte ľudí míňajú členovia tímu príliš veľa zdrojov na komunikáciu. V polovici 90. rokov Lawrence Putnam analyzoval 491 vývojových tímov: všetky vytvárali nový produkt a mali rôzne veľkosti. Štúdia ukázala, že veľké tímy (9-20 ľudí) potrebujú 4-krát viac času a úsilia na vyriešenie problému ako malé skupiny (3-7 ľudí).

Scrum Master

Scrum Master je formálnym vedúcim tímu Scrum, asistentom, ktorý dohliada na správnu aplikáciu metodiky a udržiava tímovú morálku. Je zodpovedný za to, ako robiť prácu.

Produktový vlastník, produktový vlastník

Produktový vlastník je osoba, ktorá je zodpovedná za funkčnosť finálneho produktu. Zostavuje zoznam používateľských príbehov (projektový backlog) a udržiava ho počas celého projektu. Jeho oblasťou zodpovednosti je čo robiť v rámci projektu a komunikácia so zákazníkom.

Zákazník

Zákazník alebo klient je ten, pre koho sa projekt robí. Zákazníkom môže byť tretia strana alebo organizácia alebo zasvätená osoba. Napríklad obchodné oddelenie, ktoré nariadilo vývojárom vyvinúť CRM systém.

Pravidelné stretnutia a pracovné sekcie scrumu

Plánovanie

Prvé stretnutie, ktorým sa začína šprint. Na ňom tím s pomocou Scrum Mastera a Product Ownera vyberie z hornej časti backlogu úlohy, ktoré stihne splniť.

Vybrané úlohy sú zadané do projektu sprintu s termínom a interpretom.

Denné stretnutia na cestách

Všetci členovia tímu sa stretávajú každý deň v rovnakom čase, aby zhodnotili pokrok a vymenili si informácie.

Na tento účel odpovedia na tri otázky:

1. čo som včera urobil, aby som pomohol tímu dosiahnuť svoj cieľ?
2. čo dnes urobím, aby tím dosiahol svoj cieľ?
3. čo mi bránilo robiť svoju prácu?

Stretnutia netrvajú dlhšie ako 15 minút a konajú sa v stoji.

Pre toto stretnutie si každý môže zobraziť svoju správu za vybraný deň.

Demo alebo Sprint Review

Vykonáva sa, keď je práca v šprinte dokončená. Toto je ukážka pre zákazníka a všetky zainteresované strany funkcionality, ktorú tím vytvoril počas sprintu. V tejto fáze zákazník vyjadruje svoj názor, robí úpravy, požaduje dodatočnú funkcionalitu atď.

Používajú sa reporty za zodpovedajúce časové obdobie, „klientsky prístup“ k projektom (vidno pokrok, nevidno internú kuchyňu), komentáre a emócie.

retrospektíva

Ide o stretnutie, na ktorom tím diskutuje o úlohách dokončených počas sprintu, stupni ich dokončenia a problémoch, ktoré je potrebné vyriešiť. Pomer plánovaných a dokončených úloh určuje efektivitu tímu. Spätne hľadajte spôsoby, ako sa zlepšiť.

Používajú sa prehľady za zodpovedajúce časové obdobie podľa ľudí, oddelení, účtov a podrobných.

Algoritmus. Čo robiť?

1. Vyberte si vlastníka produktu ktorý jasne definuje, čo je potrebné urobiť.

2. Vytvorte Scrum tím.

3. Vymenujte Scrum Mastera.

4. Vytvorte backlog projektu vo forme zoznamu užívateľských príbehov. Zahrňte do nej všetky úlohy, ktoré by tím mohol pre projekt urobiť a uprednostnite ich. Predložte úlohy, ktoré obsahujú hlavnú funkcionalitu projektu a ktoré prinesú príjem zákazníkovi.

Nevybavená položka je úplný zoznam prác, ktoré treba dokončiť.
Používateľské príbehy, Používateľské príbehy sú požiadavky na funkčnosť produktu vyjadrené v mene koncového používateľa. Napríklad ja ako kupujúci internetového obchodu chcem na stránke vyhľadať požadovaný produkt (platiť za nákupy kartou, ukladať tovar do košíka atď.).

5. Odhadnite úlohy z nevybavených úloh pomocou relatívnych hodnôt, ako sú veľkosti tričiek alebo čísla z Fibonacciho sekvencie: 0, 1, 1, 2, 3, 5, 8, 13 atď. Odhadnite úlohy s celým tímom pomocou plánovacieho pokru: použite balíček kariet alebo aplikáciu pre smartfón.

Plánovací poker je špeciálny balíček kariet s Fibonacciho číslami. Každý člen tímu dostane svoj vlastný set. Keď Scrum Master oznámi úlohu, členovia tímu súčasne položia na stôl karty s číslami, o ktorých si myslia, že zodpovedajú náročnosti úlohy. Ak sa karty účastníkov líšia o jednu alebo dve jednotky, napríklad 3 a 8, potom sa úlohe priradí zložitosť rovnajúca sa aritmetickému priemeru týchto čísel. Ak je rozdiel väčší, potom účastníci, ktorí vyhodili najmenšiu a najväčšiu kartu, vysvetlia svoje rozhodnutia. Potom všetci členovia tímu opäť vyložia karty. A tak ďalej, kým sa všetci nedohodnú.

6. Vykonajte plánovanie šprintu: Vyberte úlohy a rozdeľte ich medzi účinkujúcich.

7. Získajte Scrum Board, rozdeľte to na tri časti: to be done, in progress, done. Presuňte nálepky s úlohami, aby ste videli dynamiku práce. Použite skutočnú alebo virtuálnu tabuľu.

8. Nezabúdajte na svoje každodenné stretnutia.

9. Predvedenie na konci šprintu.

10. Dajte sa dokopy na retrospektíve, diskutovať o tom, ako zlepšiť prácu, aké prekážky odstrániť. Môže to byť nefunkčný kávovar, pomalý počítač, nepríjemná teplota vzduchu, povaha kolegu, bezohľadný dodávateľ. Keď tím začne pracovať na Scrume, problémy, ktoré boli mesiace odkladané, sú vyriešené.

11. Začnite svoj ďalší sprint plánovaním(bod 6).

Sprievodca scrumom. Definitívny sprievodca scrumom: Pravidlá hry / Ken Schwaber, Jeff Sutherland

Pokyny pre Scrum: Popisuje roly, aktivity, artefakty scrumu a ako ich používať. zostavili a udržiavajú spoluautori metodiky Scrum.

Scrum. Revolučná metóda projektového manažmentu / Jeff Sutherland

Produktový manažment v Scrume. Agilné metódy pre váš biznis / Roman Pikhler

Významná časť je venovaná majiteľovi produktu: jeho funkciám, vlastnostiam, chybám. Autor podrobne skúma proces tvorby produktu podľa metodiky Scrum, počnúc premyslením konceptu budúceho produktu a končiac tvorbou reportov.

Scrum a XP: Poznámky z prvej línie / Henrik Kniberg

O praktickej aplikácii moderných agilných prístupov – Scrum a Extreme Programming – v konkrétnom tíme. Množstvo príkladov, nástrojov, Scrum metód v akcii bez vody a teórie.

Manifest agilného vývoja softvéru

Pozostáva z niekoľkých línií, ktoré sú založené na flexibilných metodológiách.

Výhody a nevýhody Scrumu v IT

Scrum je skvelá metodika: vysoko efektívna, transparentná, motivujúca. Ide o obojstranne výhodný prístup, ktorý je prínosom pre tím aj pre zákazníka.

1. Transparentnosť.V tíme prebieha otvorená výmena informácií, poznatkov, problémov, každý sa cíti byť zapojený do spoločného cieľa. Zákazník má vždy prehľad o postupe prác, robí zmeny v procese, dostáva spoľahlivé informácie o termínoch.
2. Autonómia tímu. H Členovia tímu rozhodujú o spôsobe práce na projekte, motivujú slobodu konania a zodpovednosť. Zákazník komunikuje požiadavky tímu priamo, bez poškodeného telefónu.
3. Motivácia výsledkom.Koncept scrumu umožňuje každému členovi skupiny vidieť svoje vlastné a spoločné úspechy na dennej báze. Zákazník získava zvýšenie funkčnosti s každou iteráciou.
4. Minimalizácia trhových rizík.Tím rýchlo reaguje na meniace sa požiadavky projektu a nerobí prácu navyše. Zákazník dostane to, čo chce a po čom je na trhu dopyt.
5. Minimalizácia finančných rizík.Málo času a peňazí sa vynakladá na odstraňovanie chýb a pridávanie funkcionality, všetko sa investuje do rozpočtu.

Scrum je však formalizovaná metodika a pri niektorých projektoch nie je také ľahké ju aplikovať.

Tu sú zjavné nevýhody Scrumu:

• nie je vhodný pre projekty s nejasnými požiadavkami na konečný produkt, pretože zákazník môže zvýšiť funkčnosť do nekonečna;
• je ťažké naučiť sa správne určovať priority a hodnotiť úlohy;
• úspech projektu príliš závisí od Scrum Mastera;
• Scrum sa ťažko používa vo veľkých projektoch, musíte škálovať metodológiu a zaviesť scrum scrum stretnutí. Týchto mítingov sa zúčastňujú zástupcovia niekoľkých Scrum tímov pracujúcich na súvisiacich produktoch.

V našom projekte si hneď vyskúšali nacvičiť dvojúrovňový scrum: globálny a na úrovni oddelení (obchod, marketing, financie atď.). Najprv vedúci oddelení definovali úlohy v globálnom plánovaní, potom zostúpili na úroveň oddelení. Urobili sme zle – konečný výsledok bol príliš rozmazaný.

• vysokovýkonné tímy sa uvoľnia a prestanú sa zlepšovať. Indikátorom prítomnosti problému je zníženie dynamiky výkonu šprintov. Scrum Master musí tímu oznámiť závažnosť problému. Ak sa tím nedostane zo slepej uličky sám, zasiahne vedenie: prijímajú sa noví zamestnanci, rotuje sa personál.

Scrum spoločnosti

Podľa správy Scrumalliance 70 % IT spoločností používa Scrum. Medzi nimi sú takí giganti ako Google, Amazon, Salesforce.com, Microsoft, Adobe.

Salesforce.com

American, popredný vývojár CRM systémov pre podnikanie. Jej produkty používa 150 000 spoločností. Dlhé roky využíva agilné metodologické prístupy pod vedením Scrumu a na jeho základe vytvára unikátny hybrid niekoľkých agilných rámcov.

Agilné postupy používa od roku 1999 a v roku 2004 už používalo Scrum niekoľko vývojových tímov. Do roku 2009 bola väčšina vývojárov účelovo prevedená do Scrumu.

Spotify

Digitálna hudobná služba, ktorá úspešne konkuruje gigantom Google, Apple a Amazon. Spotify za svoju konkurenčnú výhodu považuje maximálne využitie možností Scrumu. Vedenie spoločnosti najíma najlepších Scrum Coachov, aby pôsobili ako Scrum Masters. Prácu vykonávajú malé autonómne tímy, ktoré sa považujú za začínajúce podniky.

Scrum používa od roku 2008, 4 tisíc vývojárov v stovkách tímov 10-12 ľudí pracuje podľa metodiky Scrum, pričom každé tri týždne vydajú nový produkt. Korporácia úspešne škálovala Scrum, aby zodpovedal jej veľkosti.

To, že Scrum sa využíva nielen v IT oblasti, dokazuje projekt – iniciatíva učiteľa chémie na škole v holandskom meste Alphen aan den Rijn. S podporou podnikateľskej komunity v Holandsku bola vytvorená nadácia eduScrum, ktorá školí učiteľov na používanie Scrumu v triede. Študenti, ktorí pracujú v Scrum tímoch, sa učia lepšie a s väčšou radosťou ako ich rovesníci.

Projekt Sentinel pre FBI

Zavedenie metodiky Scrum zachránilo pred krachom mnohomiliónový projekt americkej vlády – jednotná databáza „Guardian“ pre FBI. The Guardian bol druhým pokusom vyvinúť jednotný informačný systém pre FBI. Prvá zlyhala bez toho, aby mala čo i len deň práce.

„Guardian“ sa začal vytvárať v roku 2005 podľa kaskádového modelu. Projektu boli vyčlenené 4 roky a 450 miliónov dolárov. Začiatkom piateho roka dodávateľská firma zrealizovala polovicu prác a minula 95 % rozpočtu. Dokončenie projektu by podľa odborníkov trvalo ďalších 350 miliónov a 6-8 rokov.

Keď scrum tímová práca nahradila vodopádový model začiatkom roku 2010, produktivita vývojárov sa strojnásobila a 2. júla 2012 Guardian používala FBI vo všetkých štátoch.

Aplikácie

Práca na projektoch Scrumu sa vykonáva v špeciálnych aplikáciách a programoch. Multifunkčné rozhranie umožňuje sledovať priebeh projektu z rôznych uhlov pohľadu.

Jednoduché a intuitívne pre prácu na projektoch a riešenie rôznych obchodných problémov.

Pracovná sekcia teraz dokončuje a testuje funkcie pre scrum pred implementáciou (k októbru 2017): grafy a backlog úloh sú čisto nástroje scrumu. Tiež môže byťplánovanie pokru.Náš konzultant v tejto veci,

V poslednej dobe sa ma často pýtali, čo je Scrum od ľudí, ktorí majú k IT veľmi vzdialený vzťah. V tejto súvislosti som sa rozhodol jednoducho vysvetliť, čo Scrum znamená. Takže páni, Scrum-followers, nesúďte ma tvrdo.

Scrum (Scrum) nie je skratka, tento výraz je prevzatý z rugby, čo znamená boj okolo lopty.

Samotný pojem Scrum by som definoval nasledovne, je metodika projektového manažmentu, ktorá je postavená na princípoch time managementu. Jeho hlavnou črtou je zapojenie všetkých účastníkov do procesu a každý účastník má svoju špecifickú úlohu. Základom je, že na riešení problému nepracuje len tím, ale všetci, ktorí majú záujem problém vyriešiť, si ho len nenastavili a oddýchli si, ale neustále s tímom „pracovali“, pričom táto práca neznamená len neustála kontrola.

Hlavné pojmy používané v metodológii sú:

Vlastník produktu - človek, ktorý má priamy záujem o kvalitný konečný produkt, rozumie tomu, ako má tento produkt vyzerať / fungovať. Táto osoba nepracuje v tíme, pracuje na strane zákazníka/klienta (môže to byť buď iná firma alebo iné oddelenie), ale táto osoba pracuje s tímom. A to je človek, ktorý uprednostňuje úlohy.

Scrum Master - je to osoba, ktorú možno nazvať projektovým manažérom, aj keď to nie je úplne pravda. Hlavná vec je, že ide o človeka „nakazeného bacilom Scrumu“ natoľko, že ho prenáša do svojho tímu aj k zákazníkovi, a preto dbá na dodržiavanie všetkých princípov Scrumu.

Scrum tím je tím, ktorý akceptuje všetky princípy Scrumu a je pripravený s nimi pracovať.

šprint - časový úsek, ktorý je potrebný na dokončenie konkrétneho (obmedzeného) zoznamu úloh. Odporúča sa trvať 2-4 týždne (dobu trvania určí tím raz).

Nevybavené veci (backlog) je zoznam všetkých úloh. Dá sa povedať, že ide o diár na všeobecné použitie 🙂

Existujú 2 typy backlogov: Product Backlog a Sprint Backlog.

Produktový backlog — toto je kompletný zoznam všetkých prác, pri realizácii ktorých získame finálny produkt.

Nevybavené sprinty je zoznam prác, ktoré tím identifikoval a odsúhlasil s vlastníkom produktu na nasledujúce reportovacie obdobie (sprint). Úlohy v backlogu sprintu sú prevzaté z produktového backlogu.

Plánovanie šprintu je stretnutie, na ktorom sa zúčastňujú všetci (tím, Scrum Master, Product Owner). Počas tohto stretnutia produktový vlastník uprednostňuje úlohy, ktoré by chcel vidieť dokončené na konci sprintu. Tím v priebehu času vyhodnotí, koľko zo želaného môžu dosiahnuť. Výsledkom je zoznam úloh, ktoré sa počas sprintu nemôžu meniť a musia byť úplne dokončené do konca sprintu.

To všetko sa pokúsim vysvetliť na príklade práce PR agentúry, ako by to mohlo vyzerať, keby fungovali podľa Scrumu.

Klientska spoločnosť „X“ chce už o 2 mesiace usporiadať pre svojich partnerov a novinárov veľké podujatie. Spoločnosť "X" si objednala služby na usporiadanie takéhoto podujatia u agentúry "Z". Spoločnosť „X“ zastupuje PR-manažér, ktorý je zodpovedný za organizáciu akcie v mene klienta. V terminológii Scrumu sa táto osoba nazýva Vlastník produktu. Zo strany agentúry je za organizáciu akcie zodpovedný account manažér ( Scrum Master), ktorý je podriadený príkazu ( Scrum tím). Na spoločnom stretnutí plánovanie sprintu) spoločnosť a agentúra sa rozhodnú, že budú podávať správy a plánovať každé 2 týždne ( dĺžka šprintu). Na prvé 2 týždne si naplánovali zoznam úloh ( backlog sprintu), tím však odhadol, že nebudú môcť dokončiť celý tento zoznam. Potom PR manažér (aka Vlastník produktu), hovorí, ktoré z tohto zoznamu úloh sú prioritnejšie počas nasledujúcich 2 týždňov, po ktorých tím prevezme úlohy. Tu treba brať do úvahy len to, že v čase plánovania prvého sprintu by mal byť naplánovaný celý zoznam úloh na 2 mesiace ( nevybavených produktov), aby sa nestalo, že v čase konania akcie sa niečo nedokončí.

Na záver chcem povedať, že pojmov je v skutočnosti oveľa viac a celá metodika je oveľa hlbšia. Dúfam, že všetko uvedené bude stačiť na sčítanie prvej myšlienky 🙂

Scrum v jednoduchom jazyku

"Zo všetkých ťažkostí, ktorým NASA čelila pri vyslaní človeka na Mesiac, bola kontrola pravdepodobne tou najťažšou úlohou."

— Roger Launis, historik NASA

Počas histórie ľudstvo nahromadilo pôsobivý zoznam úspešne realizovaných zložitých projektov. Od stavby pyramíd v Gíze až po vyslanie človeka na Mesiac si najodvážnejšie ľudské aktivity vyžadovali koordinovanú prácu tisícov ľudí. A to znamená komplexný systém riadenia projektov.

A hoci len málokto z nás bude čeliť úlohám takéhoto rozsahu, väčšina čitateľov tohto blogu zažije projektové riadenie tak či onak. Odhaduje sa, že do roku 2020 tam budú PMI – a mnoho ďalších odborníkov musí často riadiť miniprojekty, aspoň na osobnej úrovni.

Zjednodušene povedané, projektový manažment je o riadení a organizovaní všetkého potrebného na dosiahnutie cieľa – samozrejme včas a v rámci rozpočtu. Či už ide o vývoj nového softvéru, vedenie marketingovej kampane alebo pristátie človeka na Marse, projektový manažment umožňuje uspieť.

Všetky projekty sú iné. Neexistuje dokonalý systém riadenia projektov pre každý typ projektu. Taktiež neexistuje systém, ktorý by vyhovoval každému lídrovi a bol pohodlný pre všetkých členov tímu. Počas existencie projektového manažmentu sa však vytvorilo mnoho efektívnych prístupov, metód a štandardov, ktoré je možné prijať. Dnes budeme hovoriť o najobľúbenejších z nich.

Vyvinuté prístupy sa navzájom veľmi líšia. Líšia sa rozsahom, detailnosťou, sebestačnosťou a formalizáciou. V názve sme ich pre pohodlie nazvali „metódy“, ale v skutočnosti článok predstavuje štandardy, koncepty, metódy a rámce, ktoré sa používajú pri riadení projektov. Účelom tohto článku je poskytnúť čo najširší prehľad existujúcich prístupov v projektovom riadení.

V tomto článku sa pozrieme na:

• Klasický projektový manažment
• Agilný
• Scrum
• Lean
• Kanban
• ŠesťSigma
• PRINCE2

A predtým, než sa pozrieme na konkrétne metódy, odpovedzme na zrejmú otázku - "Prečo vôbec potrebujeme systémy a metódy projektového riadenia?"- zamyslime sa samozrejme v krátkosti nad históriou projektového riadenia a definujme základné pojmy projektového riadenia.

Prečo "projektový manažment"?

Mená Neila Armstronga a Buzza Aldrina sa navždy zapíšu do histórie ako symboly jedného z najväčších úspechov ľudstva – pristátia človeka na Mesiaci. Hlavnými prispievateľmi k tejto udalosti však bolo 400 000 zamestnancov NASA a 20 000 spoločností a univerzít, ktoré spolupracovali na misii Apollo.

V roku 1961 si John F. Kennedy dal za úlohu pristáť človeka na satelite Zeme a vrátiť ho späť – napriek tomu, že vtedy NASA poslala človeka do vesmíru len na 15 minút. Takýto ambiciózny cieľ si vyžadoval neskutočné množstvo zdrojov, spolupráce, inovácií a plánovania.

Ako sa uvádza v knihe NASA Managing the Moon Program, hlavným problémom nebolo „ čo robiť?" a v tom, " ako stihnúť toľko za taký krátky čas? Tvrdí to Dr. Max Faget, vedúci inžinierstva vo vesmírnom stredisku Lyndona Johnsona (The Lyndon B. Johnson Space Center, JSC), potom NASA netušila, ako urobiť všetky potrebné akcie za 10 rokov. Prvým krokom teda bolo „rozdelenie projektu na zvládnuteľné kroky“.

Potom bolo dôležité urýchliť realizáciu každej jednotlivej fázy a uistiť sa, že tímy a spoločnosti pracujúce v každej fáze spolu efektívne komunikujú a prinášajú výsledky včas. Touto úlohou bol poverený doktor George E. Muller, ktorý riadil každú časť projektu Apollo, od Bieleho domu až po dodávateľa najmenšej časti. Aby bolo ovládanie projektu jednoduchšie, rozhodol sa rozdeliť projekt do 5 oblastí: Programové riadenie, Systémové inžinierstvo, Testovanie, Spoľahlivosť a kvalita a Letová prevádzka. Schéma ovládania programu Apollo je znázornená v postava 1.

Tento 5-stupňový systém – nazývaný „GEM Stages“ podľa iniciálok Dr. Mullera – bol navrhnutý tak, aby sa „zameral na testovanie produktu a jeho vývoj s vedomím, že bude testovaný,“ hovorí sám Muller. Program Control určil, čo je potrebné urobiť, spravoval rozpočet a požiadavky a riadil vzťah prvkov programu. Systémové inžinierstvo bolo zodpovedné za vývoj nových zariadení a zostáv, testovanie bolo zodpovedné za zabezpečenie toho, aby tieto nové prvky fungovali, spoľahlivosť a kvalita kontrolovala vyvinuté prvky z hľadiska zhody s požiadavkami a normami a letová prevádzka bola zodpovedná za zabezpečenie toho, že tieto uzly budú fungovať. počas letu.

Mnohí boli spočiatku voči Mullerovej metóde skeptickí, no napokon sa mu podarilo presvedčiť členov programu o potrebe nasledovať tento algoritmus. Tento systém ukázal svoju efektívnosť – projekt bol dokončený úspešne, ba možno povedať, že triumfálne, pred stanovenými termínmi. To bolo možné len rozdelením rozsiahleho projektu na zvládnuteľné, opakovateľné kroky, čo umožnilo mnohým individuálnym spoločnostiam a profesionálom pracovať rovnakým tempom. Takto dokázal projektový manažment svoju efektívnosť vo vesmírnych pretekoch.

Stručná história projektového manažmentu

Projektový manažment nevymyslela NASA a doktor Muller. Egyptské pyramídy a Veľký čínsky múr sú produkty projektového manažmentu z praveku. Žiaľ, neexistujú žiadne listinné dôkazy o tom, ako prebiehala realizácia a riadenie týchto projektov a súčasný projektový manažment je odtrhnutý od poznatkov minulých storočí.

Najzrejmejším spôsobom realizácie projektu je jeho rozdelenie na fázy alebo jednotlivé úlohy. Ako recept si nakúpite ingrediencie, poriadne ich premiešate, uvaríte a naservírujete. Najjednoduchším nástrojom riadenia projektu je kontrolný zoznam činností, ktoré je potrebné vykonať na dosiahnutie cieľa. Jednoduché a efektívne.

Ak ste však šéfkuchár a pripravujete viacero jedál, ale viacero, napríklad šalát (ktorý pozostáva z 3 etáp) a dezert (ktorý stačí podávať), budete potrebovať nástroj, ktorý umožňuje sledovať čas strávený na každej z nich a kedy by mali byť pripravené. A tu prichádza na pomoc jeden z prvých moderných nástrojov projektového manažmentu: Ganttov diagram, prezentovaný na Obrázok 2.

Nezávisle vynájdený K o V úlohe Korola Adameckiho a Henryho L. Gantta na začiatku 20. storočia Ganttov diagram zobrazuje harmonogram projektu na základe termínov a termínov splnenia úloh. Zadávajú sa do nej úlohy, ich trvanie a vzťahy a následne sa vypočítava kritická cesta – najdlhší reťazec vzájomne prepojených úloh, ktoré určujú trvanie projektu. Vzťahy medzi začiatkom a koncom rôznych úloh sú veľmi dôležité – polievku nemôžete podávať hosťom, kým ju neuvaríte, však?

Typický projekt je teda veľmi podobný projektu varenia a podávania večere, len má oveľa viac úloh, vzťahov, termínov a typov zdrojov. Pri projektoch s krátkymi termínmi pomáha Ganttov diagram rozhodnúť, kedy je lepšie začať s určitými úlohami, aby sa skrátil čas implementácie. A pre projekty so silnými obmedzeniami zdrojov poskytuje Ganttov diagram príležitosť vybudovať schému vo forme procesného reťazca riadeného udalosťami pre plánovanie zdrojov.

Rôzne projekty vyžadujú rôzne úrovne kontroly. Ak napríklad publikujete sériu článkov v , krátke termíny nie sú také dôležité. Oveľa dôležitejší je prehľadný proces, v ktorom je možné každý článok štruktúrovať, načrtnúť každý z nich, získať spätnú väzbu, urobiť úpravy, dokončiť článok, korigovať a publikovať. Namiesto riadenia času a zdrojov riadite proces.

Pre takéto projekty sú vhodnejšie agilné metódy projektového manažmentu a súvisiace prístupy ako Lean, Kanban a iné. Existujú aj metódy, ktoré vám umožnia spravovať pracovný tok aj čas a zdroje – 6 Sigma a Scrum.

Populárne systémy riadenia projektov

Počas histórie projektového manažmentu bolo vytvorených mnoho rôznych metód projektového manažmentu pre takmer akúkoľvek potrebu. Aj keď sa nechystáte poslať človeka na Mesiac a nemáte podobné množstvo prostriedkov, stále nájdete ten správny nástroj pre vás. Hlavné je pochopiť, čo je pre váš projekt najdôležitejšie – termíny, zdroje, dodržanie procesu, prípadne viacero faktorov naraz – a následne zvoliť metódu projektového riadenia zameranú na dosiahnutie tohto ukazovateľa.

Skôr než sa pustíme do najpopulárnejších metód, definujme si niektoré kľúčové pojmy.

Základné pojmy projektového manažmentu

Agilný Flexibilný iteračno-inkrementálny prístup k projektovému a produktovému manažmentu, zameraný na dynamickú tvorbu požiadaviek a zabezpečenie ich implementácie ako výsledok neustálej interakcie v rámci samoorganizujúcich sa pracovných skupín zložených zo špecialistov v rôznych oblastiach. Existuje mnoho metód založených na myšlienkach Agile, z ktorých najpopulárnejšie sú Scrum a Kanban.

Kritická cesta: Nepretržitý sled činností a udalostí od začiatku do konca, ktorý trvá najdlhšie, kým sa dokončí.

Reťazec udalostí procesov (EPC diagram): diagram znázorňujúci postupnosť realizácie projektových prác na základe dostupnosti a pracovného zaťaženia zdrojov

Časová rezerva:Čas, o ktorý možno odložiť začiatok prác bez ovplyvnenia celkového trvania projektu. Medzera pre činnosti na kritickej ceste bude teda nulová.

míľnik (kontrolný bod,míľnik): Kľúčová udalosť, ktorá označuje napríklad koniec etapy. V Ganttovom diagrame je označený úlohou s nulovým trvaním.

Projektový manažér (vedúci projektu,projektumanažér,POPOLUDNIE ): Vedúci projektového tímu zodpovedný za riadenie projektu (plánovanie, realizácia a ukončenie projektu).

zdroje: Prvky potrebné na realizáciu projektu. Zdrojmi sú čas, vybavenie, materiál, zamestnanci atď.

šprint (šprint): Iterácia (pracovný cyklus) v Scrume trvajúca týždeň až mesiac, počas ktorej sa vytvorí pracovná verzia produktu alebo jeho prvku, ktorá má pre zákazníka hodnotu.

"Klasický" alebo "tradičný" projektový manažment: Najpoužívanejšia metóda projektového manažmentu, založená na takzvanom "Vodopáde" (Vodopád) alebo kaskádovom cykle, v ktorom sa úloha postupne prenáša cez etapy, pripomínajúce tok.

Klasický projektový manažment

Najzrejmejším spôsobom, ako urobiť svoj projekt lepšie zvládnuteľným, je rozdeliť ho na postupné kroky. Tradičný projektový manažment je založený na tejto lineárnej štruktúre. V tomto zmysle to pripomína počítačovú hru - nemôžete prejsť na ďalšiu úroveň bez dokončenia predchádzajúcej. Diagram pracovného toku je zobrazený na Obrázok 3.

Tento prístup je zameraný na projekty, v ktorých sú prísne obmedzenia na postupnosť úloh. Napríklad stavba domu - nemôžete postaviť steny bez základov.

Klasický projektový manažment má zvyčajne 5 stupňov, ale ak si to projekt vyžaduje, môžu byť pridané ďalšie stupne.

5 stupňov tradičného manažmentu:

Fáza 1. Iniciácia. Projektový manažér a tím definujú požiadavky na projekt. V tejto fáze sa často konajú stretnutia a brainstormingové stretnutia, na ktorých sa určí, aký by mal byť produkt projektu.

Fáza 2. Plánovanie. V tejto fáze sa tím rozhodne, ako dosiahne cieľ stanovený v predchádzajúcej fáze. V tejto fáze tím spresňuje a upresňuje ciele a výsledky projektu, ako aj rozsah práce preň. Na základe týchto informácií tím vytvorí harmonogram a rozpočet, posúdi riziká a identifikuje zainteresované strany.

Etapa 3. Vývoj. Táto etapa sa nerealizuje pri všetkých projektoch – spravidla je súčasťou plánovacej fázy. Vo vývojovej fáze, charakteristickej pre technologické projekty, sa určuje konfigurácia budúceho projektu a/alebo produktu a technické prostriedky na jeho dosiahnutie. Napríklad pri IT projektoch sa v tejto fáze volí programovací jazyk. ( V domácej praxi sa táto fáza zvyčajne nerozlišuje a nepoužíva sa pojem "vývoj" - cca. trans.)

Fáza 4. Implementácia a testovanie. V tejto fáze vlastne prebieha hlavná práca na projekte – písanie kódu, výstavba budovy a podobne. Po vypracovaných plánoch sa začína vytvárať obsah projektu, ktorý bol definovaný skôr, kontrola sa vykonáva podľa zvolených metrík. V druhej časti tejto fázy sa produkt testuje, kontroluje sa, či spĺňa požiadavky zákazníka a záujemcov. Z hľadiska testovania sa zisťujú a opravujú nedostatky produktov.

Etapa 5. Monitorovanie a ukončenie projektu. V závislosti od projektu môže táto fáza pozostávať z jednoduchého prenosu výsledkov projektu klientovi alebo zdĺhavého procesu interakcie s klientmi s cieľom zlepšiť projekt a zvýšiť ich spokojnosť a podporiť výsledky projektu. Ten sa týka projektov v oblasti služieb zákazníkom a softvéru.

To, čo je opísané vyššie, je základom, na ktorom sú postavené rôzne metódy projektového riadenia. Rôzne projekty potrebujú rôzne fázy implementácie – niektoré potrebujú tri fázy, iné oveľa viac. Niekedy sa používa takzvaný „iteračný vodopád“, v ktorom je každá etapa akýmsi podprojektom, počas ktorého sa úlohy realizujú v pevných iteráciách. Podstata však zostáva rovnaká - projekt je rozdelený na etapy, ktoré sa vykonávajú v presne definovanom poradí.

Vzhľadom na to, že klasický projektový manažment je striktne viazaný na dobu realizácie úloh, spravidla vopred určenú vo fáze plánovania, sú na realizáciu projektov v rámci tohto prístupu vynikajúce kalendárno-sieťové plánovacie nástroje. Najbežnejším plánovacím nástrojom je už spomínaný Ganttov diagram. Na jeho zostavenie existuje veľa nástrojov, od jednoduchých tabuliek, ako sú Excel a Smartsheet, až po profesionálne softvérové ​​balíky, ako sú Microsoft Project a Primavera.

Silné stránky klasického projektového manažmentu

Dnes sa často hovorí, že klasický vodopádový prístup je zastaraný, no o strate pôdy ani neuvažuje. Veľkou výhodou tohto prístupu je, že vyžaduje, aby zákazník a manažment spoločnosti určili, čo chcú získať už v prvej fáze projektu. Skoré začlenenie prináša určitú stabilitu do práce na projekte a plánovanie umožňuje zefektívniť realizáciu projektu. Tento prístup navyše zahŕňa monitorovanie indikátorov a testovanie, ktoré je pre reálne projekty rôznych veľkostí absolútne nevyhnutné.

Klasický prístup potenciálne predchádza stresu kvôli prítomnosti voľného času v každej fáze, stanoveného v prípade akýchkoľvek komplikácií a implementácie rizík. Navyše, so správne vykonanou fázou plánovania projektový manažér vždy vie, aké zdroje má. Aj keď tento odhad nie je vždy presný.

Slabé stránky klasického projektového manažmentu

Hlavnou slabinou klasického projektového manažmentu je netolerancia voči zmenám. Vedenie Toyoty, známej tvorbou systémov ako Lean a Kanban, je často kritizované za klasický prístup k vývoju softvéru pre ich spoločnosť a práve pre nedostatok flexibility.

Nosným pilierom klasického prístupu sú teraz stavebné a inžinierske projekty, v ktorých obsah projektu zostáva prakticky nezmenený počas celého projektu. Ak však zdroje a čas nie sú kľúčovými obmedzeniami vášho projektu a rozsah projektu sa môže zmeniť, možno sa budete musieť pozrieť na iné systémy riadenia projektu.

Agilný

Ako už bolo spomenuté, nie všetky projekty môžu byť štruktúrované tak, aby sa realizovali podľa klasického projektového prístupu. Vráťme sa k nášmu príkladu šéfkuchára, varenie jedného jedla je ideálne pre vodopádový prístup, ale príprava a servírovanie štvorchodovej večere načas by bolo takmer nemožné, ak by ste museli zakaždým čakať na dovarenie jedného jedla a až potom začať s ďalším.

A tu vstupuje do hry Agile – rodina flexibilných iteratívno-inkrementálnych metód na riadenie projektov a produktov. Podľa tohto prístupu sa projekt nerozdeľuje na po sebe idúce fázy, ale na malé podprojekty, ktoré sa následne „montujú“ do hotového produktu. Schéma práce je zobrazená na Obrázok 5.

Iniciácia a plánovanie na najvyššej úrovni sa teda vykonáva pre celý projekt a následné fázy: vývoj, testovanie a iné sa vykonávajú pre každý miniprojekt samostatne. To vám umožňuje rýchlejšie prenášať výsledky týchto miniprojektov, takzvané prírastky, a pri spustení nového podprojektu (iterácii) v ňom môžete robiť zmeny bez vysokých nákladov a dopadu na zvyšok projektu. .

Napriek tomu, že Agile prišiel do módy relatívne nedávno, myšlienka iteratívneho vývoja nie je nová. (o histórii vzhľaduAgile sa dá čítať - približne za). Rodina agilných metodológií získala svoje súčasné meno v roku 2001 vydaním Agile Manifesto (Agile Manifesto), ktorý upevnil základné hodnoty a princípy vývoja agilného softvéru, ktoré sú založené na tímovej práci a adaptácii, dokonca aj „láske“ pre zmeniť.

Agile sama o sebe nie je metódou projektového riadenia. Ide skôr o súbor myšlienok a princípov, ako by sa mali projekty realizovať. Už na základe týchto princípov a osvedčených postupov boli vyvinuté samostatné flexibilné metódy alebo, ako sa niekedy nazývajú, frameworky: Scrum, Kanban, Crystal a mnohé ďalšie. Tieto metódy sa môžu navzájom značne líšiť, ale riadia sa rovnakými princípmi.

Silné stránkyAgilný

Najdôležitejšou výhodou Agile je jeho flexibilita a prispôsobivosť. Dokáže sa prispôsobiť takmer akýmkoľvek podmienkam a procesom organizácie. Práve to určuje jeho súčasnú obľúbenosť a koľko systémov pre rôzne oblasti bolo na jeho základe vytvorených.

Jedným z princípov Agile je: „Reagovať na zmenu je dôležitejšie ako nasledovať plán.“ Práve rýchla a relatívne bezbolestná reakcia na zmenu je dôvodom, prečo sa mnohé veľké spoločnosti snažia spružniť svoje procesy. Agile je navyše skvelá pre projekty s otvoreným koncom, ako je spustenie služby alebo blogu.

Oblasťou Agile je vývoj nových, inovatívnych produktov. V projektoch vývoja takýchto produktov existuje vysoký stupeň neistoty a informácie o produkte sa zverejňujú v priebehu projektu. Za takýchto podmienok je nemožné realizovať projekt na „vodopáde“ - neexistujú žiadne informácie na plánovanie.

Slabé stránkyAgilný

Na rozdiel od PRINCE2 a PMBOK nie je Agile metodikou ani štandardom. Agile je súbor princípov a hodnôt. Slabšou stránkou je, že každý tím si bude musieť samostatne zostaviť vlastný systém riadenia, ktorý sa bude riadiť princípmi Agile. Ide o zložitý a zdĺhavý proces, ktorý si vyžiada zmeny v celej organizácii, od postupov až po základné hodnoty. Toto je tŕnistá cesta a nie všetky organizácie to dokážu.

Táto cesta si od lídra zmeny bude vyžadovať nielen znalosti a vytrvalosť, ale aj seriózne administratívne zdroje, ako aj náklady. Našťastie existujú hotové súbory postupov, ktoré organizáciám uľahčia transformáciu Agile. Medzi tieto sady patrí rámec Scrum, metóda Kanban a mnohé ďalšie – Crystal, LeSS, SAFe, Nexus.

Scrum

Agilný rámec, vytvorený v roku 1986, je považovaný za najštruktúrovanejší z rodiny Agile. Bol vytvorený v roku 1986 a spája prvky klasického procesu a myšlienky agilného prístupu k riadeniu projektov. Výsledkom je veľmi vyvážená kombinácia flexibility a štruktúry.

Podľa pravidiel Agile, Scrum rozdeľuje projekt na časti, ktoré môže zákazník okamžite použiť na získanie hodnoty, nazývané produktové backlogy. A napriek tomu, že „product backlog“ je pomerne presný preklad a používa sa v odbornej literatúre, v ruskej praxi sa najčastejšie používa jednoducho „backlog“. Potom tieto časti uprednostní Product Owner – zástupca Zákazníka v tíme. Najdôležitejšie „kúsky“ sú ako prvé vybrané na vykonanie v Sprinte – takzvané iterácie v Scrume, trvajúce od 2 do 4 týždňov. Na konci Sprintu je zákazníkovi prezentovaný pracovný produkt - najdôležitejšie "kúsky", ktoré už môžu byť použité. Napríklad stránka s časťou funkcionality alebo program, ktorý už funguje, aj keď čiastočne. Potom projektový tím pokračuje do ďalšieho Sprintu. Trvanie Sprintu je pevne dané, ale tím si ho na začiatku projektu zvolí nezávisle na základe projektu a vlastného výkonu.

Aby projekt spĺňal požiadavky Zákazníka, ktoré majú tendenciu sa časom meniť, pred začiatkom každého Sprintu sa prehodnotí rozsah projektu, ktorý ešte nebol dokončený, a urobia sa v ňom zmeny. Do tohto procesu sú zapojení všetci – projektový tím, Scrum Master (Scrum Master, vedúci projektového tímu) a Product Owner. A každý je zodpovedný za tento proces.

Ako už bolo uvedené, Product Owner je zástupcom Zákazníka v projekte, prípadne zosobňuje všetkých klientov budúceho projektu, ak Zákazník nie je prítomný. K tomu musí dôkladne poznať ich potreby a spôsob myslenia, ako aj rozumieť produktu a technológii jeho výroby. Scrum Master je navrhnutý tak, aby pomohol účastníkom projektu lepšie pochopiť a prijať hodnoty, princípy a normy praxe Scrum. Je vodcom a sprostredkovateľom medzi vonkajším svetom a tímom. Jeho úlohou je zabezpečiť, aby nikto sám od seba nezasahoval do tímu a pohodlne pracovať na úlohách. Tím je zodpovedný za to, že na konci sprintu budú dokončené všetky potrebné úlohy a dokončené dodávky.

Základná štruktúra procesov Scrumu sa točí okolo 5 hlavných stretnutí: Backlog Sequencing, Sprint Planning, Daily Meetings, Sprint Debriefing a Sprint Retrospective.

Mnohým sa môže Scrum zdať ťažko realizovateľný – nový proces, nové roly, veľa delegovania a úplne nová organizačná štruktúra. Ide však o flexibilný, ale štruktúrovaný prístup k realizácii projektov, ktorý na rozdiel od vágnych a všeobecných princípov Agile nedovolí, aby sa veci pokazili.

Silné stránkyScrum

Scrum bol navrhnutý pre projekty, ktoré vyžadujú „rýchle výhry“ v kombinácii s toleranciou voči zmenám. Okrem toho je tento rámec vhodný pre situácie, keď nie všetci členovia tímu majú dostatočné skúsenosti v oblasti, v ktorej sa projekt realizuje - neustála komunikácia medzi členmi tímu umožňuje nedostatok skúseností alebo kvalifikácie niektorých zamestnancov kvôli informáciám a pomoci kolegov .

Online TV kanál Netflix je skvelým príkladom rýchleho poskytovania výsledkov. Webová stránka zdrojov sa aktualizuje každé dva týždne vďaka Scrumu, čo vám umožňuje nielen pracovať vysokou rýchlosťou, ale tiež hromadí používateľskú skúsenosť a umožňuje zákazníkom identifikovať to najdôležitejšie.

Počas každej iterácie vývojári pridávajú a testujú nové funkcie stránky a odstraňujú tie, ktoré zákazníci nepoužívali. Podľa tímu Netflix je hlavnou výhodou Scrumu to, že vám umožňuje „rýchlo zlyhať“. Namiesto dlhého a nákladného hlavného vydania sú dodávky scrumu malé. Sú ľahko sledovateľné a ak sa niečo pokazí, rýchlo to opravte.

Slabé stránkyScrum

Scrum je veľmi náročný na projektový tím. Mal by byť malý (5-9 ľudí) a multifunkčný – to znamená, že členovia tímu by mali mať viac ako jednu kompetenciu potrebnú na realizáciu projektu. Napríklad vývojár softvéru musí mať znalosti o testovaní a business intelligence. Deje sa tak preto, aby časť tímu „nezaháľala“ v rôznych fázach projektu, ako aj preto, aby si zamestnanci navzájom pomáhali a nahrádzali sa.

Členovia tímu musia byť navyše „tímoví hráči“, aktívne prevziať zodpovednosť a vedieť sa zorganizovať. Nájsť taký vyspelý tím je veľmi ťažké!

Scrum nie je vhodný pre všetky tímy a organizácie aj preto, že navrhovaný proces nemusí byť vhodný pre vývoj konkrétneho produktu – napríklad priemyselného stroja alebo stavby budovy.

Lean

Agile nám hovorí, čo sa má rozdeliť do malých, zvládnuteľných balíkov práce, ale nehovorí nič o tom, ako riadiť vývoj tohto balíka. Scrum nám ponúka svoje procesy a postupy. Lean zase pridáva k princípom Agile schému pracovného toku, aby sa každá z iterácií vykonávala rovnako kvalitne.

V Lean, rovnako ako v Scrume, je práca rozdelená do malých balíkov dodávok, ktoré sú implementované samostatne a nezávisle. Ale v Lean existuje pre vývoj každého balíka dodávok pracovný postup s krokmi podobnými tým, ktoré boli vytvorené pre projekt Apollo. Ako v klasickom projektovom manažmente, môžu to byť fázy plánovania, vývoja, výroby, testovania a dodávky – alebo akékoľvek iné fázy potrebné pre kvalitatívnu realizáciu projektov.

Štíhle etapy a ich flexibilita vám umožňujú mať istotu, že každá časť projektu je implementovaná podľa potreby. Lean nemá jasné hranice fázy, ako to má Scrum s limitmi Sprint. Navyše na rozdiel od klasického projektového manažmentu vám Lean umožňuje vykonávať niekoľko úloh paralelne v rôznych fázach, čo zvyšuje flexibilitu a zvyšuje rýchlosť realizácie projektu.

Rovnako ako Agile, aj Lean je skôr koncept, spôsob myslenia než niečo vytesané do kameňa. Pomocou nápadov Lean môžete nezávisle vytvoriť systém, ktorý spĺňa vaše požiadavky na riadenie projektov.

Silné stránkyLean

Ak máte radi agilné nápady, ale projekt vyžaduje veľmi hladkú kvalitu a precíznu realizáciu, Lean poskytuje sadu nástrojov na splnenie týchto požiadaviek. Lean kombinuje flexibilitu a štruktúru ako Scrum, ale trochu iným spôsobom.

Slabé stránkyLean

Nie každá časť projektu si vyžaduje rovnako podrobné a starostlivé štúdium a pozornosť. Ale Lean predpokladá presne tento prístup ku každej úlohe a fáze. Toto je hlavná nevýhoda používania Lean pre veľké a heterogénne projekty.

Na rozdiel od Scrumu tiež Lean neponúka jasný pracovný postup pre implementáciu „kúskov“ projektu, čo prispieva k naťahovaniu časovej osi projektu. Tento problém sa dá vyriešiť efektívnym vedením a jasnou komunikáciou. Hlavná vec, ktorú si treba zapamätať, je toto.

Kanban

Lean vyzerá sám o sebe trochu abstraktne, ale v kombinácii s Kanban je oveľa jednoduchšie ho použiť na vytvorenie vlastného systému riadenia projektov. Kanban, ktorý vytvoril inžinier Toyoty Taiichi Ono v roku 1953, je veľmi podobný priemyselnej výrobe. Pri vstupe do tohto procesu vstupuje kus kovu a hotová časť sa získava na výstupe. Aj v Kanban sa prírastok produktu posúva z fázy do fázy a na konci sa získa položka pripravená na dodanie.

Okrem toho sa tvorca Kanbanu inšpiroval supermarketmi, a to ich zásadou – „ponechať v regáloch len to, čo zákazník potrebuje“. Preto vám Kanban umožňuje ponechať nedokončenú úlohu v jednej z fáz, ak sa jej priorita zmenila a existujú ďalšie naliehavé úlohy. Neupravený blogový príspevok, zavesenie bez dátumu zverejnenia alebo časť kódu pre funkciu, ktorá nemusí byť súčasťou produktu, to všetko je normálne pre prácu Kanban.

Kanban je oveľa menej prísny ako Scrum – neobmedzuje čas šprintov, neexistujú žiadne role, okrem produktového vlastníka. Kanban dokonca umožňuje členovi tímu vykonávať viacero úloh naraz, čo Scrum neumožňuje. Taktiež porady o stave projektu nie sú nijako regulované – môžete si to robiť ako chcete, alebo nemôžete robiť vôbec.

Ak chcete pracovať s Kanban, musíte definovať kroky pracovného postupu. V Kanbane sú zobrazené ako stĺpce a úlohy predstavujú špeciálne karty. Karta sa pohybuje medzi jednotlivými fázami, ako keď sa časť v továrni presúva zo stroja na stroj, a v každej fáze je percento dokončenia vyššie. Výsledkom je, že produktový prvok je pripravený na dodanie zákazníkovi. Tabuľa so stĺpcami a kartami môže byť skutočná aj elektronická – ani tu Kanban nekladie používateľom žiadne obmedzenia.

Váš vlastný systém Kanban môže byť flexibilný, ako chcete, pretože Kanban je v mnohých ohľadoch vizualizáciou agilnej myšlienky. Kanban má však 4 piliere, na ktorých stojí celý systém:

1. karty: Pre každú úlohu je vytvorená individuálna karta, do ktorej sú zapísané všetky potrebné informácie o úlohe. Všetky potrebné informácie o úlohe sú tak vždy po ruke.
2. Obmedzenie počtu úloh na etapu: Počet kariet v jednej fáze je prísne regulovaný. Vďaka tomu je okamžite jasné, kedy dôjde k „zápche“ v pracovnom toku, ktorá je okamžite eliminovaná.
3. Nepretržitý tok:Úlohy z nevybavených úloh spadajú do toku v poradí podľa priority. Takže práca sa nikdy nezastaví.
4. Neustále zlepšovanie (kaizen)kaizen)): Koncept neustáleho zlepšovania sa objavil v Japonsku na konci 20. storočia. Jej podstatou je neustále analyzovanie výrobného procesu a hľadanie spôsobov, ako zvýšiť produktivitu.

Silné stránkyKanban

Rovnako ako Scrum, aj Kanban je vhodný pre pomerne úzke tímy s dobrou komunikáciou. Na rozdiel od Scrumu však Kanban nemá ťažké termíny, čo je dobré pre vysoko motivované a skúsené tímy.

Pri správnom nastavení a riadení môže Kanban priniesť projektovému tímu veľkú hodnotu. Presný výpočet zaťaženia tímu, správne umiestnenie obmedzení a zameranie sa na neustále zlepšovanie – to všetko umožňuje Kanbanu vážne šetriť zdroje a vtesnať sa do termínov a rozpočtu. A to všetko v kombinácii s flexibilitou.

Slabé stránkyKanban

Často môžete počuť, že Kanban, na rozdiel od Scrumu, dokáže spolupracovať s takmer akýmkoľvek tímom. Ale nie je to tak. Kanban je najvhodnejší pre tímy, ktorých zručnosti členov sa prekrývajú. Vzájomne si tak môžu pomáhať prekonávať ťažkosti pri riešení problémov. Bez toho nebude Kanban taký efektívny, ako by mohol byť. Ako už bolo spomenuté, Kanban je tiež vhodnejší v prípadoch, keď neexistujú žiadne tvrdé termíny. Pre krátke termíny je vhodnejší klasický prístup alebo Scrum.

6 sigma (Six Sigma)

Motorola spolu s Toyotou tiež prispeli k rozvoju globálneho projektového manažmentu. Bill Smith, inžinier v tejto spoločnosti, vytvoril koncept 6 Sigma v roku 1986. Je to štruktúrovanejšia verzia Lean ako Kanban, ktorá pridáva viac plánovania na šetrenie zdrojov, zlepšenie kvality a zníženie odpadu a problémov.

Konečným cieľom projektu je spokojnosť zákazníka s kvalitou produktu, ktorú je možné dosiahnuť neustálym procesom zlepšovania vo všetkých aspektoch projektu na základe dôkladnej analýzy ukazovateľov. V koncepte 6 sigma sa venuje osobitná pozornosť odstraňovaniu vznikajúcich problémov.

Na tento účel bol navrhnutý 5-krokový proces známy ako DMEDI:

• Definícia (definovať): Prvý stupeň je veľmi podobný počiatočným štádiám iných systémov riadenia projektov. Určuje obsah projektu, zbiera informácie o predpokladoch projektu, stanovuje ciele.
• rozmer (merať): 6 Sigma je zameraná na zber a analýzu kvantitatívnych údajov o projekte. V tejto fáze sa určuje, ktoré ukazovatele určia úspešnosť projektu a aké údaje je potrebné zbierať a analyzovať.
• Štúdium (Preskúmať): Počas fázy výskumu projektový manažér rozhodne, ako môže tím dosiahnuť svoje ciele a splniť všetky požiadavky včas av rámci rozpočtu. V tejto fáze je veľmi dôležité neštandardné myslenie projektového manažéra pri riešení vzniknutých problémov.
• rozvoj (Rozvíjať): V tejto fáze sa realizujú plány a rozhodnutia prijaté v predchádzajúcich fázach. Je dôležité pochopiť, že v tejto fáze je potrebný podrobný plán, ktorý popisuje všetky činnosti potrebné na dosiahnutie cieľov. V tejto fáze sa meria aj postup projektu.
• Kontrola (ovládanie): Kľúčový míľnik v metodológii 6 Sigma. Jeho hlavným cieľom je dlhodobé zlepšovanie procesov implementácie projektov. Táto fáza si vyžaduje starostlivé zdokumentovanie získaných skúseností, analýzu zozbieraných údajov a aplikáciu získaných poznatkov v projektoch, ako aj v rámci celej spoločnosti.

6 Sigma je veľmi podobná Kanbanu, len so stanovenými fázami realizácie úloh – plánovanie, stanovenie cieľov a testovanie kvality. S najväčšou pravdepodobnosťou bude s 6 Sigmou podstatne viac tímových stretnutí ako s Kanbanom, ale proces implementácie projektu je štruktúrovanejší a pre tím je ťažšie zablúdiť. A podobne ako Kanban, aj 6 Sigma sa pomerne ľahko prispôsobuje potrebám konkrétnej spoločnosti alebo tímu. Prísnou požiadavkou je len dôsledné meranie a kontrola ukazovateľov projektu v etapách implementácie – bez toho nie je možné neustále a dlhodobé zlepšovanie procesov implementácie projektu.

Silné stránky 6 Sigma

Six Sigma poskytuje jasný plán implementácie projektu a neustáleho zlepšovania procesov. Definovaním cieľov, ich starostlivou analýzou a revíziou získate kvantitatívne údaje pre hlbšie pochopenie projektu a lepšie rozhodnutia. Zhromažďovanie údajov, ich analýza a učenie môže chvíľu trvať, ale zlepší a zefektívni procesy implementácie projektov, a tým ušetrí zdroje v budúcnosti.

6 sigma je vhodná pre náročné projekty s mnohými novými a zložitými operáciami. Tento prístup vám umožňuje implementovať prvky projektu, poučiť sa z chýb a zlepšiť kvalitu v budúcnosti.

Slabiny 6 Sigma

Problémom 6 Sigmy je, že hoci je hlavným deklarovaným cieľom znižovanie nákladov a zvyšovanie efektivity, do popredia sa často dostáva spokojnosť zákazníkov. Vzhľadom na niektoré rozdiely v cieľoch v rôznych fázach projektu sú tímy často zmätené, pokiaľ ide o priority, a vyhnúť sa tomu nie je jednoduché.

Okrem toho je hlavným leitmotívom 6 Sigma: "Všetko sa dá vždy urobiť ešte lepšie." To môže demotivovať zamestnancov, ktorí sa necítia spokojní s vykonanou prácou. Navyše, ak je projekt jednorazový a spoločnosť neplánuje realizovať podobné projekty v budúcnosti, všetky náklady na analýzu a učenie môžu byť márne.

PRINCE2

NASA nie je jedinou vládnou organizáciou, ktorá prispela k rozvoju projektového manažmentu. Britská vláda dlhodobo oceňuje efektívnosť projektového manažmentu av roku 1989 bola vytvorená britská metodika PRINCE2. Názov pochádza zo skratky „ PR predmety IN C kontrolované E verzia nvironments 2 “, čo v preklade znamená „Projekty v kontrolovanom prostredí verzie 2“. Na rozdiel od agilných metód, PRINCE2 nepristupuje k projektu opakovane. Pri porovnaní s inými produktmi možno PRINCE2 prirovnať ku hybridu klasického prístupu k riadeniu projektov a zamerania sa na kvalitu od 6 sigma.

Metodika PRINCE2, na rozdiel napríklad od súboru poznatkov PMBOK, neobsahuje:

• Špecializované aspekty projektového manažmentu, ako napríklad priemysel;
• Špecifické postupy a nástroje projektového manažmentu ako Ganttov diagram, WBS atď.

PRINCE2 sa sústreďuje na aspekty projektového manažmentu vyjadrené v 7 princípoch, 7 procesoch a 7 projektových témach.

• 7 princípov definuje všeobecné pravidlá riadenia projektov podľa PRINCE2, definuje základ metodiky;
• 7 procesov definuje kroky na prechod cez projektový cyklus;
• 7 tém sú aspekty, ktoré sa monitorujú, aby sa dosiahol úspech projektu.

Na začiatku projektu nás PRINCE2 žiada, aby sme definovali 3 hlavné aspekty projektu:

• Obchodný aspekt (Prinesie tento projekt výhody?)
• Spotrebiteľský aspekt (Aký produkt je potrebný, čo urobíme?)
• Aspekt zdrojov (Máme dosť na dosiahnutie cieľa?)

PRINCE2 má jasnejšie definovanú štruktúru projektového tímu ako väčšina prístupov projektového manažmentu. Je to spôsobené tým, že PRINCE2 je zameraný na veľké vládne projekty a veľké organizácie.

Podľa PRINCE2 má každý člen tímu osobitnú úlohu v každom zo 7 procesov:

• Začiatok projektu (Štarting horea projektu): Počas tohto procesu je menovaný projektový manažér a stanovujú sa celkové požiadavky na výkonnosť produktu. Projektový manažér, ktorého primárnou zodpovednosťou je pozornosť venovaná detailom, zodpovedá Riadiacemu výboru projektu, ktorý je zodpovedný za celkové smerovanie projektu. Je to riadiaci výbor, ktorý udržiava projekt na správnej ceste a je plne zodpovedný za úspech projektu.
• Začatie projektua projektu): Počas tohto procesu projektový manažér pripraví „Projektový iniciačný dokument“, ktorý obsahuje fázový plán projektu. Etapy môžu trvať rôzne dlho, ale ako v klasickom prístupe, nasledujú striktne jedna za druhou.
• Projektový manažment (Directing a projektu): Tento proces umožňuje riadiacemu výboru prevziať celkovú zodpovednosť za úspech projektu bez toho, aby sa zamotal do detailov, ktoré sú v kompetencii projektového manažéra.
• Ovládanie fázy (Controlling a etapa): Počas realizácie projektu aj v ideálnych podmienkach dôjde k určitým zmenám. Proces Stage Control implementuje jeden z princípov PRINCE2 - princíp riadenia výnimiek. Zodpovednosťou projektového manažéra je sledovať počas realizácie etapy odchýlky od plánovaných parametrov projektu z hľadiska času, rozsahu, rozpočtu a pod. Ak tieto odchýlky prekračujú oprávnenia dané projektovému manažérovi Riadiacim výborom (v Terminológia PRINCE2 - tolerancie) je projektový manažér povinný informovať Riadiaci výbor a navrhnúť východisko zo situácie.
• Správa tvorby produktov (Riadenie produkt doručenie): Proces riadenia tvorby produktu je interakcia medzi projektovým manažérom a manažérom tímu s cieľom vytvoriť jeden z produktov projektu. Medzi zodpovednosti projektového manažéra v tomto procese patrí delegovanie oprávnenia na vytvorenie produktu manažérovi tímu a akceptovanie vytvoreného produktu.
• Manažment hraníc etapy (Managing a etapa hranica): Projektový manažér počas tohto procesu poskytuje riadiacemu výboru všetky potrebné informácie na vyhodnotenie výsledkov prejdenej etapy a rozhodnutie o prechode do ďalšej etapy.
• Ukončenie projektu (Uzávierkaa projektu): Jedným z rozdielov v PRINCE2 je, že proces dokončenia projektu nie je rozdelený do samostatnej etapy alebo etapy, ako pri klasickom prístupe, ale je vykonávaný ako súčasť konečnej fázy tvorby produktu. Účelom procesu je potvrdiť, že produkt projektu bol prijatý, alebo že projekt už nemôže priniesť nič užitočné.

PRINCE2 je možné prispôsobiť projektom akejkoľvek veľkosti a akejkoľvek oblasti. Metodika ponúka konkrétne odporúčania na zmenu životného cyklu projektu, vzoru a súboru požadovaných dokumentov v súlade s potrebami projektu.

Silné stránky PRINCE2

• Prispôsobivosť charakteristikám organizácie;
• Prítomnosť jasného popisu úloh a rozdelenia zodpovedností;
• Dôraz na projektové produkty;
• Určité úrovne riadenia;
• Zamerajte sa na ekonomickú realizovateľnosť;
• Postupnosť projektových prác;
• Dôraz na získavanie skúseností a neustále zlepšovanie.

Slabé stránky PRINCE2

• Nedostatok priemyselných postupov;
• Nedostatok špecifických nástrojov na prácu v projekte.

Najlepší systém riadenia projektov ... pre vás!

Projektový manažment je veda, ale nie je najpresnejšia. V tejto oblasti neexistujú neotrasiteľné základy a univerzálne riešenia. Ak sa vám podarí nájsť metódu, ktorá dokonale vyhovuje vášmu projektu, považujte sa za veľmi šťastného, ​​pretože väčšina menej šťastných manažérov si musí vynaložiť námahu na vytvorenie a prispôsobenie vlastných systémov riadenia projektov. Tieto systémy môžu byť zložené z prvkov existujúcich systémov, alebo dokonca môžu byť vytvorené úplne od začiatku, ako v prípade misie Apollo. Hlavná vec je použiť niečo, čo vám dáva určitú štruktúru a umožňuje vám zapamätať si, čo je pre váš projekt dôležité.

« Cynizmus je odpoveďou nášho vedomia na pocit zúfalstva.».
Jeff Sutherland

Aká silná je alternatíva PM?

Ako top manažér a projektový manažér som narazil na koncept Scrumu ako na akúsi exotickú alternatívu klasického projektového manažmentu. Chcel som pochopiť, aké sú ideologické a technologické črty tohto prístupu a čo je v skutočnosti revolúcia tejto metódy? Prečítal som viacero monografií. Aby som bol úprimný, po prvom stretnutí som nevidel veľkú hĺbku. Metodológia Scrumu sa zdala byť trochu neobjektívna a nešpecifická.

Pri druhom, podrobnejšom, zvažovaní metódy Scrum sa začali realizovať vlastnosti, ktoré si podľa mňa ešte stále zasluhujú veľkú pozornosť podnikateľskej komunity. Dokonca sa zdá, že tento spôsob je zaujímavý nielen pre komerčno-priemyselnú sféru, ale aj pre ostatné inštitúcie našej spoločnosti. Metóda je použiteľná pri navrhovaní modelov vzdelávania, výskumu a vývoja, štátnej a komunálnej výstavby. Ako pri každej novinke je však dôležité:

• vylúčiť absolutizáciu a preskripčnú bezchybnosť uvažovanej technológie;
• uvedomte si, že metóda Scrum je ideologicky surová a možno jednoducho „neleží na našej pôde“ so svojimi spôsobmi a tradíciami;
• pozrite si konfliktné body, ktoré táto metóda nesie;
• pochopiť, že metóda Scrum si vyžaduje transparentnú ideológiu štátu a biznisu ohľadom „pravidiel hry“ s personálom zapojeným do vývoja.

Sú moderná paradigma projektového manažmentu, medzinárodné a národné štandardy (ANSI Pmbok Guide, PM ICB IPMA, NTK) produktom, ktorý využívajú spotrebitelia: štát, jeho inštitúcie, biznis? Jasné. Aké problémové oblasti existujú v modernej dizajnérskej praxi založenej na pracovnej metodológii? Je ich viacero, no hlavné sú dve: nedodržanie termínov projektu a prekročenie rozpočtu projektu.

V manažmente je známe pravidlo: ak úloha má precedensy na riešenie a už bola mnohokrát vykonaná, tiahne k procesom a ťažkosti pri jej riešení sú špecifického charakteru. Ak nie sú žiadne skúsenosti s jej riešením, potom je úloha na jednej strane ideálnym projektom od prírody a na druhej strane je spôsob jej realizácie menej jasný, má nejasný obraz. Najväčším stresom pre projektového manažéra je proces plánovania ideálneho projektu z hľadiska rozsahu a načasovania. Zároveň je pre zákazníka niekedy veľmi ťažké rozložiť výsledok projektovej úlohy na základe zloženia hodnôt, ktoré očakáva.

Táto vlastnosť projektov je obzvlášť akútna v oblastiach, ktoré si vyžadujú inovatívny prístup. Metóda Scrum dokáže tieto problémy výrazne zmierniť. Začiatkom roku 2000 bol výsledkom práce dvoch inovátorov D. Sutherlanda a K. Schwabera (USA). Pri ich vývoji autori metódy využili prvky teórie H. Takeuchiho a I. Nonaka, ako aj myšlienky systému Toyota (Taiichi Ono). A ako revolučná metóda projektového riadenia si model Scrum už získal uznanie v západných krajinách a dnes sa prax jeho aplikácie neobmedzuje len na biznis.

Terminológia metódy

Autori metódy dôvodne kritizovali klasický model plánovania projektov, ktorý sa na základe prístupu G. Gantta používa už asi 100 rokov. Skutočne, nič sa nedá vyvrátiť tvrdením, že vizuálny Ganttov diagram je v podstate jednorazový. Nielenže práca na ňom trvá veľa času, takmer okamžite po začatí dizajnérskych prác sa kaskádový model vo väčšine prípadov ukáže ako zbytočný.

Dôvod je veľmi jednoduchý: mentálne konštrukcie z hľadiska obsahu a trvania operácií sa nikdy nezhodujú so skutočnými udalosťami projektu. Metodológia Scrum, ktorá je alternatívou k plánovaniu vodopádových projektov, ponúka flexibilný plánovací mechanizmus. Zvážime to trochu neskôr, ale zatiaľ si rozoberieme základné pojmy, na ktorých metóda Scrum funguje.

1. Vlastník produktu. Tento údaj je zodpovedný za to, že tímová práca prináša výsledok, ktorý prináša zisk (úžitok) spoločnosti. Musí sa dobre orientovať v podstate produktu, schopnostiach tímu a prioritách trhu.
2. Scrum majster. Metaforicky ide o veľmi zaujímavú rolu. „Vedúci sluhu“, „kapitán tímu“, „tréner-tréner“. Jeho hlavnou úlohou je viesť tím po ceste neustáleho zlepšovania, odstraňovania prekážok a príčin rušenia.
3. Scrum doska. Bežná kancelárska tabuľa rozdelená na časti: „nevybavené“, „do práce“, „v práci“, „na zváženie“, „hotovo!“. Po nej sa pohybujú nalepovacie nálepky s úlohami.
4. Kolekcia scrumu. Záverečné stretnutie na konci šprintu.
5. šprint. Časové obdobie od 1 do 4 týždňov, nastavenie pracovného rytmu tímu Scrum na vytvorenie novej funkcionality.
6. Stretnutia na cestách alebo denný Scrum. Krátke stretnutia projektového tímu na zodpovedanie otázok Scrum Mastera o výsledkoch, plánoch na daný deň a aktuálnych prekážkach.
7. Nevybavené veci (backlog). Zoznam aktuálnych požiadaviek-úloh na vytvorenie funkcionality produktu projektu.
8. Schéma vyhorenia úlohy. Graf znázorňujúci množstvo vykonanej a zostávajúcej práce na danej úlohe.
9. Fibonacciho sekvencia. Matematická zákonitosť vlastná povahe nášho vesmíru, pod ktorou funguje špeciálne poradie čísel. Táto postupnosť je dobre použiteľná pre alternatívny odhad trvania projektu vďaka použitiu takzvaného „plánovacieho pokru“. Nižšie je uvedený vizuálny model číselnej postupnosti.
10. Shuhari (Shu Ha Ri). Shuhari je jedným z konceptov japonských bojových praktík (napríklad aikido), ktorý bol zahrnutý do princípov metódy Scrum ako metafora pre možnosť postupného (iteratívneho) dosahovania dokonalosti projektovým tímom.
11. OODA. Princíp metódy Scrum pre cyklickú implementáciu: pozorovať, navigovať, rozhodovať, konať.

Fibonacciho sekvenčný model

Základný model metódy Scrum. Zdroj: Askhat Urazbaev. Stručný prehľad metodiky Scrum

Stručný popis procesu

Metodológia Scrum akoby ponorila štruktúru implementácie projektovej úlohy do dosť strnulého rytmu cyklických šprintov. Na rozdiel od štandardných projektových aktivít nie sú v metodike prvotným posolstvom pre plánovanie úlohy (aj keď projektová úloha nie je zrušená), ale príbehy a fakty, ktoré pomáhajú pochopiť hodnoty a potreby užívateľa, klienta projektu. produkt. Je potrebné pochopiť motívy, ktoré spôsobujú jeho potrebu produktu.

V klasickej projektovej činnosti sa táto práca robí v štádiu vypracovania projektovej charty, ale tam je to oveľa formálnejšie. Tu sa tvoria aj niektoré užívateľské príbehy, stručné a vhodné na následnú fragmentáciu. Upozorňujeme, že pri tradičnom rozklade dizajnérskych úloh dochádza k ich konečnému zotročeniu do podoby suchého jazyka jednoznačnosti. V metóde Scrum naopak dochádza k emancipácii – aby príbehy vytvárali hodnotný obraz o produkte projektu.

Implementácia projektu pomocou procesov Scrum pozostáva zo štyroch hlavných blokov.

1. Obsadenie rolí v tíme Scrum.
2. Tvorba artefaktov Scrumu.
3. Realizácia činnosti.
4. Reprodukcia cyklu Scrum.

Vizuálny model procesu metódy Scrum

Zloženie rolí v metóde Scrum je jednoduché: produktový vlastník, scrum master a tím. V rovnakom poradí sa do týchto úloh vyberajú ľudia. Ku klasickej úlohe projektového manažéra má najbližšie produktový vlastník, je zodpovedný za tvorbu a pravidelnú obmenu produktového backlogu. Po vytvorení backlogu projektový tím začne plánovať nadchádzajúci sprint. Zároveň sa „plánovací poker“ aktívne používa ako objektívnejší a vyváženejší nástroj založený na metóde Delphi a Fibonacciho postupnosti. Tým sa vytvorí lokálny backlog pre nadchádzajúci cyklus nového sprintu.

Artefakty scrumu v metóde sú chápané ako: produktové a sprint backlogy, projektový produkt s novou funkcionalitou. Každý sprint má za cieľ vytvorenie novej funkcionality produktu, aj keď mierny pokrok, ktorý sa však stane samozrejmosťou a bude ho možné prezentovať zákazníkovi projektu a ďalším záujemcom. V internom prostredí šprintérskeho cyklu tím funguje autonómne, sprevádzaný „stretnutiami za behu“ a pohyblivými nálepkami na Scrum boarde. Príklad vzhľadu dosky je uvedený nižšie.

Príklad scrum boardu

Zloženie atribútov dosky Scrum môže odrážať špecifické črty firemného prístupu k dizajnu. Okrem toho môžu byť zahrnuté grafy vyhorenia úloh, deklarácie cieľov sprintu atď. Po ukončení Sprintu sa konajú dve projektové podujatia: Sprint Review Meeting a Retrospective Meeting. Výstupom kontrolného stretnutia je produkt projektu s upravenou alebo úplne dokončenou funkcionalitou. Po retrospektívnej analýze sa objaví zoznam potrebných zlepšení v práci Scrum tímu. Cyklus sa uzavrie, produktový backlog sa upraví. Z nej sa „vytiahnu“ nové úlohy a proces sa spustí odznova.

Pripomienky k obsadzovaniu rolí

Jednou z monografií, s ktorou sa mi podarilo zoznámiť, bola kniha D. Sutherlanda, v ktorej je Scrum prezentovaný ako nič iné ako revolučná metóda projektového riadenia. Práca je plná mnohých príkladov z osobnej skúsenosti autora, úspešných dizajnérskych rozhodnutí a veľkých mien. Emocionálne zafarbenie argumentu je pôsobivé. Vo všeobecnosti je tento prístup tradičný pre severoamerickú metodickú školu. Napriek mierne mätúcej logike nie je pochopenie metódy návrhu zložité. Dobrá pomoc je v prílohe. Prvé tri kroky technológie sú celkom primerane venované rolám v tíme Scrum.

Krok 1 algoritmu metodológie Scrumu

Pri bližšom skúmaní sa závery-metafory uvedené ku každej časti metodiky ukázali ako veľmi účinné. Ďalej budú moje komentáre k častiam algoritmu postavené na princípe hľadania pozitívnych aspektov, ktoré odlišujú Scrum od tradičnej projektovej metodológie. Potom mám v úmysle formulovať otázky, ktoré vyvolávajú moje pochybnosti alebo vyžadujú riešenie pre ruské podmienky dizajnérskej praxe. Medzi pozitívnymi bodmi v prvom kroku metódy som videl:

• sémanticky kompetentná transformácia role projektového manažéra na produktového vlastníka, z pozície NLP precízne naprogramovanie lídra na výsledok projektovej úlohy;
• zoradenie zoznamu úloh (backlogu) projektu podľa hodnôt (pre klienta) a rizík;
• flexibilita pri akceptovaní zmien hodnoty produktu pre zákazníka projektu;
• bodovanie úloh a schopnosť nahradiť projektové úlohy počas prerozdelenia priorít a zastaviť sprint.

Krok 2 algoritmu metodológie Scrumu

Najcennejším metodickým posolstvom kroku 2 je podľa mňa „obviňovanie je hlúpe“. Bez námietok je akceptovaný aj „zlatý štandard“ veľkosti Scrumu tímu. Pre istý typ kultúry projektového tímu, ako je adhokracia alebo v inej klasifikácii participatívna, celkom súhlasím s princípom autonómie Scrum tímu. Všetky ostatné tézy kroku 2 sú univerzálne a identické s klasickým projektovým prístupom.

Krok 3 algoritmu metodológie Scrum

Prvých osem metafor pre ďalší krok Scrumu možno považovať za pravidlá pre podnikanie alebo akýkoľvek iný druh činnosti, vrátane projektov. Nedobrovoľne si kladiete otázku: prečo to v realite dizajnérskej praxe nevidíte? Myslím si, že na zodpovedanie je potrebné objasniť niekoľko ďalších bodov.

1. Ak „líder nie je šéf“, ale Scrum Master je „hráč-tréner“, potom kto riadi tím Scrum? Samoriadenie podľa mňa nezapadá do konceptu projektového manažmentu.
2. Vynára sa otázka motivácie produktového vlastníka projektu, Scrum Mastera a Scrum tímu. Metodika popisuje princíp otvorenosti informácií vrátane prístupu k finančným údajom projektu. Nie je to zlý nápad, ale vzhľadom na machiavelistický postoj, ktorý je prítomný v mnohých ruských spoločnostiach, bude mať takáto príležitosť medzi lídrami zrejme veľa odporcov.

Otázka vzniku artefaktov

Ďalšie štyri kroky algoritmu metódy Scrum sú venované tvorbe a práci s modelovými artefaktmi. Budeme nimi rozumieť informácie a hmotné predmety, ktoré slúžia ako východisko pre určitú etapu činnosti, činnosti vedúce k medzivýsledku alebo konečnému výsledku projektu. Krok vytvorenia produktového backlogu je pozoruhodný svojimi vlastnosťami.

Hlavným je, že tento zoznam požiadaviek Scrumu sa nepovažuje za niečo jednorazové a neotrasiteľné. Produktový backlog prechádza dynamickým prehodnotením zakaždým po skončení sprintu. A to je podľa mňa veľmi cenné. Z vlastnej skúsenosti môžem povedať, že takýto mechanizmus v klasickom modeli projektového riadenia chýba.

Krok 4 algoritmu metodológie Scrumu

Piaty krok algoritmu Scrum je nemenej zaujímavý. Absolútne sa nechcem ponoriť do mystických aspektov čísel. Máme však obyčajnú pragmatickú úlohu: čo najlepšie predpovedať trvanie projektu pomocou čo najobjektívnejšieho odborného posúdenia. Žiaľ, „veštenie“ odpisovaním hodín v MS Project nie je nič nudnejšie a vyčerpávajúce, a to ani pri zapojení skúsených odborníkov. Môžem s istotou prehlásiť, že som sa v projektovej praxi nikdy nestretol s lepšou metódou ako „plánovanie pokru“. Metóda je všeobecne známa, preto sa jej nebudeme venovať. Poznamenám len, že kombinácia Delphi metódy a Fibonacciho sekvencie dáva úžasné výsledky.

Solitaire Príklad metódy plánovania pokru

Existuje niekoľko dôvodov, prečo metódu Scrum považovať nie za ladenie modernej PM doktríny, ale za skutočne revolučnú metódu projektového riadenia. Jedným z nich je postoj k popisu práce na realizácii projektovej úlohy z pohľadu príbehov, ktorý je opačný ako procesný prístup D. Champiho a M. Hammera. Ľudia skutočne myslia v obrazoch. Na jednej strane je ťažké súhlasiť s tým, že sa nemožno obávať straty jednoznačnej interpretácie výsledku práce. Na druhej strane, ak ustúpite od tlaku úloh a pozriete sa na problém z pozície skutočnej orientácie na klienta projektu, soft stories môžu urobiť viac pre dosiahnutie správnych výsledkov úlohy.

Krok 5 algoritmu metodológie Scrumu

Pri pohľade na kroky 5 a 6 nie sú pochybnosti o mechanizmoch na výpočet dynamiky výkonu, backlogu sprintu, dátumoch dokončenia projektu a možnosti zrýchlenia. Všetko je celkom zrejmé. Ťažkosti s porozumením vznikajú v súvislosti s jednou otázkou: ako na konci každého sprintu dosiahnuť vizuálne zvýšenie funkčnosti produktu? Pokiaľ ide o projekty vývoja softvéru, je to celkom možné. Ako je to však napríklad pri realizácii projektu zavedenia systému rozpočtovania metódou Scrum, kde je veľa fáz prípravných prác, pri ktorých nedochádza k viditeľnému zvýšeniu funkčnosti? Zdá sa, že táto časť metódy vyžaduje dodatočné ponorenie.

Krok 6 algoritmu metodológie Scrumu

Problémy aktívnej akcie v procese

Tretím procesným blokom metódy Scrum je realizácia aktivít. Aktivity máme na mysli kroky produktového vlastníka, Scrum Mastera a celého Scrum tímu na dosiahnutie lokálnych výsledkov aktuálneho sprintu alebo projektu ako celku. Siedmy krok procesu návrhu je kontroverzný. Na jednej strane hovoríme o celkom fungujúcich nástrojoch kolektívnej práce, poskytujúcich vysokú publicitu, komunikačnú plnosť, viditeľnosť. Hovoríme o použití Scrum dosiek, nálepiek, tabuliek vyhorenia úloh. Na druhej strane, nielen pre mňa, ale aj pre mnohých ruských manažérov je dosť ťažké vnímať kategóriu šťastia ako prvok manažérskej technológie. Tejto problematike budem venovať celú časť článku.

Krok 7 algoritmu metodológie Scrumu

Za jedno z jasných zistení metódy Scrum považujem techniku ​​denných stretnutí na cestách. Veľmi výstižný a účinný prostriedok interakcie a motivácie projektového tímu v rámci sprintu. Veľký športovec 20. storočia, Mohammed Ali, prikladal veľký význam pravidelnému rituálu úspechu v akomkoľvek podnikaní. Daily Scrum Meeting má byť tým silným pravidelným rituálom, ktorý poháňa konsolidáciu tímu na krátky čas. Podpora koučingu, jednotný teritoriálny priestor, absencia rozdelenia podľa „hodností a hodností“ – to všetko funguje tak, aby Scrum tím konal s urýchlením implementácie projektu.

Krok 8 algoritmu metodológie Scrumu

V kroku 9 algoritmu metódy Scrum sa objaví to, čo vás znepokojuje a opäť sa vráti k formulácii úloh pre sprint. Dlhé roky som si musel pestovať presvedčenie, že z úlohového kontextu projektového manažmentu vyplýva jednoznačnosť formulácie výsledku v zmysle „dosiahnuté – nedosiahnuté“. Nezáleží na tom, ktorý výsledok sa berie do úvahy: úloha najvyššej úrovne alebo rozložená úloha. V každom prípade by mal byť riaditeľ projektovej úlohy a zodpovedný zdroj zbavený možnosti manipulovať s vágnosťou formulácie.

Krok 9 algoritmu metodológie Scrumu

Cyklus šprintu končí desiatym krokom, ktorým je peer review dokončeného šprintu. Pri vyhodnocovaní postupu prác na úlohách a hľadaní zlepšení sa opäť zapína koučovací režim interakcie so Scrum tímom. Ruskú mentalitu vždy charakterizujú hodnotové súdy s negatívnou konotáciou neúspešných výsledkov a porúch. V tomto prípade by mal byť vždy určený „prepínač“ – člen projektového tímu, vinou ktorého k stratám došlo. O to cennejšie sú princípy nadradenosti systémovej chyby pred konaním účastníkov procesu Scrumu ako subjektov projektovej činnosti a odmietnutie personifikácie viny.

Krok 10 algoritmu metodológie Scrum

Scrum ako kódex anticynizmu

Páči sa mi metafora uvedená v podtitulku. Patrí Jeffovi Sutherlandovi a je v ňom cítiť hlboký cynizmus ako významnú neresť moderného biznisu. Vo všeobecnosti je postoj autora metódy Scrum určite úprimný. Je to podmanivé. A v zásade nie je vôbec zlé, že Sutherland vnáša do manažérskeho kontextu zložku šťastia. Robí sa to americkým spôsobom. Zároveň by som rád pochopil, prečo slovo „šťastie“ a všetko s ním spojené v uvažovanej revolučnej doktríne dizajnu vyvoláva vnútorné nepohodlie. Ide len o subjektívno-osobné vnímanie, alebo ide o nejaký všeobecný kultúrny pohľad na navrhovaný prístup?

Vy a ja si s najväčšou pravdepodobnosťou pamätáme, čo sa stalo v Rusku koncom 90. a začiatkom 20. storočia. Krajina bola doslova zaplavená „novým bohatstvom“ z celého sveta a hlavne zo Spojených štátov, ktoré vysielali „pravdu“ o osobnom a firemnom úspechu. Treba úprimne povedať, že takéto „odhalenia“ neprešli bez stopy, mnohí biznismeni si osvojili kľúčové aspekty manažérskych teórií prinesených zo Západu. Konkrétne nemenujem vzdelávacie kurzy, autorské teórie a významné školy. Kto ich zažil, pochopí.

70 rokov sovietskej moci výrazne zmenilo vnútornú kultúru ľudí, ale genetický kód ruskej osoby sa úplne nestratil, pretože sa formoval v priebehu storočí. Keď sa však otvorili najširšie možnosti komunikácie a obchodných vzťahov, prirodzené filtre obchodníkov a manažérov sa narušili. A mnohé myšlienky boli prijaté ako axiómy, zatiaľ čo princípy elementárnej múdrosti sa neuplatňovali. To sú náklady na medzičas, ktorý sa teraz končí.

Na štátnej úrovni aj na úrovni podnikateľov dochádza k rýchlemu vytriezveniu. A začínajú chápať, že niektoré zavedené riešenia, spôsoby podnikania, budovanie vzťahov so zamestnancami sú nielen užitočné, ale slúžili nepriateľským a deštruktívnym účelom, čo viedlo k rozpadu našej národnej kultúry, vrátane kultúry riadenia. Uvediem jeden jediný príklad protikladu dvoch ideológií: "Rozdeľuj a panuj!" a "Slovo obchodníka je cennejšie ako zmluva!".

Toto vytriezvenie je dôvodom veľmi obozretného postoja k vnucovaniu zdroja šťastia ako prostriedku kontroly. V ruskej tradícii so stáročnou komunitou, ortodoxnými a islamskými koreňmi sa „šťastie“ vzťahuje na vysoko duchovné, cnostné kategórie. Nemožno ho neuvažovať komplexne z hľadiska morálneho aspektu, z hľadiska psychického stavu, z hľadiska intelektuálneho chápania, fyzického a duchovného povznesenia.

Vyššie uvedené neznižuje výhody metódy Scrum, o ktorej sa hovorí v článku. Ak odstránite závoj absolutizácie, podceňovania a nejakého pátosu, je to celkom funkčný nástroj pre dizajn. Nové je vždy ťažké nájsť cestu. Najprv sú to vysoké myšlienky, potom sú to izolované príklady a nakoniec prichádza obdobie masového prijímania. Zdá sa, že budúcnosť patrí hybridným algoritmom na realizáciu projektových aktivít a flexibilnej variabilite využívania tradičných a revolučných prístupov.