Archiwa tagu: scrum

Czego nauczyła mnie praca w Scrumie?

Piszą i mówią o Scrumie wszyscy, od lat wydaje się być nieprzemijającą modą. Zanim zaczęłam pracować w jakiejkolwiek metodologii Agile, byłam wielką entuzjastką;) Po jakimś czasie okazało się, że nie jest jednak tak kolorowo. Nie przepadałam za pracą w systemie Scrum – zwłaszcza w nieco tępym wydaniu korporacyjnym, gdzie sporą część czasu przeznaczonego na pracę zajmuje „proces” – przeciągające się ponad miarę spotkania, z których nic nie wynika; rozproszenie odpowiedzialności; ciągłe kłótnie itd.). Nie mi oceniać, dlaczego system czasem tak bardzo nie działa, że aż zgrzyta. Na szczęście są i jasne strony, a sam Scrum wielu dobrych rzeczy mnie nauczył.

Retrospektywy

Weźmy takie retrospektywy – niby takie spotkanie-zapchajdziura, siądziemy i pogadamy, a potem się rozejdziemy i tyle. Jednak dobrze poprowadzone retro okazuje się być całkiem niezłym narzędziem. Pod warunkiem wprowadzenia pewnej dyscypliny: z każdego, nawet luźnego narzekania sporządzamy notatkę, a następnie wspólnie zastanawiamy się, co można zrobić, aby to ulepszyć? Gdy już wymyślimy rozwiązania i rozejdziemy się do biurek, nadchodzi druga, najważniejsza część – realizacja! Zatem działamy, najlepiej krok po kroku, z rozbiciem na mniejsze fragmenty. Szukamy w zakresie strefy własnego wpływu, a dopiero jeśli działania nie przyniosą skutku, pójdziemy dalej. Na następnych retrospektywach przeglądamy sporządzoną wcześniej listę – czy coś się poprawiło? A może w jakiś kwestiach jest gorzej?

Dodatkowe narzędzia

Jeszcze ciekawiej jest, jeśli do tego typu działań zaprzęgniemy narzędzia coachingowe, takie jak np. koło życia. Oczywiście jesteśmy na płaszczyźnie biznesowej, zatem rubryki będą nieco inne, niż typowo się je przedstawia 😉 Warto po prostu zainspirować się i pamiętać, że na wydajność w pracy ma wpływ wiele czynników. Mogą to być np.: zadowolenie z zadań, rozwój, finanse, relacje w zespole, otoczenie itd. W każdej z tych dziedzin można szukać usprawnień – continuous improvement zobowiązuje 😉

Życie!

Lubię przenosić tą praktykę na obszar prywatny. Ktoś wciąż jęczy i narzeka? Ok! Biorę kartkę (lub smartfona) i zaczynamy zastanawiać się, co zatem można poprawić. Niektóre osoby są naprawdę w szoku – to tak można żyć? 🙂 Można, do czego zachęcam* 🙂

* Podpisano: Największa Maruda Świata.

Scrum kontra złożoność

Niedawno podawałam garść ciekawych informacji na temat metodologii Scrum. Dziś kontynuacja tego tematu.

Często słyszy się, że ta metodologia pracy nie jest dla każdego zespołu. Pewnie tak. Na jednym ze szkoleń widziałam ciekawy wykres obszarów złożoności pracy:

Scrum in complexity?

  1. Simple – dziedzina dobrze znana – tu sprawdzają się tzw. najlepsze praktyki, zalecenia z poradników itd.
  2. Complicated – dziedzina znana, ale trudna. Sprawdzają się dobre praktyki, ogólne „zalecenia”.
  3. Complex – dziedzina bardzo złożona, nie można powiedzieć, czy dane działania odniosą sukces czy nie. Metodą pracy są głównie eksperymenty – właśnie tutaj najlepiej działa Scrum!
  4. Chaos.

Krzywa uczenia

I dodatkowo: krzywe uczenia się w zależności od złożoności problematyki:

Krzywa uczenia sie w Scrum

  1. Simple – continuous improvement. Wystarczy po prostu działać, powtarzać – uczenie się jest proste, bez większych problemów.
  2. Complicated – continuous improvement – powiedziałabym: wzloty i upadki.
  3. Complex – continuous adaptive – błądzenie jak we mgle 😉 Jeden eksperyment zbliży nas do rozwiązania, inny oddali. Pamiętajmy, że adaptacja leży w głównych założeniach metodyki Scrum 🙂

Podstawy Scruma

Niedawno miałam przyjemność uczestniczyć w bardzo ciekawym szkoleniu na temat metodyki Scrum. Dowiedziałam się m.in. jakie są podstawy Scruma.

Podstawy Scruma

Podstawy Scruma

Sam Scrum pewnie znany jest większości osób, które mają styczność z wytwarzaniem oprogramowania. Myślę, że metodyka ta swoją popularność zawdzięcza głównie temu, że narzuca pewną strukturę zarządzania pracą/czasem/zespołem, jednocześnie dając wolność adaptacji do własnych potrzeb. Cechy te podkreślają filary, na których opiera się Scrum, zwłaszcza ostatni:

  • Transparency – przejrzystość
  • Inspect – inspekcja
  • Adapt – adaptacja!

Podstawową wiedzę na temat Scrum warto czerpać z oficjalnego podręcznika. Jest dostępny po polsku tutaj: http://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Polish.pdf. Kopia: [2016-Scrum-Guide-Polish]

Framework

Scrum to framework – co to oznacza w praktyce? Podręcznik przedstawia to tak: Scrum to „baza”, ramy, na których zespół buduje swoją własną „implementację”. Na bazę składa się naprawdę niewiele elementów. Są to:

  • Zespół i role: Product Owner, Scrum Master oraz zespół developerski: programiści, testerzy, graficy, analitycy biznesowi itd.,
  • Zdarzenia: Sprint (przebieg), Sprint Planning (planowanie przebiegu), Daily Scrum (jak idzie praca nad celami?), Sprint Review (demonstracja i inspekcja przyrostu pracy), Sprint Retro (czego się nauczyliśmy?),
  • Artefakty: Product Backlog, Sprint Backlog i cel Sprintu,szkolenia scrumowego
  • Reguły: łączące wszystkie elementy tej układanki.

Dodatki

Pozostałe praktyki, jakie często kojarzone są ze Scrumem, są tylko dodatkiem, implementacją, zestawem dobrych praktyk. Nie są składnikiem frameworka. Przykłady:

  • Planowanie Sprinta za pomocą kart do Scrum pokera,
  • Pozycja stojąca podczas Daily Scrum,
  • Spotkania groomingowe – backlog refinement to nie tylko spotkania, ale także praca własna nad backlogiem! Zespół powinien spędzić nad tym tematem 10% czasu, przygotowując się do kolejnego sprintu – ten czas można przeznaczyć np. na szukanie technologii do realizacji przyszłych zadań itd.

Ciekawą rzeczą, jaką wyniosłam ze szkolenia była informacja, że podczas Sprintu zespół powinien dostarczyć całą, lecz uproszczoną funkcjonalność! Niedopuszczalne jest zatem np. wykonanie części prac w bazie danych, ale niezrobienie niczego w interfejsie. Zadania powinny być zatem upraszczane, a nie dzielone. Ciekawa zasada, chyba nie zawsze jednak respektowana.

BDD, TDD, FDD i inne

Garść terminów na temat kilku metodyk zwinnych. Pochodzą z moich notatek do egzaminów i rozmów kwalifikacyjnych:)

 

Programowanie zwinne (Agile) – iteracyjno-przyrostowa metoda wytwarzania oprogramowania.Zakłada częsty kontakt z klientem, dostarczanie co jakiś czas kolejnych (działających!) fragmentów systemu. Proces:

  1. określenie wymagań, wykonanie ogólnego projektu całości
  2. wybór podzbioru funkcjonalności
  3. szczegółowy projekt podzbioru
  4. implementacja podzbioru
  5. testowanie podzbioru
  6. dostarczenie podzbioru
  7. powrót do punktu 2. aż do zakończenia projektu.

Manifest Agile:
Ludzie i interakcje ponad procesy i narzędzia
Działające oprogramowanie ponad obszerną dokumentację
Współpracę z klientem ponad formalne ustalenia
Reagowanie na zmiany ponad podążanie za planem

 

Scrum – jedna z najbardziej znanych metodyk zwinnych. Podstawowe założenia:

  • Czas realizacji projektu jest podzielony na mniejsze odcinki trwające od tygodnia do miesiąca (sprinty). Każdy sprint to jedna iteracja procesu, po której dostarczona zostaje kolejna wersja oprogramowania.
  • Lista wymagań, spisana jest w formie user stories (jak w BDD, patrz niżej), zbiór ten to backlog.
  • Zespół projektowy składa się z różnych ról: programiści, testerzy i inni wykonawcy, scrum master zarządzający procesem, product owner który zna wymagania użytkownika i jest ogniwem łączącym klienta z zespołem.
  • Zespół jest samoorganizujący się. Nie ma kierowników, każdy sam wybiera sobie realizowane zadania.

Proces:

  1. Przed rozpoczęciem iteracji, zespół na sesji groomingu przegląda backlog produktu, dzieląc zadania na mniejsze fragmenty i przypisując im punkty (story points), będące miarą złożoności zadania. Mogą używać do tego kart do Sprint pokera, czyli kart ze zdefiniowaną ilością punktów (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, nieskończoność).
  2. Na początku iteracji zespół planuje sprint (sprint planning), wybierając funkcjonalności, które będzie realizować – przerzuca je z product backlogu do sprint backlogu. Dzięki prowadzeniu statystyk i przedstawieniu każdego zadania za pomocą punktów, wiadomo ile mniej więcej zadań może wziąć na siebie zespół.
  3. Podczas trwania sprintu, zespół wykonuje zadania. Może kontaktować się z product ownerem w celu uzyskania dokładniejszych wyjaśnień itd.
  4. Każdego dnia odbywają się maksymalnie 15-minutowe spotkania podsumowujące co udało się zrobić wczoraj, co jest planowane na dziś, jakie są problemy. (Daily Scrum / stand up).
  5. Sprint kończy się spotkaniem podsumowującym (sprint review), w którym uczestniczą wszyscy zainteresowani (nawet klienci!). Prezentowana jest kolejna wersja produktu (demo).

 

TDD (Test Driven Development) – podejście, w którym najpierw pisze się testy (jednostkowe), a następnie funkcjonalności we właściwym programie. Dzięki TDD możliwe jest uzyskanie wysokiego pokrycia testami (test coverage).

  1. Pisanie testu jednostkowego do żądanej funkcjonalności. Test failuje, ponieważ nie ma jeszcze kodu programu.
  2. Implementacja funkcjonalności. Test przechodzi.
  3. Refaktoryzacja kodu.

 

FDD (Feature Driven Development)

  1. Budowa ogólnego modelu
  2. Budowa listy „cech”. „Cechy” są:
    1. niewielkie
    2. użyteczne
    3. zdefiniowane jednym zdaniem (np.: „rezerwacja pokoju”).
    4. grupowane w obszary funkcjonalne (np. „system rezerwacji hoteli”).
  3. Planowanie wg cech. Wskaźniki:
    1. priorytet
    2. pracochłonność
    3. ryzyko
  4. Projekt wg cech
  5. Implementacja wg cech
  6. Kroki 4. i 5. są powtarzane iteracyjnie. Po każdej iteracji wydawana jest wersja dla klienta.

 

BDD (Behavior Driven Development) – rozwijanie oprogramowania od strony wymagań użytkownika. Wymagania są przechowywane w postaci historyjek (user stories) w formie:

Jako powracający użytkownik
Gdy wpiszę szukany przedmiot
Pod listą wyników widzę swoje poprzednie wyszukania

Opis jest realizowany wg punktów:

given - warunki początkowe, aktor, kontekst
when - akcje, wydarzenie
then - oczekiwane rezultaty

User stories są niezwykle popularną formą przechowywania wymagań także poza BDD, o czym świadczyć może choćby popularność takich frameworków jak Cucumber, JBehave.

Czytaj dalej

Jak wygląda praca w zespole Silverlighta?

Dziś krótko bo tylko link do filmu z lubianego przeze mnie serwisu Virtual Study:

http://virtualstudy.pl/component/content/article/274.html

Tytuł to:

Jak Microsoft testuje Silverlight’a? – 53 spotkanie KDG.NET – Sesja 2

Gość (pracujący w Microsofcie) opowiada, jak wygląda u nich praca przy kolejnych wersjach Silverlight a także o testach, jakie wykonują. Warto przesłuchać, choćby wieczorem po pracy:)