WUG Days 2016

Nemá smysl popisovat, co kdo říkal a co se komu líbilo či nelíbilo. Ale stojí zato zmínit dva aspekty z posledních dvou přednášek (Od psaní kódu k programování; Agilní vývoj ...; obojí Jan Pospíšil - Microsoft). První přednáška přinesla výrazný podnět, když na dotaz, kdo zná SOLID, se zvedla tak polovina rukou (čímž není myšlena jedna ruka u každého účastníka). I některé reakce na probírání elementárních principů objektového přístupu naznačovaly, že "smrtelné hříchy" symbolizované GOTO, SWITCH a dalšími neefektivními konstrukcemi nejsou až tak podmíněny možnostmi programovacích jazyků jako spíše způsobem myšlení vývojářů.

V druhé přednášce jsem zažil překvapení - několikrát jsem se setkal s pokusy nasadit metody agilního vývoje a vždy to byla naprostá tragédie. Navíc jsem ze všech zdrojů nabyl dojmu, že se jedná o nahrazení toho, že se vyvíjí bez korektního zadání a důsledné analýzy tím, že se vyvíjí metodou pokus omyl (což dle mého názoru v naprosté většině případů pořád platí, jelikož nám chybí rozumní zadavatelé a kvalitní analytik je pravděpodobně již vyhynulý druh. Honza Pospíšil dokázal vysvětlit, že podstata selhání není v podstatě tím, že by metodika byla nedostatečná či nerealistická. Naopak - dokázal zdůraznit řadu míst, ve kterých selháváme. Jenom pro ilustraci to nejzajímavější.

  • Člen týmu nemá (či nesmí) dělat nic, o čem není přesvědčen, že je pro něj (konkrétně a bezprostředně) užitečné. Aneb scrummaster je povinen při každé pochybnosti důkladně a pořád dokola vysvětlovat, proč přesně a konkrétně je potřeba dělat to, co metodika navrhuje.
    Což samozřejmě platí nejen pro vývoj software.
  • Je reálné a nutné, aby si vývojáři (realizátoři) rozepsali požadavky (backlog) na naprosto konkrétní technické úkoly v maximální pracnosti jednoho člověkodne.
    A samozřejmě je jasné, že jsme schopni dodržet to, že jeden člověk v jednom čase může pracovat pouze na jednom úkolu.

Agilnímu přístupu a souvislostem s procesním a projektovým řízením se budeme věnovat později důkladněji.



;