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.

Brak komentarzy: