Jak szybko dostarczyć projekt Agile za pomocą Event Stormingu i Design System. Case Study.

Niedawno pracowałem w projekcie z bardzo krótkim deadline'em. Jako Escola Software House, postanowiliśmy wypróbować nowy sposób realizacji projektu... Moje cechy osobowości są nastawione na ciągłe doskonalenie, więc zawsze próbuję nowych sposobów zarządzania.

Jednak po latach pracy w branży software'owej wiem, że nie jestem dobrym project managerem. Przez jakiś czas nie pracowałem nad projektami, ponieważ byłem skupiony na byciu dyrektorem technologicznym Wellms’a, pierwszego na świecie headless LMS. Ten projekt był dla mnie wyzwaniem i starałem się usprawnić procesy. Jestem dobry w projektowaniu graficznym procesów, zwykle tworzę proste diagramy. Razem z zespołem spędziliśmy około dwóch tygodni na odkrywaniu i planowaniu, a następnie na ośmiu tygodniowych sprintach.

Poniżej przedstawiam proces, którego jestem współautorem. Diagram opisuje okres życia projektu od leadu do utrzymania. Tym razem chciałem przetestować drobne korekty.

Faza Discovery

Faza Discovery jest etapem wstępnym, zanim firma zdecyduje się podpisać umowę z klientem i rozpocząć projekt. Na tym poziomie musimy zdecydować, czy projekt jest możliwy do zrealizowania w ramach danego budżetu i terminu. W przypadku tego projektu mieliśmy deadline i musieliśmy przedstawić przybliżony szacunek tego, co może być wykonane w określonym terminie.

Klient udostępnił nam następujące zasoby:

• Kilka user stories i person
• Opisy
• Logotyp, kolory i typografia
• Makiety High-Fidelity w Figmie
• Opis słowny
• Flow użytkownika z zaznaczonymi częściami dla MVP (MVP to wersja produktu z wystarczającą ilością funkcji do wykorzystania przez pierwszych klientów, którzy mogą dostarczyć informacji zwrotnych dla rozwoju przyszłego produktu)

Na pierwszy rzut oka wydawało się, że ten projekt jest dobrze przemyślany i opisany. Jednak po zagłębieniu się w szczegóły znaleźliśmy wiele nieścisłości i sprzeczności. Na szczęście zakres MVP był bardzo ograniczony, więc podaliśmy orientacyjny kosztorys. Klient zaakceptował przedział od 1000 do 2000 godzin pracy i podpisał umowę Time & Material.

Z perspektywy biznesowej ten krok jest niezbędny, ale z perspektywy deweloperskiej jest to krok bez znaczenia. Na tym etapie nie mamy pojęcia, czy jakikolwiek projekt jest możliwy do zrealizowania w ciągu tych godzin, niezależnie od ewentualnych opisów podanych przez klienta. W Agile nazywa się to

Współpraca z klientem ponad negocjacją kontraktu

Disclaimer: Gdy używam słów „faza discovery”, mam na myśli eksplorację funkcji (feature exploration). Escola ma dedykowany produkt o nazwie „Product Discovery”, który jest czymś zupełnie innym.

Planowanie

Etap planowania obejmował wiele faz, począwszy od wyboru daty rozpoczęcia i wyboru zespołu. W zespole wypełniałem zadania jako tech lead i tester. Pracowaliśmy razem kierownikiem projektu (Project Manager), trzema frontend developerami i dwoma backend developerami.

Jedną z kluczowych decyzji przy realizacji projektu był jego charakter. W portfolio mieliśmy już wiele aplikacji e-learningowych, opartych na rozwijanym przez nas headless LMS-ie typu open course — Wellms. Mogliśmy korzystać z naszego doświadczenia przy tworzeniu kolejnej aplikacji e-learningowej. Około 50% opisanych funkcji backendu było pokryte przez moduły, które już mieliśmy. Musieliśmy wyjaśnić, co można wykorzystać w obecnej formie, co wymaga poprawek, a co jest zupełnie nową funkcjonalnością.

Ostatnim etapem było zaprojektowanie person (archetypu lub postaci, która reprezentuje potencjalnego użytkownika aplikacji) i przypisanie im user stories. Gdy już to mieliśmy, nadaliśmy im unikalny numer i umieściliśmy w roadmapie Jiry.

Decyzje technologiczne

Przed oszacowaniem projektu musimy wziąć pod uwagę kilka decyzji dotyczących architektury i technologii. Jedną z nich jest wykorzystanie naszego open source'owego e-learningowego Wellms Framework, który zawiera backend napisany w PHP 8.1 oraz frontend w postaci reużywalnych komponentów React. Inne wstępne decyzje, które zostały podjęte, obejmują:

