Leading the Transformation

Leading The Transformation
Gary Gruver i Tommy Mouser
IT Revolution, Portland, OR, 2015

3

Przyciągający, znakomity marketingowo tytuł tej pozycji jest mocno mylący. I ja sięgnąłem po nią, dając się zwabić napisem widocznym na grzbiecie. Do całości dodać trzeba tymczasem podtytuł: “Applying Agile and DevOps Principles at Scale” (stosując zasady agile i DevOps na dużą skalę – tłum. autor, dalsze takowoż).

Rzecz nie dotyczy bowiem tego, jak przewodzić agile’owej transformacji w organizacji, jak ją prowadzić, a skupia się na dostarczeniu wiedzy o tym, jakich narzędzi technicznych, jakie środowisko pracy należy zbudować w dużym dziale IT, aby działał on efektywnie.

Tym lepiej – pomyślałem na początku, zatapiając się w lekturze. Książek omawiających w praktyce, z przykładami, jak można zorganizować nowoczesny i wydajny proces wytwórczy w dziale IT, w którym zespoły pracują zgodnie z duchem agile, mamy bowiem jak na lekarstwo. Takie tematy funkcjonują gdzieś z boku w ramach większych książek całościowo omawiających Scruma czy agile’a, gdzie z kolei przedstawiane są mocno fragmentarycznie.

A tutaj z każdą początkową stroną czytelnik nabiera apetytu – mamy studium przypadku z dużej, uznanej korporacji (HP), wprowadzenie agile i DevOps do jednego z kluczowych projektów, niezwykle trudną domenę biznesową (HP LaserJet – drukarki laserowe), gdzie mamy do czynienia nie tylko ze skomplikowanym oprogramowaniem, pisanym w zapomnianych już dziś językach, ale przede wszystkim hardware. Do tego autorzy, którzy wszystkie te zmiany wprowadzali i wspierali, pokazują jakie efekty przyniosła im opisywana długa, ponad trzyletnia droga, a wśród nich rozbudzającą wyobraźnię redukcję kosztów wytwarzania z ~100M $ do ~55M $. Od razu wskazują też, że książka skierowana jest do pionu zarządczego IT w dużych firmach (100+ inżynierów). Nieraz autorzy wbijają lekką szpilę ludziom na tym stanowisku, sugerując jakoby były to osoby cechujące się szczególną idiosynkrazją do wszelkich zmian, a już w szczególności tak dużych zmian, jak wprowadzenie agile czy DevOps. Prawda to? Jakie są Wasze doświadczenia?

Książka zawiera wystarczającą ilość teorii do uświadomienia kadry zarządzającej o najważniejszych aspektach i wystarczającą ilość szczegółów, aby wyjaśnić co jest istotne i dlaczego – zachęca w blurbie sama Mary Poppendieck. No i właśnie… Wyjątkowo muszę się z nią nie zgodzić.

Na niespełna 110 stronach makulaturowego papieru znajdziemy bowiem, napisany dość ciężkim piórem, nieco nazbyt powtarzalny, zestaw bardzo ogólnych wytycznych dotyczący tego, jak trzeba działać, a wskazane wprost konkretne techniki, mechanizmy, sposoby działania, są przedstawione nazbyt teoretycznie, autorzy straszliwie skąpią nam przykładów, a odwołując się do własnej firmy przedstawiają truizmy, bardzo ogólne przykłady, lub niewiele warte ochłapy szczegółowych informacji.

Gruver i Mouser ewidentnie przyjęli tryb: zdawkowo, zwięźle, tylko najważniejsze rzeczy. Rozdziały są krótkie, jakby z góry przyjęto założenie, że odbiorca – CTO, dyrektor czy menedżer IT – na szersze lektury nie ma czasu lub cierpliwości. Zaczynają od totalnych podstaw, tłumaczenia sensu zwinności i ruchu DevOps w IT, tego, że tradycyjne metody nie mają już w tej chwili szans.

Jest i parę smakowitych cytatów:

Najważniejszym brakującym czynnikiem w naszej branży są zaangażowani kierownicy, którzy chcą poprowadzić zmianę i nakręcać, motywować do zmiany kultury pracy w firmie.

czy

Menedżerowie muszą zrozumieć, że drugą, obok zaangażowania się w nieustające udoskonalanie całego procesu, ich najważniejszą rolą, jest przywództwo w kwestii zmiany kulturowej organizacji. (…) Jeśli tego nie zrobią, wszystkie inne wysiłki będą stratą czasu.

Tego typu ostre, oschłe słowa skierowane w stronę kadry zarządczej padają tu często. To ważne, że autorzy nieustannie akcentują, że bez zrozumienia i wsparcia “góry”, można zapomnieć o całej tej zabawie. Uporczywie wracają także do tematu wizji, celów biznesowych, uwydatniają – rzecz niby oczywistą – że wprowadzając agile, Scruma, DevOps czy cokolwiek innego z “rodziny”, musimy wiedzieć po co to robimy, w jakim kierunku zmierzamy, co chcemy osiągnąć…

