Nienawidzę dużej ilości dokumentacji. Szczególnie specyfikacja wymagań czasami przypomina encyklopedię. Czy można to jakoś odchudzić?
Specyfikacja wymagań funkcjonalnych – problemy
W trakcie pracy jako kierownik projektów IT spotkałem się z poniższymi negatywnymi aspektami podczas tworzenia specyfikacji oprogramowania:
- Powielanie – czasami dokument specyfikacji zawiera często to samo co samo co: „projekt zmian” (niskopoziomowy opis zmian programistycznych), zakres zmian w dokumencie projektu, diagramy UML, lista zadań programistycznych.
- Opisywanie obrazu słowami – prototypowanie UI jeszcze wciąż nie jest powszechną praktyką. W zamian opisuje się beletrystycznie to co ma się znaleźć na poszczególnych widokach. Zgroza.
- Ambitny analityk systemowy – to taki gość co przelewania na papier wymagania dla budowy nowego systemu IT. Wielu z nich uważa, że im dłuższy dokument tym lepiej. Najdłuższa specyfikacja oprogramowania z jaką się spotkałem miała 600 stron prawie czystego tekstu. Tylko prawie nikt jej nie przeczytał.
- Wojna IT<->Biznes – szczegółowy dokument zakresu wymagań tworzy wiele pól dla różnych jego interpretacji. IT buduje coś co Biznes wyobrażał sobie zupełnie inaczej. Potem 90% czasu projektu jest poświęcane na spotkania aby ujednolicić interpretację.
„Dzięki” powyższych powstaje masa nikomu niepotrzebnej makulatury, będące zjawiskiem podobnym do tych w ministerstwach – ZAMULANIE.
Nie mówię, że obszerna specyfikacja wymagań zawsze jest zbędna. Natomiast w startup mogę stwierdzić jednoznacznie, że im więcej formalizmów tym gorzej dla Ciebie. Skup się na produkcie i sprzedaży a nie na „pięknych” dokumentach.
Specyfikacja wymagań – przykład
Jeśli tworzysz swój produkt, a zespół nie przekracza 10 osób, to z powodzeniem możesz zastosować poniższą metodę tworzenia specyfikacji wymagań.
Podziel budowany serwis, aplikację czy system na komponenty (większe paczki funkcjonalności). Załóżmy, że każdą z nich będziesz wykonywać w ciągu jednego cyklu wytwarzania (iteracji).
Stwórz plan iteracji (plan ogólny). Np. 10 iteracji po 2 tygodnie, czyli 5 miesięcy. Wbij to np. do Google Excel, do arkusza „plan produkcji – iteracje”, aby łatwo udostępniać listę innym. Kolumny:
- Numer iteracji
- Cel iteracji (np. „stworzenie komponentu autoryzacji serwisu”)
W kolejnym arkuszu („lista zadań”) stwórz kolumny:
- ID zadania
- Nazwa zadania – np. jako tzw. user story, czyli opis funkcjonalności w perspektywy użytkownika, 1-2 zdania, np. jedno z nich to: „Użytkownik rejestruje się do serwisu przez platformę Facebook” (zadanie 001)
- Numer iteracji – w której zadanie będzie wykonywane, możesz podlinkować wartości tej kolumny do arkusza planu produkcji (iteracji)
- Szacowany czas wykonania zadania (roboczo-godziny)
- Realny czas wykonania zadania (wypełniany po jego realizacji aby analizować odchylenia w szacunkach)
Następnie wykorzystaj tablicę zadań online. Przed rozpoczęciem każdej iteracji wrzucaj na tablicę zadania przypisane do niej. W polu opisu zadania na tablicy opiszcie dokładnie dane zadanie. Np. dla 001, oprócz nazwy zadania, dodajemy w opisie:
„Po pierwszym kliku przycisku FB, pobieramy z konta FB usera następujące dane: x, y, z… oraz prosimy o dostęp w jego imieniu do operacji na ramach jego konta FB: a, b, c… Zakończenie rejestracji nie wymaga podania dodatkowych danych niże te pobrane z FB. Po zakończonej rejestracji wyświetlamy użytkownikowi kokpit konta i na górze wyświetlamy zielony napis [Rejestracja zakończona. Miłego używania!]”.
W trakcie trwania iteracji nie zmieniajcie zakresu prac, a po jej zakończeniu zobaczcie jakie jest odchylenie w ilości wykonanych zadań w stosunku do planu. Jeśli zaplanowaliście za dużo to planujcie kolejną iterację ostrożniej.
Punkty kontrolne na początku każdej iteracji umożliwiają także modyfikację planu ogólnego do co kolejności wykonywania iteracji i ich zawartości. Zyskujesz dzięki temu elastyczność, zamiast planować szczegółowo na rok do przodu. Potem często się okazuje, że już po 3 miesiącach realizacji zaplanowany zakres nie ma uzasadnienia biznesowego.
Zasady
Powyższe jest oczywiście zbieżne z ideą Agile i metodyką Scrum. Niestety zamiast je zastosować dawno temu to niejedna specyfikacja wymagań przeszła przez moje ręce w formie encyklopedycznej.
Jeśli Twój projekt jest lekki, a produkt prosty, podaruj sobie wielką dokumentację i trzymaj się tych reguł:
- Trzymaj zakres zmian programistycznych w jednym miejscu
- Niech zakres będzie jednocześnie opisem technicznym i biznesowym (z perspektywy użytkownika)
- Nie planuj szczegółowo na rok do przodu, to wróżenie z fusów, planuj krocząco, długoterminowy plan niech będzie ogólny, szczegółowo planuj tylko kolejną iterację.
Nie marnuj papieru. Niech Twoja specyfikacja wymagań stanie się od razu listą zadań zrozumiałą dla wszystkich!