​Zmienność wymagań a adaptacyjność procesów w Scrumie

Jedną z najważniejszych zmian, które metodyki zwinne wprowadziły w procesie zarządzania projektem jest sposób, w jaki zarządza się wymaganiami.

Podejście do zmienności wymagań w tradycyjnych metodykach kaskadowych

Pierwotnie, jeszcze przed rewolucją, którą wprowadziły Scrum oraz inne metodyki zwinne tradycyjne kaskadowe podejście do zarządzania wymaganiami wymuszało na stronie biznesowej przygotowanie kompleksowej specyfikacji finalnego produktu, na bazie której definiowane były wymagania jeszcze przed startem projektu. Kiedy do tych wymagań zasiadał zespół deweloperski i rozpoczynała się praca wytwórcza na wszelkie zmiany było już za późno. Koszt ich wprowadzenia często przewyższał sens wdrożenia. System, który był już w trakcie budowania mógł nie być gotowy na wprowadzenie zmiany zaproponowanej już kilka tygodni po starcie prac, bo wymagałoby to szeroko zakrojonych zmian w filozofii jego działania oraz w samym kodzie źródłowym.

Sprawa ulegała jeszcze większemu skomplikowaniu kiedy w grę wchodziło wytwarzanie oprogramowania dla klienta zewnętrznego. Firma dostarczająca produkt zgodziła się na określony zakres zdefiniowany w dokumencie, zadeklarowała określony koszt tego rozwiązania i zobowiązała się przygotować je w określonym terminie. A zatem wszelkie zmiany w zakresie, które pojawiłyby się już po podpisaniu dokumentów i rozpoczęciu prac narażały dostawcę na kłopoty.

Ale przecież od zmian nie można uciec. Między innymi z tego powodu metodyki kaskadowe wypracowały ściśle określone procedury na wprowadzanie zmian w zakresie projektu. Tzw. change requesty miały bardzo dokładnie określić zakres zmian, ich koszt oraz wpływ na datę końca prac. Dzięki temu udało się opanować częściowo problem zmienności wymagań. Zmianie nie uległ jednak sposób myślenia – ciągle były one postrzegane jako coś niechcianego, coś, co wybija zespół deweloperski z rytmu i kładzie na szali datę dostarczenia produktu.

Nowe rozdanie, czyli metodyki zwinne

Metodyki zwinne zaadresowały ten problem wprowadzając zupełnie inne podejście do zarządzania wymaganiami. Podejście to różniło się nie tylko narzędziami, z których mógł korzystać zespół deweloperski, ale również całościową filozofią podejścia do zmienności. Zamiast się jej bać, zaczęto ją cenić. Nowe wymagania pojawiające się w trakcie trwania projektu mogą przecież pomóc finalnemu produktowi być bardziej aktualnym, odpowiadać na bieżące potrzeby rynku.

Sprinty jako odpowiedź na „niekończące się projekty”

Jednym z podstawowych narzędzi, które pozwala zaadresować zmienność wymagań w zwinnym projekcie są tzw. Sprinty, czyli krótkie przedziały czasu, w ramach których zespół deweloperski zobowiązuje się dostarczyć określony zestaw funkcjonalności (często nazywanych historyjkami użytkownika). W tym podejściu zespół nie zamyka się na pół roku sam ze sobą, żeby dostarczyć kompletny produkt, na który składa się długa lista wymagań, tylko „paczkuje” te wymagania w sensowne z biznesowego punktu widzenia kawałki i dostarcza je w krótszych przedziałach czasowych. Dzięki Sprintom strona biznesowa jest w stanie szybciej pozyskać określoną w zakresie Sprintu wartość, zespół deweloperski ryzykuje mniej, bo może szybciej zweryfikować, czy wytworzony produkt odpowiada potrzebom zleceniodawcy, a finalny odbiorca rozwiązania (użytkownik) otrzymuje produkt aktualny, będący odpowiedzią na bieżące wymagania rynkowe.

Product backlog

Drugim fundamentem pozwalającym zwinnemu zespołowi adoptować się do ciągłych zmian jest tzw. backlog produktu, czyli miejsce, w którym w sposób ciągły redefiniuje się jego zakres. Praca w Sprintach bez backlogu byłaby możliwa (można na przykład podzielić pierwotny zakres produktu zdefiniowany w specyfikacji na miesięczne interwały), ale byłby to właściwie powrót do prowadzenia projektu w sposób kaskadowy (przynajmniej w aspekcie zarządzania zmiennością wymagań, której to dotyczy ten wpis). Product backlog (angielski odpowiednik pojęcia, którym będziemy się posługiwać) jest tak naprawdę nieodłącznym elementem zwinnego zarządzania projektami, ponieważ służy jako miejsce, w którym agreguje się wszystkie nowe pomysły, zmiany, błędy, itp. które pojawiły się w głowie zleceniodawcy już w trakcie trwania projektu.

Backlog powinien być stale zarządzany przez tzw. właściciela produktu (czyli stronę biznesową), który musi stale dbać o to, żeby na samej górze listy potrzeb biznesowych (backlog często występuje właśnie w formie listy) były elementy aktualne, dokładnie zdefiniowane i dostarczalne w krótkim przedziale czasowym. W świecie metodyk zwinnych często pojawia się akronim INVEST, który ma pomóc stronie biznesowej w tworzeniu historyjek użytkownika.

• I – Independent (Niezależne) – Historyjki muszą być od siebie odseparowane, a to oznacza, że da się je realizować osobno.
• N – Negotiable (Negocjowalne) – Kształt historyjki wynika z negocjacji na linii zleceniodawca – dostawca. Historyjka nie jest jednostronnie zdefiniowanym elementem, który może się okazać niemożliwy do wykonania.
• V – Valuable (Wartościowe) – Każda historyjka powinna dostarczyć końcowemu użytkownikowi określoną korzyść.
• E – Estimable (Możliwe do oszacowania) – Historyjka nie może być tak obszerna, że nie da się oszacować jej pracochłonności.
• S – Small (Mała) – Historyjki muszą być na tyle małe, żeby można je było zrealizować w jednym sprincie.
• T – Testable (Możliwe do przetestowania) – Opis historyjki powinien pozwolić na przeprowadzenie testów i weryfikację, czy gotowe rozwiązanie dostarcza korzyść biznesową.

Warto tutaj wspomnieć, że w Scrumie zespół deweloperski bierze aktywny udział w pracach nad backlogiem. Co prawda właściciel produktu (tzw. Product Owner) finalnie decyduje, co znajduje się na samym szczycie listy (a więc co jest najważniejsze dla produktu w danym momencie), ale sama zawartość tej listy może być często modyfikowania (w porozumieniu z Product Ownerem) przez członków zespołu (np. dodawane są wyceny, historyjki dzieli się na mniejsze taski, aktualizuje się ich opisy).

Sprint backlog i planowanie sprintu

Poza pracą w sprintach metodyki zwinne wprowadziły również określony zestaw spotkań, które mają na celu sprawne określenie zakresu danego sprintu, monitoring postępów prac, a także ich podsumowanie. W Scrumie zdefiniowane zostały 4 kluczowe wydarzenia (tzw. eventy):

• Planowanie
• Daily
• Podsumowanie
• Retrospekcja

Dla procesu zarządzania zmiennością wymagań absolutnie kluczowe znaczenie ma pierwszy element powyższej listy, czyli Planowanie sprintu. To na tym spotkaniu zespół decyduje, co z listy wymagań (Product backlogu) dostarczy w ciągu najbliższego Sprintu. Product Owner sygnalizuje, które historyjki są dla niego najistotniejsze poprzez umieszczenie ich na samej górze listy, ale to zespół decyduje (negocjując z Product Ownerem), jak wiele tematów jest w stanie wziąć na swoje barki.

Wynikiem Planowania jest tzw. Sprint backlog, czyli zakres najbliższego sprintu. Kluczowe założenie, które przyświecało twórcom Scruma, kiedy określali sposób pracy ze Sprint backlogiem to przerzucenie pełnej odpowiedzialności za dostarczenie wyników Sprintu na zespół.

Drugim istotny z punktu widzenia zmienności wymagań wydarzeniem scrumowym jest Podsumowanie sprintu. To w trakcie tego spotkania zespół przedstawia rezultaty pracy z ostatniego Sprintu oraz wysłuchuje uwag od zleceniodawcy. Jest to bardzo dobra okazja do zrewidowania założeń, którymi zespół kierował się do tej pory, wprowadzenia zmian do zakresu projektu (Product backlogu) oraz modyfikacji priorytetów w kontekście planowania kolejnego sprintu.

Podsumowanie

Metodyki zwinne, a w szczególności Scrum, wypracowały skuteczny sposób na adaptowanie się do zmiennego środowiska biznesowego, w którym są wykorzystywane. Scrum największą popularność zdobył w branży informatycznej, w której potrzeba elastyczności i otwartości na zmianę jest bardzo duża. Nie oznacza to jednak, że podejście zwinne jest lekarstwem na problemy z zakresem we wszystkich projektach. W pewnych branżach (np. budownictwo) często nie możemy sobie pozwolić na  iteracyjne podejście do projektu. Stawiając wieżowiec, musimy już na starcie projektu znać dokładny zakres potrzebnych prac, ponieważ nie będziemy w stanie modyfikować fundamentów budynku, kładąc 34 piętro. Scrum i zwinne zarządzanie wymaganiami nie jest zatem lekarstwem na wszystkie projektowe bolączki. Może jednak znacząco ułatwić proces wytwórczy oprogramowania, pod warunkiem, że zarówno strona biznesowa, jak i zespół deweloperski w pełni rozumieją jego filozofię.