Poruszają również jak ważne jest, aby w całej firmie dobrze przedstawić na czym polega wyjątkowość specyfiki wytwarzania oprogramowania, poziom skomplikowania, nietrywialność i unikalności tego procesu. I zapewnić, że będzie to powszechnie zrozumiałe poza IT.

Ważnym spostrzeżeniem, którym się z nami dzielą jest też to, że inżynierowie/deweloperzy będą z pewnością przeciwni przejściu na nowy, prezentowany tutaj tryb pracy. Że będą oponować, mówić, że to nierealne, że u nas nie zadziała…

Mniej więcej w połowie książki przechodzimy do konkretów. W telegraficznym skrócie pędzimy przez elementarz współczesnej organizacji pracy w IT. Szczególną uwagę autorzy poświęcają procesowi wdrożeń, testów, znajdowaniu błędów, pracy z systemem kontroli wersji, środowiskom testowym. A zatem tematom, które niejednym menedżerom spędzają sen z powiek. Rzeczom niby trywialnych, które niby wszyscy wiedzą jak to robić, a wychodzi, jak wychodzi..

Gruver i Mouser serwują nam zestaw wszystkich najważniejszych i sprawdzonych dobrze w boju współczesnych trendów, w skrócie: automatyzacja, automatyzacja, automatyzacja… A dokładniej: Continous Delivery, Continous Integration, trunk development, zwinna architektura, wydajne środowiska testowe i produkcyjne, Evolutionary Database Design, wykorzystanie orkiestratorów, odpowiednio skonfigurowany deployment pipeline, częste wydania, małe porcje, stabilny trunk, wspólne i dobre onarzędziowanie w ramach wszystkich zespołów pracujących nad tym samym produktem, jak najszybsza informacja o znalezionym w kodzie błędzie… Panowie podkreślają wszakże, że w tym wszystkim szalenie istotne jest działanie metodyczne, krok po kroku, a nie wprowadzenie wszystkiego na raz.

Brzmi jak fajne kompendium, prawda? Sęk, jak wspomniałem, w tym, że zbyt mało w tym wszystkim konkretów, wszystko to zbyt powierzchowne, teoretyczne lub pokazane na bazie zbyt trywialnych przykładów. To za mało, nawet jeśli ideą były krótkie zajawki najważniejszych haseł do rzucenia do realizacji specjalistów, nawet w stylu: tu macie wytyczne, róbcie… No chyba, że aż tak źle ze światowym IT, że na najwyższych szczeblach trzeba dopiero wprowadzać wymienione już wyżej pojęcia…

W wielu miejscach autorzy odsyłają po więcej informacji do książki A Practical Approach to Large-Scale Agile Development (jednym z trzech współautorów jest Gruber), tam cała historia transformacji HP opisana jest rzekomo szerzej. Niby kusi, ale po tej lekturze podchodzę jednak do tej pozycji z dużą podejrzliwością…

Czy warto podrzucić tę książkę menedżerom IT w swojej firmie? Na pewno nie zaszkodzi. Pamiętajmy jednak, że to wypełniony ogólnikami elementarz. Prędzej widzę jego przydatność dla mniej świadomego, mniej zaawansowanego pod kątem technicznym Scrum Mastera, pracującego w/z większym (dajmy na to: 30 lub więcej osób) dziale IT, który zdobędzie wiedzę o tym, czego nie wie… A po co mu ta wiedza – żachną się pewnie co niektórzy. Ano po to, że jeśli – jako Scrum Masterzy – chcemy uzwinniać, przekształcać średnią lub dużą firmę, działać z sukcesem w okołoscrumowo-agile’owej kulturze, musimy mieć znakomity proces pod kątem technicznym. Nie musimy go kreować, nie powinniśmy odpowiadać za jego realizację, ale na pewno musimy go rozumieć i wspierać to, żeby powstał i podlegał ciągłemu udoskonaleniu. A wracając do tego, na co najmocniej naciskają autorzy – żeby to wszystko miało ręce i nogi potrzebne będzie nie tylko błogosławieństwo, ale i silne zaangażowanie “góry”. Wprowadzenie tego wszystkiego w życie to robota całego działu IT pod ich dowództwem, z silnym wsparciem Scrum Masterów.

Można zatem dzięki tej książce – dostępnej wyłącznie w wersji anglojęzycznej – zapoznać się z najnowszymi trendami w zakresie onarzędziowania i oprocesowania większego działu IT, posiłkować się nią w celu pokazania co w trawie piszczy,  możemy serwować tu i ówdzie co ciekawsze z niej cytaty…

#technikalia