Autorzy Zapostowane przezPaweł Kałkus

Paweł Kałkus

2 WPISY 0 KOMENTARZE

0 820

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ę.

0 1163
zarządzanie projektami dla początkujących

Bycie PMem to fach dla wielu bardzo tajemniczy. Młodzi adepci tej sztuki często muszą sami dobierać sobie zestaw szkoleń, seminariów, studiów podyplomowych, czy książek i na ich podstawie budować swój warsztat.

Jak wiadomo najlepszą szkołą jest szkoła życia – dostanie się do dobrze funkcjonującej organizacji i przejście tam ścieżki od świeżaka do Senior Project Managera to jednak scenariusz dla wielu niedostępny. A co jeśli chcemy poznać podstawy zarządzania projektami, posmakować tematu, żeby podjąć bardziej świadomą decyzję o tym, czy chcemy pójść tą ścieżką zawodową?

 

O autorze, czyli kim jest Marcin Żmigrodzki

W obu przypadkach z pomocą przychodzi najnowsza książka Marcina Żmigrodzkiego – Zarządzanie projektami dla początkujących. Autor to znany w Polsce praktyk i teoretyk sztuki zarządzania projektami. Poza całym pakietem certyfikatów może się pochwalić czymś bardzo unikalnym – gry i symulacje projektowe jego autorstwa były wielokrotnie nagradzane przez Project Management Institute jako najlepsze na świecie. Żmigrodzki to również wieloletni project manager, który poza światem projektów informatycznych, telekomunikacyjnych i szkoleniowych realizuje się jako wykładowca na warszawskiej Akademii Leona Koźmińskiego i wrocławskiej Wyższej Szkole Bankowej. Warto przeczytać, co ma do powiedzenia.

 

Zarządzanie projektami dla początkujących – Zawartość

Książka zaczyna się bardzo nieszablonowo – autor zarzeka się, że nie będzie korzystał z tak popularnego w naszej branży terminu „metodyka”. Zamiast tego proponuje zdroworozsądkowe podejście do tematu oparte o kilkanaście zupełnie podstawowych dla project managera koncepcji, które każdy/a z nas powinien mieć w małym palcu.

Pojawia się zatem rozdział o powodach, dla których projekt powinien ruszyć. Autor wyjaśnia pojęcia ROI, NPV i IRR. Szybko dowiadujemy się, jak ocenić, czy projekt w ogóle warto uruchomić.

W kolejnym rozdziale zapoznajemy się z jedną z najistotniejszych ról w projekcie – sponsorem. Każdy doświadczony kierownik projektu wie, że relacje na linii sponsor – PM mogą zaważyć o sukcesie albo nieuchronnej porażce projektu.

W dalszej części książki wchodzimy w temat przygotowań do uruchomienia projektu oraz definiowania jego zakresu. Autor tłumaczy, jak ważne jest zebranie wiedzy „na start”, która pozwoli szybko ustabilizować grunt pod nogami PMa. Bez tego fundamentu prace koncepcyjne nie mają prawa ruszyć. Sam rozdział dotyczący zakresu jest naprawdę bardzo sensownie rozpisanym procesem zbierania, dzielenia i priorytetyzowania prac w projekcie. Pojawiają się takie terminy jak WBS (Work Breakdown Structure), czy Product Backlog (pojęcie znane nam głównie z frameworku Scrumowego).

Rozdział 5 poświęcony jest zespołowi projektowemu. Każdy, kto choć raz uczestniczył w jakimś projekcie (nie musiał to być nawet projekt zawodowy) doskonale zdaje sobie sprawę, jak istotne jest to, z kim przyjdzie nam go realizować.

W kolejnych rozdziałach dowiadujemy się, jak planować harmonogram oraz budżet w projekcie, a także poznajemy koncepcję zarządzania ryzykiem w projekcie. Na koniec autor poświęca kilkadziesiąt stron na omówienie sposobów monitorowania postępów prac oraz znaczenia tak podstawowej kwestii jak efektywna komunikacja.

Ostatni rozdział autor poświęca na omówienie najpopularniejszych ścieżek certyfikacyjnych.

 

Materiały dydaktyczne

Nie sposób nie zwrócić uwagi, jak wiele wysiłku autor włożył w ubogacenie treści merytorycznych o ciekawe historie i anegdoty (jak chociażby budowa kanału Panamskiego). Dzięki temu książkę czyta się bardzo przyjemnie, nie jest nudna i monotonna jak wiele innych pozycji na rynku.

Za przydatną ciekawostkę należy uznać mapę kroków w projekcie w formie gry planszowej, którą autor wprowadza na samym początku książki i przez którą prowadzi nas w trakcie jej czytania.

 

Podsumowując

Książka Żmigrodzkiego nie jest kompendium wiedzy o zarządzaniu projektami, ale trzeba też przyznać, że nie to było celem autora. Zależało mu przede wszystkim na przekazaniu, w jaki sposób doprowadzić projekt do szczęśliwego zakończenia i jak uchronić się przed minami, na które na pewno na się w trakcie tej drogi natkniemy.

Książkę polecamy nie tylko początkującym PMom, jako bardzo solidne wprowadzenie do tematu, ale również tym bardziej doświadczonym kierownikom projektów, którzy „zasiedzieli” się w swojej firmie, albo powoli przechodzą w tryb zastanawiania się „za co ja tak właściwie biorę pieniądze”. Często taka lektura pozwala zdać sobie sprawę, jak wiele już potrafimy i rozumiemy oraz ile rzeczy powinniśmy jeszcze opanować, a to z kolei podnosi naszą motywację do dalszej pracy i doskonalenia swoich umiejętności.

 

Paweł Kałkus, Jarek Łojko

 

Konkurs

Na zakończenie chcielibyśmy Was zaprosić do konkursu. Napiszcie w komentarzach, jakie Waszym zdaniem są 3 kluczowe cechy/umiejętności project managera i uzasadnijcie swój wybór. Na bazie Waszych odpowiedzi powstanie wpis na blogu, w którym postaramy się zdefiniować DNA prawdziwego kierownika projektów. 4 najlepsze odpowiedzi nagrodzimy książkami Marcina Żmigrodzkiego – Zarządzanie projektami dla początkujących.