Skrzynka narzędziowa architekta oprogramowania - ebook

DZIAŁANIA NA RZECZ ZROZUMIENIA PROBLEMU

W nastawieniu na zrozumienie aktywnie poszukujemy informacji od interesariuszy i pracujemy nad zdefiniowaniem (lub przedefiniowaniem) problemu. Zrozumienie to coś więcej niż tylko określanie wymagań. Musimy również ustalić, kim są nasi interesariusze, określić cele biznesowe dla systemu i zapewnić wymagania określone z myślą o architekturze.

Istnieją cztery rodzaje wymagań istotnych dla architektury. Wszystkie one wpływają na architekturę, ale najbardziej wpływowymi i kluczowymi zagadnieniami dla architektów są atrybuty jakościowe.

Ograniczenia Niezmienialne decyzje projektowe, zwykle narzucone, czasem wybrane.

Atrybuty jakościowe Właściwości widoczne z zewnątrz, które charakteryzują działanie systemu w określonym kontekście.

Wpływowe wymagania funkcjonalne Funkcjonalności i cechy wymagające szczególnej uwagi w architekturze.

Inne czynniki mające wpływ Czas, wiedza, doświadczenie, umiejętności, polityka biurowa, własne ukryte uprzedzenia i wszystkie inne rzeczy, które przeszkadzają w podjęciu decyzji.

Działania w tym rozdziale pomagają zespołom wczuć się w interesariuszy i poszukiwać wymagań istotnych dla architektury. Używajmy ich, gdy potrzebujemy lepszego zrozumienia prawdziwego problemu.

DZIAŁANIE 1
WYBÓR JEDNEJ RZECZY

Przedyskutujmy priorytety z interesariuszami, przedstawiając im ekstremalny wybór: jeśli możesz wziąć tylko jedną rzecz, to co to będzie? To działanie może pomóc interesariuszom w podejmowaniu decyzji w obliczu trudnych kompromisów.

Korzyści

• Jasno komunikuje: to jest ważniejsze niż tamto.

• Rozpoczyna rozmowę o tym, dlaczego dokonano pewnego wyboru i co należy zmienić, aby zainteresowane strony zmieniły zdanie.

• Sprawia, że wiadomo, kiedy zainteresowane strony się nie zgadzają.

Uczestnicy

Wszyscy interesariusze.

Przygotowanie i materiały

• Lista opcji spośród atrybutów jakościowych lub innych trudnych kompromisów, takich jak koszt, harmonogram i funkcjonalności.

Kroki

1. Wyjaśniamy zasady gry. Zainteresowane strony mogą wybrać tylko jedną z przedstawionych opcji. Przypominamy uczestnikom, że nie oznacza to, iż zrobimy tylko jedną rzecz, ale chodzi o wczesne przeprowadzenie twardej rozmowy, by uniknąć problemów po drodze.

2. Przedstawiamy zestaw opcji interesariuszom. Omawiamy, co oznacza każda opcja i upewniamy się, że wszyscy je rozumieją.

3. Zmuszamy interesariuszy do wyboru jednej opcji. Wszystkie zainteresowane strony powinny zgodzić się, że jest ona najważniejsza. W tym działaniu chcemy konsensusu.

4. Krótko omawiamy, dlaczego została wybrana dana opcja. Ta dyskusja ma często większe znaczenie niż sama opcja.

5. Wybieramy inny zestaw wymagań istotnych dla architektury, które są ze sobą w konflikcie, i gramy ponownie.

Wskazówki i podpowiedzi

• Zagrajmy w tę grę, zanim wszystko stanie się zbyt trudne. Taka rozmowa jest łatwiejsza, gdy jest hipotetyczna, niż kiedy dotyczy rzeczywistości.

• Atrybuty jakościowe, które są ze sobą w konflikcie, powinny być sobie przeciwstawiane.

• Używajmy tego działania, aby nadać priorytety wpływowym wymaganiom funkcjonalnym.

• Ta technika sprawdza się dobrze jako nieformalna rozmowa, która pomaga lepiej zrozumieć prawdziwe potrzeby interesariuszy.

Przykład

Oto kilka scenariuszy, które pewien zespół stworzył dla kilku interesariuszy, oraz jak przebiegła rozgrywka, gdy zostali oni poproszeni o wybór jednej rzeczy:

------------------------------------------ -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Wybrane pary Wybór interesariuszy
Szybsza wydajność lub większa dokładność Szybsza wydajność, przy założeniu, że dokładność spełnia wymagany minimalny próg.
Koszt vs czas wejścia na rynek Czas wejścia na rynek; zainteresowane strony były skłonne zaakceptować większy dług technologiczny, aby uzyskać wymagane funkcjonalności w określonym terminie.
Użyteczność vs bezpieczeństwo Bezpieczeństwo; był to najważniejszy atrybut jakościowy i zaskakująco pokonał kilka innych ważnych atrybutów jakościowych.
Dostępność vs koszt Dostępność; osiągnięcie wysokiej dostępności tego konkretnego systemu wymagało potencjalnie kosztownej redundancji, za którą zainteresowane strony chętnie by zapłaciły (do pewnego stopnia), gdyby to było wymagane.
------------------------------------------ -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Warianty

