środa, 9 grudnia 2009

Po Zwinnym Szkoleniu

W ostatni piątek i sobotę prowadziliśmy szkolenie ze Zwinnego Rozwijania Oprogramowania.
Cel był dość prosty - przekazać w te dwa dni jak najwięcej wiedzy dotyczącej zwinnych metodyk i  myślenia/filozofii z nimi związanej. Najważniejsze dla nas było zrobienie tego w taki sposób, który pozwoli kursantom zacząć wdrażać nowopozyskaną wiedzę już pierwszego dnia po szkoleniu. Opierało się więc ono w dużej mierze na warsztatach i ćwiczeniach.

Agenda szkolenia była następująca:
1) Wprowadzenie do Zwinnego Rozwijania Oprogramowania
Bazując na manifeście przekazaliśmy wszystkie główne myśli i zasady związane ze zwinnym myśleniem. Porównaliśmy zwinne metodyki z tradycyjnym "inżynierskim" podejściem. W ramach warsztatów pokazaliśmy, że zwinne metodyki dotykają wszystkich głównych problemów związanych z prowadzeniem i realizacją projektów programistycznych.
2) Scrum & eXtreme Programming
W tej części zaprezentowaliśmy dwie różne, ale zwykle używane komplementarnie zwinne metodyki: Scrum i XP. Staraliśmy się pokazać jak wypełniają one zasady zawarte w Manifeście. Przy okazji w ramach warsztatów z pomocą Scrum'a pisaliśmy wspólnie poezję :)
3) Zwinne praktyki programistyczne
Ta część przybliżyła założenia co do pisania oprogramowania związane z XP (TDD, programowanie w parach, Continous Integration), co to znaczy pisać Czysty Kod oraz opisała ideę Software Craftsmanship.
Krótki wykład zakończył się prezentacją połączenia TDD z programowaniem w parach (tzw. TDD ping-pong).
4) Zwinne Szacowanie i Planowanie
W ramach tej części pogłębiliśmy temat szacowania i planowania bazującego na Scenariuszach (User Stories), pokazaliśmy jak robić to w grupie (Planning Poker) oraz w jaki sposób wyceniać i planować iteracje i wydania. Nawiązaliśmy do tego jak mogą wyglądać umowy w zwinnych projektach i jak działać zwinnie w przypadku projektów fixed-time & fixed-scope. Pokazaliśmy jak liczyć prędkość zespołu i do czego można ją wykorzystać.
Zdobytą wiedzę wykorzystaliśmy do szacowania codziennych czynności takich jak pisanie smsów, czytanie książek czy wieszanie firanek :)
5) Zwinne zespoły
W tej części opowiadaliśmy o tym czym zwinne zespoły różnią się od zwykłych, co wpływa na efektywność pracy zespołu, co można zrobić, by zespół poprawiał jakość tak swoją jak i tworzonych przez siebie produktów. Pogłębiliśmy temat retrospektywy jako mechanizmu ułatwiającego zespołowi unaocznianie problemów i ciągłe poprawianie się. Na koniec przeprowadziliśmy warsztaty z prowadzenia retrospekcji.
6) XP Lego Game
Jako podsumowanie praktycznej części szkolenia zrealizowaliśmy kompletny projekt z wykorzystaniem planowania, szacowania i retrospekcji. Właściciel produktu weryfikował poprawność wykonania, wymagał refaktorowania części i dotrzymywania terminów. W ten sposób zrealizowaliśmy park z klocków lego:





7) Transformacja zespołów i organizacji
Ta, najbardziej teoretyczna część, dotyczyła wprowadzania zwinnych metodyk w istniejących zespołach, transformacji organizacji i sposobów pracy zwinnych zespołów z niezwinnymi działami. Dotknęliśmy zagadnień przekazywania odpowiedzialności i uprawnień związanych z projektem zespołom,  roli menagera, lidera i coach'a w zwinnych zespołach.


Retrospektywa
Na koniec szkolenia poprosiliśmy kursantów o wypełnienie ankiety, na podstawie której wyciągnęliśmy następujące wnioski (z powtarzających się komentarzy i ocen każdej z części oddzielnie):
Co się udało:
  • szkolenie bardzo się podobało - 98% uczestników uważało je za bardzo dobre
  • dwóch prowadzących o różnych temperamentach i punktach widzenia poszerzało perspektywę (zostaliśmy nazwani "dobry i zły glina" ;-))
  • wprowadzenie praktycznych warsztatów było dobrym pomysłem
  • projekt parku z LEGO był hitem :)
  • zrównoważyliśmy teorię z praktyką - zadowolone były zarówno osoby chcące poznać podstawy teoretyczne (już pracujące w Scrumie), jak i osoby bardziej oczekujące praktycznych informacji (zadowolenie z warsztatów i prezentacji TDD)
  • wszystko było prawie idealnie na czas
Co warto poprawić na następny raz:
  • lokalizacja bliżej centrum
  • salka szkoleniowa mogłaby być trochę większa
  • prezentacja TDD mogłaby być nie na koniec dnia, byłaby okazja podyskutować
  • prezentacja TDD powinna skupić się albo na refaktoryzacji, albo na drive'owaniu nowego kodu żeby była czytelniejsza
  • część poświęcona transformacji powinna mieć przykłady z życia wzięte

Na początku przyszłego roku planujemy otwarte szkolenie-warsztaty z TDD, na które już teraz zapraszamy.

Jesteśmy gotowi powtórzyć Zwinne Szkolenie dla konkretnych zespołów (jako szkolenie zamknięte), oraz zachęcamy do zgłaszania swojego zainteresowania udziałem w kolejnym takim szkoleniu otwartym, które pewnie odbędzie się też w pierwszej części przyszłego roku.

5 komentarzy:

  1. Szkolenie było świetne. Od poniedziałku chodzi mi i osobom z mojego Zespołu po głowach wprowadzenie choćby niektórych elementów agile. Do tego, zostałem zobowiązany przekazać wiedzę Zespołowi, także, ponieważ udostępniliście slajdy, będę mógł się wywiązać.

    Cały czas problemem jest przekonanie managementu do zmian i wprowadzania programowania w parach oraz refaktoryzacji. W pojęciu szefów, takie praktyki są niepotrzebną stratą czasu.
    Warto Waszą prezentację o "transformacji" rozszerzyć o jakiś gotowy, spisany pakiet argumentów, które uczestnicy mogą potem zanieść do swoich firm i szefów. Gdybyście jako materiał szkoleniowy przygotowali małą prezentację, którą potem można pokazać kierownikom, aby ich spróbować przekonać do agile, to byłoby super.

    Jeśli dobrze się orientuję, to było pierwsze szkolenie Pragmatists. Gratuluję udanego debiutu :)

    OdpowiedzUsuń
  2. Ja słyszałem o szkoleniu od koleżanki, która na nim była i innych osób z zaprzyjażnionej firmy, które w nim uczestniczyły. Zazdroszczę pomysłów budowania z lego w rytmie Agile :) Bez wątpienia hicior. Zdziwiła mnie jedna rzecz - wszystkim podobało się szkolenie ale chyba tylko jedna osoba uwierzyła w Agile i od następnego dnia od razu chciała budować u nas zwinny zespół. Pozostali stwierdzili że idea fajna, ale nierealna, coś jak socjalizm. No bo jak to commit na jeden login i kod wspólny? Nie wiadomo komu potem zmyć głowę za błąd ;) Ja w swojej naiwności sądziłem że wszyscy programiści pragną być członkiem zespołu Agile, tylko kierownictwo uważa Agile i programowanie w parach za fanaberię, hamując w rezultacie zapędy programistów. Jednak tak nie jest, co mnie bardzo zaskoczyło. Sami programiści nie wierzą, że to działa. Myślę jednak, że każda dusza programistyczna, która przeszła po Waszym szkoleniu na jasną stronę mocy to Wasz sukces :)

    OdpowiedzUsuń
  3. Dzięki Jacek za komentarz.
    Lego było oczywiście tylko pretekstem do zastosowania zwinnego procesu, mechanizmem pomagającym zastosować w praktyce kawałek wiedzy zdobytej w czasie szkolenia. Cieszę się, że się podobało, bo był to jeden z bardziej ryzykownych elementów szkolenia (z drugiej strony - kto nie lubi budować z lego?)

    Co do jednego loginu SVN to to jest mój autorski pomysł i nie jest zaleceniem żadnej zwinnej metodyki . Mówiłem o tym w kontekście adaptacji procesu i budowania zespołowego myślenia (właśnie nie chcemy, żeby ktokolwiek komukolwiek głowę mył, ale żeby każdy czuł się odpowiedzialny za cały kod). U nas z resztą ten pomysł się sprawdza.

    Co do niewiary programistów w zwinne metodyki, to tak fajny temat, że napiszę na ten temat oddzielny post :)

    OdpowiedzUsuń
  4. Paweł,

    Jeśli chodzi o pracę z kontrolą wersji w parach, to kiedyś natknąłem się na pomysł tworzenia tylu loginów ile jest kombinacji tworzących pary. Każda para pracuje na innym loginie. Gdybym ja z Tobą programował w parze, to na nasze potrzeby używalibyśmy loginu jz_pl. Przy zmianie pary, zmieniamy login na pasujący do kombinacji inicjałów.
    Wyczytałem to na blogu firmy Hashrocket http://blog.l4rk.com/2009/05/pair-programming-git-github-gravatar.html. Co sądzisz?

    OdpowiedzUsuń
  5. Tak naprawdę to zastanawiam się czy to ma jakikolwiek sens. Ja go nie widzę. Nad jednym zagadnieniem często pracuje więcej osób, czasem pary się miksują, czasem dwie pary robią różne rzeczy w ramach tego samego scenariusza. Co za różnica kto to commit'ował?
    Login w systemach kontroli wersji służy określaniu kto co zrobił (zwykle zepsuł...) My tego nie chcemy bo:
    - Kod jest wszystkich, i każdy musi go móc zrozumieć. Jak nie rozumie, to niech przepisze, bo niezrozumiały kod jest nieutrzymywalny.
    - Przerzucanie się winą działa przeciw zespołowi a więc i projektowi.

    A poza tym to dlaczego jz_pl? Ja uważam, że pl_jz, bo jestem lepszym programistą! ;-)

    OdpowiedzUsuń