niedziela, 30 września 2007

Wielkość funkcjonalności

Dzisiaj będzie krótko ale treściwie. Dość często zespoły wdrażające zwinne zarządzanie projektami stają przed problem wielkości funkcjonalności. Brzmi to trochę abstrakcyjnie, ale w praktyce objawia sie w prosty sposób. Otóż osoby wytwarzające nasz produkt mówią kierownikowi, że funkcjonalność, która jest przewidziana do realizacji w iteracji jest zbyt duża żeby ją skończyć w ramach jednej iteracji. Co wtedy? Odpowiedź prawidłowa jest tylko jedna: należy podzielić tą funkcjonalność na mniejsze. Zawsze po iteracji ma być dostarczona nowa wartość dodana dla klienta. Dlatego funkcjonalność, której nie można zrobić w okresie jednej iteracji (znaczy: na koniec iteracji nie będzie działała) nie spełnia wymogów dostarczenia nowej wartości dodanej. Funkcjonalność zbyt dużą do wykonania w jednej iteracji trzeba podzielić tak, aby w każdej z iteracji dostarczać coś działającego, co będzie miało realną wartość dla klienta. Klient będzie mógł to obejrzeć i dać nam informacje zwrotne jak mu się podoba.

Zarządzanie zwinne najlepiej działa jeżeli różnica między najmniejszą a największą funkcjonalnością jaką operujemy to mniej więcej rząd wielkości. Czyli największa jest około 10 razy większa od najmniejszej. Przy takim doborze wielkości najlepiej działają wszystkie metody szacowania dla projektów zwinnych. Jeżeli funkcjonalności w naszym projekcie po pierwszej identyfikacji nie mieszczą się w tych granicach to należy je dostosować: to co jest za małe połączyć, to co jest za duże podzielić. Operacje dostosowywania wielkości funkcjonalności powinny się odbywać na poziomie planowania wersji (zobacz: poziomy planowania).

niedziela, 23 września 2007

Metody zwinne a struktura organizacyjna

Czy struktura organizacji może mieć wpływ na zdolność do działania z wykorzystaniem metod zwinnych? Mogłoby się wydawać, że nie bo co ma struktura organizacji do metod wykorzystywanych w konkretnym projekcie. A jednak...

Dla uproszczenia przyjmijmy, ze mamy cztery podstawowe struktury organizacyjne:
  • Liniowa - organizacja dzieli się na działy, które realizują poszczególne elementy projektu. Każdy dział dostaje do realizacji ten kawałek projektu który odpowiada jego specjalizacji. Cała władza skupia się w rękach kierowników liniowych.
  • Macierzowa słaba - do organizacji liniowej wprowadza się koordynatorów projektów, którzy koordynują pracę osób w poszczególnych działach. Ich zadaniem jest jednak jedynie koordynacja prac, bez możliwości realnego wpływania na pracowników. Bezpośrednimi przełożonymi pracowników są kierownicy liniowi.
  • Macierzowa silna - różni się od macierzowej słabej tym, że pojawia się pełnowartościowy kierownik projektu, który ma odpowiedzialność za projekt ale również uprawnienia do władzy na członkami zespołu projektowego. Kierownicy liniowy pełnią funkcje pomocnicze dbając o zapewnienie personelu, bieżące zarządzanie kompetencjami, sprawy formalne itp.
  • Projektowa - organizacja całkowicie projektowa nie posiada struktur liniowych a tylko pulę pracowników, z których wybiera się członków zespołów projektowych. Kierownik projektu ma pełną odpowiedzialność i uprawnienia do zwierzchnictwa nad członkami zespołu projektowego.
