Oceniajmy wcześnie, oceniajmy często, oceniajmy w sposób ciągły
Projekt Lionheart: do tej pory…
Wzmacnianie architektów w zespole
łatwianie podejmowania decyzji i wspieranie rozwoju umiejętności
Stworzenie możliwości bezpiecznej praktyki
kompetencji projektowych
Działania na rzecz zrozumienia
Działanie 8. Mad lib „punkty widzenia”
Działanie 9. Miara odpowiedzi sofizmatu rozszerzenia
łanie 10. Mapa
16. Działania służące osiągnięciu namacalności projektu . . . .
Działanie 20. Zapisy decyzji architektonicznych
Działanie 21. Architektoniczne haiku
Działanie 22. Diagram kontekstowy
Działanie 23. Lista najpopularniejszych haseł
Działanie 24. Tablica koncepcyjna
Działanie 25. Modularny diagram dekompozycji
Działanie 26. Odrzucone ścieżki
Działanie 27. Prototypowanie w celu zdobycia wiedzy lub podjęcia decyzji
Działanie 28. Diagram sekwencji
łanie 29. Metafora systemowa
17. Działania służące ocenie możliwości projektowych
łanie 30. Briefing architektury
łanie 31. Przegl
Mówi Ipek:
Linie są także obywatelami pierwszej klasy!
Ipek Ozkaya, seniorka w zespole technicznym w Software Engineering Institute w Carnegie Mellon University
Moja praca polega na pomaganiu organizacjom i zespołom w poprawianiu jakości ich systemów z punktu widzenia sprawności ich architektury. Nieuniknioną i oczywistą prośbą w tych działaniach jest „Pokaż mi swoją architekturę”. Przez lata, opierając się na otrzymanych odpowiedziach, opracowałam własny katalog nieporozumień dotyczących architektury i jej tworzenia.
Wydruk wszystkich diagramów sekwencji dla wszystkich scenariuszy użycia, które aż do tej pory pojawiły się w twoich myślach, nie jest twoją architekturą! Chociaż zbiór wszystkich przypadków użycia i ich sposobów zachowania, czyli tego, co umieszczasz w diagramach sekwencji, jest użyteczny i ważny dla twojego systemu, to nie zapewnia on odpowiedniego poziomu abstrakcji dla wnioskowania o wariantach zachowania systemu.
Przegląd kodu nie może zastąpić przeglądu architektury! Najważniejszy cel każdej pracy związanej z architekturą to zaprojektowanie i wdrożenie systemu spełniającego cele biznesowe i cele interesariuszy. Działający kod jest nieuchronną rzeczywistością. Jednak potrzeby architektoniczne przecinają się z wieloma elementami w zaimplementowanym systemie. Efektywny przegląd architektur y wiąże się z tymi wymaganiami istotnymi dla architektury oraz wszystkimi elementami, których dotyczą. Tradycyjne praktyki sprawdzania kodu nie obejmują tej całościowej perspektywy.
Pudełka nie są jedynymi elementami architektonicznymi! W przypadkach gdy zespół ma artefakt, często nazywany dokumentacją architektury oprogramowania, i niestety nazywany również SAD, to zawiera on opisy rysunków ad hoc składających się z linii i pudełek. To świetny początek, ale długie dyskusje koncentrują się na pudełkach, podczas gdy linie bywają całkowicie zapomniane. To niefortunne, ponieważ w wielu przypadkach linie opisują najważniejsze aspekty decyzji architektonicznych.
Spośród tych trzech nieporozumień najważniejsze to docenienie znaczenia linii na diagramach architektury oprogramowania. Pomyśl o tym. Jeśli chcesz zwiększyć wydajność, skup się na częstości i ilości połączeń między elementami. Jeśli chcesz poprawić łatwość modyfikowania, ogranicz interakcje między elementami. Jeśli chcesz zoptymalizować bezpieczeństwo, chroń relacje między elementami. Wszystko to reprezentują linie!
Rozdział 2. Podstawy myślenia projektowego • 18
Oto cztery reguły projektowania:
1. Reguła ludzka (ang. Human rule). Cały projekt ma charakter społecznościowy.
2. Reguła niejednoznaczności (ang. Ambiguity rule). Zachowajmy niejednoznaczność
3. Reguła przeprojektowywania (ang. Redesign rule). Cały projekt to przeprojektowanie.
4. Reguła namacalności (ang. Tangibility rule). Uczyńmy pomysły namacalnymi dla ułatwienia komunikacji.
Będziemy używać akronimu HART (ang. human, ambiguity, redesign, tangibility), aby pomóc zapamiętać te zasady. Przyjrzyjmy się zasadom HART w tym zakresie, w jakim odnoszą się one do projektowania architektury oprogramowania, dzięki czemu możemy zobaczyć, jak zastosować myślenie projektowe w kontekście tego typu systemów.
Projektowanie dla ludzi
Projekt jest przedsięwzięciem skoncentrowanym na człowieku. Projektujemy oprogramowanie dla ludzi. Projektujemy oprogramowanie z ludźmi. Każda decyzja projektowa w architekturze w jakiś sposób pomaga osobom. Zarazem każda taka decyzja musi być zrozumiana i udostępniona innym osobom.
Architekci muszą wczuć się we wszystkich interesariuszy. Trzeba dbać o użytkowników końcowych tak samo jak o ludzi, którym pomagają użytkownicy końcowi, programistów, którzy piszą kod, testerów, którzy go weryfikują, a nawet menedżerów, którzy pilnują harmonogramu projektu. Gdy projektujemy system oprogramowania, będziemy współpracować z pozostałymi osobami z naszego zespołu i okazywać szacunek, słuchając ich, zakładając pozytywne intencje oraz stosując metody projektowania ukierunkowane na człowieka.
Reguła ludzka przypomina również, że architekci nie są oddzieleni od zespołów. Współpracujemy bezpośrednio z nimi, aby wspólnie projektować architekturę. Budowanie oprogramowania to intensywna aktywność społeczna. Idea architekta w wieży z kości słoniowej, który projektuje architekturę izolowany od zespołu, jest mitem. Architekci oprogramowania stanowią integralną część każdego zespołu. Oddzielenie architekta od zespołu odcina połączenie między architektem a wszystkimi, których architektura będzie dotyczyć
Empatia w stosunku do ludzi, którzy bezpo ś rednio i po ś rednio wchodz ą w interakcję z architekturą, czyni nas lepszym projektantem, komunikatorem i liderem.
Mapa empatii
Przeprowadzanie burzy mózgów i zapisywanie odpowiedzialności, myśli i uczuć poszczególnych interesariuszy, aby pomóc zespołowi rozwinąć większe poczucie empatii z celami interesariuszy.
Korzyści
• Odkrycie potrzeb odbiorców przed opracowaniem opisu architektury.
• Pomoc w decyzji, jakie informacje uwzględnić lub wykluczyć.
• Utworzenie skali osiągnięć do oceny skuteczności opisu architektury.
Czas trwania działania
10–30 minut.
Uczestnicy
Architekt oprogramowania, zespół programistów.
Małe grupy 3–5 osób lub ćwiczenie indywidualne.
Przygotowanie i materiały
• Przed rozpoczęciem działania wybierzmy, którzy interesariusze, systemy lub użytkownicy będą głównym tematem działania.
• Papier do flipcharta lub biała tablica, markery i karteczki samoprzylepne.
• To działanie może zostać dostosowane do rozproszonych uczestników dzięki udostępnieniu ekranu lub oprogramowania do zdalnej współpracy.
Kroki
1. Rysujemy siatkę na białej tablicy lub papierze. Oznaczamy każdy kwadrant – wykonywanie, przygotowywanie, mówienie i myślenie.
2. Wybieramy określonego interesariusza i wpisujemy jego nazwę w środku.
3. Wybrany interesariusz wykonuje zadania zwi ą zane z burz ą mózgów, przygotowuje artefakty, mówi o różnych rzeczach i może mieć uczucia.
4. Zapisujemy każdą ideę na karteczce i umieszczamy ją w odpowiednim kwadrancie.
5. Przeglądamy mapę empatii i podkreślamy spostrzeżenia.
Wskazówki i podpowiedzi
• Bądźmy konkretni. Wybierzmy osobę, z którą można odczuwać empatię, a nie ogólną rolę.
• Weryfikujmy wyniki mapy empatii z interesariuszami.
• Wyszczególnijmy atrybuty jakościowe, ryzyka lub inne potrzeby, które ta osoba może uznać za istotne.
• Zastosujmy tę metodę do zrozumienia użytkowników końcowych aplikacji, systemów zewnętrznych (do projektowania interfejsu) lub do przedstawicieli interesariuszy w celu zrozumienia atrybutów jakościowych.
• Gdy uczestnicy są rozproszeni, korzystajmy z oprogramowania typu Mural1.
Przykład
Przykładowa mapa empatii dla interesariusza będącego deweloperem jest przedstawiona na stronie 211.
Warianty
Kwadranty na mapie empatii można zmienić. Inny typowy schemat to: słyszenie, widzenie, wykonywanie (lub mówienie) i myślenie (lub czucie).
Mapy empatii są również przydatne do analizy atrybutów jakościowych2. To podejście jest szczególnie przydatne, gdy interesariusze nie są w stanie uczestniczyć w innych warsztatach, takich jak Działanie 7. Miniwarsztaty atrybutów jakościowych na stronie 224. Zamiast skupiać się na tym, co interesariusze robią lub o czym myślą, skupiamy się na tym, jak reagują na określone atrybuty jakościowe. Oczywiście, lepiej zapytać interesariuszy bezpośrednio. Kiedy nie są dostępni, jest to dobry zamiennik.
1 https://mural.co/
2 Thijmen de Gooijer. Quality Requirements on a Shoestring. SATURN 2015. http://resources.sei. cmu.edu/library/asset-view.cfm?assetID=436426