Specyfikacja wymagań dla oprogramowania? Po co? Zrób od razu listę zadań

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:

1. 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.
2. 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.
3. 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ł.
4. 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!