• Aplikacja frontendowa w Next.js w wersji 13: Ta decyzja mogła nie być rozsądna, ponieważ nie jest to stabilna wersja, przetestowana w boju. Zawiera duże zmiany w porównaniu do wcześniejszych wersji.
• Responsywny projekt strony internetowej o szerokości powyżej 1024 px: Wersja MVP była przeznaczona tylko dla komputerów stacjonarnych i tabletów. Wersja mobilna zostanie uwzględniona w przyszłych etapach.
• Styleguide  z komponentami wielokrotnego użytku React 18: Jest to niezbędne dla etapów po MVP.
  Projekt ma być dostarczony równolegle z procesem projektowania graficznego w Figmie. Zajęła się tym zewnętrzna agencja.
• Wszystkie komponenty (REST API, Student frontend SSR Next.js i Admin Dashboard) będą automatycznie budowane jako obrazy docker, wypychane do rejestru i stosowane jako klaster Kubernetes.

Wszystkie te decyzje są zapisywane w Confluence projektu jako ADR (architectural decision record). ADR jest dokumentem, który opisuje wybór, jakiego zespół dokonuje w odniesieniu do istotnego aspektu architektury oprogramowania, które planuje zbudować. Każdy ADR opisuje decyzję architektoniczną, jej kontekst i konsekwencje. Na szczęście Confluence posiada szablon dla tych dokumentów o nazwie „DACI: dokumentacja decyzji”.

Wstępna estymacja

Mieliśmy tylko tyle, aby rozpocząć wstępne estymacje. Oprogramowaniem wspomagającym był planningpokeronline.com, połączony z Jirą, który importował wszystkie stories z Jiry.

Wraz ze wzrostem doświadczenia w branży staje się jasne, że programiści nie potrafią dokładnie oszacować i niewiele można z tym zrobić. Jednak posiadanie pewnej wiedzy o tym, które historie lub komponenty są bardziej skomplikowane niż inne, jest konieczne. Zrobiliśmy kilka rund, używając albo story points, albo ballpark hours, ale szybko zdałem sobie sprawę, że planowanie pokera nie miało sensu ze stories, które mieliśmy. Pozwólcie, że podam wam przykład:

Zakładając, że mamy story: "Jako niezalogowany student mogę się zalogować lub zarejestrować za pomocą uwierzytelniania Google OAuth 2.0".

Członkowie zespołu w tej rundzie podali estymację punktów story:

• Backend developer 1 przyznał 3 punkty za story, ponieważ jest to gotowy moduł, który trzeba tylko skonfigurować.
• Backend developer 2 dał 13 punktów story, ponieważ jest to gotowy moduł napisany wcześniej, ale wie, że ustawienie tego wymaga stworzenia aplikacji Google w konsoli, co zajmuje więcej czasu niż rzeczywiste programowanie.
• Trzech frontend developerów spojrzało na makiety i zobaczyło, że to tylko przycisk, więc podali niskie szacunki od 1 do 3 punktów story.
• Wiem, że ustawienie tego nie jest proste, więc dałem 8 punktów story.

Następnie karty miały wartości 1, 2, 3, 8, 13, co w zależności od algorytmu szacowania pokera dało średnio 5 punktów story. Ta wartość miałaby sens tylko wtedy, gdyby zespół backendowy lub frontendowy szacował je oddzielnie, ale zrobili to razem, a oprogramowanie nie ma możliwości sumowania i uśrednienia wyników. Podsumowując, user stories są świetne do zrozumienia projektu pod względem doświadczenia i użyteczności, ale są bezużyteczne do estymacji. Jednak zakończyliśmy tę fazę z szacunkiem około X godzin i Y punktów story.

Gromadzenie wymagań

Moim zdaniem najbardziej krytyczną fazą, która decyduje o sukcesie projektu, jest zbieranie wymagań. Jeśli właśnie przewijasz ten post, przeczytaj tę sekcję. Zaaranżowaliśmy kilka dwugodzinnych rozmów z klientem, aby rozłożyć każdy Epic w ich projekcie w formie zdalnych sesji Event Storming Big Picture.

Kluczowe w tej sesji było zaangażowanie każdego członka zespołu. Podczas wszystkich spotkań dowiedzieliśmy się, że oczekiwania klienta i nasze potrzeby mocno się różnią. W sumie spędziliśmy co najmniej osiem godzin na sporządzaniu notatek z przedstawicielami klienta i wszystkimi członkami naszego zespołu. Podczas rozmowy na żywo zrobiliśmy losowe notatki, które były następstwem Big Picture Event Storming i zdefiniowaliśmy Ubiquitous Language (Wszechobecny język), który jest kluczową częścią Strategicznego  Domain Driven Design.

