B. Bereza - Oszacowanie kosztów i korzyści metod zwinnych opis gry symulacyjnej

Transkrypt

1 Gra symulacyjna opis Gra i następujące w niej wydarzenia służą doświadczeniu, w symulowanej, żartobliwej i zapadającej mamy nadzieję - w pamięć formie, w skoncentrowanej postaci, pewnych realnych zjawisk i zagadnień, w celu projektowania oraz dyskutowania możliwych rozwiązań dla występujących sytuacji, w zakresie odnoszącym się do tematyki warsztatu: szacowania kosztów i korzyści metod zwinnych. Gra nie jest odzwierciedleniem przebiegu rzeczywistego ani nawet możliwego projektu, ani wzorcem projektu kolejność następujących w niej wydarzeń może być nierealna. Gra jest rywalizacją, ale jej wynik nie jest żadną miarodajna oceną ani umiejętności, ani wiedzy uczestników, gdyż zależy częściowo od przypadku, a częściowo od wybranego przez uczestników trybu działania w paradygmacie zabawy. Dobrej zabawy! Strona 1 z 10

2 Zespoły W grze bierze udział sześć zespołów, 5-7 osobowych, o nazwach: HENNES, KRABB, KNAPPER, MINDE, BRIMNES oraz STAVE. Zespoły siadają przy jednym stoliku, na którym jest kartka z nazwą zespołu: Każdy zespół ma dwie plansze do gry formatu A3, pionek i kostkę do rzucania, oraz tę instrukcję: Zespoły grają niezależnie od siebie. Zasady gry Gra składa się z serii kolejek, których rytm i tempo wskazywane są przez prowadzącego. W trakcie większości kolejek odbywa się także praca w grupach oraz dyskusja. Wejście do gry Wejście na trasę gry odbywa się po wyrzuceniu jedynki (jednego oczka) lub szóstki (sześciu oczek). Jeśli zespół nie wyrzuci w danej kolejce jedynki lub szóstki, czeka do następnej kolejki. Po wyrzuceniu jedynki lub szóstki, zespół stawia swój pionek na polu 1 (A). Strona 2 z 10

3 Przebieg kolejki gry Na sygnał prowadzącego, każdy zespół rzuca kostką i przesuwa swój pionek do przodu o tyle pól, ile oczek wskaże kostka. Uwaga: po wyrzuceniu szóstki, zespół ma prawo rzucić kostką ponownie i przesunąć pionek o łączną liczbę oczek z obu rzutów. Powtórne wyrzucenie szóstki nie daje już jednak prawa do trzeciego rzutu. Kiedy wszyscy są gotowi, prowadzący ustawia aktualne pozycje zespołów na planszach na ekranie: Uwaga 1: po dojściu do, lub przekroczeniu pola numer 22 na planszy projektowej, zespół przenosi swój pionek na pole s1 tablicy scrumowej: Strona 3 z 10

4 Uwaga 2: po dojściu do, lub przekroczeniu ostatniego pola na planszy scrumowej, zespół przenosi swój pionek na pole 23 tablicy projektowej: Zespoły, których pionek wylądował na polu oznaczonym dużą, pogrubioną literą np. A (na planszy scrumowej odpowiednio sa), czytają - poniżej w tej instrukcji - opis sytuacji i przygotowują odpowiedź / plan działania zgodnie z poleceniem dla danej sytuacji. Jest na to mało czasu, około sekund, aby inne zespoły nie zaczęły się nudzić, czekając! Uwaga, jeśli któryś z tematów pojawia się ponownie, kiedy natrafił na niego kolejny zespół, lub ten sam zespół po uprzednim cofnięciu się, nie musimy go omawiać (możemy, jeśli pojawiły się nowe opinie). Strona 4 z 10

5 Prowadzący wyświetla na ekranie odnośny opis, a przedstawiciel wskazanej grupy krótko omawia, co grupa w tej sytuacji grupa zamierza zrobić / jak grupa komentuje sytuację: Swoje opinie na ten temat mogą również wygłaszać pozostałe osoby, z innych grup! Prowadzący moderuje powstałą dyskusję. Kiedy w ten sposób przepracowane zostaną wszystkie przypadające na danę kolejkę tematy, prowadzący ogłasza: Czas nie więcej niż jedna minuta! na zrobienie notatek; Następną kolejkę następny rzut kostką. Strona 5 z 10

6 Zakończenie gry Zespół, który pierwszy dojdzie do końca, wygrywa. Grę toczy się aż do jej ukończenia przez wszystkie zespoły. Przypominamy: wynik gry nie jest miarodajna oceną ani umiejętności, ani wiedzy uczestników, gdyż zależy częściowo od przypadku, a częściowo od wybranego przez uczestników trybu działania w paradygmacie zabawy. Dobrej zabawy! Opisy sytuacji projektowych A. Zapytanie ofertowe klienta (dla instytucji publicznej, będzie to SIWZ) zawiera następujące sformułowania: (1) Główne funkcje systemu to dostęp podróżujących do listy towarów, możliwych do kupienia na pokładzie samolotu, przed podróżą, przez Internet oraz urządzenia mobilne, możliwość składania zamówień i dokonywania płatności przed podróżą oraz możliwość odbioru zamówionych towarów w samolocie. (2) Projekt ma być zrealizowany metodą agile scrum. Proszę podać: (a) możliwe uzasadnienie biznesowe tego produktu, oraz (b) możliwe argumenty stojące za wymaganiem stosowania agile scrum. B. W trakcie analizy wstępnej projektu okazało się, że niejasne są obecnie obowiązujące procedury procesu sprzedaży i niejasne, jakie zasady biznesowe (business rules) obowiązują. Czy możliwe jest równoległe wykonywanie analizy biznesowej obecnego procesu oraz tworzenie w ramach agile scrum elementów nowego systemu, wspierającego nowy proces? Jakie będą zagrożenia, jakie możliwe korzyści takiego podejścia? COFAMY SIĘ O JEDNO POLE WSTECZ. C. Analiza wstępna wskazała, że operatorzy obecnie stosowanych systemów sprzedaży pokładowej (linie lotnicze) mają określoną architekturę korporacyjną oraz wynikającą z niej architekturę IT. Jakie są korzyści, jakie koszty uwzględnienia architektury korporacyjnej oraz IT klienta w wymaganiach oraz ich realizacji? Jak to można realizować w agile scrum Strona 6 z 10

7 (przed rozpoczęciem scrum agile, w przebiegu zerowym, obok, w każdym przebiegu osobno?). IDZIEMY DWA POLA DO PRZODU. D. DevOps: dla każdego systemu online, krytycznego dla biznesu, w tym dla systemów sprzedaży online, kluczowe są sprawne konserwacja i utrzymanie systemu. Aby to ułatwić, korzystne jest podejście DevOps współudział osób zajmujących się administrowaniem i osób zajmujących się wytwarzaniem w jednym projekcie. Jak to można połączyć w podejściu zwinnym? E. Okazuje się, że dla dostawcy, system, umożliwiający sprzedaż na pokładzie samolotu także towarów zamówionych wcześniej przez Internet, jest jednym z wielu produktów należących do pakietu produktów sprzedaży online, co umożliwia wielokrotne wykorzystanie wielu komponentów. IDZIEMY DWA POLA DO PRZODU. Jakie są korzyści, jakie koszty uwzględnienia całości portfela produktów przy realizacji kolejnego z nich? Jak to można realizować w agile scrum (przed rozpoczęciem scrum agile, w przebiegu zerowym, obok, w każdym przebiegu osobno?). F. Okazuje się, że dostawca systemu, umożliwiającego sprzedaż na pokładzie samolotu także towarów zamówionych wcześniej przez Internet, jest dużą firmą, realizującą jednocześnie cały portfel projektów dla tej samej kategorii klientów (linie lotnicze). To utrudnia skoncentrowanie wysiłków na tym jednym projekcie. COFAMY SIĘ O DWA POLA. Niektóre z projektów realizowanych w tym portfelu są agile, inne nie. Jaki wpływ wywiera ta sytuacja na możliwość zastosowania agile scrum w bieżącym projekcie? G. Architektura rozwiązania. Porównajmy korzyści i koszty czterech spotykanych rozwiązań: (1) brak prac architektonicznych; (2) architektura powstaje na bieżąco, tworzą ją programiści w kolejnych przebiegach; (3) architektura jest częściowo określona z góry, następnie modyfikowana w kolejnych przebiegach; (4) architektura jest dokładnie zaprojektowana z góry. Który wariant wybieracie? H. Wymagania niezawodności standardy lotnicze. Oj, zapomnieliśmy o tym! COFAMY SIĘ TRZY MIEJSCA DO TYŁU. Jak w projekcie agile uwzględnić i zapewnić spełnienie wymagań norm bezpieczeństwa lotniczego? Strona 7 z 10

