Etapy agilního vývoje. Co je Agile? Na začátku tým zkoumá realitu vývoje aplikací a rozsah. Další práce je rozdělena do tří na sebe navazujících cyklů

Agile („agilní“) je slovo, které v poslední době zní z každého železa. Ale co je Agile a hlavně proč je tento Agile potřeba?

Pokud je otevřeno slovník, například Oxford, pak si tam můžete přečíst alespoň dvě definice:

1. Schopný rychle a snadno se pohybovat.
2. Umět rychle myslet a rozumět.

To znamená, že abyste byli agilní, musíte se umět rychle a snadno pohybovat a rychle přemýšlet. Zdá se, že jsou to docela užitečné vlastnosti, zejména v podnikání. Rychle myslet a rychle reagovat je přesně to, co lékař nařídil pro naši dobu, jinak prostě nepřežijete: konkurenti vás sežerou. Na světě je stále méně průmyslových odvětví, kde tito konkurenti neexistují. Navíc rychlost kopírování prakticky znemožňuje uvést produkt na trh a usnout na vavřínech. Bez schopnosti rychle se přizpůsobit změnám, kterou dává tzv. „Agilní metodologie“, je stále obtížnější přežít.

Ne náhodou beru výraz „Agilní metodika“ v uvozovkách, protože to můžete často slyšet, ale není to úplně správné. Pokud nezacházíte do technických detailů, pak Agile není metodika, ale souhrnný název pro různé metody a přístupy k řízení, které:

1. Zaměřte tým na potřeby a cíle klientů.
2. Zjednodušte organizační strukturu a procesy.
3. Nabízejí práci v krátkých cyklech.
4. Aktivně využívat zpětnou vazbu.
5. Dochází ke zvýšení pravomocí zaměstnanců.
6. Jsou založeny na humanistickém přístupu.
7. Nejsou konečným stavem, ale spíše způsobem myšlení a života.

Nic nadpřirozeného, ​​že? Pojďme bod po bodu a podívejme se, proč je výše uvedené důležité, abychom byli rychlí a agilní, a jak Agile těchto cílů dosahuje.

Zaměřte se na potřeby a cíle zákazníků

Myslím, že nemá cenu vysvětlovat, proč je nejúspěšnější podnik, který uspokojuje potřeby svého klienta lépe než konkurence. Je zajímavější pochopit, jaké nástroje v Agile toho pomáhají dosáhnout.

A co je nejdůležitější, zaměření na klienta se u Agilního přístupu neobjevuje pouze v hlavě majitele firmy (tam již existuje), ale u každého, kdo pracuje na tvorbě produktu nebo služby. Každý účastník procesu musí rozumět tomu, kdo je klient, co chce, jaké problémy s naším produktem řešíme, co miluje, čeho se bojí a podobně. Takové globální zaměření umožňuje vytvářet řádově lepší řešení. Opakovaně jsem se setkal se situací, kdy lidé, kteří byli dříve zodpovědní za nějaký malý kus práce, když pochopili cíle klienta, začali rozdávat skvělé nápady a lidé, kteří jsou zodpovědní za vývoj produktu, si překvapeně zapisovali. Nebo - jak se takové nápady pilují na sezeních skupinového vývoje produktů odlišní lidé a vzájemně se doplňují, od prostě dobrých po vynikající. A samozřejmě, jak jsou následně realizovány.

„Nástroje práce“ jsou v tomto případě krátké, ale intenzivní sezení (setkání) všech účastníků práce nebo klíčové většiny, kde se generují a testují různé nápady. Tyto stejné schůzky slouží k dosažení úrovně porozumění a zaměření: všichni účastníci výstupní schůzky chápou, co dělají, proč a proč je to pro klienta důležité. A demokratický formát workshopu na rozdíl od nudných prezentací zaručuje větší zapojení a motivaci všech účastníků.

Příklady takových nástrojů jsou Lean Canvas, Impact Mapping, User Story Mapping a další agilní metody pro popis hypotéz a procesů.

Jedním ze základních kamenů Agile je extrémní jednoduchost. A organizační struktura organizace a procesy, kterými lidé pracují, a pravidla by měly být co nejjednodušší. To lidem umožní soustředit se na svou práci, na hodnotu, kterou vytvářejí, a ne na dodržování předpisů a pravidel. Skvělé příklady tohoto přístupu lze nalézt v mnoha týmech pracujících na Scrumu, nejoblíbenějším způsobu organizace workflow v Agile. Ve skutečnosti se všechny dohody a pravidla týmu 10-11 lidí, aktuální úkoly na pár týdnů, cíle i strategické plány snadno vejdou na 2-3 listy papíru A0. Na jednom listu může být takzvaný „sprint backlog“, seznam všeho, co se tým chystá udělat v další iteraci. Pokud si jeden pověsíte v místnosti, kde pracujete, můžete si ušetřit námahu s zapamatováním si toho všeho. Totéž platí pro procesy. Například ve Scrumu jsou místo a čas všech setkání pevně stanoveny. Každý účastník jistě ví, že například v pondělí v 10-00 je plánována další iterace a v pátek v 17-30 - schůzka ke zlepšení pracovního procesu.

