Agile. Szansa na skokowy wzrost produktywności

Redakcja

Autor:

Bogdan Bereza

Kierownik grupy wydawniczej:

Ewa Ziętek-Maciejczyk

Wydawca:

Monika Kijok

Redaktor prowadzący:

Rafał Janus

Korekta:

Zespół

Skład i łamanie:

Raster studio, Norbert Bogajczyk

Projekt okładki:

Piotr Fedorczyk

Druk: Miller

ISBN: 978-83-269-3449-0

Copyright by Wydawnictwo Wiedza i Praktyka sp. z o.o.

Warszawa 2014

Wydawnictwo Wiedza i Praktyka sp. z o.o.

03-918 Warszawa, ul. Łotewska 9a

tel. 22 518 29 29, faks 22 617 60 10

NIP: 526-19-92-256

Numer KRS: 0000098264 – Sąd Rejonowy dla m.st. Warszawy, Sąd Gospodarczy XIII Wydział Gospodarczy Rejestrowy. Wysokość kapitału zakładowego: 200.000 zł

„Agile: szansa na skokowy wzrost produktywności” wraz z przysługującymi Czytelnikom innymi elementami dostępnymi w subskrypcji (e-letter, strona www i inne) chronione są prawem autorskim. Przedruk materiałów opublikowanych w publikacji „Agile: szansa na skokowy wzrost produktywności” oraz w innych dostępnych elementach subskrypcji – bez zgody wydawcy – jest zabroniony. Zakaz nie dotyczy cytowania publikacji z powołaniem się na źródło.

Publikacja „Agile: szansa na skokowy wzrost produktywności” została przygotowana z zachowaniem najwyższej staranności i wykorzystaniem wysokich kwalifikacji, wiedzy i doświadczenia autorów oraz konsultantów. Zaproponowane w publikacji „Agile: szansa na skokowy wzrost produktywności” oraz w innych dostępnych elementach subskrypcji wskazówki, porady i interpretacje nie mają charakteru porady prawnej. Ich zastosowanie w konkretnym przypadku może wymagać dodatkowych, pogłębionych konsultacji. Publikowane rozwiązania nie mogą być traktowane jako oficjalne stanowisko organów i urzędów państwowych. W związku z powyższym redakcja nie może ponosić odpowiedzialności prawnej za zastosowanie zawartych w publikacji „Agile: szansa na skokowy wzrost produktywności” lub w innych dostępnych elementach subskrypcji wskazówek, przykładów, informacji itp. do konkretnych przypadków.

Wstęp

Moda na Agile trwa, a wręcz się nasila. Z jednej strony to wspaniale, gdyż Agile jest rodziną bardzo skutecznych sposobów tworzenia oprogramowania. Z drugiej strony – wielka szkoda, że Agile stało się modą. Przez to bowiem bywa propagowane i stosowane bezmyślnie, a nawet gloryfikowane jako niemal uniwersalne rozwiązanie, jako cel sam w sobie. Tymczasem celem powinna być wyłącznie skuteczność i sprawność przedsięwzięć IT, a jednym z narzędzi pomagających w jego osiągnięciu może być Agile.

Aby dobrze zrozumieć i skutecznie stosować Agile, nie wystarczy szczegółowa znajomość instrukcji praktykowania jednej ze zwinnych metodyk (najczęściej Scrum). Tym bardziej że zwykle wybór metodyki jest przypadkowy. Zamiast analizy organizacje kierują się modą i obiegowymi opiniami.

W wielu publikacjach na temat Agile jako coś oczywistego przyjmuje się wyższość omawianych metodyk nad alternatywnymi. Wyraża się to nawet w terminologii, w której metody inne niż Agile określa się zwykle pobłażliwą nazwą „tradycyjnych”. Taki sposób prezentacji, pozornie skuteczny i pragmatyczny, nie pozwala naprawdę dogłębnie zrozumieć omawianego tematu. Cierpi na tym efektywność i elastyczność osób mających tylko taką wąską wiedzę. Nie chodzi bowiem o to, żeby być zwinnym, choć nazwa brzmi kusząco, lecz żeby być skutecznym. Dlatego nie spisujmy lekkomyślnie na straty projektów sekwencyjnych i hierarchicznych. Dobry menedżer dopasowuje taktykę do potrzeb, a nie na siłę stosuje rzekomo uniwersalne rozwiązanie niezależnie od sytuacji.

