W zeszłym tygodniu byłem w delegacji u klienta w Edynburgu. W trakcie, na moim kanale na Youtube prowadziłem codziennego vloga, gdzie podsumowywałem każdy dzień. Jednak w tym wpisie chciałem zebrać w całość temat przygotowania się klienta do rozpoczęcia projektu. Dla niecierpliwych – słabego przygotowania. Co nieco mówiłem o tym we vlogu z piątku.

Dobre złego początki

Do Szkocji leciałem mając informację, że będziemy się wdrażać w nowy projekt, który będzie częścią większej aplikacji. Po przylocie zaczęło się standardowo. Najpierw nowe osoby (te, które zatrudniliśmy niedawno) miały wdrożenie do firmy klienta. Potem zostaliśmy zapoznani z istniejącym systemem, który będziemy zastępować. Pokazano nam też część aplikacji, która została już przepisana. Tutaj wszystko przebiega wg planu. Standardowe zapoznanie się z zespołem i domeną.

Wszystko szło całkiem sprawnie. Prezentacje były nieźle przygotowane. Wiadomo, że w dwa dni nie da się upchnąć zbyt dużo wiedzy o systemie używanym od lat. Zwłaszcza jak sami nie siedzimy w tym biznesie. Ale podstawy otrzymaliśmy. Nikt z prowadzących nie miał problemu z opowiadaniem o funkcjonalnościach. Czas na pytania i dyskusje też był. Super.

Pierwszy zgrzyt, ale zamaskowany

Po wprowadzeniu teoretyczno-obrazowym zaplanowana była sesja na dyskusje o naszym rozwiązaniu i naszym planie na nie. Zgrzyt wspomniany w tytule tej części to fakt, że pierwsza część zaczęła się od „ok, to porozmawiajmy o strukturze tabel w bazie danych”. Od razu w mojej głowie pojawiło się „WTF?” i skojarzenie ze starymi aplikacjami pisanymi w metodologii waterfall. Co ciekawsze nawet nie było to projektowanie tabel od nowa. Pokazano nam gotowy schemat i mieliśmy powiedzieć czy jest ok. Był to projekt tabel, który po prostu 1:1 przenosił strukturę starego projektu. Czyli jednak robimy starą aplikację tylko w nowym języku? Nie spodobało mi się to. Tym bardziej, że nawet jeszcze nie widzieliśmy konkretnych wymagań co do nowej aplikacji. Sesja przeglądania user stories i planowania miała być następnego dnia. Ale po powtórzeniu parę razy, że coś z tego wszystkiego ma sens, ale bez wymagań i tak będziemy to zmieniać poskutkowało odstawieniem tematu na bok.

Kiedy udało się odstawić pomysł rozpoczęcia projektu od zaprojektowania bazy danych przeszliśmy do dyskusji o architekturze. Tutaj bardziej my przejęliśmy pałeczkę, dlatego w tytule wspomniałem, że zgrzyt został zamaskowany. Bazując na tym, że wiemy, że będziemy robić API i mając ogólne pojęcie o domenie problemu zaproponowaliśmy wysokopoziomową architekturę aplikacji (która już pierwszego dnia po powrocie się trochę zmieniła, ale co tam). Jednak w trakcie pojawiały się niepokojące pytania. Np. o to co w sytuacji jak ktoś inny będzie chciał używać naszego API. I ten ktoś będzie potrzebował mniej więcej ten sam flow, ale minimalnie inny. Aż w końcu przyszła jedna osoba i powiedziała, że ich architekci zaproponowali rozwiązanie, które pozwala dostosować aplikację do różnych wymagań.

APIcepcja

Pomysł ten zakładał, że mamy warstwę, która jedyne co robi to opakowuje w API HTTP metody dostępu do bazy danych. Potem mamy warstwę z logiką, która też udostępnia API HTTP i korzysta z tego poprzedniego API. W dodatku inni mogą albo korzystać z tego drugiego API, albo napisać swoje korzystając tylko z tego pierwszego. Czyli po prostu wymyślili, żeby wystawić bazę danych jako API i dorobić do tego aplikację z logiką, ale w razie potrzeby dopisywać inne aplikacje z kompletnie inną logiką. Bez diagramu i 15 minutowego komentarza nawet dla mnie to jest ciężki. Także rozumiem jeżeli nic z ostatnich zdań nie zrozumiałeś.

