Mity i Problemy w AgileDlaczego tak często Agile w organizacjachnie działa?

Wiktor Żołnowski

This book is for sale at http://leanpub.com/problemywagile

This version was published on 2014-06-13

This is a Leanpub book. Leanpub empowers authors andpublishers with the Lean Publishing process. Lean Publishing isthe act of publishing an in-progress ebook using lightweighttools and many iterations to get reader feedback, pivot untilyou have the right book and build traction once you do.

©2013 - 2014 Wiktor Żołnowski

Tweet This Book!Please help Wiktor Żołnowski by spreading the word about thisbook on Twitter!

The suggested tweet for this book is:

Właśnie zabieram się do czytania książki: ”Mity i problemy wAgile” by @streser https://leanpub.com/problemywagile/

The suggested hashtag for this book is #problemywagile.

Find out what other people are saying about the book byclicking on this link to search for this hashtag on Twitter:

https://twitter.com/search?q=#problemywagile

Spis treści

O Książce . . . . . . . . . . . . . . . . . . . . . . . . . . 1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Agile to taki iteracyjny Waterfall . . . . . . . . . . . . 5Jak wiele Agile jest w Agile? . . . . . . . . . . . . . . 6Czy Agile daje gwarancję sukcesu? . . . . . . . . . . 10Dlaczego większość wdrożeń Agile kończy się niepo-

wodzeniem? . . . . . . . . . . . . . . . . . . . 12Scrum a Waterfall . . . . . . . . . . . . . . . . . . . . 15Water-Scrum-Fail i W-Agile. . . . . . . . . . . . . . . 18Czym więc jest Agile? . . . . . . . . . . . . . . . . . 25

O KsiążceKsiążka “Mity i ProblemywAgile” powstała na podstawiemoichdoświadczeń związanych z pełnioną przeze mnie rolą niezależ-nego Coacha Agile oraz doradcy pomagającego organizacjompodczas transformacji w kierunku Agile. Więcej na temat naszejdziałalności możecie znaleźć na naszych stronach¹.

Myślą przewodnią książki było omówienie najczęściej spo-tykanych problemów pojawiających się na drodze organizacjipodczas transformacji agileowej. Wokół Agile krąży równieżwiele mitów, które stopniowo staram się w poniższej publikacjiobalać. Takie podejście wydaje się być znacznie ciekawsze niższczegółowe wykładanie teorii, którą inni wykładali już wielo-krotnie.

Książka ta skierowana jest przede wszystkim do praktyków.Nie tylko tych, którzy są już wyjadaczami w Agile ale takżetych, którzy dopiero swoją przygodę z transformacją rozpoczy-nają. Dla tych bardziej doświadczonych pokazanie z pewnejperspektywy niektórych problemów może okazać się kluczowew doskonaleniu procesów wytwarzania oprogramowania. Dlapoczątkujących wiedza o potencjalnych problemach może po-móc w ich uniknięciu już na samym początku transformacji.

Ci którzy mnie znają wiedzą, że moim ulubionym zajęciemjest kwestionowanie otaczającej nas rzeczywistości. To właśniedlatego kilka lat temu rozpocząłem swoją karierę w IT jakotester. Ciągle zadając pytania o to jak zepsuć testowane opro-gramowanie zdobywałem coraz to nowe umiejętności. Sameumiejętności psucia oprogramowania okazały się być dla mnie

¹http://www.agileszkolenia.pl

1

O Książce 2

niewystarczające. Zadając kolejne pytania o to skąd biorą siębłędy w oprogramowaniu i dlaczego nie można tego zrobić lepiejzainteresowałem się procesami wytwarzania oprogramowania. Itak oto w pewnym momencie przekopując się przez różne mo-dele i metody wytwarzania oprogramowania odkryłem Scrum iAgile - wtedy już wiedziałem, że to jest właśnie odpowiedź napytanie, o to jak wytwarzać oprogramowanie lepiej?!

Miałem przyjemność pracować w kilku zespołach i w kil-ku różnych organizacjach. W niektórych z nich Agile działałodobrze i dawało niesamowicie pozytywne efekty a w innychznaczenie gorzej. Ciągłe poszukiwania i zadawanie pytań o todlaczego czasem Agile działa a czasem nie w efekcie doprowa-dziło do powstania tej właśnie książki.

W międzyczasie zapoczątkowałem ogólnokrajową idee spo-tkań Bring Your Own Problem². Spotkania te powstały ponieważzauważyłem, że na naszych szkoleniach oraz na różnych konfe-rencjach najciekawsze rzeczy dzieją często podczas przerw ka-wowych, kiedy to uczestnicy mają okazję porozmawiać o swoichproblemach. O problemach zaczerpniętych z codziennej pracy,charakterystycznych dla ich kontekstu. Bardzo często okazywałosię, że wiele osób spotyka się z bardzo podobnymi problemami.Niektórzy radzili sobie z nimi lepiej a inni gorzej. Bez względuna to, każdy miał coś wartościowego do powiedzenia i potężnybagaż doświadczeń, którym chętnie się dzielił. To właśnie natych spotkaniach utwierdziłem się, że tego typu publikacja możeokazać się przydatna dla wielu praktyków Agile.

Niektóre z opisanych problemów pojawiły się wczęśniej wdosyć skróconej formie na moim blogu³, a także opowiadałem onich na różnych konferencjach, gdzie po raz pierwszy były przez

²http://byop.pl³http://blog.testowka.pl

O Książce 3

odbiorców testowane.Książka jest ciągle w fazie rozwoju. Jak do tej pory ukazały

się trzy rozdziały poświęcone kolejno porównaniu Agile do kla-sycznych metod wytwarzania oprogramowania, roli Manageraw Agile, oraz nieporozumieniom wokół Scrum.

W planach są kolejne rozdziały miedzy innymi o celachtransformacji, nieporozumieniachwokół Kanbana, zespołach kros-funkcjonalnych i pewnie jeszcze kilka innych.

Książka się ciągle rozwija - rozwija nie tylko w mojej głowieale także w głowach Waszych - czytelników. Dzięki LeanPubmogę na bieżąco otrzymywać od Was feedback i pomysły nadalsze rozdziały. Serdecznie Was do tego zachęcam!

Publikacja ta jest (jak na razie)dostępna już za minimalnąkwotę 0.99$. Przy każdej okazji rozdaję też kody promocyjnepozwalające na darmowe jej pobranie. Ale, że nie ma nic zadarmo to chciałbym abyście w zamian za darmowy lub bardzotani dostęp do kolejnych publikacji dali też coś od siebie -przesyłajcie proszę wszelkie uwagi i pomysły na mojego maila[wiktor.zolnowski@gmail.com]lub publikujcie swoje komenta-rze na stronie książki w LeanPub.

Niezwykle miłym jest to, że niektórzy zWas postanowiło za-płacić za książkę, po tym jak otrzymali ją za darmo i przeczytali.Jeszcze raz serdecznie dziękuję!

“Największym wrogiem wiedzy nie jest ignorancja,lecz iluzja wiedzy”

Stephen Hawking

4

Agile to taki iteracyjnyWaterfall

Rozpoczynając pracę nad tą książką zastanawiałem się nad tymjaki temat będzie dobry na początek? Jaki mit obalić jako pierw-szy? Najlepiej zacząć od “podstaw” i tematów, które jeśli niezostaną dobrze zrozumiane to mogą mieć największe negatywnekonsekwencje. Jedynie dobre zrozumienie genezy i podstawo-wych wartoci Agile a co za tym idzie różnic pomiędzy Agilea klasycznym podejściem projektowym pozwala na uniknięciewielu błędów i problemów.

Zanim zaczniemy rozważania na temat wyższości Agile nadWaterfall i na odwrót, warto zastanowić się nad tym, czymAgiletak właściwie jest?

Na przestrzeni ostatnich kilkunastu lat Agile zyskiwało napopularności stając się jedną z najpopularniejszych, o ile nienajpopularniejszą metodą wytwarzania oprogramowania. Tenprogres przyniósł wiele nieoczekiwanych konsekwencji, gdyżilość nie zawsze idzie w parze z jakością. Niestety coraz częściejspotykam się totalnym brakiem zrozumienia tematu przez osoby,które za transformacje Agile w swoich i cudzych organizacjachsię zabierają. Zbyt często skupiamy się na samych metodach inarzędziach pomijając kontekst w jakim te narzędzia powstały ibyły z powodzeniem stosowane. Niestety tracimy wtedy możli-wość oceny czy dane narzędzie lub metoda jest odpowiednia dozastosowania w naszym kontekście.

5

Agile to taki iteracyjny Waterfall 6

Jak wiele Agile jest w Agile?Coraz więcej organizacji decyduje się na wykorzystywanie ele-mentów zwinnychmetodyk zarządzania projektami. Bycie Agilestało się trendem. Jeśli twoja firma nie jest Agile to klienci niechcą z Tobą rozmawiać. Taki trend oprócz wielu pozytywnychz punktu widzenia propagatorów Agile korzyści spowodowałrównież wszechobecną dewaluację słowa “Agile”. Teraz każdyjest Agile - cokolwiek by to nie znaczyło. Byleby tylko móc siętym pochwalić. Powstają nowe firmy prześcigające się w wymy-ślaniu certyfikacji Agile dla organizacji tylko po to, by mogły sięone chwalić kolejnym papierkiem przed swoimi klientami. Aleczy taki papier cokolwiek znaczy? Czy nie przerabialiśmy jużtego wcześniej? Czyż nie tak było z normami ISO w IT czy np.CMMI? Certyfikacja ma zapewne również pozytywne strony -jak na przykład pewna standaryzacja, czy w ogóle motywacja dojakichkolwiek działań więc nie chciał bym byście źle zrozumielimoje intencje. Nie neguję certyfikacji jako takiej, lecz poddajęw wątpliwość motywację stojącą za decyzjami o takiej czy innejcertyfikacji w organizacjach.

Przez ostatnich kilka lat zadawałem na różnych konferen-cjach i wydarzeniach dla praktyków IT trzy pytania:

1. Kto z Was pracuje w organizacji, która chwali się tym, żejest Agile, używa Scrum, Kanban lub czegoś innego w tymstylu?

2. Kto z Was jest pewien, że to, co tak naprawdę robi jegoorganizacja, można z czystym sumieniem nazwać Agile?

3. U kogo ten Agile działa spełniając oczekiwania postawio-ne przed transformacją w Agile?

O ile na pierwsze pytanie pozytywnie odpowiadała znacząca

Agile to taki iteracyjny Waterfall 7

większość uczestników konferencji, to już przy drugim w górzepozostawało zazwyczaj tylko kilkanaście rąk. Przy trzecim pyta-niu zazwyczaj pozostawało kilka osób, które przeważnie mogłemwymienić z imienia i nazwiska - świat entuzjastów i praktykówAgile w Polsce jest dosyć mały i praktycznie wszyscy się znamy.