Nie krytykuję opracowań, które koncentrują się na opisie szczegółów i taktyki zwinnego działania. Są one jak najbardziej potrzebne, a liczne takie książki są już na naszym rynku dostępne. Brakuje natomiast opracowania syntetycznego, pozwalającego znaleźć odpowiedź na pytanie, kiedy i po co wybrać strategię Agile. Wprawdzie od autorów książek trzeba wymagać szerszej wiedzy niż tylko wziętej z praktycznego doświadczenia. Z drugiej strony nie ma raczej sensu, aby od każdego uczestnika projektu Agile, nawet na kierowniczym stanowisku, wymagać zarówno wielkiego doświadczenia, jak i przygotowania teoretycznego. Byłoby to marnotrawstwem czasu. Optymalnym rozwiązaniem jest książka, która z jednej strony zawiera szczegółowe przepisy i praktyczne przykłady, a jednocześnie oferuje szersze spojrzenie. Taka pozycja to dla Czytelników dobra namiastka wieloletniego doświadczenia i streszczenie pogłębionej, niedostępnej gdzie indziej wiedzy z dziedziny IT, organizacji, inżynierii oprogramowania. A nawet psychologii, która jest potrzebna, aby umiejętnie stosować Agile.

Taką optykę przyjmuję w tej książce. Po pierwsze, staram się zachować bezstronność, opisywać równie dokładnie zalety i możliwości, jak i wady lub zagrożenia stosowania metodyk zwinnych. Nie zaczynam od wyjaśniania niezrozumiałych dla niewtajemniczonych nazw artefaktów i rytuałów Agile. Jako punkt wyjścia przyjmuję konkretną potrzebę biznesową lub technologiczną, którą będzie się przy ich pomocy realizować. Słowem, traktuję Agile tak, jak narzędzie – jedno z wielu – do osiągnięcia konkretnych celów, a nie jako wartość, która nie podlega dyskusji. Skorzystają na tym i Czytelnicy, i sama Agile, ponieważ taka formuła chroni nas przed karkołomnymi próbami stosowania tej metodyki tam, gdzie nie daje ona korzyści.

Książka pozwoli Czytelnikom w pełni zrozumieć, oswoić i wykorzystać Agile w najlepszy możliwy sposób. Tłumaczy i pokazuje na przykładach, jak można Agile zastosować do rozwiązywania prawdziwych problemów i realizowania konkretnych potrzeb projektów IT. Zalecamy ją zarówno menedżerom, jak i informatykom, którzy dopiero planują wejść w świat Agile, aby mogli szybko zrozumieć, o co w tym wszystkim chodzi i dlaczego ta metoda ma naprawdę szansę być bardzo skutecznym sposobem współpracy.

Jest to pozycja interesująca również dla tych, którzy poznali już Agile w praktyce i chcą podnieść swoje kwalifikacje, pracować skuteczniej, ze zrozumieniem. Zrozumienie jest kluczowe do tego, aby umieć wyjść poza wąskie przykłady, przepisy książki kucharskiej i umieć na sposób Agile stawiać czoło coraz to nowym wyzwaniom, realizować coraz to nowe cele biznesowe.

1. Metody zwinne – wprowadzenie

Agile to podejście (ang. framework) do projektów IT, łączące wiele różnorodnych elementów. W praktyce Agile staje się często także swego rodzaju postawą, filozofią działania, mającą zastosowanie również poza światem informatyki.

Najważniejszą cechą Agile jest iteracyjność. Zakłada się, że próba precyzyjnego określenia z góry wszystkich wymagań dla systemu IT jest zwykle nieskuteczna, stwarza ryzyko stawiania błędnych celów projektom i może powodować nieprawidłową realizację oraz opóźnienia. Dlatego Agile zaleca podejście iteracyjne (prototypowanie, model spiralny). Praca z wymaganiami trwa przez cały czas projektu i zakłada możliwość nawet znacznych zmian tych wymagań podczas trwania prac deweloperskich.

Rysunek 1.1. Iteracyjny model wytwarzania oprogramowania

Agile zakłada, że szczegółowe planowanie, wobec braku na początku precyzyjnych i w pełni uzgodnionych wymagań, jest tworzeniem fikcji. Dlatego w projektach realizowanych metodami Agile dokonuje się szczegółowego planowania i nadzoru tylko niewielkich części pracy (w Agile Scrum są tzw. przebiegi, ang. Sprint), natomiast planowanie na wyższym poziomie pozostawia się innym.

