7 wrz 2009

Pierwszy release

Dziś w Pragmatists mieliśmy pierwsze wdrożenie pierwszego projektu. To taki miły moment, kiedy jest wreszcie chwila na zastanowienie się jak poszło. Na przemyślenie co można następnym razem lepiej. Jak nie popełniać pewnych błędów, jak pomagać klientom nie wpadać w pułapki.

Projekt był hybrydowy - z naszej strony staraliśmy się robić wszystko zwinnie - zaczęliśmy klasycznie od ustalenia z klientem o co mu chodzi, utworzyliśmy masę User Stories, zrobiliśmy estymacje, backlogi, pracowaliśmy w parach, TDD, itp. itd. Z drugiej strony nasz klient, choć z grubsza chętny do zwinnego podejścia, jednak z własną historią i przyzwyczajeniami (bardzo niezwinnymi). I do tego z projektem, który miał już wyznaczony termin wdrożenia, choć jeszcze nie wiadomo było dokładnie co ma być zrobione. I to jest pierwsza pułapka i chyba bardzo częsta. Terminy rzadko ustala zespół. To często element negocjacji, jakby niemerytoryczny - ustalany między managerami i salesami. W naszym przypadku nasz klient naprawdę nie wiedział czego chce ich klient (który jest użytkownikiem aplikacji) poza ogólnikami i własnymi domysłami (z resztą błędnymi, więc po pierwszych 2 miesiącach pracy zakomunikowano nam, że trzeba zacząć od nowa i zrobić coś zupełnie innego :)). Myśmy na to przystali (no cóż, nie zdobywa się klientów od stawiania im warunków...) i skutek był taki, że ostatnie 4 tygodnie były zmaganiem z czasem, wymaganiami (prośba o ostatnią zmianę w aplikacji pojawiła się wczoraj, w niedzielę, o 22:30...) i stresem własnym i klienta.
To podstawowa różnica między projektem zwinnym a klasycznym - w zwinnym termin jest funkcją zakresu wymagań i prędkości zespołu. Dlatego staramy się dostarczać aplikacje przyrostowo, wtedy terminy przestają być kluczowe, bo klient zaczyna dostawać aplikację wcześniej i ma realny wpływ na jej zawartość, a więc również na termin kiedy zacznie ją wykorzystywać. A więc:
Action Point 1: zachęcić klienta do spróbowania teraz (po tych średnio miłych doświadczeniach ostatniego miesiąca) "naszego" sposobu - nie tylko pokazywać, ale dostarczać kolejne wersje aplikacji na produkcję co 2 tygodnie. Dzięki temu nie będzie gorączki przedwdrożeniowej, ale stały jasny dla wszystkich proces regularnego dostarczania już-nie-tylko-potentially shippable product'u (mamy zadbane środowisko CI, więc jakby się uprzeć, to z technicznego punktu widzenia moglibyśmy dostarczać nawet codziennie).
Kolejne doświadczenie to komunikacja. Tutaj mamy wciąż dużo do poprawy. To, że nie mamy bezpośredniego kontaktu z użytkownikiem wpływa na naszą niepewność co do tego, czego on może tak naprawdę potrzebować. Jak chciałby pracować z aplikacją. Np. dwa tygodnie przed wdrożeniem dowiedzieliśmy się, że użytkownik lubi na raz pracować z excel'ami o setkach wierszy, bo wtedy "wszystko widzi" - a nasz a'la-excel'owy mechanizm wspiera raczej nie więcej niż 50 wierszy.
Nasz klient jest 1300km od nas i sprawność komunikacji jest kluczowa. Maile nie zawsze starczają a cotygodniowe spotkania iteration review/planning nie dają nam odpowiedzi na kluczowe pytania: czy aplikacja się podoba, czy są zadowoleni (z aplikacji, postępu,itp.)
Action Point 2: Bardziej cisnąć o informacje w czasie planowania - w czasie trwania iteracji MUSIMY wiedzieć dokładnie co mamy robić i czemu to ma służyć.
Zespół = Ludzie + Interakcje. Widzę to codziennie. Są dni, kiedy widać jak na dłoni, że pracując razem stanowimy dużo więcej niż gdyby każdy pracował oddzielnie. Wpadamy na lepsze pomysły (bo dużo dyskutujemy, a więc projektujemy), tworzymy lepszy kod (bo wiele osób go czyta i pisze, a więc musi być zrozumiały), nakręcamy się do pracy (bo to nie tylko nasz chleb, ale głównie nasza pasja), zachęcamy się do nauki i ciągłego ulepszania samych siebie ("kuuuurde, chłopaki, ale książkę znalazłem...", "ej, Kamil, jest tam coś ciekawego w tym artykule?", "Paweł, w mordę, nie pisz takiego szitu, przecież to można ładniej zrobić!") Są dni, kiedy wychodząc z pracy dobrze rozumiem dlaczego moje dzieci płaczą, że nie chcą jeszcze wracać gdy ich odbieram z przedszkola.
Action Point 3: jeszcze więcej pracy w parach, jeszcze więcej dyskusji przy tablicy, jeszcze więcej chłonięcia wiedzy od siebie i wspólnego tworzenia nowej.
Testy, testy i jeszcze raz testy (automatyczne). To jedyny sposób robienia oprogramowania wysokiej jakości. To jedyny sposób żeby być pewnym, że możesz dostarczyć aplikację KIEDY TYLKO KLIENT ZECHCE. To jedyny sposób na uniknięcie długich niezrozumiałych metod i niejasnych rozwiązań. To jedyny sposób na weryfikowanie poprawności twoich pomysłów gdy aplikacja już się rozrosła (inaczej marnujesz długie godziny na klikanie i debugowanie). To w końcu jedyny sposób by móc sobie powiedzieć: zrobiłem (done) i jestem tego pewien. A to jedno z milszych uczuć jakie mamy w naszej pracy. Nie wierzę, że może twierdzić inaczej ktoś kto choć raz brał udział w tak rozwijanym projekcie (jest to zdecydowanie najwyższej jakości projekt w jakim brałem udział w życiu, a mam za sobą ponad 10 lat pracy w developmencie i pewnie ponad 20 projektów różnego rozmiaru za sobą).
Testy dają nam poczucie pewności a naszemu klientowi możliwość prawie dowolnego kształtowania i modyfikowania wymagań - a to przekłada się w prostej linii na jego przewagę nad konkurencją.
Action Point 4: weryfikacja (ciągła) pokrycia funkcjonalności testami (nie pokrycia linii kodu, ale pokrycia funkcjonalności) i dorabianie ich tam, gdzie ich brakuje.

