Skvělá kniha The Phoenix Project popisuje sice imaginární, nicméně v realitě odrážející se příběh přechodu k agilnímu řízení, enbo spíš snahu o agilní transformaci s využitím Kanbanu a DevOps.

Všechny ty pasti a pastičky, kterými se propletá hlavní hrdina Bill Palmer, zrcadlí svět IT a jeho nefungování v plné nahotě. V tomto článku bych vám chtěl přiblížit komentované postřehy, které považuji za klíčové.

Intro

Kniha začíná poměrně nečekaným uvedením hlavního hrdiny do role VP pro IT operations ve Drmě, která vyrábí autodíly. Horší entrée si neumíte ani představit. Firma dlouhodobě neplní stanovené cíle, prodělává, její akcie padají dolu rychleji než popularita Jana Fischera. Konkurence jim dává pořádně na pdel a podle analytiků bude nejspíše Drmu potřeba rozdělit a prodat. Aby té smůly nebylo dost, ve Drmě krouží banda auditorů se soupisem porušení bezpečnostních a právních pravidel, který by pokryl více papírů než únos Ivety Bartošové. Naděje celé Drmy, počínaje vedením, přes marketing a konče u prodejního oddělení, se upínají k projektu Phoenix, který by měl výrazně pomoci dosáhnout cílů společnosti. Projekt se několikrát opozdil a jeho rozpočet se pořádně prodražil, jeho aktuální stav je neurčitý a datum nasazení je nebezpečně blízko. Na hlavního hrdinu padají kostlivci ze skříně zcela neočekávaně, přesně ve chvíli kdy si myslíte, že to nemůže být horší.

Na scéně se postupně objevuje postava mentora Erika, který nechává hlavního hrdinu nahlédnout do výrobního procesů továrny a dospět k zjištění, že správná cesta k řízení práce je Kanban a modus operandi fungování vývojářů a lidí z operations je potřeba vyměnit za DevOps. K dalším výrazným postavám patří Brent, DeusEx machina zasahující prakticky kdykoliv se objeví incident na produkci, případně je potřeba udělat nějakou složitější práci. Klacky pod nohy IT hází šéfka retail oddělení Sarah a drahnou dobu i John odpovědný za bezpečnost.

Zdroje činností v IT a jejich vliv

Jeden z prvních problémů, který musí Bill Palmer vyřešit, je výpadek výplatního systému. Po dlouhém pátrání přijdou na to, že někdo na nasadil šifrování čísel sociálního pojištění (obdoba našeho rodného čísla a zákonu o jeho utajení), které způsobilo nevalidní data v databázi. Postupně se ukazuje, že změna nebyla testována (nebylo testovací prostředí) a někdo tu změnu propašoval bokem mimo jakýkoliv changemanagement.

The only thing more dangerous than a developer is a developer conspiring with security. Information security is always 8ashing their badges at people and making urgend demands, regardless of the consequences to the rest of the organization

Hlavnímu hrdinovi jde hlava kolem z množství práce, která na IT oddělení padá. Z pohledu zákazníků IT oddělení (business, marketing atd.) to vypadá, že všechny jejich projekty jsou zpožděné a i ty nejjednodušší požadavky trvá vyřídit neúměrně dlouho. Jak se brzo ukáže, tyto požadavky jsou jenom jednou čtvrtinou toho, co IT běžně řeší nebo je po něm požadováno. S tím by se mělo počítat a zohlednit při odhadu výkonu/propustnosti týmu.

• business projekty — úkoly vycházející z potřeb core businessu např. udělějte feature XYZ
• interní IT projekty — úkoly, které si stanovuje IT, aby mohlo efektivně fungovat např. vývoj monitorovací infrastruktury, nástroje pro vývoj, sběr a analýza logů
• změny — nasazení záplat, změna konDgurace, deploy nových mašin a jiné záležitosti související s operačními požadavky na doručované aplikace/skužby
• neplánovaná práce — urgentní požadavky mimo plán např. řešení incidentů, hotDxy

