(Ne)funkční tým

V rámci projektu, na němž se podílí kromě zákazníka několik firem, jsem přebíral tým vývojářů. Nebylo to úplně přátelské převzetí (z hlediska projektu) a tak jsem se obrátil na radu k moudrým knihám. Z nabídky Amazonu jsem nakonec zvolil The Five Dysfunctions of a Team od Patricka Lencioniho.

Kniha je rozdělena do dvou částí. Tu první, větší charakterizuje podtitul knihy - A Leadership Fable. Sledujeme v ní příběh IT společnosti (startupu), který má (jak jinak, vzhledem k tématu) nefunkční executive team. Do firmy přichází nová CEO, která má na starosti tým sjednotit, motivovat a dovést společnost k rozkvětu :-)

Tato část je napsána velmi čtivě, až napínavě a celkem přirozeně představuje a vysvětluje principy (ne)fungování úspěšného týmu. Tyto principy jsou pak precizně shrnuty v druhé části, nazvané The Model. No a co že je oněmi pěti principy?

V podstatě nejde o nic překvapivého (když je to takto zjeveno a poskládáno v logických souvislostech), ale člověku takové "zjevné" věci kolikrát ani nedojdou. Pro mne nejpřínosnější byl hned ten první princip Absence důvěry. Dovolil bych si zde z něj (a z knihy) dvakrát ocitovat:

"In the context of building a team, trust is a confidence among team members that their peers' intentions are good, and that there is no reason to be protective or careful around the group. In essence, teammates must get comfortable being vulnerable with one another."

"The most important action that a leader must take to encourage the building of trust on a team is to demonstrate vulnerability first. ... What is more, team leaders must create an environment that does not punish vulnerability."

UML certifikace, OCUP Intermediate

Právě jsem se čerstvě UML certifikoval, ještě mám vedle sebe "kouřící" report. Celá certifikace se jmenuje OMG-Certified UML Professional Intermediate Exam :-) zkráceně OCUP Intermediate. Nebylo to úplně jednoduché, nicméně jsem prošel se skóre 45/70 (passing score je 31/70).

Jako přípravu jsem primárně použil prep-kit UM0-200 od uCertify. Buď už mám těch certifikací moc a jsem zmlsaný, nebo zrovna tohle nebyl úplně povedený kit, každopádně ho nedoporučuju použít jako jediný zdroj na zkoušku. Nicméně i když jsem s jeho kvalitou nebyl úplně spokojený, i tak mi dost pomohl.

Naopak bych vřele doporučil knížku UML Certification Guide: Fundamental & Intermediate Exams. Bohužel jsem jí nevěnoval dostatek času - určitě bych pak měl lepší skóre. Jenom je škoda, že knížka už neobsahuje poslední, závěrečnou certifikaci (OCUP Advanced). Tu bych si chtěl časem také udělat a zatím nevím, jaké materiály pro to zvolit.

Kvůli certifikaci jsem si pořídil ještě jednu knížku (už jsem o ní psal): UML Distilled od Martina Fowlera. Jednak jsem si chtěl trochu šířeji oživit UML samotné a jednak jsem ji použil jako sekundární zdoj. Řekl bych, že se celkem hezky doplňovala s prep-kitem od uCertify.

Závěrem. Myslím, že zdroje jsem si zvolil správně, jenom jsem měl být trochu důslednější (= méně líný) při čtení UML Certification Guide.

Enterprise integrace, messaging

Dostal jsem se jako teamleader na integrační projekt, založený na proprietárním řešení/technologii. To proprietární (o kterém nechci psát) je nicméně postaveno nad WebSphere Message Brokerem (WMB). Právě kvůli WMB, jsem se pustil do čtení výborné knížky Enterprise Integration Patterns (EIP). A jelikož je pro mne jak WMB, tak EIP nové, rozhodl jsem se o tom napsat (v rámci studia) pár článečků. Takže...

Základní koncepty messagingu

WMB je, jak napovídá název, založený na messagingu, takže se prvně podíváme, co to ten messaging je a na čem jsou postaveny jeho základy (inspirováno a citováno z EIP). Vezměme si následující obrázek, který obsahuje všechny základní koncepty messagingu:

• Messages (zprávy). Kolem zpráv se to celé točí. Zprávy jsou atomickým paketem dat, která jsou přenášeny z jednoho systému do druhého. Každá zpráva se skládá z hlavičky a z těla (nic překvapivého). Zprávy mají často hierarchickou podobu (např. XML, nebo struktura Java objektů).
• Channels (kanály). Virtuální "trubky", kterými tečou zprávy. Kanály jsou jednosměrný - jedna aplikace do kanálu zapisuje a druhá z něj čte.
• Endpoints (koncové body). Rozhraní pro připojení aplikace k messagingovému systému. Umožňuje aplikaci posílat a přijímat zprávy. Instance endpointu je svázána s konkrétním kanálem - z toho vyplývá, že může zprávy buď přijímat, nebo odesílat (ne obojí najednou).
• Routing (směrování). Pokud máme hodně aplikací a kanálů, může být tok zprávy velmi komplikovaný. Namísto aby se o její trasu musel starat odesílatel, pošle ji do message routeru, který se postará o navigaci zprávy skrze topologii kanálů tak, aby dorazila k příjemci (známe z TCP/IP).
• Pipes and Filters (trubky a filtry). Pokud potřebujeme se zprávou během jejího toku nějak pracovat, je vhodné ji přes několik kanálů prohnat potřebnými škatulkami - princip, který dobře znají uživatelé Unixu (ls -l /dev/ | grep sd[a-f] | wc -l), nebo električtí kytaristé (kytara - ladička - overdrive - chorus - kombo).
• Transformation (transformace). To jsou ty krabičky. Potřebuju konvertovat data z jednoho formátu do jiného? Potřebuju zprávu něčím obohatit? Potřebuju změnit transportní protokol? Použiju odpovídající transformaci/krabičku.

Jak je vidět z uvedeného přehledu základních principů, jde o v podstatě triviální koncepty. Přínosem výše uvedené EIP knížky je, že jednak tyto principy probírá do hloubky a v různých variantách, jednak je uvádí komplexně (můžou být věci, které člověku na první, druhý, třetí pohled nedojdou) a jednak je kombinuje do důmyslných a praxí ověřených řešní (přeci jenom, jsou to vzory).

ThoughtWorks Radar, zajímavé technologie

Firma ThoughtWorks (kde pracuje můj oblíbený SW guru Martin Fowler) nedávno zveřejnila svůj Technology Radar, jehož účelem je "to help decision makers understand emerging technologies and trends that affect the market today." Ještě než se dostanu k technologiím, které mne zaujaly, uvedu k Radaru krátkou legendu. Radar je rozdělen do kvadrantů Techniques, Tools, Platforms a Languages. Jednotlivé technologie jsou umístěny na kruzích:

• Adopt: We feel strongly that the industry should be adopting these items. We use them when appropriate on our projects.
• Trial: Worth pursuing. It is important to understand how to build up this capability. Enterprises should try this technology on a project that can handle the risk.
• Assess: Worth exploring with the goal of understanding how it will affect your enterprise.
• Hold: Proceed with caution.

To, co mě na Radaru zaujalo nejvíc, je nadějná pozice Clojure. Vzhledem k tomu, že tomuto se věnuji na svém dalším blogu věnovaném Clojure, nebudu to zde rozebírat. Co dalšího?

• Continuous Delivery. Aktuální agilní technika z dílny samotných ThoughtWorks, aneb jak efektivně dostat na produkci každý dobrý build. Knížku už mám zakoupenou, teď jen najít čas si ji přečíst.
• Sonar. Integrovaný nástroj pro kontrolu a vizualizaci metrik zdrojového kódu. Sám jsem ho sice, bohužel, na projektu ještě nepoužil, ale už mockrát jsem nad ním přemýšlel - procházet jednotlivé metriky vygenerované Mavenem je otravné a člověk přitom ztrácí celkový kontext.
• Vzestup NoSQL databází. Už bych se měl na nějakou konečně podívat.
• Gradle. Nástroj na automatizaci projektu, něco jako Maven používající Groovy DSL. Jeden čas jsem ho používal na malé Java a Groovy projekty. Možná nastal čas se k němu vrátit.
• JRuby. Ruby implementace pro JVM. Jestli mi do toho něco nevleze, rád bych se Ruby naučil jako další jazyk. Ruby/JRuby se mi jako Javistovi hodí.
• Špatné umístění GWT. Doslova je řečeno: "GWT is a reasonable implementation of a poor architectural choice.". O GWT jsem přemýšlel ze strategického hlediska, jako o možné frontendové Java technologii při návrhu architektury AJAX aplikací. Tak teď nevím, nevím.

ThoughtWorks Radar ve formátu PDF.

Destilované UML

V rámci přípravy na druhý stupeň UML certifikace jsem si koupil (a přečetl) knížku Martina Fowlera UML Distilled s podtitulem A Brief Guide to the Standard Object Modeling Language. Fowler se zaměřuje na dvě hlavní témata: jednak celkový přehled všech UML diagramů ve verzi 2.0 (kde až na výjimky nejde moc do hloubky - opravdu brief guide) a jednak zasazení diagramů do kontextu SW vývoje/designu/analýzy - zde můžou být (pro někoho) cenné jeho  postřehy a doporučení o použitelnosti jednotlivých diagramů.

