11 zasad projektowania architektury oprogramowania - ebook

OPRACOWYWANIE STRATEGII PROJEKTOWANIA

Projektowanie architektury oprogramowania zawsze wydaje się nieco chaotyczne. Mimo zawirowań i niepewności, które dotyczą każdego systemu oprogramowania, ważne jest, aby mieć plan. Dzięki solidnej strategii projektowania możemy przejść drogą, pokonując mgiełkę niepewności.

Myślenie projektowe jest idealne do znajdowania rozwiązań złożonych problemów. Zamiast próbować skutecznie rozwiązać problem od razu przy pierwszej próbie, myślenie projektowe kładzie nacisk na uczenie się i eksperymentowanie. Testowanie architektury może się nie udać bez jej implementacji, ale można weryfikować elementy architektury przyrostowo w miarę ich projektowania. Mamy możliwość użycia nastawień projektowych oraz cyklu myślenie–robienie–sprawdzanie, aby zdecydować, na czym w kolejnym kroku skupić naszą uwagę.

W tym e-booku nauczymy się wybierać nastawienia projektowe jako część szerszej strategii projektowania, myśląc o zagrożeniach w systemie oprogramowania.

Poszukiwanie satysfakcjonującego projektu

W racjonalnym świecie problem byłby przez nas w pełni zidentyfikowany, zanim zaprojektowalibyśmy idealną architekturę, która by go rozwiązywała. Szkoda, że nie żyjemy w idealnym, racjonalnym świecie. W _The Sciences of the Artificial _ Herbert Simon ukuł termin _ograniczonej racjonalności_, aby opisać teoretyczną barierę stworzoną przez ograniczenia czasu, pieniędzy, umiejętności i wiedzy, które sprawiają, że racjonalne projektowanie stanowi wyzwanie dla złożonych problemów, takich jak architektura oprogramowania.

Zamiast racjonalnie poszukiwać optymalnego projektu, staramy się znaleźć architekturę, która jest _satysfakcjonująca_. Satysfakcjonujący projekt jest także wystarczający – wystarczająco dobry – dla naszych potrzeb.

Zamiast myśleć o architekturze oprogramowania jako o problemie optymalizacji projektu, będziemy szukać satysfakcjonującego projektu, podkreślając następujące działania.

Traktowanie rozwiązań jako eksperymentów. Architekci nie są wszechwiedzącymi mędrcami technologii. Potraktujmy każde potencjalne rozwiązanie jako eksperyment do sprawdzenia. Im wcześniej, szybciej i taniej będziemy mogli potwierdzić (lub unieważnić) nasze hipotezy, tym wcześniej znajdziemy właściwą kombinację struktur, które pomogą naszym interesariuszom, oraz tym szybciej nasi interesariusze zyskają na naszych projektach.

Koncentracja na zmniejszaniu ryzyka. Wartość to tylko jedna zmienna, którą należy wziąć pod uwagę. Architektura jest podstawą systemu oprogramowania. Jeśli ona zawiedzie, to zawiedzie wszystko. Architekci muszą wciąż martwić się, co może pójść źle i projektować tak, aby brać pod uwagę takie scenariusze. Możemy wykorzystać ryzyko, aby pomogło nam zdecydować, na czym mamy się następnie koncentrować.

Działania w celu uproszczenia problemów. Proste problemy często mają proste rozwiązania. Istnieje wiele sposobów na uproszczenie problemu. Zmniejszenie liczby zainteresowanych stron zmniejszy różnorodność konkurencyjnych perspektyw, które wpływają na system. Dodawanie lub usuwanie ograniczeń albo też skupianie się na fragmencie problemu może zmniejszyć jego złożoność. Identyfikacja _typowych problemów_ ułatwia skupienie się na przeprojektowywaniu. Typowe problemy mają znane rozwiązania, dlatego możemy zacząć od katalogów ze wzorcami i wykorzystywać nasze zbiorowe doświadczenie podczas poszukiwania rozwiązań.

Szybkie iteracje to szybka nauka. Im szybciej się uczymy, tym więcej możemy odkryć i tym więcej zaufania mamy do naszych rozwiązań. Jeśli się mylimy, dowiedzmy się tego tak szybko, jak to możliwe. Szybki upadek oznacza szybką naukę. Preferujmy krótkie, mocno skonkretyzowane iteracje projektowe z konkretnymi wynikami zamiast długich iteracji projektowych, które koncentrują się wyłącznie na abstrakcyjnych celach.

Myślenie w tym samym czasie o problemie i rozwiązaniu. W _Notes on the Synthesis of Form _ Christopher Alexander pokazuje, że problemy są zawsze definiowane z myślą o rozwiązaniu. Granicę wokół problemu tworzą te rozwiązania, które mogłyby go rozwikłać. Aby zrozumieć problem, musimy odkrywać rozwiązania. Aby lepiej je przeanalizować, musimy uzupełnić naszą wiedzę na temat problemu. Projektowanie architektury oprogramowania wymaga jednoczesnego myślenia o problemach i rozwiązaniach. Pisanie kodu na wczesnym etapie projektowania jest jedną ze strategii radzenia sobie z wzajemnym związkiem między problemami i rozwiązaniami.

Unikanie racjonalnego projektowania nie oznacza, że nagle stajemy się irracjonalnymi architektami. Architektura jest podstawą każdego systemu oprogramowania, zatem nadal potrzebujemy wykonać pewne prace projektowe z góry. Musimy zdecydować, jaką część architektury zaprojektujemy z góry i jak duża powstanie wraz z upływem czasu. Wczesne wybranie strategii projektowania w życiu systemu oprogramowania powie naszemu zespołowi, jak chcemy rozwijać architekturę i wzbudzi zaufanie u naszych interesariuszy.

Decydowanie, ile zaprojektować na początku

Architektura jest niezbędną inwestycją. Każdy system oprogramowania ma architekturę. Tak czy inaczej, jej projektowanie zajmie nam ileś czasu. Jeśli na początku zajmiemy się projektowaniem architektury, to zmniejszymy koszty przyszłych przeróbek. Oczywiście, planowanie architektury opóźni również wdrożenie, a potencjalnie opóźni rezultat dla interesariuszy. Jeśli na początku nie poświęcimy czasu na architekturę, to z dużym prawdopodobieństwem będziemy musieli wprowadzić zmiany w architekturze po opracowaniu części oprogramowania.

W zależności od wielkości systemu oprogramowania i jego wymagań każdy system oprogramowania ma _projektowy złoty środek_, optymalną ilość czasu przeznaczoną na zaprojektowanie architektury przed zajęciem się implementacją.

Znajdowanie projektowego złotego środka

W _Architecting: How Much and When? _ Barry Boehm pokazuje nam, że połączenie czasu tworzenia, planowania architektury i przeróbek to główne czynniki wpływające na ogólny harmonogram projektu. Przeróbki obejmują czynności, takie jak usuwanie usterek projektowych, przepisywanie kodu i naprawianie błędów. Aby znaleźć złoty środek, musimy wziąć pod uwagę zarówno koszty projektu, jak i nieuniknione poprawki wymagane do ukończenia całości systemu.

Architektoniczny złoty środek jest w znacznym stopniu zależny od wielkości, zmienności wymagań i złożoności tworzonego oprogramowania. Wykres na stronie 7 na podstawie _Boehm’s data _ pokazuje, jak zmniejsza się liczba przeróbek, gdy więcej czasu poświęca się na planowanie architektury. Ciągła zielona linia reprezentuje sumę wysiłków włożonych w projekt architektury (niebieska przerywana linia) oraz kosztów przeróbek (przerywana pomarańczowa linia).

W tym przypadku poświęcenie mniej niż około 20% pierwotnego harmonogramu projektu na architekturę będzie skutkować zmniejszeniem korzyści. Mniejsza liczba błędów spowodowana zbyt dużymi inwestycjami w architekturę będzie także powodować wydłużenie całkowitego harmonogramu projektu. I analogicznie – poświęcenie zbyt mało czasu na architekturę spowoduje zwiększenie liczby przeróbek, co również da dłuższy ogólny harmonogram projektu.

W tych samych badaniach Boehm pokazuje również, w jaki sposób zmienia się złoty środek w zależności od szacowanej wielkości systemu oprogramowania. Skorzystajmy z tych danych, aby zdecydować, czy ilość czasu, który planujemy poświęcić na wstępny projekt architektury, znajduje się we właściwym zakresie.

Wykres na stronie 8 zawiera istotne implikacje, przeanalizujmy zatem jego zasadnicze punkty.

Im większy system oprogramowania, tym większe korzyści, jakie uzyskamy dzięki zaprojektowaniu architektury na początku. Z badań przeprowadzonych przez Boehma wynika, że rozsądną decyzją byłoby poświęcenie 37% całkowitego szacunkowego harmonogramu prac na zaprojektowanie architektury dla dużych (10 000 KSLOC, gdzie KSLOC odpowiada tysiącowi źródłowych linii kodu) systemów software’owych.

Mniejsze (10 KSLOC) systemy oprogramowania niewiele zyskują na planowaniu architektury na początku. Z badań Boehma wynika, że zaledwie 5% całkowitego szacunkowego harmonogramu powinno zostać przeznaczone na początkowy projekt architektury. W niektórych przypadkach szybsze może być przepisanie małego oprogramowania niż poświęcenie znacznej ilości czasu na zaprojektowanie architektury z góry.

Możemy porządnie oberwać, jeśli zainwestujemy zbyt mało w projektowanie architektury. Unikanie projektu architektury na początkowym etapie w mniejszych systemach oprogramowania może być bardziej opłacalne i skutkować krótszym ogólnym harmonogramem, ale przeróbki będą nadal konieczne. Przygotujmy się na to i uwzględnijmy w swoich planach gruntowne zmiany projektu. Przy niewystarczających początkowych nakładach na projekt architektury bardziej narażone na to będą większe systemy.

Im więcej zainwestujemy w architekturę, tym mniej przeróbek będzie trzeba dokonać. Planowanie architektury pomaga unikać błędów. Jeśli preferujemy raczej przewidywalne niż efektywne harmonogramy projektów, pomoże nam przeznaczenie większych nakładów na początkowy plan nawet w przypadku mniejszych systemów. Wstępne planowanie jest koniecznością w większych systemach oprogramowania.

Rozmiar to dobry predyktor, ponieważ można go łatwo zmierzyć lub oszacować, ale _wiele zespołów stosuje również złożoność _, aby zdecydować, ile architektonicznej pracy może być wymagane. Duże systemy mogą być złożone, ale nie wszystkie złożone systemy są duże. Jeśli rozwiązanie jest rutynowe, zespołowi może się udać z mniejszymi nakładami planistycznymi, nawet jeśli to duży system.

Kolejnym czynnikiem, który należy wziąć pod uwagę, jest zmienność wymagań. Zmiany w fundamentalnych wymaganiach architektonicznych mogą przekreślić nawet najlepiej stworzone plany. Jeśli spodziewamy się znaczących zmian, opóźnijmy podejmowanie wiążących decyzji i skoncentrujmy się na użyciu mniej obciążających metod projektowania i dokumentowania.

Przykład: wpływ architektury na całkowity harmonogram

Załóżmy, że tworzymy system oprogramowania o szacunkowej wielkości 100 KSLOC z początkowym harmonogramem części deweloperskiej obejmującym 100 dni. Zgodnie z danymi Boehma, gdybyśmy poświęcili dodatkowo 5% tego czasu na architekturę, wtedy całkowity harmonogram projektu wydłużyłby się o około 43%. Gdybyśmy zarezerwowali trochę więcej czasu na architekturę, powiedzmy 17% szacowanego harmonogramu części deweloperskiej, wtedy całkowity harmonogram projektu wydłużyłby się tylko o 38%.

Oczywiście więcej architektury nie zawsze oznacza, że będziemy mieli krótszy harmonogram. Gdybyśmy przeznaczyli dodatkowo jedną trzecią szacowanego czasu części deweloperskiej na architekturę, spowodowalibyśmy wydłużenie całkowitego harmonogramu. Nawet gdyby w ten sposób czas przeznaczony na poprawki został bardzo znacząco zmniejszony, poświęcenie dodatkowego czasu na architekturę nie opłacałoby się, ponieważ ogólny czas projektu wzrósłby o około 40%.

Oto zestawienie przy założeniu, że nasz szacowany początkowy harmonogram części deweloperskiej wynosi 100 dni:

----------------------------------------- -------------------------------------- ------------------------------------
LICZBA DNI POŚWIĘCONYCH NA ARCHITEKTURĘ LICZBA DNI POŚWIĘCONYCH NA PRZERÓBKI LICZBA DNI W ŁĄCZNYM HARMONOGRAMIE
5 38 143
17 21 138
33 7 140
----------------------------------------- -------------------------------------- ------------------------------------

Constructive Systems Engineering Model (COSYSMO) zawiera wyniki Boehma. Sugerujemy wypróbowanie narzędzi COSYSMO i COCOMO II na danych z naszego projektu¹.

Dzięki badaniom Boehma mamy ogólne pojęcie, ile czasu poświęcić na projektowanie architektury, ale wciąż nie wiemy, kiedy wykonać prace projektowe lub kiedy przyjąć poszczególne nastawienia do projektu. Okazuje się, że Boehm również na to ma odpowiedź (tak, on jest niesamowity). W _Using Risk to Balance Agile and Plan-Driven Methods _, Barry Boehm i Richard Turner proponują wykorzystanie ryzyka, aby zdecydować, kiedy skupić się na architekturze. Jeśli myślimy o ryzyku we właściwy sposób, możemy również użyć go do określenia, co zaprojektować i jak zaangażować zainteresowane strony w proces projektowania.

Niech ryzyko będzie naszym przewodnikiem

Krótko po pierwszym spotkaniu z interesariuszami dotyczącym nowego projektu zawsze czuję, jak ściska mnie w żołądku. Gdybym nie miał tego uczucia, byłbym zmartwiony. Tworzenie oprogramowania zawsze wiąże się z ryzykiem. _Powinniśmy_ czuć się trochę niekomfortowo na początku nowego projektu. W końcu, gdybyśmy od początku wszystko wiedzieli i nie mielibyśmy żadnych pytań na temat tego, co mamy budować, to do czego potrzebny byłby architekt?

Możemy wykorzystać to lekkie uczucie zaniepokojenia. Ryzyko jest doskonałym wskaźnikiem tego, co może nam przeszkodzić w osiągnięciu sukcesu. Wykorzystajmy ten niepokój i zapiszmy wszystko to, co martwi nas w nowym systemie. Następnie nadajmy priorytety pozycjom na liście, aby rzeczy, które mogą sprawić najwięcej problemów, były na niej najwyżej. Na koniec wybierzmy jedną z rzeczy, o które najbardziej się martwimy, a potem nastawienie projektowe, aby zmniejszyć to ryzyko.

Ściskanie w żołądku to dobry początek, ale to nie wystarczy, abyśmy mogli iść naprzód. Nie wiem jak wy, ale ja nie znoszę chodzić do mojego szefa z bólem brzucha. _Cześć, Will, nie jestem pewien, czy to przez burrito, które zjadłem, czy co, ale mam złe przeczucia, jak ten system będzie się skalował, kiedy dodamy dane_. Niepokój w żołądku mówi nam, że coś idzie źle, ale możemy zrobić o wiele więcej, niż tylko wsłuchiwać się we własne wnętrzności.

