blog.testowka.pl

Archiwum wiadomości z Maj, 2014

Wymagania != Specyfikacja

opublikowany przez 07, Maj, 2014, w kategoriach Agile, Scrum

„Wymagania” to nie to samo co „specyfikacja funkcjonalna/techniczna”! Wiem, że to nie wydaje się być oczywiste, ale gdyby wszyscy zdawali sobie z tego sprawę to mogli byśmy uniknąć wielu, tak często powtarzających się w IT problemów. Spróbujmy więc to jakoś zdefiniować.

Wymagania (ang. Requirements) – wymagania wobec tworzonej aplikacji to jest to, co ktoś od niej wymaga. Pisząc ktoś mam na myśli kogoś, kto ma jakiś interes w tym, by dane wymaganie zostało zrealizowane – ten ktoś jest więc Interesariuszem (ang. Stakeholder). Interesariusz wymaga od aplikacji, by realizowała ona lub pomagała w realizacji jakichś konkretnych celów. Przeważnie chodzi o cele biznesowe, ale mogą to też być też kwestie związane na przykład z wymogami prawnymi czy zależnościami od innych systemów. Ponad Interesariuszami (przeważnie jest ich wielu) jest jeszcze ogólny cel biznesowy naszej organizacji jakim przeważnie jest generowanie zysków – tak, chodzi oczywiście o pieniądze (choć nie zawsze wprost). Interesariusze wyrażają swoje potrzeby właśnie w postaci wymagań, a więc wymagania opisują to jaki cel ma zostać osiągnięty – czyli to CO aplikacja ma dostarczać. To czego wymagania nie powinny dotyczyć to sposób, w jaki ten cel musi zostać osiągnięty (można podać oczywiście w ramach wymagań jakieś przykłady różnych rozwiązań niemniej jednak nie jest to konieczne).

Większość problemów w wytwarzaniu współczesnych produktów IT bierze się właśnie stąd, że za definiowanie tego jak powinny wyglądać rozwiązania IT biorą się ludzie, którzy nie potrafią tych rozwiązań zaimplementować. Oczywiście robią to nie pytając o zdanie tych, którzy to potrafią. W ten sposób bardzo często powstaje właśnie specyfikacja funkcjonalna – czyli dokumentacja opisująca to JAK system ma spełniać wymagania Interesariuszy. Dokumentacja ta następnie (no może nie tak od razu) jest zazwyczaj przekazywana tym drugim (developerom), którzy implementują te rozwiązania na tyle na ile je rozumieją.

Warto zastanowić się nad tym po co tworzona jest zazwyczaj specyfikacja funkcjonalna? Przeważnie tworzy się ją po to, by za jakiś czas pamiętać o tym co nasz system ma robić i jak ma to robić? Kluczowe jest tutaj „…za jakiś [znacznie dłuższy] czas…”.

Potrzeba istnienia specyfikacji funkcjonalnej sprowadza się do minimum (w zasadzie zależy to tylko od tego, czy z jakiegoś rozsądnego powodu chcemy mieć na przyszłość dokumentację tego, co zostało zaimplementowane), gdy mamy do czynienia z inkrementalnym i iteracyjnym wytwarzaniem oprogramowania jak na przykład w Scrum. Planując pracę na najbliższe dwa tygodnie nie potrzebujemy z góry szczegółowo zapisywać tego jak zamierzamy zaimplementować rozwiązania postawionych przed nami problemów. Zgodnie z zasadą Just In Time – pracujemy w danym momencie nad tym co jest w danym momencie najważniejsze. Przed rozpoczęciem Sprintu przeważnie nie wiemy jak zaimplementujemy dane wymaganie.

Cały ten Agile dotyczy właśnie tego by zbliżyć tych ostatnich w łańcuchu – developerów, do tych z samego początku – Interesariuszy. Chodzi o to, by to właśnie ludzie, którzy mają implementować rozwiązania mogli podejmować decyzje, co do tego jak dane wymaganie zostanie zrealizowane.

To plus rozróżnienie wymagań od specyfikacji to fundamentalne podstawy dobrego zrozumienia metod takich jak Scrum czy BDD. Niestety wydaje mi się, że wiele osób zgubiło to gdzieś po drodze i teraz na przykład piszą User Stories tak, jak by były dokumentacją funkcjonalną. Wielokrotnie spotykałem się z (oczywiście bzdurną) opinią, że User Stories mają być odpowiednikiem dokumentacji funkcjonalnej…

Co w takim razie z analitykami? Nic… Analitycy są potrzebni – bardzo potrzebni! Pomagają zrozumieć domenę biznesową developerom, a także często samym Interesariuszom. Pomagają znaleźć optymalne rozwiązania problemów wyrażonych w postaci wymagań.

Jeśli natomiast Twoja praca sprowadza się głównie do pisania specyfikacji funkcjonalnej, którą później wysyłasz do developerów to przykro mi, ale jest spora szansa, że jesteś dokumentalistą a nie analitykiem (nawet pomimo swoich wybitnych umiejętności w tym zakresie). Analizując problem i poszukując jego rozwiązań należy bowiem brać pod uwagę różne aspekty – a już na pewno kwestie biznesowe oraz możliwości implementacyjne. Dobry analityk będący częścią wskroś-funkcjonalnego zespołu developerskiego wnosi niesamowitą wartość – jeśli tylko rozróżniamy wymagania od specyfikacji funkcjonalnej (patrz powyżej).

Specyfikacja funkcjonalna – czy inna dokumentacja tego typu stanowi zasadniczy koszt wytwarzania oprogramowania i naprawdę warto jest się zastanowić czy mamy doby powód by koszt ten ponosić. Zauważcie, że nie neguję istnienia takiej dokumentacji zawsze i wszędzie – jest z pewnością wiele przypadków, w których jej istnienie jest konieczne! Proszę Was tylko o to, byście zadali sobie pytanie z jakiego powodu taka dokumentacja jest konieczna w Waszym przypadku, oraz zastanowili się, czy odpowiedź na nie ma sens…

–== C. D. N. ==–

4 komentarze więcej...