Tyhle čtyři zdroje činností IT se perou o sdílené zdroje. První věci, kterou náš hlavní hrdina udělá, a vy byste měli rovněž, je rozdělení plánování zdrojů na tyto čtyři oblastí a identiDkace omezení, která způsobují, že se tyto čtyři činnosti vzájemně blokují. V případě knihy a jejího děje je omezením DeusEx machina vývojář Brent, na kterém se sbíhají všechny důležité požadavky.

Vybudujte zeď

Processes are supposed to protect people. We need Agure out how to protect Brent.

Před Brenta doslova a do písmene postaví zeď v podobě manažera, přes kterého přicházejí všechny požadavky. Bylo totiž zvykem Brentovi přímo volat nebo posílat emaily s tím, že něco je potřeba udělat teď hned a urgentně. Brent potom nedělal nic jiného kromě Neplánovné práce přestože byl potřeba na projektu Phoenix. S Brentem pracují tři vývojáři, aby se předalo jeho know how dál. Postupně se podaří požadavky kategorizovat, zdokumentovat jejich zpracování a nakonec jejich vyřízení kompletně přeberou další vývojáři. Brentovi ruce jsou potom kompletně k dispozici projektu Phoenix.

Unlike other categories of work, unplanned work is recovery work, which almost always takes you away from your goals. That’s why it’s so important to know where your unplanned work is coming from.

Z tohoto minipříběhu plyne ponaučení, že úkoly by se měly lidem předávat řízenou formou a měl by pro ně existovat jeden zdroj. V knize používají Kanban a co není na Kanbanu, na tom se nedělá. Je velmi přínosné, aby se spolu lidi bavili o tom, co je potřeba udělat. Žádná věc, a to ani v IT, se ovšem nestala jenom protože jste o ní s někým mluvili nebo poslali skupinový mail. Samozřejmě pokud u vás nefunguje bájná skupina japonských inženýrů Onoseto a Samoseto. Bez jednoho autoritativního zdroje práce vám hrozí, že budete pracovat jenom na neplánované práci. Navíc ani nebudete schopni identiDkovat její zdroj a způsob jak ji eliminovat.

Unplanned work kills your ability to do planned work, so you must always do whatever it takes to eradicate it.

Work In Process

V metodologii Kanban vývoj funguje podobně jako výrobní linka v továrně. Na vstupu je úkol/zadání, které pluje přes jednotlivé fáze linky. Pro nové features může linka může mít linka fáze — návrh, kódování, testy a deploy. Pro provisioning nových strojů to může být — alokace hardwaru, konDgurace, instalace software a předání. Když je úkol uvnitř výrobní linky má označení Work In Process (zkráceně WIP). Úkol je splněný až ve chvíli kdy opustí výrobní linku. Čím více úkolů máte paralelně ve výrobní licence, tím více WIP úkolů tj. práce která stále nebyla dokončená.

Remember, outcomes what matter — not to the process, not controls, or, for that matter, what work you complete

V našem příběhu se ukáže, že důvodem proč má IT oddělení cokoliv doručit včas je právě vysoký počet WIP úkolů. Díky analýze se přijde na to, že zdrojem WIP je Brent, na kterém se všechno sbíhá a úkoly musí čekat, než je postupně vyřeší. Dalšími faktory ovlivňujícími WIP je technologický dluh Drmy. Nakonec hlavní hrdina sáhne k poměrně drastickému opatření a po určitou dobu zakáže přijímání dalších úkolů dokud si nedokončí aktuální WIP úkoly. Znovu otevření je možné jenom pro úkoly resp. výrobní linky, které nezávisí na jejich klíčovém omezení 

— Brentovi.

Proč je důležité nedělat všechno

Hlavní hrdina si velmi rychle uvědomí, že tempem kterým na IT oddělení padají nové úkoly dojde dříve nebo později k opětovnému zahlcení a růstu WIP. Výsledkem bude, že IT oddělení nebude schopné dostát svým závazkům a vše se bude opožďovat proti plánu. Na scénu vstupuje mentor Erik, který vysvětluje, že nikoliv všechny úkoly, které na IT padají z venku jsou skutečně potřeba. Klíčem je pochopit, které z těch úkolů souvisí s cíli společnosti.

Společně s hlavním hrdinou postupně navštěvujete jednotlivá oddělení (marketing, prodej atd.) s cílem pochopit, jak se cíle společnosti odrážejí v jejich práci. To mu umožňuje identiDkovat jejich klíčové potřeby vzhledem k IT a zároveň pochopit, čím by je mohlo IT ohrozit. Jedním ze zdrojů velkého množství úkolů jsou výsledky auditu. Nakonec se ukáže, že díky toku zpracování Dnančních transakcí je možné velkou část IT systému vyjmout z auditu a snížit počet úkolů.

Remember, it goes beyond reducing WIP. Being able to take nedless work out of the system is more important than being able to put more work into the system. To do that, you need to know waht matters to the achievement of the business objectives, whether it’s projects, operations, strategy, compliance with laws and regulations, security, or whatever

Poznámka pod čarou: a z toho plyne ponaučení, že výsledky auditu lze vykládat stejně pružně jako naší ústavu.

Velké projekty nefungují a velké DevOps -nále

Hlavní hrdina dochází k závěru, že projekt Phoenix, který se jim v potu tváře nakonec podaří nasadit, vlastně není úplně potřeba vzhledem k cílům společnosti. Jinými slovy, že práce mnoha lidí a miliony

investovaných dolarů padnou vniveč a tím pádem i naděje Drmy na přežití. Jedním z posledních záchvěvů naděje je sestavení týmu, který by v krátkém čase implementoval projekt umožňující lepší zacílení prodejní kampaň. V týmu jsou obsazeni nejenom lidé z developmentu, ale i z operations a businessu. Co vám mám povídat, je to happyend. Projekt je doručen přesně na čas před Černým pátkem (den kdy američané nejvíce nakupují) a umožňuje Drmě dosáhnout nejlepší výsledků za několik let. Firma je zachráněna a nehrozí její prodej na části s outsorcováním IT do Bengalore.

Velké projekty většinou nefungují, protože stojí moc peněz a nikdy se je nepodaří doručit včas. Rozhodujícím faktorem je takzvaný Time to market, tedy jak rychle se vám podaří dostat konkrétní produkt na trh. Není potřeba, aby byl dokonalý, je potřeba aby tam byl. Je to o zkoušení co by se mohlo uchytit, protože dokud to nezkusíte, nemůžete vědět, jak jej zákazníci přijmou a nebo jak zareaguje vaše konkurence. Všechny tyto atributy hrají do karet proti velkým projektům.

Cílem knihy je provést čtenáře změnou organizace a fungování IT, která se nazývá Three Ways.

The First way is all about controlling the 8ow of work from Development to IT operations.

The Second way is about creating constant feedback loops from IT operations back into Development, designing quality into the product at the earliest stages.

The Third way is about creating a culture that reinforces the value of taking risks and learning from failure and the need for repetition and practice to create mastery

Závěr

Žádný článek popisující knihu nemůže být stejně vyčerpávající jako vlastní kniha, mnoho zajímavých informací a z nich plynoucích konsekvencí jsem musel vynechat — nezůstalo místo na zkrácení dodacího cyklu z devíti měsíců na dny tj. reminiscence continuous delivery, nemohl jsem se ani věnovat tomu, proč je důležité nechat lidem nějaký volný pracovní čas — možná to napravím v některém z dalších článků. Jsem v pokušení napsat, že pokud to s DevOps myslíte vážně, představuje pro vás tato kniha povinné čtení. Nebyla by to ovšem celá

pravda, protože tato kniha nabízí podle mých zkušeností zcela reálný popis toho jak funguje IT oddělení valné většiny Drem.

When IT fails, the business fails. It stands to reason that if IT is organized so that it can win, the business wins, too.