Własność funkcjonalności

W projektach informatycznych zdarza się bardzo często sytuacja kiedy projekty jest na tyle duży, że do poprawnego zdefiniowania wymagań potrzeba więcej niż jednej osoby. Po prostu wiedza dziedzinowa dotycząca projektu nie jest możliwa do zgromadzenia przez jedną osobę. W takim wypadku szczególnej uwagi nabiera kwestia tego, kto jest "właścicielem" poszczególnych funkcjonalności.

Przez właściciela funkcjonalności rozumie się osobę, która jest w pełni odpowiedzialna za zdefiniowanie danej funkcjonalności i zwykle będzie osobą używającą jej w przyszłości (odbiorcą korzyści biznesowej dostarczanej przez daną funkcjonalność). Zdefiniowanie takiej osoby jest niezmiernie ważne w kontekście mogących się pojawić wątpliwości dotyczących tego jak ma działać zdefiniowana funkcjonalność. Musi być ktoś, kto ma ostateczny głos w sprawie zdefiniowania pożądanego sposobu zachowania się systemu. W mniejszych systemach tą osobą jest właściciel produktu, w większych często właściciel produktu nie ma wystarczającej wiedzy aby decydować o każdej funkcjonalności i dlatego warto wyznaczać właścicieli poszczególnych funkcjonalności. Najlepiej właściciela po prostu zapisać na karcie funkcjonalności.

Powyższy system działa dobrze, do czasu kiedy nie zajdzie sytuacja w której dwie funkcjonalności zdefiniowane przez różne osoby stoją w konflikcie ze sobą. Wbrew pozorom często tak jest. Na przykład w systemach kompleksowo obsługujących przedsiębiorstwa proces sprzedaży zakłada zwykle udział działów sprzedaży, magazynu, księgowości a często także produkcji. Każdy z tych działów może mieć różną koncepcję tego jak proces sprzedaży wyglądać powinien. W takich sytuacjach osobą rozstrzygającą powinien być właściciel produktu. Niezależnie bowiem od właścicieli poszczególnych funkcjonalności musi istnieć ktoś, kto jest odpowiedzialny za całość definiowania wymagań i w związku z tym za ostateczny kształt projektowanego systemu. Tą osobą jest właśnie właściciel produktu. W przypadku dużych systemów, gdzie występuje wielu właścicieli funkcjonalności brak właściciela produktu jest bardzo często spotykanym błędem.

I na koniec: w takich sytuacjach jak opisana bardzo ważne jest, aby właściciel produktu był mocno "umocowany" w strukturze organizacji. Jest to konieczne, gdyż prędzej czy później będzie musiał on godzić wymagania różnych działów i forsować rozwiązania korzystne dla całości przedsiębiorstwa a nie dla poszczególnych kierowników. Osoba nisko stojąca w hierarchii, bez odpowiedniego autorytetu formalnego i nieformalnego nie ma szans w starciu z kierownikami "silosów". Wyznaczenie mało znaczącego właściciela produktu jest drugim bardzo często popełnianym błędem w opisywanych sytuacjach.

Metoda Uwe K.

Jakiś czas temu pracowałem dla naszych sąsiadów zza Odry i Nysy Łużyckiej a moim szefem był niejaki Uwe K. Miał on bardzo ciekawą metodę zarządzania zadaniami. Otóż dzwonił codziennie o godzinie 16.15 do mnie, jako do swojego pracownika i przekazywał ustnie zadania do wykonania. Następnego dnia często dzwonił o godzinie 8.00 z pytaniem gdzie może obejrzeć rezultaty mojej pracy. Najwięcej zadań oczywiście było przekazywane w piątek o 16.15, tylko po to, aby oczekiwać, że będą zrealizowane do poniedziałku do 8.00. Bardzo ciekawa metoda zarządzania to była. Szczególnie w kontekście tego, że życie nie składa sie jedynie z pracy. Jak się zapewne domyślacie dość szybko zacząłem aktywnie działać w kierunku zwolnienia Uwe K. z funkcji mojego szefa...