Którą należałoby wybrać dla realizacji projektów metodami zwinnymi? Zanim się na to pytanie odpowie najpierw kilka słów o tym czym powinien charakteryzować się zespół pracujący nad projektem metodami zwinnymi. Poniżej tylko cechy właściwe dla tej dyskusji:
  1. Zespół jest interdyscyplinarny - skupia ludzi o różnych umiejętnościach ale jednocześnie każdy członek zespołu może wchodzić w różne role
  2. Zespół ponosi pełną odpowiedzialność za wykonywaną pracę
  3. Zespół ma wszelkie uprawnienia potrzebne do wykonywania zadanej pracy
  4. Kluczowy członkowie zespołu pracują tylko i wyłącznie nad jednym projektem
W przypadku organizacji o strukturze liniowej żadna z tych cech nie mogłaby być spełniona. Nie ma interdyscyplinarności - w ramach jednego zespołu linowego osoby posiadają prawie identyczne umiejętności. Zespół nie może ponosić pełnej odpowiedzialności za całość prac, bo z definicji wykonuje tylko ten jej kawałek za który odpowiada komórka organizacyjna w której pracuje. Zespół nie ma uprawnień do wykonywania całej pracy a jedynie tego kawałka, który dotyczy ich części organizacji. Ponieważ organizacja jest liniowa a nie projektowa najczęściej pracuje "nad zagadnieniem", które jest w wielu projektach. Cecha czwarta też nie jest spełniona. W takich warunkach nie można prowadzić projektu metodami zwinnymi!!!

W przypadku organizacji macierzowej słabej cecha pierwsza ma się trochę lepiej. Zespół pochodzi z różnych działów, więc jest interdyscyplinarny. Cecha druga jednak nie jest już spełniona, gdyż nadal zespół nie posiada odpowiedzialności - posiadają ją kierownicy liniowi. Podobnie z uprawnieniami - mimo iż jest zespół projektowy to nie ma on możliwości podejmowania decyzji, która leży w gestii kierowników liniowych. Co do cechy czwartej to w tej strukturze organizacyjnej często jest możliwe osiągnięcie stanu kiedy członkowie zespołu projektowego pracują nad jednym i tylko jednym projektem.

Wszystkie cechy zespołu zwinnego są możliwe do osiągnięcia tylko w organizacjach projektowych i macierzowych silnych. Macierzowe silne muszą być na tyle silne, aby rola kierowników liniowych faktycznie ograniczała się tylko do spraw administracyjnych. Trzeba mieć możliwość traktować ich jako wsparcie administracyjno-logistyczne. Jeżeli w rękach kierowników liniowych pozostanie możliwość podejmowania (blokowania) decyzji to okaże się, że zespół zwinny nie będzie miał ani uprawnień ani odpowiedzialności za projekt.

Co z tego wszystkiego wynika? Otóż jeżeli jakaś organizacja będzie chciała wdrożyć zwinne zarządzanie projektami to musi się też zastanowić nad tym, czy jednocześnie nie należy zmienić struktury organizacyjnej. Bardzo często może to powodować spięcia. Przejście z organizacji liniowych czy macierzowych słabych do bardziej zorientowanych projektowo oznacza bowiem, że kierownicy liniowi tracą część swojej władzy. To zaś zawsze jest dla ludzi trudne...

niedziela, 16 września 2007

Poziomy planowania

Dzisiaj krótko o poziomach planowania. Ostatnio musiałem tą koncepcję kilka razy tłumaczyć, co znaczy jest zapotrzebowanie na ten temat. Od razu mówię, że nie jest to kompletne omówienie tematu a raczej jego zasygnalizowanie. Kompletne omówienie zajmuje całą książkę :-)

Z bliżej nieznanych przyczyn część osób, które gdzieś tam tylko usłyszały o "agile" uważa, że w zwinnym zarządzaniu całe planowanie polega tylko i wyłącznie na zaplanowaniu tego co zostanie zrealizowane w następnej iteracji. Z tego powodu pojawia się od razu zarzut, że jest to planowanie zbyt mało dokładne i nie nadające się do "poważnych" zastosowań. Nic bardziej błędnego. Planowanie w technikach zwinnych odbywa się na kilku poziomach, z których poziom iteracji jest owszem najczęściej opisywany, ale na pewno nie jest jedyny. Poniżej skrótowy opis wybranych poziomów planowania, które muszą być zastosowane w każdym projekcie prowadzonym technikami zwinnymi (są jeszcze dwa poziomy nazwijmy je "opcjonalne").