A čím větší je organizace, tím větší je výhoda takové jednoduchosti, protože složitost má tendenci exponenciálně růst a Agile je dobrá cesta porazit tuto složitost nebo alespoň omezit její růst.

Příklady zjednodušení (a zploštění, ale to je téma na jinou diskusi) v Agile jsou Scrum, Nexus, LeSS (Large-Scale Scrum nebo Scrum ve velkém měřítku), stejně jako samotný projev Agile.

V Agilním světě není zvykem zavřít se na tři roky do dílny, abyste tam něco zajímavého nabrousili. Riziko je velmi velké, strávit moře síly a času něčím, co nikdo nepotřebuje nebo je zastaralé.

Aby se tomu zabránilo, používá se takzvaný iterativní-inkrementální přístup, když:

• práce je vykonávána v malých pevně stanovených časových obdobích, například v jednom, dvou nebo čtyřech týdnech,
• a co je nejdůležitější, na konci každého časového úseku nevznikne jen jakýsi mezivýsledek, ale, byť malý, osekaný, sporý, ale pracovní verze produktu, který můžete začít používat.

Jako nejjednodušší příklad takového pracovního modelu si můžeme představit programový standard „kalkulačka“ pro všechny počítače, který nejprve umožňuje pouze sečíst dvě čísla, poté přidáme odčítání, násobení, dělení, transcendentální čísla, goniometrické funkce a tak dále, v pořadí podle frekvence používání. Na začátku je funkcionalita malá, ale už vidíme, jak kalkulačka vypadá, jak pohodlně se používá a představujeme si, jak ji dále rozvíjet. A co je nejdůležitější, někteří klienti (řekněme školáci základní škola) jej již můžete začít používat.

Další výhodou tohoto přístupu, kromě brzkého vstupu na trh a provádění změn v raných fázích práce, je možnost přesněji měřit pokrok. Neudělali jsme jen „15 % práce“, což je dost abstraktní. „Udělali jsme 15 % funkčnosti“, která již funguje.

Všechno procesní přístupy v Agile mají krátké cykly, ať už se jedná o dříve zmíněný Scrum, Nexus, LeSS, SAFe nebo plus nutnost pracovat s takovými cykly je zmíněna v samotném Agile manifestu.

Aktivní, systémové využití zpětné vazby

Tento bod je podle mého názoru pro každý proces nejdůležitější, protože umožňuje práci v průběhu času na základě zkušeností upravovat, odstraňovat chyby a ztráty z procesu i vytvářeného produktu a přidat něco užitečného.

V jakékoli oblasti lidské činnosti související s tvorbou něčeho nového najdete podobné pracovat prostřednictvím experimentu. Raketa, letecké inženýrství, farmacie, fyzika, medicína, stavebnictví, psychologie, ekonomie - jakákoli oblast činnosti začala experimenty a promyšleným zpracováním zpětná vazba od nich.

Agile nabízí systematické využití tohoto přístupu všude: při vytváření produktu (uvádíme jej na trh, ukazujeme zákazníkovi, provádíme testy a využíváme zpětnou vazbu k nápravě), při budování procesů (periodicky „zastavujeme“ práci a analyzovat samotný proces, zlepšit jej, zbavit se ztrát a problémů), a to i při budování struktury organizace a dolaďování vztahů v týmech.

Příklady jsou opět všude: retrospektivní setkání ve Scrumu, Kanbanu, Nexus a LeSS, I&A cykly v SAFe, designový přístup k vytváření produktů atd.

Proč dávat více pravomocí, když můžete dát kus papíru s pokyny? Existují minimálně tři důvody, proč to udělat.

Za prvé, lidé zabývající se duševní prací se neradi cítí jako opice (no, nebo roboti), a tím, že člověku odebíráme schopnost rozhodovat se, odebíráme mu duševní práci jako takovou. A to je rozhodně demotivující.

Za druhé tím, že dáváme více pravomocí, dáváme více odpovědnosti a lidé jsou nuceni učit se rozhodovat sami a hlavně za ně nést odpovědnost. Je to dlouhé, těžké, ale stojí to za to. Práce se nezastaví, pokud samoorganizovaný tým narazí na neznámý, dříve neznámý problém. A kdo bude tvrdit, že v práci jsou zralí a zodpovědní dospělí užitečnější než velké děti, které nejsou schopny samostatně myslet?

Za třetí, je to stále stejná rychlost. Pokud člověk může vyřešit problém sám, na svém místě, aniž by se kohokoli ptal, zkracuje to čas na rozhodování. Už žádné posílání otázky „nahoru“ a čekání na odpověď od vedení. Tato výhoda není tak patrná, pokud máte 3 pracující, ale pokud jich máte 30, nebo 300 nebo 3000... Ve velkých organizacích postavených na čistě hierarchickém rozhodování může být paralýza vůle zcela běžná.

Populární způsoby budování práce v Agile, zejména ty založené na frameworku Scrum, zahrnují systém samostatně organizovaných týmů a podporují vedení na všech úrovních.

Proč se chovat k lidem jako k lidem? To znamená, že morální stránka věci je jasná, ale jaký užitek to přinese majiteli podniku?

Odpověď je docela jednoduchá. Pokud vytváření toho, co prodáváte, nevyžaduje duševní práce, ale pouze mechanické akce - nemůžete se obtěžovat. Stačí zaplatit podle odvedené práce a je to. Jakmile ale vstoupí do hry mozek pracovníků, budete muset počítat s principy motivace duševní práce. A pro lidi je prý důležitá možnost seberealizace, zlepšení dovedností, přivedení něčeho hodnotného na svět, samostatnost v rozhodování a řada dalších faktorů. A motivovaný člověk (neplést se stimulovaným!) bude do práce více investovat a výsledek bude lepší a rychlejší. A vůbec, příjemná atmosféra v práci přidává chuť přijet tam pracovat – s tím taky těžko někdo může polemizovat.

A co je hezké, když zabrousíte do stejného Scrumu, ukáže se, že všechny klíčové faktory pro motivaci pracovníka mentální a/nebo kreativní práce jsou v něm již zahrnuty. V každé iteraci („sprint“) si stanovíme cíl, kterého chceme dosáhnout; dostáváme možnost rozhodnout se, jak přesně cíle dosáhneme; na konci se podíváme na to, jak moc jsme se zlepšili (nebo zhoršili) pracovat než dříve; vidíme lidi, kteří se zajímají o produkt a jejich emoce z jeho poznávání. Je obzvláště dobré, pokud jsou tyto emoce pozitivní.

Závěr je: šťastní lidé fungují lépe a agilní technologie pomáhají zavést proces, ve kterém se lidé cítí šťastnější. A první bod manifestu je právě o tomto: lidé a to, jak komunikují, jsou důležitější než cokoli jiného.

Agile není konečný stav, ale způsob myšlení a života

Tento bod je o tom, jak Agile je obecně cestou, nikoli cílem. Nemůžete „implementovat“ Agile a relaxovat. Zvolíte-li tuto cestu, budete mít vždy co dělat lépe, nějakou další výzvu, na kterou je třeba odpovědět, nějaký jiný problém, který musíte vyřešit, jinou výšku, kterou musíte zdolat... Toto je pohyb. donekonečna, protože neexistuje žádný ideální proces nebo produkt, vývoj a konkurence se nikdy nezastaví, stejně jako nikdy nekončí boj o přežití v přírodě.

A pokud se vše povedlo: lidé ve firmě chápou a sdílejí hodnoty a principy Agile a pracují podle nich, pak management nebude muset „tahat“ žádné změny nebo „nakopat“ zaměstnance, aby začali něco dělat jinak. Podnik se stane jediným organismem, jehož řízení bude vyžadovat méně úsilí a přinese více potěšení.
A kde je větší radost z práce a výsledek je vyšší. To platí nejen pro specialisty, ale i pro management, a to v ještě větší míře.

Každý, kdo se někdy zabýval projektovým řízením, ví, jak těžké je zorganizovat sehranou práci týmu a při neustále se měnících požadavcích na výsledek projektu může vyjít veškeré vynaložené úsilí vniveč. Agilní metoda projektového řízení je pro práci s takovými projekty ideální.

Agilní metoda projektového řízení je série pracovních fází definovaných tvrdými termíny – sprinty, umožňující týmu neustále vyhodnocovat výsledky odvedené práce a získávat zpětnou vazbu od zákazníka a ostatních účastníků projektu. Tento přístup vám umožňuje provádět okamžité změny produktu, když se objeví nové požadavky.

Historie Agile

Evoluční projektové řízení a adaptivní vývoj software se objevil na počátku 70. let 20. století. V roce 1970 představil Dr. Winston Royce článek nazvaný „Řízení vývoje velkých softwarových systémů“, který byl kritický vůči sekvenčnímu vývoji. Tvrdil, že software by se neměl vyvíjet jako auto na montážní lince, kde se každá část přidává v postupných fázích. V těchto po sobě jdoucích fázích musí být každá fáze projektu dokončena, než může začít další fáze. Dr. Royce doporučil použít postupný přístup, kdy vývojáři nejprve shromáždí všechny požadavky projektu a poté dokončí celou jejich architekturu a design, poté napíší veškerý kód a tak dále.

