Agile (Scrum) w dużej organizacji

Dnia 16 kwietnia 2014 miałem przyjemność uczestniczyć w seminarium organizowanym przez Warszawski oddział PMI, którego tematem były praktyczne doświadczenia dużej organizacji w zwinnym rozwoju oprogramowania. Oprogramowanie tworzono w metodyce Scrum. Seminarium prowadził Cezary Zieniewicz Scrum Master wspomagający swoją sztuką centrum rozwoju aplikacji NSN – Nokia Solutions and Networks (NSN) we Wrocławiu.

Wrocławskie centrum NSN specjalizuje się w rozwoju oprogramowania dla infrastruktury sieci komórkowej (np. BTS). Jest to produkt, którego oprócz inżynierów zajmujących się budową i obsługą sieci komórkowych nikt nie ogląda ale absolutnie wszyscy oczekują, że będzie działał perfekcyjnie.

Dobre narzędzie to popularne narzędzie

Seminarium zaczęło się od prezentacji narzędzi używanych w procesie budowy oprogramowania. Wybór dobrych narzędzi wspierających rozwój oprogramowania ma podstawowe znaczenie, zwłaszcza w metodykach zwinnych kiedy, kiedy łatwo sprowokować kontestację i sprzeciw narzucając narzędzie niepoważane. Dlatego dobre narzędzie to popularne narzędzie. Rozwiązania egzotyczne pociągają za sobą dodatkowe koszty szkolenia. Tworzenie własnych rozwiązań to także ślepy zaułek. Grupa twórców – entuzjastów jest zwykle mała i narażona na ryzyko utraty krytycznych zasobów, ludzie odchodzą do innych organizacji lub innych zadań. Wśród stosowanych narzędzi wymieniono:

  • Jenkins – automatyczne budowanie wersji oprogramowania
  • googletest – narzędzie do testów
  • SVN – Apache Subversion
  • Crucible – kontrola jakości kodu
  • DOORS – oprogramowanie IBM do zarządzania wymaganiami

Wybór narzędzi jest procesem ciągłym. Przez pewien czas centrum używało IBM Rhapsody, jednak to narzędzie  nie sprawdziło się. Kod tworzony na podstawie rysunku (diagramu funkcjonalności) był bardzo trudny do zrozumienia przez człowieka, co utrudniało testy. Możliwości tworzenia testów z rysunku zaś nie było. Ponieważ testy automatycznie tworzonego kodu były koszmarem, zdecydowano się na odstawienie narzędzia. Spowodowało to redukcję rozmiaru kodu o 50% i przyśpieszyło cykl rozwoju. Jak widać automatyzacja nie zawsze prowadzi do spadku kosztów.

Zespół czyli ludzie przed procesami

Organizacja, która chce wdrożyć zwinny rozwój oprogramowania musi dbać o ludzi, bo w głowach ludzi jest pamięć organizacji. Rotacja zespołu szkodzi szybkości i jakości produkcji oprogramowania. Nie na darmo pierwsza zasada Agile Manifesto to “Individuals and interactions over processes and tools”. Scrum to władza zespołu nad problemem. Zespół musi być kompetentny i mieć warunki do pracy. Zespół musi mieć też widoki na sukces, bo bez niego popada w zgorzknienie co dramatycznie obniża wydajność pracy. Tworzenie zespołu i dobór jego członków jest krytyczne dla ostatecznego sukcesu. Zespól tworzy resource manager on dobiera ludzi i odpowiada za sprawdzenie ich kompetencji. Zespół nie może być ani za mały ani za duży, w centrum NSN przyjęto, że może on liczyć od 5 do 9 programistów, optymalna wielkość to 6-7.

Dobry zespół ma stabilną szybkość pracy i jest przewidywalny. Oczywiście są też zespoły złe, które nie dowożą wyników. Naprawa złych zespołów jest zadaniem resource managerów. Mogą oni wymieniać poszczególnych członków zespołów w ramach oceny okresowej lub mieszać złe zespoły z dobrymi. To drugie oczywiście niesie ze sobą ryzyko stworzenia dwóch złych lub dwóch dobrych zespołów.

Agile powoduje odkorkowanie inicjatywy. Ujawniają się jednostki kompetentne i kreatywne, które dzięki samoorganizacji potrafią osiągnąć doskonałe wyniki. Warunkiem jest przekazanie części władzy w ręce programistów. Oczywiście jeżeli kompetencje członków zespołu są niskie wprowadzenie metodyki Agile ich nie zwiększy. Możemy nawet osiągnąć gorszy niż przy klasycznym zarządzaniu  rezultat. Scrum w słabym zespole nie działa i stanowi zagrożenie dla organizacji, pasywny zespół trzeba wzmocnić lub zarządzać nim w inny sposób. Scrum to zabawa dla ambitnych, którym daje możliwości wykazania się.

Odpowiedzialność za budżet

