Dziś o pracy (dla odmiany...) Mniej więcej rok temu trafiłem do firmy, która stosuje metodologię wytwarzania programowania zwaną po angielsku "Agile". Nie wiem, czy polskie tłumaczenie "Programowanie zwinne" jest najszczęśliwsze - mi bardziej podchodzi angielska wersja i jej będę używał. Przy okazji, dla osób nieznającyh angielskiego: "agile" wymawia się "edżajl" lub "ejdżajl".
Założenia Agile są takie, żeby skupiać się na dostarczaniu działającego oprogramowania w krótkich odstępach czasu. Krótki odstęp czasu to w tym przypadku około 2-3 tygodnie. Tak więc pracuje się w 2-3 tygodniowych iteracjach, na końcu każdej z nich można zaprezentować konkretne, działające oprogramowanie. Nie ma więc dalekosiężnego planowania na kilka lat do przodu, jest za to szczegółowo zaplanowana praca na najbliższych parę tygodni.
Główną zaletą metod Agile jest to, że przez cały czas dostarczamy działające oprogramowanie, oraz że nowa (również działająca) funkcjonalność jest dostarczana regularnie, w przewidywalnych odstępach czasu. Dzięki temu widać ciągły postęp i rozwój tworzonego produktu. W każdej chwili można łatwo odpowiedzieć na pytania typu "co zostało zrobione ostatnio?", "co będzie zrobione w najbliższym czasie" bez grzebania w dokumentach ani szukania właściwych ludzi na właściwych miejscach. Użytkownicy końcowi naszych produktów wiedzą dokładnie czego się spodziewać na koniec każdego cyklu.
Bardzo ważnym elementem Agile jest ciągła komunikacja mięczy developerami w teamie, jak również bliska i ciągła komunikacja developerów z konsumentami produktu (czyli na ogół z użytkownikami biznesowymi tej samej firmy). Dzięki temu wszelkie problemy są usuwane we wczesnej fazie, a także mamy pewność, że jak użytkownik końcowy chce kółka to będzie miał kółka a nie trójkąty.
Nie mniej ważnym elementem Agile jest samozarządzalność teamu. Znając oczekiwania użytkowników końcowych, team jest w stanie samoczynnie planować kolejne iteracje w taki sposób, żeby dostarczać to, co jest potrzebne, wtedy kiedy to jest potrzebne. A więc, jeżeli Kowalski z działu Zarządzania Stolcem potrzebuje zestawu raportów analitycznych dotyczących kolorystyki surowca, a dodatkowo potrzebuje również oprogramowania do pomiarów muszli, kontaktujemy się z Kowalskim i wyciągamy od niego informacje który z tych produktów jest ważniejszy (którego potrzebuje wcześniej) i w zależności od tego planujemy kolejną iterację. Czasem oczywiście okazuje się, że kilka produktów jest równie ważnych - wówczas pracuje nad nimi kilku developerów, albo też ustala się, które elementy każdego produktu są najbardziej istotne i implementuje się te elementy w pierwszej kolejności, pozostawiając rozwijanie produktu na kolejne iteracje. Na przykład, spośród dwunastu raportów, Kowalski może wskazać trzy z nich jako bardzo ważne, kolejnych pięć jako dość ważnych a pozostałe cztery jako mało ważne, ale czasami przydatne.
Zanim przejdę do lania wody na kolejny temat, wspomnę o jeszcze jednej cesze Agile - prostocie. Prostota polega na tym, że niezależnie od stopnia złożoności końcowego produktu, każdy developer musi mieć absolutną pewność, że rozumie co konkretnie ma być dostarczone - a także musi mieć dobry plan wykonania swojej części produktu, podzielony na małe, łatwe do zrozumienia kroki. W ten sposób unika się sytuacji z trójkątami zamiast kółek.
Agile w swojej definicji jest dość ogólne; mówi raczej co trzeba osiągnąć i przy jakich wytycznych; konkretnych implementacji tej metodologii jest kilka (scrum, extreme programming, feature-driven development i parę innych, których teraz nie pamiętam). Zarówno mój poprzedni jak i obecny pracodawca używają Scrum - chyba dlatego, że spośród dostępnych opcji Scrum reprezentuje podejście najbardziej uporządkowane. Napiszę więc jeszcze parę słów o Scrum i zmykam zanim zdołam uśpić tych samobójców, którzy dotarli w lekturze aż tutaj.
W każdym teamie jest jedna osoba ("Scrum Master"), która odpowiada za stronę merytoryczną ogółu produktów dostarczanych przez team w danym sprincie ("sprint" to pojedyncza, 2-3 tygodniowa iteracja - podstawowy cykl pracy w Scrum opiera się właśnie na sprintach). Osoba taka musi być bardzo dobrze zorientowana w modelu biznesowym firmy i musi dobrze rozumieć co w danym sprincie ma być dostarczone przez team. Istotną informacją jest to, że Scrum Master może być równocześnie człokiem kilku teamów (na przykład, jeżeli development IT jest podzielony na OLAP, OLTP i DBA, Scrum Master może być członkiem wszystkich tych teamów). Raz na jakiś czas (nie rzadziej niż raz na tydzień, na ogół raz na 2-3 dni) spotyka się on z innymi Scrum Masterami (spotkanie takie nazywa się Scrum of Scrums) i wymieniają się istotnymi informacjami na temat postępu bieżących projektów.
Hierarchia Scrum Masterów jest dość płaska - jeden SM na kilka teamów, oraz jeden główny Scrum Master korporacyjny mający dobre pojęcie o całości zagadnień oraz rozstrzygający wszelkie sporne kwestie międzydziałowe. Żeby nie mnożyć ponad miarę stanowisk zarządzających, często bywa tak (aczkolwiek nie jest to regułą), że Scrum Master jest równocześnie Team Managerem jednego ze "scrumowanych" przez siebie teamów.
Każdy sprint trwa 2 lub 3 tygodnie; pierwszy dzień sprintu (czasem drugi też) jest poświęcony na planowanie. Planowanie odbywa się w dwóch sesjach - poranna, w czasie której developerzy wybierają projekty, nad którymi chcą pracować w danym sprincie (listę projektów na dany sprint ustala Scrum Master), oraz popołudniowa, w czasie której developerzy rozbijają swój kawałek sprintu na poszczególne zadania oraz przydzielają tym zadaniom kolejność, priorytety i przewidywany czas wykonania.
A potem to już leci automatycznie. Developer bierze ze swojej listy jedno zadanie i je realizuje; pod koniec każdego dnia (ew. rano nazajutrz) zmniejsza ilość godzin jaka pozostała na ukończenie danego zadania - dzięki temu widać nie tylko ile zostało do końca, ale również ile czasu developer potrzebował na konkretne zadanie. Bywa, że z początkowych, dajmy na to, pięciu godzin, po dwóch dniach robi się 10 (a więc czas rośnie zamiast maleć - bo developer błędnie wyestymował czas potrzebny na zadanie) - dlatego właśnie ważne jest dzielenie projektów na zadania możliwie małe, możliwie łatwe do oszacowania.
W każdej chwili dostępny jest wykres postępu bieżącego sprintu (tzw. Burndown) w postaci linii prostej obrazującej sytuację "idealną" (czyli taką, gdzie wszyscy developerzy zaplanowali prawidłową ilość godzin oraz zużywają idealnie zaplanowane ilości czasu na poszczególne zadania, a także nie chorują, nie mają wypadków losowych i nie zapominają regularnie aktualizować swoich godzin) z nałożonym na tą linię wykresem postępu faktycznego. Ogólna zasada jest taka, że jeżeli postęp faktyczny jest blisko linii "idealnej" wówczas nie ma się czym martwić. Jeżeli jest dużo powyżej, wówczas mamy jakiś przestój lub inny problem (dużo niedoszacowanych zadań albo zapominalscy developerzy nie wpisujący swich dziennych godzin). Jeżeli wreszceie jest poniżej linii "idealnej" oznacza to, że przeszacowaliśmy projekty i przydzieliliśmy do nich za dużo developerów.
Przykład takiego Burndown:
(niestety, wcięło mi obrazek przy okazji którejś zmiany providera - poszukaj sobie wykresów burndown na Google.
Należy pamiętać, że Burndown można wykreślić dla jednego developera, jednego projektu (z developerami z, być może, różnych teamów), jednego teamu, kilku teamów, całej firmy - jest to bardzo wygodne narzędzie obrazujące bieżący postęp pracy na wszystkich poziomach korporacyjnych.
Ponieważ Agile (i Scrum) polega, ze swojej definicji, na ścisłej i ciągłej współpracy wewnątrzteamowej, zdarza się dość często, że developerzy, którzy przeszacowali swoje projekty, po ukończeniu pracy nad nimi przejmują zadania od kolegów, którzy mają zaplanowane największe ilości godzin - żeby poprawić szanse ukończenia projektu w terminie. Oczywiście niektórzy developerzy mogą próbować sztucznie przeszacowywać swoje zadania - dzięki temu mogą udawać, że pracują nad zadaniem, a w rzeczywistości wypoczywać. Dlatego właśnie Scrum Master musi mieć bardzo dobre rozeznanie w projektach, żeby wychwytywać takie sytuacje najwcześniej jak się da. Oczywiście działa to też w drugą stronę - niedoświadczeni developerzy (bądź ludzie dopiero co przyjęci do pracy) mają tendencję do niedoszacowywania swoich zadań, co jest spowodowane brakiem znajomości charakterystyki biznesu i firmy ogólnie. W efekcie Burndown będzie pod koniec sprintu celował w górę zamiast zejść do zera.
Z szerszej perspektywy, każdy produkt (rozumiany w skali korporacyjnej) składa się z kawałków tworzących tzw. Backlog - elementy tego backlogu są priorytetyzowane przez Scrum Masterów (przy współpracy z użytkownikami biznesowymi) i te z najwyższymi priorytetami trafiają do kolejnych sprintów. Dzięki współpracy SM-ów między sobą wszystko daje się w miarę sensownie zsynchronizować na poziomie całej firmy. Oczywiście zdarzają się czasem sytuacje, że przestój w jednym dziale powoduje, że inny dział musi czekać, jednak wtedy po prostu wyciąga się z backlogu kolejne zadania (o niższych priorytetach) i pracuje się nad nimi. W ten sposób każdy team ma zawsze coś do pracy i nie marnuje się za dużo zasobów.
Na zakończenie jeszcze jak to wygląda od strony technicznej - na niedużą skalę można wdrożyć Scrum przy użyciu małych żółtych karteczek. Projekty i zadania wpisuje się na karteczki, przykleja się je do tablicy, zapisuje na każdym zadaniu ile godzin jest na nie przewidywanycn, następnie raz dziennei każdy develoepr wybiera karteczkę z sekcji "Planned" do sekcji "In Progress" i dorzuca swoje inicjały, potem skreśla się godziny, na koniec karteczka trafia do sekcji "Done" (ewentualnie jeszcze "Review" po drodze). Burndown daje się prosto wykreślić w Excelu - i jest fajnie.
Na większą skalę trzeba już wdrożyć specjalizowane oprogramowanie do zarządzania projektami za pomocą Scrum. Zaleta jest taka, że jest większa elastyczność; wada natomiast to niewątpliwie koszt, ponieważ te zabawki tanie nie są. Zarówno licencja jak i początkowe wdrożenie mogą pochłonąć sporą część budżetu. Za to później jest już bajka.
I żyli długo i szczęśliwie...
Kawał? E tam. Do tej pory wszyscy czytający na pewno zasnęli, a oszuści skaczący od razu na koniec tylko dla samego kawału niech sobie idą na JoeMonster.org
Zacznę od cukierka, a cyjanek na koniec 😉 Bardzo mi się blog podoba i zapewne z zapałem będę go odwiedzać 🙂
Następnie, wybacz Szanowny Autorze, że pozwolę sobie znów się przyczepić 😉
1) Nie metodologia, tylko metodyka!
2) Nie zaczynałbym tłumaczenia SCRUM, od SCRUM of SCRUMS, bo to jest dalsze rozwinięcie tej metodyki na potrzeby bardziej złożonych sytuacji 🙂
3) Najistotniejsza jak mi się wydaje uwaga: to nie prawda, że zespół/SM wybiera czym się będzie zajmować i z jakim priorytetem. Pominąłeś Autorze niezwykle istotną rolę – Product Owner. On jest odpowiedzialny za priorytety i definicje zadań. Zespół zobowiązuje się do zrealizowania tylu najważniejszych zadań, ile zespołowi się wydaje, że zdąży w nadchodzącym sprincie (na podstawie estymat, commitment planning, itp. itd.).
4) SCRUM Master w zasadzie nie musi mieć bladego pojęcia o charakterystyce wykonywanego projektu. Zjawisko, które opisałeś o przeszacowywaniu można doskonale wychwycić, gdy estymuje się zgodnie z metodyką – wspólnie całym zespołem. I to jest jedno z najistotniejszych zadań SM – wychwytywanie problemów w zespole.
Niemniej jednak bardzo dobry opis – głównie z uwagi na nacisk na dobrą komunikację, która jest bardzo istotnym czynnikiem, a często pomijanym.
Na koniec jeszcze pozwolę sobie zauważyć, że skoro opis był oparty o istniejący w jakiejś firmie proces, to zapewne jest to jedna z wariacji SCRUM, których istnieje tyle co zespołów korzystających ze SCRUM 😉 Nie mam zamiaru tego podejścia z góry negować – niektóre takie "zwyrodnienia" (bez zabarwienia negatywnego) mogą być dobre – jeśli właśnie tak zespołowi się najlepiej pracuje. Zadaniem SCRUM Mastera jest stwierdzenie, czy warto zbliżyć się do ideału SCRUM i czy zespół nie mógłby pracować jeszcze sprawniej 🙂
No rewelka, ktoś z branży wreszcie się dorwał do tego nieszczęsnego bloga… Fajnie.
Z tą metodyką to pewnie masz rację; dla mnie różnica między metodologią a metodyką była dotychczas taka, że metodologia ma więcej sylab. Teraz sobie poczytałem na Wiki i już wiem, ale do jutra pewnie zapomnę. Niemniej jednak – dzięki.
Co do priorytetów – tak, zgadza się, Product Owner ustala priorytety, ale przy ścisłej współpracy z przedstawicielem/-ami Teamu. Ponieważ często jest tak, że Team wie o jakichś technologicznych zależnościach między projektami / zadaniami, i dorzuca swoje trzy grosze ("nie da się zrobić A bez B i C a więc pomimo tego, że A jest ważniejsze od B i C, wrzucamy je po B i C"). Mam w tej chwili taki właśnie projekt – Product Ownerowi wydaje się, że wie dokładnie co w którym sprincie chce dostać, a my go musimy korygować bo lepiej od niego znamy wewnętrzne zależności między systemami / modułami.
Na koniec wreszcie powiem, że zapomniałem napisać o czymś szalenie ważnym – często jest tak – zwłaszcza przy nowych wdrożeniach Scrum w środowiskach zdominowanych dotychczas przez Waterfall – że Scrum jest tylko przykrywką pełną fajnych nazw i koncepcji, a "pod maską" wciąż jest Waterfall. Trzeba naprawdę nieźle się przyłożyć żeby kadra (zarówno zarządzająca jak i ta poniżej warstwy omułków) przestawiła się na nowy tok myślenia.
Dzięki za konstruktywną krytykę.
Tak, to też bardzo częste – robimy, to co robiliśmy, ale nazwijmy to "Agile", żeby fajnie wyglądać 😉