Historia powyższa przypomniała mi się gdy rozmawiałem w zeszłym tygodniu z pewną osobą, której nie udało się wdrożenie zwinnych metod zarządzania w średniej wielkości polskiej firmie informatycznej. Teoretycznie firma była idealna do wdrożenia. Produkty cechujące się dużą niepewnością funkcjonalności, bardzo duża możliwość testowania niepełnego produktu przez klientów ostatecznych, projekty na tyle małe, że można je robić jednym zespołem, więc odpadają wszelkie typowe problemy ze skalowaniem metod zwinnych. Niestety wdrożenie zostało wyłożone. Co się stało? Zacznijmy od tego, że wdrożenie agile project management zostało umotywowany tym, że "firma zbyt wolno reaguje na potrzeby klienta". Celem było więc stworzenie systemu, który pozwoli szybko reagować na zgłaszaną przez klienta informację zwrotną o produktach firmy. O ile osoby zajmujące się programowaniem dość szybko zrozumiały o co chodzi w nowym systemie pracy, to zrozumienie metod zwinnych po stronie osób zarządzających produktem (product managerów) było cokolwiek powierzchowne. Doprowadzono do sytuacji, w której dano product managerom pełną dowolność zmian funkcjonalności produktu bez liczenia się z opinią kierowników projektów realizacyjnych. Bardzo szybko spowodowało to pojawienie się syndromu opisanego powyżej. Objawiało się to wpisywaniem przez menedżerów produktu na listę funkcjonalności niezdefiniowanych rzeczy podczas spotkań planujących iterację. Realizatorzy prosili o uszczegółowienie takich wymagań, co następowało zwykle na trzy dni przed końcem iteracji. Na innym poziomie było wrzucanie do ostatniej iteracji przed wypuszczeniem wersji zmian fundamentalnych, wymagających zmian w architekturze - oczywiście tłumaczone nagłą potrzebą klienta. A także inne kwiatki, których nie mogę opublikować. Jak się domyślacie oczekiwanie było, że na koniec każdej iteracji będzie dostępny działający produkt. A już wersja to koniecznie musiała być, bo przecież obiecana klientowi. Jakiekolwiek tłumaczenie od strony realizatorów, że taka praca jest nieoptymalna menedżerowie produktów kwitowali krótko: "no jak to, czy to znaczy, że nie jesteście wystarczająco agile?". Dość szybko ludzie z zespołów realizacyjnych zaczęli myśleć dokładnie to, co ja myślałem o moim szefie.

Nauka z tego taka, że zwinność zwinnością, ale i tak zawsze trzeba pamiętać, że istnieje gdzieś niepisana cienka linia, której przekroczenie spowoduje zabicie metody. Najpierw na poziomie elementarnego poziomu i trzymania się zasad. Chwilę potem na poziomie ludzkich relacji i chęci dalszej współpracy. Napiszę jeszcze raz to, co już tu wielokrotnie wprowadzałem: agile to wprowadzanie porządku w chaos. Agile to nie jest zarządzanie bez reguł.

I na koniec taka refleksja. Nie wiem dlaczego, ale zaczyna u mnie dominować przekonanie, że wdrożenia metod agile są najbardziej zagrożone nie od strony realizacji, ale od strony zarządzania produktem. Właśnie ze względu na błędne zrozumienie, że agile oznacza "wszystko nam wolno". A co ciekawe firmy praktycznie nigdy nie chcą aby im szkolić menedżerów produktów...

Dzielenie funkcjonalności raz jeszcze

Prawie dokładnie dwa lata temu napisałem post nt. wielkości funkcjonalności. Post był krótki i treściwy, ale po dwóch latach w sposób równie krótki i równie treściwy muszę dokonać pewnej modyfikacji tego, co w nim napisałem.

Otóż jak najbardziej prawdą jest, że w ramach iteracji powinniśmy realizować funkcjonalności, których wielkość jest nie większa niż jedna iteracja. Doświadczenie dwóch lat nauczyło mnie jednak, że nie jest optymalne mówienie, iż każda z tych funkcjonalności musi dostarczać wartość dodaną dla klienta. Powinno się mówić o tym, że każda z funkcjonalności (w tym takie po podziale) powinny dostarczać wartość dodaną dla właściciela produktu (Product Managera). Czy to robi różnicę? Subtelną, ale jednak robi. Różnica ta polega na tym, że właściciel produktu nie koniecznie jest klientem (aczkolwiek może nim być). Zdarzyło mi się w mojej praktyce spotkać się z przypadkami, kiedy klient końcowy jako wartość dodaną dla siebie widział tylko i wyłącznie coś, co jest efektem końcowym całego projektu. Po prostu z punktu widzenia klienta końcowego żaden z elementów pośrednich, będących efektami poszczególnych iteracji nie powoduje, że biznes klienta zacznie lepiej działać i przynosić lepsze efekty. Dlatego czasami trudno tu jest mówić o wartości dodanej poszczególnych iteracji. Z punktu widzenia klienta takowych po prostu nie ma.

Natomiast wartość dodana z punktu widzenia właściciela produktu może być trochę inną wartością dodaną niż z punktu widzenia klienta. Na przykład posiadanie części rozwiązania może być dla właściciela produktu wartością, bo wie, że jest bliżej całości rozwiązania. Natomiast z punktu widzenia klienta to nie ma żadnego znaczenia, bo jemu wartość przynosi tylko i wyłącznie rozwiązanie w całości.

