Agile w Nokia Siemens Networks
23 kwietnia 2008 na Politechnice Wrocławskiej w ramach IT Days 2008 obył się wykład pt. “Agile techniques in big IT venture” poprowadzony przez Marcina Kołtonowskiego i Marka Majchrzaka z Nokia Siemens Networks (dalej NSN). Poniżej przedstawiam garść informacji o tym co na wykładzie można było usłyszeć i o tym czego niestety nie usłyszałem, a nie ukrywam, że chciałem :-)
Prezentacja podzielona była na 5 części:
- Ogólne informacje na temat NSN oraz na temat platformy @dvantage, przy której pracują obaj autorzy.
- Krótkie przypomnienie modelu kaskadowego (ang. waterfall) i jego wad.
- Manifest agile i główne założenia iteracyjnego tworzenia oprogramowania.
- Wprowadzenie do Scrum z omówieniem cyklu projektu i ról w projekcie.
- Część praktyczna, czyli spojrzenie na implementację Scrum w NSN jako dużej globalnej korporacji.
Jak się pewnie domyślacie, idąc na ten wykład liczyłem głównie punkt 5 i głównie na nim się skupię. Na prezentację zaplanowano 90 minut. Pierwsze cztery części zabrały w sumie około 50 min. Szkoda, bo zupełnie niepotrzebnie dużo miejsca zajęły szczegóły na temat platformy @advantage i związanych z nią narzędzi oraz teoria na temat Scrum, przez co na to, co faktycznie najciekawsze zostało już tylko pół godziny plus 10 min na pytania z sali.
Ale do rzeczy… Wrocławski odział NSN podjął próbę wprowadzenia Scrum kilka miesięcy temu. Autorzy prezentacji opowiadali o pracy ok 20 osobowego zespołu, który został podzielony na 4 podzespoły (Scrumy). Trzy z nich zajmują się oprogramowaniem trzech różnych linii produkcyjnych wspomnianej platformy @dvantage, czwarty to typowy “firefighting team” zajmujący się naprawą krytycznych błędów na wszystkich trzech liniach działającego już produkcyjnie kodu.
W każdym zespole rolę Scrum Mastera pełni osoba z większym doświadczeniem wybrana z pośród dotychczasowych programistów. Zespoły praktykują codzienne 15 minutowe spotkania, planning meetings na początku sprintu oraz retrospectives po sprincie. Scrum Masterzy ze wspomnianych czterech zespołów tworzą wirtualny zespół Scrum of Scrums aby synchronizować podobne prace toczące się na poszczególnych liniach platformy. Nie wiem tylko ja wygląda komunikacja w obrębie tego zespołu, ale odniosłem wrażenie, że nie mają swoich codziennych spotkań.
Na razie wygląda normalnie… wręcz zbyt dobrze, a przecież to duża korporacja… no to przejdźmy do problemów jakie udało mi się wychwycić.
Po pierwsze NSN pozostaje jako korporacja organizacją polegającą na modelu kaskadowym. Różne warstwy organizacji mają do osiągnięcie pewne kamienie milowe i etapy ich osiągnięcia są góry ustalone. Sam dział programistyczny mapuje Scruma na poziomie poszczególnych faz modelu kaskadowego. I tak mamy opracowanie specyfikacji wymagań, analizę i projektowanie, implementację, wdrożenie i w końcu utrzymanie aplikacji. Jeśli da się dany etap wykonać iteracyjnie, to zespół podejmuje próbę zaprzęgnięcia do tego Scruma w skali pojedynczego etapu. Przy czym Scrum na etapie implementacji jest tutaj najbardziej eksponowany.
Autorzy zapytani przeze mnie o to, jak w takim razie radzą sobie ze zmianą wymagań pochodzących z fazy specyfikacji wymagań odpowiedzieli, że tamte wymagania są na tyle ogólne, że raczej nie zmieniają się potem podczas implementacji. Tak więc możliwa jest co najwyżej reakcja na zmiany drobniejszych wymagań, które identyfikowane są już podczas fazy implementacji a do faz, które już minęły nie wracamy. Nie rozumiem tylko na podstawie czego powstaje w takim przypadku backlog produktu i czy to oznacza, ze on nie może się już zmienić?
Drugi problem jaki dotyczy tak dużej organizacji, to kooperacja pomiędzy działami. W NSN funkcjonuje duży dział testów, który wykonuje między innymi testy funkcjonalne aplikacji tworzonych przez programistów NSN (w tym tych wchodzących w skład 4 Scrumów platformy @dvantage). Problem polega na tym, że praca działu testów nie jest uwzględniona w sprincie a odbywa się już po. W ramach sprintu programiści wykonują jedynie testy jednostkowe (przy czym TDD to raczej opcja niż norma, choć w przypadku tego typu systemów to mnie raczej nie dziwi).
Szkoda, że nie dowiedziałem się z prezentacji więcej na ten temat, bo właśnie tego byłem ciekaw najbardziej. NSN jako duża sformalizowana organizacja jest dotąd raczej oparta na pewnych warstwach zadaniowych i działach, które zajmują się pewnym wybranym aspektem działania firmy. Tymczasem wprowadzanie metod agile, w tym Scrum wiąże się ze zmianą organizacji pracy na bardziej projektową i wymaga utworzenia bardziej kompletnych i samowystarczalnych zespołów. Oczywiście wymagałoby to rewolucji i likwidacji pewnych działów, albo przynajmniej fizycznego przemieszczenia pracowników, tak aby np. pojedynczemu zespołowi developerów przydzielić również osoby z takiego działu testów, a pewnie znalazłoby się jeszcze kilka innych działów, z których należałoby wyciągnąć ludzi. Z tego co autorzy przekazali podczas wykładu wynika, że nie udało się tego dotąd zrobić w NSN i działy pomiędzy sobą nie dzielą nawet wspólnych sprintów.
Na koniec sprawy bardziej techniczne a nie organizacyjne. Sprint w tych zespołach trwa 4 tygodnie. Szacowanie zadań dla poszczególnych sprintów odbywa się w godzinach, przy czym odniosłem wrażenie, że oszacowania dokonują pojedynczy programiści a nie zespół (ale może to niedopowiedzenie). Autorzy prezentacji wspomnieli o śledzeniu wykresów burndown, ale nie wspomnieli nic na temat tego w jaki sposób śledzą velocity (co w przypadku estymowania w godzinach jest szczególnie pomocne) i jak wykorzystują to do planowania i poprawiania swoich oszacowań godzinowych.
No i jeszcze taka ciekawostka - continous integration. W przypadku omawianej na wykładzie platformy zbudowanie, integracja i wstępne przetestowanie automatyczne kodu trwa całą noc. Więc nad ranem następnego dnia zespoły wiedzą, czy coś im nie wyszło dnia poprzedniego. No… oflagowanie tego procesu mianem CI jest moim zdaniem lekkim nadużyciem i uważam, że dużo wiarygodniej brzmiałoby stwierdzenie, że w skali całego projektu nie da się tam wdrożyć pełnego CI. Chciałem zadać jeszcze pytanie czy w ogóle da się w takiej organizacji i przy tak skomplikowanych i złożonych systemach zachować zasadę, że w każdej iteracji otrzymujemy w pełni wdrażalny produkt, zwłaszcza że do tego potrzeba właśnie ścisłego współdziałania działów korporacji? Po prezentacji mam wątpliwości.
Chcę podkreślić, że nie chcę wytykać tutaj żadnych błędów. Moje spostrzeżenia traktuję bardziej jako konfrontację teorii ze staraniami zespołów ograniczonych z wielu stron przez sztywne ramy korporacji. Mam nadzieję, że uda się np. za rok usłyszeć podobne wystąpienie, w którym będzie mowa o tym, jakie z tych problemów udało się, bądź nie udało się rozwiązać. Na razie wygląda na to, że próby wdrożenia Scrum w NSN nie są wspierane na wszystkich poziomach organizacji i raczej wyglądają jako taka inicjatywa na średnim i niższych szczeblach. NSN dysponuje ponoć 500 Scrum Masterami (informacja z wykładu) - pytanie jaki jest stosunek ilości programistów do SMów? Być może na wyższych szczeblach funkcjonuje to bardziej na zasadzie “wszyscy są teraz agile, więc my też bądźmy, ale nie zmieniajmy przy tym za wiele”. Obym się mylił a rozpoczęty w NSN proces ulegał doskonaleniu w praktyce a nie tylko na prezentacjach.
I jeszcze takie fundamentalne pytanie jakie nasuwa mi się jeśli myślę o wdrażaniu agile w takiej organizacji. Czy w trakcie wdrażania procesów Scrum okazało się, że jakieś stanowiska są niepotrzebne? Czy każdy trybik takiej organizacji znajdzie dla siebie miejsce w ramach nowych procesów, czy może pewne stanowiska okażą się nie potrzebne?
Kij w mrowisko wsadzony :-) Czekam na komentarze tych najbardziej zainteresowanych, jeśli takowi czytają tego bloga :-)
4 comments April 28th, 2008