Rysunek 1.2. Metody Agile ograniczają próby planowania o zbyt dużej niepewności

Drugą kluczową cechą Agile jest przyrostowość. Wychodzi się z założenia, że dla klienta korzystniejsze jest dostarczanie oprogramowania kawałkami, jak najwcześniej, zamiast jednej wielkiej dostawy na zakończenie. Twierdzi się, że metody przyrostowe są też korzystne dla samego procesu wytwarzania oprogramowania, umożliwiając lepszy nadzór i skuteczniejsze kontrolowanie jakości.

Rysunek 1.3. Przyrostowy model wytwarzania oprogramowania

Trzeci ważny aspekt Agile to preferowanie bezpośredniej współpracy oraz interakcji. Przyjmuje się tezę, że nadmierna formalizacja współpracy przy użyciu obszernej dokumentacji projektowej oraz drobiazgowych procedur definiujących role bywa nieskuteczna i pracochłonna. Czasem staje się wręcz przyczyną nieporozumień i pomyłek. Agile zakłada, że najlepszą formą współpracy i komunikacji są intensywne, bezpośrednie kontakty między ludźmi.

UWAGA

Często wynika z tego fałszywe mniemanie, jakoby Agile nie mogło dostarczać obszernej dokumentacji. Dokumentacja produktowa, jeśli jest wymagana przez klienta, staje się po prostu częścią produktu IT. Metody Agile mogą ją produkować tak samo jak kod oprogramowania. Jeśli zaś chodzi o dokumentację projektową, Agile zakłada jedynie, że nie należy jej tworzyć bez powodu. Nie wyklucza natomiast, by wymagania wynikające z jakichś standardów czy praw albo oczekiwań innych części organizacji były właśnie takim powodem.

Metodyki Agile zakładają realizację projektów przez niewielkie, samoorganizujące się zespoły współpracujące ze sobą. Nie ma w nich miejsca na tradycyjną rolę kierownika projektu czy zespołu, jako nadzorcy, mówiącego pracownikom co, kiedy i w jaki sposób mają robić. Również tzw. Scrum Master nie jest w pełni kierownikiem. Jest primusinterpares, koordynującym, ułatwiającym i w pewnych sytuacjach nadzorującym, ale nie narzucającym rozwiązania.

Scrum Master to rola szczególna. Najlepiej wyjaśnia ją określenie „kierownik służebny” (servant-leader). Ta osoba nie wykonuje tradycyjnych zadań kierowniczych, jak oszacowanie pracochłonności, planowanie, podział pracy, nadzorowanie i wydawanie poleceń. Te zadania wykonuje wspólnie cały zespół scrumowy podczas planowania przebiegu oraz podczas codziennych scrumów. Zadaniem Scrum Mastera jest chronić zespół przed przeszkodami i trudnościami, pomagać je rozwiązywać. Trudności mogą być zewnętrzne. Typowe przykłady to próby zmiany zakresu przebiegu już w trakcie jego trwania. Mogą pochodzić również z wewnątrz, np. powstające opóźnienia lub niewywiązywanie się przez pojedynczych członków zespołu scrumowego ze swoich zadań. Rola Scrum Mastera polega w dużym stopniu na facylitacji (rozwiązywaniu konfliktów), a w mniejszym na nadzorze administracyjnym.

Podejście Agile można zaklasyfikować do tak zwanych metod zarządzania przez cele. W wyniku planowania przebiegu właściciel produktu negocjuje kontrakt z uczestnikami zespołu i zawiera go po zaakceptowaniu warunków przez obie strony. Zespół, w Agile Scrum zwany zespołem scrumowym, obejmuje wszystkie role potrzebne do realizacji zadań: programistów, testerów, specjalistów wymagań. Kontrakt ten określa cel, który należy osiągnąć w danym przebiegu, i zespół sam organizuje swoje działania w celu jego realizacji.

1.1. Metoda prób i błędów – lekarstwo na niepewność