Scrum odwraca hierarchię, mamy X ludzi ile zrobią zależy od tego jak dobrzy są i jak dobrze pracują. Zespół nie ma narzuconych odgórnie norm wydajnościowych, jego istnienie jest stałym kosztem, warunkiem koniecznym lecz nie dostatecznym dla stworzenia wartości. Użyteczność pracy zespołu dla organizacji w olbrzymim stopniu zależy od Product Ownera, który określa jak ma wyglądać produkt i potrafi poznać i przekazać zespołowi w jakim stopniu kolejne iteracje produktu spełniają jego (i organizacji) oczekiwania. Mamy tu do czynienia z ciągiem prototypów, które w każdej kolejnej iteracji zbliżają nas do celu. Nie występuje faza detalicznego planowania i dokumentowania produktu, obowiązuje zasada “Working software over comprehensive documentation”.

Organizacja tworząca produkt musi umieć ocenić jego wartość. Koszty wytworzenia szacuje się na podstawie prędkości pracy zespołu, którą trzeba zmierzyć. Dobry zespół jest przewidywalny, po kilku iteracjach dość dokładnie wiadomo w jakim czasie zadanie może być wykonane. Kwestionowanie terminów podawanych przez zespół jest ryzykowne. Straty wynikające z przyjęcia nadmiernie optymistycznych terminów są większe niż koszty dodatkowej pracy i czasu. Scrum jest metodologią marchewki, nie kija. Zespół pracuje najlepiej jak potrafi bo usuwamy problemy ograniczające jego wydajność. Do administracyjnego wyciskania nierealnych terminów potrzebna jest inna metodologia, roboczo można nazwać ją Scam…

Scrum nie był stosowany przez biznes, tam stosowano zarządzanie przez cele. Oczywiście powodowało to rozbieżności w ocenie tego co jest realne do wykonania. Początkowe oszacowania na górze i na dole organizacji bardzo się różniły. Potrzebny kompromis osiągano raczej manewrując zakresem prac niż parciem na zwiększenie wydajności. Lepiej zrezygnować z nierealnych celów niż tracić zasoby na ich osiągnięcie. Paradoksalnie ciśnienie na większą wydajność może skutkować większym opóźnieniem, bo rośnie liczba błędów i spada motywacja zespołów, które nie widzą szans na sukces.

Scrum Master i jego rola

Scrum Master nie jest kierownikiem zespołu, nie jest także do końca jego członkiem. Jest buforem pomiędzy zespołem programistów a przeszkodami, które nie pozwalają na osiągnięcie pełnej wydajności. Jest sługą i przywódcą zespołu w jednej osobie. Jego rola może być niewdzięczna, bo równie łatwo obciążyć go winą za niepowodzenia zespołu jak odmówić udziału w sukcesach. Scrum Master odpowiada za przestrzeganie metodyki pracy zespołu i powinien mieć wyobrażenie o naturze jego pracy. Brak technicznych kompetencji prowadzić może do dogmatycznego trzymania się metody a czasem trzeba odpuścić Daily Scrum meeting jeżeli akurat nie ma potrzeby jego przeprowadzenia. Dobry Scrum Master czasem kupi ciastka dla podbudowania nastroju i wie, że dobrze traktowany zespół wszystko co dostał odda z nawiązką. Doświadczenia NSN pokazały, że jeden Scrum Master może opiekować się dwoma zespołami programistów, większe obciążenie na ogół prowadzi do jego przeciążenia i wypalenia. Lektury polecane dla scrum mastera i nie tylko:

Product Owner i jego zadania

Product Owner reprezentuje interesy organizacji i jej klienta. W przypadku centrum rozwoju aplikacji jego rola jest trudna, bo nie ma stałego kontaktu z klientem końcowym, więc nie zna odpowiedzi na wszystkie pytania zespołu. Nie angażuje się też w bieżące prace zespołu więc szybko traci kompetencje techniczne.  Prowadzi to do alienacji Product Ownera, bo coraz mniej rozumie zespól a klienta (który rezyduje np. w Korei) widuje rzadko i na ogół przy okazji tłumaczenia się za duże błędy. Specyfika tworzenia oprogramowania do BTS wymagała dużej wiedzy technicznej Product Ownera, który bez niej nie był w stanie ani zdefiniować pracy dla zespołu ani jej odebrać w trakcie sprint rewiew. Bez aktualnej wiedzy technicznej Product Owner tracił wiarygodność wobec zespołu. Początkowo jeden Product Owner zlecał pracę 6 zespołom, ale ponieważ jego obciążenie było zbyt duże (według naocznych świadków wyglądał jak zombie) liczbę tę zredukowano do maksymalnie 4.

Scrum w dużych zespołach

Duży projekt może wymagać zaangażowania wielu zespołów programistów, inaczej nie da się go skończyć w rozsądnym czasie. W konsekwencji trzeba także wprowadzić hierarchię Product Ownerów. Potrzebna jest też osoba, która będzie miała wizję całego systemu i wyznaczała kierunki rozwoju. W centrum NSN taką rolę pełnił Chief Architect.

