Category Archives: Knihovnička SE

Měříme touhu

V mé choré mysli se zrodil plán. V případě nedostatku vlastních myšlenek, jako například teď, vás budu oblažovat výběrem oblíbených kapitol z oblíbených knih. Takže se postupně budu vracet i ke knihám o kterých jsem už psal dříve, když jsem je četl.

Dnes budu psát o kapitole Prioritizing desirability, z knihy Agile Estimating and Planning Mika Cohena. Kapitola je o zjišťování toho, co si zákazník přeje. Začíná Kanovým modelem zákaznické spokojenosti. V principu jde o to, že existují tři základní kategorie vlastností produktu

  • Nutné – vlastnosti, bez kterých se neobejde. Když kupuji notebook, chci aby měl monitor.
  • Lineární – čím víc tím líp. Čím má notebook větší paměť, tím lépe.
  • Vzrušující – věc kterou jsem nečekal a příjemně mě překvapí. U notebooku to může být například dálkové ovládání pro sledování filmu z postele.

Když si to zakreslíme do grafu, dopadne to asi takto

Kano model

Na svislé ose máme spokojenost zákazníka. Nahoře je spokojený, dole nespokojený. Na vodorovné ose vidíme míru přítomnosti dané vlastnosti (nebo potřeby). Vlevo úplně chybí, vpravo je plně obsažena.

Zeleně jsou označeny nutné vlastnosti. Vidíme, že když nejsou obsaženy, tak zákazník dokáže být hodně nespokojený. Nicméně i když je do produktu přidáme, moc vysoko se na žebříčku spokojenosti nevyšplháme.

Modré jsou lineární vlastnosti. Ty jsou podle mě snadno pochopitelné.

Červeně jsou označeny vzrušující vlastnosti. Když nejsou obsaženy, zákazníka to moc neštve. Když je ale přidáme, můžeme si snadno zajistit jeho spokojenost.

Je důležité si uvědomit, že to samé rozdělení platí i u vlastností software. Když vyvíjíme agilně, můžeme toto rozdělení použít pro prioritizaci práce. Víme, že nutné vlastnosti musí náš produkt nutně obsahovat. Musíme je proto rozhodně stihnout do releasu, není dobré je odkládat. Nicméně nemusíme je implementovat plně. Vidíme, že nárůst spokojenosti není od určité úrovně naimplementování moc velký.

Lineární vlastnosti jsou druhé na řadě. Měli bychom jich stihnout co nejvíce v co největší míře. Nakonec je dobré přihodit pár vzrušujících vlastností, abychom si zákazníka trochu rozmazlili.

Otázkou zůstává, jak zjistit, do které kategorie daná vlastnost patří. I na to v knize dostaneme odpověď. Zeptáme se například následující otázkou, s možnými odpovědmi

Pokud váš nový program bude umět exportovat data do excelu

  1. Budu rád
  2. Čekám že to tak bude
  3. Je mi to jedno
  4. Zvládnu s tím žít
  5. Nebudu rád

Trik je v tom, že se ho zeptám ještě jednou na opak

Pokud váš nový program nebude umět exportovat data do excelu

  1. Budu rád
  2. Čekám že to tak bude
  3. Je mi to jedno
  4. Zvládnu s tím žít
  5. Nebudu rád

Když dostaneme odpověď na obě otázky, můžeme použít následující tabulku pro určení dané vlastnosti

Tabulka

Teď už nám nic nebrání v tom, abychom se zeptali několika potencionálních uživatelů a podle toho určili, co vlastně od našeho produktu chtějí. Samozřejmě to nikdy nevyjde jednoznačně, ale s použitím statistiky nebo jiného podfuku to dokážeme zpracovat. Dostaname tak zajímavý nástroj na prioritizaci vlastností.

Dilbert a já

Hrozně rád čtu knihy o věcech kterým nerozumím. Ještě radši o takových věcech píši. Dnes proto budu psát o knize, která je určena manažerům. Jmenuje se poeticky: Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, napsal ji pan Tom DeMarco.

Kniha je to ohromě zajímavá, člověk si díky ní uvědomí spoustu věcí. Protože se ale chystám vyrazit do hospody, budu dnes stručný a přiblížím vám jenom jednu kapitolu, tu která mě zasáhla úplně nejvíce.

Pojednává o populárním Dilbertovi, pokud netušíte o koho se jedná, přináším malou ukázku

Dilbert

Takže už víte, že Dilbert je normální geek (ajťák?), který má tupého šéfa a tupé kolegy. Často na jeho obrázky narazíte v různých kancelářích, lidé se jim každý den smějí (protože jim něco nebo někoho připomíná) ale nikdo se nad nimi moc nezamýšlí. Pan DeMarco, alespoň u mne ťal do živého když napsal:

