Jak wiemy metodyki zwinne dają możliwość prowadzenia projektu w różnorodny sposób. Istnieje kilka ściśle określonych zasad a cała reszta to wewnętrzne założenia oraz kompromisy.
Zasady
Jako przykładem posłużę się metodyką SCRUM oraz sposobem, w jaki dzieli ona projekt na kolejne etapy. Zasadniczo są to trwające 2-4 tygodni sprinty. Na początku każdego z nich organizowane jest spotkanie mające na celu ustalenie zakresu tego sprintu a na jego koniec następuje podsumowanie wykonanej pracy oraz analiza ewentualnych problemów, jakie się pojawiły. Ponadto, każdy sprint powinien dostarczyć działający produkt, który możemy wdrożyć na produkcję.
Założenia
Reszta to założenia wynikające ze specyfiki projektu oraz wewnętrznych, jak i zewnętrznych obostrzeń.
Na przykład …
Załóżmy, że nasz aktualny projekt operuje na wrażliwych danych finansowych, a przez to proces weryfikacji oraz sprawdzania każdej nowej wersji aplikacji jest niezwykle czasochłonny. Aby zoptymalizować czas potrzebny na przygotowanie dokumentacji potrzebnej do wdrożenia nowej wersji, grupujemy sprinty w półroczne wydania.
Innym przykładem jest uzgodnienie z biznesem stanu wymagania, w którym może ono być oszacowane przez zespół programistów oraz testerów. Aby było to możliwe, wymaganie powinno być dobrze rozumiane przez wszystkich zainteresowanych. W przypadku, gdy ktoś ma jakiekolwiek wątpliwości lub pytania, powinny one być wyjaśnione. Dopiero wtedy możemy włączyć wymaganie do kolejnych sprintów.
Biorąc pod uwagę powyższe ustalenia możemy określać moment, kiedy możliwa będzie implementacja kolejnych wymagań w aplikacji z dokładnością do jednego sprintu.
Praktyka
W projekcie, w którym uczestniczę właśnie została wydana kolejna wersja. Spotykamy się wraz z testerami, biznesem oraz klientem końcowym na tygodniowe podsumowanie, aby zweryfikować prace nad ostatnią wersją oraz przedstawić plany na najbliższą wersję. Jeden z dni przeznaczony jest na omówienie wymagań przygotowanych już na następną wersję. Wśród nich znalazł się zestaw wymagań opisujących importowanie danych z plików.
Haczyk ?
Do wymagań było sporo zastrzeżeń oraz wątpliwości. Po wspólnym przeanalizowaniu pojawiło się jeszcze więcej niejasności. Mieliśmy wrażenie, że przygotowujemy się do estymacji wymagań, które są jeszcze wersją roboczą.
Podczas sesji uzupełniania estymat dla wymagań otrzymaliśmy zaktualizowany zestaw wymagań, które różniły się one znacząco od ich poprzedniej wersji. De facto żadna z wersji wymagań nie spełniała przyjętych w projekcie założeń odnośnie stanu wymagania.
Można się domyśleć, jak projekt się potoczył. Funkcjonalność była krytyczna dla nadchodzącej wersji, więc została oddana. Stało się to jednak kosztem bardzo ciężkiej pracy zespołu i wielu nerwów.
Jako wniosek można by stwierdzić, że trzymanie się przyjętych w projekcie założeń, o ile oczywiście są właściwe, pozwala płynnie go realizować i osiągać sukcesy wspólną pracą bez poświęceń z jednej ze stron biorących udział w projekcie,
Zostaw komentarz