1. Poziom produktu
Podobno chińskie przysłowie mówi, że jak nie wiesz dokąd chcesz iść to nigdy tam nie dojdziesz. Tak samo jest z projektami. Planowanie na poziomie produktu pozwala określić co tak naprawdę projekt ma przynieść. Jakie cele mają być zrealizowane. W odróżnieniu od technik tradycyjnych w technikach zwinnych na tym poziomie nie stosuje się dokładnego planowania a raczej pojęcie i koncepcję wizji produktu końcowego. Wizja ta jest realizowana w sposób zwinny - stąd nie może istnieć dokładny plan na tym poziomie. Jeżeli by istniał, to po co nam zwinność? Istnieją specjalne narzędzia wspomagające planowanie na tym poziomie.

2. Poziom wersji
Po angielsku "release". Jak już wiadomo jest co ma być oczekiwanym rezultatem końcowym produktu/projektu trzeba zaplanować kiedy kolejna wersja produktu trafi na rynek. Wersja jest to coś co jest sprzedawane komercyjnie. I tu uwaga, bo można się pomylić z iteracją. Produktem iteracji też jest działający produkt, ale niekoniecznie jest to wersja do komercyjnej sprzedaży. Natomiast produktem wersji jest zawsze produkt (wersja produktu) idący do sprzedaży i komercyjnego wdrożenia. Na etapie planowania wersji identyfikuje się funkcjonalności, które powinny się w niej znaleźć oraz określa się ile iteracji będzie potrzebnych do wyprodukowania wersji produktu zawierającego zakładane funkcjonalności. Zwykle powinno być to przynajmniej kilka (5-10) iteracji. Można, choć nie trzeba, na tym etapie przypisać wstępnie która funkcjonalność jest do zrealizowania w której iteracji - z założeniem, że to się może pozmieniać. Choć powyższe może brzmi banalnie trzeba mieć świadomość, że aby choć wstępnie określić jakie funkcjonalności przypisać do których iteracji, trzeba mieć wstępną wycenę pracochłonności poszczególnych funkcjonalności. Co czyni planowanie na tym poziomie wcale nie takim prostym jak to się wydaje na pierwszy rzut oka.

3. Poziom iteracji
Najczęściej wspominany w literaturze. Na tym poziomie należy podjąć decyzję na dwóch pod-poziomach. Zespół musi się zobowiązać które funkcjonalności zrealizuje w ramach danej iteracji oraz rozbić te funkcjonalności na zadania do wykonania. Te decyzje zwykle podejmuje sie iteracyjnie, gdyż często aby się zobowiązać do zrobienia czegoś trzeba to lepiej poznać przez rozbicie na zadania. Z drugiej strony powinno się rozbijać na zadania tylko te funkcjonalności, które mają szanse znaleźć się w najbliższej iteracji. Oczywiście przy podejmowaniu decyzji o wyborze funkcjonalności należy kierować się ogólnie przyjętymi zasadami wyboru funkcjonalności, co w praktyce często oznacza, że będzie w to zaangażowany klient lub właściciel produktu. Pamiętać należy, że plan iteracji z punktu widzenia obserwatora spoza zespołu, zgodnie z duchem zarządzania zwinnego powinien być oparty i jasno pokazywać wartość dodaną, która zostanie wytworzona w danej iteracji. Z drugiej strony na tym poziomie planowania poprzez rozbicie na zadania powstaje plan operacyjny dla zespołu pracującego nad projektem. Plan operacyjny oznacza zidentyfikowane zadania do wykonania.