Knížka to není špatná (dal jsem jí čtyři hvězdičky), nicméně pro moji aktuální potřebu se moc nehodí. Celkový přehled diagramů byl fajn pro oživení UML oblasti. Ovšem vzhledem k účelu, ke kterému jsem si knihu pořídil tam byl nevhodný poměr mezi specifikací UML a popisem/vysvětlováním různých oblastí SW engineerství (= málo UML). Navíc celý ten "projektový" kontext, kterým Fowler UML ve své knize obalil (např. iterativní vývoj), už byl mnohokrát popsán jinde. Pro certifikaci samotnou tedy spoléhám spíše na doporučený (oficiální) studijní materiál UML 2 Certification Guide a sadu zkušebních testů.

Na závěr ještě poznámka ke Kindle edici knížky. Vzhledem k tomu, že Fowler je u daného diagramu někdy velmi stručný, velmi často odkazuje do bibliografie a doporučuje další čtení k prohloubení tématu. Bohužel, biblio reference jsou uvedeny pouze jako klíč obyčejným textem - pokud si tedy v textu přečtu, že výborným doplňujícím zdrojem k tématu je [McConnell] a nemůžu si jednoduše kliknout a navíc navigace knihy neumožňuje jednoduše skočit do sekce bibliografie, tak je to otravné až frustrující. Dalším, již méně otravným (nicméně také bych jej párkrát využil) nedostatkem je nemožnost listovat mezi kapitolami.

P.S.: Pro ty, co jsou zvědaví, co se skrývá pod klíčem [McConnell], tak je to Rapid Development: Taming Wild Software Schedules od Steva McConnella.

Manažerem humorně a kousavě

Přečetl jsem výbornou knížku Managing Humans s podtitulem Biting and Humorous Tales of a Software Engineering Manager. Autorem je Michael Lopp, kterému se "nikdy nepodařilo uprchnout ze Silicon Valley", a který mmj. pracoval pro společnosti Apple Computer, Netscape Communications, Symantec Corporation, či Borland International jako sw engineering manager. Michael také píše populární blog Rands In Repose, kde většina(?) kapitol ze zmíněné knihy vyšla.

Knížka, která je velmi vtipná a čtivá (s trochu těžší angličtinou), popisuje různé aspekty softwarového inženýrství pomocí příběhů. Jelikož jsem četl na Kindlu, tak jsem si hodně podtrhával. Z mnoha myšlenek namátkově vybírám ty, které by mohly fungovat i vytržené z kontextu:

"This basic what-do-you-do disconect between employees and managers is at the heart of why folks don't trust their managers or find them to be evil."

"You instinctively know that telling your boss that you had a beer at lunch is a bad idea, not because he'd know it, but because the organization would."

"If you're sitting in a meeting where you're unable to identify any players, get the hell out. This is a waste of your time."

"Rule of thumb: When the debate is no longer productive, it's time to make a decision."

"I know engineers want to solve every problem in the product in any given major release, but that never ever happens ever. Better is the enemy of done, and if it's your project, you need to draw a line on what topics/ideas you intend to tackle and stick to it."

"In just about every company I've worked at, the only source of measurable truth regarding the product is the bug database."

"Yes, this guy is a C++ god. The next question is, OK, so he's a god; is he going to piss off the rest of the team by being godlike?"

"A view: Like the drink, the view is a mental break, an escape to somewhere else that provides a brief alternation of perspective. This is why everyone in the office wants a window. It's not a status symbol, it's an escape."

"A useful meeting is not a speech; it's a debate."

Updated: O knížce už před časem psal blog Java crumbs.

Odhady pracnosti softwaru

Zrovna čtu, paralelně, tři knížky - klasiky The Pragmatic Programmer, The Mythical Man-Month a The Passionate Programmer, což sice není klasika, ale výborná knížka to podle mne je. Všechny tři knihy (i když každá jiným způsobem) se zabývají tématem "sebezušlechtění programátora", ať už na poli kariérním, tak na poli praktickém.

V PragProg je kapitola o odhadech. Protože mi předestírané řešení/postupy konvenují, resp. jsem k nim došel intuitivně víceméně také, protože jsem v uplynulých dvou měsících dělal odhady na cca pět projektů v hodnotě 5-30 mil. a protože se mě kolega nedávno zeptal, "jestli máme ve firmě nějakou metodiku na odhady" (nemáme), přišlo mi to jako vhodné téma na blogpost.

