Kniha o které budu dnes psát se celým jménem jmenuje Agile & Iterative development – A Manager’s guide a napsal ji pan Craig Larman. Je to další z knih, kterou by si měl člověk přečíst, pokud se chce softwarovému inženýrství opravdu věnovat. Jak už název napovídá, jde o popis a obhajobu iterativních a agilních metod. Hned v první kapitole nás zaujme následující důležitá tabulka

Sloupeček vlevo je například výroba mobilního telefonu na výrobní lince. Víme velmi přesně jak dlouho to bude trvat a kolik to bude stát.

Sloupec vpravo může například reprezentovat stavbu domu, jehož majitel chce použít nové, prostředí přívětivé materiály a metody. Navíc si není jistý co přesně chce a chystá se měnit a upřesňovat svá rozhodnutí podle toho jak se bude vyvíjet stavba, cena a čas. V které kategorii vidíte software? Autor tvrdí jednoznačně, že

Výroba většiny softwaru není předvídatelná nebo hromadná. Vývoj softwaru je vývojem nového produktu.

Kolem tohoto tvrzení se točí následující kapitoly. Dostane se nám úvodu do iterativního vývoje.

Iterativní vývoj (IID) je přístup k budování softwaru (nebo čehokoliv) v němž je celkový vývoj složen z posloupnosti několika iterací. Každá iterace je samostatný miniprojekt složený z aktivit jako je analýza požadavků, návrh, programování a testování. Cílem každé iterace je iterační vydání (release) – stabilní, zintegrovaný, otestovaný a částečně kompletní systém.

V moderních iterativních metodách je doporučená délka iterace mezi jedním a šesti týdny.

Všimněte si, iterativní vývoj není o tom, že si každý dělá co chce kdy chce (tzv. cochcárna). V iterativním vývoji máme pevně stanovený konec iterace, máme seznam funkcionalit, které se musí v dané iteraci naimplementovat a v případě potřeby máme i analýzu a design pro danou iteraci. A hlavně na konci každé iterace ukážeme výsledek zákazníkovi a až na základě jeho zpětné vazby se rozhodujeme jak postupovat v dalších iteracích.

Co nám tento přístup přinese se dozvídáme v páté a šesté kapitole. Autor porovnává iterativní metody s vodopádem. Na této kapitole je důležité to, že tu máme velké množství odkazů na výzkumné práce, které všechna fakta podporují. Uvedu jich jen pár

Typický softwarový projekt zakouší 25% změnu požadavků

Z prvotně specifikovaných požadavků není 45% používáno nikdy, 19% zřídkakdy

Zajímavé jsou i odkazy na úspěšné použití iterativního vývoje, uvedu jeden příklad za všechny: Primary Avionics Software pro americké raketoplány byl vyvinut mezi roky 1977 a 1980. Bylo použito 17 iterací po dobu 31 měsíců, průměrná délka iterace 8 týdnů. Důvod pro použití iterativního vývoje byl vskutku originální – potřeba změn požadavků v průběhu vývoje.

V druhé polovině knihy se docela podrobně seznámíme s agilními metodami Scrum, Extreme programming, Unified process a Evo. Je docela zajímavé, jak jsou si tyto metody podobné. Liší se opravdu jenom v detailech.

Tuto knihu bych doporučil všem, kteří se zajímají nebo alespoň živí řízením softwarových projektů. Možná bychom se méně setkávali s obvyklou praxí řízení projektu vodopádem v druhé půli plynule přecházejícím v cochcárnu. Pokud vás téma zaujalo, přijďte na příští CZJUG, určitě se tam dozvíte mnohem víc.

Možná jste si všimli, že fanoušek knih z dávnověku softwarového inženýrství. Jednou takovou knihou je i Peopleware jejíž autoři jsou Tom DeMarco a Timothy Lister. První vydání zdobí letopočet 1987. Z názvu můžete soudit, že je to kniha především o lidech. Mohl by ji charakterizovat následující citát:

Hlavní problém naší práce není ve své podstatě ani tak technologický jako spíše sociologický.

Jednotlivé kapitoly popisují problémy, s kterými se naši předci potýkali v dobách temna. Zajímavá je například část druhá, která popisuje pracovní prostředí. Představte si, že tenkrát lidé pracovali v prostorech zvaných openspace. Myšlenka byla taková, že se ušetří spousta peněz tím, že se nacpe co nejvíce lidí na co nejmenší místo. Nějak jim nedošlo, že tím ohromě snižují produktivitu práce lidí, kterým platí dost velké peníze. Zajímavá jsou následující čísla. Vývojář obvykle pracuje

30% času sám
50% času s kolegou
20% času s dvěma nebo více lidmi.

Z toho nám plyne, že 30% času nám hluk vadí a 70% času ho generujeme. Čím více máme lidí na menším místě a čím méně je přepážek mezi nimi, tím méně toho udělají. Jaké štěstí, že v dnešní době už si management umí spočítat, že ztráty způsobené sníženou produktivitou jsou větší než peníze ušetřené na kancelářském prostoru. Jinak bychom si museli postesknout:

Existuje milión cest jak ztratit pracovní den ale neexistuje ani jedna jak ho získat zpět

Další části jsou už dnešku přeci jenom blíže. Jsou o lidech a ti se tak rychle nemění. I když i zde se najdou výjimky. V dávných dobách někteří manažeři žili v iluzi, že jsou všichni lidé stejní. Že jsou něco jako součástky stroje, kde je velmi snadné jednu součástku vyjmout a místo ní strčit stejnou, která okamžitě začne dělat práci té předchozí. Chtěli prý dokonce aby se lidé stejně oblékali – říkali tomu dress code. Dnes už se naštěstí všichni poučili a vědí, že v různorodosti je síla a drobná výstřednost není na překážku.

Celek je víc než jen souhrn všech částí.

Hodně zajímavá je i z pohledu dnešní osvícené doby část čtvrtá – o týmech. Autoři v ní tvrdí, že mít sehraný tým je to nejlepší co se vám na projektu může stát. Když lidé vědí co mohou od sebe navzájem očekávat, když si rozumí a hlavně když je baví pracovat dohromady. Prý je to ta nejlepší motivace. Já osobně bych souhlasil. Pokud jste ale manažer a máte opačný názor, předkládají několik rad, jak tým zaručeně rozbít. Vyberu jich jen pár:

Byrokracie – pokud chcete rozbít tým, je nejlepší je zahrnout hromadou papírů
Fragmentace času – pokud nechcete aby se vám tým semkl, je dobré nechat lidi dělat 20% času na jednom projektu, 30% na druhém a 50% na třetím
Přikrášlené termíny – nerealistické termíny u kterých není vidět, proč všechno musí být hotovo před zvoleným datem. Nejlepší způsob jak lidi demotivovat
Přesčasy – vhodné kombinovat s předchozím. Vždy se nejde jedinec, který nebude moci nebo chtít dělat stejně přesčasů jako ostatní. Můžete si být jisti, že se vám z toho podaří vykřesat krásné negativní emoce, které zajistí, že se tým nesehraje.

Dovolil bych si ještě jednu osobní radu na závěr: Okamžitě po projektu je potřeba tým rozdělit tak, aby se už nikdy nesešel.

Chtěl bych se s vámi podělit o zážitky z četby knihy Facts and Fallacies of Software Engineering od Reborta L. Glasse. Na první pohled je to tenoučká kniha, do které se toho moc vejít nemůže. Nicméně uvnitř najdete 55 faktů a 5 klamů o softwarovém inženýrství. Nečekejte žádné novinky, spoustu faktů najdete i jinde, spoustu jich je samozřejmých a většinu věcí lidé prostě vědí.

Co je tedy na té knize tak zásadní, že vám tu o ní píši? Je to právě nashromáždění věcí, které by měl každý software inženýr vědět. Uveďme příklad:

Fakt 8: Jeden ze dvou hlavních důvodů splašení projektů jsou špatné odhady.

Ano, všichni to vědí. Projekt je často ve zpoždění protože někdo někdy udělal odhady pracnosti a z těch se po celou dobu projektu vychází. Odhady se málokdy upřesňují. A téměř nikdy jejich autoři nedostávají zpětnou vazbu. Proč tomu tak je? No přeci z obchodních důvodů. Aplikace musí být hotova do konce roku a musí stát méně než X miliónů. Je tedy naprosto jasné, jaké si můžeme dovolit odhady. Nebo ne?

Možná přemýšlíte, co je ten druhý důvod splašení projektů. Než budete číst dál, zkuste na to přijít sami. Tak co, máte to?

Fakt 23: Jeden ze dvou hlavních důvodů splašení projektů jsou nestálé požadavky.

Zase žádná novinka. V některých společnostech jsou sběr požadavků a zpracování změn docela zvládnuté. Pamatuji ale projekt, kdy týden před plánovaným ukončením vývoje ještě nebyly jasné všechny požadavky. A ty co už byly stanoveny, se často měnily. Asi si dovedete představit kvalitu výsledného produktu.

Ale zpět ke knize, pokud vás z psaní aplikací zajímá i něco víc než jen bušení kódu, tuto knihu vřele doporučuji. Nečekejte však od ni žádné rady jak řešit problémy. Dostane se vám jen popis faktů a hodně odkazů na literaturu pro podrobnější informace. Na rozloučení ještě asi nejvtipnější fakt:

Fakt 14: Odpověď na studii proveditelnosti je skoro vždy „ano“.