Okazuje się, że wiele organizacji chwalących się tym, że sąAgile z prawdziwą zwinnością nie ma zbyt wiele wspólnego.Mało tego, pracownicy tychże organizacji doskonale zdają so-bie sprawę z tego, że w tym co robią na co dzień jest wielebłędów i niedomówień powodujących różne dysfunkcje. Wielerazy słyszałem, że stosujemy “tak jakby Scrum”, albo “no mamytaki Agile według naszych korporacyjnych standardów”. Kilkapytanych osób jest w stanie nawet wymienić kilka najważniej-szych dysfunkcji, które obserwują w swoich oraganizacjach alewiększość raczej bardziej “czuje”, że coś jest nie tak niż jest wstanie wskazać konkretne błędy i problemy. Wniosek nasuwasię jeden - świadomość i wiedza na temat tego czym są ZwinneMetody wytwarzania oprogramowania jest nadal bardzo niskaw organizacjach z branży IT.

W efekcie Agile staje się kolejnym buzz-wordem, przezwieluwręcz znienawidzonym. W ten sposób rodzi się pierwszy mit doobalenia - “Agile nie działa”. Przyszło nam odnaleźć się w takiej anie innej rzeczywistości, gdzie rzeczy pomimo tego, że nazwanepo imieniu nie zawsze są tym, czym by się wydawały. Pozostajejednak pytanie co my - w tym także Ty, Drogi Czytelniku może-my z tym zrobić? Pierwszym krokiem jest wiedza, która mamnadzieję po przeczytaniu tego i kolejnych rozdziałów pozwolinam na ustalenie dalszych, konkretnych działań.

Czym jest Agile? O co w tym wszystkim chodzi? Co jestważne a co nie? Nie chcę tutaj cytować definicji tego, czym jestAgile, ani też tworzyć swoich własnych. Najważniejsze jest w

Agile to taki iteracyjny Waterfall 8

tym wszystkim to, co za pomocą Agile, Lean czy czegokolwiekinnego chcemy osiągnąć, oraz to, do czego dane metody zostałystworzone. Tutaj pojawia się kolejny problem, który próbowa-łem wielokrotnie wybadać zadając trzecie pytanie dotyczącespełnienia oczekiwań stawianych przed transformacją Agile.Wiele organizacji i osób rozpoczynających takie zmiany niema skonkretyzowanych celów anie oczekiwań. W następstwiebłądzą oni trochę na ślepu próbując osiągnąć jak najwięcej zmie-niając trochę tu trochę tam i tworząc w efekcie “swóje własnepodejście do Agile”, przy okazji generując wiele problemów.

Ruch wokół Agile zapoczątkowali ludzie, którzy dostrzeglinowe możliwości wynikające z szybkiego rozwoju technik inarzędzi programistycznych. Wraz z rozwojem technologii atakże rosnącą liczbą specjalistów od programowania rosła ilośćwytwarzanego oprogramowania, które zaczęło pojawiać się wniemal każdej dziedzinie naszego życia. Oprogramowanie zdo-minowało świat który otacza nas obecnie.

Początkowo programowanie było domeną pasjonatów, któ-rzy poświęcali całe swoje życie, by rozwiązywać nietrywialneproblemy przy użyciu komputera. Z czasem wytwarzanie opro-gramowania stało się jednak bardzo lukratywnym biznesem -zwłaszcza po sukcesach startupów takich jak Microsoft czy Ap-ple (później na przykład Google i Facebook). Dodatkowo nowetechnologie i łatwy dostęp do wiedzy (popularyzacja Internetu)skusiły wiele osób do tego, by rozpocząć swoją przygodę zprogramowaniem. Prekursorzy Agile dostrzegli, że wraz z ilościąprodukowanego oprogramowania spada jego jakość. Produkcjana masową skalę bardzo często prowadziła do sytuacji, w któ-rych ludzie pracowali latami nad aplikacjami, które nigdy niezostały użyte, bądź też nie cieszyły się popularnością wśródpotencjalnych użytkowników. Aplikacje takie oczywiście nigdy

Agile to taki iteracyjny Waterfall 9

na siebie nie zarobiły a inwestorzy tracili na nich często niemałepieniądze.

Agile obok Lean Software Development oraz Lean Startupbyło i jest obecnie jedną z odpowiedzi na pytanie jak wytwarzaćoprogramowanie optymalizując koszty jego wytwarzania orazmaksymalizując zyski płynące z dostarczania użytecznej funk-cjonalności użytkownikom?

Za wytwarzanym oprogramowaniem praktycznie zawszekryje się jakiś model biznesowy, a co za tym idzie biznes.Biznes to organizacja. Agile i Lean starają się odpowiedzieć napytanie jaka powinna być organizacja, by mogła wytwarzaćwartościowe oprogramowanie w optymalny sposób. Oznaczato, że wspomniane wcześniej transformacje Agile przeważnie,docelowo znacznie wykraczają poza dział IT, obejmując całeorganizacje. W zasadzie większość powszechnie stosowanychmetod zwinnych takich jak na przykład Scrum czy Kanbandocelowo mają wywierać umiarkowany nacisk na całą orga-nizację i przy pomocy empirycznego podejścia inkrementalniewprowadzać w niej zmiany.

Agile to taki iteracyjny Waterfall 10