Identyfikowanie stanów i konsekwencji

Ryzyko jest czymś złym, co może się wydarzyć w przyszłości. Jeśli już to się stało, nazywa się to problemem. Jeśli zaczyna się od _a co, jeśli_… to jest czysta spekulacja. Moglibyśmy używać _a co, jeśli…_ przez cały dzień i nigdy nie zbliżylibyśmy się do projektowania użytecznej architektury. Zamiast spekulować, wykorzystamy to, co wiemy dzisiaj na temat architektury, aby pomogło nam zdecydować, co zaprojektować dalej.

Ryzyko składa się z dwóch części. _Stan_ to fakt dotyczący świata, obecnie prawdziwy. _Konsekwencja_ to coś złego, co może się wydarzyć w przyszłości jako bezpośredni skutek tego stanu. Zapisujemy informacje o ryzyku, stosując prosty szablon z _A Construct for Describing Software Development Risks , ; może mieć ._

Oto zapis ryzyka w formacie stan–konsekwencja.

Istnieje wiele sposobów na zmniejszenie lub wyeliminowanie tego ryzyka:

• Zmniejszenie prawdopodobieństwa. Wynajmijmy catering, aby dostarczano jedzenie przez kilka dni w tygodniu oraz zorganizujmy sesję informacyjną na temat wyboru odpowiednich porcji posiłków. Zmniejszanie oddziaływania. Przechowujmy w biurze zapas leków zobojętniających kwas żołądkowy.

• Przesuwanie ram czasowych ryzyka. Zaplanujmy spotkania podczas lunchu, aby ludzie mogli jeść burrito tylko na kolację.

• Usuwanie stanu. Przenieśmy biuro do nowej lokalizacji. Zmieńmy harmonogram zmian, aby wszyscy pracowali w nocy, gdy nowa restauracja będzie zamknięta.

• Zaakceptujmy to i nic nie róbmy. Czasami ludzie jedzą zbyt wiele burrito (_mniam… guacamole_). Poradzimy sobie z konsekwencjami, jeśli ryzyko przekształci się w problem.

------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------
NEGATYWNE STWIERDZENIE O RYZYKU DLACZEGO JEST NEGATYWNE
Została otwarta nowa restauracja z burrito. No i co z tego? Negatywne skutki są niejasne. W rzeczywistości brzmi świetnie. Kochamy burrito!
Zespół może przesadzić z burrito. To brzmi źle, ale dlaczego mielibyśmy się tym teraz martwić?
Jedzenie zbyt dużej ilości burrito może spowodować nudności. To prawda, ale co to ma wspólnego z naszym zespołem?
Jeśli kolega lub koleżanka z zespołu zje zbyt wiele burrito, będzie chorować. A jeśli radioaktywny meteoryt spadnie na biuro, to też będziemy chorować. To dlaczego martwimy się o burrito?
------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------

Znajomość stanu i konsekwencji tworzy punkty zaczepienia w celu podjęcia decyzji, co zrobić z ryzykiem. Porównajmy nasze ryzyko ; może mieć z innymi, mniej efektywnymi opisami dotyczącymi ryzyka.

OK, wystarczy już o burrito. Wróćmy do projektowania oprogramowania.

Używanie ryzyka do wyboru nastawienia projektowego

Projektowanie architektury oprogramowania jest ograniczaniem ryzyka. Za każdym razem, gdy myślimy, że _mamy złe przeczucia co do tego_, to znak, że w pobliżu czai się ryzyko. Jeśli potrafimy wybrać stan i konsekwencje oddające istotę naszych złych przeczuć, to możemy wykorzystać te informacje do kierowania naszymi działaniami projektowymi.

Oto przykładowe ryzyka pochodzące z poprzedniego projektu, nad którym pracowałem, oraz działania projektowe, które zespół wykorzystał do ich zmniejszenia:

Usługa Model Training została oryginalnie zbudowana w innym celu; może zostać przeciążona nowymi żądaniami.

Nastawienia projektowe: rozumienie, ocenianie.

Co zrobiliśmy: porozmawialiśmy z zespołem, który zbudował usługę Model Training, przeprowadziliśmy eksperymenty, aby zmierzyć wydajność.

Przetwarzanie danych jest czasochłonne i wymaga dużego nakładu zasobów; może nie być w stanie zakończyć przetwarzania zadań bez awarii.

Nastawienia projektowe: badanie.

Co zrobiliśmy: zastosowaliśmy burzę mózgów w celu wsparcia niezawodności, zbadaliśmy schematy planowania zadań i nakreśliliśmy alternatywne schematy, które mogą skrócić czas przetwarzania.

Do opracowania statystycznie istotnego modelu potrzebna jest duża ilość danych; może to być nieopłacalne z powodu kosztów przechowywania danych na dużą skalę.

Nastawienie projektowe: wykonywanie.

Co zrobiliśmy: stworzyliśmy model szacowania kosztów. Model wykazał dla interesariuszy zalety i wady różnych opcji projektowych. Wyeliminował ramy czasowe ryzyka, zmieniając priorytety zaległości.

Przechowywane dane mogą zawierać wrażliwe informacje o klientach; mogą wymagać ściślejszej ochrony, niż możemy ją zapewnić.

Nastawienie projektowe: ocenianie.

Co zrobiliśmy: oceniliśmy dostępne platformy obliczeniowe na podstawie tego, jak dobrze każda spełniłaby nasze potrzeby.

Inżynieria ryzyka pomaga nam zdecydować, co zaprojektować. Nastawienia projektowe pomagają nam opracować strategię zmniejszania ryzyka. W obliczu konieczności zmniejszenia ryzyka najpierw zdecydujmy, które jego elementy możemy zidentyfikować – stan, wpływ, prawdopodobieństwo lub ramy czasowe. Następnie wybierzmy nastawienie projektowe. Oto kilka pytań. Pomagają one zdecydować, które nastawienie projektowe może być odpowiednie:

Ryzyko to GPS dla naszego procesu projektowania. Mówi nam, gdzie jesteśmy, dokąd zmierzamy i ile pozostało nam do zaprojektowania. W każdej pętli cyklu myślenie–robienie–sprawdzanie musimy myśleć o zagrożeniach i wykorzystywać je, aby zdecydować, co dalej.

---------------------------- -------------------------------------------------------------------------------------------------------------------------------------
SPRÓBUJMY… JEŚLI…
nastawienie na zrozumienie ryzyko dotyczy problemu. Czy potrzebujemy lepszego zrozumienia interesariuszy lub innych aktorów w systemie?
nastawienie na badanie ryzyko jest związane z rozwiązaniem. Czy widzieliśmy wystarczająco dużo alternatywnych rozwiązań?
nastawienie na tworzenie ryzyko dotyczy komunikacji. Czy interesariusze w pełni rozumieją koncepcje projektowe w działaniu i czy mogą zobaczyć architekturę?
nastawienie na ocenianie ryzyko wiąże się z decyzją projektową lub ogólnym dopasowaniem projektu. Czy musimy podjąć decyzję projektową?
---------------------------- -------------------------------------------------------------------------------------------------------------------------------------

Przejście do projektowania pasywnego po zmniejszeniu ryzyka

W _Just Enough Software Architecture: A Risk-Driven Approach _, George Fairbanks mówi nam, że architekci powinni dążyć do zmniejszenia ryzyk technologicznych do momentu, w którym architektura przestaje być największym źródłem ryzyka w systemie. Kiedy już zredukujemy wystarczająco ryzyko architektoniczne, cokolwiek to oznacza dla systemu oprogramowania, wtedy nasz czas lepiej poświęcić na coś innego.

Gdy architektura nie jest już największym źródłem ryzyka w systemie, przejdźmy od _projektowania aktywnego_ do _projektowania pasywnego_, jak pokazano na wykresie na stronie 13. W projektowaniu aktywnym kierujemy procesem projektowania w celu dążenia do zmniejszenia ryzyka. W projektowaniu pasywnym obserwujemy architekturę funkcjonującą w działającym systemie i w razie potrzeby podejmujemy działania naprawcze.

Nie dajmy się zwieść nazwie. W projektowaniu pasywnym jest nadal wiele do zrobienia dla architekta. Możemy poprawić błędną dokumentację lub stworzyć brakujące dokumenty. Wprowadzamy drobne poprawki w architekturze w miarę pojawiania się nowych informacji. Przekazujemy wiedzę o architekturze kolegom z zespołu, łącząc się w pary i przeglądając kod. A co najważniejsze, jesteśmy na pierwszej linii frontu w walce z erozją architektury i innymi kwestiami omówionymi na stronie 147.

Nawet przy zachowaniu dużej czujności architektura może stać się znaczącym ryzykiem. Mogą pojawić się nowe zagrożenia. Wdrożony system może zbytnio odbiegać od naszych planów. Możemy zorientować się, że nasze założenia dotyczące świata są błędne lub że świat wokół nas się zmienił. Kiedy to się stanie, przełączmy się z powrotem na projektowanie aktywne i dostosujmy architekturę, opierając się na nowych realiach.

Teraz, gdy już wiemy, jak używać ryzyka w celu decydowania, co zaprojektować, zbierzmy wszystko to, czego się nauczyliśmy w tym rozdziale, opracowując plan projektowania architektury.

Tworzenie planu projektowania

Plany projektowania określają ogólną strategię – ile czasu i w jaki sposób zespół ma poświęcić go na architekturę. Czy przeprowadzimy więcej analiz na początku? Czy spodziewamy się zmiany w późniejszym czasie? Kiedy zaczynamy pisać kod? Dobry plan projektowania określa oczekiwania i wyjaśnia te szczegóły.

Plan projektowania nie musi być formalnym harmonogramem, ale trzeba w to włożyć trochę przemyśleń. Oto kilka rzeczy, które powinien zawierać plan projektowania: zapiszmy nasz plan w prostym dokumencie, na poziomie tablicy koncepcyjnej.

Warunki przerwania projektowania. Czy zajmiemy się projektowaniem z wyprzedzeniem, czy będziemy zmniejszać ryzyko bez względu na to, jak długo to potrwa? Czy naszkicujemy minimalny wstępny projekt przed rozpoczęciem pisania kodu, czy będziemy chcieli poświęcić więcej na architekturę? Czy implementacja może zacząć się fragmentarycznie, czy też niektóre obszary trzeba będzie zacząć razem? Nie ma jednej prawidłowej odpowiedzi. Warunki przerwania projektowania zależą w dużej mierze od zespołu, interesariuszy i kontekstu projektu.

Wymagane artefakty projektowe. Powiedzmy wszystkim, jak planujemy udokumentować architekturę, zanim rozpoczniemy. Czy dobrze czujemy się z obrazkami na białych tablicach, czy potrzebujemy bardziej tradycyjnego dokumentu? Czy nasz zespół używa określonych szablonów? Gdzie powinny być przechowywane artefakty projektowe?

Oś czasu. Opiszmy kluczowe etapy w harmonogramie projektu. Wiele dużych projektów ma odrębną fazę opracowywania w celu zbierania wymagań i eksplorowania architektury. Mniejsze projekty lub nieprzerwanie utrzymywane systemy oprogramowania mogą regularnie planować szybkie implementacje, czyli prototypy, które ewentualnie zostaną ostatecznie porzucone (tzw. spike).

