Poradenství v IT při vývoji software může mít různou formu, ale některé typy spolupráce se opakují, proto jsem si je dovolil popsat podrobněji.
Audit organizace
V poradenské činnosti dávám přednost dlouhodobému partnerství se zákazníkem. V dlouhodobém partnerství je klíčové, abyste svého partnera znali – díky tomu mu dokážete dobře poradit. Proto si obvykle na začátku spolupráce uděláme společně přehled o tom, co vaši firmu momentálně trápí a pokusíme se zjistit, jestli existuje způsob, jak vám s tím pomoci.
Sparring partner
Chcete udělat nějaké důležité rozhodnutí? Chcete si urovnat myšlenky? Promyslet si další postup? Potřebujete vyhodnotit alternativy? V takových situacích dokážu sloužit jako sparring partner – jako někdo, kdo zná vaše problémy, protože byl na podobném místě, kde jste teď vy. Můžu vám dát zpětnou vazbu na naše nápady předtím, než je začnete ve firmě realizovat.
Poradenství při sestavení a vydávání produktu
Nejen psaním kódu živ je programátor. Abyste dostali svůj software do produkčního prostředí, je třeba ještě něco navíc. Na začátku to může být jednoduché jako nakopírování binárních souborů na server. Dříve nebo později ale budete potřebovat něco čemu se říká Build Pipeline.
Pokud na vývoji vašeho produktu pracuje více týmů, můžete mít problémy se sjednocením verzování různých částí, dlouhým časem pro stabilizaci finálního buildu, nestabilitou a dlouhým trváním testů nebo řetězcem manuálních kroků, který je potřeba k vytvoření produkční verze.
Správné nastavení buildovacího procesu je důležité k tomu, aby neblokovalo vaše týmy při vývoji a mohli se soustředit na vylepšování produktu. Přináším zkušenosti z několika firem, ve kterých jsem pracoval na vymýšlení a implementaci buildů, které pracovaly se stovkami repozitářů, kompilovaly miliony řádků kódů a pouštěly desítky tisíc testů. A mimochodem, věděli jste, že přes vaše buildy se dá provést Supply Chain Attack?
Služba probíhá formou konzultace přímo u vás ve firmě.
Test-Driven Development
Máte pocit, že vývoj software ve vaší firmě už nejde tak rychle jako dřív? Hlásí vám zákazníci hodně chyb? Tráví vaši vývojáři hodiny a hodiny hledáním chyb? Pak je pro váš tým vhodný Test-Driven Development. Na první pohled to vypadá nelogicky – vývojáři stráví dvakrát tolik času psaním kódu, protože píšou navíc ještě testy. Dlouhodobý efekt je ale ten, že pak netráví téměř žádný čas laděním a hledáním záhadných chyb, protože takové chyby v kódu, který byl napsán pomocí TDD, typicky vůbec neexistují. Vývojáři vám poděkují za to, že nemusí v práci trávit večery a zákazníci za to, že váš produkt je bez chyb. No a váš šéf vás pochválí za to, že vývoj se nezpomaluje, i když produkt a firma roste.
Jelikož TDD je poměrně obtížná technika, její naučení probíhá ve dvou fázích. První fáze je jednorázové školení. Trvá 1-2 dny a na něm se vývojáři naučí, jak používat TDD na jednoduchých “školních” příkladech. V průběhu školení jdeme postupně od nejjednodušších situací k těm složitějším, nicméně ze zkušeností není možné na školení pokrýt všechny situace, které ve svém produktu máte – zvláště pokud byl kód napsaný původně bez testů, tak se testy zpočátku velmi špatně pokrývá.
Proto obvykle navazuje druhá fáze – mentoring. V ní se vývojáři učí používat TDD na kódu vašeho produktu, konkrétně na těch částech produktu, na kterých je zrovna potřeba pracovat. Tato fáze může trvat několik týdnů (v menší intenzitě i měsíců) a já při ní působím jako mentor vašich vývojářů. Účastním se běžné práce na produktu, typicky pomocí párového programování a starám se o to, aby TDD přešlo vývojářům do krve.
Motivace ke spolupráci
Když vaše firma překročila počet pěti zaměstnanců museli jste si mezi sebou nějak rozdělit práci. Pak firma rostla dál a museli jste do udělat znova. A pak ještě několikrát. A teď jste se dostali do stavu, kdy máte firmu s několika odděleními, každé dělá svoji práci, jak jste se dohodli a vy máte přesto pocit, že to nefunguje moc dobře. I přes to, že každý odvede svůj díl práce, zůstávají věci nedořešené a musíte je řešit vy nebo vaši vedoucí oddělení místo toho, aby se zabývali rozvojem firmy a naplňováním její vize. Chtělo by to pomoc s tím, aby zaměstnanci opravdu řešili problémy a ne jenom dělali práci podle popisu.
Na tomto jednodenním školení se dozvíte, jak se stát lepším lídrem a vést lidi k tomu, aby dělali to, co potřebujete – spolupracovali a táhli za jeden provaz. Povíme si o způsobech motivace, delegování odpovědností, nastavení prostředí pro spolupracující týmy.
Škálování vývoje software pro více týmů
Možná jste se už dostali do fáze, kdy se na vývoji vašeho produktu podílí více než 10 lidí a vy máte spoustu otázek. Jaké mám vytvořit týmy? Jak mají být velké? Kdo má být členem týmu? Chci mít nějaké lidi mimo tým? Jak má vypadat manažerská struktura? Kdo bude týmu nebo týmům zadávat práci? Mám vytvořit pozici vedoucího týmu? Chtěl bych použít Scrum, protože v malém nám dobře funguje. Potřebuju Scrum mastera? Potřebuju Product Ownera? A kolik jich potřebuju? A záleží na tom?
A to jsou jenom otázky, které se přímo týkají vývojového oddělení. Když se podíváme na celou firmu, okamžitě nás napadají další. Jak naplnit ten ambiciózní plán, který jsme slíbili investorům? Kde sehnat všechny ty lidi, které k tomu potřebujeme? Jak zajistit, aby vývoj běžel stejně rychle jako v době, kdy nás bylo ve firmě pět? Jak vlastně nastavit procesy ve firmě, např. odměňování nebo schvalování? Jak to udělat, aby všechna oddělení táhla za jeden provaz? A jaká oddělení vlastně ve firmě potřebujeme? A záleží na tom?
Tak bychom mohli pokračovat ještě dlouho. Nejsou to jednoduché otázky a odpověď na ně bude v každé firmě trochu jiná. Pravdou je, že i když máte agilní myšlení a nějaké zkušenosti se Scrumem nebo jinou agilní metodou, dá se v této fázi rozvoje firmy udělat spousta chyb, které se později těžko napravují. Trochu pomůže, když začnete studovat – číst knihy, jezdit na konference, bavit se s kolegy z jiných firem – a já to velmi doporučují.
Bohužel to obvykle nestačí, osobní zkušenosti jsou v tomto směru nepřenosné. Díky tomu, že jsem podobným procesem prošel v několika firmách (a ve dvou jsem ho vymýšlel a řídil), dokážu poradit, čeho se vyvarovat a na co naopak od začátku dbát.
Můj hodnotový systém vychází z myšlenek LeSSu, ale o LeSS vlastně vůbec nejde. Jde o to aplikovat důležité teoretické principy – systémové myšlení (systems thinking), lean thinking a zásady agilního manifestu a aplikovat je na praktickou situaci v konkrétní firmě tak, aby odpovídala zadání od vedení. A když říkám vedení, tak tím myslím nejvyšší vedení firmy. Ano, při škálování vývoje nestačí zapojit pouze vývojové oddělení, ale musí se změnit celá firma.