Czy Agile daje gwarancję sukcesu?Odpowiedź na to pytanie brzmi oczywiście: Nie - Agile tak samojak każda inna, mniej lub bardziej popularna metoda pracy,nie daje gwarancji tego, że zawsze wszystko będzie działało iprzynosiło korzyści. Agile nie jest też odpowiednim podejściemdo zarządzania pracy w każdej organizacji - czasami ilość zmiankoniecznych do wprowadzenia nie jest warta potencjalnych, leczniepewnych korzyści.

Główną zaletą zwinnych metod wytwarzania oprogramo-wania jest to, że skupiają się one na ciągłym udoskonalaniuprocesów oraz narzędzi. Duży nacisk kładziony jest także narozwój umiejętości pracowników, gdyż to właśnie indywidualneumiejętności oraz praca zespołowa są podstawą do osiągnięciasukcesu. Dzięki temu bez wzgledu na to czy próby wdrażaniapewnych praktyk zakończą się powodzeniem w efekcie po ta-kich eksperymentach nasza organizacja przynajmniej w teoriipowinna być odrobinę lepsza. Prawda jest jednak taka, że cza-sami zwiększenie świadomości co do tego jak bardzo stosowaneobecnie procesy są mało efektywne w porównaniu do zwinnychmetod może wprowadzać niemały dysonans poznawczy i pro-wadzić do obniżenia motywacji pracowników. To tylko jedno zwielu ryzyk i zagrożeń związanych z rozpoczęciem transformacjiAgile w organizacji.

Agile skupia się na skracaniu pętli informacji zwrotnej do-tyczącej tego, czy to, w jaki sposób pracujemy i to, co jestefektem naszej pracy ma sens i jest najbardziej optymalne orazefektywne. Jeśli na podstawie takiej informacji wnioskujemy, żepotrzebna jest zmiana, to po prostu coś zmieniamy. Dzięki przy-spieszonemu feedbackowi nie musimy się długo zastanawiać iplanować tego jaką decyzje podjąć? Często podejmujemy decy-

Agile to taki iteracyjny Waterfall 11

zję taką jaka “wydaje się” nam najlepsza w danym momenciei bardzo szybko ją testujemy w praktyce. Efekty widoczne sąbardzo szybko - często już po jednej iteracji, więc równie szybkomożemy zmienić decyzję i w najgorszym wypadku wrócić dostatus quo sprzed wprowadzonych zmian. Takie podejście jestz goła odmienne od tradycyjnego zarządzania projektami, gdziewszystko musi być wmaksymalnym stopniu szczegółowo zapla-nowane i przewidziane a zmiana planów oznacza uruchomieniebardzo powolnych i skomplikowanych procedur.

Odnośnie pętli zwrotnej to nawet pisząc tą książkę generujęwersję testową kilkanaście razy dziennie by zobaczyć jak wpro-wadzone właśnie zmiany wyglądają w gotowym produkcie. Dorąk czytelników kolejne wersje również trafiają dosyć często - aprzynajmniej staram się by tak było. To chyba można uznać zaAgile.

Agile to taki iteracyjny Waterfall 12

Dlaczego większość wdrożeń Agilekończy się niepowodzeniem?

Jak już wspomniałemwcześniej wwielu przypadkachwdrożenieAgile w organizacji nie przynosi oczekiwanych efektów. Bywatak zwłaszcza wtedy, gdy decyzja o zastosowaniu wspomnia-nych metodyk zapada zbyt późno - gdy organizacja jest jużpełna dysfunkcji. Często zmiany wymagają czasu - a im większaorganizacja, tym tego czasu potrzeba więcej.

Powodów niepowodzeń jest znacznie więcej - na przykładjuż samo stwierdzenie, że Agile można wdrożyć jest błędne.Aby organizacja była zwinna potrzebna jest gruntowna transfor-macja (a nie tylko wdrożenie), która zmieni sposoby zachowańposzczególnych ludzi oraz interakcji między nimi. Agile niemożna wdrożyć (w sensie zakończyć wdrożenie), gdyż transfor-macja Agile jest procesem ciągłym i nigdy się nie kończy. BycieAgile oznacza ciągłe wprowadzanie zmian, eksperymentowaniei dostosowywanie się do rynku i otaczającej nas rzeczywistości.Ta zmiana sposobu myślenia na temat transformacji Agile jestwymagana u wszystkich osób zaanagażowanych w proces nietylko wśród osób zarządzajacych organizacją.

W tej książce będę dosyć często odnosił się do Scrum, gdyżjest to jedna z najpopularniejszych ostatnio zwinnych metodstosowana powszechnie w wielu firmach. Warto zaznaczyć, żeScrum to nie to samo co Agile, jak niektórzy uważają. Nawetpoprawne wdrożenie Scrum (z moich obserwacji nadal dosyćrzadkie) nie gwarantuje osiągnięcia zwinności organizacji. Poszczegółowy opis Scrum odsyłam do Scrum Guide⁴. Zalecamlekturę w oryginalnej wersji anglojęzycznej, gdyż powszechnie

⁴http://www.scrumguides.org/

Agile to taki iteracyjny Waterfall 13

stosuje się terminologię w tym języku, a polskie tłumaczeniabrzmią wręcz fatalnie.

