Zarządzamy projektami, zarządzamy zespołem … A co z wymaganiami? Oczywiście one też podlegają zarządzaniu w kontekście tego, jakie systemy, czy aplikacje obecnie budujemy i tego, jak są one rozwijane. Zarządzanie wymaganiami to więc całokształt czynności, które wykonujemy, aby te wymagania żyły, były aktualne i znane wszystkim interesariuszom.
Przede wszystkim wymagania utrzymujemy. Aktualnie panuje trend do tworzenia minimum dokumentacji, a w zasadzie do jej nie tworzenia, lub tworzenia jedynie ad hoc na potrzebę developmentu i nie przechowywania jej dłużej. W zależności od projektu oraz okoliczności rozwijania systemu nie zawsze tak się jednak da. Minimum dokumentacji jest czasem potrzebne. Ludzie w projektach się zmieniają, a ani kod, ani aplikacja sama w sobie wcale nie są wcale najlepszą dokumentacją. W sytuacji, kiedy więc musimy do pewnych funkcjonalności wrócić, chcąc je rozwijać, modyfikować, czy się na nich wzorować, potrzebujemy chociaż tego minimum dokumentacji. Wszystko jedno w jakiej formie będą zebrane wymagania – model, opis, prototyp. Utrzymanie ma więc kluczowe znaczenie, kiedy do wymagań przynajmniej raz będziemy musieli wrócić. Czy to po to, żeby się dowiedzieć, o co w ogóle chodziło, czy też po to, żeby coś zmienić. Let’s keep them up to date 🙂
Kolejnym aspektem jest ustalanie priorytetów. Priorytetyzowanie było zarówno w projektach tradycyjnych, jak i jest obecnie – w projektach zwinnych – istotne, kiedy musimy wybrać z jakichś względów pomiędzy dwoma wymaganiami. Może to wynikać z wielu czynników. W projektach waterfall’owych mogło to wynikać z konieczności ograniczenia zakresu tak, aby zmieścić się w budżecie i czasie, w projektach typu agile chodzi przede wszystkim o ustalenie funkcjonalności najbliższego przyrostu aplikacji – aplikacja na koniec iteracji musi działać, wybieramy więc taki pod zakres, który jest najbardziej istotny z punktu widzenia wartości biznesowej i który damy radę zaimplementować. Priorytetyzowanie najczęściej należy do interesariuszy biznesowych, np. obecnie do Product Ownera, natomiast rola Analityka jest w tym nieoceniona, to on zazwyczaj wie, że trzeba coś „poukładać w kolejności” i wspiera ten proces np. dostarczając technik.
A teraz pobawmy się w … detektywów 🙂 Tak jest, wymagania śledzimy. Co to oznacza? Dla wymagań utrzymujemy powiązania wertykalne i horyzontalne. Powiązania wertykalne to te między wymaganiami. Ogromnie istotne w kontekście analizy zmian w wymaganiach, ale o tym w najbliższym poście („Zarządzanie zmianą wymagań”). Powiązania horyzontalne to te pomiędzy wymaganiami, ich implementacją i pojedynczym testem, który sprawdza implementację wymagania. Śledzenie tych powiązań w obydwu kierunkach powoduje, że nie umykają nam żadne kwestie i znamy całokształt wysiłku, który nas czeka, aby prawidłowo zaimplementować pewien aspekt odpowiadający na potrzebę biznesową.
Wymagania komunikujemy. A mianowicie informujemy, jeśli nie wszystkich, to przynajmniej najbardziej zainteresowanych interesariuszy, że w wymaganiach powstała zmiana, lub, że w ogóle pojawiło się wymaganie. Dla developerów może być bardzo istotna informacja, że jednak inaczej realizujemy pewną funkcjonalność, zwłaszcza jeśli są w trakcje developmentu. A przecież wszyscy dobrze wiemy, jaki to chleb powszedni projektów 🙂 Z kolei w drugą stronę – dla biznesu waży jest przekaz od developerów, że np. pewnych funkcjonalności nie da się zrealizować w oczekiwany sposób. Takich sytuacji może być dużo i mogą być naprawdę różne, istotne jest to, aby zachowywać przeźroczystość obecnej sytuacji dla wszystkich.
Wreszcie – status wymagań, czyli ich cykl życia. Ta kwestia troszkę rozszerza aspekt powiązań horyzontalnych i utrzymania. Wymagań w projektach mamy zazwyczaj ogromne ilości. Pojawia się na szczęście coraz więcej narzędzi, które nas wspierają w zarządzaniu, czy będzie to np. JIRA, czy też dedykowane narzędzie stricte do zarządzania wymaganiami. W takich narzędziach dość łatwe staje się zarządzanie statusami, trzeba po prostu z tego skorzystać. W backlogu dla produktu, który to backlog jest wykorzystywany w projektach prowadzonych według metodyki SCRUM (lub scrum-o podobnej :)), przechowujemy wszystko, co jest do robienia w produkcie. Ważne jest więc, aby wiedzieć dokładnie, co jest do zrobienia, co jest w trakcie realizacji (i na jakim etapie – czy development, czy testy wewnętrzne, czy też testy akceptacyjne), a także co zostało już wcześniej wykonane i jest wymaganiem archiwalnym. Do tego dochodzą aspekty pewnych statystyk, które możemy prowadzić, np. wydajności zespołu developerów dla pewnej liczby wymagań określonych rozmiarów, porównywania wersji produktu pod kątem rozmiaru, czyli liczby wymagań i inne.
Obszar zarządzania wymaganiami jest obszerny analogicznie jak zarządzanie innymi aspektami. Tak samo jak żyje produkt, powinny żyć wymagania do niego, dla analityka jest więc niezwykle istotne, aby mieć wymagania pod kontrolą. Bądźmy więc „Requirement Managerami” 🙂
Zostaw komentarz