[ Pobierz całość w formacie PDF ]
cyzyjniej byłoby powiedzieć, że te decyzje będą zakodowane w kodzie, a zdekodowanie ich czę-
sto nie jest zabawne. Jednym z celów technik zaprezentowanych w tej książce w szczególności
projektowania opartego na dziedzinie i architekturze DCI jest wyeliminowanie kodu jako
sposobu komunikowania zamiarów programisty. Ważne jest, aby posługiwać się wspólnym ję-
zykiem dokumentowania decyzji. Ten język rzadko może być językiem programowania. W końcu
nie dla wszystkich interesariuszy język programowania jest podstawowym językiem. Spotkania
i sprawozdania z tych spotkań również nie zawsze się sprawdzają (w końcu kto to czyta?). Zatem
potrzebujemy frameworka, który pomoże nam opisać ważne decyzje dotyczące funkcjonalności.
Na razie nie mówimy o decyzjach, które może podejmować programista. Te są najlepiej do-
kumentowane za pomocą kodu. Mówimy o decyzjach, które dotyczą innych zainteresowanych
szczególnie przedstawicieli biznesu, na przykład właściciela produktu w metodyce Scrum.
Nowe wymagania również stwarzają potrzebę podejmowania decyzji. Dla nich również po-
trzebujemy miejsca. W tradycyjnej specyfikacji wymagań w rzeczywistości nie ma miejsca na
nowe wymagania zbiór wymagań jest zamknięty. Opowieści użytkowników i zestawy funkcji
w gruncie rzeczy mogą się tylko rozrastać wraz z każdym nowym wymaganiem. Strategia ta jednak
powoduje, że nie jesteśmy w stanie zobaczyć lasu z powodu drzew. Kiedy opowieść użytkownika
się powtarza? Kiedy jest to tylko zbieżność z inną opowieścią użytkownika? Jak można zweryfi-
kować, czego brakuje? To podejście sprawdza się w przypadku bardzo małych i prostych systemów
na przykład stron internetowych, kiedy można wydać nową wersję codziennie i natychmiast
uzyskać informacje zwrotne. Nasze decyzje są udokumentowane na stronie internetowej, a użyt-
kownicy je testują. To tworzy zwięzły, prosty kontekst.
Ostatnim elementem w części co-system-robi jest zwrócenie uwagi na to, aby fragmenty
funkcjonalności były wystarczająco małe, tak by planowanie wydania było łatwe. Co planowanie
wydania ma wspólnego z architekturą? Chcemy wiedzieć, które funkcjonalności będą wyzwaniem
dla architektury, a które są tylko rozszerzeniem już istniejących funkcjonalności. Jedną z opcji, jakie
mamy do dyspozycji, jest zajęcie się funkcjonalnością ryzykowną dla architektury we wczesnej
iteracji, aby uniknąć przykrych niespodzianek w pózniejszym iteracjach. Jest to jeden z przykładów
sytuacji, gdy architekt powinien wspomóc właściciela produktu w szeregowaniu rejestru wymagań
produktu. To architekt jest tym, który wie, czy konieczna jest redukcja ryzyka. Jest to sprzeczne
z zasadą naiwnych zwolenników Agile, że najpierw należy zająć się najprostszymi rzeczami. To
jednak stosunkowo niewielki problem, jeśli wziąć pod uwagę pogląd Agile na temat czegokolwiek,
co jest ukierunkowane na architekturÄ™.
Kup książkę Poleć książkę
172 Rozdział 7. Co system robi: funkcje systemu
Dlatego kryteria konsolidacji części co-system-robi zawierają następujące elementy:
1. Wsparcie przepływu pracy użytkowników (scenariusze użycia).
2. Wsparcie dla testów, które powinny być blisko prac rozwojowych (scenariusze testów).
3. Wsparcie dla skutecznego procesu podejmowania decyzji o funkcjonalnościach
(scenariusz słonecznego dnia znany również jako scenariusz najważniejszego sukcesu
a odchylenia).
4. Wsparcie dla nowo powstających wymagań (odchylenia).
5. Wsparcie dla planowania wydań (przypadki użycia i odchylenia).
6. Uzyskanie danych wejściowych do opracowania architektury (terminy i pojęcia
ze scenariuszy).
7. Budowanie w zespole zrozumienia tego, nad czym zespół pracuje.
Pokazaliśmy wcześniej, że jednym z rozwiązań są przypadki użycia. Nie są one jednak jedynym
rozwiązaniem. Warto wziąć pod uwagę kryteria wymienione powyżej. Czy pasują do naszego
kontekstu rozwoju? Jakie inne techniki z powodzeniem stosowaliśmy wcześniej? Należy kierować
siÄ™ zdrowym rozsÄ…dkiem!
Mogliśmy wybrać dla tej techniki jakąś inną nazwę niż przypadek użycia być może zasto-
sować jakieś fantazyjne japońskie słowo i powiedzieć, że jest to nowa technika formułowania
wymagań zgodna z Lean. Prawdopodobnie zajęłoby nam to trochę czasu, zanim rozpoznalibyśmy
tę technikę jako przypadek użycia. Jesteśmy jednak zwolennikami przejrzystości. Zilustrujemy
to za pomocą przykładu. Naszym celem nie jest nauczenie Was posługiwania się przypadkami
użycia. (Literatura dostarcza mnóstwo dobrych zródeł: Adolph et al. 1998; Constantine i Lucy
1999; Cockburn 2001; Wirfs-Brock 1993). Naszym celem jest pokazanie, w jaki sposób technika
przypadków użycia może pomóc w rozwijaniu oprogramowania zgodnie z Agile i Lean, bez ko-
nieczności odkrywania nowych technik tylko po to, by móc je nazwać Agile i Lean. Nie stawiamy
sobie celu, aby pokazać doskonały przykład zastosowania przypadków użycia. Proces wokół przy-
padków użycia jest ważniejszy niż same przypadki użycia.
7.5.1. Widok helikoptera
Po rozgrzewce jesteśmy gotowi do konsolidacji. Być może mamy wiele historii użytkowników
oraz kilka prototypów. Przedstawiciel biznesu wygłosił motywacyjną mowę lub cały zespół podzielił
się żywymi opowieściami. Mamy mnóstwo danych wejściowych przede wszystkim chcemy je
zorganizować i dokonać ich przeglądu. Czego nauczyła nas sesja rozgrzewkowa na temat kontekstu?
Przejdzmy od bankomatu znajdującego się na zewnątrz i wejdzmy do środka, gdzie nie pada.
Spróbujmy pomyśleć o sobie jako o obywatelach, którzy chcą przeprowadzać transakcje bankowe,
siedząc w domach przy swoich komputerach. Bank nie jest już diabelskim twórcą pieniędzy, ale
naszym partnerem, który próbuje ułatwić nam życie. Jakich zatem najważniejszych usług ocze-
kiwalibyśmy od banku? Co chcielibyśmy realizować w domu przez internet? Chcielibyśmy móc
przelewać pieniądze, przeglądać ostatnie transakcje, dodawać nowe stałe płatności, drukować
wyciągi z konta i opłacać rachunki. Podczas burzy mózgów może przyjść nam na myśl wiele innych
rzeczy, ale to są podstawowe usługi, które menedżer produktu uważa za ważne na początek.
Moglibyśmy nazwać je usługami lub epiką lub ogólnymi wymaganiami albo funkcjami ,
ale wolimy nazywać je przypadkami użycia.
Kup książkę Poleć książkę
7.5. Konsolidacja tego, co system robi 173
Abyśmy mogli używać nazwy przypadki użycia, każdy z nich powinien wspierać cel dla użyt-
kownika. Najpierw zatem powinniśmy zdefiniować użytkownika: w języku przypadków użycia
to jest aktor. W trakcie sesji burzy mózgów zbadaliśmy granice: czy osoba w wieku 11 lat jest
zbyt młoda? Czy osoba w wieku 85 lat jest zbyt stara? Czy mamy na myśli tylko osoby prywatne,
czy również instytucje? Czy udzielamy dostępu klientowi, który ma kredyt, ale nie ma rachunku
w naszym banku? (Czy takie osoby istnieją?) Zdecydowaliśmy się nazwać aktora prywatnym
posiadaczem rachunku . Jeśli nie mamy dobrego opisu tego aktora, priorytetem powinno być
jego opracowanie. Dysponujemy teraz prostym przeglÄ…dem.
Chcemy wykonać pierwszą konsolidację widoku helikoptera. Będzie to kontener, w którym
[ Pobierz całość w formacie PDF ]