V 90. letech 20. století byla vyvinuta řada agilních metod vývoje softwaru v reakci na převládající těžké metody. Patří mezi ně: od roku 1991 - RAD (rychlý vývoj aplikací); od roku 1994 - Metoda vývoje dynamických systémů (DSDM); od roku 1995 - Scrum; Od roku 1996 Crystal Clear and Extreme Programming (XP); A od roku 1997 - Vývoj řízený funkcemi (FDD). Přestože vznikly před zveřejněním Manifestu vývoje agilního softwaru, souhrnně se označují jako Agile Software Development.

V únoru 2001 se sedmnáct softwarových vývojářů sešlo v Snowbird Resort v Utahu, aby prodiskutovali lehké vývojové techniky. Společně vydali Agilní manifest.

Agilní manifest

Agile Manifesto se skládá ze 4 základních myšlenek a 12 principů. Každá agilní metodika aplikuje tyto myšlenky odlišně, ale všechny na ně spoléhají, aby řídily projekty co nejefektivněji.

4 agilní nápady

1. Lidé a interakce jsou důležitější než procesy a nástroje.
2. Funkční software je důležitější než dokumentace.
3. Spolupráce s klienty je důležitější než vyjednávání podmínek smlouvy.
4. Ochota provádět změny přednostně než se držet původního plánu.

12 principů Agile

1. Spokojenost zákazníků díky včasnému a nepřetržitému dodávání softwaru. Zákazníci jsou šťastnější, když dostávají funkční software v pravidelných intervalech.
2. Provádějte změny požadavků na produkt během procesu vývoje.
3. Časté dodávky funkčního softwaru (každý měsíc, čtrnáct dní, týdně atd.).
4. Spolupráce mezi stakeholdery (zákazníkem a vývojáři) v průběhu celého projektu.
5. Podpora, důvěra a motivace zúčastněných lidí. Motivované týmy s větší pravděpodobností splní své nejlepší práce než zaměstnanci nespokojení s pracovními podmínkami.
6. Interakce z očí do očí. Komunikace je úspěšnější, když jsou vývojové týmy schopny komunikovat přímo.
7. Funkční software je hlavním měřítkem pokroku. Dodání funkčního softwaru klientovi je konečným faktorem, který měří pokrok.
8. Udržování stálého pracovního tempa. Týmy vytvářejí opakovatelnou a udržitelnou rychlost provozu, při které mohou dodávat fungující software.
9. Pozor na technické detaily a design. Správné dovednosti a dobrý design umožnit týmu udržet dynamiku, neustále zlepšovat produkt a pracovat na změnách.
10. Jednoduchost.
11. Samoorganizující se týmy podporují vynikající architekturu, požadavky a návrhy. Kvalifikovaní a motivovaní členové týmu, kteří mají pravomoc rozhodovat, pravidelně komunikují s ostatními členy týmu a vyměňují si nápady, které zajistí vytvoření kvalitního produktu.
12. Neustálé přizpůsobování se měnícím se podmínkám, které pomohou učinit produkt konkurenceschopnějším na trhu.

Základ agilní metody

Základem agilní metody řízení projektů je řada klíčových prvků:

1. Vizuální kontrola. Účastníci projektu při práci na projektu používají kartičky různých barev a typů, které signalizují, který prvek výsledného produktu je již vyvinut, naplánován, dokončen atd. Tým má vizuální představu o aktuálním stavu věcí. Vizuální kontrola zajišťuje stejnou vizi projektu každým z účastníků.
2. Všichni účastníci projektu pracují vedle sebe, včetně klienta. Tento přístup řadu procesů spojených s informováním členů pracovní skupiny nejen zrychluje, ale také vytváří příznivá atmosféra za spolupráci a efektivní práci.
3. Adaptabilní management. Projektový manažer není člověk, který dává pokyny, ale vedoucí, který určuje základní pravidla práce a spolupráce.
4. Spolupráce. Tým, projektový manažer a klient spolupracují, což eliminuje možnost ztráty informací a nepochopení cílů. Transparentnost všech procesů také umožňuje okamžitě eliminovat vznikající problémy a nacházet úspěšná řešení a zlepšení.
5. Práce založená na rozdělení celkového rozsahu projektu na jednotlivé části. Tento systém práce výrazně snižuje složitost projektu a umožňuje týmům soustředit se na každou část zvlášť.
6. Pracujte na chybách. Během práce jednoho cyklu se tým učí novým dovednostem a analyzuje vzniklé chyby, což vylučuje jejich výskyt v dalším cyklu.
7. Sprinty a denní setkání. Sprinty – časové úseky, během kterých týmy plní řadu úkolů – vám umožní jasně vidět výsledky práce. Rozdělením doby práce na projektu do sprintů nám vyjde např. 10 sprintů, každý na dva týdny. A každodenní schůzky ne delší než 15 minut pomohou každému členovi týmu zodpovědět si za sebe tři otázky: co jsem dělal včera, co budu dělat dnes, co mi brání v práci?