4. Poziom dnia
Na poziomie dnia planuje się i kontroluje operacyjnie działanie grupy. Najgłośniejszą metodą są tu dzienne spotkania zespołu podczas których tak naprawdę jest kontrolowany status poszczególnych zadań. To pozwala porównywać wykonywane zadania z zadeklarowanymi na poziomie planowania iteracji. Daje to kierownikowi projektu natychmiastową informację zwrotną jeżeli tylko cokolwiek idzie nie tak, są odstępstwa od planu. Podkreślenia wymaga fakt, że dziennie również odbywa się planowanie. Jak to się bowiem zwykle dzieje w środowisku projektowym plan traci aktualność z chwilą jego wytworzenia. Planowanie codzienne pozwala mieć bardzo częste aktualizacje informacji o stanie rzeczywistym wykonywanych działań. W przypadku kiedy stan rzeczywisty nie odzwierciedla planu (wcześniejszego przewidywania) należy podjąć działania. W "tradycyjnej" książce czy szkoleniu byłoby w tym miejscu napisane, że działania mają mieć na celu przywrócenie projektu do zgodności z planem. Ponieważ tekst dotyczy metod zwinnych to trzeba przyjąć inną strategię: podjęte działania mają zmaksymalizować ilość dostarczanej wartości dodanej dla klienta przy zachowaniu wartości związanych ze zwinnym zarządzaniem projektami. Mówiąc po ludzku: projekt trzeba zaadoptować do zaistniałej sytuacji.

niedziela, 9 września 2007

Testowanie w projektach zwinnych

W ciągu ostatnich trzech tygodni byłem trzy razy pytany o to jak testować oprogramowanie powstające z wykorzystaniem procesów zwinnych. Pytały trzy różne, niezależne osoby. Oznacza to, że temat jest ciekawy. To co poniżej napiszę to tylko wstęp, ale na początek powinien wystarczyć.

Opiszę jak w podejściu zwinnym odbywa się (powinno się odbywać) testowanie na poziomach testowania jak zdefiniowanych tutaj.

Testowanie komponentów
To jest najprostsze. Testowanie komponentów musi odbywać się obowiązkowo w każdym projekcie realizowanym z użyciem metod zwinnych. Testowanie komponentów zawsze powinno być automatyczne. W zależności od tego w jaki sposób zespół jest przyzwyczajony pracować absolutnym minimum jest napisanie testów automatycznych pokrywających 100% napisanego kodu. Sytuacją dającą najlepsze rezultaty jest programowanie z nastawieniem "najpierw testy" oraz używanie środowiska ciągłej integracji. Chodzi mniej więcej o to, aby w sposób automatyczny wykonywały się testy całości do tej pory zaimplementowanej funkcjonalności. Po każdej zmianie kodu całość powinna być rekompilowana i testy powinny wykonywać się automatycznie. Najlepiej aby raporty z wykonania tych testów były w jakiś sposób publikowane, tak aby każdy mógł je zobaczyć. Na przykład na jakiejś stronie intranetowej.

Takie podejście jest absolutnie konieczne ze względu na dużą zmienność występującą w systemach wytwarzanych metodami zwinnymi. Jeżeli zaniedba się testy automatyczne to po kilku iteracjach w kodzie zapanuje chaos i nie będzie wiadomo co działa a co nie. Gwarantowane.

Testowanie integracji
Uwaga! Poniższe dotyczy testów integracji komponentów. Nie odnosi sie to testowania integracji systemów.

