Wszędzie może się zdarzyć, że powrócimy do wymagań, które już zostały oficjalnie spełnione i zamknięte. Dzisiejszy tekst to zbiór przemyśleń, różnych sytuacji i uwag związanych z powrotami do już zrealizowanych wymagań.
Powody do powrotów
Jest wiele powodów, dla których wracamy do wymagań, które już uznaliśmy za ukończone. Ba, zdarzą się też takie sytuacje, gdzie będziemy chcieli coś zmienić w funkcjonalnościach, które już wdrożyliśmy. Powiedziałbym nawet, że jeśli taka sytuacja zdarza się najczęściej, to (prawie) wszystko dobrze. Działamy empirycznie – wdrażamy się, a następnie na podstawie informacji zwrotnych dostosowujemy nasze rozwiązanie. Musimy „tylko” zacząć wyciągać wnioski na przyszłość i lepiej przewidywać potrzeby naszych odbiorców. Łatwo powiedzieć, trudniej zrobić.
Zdarzą się sytuacje, w której uparty klient będzie chciał robić coś, co doskonale wiemy, że się nie sprawdzi. Jeżeli nasz Product Owner nie jest odpowiednio przekonujący, czasami zdarzy nam się przerabiać coś, mrucząc pod nosem „a nie mówiłem”. Niezależnie od tego czy to pomyłka odbiorców naszych prac, czy też rozminięcie się z rynkiem bądź oczekiwaniami, będą czekały nas przeróbki. Jak z nimi postępować?
Złotą zasadą pracy z wszelkiego rodzaju poprawkami-które-nie-były-ujęte-w-wymaganiach, jak i wszelkiego rodzaju zmianami koncepcji jest wrzucanie nowych zachcianek po prostu jako nowych elementów backlogu. Być może wcześniej się nie zrozumieliśmy, bądź nasi klienci zdecydowali, że nie pasuje im nasze rozwiązanie. Jednak jeśli praca została wykonana, a wymagania zostały spełnione, nie możemy ich teraz „przywracać”. Pojawiły się inne, nowe. Wrzućmy je więc jako nowe PBI, czyli Elementy Backlogu produktu. Pomoże nam to w zachowaniu transparentności i pokazaniu, czym faktycznie się zajmujemy.
W podobny sposób będziemy postępować w przypadku, w którym ktoś znalazł błąd w dawno zamkniętej części tworzonego produktu. Co z nim zrobić? Nie jest on przecież nowym wymaganiem – coś nagle przestało działać i tyle. Szczególnie częsta jest to sytuacja, w której posiadamy setki bądź tysiące testów automatycznych, jednostkowych i innych. Nieważne skąd się to wzięło, wrzućmy to do backlogu jako nowa praca do wykonania. A jeżeli takich sytuacji zacznie być zbyt wiele, przeprowadźmy dochodzenie (czytaj: retro) i sprawdźmy, z czego one się biorą.
Wymagania niefunkcjonalne
Tu należy jeszcze poświęcić kilka akapitów wymaganiom niefunkcjonalnym, zwanym czasami NFR-ami (ang. non-functional requirements). Wymagania niefunkcjonalne co do zasady są wymaganiami jakościowymi. Poświęciliśmy im osobny tekst, ale jak zwykle przypomnę w paru zdaniach samą koncepcję.
Wymaganie funkcjonalne mówią nam o tym „co” ma być możliwe. O tym „jak” to będzie zrealizowane decyduje zespół, a o tym kiedy praca jest skończona mówi nam Definition of Done. Z kolei wymagania niefunkcjonalne to „jakie parametry jakościowe mają być spełnione”. Te ostatnie powinny być wyrażone liczbą i być opisane granicami („nie mniej niż”, „nie więcej niż”). Jeżeli są słowno-muzyczne, jak np. „aplikacja ma być wygodna w użyciu”, to przykro mi bardzo, ale nie są to żadne wymagania, a co najwyżej jakieś wskazówki.
I tu dochodzimy do kwestii testowania i powrotów do NFR-ów. Najbardziej typowe wymaganie niefunkcjonalne to „czas wykonania dowolnej operacji w systemie nie może być dłuższy niż x sekund”. Już sama konstrukcja tego zdania mówi nam, że nigdy nie będziemy mogli takiego wymagania „zamknąć”, czyli powiedzieć, że oto jest ono zrealizowane i nigdy do niego nie wrócimy. Patrzymy więc znów w kierunku testów automatycznych oraz CI/CD. Bez nich zabawa w wymagania niefunkcjonalne w ogóle nie ma sensu. No bo jak inaczej chcemy co iterację sprawdzać, czy wciąż spełniamy te kryteria?
Jeżeli natomiast wydaje nam się, że jakieś wymaganie jakościowe można zamknąć raz na zawsze, to strzelam w ciemno, że jest to wymaganie związane z jedną konkretną funkcjonalnością albo wręcz zakamuflowana funkcjonalność. W takim wypadku wystarczy je umieścić w kryteriach akceptacji tejże, a nie bawić się w jakieś dodatkowe twory.
Powroty, czy zmiany?
Na koniec rozróżnijmy jeszcze dwie podstawowe kwestie. Czym innym jest powrót do wymagania, bo znaleźliśmy błąd, a czym innym zmiana poprzednich, zrealizowanych ustaleń. W tym pierwszym przypadku, jeśli wrócimy do pierwotnego User Story (zakładając, że korzystamy z tego formatu), to wszystko, co będzie w nim napisane, wszystkie kryteria akceptacji, będą prawdziwe.
Powrót do już zamkniętych wymagań, bo znaleźliśmy nowe dziury to przeważnie efekt testów i dalszego rozwoju. Tu warto podkreślić, że im dłużej gotowe oprogramowanie leży na wirtualnej półce (czytaj: nie jest wdrożone i używane produkcyjnie), tym więcej takich błędów w nim znajdziemy. Nieużywany software degeneruje się wraz z dodawaniem do niego kolejnych elementów. Nikt z niego nie korzysta, nikt więc nie wyłapuje dziur. Same testy nie wystarczą.
A co jeżeli po prostu wykryjemy lukę w naszym rozumowaniu, o której wcześniej nie pomyśleliśmy? Typowy przykład to sytuacja brzegowa, której nie przewidzieliśmy lub która miała nigdy nie nastąpić, ale jednak się wydarzyła. Zgodnie z podanym wcześniej przepisem, potraktujmy to jak nowe wymaganie i tyle.
Jeżeli zaś chodzi o zmiany wcześniejszych ustaleń i decyzji, to przede wszystkim pamiętajmy, że gramy do jednej bramki. Jeżeli wydarzyło się coś niespodziewanego albo odkryliśmy, że nasze wcześniejsze plany nie mają sensu, nie róbmy czegoś „bo tak mówiliśmy rok wcześniej” albo „bo tak zapisaliśmy w umowie”. W podejściu zwinnym dajemy sobie możliwość dostosowania się do zmieniających się okoliczności, co ma się dziać z korzyścią dla wszystkich. Nikt przecież nie lubi wytwarzać rzeczy bezużytecznych.
Mówiliśmy o tym szerzej w filmie pod tytułem „Gotowość na zmiany wymagań, czyli co?” Nie mieszajmy więc niezdecydowania klienta, kiepsko zrobionej analizy czy braku wizji z uszczegóławianiem wymagań i dostosowywaniem się do zmieniającego się świata.
Jedyna kwestia otwarta, to wspomniane wcześniej User Stories. Jak to wszystko zapisać, żeby mieć jakąś dokumentację opisującą bieżący stan systemu? Napisaliśmy, że US-y w takich sytuacjach opisywały będą tylko poszczególne zmiany. Skąd więc wziąć „tekst jednolity”, czyli bieżący opis naszego systemu? To już brzmi jak temat na zupełnie inny tekst lub film. Tak czy inaczej, zapraszamy do śledzenia nas na social mediach, gdzie znajdziecie wszystkie informacje o naszych dziełach.