Scrum Guide opisuje w sposób zupełnie wystarczający całąmetodykę - wystarczy jednynie przeczytać te kilkanaście stronbardzo uważnie. Sam regularnie wracam do tej lektury. Traktujęto jako pewnego rodzaju ćwiczenie, podczas którego uważ-nie czytam analizując znaczenie każdego przeczytanego słowa(oczywiście w wersji oryginalnej - angielskiej, by nie sugerowaćsię tym, co mogło zostać utracone podczas tłumaczenia). Prak-tycznie za każdym razem odnajduję tam coś innego.

W tym miejscu zapewne określicie mnie mianem jakiegośfanatyka Scrum - nie, nie jestem fanatykiem. Scrum jest jednymz narzędzi, którego używam w swojej pracy Coacha i doradcy.Niemniej jednak należę do osób, które uważają, że dobra zna-jomość narzędzi to podstawa ich poprawnego użycia, dlategotak wiele uwagi poświęcam na eksperckie opanowanie tej czyinnej techniki. Ponadto zauważyłem, że wiele problemów or-ganizacji, z którymi współpracuję, wynika z niewłaściwego lubniekompletnego zrozumienia często wydawało by się drobnych iwręcz nieistotnych szczegółów dotyczących metod pracy. Dobraznajomość wielu narzędzi pozwala również odpowiednio dobraćnarzędzia do sytuacji.

Bardzo często słyszę od naszych klientów pytanie: ile topotrwa? Początek transformacji jest trudny zwłaszcza, gdy ma-my do czynienia z organizacją, która ma już jakąś przeszłość.Możemy tutaj wyróżnić co najmniej dwa rodzaje organizacji -takie, które stosowały już z powodzeniem zdefiniowane meto-dyki wytwarzania oprogramowania i takie, które do tej porywytwarzały oprogramowanie w sposób nazwijmy to odrobinęchaotyczny. Często granica między jednym a drugim dosyćszybko się zaciera, zwłaszcza, gdy organizacja szybko rośnie.

Agile to taki iteracyjny Waterfall 14