8 I. Umowa prawna na projekt agile. Czy sposób realizacji projektu ma wpływ na kształt umowy? Jak sformułować umowę, aby była stosowna do projektu realizowanego w formie agile? J. Lean w procesie sprzedaży pokładowej a lean w procesie tworzenia oprogramowania wspierającego tę sprzedaż. Na czym polega lean w procesie sprzedaży i produkcji? Na czym w procesie projektowym? Grozi nam pomylenie pojęć, COFAMY SIĘ O JEDNO MIEJSCE. K. Z różnych powodów, na poziomie całego projektu wymagane jest zastosowanie modelu PRINCE2. W jaki sposób pogodzić to ze stosowaniem agile scrum podczas tworzenia kodu? L. Pojawia się mnóstwo nowych pomysłów dotyczących wyglądu interfejsu w trakcie realizacji projektu. TRACIMY JEDNĄ KOLEJKĘ. Jak to rozwiązać na styku zarządzania projektem oraz agile scrum? M. Kłopoty z egzekwowaniem udziału przedstawicieli klienta w projekcie. Osoby ze strony klienta, z którymi współpracuje dostawca, są niemiarodajne, ich opinie dotyczą tylko części systemu. TRACIMY DWIE KOLJKI. Jakie mogą być przyczyny, jak zapobiegać o jak przeciwdziałać tego typu trudnościom? N. Różnica kultury i struktury organizacji klienta i wykonawcy. Ups! Już podczas scrumu wyszły na jaw różnice między kulturami organizacyjnymi dostawcy oraz klienta, co rodzi szereg nieporozumień i poważnie utrudnia realizację zapisanych w umowie zasad agile scrum. TRACIMY DWIE KOLEJKI! Poszukajmy wspólnie sytuacji, może z planszy scrumowej, będących symptomami trudnych do pogodzenia różnić kultur między organizacjami. O. Usuwanie realizacji niepotrzebnych, wstępnie zaplanowanych wymagań w projektu: IDZIEMY WRPOST NA POLE 31! (Kłopoty, które tam nas czekają, omówimy w następnej kolejce). Czego jakie są korzyści, jakie zagrożenia takiego postepowania? Jakie warunki muszą być spełnione ze strony klienta, aby było możliwe? P. Wykrywanie błędów we wcześniej dostarczonych funkcjach. Z POWROTEM NA POLE 26. Jak zmniejszać prawdopodobieństwo takich problemów? Jak sobie z nimi radzić, jeśli mimo tego wystąpią? Strona 8 z 10

