Agile Prague Conference 2011 - ohlédnutí

Ve čtvrtek a v pátek se v Praze konal první ročník konference o agilním přístupu k vývoji - Agile Prague Conference, které jsem se zúčastnil.

Pokud bych měl krátce zhodnotit akci jako takovou, tak moc nevím, co bych ji vytknul - vše probíhalo podle plánu, catering fungoval jak měl, na žádné nedostatky technického rázu jsem nenarazil. Kvalita přednášek a přednášejících byla nadprůměrná - z mého osobního pohledu se mi více líbil pátek a až na jednu hodně slabou přednášku ve čtvrtek jsem byl celkově spokojený. Nejvíce mě zaujaly čtyři "case-study" přednášky českých firem, které se podělili se zkušenostmi se zavaděním agilních metodik u nich ve firmě. Také asi pro mnoho lidí bylo překvapením, že o jednotlivých metodikách se skoro vůbec nemluvilo, vše bylo spíše o důvodech pro agilní vývoj, o organizaci týmů, o zkušenostech ze zavádění agilních přístupů.

Dále nechci procházet jednotlivé přednášky a hodnotit je, chci zmínit zajímavé postřehy a myšlenky, které jsem si odnesl:

• agilní přístup k vývoji má velice úzký vztah ke správné organizaci/struktuře společnosti - pokud chce být firma "agilní", tak musí být agilní celá a ne jen vývojové oddělení a i organizace jako taková tomu musí být přizpůsobena - místo klasické hierarchie šéf - product manager - project manager - tým vytvářet Self Organizing Teams, tj. reorganizovat odpovědnosti na celý tým, podpořit kreativitu a přenést zodpovědnost na všechny členy týmu.
• všechny case-study přednášky se týkaly firem, které mají produkty, takže zákazníkem vývoje jsou interní product manažeři. Hodně by mě zajímal pohled na agilní firmu, které funguje zakázkově pro externí zákazníky (a ještě navíc pro státní sektor)
• došel jsem k názoru, že pro úspěšné zavedení agilních metodik je nezbytné využití externího konzultanta, který díky tomu, že je externí, má mnohem lepší přesvědčovací pozici než interní vedení. Nejčastějším přístupem lidí při zavádění agilních přístupů je, že říkají, že to nebude fungovat, že my máme něco speciálního, co jinde nemají a proto to zde nemůže fungovat. Toto dost často externí člověk může vyvrátit.
• dále mi přišlo velice důležité začínat pilotním týmem/projektem, protože ve všech firmách, které své zkušenosti prezentovali, byla skladba lidí před zaváděním přibližně tato - třetina se moc těší, třetině to je jedno a třetina lidí si myslí, že to nemůže fungovat. Pilotní projekt dokáže hodně lidí z poslední skupiny přesvědčit, že to fungovat může.
• stále více se mi líbí Kanban, jako metodika pro vývoj softwaru - jednoduché, názorné, zábavné a "hravé".
• pro mě osobně nový zajímavý pojem Lean software development
• bez osobního potkávání a intenzivní spolupráce to nejde. Pokud chci co nejvíce omezit psaní dokumentace a pokud chci co nejvíce zodpovědnosti přenést na celý tým, pak musím tento tým dát dohromady, na jedno místo. I když preferuji práci na dálku (zejména kvůli mému osobnímu pohodlí), tak sám vím, že je něco úplně jiného mít tým v jedné kanceláři, kde lítají myšlenky vzduchem, kde všichni táhnou za jeden provaz.
• zpětná vazba od zákazníka musí být co nejkratší - pokud chci něco řídit (viz Teorie řízení z kybernetiky), tak kvalita řízení je přímo úměrná kvalitě zpětné vazby. Na jedné přednášce byla prezentována přímá úměra mezi délkou sprchy a nastavením správné teploty vody. Jak trefné :)
• Dnes (snad již) nikdo nevěří tomu, že vodopádový model může efektivně fungovat. Mnoho firem postoupilo o krok dále a praktikují iterativní způsob vývoje a včetně zavedené postupné integrace. To je ale pořád jen víceméně technický posun, ale pokud se nezmění organizace práce, struktura firmy a předání odpovědnosti týmům, pak není možné se bavit o agilním způsobu vývoje.
• Líbila se mi přednáška, kde přednášející trefně říkal, že dlouhá léta se softwarové inženýrství snažilo okoukávat přístup k vývoji a řešení problémů od průmyslu, který tu už přes sto let byl a dobře fungoval. Až nyní v poslední době se ukázalo, že vývoj softwaru potřebuje zcela něco jiného.

A nakonec přidám ještě pár hesel, které mě zaujaly:

• Vždy bude více požadavků než jaké jsou možnosti realizace - nutná prioritizace požadavků, čím kratší a rychlejší zpětná vazba, tím lepší.
• Častěji bych se měl ptát, zda dělám správnou věc než zda dělám danou věc správně.
• Posunu resp. zlepšení není možné dosáhnout beze změn.
• "When in doubt, leave it out" - pokud si nejsme jisti při výběru a návrhu nějaké nové funkce, tak to raději nechme ať zákazník sám řekne, jak a co chce.
• Kvalitní zpětná vazba od zákazníka není možná bez kvalitní komunikace s ním.
• Čím jednoduší je architektura celého systému, tím rychlejší je přidávání nových vlastností do systému. I proto refaktoring je tolik důležitý.
• Realita se mění, to je realita. Pokud chci vytvářet reálnou aplikaci, pak musím být na každodenní změny připravený.
• Kód píšeme kvůli tomu, že ho ještě nikdo jiný před námi nenapsal. Pokud již někdo napsal, pak není důvod to psát znovu.