Pierwotne grupy łowieckie składały się z kilku, najwyżej kilkunastu osób. Łowy miały znany z góry, ogólny cel, ale szczegóły ustalano każdorazowo dopiero w trakcie polowania. Cel był często zmienny, dostosowywany do nadrzędnego zamysłu realizacji potrzeby. Kiedy jednak budowano piramidy, taka organizacja nie wystarczała. Korzystniejszy był inny tryb działania: planowanie zawczasu, budowa trwająca długie lata i realizowana przez złożoną, hierarchiczną organizację. Zarządzanie procesem wymagało obszernej biurokracji, o czym świadczą dobitnie archeologiczne dane także ze starożytnego Egiptu.

Mała, samoorganizująca się grupa mająca elastyczny cel sprawdza się lepiej w niewielkich przedsięwzięciach, zaś planowana działalność i hierarchiczna organizacja są niezbędne, aby realizować cele wielkie i złożone. Ta zasada pozostaje do pewnego stopnia prawdziwa również dzisiaj. Przejście wielu dziedzin działalności gospodarczej z formuły rzemieślniczej i manufakturowej do formuły taśmy produkcyjnej w XIX–XX wieku nawet pogłębiło ten stan rzeczy. Wytwarzanie wielu urządzeń i przedmiotów, wprawdzie możliwe metodami rzemieślniczymi, okazało się znacznie tańsze przy zastosowaniu szczegółowego planowania, hierarchicznej struktury zarządzania i technologii produkcji masowej. Ponadto taśma produkcyjna pozwoliła, aby w procesie produkcji brali udział pracownicy słabo wykwalifikowani, umiejący wykonać tylko małą część pracy i często nierozumiejący ani jej celu, ani ogólnych zasad.

W latach 40. i 50. ubiegłego stulecia IT rozwijało się metodami rzemieślniczymi i „łowieckimi”. Wraz z dramatycznym wzrostem złożoności i biznesowego znaczenia systemów IT nastąpił okres dominacji metod planowych i hierarchicznych. Szereg czynników spowodował, że rozpoczęto próby odejścia od zarządzania nadmiernie biurokratycznego, dokładnego planowania i hierarchii, a mające na celu powrót do elastyczności grup łowieckich, czego przykładem jest właśnie Agile.

Skąd biorą się te różnice? Wiele gałęzi przemysłu, jak konstruowanie okrętów, budownictwo, metalurgia czy mechanika istnieją od setek, a nawet tysięcy lat. IT jest o wiele młodszą branżą i zupełnie do innych przemysłów niepodobną. Ponadto swój złoty wiek – okres szczególnie burzliwego rozwoju – przeżywała w czasach hippisowskiej kontrkultury, więc łatwiej w niej, przynajmniej psychologicznie, o niestandardowe rozwiązania.

Technologia IT, zbudowana według założeń architektury von Neumanna (w tej architekturze zarówno instrukcje, jak i dane komputera mogą być modyfikowane), pozwala na dużą elastyczność procesu wytwarzania, a koszt wprowadzania modyfikacji jest stosunkowo niski. Dlatego odkładanie jak najdłużej nieodwracalnych, krytycznych decyzji jest możliwe znacznie dłużej przy wytwarzaniu oprogramowania niż przy wytwarzaniu, przykładowo, produktów z kamienia.

Poza tym IT nigdy nie dorobiło się odpowiednika efektywnej produkcji taśmowej. Ma to pewne uzasadnienie, ponieważ większość przedsięwzięć informatycznych ma charakter pionierski, tworzy odmienne od poprzednich prototypy. Dlatego proces produkcyjny, taki jak przy tworzeniu długich serii jednakowych egzemplarzy, nie ma racji bytu w IT.

Z drugiej strony, swoista hackerska kultura branży, idealizująca twórczy aspekt budowania oprogramowania oraz debugowanie, a wybitnie niechętna procedurom i nieznacznie choćby sformalizowanym dobrym praktykom, powoduje, że nawet w bardzo hierarchicznych i planowanych działaniach poprawianie dominuje (debugowanie) nad zapobieganiem błędom. Mówiąc inaczej, kontrola jakości jest powszechniejsza od zapewnienia jakości.

Byś może nie dla każdego jest jasne, czym różnią się od siebie kontrola i zapewnienie jakości. Te nazwy rzeczywiście nie są najszczęśliwiej dobrane, ale niestety przyjęte. Kontrola jakości oprogramowania to test: sprawdzamy, czy nie ma w nim powodujących awarie błędów. Zapewnienie jakości to wszystko, co się robi, aby uniknąć powstania błędów. Do tych działań zalicza się analiza i dobry opis wymagań, pilnowanie konfiguracji, dobra organizacja pracy, wiedza, motywacja i umiejętności uczestników projektu.