Duże projekty realizowane są przez zespoły międzynarodowe, kod tworzony jest w Azji, Europie i Ameryce, produkcja trwa 24 godziny na dobę. Trzeba dbać o właściwą komunikację, inaczej może kazać się, że Zespoły Chińskie nie wiedzą czegoś, co w Polsce jest oczywiste i vice versa. Dodatkowym problemem są różnice kulturowe, wspomniany Chińczyk nie przyzna się do niewiedzy, bo w jego kulturze oznacza to utratę twarzy. W międzynarodowym zespole programistów trudno jest utrzymać jednolitą jakość kodu, czasem jest ona na tyle niska, że dana gałąź rozwoju aplikacji przestaje się kompilować i trzeba ją zamknąć (zablokować możliwość dostarczania nowego kodu) do czasu usunięcia starych błędów. W utrzymaniu dyscypliny programistów pomaga wizualizacja wyników pracy na monitorach rozmieszczonych w centrach. Wskazują one które części kodu mają problemy jakościowe, ile jest błędów i który zespół jest ich źródłem. Pomimo początkowo sceptycznego przyjęcia taki sposób dyscyplinowania zespołów programistów okazał się bardzo skuteczny motywując odstających do poprawy jakości pracy.

Zapewnienie jakości produktu

Produkcja oprogramowania to nieustanne niezadowolenie z efektu. Programista ma tworzyć kod i testy pisanego kodu. Brak nawyku budowy testów unitowych w zespole jest niezawodną przepowiednią problemów z jakością kodu. Scrum Master nie jest kluczowy dla jakości produktu. Jego zadaniem jest wdrożenie rutyny i nawyku tworzenia testów razem z kodem. Dobry zespol dziala dla wlasnej przyjemnosci, której częścią jest tworzenie dobrego produktu. Trzeba przyjąć, że połowa czasu zespołu to kodowanie. Resztę zajmują spotkania i testy.

Osobnym zagadnieniem jest dokumentacja kodu. NSN stosowało dokumentację dla programistów ale zrezygnowano z niej. Powodem była permanentna niezgodność dokumentacji z kodem. Zamiast dokumentacji dla programistów wprowadzono zasady dokumentowania kodu i rolę Code Guard, który strzeże ich przestrzegania.  Uzasadnienie jest proste: Celem dokumentacji kodu jest ułatwienie przejęcia jego rozwoju przez innego programistę jeżeli autor jest niedostępny (np. odszedł z organizacji). Code Guard jest programistą, kod który sprawdza jest dla niego obcy. Jeżeli jest w stanie go zrozumieć to znaczy, że inny programista może przejąć dalszy rozwój sprawdzanego kodu. Taki poziom dokumentacji uznajemy za dostateczny. Working software over comprehensive documentation.

Organizacja pracy zespołu

Zespół procował w 2 tygodniowych spintach. W wyjątkowych przypadkach czas sprintu wydłużano do 3 tygodni. Obowiązywała zasada, że zespół, który stworzył kod usuwa błędy w tym kodzie. W związku z tym zespół musiał alokować zasoby do usuwania błędów, średnio były to dwie osoby. Oczywiście zasoby alokowano dynamicznie, jeżeli błędów nie było wszyscy mogli tworzyć nowy kod. W organizacji stworzono rolę Inwestygatora, który potwierdzał, że zgłoszony błąd jest błędem kodu, określał w którym miejscu występuje i przekazywał do odpowiedniego zespołu programistów. Błędom nadawano priorytety. Najwyższy priorytet miały błędy zgłoszone przez klienta.

Istotnym zagadnieniem jest zarządzanie wiedzą w zespole. Należy unikać koncentracji wiedzy w pojedynczych osobach. Teoria Scrum mówi o pełnej wymienności członków zespołu, ale trudno jest to osiągnąć w praktyce. Dobrym rozwiązaniem jest dzielenie wiedzy w parach. Zespół powinien stanowczo unikać tworzenia osób niezastąpionych. Rolą Scrum Mastera jest wczesne ostrzeganie przed taką sytuacją. Zespół musi mieć rezerwy czasu na rozwój. Jako normę przyjęto 2 szkolenia zewnętrzne po 3 dni w roku dla każdego członka zespołu. Za planowanie i organizację szkoleń odpowiada resource manager.

Podsumowanie skuteczności Scrum

Wrocławskie centrum powstało z połączenia zespołów Nokii i Siemensa. W organizacji Siemensa obowiązywało podejście klasyczne. Wszystko dokładnie planowano, tworzono bardzo dużo papieru. Podejście zwinne przyszło z Finlandii i zdobywało uznanie stopniowo. W ciągu 4 lat z 7 zespołów Scrum zrobilo sie 14. Średnia rotacja product ownerów i scrum masterów wynosiła 2 lata. Co ciekawe Scrum sprawdził się także jako metoda konkurowania o programistów. Credit Suisse otworzył we Wrocławiu centrum produkcji oprogramowania, gdzie używano systemu nakazowego do zarządzania zespołem. Nowe centrum podebrało część programistów NSN oferując lepsze warunki finansowe. Jednak po jakimś czasie zdolni ludzie wrócili. Widocznie większe pieniądze nie rekompensowały braku władzy nad problemem, którą dawał Scrum i wynikającej z niej przyjemności pracy.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.