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:

  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łowamiprototypowanie 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).

product backlog
Plan produkcji  w Google Docs

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”)
Czytaj również:  Zarobki programisty - jak nie zbankrutować w startupie? [cz. 1]

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!]”.

specyfikacja wymagań
Przykładowa tablica w KanbanPad

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ę.
Czytaj również:  Roszczeniowi Klienci i Szefowie... trójkąt ograniczeń (Zarządzanie Projektami)

Nie marnuj papieru. Niech Twoja specyfikacja wymagań stanie się od razu listą zadań zrozumiałą dla wszystkich!

Komentarze (Dodaj swój):

  1. mondrzy gado.
    a popieram dlatego, że nie lubię czytać takich wypocin analityków, bo i tak się potem wszystko porozjeżdża 🙂

  2. tylko że ten powyższy "spis rzeczy" to trywialny CRUD, do czegoś takiego faktycznie nie ma co "tworzyć" jakiejkolwiek dokumentacji ponad powyższe listy, rozwlekła niejednoznaczna słowna dokumentacja jest bez sensu i tu zgoda, ale gdzie (skąd) wiedza o logice biznesowej bardziej złożonej niż "dodaj, usuń, pokaż"? Na jakiej podstawie zostanie wykonana implementacja np. systemu upustów albo naliczania prowizji partnerom? Poprawnie opracowane wymagania to zwięzły spis warunków przydatności oprogramowania, to odpowiedź na pytanie "jak stwierdzimy, że oprogramowanie zostało poprawnie wykonane"?

  3. crud, cmok czy chwdp… no matter. co stoi na przeszkodzie aby pisać o upustach/prowizjach w story? poza tym nie powiedziałem że nie można uzupełnić tego np. o UML. grunt aby nie tworzyć cegieł których nikt nie jest w stanie przerobić i do tego nie powielać na kilka dokumentów jak to często jest robione.
    Co do wklejonego linka, z samym tytułem w url się nie zgadzam.

  4. Maćku, zgadzam się w 100% z tym co napisałeś. Od siebie dodałbym tylko to, że całość dokumentów dotycząca projektu IT powinna się "naturalnie" rozchodzić w drzewko – czyli jak mamy już prostą listę zadań to dać warunki pozytywnego zakończenia zadania(tutaj widzę rolę testera). i idąc w dół kolejne elementy dodawane przez developerów w formie nawet komentarzy, żeby później można było szybko zlokalizować błędy lub wprowadzić nowe funkcjonalności.

  5. Maciej Oleksy reguły biznesowe z pomocą user story to brzmi jak "kodeks drogowy opisany za pomocą kilku opowieści o podróży samochodem z domu do pracy"…

  6. co do dokumentacji to nikt chyba nie lubi dokumentów niskiej jakości, rzecz w tym by były dokumenty pozwalające na bieżące rozliczanie wykonawcy …. a zakres projektu termin i budże to to klucze do rozliczeń

  7. Jarek Żeliński, możesz opisać logikę jakiegoś mega ficzera w osobnym dokumencie i zalinkować do niego z user story. Chodzi o to aby tablica była czytelna i pozwalała na łatwe zarządzanie całym zakresem i wspomagała komunikację zespołu. Bardziej niż niską jakość nikt nie lubi mega encyklopedii bez mapy drogowej, bo jakiś szajbnięty analityk zapomniał, że ten dokument jest dla ludzi i tworzy coś dla nikogo bo się tego nijak ogarnąć nie da.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *