21 wrz 2009

Agileee retrospective

This post is in english, since the conference was mainly in english (and maybe some agileeestas would like to read it.)

So, the conference was simply great. Maybe not perfect, but great.
I even had a little influence on its shape by having a talk there (the slides are here...)

So let me summarise it:

WHAT WAS GOOD:
  • venue
  • lunch
  • keynotes (Jutta Eckstein with her 'distributed agile' talk - have heard her already twice with a similar subject before, but there's always something new; David Hussman with a really touching closing talk underlining how important it is to follow what you believe in)
  • many talks
  • speaker's night out (and I thought that Poles drink a lot...)
  • lots of nice, clever and experienced people
  • ratio: cost / value 


WHAT COULD BE BETTER:
  • coffee and water not always available 
  • some talks really for agile-beginners (maybe there should be some 'experience level' mark by each talk, so that you go to the level you're at)
  • stage in Russian (I mean I could be better and speak Russian, there must have been a lot of valueable stuff, otherwise unavailable for a non-ex-soviet-country guy)


PLANS TO HAVE A BETTER AGILEEE IN FUTURE:
  • learn Russian
  • don't loose the conference schedule and read in advance where you plan to go to
  • meet even more people on corridors


So in total I'd say 8/10 (just to leave the organisers some place for kaizen...)
I really hope to be there next year, and wish it to you all!

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.