Archive for the ‘Knihovnička SE’ Category

Nádherný kód

Sunday, May 25th, 2008

Půl roku v laboratoři vás dokáže uchránit od deseti minut v knihovně.

Původně jsem chtěl psát o svých pokusech se Spring OSGI modulem, ale přišlo mi lepší počkat si, až se ve středu něco poučím na CZJUGu. Takže vás dneska čeká další z mých minirecenzí knih. Tentokrát budu psát o hardcore koderské knize s názvem Beautiful Code. Autora neuvádím, protože co kapitola, to jiný autor. Jde v podstatě o kompilaci textů různých programátorů. Všichni se zamýšlí nad tím, co to je nádherný kód.

Nápad je to dobrý, nicméně takto sepsaná kniha má i své mouchy. Není konzistentní, takže některé kapitoly mě hodně bavily, jiné zase vůbec. Například kapitola o tom, jak funguje přenos dat v Subversion je hodně zajímavá. Stejně tak kapitola o MapReduce. Na druhou stranu, z některých kapitol jsem přečetl jen první dvě stránky a pak je přeskočil.

Samozřejmě, že se v té knize člověk nedozví, jak napsat nádherný kód. Zajímavé ale je, že spousta autorů sdílí názor, že nádherný kód = jednoduchý kód. Několik odvážlivců si dokonce píše i o tom, že nejlepší kód je ten, který vůbec nenapíšeme. Docela s nimi souhlasím, bohužel ne vždy se tím řídím.

Takže abych to shrnul: z knihy mám rozpačitý pocit. Vůbec by neškodilo, kdyby byla poloviční. Je ale možné, že někomu jinému by se líbily jiné kapitoly. Takže uděluji slabých 5 hvězdiček z deseti.

Vytíženost

Tuesday, May 13th, 2008

Chtěl bych se vrátit ke knize Slack, o které jsem tu už psal. Tenkrát jsem si vybral kapitolu, která se mě tehdy docela dotýkala. Bohužel z ní nebylo vidět, o čem ta kniha je. A to je škoda, protože Slack je jedna z nejlepších knih, kterou jsem o managementu četl (ono jich zas tolik nebylo).

Název Slack by se dal podle slovníku přeložit jako časová rezerva, nevyužitý nebo dokonce flákat se. O tom všem to je - o potřebě určité volnosti. Jako příklad uvedu citaci

Vezměte si například sekretářku (Pamatujete si ještě sekretářky? Kdysi obvyklý prvek firemního života.) Práce sekretářky [...] usnadňuje hladký průběh pracovního života manažera. Říkejme ji Silva.

Dobrá sekretářka je poklad [...] Když je v práci Silva, všechno jde snadno. [...] Teď si představte, že nastoupí konzultant s cílem snížit náklady. „Cože, co to je? Sekretářka? A co zrovna teď dělá?“ Sedne si se stopkami vedle jejího stolu. Nikoho nepřekvapí, že přijde na to, že Silva je zaměstnána jen 43% času. Ve zbytku doby se … je k dispozici. Je k dispozici dělat práci kterou zrovna teď potřebujete. To je to co je na Silvě tak skvělé. Když je něco potřeba, je okamžitě k dispozici.

Triumfální výraz se usadí na konzultantově tváři. Pokud je Silva zaměstnána jen 43% času, můžeme ušetřit 57% procent jejího času. Můžeme ji hodit do „poolu“ a alokovat 43% pro vás a 57% pro ostatní. [...] Nebo se jí úplně zbavit a najmout brigádníka jen na těch 43%. [...] Jaká úžasná efektivnost. Místo člověka který 57% času zahálel, máme někoho kdo pracuje 100% času. Povídejte mi o výkonnosti!

Problém je samozřejmě v tom, že teď plně využitá sekretářka jednoduše nereaguje tak rychle jako Silva. Tato nově výkonná osoba prostě nereaguje tak rychle na věci, které je potřeba udělat, protože má moc práce.

Platí něco podobného o programátorech? Když přijdete na to, že potřebujete 73% programátora, můžete hodit ten zbytek do „poolu“ k dispozici jiným manažerům? Když potřebujete 100% senior programátora, můžete počítat s tím, že ho budete mít na 100%? Co když bude potřebovat poradit nováčkovi, co když bude potřeba řešit něco na projektu na kterém už dávno oficiálně není? Co když bude potřeba pomoci s nabídkou pro nového zákazníka?

Představte si firmu, kde může manažer říci, „Já potřebuju Tondu jen na 50%, zbytek dávám k dispozici, ať si ho veme kdo chce“. Může to fungovat?

Podle mě ne. Za prvé, ten manažer ho nechce jen na 50%, on ho chce jen na 50% platit. Nevěřím, že pro něj bude práce přesně na 4 hodiny denně. Spíš bych tipoval, že víc.

Navíc mám pro vás jednu novinku, programátoři se nedají krájet. Když si z programátora ukrojím půlku, dostanu dvě půlky mrtvoly. Když to udělám jen obrazně, dopadne to jen o trochu lépe. Takže opakuji: 1 programátor – 0,5 programátora << 0,5 programátora. Platí rovnice, kterou se opět můžeme dočíst v knize (od které jsem se na moment trochu odchýlil, za což se všem postiženým omlouvám)

Trest za přepínání úloh = čas potřebný pro přesun na novou úlohu + oprava chyb způsobených nevhodným přerušením v práci + čas pro opětovné se ponoření do úkolu + frustrace + ztráta vazby na tým

Takže jak to dopadne v naší hypotetické firmě, která umožňuje prodat dvě půlky programátora? Napadají mě dvě možnosti. Buď budeme potkávat na chodbách usínající programátory, kteří pracují na 150% procent. Nebo se prostě a jednoduše budou falšovat výkazy, tak aby to vypadalo, že máme dvě nezávislé půlky programátora.

Měříme touhu

Sunday, January 27th, 2008

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í.