Kiedy warto sięgnąć po rysunek#
Diagramy UML przydają się w codziennej pracy, gdy pomagają wyjaśnić zależność, ustalić regułę albo sprawdzić, czy wszyscy rozumieją problem tak samo. Ich wartość można ocenić po tym, co udaje się dzięki nim uzgodnić. Czasem wystarczy niewielki rysunek wykonany podczas rozmowy; czasem potrzebny jest dokładniejszy opis, do którego zespół będzie wracał przez kolejne miesiące.
Wyobraźmy sobie spotkanie dotyczące sklepu internetowego. Ktoś mówi: „Po płatności zamówienie trafia do realizacji”. Wszyscy potakują. Programista zaczyna jednak myśleć o odpowiedzi operatora płatności, osoba z obsługi klienta o wiadomości wysłanej kupującemu, a właściciel sklepu o przekazaniu paczki do magazynu. Użyli tych samych słów, ale mogli wyobrazić sobie różne momenty procesu.
Taka sytuacja jest dobrym powodem, żeby coś narysować. Wspólny obraz daje uczestnikom rozmowy konkretny punkt odniesienia: można wskazać krok i zapytać, co dokładnie oznacza.
Mały przykład: płatność, która się nie udała#
Załóżmy, że sklep chce umożliwić klientowi ponowienie odrzuconej płatności. Przed zmianą trzeba ustalić, co dzieje się z samym zamówieniem. Czy znika? Czy pozostaje zapisane? Czy trafia do magazynu, mimo że pieniądze nie wpłynęły?
W naszym przykładzie zespół przyjmuje następującą zasadę: zamówienie powstaje przed płatnością. Po potwierdzeniu zapłaty może trafić do realizacji. Po ostatecznym odrzuceniu próby płatności pozostaje zapisane i oczekuje na kolejną próbę. Klient otrzymuje informację o niepowodzeniu.
Można to pokazać na diagramie aktywności, czyli rysunku przedstawiającym przebieg działań i wybór między ścieżkami. Poniższy przykład obejmuje próbę płatności, dla której otrzymano już jednoznaczny wynik.
Rysunek czytamy od góry. Zaokrąglone prostokąty oznaczają czynności, a romb rozdziela dwa wyniki. Zakończenie diagramu oznacza koniec przedstawionego przebiegu, a nie usunięcie zamówienia. Na dolnej ścieżce sprawa pozostaje otwarta z perspektywy klienta, choć opisana próba płatności już się skończyła.
Diagram pozwala teraz zadawać precyzyjne pytania. Tester może sprawdzić, czy po odrzuceniu płatności zamówienie nadal jest dostępne. Osoba z obsługi klienta może ustalić treść komunikatu. Programista może wskazać miejsce, z którego rozpocznie się ponowienie płatności.
Jest też wyraźna granica tego przykładu: brak odpowiedzi operatora nie oznacza odrzucenia. Jeżeli wynik jest nieznany, potrzebny będzie osobny sposób jego sprawdzenia. Również opóźnione potwierdzenie, termin rezerwacji towaru i powtórzone powiadomienia wymagają ustaleń, zanim na tej podstawie powstanie kompletna implementacja. Niewielki diagram pomaga rozpocząć tę rozmowę, ale jej nie zamyka.
Pomoc przy przekazywaniu projektu#
Podobną korzyść można uzyskać, gdy do zespołu dołącza nowa osoba. Zamiast od razu oprowadzać ją po kilkudziesięciu plikach kodu, można pokazać głównych uczestników procesu: sklep, operatora płatności i magazyn. Następnie przejść przez jedno konkretne zamówienie.
Taki punkt wyjścia pomaga ułożyć szczegóły w całość. Nowa osoba wie, po co istnieją poszczególne części systemu i o co pytać podczas dalszego poznawania projektu. Diagram nie musi przedstawiać każdej klasy ani każdego wywołania. Powinien pokazywać te zależności, które są potrzebne do zrozumienia omawianego fragmentu.
Martin Fowler opisuje takie selektywne użycie UML jako szkicowanie. To użyteczna perspektywa w pracy: można posługiwać się małym fragmentem notacji, aby wspólnie przyjrzeć się wybranemu problemowi.
W rozmowie z osobą spoza IT#
Osoba odpowiedzialna za sprzedaż lub obsługę klienta może dobrze znać zasady działania firmy, choć nigdy nie uczyła się UML. Warto więc objaśnić użyte symbole i zacząć od jej doświadczeń. Pytanie „co robicie, kiedy płatność zostaje odrzucona?” zwykle daje lepszy początek niż prezentacja gotowego, rozbudowanego modelu.
Wspólne rysowanie pozwala od razu poprawiać nieporozumienia. Jeśli pracownik mówi, że telefonuje do klienta dopiero po drugim niepowodzeniu, można dopisać tę regułę lub zaznaczyć ją jako temat do ustalenia. Trzeba jednak uważać, żeby rysunek nie nadawał przypadkowemu pomysłowi statusu obowiązującej procedury. Obecny sposób działania i proponowana zmiana powinny być wyraźnie opisane.
Kiedy wystarczy kilka zdań#
Nie każda sprawa wymaga diagramu. Jeżeli zmiana polega na poprawieniu literówki w wiadomości, rysunek raczej niczego nie wyjaśni. Jeśli zespół porównuje dziesięć poziomów uprawnień, czytelniejsza może być tabela. Wygląd formularza łatwiej omówić na jego makiecie.
Warto też uwzględnić koszt utrzymania dokumentacji. Diagram zapisany na stałe powinien mieć jasny cel, odbiorców i miejsce przechowywania. Gdy zmienia się pokazana na nim reguła, trzeba go poprawić. Szkic, który posłużył tylko do rozstrzygnięcia jednej kwestii, można zachować jako zapis rozmowy z odpowiednią datą i kontekstem albo po prostu odłożyć.
Dobrym sprawdzianem użyteczności jest proste pytanie: co odbiorca będzie mógł dzięki temu rysunkowi zrozumieć lub zdecydować? Jeżeli odpowiedź jest konkretna, warto spróbować. Jeśli trudno ją sformułować, najpierw trzeba doprecyzować sam problem.
Od jednego pytania do wspólnego ustalenia#
Na początek wystarczy wybrać jedną niejasność, taką jak los zamówienia po nieudanej płatności. Rozrysować kilka kroków, przejść przez przykład z osobami znającymi temat i zapisać wynikające z rozmowy decyzje. Niewiadome powinny pozostać widoczne, z informacją, kto ma je wyjaśnić.
W codziennej pracy właśnie taki niewielki model może okazać się najbardziej przydatny. Pomaga zauważyć rozbieżne wyobrażenia, zanim zamienią się one w odmienne wymagania, kod i oczekiwania klienta.