Nejprve ve zkratce, co radí PragProg:

1. Porozumnění tomu, co je požadováno.
2. Vytvoření modelu systému.
3. Rozbití modelu do komponent.
4. Ohodnocení parametrů.
5. "Výpočet" odpovědí.
6. Průběžná kontrola odhadů (tracking).

Každý bod by chtěl trochu rozvést, ale to si můžete přečíst v knížce. Pouze bych zde ocitoval důležitou radu:

Základní trik v odhadech, který dává vždycky dobré výsledky: zeptejte se někoho, kdo už něco takového (projekt, problém) dělal.

Můj postup je z velké části podobný. Nejdříve se snažím získat co nejvíc informací. Většinou dostanu do ruky poptávku, plus se snažím zjistit kdo ve firmě dělal něco podobného, pracoval/pracuje u daného zákazníka, má zkušenosti s danou technologií, apod.

Jako model používám hrubou kostru projektu. Aby to neimplikovalo vodopád (někdy to je, někdy ne), uvedu jen uvažované role:

• projekt manažer,
• architekt,
• vývojář,
• tester,
• dokumentátor.

Role se mohou různě překrývat, čili role != člověk. Jako vývojář mívám na starost architekturu a vývoj. Pokud musím odhadovat i zbylé role/části projektu, dávám tam nějakou konstantu vůči vývoji, např. testování = 30 % vývoje. 30 % na vývoj se může zdát málo (alespoň podle Mythical Man-Month), ale jednak počítám že vývojáři píšou unit (a integrační) testy a jednak, že tester je přítomen během celého vývoje, tj. netestuje až na konci vývoje (UAT), takže většinu chyb odchytí během jednotlivých iterací.

Pak si v Excelu rozpadnu jednotlivé role v rámci týmu na komponenty. U každé komponenty si představím, kolik lidí by ji optimálně mělo dělat a jak dlouho by jim to mělo trvat. Tohle je těžká část a myslím si, že jinak než praxí a trénováním odhadů se to dělat nedá. Pokud si to nemám k čemu vztáhnout, je to opravdu... odhad. Excel, který používám se projekt od projektu liší, ale může vypadat přibližně takto:

Důležitý jsou poslední dva sloupce. MD best estimation je můj odhad nejkratšího času, za který se dá daný komponent vytvořit. Tj. všechno jde "podle plánu", nejsou žádné problémy, tasky dělají kvalifikovaní lidé, atd. MD mean estimation je odhad best estimation vynásobený nějakou konstantou (> 1). Velikost konstanty se pro jednotlivé komponenty liší a opět ji určuju na základě zkušeností. Číslo, který pak dávám k dispozici jako svůj odhad, je suma mean estimation.

Samozřejmě projekty se liší a občas je potřeba udělat nějakou "magii nad čísly", ale víceméně se držím výše popsané kostry. Aspektů o kterých by se dalo psát je hodně (bylo by to na článek,nebo na knihu), tak třeba někdy příště, až mě zase něco trkne. Dal bych jen několik doporučení:

• Odhady se dají trénovat. Člověk by měl už jako junior odhadovat tasky které dostává - jsou malé a dá se na nich dobře "zastřílet". Jak člověk "seniorní" dostává se k větším a větším taskům a pak i projektům a má pak na čem stavět.
• Opravdu se na tím zamyslet. Tj. zanalyzovat problém, zkusit ho dekomponovat, nakreslit si to, atd. Pomocníky jsou Excel, nějaké kreslítko (UML, mind mapy, diagramy, papír a tužka).
• Sbírat informace - knížky, kolegové, atd.

A na úplný závěr. Dávám vždycky odhady, jak si myslím, že to je, tj. nenásobím dvěma, protože mi to pak někdo ořeže. Rovněž nedávám tzv. "finger-sucking" a "window-outlooking" odhady, ale snažím se to vždy vztáhnout k něčemu ukotvenému v reálu. Spolu s trénováním pak ve výsledku dostávám odhady se slušnou mírou přesnosti.

Master your tools!

Už od malička jsem vášnivě četl. Časem se k tomu přidala neodbytná touha a potřeba po vzdělá(vá)ní. A kromě toho, že dělám práci, která mě baví, je její neoddělitelnou součástí (pro mne radostná) nutnost "učit se nové věci".

Protože jsem nechtěl zakládat další (tuctový) blog o Javě (která je momentálně mojí hlavní pracovní náplní) ani jsem se nechtěl svazovat nějakou konkrétní technologií, rozhodl jsem se psát o čemkoliv z oblasti SW inženýrství a brát to jako "ostření nástrojů", které se mi jednou budou hodit.