Po rozmowie z Arie van Bennekum, jednym z autorów manifestu Agile, Hania argumentowała dlaczego analiza nie kłóci się z podejściem zwinnym. Kiedy już wiemy, ze nie musimy toczyć wojen między analitykami i agile coachami, pojawia się jednak pytanie: Jak w praktyce prowadzić analizę w zwinnym projekcie?
Poniżej przedstawię proponowane przeze mnie podejście do wykorzystania analizy w projektach zwinnych, którego używam (i cały czas usprawniam ;)) w praktyce.
Założenia
Żebyśmy mieli jednak jasność o jakim środowisku mówimy, cztery założenia dotyczące większości realizowanych projektów IT:
- Projekt toczy się w środowisku klient-dostawca.
- Klient nie do końca wie czego chce – a właściwie nie wie czego potrzebuje. Mówiąc krótko, potrzebuje w projekcie pomocy.
- Ciężar zarządzania projektem spoczywa na barkach dostawcy – niestety rzadko spotykanym w Polsce podejściem jest realne zarządzanie projektem po stronie klienta.
- Mówiąc o projekcie zwinnym mam na myśli projekt w którym obie strony świadome są niepewności zakresu i otwarte są na zmiany. Są też gotowe do ścisłej współpracy i adaptacyjnego tworzenia oprogramowania. Nie chcę wskazywać tutaj konkretnej metodyki, tym bardziej że nie spotkałem się z podejściem czysto agilowym w środowisku klient-dostawca.
1. Poznaj cel
Zanim zaczniesz realizować projekt, trzeba się do niego przygotować – zrobić analizę. Zaraz, zaraz… Jaką analizę na początku? Przecież to waterfall, a nie agile! Żeby zacząć realizować jakikolwiek projekt, warto mieć chociaż jakąś zgrubsza określoną wizję tego co ma powstać i jaki cel ten projekt ma osiągnąć. Tę wizję powinien posiadać klient. W praktyce tu pojawia się problem. Bo choć zwykle zdaje on sobie sprawę z tego jaki cel chce osiągnąć, to już z wizją rozwiązania jest dużo gorzej. Najczęściej wręcz nie znając się na IT, sugeruje rozwiązanie (np. system używany przez konkurencję), które osiągnięcia tego celu nie zapewni.
Dlatego warto, nawet w projekcie agilowym, na początku klientowi pomóc i zrobić analizę. Mówiąc o analizie, nie chodzi tu o zebranie i wyspecyfikowanie wszystkich wymagań, jak to ma w zwyczaju wiele firm IT (i wtedy powstaje system, którego klient chce, ale nie potrzebuje; albo w połowie projektu trzeba wszystko zaorać i zrobić ponownie). Efektem odpowiednio przygotowanej analizy, powinno być:
- jak najlepsze zrozumienie celu biznesowego klienta – nie jak ma działać oprogramowanie tylko po co klient w ogóle podejmuje ten projekt.
- jak najlepsze zrozumienie biznesu klienta i określenie obszarów tego biznesu, które mają ulec poprawie/zmianie dzięki projektowi. I tu pomocna okazuje się klasyczna analiza biznesowa.
- nakreślenie wizji rozwiązania – nakreślenie rozwiązania, które pozwoli osiągnąć wskazane cele i które wpisuje się organizację klienta
- mając już kompetencje techniczne warto trochę mocniej pochylić się nad kluczowymi dla architektury elementami przyszłego systemu (aby w połowie projektu nie okazało się, że architektura systemu nie pozwala na pewne rozwiązania)
Wszystkie te działania mają prowadzić ostatecznie do zrealizowania 2 celów: lepszego zrozumienia na linii klient-dostawca oraz powstania wstępnego backlogu projektu (korzystając z nomenklatury scrumowej). Nie ma najmniejszego sensu tworzenie na tym etapie rozbudowanej i szczegółowej specyfikacji funkcjonalnej – i tak zostałaby ona wywrócona do góry nogami. Warto natomiast opracować już bardziej szczegółowo pierwszą iterację pracy zespołu IT (o tym za chwilę).
Wstępna analiza powinna trwać możliwie jak najkrócej, ale wystarczająco długo żeby zrealizować powyższe 2 cele. Idealnie, gdyby od początku prac koncepcyjnych, po stronie klienta uczestniczyła osoba techniczna znająca rynek lub po prostu niezależny konsultant. Dostawcy IT mają, całkiem zresztą słuszną z punktu widzenia ich biznesu, tendencję do proponowania własnych, niekoniecznie najlepszych dla klienta, rozwiązań.
C.D.N. W kolejnej części: szacowanie i dzielenie na iteracje, przygotowanie iteracji oraz jej realizacja.