Zamiast przeciwstawiać jeden wariant innemu, użyjmy suwaków kompromisów, aby pozwolić interesariuszom na dokonanie wielu porównań. Aby przećwiczyć to działanie, wybierzmy 3–5 powiązanych wariantów. Każdy wybór może otrzymać numer 1 – N, gdzie N jest liczbą pozycji na liście. Żadne dwa wybory nie mogą mieć tej samej wartości. Ta aktywność jest często prezentowana wizualnie za pomocą suwaków.

DZIAŁANIE 2
MAPA EMPATII

Przeprowadzanie burzy mózgów i zapisywanie odpowiedzialności, myśli i uczuć poszczególnych interesariuszy, aby pomóc zespołowi rozwinąć większe poczucie empatii z celami interesariuszy.

Korzyści

• Odkrycie potrzeb odbiorców przed opracowaniem opisu architektury.

• Pomoc w decyzji, jakie informacje uwzględnić lub wykluczyć.

• Utworzenie skali osiągnięć do oceny skuteczności opisu architektury.

Czas trwania działania

10–30 minut.

Uczestnicy

Architekt oprogramowania, zespół programistów.

Małe grupy 3–5 osób lub ćwiczenie indywidualne.

Przygotowanie i materiały

• Przed rozpoczęciem działania wybierzmy, którzy interesariusze, systemy lub użytkownicy będą głównym tematem działania.

• Papier do flipcharta lub biała tablica, markery i karteczki samoprzylepne.

• To działanie może zostać dostosowane do rozproszonych uczestników dzięki udostępnieniu ekranu lub oprogramowania do zdalnej współpracy.

Kroki

1. Rysujemy siatkę na białej tablicy lub papierze. Oznaczamy każdy kwadrant – wykonywanie, przygotowywanie, mówienie i myślenie.

2. Wybieramy określonego interesariusza i wpisujemy jego nazwę w środku.

3. Wybrany interesariusz wykonuje zadania związane z burzą mózgów, przygotowuje artefakty, mówi o różnych rzeczach i może mieć uczucia.

4. Zapisujemy każdą ideę na karteczce i umieszczamy ją w odpowiednim kwadrancie.

5. Przeglądamy mapę empatii i podkreślamy spostrzeżenia.

Wskazówki i podpowiedzi

• Bądźmy konkretni. Wybierzmy osobę, z którą można odczuwać empatię, a nie ogólną rolę.

• Weryfikujmy wyniki mapy empatii z interesariuszami.

• Wyszczególnijmy atrybuty jakościowe, ryzyka lub inne potrzeby, które ta osoba może uznać za istotne.

• Zastosujmy tę metodę do zrozumienia użytkowników końcowych aplikacji, systemów zewnętrznych (do projektowania interfejsu) lub do przedstawicieli interesariuszy w celu zrozumienia atrybutów jakościowych.

• Gdy uczestnicy są rozproszeni, korzystajmy z oprogramowania typu Mural.

Przykład

Przykładowa mapa empatii dla interesariusza będącego deweloperem jest przedstawiona na stronie 8.

Warianty

Kwadranty na mapie empatii można zmienić. Inny typowy schemat to: słyszenie, widzenie, wykonywanie (lub mówienie) i myślenie (lub czucie).

Mapy empatii są również przydatne do analizy atrybutów jakościowych. To podejście jest szczególnie przydatne, gdy interesariusze nie są w stanie uczestniczyć w innych warsztatach, takich jak Działanie 7. Miniwarsztaty atrybutów jakościowych na stronie 21. Zamiast skupiać się na tym, co interesariusze robią lub o czym myślą, skupiamy się na tym, jak reagują na określone atrybuty jakościowe. Oczywiście, lepiej zapytać interesariuszy bezpośrednio. Kiedy nie są dostępni, jest to dobry zamiennik.

Aby skorzystać z tego wariantu, wybierzmy interesariusza i za pomocą burzy mózgów przeanalizujmy co najmniej dwa scenariusze atrybutów jakościowych lub ogólne potrzeby dotyczące każdego istotnego atrybutu jakościowego. Użyjmy głosowania kropkowego, aby oszacować, w jaki sposób dany interesariusz ocenia atrybuty jakościowe. Idealnie, gdy możemy potwierdzić wyniki tego ćwiczenia, ale nie zawsze jest to praktyczne. Zebrane spostrzeżenia mogą zostać wykorzystane podczas innych warsztatów, aby zapewnić, że perspektywę interesariuszy reprezentuje się nawet wtedy, gdy ten interesariusz nie jest obecny.