Wbrew pozorom w przypadku organizacji, która wcześniej sto-sowała cięższe podejście kaskadowe (ang. Waterfall) transfor-macja może być łatwiejsza niż w przypadku organizacji, wktórych żadnych zdefiniowanych metodyk wcześniej nie było.Mimo to wypracowane wcześniej nawyki mogą stanowić pe-wien problem, dlatego nie ma raczej reguły - wszystko zależy odkontekstu. Czas potrzebny do osiągnięcia widocznych efektówtransformacji zależy od bardzo wielu czynników i nie da się go zgóry przewidzieć. Jednym z głównych i najbardziej zmiennychczynników w tej układance są ludzie i ich motywacja do tegoby coś zmienić, a w zasadzie by zmiana stała się procesemciągłym - często nie tylko w pracy ale i w całym ich życiu.Z mojego doświadczenia wynika, że czasem by widoczne byłyefekty wprowadzanych zmian potrzebne jest nawet kilkanaściemiesięcy (coaching dla klienta korporacyjnego) a czesm zmianysą widoczne po kilku dniach od pierwszego spotkania z zespołem(coaching wmałym startupie - przykład opisany wmojej książce“Agile Transforacje⁵”.

⁵https://leanpub.com/agile-transformacje

Agile to taki iteracyjny Waterfall 15

Scrum a WaterfallScrum często nazywany jest “iteracyjnympodejściem dowytwa-rzania oprogramowania”. O ile stwierdzenie to nie jest błędne, toScrum ma jeszcze jedną, dużo bardziej istotną cechę - jest inkre-mentalny. Oznacza to, że co iterację będziemy dostarczać kolejnyinkrement - kolejną wersję działającej, potencjalnie gotowej dowydania na produkcję aplikacji. Ta inkrementalność jest właśnietym, co najbardziej odróżnia (z perspektywy developera) Scrumod innych iteracyjnych podejść do wytwarzania oprogramowa-nia, często bazujących nawet na modelu kaskadowym.

Inkrementem jest coś, co możemy uznać za działającą funk-cjonalność dodającą jakąś wartość do naszego produktu. Zatemnie nazwiemy inkrementem przygotowanej dokumentacji czyteż planu, nie nazwiemy inkrementem projektu architektury, nienazwiemy inkrementem raportu z testów, itd. Inkrement musibyć używalny przez potencjalnych użytkowników. Inkrementmożemy zdefiniować jako widoczna zmiana w zachowaniu sys-temu wnosząca konkrentą, zdefiniowaną wartośc dla interesa-riuszy tego systemu.

W tradycyjnym modelu kaskadowym wyróżnialiśmy po-szczególne etapy wytwarzania oprogramowania (realizacji pro-jektu informatycznego). Przeważnie są to kolejno: Analiza Wy-magań, Tworzenie Projektu Architektury, Implementacja, Testy,Wdrożenie. Podejście to działało całkiem nieźle, gdy tworzy-liśmy aplikacje pudełkowe, które po zakończeniu lądowały napółce w sklepie i albo się sprzedawały albo nie - ale to jużnie był nasz problem, gdyż w międzyczasie zaczynaliśmy jużkolejne projekty. Na każdy etap takiego projektu mogliśmy zgóry alokować pewną ilość czasu i innych zasobów, a następniemonitorować i optymalizować na bieżąco ich wykorzystanie.

Agile to taki iteracyjny Waterfall 16

Problemy przeważnie pojawiały się dopiero na etapie testów,gdzie nagle okazywało się, że zanim projekt będzie mógł przejśćw fazę wdrożenia, potrzebne są poprawki błędów, które zostaływykryte. Jeśli błędy dotyczyły samej fazy developmentu to niebył to jeszcze duży problem - wystarczyło zgłosić błąd, pocze-kać, aż developer na szybko coś połata, sprawdzić i oznaczyćjako problem rozwiązany. Gorzej jeśli błędy wykryte podczastestowania zostały zaimplementowane w fazie projektowaniarozwiązań albo co gorsza, na etapie ustalania wymagań powo-dując na przykład, że niektóre wymagania są ze sobą sprzecz-ne lub niekompletne. W takim przypadku należało cofnąć sięaż do fazy zbierania wymagań, następnie zmienić architekturęprojektu, zaimplementować zmiany i jeszcze raz przetestowaćcały system. Tak - jasne… Tak wynikałoby z teorii - niestety wswojej karierze nigdy nie spotkałem się z takim podejściem. Wzasadzie oczywistym jest to, że takie cofanie się byłoby zupełnienieopłacalne (dla projektów innych niż elektrownie jądrowe czystatki kosmiczne). Tymczasem znacznie częściej po prostu łatanona szybko znalezione błędy tak, by było jak najtaniej i najszyb-ciej. Między innymi stąd wzięło się często zadawane przeze mniepytanie: czy poprawianie błędów oznacza poprawianie jakościoprogramowania? Tego typu poprawki na szybko mogą jedynieobniżyć jakość kodu i wygenerować szereg potencjalnych pro-blemów z jego utrzymywalnością, które dopiero się pojawią - wten sposób powstaje dług techniczny.

Agile to taki iteracyjny Waterfall 17

Czy coś jest nie tak z podejściem kaskadowym?

W wytwarzaniu oprogramowania - bez względu na mo-del - koszty błędów są tym większe, im później zostały onewykryte. Dla modelu kaskadowego powstało kilka obejść tegoproblemu - jak na przykład próba zaangażowania testerów odsamego początku trwania projektu tak, by testowali już sa-mą dokumentację - na przykład “Model W⁶”. Pomimo starańniezwykle często okazywało się, że po wydaniu na produkcję,dana aplikacja nawet zgodna ze specyfikacją nie była używalnabądź też potrzebna użytkownikom. Ewidentnie coś było nie tak.Agile wydawał się być pierwszą od lat odpowiedzią na pytaniejak wytwarzać oprogramowanie wysokiej jakości, które będziejednocześnie wartościowe dla użytkowników.Właśnie magicznapętla informacji zwrotnej, oraz jej skracanie do minimum stałysię kluczowym czynnikiem pozwalającym na maksymalizacjęzysków. Właśnie dzięki skracaniu tej pętli oraz praktykom inarzędziom, które w tym celu powstały, narodziła się międzyinnymi idea Lean Startup.

⁶http://sqa.fyicenter.com/FAQ/Software-Development-Models/Software_Development_Models_W_Model.html

Agile to taki iteracyjny Waterfall 18

Water-Scrum-Fail i W-Agile.Na jednej z największych w Polsce konferencji dla testerówmiałem okazję wysłuchać wykładu, którego temat brzmiał mniejwięcej tak: “Scrumowy zespół testerski”. Sam tytuł brzmi prze-rażająco - nie ma czegoś takiego jak Scrumowy zespół testerski.To nie jest Scrum! To nawet nie jest blisko do Scrum.

Zamiast krytykować, zacząłem zastanawiać się z czego towynika i przypomniała mi się wtedy pewna historia opowiadanaprzez Tomka Włodarka - Trenera Scrum i Agile Coacha(ST) pra-cującego ówcześnie dla pewnej korporacji. Pewna pani projectmanger (PM) postanowiła udowodnić mu, że w zasadzie to niema różnicy pomiędzy Scrum a Waterfall. Wyglądało to mniejwięcej tak:

..

• PM: Skoro mamy czterotygodniową iterację to mo-żemy ją sobie podzielić na poszczególne etapy i naprzykład przez pierwszy tydzień planować i pro-jektować, później dwa tygodnie kodować, a ostatnitydzień poświęcić na testy i wdrożenie.

• ST: Nie, nie możemy…• PM: Ale poczekaj, popatrz, jak nasi architekci skoń-czą projektowanie, możemy przenieść ich do sprin-tu innego zespołu, któremu zaprojektują prace naich fazę developmentu…

• ST: Zaraz, zaraz, ale to jest Waterfall…• PM: No nie jest Waterfall bo przecież będziemypracować w sprintach. No dobrze, to może robimysobie zespół architektów pracujących w Scrum, ze-spół developerów i zespół testerów. Będziemy tylkozarządzać ich pracą.

Agile to taki iteracyjny Waterfall 19

..

• ST: Ale czym to się będzie różnić od Waterfall?• (Po czym ST narysował to na tablicy w postacikaskady)

• ST: No i co to jest Waterfall czy Agile?• PM: W… A… W…W-Agile… (czyt. Ładżajl).

Powyższy przykład jest może aż nazbyt jaskrawy, ale tegotypu wdrożenia W-Agile miałem wątpliwą przyjemność oglą-dać naprawdę w wielu organizacjach. Większość osób, którezgłaszają się do doradcy w dziedzinie Agile i Scrum, to ludzie,którzy mają duże problemy z wdrożeniem Scrum i transformacjąAgile. Jak to jeden z czytelników mojego bloga⁷ podsumował:“Ze zmian cieszy się tylko dziecko z mokrą pieluchą” - coś w tymjest. Organizacje, które nie mają problemów, lub raczej takie,które tych problemów jeszcze nie dostrzegają, nie zwracają siędo nas z prośbą o pomoc w przeprowadzaniu zmian.

Do dwóch typów organizacji (zdefiniowane procesy luborganizacja chaotyczna), w których rozpoczynamy zazwyczajtransformację Agile możemy dodać trzeci typ - organizację,która próbowała już swoich sił w Scrum ale niestety nie udało sięi powstała pewna hybryda, która niekoniecznie działała dobrze- typowy Water-Scrum-Fail.

Wracając do W-Agile (jak się okazuje niezwykle powszech-nego w wielu firmach), jednym z narzędzi służących do wykry-wania tego problemu może być wykres Story Point BurndownChart. Wykres ten przedstawia ilość Story Points, czy też in-nych jednostek estymacji, spalonych (zrealizowanych) podczasiteracji. Wykres ten opada tylko wtedy, gdy dane wymaganie

⁷http://blog.testowka.pl

Agile to taki iteracyjny Waterfall 20

zostanie zrealizowane od początku do końca zgodnie z Defi-nition of Done. Jeśli wykres wygląda tak, jak na załączonymobrazku - przez pierwszą część Sprintu jest płaski, a ostatniegodnia gwałtownie opada do zera to wiedz, że coś się dzieje… Amianowicie wiedz, że masz najprawdopodobniej do czynienia zWater-Scrum-Fail.

Story Point Burndown Chart - Water-Scrum-Fail

Wykres taki (jeśli oczywiście w Sprincie mieliśmy więcej niżjedno wymaganie - co jest zalecane) wraz ze Sprint BurndownChart (pokazującym ilość godzin pozostałych do spalenia),którywygląda “dobrze”, pokazują, że najprawdopodobniej wszystkiewymagania były rozpoczęte na raz, po czym na koniec zostałyprzetestowane na szybko, z dużym ryzykiem niepowodzeniai wątpliwą rzetelnością. Sytuacja taka jest niepożądana, gdyżnagle może okazać się, że zabraknie nam czasu na testy i wtedySprint zakończy się bez inkrementu.

Agile to taki iteracyjny Waterfall 21

Problemy tego typu mają swoje korzenie przeważnie w “si-losowości organizacji”. Tradycyjne metody wytwarzania opro-gramowania narzucały mocno wyspecjalizowaną strukturę or-ganizacyjną. Mieliśmy osobne działy analizy, programowaniai testów. Osoby w tych działach najprawdopodobniej nigdynie pracowały bezpośrednio ze sobą w jednym zespole. Jeślitaki sztywny podział nadal istnieje i pracownicy tych działównie pracują RAZEM to nie ma mowy o działającym Scrum wnaszej organizacji. Z powodu licznych biurokratycznych pro-blemów wiele organizacji decyduje się na tworzenie “wirtual-nych” - kros-funkcjonalnych zespołów Scrumowych złożonychz przedstawicieli poszczególnych działów. Rozwiązanie takienie wprowadza rewolucji w strukturach organizacyjnych, a maszanse działać. Niemniej jednak członkowie takiego zespołu mu-szą pracować RAZEM a co za tym idzie mieć wspólne cele.Jeśli widzimy problemy z Water-Fail-Scrum znaczy to, że nasz“zespół” jest tak naprawdę grupą ludzi a niekoniecznie zespołem,lub jego członkowie po prostu nie wiedzą jak wygląda pracazespołowa i czym różni się od pracy grupowej.

Scrum sam w sobie nie narzuca kolokacji zespołu, niemniejjednak sugeruje ją. Ja też to Wam sugeruję! Posadzenie testerówbliżej programistów i fizyczne zbliżenie ich do siebie daje na-prawdę bardzo dobre efekty mogące poprawić sytuację już odpierwszych dni.

Tutaj przypomina mi się historia początków mojej pracyjako tester w Code Sprinters - raczej zwinnej firmy, do którejprzyszedłem z klasycznej kaskadowo, CMMI-owej organizacji.Od samego początku zostałem posadzony w jednym pokoju,przy jednym dużym stole z programistami, co było niemałąodmianą w stosunku do wcześniejszej pracy w zespole testowymodizolowoanym od programistów trzema piętrami biurowca. Już

Agile to taki iteracyjny Waterfall 22

pierwszego dnia znalazłem błąd w oprogramowaniu więc posta-nowiłem go zgłosić do bugtrackera. Chciałem się wykazać, wieczrobiłem ładne screenshoty, opisałem krok po kroku wszystkoco robiłem by możliwe było odtworzenie błędu, dodałem od-powiednie kategorie i ustaliłem priorytet. Po chwili wszyscy wpokoju dostali maila z informacją o zgłoszonym błędzie. Jakiebyło moje zdziwienie, gdy pierwszą reakcją jednego z kolegów -programistów było pytanie: “PO CO to zgłaszałeś?”. Odpowiedzimiałem conajmniej kilka i każda z nich była bardzo dobra,w myśl dobrych praktyk testerskich etc. Niemniej jednak jegoargumenty były mocniejsze - dużo szybsze i mniej pracochłonnebyło by po prostu powiedzenie na głos, że znalazłem taki błąd wewłaśnie implementowanej funkcjonalności. Docelowo poprawkai retesty zajęła znacznie mniej czasu niż samo wypełnianiezgłoszenia. Tego dnia nauczyłem się, że dużo lepiej jest pogadać zprogramistami jeśli mamy taką możliwość niż pisać bezsensow-ną dokumentację. A gdy błędy poprawiamy na bieżąco zamiastodkładać je na później to nie ma problemu z tym, że coś namumknie i nie zostanie poprawione. Na bugtracker trafiały jedyniezgłoszenia rzeczy, które nie były na tyle pilne by zajmować sięnimi od razu - nie były szkodliwe i uciążliwe dla klientów.

Kolejnym krokiem rozwiązania problemów związanych zbrakiem pracy zespołowej i komunikacją w zespole, w razie gdy-by sama kolokacja zespołu nie zadziałała od razu, jest wprowa-dzenie limituWork in Progress (WIP). Oznacza to, że narzucamyzespołowi (czy raczej podsuwamy im taką genialną myśl) ilośćzadań, które mogą być “rozgrzebane” w danym momencie.

Na początek proponuje limit WIP = 1! Teraz powiecie, że toniedorzeczne - jak grupa np. 7 osób ma pracować nad jednymwymaganiem?! Przecież będą sobie ciągle wchodzić w drogę!Szczerze - nie wiem jak, ale wiem, że developerzy to inteligentne

Agile to taki iteracyjny Waterfall 23

bestie i wymyślą jak to zrobić najbardziej efektywnie - tak wła-śnie buduje się samo-organizację zespołu. Przykładowe studiumprzypadku z zastosowania tego rozwiązania wygląda zazwyczajmniej więcej tak:

..

• proponujemy zespołowi limit Work In Progress = 1,• zespół wyraża oburzenie i stwierdza, że przecież togłupie i nie będzie działało, ale obiecują spróbować,

• testerzy na początku iteracji jak zwykle się nudzą(ale krócej niż zwykle),

• programiści oddają pierwsze wymaganie i zaczyna-ją się nudzić,

• testerzy pod presją ze strony programistów ostrotestują, by jak najszybciej oddać wymaganie,

• w końcu z nudów programiści pomagają testeromtestować, lub piszą jakieś automaty,

• przy następnym wymaganiu testerzy dostrzegają,że w zasadzie jeśli usiądą razem z programistamii zaczną wcześniej testować, to szybciej zakończądane wymaganie,

• programiści, dzięki pracy nad testowaniem poprzed-niego wymagania lepiej rozumieją pracę testerów isą bardziej otwarci na współpracę z nimi,

• poprawia się komunikacja z testerami, testowaniezaczyna sie znacznie wcześniej niż w momencie“oddania” funkcjonalności do testów.

• do układanki możemy dopisać analityków, archi-tektów etc…

Oczywiście przeważnie będzie to trwało trochę dłużej niżjedną iterację, zanim zespół się dotrze, ale nawet ze staty-

Agile to taki iteracyjny Waterfall 24

stycznego punktu widzenia, tego typu praca nie powinna miećzasadniczego wpływu na ogólną prędkość zespołu. Mało tego,empirycznie dowiedziono⁸, że tego typu podejście (ang. SinglePiece Flow) jest bardziej efektywne niż praca nad kilkoma zada-niami równocześnie.

Aby tego typu praca była możliwa przy minimalnym ry-zyku, na Sprint Backlogu zadania powinny być w takiej samejkolejności jak na Product Backlogu. Dzięki temu w najgorszymwypadku, gdy skończy się Sprint, będziemy mieli zrobione dokońca najważniejsze zadania, a te, które nie zostały zakończone,będą zrobione w kolejnej iteracji (jeśli będzie to nadal miało sens- pamiętajcie, plany się zmieniają!).

⁸http://youtu.be/JoLHKSE8sfU

Agile to taki iteracyjny Waterfall 25

Czym więc jest Agile?Jeśli twoja organizacja jest w stanie wydawać inkrementalnieoprogramowanie i na tej podstawie uzyskiwać wartościowe in-formacje zwrotne dotyczące tego czy to, co produkujecie jest tym,czego potrzebuje rynek to z pewnością jesteście bliżej Agile niżdalej.

Jeśli ta informacja jest szybka - maksymalnie co kilka tygo-dni to istnieje duże prawdopodobieństwo, że będziecie w staniebardzo szybko reagować na potrzeby rynku i zaoszczędziciedużo pieniędzy, które prawdopodobnie zainwestowali byście wtworzenie czegoś, co jest niepotrzebne użytkownikom.

Jeśli oprócz informacji zwrotnej na temat produktu jesteściew stanie pozyskać informacje na temat efektywności waszej pra-cy i skuteczności stosowanych metod, a na tej podstawie jesteściew stanie ciągle udoskonalacie to, w jaki sposób wytwarzacieoprogramowanie to w zasadzie nic więcej nie potrzeba do tego,by wasza transformacja Agile stała się ciągłym procesem.

Jeśli ponadto stworzyliście sobie środowisko do bezpiecz-nego popełniania błędów zarówno tych w kodzie jak i tychw stosowanych metodach to gwarantuję wam, że to wszystkorazem sprawi, iż będziecie uczyć się i doskonalić swoje metodypracy bardzo, bardzo szybko.

Agile można podsumować w dwóch słowach: “Inspect &Adapt”. Eksperymentujemy i sprawdzamy rezultaty naszycheksperymentów, a na ich podstawie planujemy nowe. Wszystkow jak najkrótszych pętlach i odpowiednim, bezpiecznym i trans-parentym środowisku.