W tej sytuacji metody zwinne niewiele tracą w porównaniu z hierarchicznymi, planowanymi, jeśli chodzi o jakość i staranność, a zyskują wiele pod względem elastyczności.

Znamienne jest to, że w praktyce dobrze prowadzony projekt Agile często jest znacznie bardziej zdyscyplinowany i uporządkowany niż typowy projekt hierarchiczny, w którym za fasadą solidnej dokumentacji i zdefiniowanych ról ukrywa się niekiedy mnóstwo bałaganu i cynizmu uczestników.

Do wytworzenia wielu produktów IT lepiej pasuje formuła „łowiecka” niż hierarchiczne metody konstruowania piramid. Istnieją wprawdzie systemy IT bardziej złożone niż transatlantyk czy Airbus A380 (np. systemy sygnalizacyjne, systemy kontroli lotów, systemy nadzoru produkcji), ale większość jest stosunkowo prostych i nie wymaga bardzo dokładnego planowania. Przy ich tworzeniu biznesowo więcej korzyści przynosi elastyczność, zdolność do zmian i szybkość dostawy pierwszej wersji niż dokładność, trafność przewidywań i możliwość dokładnego planowania z wyprzedzeniem.

1.2. Najważniejsze fakty z historii metod iteracyjnych i przyrostowych

Dość powszechne jest przekonanie, jakoby metody Agile różniły się na tyle od innych metod wytwarzania oprogramowania, że wymagają zupełnie odmiennych technik i umiejętności. Z jednej strony ten mit powoduje nieuzasadnioną podejrzliwość i sceptycyzm wobec Agile ze strony biznesu oraz praktyków działających innymi metodami. Z drugiej strony, zdarza się wśród niektórych specjalistów Agile brak wiedzy i lekceważący stosunek do innych, rzekomo „tradycyjnych” i „przestarzałych” metod pracy. Dlatego pokazujemy najważniejsze zagadnienia związane z podejściem Agile, które miały miejsce przed ogłoszeniem „manifestu Agile” w lutym 2001 roku. Ta wiedza umożliwia spojrzenie na Agile w kontekście reszty świata IT, a nie w oderwaniu od niego.

EVO Toma Gilba

Tom Gilb propaguje ewolucyjne (EVO – Evolutionary Project Management) podejście do zarządzania projektami IT już od lat 60. ubiegłego stulecia. Pouczający wywiad z Tomem, w języku polskim, znajduje się na stronie http://tinyurl.com/wiplink01. Pod nazwami innymi niż Agile Gilb zaleca m.in. podejście iteracyjne oraz przyrostowe, a także dążenie do tego, aby każda kolejna dostawa kodu realizowała konkretną wartość biznesową.

Rysunek 1.4. Evolutionary Project Management EVO – formuła Agile z lat 70. XX w.

JAD – Joint Application Development

Tę metodę, postulującą, podobnie jak Agile, zaangażowanie klienta i użytkownika w proces tworzenia oprogramowania, stosowano już w latach 70. ubiegłego wieku.

RAD – Rapid Application Development

Podejście stosowane w latach 70. i 80. XX w. (formalnie opisane zostało w 1991 roku). Wprowadziło między innymi do inżynierii oprogramowania metody takie jak model spiralny oraz prototypowanie.

Cleanroom Software Engineering

Ta metodyka, choć w większości odległa od Agile i obszarów, gdzie Agile ma zastosowanie (zaleca między innymi statystyczną kontrolę jakości oraz metody formalne), kładzie jednak nacisk na iteracyjność procesu wytwarzania oprogramowania.

DailyBuild

Codzienne budowanie – DailyBuild – stosowano już w latach 90. ubiegłego stulecia. Jest formą i wcześniejszą wersją stosowanej dziś w wielu projektach ciągłej integracji (Continuous Integration, CI).

Długa historia idei Agile wymownie świadczy, że takie podejście jest w IT potrzebne i że przynosi korzyści. Warto również zdawać sobie sprawę, że nie zawsze konieczne jest stosowanie wszystkich zasad Agile. Można wybierać tylko te, które odpowiadają potrzebom konkretnego projektu.

1.3. Dalszy rozwój metod zwinnych – post-agilism