Ubiquitous Language jest niezbędny. Jest to słownictwo jednoznaczne, współdzielone przez wszystkich zaangażowanych w projekt, od ekspertów domeny, przez zainteresowanych, przez kierowników projektu, po programistów. Na przykład nie chcemy mieć aktorów w systemie nazywanych użytkownikami, a następnie story typu,,użytkownicy mogą się zalogować", ponieważ są one tak wieloznaczne i pozbawione znaczenia (admin, tutor, student, anonim to wszyscy użytkownicy, ale mają zupełnie inne role i możliwości), że w końcu są bezużyteczne.

Kiedy karty z Event Storming nie wystarczają, używamy prostych diagramów. Ważne jest, aby każdy zainteresowany rozumiał co się dzieje bez większego przygotowania. Dlatego nie będziemy używać UML czy BPM (Business Process Modeling), bo Manifest Agile mówi nam

Działające oprogramowanie ponad kompleksową dokumentację.

Chciałbym podkreślić — nie jestem przeciwnikiem UML, BPM, C4 czy innych ustandaryzowanych metod, tutaj użyliśmy tylko ich uproszczonej wersji.

Diagramy, które są jednoznaczne i przejrzyste dla każdego zainteresowanego.

Podstawowe diagramy i notatki dla programistów.

Mój wniosek po tych spotkaniach jest taki, że ponieważ wszyscy członkowie zespołu brali w nich udział, rozumieją ogólny wymiar całego projektu. Jest mniejsza szansa, że ktoś zrobi coś złego lub bezsensownego z biznesowego punktu widzenia. 

