Miałam okazję zaczerpnąć wiedzy u samego źródła – autora Manifestu Agile – Arie van Bennekum. Spotkałam Ariego na PAM Summit w Krakowie 🙂 Chociaż posługiwaliśmy się różnymi pojęciami i narzędziami, odkryłam jak zdumiewająco wiele mamy wspólnych celów i jak wiele jest możliwości połączenia porządnej analizy i podejścia zwinnego dla dobra naszych klientów.
Mamy różne cele
A w zasadzie – nie. Właściwie chcemy tego samego – zadowolenia klienta z produktu, który otrzymuje. Agile przeciwstawia się wielomiesięcznemu zamykaniu przed klientem, sztywnym procedurom, planom i dokumentom, które odgradzają od drugiego człowieka – odbiorcy (hasło firmy Ariego to „People make the difference”). Analiza w ujęciu formalnych narzędzi, metod dogłębnego zrozumienia problemu, sprzeciwia się bałaganowi, brakowi ładu i planu, czyli rzeczom, które spotyka się obecnie niestety często, a utrudniają one znacząco wykonywanie systemów wysokiej jakości i odpowiadających potrzebom klienta.
Chaos _______________________________________________________ Sztywność
W Agile nie wiemy, co powstanie na końcu, działamy po omacku
Arie jest za tym, żeby przeprowadzać analizę na początku projektu. Nazywał to spotkaniami, warsztatami, ale generalnie mieliśmy zadziwiająco spójną wizję. Co mnie urzekło w rzeczach, ktore podkreślał twórca Agile – pierwsze i najważniejsze, to zrozumieć cel klienta! Nie to, co ma robić zamówione oprogramowanie, ale przyczyny podjęcia decyzji o jego zamówieniu. Przesłanki te są osadzone w biznesie klienta, np. obniżenie kosztów, wykorzystanie możliwości rynkowej, zwiększenie efektywności głównych procesów. Właśnie! Po drugie – zrozumieć jak działa biznes klienta, zrozumieć jego procesy biznesowe, które są powiązane z problemem, który staramy się zaadresować. Zrozumieć i jeszcze raz zrozumieć! Nie mogłabym się zgadzać bardziej:) Więc jak? Analiza biznesowa first, a później dobieranie rozwiązania. Propozycjom funkcji przydzielamy priorytety (np. MoSCoW), żeby określić co jest konieczne, a co stanowi miły acz niekonieczny dodatek i umiejętnie dobierać funkcje tak, aby zawsze dostarczać produkt najwyższej wartości dla klienta (wodotryski nie są konieczne), a także uświadamiać, czego rozwiązanie nie będzie miało (Won’t have).
Agile nie cierpi dokumentów
„Working software over comprehensive documentation” – to jedno z najczęściej opacznie rozumianych stwierdzeń Manifestu Agile. Arie mówił jak wielu spotyka ludzi, którzy są przekonani o swojej zwinności, ponieważ nie tworzą dokumentacji. Zwinność to nie chaos. Metodyki nurtu agile mają wiele procesów i narzędzi, których należy ściśle przestrzegać. Dokumentacja odgrywa w nich mniejszą rolę niż działające oprogramowanie, ponieważ to właśnie odbiera klient. Działamy w celu stworzenia rozwiązania, nie dokumentacji. Jednak jej tworzenie, jeśli nie jest przerostem formy nad treścią, nie jest żadnym demonicznym działaniem. Arie lubi rysować na spotkaniach z klientem. Ja też. Moje modele i opisy spełniają ważną rolę – pomagają weryfikować kompletność i spójność tego, o czym mówimy. Zanim nie narysujesz modelu, nie wiesz, ile rzeczy dostąd nie zauważyłeś. Zanim nie zapiszesz jawnie przyjętych założeń, nie zobaczysz, że pociągają one kolejne doprecyzowujące pytania. Takie dokumentowanie służy produktowi, buduje zrozumienie analityka i wspólne zrozumienie problemu w taki sam sposób przez wszytskich zainteresowanych, nie jest ślepym dopełnianiem procedury.
Nie ma miejsca dla analityka w Agile
Arie widzi miejsce dla analityka w Agile. Jest to styk świata biznesu ze światem IT. Nie ma też problemu ze specjalizacją w zespole – jeśli mamy analityka, wysyłamy go na pozyskiwanie wymagań. Musi być ktoś, kto lubi drążyć temat i rozumie biznes. Co ma być efektem pracy analityka? Po pierwsze – zrozumienie, po drugie, w zależności od metodyki, np. w Scrumie Rejestr Produktu (czy analityk czy PO, to kwestia do rozstrzygnięcia), doprecyzowanie wymagań w bardziej dokładnej dokumentacji? Czemu nie? Sprinty i prezentacje dla klienta? Cóż jest mniej kosztownego i szybszego do wykonania niż prezentowanie w pierwszym sprincie protowypów-modeli przypadków użycia, które można łatwo zweryfikować, odrzucać i zmieniać oraz prototypów-makiet, które pomagają zwizualizować klientowi proponowane rozwiązanie?
Agile Manifesto
Individuals and interactions over processes and tools.
Dobry analityk posiada zestaw narzędzi, z kórych może wybierać te, które najlepiej będą pasować do projektu i klienta, nie jest niewolnikiem procesów, których nie potrafi dopasować.
Working software over comprehensive documentation.
Dobry analityk tworzy dokumentację i modele, które służą projektowi, nie są bezmyślmym wypełanianiem nadmiarowych szablonów.
Customer collaboration over contract negotiation.
Tu wiele zależy od dostępności klienta i przyjętego modelu współpracy. Im większe stawki i klienci, tym trudniej.
Responding to change over following a plan.
Dobry analityk proponuje rozwiązanie oparte na zrozumieniu biznesu, stąd wiele zmian jest przewidywalnych lub rozwiązanie jest w stanie jest łatwo zaadaptować, jeśli się pojawią; podążanie do ruchomego celu nie jest proste, ale dzielenie planów na krótkie okresy stanowi dobry kompromis między zmianami a planem.
0 komentarze “Czy dobra analiza gryzie się z agile?”
W samym PAM Summit nie miałem okazji brać udział, ale dzień wcześniej uczestniczyłem w powiązanych z tym wydarzeniem warsztatach (jedne z nich prowadził właśnie Arie). Podczas przerwy podzielił się ze mną pewnym doświadczeniem. Swego czasu, dla jednego z klientów przygotowywał ofertę na wykonanie projektu przygotowującego zamawiąjącego do prowadzenia projektów w oparciu o metodykę SCRUM. Jego konkurentem był równie doświadczony, aktywnie uczestniczący w pracach naukowych, wykładowca i współtwórca metod zwinnych. Przetarg wygrał jednak Arie, tylko i wyłącznie z jednego powodu. Mianowicie, jego oferta była przygotowana w oparciu o metodykę SCRUM (zawierała m.in Rejestr Produktowy, Rejestr Zadaniowy), a konkurent wykonał ją w “tradycyjny sposób”. Ot, co znaczy zrozumieć potrzeby klienta …
Właśnie! Takie odniosłam wrażenie, że ten człowiek ma bardzo duże zrozumienie dla potrzeb klientów. Wydaje mi się, że wielu zapomina o tym i skupia się na produkcie, który ma powstać, nie rozumiejąc tak naprawdę istoty tego, po co to klientowi. A taka świadomość jest szalenie ważna, tym bardziej w Scrumie, gdzie nic nie przypomina nam o tym, żeby taką rzetelną analizę przeprowadzić 🙂
Sama nawet idea konferencji PAM Summit pokazała jak istotna w projektach prowadzonych metodykami Agile jest współpraca pomiędzy Kierownikami Projektu, Analitykami i Deweloperami. Dopiero połączenie tych ról, wiedzy i umiejętności, pozwala na efektywne prowadzenie projektów. Mam nadzieję, że środowisko będzie dążyć do większej synergii w tym zakresie.
Ze swojej strony cieszę się, że ktoś napisał taki artykuł. Jasno pokazuje on jak bardzo mylą się Ci, którzy właśnie upierają się, że w Agile nie powinny istnieć żadne dokumentacje.
Też mam taką wielką nadzieję 🙂 W każdym projekcie taka współpraca jest cenna, nawet dorzuciłabym tam UXa, jeśli ktoś miał okazję współpracować. Najważniejsze jest zrozumienie i komunikacja między wszystkimi uczestnikami projektu, a „jakaś forma dokumentacji” moim zdaniem obie te rzeczy bardzo wspiera, jako środek do celu.
Dobry analityk tworzy dokumentację i modele, które służą projektowi, nie są bezmyślmym wypełanianiem nadmiarowych szablonów.
Dobry analityk nie robi dwóch literówek w jednym zdaniu.