Wpis gościnny autorstwa Magdy Nicgorskiej, zdalnej project managerki z 8-letnim doświadczeniem w zarządzaniu projektami i zespołami.
W poprzednich częściach serii opisywałam metodyki znajdujące się po lewej stronie parasola Agile. Zajmowaliśmy się tzw. lżejszymi metodykami zwinnymi, czyli organizacją pracy na poziomie zespołu. W tym wpisie przedstawię wybrane metodyki zarządzania całymi projektami, czyli szersze podejście zwinne. Będzie trochę teorii. Porównamy również metodyki zwinne z klasycznymi i zastanowimy się, jak dopasować je do projektu.
Spis treści:
- Metodyki zwinne zarządzania projektami
- Porównanie metodyk zwinnych
- Scrum of Scrums (SoS)
- Large Scale Scrum (LeSS)
- AgilePM (DSDM)
- Jak dobrać odpowiednią metodykę zwinną?
Metodyki zwinne zarządzania projektami
Pewnie się zastanawiasz, czy sam Scrum albo kanban nie byłyby nam wystarczające? W końcu dobrze organizują pracę zespołu i pozwalają zapanować nad zadaniami. Owszem, ale to za mało, aby poprowadzić złożone przedsięwzięcia.
Niektóre przedsięwzięcia będą zbyt duże, aby mogły być zrealizowane przez jeden zespół. Projekty często wymagają koordynacji wielu zespołów, podwykonawców oraz klienta. Wiemy też, że na przykład powiększenie zespołu scrumowego o kolejne osoby, nie rozwiąże problemu. Nie bez powodu nie zaleca się przekraczania pewnej ilości osób w zespole. Nie oznacza to jednak, że musimy całkowicie zrezygnować ze Scruma czy też podejścia zwinnego jako takiego.
Metodyki zwinne – porównanie
Wypracowano sposoby skalowania zarówno samego Scruma, jak i Agile do złożonych środowisk projektowych. Nie sposób opisać ich wszystkich w jednym wpisie, dlatego dzisiaj przybliżę tylko kilka wybranych.
Metodyki zwinne zarządzania projektami
| Opis | Zastosowanie | |
| SoS | Metodyka pozwalająca skalować Scruma. | Koordynacja wielu zespołów Scrum pracujących nad tym samym projektem lub kilkoma zależnymi od siebie projektami. |
| LeSS | Skalowanie Scruma; do 72 osób (8 zespołów do max 9 osób). W wersji Huge możliwe jest skalowanie nawet projektów złożonych z kilku tysięcy osób. | Koordynowanie wielu zespołów scrumowych pracujących nad jednym produktem. |
| SAFe | Pozwala zarządzać projektami liczącymi 50 osób i więcej (nawet bardzo złożone projekty). | Metodyka pozwala na zwinne zarządzanie dużymi i bardzo dużymi projektami w złożonym otoczeniu. |
| AgilePM (DSDM) | Koncentracja na potrzebie biznesowej; dostarczanie produktu dobrej jakości. | Środowisko wymagające zorganizowanej kultury korporacyjnej; wymagany pełny cykl życia projektu. |
| Prince2Agile | Dostępna certyfikacja na poziomie Foundation i Practitioner. | Organizacje, które stosują PRINCE2, ale chcą skorzystać też z zalet zwinnych metodyk. |
Scrum of Scrums – SoS
Skalowanie polega na zapewnieniu komunikacji, przepływu informacji oraz zsynchronizowanego planowania pracy pomiędzy wieloma zespołami projektowymi. Jednocześnie nadal kładzie się nacisk na unikanie zbędnej formalizacji, czy też tworzenia nadmiaru dokumentacji.
Podstawowym sposobem, który ma zapewnić synchronizację, są spotkania SoS – odpowiednik Daily Scrum. Tylko zamiast wszystkich członków zespołów, uczestniczą w nim wybrani przedstawiciele każdego zespołu (najczęściej Scrum Masterzy). W takim spotkaniu mogą uczestniczyć również osoby spoza zespołów scrumowych, ale istotne dla zapewnienia jakości rozwiązania np. – przedstawiciele biznesu czy marketingu.
Częstotliwość spotkań jest ustalana w zależności od złożoności projektu i napotykanych przeszkód. Formuła zazwyczaj jest podobna do Daily – następuje wymiana informacji o tym, co udało się zrobić od ostatniego spotkania. Co zostało zaplanowane i jakie problemy napotkały zespoły. Poruszane są przede wszystkim zagadnienia mające wpływ na pracę innych zespołów.
Large Scale Scrum – LeSS
Inną metodyką pozwalającą na skalowanie Scrum jest LeSS. W przeciwieństwie do SoS, gdzie koordynowano zespoły pracujące nad jednym projektem lub kilkoma powiązanymi projektami, LeSS zaprojektowany został do koordynacji wielu zespołów pracujących nad jednym produktem (!). Różnica polega na tym, że w SoS może być wiele produktów, w LeSS tylko jeden. Mocny nacisk kładzie na to, aby zespołu skupiały się na całościowym ujęciu produktu, a nie wyłącznie na swoim zakresie.
Zatem LeSS to nadal Scrum, tylko zapewniający skoordynowaną pracę wielu zespołów pracujących nad jednym produktem. Skoro jest jeden produkt, również Product Backlog jest wspólny dla wszystkich zespołów i jest wyłącznie jeden Product Owner. Wszyscy pracują w obrębie tego samego Sprintu, w którym ustalany jest jeden, wspólny przyrost. Wszystkie zespoły mają zdefiniowane też takie same Definition of Done. Jak widać i jak podkreślają autorzy, LeSS to nadal Scrum, tylko w nieco większej skali.
Różnice pomiędzy Scrumem w obrębie jednego zespołu, a LeSS są następujące:
- Planowanie podzielone zostało na dwie fazy. Pierwsza faza odbywa się z udziałem wszystkich zespołów i polega na podzieleniu przyrostu Sprintu między zespoły. Jest to też moment, kiedy ustala się elementy wymagające współpracy pomiędzy zespołami. Druga faza planowania odbywa się już w obrębie samego zespołu i polega na podziale i rozplanowaniu pracy w danym sprincie.
- Daily Scrum również odbywa się indywidualnie na poziomie zespołu. Jednak, mając na uwadze, że niektóre zadania mogą wymagać wymiany informacji pomiędzy zespołami, często reprezentanci blisko współpracujących zespołów uczestniczą w tych ceremoniach.
- Koordynacja – nie jest sformalizowana, twórcy zakładają jej maksymalne uproszczenie, rozmowy, szybkie załatwianie spraw zamiast ton dokumentacji: „Just Talk, Communicate in Code, Travelers, Open Space, and Communities.”
- W Less zdefiniowane są jeszcze Overall PBR, czyli Wspólne Porządkowanie Backlogu Produktu oraz Product Backlog Refinement, czyli Porządkowanie Backlogu Produktu na poziomie zespołu. Wspólne porządkowanie to spotkanie Product Ownera z przedstawicielami zespołów. Omawiane jest prawdopodobieństwo dostarczenia poszczególnych elementów Product Backlogu.
- Demo Sprintu odbywa się wspólnie ze względu na jednego Product Ownera. W demo mogą brać również udział przedstawiciele interesariuszy. Ze względu na mnogość zespołów zamiast pojedynczego prezentowania wyników pracy proponuje się np. przyjęcie formy targów, wystawy czy też bazarku, gdzie każdy zespół ma swoją przestrzeń, na której prezentuje wyniki.
- Wspólna retrospekcja (Overall Retrospective) – w przeciwieństwie do spotkania w pojedynczym zespole, wspólna retrospekcja ma na celu objęcie całego systemu, a nie poziomu pojedynczych zespołów. W spotkaniu uczestniczą Scrum Masterzy oraz wybrani przedstawiciele każdego zespołu.
AgilePM (DSDM)
„Najlepsza wartość biznesowa wyłania się, gdy projekty są powiązane z jasnymi celami biznesowymi, często dostarczają korzyści, a także angażują do współpracy ludzi zmotywowanych i umocowanych”.
Jest to metodyka powstała we współpracy z DSDM Consortium (ang. Dynamic Systems Development Method). Powyższy cytat to filozofia, która za nią stoi. Poza filozofią na AgilePM składają się jeszcze pryncypia (jest ich 8). Czym są pryncypia? Są to zasady, wartości, jakimi kierowano się określając podstawy dla tej metodyki:
- Koncentruj się na potrzebie biznesowej – dbaj o to, aby projekt miał uzasadnienie biznesowe i aby było wiadomo „Po co to robimy”.
- Dostarczaj na czas – z czasem nie negocjujemy, ustalone ramy czasowe są sztywne, nieprzekraczalne.
- Współpracuj – pamiętaj o tym, jak ważna jest współpraca między klientem i dostawcą.
- Nigdy nie idź na kompromis w kwestii jakości – jakość ma być wystarczająca, by zaspokoić potrzeby klienta.
- Buduj przyrostowo od solidnych podstaw – pamiętaj o tym, aby na samym początku przeanalizować i wystarczająco zaprojektować rozwiązanie. Wystarczająco, czyli na tyle dokładnie, żeby mieć podstawy do dalszej pracy i nadać kierunek naszemu rozwiązaniu.
- Rozwijaj iteracyjnie – od czegoś trzeba zacząć, w końcu nic nie jest doskonałe za pierwszym razem.
- Komunikuj się ciągle i jasno – wiele osób nie zdaje sobie sprawy, jak duże problemy powoduje zła komunikacja i niewłaściwy przepływ informacji.
- Demonstruj kontrolę – bynajmniej nie chodzi tu o próbę sił. :) Chodzi o to, aby każdy z członków projektu, świadomie pokazywał, że wie, co się dzieje, czym się zajmuje i jaka jest jego rola.
Oprócz pryncypiów, które wyznaczają nam wartości, jakimi powinniśmy się kierować, metodyka AgilePM definiuje proces, role oraz obowiązki, produkty oraz kluczowe praktyki. Opisuje również sposób planowania oraz kontroli.
Proces, role oraz obowiązki, produkty oraz kluczowe praktyki
- Proces – definiuje cykl życia projektu. Opisuje fazy:
- Przed projektem
- Wykonywalność
- Podstawy
- Rozwój ewolucyjny
- Wdrożenie
- Po projekcie
- Role i obowiązki – opisuje zadania ludzi w projekcie. Wyróżniamy role poziomu projektu, role zespołu i role wspierające.
- Produkty DSDM – są to wszystkie produkty biznesowe, zarządcze oraz rozwiązania techniczne powstałe w czasie projektu.
- Kluczowe praktyki – w AgilePM to: rozwój iteracyjny, priorytety MoSCow, timeboxing, modelowanie oraz warsztaty facylitowane.
Ponieważ metodyka definiuje wiele ról i produktów oraz złożony proces, na końcu wpisu zamieszczam linki do wartościowych źródeł na ten temat. W ramach wstępu warto wiedzieć, że istotnym jej elementem jest stosowanie Timeboxów (są to odpowiedniki iteracji/Sprintów w Scrumie). Istotne są również priorytety nadawane wymaganiom w celu sprawnego ustalania zakresu Timeboxa. Warto również pamiętać, że przy zwinnym dostarczaniu produktów klient płaci za pracę zespołu, a nie za produkt. Produkt powstaje w kolejnych iteracjach. Jego zakres jest zmienny w czasie trwania projektu – mogą zmieniać się priorytety oraz koncepcja rozwoju produktu. Natomiast czas, koszt oraz jakość nie podlegają negocjacjom.
Jak dobrać odpowiednią metodykę?
Pierwszą decyzją, jaką należy podjąć, będzie „Zwinnie czy tradycyjnie?”. We wprowadzeniu do Agile wspominałam już, kiedy najlepiej wybrać Agile i jakie są główne różnice między metodykami zwinnymi i tradycyjnymi. Nie zawsze organizacja, otoczenie, w którym będziemy przeprowadzać projekt, chce i będzie gotowe na wprowadzenie zwinnych metodyk. Czasem metodyka może być nam narzucona i nie będziemy mieć na nią dużego wpływu – różnie to bywa.
Aby dopasować metodykę do projektu musimy odpowiedzieć sobie na wiele pytań.
Skala
- Jaka jest skala naszego projektu?
- Czy jest to dość proste rozwiązanie, czy też dostarczenie produktu, czy może musimy zapewnić cały cykl życia projektu?
- Czy to przedsięwzięcie dla jednego, czy dla wielu zespołów?
Czas realizacji
- Czy wymagane jest, aby produkt lub jego część zostały dostarczone jak najszybciej?
- Czy możemy sobie pozwolić na długie oczekiwanie na gotowy, kompletny produkt?
- Czy czas jest krytycznym czynnikiem w projekcie, czy ważniejsze będzie dostarczenie pełnego zakresu, nawet kosztem wydłużonego czasu?
Formalizacja, dokumentacja
- Jak dużej formalizacji wymaga nasze otoczenie?
- Czy musimy uwzględniać np. wymogi organizacji dotyczące dokumentacji, procedur decyzyjnych lub organizacji zespołów?
Zależności
- Czy nasz projekt zależy od innych projektów? Czy jest częścią czegoś większego?
- Czy musimy skoordynować jeden duży projekt, czy wiele powiązanych projektów?
- Czy wymaga integracji np. różnych programów i rozwiązań?
Ograniczenia
- Jak wygląda proces decyzyjny w organizacji?
- Jak zmienne jest otoczenie?
- Jakie są wymagania odnośnie jakości i terminów?
Zakres i zmiany
- Jak dobrze zdefiniowany jest cel i zakres projektu?
- Czy zakres jest stały, czy zmienny? Czy spodziewamy się wielu zmian zakresu w czasie trwania projektu?
Jak widać, jest wiele aspektów, które należy uwzględnić przy wyborze metodyki. Każda z nich powstała z nieco innych powodów i ma nieco inne przeznaczenie. Każdy wybór będzie miał też plusy oraz minusy.
Przydatne linki i źródła:
- https://agilepm.wiki/ – przegląd metodyki AgilePM oraz dostępnej certyfikacji (strona po angielsku)
- https://narudo.pl/jak-ustalac-priorytety-czesc-2-moscow/ – Priorytety MoSCow
- https://www.youtube.com/watch?v=bBEFqUfmTck – AgilePM Explained in 30 Minutes – wprowadzenie do metodyki (wideo dostępne po angielsku)
- https://www.agilebusiness.org/page/TheDSDMAgileProjectFramework – darmowe kompendium wiedzy na temat AgilePM, może nie być wystarczające do zdania egzaminu certyfikującego, jednak zawiera wiele użytecznej wiedzy.
- https://prince2.wiki/pl/ – wiele informacji o metodyce, również w języku polskim
- https://mfiles.pl/pl/index.php/Large-scale_scrum – więcej o Less.
- https://www.scaledagileframework.com/ – strona poświęcona SAFe (po angielsku)
Magda z narudo.pl
Cześć, jestem Magda, ta z narudo.pl – entuzjastka technologii, project manager i analityk IT. Wspieram przedsiębiorców i twórców internetowych w organizacji i planowaniu oraz skutecznym wykorzystywaniu narzędzi online i sztucznej inteligencji. Wierzę w optymalizację pracy i efektywne zarządzanie, jestem gotowa podzielić się swoim doświadczeniem i wiedzą, abyśmy mogli pracować mądrzej, nie ciężej.
Na mojej stronie znajdziesz informacje dotyczące organizacji, planowania oraz wykorzystania technologii w biznesie. Zapraszam Cię do odkrywania razem ze mną tajników efektywnego zarządzania projektem, wykorzystywania narzędzi AI i rozwijania swojego biznesu. Jeśli zależy Ci na pracowaniu sprytnie, a jednocześnie skutecznie zapisz się na mój newsletter i odbierz darmowy e-book „Jak wykorzystać potencjał sztucznej inteligencji”.
Dziękuję za ten tekst, prawdę powiedziawszy przyda mi się takie zestawienie przy rozmowach na temat Scruma z “Talibami” znającymi tylko Scruma i ślepymi na jego wady :) To by po Hitchcock’owsku mocno uderzyć na początku i by potem napięcie mogło tylko rosnąć ;)
Główną wadą “czystego” Scruma jest to, że jest to Produkt sam w sobie, nastawiony na dobrą sprzedaż, z bardzo dobrym marketingiem, który niestety zepsuł “rynek” – dzisiaj praktycznie zanikła dyskusja i argumentacja, jak w tym artykule, że metodykę dobiera się do pracy do wykonania, a nie jak z taśmą Aleksandra Forda: “Dostarczymy ci Forda T w każdym kolorze, pod warunkiem, że będzie to kolor czarny”. Znaczy “Metodyka? Tak – może być każda, byle zwinna, byle był to Scrum”!
Nie tędy droga. Oglądałem kiedyś film dokumentalny o projekcie i budowie najwyższego mostu na świecie, na którejś z francuskich przełęczy. Problemem były najwyższe zbudowane do tej pory przęsła i sposób ich podniesienia. Francuski inżynier opowiadający o tym stwierdził coś, co jest kluczowe DLA KAŻDEGO PROJEKTU, W KAŻDEJ BRANŻY: “- Dobry inżynier budowlaniec powinien mieć ‘z tyłu głowy’ wszystkie techniki i narzędzia, które pojawiły się w budownictwie na przestrzeni ostatnich 4 tysięcy lat tak, by móc dobrać te, które najlepiej odpowiadają potrzebom w danym projekcie”. Do przetransportowania na miejsce budowy, podniesienia i ustawienia na miejscu przęseł zastosowano te same techniki, które zastosowali budowniczowie piramid Egipskich, kilka tysięcy lat wcześniej…
Informatyka nie liczy sobie kilku tysięcy lat, ale techniki zarządzania projektami są starsze, niż informatyka. Podobnie jak Autorka tego tekstu, nie wyobrażam sobie stawiania mostu przez Wisłę “Agilowo” i z zastosowaniem zwykłego Scruma ;) Jest taka dziedzina informatyki, którą nazywa się Inżynierią Oprogramowania, która ma znaczenie, a o której w takich dyskusjach kompletnie się zapomina, jakby myśląc, że Scrum załatwi wszystko. Zdarzało mi się już ratować projekty “załatwione” w ten sposób przez Scruma, chociaż sam jestem zwolennikiem zwinnego dostarczania Produktu, ale “z głową”!
Tak naprawdę Scruma wymyślono po to, by ograniczyć problem w projektach, jaki pojawił się na rynku – brak dobrych Analityków i “Procesu Analitycznego”, tj. usystematyzowania tego, co ma być produktem ich pracy, jak ma ona wyglądać, czemu służy. Od jakichś 10 lat obserwuję odchodzenie od pewnych ról w projekcie (przy czym nie udaje się to nie bez powodu), tj. Analityka (w znacznie mniejszym stopniu), czy też Projektanta (tutaj ta rola praktycznie zanikła), przy pojawieniu się Developera, tj. roli zawierającej w sobie kompetencje Programisty, Projektanta, częściowo Architekta i Analityka.
Z punktu widzenia zakresu projektu i pracy, która musi być wykonana, nie ma cudów – ktoś musi zanalizować zakres projektu
(Wymagania) określony czy to funkcjonalnością (Przypadkiem Użycia), “historyjką użytkownika”, czy też zadaniem. Jeśli w projekcie brakuje dobrego Analityka, to ta praca rozkłada się gdzieś pomiędzy Scrum Mastera i Developera, bo sama historyjka odpowiada na pytanie “co”, a specyfikacja musi odpowiedzieć również na pytanie “jak”. Zwykle Analityk odpowiada na wszystkie pytania zarówno “co”, jak i “jak” ma być wytworzone, z jaką jakością, z jakim zakresem informacyjnym itp. Po prostu jest to ktoś, kto koordynuje projekt w warstwie pomiędzy Product Ownerem, który koncentruje się na wartości dla Klienta a Developerem. Jest to zwykle Analityk – właściciel Wizji Rozwiązania.
Problemem nadal jest niestety zanik roli Projektanta. Spotkałem się już w praktyce zawodowej z przypadkiem powierzchownego wdrażania Scruma w projekcie kompletnie do tego nie przystosowanym (kilkadziesiąt milionów złotych, dobrze określony zakres, 60 “Developerów”, gdzie Scrum Master bezmyślnie próbował wymusić zastosowanie prostego Scruma bez przygotowania zespołu). Prezentując zakres projektu zespołowi Developerów, spotkałem się z pytaniami w rodzaju: “- No dobrze, wiemy co mamy zrobić (historyjki), ale jak mamy to zrobić?!”, albo “- OK, ale kto nam zaprojektuje bazę danych?”. To było wprost wypunktowanie braków Scruma (i przy okazji braku kompetencji konkretnego Scrum Mastera – patrz wdrożenie Zespołu do takiego a nie innego wykonania pracy, która jest do zrealizowania)!
No właśnie, to jest praca do wykonania – “jak” i koordynacja Wizji Rozwiązania, skoncentrowania jej w jednej “głowie”, dlatego najbliżej z tych metodyk zwinnych jest mi do Agile PM. Zgadzam się tam niemal z wszystkim, zwłaszcza z tym “Buduj przyrostowo od solidnych podstaw”, bo solidny model na początku projektu to podstawa! Każdy projekt przypomina raczej strukturę hierarchiczną, wtedy jest sprawnie zarządzany, natomiast Scrum wprowadza pewną anarchię i brak odpowiedzi na pytanie, kto odpowiada za realizację Wizji Rozwiązania? Kto jest właścicielem tej wizji? Na poziomie Produktu – Product Owner, ale na poziomie Wizji Rozwiązania? Architekt? Nie – powinien za to odpowiadać Analityk! Ta odpowiedzialność w Scrumie jest rozproszona, co generuje w projekcie ryzyka.
W Agile PM brakuje mi jednego pryncypium: “Konsekwentnie zarządzaj zmianą”, co jest nieco w sprzeczności i neguje “dostarczaj na czas” rozumiane jako bezwzględne trzymanie się ustalonego terminu. Bo kto go ustala? I czy to uwzględnia zarządzanie zmianą? Bo każda zmiana może podważyć ustalone terminy wynikające z pracochłonności i efektywności zespołu! Ja znam swoją efektywność, bo gromadziłem statystyki w projektach, w których brałem udział (zawsze musiałem określić czas realizacji Analizy, zawsze musiałem znać jej zakres – to było zawsze moje założenie przy szacowaniu czasu realizacji). W dużych, trwających długo projektach, zmian może pojawić się w trakcie bardzo wiele, w szczególności jedna kluczowa – podważenie zasadności biznesowej projektu. I co wtedy? Trzymamy się terminów?
Jest ponadto jeszcze jedno kryterium w dobieraniu metodyki do projektu, poniekąd wynikające z tego, co napisałem, tj. kompetencje zespołu projektowego. Otóż, jeśli są one za słabe a projekt duży, kluczową rolę pełnią Analityk, Projektant, Architekt w projekcie. Po prostu – wszelkie zwinne metodyki kładą nacisk na wysokie kompetencje Developerów i pewną uniwersalność tej roli, przy bardzo dobrych umiejętnościach interpersonalnych, w komunikacji w zespole. Programista i “dobra komunikacja”, to często nie idzie ze sobą w parze (przy całym szacunku dla Programistów!).
Po prostu, Programista musi być poniekąd introwertykiem/perfekcjonistą, koncentrować się na szczegółach, dbać o detale, pracując na poziomie niemal atomowym – kodu, a to zazwyczaj nie idzie w parze z dobrą komunikacją na poziomach bardziej abstrakcyjnych, tykających Wizji Rozwiązania – generuje to problemy ze spójnością tej wizji. Lepiej powierzyć część kompetencji związanych z Wizją Rozwiązania dedykowanym, wyspecjalizowanym rolom (Analityk, Architekt, Projektant), zamiast liczyć na to, że zajmą się tym “wszyscy”, co zwykle znaczy – nikt! Taki zespół jest tak słaby, jak najsłabsze jego ogniwo, czy to jeśli chodzi o personę, rolę, czy też pracę do wykonania w WBSie projektu, a bywa, że tym słabym ogniwem jest Wizja Rozwiązania, często eklektyczna, niespójna, niepełna, niekonsekwenta, niejednoznaczna, nadmiernie skomplikowana! To dlatego właśnie nie buduje się mostów “Agilowo” – nie przeżyłby pewnie żaden Architekt (ten od architektury mostów, czy domów). Oni tradycyjnie stoją pod mostem w trakcie prób obciążeniowych, gwarantując swoim życiem, że opracowali Wizję Rozwiązania z należytą starannością ;)
Jest jeszcze jedno zagadnienie, które wpływa na wybór metodyki, ale poniekąd poruszone w tekście – produkt i jego czas życia, sposób obsługi, przeznaczenie, umocowanie zespołu. Jeśli Produkt ma posłużyć organizacji na potrzeby wewnętrzne, budżet nie jest sztywny i bardziej przypomina projekty utrzymaniowe/usługę, gdzie wiadomo, że Produkt będzie żył “na bieżąco”, to wybrałbym metodyki bardziej zwinne. Jeśli produkt ma być produktem rynkowym, to ZAWSZE, PRĘDZEJ CZY PÓŹNIEJ POJAWIĄ SIĘ ZAGADNIENIA ZWIĄZANE Z UTRZYMANIEM, tj. zgłoszenia Klientów, które musi przyjąć I Linia Wsparcia i poddać Analizie Analityk Service Desk w II Linii Wsparcia, który analizuje wpływ i zakres potencjalnej zmiany na projekt, po czym przekazuje do III Linii Wsparcia – Developerom/Programistom (A powinien Projektantowi/Architektowi, ale patrz wyżej).
Poważnym problemem na tym etapie jest brak Dokumentacji Analitycznej Produktu, której zwykle nie ma w projektach Scrumowych, bo nikt nie sięga aż po utrzymanie, koncentrując się na wytworzeniu! Każdy proces można ująć w skali CMMI (Capability Maturity Model Integration – model dojrzałości organizacyjnej), która definiuje dojrzałość procesową organizacji. Można nią określić również dojrzałość procesu produkcyjnego. Scrum na tej skali wypada blado…
Pierwszy poziom – procesy realizujemy ad hoc, nie ma ustalonej metodyki ich realizacji, po zrealizowaniu zapominamy i rozchodzimy się do siebie.
Drugi poziom – procesy realizujemy powtarzalnie, ale metodykę “mamy w głowie”, tj. odchodzi ktoś z zespołu, tracimy wiedzę o tym, “jak” realizować konkretne zadanie, nowa osoba przynosi swoje pomysły na to, “jak” – tracimy czas (i co z terminami – patrz wyżej). Na tym mniej więcej poziomie, jeśli chodzi o realizację “jak”, czyli na poziomie Wizji Rozwiązania, umieścić można Scruma.
Trzeci poziom – udokumentowany, to pierwszy poziom bezpieczny. W odniesieniu do dokumentacji projektowej, dotyczyć to może w szczególności dokumentacji Analitycznej. Jeśli ją mamy, mamy dobrze wyspecyfikowaną Wizję Rozwiązania, nie boimy się zmian w zespole – wystarczy, że Developer będzie miał wymagane do realizacji kompetencje techniczne, nie musi domyślać się jak zrealizowano zadania, albo jak ma je zrealizować – ma to w dokumentacji!
Czwarty poziom, to poziom mierzalny. Dokumentacja Analityczna daje tutaj podstawy do szacowania wymiaru funkcjonalnego, choćby metodami punktów funkcyjnych, czy wręcz wymiarowania oprogramowania wspomnianymi metodami. Trudno to przecenić, bo to dokładna odpowiedź na pytanie – ile będzie trwało dane zadanie, przy założonych kompetencjach zespołu i jego składzie, mając obliczony wymiar funkcjonalności oprogramowania (poniekąd determinujący pracochłonność), przy określonej efektywności pracy zespołu. Nadal te metody wymiarowania nie są powszechnie stosowane (wymiarowanie metodą punktów funkcyjnych), bo zgadza się – są pracochłonne. Tym niemniej brak Analizy kosztuje – zwykle dużo więcej, ale na etapie funkcjonowania Produktu na rynku, czy też już przed końcem projektu, gdy przed uruchomieniem rynkowym Produktu pojawia się coś takiego, jak np. “crunch” u twórców gier, czyli praca ponad ustalone godziny. Jest to właśnie wynik nieprzemyślenia do końca tego “jak” Produkt ma być wytworzony, niedostatecznej koordynacji prac, bo nie ma jednego, ustalonego właściciela Wizji Rozwiązania, oraz braku formalnej dokumentacji tej wizji. Praca Scrumowa ma właśnie taki trochę anarchistyczny charakter i wynikające z tej anarchii problemy.
Dopowiem o skali CMMI – piąty poziom, to poziom organizacji uczącej się, która modyfikuje swoje procesy, np. Proces Produkcyjny, czy Proces Analityczny (mało która go ma – nie spotkałem się z taką, która by w ogóle wiedziała, że go potrzebuje). Po każdym projekcie mamy “Lessons Learnt”, który to etap powinien nam odpowiedzieć na pytania – co zrobić mogliśmy lepiej i dlaczego, jak zmodyfikować nasze procesy, biorąc pod uwagę zebrane wskaźniki (poziom 4 CMMI).
W swojej praktyce zawodowej, w różnej skali projektach, spotykałem się często z metodykami zwinnymi, sam je stosując, np. elementy Scrum’a, ale prawie nigdy nie był to czysty Scrum, bo po prostu metodykę narzucono, bo modna, bo ktoś zasłyszał, że tak będzie lepiej, nie przemyślawszy, czy jest dostosowana do projektu. Parę takich projektów udało mi się uratować, np. niwelując w ciągu 3 miesięcy (wraz z Kolegami Analitykami, którzy zastosowali zaproponowaną metodę i pojawili się razem ze mną w projekcie w roli “Strażaka” do ugaszenia pożaru) “dług technologiczny” – 18 miesięcy pracy bez rezultatów. Musieliśmy praktycznie zaczynać projekt od początku, od jego organizacji, ale dzięki zasadom Inżynierii Oprogramowania i Dobrym Praktykom, dobrej pracy Analityków w zespole, “zasypaliśmy” Developerów specyfikacją funkcjonalności niwelując ten wspomniany wyżej “dług” do zera!
Ważne, by metodykę dostosować do potrzeb w konkretnym Projekcie i ograniczeń, wynikających również z kompetencji Zespołu. Każde niedostosowanie metod do wymagań odnośnie pracy do wykonania (kluczowe jest jej zidentyfikowanie w Projekcie), skutkuje “rolowaniem” długu, który kiedyś komuś przychodzi spłacić – Developerowi pod koniec projektu, albo członkom zespołu Service Desk na Etapie Utrzymania i Rozwoju. W przyrodzie żadna praca nie ginie, parafrazując znane powiedzenie, co najwyżej nie ma dobrze określonego właściciela…