Agilní 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“:
- “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 …
- “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 …
- “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.
- “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
- 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.”
- Implementace funkčnosti
- Revize funkčností a předvedení zákazníkoci – jeho zpětná vazba
- 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.
Staré projekty
Asi každý, kdo podnikal má nějaké historické projekty, které jsou v různých stádiích – některé jenom „v šuplíku“, tedy ve stádiu úvah, třeba zjištění prvních informací o trhu, … Další třeba započal, udělal si rozpočty, koupil doménu v případě webových projektů, ale prostě málo času, nebo nedostatek nadšení pro ně způsobil, že opět nepostoupily dál. No a určitě je i pár takových „otazníků“ – použijme terminus technicus BSC matice – tedy projekty, které započaly, nějak si žijí, není čas/chuť/síla se o ně starat a je to takové „třeba se k tomu někdy vrátím, třeba ne“, možná se to rozjede samo, nebo až dokončím něco důležitějšího (často výnosnějšího).
Má smysl se k těmto projektům vracet? Má cenu je udržovat? Zrovna nedávno jsem udělal menší inventuru – mám pár věcí, u kterých bych určtě věděl, jak je pošťouchnout dopředu, ale prostě čas na to není. Pokud má někdo zkušenosti s projekty, které takto po letech otevřel a začlo se jim dařit, svěřte se.
Můj soukromý názor je, že 90% podobných projektů nikdy nedospěje dál, ale pokud je energie na jejich udržení minimální, nebo nulová, asi nemá smysl je hned rušit. Na druhou stranu by si asi měl každý stanovit hranici – pokud se k projektu nevrátím po dobu řekněme 5 let, asi nemá smysl ho „udržovat ve stádiu hibernace“.
projekt knihovna -požadavky x Use Case x Use Case diagram
Když už jsme si připravili Use Case diagram (a není ještě úplný), měly bychom si říci, jaký je vlastně rozdíl resp. vztah mezi požadavky, Use Case a Use Case diagramem. Čtenáře poprosím o schovívavost, ale budu používat anglický termín Use Case namísto českého Případy Užití, který je i u nás obecně používaný a nechci být jazykový puritán.
Takže shrňme si to:
Požadavky
Jsou seznam operací, které bude systém provádět, respektive, které budou jednotliví uživatele používat, většinou by mělo být alespoň trochu popsáno o co jde (často jen slovně) a kdo činnost provádí/má k ní oprávnění.
Diagram Use Case
Obsahuje jednotlivé uživatele/role (Actors) a procesy (Use Cases) s naznačením, co kdo má oprávnění provádět. Zde již je vidět jistý náznak objektové hierarchie – mezi uživateli se často používá vztahu generalizace. Což je vlastně zobecnění, tedy “nadtřída” a naopak vztah specializace, což je potomek, tedy podtřída. Mezi procesy pak existují vztahy <<include>> a <<extends>> – píše se na šipku spojující procesy (Use Case-y, jestli to tak mohu skloňovat) a vede směrem k případu, který se v tom prvním používá – tedy například šipka s include vede od rezervovat knihu k procesu najít knihu … když chceme knihu zarezervovat, musíme jí předtím najít – velmi často je proces ke kterému vede vztah <<include>> sám o sobě nepoužitelný. Spojení extends je méně časté a ukazuje rozšíření dané funkce, případu, které nemusí vždy nastat – při přidávání knihy bychom mohli zakládat kategorii (žánr), ale to jenom tehdy, pokud by již daný žánr neexistoval … Určitě sek tomu při zpřeňování ještě dostaneme.
Use Case – Případy užití
A konečně poslední varianta – není to graf, ale seznam jednotlivých Use Case, spolu s popisem jednotlivých kroků a jejich odpovědností – vhodné je pro popis používat jistý pseudokód – ať už anglický, nebo čestký, tedy “když/if, jinak/else, dokud/while …” nejdůležitější je abychom myi zákazník popisu rozumněli.
Nejjednodušší je asi zápis do tabulky
| Rezervování knihy | ||
|---|---|---|
| krok | role | popis |
| 1 | uživatel | vyhledání knihy |
| 3 | uživatel/knihovník | IF knihovník |
| 2.1 | knihovník | – vyhledat uživatele |
| 2.2 | knihovník | END |
| 3 | system | ověřit stav uživatele |
| 4 | system | IF uživatel není zablokován |
| 4.1 | system | – založit rezervaci knihy |
| 4.2 | system | END |
Všimněme si jedné drobnosti – v tuhle fázi často ignorujeme stavy kniha nenalezena, uživatel nenalezen – většinou procházíme typické scénáře. Na výjimky/speciální případy bude snad čas později. Jde spíše o to si popsat s uživatelem standardní běh systému.
LinkedIn