Do 17 pierwszych sygnatariuszy manifestu Agile (www.agilemanifesto.org) należy Robert Cecil Martin (tinyurl.com/wiplink02). Nie można więc mieć wątpliwości, że „wujek Bob”, jak bywa przezywany przez kolegów, jest gorącym zwolennikiem Agile. Wobec tego zaskoczeniem może być jego artykuł „Aristotle’s Error or Agile Smagile”, opublikowany ledwo dwa lata później na blogu Java.net (tinyurl.com/wiplink03). W tym tekście autor zwraca uwagę na masowe nadużywanie określenia „Agile”, które, bezmyślnie wykorzystywane przez branżowych dziennikarzy i marketingowców, zaczęło być stosowane jako synonim słowa „świetny”, a jego pierwotne, konkretne, fachowe znaczenie gdzieś się w tym wszystkim zagubiło.

Na potrzeby marketingu takie nadużywanie ułatwia sprzedaż wszystkiego, byle wesprzeć ją magicznym słówkiem „agile”. Słowo to ma wydźwięk pozytywny. „Zwinny” brzmi lepiej niż „ociężały” i sugeruje młodość, nowoczesność, energię, siły witalne.

Od czasu publikacji tekstu Roberta Martina nic się w tym względzie nie poprawiło, przeciwnie, to negatywne zjawisko jeszcze się nasiliło. Często wejście pod sztandar słówka „agile” staje się drogą na skróty do kariery, z pominięciem wiedzy i doświadczenia. Narzekanie na ten stan rzeczy nic nie pomoże. Branża IT nie jest w żaden sposób magicznie uodporniona na mechanizmy mody i psychologii grupy ani na zjawiska społeczne. Stosując lub próbując stosować Agile, trzeba tylko być tego świadomym i zachować ostrożność. Aby stosować Agile z powodzeniem, a nie na zasadzie owczego pędu, trzeba jego zasady, korzyści i ograniczenia dogłębnie zrozumieć, by móc myśleć samodzielnie, a nie kierować się modą. Lektura książki ułatwi osiągnięcie tego celu.

Polska „Nonsensopedia” publikuje następujący żartobliwy tekst na temat programowania ekstremalnego: Programowanie ekstremalne – doktryna religijna i metodyka programowania mająca na celu wydajne tworzenie małych, średnich i średnio dużych projektów wysokiego ryzyka, czyli takich, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić. Przyświeca temu koncepcja surrealistycznej, prymitywnej rozrywki, wywodząca się z obsesyjnej obserwacji innych programów, które odniosły sukces (albo i nie). Podstawą ekstremalnego programowania są synergia, akomodacja i mahabharata, wynikające ze stosowania rozmaitych praktyk religijno-informatycznych.

Ten absurdalny tekst okazuje się nieznacznie tylko zmodyfikowaną kopią z autentycznej definicji programowania ekstremalnego z „Wikipedii”. Wniosek: uwaga na błąd Arystotelesa, same słowa nie wystarczają. Od samego stosowania nazwy Agile nic nie zmieni się na lepsze. Jeśli ktoś stosuje Agile jako uniwersalne rozwiązanie, zapalmy czerwone światło ostrzegawcze.

1.4. Przegląd metod zwinnych

Metodyki Lean

Metodyki „odchudzone” lub „szczupłe” (lean) w odniesieniu do wytwarzania oprogramowania, znane pod budzącym niecodzienne skojarzenia skrótem LSD (Lean System Development), to próba przeniesienia do inżynierii oprogramowania zasad wchodzących w skład odchudzonego systemu produkcyjnego Toyoty, opisanego po raz pierwszy w 1998 roku. Pionierska w tej dziedzinie IT książka Mary i Toma Poppendiecków „Lean Software Development: An Agile Toolkit” została wydana w 2003 roku.

Lean nie jest innym czy alternatywnym podejściem ani procesem, ani metodyką, lecz zbiorem zasad oraz technik pozwalających realizować te zasady w projektach prowadzonych według wytycznych Agile. Oczywiście zasady Lean można także próbować stosować poza Agile, ale w praktyce Lean oraz Agile najczęściej stosuje się łącznie.

Siedem zasad Lean to:

1. Eliminacja strat (np. zbędna funkcjonalność, niejasne wymagania, niedostateczne testy).