9 Q. Nieprzewidziane kłopoty z wydajnością systemu przy pełnym obciążeniu. WRACAMY NA POLE 29. Jak zmniejszać prawdopodobieństwo takich problemów? Jak sobie z nimi radzić, jeśli mimo tego wystąpią? Opisy sytuacji scrumowych sa. Kto powinien pełnić role właścicieli produktu. Właścicielem produktu zostaje ta sama osoba, co scrum masterem. TRACIMY KOLEJKĘ. Kto najlepiej powinien być właścicielem produktu? sb. Planowanie przebiegu (sprintu) trwa zbyt długo. COFAMY SIĘ NA s2. Jak zlikwidować ten problem? sc. Usiłowania wkładania niedojrzałych wymagań do rejestru przebiegu. WRACAMY NA s3. Jakie są skutki tego problemu? Jakie są metody zaradcze? sd. Próby negocjowania tworzenia długu technicznego. Z POWRTOEM NA s7. Jakie mogą być skutki tego problemu? Jakie są metody zaradcze? se. Dyskusje nad definicją DoD. Do omówienia: jak uwzględnić wyniki testowania w DoD? DoD a kryteria akceptacyjne. Cele biznesowe i techniczne kryteriów akceptacyjnych. sf. Dostęp do środowiska testowego. Ojej, środowisko docelowe jest prawie niedostępne dla deweloperów, integratorów i testerów, więc trzeba budować obszerne środowisko testowe. ZATRZYMUJEMY SIĘ NA DWIE KOLEJKI. Jakie trudności organizacyjne i techniczne rodzi wspólne środowisko testowe w agile scrum? Jak je rozwiązywać? sg. Trudności z integracją. Jak podzielić zadania integracji systemu oraz integracji systemów (integracji z innymi systemami) między zespoły scrumowe? sh. Potrzeba automatyzacji testów regresji. Kosztem agile jest zwiększona konieczność częstych (i obszernych) testów regresji. STOIMY JEDNĄ KOLEJKĘ. Jakie są koszty i korzyści testów regresji, lub ich zaniechania? Jakie są koszty i korzyści automatyzacji testów regresji, lub jej zaniechania? si. Próba zmian wymagań w trakcie przebiegu. Jest stare, dobre wrzutki miały w agile zniknąć, ale pojawiły się znowu! WRACAMY NA s18. O czym to może świadczyć? Jakie są skutki? Jak zapobiegać wrzutkom? Strona 9 z 10

10 sj. Wymagania dokumentacji. Nieoczekiwanie, okazało się, że klient (albo nasza własna księgowość, albo standard, lub wymogi prawne, o których zapomnieliśmy na początku) wymagają obszernej dokumentacji. POWRÓT NA s18. Jak sobie z tym radzić? Jak zapobiegać temu, że takie wymagania nas zaskakują? (czyli co robić, żeby nas nie zaskakiwały). sk. Kamienie milowe projektu. Projekt powyżej poziomu agile scrum ma zdefiniowane kamienie milowe, które wymagają (a) specjalnej dokumentacji; (b) dodatkowych testów; (c) jeszcze czegoś. Jak te zadania bezboleśnie wpisać w agile scrum? sl. Nierealne ocenianie szybkości zespołu scrumowego (velocity). Dwa spośród czterech zespołów są świeże nie umieją trafnie ocenić swojej szybkości, przez co dwa przebiegi nie zostają zrealizowane w pełni, tylko częściowo. Z POWRTEM NA s22. Jak poprawić trafność samooceny zespołów? Jaki zapobiegać kłopotom, spowodowanym tym, że nowe zespoły zawsze mają trudność z oceną swojej szybkości? sm. Błędy zostały wykryte po zakończeniu przebiegu. COFAMY SIĘ NA s22. Jak sobie radzić ze skutkami tej sytuacji? Z czego ona wynika i jak jej można próbować zapobiegać? sn. Przygotowanie dostawy do klienta. Z czego może wynikać rozbieżność między dostawami z kolejnych przebiegów, a dostawami do klienta? Jak sobie radzić z tą sytuacją? so. Nieuwzględnianie poziomu ryzyka przy planowaniu przebiegów. Nieuwzględnianie poziomu ryzyka (konsekwencji i prawdopodobieństwa błędów i awarii) powoduje, że nieprawidłowo szacuje się wymaganą staranność pracy, a więc i czas na nią potrzebny, w tym czas potrzebny na testowanie. COFAMY SIĘ NA s26. Jak takie uwzględnianie można wpisać w proces scrumowy? sp. Bardzo czasochłonne testy odbiorcze. Jak przekonać klienta (i samych siebie), że obszerne testy odbiorcze (UAT-y, OAT-y) nie są konieczne? Jeśli są konieczne, jak to ma się do metodyki scrum? sq. Pojawiają się próby wyrywania osób z zespołów scrumowych do innych zadań. WRACAMY NA s28. O czym to świadczy? Jakie są skutki? Jak zapobiegać? Strona 10 z 10