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.

Dokumentacja wdrożeniowa i administracyjna

Ostatnio pojawiło się bardzo dużo, bardzo ciekawej pracy. Stąd przerwy w pisaniu na blogu. Będę próbował się poprawiać :-)

Wracając do tematu, spotkałem się z bardzo ciekawym człowiekiem, który pisze pracę magisterską z dziedziny agile. Konkretne na temat dokumentacji w projektach realizowanych metodami zwinnymi. Ja już kiedyś swoje zdanie na ten temat wyraziłem (tutaj). W trakcie rozmowy wyniknął jednak jeden ciekawy problem.

Kto bowiem w zespole pracującym zgodnie z metodami zwinnymi jest odpowiedzialny za pisanie dokumentacji wdrożeniowej i administracyjnej? Na początek ustalmy pojęcia. Dokumentacja wdrożeniowa obejmuje opis procesu, który trzeba zastosować, aby system został uruchomiony w środowisku klienta i poprawnie funkcjonował z innymi systemami wcześniej tam obecnymi. Dokumentacja administracyjna obejmuje opis procedur, które muszą być stosowane przez osoby obsługujące systemy (bardzo często są to pracownicy naszego klienta) aby zapewnić utrzymanie systemu. Często dokumentacja administracyjna obejmuje też instrukcję radzenia sobie z najczęstszymi problemami.

W przypadku dokumentacji technicznej oraz dokumentacji użytkownika sprawa jest dość prosta. Odpowiadają za nią członkowie zespołu, którzy jednocześnie piszą kod bądź testują oprogramowanie. Z dokumentacją wdrożeniową, a już zwłaszcza administracyjną, jest jednak inaczej. Otóż w najczęściej spotykanych przypadkach jest tak, że osoby zajmujące się wdrożeniami systemu (czy też integracją systemów) nie są bezpośrednio członkami zespołów agilowych. Wynika to z faktu, że w większość znanych mi firm (nie mówię tu o sytuacji super-idealnej wziętej z książki któregoś z guru) osoby zajmujące się rozwojem produktu oraz osoby zajmujące się jego wdrożeniem i później ewentualnie administracją pracują w różnych działach, często nie mających ze sobą nic wspólnego. Dlatego w znanych mi zespołach nie było osób z kwalifikacjami potrzebnymi do napisania tego typu dokumentacji.

Jak więc sobie z tym poradzić? Długo się zastanawiałem i wymyśliłem dwa sposoby. Pierwszy jest „ortodoksyjny”. To znaczy zespół agilowy jest odpowiedzialny za stworzenie i tej dokumentacji. Przy czym oznacza to wprowadzenie do zespołu osoby, która się na tym zna. Oznacza to, niestety, że zespół się rozrośnie, bo tak jak to wspomniałem wcześniej rzadko zdarza się, żeby osoby pracujące nad rozwojem produktu miały wiedzę i umiejętności potrzebne do napisania takiej właśnie dokumentacji. Drugim rozwiązaniem, bardziej praktycznym, jest… odpuszczenie sobie tej dokumentacji na poziomie prac wykonywanych w poszczególnych iteracjach. Dokumentacja wdrożeniowa i administracyjna powinna pojawiać się wówczas jako element wypuszczanej wersji a nie produkt iteracji (o różnicach w planowaniu wersji i iteracji pisałem tutaj). Wówczas będzie działać to tak, że zanim wersja zostanie uznana za gotową do wypuszczenia do klientów jako warunek konieczny pojawi się „dostępna dokumentacja wdrożeniowa i administracyjna”. Pracę tą można wykonać na przykład podczas iteracji synchronizującej (tutaj). Ma to też sens patrząc się ze strony działów wdrożeń, których pracownicy będą się musieli uczyć zmian w systemie raz na wersję a nie raz na iterację. Z ich punktu widzenia to akurat bardzo duże ułatwienie.

Wieloprojektowość

Wyobraźcie sobie szpital, w którym operuje się chorych. Teraz kierownictwo tego szpitala, jako że chce skutecznie i szybko leczyć swoich pacjentów nakazuje aby natychmiast jak tylko pojawi się pacjent kierować go na potrzebną mu operację. Pomyślcie co się zaczyna dziać na salach operacyjnych. Jak jest jeden czy dwóch pacjentów to jest jeszcze dobrze, potem zaczyna być ich coraz więcej (kierowani są na operacje od razu jak tylko się pojawią). W końcu jest ich więcej niż zespołów lekarzy chirurgów i sal operacyjnych. Co w tym momencie robi kierownictwo szpitala? Nakazuje, żeby jeden zespół lekarzy wykorzystujący jedną salę operacyjną jednocześnie robił kilka operacji. Przecież Ci lekarze to świetni specjaliści, na pewno jakoś dadzą radę. Tak więc zaczyna się dzielenie czasu. Nad jednym pacjentem godzina, potem godzina dla drugiego. W miarę jak rośnie ich liczba zaczyna się problem z dostępnością sal operacyjnych. Anestezjologów zresztą też brakuje. W związku z tym tworzymy listy dostępności sali wraz ze ścisłym harmonogramem, który chirurg kiedy operuje którego pacjenta a który anestezjolog gdzie asystuje. Sale są dokładnie na godziny, więc nie można się spóźniać. Problem w tym co chirurdzy mają robić w czasie, gdy nie mogą operować swojego pacjenta, bo sala jest zajęta. Najchętniej by poczekali, ale szefostwo szpitala nie chce marnować drogocennego czasu chirurgów. Przecież to są świetni specjaliści i nie mogą w pracy spędzać "nieproduktywnych" godzin. W związku z tym szefostwo nakazuje chirurgom robić obchody w czasie jak ich (już "rozpoczęty") pacjent czeka na wolną salę. Skutek jest taki, że przestają zdążać na swój czas w harmonogramie dostępności sali, bo nie mogą się oderwać od obchodów. A jak już przyjdą i zaczną operować to jak tylko się dobrze "wdrożą" w danego pacjenta okazuje się, ze muszą go zostawić, bo w harmonogramie skończył się czas dostępności dla nich sali operacyjnej. Anestezjolodzy mają podobny problem.

Jesteście oburzeni takim podejściem? Kto by się chciał tam leczyć?

Teraz proszę podstawicie sobie w powyższym przykładzie zamiast "pacjent" to "projekt", zamiast "chirurg" to "programista" a zamiast "sala operacyjna" to "serwerownia" (czy dowolny inny zasób, który jest wystarczający rzadki w Waszym środowisku). Brzmi znajomo? Nikt nie zadaje pytania "kto by kupił projekt od takiej organizacji"?

Ciekawe jest, że branża medyczna, jakkolwiek niedoskonała, już od dawna potrafi sobie radzić z taką sytuacją. W prosty sposób: dedykowane zespoły, priorytetyzacja wykorzystania kluczowych zasobów (najpierw ten co ma życie zagrożone a potem ten co operacja plastyczna), kolejkowanie pacjentów zamiast współbieżności. Śmiem twierdzić, że nawet w Polsce statystyki sukcesów są dużo lepsze dla operacji medycznych niż dla projektów, w tym zwłaszcza projektów innowacyjnych. Znaczy, że takie rozwiązania działają. Teraz wypadałoby podpatrzyć czy u nas nei da się tak samo. I tutaj niespodzianka. Zarządzanie zwinne bardzo podobnie podchodzi do portfolio projektów jak szpital do operacji. To znaczy: zespół jest dedykowany do jednego projektu (nie wolno pożyczać ludzi), projekty robi się jeden po drugim a nie współbieżnie, a priorytety zapewnia właściciel produktu. Czyli podobnie. Ciekawe, dlaczego skoro w branży medycznej te zasady uznajemy za taką oczywistość w projektach już nie.

Iteracja zero

Pojęcie iteracji zero nie jest popularne w świecie zwinnego zarządzania projektami a według mnie jest to jedno z bardziej przydatnych narzędzi, które powinno być częściej wykorzystywane.

Jak wiadomo jedną z podstawowych zasad zwinnego zarządzania projektami jest to, że każda iteracja ma dostarczyć produkt o zwiększonej wartości biznesowej dla klienta, czyli ze zrealizowanymi dodatkowymi funkcjonalnościami. Każda iteracja zakończona jest pokazem dla klienta, podczas którego ma on możliwość przetestowania dostępnej nowej funkcjonalności. Iteracja zero różni się tym, że nie dostarcza żadnej wartości dodanej dla klienta. Dostarcza ona natomiast wartość dodaną dla zespołu realizującego projekt.

Iteracja zero jeżeli jest stosowana musi być pierwszą z iteracji w projekcie. Stosuje się ją, gdy zespół z jakichś względów nie może rozpocząć od razu pracy nad merytoryczną częścią projektu. Jej celem jest przygotowanie wszystkiego co jest niezbędne, aby zacząć projekt. Mogą to być takie rzeczy jak zdobycie nowej wiedzy, przygotowanie środowisk pracy, nabycie materiałów niezbędnych do rozpoczęcia prac, decyzje strategiczne dotyczące architektury przyszłego rozwiązania itp. Ze względu na swój szczególny charakter iteracja ta może mieć długość inną niż pozostałe. Ważne jest, aby iterację zero zaplanować. Należy bardzo dokładnie określić co jest jej celem i jak oceni się, że została ona zakończona. Tu postępuje się podobnie jak w każdej innej iteracji. Podobnie po iteracji przeprowadza się spotkanie kończące na którym przedstawiana jest wartość dodana, którą zespół uzyskał po zakończeniu iteracji. Uwaga, iteracja zero może być jedna i tylko jedna. To znaczy, trzeba ją zaplanować tak dokładnie aby nigdy więcej w ramach projektu zespół nie musiał zatrzymywać się - należy w tej pierwszej iteracji zero zatroszczyć się o wszystko co jest koniecznie do prowadzenia prac.

Podstawowym błędem popełnianym przy używaniu tego narzędzia jest próba użycia go w celu "przemycenia" starych nawyków z podejścia kaskadowego. Syndromem jest tutaj poświęcenie całej iteracji zero na "zaplanowanie" albo "przeanalizowanie" sposobu realizacji wymagań. To nie jest celem iteracji zero. Planowanie i analizowanie wymagań użytkownika odbywa się w ramach normalnego procesu iteracyjnego w zwinnym zarządzaniu projektem. Dla porównania iterację zero powinno się zastosować, jeżeli na przykład nikt z zespołu nie zna przepisów, w ramach których musi pracować nasz produkt. To drugie jest warunkiem koniecznym do startu prac zespołu to pierwsze jest próbą powrotu z metod iteracyjnych do kaskadowych.

Jak definiować testy?

Problem z praktyki: w jaki sposób definiować testy funkcjonalne w oprogramowaniu rozwijanym metodami zwinnymi? Żeby odpowiedzieć poprawnie najpierw przyjrzyjmy się jak to jest robione w standardowych metodach zarządzania projektami informatycznymi. Według teorii dokumentem na którym się bazuje jest definicja wymagań. Po zatwierdzeniu dokumentu definiującego wymagania przez klienta na podstawie tegoż dokumentu jednocześnie projektanci przystępują do projektowania systemu a osoby odpowiedzialne za testy piszą tzw. specyfikacje testów. Czyli ustalają co ma być testowane, w jaki sposób i w jakich ramach czasowych. Tak jest w teorii. W praktyce bywa nieco inaczej oczywiście. Głównie dlatego, że w znakomitej większości projektów dokument specyfikacji wymagań tak naprawdę zamknięty i zakończony jest dopiero w momencie zakończenia prac nad projektem. Klient przez cały czas wprowadza jakieś poprawki, które potem muszą być odzwierciedlane w testach. Dlatego po każdej zmianie specyfikacji wymagań trzeba zmienić specyfikację testów. Gratulacje dla tych, którym udaje się to utrzymać w porządku przy większych projektach.

