Darmowy fragment publikacji:
Tytuł oryginału: Lean Architecture: for Agile Software Development
Tłumaczenie: Radosław Meryk
Projekt okładki: Studio Gravite / Olsztyn
Obarek, Pokoński, Pazdrijowski, Zaprucki
ISBN: 978-83-246-8672-8
© 2010 James Coplien and Gertrud Bjørnvig.
All Rights Reserved. Authorised translation from the English language edition published by
John Wiley Sons Limited. Responsibility for the accuracy of the translation rests solely with Helion S.A.
and is not the responsibility of John Wiley Sons Limited.
No part of this book may be reproduced in any form without the written permission of the original
copyright holder, John Wiley Sons Limited.
Translation copyright © 2014 by Helion S.A.
Designations used by companies to distinguish their products are often claimed as trademarks. All brand
names and product names used in this book are trade names, service marks, trademarks or registered
trademarks of their respective owners. The publisher is not associated with any product or vendor
mentioned in this book. This publication is designed to provide accurate and authoritative information in
regard to the subject matter covered. It is sold on the understanding that the publisher is not engaged in
rendering professional services. If professional advice or other expert assistance is required, the services of
a competent professional should be sought.
Quotes from The Clock of the Long Now: Time and Responsibility – The Ideas Behind the World’s Slowest
Computer are Copyright © 2000 Stewart Brand.
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej
publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną,
fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje
naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich
właścicieli.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były
kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane
z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie
ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji
zawartych w książce.
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/arlean
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
Printed in Poland.
• Kup książkę
• Poleć książkę
• Oceń książkę
• Księgarnia internetowa
• Lubię to! » Nasza społeczność
Spis treści
O autorach ............................................................................................................................ 11
Wstęp .................................................................................................................................... 13
1. Wprowadzenie ................................................................................................................. 19
1.1. Podwaliny: Lean i Agile ........................................................................................................................... 19
1.2. Architektura Lean i wytwarzanie funkcji zgodnie z metodyką Agile ............................................... 22
1.3. Produkcja Agile ......................................................................................................................................... 24
1.3.1. Agile bazuje na architekturze Lean .................................................................................................. 24
1.3.2. Zakres systemów Agile ....................................................................................................................... 25
1.3.3. Agile i DCI ........................................................................................................................................... 26
1.4. Książka w bardzo małej pigułce .............................................................................................................. 27
1.5. Lean i Agile: kontrastujące i uzupełniające ........................................................................................... 28
1.5.1. Sekret Lean ........................................................................................................................................... 30
1.6. Utracone praktyki ..................................................................................................................................... 30
1.6.1. Architektura ......................................................................................................................................... 31
1.6.2. Obsługa zależności pomiędzy wymaganiami ................................................................................. 31
1.6.3. Podstawy użyteczności ....................................................................................................................... 31
1.6.4. Dokumentacja ..................................................................................................................................... 32
1.6.5. Zdrowy rozsądek, myślenie i opieka ................................................................................................ 35
1.7. O czym ta książka nie jest? ...................................................................................................................... 36
1.8. Agile, Lean, Scrum i inne metodologie ................................................................................................. 37
1.9. Rys historyczny ......................................................................................................................................... 38
2 . Produkcja Agile w pigułce .............................................................................................. 41
2.1. Zaangażuj interesariuszy ......................................................................................................................... 41
2.2. Zdefiniowanie problemu ......................................................................................................................... 43
2.3. Czym system jest: podstawa formy ........................................................................................................ 43
2.4. Czym system jest: siła napędowa systemu ............................................................................................ 45
2.5. Projekt i kodowanie ................................................................................................................................. 46
2.6. Odliczanie: 3, 2, 1... ................................................................................................................................... 47
Kup książkęPoleć książkę 6 (cid:181) Spis treści
3. Zaangażowanie interesariuszy ....................................................................................... 49
3.1. Strumień wartości ..................................................................................................................................... 49
3.1.1. Użytkownicy końcowi i inni interesariusze jako kotwice strumienia wartości ......................... 50
3.1.2. Architektura w ramach strumienia wartości .................................................................................. 51
3.1.3. Sekret Lean ........................................................................................................................................... 52
3.2. Najważniejsi interesariusze ..................................................................................................................... 54
3.2.1. Użytkownicy docelowi ....................................................................................................................... 56
3.2.2. Biznes .................................................................................................................................................... 60
3.2.3. Klienci ................................................................................................................................................... 61
3.2.4. Eksperci dziedzinowi .......................................................................................................................... 64
3.2.5. Deweloperzy i testerzy ....................................................................................................................... 66
3.3. Elementy procesu angażowania interesariuszy .................................................................................... 68
3.3.1. Od czego zacząć? ................................................................................................................................. 68
3.3.2. Zaangażowanie klienta ....................................................................................................................... 70
3.4. Sieć interesariuszy: eliminowanie marnotrawstwa czasu ................................................................... 71
3.4.1. Linia produkcyjna czy rój? ................................................................................................................ 71
3.4.2. Pierwsza rzecz, którą należy zbudować ........................................................................................... 73
3.4.3. Utrzymuj jedność zespołu ................................................................................................................. 74
3.5. Nie ma szybkich rozwiązań, ale jest nadzieja ....................................................................................... 75
4. Definiowanie problemu .................................................................................................. 77
4.1. Jakie cechy Agile mają definicje problemów? ...................................................................................... 78
4.2. Jakie cechy Lean mają definicje problemów? ....................................................................................... 78
4.3. Dobre i złe definicje problemów ............................................................................................................ 79
4.4. Problemy i rozwiązania ........................................................................................................................... 81
4.5. Proces definiowania problemów ............................................................................................................ 82
4.5.1. Ceń bardziej polowanie niż nagrodę ................................................................................................ 82
4.5.2. Własność problemu ............................................................................................................................ 83
4.5.3. Przerost funkcjonalności ................................................................................................................... 84
4.6. Definicje problemu, cele, czartery, wizje i zamierzenia ...................................................................... 84
4.7. Dokumentacja? ......................................................................................................................................... 85
5. Czym jest system? Część I. Architektura Lean ............................................................... 87
5.1. Kilka niespodzianek o architekturze ...................................................................................................... 88
5.1.1. Co Lean ma z tym wspólnego? .......................................................................................................... 90
5.1.2. Co Agile ma wspólnego z architekturą? .......................................................................................... 91
5.2. Pierwszy krok w projekcie: podział na części ....................................................................................... 94
5.2.1. Pierwszy podział: forma dziedzinowa a forma behawioralna ...................................................... 95
5.2.2. Drugi podział: prawo Conwaya ........................................................................................................ 96
5.2.3. Rzeczywista złożoność podziału systemu ........................................................................................ 98
5.2.4. Wymiary złożoności ........................................................................................................................... 99
5.2.5. Dziedziny. Wyjątkowy podział ......................................................................................................... 99
5.2.6. Wracamy do wymiarów złożoności ...............................................................................................101
5.2.7. Architektura i kultura ......................................................................................................................104
5.2.8. Wnioski na temat prawa Conwaya ................................................................................................105
Kup książkęPoleć książkę Spis treści (cid:181) 7
5.3. Drugi krok w projekcie: wybór stylu projektu ...................................................................................105
5.3.1. Struktura a podział ...........................................................................................................................106
5.3.2. Podstawy stylu: części stałe i zmienne ...........................................................................................107
5.3.3. Zaczynamy od oczywistych części wspólnych i różnic ................................................................108
5.3.4. Części wspólne, różnice i zakres .....................................................................................................111
5.3.5. Jawne wyrażanie części wspólnych i różnic ..................................................................................113
5.3.6. Najpopularniejszy styl: programowanie obiektowe .....................................................................116
5.3.7. Inne style w obrębie świata von Neumanna .................................................................................118
5.3.8. Języki dziedzinowe i generatory aplikacji ......................................................................................120
5.3.9. Formy skodyfikowane: języki wzorców .........................................................................................123
5.3.10. Oprogramowanie dostawców zewnętrznych i inne paradygmaty ...........................................124
5.4. Dokumentacja? .......................................................................................................................................127
5.4.1. Słownik dziedziny .............................................................................................................................127
5.4.2. Przenoszenie architektury ...............................................................................................................128
5.5. Tło historyczne .......................................................................................................................................128
6. Czym jest system? Część II. Kodowanie .......................................................................131
6.1. Krok trzeci: szkic kodu ..........................................................................................................................131
6.1.1. Abstrakcyjne klasy bazowe ..............................................................................................................132
6.1.2. Warunki wstępne, warunki końcowe i asercje .............................................................................136
6.1.3. Skalowanie algorytmów: druga strona statycznych asercji .........................................................142
6.1.4. Forma a dostępne usługi ..................................................................................................................143
6.1.5. Rusztowanie .......................................................................................................................................144
6.1.6. Testowanie architektury ..................................................................................................................146
6.2. Relacje w architekturze ..........................................................................................................................149
6.2.1. Typy relacji ........................................................................................................................................149
6.2.2. Testowanie relacji .............................................................................................................................150
6.3. Programowanie obiektowe „po nowemu” ..........................................................................................151
6.4. Ile architektury? ......................................................................................................................................153
6.4.1. Równowaga pomiędzy BUFD a YAGNI .......................................................................................154
6.4.2. Jeden rozmiar nie pasuje wszystkim ..............................................................................................154
6.4.3. Kiedy architektura jest gotowa? ......................................................................................................156
6.5. Dokumentacja? .......................................................................................................................................156
6.6. Tło historyczne .......................................................................................................................................157
7. Co system robi: funkcje systemu ..................................................................................159
7.1. Co system robi? .......................................................................................................................................160
7.1.1. Opowieści użytkowników: początek ..............................................................................................160
7.1.2. Wykorzystanie specyfikacji i przypadków użycia ........................................................................161
7.1.3. Pomoc należy się także programistom ..........................................................................................162
7.1.4. Kilometraż nie zawsze jest taki sam ...............................................................................................163
7.2. Kto będzie korzystać z naszego oprogramowania? ............................................................................164
7.2.1. Profile użytkowników ......................................................................................................................164
7.2.2. Osoby ..................................................................................................................................................164
7.2.3. Profile użytkowników czy osoby? ...................................................................................................165
7.2.4. Role użytkowników i terminologia ................................................................................................165
Kup książkęPoleć książkę 8 (cid:181) Spis treści
7.3. Do czego użytkownicy chcą wykorzystać nasze oprogramowanie? ................................................166
7.3.1. Lista własności ...................................................................................................................................166
7.3.2. Diagramy przepływu danych ..........................................................................................................166
7.3.3. Osoby i scenariusze ..........................................................................................................................167
7.3.4. Narracje ..............................................................................................................................................167
7.3.5. Projektowanie aplikacji sterowane zachowaniami .......................................................................167
7.3.6. Teraz, gdy jesteśmy rozgrzani... ......................................................................................................168
7.4. Dlaczego użytkownicy chcą korzystać z naszego oprogramowania? ..............................................169
7.5. Konsolidacja tego, co system robi ........................................................................................................170
7.5.1. Widok helikoptera ............................................................................................................................172
7.5.2. Ustawianie sceny ...............................................................................................................................177
7.5.3. Odtwarzanie scenariusza słonecznego dnia ..................................................................................178
7.5.4. Dodawanie interesujących rzeczy ...................................................................................................183
7.5.5. Od przypadków użycia do ról .........................................................................................................191
7.6. Podsumowanie ........................................................................................................................................193
7.6.1. Wsparcie przepływu pracy użytkowników ...................................................................................193
7.6.2. Wsparcie dla testów blisko prac rozwojowych .............................................................................193
7.6.3. Wsparcie dla wydajnego podejmowania decyzji na temat funkcjonalności ............................194
7.6.4. Wsparcie dla nowo powstających wymagań (odchyleń) .............................................................194
7.6.5. Wsparcie dla planowania wydań ....................................................................................................194
7.6.6. Uzyskanie danych wejściowych do opracowania architektury ..................................................195
7.6.7. Budowanie w zespole zrozumienia przedmiotu pracy ................................................................195
7.7. „To zależy”: kiedy przypadki użycia nie są dobre? ............................................................................196
7.7.1. Klasyczne programowanie obiektowe: architektury atomowych zdarzeń ...............................196
7.8. Testowanie użyteczności .......................................................................................................................197
7.9. Dokumentacja? .......................................................................................................................................198
7.10. Tło historyczne .....................................................................................................................................200
8. Kodowanie: podstawowy montaż ................................................................................201
8.1. Obraz z góry: wzorzec projektowy Model-View-Controller-User ..................................................201
8.1.1. Czym jest program? ..........................................................................................................................202
8.1.2. Czym jest program Agile? ................................................................................................................203
8.1.3. MVC bardziej szczegółowo .............................................................................................................204
8.1.4. MVC-U: to nie koniec opowieści ...................................................................................................205
8.2. Forma i architektura systemów zdarzeń atomowych ........................................................................208
8.2.1. Obiekty dziedziny .............................................................................................................................208
8.2.2. Role obiektów, interfejsy i Model ...................................................................................................208
8.2.3. Refleksje: przypadki użycia, architektury zdarzeń atomowych i algorytmy ............................211
8.2.4. Przypadek specjalny: odwzorowanie ról obiektów na obiekty typu jeden do wielu ...............212
8.3. Aktualizacja logiki dziedziny: rozwijanie metod, faktoryzacja i refaktoryzacja ............................212
8.3.1. Tworzenie nowych klas i wypełnianie istniejących namiastek funkcji .....................................213
8.3.2. Powrót do przyszłości: po prostu stare, dobre programowanie obiektowe .............................215
8.3.3. Narzędzia analizy i projektowania .................................................................................................215
8.3.4. Faktoryzacja .......................................................................................................................................216
8.3.5. Uwaga na refaktoryzację ..................................................................................................................216
8.4. Dokumentacja? .......................................................................................................................................217
Kup książkęPoleć książkę Spis treści (cid:181) 9
8.5. Do czego te wszystkie artefakty? ..........................................................................................................217
8.6. Tło historyczne .......................................................................................................................................218
9. Kodowanie: architektura DCI .......................................................................................219
9.1. Czasami inteligentne obiekty po prostu są niewystarczające ...........................................................219
9.2. DCI w pigułce .........................................................................................................................................220
9.3. Przegląd architektury DCI ....................................................................................................................221
9.3.1. Części modelu mentalnego użytkownika końcowego, o których zapomnieliśmy ..................221
9.3.2. Wprowadzenie ról obiektowych z metodami ...............................................................................223
9.3.3. Sztuczki z cechami ............................................................................................................................225
9.3.4. Klasy kontekstu: jedna w każdym przypadku użycia ..................................................................226
9.4. DCI na przykładzie .................................................................................................................................229
9.4.1. Dane wejściowe do projektu ...........................................................................................................229
9.4.2. Od przypadków użycia do algorytmów .........................................................................................230
9.4.3. Bezmetodowe role obiektów: framework dla identyfikatorów ..................................................232
9.4.4. Podział algorytmów pomiędzy role obiektowe z metodami ......................................................234
9.4.5. Framework kontekstu ......................................................................................................................241
9.4.6. Warianty i sztuczki w architekturze DCI ......................................................................................259
9.5. Aktualizacja logiki dziedziny ................................................................................................................261
9.5.1. Porównanie DCI ze stylem architektury zdarzeń atomowych ...................................................261
9.5.2. Szczególne aspekty logiki dziedzinowej w architekturze DCI ....................................................263
9.6. Obiekty kontekstu w modelu mentalnym użytkownika końcowego:
rozwiązanie odwiecznego problemu ........................................................................................................265
9.7. Do czego te wszystkie artefakty? ..........................................................................................................269
9.8. Nie tylko C++: DCI w innych językach ...............................................................................................272
9.8.1. Scala ....................................................................................................................................................272
9.8.2. Python ................................................................................................................................................273
9.8.3. C# ........................................................................................................................................................273
9.8.4. ...a nawet w Javie ...............................................................................................................................273
9.8.5. Przykład z rachunkami w Smalltalku .............................................................................................274
9.9. Dokumentacja? .......................................................................................................................................274
9.10. Tło historyczne .....................................................................................................................................275
9.10.1. DCI a programowanie aspektowe ................................................................................................275
9.10.2. Inne podejścia .................................................................................................................................276
10. Epilog ............................................................................................................................277
A. Implementacja przykładu architektury DCI w Scali ...................................................279
B. Przykład implementacji rachunków w Pythonie ........................................................283
C. Przykład implementacji rachunków w C# ...................................................................287
D. Przykład implementacji rachunków w Ruby ..............................................................291
E. Qi4j ..................................................................................................................................297
F. Przykład implementacji rachunków w Squeaku .........................................................299
Bibliografia .........................................................................................................................307
Skorowidz ..........................................................................................................................317
Kup książkęPoleć książkę 10 (cid:181) Spis treści
Kup książkęPoleć książkę ROZDZIAŁ7
Co system robi: funkcje systemu
Jednym z zaskakujących produktów ubocznych procesu planowania
scenariuszy jest zwiększająca się odpowiedzialność.
The Clock of the Long Now, s. 118.
Każdy system ma dwa projekty: projekt tego, co system robi, oraz projekt tego, czym system jest.
Użytkowników końcowych najbardziej interesują usługi, które realizuje oprogramowanie, a te
prawie zawsze należą do kategorii co-system-robi. Jednak przez interfejs usług ujawnia się model
dziedziny. Przypomnijmy sobie, jak ważna dla programowania obiektowego jest metafora bez-
pośredniej manipulacji. Ponadto ze względu na dążenie do obniżania długoterminowych kosztów
(co jest dobre z punktu widzenia klientów i użytkowników końcowych) oraz przygotowanie się
na zmiany (oczekiwane zarówno przez klientów, jak i większość końcowych użytkowników)
producent (którego jesteśmy przedstawicielami) także chce rozpocząć od dobrej ogólnej formy
całego systemu, a ta forma jest ugruntowana w części czym-system-jest. Na początku projektu
trzeba skupić się na obu tych aspektach. Ta koncentracja na dwóch krańcach nie tylko odnosi
się do dobrego początku, ale i jest podstawą długoterminowej kondycji produktu.
Ważne jest, aby zawsze pamiętać, że sednem tego, co oprogramowanie dostarcza, są usługi,
a usługi dotyczą działania. W przeciwieństwie do budynków komputery działają w ludzkich ska-
lach czasowych. Ta dynamika jest kluczem do ich roli w życiu. Luke Hohmann uważa, że zamiast
sięgać do architektury budynków jako metafory projektowania systemów oprogramowania,
powinniśmy raczej skorzystać z innego rodzaju sztuki: tańca. Podobnie jak architektura, taniec
dotyczy formy, ale jest żywy i dynamiczny. Rozdziały 5. i 6. przygotowały nam „salę balową”. Te-
raz możemy przejść do tańca.
Biorąc pod uwagę, że jest to książka poświęcona Agile, można się spodziewać, że więcej użyt-
kowników będzie przedkładać część o tym, co system robi, nad część poświęconą czystej archi-
tekturze. W idealnym świecie postąpilibyśmy w taki sposób: prowadzilibyśmy projekt wyłącznie
według dążeń użytkownika końcowego, nie zajmując się niczym poza tym. Analizujemy trochę
formę dziedziny przed szczegółowym omówieniem funkcjonalności szczegółowo, ponieważ taki
sposób zapewnia lepszą wydajność. Jeśli terminologia związana z architekturą wspiera wzajemne
zrozumienie pomiędzy dostawcą a użytkownikiem, możemy z ufnością przejść do funkcjonal-
ności oraz zająć się poprawianiem długoterminowej elastyczności.
Kup książkęPoleć książkę 160 (cid:181) Rozdział 7. Co system robi: funkcje systemu
7.1. Co system robi?
Aby zdecydować, co system robi, najpierw musimy znać odpowiedzi na pytania: kto?, co? i dlaczego?
Kto będzie korzystać z naszego oprogramowania? Co będzie z nim robić? I dlaczego to robi?
W świecie wytwarzania oprogramowania zgodnie z metodyką Agile popularne opowieści użyt-
kowników formułuje się wokół tej mantry „kto, co i dlaczego”. „Jako posiadacz rachunku (kto)
chcę przelewać pieniądze pomiędzy moimi rachunkami (co) po to, by mieć pewność, że na żadnym
z rachunków nie powstanie debet (dlaczego)”.
7.1.1. Opowieści użytkowników: początek
Opowieści użytkowników są dobrym punktem wyjścia, ale prawdopodobnie nie są dość dobre,
by zapewnić dobry rezultat końcowy. Co właściwie wiemy o posiadaczu rachunku? Jeśli to ja
mam być posiadaczem rachunku, to będę korzystał z konta internetowego do realizowania
przelewów. Jeśli posiadaczem rachunku jest mój 11-letni syn, to ma on tylko jeden rachunek i nie
będzie potrzebował tej funkcjonalności. Jeśli posiadaczem rachunku jest moja 85-letnia ciocia,
to pójdzie do banku i poprosi pracownika, aby zrealizował dla niej przelew. Jeżeli posiadacz ra-
chunku nie może sam pójść do banku i nie ma dostępu do internetu, telefon do banku będzie
preferowanym rozwiązaniem. A zatem powinniśmy wiedzieć więcej na temat kontekstu. W roz-
dziale 4. zwróciliśmy uwagę na znaczenie kontekstu w formułowaniu problemu do rozwiązania.
Czy posiadacz rachunku jest użytkownikiem internetu i będzie realizował przelewy z domu? Czy
posiadacz rachunku korzysta z pośrednika w banku do realizacji przelewu? Czy bank chce udo-
stępnić tę usługę z poziomu swoich bankomatów?
Przelew pieniędzy powinien być prosty. Użytkownik wybiera rachunek źródłowy, rachunek
docelowy i kwotę. System przeprowadza proste obliczenia i aktualizuje saldo na obu rachun-
kach. Dwa kroki i na tym koniec. Prawie... Po prostu powinniśmy wiedzieć kilka dodatkowych
rzeczy: czy oba rachunki muszą być w tym samym banku? Jakie będą konsekwencje przekazania
pieniędzy z rachunku, jeśli po operacji pozostanie na nim ujemne saldo? Czy przelew powinien
odbyć się natychmiast? Czy użytkownik może zaplanować realizację przelewu w przyszłości?
Czy przyszłość może oznaczać „za 10 lat?”. Co powiemy posiadaczowi rachunku mającemu tylko
jeden rachunek, a próbującemu przelać pieniądze? (Błąd?) Czy dzieci powinny mieć dostęp do tej
funkcji? Czy użytkownik może zlecić przelew cykliczny, na przykład raz na miesiąc?
Ktoś, kto od lat pracuje w określonym banku i posiada głęboką wiedzę dziedzinową, być
może zna odpowiedź na wiele z tych pytań. Ale strategie bankowe są ulotne i nadążenie za aktu-
alnymi zmianami może być trudne. Projektantowi lub nawet architektowi zazwyczaj ktoś do-
starcza odpowiedzi na pytania dotyczące wybranej dziedziny. Może nam się wydawać, że im-
plementacja przelewu cyklicznego nie jest trudna, a jej zakodowanie nie zajmie zbyt dużo czasu.
Ale to wymaga również prawidłowego interfejsu użytkownika. Trzeba przeprowadzić testy. Po-
wstają nowe pytania w stylu: w jaki sposób poinformować posiadacza rachunku o tym, że nie ma
wystarczających środków do zrealizowania przelewu? Jest to zatem decyzja biznesowa, a nie decyzja
bazująca na interpretacji opowieści użytkownika z punktu widzenia programisty.
Moglibyśmy również przeanalizować perspektywę dlaczego. Być może posiadacz rachunku
przelewa pieniądze, ponieważ na innym rachunku jest lepsze oprocentowanie albo ze względu
na korzyści podatkowe, które wynikają z przelewu pieniędzy na inny rachunek na początku no-
wego roku. Czy to ma znaczenie? Nie wiemy tego na pewno, dopóki nie przeprowadzimy analizy.
Wiemy jednak, że ukryte założenia projektanta mają ogromny wpływ na projekt interfejsu użyt-
kownika.
Kup książkęPoleć książkę 7.1. Co system robi? (cid:181) 161
7.1.2. Wykorzystanie specyfikacji i przypadków użycia
Powyższe pytania pokazują to, co stało się powszechnym doświadczeniem wytwarzania opro-
gramowania zgodnie z metodyką Agile: opowieści użytkowników nie są wystarczające. Liderzy
Agile uzupełnili przypadki użycia przypadkami testowymi (Cohn 2004, s. 7) oraz ograniczeniami
i regułami biznesowymi (Cohn 2004, s. 77). Zalecają nawet wykorzystanie narzędzi w celu prze-
zwyciężenia ograniczeń kart (Cohn 2004, s. 179). A opowieści można pogrupować w obszary
biznesowe wyższego poziomu, podobnie do scenariuszy grupowania przypadków użycia (Patton
2009). W miarę jak społeczność Agile zdobywała doświadczenie w ciągu ostatnich dziesięciu lat,
współczesne opowieści użytkowników w rzeczywistości stały się przypadkami użycia (rysunek 7.1).
Alistair Cockburn uzasadnia, dlaczego w dalszym ciągu używa przypadków użycia (Cockburn 2008):
Opowieści użytkowników i pozycje rejestru wymagań nie dają projektantom kontekstu,
który stworzyłby podstawę do pracy (...) nie dają zespołowi projektowemu poczucia
„kompletności” (...) nie dostarczają wystarczająco dobrego mechanizmu patrzenia
w przyszłość na trudności wynikające z prac, które będą wykonywane.
(...)
Przypadki użycia są rzeczywiście „cięższe” i trudniejsze niż zarówno opowieści
użytkowników, jak i elementy rejestru wymagań, ale wnoszą wartość w zamian za ten
dodatkowy ciężar... W szczególności przypadki użycia rozwiązują następujące trzy problemy.
Rysunek 7.1. Przypadki użycia integrują wiele dodatków do opowieści użytkowników
1. Lista nazw celów zapewnia kierownictwu krótkie podsumowanie tego, co system
zaoferuje użytkownikom biznesowym i użytkownikom końcowym...
2. Główny scenariusz sukcesu każdego przypadku użycia zapewnia porozumienie wszystkich
zainteresowanych stron odnośnie do tego, co system będzie robił, a czasem, co ważniejsze,
czego nie zrobi...
3. Rozszerzenia każdego przypadku użycia zapewniają analitykom wymagań framework
do analizy niewielkich elementów, które niekiedy w niezrozumiały sposób zajmują 80
czasu i pieniędzy przeznaczonych na projekt...
Kup książkęPoleć książkę 162 (cid:181) Rozdział 7. Co system robi: funkcje systemu
4. Fragmenty opisujące rozszerzenia przypadków użycia dostarczają odpowiedzi na wiele
szczegółowych, często trudnych pytań biznesowych zadawanych przez programistów...
jest to framework (dokumentacja) myślenia...
5. Pełny zestaw przypadków użycia pokazuje, że analitycy przemyśleli wszystkie potrzeby
użytkowników, zajęli się wszystkimi celami, jakie ma spełnić system, oraz wszystkimi
wariantami...
Zwolennicy Agile odpowiadają, że opowieści użytkowników są jedynie „obietnicą przyszłej
konwersacji”. Prawdą jest, że prowadzenie takiej konwersacji jest ważne. Pytanie brzmi: co zro-
bimy z ustaleniami wynikającymi z takiej rozmowy? Jednym z efektów może być więcej opowieści
użytkowników:
„Jako posiadacz rachunku chcę składać polecenia przelewów comiesięcznych, tak bym
mógł opłacać rachunki z innego rachunku niż ten, na który wpływa moja pensja”.
„Jako posiadacz rachunku chcę przelewać pieniądze innemu posiadaczowi rachunku,
tak bym mógł płacić za wypożyczanie nart”.
„Jako posiadacz rachunku chcę opłacać rachunki przez internet, abym nie musiał
chodzić na pocztę”.
Moglibyśmy także stworzyć opowieści użytkowników dla innych ról użytkowników, takich
jak doradcy bankowi, księgowi lub organy podatkowe. Moglibyśmy przedstawić różne motywa-
cje dla tej samej funkcji i mieć nadzieję na ich zintegrowanie ze sobą. Aby szybko uzyskać wiele
opowieści użytkowników, można umieścić pięciu ekspertów dziedzinowych w pokoju i poprosić
o przeprowadzenie burzy mózgów na ten temat. To jest dobry sposób na analizę wymagań. Ale
w jaki sposób zorganizować 200 opowieści użytkowników utworzonych w zeszłym tygodniu?
Trzeba stworzyć (najlepiej uporządkowaną) listę opartą na relacjach między nimi, ich kosztami,
wartością biznesową i oczekiwanym czasem pojawienia się na rynku, tak aby można było podjąć
właściwe decyzje biznesowe dotyczące rozpoczęcia pracy nad każdą z opowieści użytkowników.
Trzeba spróbować pomóc przedstawicielom biznesu, zanim sprawy skomplikują się za bardzo.
Pomoc nie powinna polegać na tworzeniu „podopowieści” (dzieleniu dużych opowieści na mniej-
sze) czy też „epiki” (łączeniu mniejszych historii w większe). Nie ma powodu, aby odkrywać
koło na nowo. W branży od dawna istnieją sprawdzone sposoby radzenia sobie z takimi pro-
blemami, a wiele z tych praktyk honoruje podejście zarówno Lean, jak i Agile.
7.1.3. Pomoc należy się także programistom
Większość dyskusji na temat wymagań skupia się na spełnieniu oczekiwań przedstawicieli biznesu.
Chcemy, aby czuli, że przekazali nam coś, co daje obraz ich wizji, i aby byli w stanie to zrobić,
nie wiedząc zbyt wiele o Ruby, C# czy Javie. Łatwo jest zapomnieć o kliencie tych wymagań: ze-
spole projektowym.
Deweloper może teoretycznie sam przeprowadzić analizę i bezpośrednio uzyskać wymaga-
nia. Takie podejście może się sprawdzać w małych zespołach projektowych lub w nieformalnych
relacjach biznesowych. Zazwyczaj jednak deweloperzy nie mają umiejętności wykonywania dobrej
analizy i brakuje im wiedzy biznesowej niezbędnej do przyjęcia odpowiedzialności za formu-
łowanie wymagań, które będą miały wpływ na kierunek biznesu. Wiemy przy tym — dotyczy to
zarówno projektowania zgodnie z metodyką Agile, jak i innych metodyk — że przedstawiciele
biznesu zbyt często przedwcześnie przekazują pracę zespołowi projektowemu. Zespół nie zawsze
Kup książkęPoleć książkę 7.1. Co system robi? (cid:181) 163
wie, czego chce biznes, i czasami brakuje mu możliwości uzyskania istotnych wyjaśnień. Oczy-
wiście, niemożliwe jest stworzenie wyczerpującej listy wymagań (z powodu powstawania no-
wych), więc zawsze potrzebne jest jakieś sprzężenie zwrotne, które pozwoli utrzymać rozwój pro-
duktu już po rozpoczęciu kodowania.
Nawet wtedy, gdy programista uzyska wymagania, powinno być możliwe szybkie rozpoczęcie
prac rozwojowych. Pytania o wymagania nie powinny wynikać z nieadekwatności specyfikacji,
ale raczej powinny pojawiać się jako „niespodzianki”, które ujawniają się podczas szczegółowego
projektowania lub kodowania. Dobre wymagania powinny stwarzać możliwości dla dewelopera.
Specyfikacje stwarzające możliwości nie są jednak substytutem zasady wszyscy, razem, od wczesnej
fazy: są one raczej dowodem na to, że sekret Lean jest rzeczywiście w użyciu.
W amerykańskim systemie patentowym wykorzystuje się termin enabling specification (z ang.
specyfikacja stwarzająca możliwości) do opisania patentu, który jest na tyle przekonujący, aby
można było rozpocząć produkcję bez zbyt wielu nowych badań. W tym samym sensie, jak patent
umożliwia rzemieślnikowi odtworzenie wynalazku, tak wymagania powinny umożliwić członkom
zespołu maksymalne wyeliminowanie konieczności ponownych badań tematu.
Jeff Sutherland opisuje koncepcję specyfikacji stwarzających możliwości w metodyce Scrum
(Sutherland 2009). Pisze on między innymi:
Okazuje się, że specyfikacja stwarzająca możliwości to dokładnie to, co jest potrzebne do
maksymalizacji wydajności procesu realizacji opowieści użytkowników. Średnia wydajność
procesu zespołów realizujących opowieści użytkownika wynosi około 20 . Oznacza to,
że realizacja opowieści oszacowanej na jeden idealny dzień pracy zajmuje pięć dni
kalendarzowych. Firma Systematic Software Engineering stosująca piąty stopień CMM
(ang. Capability Maturity Model) posiada szerokie dane pokazujące, że zespoły, które uzyskają
ponadpięćdziesięcioprocentową wydajność przetwarzania opowieści użytkownika, będą
systematycznie podwajać swoją prędkość.
7.1.4. Kilometraż nie zawsze jest taki sam
W małym projekcie opowieści użytkownika wraz z przypadkami testowymi oraz mapą opowie-
ści zdobiącą ścianę pomieszczenia zespołu mogą być wszystkim, czego potrzeba (Patton 2009).
W tym rozdziale omówimy wiele sposobów realizacji części architektury odpowiadającej na py-
tanie, co system robi: opowieści użytkowników, przypadki użycia, funkcje, a nawet dobre, sta-
romodne wymagania. Tak jak wcześniej, przy okazji będziemy trochę kwestionować konwen-
cjonalną mądrość metodyki Agile. Ale nie damy jednoznacznej recepty.
Zanim przejdziemy dalej, powinniście zapamiętać dwie rzeczy. Po pierwsze, głównym celem
każdego formalizmu związanego z wymaganiami jest zapewnienie centralnej platformy do bez-
pośredniego dialogu, który zachodzi wokół niej. Taki dialog daje największe szanse budowania
wspólnej perspektywy niezbędnej do spełnienia oczekiwań użytkowników końcowych. Po drugie,
trzeba pamiętać, że my nie udzielamy ostatecznych odpowiedzi. Zachęcamy do eksperymento-
wania w celu znalezienia tego, co sprawdza się w konkretnym przypadku. To może oznaczać
stawianie sobie wyzwań oraz próbowanie rzeczy, w które nie do końca wierzymy, że działają. Być
może warto, ale nikt z nas nie może wiedzieć z góry.
Spróbujmy zatem powrócić po kolei do odpowiedzi na pytania: kto?, co? i dlaczego? Naszym
celem jest wyjście poza postulat Manifestu Agile „działającego oprogramowania”. Chcemy, aby
nasze oprogramowanie było użyteczne. Do podejścia metodyki Agile dodamy praktyki Lean, aby
zminimalizować marnotrawstwo wynikające z przeróbek. Czym-system-jest to stabilna część
Kup książkęPoleć książkę 164 (cid:181) Rozdział 7. Co system robi: funkcje systemu
architektury, natomiast co-system-robi to jego część dynamiczna. Ale nawet w obrębie części
co-system-robi jest element, który wcześnie należy ustabilizować — funkcja także ma formę —
a bardziej dynamiczna część mieści się w tym fragmencie Manifestu Agile, który jest poświęcony
„przygotowaniu się na zmiany”. Potrzebujemy zarówno praktyk Lean, jak i metodyki Agile.
7.2. Kto będzie korzystać z naszego oprogramowania?
Początkowo w opowieściach użytkowników metodyki Agile rzadko występują prawdziwi użyt-
kownicy (Jeffries, Anderson i Hendrickson 2001, s. 25 – 28). Na przykład:
Dla każdego rachunku oblicz saldo poprzez zsumowanie wszystkich wpłat i odjęcie
wszystkich wypłat. (Jeffries, Anderson i Hendrickson 2001).
W wielu fragmentach nazywanych opowieściami użytkowników w ogóle nie ma użytkowników.
Wiele firm stosuje formę opowieści użytkownika „Jako użytkownik...”, ale użytkownik nigdy nie
jest nikim innym... jak tylko użytkownikiem. Podczas tej translacji zagubiono rolę użytkownika.
Czy użytkownik jest w moim wieku? W wieku mojego dziecka? Mojej 85-letniej ciotki? Dobre
historie użytkowników wyjaśniają role użytkowników. Role, które odzwierciedlają przemyślenia
analityków dotyczące tożsamości użytkownika. W ten sposób do opowieści użytkowników trafia
użytkownik w klasycznym znaczenia tego słowa. W opowieściach użytkowników Agile nie ma
poza tym żadnej opowieści, ale to już inna opowieść...
Zanim przejdziemy do omawiania ról użytkowników, zwróćmy uwagę, że należy odróżnić
role użytkowników od ról w architekturze DCI. W DCI są to obiekty, które mogą odgrywać różne
role, więc by uniknąć nieporozumień, możemy nazwać je rolami obiektów.
7.2.1. Profile użytkowników
Jak definiujemy rolę użytkownika? Najpierw szukamy wskazówek w użyteczności. Eksperci
w dziedzinie użyteczności wiedzą, jak badać perspektywę użytkownika końcowego oraz jak skon-
solidować te ustalenia w profilach użytkowników. Model przypadków użycia reprezentuje interesy
użytkowników końcowych za pomocą aktorów. Aktor jest rolą użytkownika, dlatego profil użyt-
kownika można zmapować bezpośrednio do przypadku użycia aktor. Profil użytkownika staje
się opisem aktora. Profile użytkowników mogą oczywiście być również używane jako role użyt-
kowników w opowieściach użytkowników.
Jeśli organizacja nie posiada specjalistów w dziedzinie użyteczności, zespół może samodziel-
nie przeprowadzić cenne modelowanie ról użytkowników. Mike Cohn (Cohn 2004, rozdział 3.)
przedstawia ciekawe wytyczne w formie procedury składającej się z czterech kroków.
7.2.2. Osoby
W przypadku aplikacji internetowych popularne stało się tworzenie osób. Osoba jest wymyśloną
postacią o określonej płci, wieku, rodzinie, zawodzie, hobby oraz wszystkim innym, co można
wiedzieć o postaci. Osoba jest „kimś, kogo znasz tak dobrze, jakbyś z nim spał” — to popularne
powiedzenie w środowisku ludzi posługujących się tym pojęciem. Osoba może odgrywać wiele
ról użytkowników w powiązaniu z naszym oprogramowaniem — tak jak prawdziwa osoba. Profil
użytkownika nie jest konkretną osobą, ale rolą użytkownika bazującą na faktach dotyczących
Kup książkęPoleć książkę 7.2. Kto będzie korzystać z naszego oprogramowania? (cid:181) 165
rzeczywistych użytkowników. Osoby mają imiona, na przykład „Maria” lub „Jan”, podczas gdy
profil użytkownika charakteryzuje się nazwą roli użytkownika, na przykład „administrator bazy
danych” lub „nastoletni klient banku”.
7.2.3. Profile użytkowników czy osoby?
Osoby mogą dodać wartość do organizacji, w których oprogramowanie jest używane przez takie
szerokie grono użytkowników, że określenie ograniczonego, cennego zbioru profili użytkowników
wydaje się niemożliwe, lub tam, gdzie koncentracja na użytkownikach jest dla organizacji czymś
nowym. Zamiast sytuacji, w której wszyscy interesariusze w czasie tworzenia oprogramowania
mają na myśli własny obraz „osoby”, mogą teraz współdzielić uspołeczniony, konkretny opis
osoby. Istnieje ryzyko, że stworzymy oprogramowanie dla tej konkretnej osoby, a nie dla roli
użytkownika, którą może odgrywać wiele różnych osób.
W bardziej dojrzałych organizacjach, w których członkowie zespołu mają zdyscyplinowany
kontakt z użytkownikami końcowymi, osoby sprawiają wrażenie nierealistycznych. Będą one
postrzegane jako powierzchowne i zbyt różniące się od prawdziwych użytkowników, z którymi
mają styczność członkowie zespołu. W tego rodzaju organizacjach lepiej posługiwać się profilami
użytkowników niż osobami. Profile użytkowników są bazującymi na doświadczeniu charakte-
ryzacjami segmentów rynku, a w szczególności tych segmentów, do których ma dotrzeć pro-
dukt (rysunek 7.2).
Rysunek 7.2. Profil użytkownika (za Nielsen 2005)
Czasami wizerunek osoby jest zbyt ograniczający, a rynek zbyt odległy. Możemy skorzystać
z wzorca projektowego Surrogate Customer (Coplien i Harrison 2004, s. 116 – 117), aby uzyskać
jak najszerszą wiedzę o rynku w przypadkach, gdy mamy ograniczony kontakt z prawdziwymi
klientami. Constantine i Lockwood (Constantine i Lockwood 1999) mówią również o tym, jak
opracować rozsądne wymagania w takich warunkach. Należy jednak dążyć do zachowania po-
stawy Agile i ciągłego uzyskiwania informacji od społeczności użytkowników końcowych.
7.2.4. Role użytkowników i terminologia
Słowa oznaczają rzeczy. Dobre, opisowe nazwy mogą pomóc w zbliżeniu się do oczekiwań użyt-
kowników końcowych. „Maria” i „Jan” jako imiona typowych klientów nie wnoszą zbyt wielu
informacji. „Nastoletni użytkownik” (rysunek 7.2) przekazuje znacznie więcej informacji i może
być podstawą do stworzenia roli „nastoletni klient banku”. Takie terminy są ważne nie tylko
w rozmowach między zainteresowanymi stronami, ale także w zagwarantowaniu czytelności i ła-
twości utrzymania kodu. Tak, można używać tych uzgodnionych nazw w kodzie! Tradycyjne
Kup książkęPoleć książkę 166 (cid:181) Rozdział 7. Co system robi: funkcje systemu
możliwości śledzenia, które są sformalizowane przez narzędzia, są martwe w metodyce Agile
(pamiętajmy o zasadzie „osoby i interakcje ponad procesy i narzędzia”). W podejściu Lean
możliwości śledzenia zastępujemy uważnie dobraną terminologią. Dobra nazwa roli użytkownika
może przyczynić się do właściwego rozumienia roli. Wystarczy obserwować swoich użytkowników
— nie trzeba z nimi spać.
7.3. Do czego użytkownicy
chcą wykorzystać nasze oprogramowanie?
To jest zasadnicza część odpowiedzi na pytanie, co system robi. Części kto i dlaczego pomagają
właściwie odpowiedzieć na to pytanie — dostarczają ważnego kontekstu1. Odpowiedzi na pyta-
nie, co system robi, można udzielić na wiele sposobów: w postaci wymagań, diagramów prze-
pływu danych, własności, aktorów i przypadków użycia, opowieści użytkowników i testów ak-
ceptacyjnych, osób i scenariuszy, w postaci narracji, scenorysów (ang. story boards), prototypów
i prawdopodobnie wielu innych. Kiedy system coś robi, oznacza to, że ma jakieś zachowanie.
Powyższe techniki opisują zachowanie mniej lub bardziej wyraźnie. Tradycyjne sformułowanie
wymagania może brzmieć następująco: „System powinien przelewać pieniądze z jednego ra-
chunku na inny”. Brzmi znajomo? Nie różni się zbytnio od naszej opowieści użytkownika: „Jako
posiadacz rachunku chcę przelewać pieniądze pomiędzy moimi rachunkami, by mieć pewność,
że na żadnym z rachunków nie powstanie debet”.
7.3.1. Lista własności
Listy własności (ang. feature lists) to jeszcze inne podejście do opisywania funkcjonalności. Opis
własności dla wymagania wymienionego powyżej może brzmieć następująco: „Przelew pieniędzy
z jednego rachunku na inny”. Słowo „przelew” oznacza zachowanie, ale nie jest ono wyraźnie opi-
sane, co prowadzi do stawiania pytań, których przykłady zaprezentowaliśmy w pierwszej części
tego rozdziału.
Różnica pomiędzy własnością a opowieścią użytkownika jest subtelna. Na początku, kiedy
Kent Beck wprowadził opowieści użytkowników (Beck 2005), jedyną różnicą pomiędzy opisem
własności a opowieściami użytkownika, było to, że opowieści użytkowników były krótkie i pisane
ręcznie na „karcie opowieści” (ang. story card). W dzisiejszym świecie Agile większość opowieści
użytkownika jest zapisywanych w komputerze za pomocą takich narzędzi jak Excel lub narzędzi
bardziej dostosowanych do tego celu. Trudno jest zauważyć różnicę między listami własności
a listą opowieści użytkowników z wyjątkiem tego, że termin opowieść użytkownika jest społecznie
bardziej akceptowalny wśród firm programistycznych, które postrzegają siebie jako Agile.
7.3.2. Diagramy przepływu danych
Diagram przepływu danych (ang. Data Flow Diagram — DFD) — kolejna alternatywa — zawie-
rałby wysokopoziomowy proces o nazwie „Przelew pieniędzy”. Do i z tego procesu przekazywane
byłyby dane (tzn. kwota i saldo). Proces ten można zdekomponować na następujące podprocesy:
1 Tutaj, w rozdziale 7. używamy słowa „kontekst” w przybliżeniu w takim znaczeniu, w jakim używa się go
w języku naturalnym. Pojęcie w znaczeniu bardziej ścisłym pojawia się w rozdziale 9.
Kup książkęPoleć książkę 7.3. Do czego użytkownicy chcą wykorzystać nasze oprogramowanie? (cid:181) 167
„Zdefiniuj rachunek źródłowy i docelowy”, „Przelej pieniądze” oraz „Zrealizuj zapisy księgowe”.
Dekompozycja zatrzymuje się, gdy proces najniższego poziomu można nazwać „atomowym” (nie
można go dalej dekomponować). Diagramy przepływu danych mogą się sprawdzać w przypadku
indywidualnego analityka, ale nie gwarantują skutecznego mechanizmu przekazywania wiedzy
pomiędzy członkami zespołu projektowego. Bardzo łatwo pogubić się na wielu poziomach de-
kompozycji.
7.3.3. Osoby i scenariusze
Osoby często są wykorzystywane razem ze scenariuszami. Scenariusz opisuje konkretny sche-
mat działania dla wskazanej osoby. Jeśli osobą jest „Maria”, 32-letnia samotna matka 2-letniego
Benjamina i 4-letniej Laury, która pracuje na pełny etat jako pielęgniarka, to scenariusz może
opisywać, jak Maria w drodze do domu z pracy korzysta z bankomatu, aby przelać pieniądze
z konta oszczędnościowego, by mogła zapłacić rachunek za naprawę samochodu. Scenariusz dla
osoby koncentruje się na tym, jakie przyciski ma wciskać Maria oraz jakie elementy menu ma
wybierać.
7.3.4. Narracje
Narracja2 może korzystać z tego samego podejścia jak w przypadku osób, ale unika tworzenia
konkretnego stereotypu. Zamiast tego tworzone jest krótkie opowiadanie opisujące funkcjonal-
ność systemu. Na przykład możemy wymyślić hipotetyczną osobę o imieniu Maria „w locie”.
Niech Maria będzie treserem psów policyjnych. Jej samochód jest w warsztacie. Maria trzyma
w jednej ręce smycz z dwoma psami policyjnymi, a na drugim ręku ma Benjamina. Pada deszcz,
a za 10 minut zamykają przedszkole Laury. W tym przypadku narracja opisywałaby wizję, jak
bankomat może pomóc Marii w tej konkretnej sytuacji, bez skupiania się na szczegółach inter-
fejsu użytkownika bankomatu. Ale historia może nam pomóc w uzyskaniu świadomości, że ten
przypadek wiąże się z innymi wymaganiami w odniesieniu do interfejsu użytkownika niż w przy-
padku osoby, która wykonuje transakcje bankowe z komputera w swoim domu. Narracja kon-
centruje się na kontekście (Cockburn 2001, s. 18).
Narracja może się składać z dwóch części: części przed i części po. Opisują one kłopoty Marii,
zanim bank dał jej łatwy sposób przelania pieniędzy, oraz po tym fakcie. Możemy zatem mówić
o narracji problemu oraz narracji wizji, które pomagają zrozumieć motywację użytkownika lub
firmy. Wykorzystanie kombinacji osób i scenariuszy wyjaśnia motywację użytkownika, ale opi-
suje interfejs użytkownika w pewien pośredni, zagmatwany sposób.
7.3.5. Projektowanie aplikacji sterowane zachowaniami
W opowieściach użytkowników brakuje wyraźnego opisu zachowania. Popularnym sposobem
na to, by ten brak zrekompensować, jest dodanie testów akceptacyjnych na odwrocie karty opowie-
ści użytkownika. Oznacza to, że odpowiedzi na niektóre z pytań postawionych na początku tego
2 Używamy terminu „narracja” po to, by nie mylić tego rodzaju historii z opowieściami użytkowników.
Alistair Cockburn używa terminu „narracje użycia” w odniesieniu do historii, które przypominają
scenariusze w podejściu wykorzystującym osoby i scenariusze. Unika terminu „opowieść” w tym kontekście
z tego samego powodu: aby nie mylić ich z pojęciem opowieści użytkowników w programowaniu
ekstremalnym.
Kup książkęPoleć książkę 168 (cid:181) Rozdział 7. Co system robi: funkcje systemu
rozdziału zostaną udzielone w postaci kryteriów testów akceptacyjnych. Na przykład „Test: jeśli
konto źródłowe po transakcji stanie się ujemne, przelew nie będzie dozwolony”. Prawdopodob-
nie będzie więcej kryteriów testów akceptacyjnych. Tyle, na ile pozwoli miejsce na karcie. Kryteria
te zostaną opisane w innym miejscu.
To skrócone podejście sugeruje, że przemieszczamy wiedzę z obszaru co-system-robi do opi-
sów testów. Właśnie takie podejście jest stosowane w metodyce BDD (Behavior-Driven Devel-
opment) (North 2006). W BDD opowieści użytkowników są danymi wejściowymi do scenariuszy
testowych opisujących, co system robi. Programista koduje scenariusze testowe bezpośrednio za
pomocą narzędzia testowego — i voilà! Od tej chwili programista jest odpowiedzialny za wyma-
gania. Być może jest to o jeden krok dalej, niż chcielibyśmy pójść teraz. Nie chcemy stracić na-
szych ekspertów z dziedziny biznesu ani specjalistów od interakcji z użytkownikami z powodu
dążenia do kodowania. Kod jest bardzo czytelny dla koderów, ale być może nie jest tak bardzo
czytelny dla reszty świata.
7.3.6. Teraz, gdy jesteśmy rozgrzani...
Spróbujmy cofnąć się o parę kroków i zobaczmy, w jakim miejscu jesteśmy. Mamy techniki do
opisania co-system-robi, w których brakuje jawnej specyfikacji zachowania: tradycyjnych wyma-
gań, list własności i opowieści użytkownika (wykorzystywanych bez testów akceptacyjnych).
Mamy również mechanizm osób i scenariuszy, które opisują zachowania, ale które ograniczają
się tylko do kilku specyficznych przykładów. Pozostałą część zachowania pozostawiono wy-
obraźni programisty. Narracje są po prostu opowieściami, które mogą nam dać dobry, wspólny
obraz motywacji. Ale narracji nie można testować, zatem oferują one bardzo niepełny obraz tego,
co system robi.
Prototypy
Być może powinniśmy spróbować zasymulować sytuacje, w których powstają te wymagania.
Prototypy są świetnym sposobem na odkrywanie i testowanie części tego, co robi system. Pro-
totyp można wykorzystać do przetestowania koncepcji interfejsu użytkownika, części funkcjo-
nalności, a nawet wydajności lub technicznej wykonalności. Prototypy architektury również mogą
być bardzo przydatne. Scenorysy to bardzo uniwersalna technika użyteczności. Pierwotnie uży-
wano ich do wspierania projektu, ale równie dobrze służyły sprawdzaniu poprawności założeń
zespołu dotyczących przepływu sterowania dla poszczególnych funkcji systemu. Zespół zaczyna
od scenorysów, których zadaniem jest uchwycenie wizji przepływu pracy użytkownika, aby póź-
niej przystąpić do sprawdzania założeń w rzeczywistym środowisku.
W kierunku podstaw do podejmowania decyzji
Wszystko to są dobre techniki rozgrzewki: pozwalają rozpocząć konwersację, burzę mózgów
i wizjonerstwo. Należy wybrać swoje ulubione i zacząć je stosować — aż będziemy gotowi do
konsolidacji. Cel, jakim jest architektura, wymaga skonsolidowanych danych wejściowych. Kon-
solidacja daje pewność, że odpowiednie osoby podejmą właściwe decyzje we właściwym czasie.
Burza mózgów i wizjonerstwo są zarówno pomo
Pobierz darmowy fragment (pdf)
