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

3 sierpnia, 2013 09:32, komentarzy 10

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:

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

Prosta lista zadań

Jeśli tworzysz swój produkt, a zespół nie przekracza 10 osób, to z powodzeniem możesz zastosować poniższą metodę.

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 – np. https://www.kanbanpad.com/. 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!

Przeczytaj inne

Komentarze