Zabawy ze SCRUM

Jakiś czas temu wystartowaliśmy z nowym projektem (jeszcze nie mogę powiedzieć czego dotyczy), w którym mamy więcej wykorzystanych praktyk z kategorii Agile niż inne do tej pory.

Przede wszystkim – iteracje (trzytygodniowe).
Właśnie zakończyliśmy pierwszą. Odbyła się prezentacja iteracji, na której niestety nie było klienta. Był za to szef w roli klienta wewnętrznego- to on bywał na spotkaniach z klientami, więc był najlepszym substytutem na jaki nas było stać.

Ze scrum używamy dziennika zaległości produktowych (product backlog), który ciągle się rozrasta. Na razie sukcesem jest to, że przed końcem pierwszej iteracji w dzienniku mieliśmy wystarczająco elementów, żeby zacząć następną.

Tak wygląda wykres burndown dla zakończonej właśnie iteracji:
iteracja1_burndown_chart

Staramy się stosować stopniowe zbieranie wymagań i stopniowy rozwój architektury z tym, że to drugie przetestowaliśmy już wcześniej w mniejszych pod-projektach. Pomijając fakt, że jest to zwyczajnie przyjemne podejście – gdybyśmy chcieli zebrać wszystkie wymagania, to trwałoby to do końca października. Gdyby jeszcze do tego projektować wszystko “z góry” – następny miesiąc by minął do startu projektu.

Po pierwszej retrospekcji doszliśmy do wniosku, że zbyt mało energii zostało włożone w etap planowania iteracji. Tym razem bardziej się na tym skupiliśmy. Jednak efekty, jeśli będą widoczne, to dopiero podczas kolejnej iteracji.

Udało nam się też wykonać krok w kierunku ciągłej integracji (CI):
- używamy MySchemaShell do migracji struktury bazy danych
- własnego narzędzia dla startowych danych testowych (też programik Shell) + do generowania obiektów ACL
- Selenium dla prostych (na razie) testów interfejsu, dla zabezpieczenia się przed sytuacją, gdy jest dwie godziny do prezentacji iteracji, nie ma odważnego do przeklikania systemu w celu znalezienia wpadek. No i te wpadki znajduje klient. Te testy trochę trwają, ale na pewno mniej niż ręczne “śmiganie po stronie”.

Co do testów jednostkowych – na razie jest plan, aby umieszczać je w krytycznych miejscach. Co w praktyce oznacza testowanie reguł biznesowych umieszczonych w warstwie modelu.

Jeśli pojawi się więcej ciekawostek – na pewno nie omieszkam napisać.

Jaką książkę warto przeczytać, aby poznać Agile?

Z racji mojej magisterki i zainteresowań trochę książek o tej tematyce mam za sobą (na szczęście “za” ;)). Dlatego chętnie podzielę się swoimi doświadczeniami polecając trzy pozycje:

  1. Agile Software Development. Gra zespołowa. Alistair Cockburn
    Agile Software Development. Alistair Cockburn

    Agile Software Development. Dużo teorii i dużo informacji



    Bardzo dobra pozycja, choć dość trudna w odbiorze. Charakteryzuje się dość wysokim poziomem abstrakcji. Ale dzięki niej można zrozumieć dlaczego agile działa, a nawet kiedy nie działa i dlaczego. Autor jest też twórcą rodziny metodyk Crystal i z tej książki dowiesz się o nich co nieco. Jeśli na temat stosowania Agile chcesz poznać wszystkie sekrety i mechanizmy stojące za jego siłą – to pozycja dla Ciebie. Jeśli nie jesteś gotowy na teoretyczną przeprawę – rzuć okiem na pozycje poniżej.

  2. Agile Development. Filozofia programowania zwinnego. James Shore, Shane Warden
    Agile Development. Shore, Warden

    Agile Development. Równowaga między teorią a praktyką stosowania XP


    To nieco lżejsza pozycja, bardziej traktująca o tym jak używać (w tym przypadku XP), a nie jak działa. Z tej książki poznasz dokładnie wszystkie elementy XP, łącznie z tymi najbardziej subtelnymi. Dowiesz się dlaczego programowanie w parach jest równie skuteczne, co dziwaczne (na pierwszy rzut oka). Jeśli jesteś szefem programistów – zrozumiesz dokładniej co programiści robią podczas pracy. Dowiesz się, że jeśli nie klepią w klawiaturę, to jeszcze nie oznacza, że nie pracują. Pozycja obowiązkowa dla tych, którzy chcą z powodzeniem stosować XP. Dla osiągnięcia mistrzostwa prawdopodobnie po pół roku używania XP warto by do niej wrócić.
  3. Head First Software development. Dan Pilone, Russ Miles
    Head First Software Development. Pilone, Miles

    Head First Software Development. Zestaw praktyk w lekkiej i przystępnej formie


    Najlżejsza pozycja w zestawienia, jednak również wartościowa. Nie przedstawia z sobą żadnej konkretnej metodyki. Choć może raczej nie przedstawia żadnej nazwanej metodyki. Jest to zbiór prostych praktyk, które usprawnią działanie Twojego zespołu. Przykłady zamieszczone są w języku Java, ale pozycja przydatna nawet dla tych co Javy nie znają (jak ja, kiedy zaczynałem tą książkę czytać). Wiele ćwiczeń, pytań i wszystkiego, co sprawi, że nawet jeśli zdiagnozowano u Ciebie ADHD – wciągnie Cię i niewielkim wysiłkiem poznasz podstawy zwinnego wytwarzania oprogramowania.
  4. Miłej lektury.

    Ps. jeśli sam(a) chcesz mi coś polecić – wrzuć to koniecznie do komentarza – nie mogę się doczekać.

Refactoring pracy magisterskiej

Sobota (wczoraj)

http://helion.pl/view/4113g/agilsd.htm

To było jak olśnienie. Okazuje się, że refactoring to nie jest coś co tylko programiści mogą robić. Oto jak było.

Od miesiąca nie przybyło w mojej pracy magisterskiej więcej niż 2 strony. Nie mogłem się zabrać. Jak się zabierałem – szybko kończyły mi się pomysły, nie miałem ochoty więcej rozwijać wątków. Miałem wrażenie, że nic nowego tam nie dodam. Aż wczoraj wracając z wykładu przedmiotu “Koncepcje zarządzania” (o Lean management, banchmarkingu, outsourcingu itp. – inspirujące tematy) pomyślałem, że trzeba coś z tym zrobić.

Miesiącami już czytam o zwinnym wytwarzaniu oprogramowania. Niedawno w książce “Agile Software Development. Gra zespołowa” doszedłem do miejsca, w którym autor, Alistair Cockburn, opisał jak wykorzystał podejście zwinne przy rozbudowie domu (!). Wracając ze wspomnianego wykładu pomyślałem- skoro piszę pracę o zwinnym wytwarzaniu (oprogramowania), to może napiszę ją w sposób zwinny?

Po pierwsze postanowiłem znokautować swój pierwszy problem: nie wiedziałem na jakim etapie jestem. Brakowało mi informacji mimo, że mój zespół składał się tylko ze mnie – potrzebowałem radiatora informacji mimo, że jedynie ja miałbym z niego korzystać. Kupiłem korkową tablicę (miałem ochotę na “suchościeralną”, ale a/ była sobota i jeden sklep papierniczy był otwarty w okolicy b/ to wersja ekonomiczna: 60x40cm ok.20zł). Po powrocie do domu, przy pomocy dratwy przymocowałem ją do regału nad monitorem. Jest “Wystarczająco stabilna”

Miałem już radiator, teraz pora zacząć od podstaw: ustalić misję, cel projektu. Na niedużej kartce (takiej do notowania) napisałem mazakiem “Cel pracy”
i przykleiłem do niej 3 karteczki z powodami dla których w ogóle się tym zajmuję, zamiast na przykład wspinać się po górach. Po chwili uznałem, że warto ustalić im ważność. Dopisałem w nawiasie “wysokość ma znaczenie” i narysowałem podziałkę ;). Poniżej wrzucę efekty, jak tylko będę miał w rękach aparat.

Po drugie potrzebowałem “opowieści”, głównie po to, aby móc stosować “energiczną pracę”. Znam siebie na tyle, że wiem iż kiedy mam niepustą kolejkę zadań do wykonania – wtedy pracuję wydajniej. Zawsze mogę sięgnąć po następne zadanie – nie tracę czasu na zastanawianie się “co teraz?”. Na tablicy pojawiły się karteczki z nazwami danych obszarów: “Do zrobienia”, “W trakcie”, “Zrobione” :)

Postanowiłem postawić sobie krótkie zadanie do wykonania, aby szybko otrzymać nagrodę w postaci jego wypełnienia. Cały czas tytuł mojej pracy nie był ostateczny. Choć należałoby powiedzieć raczej, że był bardzo wstępny. Źle się z tym czułem, bo też mi się nie podobał, trącił trywialnością. Brzmiał “Możliwość zastosowania Zwinnej metodyki budowania aplikacji internetowych w firmie X”. Nawet gdyby zmiana tytułu miała polegać na zmianie błędu “zwinnej metodyki” na “zwinnych metodyk” – to był sukces, którego potrzebowałem.
Jednak podczas wypełniania karteczki z opowieścią, w której chciałem opisać mniej więcej co jest do zrobienia pojawił się pomysł i zanotowałem:

Może warto zmienić na “Nowoczesne metodyki wytważania wytwarzania oprogramowania; Agile; możliwość zastosowania w mikroprzedsiębiorstwach na podstawie firmy X”

Potem dokleiłem karteczkę “elasyczne, zwinne zamiast *nowoczesne*” i drugą “drugi temat pozwala skupić się na Agile zamiast na firmie”.

Efekty mi się podobały. Pomyślałem, że ta zmiana powinna zostać skonsultowana z moim promotorem. Zmniejszyłem nieco obszar “Zrobione”, który nie jest istotny pod względem informacyjnym – rosnący tam pęk zadań ma sprawiać, że będę się czuł pracowity :D; dodałem obszar “Skonsultować z promotorem” i tam wbiłem zadanie z tytułem.

Przyszedł czas na zadanie numer dwa. Jakiś czas temu M (nie wiem, czy pozwoli ujawnić swoje imię), kolega z pracy, zagaił mnie o magisterkę. Sam jest prawie rok po obronie. W dyskusji wyjawił, że gdy już miał spis treści – bardzo łatwo mu się pisało, gdyż po prostu pisał o tym o czym dany podrozdział miał traktować. Ja miałem odczucie, że mój spis treści jest zabałaganiony. Dlatego zadanie numer 2 brzmiało: “Uporządkować spis treści”.

Spis treści jest krajobrazem mojej pracy, dlatego go wydrukowałem, aby móc nad nim kontemplować. Wyglądał mniej więcej tak:

    Wstęp

  1. Zapotrzebowanie na metodyki
  2. Ogólnie o metodykach
  3. Przykłady metodyk zwinnych
  4. Typowe problemy w firmie X
  5. Metodyki zwinne (Agile)
  6. Konfrontacja teorii z rzeczywistością

Po pierwsze postanowiłem połączyć rozdział 2 z 3 – w końcu były niemal o tym samym. A treść zawarta w rozdziale 2 sprawiała, że nie miałem o czym pisać w rozdziale 3. To samo tyczyło się rozdziałów 4 i 6 – nabazgrałem między nimi linię opatrzoną opisem “połączyć”.
Rzuciłem okiem na nowy pomysł tytułu, który mi się spodobał bardziej. Pomyślałem, że fajnie przesunął ciężar pracy z implementacji metodyki w firmie X, na opisanie metodyk zwinnych. Pomyślałem, że spis powinien oddawać kolejność zaproponowaną w tytule, tym bardziej, że tytuł oddawał to o czym chciałem pisać. Nabazgrałem kilka strzałem z przesunięciem rozdziału 5 na przedostatnią pozycję. Teraz spis miał sens – drzewa były “zielonym do góry;)”. Policzyłem jeszcze ile będzie “nowych” rozdziałów, żeby ich nie było za mało. Z 8 liczba spadła do 6. Projekt uległ uproszczeniu, stał się bardziej przejrzysty.

Zatem zabrałem się za przenoszenie akapitów w pracy w taki sposób, aby wygenerowany spis treści był taki jak chciałem. W trakcie tych czynności pomyślałem, że przeprowadzam właśnie refactoring mojej pracy magisterskiej. Ucieszyłem się i z tej radości napisałem “refactoring :)” na przylepnej, żółtej karteczce i ustawiłem sobie opis na skype “refactoring pracy magisterskiej”. Taka była moja radość.

Gdy skończyłem – wpiąłem zadanie w miejsce “Skosultować z promotorem”; wygenerowałem dwa pdfy ze starym i nowym spisem treści i wysłałem maila do doktora B, z nowym pomysłem tytułu, uzasadnieniem i spisami treści.

W międzyczasie pojawił się pomysł na kolejne zadanie. Otóż czytając książki (źródła ;)) nauczony doświadczeniem – sporo bazgrałem, zaznaczałem ciekawe fragmenty itd. Gdybym tego nie zrobił – straciłbym przemyślenia, które pojawiały się podczas czytania (często w krakowskich tramwajach). Nie miałbym też ochoty drugi raz brnąć przez lekturę (nie chodzi o to, że nieciekawą – ale mam znam kilka większych przyjemności niż czytanie dwa razy tej samej książki, na przykład przeczytanie dwóch książek raz :D).

Teraz miałem 6 książek: 2 przeczytane w całości (w tym “Marsz ku klęsce” Yourdona), jedną przeczytaną tak daleko jak wydało mi się konieczne, 2 w trakcie czytania oraz jedną ledwie liźniętą. Łącznie mają już w sobie kilka dobrych gram grafitu ołówków z ikei (mały czasem może więcej). Problem polegał na uporządkowaniu tej wiedzy. Trzecie zadanie “Uporządkowanie źródeł” zostało wbite w strefę “do zrobienia”. Pojawiło się na niej 6 karteczek – jedna dla każdego tytułu.

W międzyczasie moja ukochana wróciła z zajęć, więc praca była tego dnia skończona. Całe szczęście – nie przeszkadza jej spora tablica korkowa zasłaniająca pół regału :D

Niedziela.

Zabrałem pierwszą i wkleiłem w miejsce “W trakcie”. Przeglądałem wypatrując zakreśleń, gdy je namierzałem – opisywałem o czym jest i wklejałem zakładkę. Mniej więcej w połowie przyszedł czas na przerwę: picie zimnej kawy, głośne słuchanie muzyki, telefon do przyjaciela (serio).

Teraz karteczka “Cockburn” jest skreślona (znaczy skończona) i wróciła na kartkę opowieści. Zabrało mi to nieco ponad 3 godziny. Jednak na pierwszy ogień postanowiłem wziąć zadania trudniejsze, żeby po dwóch największych skarbnicach grafitu mimo zmęczenia móc na luzie dokończyć pracę. “W trakcie” jest teraz Shore, ale zanim zacznę – miałem ochotę napisać ten post.

Teraz wracam do porządkowania źródeł. Gdy w tej sprawie coś się pojawi jeszcze ciekawego, na pewno o tym napiszę.