Testy integracyjne należy również zautomatyzować na ile tylko się da. Podstawowe testy integracyjne powinny być wykonywane w środowisku ciągłej integracji, czyli tak często jak się da. Najrzadziej co noc. Problem pojawia się wtedy kiedy mamy się integrować z niestabilnymi komponentami, na przykład tworzonymi równolegle przez zespoły pracujące metodami zwinnymi. Będzie to problematyczne, ale też należałoby tutaj zautomatyzować takie testy do granic, gdzie się da. Zwykle będzie to wymagało dokładnego dogadania się z innymi zespołami na temat wykorzystywanych interfejsów. Brzmi trudno, ale w praktyce powinno być tak, że mniej więcej w połowie iteracji zespoły powinny znać szczegóły interfejsów zewnętrznych swojego komponentu. To powinno zaś umożliwić zautomatyzowanie testów. Trzeba tylko uważać na ewentualne zależności w funkcjonalności poszczególnych komponentów. Takie zależności powinny być rozwiązywane na poziomie zarządzania zwinnego projektem a dokładnie na poziomie zarządzania wieloma zespołami. Przykładem techniki, która to umożliwia jest na przykład "scrum of scrums" - temat na osobny wpis/kilka wpisów.

Szczególną uwagę należy zwrócić na testy wydajnościowe. Ja zaliczam je do testów integracyjnych, gdyż poszczególny test wydajnościowy zwykle dotyczy tak naprawdę testowania współdziałania jednego bądź dwóch modułów systemu, rzadko kiedy całego systemu. Jeżeli komuś to nie pasuje to może uznać je za testy systemowe. W obu wypadkach podtrzymuję to co zaraz napiszę. Testy wydajnościowe powinny być wykonywane co najmniej raz na iterację. Powinny być wykonywane względem celu wydajnościowego ustalonego dla końcowego systemu w karcie ograniczeń produktu. Powinny obejmować wszystkie te funkcjonalności które są dostępne w danej iteracji. Powód takiego działania jest dość prosty. Otóż ze względu na iteracyjność tworzenia oprogramowania w sposób naturalny architektura rozwiązania może się zmieniać. W związku z tym powinno nam zależeć na jak najszybszym dowiedzeniu się czy aktualna architektura aby na pewno odpowiada wymaganiom stawianym przed systemem. Stąd testy wydajnościowe należy przeprowadzać z celami dla całego systemu przynajmniej raz na iterację, żeby było wiadome czy aktualna architektura i wykonanie systemu realizują założone cele.

Testowanie systemu
To najciekawszy poziom testowania z punktu widzenia metod zwinnych zarządzania projektami. Szczególnie ciekawy jest w przypadkach kiedy kilka zespołów pracuje nad kilkoma modułami stanowiącymi jeden system. Pytanie brzmi kiedy i jak testować całość systemu. Oczywiście odpowiedź brzmi, że w świecie idealnym powinno się to robić co iterację. Świat rzeczywisty wygląda jednak często tak, że nie ma na to czasu. Testy systemowe zwłaszcza dużych systemów potrafią trwać zbyt długo, aby można było sobie pozwolić na robienie ich w ramach jednej iteracji. Często głównym powodem jest tutaj fakt, że testy te wymagają dużej aktywności użytkownika końcowego i po prostu nie starczyłoby czasu. W związku z tym dla dużych systemów dopuszcza się dokonywanie testów systemu raz na każdą wersję (release) oprogramowania.

