Na včerejší přednášce o agilním programování jsem pravda byl jako člověk pracující převážně ve “one-man show” akcích, zároveň ale s chutí poznat něco nového z řízení projektů, na kterém jsem se již také několikrát podílel. Obecně je tento nový (relativně – pro někoho to již je zaběhnutá věc) přístup buzz-word posledních let. Hlavně mnoho programátorů na to dobře slyší, protože se odbourávají složité vyplňování formulářů, psaní dokumentace na vše, … prostě spousta věcí, které jsou považovány za zbytečné a za zdržující od práce. Rozhodně nejsem fanda striktních metodologií a vyplňování půlhodinových time-sheetů, na druhou stranu se nemohu zbavit dojmu, že metody agilního vedení projektu nemusí fungovat všude. Zde podotknu, že jsem od “agilního programování” přešel k “agilnímu managementu” – nevidím důvod, proč stejné metody nepoužívat v obecném řízení projektu. Jenže stejně tak nevidím mnoho důvodů, proč by metody fungující u normálních projektů neměly fungovat u projektů softwarových. Nebo snad mají “svoje špecifíka”? Ano mají, ale základ bývá opravdu stejný. Agilní metody proto beru spíše jako doplnění klasického postupu, případně modifikaci a zdůraznění některých věcí, které jsme dříve (v zájmu přesnosti a procesního řízení opomíjeli). Základní myšlenky lze vzít z “Agile Manifesto“:

1. “Individuals and interactions over processes and tools” – tedy vyjádření, že pocity lidí jsou důležitější naž nástroje. Je důležité spíše naučit lidi komunikovat, než je nutit vyplňovat kdejaké reporty a formuláře …
2. “Working software over comprehensive documentation” – tady je třeba souhlasit, ale IMHO s upozorněním, že extrémní varianta – “dokumentaci píšeme až ji potřebujeme” – má svoje úskalí a psát si postupnou dokumentaci, k třídám, metodám považuji za dobrý mrav …
3. “Customer collaboration over contract negotiation” – ano to podepisuji beze zbytku – je lépe zákazníka brát jako partnera – informovat ho o problémech a hledat SPOLEČNĚ řešení je určitě lepší než se na konci začít nad smlouvou hádat, jestli je bod splněn nebo nesplněn.
4. “Responding to change over following a plan” – tedy raději reagovat na změny (požadavku zákazníka, změna prostředí), než striktně dodržovat rozpočet a časový harmonogram. IMHO hodně souvisí s bodem tři, kdy je lépe si sednout se zákazníkem a vysvětlit, že jeho nový požadavek prostě bude stát více času/peněz a znát jeho názor, dohodnout se, jestli je to pro něho přijatelné, … než si říct “na to není čas, budeme dělat až jako změnu po předání díla”.

V každém případě mám pocit, že agilní metody a jejich rady mohou vývoj obohatit i když nebudou přijaty jako celek. Co bych vyzdvihnul je určitě “retrospektiva” – tedy kolečko (pořádané ráno), kdy každý člen teamu řekne, co dělal minulý den, co se chystá dělat dnes a jestli mu něco dělá problém. Mám pocit, že to prostě dá lidem krátkou představu o projektu jako celku a jeho stavu …

SCRUM

Asi bych se měl zmínit i o SCRUMu – nevím, jestli to nazvat metodou, nebo metodolofií – obecně jde o způsob vývoje (třeba software) založení na krátkých cyklech (záleží na projektu, ale pokud jsem mluvil s lidmi, tak nejčastější je cca 5 pracovních dní) nazývaných sprinty. V podstatě se jedná o cyklus

1. Vyber funkčnost, která se v tomto sprintu bude implementovat. Z množiny požadavků tedy zvolení těch “které mají být na konci sprintu hotovy.”
2. Implementace funkčnosti
3. Revize funkčností a předvedení zákazníkoci – jeho zpětná vazba
4. Běž na krok č. 1

Co je důležité?

• Dodržet čas – raději si přiznat, že něco nestihneme, ale sprint po dané časové jednotce ukončit a funkčnost, kterou jsme neudělali vrátit do “zásobníku práce”.
• Funkčnosti vybírat s přihlédnutím k názorům zákazníka.
• Na konci vždy něco zákazníkovi ukázat – team i zákazník musí cítit, že projekt postupuje!
• Po předvedení diskutovat s teamem i zákazníkem a nebát se požadavky ze zásobníku práce přidávat, měnit, odebírat …
• Pracovat JEN na tom co jsme na začátku sprintu vybrali (snad jedině pokud dokončíme vybrané, lze přidat další …)

Oproti klasice (watterfall) není plán dopředu tak rozpracován a přizpůsobuje se změně požadavků zákazníka, je možná trochu náročnější odhad času a ceny (neprovádí se na začátku tak podrobná analýza). Důležitá je zkušenost a schopnost dodržet tento rytmus …

Přednáška se konala v rámci cyklu na ČVUT a mohu ho doporučit.