Chcete-li mít tým potažmo SW firmu opravdu efektivní, musíte se řídit pravidlem, že nikdo nevlastní kód ani jeho část. Narážíte-li na námitky vývojářů že to nejde, neboť jen oni opravdu rozumí dané části aplikace a ostatní by jim to jen zkazili, není to nikterak neobvyklé. Stačí věřit tomu, že to jde a mít schopnost zavést týmové metody spolupráce. Třeba Scrum proces nebo agilní metody řízení softwaru 🙂
Abyste mi věřili, že to je možné i ve velmi složitých prostředích kritických na jakoukoli chybu, přikládám následující case study.
Case Study – “NENAHRADITELNÝ JAMES”
Prostředí
Mezinárodní firma operující v life critical oblasti, přes 50% světového trhu v daném sektoru. Vývojová centra v několika zemích.
Projekt
Migrace všech aplikací na novou platformu pro divizi A. Přes 60 aplikací, čtyři odlišné architektury. Několik sdílených knihoven a klíčových oblastí.
Současně s migrací probíhal vývoj nových funkcionalit v rámci původních aplikací na originální platformě.
Původní stav
Každá sdílená oblast měla jednoho vlastníka (skupinu vlastníků), který oblasti skvěle rozuměl, a nikdo jiný nebyl oprávněn oblast měnit.
Nejvíce kritická situace nastala v klíčové knihovně využívané všemi 60 aplikacemi. Tu měl na starosti James, který ji před mnoha lety navrhl, vymyslel, naimplementoval a celou dobu dělal všechny potřebné změny pro jednotlivé aplikační týmy.
Vzhledem k jeho unikátním znalostem a komplexitě problému bylo řešení v lokálním měřítku optimální, a jeho kapacita stačila požadavkům okolí.
Koncový stav
Po startu migrace, začal být velmi rychle James zahlcený požadavky na změnu knihovny, která byla sdílená přes nové i staré aplikace a v rámci migrace se musela výrazně měnit. Nepomohlo ani to, že některé týmy navrhovaly přímo konkrétní implementaci řešení, kterou stačilo zrevidovat a použít. Čekací doba na změnu kritickou pro migrační projekty byla několik měsíců, což ohrožovalo projekt jako celek.
Řešením byla změna přístupu k této sdílené knihovně a odstranění unikátního postavení Jamese, který už nadále nemohl knihovnu vlastnit a být jejím výhradním přispěvovatelem. Z knihovny se stal sdílený kód, ke kterému měly přístup všechny týmy. Nebyly zpočátku sice tak efektivní jako James, ale průchodnost systému jako celku se odblokovala. Změny samozřejmě probíhaly za Jamesova dohledu a podléhaly revizi Jamese i týmu architektů, aby se předešlo problémům s kvalitou.
Podobné oblasti jsou ve všech větších firmách s komplexnějším prostředím a udělat z nich sdílený kód obvykle pomůže systému jako celku.
Naučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay, Skvělý ScrumMaster #ScrumMasterWay, Agilní lídr: Využití síly vlivu nebo Agilní Metody Řízení Projektů.
Tenhle postup je ideální a zbavení se odpovědnosti za chyby. Protože nleze říct kdo danou část podělal, takže všichni jsou z obliga.
Nikdo za nic tím pádem nemůže.
Od toho preci mame CVS, SVN, apod. Pak neni proble se podivat 😉
Přijde mi to trochu jako pohádka. Hlavně to, jak James byl zahlcený požadavky na změnu (ačkoli mu posílali i přímo implementaci) a pak kouzelná změna, kdy se kód stal sdíleným a změny se děly rychle, ačkoli na ně James dohlížel. Kde tedy bylo jádro problému? V tom, že James je pomalý programátor (těžko, pokud by dostával přímo implementované změny), nebo vázla komunikace (také nepříliš pravděpodobné, když ve 2. scénáři zvládal dělat revize změn).
Ono totiž největší problém není něco naimplementovat, ale dohodnout potřebné změny a zdokumentovat je. Což v případě knihovny, kterou používá 60 aplikací je obrovsky složité, pokud není možné používat několik verzí knihovny současně.
Na závěr – nemám nic proti sdílení kódu, myslím, že je docela běžné kód sdílet s tím, že změny se pokud možno konzultují s původním tvůrcem, jen mi uvedený příběh nepřijde příliš uvěřitelný.
Zodpovědnost za chyby? A ta snad leží na jediném vývojáři? Noční můra!
Realita prinasi obcas i vice neuveritelne pribehy nez pohadky…
Opravdu to tak bylo. Proc? Ja jsem odpoved hledala v tom, ze to byla velka spolecnost, tisice lidi. A tam ne vzdy leva ruka vi co dela prava. Vyrovnavat priority pres takhle velkou firmu uz je slozitejsi. A nez managovat bottleneck (cos James v tomto kontextu byl) bylo snazsi bottleneck rozsirit a v podstate odstranit.
Btw. Dokumentace neexistovala, takze ta nas “nezdrzovala” a domluvy o tom co to ma delat take ne, bylo to v podstate zrejme, to je vyhoda migrace.
Ve druhem scenari se mu zmenily priority a uvolnily ruce, neb uz nebyl zahlceny implementacnimi pozadavky na vyvoj novych veci. Delat revizi vsemu se zvladnout dalo, psat a vymyslet k tomu ale jeste polovinu zmen uz ne. A nekde tam byl duvod proc to jako sdileny kod fungovalo dobre.
Nesdílet kód znamená obrovské riziko pro firmu v případě, že se klíčovému pracovníkovi něco stane. Pokud je systém navržený jako robustní, jsou správně nastavena designová pravidla pro vytváření zdrojového kódu a pokud je vývojář zkušený a vytváří “čistý kód”, je sdílení snazší. Sdílení kódu úzce souvisí se sdílením znalostí ve firmě. Zastupitelnost jednotlivých rolí je dle mého názoru klíčová pro dlouhodobé týmové projekty.
Článek je fajn, díky!