Nauka z tego taka, że w planowaniu zwinnym jeżeli istnieje ktoś taki jak właściciel produktu to planowanie odbywa się z oparciu o jego definicję wartości i on odpowiada za definiowanie funkcjonalności. I to właściciel produktu odpowiedzialny jest za to, aby koniec końców produkt dostarczał wartość dla klienta ostatecznego.

Uwaga!!! Klient i właściciel produktu w niektórych przypadkach to może być jedna i ta sama osoba, wtedy oczywiście cały ten post i tłumaczenie ma mały sens.

I na koniec jeszcze jedno spostrzeżenie. Gdyby nie praktyczna próba zastosowania agile nigdy nie spotkałbym się z taką sytuacją i nigdy nie przypuszczałbym, że wartość dodana dla klienta może w pewnych wypadkach być tak trudna do zastosowania. Ale od czego jesteśmy zwinni (agile). W sposób agilowy dostosowaliśmy się do panujących warunków. Zastanawiam się tylko jak by się w takiej sytuacji zachowali reprezentanci nurtu "agile ortodoksyjny"?

Iteracje synchronizujące

Kiedyś pisałem o tym, że nie każda iteracja musi być „zwykłą” iteracją. Wtedy podawałem przykład tzw. iteracji 0, których cechą jest dostarczanie wartości dodanej dla zespołu projektowego nie dla klienta. Osobom wyznającym „agile ortodoksyjny” na pewno się to nie spodoba, ale ja dopuszczam poza iteracją 0 także inne „specjalne” iteracje. Ważne tylko jest, aby każda z tych iteracji dostarczała realną wartość dodaną dla klienta. Nie dopuszczam sytuacji, kiedy iteracja inna niż 0 nie wytwarza rzeczywistej wartości dodanej.

Szczególnym przykładem takiej specjalnej iteracji jest coś, co popularnie nazywa się iteracjami synchronizującymi. Takie iteracje występują w sytuacji, kiedy na jeden produkt składa się więcej niż jeden element wytwarzany metodami zwinnymi w jednym czasie. Wówczas w którymś momencie musi nastąpić połączenie poszczególnych elementów w jeden produkt, czyli integracja komponentów. „Agile ortodoksyjne” zakłada, że takie komponenty są integrowane cały czas wykorzystując mechanizmy ciągłej integracji. W praktyce często zdarza się jednak, że z różnych powodów nie jest możliwe przeprowadzanie ciągłej integracji. Wówczas dość często stosuje się tak zwane iteracje synchronizujące. Polega to na tym, że dana wersja produktu jest rozwijana w ramach poszczególnych komponentów (czyli normalnie). Ostatnia iteracja w rozwoju danej wersji przeznaczona jest na poskładanie w całość wszystkich komponentów. Z punktu widzenia przepływu wartość dla klienta wygląda to tak, że do przedostatnie iteracji klient dostaje komponenty o zwiększonej funkcjonalności, natomiast zwiększoną wartością ostatniej iteracji jest działanie systemu (zamiast sumy komponentów). Takie działania integracyjne w ramach ściśle określonej iteracji dają w większości przypadków bardzo pozytywne efekty. Należy jedynie pamiętać, aby tą akurat iterację zaplanować od strony czasowej bardzo konserwatywnie. Powód jest bardzo prosty. Bez włączonych mechanizmów ciągłej integracji okazuje się, że sama integracja wykazuje wiele błędów w poszczególnych komponentach. Dlatego dodatkowy czas musi być przeznaczony na ewentualne poprawki znalezionych błędów. Cóż: coś za coś – brak „problemów” ciągłej integracji skutkuje zwiększonymi kosztami poprawiania błędów.

Na koniec dwie uwagi do powyższego tematu. Po pierwsze mimo braku zaimplementowanych mechanizmów ciągłej integracji pod żadnym pozorem nie wolno doprowadzić do rozjechania się interfejsów poszczególnych komponentów. Zadanie zsynchronizowania poszczególnych części jest w takiej konfiguracji szczególnie ważne i powinno zostać powierzone osobie odpowiedzialnej za całość przedsięwzięcia (uwaga, to też nie jest zgodne z „agile ortodoksyjnym”).

Druga uwaga, to dość oczywisty, ale często zapominany fakt, że problemy z integracją komponentów w największym stopniu można ograniczyć poprzez inteligentny i przemyślany podział na całości systemu na części. Do takich przemyśleń można wykorzystać na przykład czas iteracji 0. Jak konkretnie to zrobić to byłby już temat na osobny post.

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