Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
01460 015800 13627445 na godz. na dobę w sumie
Architektura Lean w projektach Agile - książka
Architektura Lean w projektach Agile - książka
Autor: , Liczba stron: 320
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-8672-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> agile - programowanie
Porównaj ceny (książka, ebook, audiobook).

Programuj i organizuj kod z metodyką Lean!

Tempo rozwoju aplikacji wymusza stosowanie elastycznych sposobów wytwarzania oprogramowania. Książka ta została poświęcona architekturze Lean, która usprawni ten proces dzięki nowatorskiemu podejściu. Wykorzystaj je i przygotuj swoją aplikację na zmiany funkcjonalne, by użytkownicy mogli w pełni wykorzystać jej potencjał!

W trakcie lektury zapoznasz się z duchem Agile i Lean oraz przydzielisz najważniejsze role członkom projektu. Po tym niezwykle interesującym wstępie rozpoczniesz pasjonującą podróż po świecie architektury Lean. Dowiesz się, czym jest system, jak podzielić projekt na części i wybrać jego styl. W kolejnych rozdziałach zorganizujesz swój kod i przetestujesz zaprojektowaną architekturę. Znajdziesz tu wiele przykładów, które w najlepszy sposób przedstawiają założenia i intencje architektury Lean, z dużym naciskiem na sam kod. To obowiązkowa lektura dla wszystkich programistów i projektantów systemów informatycznych.

Dzięki tej książce:

Twój przewodnik po architekturze Lean!

Znajdź podobne książki Ostatnio czytane w tej kategorii

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)

Gdzie kupić całą publikację:

Architektura Lean w projektach Agile
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: