Agilní programování

October 19, 2010 by
Filed under: Práce, programování 

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.

Print Friendly, PDF & Email
Be Sociable, Share!
  • Twitter
  • Facebook
  • email
  • StumbleUpon
  • Delicious
  • Google Reader
  • LinkedIn
  • BlinkList
Share

Comments

2 Comments on Agilní programování

  1. Zuzi on Sun, 24th Oct 2010 19:09
  2. Zdravim,
    jsem rada, ze Vas moje prednaska zaujala 😉

    Zuzana Sochova

  3. admin on Sun, 24th Oct 2010 19:35
  4. @Zuzana: Určitě, jsem sice trochu v jiné situaci – team tvoří většinou 2-4 lidi se zastupitelností skoro nulovou, ale v každém případě beru za rozumné podívat se “jak to dělají jinde”. Skoro u všeho lze nalézt něco zajímavého i pro jiné situace.
    Vlk

Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!





%d bloggers like this:
TOPlist