Na osi czasu powinny być zaznaczone kluczowe etapy w celu przeglądu wymagań architektonicznych, przeglądu szkiców projektów i przeprowadzania ocen. Uwzględnijmy również wszelkie ważne warsztaty z udziałem zainteresowanych stron. Określmy, kiedy spodziewamy się, że rozpocznie się implementacja oraz co znajdzie się w jej początkowej fazie.

Najważniejsze ryzyka. Od kiedy używamy podejścia projektowego opartego na ryzyku, uwzględnijmy jako kontekst najważniejsze zagrożenia w planie projektu. Ponownie sprawdźmy naszą listę zagrożeń dotyczących całego życia systemu oprogramowania, a zwłaszcza w początkowym projekcie.

Projekt hipotetycznej architektury. Zacznijmy od potencjalnego rozwiązania. Przypomnijmy sobie, że musimy pomyśleć o rozwiązaniu, które pomoże nam zdefiniować problem. Hipotetyczna architektura może być prostym szkicem, wystarczającym do przekazania treści pierwszych zamierzeń projektowych.

Ilość czasu poświęcanego na projektowanie może wynosić kilka godzin, dni lub nawet miesięcy w zależności od systemu oprogramowania. Bez względu na horyzont czasowy, jeśli zastosujemy cztery zasady myślenia projektowego i skupimy się na znalezieniu satysfakcjonującego rozwiązania przedyskutowanego na stronie 4, powinniśmy dojść do działającego rozwiązania w czasie, jaki mamy do dyspozycji.

Projekt Lionheart: do tej pory…

W przyszłym tygodniu zbierzemy wymagania od burmistrza i innych interesariuszy. Mamy ustaloną ostateczną datę przekazania całości za około sześć miesięcy. Musimy skoncentrować się na początkowych oczekiwaniach i dostarczać wymagane wartości tak szybko, jak to możliwe. Wydaje się również, że podstawowe wymagania funkcjonalne będą oparte na istniejącym procesie, więc jest małe prawdopodobieństwo, że ulegną zmianie.

Rozwiązanie wydaje się klasyczną, opartą na danych aplikacją webową z dodatkowymi funkcjami wyszukiwania. Zgodnie z opisem burmistrza kluczową sprawą może okazać się bezpieczeństwo i prywatność. Wiemy również, że dział informatyczny miasta przejmie od nas system. Ta grupa może nałożyć pewne wyjątkowe ograniczenia.

Wysyłamy do burmistrza van Damme’a program wizyty na miejscu. Naszym największym zagrożeniom można chwilowo zaradzić, poszukując odpowiednich informacji, zatem na razie skoncentrujmy się na poznawaniu naszych interesariuszy. Wydaje się, że możemy rozpocząć od prostego projektu wstępnego, aby skoncentrować się na szybszym dostarczaniu wartości, nawet jeśli oznacza to przepisanie części aplikacji później. Zespół chce rozpocząć pisanie kodu natychmiast po dwutygodniowym projektowym spike’u.

Co dalej

Tak czy inaczej, zapłacimy za architekturę albo z powodu wstępnego projektu, albo ze względu na późniejsze poprawki. W tym rozdziale nauczyliśmy się, jak używać ryzyka do planowania naszych działań projektowych. Ryzyko może pomóc nam zdecydować, ile pracy należy wykonać na samym początku. Możemy również wykorzystać ryzyko, aby zdecydować, które z założeń projektowych przyjąć.

Jedno z pierwszych zagrożeń, z którymi wiele zespołów boryka się w nowym systemie oprogramowania, nawet jeśli jest on nowy tylko dla nas, to zrozumienie, komu oprogramowanie ma pomóc. W następnym rozdziale dowiemy się, w jaki sposób zastosować nastawienie na zrozumienie, rozwijając empatię wobec ludzi, którzy korzystają z rozwijanego oprogramowania. Kiedy będzie można wczuć się w rolę interesariuszy, uzyskamy głębsze zrozumienie ich rzeczywistych potrzeb, a to zwiększy szansę na rozwiązanie właściwego problemu.