21 lutego 2015
Maciej Wilmiński
User Stories Applied for Agile Software Development – Mike Cohn
Mike Cohn
User Stories Applied for Agile Software Development
2004
Pearson Education Inc.
„User Stories Applied – for agile software development” Mike’a Cohna, to książka, która wiele po tytule i autorze obiecuje, ale która niestety tych oczekiwań nie spełnia. Cóż to za herezje! – może w tym momencie zakrzyczeć niejedna osoba. Wszak, to pozycja przez wielu uznawana za kanoniczną, ba, niejednokrotnie, gdy natrafiłem w Internecie na tematy związane ze stories, kończyły się one odesłaniem do tejże pozycji.
Niestety, wyraźnie widać, że ta książka ma już dekadę. W momencie jej pisania niewątpliwie koncepcja User Stories była czymś nowym i nieśmiało zdobywała popularność, być może to jedna z pierwszych pozycji książkowych opisujących tę technikę opisywania wymagań. Problem w tym, że od tego czasu świat IT wiele się nauczył. I choć podstawowe zasady się nie zmieniły, to jednak sporo koncepcji zostało rozwiniętych i udoskonalonych, a część najzwyczajniej w świecie się zdezaktualizowała. Ba, od tego czasu Mike Cohn napisał inną, znakomitą książkę (mam tu na myśli Succeeding with Agile: Software Development using Scrum), gdzie również temat stories jest poruszany, choć w sposób znacznie bardziej skondensowany.
Sporo tu wartościowych informacji, ale są one podane z dość sporą ilością typowego dla tego autora „lania wody”. Jest ona też wyraźnie przeznaczona dla początkujących adeptów metodyk agile’owych, bardziej zaawansowani praktycy wiele nowego się stąd nie dowiedzą, co najwyżej porządnie ugruntują zdobytą wiedzę i zapiszą parę ciekawych spostrzeżeń.
Książka podzielona jest na cztery części. Esencję stanowią pierwsze dwie, w których od podstaw poznajemy zamysł stojący za historyjkami użytkownika. Czym jest user story, jakie cechy powinno spełniać, ale także jak zbierać wymagania od użytkownika czy jakie cechy powinny mieć dobre testy akceptacyjne dla danego story. Poznajemy proces szacowania zadań, iteracyjnej pracy zespołu deweloperskiego, mierzenia prędkości zespołu czy w końcu planowania wydania. Trzecia część stanowi rozwinięcie wcześniejszej wiedzy i zaprezentowanie atutów user stories w kontrformie do innych sposobów zbierania wymagań, przykłady problemów czy sposoby implementacji historyjek w metodologii Scrum. W końcu ostatnia część prezentuje prosty, ale pouczający przykład podsumowujący omówioną wiedzę – zebranie wymagań, stworzenie backloga, estymacja, planowanie itp.
Każdy rozdział zakończony jest krótkim podsumowaniem, stanowiącym zestaw wskazówek, wynikających z treści przedstawionych wcześniej, prezentowanych z dwóch perspektyw: dewelopera, jak i „przedstawiciela biznesu”. Warto podkreślić też, iż zadbano o zestaw (z reguły) otwartych pytań dotyczących każdego z rozdziałów, pozwalających na chwilę zastanowienia i weryfikację zdobytej w czasie lektury wiedzy. Co istotne własne odpowiedzi na pytania możemy skonfrontować z ich wzorem zgromadzonym na końcu książki. Sęk w tym, że wiele konstatacji i spostrzeżeń autora powtarza się, często krążymy wokół tego samego.
Generalnie – user stories są tu wyjaśnione naprawdę dobrze. Autor wie w czym rzecz, bardzo dobrze tłumaczy i znakomicie uwypukla zalety tej metody zbierania wymagań, prezentuje też wiele ciekawych wskazówek przydatnych szczególnie na samym początku. Jeżeli ktoś nie wie dlaczego warto stosować user stories czy nie miał do czynienia z typowo agile’owym podejściem do zbierania wymagań, tu znajdzie znakomicie przedstawione argumenty i przykłady pokazujące, że „to działa”. Praktycy docenią to, że zaprezentowane są najczęstsze błędy i pułapki które czyhają na samym początku korzystania z tychże mechanizmów. Szczególnie ciekawe są rozdziały dotyczące zbierania wymagań. Z drugiej jednak strony, te trudniejsze tematy, które pojawiają się w praktyce, czyli: dekompozycja złożonych zadań, technikalia czy „spike’i” są potraktowane zbyt powierzchownie, a przykłady są zbyt proste. Również samo budowanie backloga czy listy wymagań prezentowane jest na przykładach prostych aplikacji Internetowych, podczas gdy przydałyby się i przykłady bardziej złożonych systemów, o innej specyfice, trudniejszej do przełożenia na user stories i korzyści biznesowej.
Wspomniałem o paru zaszłościach. Czas je wymienić. Ot, chociażby jeden z najpopularniejszych (co nie znaczy, że najlepszy) sposób zapisu historyjek, czyli Jako (rola) chciałbym (funkcjonalność) żeby (wartość biznesowa), tu wspomniany jest jako nowość.
Ciekawe są też przedstawione zasady Scruma – przegląd sprintu może trwać maksymalnie dwie godziny, nie wolno pokazywać na nim żadnych slajdów, iteracja trwa 30 dni. Nie, nie ma tu żadnych herezji, kiedyś zasady Scruma faktycznie narzucały 30 dniową iterację. I między innymi dlatego uważam, że po prostu warto sięgnąć po nowsze wydawnictwa.
Jeżeli nie znasz „user stories”, warto sięgnąć po tę pozycję, jeżeli jednak masz już doświadczenie w pracy z ich wykorzystaniem, lepiej sięgnąć po nowsze i bardziej zaawansowane pozycje.