W każdym razie pomysł wielowarstwowego API i prawie bezpośredniego dostępu do bazy danych przez kogokolwiek szybko zbombardowaliśmy. Ułatwiła nam to odpowiedź na pytanie – kto będzie z tego jeszcze korzystał i jakich zmian wymaga? Nie wiedzą kto w przyszłości będzie z tego korzystał i nawet nie wiadomo czy cokolwiek będzie potrzebował zmienić w naszej logice.

Plan bez planu

Głównym punktem, przy którym powstała w mojej głowie tytułowa myśl o falstarcie projektu, była piątkowa sesja. Zaczęła się od dyskusji na temat metodologii w jakiej będziemy pracować. Oczywiście był to Scrum. Najbardziej książkowy. Takie są najgorsze. Właściwie nie same Scrumy ale osoby, które o takich mówią. Ciężko mi było coś dodać albo zmienić w tym co prezentowali. Bo były same ogólniki. Ze szczegółów to nawet daty pierwszego sprintu albo w ogóle dnia tygodnia, w którym się sprinty będą rozpoczynać nie udało się ustalić.

Dodatkowo klient koniecznie chce żeby co 3 sprinty, czyli co 6 tygodni, były spotkania na żywo. Czyli raz my przyjeżdżamy, a raz oni. Tylko jednak nie. Bo mają problem z wysłaniem niektórych osób z zespołu, które są na kontrakcie. Więc dopóki tego nie rozwiążą to zawsze by będziemy jeździć.

Rozmowa o estymowaniu zadań skończyła się po kilku zdaniach. Dostaliśmy pytanie jak to robiliśmy gdzieś indziej. Zostało powiedziane, że pracujemy na punktach nie przeliczanych 1:1 na godziny i tyle. Temat został zawieszony.

Powiedz czego chcesz

Punktem kulminacyjnym była sesja planowania. Zebraliśmy się wszyscy przy stole. Analitycy podłączyli się do telewizora. Czekamy w skupieniu. Iiii….

…ludzie klienta nawet nie wiedzą jak wyglądają user story. Zobaczyliśmy pierwsze wymaganie, które brzmiało „jako użytkownik chcę mieć dostęp do danych”. W tym momencie sesja planowania została przerwana i zaczęła się sesja uczenia jak się spisuje wymagania. Szło bardzo opornie. Osoby, które miały jakiekolwiek pojęcie o tym dyktowały zdanie po zdaniu co analityk ma zapisać. Daliśmy im chwilę na samodzielną pracę. W końcu godzinę wcześniej ustaliliśmy, że tylko analitycy i product owner mogą dodawać user story. Więc niech się sami nauczą jak to robić dobrze. Jedynie co jakiś czas wtrącałem moje komentarze. Do samego końca widziałem, że nie potrafią zejść na niższy poziom i zrozumieć, że wymaganiem jest raczej „jako użytkownik chcę móc wyszukać pozycję za pomocą wyszukiwarki” niż taki bezużyteczny ogólnik jaki wcześniej został zaprezentowany.

Jak to ma wyglądać?

Kiedy już wszyscy uznali, że dyskutowanie na temat tego jak wyglądają wymagania nie ma w tym momencie sensu i analitycy muszą mieć czas na zastanowienie, pojawił się temat designu UI. Nie pamiętam już czy to ja zapytałem jak wygląda design czy ktoś inny ale taki temat powstał. Okazało się, że nie ma projektu UI do tego co robimy (wspominałem, że robimy API jednak będzie ono zintegrowane bezpośrednio z resztą systemu i dostępne rzez UI właśnie). Nie planowali tego jeszcze. Przez dłuższą chwilę próbowałem wytłumaczyć, że to powinien być fragment wymagań. W końcu wcześniej się zgodziliśmy, że aby zadanie było gotowe do wzięcia musi mieć przygotowane wszystko co do wykonania go jest potrzebne.