Action Point 5: definiowanie zakresu iteracji za pomocą testów akceptacyjnych (A-TDD) - to dotyczy zarówno kwestii elastyczności wymagań, jakości produktu, jak i (a może przede wszystkim) komunikacji z klientem.
To tak z grubsza większość moich przemyśleń co do tego projektu. Widziałem w tym czasie zaangażowanie, kreatywność i pasję. Obserwowałem (a trochę może też wpływałem na) tworzenie się z grupy ludzi zespołu. Rodzenia się odpowiedzialności i poczucia wspólnego celu. Wiele jeszcze oczywiście przed nami. Ale przecież to zaledwie początek.

5 komentarzy:

ToJaJarek pisze...

Jako analityk czytam programistów często bo to mnie najwięcej nauczyło :) i tu znalazłem po raz kolejny dwa kluczowe błędy:
- "user story" to największa pomyłka analityczna moim zdaniem bo nie ma większej sieczki inforacyjnej niż takie "słowne produkcje"

- prototypowanie czyli "aż sie użytkownikowi spodoba" do prosta droga do pożarcia budzetu przed terminem

Nie jest to wylewanie na Was pomyj a raczej na osobe, która w taki projekt was wpuściła. Powyższy opis to opis tego "jak powstaja apliakcje gdy nie ma ich projektu".

Daleki jestem od dawania Wam rad bo każdy ma inne swoje doświadczenia. Moje mówi, że:

- przyszły użytkownik jest najgorszym źródłem informacji o wymaganiach, bo one czesto są tylko tym co chce w firmie uzyskać (ugrać) ten czy inny pracownik,

- wymagania powinien okreslać szef tego interesu (prezesi i dyrektorzy), nie prawdą jest, że nie wiedza czego chca bo wiedzą doskonale, prawdą natomiast jest że potrzebny jest ktoś kto zamieni hasło "zwiększenie sprzedaży o 10" na procesy, ich usprawnienie - także z pomoca nowego oprogramowania, nie spodziewajmy sie, że szeregowy pracownik firmy ja usprawni.