Członkowie projektu rozumieją potrzeby i oczekiwania klienta, motywacje, a przede wszystkim zasady biznesowe dla tego konkretnego projektu. Nie zaimplementują niepotrzebnego feature'u z powodu złego opisu issue'u na Jirze (jednym z powodów, dla których jestem złym PM'em jest to, że nie potrafię zostawiać sensownych opisów). Ta część była najważniejsza i najbardziej zaskakująca jako czynnik sukcesu.

Ponieważ większość developerów brała udział w tych sesjach po raz pierwszy, większość z nich nie powiedziała nawet jednego słowa. Na początku wydawało się, że to strata czasu, ale w końcu się opłaciło.

Do zbierania wymagań używałem Miro, które jest do tego doskonałym narzędziem.

W Agile jest to tak zwane

Osoby i interakcje ponad procesami i narzędziami

Backlog Jiry

Kiedy zespół już rozumie zarys projektu, możemy stworzyć backlog zadań. Tu oddzielamy backend, frontend, DevOps i inne zagadnienia od user stories. Ważne jest, że skupiamy się na różnych komponentach projektu.

Styleguide / Design System

Stworzenie jednego źródła prawdy dla wszystkich elementów wizualnych jest ważne przy projektowaniu i rozwijaniu oprogramowania. Istnieją różne podejścia do osiągnięcia tego celu, takie jak użycie style guide lub design system. Wybrałem użycie styleguide, który obejmuje zebranie i opisanie wszystkich możliwych komponentów i ich wariantów oraz opracowanie ich jako „dummy” komponentów wielokrotnego użytku.

Do stworzenia przewodnika stylu użyliśmy narzędzia o nazwie Styleguidist ( znacznie mniej popularne niż Storybook), które automatycznie generuje to jako stronę GitLab i jest częścią naszego procesu ciągłej integracji. Style guide dokumentuje wszystkie komponenty i prezentuje je w różnych wariantach z przykładowym kodem źródłowym.
Chociaż istnieją oczywiste zalety korzystania ze style guide, istnieją również pewne wady. Jedną z nich jest to, że nie można używać kolejnych komponentów wewnątrz style guide. To utrudnia przekazanie ich do, powiedzmy, komponentu menu. Inną kwestią jest to, że tworzenie callbacków takich jak `onClick={()=> router.push(...)}` nie jest idealne, ponieważ tracisz prefetching Next.js i możliwość otwierania linków w nowym oknie. Wreszcie, przestrzeganie zasady DRY może być czasami trudne, ponieważ może być konieczne złamanie go zamiast tworzenia zbyt abstrakcyjnego i wieloznacznego potwora spaghetti, które sprawiają, że kod jest trudniejszy do utrzymania (Hej deweloperze - jeśli jesteś zainteresowany przeczytaj ten świetny wpis na blogu Dana Abramova).

Komponenty na żywo - dokumentacja kodu. Doświadczenie w zakresie Developer First.

Czy idziemy zgodnie z planem?

Po kilku sprintach przeprowadziliśmy ponowną estymację, tym razem nie na podstawie user stories, ale o komponenty. Wykorzystaliśmy Miro Estimation, który okazał się zbyt prosty do naszych celów. Połączyliśmy go jednak z Miro Kanban i integracją, która wysyłała story pointy do Jiry, gdzie rozwiązywaliśmy problemy z estymacją i mieliśmy wgląd w nasze postępy, średnią zaawansowania i to, ile czasu i story pointów potrzebujemy do oczyszczenia backlogu.

Estymacja odbywa się na podstawie Epic i komponentów zamiast User Stories.

Manifest Agile mówi o

Reagowanie na zmiany ponad podążanie za planem

ale w tym przypadku „plan” oznacza ile MVP jest faktycznie dostarczane i czy będziemy w stanie mieć przyzwoicie działającą aplikację przed wyznaczoną datą.

Miro Kanban board Komponenty podzielone najpierw na Frontend/Backend/DevOps następnie na Epic i komponenty. Zwróć uwagę na integrację z Jirą pokazującą ilość story pointów i aktualny status zadania.

Dostarczenie aplikacji, stały proces

Nasz proces rozwoju przebiegał w tygodniowym cyklu sprintów, a zespół stosował następujące podejście:

• Codzienne zdalne spotkania daily na Google Meet
• Cotygodniowe sprinty śledzone i zarządzane za pomocą Jira
• Rozwój oparty o trunk based development z intensywnym code review
• Cotygodniowe demo dla klienta w celu zaprezentowania postępów poczynionych podczas sprintu

W trakcie procesu zidentyfikowaliśmy, że proces dostarczania projektów był wolniejszy niż proces dostarczania frontendów. Dlatego też zmniejszyliśmy wielkość zespołu frontendowego, a później musieliśmy zrobić to samo z zespołem backendowym, ponieważ zakończył on swój backlog wcześniej niż oczekiwaliśmy. W manifeście Agile, jak sądzę, jest to zatytułowane

Reagowanie na zmiany zamiast podążania za planem

co zostało już wspomniane w poprzednim akapicie.

Cotygodniowe demo

Cotygodniowe demo dla klienta było kluczowym czynnikiem sukcesu projektu. Wszyscy członkowie zespołu brali w nich udział, a po kilku spotkaniach wyznaczyliśmy jednego z programistów na prezentera. Pomogło to zmotywować cały zespół do dostarczenia swoich komponentów najlepiej jak potrafili.

Faza testów

Przekazaliśmy klientowi działające oprogramowanie do ostatecznego przetestowania, chociaż testował on podczas całego procesu i znał postępy poczynione podczas cotygodniowych sesji demo.

Jednym z ciekawych narzędzi, wykorzystanych w fazie testów był Ybug, który jest oprogramowaniem do wizualnego przekazywania informacji zwrotnych, umożliwiającym użytkownikom stron internetowych i aplikacji wysyłanie wizualnych informacji zwrotnych z adnotowanymi zrzutami ekranu. Automatycznie dołącza on kontekstowe informacje o środowisku użytkownika, ułatwiając zespołowi odtworzenie i naprawienie zgłoszonych problemów.

Podsumowanie

Podsumowując: stwierdziłem, że wdrożenie kilku sesji Event Storming w trakcie trwania projektu było kluczowym czynnikiem sukcesu. Proces ten pozwolił na głębokie zrozumienie zasad biznesowych projektu i oczekiwań klienta, co pomogło uniknąć błędów lub zbędnego wysiłku członków zespołu. Co więcej, wykorzystanie narzędzi takich jak Miro, Jira i Gitlab pages do stworzenia styleguide i procesu ciągłej integracji było pomocne w efektywnej współpracy i zarządzaniu zadaniami. Podczas cotygodniowych sprintów, codziennych zdalnych spotkań i przeglądów kodu (code review), byliśmy w stanie ustalić priorytety i dostosować kierunek projektu do potrzeb. Demonstracja dla klienta na koniec każdego tygodnia motywowała wszystkich do jak najlepszej pracy, a użycie Ybug do wizualnej informacji zwrotnej podczas testowania pomogło zapewnić płynne i udane dostarczenie projektu. Ogólnie rzecz biorąc, połączenie efektywnej współpracy, jasnej komunikacji i planowania strategicznego, w tym wykorzystanie sesji burzy mózgów, było kluczowe dla sukcesu tego projektu.