Tedy úvod flexibilní metoda Agilita je možná za následujících podmínek:

• je jasně uveden smysl projektu,
• klient je aktivně zapojen do celého projektu,
• možná postupná realizace celého rozsahu projektu,
• výsledek práce je důležitější než dokumentace,
• pracovní skupina nemá více než 7-9 osob.

Na tento moment Agilní metodika je rozšířena v oblasti IT a začíná si osvojovat obchodní oblast, zejména marketing, management, školení atd. Metodu agilního projektového řízení využívá mnoho společností a vládních agentur, například vlády Norska a Nového Zélandu Zéland používá Agile. V Rusku ovládá Sberbank Agile pro komerční sektor.

Systémy projektového řízení založené na Agile

Existuje mnoho metod založených na myšlence Agile, nejoblíbenější z nich jsou Scrum a Kanban.

SKRUMÁŽ

Scrum je metodika projektového řízení, která se zaměřuje na kontrolu kvality pracovního procesu. Hirotaka Takeuchi a Ikujiro Nonaka, první, kdo popsali Scrum přístup, jej vysvětlili jako „ragbyový přístup“, ve kterém scrum bojuje o míč. Samotná metoda je vývojový proces rozdělený do malých iterací – sprintů, na jejichž konci uživatelé obdrží vylepšenou verzi softwaru. Sprint je pevně fixován v čase a jeho trvání je od 2 do 4 týdnů. Práce v rámci jednoho sprintu se skládá z několika fází:

1. Plánování rozsahu práce na jeden sprint.
2. Každodenní schůzky po dobu 15 minut pro korekci práce týmu a shrnutí průběžných výsledků.
3. Ukázka výsledků práce.
4. Retrospektiva sprintu hodnotící úspěchy a neúspěchy posledního sprintu.

Scrum se nejčastěji používá ke správě komplexního vývoje softwaru a produktů pomocí iteračních a inkrementálních metod.

Scrum výrazně zvyšuje produktivitu a zkracuje čas, což je výhoda oproti klasickým „vodopádovým“ procesům. Scrum procesy umožňují organizacím bezproblémově se přizpůsobovat rychle se měnícím požadavkům a vytvářet produkt, který splňuje měnící se obchodní cíle. Scrum vám umožňuje:

• zlepšit kvalitu výsledků;
• Lepší se vypořádat se změnou;
• Poskytovat přesnější odhady a trávit méně času jejich vytvářením;
• Je lepší řídit scénář projektu a fáze práce.

Kanban

Kanban je proces navržený tak, aby pomohl týmům efektivněji spolupracovat. V japonštině kanban znamená „ plakátovací tabule, vývěsní štít“, a samotná metoda je převzata a upravena produkční systém Toyota. Podstatou Kanbanu je maximálně zprůhlednit vývojový proces a rovnoměrně rozložit zátěž mezi členy týmu. Kanban podporuje neustálou spolupráci a podporuje aktivní, neustálé učení a zlepšování.

Kanban je založen na třech principech:

1. Vizualizace úkolů: viditelnost všech informací o projektu pomůže vidět nedostatky, chyby a překryvy.
2. Kontrola a omezení WIP (probíhající práce): To pomáhá vyvážit přístup vláken, takže týmy nezačínají a nedělají příliš mnoho práce najednou.
3. Kontrolujte čas na dokončení úkolu a optimalizujte práci, abyste ušetřili čas.

Výhody a nevýhody Agile

Každá metoda má své výhody a nevýhody. Zvažte výhody a nevýhody Agile.

Výhody

1. Větší flexibilita ve srovnání s metodikou Waterfall.

Tradiční metodika vodopádu jasně diktuje fáze práce. U agilní metodiky jsou hlavními určujícími faktory harmonogram a náklady, což je oblast, která se mění, aby vyhovovala požadavkům zákazníků a spotřebitelů produktu.

2. Méně vad v konečném produktu.

Je to výsledek kontroly kvality prováděné v každé fázi práce. Nepřetržitý proces„develop, build, and test“ také redukuje defekty, protože iterační cykly pokračují.

Nedostatky

1. Neustálé přijímání zpětné vazby vede k neustálému odkládání termínu dokončení projektu.

S okamžitou zpětnou vazbou, kterou Agile poskytuje, existuje nebezpečí dlouhá práce. Koncoví uživatelé, kteří vidí, že tyto požadavky lze splnit „snadno“ (vidí pouze výsledek, nikoli snahu), budou požadovat další funkce. Pokud projektový manažer a vývojáři nezvládnou očekávání, koncoví uživatelé budou stále žádat více, dokud nebude celý tým zatížen prací navíc.

2. Dokumentace

Vzhledem k flexibilní povaze Agile musí dokumentace sledovat rychle se měnící podmínky projektu. Požadavek na změnu nebo funkci by mohl být podrobně prodiskutován a odsouhlasen s koncovými uživateli, vývojáři a testery, ale pokud tým nebyl informován, může být předložen kritický dokument, jako je uživatelská příručka, dokument o architektuře nebo funkční požadavek, stane se zastaralým.

3. Častá setkání

Zatímco Agile doporučuje, aby se tato setkání konala denně, aby se všichni navzájem informovali o pokroku, udržitelnost této praxe si vybírá daň na postupu iterací. Vývojáři se soustředí na to, co dělají. Vytáhnout je na schůzku, která by je mohla odvést od činnosti skutečná práce, není něco, co rádi přijmou.

Agilní implementace

1. Volba metodiky. Existují různé flexibilní metodiky, které jsou vyvíjeny za určitých podmínek. Prvním krokem při práci s Agile je určit si cíle pracovního úkolu, termíny, počet zaměstnanců a mnoho dalšího a zvolit takovou flexibilní metodiku projektového řízení, která bude splňovat všechny požadavky.
2. Výcvik.Školení je nezbytné, aby zaměstnanci pochopili základní principy Agile a věděli, jak s nimi pracovat. Právě v této fázi jsou identifikována úskalí, která lze snížit Agilní efektivita. Je tým připraven na změnu? Jsou projekty společnosti vhodné pro agilní praktiky? Na tyto a mnohé další otázky obvykle odpoví agilní obchodní koučové. Mimo jiné bude také vypracován seznam školení a plán, podle kterého bude implementace Agile ve firmě probíhat.
3. Agilní demo. Jakási agilní testovací jízda, která se provádí pod dohledem specialisty a ukazuje všechny fáze práce, vysvětluje funkce rolí, interakci v týmu a mezi týmy atd.
4. Vytvoření týmu. Součástí tvorby týmu je kromě výběru zaměstnanců také definice odpovědností, rozdělení úkolů, tvorba zasedacího pořádku atp. Každá metoda je určena pro určité množstvíčlověk v týmu.
5. Výběr nástroje nezbytné pro distribuci úkolů, reporting, analýzy a další.
6. První projekt s Agile. V prvním projektu budou chyby, nekonzistence, odmítnutí některých nástrojů a výběr jiných. Jakákoli technika vyžaduje určitý druh přizpůsobení charakteristikám společnosti, ve které je implementována.

Pokud najdete chybu, zvýrazněte část textu a klikněte Ctrl+Enter.

Je těžké najít člověka, který by nechtěl, aby se s ním jednalo s respektem. Tento stav ale musí mít svůj důvod. Například, když je člověk vysoce kvalifikovaným uznávaným specialistou v oblasti vývoje softwaru. A k tomu je třeba studovat. A v rámci tohoto článku se zamyslíme nad tím, co je Agile, k čemu slouží a jak této technologii porozumět.

obecná informace

Nejprve se vypořádejme s technickými problémy. Co je Agile? Překlad (doslovný) tohoto slova z anglického jazyka- „živý, mobilní“, „flexibilní“ se uvádí o něco méně často. A mimochodem, je to zkratka. Celý název tohoto přístupu je Agilní vývoj softwaru. Ale protože je příliš dlouhá, bylo rozhodnuto ji ustřihnout. A teď říkají jen Agile. Překlad jako "flexibilní" se používá proto, že nejvíce odpovídá skutečné situaci.

Co je zde zahrnuto?

Nadále zvažujeme, co je Agile. Zde se chci zaměřit na to, že se jedná o flexibilní přístup, který je založen na mnoha různých XP, „Kanban“, Lean). Abychom lépe porozuměli tématu, uveďme paralely. Řekněme, že agilní technologie jsou procesem zrodu Vesmíru. Konečným produktem je samotný skutečný svět. A velký třesk je nejbolestivější problém, kterému musíte čelit – změna seznamu požadavků na produkt. Procesy tvorby obvykle zahrnují použití model vodopádu. V tomto případě jde vše postupně a po etapách. Tento přístup lze vyjádřit stručně: Vidím cíl – jdu k němu. A pokud se požadavky na konečný výsledek změní, musíte někdy téměř vše předělat znovu. Co tuto situaci dále komplikuje, je snaha předstírat, že je vše v pořádku a že musíme jít dál.

A tady je management, navržený tak, aby se s tím vším vypořádal díky své flexibilitě. Tento mišmaš minimalizuje různá rizika pomocí souborů zásad. Všechny se odrážejí v Agile Manifestu, vydaném v roce 2001. Stručně řečeno, znějí takto:

1. Hlavní jsou lidé, ne věci.
2. Spolupracujte, nečtěte smlouvu.
3. Dokumentace by neměla zasahovat do práce.
4. Změňte co nejrychleji.