Tu ktos musi zrozumiec tych dyrektorow i napisać przypadki użycia nowego oproramowania uzupełnione modelem dziedziny i ograniczeniami (czyli analityk biznesowy).

Paweł Lipiński pisze...

Oj straszne to co piszesz. Aż nie wiem co odpowiedzieć :)
Tak jak pisałem w tym poście mam ponad 10 lat doświadczenia - jako programista, architekt, konsultant, audytor itp. Sam napisałem pewnie ponad 20, a widziałem cudzych parędziesiąt projektów. I z pozycji tego doświadczenia nie zgadzam się z tobą... no cóż - w pełni.
1) User story to bardzo dobry sposób opisu wymagań (polecam książkę Agile Estimation and Planning jeśli chodzi o szczegóły). Jest jasny i enduser-friendly, więc zrozumiały dla wszystkich. Jest konkretny, więc minimalizuje miejsce na błędy. Jest mierzalny (i oszacowany) więc pozwala określić pracochłonność vs. opłacalność oraz statystycznie planować zakres vs. czas wydań.
2) Nie pisałem nic o prototypowaniu. My dostarczamy działającą aplikację. Nad nieprzeżeraniem budżetu czuwa biznes (w Scrumie jest to Product Owner) i to on ocenia opłacalność (business value)
3) Sami się "wpędziliśmy" - taki mamy model firmy, tak chcemy pracować. Z resztą efekty mówią same za siebie - w ciągu w sumie 8 tyg (po tym, jak już klient się zorientował o co tak naprawdę mu chodzi) napisaliśmy i wdrożyliśmy aplikację. Właśnie policzyłem (choć to dużo nie mówi) - prawie 30k linii kodu.
4) To już herezja. Użytkownik JEST najlepszym źródłem informacji, bo to on ostatecznie z aplikacji korzysta i on jest ekspertem w swojej dziedzinie. To nie oznacza, że nie słuchamy managerów, ani że nie mamy własnych pomysłów, które mu przedstawiamy. Ale w 80% przypadków się mylisz. A co do ugrywania, to akurat rzadko faktyczny użytkownik aplikacji chce coś ugrać. Polityką jednak zajmuje się głównie kadra managerska.
5) No tu to już pojechałeś. Na prawdę prezes ma dużo innych rzeczy do roboty niż opracowywanie wymagań... Z drugiej strony z oczywistych względów sponsor POWINIEN mieć wpływ na zawartość aplikacji.

Nie twierdzę, że analitycy są zbędni. Twierdzę, że są dobrym materiałem na PO jeśli są merytorycznie bez zarzutu.

jnb pisze...

Paweł ma rację. Ale nie dziwię się że Jarek tego nie widzi. Jako były analityk, aktualny programista/architekt/etc. (czyli wszystko w kupie) mogę powiedzieć, że taki sposób pracy jest nieintuicyjny - trzeba go przeżyć, żeby dostrzec zalety (podobnie TDD i pair programming).

Ewentualnie trzeba przeżyć kilka gównianych projektów BDUF (big design up-front), gdzie po latach wychodzi nikomu nieprzydatny system i wyciągnąć wnioski :]

Tomasz Nazar pisze...

Gratulacje! Przyjemnie slyszec o fajnych zespolach i "zwinnych" sukcesach :)

Zdradzisz pare szczegolow o technologiach.. bo czasu to nie za duzo było, a macie automatyke testow [funkcjonalnych], CI, wiec troche w "infrastrukture" trzeba bylo zainwestowac. I sie zastanawiam w co wlasnie...

Paweł Lipiński pisze...

No to mamy tak: Hudson jako CI, Maven do budowania, SVN do trzymania, Tomcat do sprawdzania, Eclipse + NetBeans do developowania.
Testy mamy głównie jednostkowe (w tej chwili grubo ponad 700); trochę funkcjonalnych, ale te też w JUnit'cie; trochę integracyjnych (też JUnit).
Aplikacja Spring + Hibernate (choć tylko jakieś 50%, bo reszta to procedury składowane jeżdżące po hurtowni danych) na serwerze oraz NetBeans Platform dopięty Springiem w kliencie.
Aktualnie rozważamy wprowadzenie FitNesse'a do A-TDD, ale to zależy głównie od tego, czy klient będzie zainteresowany takim podejściem (wstępnie jest, ale wszystko może rozbić się o czas). Poza tym podepniemy teraz trochę statycznych analizatorów do Hudsona/Maven'a.