Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00251 004856 15201043 na godz. na dobę w sumie
Agile. Szansa na skokowy wzrost produktywności - ebook/pdf
Agile. Szansa na skokowy wzrost produktywności - ebook/pdf
Autor: Liczba stron:
Wydawca: Wydawnictwo Wiedza i Praktyka Język publikacji: polski
ISBN: 978-8-3269-3449-0 Data wydania:
Lektor:
Kategoria: ebooki >> poradniki >> zarządzanie projektami
Porównaj ceny (książka, ebook (-22%), audiobook).
 Książka jest syntetycznym opracowaniem na temat coraz bardziej popularnej metodologii wdrożeń systemów informatycznych - Agile, pozwalającym znaleźć odpowiedź na pytanie: kiedy i w jakim celu zdecydować się właśnie na nią, a nie na klasyczną metodykę. Książka zawiera szczegółowe porady i praktyczne przykłady. Taka pozycja to dla Czytelników namiastka wieloletniego doświadczenia i streszczenie pogłębionej, niedostępnej gdzie indziej wiedzy z dziedziny IT, organizacji i inżynierii oprogramowania. Jest to również świetne uzupełnienie i pogłębienie szkoleń z obszaru Agile.
Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Książka jest syntetycznym opracowaniem, pozwalającym znaleźć odpowiedź na pytanie: kiedy i po co wybrać strategię Agile? Z jed- nej strony zawiera szczegółowe przepisy i praktyczne przykłady, a jednocześnie oferuje szersze spojrzenie. Taka pozycja to dla Czytelników namiastka wieloletniego doświadczenia i streszcze- nie pogłębionej, niedostępnej gdzie indziej wiedzy z dziedziny IT, organizacji, inżynierii oprogramowania. Lektura pozwoli Czytelnikom w pełni zrozumieć i wykorzystać Agi- le w najlepszy możliwy sposób. Autor tłumaczy i pokazuje na przy- kładach, jak można Agile zastosować do rozwiązywania realnych problemów biznesowych. Jest to pozycja interesująca również dla tych, którzy poznali już Agile w praktyce i chcą podnieść swoje kwalifikacje, aby pracować skuteczniej. ISBN 978-83-269-3449-0 UOR 10 Cena 79 zł e . A g i l S z a n s a n a s k o k o w y w z r o s t p r o d u k t y w n o ś c i Agile Szansa na skokowy wzrost produktywności Bogdan Bereza Bogdan Bereza Agile Szansa na skokowy wzrost produktywności Magdzie 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 zachowa- niem najwyższej staranności i wykorzystaniem wysokich kwalifikacji, wiedzy i doświadczenia au- torów oraz konsultantów. Zaproponowane w publikacji „Agile: szansa na skokowy wzrost produk- tywnoś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. 2. Spis treści Wstęp .......................................................................................................................................... 5 1. Metody zwinne – wprowadzenie ....................................................................................... 7 1.1. Metoda prób i błędów – lekarstwo na niepewność ......................................... 10 1.2. Najważniejsze fakty z historii metod iteracyjnych i przyrostowych .............. 12 1.3. Dalszy rozwój metod zwinnych – post-agilism ............................................... 13 1.4. Przegląd metod zwinnych ................................................................................... 14 1.5. Metametoda – wybór procesu ............................................................................ 20 1.6. Unikanie szkodliwych nieporozumień na temat Agile ................................... 25 1.7. Agile w kaskadowym świecie .............................................................................. 27 1.8. Integracja wielu zespołów Agile ......................................................................... 28 Od potrzeby biznesowej do zaspokojenia – zwinna realizacja ............................. 31 2.1. Etapy życia produktu: projekt, wdrożenie, utrzymanie ................................... 31 2.2. Czy klienci potrzebują dobrych produktów? .................................................. 32 2.3. Brak kosztów jakości projektów i jakości produktów ..................................... 33 2.3. Modele cyklu życia oprogramowania ................................................................ 36 2.4. Ciągła integracja i częste dostawy ...................................................................... 43 3. Zwinna inżynieria wymagań ....................................................................................... 51 3.1. Cele określania wymagań .................................................................................... 54 3.2. Techniki pozyskiwania wymagań ...................................................................... 57 3.3. Paradoksy wymagań i model Kano .................................................................... 60 3.4. Współpraca z marketingiem ............................................................................... 61 3.5. Opisywanie wymagań .......................................................................................... 63 3.6. Rodzaje wymagań – atrybuty jakości ................................................................ 64 3.7. Zasady podziału wymagań w Scrumie .............................................................. 65 3.8. Korzyści i koszty zapisywania ............................................................................. 66 3.9. Opisywanie wymagań w języku naturalnym .................................................... 69 3.10. Opowieści użytkowników ................................................................................... 70 3.11. Modelowanie wymagań ....................................................................................... 71 3.12. Zatwierdzanie wymagań ..................................................................................... 73 3.13. Weryfikacja, walidacja, negocjowanie i konsolidacja wymagań w Agile ..... 75 3.14. Interesariusze, kontekst, granica kontekstu i negocjacje w metodach zwinnych ............................................................................................................... 77 3.15. Zwinne przeglądy ................................................................................................. 79 3.16. Weryfikacja modeli .............................................................................................. 81 3.17. Zarządzanie śliskimi wymaganiami .................................................................. 82 3.18. Wersjonowanie ..................................................................................................... 84 3.19. Śledzenie powiązań wymagań ............................................................................ 86 3 4. Planowanie i nadzorowanie w Agile Scrum ................................................................. 89 4.1. Zasady dobrego planowania pracy .................................................................... 89 4.2. Przegląd sposobów szacowania pracochłonności ............................................ 92 4.3. Szacowanie algorytmiczne lub na podstawie doświadczenia ......................... 93 4.4. Planowanie w Agile: pracochłonność, wydajność zespołu, ryzyko ............... 95 4.5. Dług techniczny ................................................................................................... 97 4.6. Diagram wypalenia i jego wykorzystanie ...................................................... 101 5. Testowanie w Agile ......................................................................................................... 103 5.1. Testowanie jako jedna z form zapewnienia jakości w Agile ........................ 104 5.2. Cele, rodzaje i poziomy testów według kwadrantów testowych Agile ....... 108 5.3. Testy czarnej skrzynki i testy dogłębne .......................................................... 110 5.4. Testy właściwości (pozafunkcjonalne) w Agile ............................................. 111 5.5. Szkoła kontekstowa i testowanie eksploracyjne w Agile .............................. 113 5.6. Testowanie eksploracyjne w Agile .................................................................. 117 5.7. Podstawy automatyzacji testów w projektach Agile ..................................... 118 5.8. Automatyzacja przygotowania testów w Agile .............................................. 120 5.9. Znaczenie automatycznych testów w modelu iteracyjnym ......................... 122 5.10. Wpływ Agile na automatyzację testów ........................................................... 123 5.11. Testowanie na podstawie modeli .................................................................... 124 5.12. Projektowanie testów ........................................................................................ 125 5.13. Sposoby projektowania testów ........................................................................ 131 5.14. Agile a tradycyjne trudności testowania ........................................................ 132 5.15. Obsługa wykrytych błędów ............................................................................. 134 5.16. Testy jednostkowe ............................................................................................. 136 5.17. Metodyka TDD ................................................................................................. 136 5.18. Testy akceptacyjne a kryteria ukończenia – ATDD ..................................... 138 6. Jak być Agile i przetrwać w zespole ............................................................................. 141 6.1. Społeczne i psychologiczne aspekty pracy zwinnej ...................................... 141 6.2. Znaczenie rytuałów i terminologii Agile ....................................................... 142 6.3. Zwinny programista i jego rola w zespole Agile ........................................... 145 6.4. Metody treningu – jak stać się zwinnym ....................................................... 146 6.5. Certyfikacje ........................................................................................................ 148 6.6. Wady i zalety certyfikatów ............................................................................... 149 6.7. Wybór certyfikacji ............................................................................................. 150 6.8. Agile po pięćdziesiątce ..................................................................................... 152 6.9. Agile a kariera .................................................................................................... 153 7. Słownik terminów ........................................................................................................... 155 8. Źródła ................................................................................................................................ 157 4 Agile: szansa na skokowy wzrost produktywności Wstęp 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 oprogramo- wania. Z drugiej strony – wielka szkoda, że Agile stało się modą. Przez to bowiem bywa propagowane i stosowane bezmyślnie, a nawet gloryfikowa- ne jako niemal uniwersalne rozwiązanie, jako cel sam w sobie. Tymcza- sem 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 szcze- gółowa znajomość instrukcji praktykowania jednej ze zwinnych metodyk (najczęściej Scrum). Tym bardziej że zwykle wybór metodyki jest przypad- kowy. 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ć omawiane- go 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ć na- zwa brzmi kusząco, lecz żeby być skutecznym. Dlatego nie spisujmy lek- komyś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 tak- tyki 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, na- wet na kierowniczym stanowisku, wymagać zarówno wielkiego doświad- czenia, 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 wie- dzy z dziedziny IT, organizacji, inżynierii oprogramowania. A nawet psy- chologii, która jest potrzebna, aby umiejętnie stosować Agile. 5 Taką optykę przyjmuję w tej książce. Po pierwsze, staram się zachować bez- stronność, 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 Agi- le. Jako punkt wyjścia przyjmuję konkretną potrzebę biznesową lub tech- nologiczną, 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 Czytel- nicy, 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ć Agi- le 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 re- alizowania konkretnych potrzeb projektów IT. Zalecamy ją zarówno me- nedż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 prak- tyce i chcą podnieść swoje kwalifikacje, pracować skuteczniej, ze zrozumie- niem. 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. 6 Agile: szansa na skokowy wzrost produktywności 1. Metody zwinne – wprowadzenie Agile to podejście (ang. framework) do projektów IT, łączące wiele różno- rodnych elementów. W praktyce Agile staje się często także swego rodza- ju postawą, filozofią działania, mającą zastosowanie również poza światem informatyki. Najważniejszą cechą Agile jest iteracyjność. Zakłada się, że próba precy- zyjnego 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 zale- ca podejście iteracyjne (prototypowanie, model spiralny). Praca z wymaga- niami 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 precy- zyjnych i w pełni uzgodnionych wymagań, jest tworzeniem fikcji. Dlatego w projektach realizowanych metodami Agile dokonuje się szczegółowe- go 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. 7 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 wytwarza- nia oprogramowania, umożliwiając lepszy nadzór i skuteczniejsze kontro- lowanie 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 proce- dur definiujących role bywa nieskuteczna i pracochłonna. Czasem staje się wręcz przyczyną nieporozumień i pomyłek. Agile zakłada, że najlep- szą formą współpracy i komunikacji są intensywne, bezpośrednie kontak- ty między ludźmi. 8 Agile: szansa na skokowy wzrost produktywności 1. Metody zwinne – wprowadzenie UWAGA Często wynika z tego fałszywe mniemanie, jakoby Agile nie mogło do- starczać obszernej dokumentacji. Dokumentacja produktowa, jeśli jest wymagana przez klienta, staje się po prostu częścią produktu IT. Meto- dy 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, samoor- ganizują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ące- go 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 narzu- cającym rozwiązania. Scrum Master to rola szczególna. Najlepiej wyjaśnia ją określenie „kierow- nik 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ól- nie cały zespół scrumowy podczas planowania przebiegu oraz podczas co- dziennych 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. po- wstające opóźnienia lub niewywiązywanie się przez pojedynczych człon- ków zespołu scrumowego ze swoich zadań. Rola Scrum Mastera polega w dużym stopniu na facylitacji (rozwiązywaniu konfliktów), a w mniej- szym na nadzorze administracyjnym. Podejście Agile można zaklasyfikować do tak zwanych metod zarządza- nia przez cele. W wyniku planowania przebiegu właściciel produktu ne- gocjuje kontrakt z uczestnikami zespołu i zawiera go po zaakceptowaniu warunków przez obie strony. Zespół, w Agile Scrum zwany zespołem scru- mowym, obejmuje wszystkie role potrzebne do realizacji zadań: progra- mistó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. 9 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 pirami- dy, taka organizacja nie wystarczała. Korzystniejszy był inny tryb działa- nia: planowanie zawczasu, budowa trwająca długie lata i realizowana przez złożoną, hierarchiczną organizację. Zarządzanie procesem wymagało ob- szernej 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 manufakturo- wej 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 zasto- sowaniu 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ślni- czymi i „łowieckimi”. Wraz z dramatycznym wzrostem złożoności i bizne- sowego 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 planowa- nia 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 ty- się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 rozwo- ju – 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ć 10 Agile: szansa na skokowy wzrost produktywności 1. Metody zwinne – wprowadzenie 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łado- wo, 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ęć in- formatycznych ma charakter pionierski, tworzy odmienne od poprzednich prototypy. Dlatego proces produkcyjny, taki jak przy tworzeniu długich se- rii 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ęt- na 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 za- pewnienie jakości. Te nazwy rzeczywiście nie są najszczęśliwiej dobrane, ale niestety przyjęte. Kontrola jakości oprogramowania to test: sprawdza- my, 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 hierarchicz- nymi, 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 pro- jekt hierarchiczny, w którym za fasadą solidnej dokumentacji i zdefiniowa- nych 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 sygnali- zacyjne, 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 11 zmian i szybkość dostawy pierwszej wersji niż dokładność, trafność prze- widywań 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 odmien- nych technik i umiejętności. Z jednej strony ten mit powoduje nieuzasadnio- ną 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 spoj- rzenie 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. 12 Agile: szansa na skokowy wzrost produktywności 1. Metody zwinne – wprowadzenie JAD – Joint Application Development Tę metodę, postulującą, podobnie jak Agile, zaangażowanie klienta i użyt- kownika 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 oprogramowa- nia 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 zasto- sowanie (zaleca między innymi statystyczną kontrolę jakości oraz metody formal- ne), kładzie jednak nacisk na iteracyjność procesu wytwarzania oprogramowania. DailyBuild Codzienne budowanie – DailyBuild – stosowano już w latach 90. ubiegłe- go stulecia. Jest formą i wcześniejszą wersją stosowanej dziś w wielu pro- jektach 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 wy- bierać 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 wy- korzystywane 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 pozy- tywny. „Zwinny” brzmi lepiej niż „ociężały” i sugeruje młodość, nowocze- sność, energię, siły witalne. 13 Od czasu publikacji tekstu Roberta Martina nic się w tym względzie nie po- prawił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ć samo- dzielnie, 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 pro- gramowania ekstremalnego: Programowanie ekstremalne – doktryna religijna i metodyka programowania mająca na celu wydajne tworzenie małych, śred- nich 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 mahabha- rata, wynikające ze stosowania rozmaitych praktyk religijno-informatycznych. Ten absurdalny tekst okazuje się nieznacznie tylko zmodyfikowaną kopią z autentycznej definicji programowania ekstremalnego z „Wikipedii”. Wnio- sek: 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 Agi- le 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 wytwarza- nia 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 pro- dukcyjnego Toyoty, opisanego po raz pierwszy w 1998 roku. Pionierska w tej dziedzinie IT książka Mary i Toma Poppendiecków „Lean Software Deve- lopment: An Agile Toolkit” została wydana w 2003 roku. Lean nie jest innym czy alternatywnym podejściem ani procesem, ani me- todyką, lecz zbiorem zasad oraz technik pozwalających realizować te zasady w projektach prowadzonych według wytycznych Agile. Oczywiście zasady 14 Agile: szansa na skokowy wzrost produktywności 1. Metody zwinne – wprowadzenie 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, nie- dostateczne testy). 2. Pozyskiwanie wiedzy (dotyczącej potrzeb klienta i produktu w kolejnych itera- cjach poprzez pozyskiwanie wymagań, prototypowanie i testy akceptacyjne). 3. Odsuwanie nieodwracalnych decyzji – budowanie pod kątem maksy- malnej 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 po- dejmowanych przez zespół, ale nie narzucanych przez proces lub hie- rarchiczną 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 prak- tykom 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 magazyno- wej, natomiast w odniesieniu do procesu tworzenia oprogramowania za- sady 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 wyma- gania są niejasne i zmienne, a terminy szczególnie pilne. UWAGA Narzuca się pytanie, czy w tej sytuacji w ogóle należało tworzyć jakie- kolwiek oprogramowanie? To zagadnienie dotyczy jednak obszaru ana- lizy biznesowej i podejmowania decyzji w biznesie, a nie metod realizacji tych decyzji. Można mieć wrażenie, że wymogi błyskawicznego budowa- nia systemów, tak często stawiane wobec IT, wynikają bardziej z mody i swoistej subkultury biznesu niż z rzeczywistej potrzeby. 15 W dużym stopniu XP było inspirowane potrzebami pierwszego inter- netowego boomu w tym okresie. Z punktu widzenia biznesowego uza- sadnienia 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 wyzwa- niami, 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 ba- dania Daniela Kahnemana i Amosa Tversky’ego (nagroda Nobla z ekonomii w 2002 roku), podejmując decyzje biznesowe, często działają na nas mecha- nizmy opisane przez teorię perspektywy: pewne wybory wydają się nam lep- sze, 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ł nieja- sny, 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 ma- nieryzm 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, naj- częściej TDD, ale nie jest to konieczny warunek żadnej z metod zwinnych. Uzasadnienie XP zawiera wiele gołosłownej psychologicznej ideologii (o sy- nergii, o zaangażowaniu, o kreatywności), ale możliwe jest wskazanie rze- czywistych korzyści, wynikających ze stosowania konkretnych praktyk. Praktyki XP to: 1. Unikanie podejmowania z góry decyzji dotyczących wymagań i archi- tektury 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 sekwen- cyjnych”. 3. TDD (Test Driven Development, wytwarzanie sterowane testami) – wię- cej w rozdziale „Metodyka TDD”. Tamże opis procedury refaktoryzacji. 16 Agile: szansa na skokowy wzrost produktywności 1. Metody zwinne – wprowadzenie 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 pro- dukcji w japońskim przemyśle motoryzacyjnym, jako jedna z praktyk to- warzyszących metodykom Lean w produkcji. Mówiąc w skrócie, celem tej metody jest płynne wytwarzanie procesu bez żadnych kosztownych zapa- só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 pro- dukcji oprogramowania przeniósł duński informatyk David Anderson („Kan- ban: Successful Evolutionary Change for Your Technology Business”, 2010). Kanban, stosowany razem z Agile Scrum, bywa nazywany Scrum-ban. Cen- tralnym 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 17 przedstawiane są w postaci kart, które umieszcza się we właściwej dla ak- tualnej fazy kolumnie. Określa się obowiązujące limity dla liczby czyn- noś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 Hu- man-Powered Methodology for Small Teams: A Human-Powered Meth- odology for Small Teams” (2004). Cockburn opisuje Agile Crystal Clear jako metodykę Agile (nic dziw- nego –  Alistair jest jednym z  sygnatariuszy Manifestu Agile), do- stosowaną do niewielkich, 5–8-osobowych zespołów. Cockburn nie uległ pokusie popełnienia opisanego wcześniej błędu Arystotele- sa i nie głosił modnej tezy, że Agile Crystal jest zbawieniem dla świa- ta. Może dlatego Crystal Clear, merytorycznie ani lepsze, ani gorsze od Agile Scrum, pod względem popularności przegrało ze Scrumem. UWAGA Nie jest w IT niczym nowym, że technologie wygrywają lub przegrywają ry- walizację ze sobą nie ze względów merytorycznych, lecz mody. Język C prze- grał z językiem Pascal, obiektowa Simula przegrała z półobiektowym C++, solidny system operacyjny OS 2 przegrał z „bałaganiarskim” Windows. Nie szkodzi! Zarówno książkę Cockburna, jak i jego samego (prowadzi szkolenia) gorąco polecamy. Na pociechę zwolennikom Crystal Clear można powie- dzieć, że uprawiając Agile Scrum, realizujemy 90 postulatów Crystal Clear. Agile Scrum Pomysł Scrum pojawił się właśnie pod tą nazwą już w 1986 roku, opisany przez dwóch japońskich autorów jako filozofia zarządzania firmą, nieko- niecznie IT.W latach 90. Ken Schwaber oraz Jeff Sutherland doskonalili oraz opisywali metodykę Scrum w praktyce przemysłu IT, jednocześnie prezen- tując ją na konferencjach. W 2001 roku Schwaber i Mike Beedle opubliko- wali klasyczną dziś pozycję „Agile Software Development with Scrum”. Na początku XXI wieku powstał Scrum Alliance (scrumalliance.org), oferujący 18 Agile: szansa na skokowy wzrost produktywności
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Agile. Szansa na skokowy wzrost produktywności
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: