niedziela, 12 lutego 2012

Zbiór dobrych praktyk agailowych

Poniżej zbiór dobrych praktyk agailowych, które powinny znaleźć zastosowanie w większości projektów przez nas prowadzonych:
  • współpraca z klientem (customer collaboration)
    • bieżąca aktualizacja postępu prac
    • informacja co będzie zrobione w ramach sprintu
    • nieustanna komunikacja z zespołem w celu pewności dostarczenia wszystkich funkcjonalności 
  • budowa produktu (product backlog
    • podział produktu na małe kawałki możliwe do implementacji
    • duże funkcjonalności (epic) dzielone na wiele małych
    • oszacowanie pracochłonności potrzebnej na zrobienie danego kawałka 
    • priorytetyzacja w zalezności od potrzeb biznesowych klienta
    • najważniejsze finkcjonalności na górze listy 
    • utrzymywanie backlogu w porządku i ryzach, nie doprowadzać do przepełnienia
  • iteracyjne budowanie produktu (iterative development, sprints)
    • dobór na podstawie dostępych godzin zespołu ilości pracy możliwej do zrobienia
    • zespół sam decyduje ile jest w stanie zrobić, patrząc na swoje możliwości i  doświadczenie poprzedniej iteracji
  • ograniczenia czasowe (time boxed)
    • sztywny czas trwania sprintu (zazwyczaj od 2 tygodni do 1 miesiąca)
    • sztywny czas trwania scrum meetingów (codziennie około 10-15 minut)
  • analiza i definicja funkcjonalnosci (value stream analysis)
    • definicja produktu na user stories bazując na analizie biznesowej, aby nie ominąć żadnych wartości biznesowych
    • definicja zależności biznesowych oraz technicznych pomiedzy funkcjonalnosciami  
  • opisanie funkcjonalności produktu (user stories)
    • opis funkcjonalnosci bazując na komunikacji z klientem
    • opis z pozycji usera w specyficzny sposób (jako .... chcę ..... ponieważ... )
    • zawierające 3 najważniejsze sekcje (opis, kryterium akcepatcji oraz estymację czasową bazującą na złożoności) 
    • zbyt złożone rozbijane na mniejsze, aby mogły być jako całość zrobione w ramach kilku sprintów
  • opisanie funkcjonalności poprzez przykłady (user stories specified by examples)
    • opis user stories w sposób podany wyżej uzupełniony o przykłady które pokazują wszytskie opcje działania funkcjonalnosci oraz jej wpyw na inne
    • duży support dla deweloperów i testerów 
  • codzienne spotkania statusowe (scrum meetings)
    • codzienne poranne spotkanie, ok. 10 minutowe
    • prowadzone przez scrum mastera z całym zespołem
    • rozmowa o trzech kluczowych kwestiach (co zrobione od wczoraj, co zamierzamy robić dzisiaj oraz czy są jakies przeszkody aby spokojnie pracować)
    • dodatkowo programując w parach informacja kto z kim w parze
  • ciągła integracja kodu (countinous integration)
    • pozwala zachować kod up to date
    • kod poddawany weryfikacji zanim zostanie złączony ze starym kodem
    • ułatwia testowanie nowych user stories
    • po złączeniu wykonywane junit testy, sprawdzenie czy nie ma błędów
    • nastepnego dnia  wykonywany regression test, gdzie widać czy nowa funkcjonalność wpływa negatywnie na resztę kodu
  • automatyczne testy (automated tests)
    • regression test usuchamiany codzinnie przed przystąpieniem do prac upewniający która wersje kody są akceptowalne
    • szybka informacja który kawałek funkcjonalnosci nie działa zgodnie z załozeniami
  • programowanie w parach (extreme programming)
    • implementacja user stories w parach(primary i secondary)
    • praca eksperta z nowicjuszem, jeden właściciel user story, w parze niezmienny, drugi zapewnia support, może rotować 
    • dwie sesje deweloperskie dziennie, raz jeden raz drugi jest właścicielem user story
    • przeglądy kodu realizowane w parach
    • macierz par w celu oceny zespołów, wyników oraz częstości pracy razem
    • wyniki zazwyczaj lepsze niż praca dwóch deweloperów samodzielnie
  • development poprzez testy (test driven development)
    • programowanie począwszy od napisania testów akceptacyjnych, poprzedzaonych testami jednostkowymi, dopiero póżniej od pisania właściwego kodu opisującego user story
    • aktualizacja podczas spotkań scrumowych
  • wykresy wypalania (burndown charts)
    • wykresy pokazujące czy idziemy zgodnie z planem, z kalendarzem deweloperskim
    • pokazujący szybko harmonogram prac ws czas
    • pokazujący ilość wykonanych user stories per jednostka czasu, poniżej lub powyzej planu
  • demo sprintu (sprint demo meeting)
    • krótkie spotkanie pokazujące klientowi wykonane w ramach sprintu funkcjonalnosci i sposób ich działania
    • potwierdzenie prze klienta że akceptuje i że jest zrobione zgodnie z jego oczekiwaniami 
  • spotkanie retrospektywne (retrospective meeting)
    • spotkanie iteracyjne po skończonych dewelopmencie
    • udział obowiązkowy to cały zespół, moze uczestniczyć klient
    • rozmowy na temat możliwosci poprawy procesu, jakości pracy, narzędzi, lessons learned, itp
    • macierz z podziałem na sekcje stop, start i continue
  • działająca paczka po zakończeniu iteracji (shippable code)
    • zawsze działający kod po okresie developmentu
    • klient ma pewność że dostanie w krótkim czasie zakładaną wartość biznesową
  • planownie releasów (release planning) 
    • kalendarz releasów daje jasną informację dla wszytskich kiedy można sie spodziewać produkcyjnie nowych funkcjonalnosci
    • pomaga w prawidłowym wersjononowaniu kodu
    • wspiera testy automatyczne i integracje