W przypadku projektów realizowanych metodami zwinnymi jest trochę inaczej. Jak wiadomo wymagania definiowane są poprzez funkcjonalności, które muszą przynosić wartość dodaną oraz być nie większe niż jedna iteracja. Funkcjonalności mają też taką cechę, że nie mogą się zmieniać tylko i wyłącznie w ramach iteracji, w której są wykonywane. Wcześniej lub później można je dowolnie przedefiniować. W przypadku gdyby chcieć w takich warunkach pisać zwykłą specyfikację testów byłoby to niemożliwe ze względu na narzut na utrzymanie aktualnej dokumentacji. Jak sobie z tym poradzić? W najprostszy możliwy sposób. Otóż testy funkcjonalne zapisywane są i definiowane w obrębie danej funkcjonalności i do nie niezmiennie przypisane. W praktyce wygląda to tak, że funkcjonalność składa się z opisu tego co ma być zrobione oraz sposobu w jaki należy sprawdzić, czy zostało to zrobione poprawnie. Mówiąc językiem bardziej biznesowym funkcjonalność zawiera metodę upewnienia się, że faktycznie wprowadza ona wartość dodaną dla klienta.

Proste? Przede wszystkim zgodne ze zdrowym rozsądkiem. I bardzo dobre dla wszystkich stron zaangażowanych w tworzenie oprogramowania. Klient od razu wie w jaki sposób będzie sprawdzane czy funkcjonalność jest dobra, więc bardzo wcześnie można wykryć wszelkie niedomówienia w definiowaniu wymagań. Unika się w ten sposób sytuacji, kiedy wymaganie zostało inaczej zrozumiane przez zespół - "myśleliśmy, że o to Wam chodziło". Tutaj w sposób jawny definiujemy jak będziemy sprawdzać poprawność wykonania wymagania klienta. Testerzy są bardzo zadowoleni, bo zwykle mają w takim przypadku gotowe specyfikacje testów, które trzeba tylko oprogramować i wykonać. Programiści natomiast doskonale wiedzą czego się od nich oczekuje. Mogą więc na przykład postawić na TDD (Test Driven Development).

Metoda jest bardzo prosta, ale istnieją dla niej pewne zagrożenia. Jednym z nich jest to, że nagle zaczną sie pojawiać "testy luzem". To znaczy propozycje wykonania testów, które "muszą być", ale nie będą przypisane do żadnej funkcjonalności. Uwaga na takie sytuacje!!! W technikach zwinnych "testy luzem" akceptuje się tylko i wyłącznie dla wymagań niefunkcjonalnych. Zgodnie ze swoją definicją dotyczą one ogółu systemu (np. wydajność) a nie poszczególnego funkcjonalności. Jeżeli natomiast trafi się propozycja uwzględnienia funkcjonalnego "testu luzem" to najprawdopodobniej jest to błąd wynikający z jednej z dwóch przyczyn. Po pierwsze brak wymagania - sytuacja kiedy ewidentnie brakuje jakiegoś wymagania funkcjonalnego. "Funkcjonalny test luzem" nie istnieje, bo z definicji testuje jakąś funkcjonalność. Jeżeli nam się taki osierocony test przytrafi to przyczyną może być brak definicji któregoś z wymagań - trzeba je dodefiniować. Drugą przyczyną może to być "pozłacanie" (ang. gold plating) produktu - klient nie chciał, ale my mu zrobimy bo jesteśmy fajni. Nie wolno. Jeżeli klient nie chciał to za to nie płaci, dlatego nie robimy. Możemy ewentualnie zasugerować klientowi, że znaleźliśmy możliwość wprowadzenia takiej dodatkowej funkcjonalności i poczekać na jego decyzję.

Skąd się biorą wymagania?

Pytanie nieskomplikowane, odpowiedź zwłaszcza w świetle tego, o czym pisałem wcześniej powinna być oczywista: od klienta. Niestety. Odpowiedzi oczywiste nie zawsze są prawdziwe.

Najpierw trzeba się dobrze zastanowić, kto to jest klient. Klient jest osobą, która zamawia i płaci za nasz produkt. Jeżeli działamy w ramach projektów wewnętrznych zamiast klienta jest tzw. właściciel produktu, czyli osoba, która odpowiada za stworzenie nowego produktu. Płacą zaś za niego tak naprawdę klienci docelowi, którym właściciel produkt sprzedaje. Umówmy się, że niezależnie od tych sytuacji wszystkie te osoby będę nazywał klientami.

Pytanie jest następujące: czy klient ma dobrą wiedzę o tym potrzebnych funkcjonalnościach produktu? Zdarza się, że tak. Ale w ogólnym przypadku klient nie zawsze jest tym, który produktu używa. Na przykład w dużych korporacjach software jest zwykle kupowany przez dział IT a potem wdrażany w całej firmie. Czy dział IT (klient) naprawdę wie jakie funkcjonalności powinien mieć program? Nie. O funkcjonalnościach najwięcej wie użytkownik końcowy, czyli ten, który oprogramowanie będzie używał w swojej codziennej pracy.

Co więcej często dość naturalne jest, że istnieje pewnego rodzaju różnica zdań pomiędzy spojrzeniem na wymagania od strony klienta a od strony użytkownika końcowego. Załóżmy, że tworzone jest nowe oprogramowania do zarządzania projektami w dużej firmie. Używać go będą oczywiście kierownicy projektów oraz wszyscy zaangażowani w projekty w firmie. Zamawia go (klientem jest) jednak albo centralny dział IT albo szef działu zarządzania projektami. Z ich punktu widzenia priorytet będą miały takie wymagania jak: bezpieczeństwo danych, łatwość instalacji, łatwość zdalnego zarządzania, przeglądanie sytuacji wielu projektów, raporty z pracy poszczególnych kierowników projektów, kontrolowanie zasobów firmy w kontekście wielu projektów itp. To są funkcjonalności, które oni potrzebują. Czy te wymagania stanowią jakąkolwiek wartość dodaną dla zarządzania projektami w firmie? Wątpliwą. Użytkownicy końcowi potrzebują: łatwości planowania projektów, pomocy w harmonogramowaniu, łatwości przydzielania zasobów, automatyzacji przydzielania zadań, łatwości śledzenia postępu prac (dla kierowników), prostej i szybkiej metody raportowania postępu prac (dla wykonawców), ostrzeżeń o nieprawidłowościach w projekcie. Jeszcze raz: czy system spełniający wymagania klienta ale nie implementujący wymagań użytkownika końcowego będzie miał rzeczywistą wartość dodaną dla organizacji?

Czy w związku z tym wszystkie napisane we wcześniejszych wpisach słowa o kreowaniu wartości dla klienta nie są prawdziwe? Czy nie powinno chodzić o wartość użytkownika? Nie, bo mówimy o dwóch różnych rzeczach. Nie można porównywać jabłek z gruszkami. Klient płaci za produkt, więc to on domaga się za płacone pieniądze dostarczenia wartości dodanej dla siebie. Tylko za tą wartość zapłaci. Wartość ta tworzona jest poprzez implementację funkcjonalności potrzebnej użytkownikom końcowym produktu (wartość dla użytkownika końcowego powinna przekładać się na wartość dla organizacji). Jednak to klient ma ostateczny głos za co chce płacić a za co nie. On też decyduje o tym, które elementy z jego punktu widzenia są najbardziej potrzebne a które mniej. Jeżeli klient zadecyduje, że jego wymagania mają większą wartość niż wymagania użytkowników i trzeba je zaimplementować to jest jego suwerenna decyzja. Etyka zawodowa nakazywałaby jednak poinformować go o potencjalnym konflikcie takim jak opisany wcześniej.

Tak więc jak w projektach zwinnych powinno wyglądać ustalanie co tak naprawdę produkujemy? Wymagania zbieramy od użytkowników końcowych. Priorytety ustalamy z klientem. Proste.

Niepewność wymagań

Niepewność wymagań została wywołana dwukrotnie w ciągu ostatnich dwóch tygodni, w tym raz publicznie w komentarzach na blogu Alexa. Dlatego dzisiaj o niepewności wymagań.