Může se to zdát příliš vágní a nepřesné, ale pojďme na podrobnosti.

Návrh procesu

Vzhledem k tomu, co je Agile, pojďme se věnovat jedné z nejpopulárnějších metod známých jako „Scrum“ (Scrum). Co nabízí? Chcete-li začít, potřebujete:

1. Vyberte vlastníka produktu. Tato role je vhodná pro člověka, který vidí, k jakému cíli musíte jít a co se nakonec stane.
2. Rozhodněte se pro tým. To vyžaduje skupinu tří až deseti lidí, kteří mají dovednosti k dosažení výsledků.
3. Vyberte si zodpovědnou osobu. Je to osoba, která bude sledovat vývoj projektu a pomůže týmu překonat potíže.
4. Vypořádat se s obtížemi. Všechny stávající požadavky na produkty by měly být shromážděny na jednom místě a měly by být upřednostněny. Produktový vlastník by zde měl shromažďovat všechna svá přání. Poté je tým vyhodnotí a pochopí, zda to lze realizovat a kolik času je k tomu potřeba.
5. Celý rozsah práce byste měli rozdělit na časové úseky, týden nebo dva dlouhé, během kterých bude tým plnit určité soubory úkolů.
6. Schůzky by se měly konat denně, ne déle než patnáct minut. Na programu by se mělo diskutovat o tom, co se dělalo včera, jaké jsou plány na dnešek a překážky, které nám brání dostat se do výšky.
7. Na konci týdne (dva) udělejte recenze, během kterých tým mluví o tom, co bylo uděláno. Zároveň je nutné prokázat výkon částí výrobku.
8. Po každém časovém období by se měly problémy prodiskutovat a hledat řešení. Kromě toho musí být veškerý vývoj okamžitě realizován.

Jak rozpoznat Agile?

Metodika řízení, bez ohledu na zvolený směr, má vždy následující vlastnosti:

1. Minimalizace rizik. to hlavním cílem který každý flexibilní přístup sleduje.
2. Iterativní vývoj. V tomto případě se předpokládá práce v malých cyklech.
3. Nejdůležitější jsou lidé a komunikace mezi nimi.

Představme si řeku. Na jedné straně zákazníka. Druhým je tým. V tomto případě má agilní vývojová metodika výhody pro každého:

1. Zákazník chce minimální životaschopný produkt. Při jeho tvorbě se přitom mohou měnit podmínky.
2. Pro tým je užitečné komunikovat s kolegy a zákazníkem. V tomto případě se minimalizuje riziko nepochopení, zvyšuje se transparentnost procesů, rychle se řeší problémy a snižuje se šance, že při vytváření produktu dojde k překvapení.

sociální faktor

Když mluví o tom, co je Agile, většinou mluví jen o pozitivních věcech. Komunikace v týmu se skutečně zlepšuje. Všichni lidé se soustředí na jednu myšlenku, nevytvářejí mezi sebou tajemství, dávají si závazky. Výsledkem je, že tým pracuje v pohodlných podmínkách a rychlým tempem. Tento přístup vám umožňuje zefektivnit chaos.

Od svého vzniku si dokázala najít uznání v technologických odvětvích. V současné době široce používané pro navrhování nových softwarových produktů. Ale v obecné obchodní praxi je tento přístup stále málo známý. Ti, kteří se s Agile ještě nesetkali, jsou proto opatrní. Mělo by být také zřejmé, že by se měl používat pouze v případech, kdy lidé čelí úkolu intelektuální práce.

Malý příklad

Pojďme se podívat, jak tyto metodiky vývoje softwaru fungují. Řekněme, že máme Petra, majitele produktu. Nezná technické detaily, ale má vizi velkého obrazu. Ví, proč je produkt potřebný, jaké problémy vyřeší a koho uspokojí. Jsou tu i zájemci. Mohou produkt používat, podporovat jeho tvorbu nebo se na jeho tvorbě jinak podílet. Můžete také přidat uživatelské příběhy, které vyjadřují přání zájemců. Například: systém pro rezervaci jízdenek na pravidelné autobusy Moskva-Petrohrad by měl mít vyhledávání letů. Petr pomůže zájemcům. Převezme kontrolu nad implementací z nápadů uživatelských příběhů. Nechybí ani vývojový tým. To jsou lidé, kteří budou budovat fungující systém.

Vzhledem k tomu, že metodika vývoje je agilní, uživatelské příběhy se neshromažďují až do velkého vydání, ale jsou zveřejňovány ihned po dokončení a tak často, jak je to možné. Počet zpracovaných požadavků je týdenní propustnost týmu. Aby tým neztratil dynamiku a nezabředl do manuálního testování, měl by pracovat na automatizované integraci. Co je to? Pro každý pracovní okamžik je vypsán automatický test. Pokud je příběhů příliš mnoho, může dojít ke spěchu, ztrátě motivace, ztrátě produktivity a kvality. Pro takové případy je poskytována metoda "včerejší počasí". Spočívá v tom, že je třeba stanovit přísné limity na množství práce a pečlivě si vybrat, co přesně bude realizováno. Dříve zmíněný „Kanban“ navrhuje nastavit limit úkolů.

Co dělat s frontou?

Dobře, takže se tým rozhodl, že může zpracovat čtyři příběhy týdně. Ale jak se orientovat ve všem, co je? Řekněme, že uživatelé nahrávají deset příběhů týdně. Čtyři se zpracovávají. Fronta tak bude neustále narůstat. V tomto případě je pouze jeden účinná metoda- slovo "ne". Pro vlastníka produktu je to nesmírně důležité. Říct „ano“ není těžké. Mnohem obtížnější a důležitější je rozhodnout se, co nedělat. Navíc je za to také nutné nést odpovědnost. Proto je nutné se rozhodnout, čemu věnovat pozornost nyní a co naopak odložit. Aby to bylo správně, musí produktový vlastník porozumět hodnotě a rozsahu každého příběhu.

Děláme rozhodnutí

Některé příběhy jsou nesmírně potřebné. Ostatní jsou jen příjemným bonusem. Vývoj některých příběhů zabere několik hodin. U ostatních bude dokončení trvat měsíce. Mnozí často vytvářejí korelaci mezi velikostí příběhu a jeho hodnotou. Ale to není vždy správné. Více není totéž jako lepší. Složitost a hodnota úkolu pomáhá Petrovi správně stanovit priority. Jak lze tyto vlastnosti kvantifikovat? V žádném případě. Toto je skutečná hádací hra. A pro větší efektivitu je potřeba do toho zapojit hodně lidí. Jedná se o vývojový tým, který bude informovat o náplni práce a zájemcích. Je však třeba si uvědomit, že všechna data získaná tímto způsobem jsou přibližné odhady. Přesná čísla zde nejsou. Zpočátku budou chybět. Ale jak budete získávat zkušenosti, jejich počet a rozsah se bude snižovat.

Možná rizika

Abychom se vyhnuli problémům, je nutné poctivě odpovědět na řadu otázek. To:

1. Děláme správné věci? To je podnikatelské riziko.
2. Dokážeme implementovat to, co potřebujeme?
3. Bude projekt fungovat na této platformě. Jedná se o technické riziko.
4. Je dost peněz a budeme mít čas? To jsou rizika z hlediska implementace a nákladů.

V tomto případě jsou nutné znalosti. Lze je považovat za protiklady rizik. Když je zafixována významná míra nejistoty, pak získáváme znalosti – například vytváříme prototypy rozhraní nebo technické experimenty. A když už je máme, rozhodujeme se o směru, kterým bychom se měli ubírat.

Jak se učit?

IT průmysl se extrémně rychle rozvíjí, a abychom nakonec neprohráli, je nutné se neustále vzdělávat, zlepšovat dovednosti a efektivitu práce. Proto jsou otázky školení a implementace aktuálnější než kdy jindy. kde začít? Většina nejlepší možnost- jedná se o spolupráci s firmou, kde se již Agile uplatňuje. Školení v tomto případě povedou lidé, kteří z doslechu nevědí, co je agilní rozvoj. Ale bohužel to není vždy možné. Nejčastěji je zapojen specialista třetí strany, který ví, co je Agile. Implementace tohoto přístupu probíhá pod jeho dohledem. Je pravda, že služby takového specialisty stojí peníze. Ale pokud seženete opravdu znalého člověka, pak se vám všechny výdaje bohatě vyplatí. Ostatně v moderní svět Výkon zaměstnanců hraje důležitou roli.

Co se chystá do budoucna?

Metodologie vývoje softwaru se neustále vyvíjí. Hledání nových cest a příležitostí ke zlepšení efektivity činností a práce. Je poměrně problematické říci, co nás čeká v budoucnosti. Flexibilní vývojový systém bude pravděpodobně integrován s automatizačními nástroji výrobní procesy. Například bude možné řešit problémy i na dálku od sídla firmy. V mnoha ohledech budoucnost určuje nové Informační technologie. Když totiž vzniknou, musíte si osvojit nové metody práce s nimi. A v tomto případě jde o vývoj uzavřený v cyklu.

Konečně

Exkurze do flexibilních tedy skončila, ale je třeba připomenout, že teorie je jedna věc a praxe druhá. Nové informační technologie, které se neustále objevují, jsou výzvou pro velkou komunitu vývojářů. Jak můžete zvýšit efektivitu svého týmu? Odpověď na tuto otázku najde každý sám. Zde uvedené informace mohou být použity k vytvoření páteře. V praxi ale budete muset pracovat se stávajícím modelem a uvést stav věcí do stavu souladu s existujícími výzvami. Pak bude tým schopen efektivně plnit své cíle.