Powstała więc kolejna dyskusja – czy dodać osobne zadanie na przygotowanie projektu UI. Wniosek był taki, że trochę to bez sensu bo ciężko to przepchnąć przez flow jakie mają i np. przetestować. Ale i tak takie zadanie się pojawiło…. Zasugerowałem, że zanim cokolwiek zostanie spisane w wymaganiach i gotowe do wyceny to trzeba mieć gotowe makiety i do każdego zadania wycinać fragment tej makiety pokazujący dany fragment albo powiedzieć jak się do niego dostać na interaktywnym prototypie. Z lekką niechęcią zgodzili się z tym. Ustaliliśmy więc, że trzeba o UI pomyśleć już teraz.

Ktoś mógłby powiedzieć, że skoro myśleli o API itd. to po prostu stało się przeoczenie. Nic złego. Ale nie. Bo zabawnie się zrobiło kiedy po dyskusji o prototypie UI ktoś otworzył prezentację z road mapą (chyba zapytałem po prostu o jakieś terminy). Na slajdzie opisanym „Marzec”, w punkcie „Początek marca” pierwsza pozycja jaką sami już jakiś czas temu dodali było… „zlecić przygotowanie prototypu UI”. Padłem.

Design interfejsu i związane z tym zadania także trafiły na listę „będziemy rozmawiać”.

Działamy?

Spotkanie skończyło się tak, że uznali, że potrzebują jeszcze z tydzień na ogarnięcie wymagań i dopiero wtedy wrócimy do planowania. Także było to klasyczne spotkanie pt. „Spotkaliśmy się po to aby ustalić, że się spotkamy”.

Z naszej strony sprawa wygląda tak – powiedziałem, że na początku i tak robimy setup projektu. Więc możemy przez parę dni obyć się bez wymagań biznesowych. W końcu założenie solucji czy przygotowanie kontenerów jest niezależne od tego w pewnym stopniu.

Wczoraj – czyli w poniedziałek po delegacji – uznali, że musimy przetestować robienie standupów online. Na piątkowym spotkaniu zostało powiedziane, że domyślnym narzędziem u nich w firmie jest Zoom. Jednak w poniedziałek uznali, że połączymy się przez MS Teams. Przez 15 min. ja i kolega próbowaliśmy dołączyć do spotkania i obu nas wyrzucało po kilkunastu sekundach. Po tym czasie wysłałem link do pokoju w Zoomie. Wszyscy się od razu połączyli bez problemu. Ich argument za pierwszymi próbami? „Nie wiedzieliśmy, że da się korzystać z Zooma na komputerze, a nie tylko z salek”. Jak widać da się.

Dzisiaj – czyli we wtorek – przyszły dwie rzeczy. Po pierwsze dostałem dokument mówiący o pisaniu dokumentacji architektury aplikacji. Moja odpowiedź na niego była taka, że spoko, tylko najpierw to ustalimy jakąś architekturę i zbiór bibliotek chociaż. Poza tym muszę się nauczyć robić diagramy, które na pewno po miesiącu będą nieaktualne, ale są wymagane. Jakoś przeszła taka argumentacja więc pisanie dokumentacji odłożyłem w czasie.

Druga rzecz to dostaliśmy informację, że pojawiły się user story do setupu projektu (ustaliliśmy w piątek, że będą takie, żeby było jak zadania przeciągać w TFSie). Spojrzałem na nie. I nie. To nie są w żaden sposób wymagania do części technicznej. Są to ponownie ogólniki mówiące mniej więcej tyle, że chcę móc w aplikacji pobrać dane. Jeszcze nie miałem okazji zareagować na to. Ale pierwsza myśl jaka mi przyszła do głowy to po prostu na planowaniu rzucić, że to zadanie zajmie np. 2 miesiące. Bo obejmuje 1/3 projektu.

Zobaczymy co przyniosą kolejne dni. A zapowiadał się dobry start już od pierwszych spotkań…