Wersja oprogramowania pojawia się w procesach zwinnych co kilka iteracji. Każda z iteracji ma na celu dostarczenie działającej wersji, potencjalnie mogącej być wysłaną do użytkownika ("potentially shipable product increment" - tak to jest w języku Shakespeare'a). Co kilka iteracji powstaje zaś "wersja" oprogramowania, która jest po prostu komercyjnym produktem mogącym iść na sprzedaż bądź być wdrożonym u klienta. Oczywiście zdarzają się przypadki, kiedy wersja powstaje w każdej iteracji, lecz doświadczenie wskazuje, że są to wtedy raczej mniejsze systemy. Systemy większe, takie które będą miały konieczność dokonania testowania systemu zwykle będą planowane na obu poziomach: wersji i iteracji. Dlaczego o tym piszę? Otóż w takich przypadkach zwykle ostatnia iteracja w wersji jest przeznaczana na testy systemowe. Zakłada się, że wartością dodaną w takiej iteracji jest dostarczenie w pełni zintegrowanego systemu. Oczywiście testy systemowe niekoniecznie muszą zajmować całą iterację. Ale na pewno przyczynią się do zmniejszenia ilości zaimplementowanej nowej funkcjonalności.

Testy akceptacyjne
Tutaj sprawa jest prosta: testy akceptacyjne wykonuje klient po przekazaniu mu każdej jednej wersji do testów. Ze względu na bliskie zaangażowanie klienta możliwe jest przekazywanie produktu nie mającego zaimplementowanych wszystkich funkcjonalności i otrzymywanie natychmiastowej informacji zwrotnej o postępach prac. W przypadku bardzo dobrej współpracy między klientem a dostawcą możliwe jest nawet przekazywanie klientowi zawierającego błędy oprogramowania w środku iteracji - po to, aby sprawdził czy koncepcja zaimplementowania którejś z funkcjonalności odpowiada jego potrzebom.

niedziela, 2 września 2007

FBS

Ostatnio napisałem o planowaniu dla wartości klienta. Jednym z narzędzi, które wydatnie w tym pomagają jest FBS. Z angielska jest to Feature Breakdown Structure, czyli struktura podziału funkcjonalności. W planowaniu zwinnym jest to odpowiednik znanej z tradycyjnego planowania struktury podziału pracy, czyli tzw. WBS. Różnica miedzy FBS a WBS tkwi w ideologii stojącej za tworzeniem jednego i drugiego.

W przypadku WBS ideologia mówi, że zakończenie projektu jest równe zakończeniu wszystkich działań podejmowanych w ramach tego projektu. Te działania mają na koniec zapewnić osiągnięcie celów założonych przy planowaniu. Dlatego tworząc strukturę podziału prac uwaga skupiona jest na czynnościach, które mają doprowadzać do stworzenia całości. Projekt jest dzielony na zadania do wykonania. Zakłada się, że wykonanie działań powoduje dojście do wyznaczonych celów. Zgodnie z tzw. zasadą 100%, która jest jedną z zasad tworzenia poprawnego WBSa określa się, że jeżeli wykonanie wszystkich działań na poziomie n WBS jest jednoznaczne ze 100% uzyskaniem elementu zdefiniowanego na poziomie n+1. I jeszcze raz: skupienie jest tu na działaniach i ich ukończeniu. Ukończenie działań, wszystkich działań, ma być gwarancją osiągnięcia efektu.

Zarządzanie zwinne proponuje podejście odmienne. Ze względu na to, że projekty zwinne są sterowane poprzez dostarczanie wartości dla klienta planowanie odbywa się nie poprzez podzielenie produktu końcowego na funkcjonalności, które mogą być dostarczane klientowi w kolejnych iteracjach. Struktura podziału dotyczy więc nie wykonywanych zadań a dostarczanych funkcjonalności. Podział większej funkcjonalności na mniejsze musi się odbywać w taki sposób, aby zidentyfikować funkcjonalności jednostkowe, które zawsze muszą mieć następujące dwie cechy (plus kilka innych, mniej ważnych z omawianego punktu widzenia):
  • funkcjonalność musi mieć realną wartość dodaną dla klienta
  • funkcjonalność musi być jednoznacznie testowalna
Pierwsza cecha gwarantuje, że podzielimy produkt na takie części jednostkowe, które na pewno wnoszą coś dla naszego klienta, co w ostateczności oznacza, że klient będzie za nie w stanie zapłacić. Po co bowiem klient miałby płacić za coś czego nie potrzebuje? To najprostszy sposób, żeby uniknąć tworzenie czegoś, co jest zbędne. Jednocześnie takie podejście w wielu przypadkach ułatwia szybkie dostarczenie produktu przynoszącego realną wartość. Pamiętać tu bowiem trzeba o zasadzie Pareto, która w tym konkretnym przypadku powie, że 20% funkcjonalności przyniesie 80% wartości dodanej. Konieczność zastanowienia się nad konkretną wartością dodaną przy każdej funkcjonalności ułatwia określenie o które 20% tak naprawdę rozgrywa się gra. Na koniec tego akapitu jeszcze raz dla podkreślenia: o tym co ma jaką wartość zawsze decyduje klient.

Drugą cechą każdej z funkcjonalności jednostkowych powinna być jednoznaczna testowalność. To znaczy już na etapie określania co jest jednostkową funkcjonalnością należy jednocześnie określić jak będzie można przetestować czy dana funkcjonalność została zrealizowana poprawnie i czy faktycznie przynosi wartość dodaną. Oczywiście chodzi tu o to, aby z punktu dostawcy jednoznacznie wiedzieć jakie są kryteria dla klienta. Kiedy klient wie, że dany kawałek produktu faktycznie jest dla niego przydatny. Jeżeli nie ma możliwości określenia tego zwykle coś jest nie tak ze zdefiniowaniem samej funkcjonalności. Z doświadczeń z rozmów z klientami wynika jednak, że w znakomitej większości przypadków doskonale wiedzą oni po co tak naprawdę jest mi potrzebna dana funkcjonalność i jak sprawdzić, czy działa ona tak jakby chcieli. Jeżeli pojawiają sie z tym problemy to zwykle w sytuacjach kiedy rozmawiamy nie z faktycznym ostatecznym użytkownikiem produktu a z jego reprezentacją wewnątrz firmy, czyli właścicielem produktu.

Podzielenie projektu na części za pomocą FBS niesie za sobą oczywiście konsekwencje w dziedzinie planowania a później zarządzania postępami prac. W projektach zwinnych w znakomitej większości przypadków śledzi się właśnie wykonanie konkretnych funkcjonalności dla klienta. Wykonanie funkcjonalności potwierdza się za pomocą ustalonych wcześniej kryteriów testów podczas gdy wykonanie tradycyjnych zadań uważa się za zakończone wtedy, kiedy wykonujący je ludzie uznają je za zakończone. To znów kwestia podejścia. W zarządzaniu zwinnym nie jest ważne jakie prace są wykonywane tylko jaka wartość dodana została stworzona. Zauważcie, że wykonanie zadań w tradycyjnych metodach z założenia może nie prowadzić do stworzenia wartości dodanej - tam wartość może pojawić się dopiero po wykonaniu 100% zadań. W zarządzaniu zwinnym kwestią dogmatyczną jest, że najlepszym raportem ze statusu projektu jest pójście do klienta i powiedzenie mu "w ostatnim miesiącu wydaliśmy EUR 10 000 i wykonaliśmy funkcjonalności F1, F2 i F3 - zostały przetestowane zgodnie z ustaleniami". Tymczasem "tradycyjny" raport postępów prac dla klienta o ile się w ogóle pojawia wygląda najczęściej tak: "w ostatnim miesiącu wydaliśmy EUR 10 000 i wykonaliśmy zadania Z1 i Z2 aktualnie mam 50% wykonania zadania Z3".

Postawcie się w pozycji klienta i zastanówcie się który raport chcielibyście usłyszeć.

I tak na koniec: planowanie za pomocą FBS ma też swoje wady. Największą z nich jest to, że aby wykonać w całości daną funkcjonalność najczęściej trzeba wykonać prace w wielu miejscach produktu na raz. To prowadzi do sytuacji, że i tak na bardzo niskim poziomie, w ramach jednej iteracji, trzeba planować zadania dla poszczególnych osób/zespołów. Drugi duży problem to wymagania niefunkcjonalne. Jak sama nazwa wskazuje nie mogą być częścią FBS a muszą być zaimplementowane. Do ich śledzenia używa się tzw. kart ograniczeń projektu. Ale o tym to już innym razem.