2. Pozyskiwanie wiedzy (dotyczącej potrzeb klienta i produktu w kolejnych iteracjach poprzez pozyskiwanie wymagań, prototypowanie i testy akceptacyjne).

3. Odsuwanie nieodwracalnych decyzji – budowanie pod kątem maksymalnej elastyczności i możliwości zmian.

4. Jak najszybsze wdrażanie w krótkich iteracjach.

5. Pełnomocnictwa dla zespołu – jak najwięcej decyzji i kontroli jest podejmowanych przez zespół, ale nie narzucanych przez proces lub hierarchiczną organizację.

6. Zapewnienie jakości, zamiast kontroli jakości – wbudowanie atrybutów jakości takich jak łatwość utrzymania oraz refaktoryzacja i optymalizacja rozwiązań.

7. Całościowe widzenie produktu, jego właściwości i celu przez wszystkich uczestników projektu.

Swój sukces biznesowy Toyota w dużym stopniu zawdzięcza właśnie praktykom Lean. Natomiast w inżynierii oprogramowania brak jednoznacznych empirycznych dowodów, na ile dość ogólnikowe hasła LSD rzeczywiście przekładają się na sprawność zespołów i korzyści biznesowe. W procesie produkcji zasady Lean oznaczają faktyczne fizyczne zmniejszenie zapasów, krótszy proces produkcyjny i mniejsze potrzeby powierzchni magazynowej, natomiast w odniesieniu do procesu tworzenia oprogramowania zasady te mają raczej symboliczny i hasłowy charakter.

XP – programowanie „ekstremalne”

Programowanie „ekstremalne” to stworzona i spopularyzowana przez Kenta Becka w latach 90. metoda szybkiego tworzenia oprogramowania, mająca na celu maksymalne przyspieszenie tworzenia kodu w sytuacji, gdy wymagania są niejasne i zmienne, a terminy szczególnie pilne.

UWAGA

Narzuca się pytanie, czy w tej sytuacji w ogóle należało tworzyć jakiekolwiek oprogramowanie? To zagadnienie dotyczy jednak obszaru analizy biznesowej i podejmowania decyzji w biznesie, a nie metod realizacji tych decyzji. Można mieć wrażenie, że wymogi błyskawicznego budowania systemów, tak często stawiane wobec IT, wynikają bardziej z mody i swoistej subkultury biznesu niż z rzeczywistej potrzeby.

W dużym stopniu XP było inspirowane potrzebami pierwszego internetowego boomu w tym okresie. Z punktu widzenia biznesowego uzasadnienia potrzeby takiego podejścia warto pamiętać o zjawisku bańki internetowej z lat 1995–2001, zakończonej spektakularnym krachem. Oprogramowanie można próbować tworzyć bardzo szybko, nawet nie znając wymagań.Chwała IT oraz XP, że radzi sobie nawet z takimi wyzwaniami, natomiast niekoniecznie te wyzwania są komukolwiek potrzebne.

W biznesie ulegamy często wprowadzającym w błąd przykładom osób, firm oraz idei, które odniosły spektakularne sukcesy. Jak dobitnie pokazały badania Daniela Kahnemana i Amosa Tversky’ego (nagroda Nobla z ekonomii w 2002 roku), podejmując decyzje biznesowe, często działają na nas mechanizmy opisane przez teorię perspektywy: pewne wybory wydają się nam lepsze, choć obiektywnie są gorsze. Historia niektórych znakomitych sukcesów w IT pokazuje, że sukces udało się osiągnąć nawet wtedy, gdy cel był niejasny, pośpiech morderczy, a proces wytwórczy chaotyczny. Analizując takie przypadki, dochodzimy do fałszywej tezy, że sukces udało się osiągnąć dzięki tym atrybutom, a nie mimo ich. Arogancki, woluntarystyczny styl zarządzania Steva Jobsa nie przeszkodził mu w osiągnięciu sukcesu, ale dla tysięcy innych szefów okazał się przeszkodą nie do pokonania. Tak samoswoisty manieryzm niektórych gałęzi współczesnego biznesu, gloryfikujący pośpiech, a pomijający przypadki niepowodzeń spowodowanych pośpiechem, bywa stosowany jako uzasadnienie „szybkich” metod tworzenia oprogramowania. Podkreślmy jeszcze raz: są możliwe, ale nie zawsze mają biznesowy sens.