W świecie IT (choć nie tylko) bardzo często dochodzi do sytuacji, kiedy w momencie w którym projekt powinien się rozpocząć zespół wykonawczy nie jest w stanie spisać wszystkich wymagań klienta. Według standardowych metod w takim wypadku należy powołać zespół analityków i być może projektantów, którzy siądą z użytkownikami końcowymi (lub klientem, choć to bardziej ryzykowne) i spiszą wymagania. Brzmi bardzo rozsądnie. Problem pojawia się w momencie kiedy klient nie wie czego by chciał. To wbrew pozorom zdarza się dosyć często. Tzn. klient wie do czego ma służyć system, wie jakie mają być główne jego funkcje, ale na przykład wymyślenie szczegółowych raportów, które powinien generować system jest poza możliwościami klienta. Głównie dlatego, że system nie istnieje jeszcze w rzeczywistości a człowiek często ma trudności w operowaniu bytami wirtualnymi. Co więcej jest pewna gama projektów, w których nie ma możliwości określić wszystkich wymagań na początku trwania projektu. Przykładami jest większość projektów internetowych. Na przykład www.flickr.com powstał jako narzędzie do dzielenia się zdjęciami. Kto w momencie powstawania tego serwisu zdefiniowałby takie funkcjonalności jak geotagging czy tworzenie fizycznych gadżetów ze zdjęciami?

Wracając jednak do niepewności wymagań: należy założyć, że istnieją projekty w których ta niepewność po prostu jest. Są też projekty, w których tej niepewności być nie powinno. Na przykład projekty realizowane w ramach zamówień publicznych - tam wszystkie wymagania powinny być określone w SIWZ. Błędem często popełnianym przez kierowników projektów jest próba użycia metodyk doskonale sprawdzających się w projektach ze stałymi wymaganiami do projektów w których występuje duża niepewność wymagań. Oczywiście gwoździe można wbijać trzonkiem noża zamiast młotkiem ale skutki mogą być opłakane.

Narzędziem do radzenia sobie z projektami o dużej niepewności wymagań są właśnie metody zwinne zarządzania projektami. Metody zwinne oferują kilka narzędzi/technik, które pomagają radzić sobie z takimi problemami. Najważniejsze:

• Klient szybko dostaje wartość dodaną - krótkie powodują, że klient dostaje regularnie system wzbogacony o nowe funkcjonalności do testowania, co powoduje że jest w stanie na żywo sprawdzić czy jego wymagania zostały spełnione i wygenerować/uszczegółowić nowe
• Planuje i rozlicza sie funkcjonalności - całe planowanie oparte jest o kolejne funkcjonalności a nie o zadania do wykonania. Z tego względu klient i zarząd dokładnie wie co (jaką wartość) otrzyma po każdej iteracji. Konieczność zdefiniowania tego powoduje, że musi doprecyzowywać wymagania na bieżąco - do realizacji nie wchodzą wymagania "niepewne".
  
• Można planować na różnych poziomach - Ze względu na poziomy planowania tylko najbliższa iteracja lub iteracje muszą być zaplanowane dokładnie. Kolejne wersje mogą być zaplanowane mniej dokładnie, co wprost implementuje naturalną dla człowieka zdolność do dokładniejszego planowania tego co jest bliżej a mniej dokładnego tego co jest dalej. Dodatkowo w sposób naturalny obejmuje to wszelkie niepewności co do wymagań odnośnie szczegółów projektu.
  
• Istnieje pewność realizacji spójnego projektu - poziom planowania produktu czy też wizji w projektach zwinnych zapewnia, że cały czas będziemy realizować jeden projekt z jedną wizją i spójnym produktem końcowym. Pozwala to błyskawicznie wykryć sytuację kiedy okaże się, że wymagania tak się zmieniły, że robimy co innego niż pierwotnie zakładane.
  
• Zespół pracuje w środowisku stabilnym - na czas iteracji. A to już spojrzenie "z drugiej strony". Programiści i inni zaangażowani w projekt realizowany metodami zwinnymi są szczęśliwi, bo mają pewność że wymagania są zamrażane na czas jednej iteracji. Mają pewność, że nikt nie przerwie im pracy i nie zmieni gwałtownie tego co robią przez całą iterację. Ta pewność w morzu niepewności jest przez członków zespołów szczególnie ceniona.
  

Oczywiście na koniec słowo o kontraktach. Kiedyś już to było poruszane na tym blogu. W skrócie jeżeli klient nie wie co chce to w jaki sposób może oczekiwać, że my wiemy jak to wycenić? W przypadku projektów o dużej niepewności wymagań podawanie stałej ceny za zrealizowanie takiego kontraktu to chodzenie po bardzo cienkiej linie.