Battle for Agility

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:

1. Ogólne informacje na temat NSN oraz na temat platformy @dvantage, przy której pracują obaj autorzy.
2. Krótkie przypomnienie modelu kaskadowego (ang. waterfall) i jego wad.
3. Manifest agile i główne założenia iteracyjnego tworzenia oprogramowania.
4. Wprowadzenie do Scrum z omówieniem cyklu projektu i ról w projekcie.
5. 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

Jak zwinny jest Twój zespół?

Na polskiej grupie dotyczącej lekkich metodyk Piotr Gabryanczyk zaprosił do więcia udziału w ankiecie. Również zachęcam do jej wypełniania i czekamy na wyniki.

Add comment March 12th, 2008

Akcent Agile na JDD 07

Piątek spędziłem na Java Developers Day 2007. Dlaczego piszę tutaj o konferencji Java? W zeszłym roku agile było praktycznie w każdym wystąpieniu. Wszystkie produkty, praktyki, frameworki były agile. W tym roku coś się zmieniło… terminem agile nie wiało już z każdej prezentacji, co w sumie jest nawet lepsze, bo przywykliśmy do zbytnich nadużyć w kwestii stosowania agile wszędzie gdzie się tylko da.

Ale nie myślcie, że agile zniknęło z JDD. Także i tegoroczna edycja miała swój akcent w postaci wystąpienia Jakuba Dziwisza na temat “Test Driven Development w Java”. Wykład powinien być niedługo dostępny w wersji wideo na stronach organizatora konferencji, a na blogu Jakuba powinien się pojawić artykuł uzupełniający samą prezentację. Zaczęło się nieźle… Jakub przekonywał o zaletach TDD w tworzeniu oprogramowania, z czym generalnie się zgadzam. Były założenia TDD, trochę o trybie red - green - refactor, później prosty test, który nie przechodził ale wyznaczył funkcjonalność, implementacja (test przeszedł - byliśmy w green), wreszcie przyszedł czas na “refactor”.

Niestety etap refaktoryzacji zaprezentowany podczas wykładu był dla mnie nieco kontrowersyjny. Mianowicie za jednym zamachem uległa zmianie implementacja testowanej klasy i bez uruchomienia testów od razu uległa zmianie także implementacja samego testu. Być może nie było to zamierzone a jedynie podyktowane ograniczeniami czasowymi samej prezentacji, ale chciałbym podkreślić, że w TDD właśnie po to najpierw piszemy test, żeby później w trakcie refaktoryzacji móc na nim polegać zmieniając kod. Jeśli programista zacznie jednocześnie zmieniać kod testowany i kod testujący to jaką ma pewność czy zielony pasek nadal wskazuje, że kod działa, a nie że właśnie dostosował test do tego, żeby przechodził z nowym kodem? A co jeśli po takich jednoczesnych zmianach test nie przejdzie? Czy to oznacza że źle zrefaktoryzowaliśmy kod, czy może nie wyszła nam modyfikacja testu? Test ma łapać błędy powstałe podczas refaktoryzacji. Dopiero później przychodzi czas na ew. refaktoryzację samego kodu testów. Z reszta Jakub wspomniał o tym, że dobrze napisane testy nie powinny tak często wymagać zmiany, kiedy tylko refaktoryzujemy kod aplikacji.

Chciałbym się także odnieść do pytania, które padło z sali. Mianowicie “Do czego TDD się nie nadaje?”. Odpowiedzią było, że “nie nadaje się do utrzymania oprogramowania”. Z drugiej strony Jakub stwierdził, że nie wyobraża sobie napisania linijki kodu produkcyjnego bez wcześniejszego napisania testów. Ani jedna, ani druga odpowiedź nie do końca mnie satysfakcjonuje.

To jest generalnie dobre pytanie jeśli chodzi o agile, bo będąc entuzjastą jakiejś konkretnej praktyki lub wszystkiego co agile, dość łatwo mówi się o tym jakie to wszystko jest piękne, ale pamiętamy formułę “there is no silver bullet” prawda?

Akurat według mnie TDD doskonale nadaje się do utrzymania oprogramowania. Nie mówię tu bynajmniej o rozpoczynaniu krucjaty w pisaniu testów do wielkiego istniejącego systemu, który takich testów nie posiada. Byłoby to niewiarygodnie męczące i praktycznie nieuzasadnione jeśli chodzi o koszty. Ale jestem zdania, że w takim wypadku doraźne aplikowanie TDD do napotkanych błędów w tego typu kodzie jest bardzo dobrą praktyką.

Załóżmy, że zostaje zgłoszony błąd w utrzymywanym przez nas oprogramowaniu. Co należy zrobić?

1. Najpierw piszemy test, który reprezentuje oczekiwane przez nas prawidłowe działanie aplikacji (jesteśmy w fazie RED, test nie przejdzie, bo przecież mamy błąd w aplikacji).
2. Naprawiamy błąd. A skąd wiemy, że go naprawiliśmy? Bo przeszedł test, które wcześniej napisaliśmy. Jesteśmy w GREEN.
3. Skoro mamy poprawkę i test, który przechodzi, to czas na ew. REFACTOR. Wiemy, że mamy test, który odpowie czy nie zepsuliśmy poprawki.

Oczywiście w przypadku systemów, które nie posiadały wcześniej testów, faza 2 i 3 są trudniejsze, bo nie wiemy czy poprawka i refaktoryzacja nie wpłynęły negatywnie na inne części systemu na które nie mamy testów, ale cóż. Jeśli znajdziemy inny błąd to wracamy do kroku 1. W ten sposób doraźnie reagując budujemy powoli bazę testów dla systemu, który mogliśmy dostać w spadku. Przy okazji pisania testów uczymy się także samego systemu, a napisane w tym momencie testy zabezpieczą nas przed powrotem tego samego błędu w kolejnym wydaniu oprogramowania.

Czy w takim razie rozpoczynając nowy projekt można zastosować TDD wszędzie i nie powstanie ani linijka kodu bez testów, które najpierw nie przechodziły? Niestety nie zawsze jest to możliwe. Wg. mnie nie warto pisać testów jednostkowych dla klas GUI w aplikacjach typu desktop. Ciężkie jest także testowanie w ten sposób kodu widoków w aplikacjach webowych. Oczywiście to nie znaczy, że nie należy automatyzować testów tego typu elementów. Chodzi tylko o to, że są to elementy, które raczej nadają się do testów funkcjonalnych, najlepiej “nagranych” przy pomocy specjalnego oprogramowania przez testerów, a nie przez samych developerów i przynajmniej w moim przypadku nie bardzo sprawdzało się tutaj TDD w swojej czystej formie.

TDD to jednak jedna z bardziej interesujących praktyk agile, więc na pewno jeszcze do tego tematu wrócę.

Add comment October 28th, 2007

Agile na JDD 2006

Wczoraj (tj. 21 października) w Krakowie odbyła się konferencja Java Developers Day 2006, na której swoje 5 minut miało także agile. Pan Marcin Kucieba z Sabre Poland miał wystąpić z tematem “Zastosowanie praktyk Agile w tworzeniu aplikacji i systemów z wykorzystaniem Javy”. Piszę “miał”, bo ostatecznie zaprezentował temat “Agile developement”, który z samą Javą miał niewiele wspólnego. Podczas tej prezentacji zostały przedstawione najczęściej stosowane praktyki agile takie jak:

• iteracyjne tworzenie oprogramowania
• idea user stories i ich estymowania
• backlog i wypalanie się projektu
• test driven development i wartość testów
• continous integration

Zacząłem ten wpis dość krytycznie, bo jednak po temacie z agendy konferencji spodziewałem się bardziej szczegółowego odniesienia do narzędzi i metod związanych ze środowiskiem programistów Java, do których sam się zaliczam. Niemniej ,mimo wstępnego rozczarowania, sama prezentacja była całkiem wartościowa. Zwłaszcza jej końcowa część, gdzie Pan Kucieba podjął temat “Dlaczego Agile?” i pokazał między innymi zależności oczekiwań klientów w stosunku do otrzymanych wyników na tle podejścia waterfall (prosty aczkolwiek wymowny wykres). To samo dotyczy również poziomu i szybkości zwrotu kosztów z inwestycji w przypadku wcześniejszych releasów z działającą funkcjonalnością jakie można zrobić stosująć agile zamiast czekać do ostatecznej akceptacji całej listy wymagań. Nie mogę sam zamieścić tej prezentacji, ale mam nadzieję, że pokaże się ona na stronie Polskiej Grupy Agile.
Dobrze, że takie wystąpienie się pojawiło chociaż nadawałoby się bardziej na rozpoczęcie konferencji “Agile Day” jakiego mam nadzieje doczekamy się w roku 2007 :-). Co ciekawe “agile” pojawiło się na JDD2006 praktycznie w każdym z wystąpień począwszy od testowania kodu przy pomocy TestNG (w tym kontekście to zrozumiałe) aż po ideę SOA (prezentacje BEA i DRQ), na której temat prelegenci zgodnie twierdzili, że jest ona bardzo “agile” :-).

Samą konferencję uważam za całkiem udaną. Natomiast w sferze agile mam następujące spostrzeżenie. Z jednej strony to dobrze, że wszyscy dostrzegają w agile dobrą drogę, ale jednak jestem w tym względzie mocno sceptyczny. Doczekaliśmy się momentu, kiedy wszyscy chętnie przyklejają swoim produktom i praktykom metkę agile podczas gdy nie ma to z agile dużego związku.

To chyba tyle mojej subiektywnej oceny JDD2006 z agile w tle.

Add comment October 22nd, 2006