Wspomniany Kent Beck jest jednym z pierwszych sygnatariuszy manifestu Agile. Obecnie wiele praktyk XP bywa stosowanych w projektach Agile, najczęściej TDD, ale nie jest to konieczny warunek żadnej z metod zwinnych.

Uzasadnienie XP zawiera wiele gołosłownej psychologicznej ideologii (o synergii, o zaangażowaniu, o kreatywności), ale możliwe jest wskazanie rzeczywistych korzyści, wynikających ze stosowania konkretnych praktyk. Praktyki XP to:

1. Unikanie podejmowania z góry decyzji dotyczących wymagań i architektury oraz ich minimalistyczna dokumentacja, kiedy w końcu zostaną podjęte. Jest to oczywiście praktyka bardzo kontrowersyjna, ale w sytuacji, gdy brak podstaw do podejmowania takich decyzji, mająca szereg zalet.

2. Iteracyjność – korzyści i koszty tego podejścia omawiamy obszernie w rozdziale „Porównanie kosztów i korzyści Agile oraz metod sekwencyjnych”.

3. TDD (Test Driven Development, wytwarzanie sterowane testami) – więcej w rozdziale „Metodyka TDD”. Tamże opis procedury refaktoryzacji.

4. Programowanie parami – zamiana rolami autorów testów i autorów kodu. Pozwala to na lepsze przestrzeganie zasady, żeby autor kodu nie był jednocześnie jego testerem.

5. Rotacja programistów między parami – możliwość wspólnej własności kodu.

6. Stały kontakt z klientem – TDD stosowane w ramach Agile realizuje tę zasadę różnymi metodami, często wspólnie z metodyką ATDD (więcej w rozdziale „ATDD – wyższa szkoła jazdy automatyzacji testów”).

Agile Kanban

Metoda Kanban pojawiła się w latach 50. do sterowania procesami produkcji w japońskim przemyśle motoryzacyjnym, jako jedna z praktyk towarzyszących metodykom Lean w produkcji. Mówiąc w skrócie, celem tej metody jest płynne wytwarzanie procesu bez żadnych kosztownych zapasów czekających na przetworzenie i bez konieczności oczekiwania przez ludzi i procesy na surowce, które można by przetworzyć. Aby to osiągnąć, przepływ produktu przez system produkcyjny musi odbywać się bez wąskich gardeł i spiętrzeń.

Rysunek 1.5. Tablica Kanban

Tę filozofię – na zasadzie analogii, nie kopiowania – na teren procesów produkcji oprogramowania przeniósł duński informatyk David Anderson („Kanban: Successful Evolutionary Change for Your Technology Business”, 2010). Kanban, stosowany razem z Agile Scrum, bywa nazywany Scrum-ban. Centralnym elementem stosowania Kanban w IT jest tak zwana tablica Kanban. Kolumny tablicy odpowiadają kolejnym etapom procesu IT, zdefiniowanym w danej organizacji czy grupie. Z kolei poszczególne zadania do realizacji przedstawiane są w postaci kart, które umieszcza się we właściwej dla aktualnej fazy kolumnie. Określa się obowiązujące limity dla liczby czynności, które mogą jednocześnie znajdować się w tej samej fazie realizacji.

Kanban, podobnie jak metodyki Lean, jest zalecanym sposobem działania, ale nie jest podejściem równie pełnym jak Agile Scrum. Z tego powodu Kanban można na przykład stosować również do regulowania procesów sekwencyjnych, niekoniecznie iteracyjnych, jak Scrum.

Agile CrystalClear

Jest to jeden z wielu istniejących sposobów realizacji ideałów Agile oraz Lean. Agile Crystal został zaproponowany przez Alistaira Cockburna (alistair.cockburn.us) i opisany przez niego w książce „Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams” (2004).

Cockburn opisuje Agile Crystal Clear jako metodykę Agile (nic dziwnego – Alistair jest jednym z sygnatariuszy Manifestu Agile), dostosowaną do niewielkich, 5–8-osobowych zespołów. Cockburn nie uległ pokusie popełnienia opisanego wcześniej błędu Arystotelesa i nie głosił modnej tezy, że Agile Crystal jest zbawieniem dla świata. Może dlatego Crystal Clear, merytorycznie ani lepsze, ani gorsze od Agile Scrum, pod względem popularności przegrało ze Scrumem.

UWAGA