Je snadné (a spravedlivé) svalovat vinu za bídný management na bídné managery. Ale není to dostatečné. Je také nutné vinit ty lidi, kteří se nechají takto špatně řídit. Za každé špatné rozhodnutí je alespoň částečně zodpovědný nějaký zbabělý Dilbert, který to dopustí.

Takže pokud si občas připadáte jako v Dilbertově světě, je to částečně i vaše vina. Proč s tím sakra něco neuděláte. Protože na to nemáte pravomoc?

O tom autor píše v další části kapitoly. Vypráví, jak za ním často po jeho přednáškách někdo přijde a říká: „To by měl slyšet můj šéf.“ Nejdřív si prý myslel, že přednáší špatným lidem, že by to měl vysvětlovat jejich šéfům. K jeho překvapení výše postavení měli stejné komentáře. Proto dospěl k následujícímu závěru:

Když mi lidé říkají „To by měl slyšet můj šéf“ vím, že moje poselství dopadlo na úrodnou půdu a že jsem ho sdělil té správné osobě […] Osoba, která si nejvíce přeje přehodit tuto zodpovědnost někam výše je přesně tou osobou která ví, že by mohla tuto změnu uskutečnit, ale že to nebude jednoduché.

Proboha, jak se o mě dozvěděl?!

Agilní odhadování a plánování

Žádný plán nepřežije střet s nepřítelem. [polní maršál Helmut Graf von Moltke]

Včera jsem dočetl knihu Agile Estimating and Planning od Mika Cohna. Je to kniha docela zajímavá, zvlášť pro mě, který o daném tématu neví skoro nic.

Dozvěděl jsem se v ní proč je dobré plánovat, proč je to tak těžké a hlavně jak to dělat správně agilně. Konečně jsem také pochopil co je to story point (bod příběhu ??).

V agilních procesech by mělo odhadování mělo probíhat ve dvou fázích. V první fázi určíme takzvané uživatelské příběhy (story). Tzn. sepíšeme si, co vlastně budou jednotliví uživatelé se systémem dělat. Je to podobné jako klasické případy užití (use case), jenom mnohem stručnější. Příběh může vypadat například takto: „Jako uživatel mohu uložit dokument“. Poté celý tým odhaduje relativní velikost jednotlivých příběhu. Přiřazuje jim body, které nemají žádný reálný základ. Odrážejí jenom relativní velikost jednotlivých příběhů mezi sebou. Takže uložení dokumentu může mít velikost 5 bodů, načtení třeba 3. Sečtením bodů všech příběhů získáme odhad velikosti celého projektu (releasu).

Poté nastává druhá fáze, kdy se snažíme převést bezrozměrné body na čas. Zde nám začíná hrát roli rychlost (velocity). Pokud už agilně vyvíjíme, víme kolik bodů zvládne daný tým udělat za iteraci. Tomuto číslu budeme říkat rychlost. Poté už můžeme přibližně odhadnout, kolik iterací zabere současný projekt. Jednoduše vynásobíme rychlost počtem bodů. Pokud rychlost neznáme, můžeme ji odhadnout tak, že si zkusíme odhadnout trvání pár příběhů v hodinách a z tohoto odhadu odhadnout rychlost. Nicméně pravá rychlost týmu se projeví až (už) po prvních pár iteracích.

V čem je tento přístup výhodný? Je snadný. Je snadné říci, jestli je implementace jednoho uživatelského příběhu dvakrát těžší než implementace druhého. Je snadné říci, že jiné dva příběhy jsou přibližně stejně obtížné. Při odhadování velikosti opravdu jenom porovnávám jednotlivé příběhy mezi sebou.

Čas se počítá až v druhé fázi a to více méně automaticky. Rychlost je dána, tu známe z předchozích iterací. Takže jenom vynásobíme velikost projektu rychlostí a máme odhad trvání projektu. Je hodně těžké švindlovat a lhát si do kapsy. Těžko se hájí to, že začneme tvrdit, že se rychlost z čista jasna zvýší na dvojnásobek. Naopak, když se nám kvůli nějakým problémům rychlost sníží, projekt se automaticky přeplánuje. Okamžitě uvidíme, jak dlouho bude projekt trvat pokud budeme mít tuto rychlost i v dalších iteracích.

Kniha se samozřejmě věnuje i jiným tématům než odhadování a plánování celého projektu. Věnuje se i plánování jednotlivých iterací, monitorování, komunikaci a jiným tématům. Hodně pěkná je i kapitola o určování toho, které příběhy implementovat a které ne, ale o tom snad napíši někdy jindy.

Poznámka: Snažil jsem se termíny překládat do češtiny. Uvědomuji si, že některé termíny znějí trochu kostrbatě. Pokud máte lepší překlad, napište mi ho prosím.