W poniższym przykładzie z warsztatów prowadzonych przez Thijmena de Gooijera karteczki reprezentują surowe, proste scenariusze atrybutów jakościowych. Linie pośrodku mapy pokazują, jakie potrzeby różni nieobecni uczestnicy mogliby mieć w stosunku do różnych atrybutów jakościowych wyświetlanych w sieci atrybutów jakościowych na stronie 18. Sieć atrybutów jakościowych pomaga nam zwizualizować znaczenie różnych atrybutów jakościowych podczas uporządkowanej burzy mózgów. W trakcie warsztatów poproszono różnych uczestników o odgrywanie roli nieobecnego interesariusza za pomocą mapy empatii jako przewodnika.

DZIAŁANIE 3
WARSZTATY CEL-PYTANIE-METRYKA

Podejście w celu identyfikacji metryk i miar liczbowych odpowiedzi, dzięki czemu jest możliwe połączenie danych z celami biznesowymi. Podejście cel-pytanie-metryka (ang. Goal-Question-Metric, GQM) zostało wprowadzone przez Victora Basiliego, Gianluigiego Caldierę i H. Dietera Rombacha w The Goal Question Metric (GQM) Approach . Celem GQM jest identyfikacja miar, z których możemy skorzystać w celu ustalenia, czy cel został spełniony.

Są trzy części podejścia GQM. Cel definiuje wymóg konceptualny, który musi zostać spełniony. Cele mogą opisywać scenariusze atrybutów jakościowych, ogólną jakość oprogramowania, cele biznesowe lub inne zagadnienia. Pytania pomagają zrozumieć, w jaki sposób można osiągnąć jeden lub więcej postawionych celów. Metryki definiują miary potrzebne do udzielenia odpowiedzi na jedno pytanie lub więcej pytań.

Korzyści

• Podkreśla wykorzystanie celów interesariuszy jako podstawy miar.

• Pokazuje wyraźne połączenie między danymi a celami interesariuszy za pomocą pytań, na które należy odpowiedzieć, aby stwierdzić, czy cel jest spełniony.

• Elastyczne podejście, które może pomóc zespołom myśleć o metrykach w różnych sytuacjach.

Czas trwania działania

15–90 minut.

Uczestnicy

To działanie może być wykonywane solo lub w małej grupie 2–5 osób. Każdy miks interesariuszy jest właściwy.

Przygotowanie i materiały

• Biała tablica lub papier do flipcharta, markery.

• Cele do zbadania mogą zostać opcjonalnie zidentyfikowane przed warsztatami.

Kroki

1. Piszemy cel po lewej stronie tablicy.

2. Prosimy uczestników o podawanie pytań. Na jakie pytania musielibyśmy odpowiedzieć, aby dowiedzieć się, czy osiągnęliśmy ten cel? Zapisujemy każde pytanie na prawo od celu. Rysujemy linie od celu do pytania, aby utworzyć drzewo.

3. Analizujemy każde pytanie, aby zidentyfikować metryki potrzebne do udzielenia odpowiedzi na pytanie. Zapisujemy każdą metrykę na prawo od pytań. Rysujemy linie od każdego pytania do metryk wymaganych do udzielenia odpowiedzi.

4. Powtarzamy ćwiczenie dla wszystkich powiązanych celów, które w dużym stopniu mogą używać tych samych pytań lub metryk. Końcowym wynikiem powinno być drzewo łączące metryki z pytaniami i pytania z celami.

5. Identyfikujemy dane wymagane do wyznaczenia każdej metryki. Zapisujemy potrzebne dane po prawej stronie metryk. Rysujemy linie od każdej metryki do danych potrzebnych do jej obliczenia.

6. Dla każdego fragmentu zidentyfikowanych danych określamy, skąd możemy je zdobyć. Zapisujemy każde źródło dla każdego fragmentu danych. Określamy koszt zebrania danych z każdego ze źródeł danych.

7. Ostatnim etapem warsztatów jest ustalenie priorytetów danych i metryk. Należy jasno określić metryki, które muszą być. Szukamy źródeł danych, które mogą dostarczyć danych potrzebnych do obliczenia wielu metryk, oraz metryk, które mogą odpowiedzieć na wiele pytań.

8. Zapisujemy rezultaty warsztatów, wykonując zdjęcia i zapisując omawiane cele, pytania, dane i źródła danych.

Wskazówki i podpowiedzi

• Upewnijmy się, że mamy dużo miejsca na narysowanie drzewa GQM.

• Poszukujmy możliwości ponownego użycia. Metryki mogą być wykorzystane do odpowiedzi na więcej niż jedno pytanie. Podobnie, te same dane mogą pomóc w obliczeniu wielu metryk.

• Źródła danych i dane prawdopodobnie wpływają na architekturę, ale szukajmy możliwości gromadzenia danych także poza architekturą.

• Zapisujmy wyniki w tabeli lub arkuszu kalkulacyjnym, aby później omówić je z interesariuszami. Zidentyfikowane metryki będą weryfikowane przez cały okres użytkowania oprogramowania.

Przykład

W poniższym przykładzie cel jest zapisany po lewej stronie, pytania są umieszczone w środkowej kolumnie, a dane znajdują się w kolumnie po prawej stronie. W tym konkretnym szkicu GQM zostały pominięte dane użyte do wyznaczenia metryk.