Specification by Example zmniejszy twoje historyjki

Lubisz duże historyjki użytkownika? Z rodzaju tych, które zajmują cały sprint? Ja ich nienawidzę.

Weźmy na przykład estymaty. Ja jestem słaby w estymowaniu i generalnie uważam to za trudną sztukę. Powiedzmy, że zespół właśnie dwukrotnie niedoszacował historyjki. Jeśli była mała, problem jest pomijalny. Ale jeśli była wielkości całego sprintu…

Albo integracja. Jeśli zespół nie używa Continuous Integration, to prawdopodobnie w przypadku dużej historyjki stworzy brancha, który będzie żył prawie cały sprint. Niedobrze, bo stracimy czas na jego integrację.

Jednym ze sposobów podzielenia dużej historyjki na mniejsze jest wykorzystanie Specyfikacji na Przykładach.  Zazwyczaj dzieje się to tak:

Najpierw czytam historyjkę użytkownika i zapisuję nazwy scenariuszy, które przychodzą mi do głowy. Powiedzmy, że jest ich 6.

Gdy je spisuję, to przychodzą mi do głowy kolejne. Pojawiają się myśli w rodzaju: „A co, jeśli zamówienie jest już zatwierdzone?” albo „Przecież wynik będzie zależał od roli użytkownika”. Zejście na poziom przykładów, wstawianie do nich konkretnych danych prowadzi do tego, że zauważamy pewne wzorce, zwracamy uwagę na różne zakresy danych, przychodzą nam do głowy połączenia nowej funkcjonalności z już istniejącą. Zatem naturalnie widzimy luki w specyfikacji i ją uzupełniamy. Po tym etapie dochodzą np. 4 kolejne scenariusze.

Teraz czas, aby mojej pracy przyjrzał się ktoś inny. Może tester, może ktoś z biznesu, może developer. Różni ludzie mają różne sposoby myślenia i zauważają inne rzeczy. W ten sposób pomagają zidentyfikować kolejne braki lub nieścisłości. Zatem pojawiają się, dajmy na to, kolejne 2 scenariusze.

No to mamy problem… Dla prostej historyjki, o której myśleliśmy, że zamknie się w 6 scenariuszach, okazało się, że jest ich 12. Na szczęście zrobiliśmy to przed implementacją. Jeszcze nie jest za późno, aby podzielić ją na mniejszą. W jaki sposób?

Przyglądamy się scenariuszom pod kątem tego, w czym są do siebie podobne, a czym się różnią.

Na przykład zauważamy, że w 3 scenariuszach użytkownik jest niezarejestrowany. Czy możemy najpierw zrobić funkcjonalność tylko dla niezarejestrowanych? Pewnie tak.

Dla innych 4 nie interesuje nas wartość zamówienia. Może zależną od niej funkcjonalność możemy zaimplementować później? Jasne, że tak.

Inne scenariusze mówią o walidacji. Czy możemy dostarczyć historyjkę bez walidacji, a tę wydzielić do nowej? Bardzo dobry pomysł.

Zatem, patrząc na podobieństwa i różnice między danymi w scenariuszach, dzielimy je na grupy nadające się do wydzielenia do oddzielnych historyjek.

Zauważ, że każda z wydzielonych historyjek przynosi jakąś wartość biznesową. Nawet, jeśli nie zdecydujesz się na jej wdrożenie na produkcję (a może jednak?…). Otóż uzyskujemy informacje zwrotne od naszych interesariuszy – właściciela produktu, klientów.


Jeśli temat wydał ci się interesujący, zapraszam na otwarte szkolenie z Specification by Example w dniach 24-25 listopada w Warszawie. Dzień pierwszy dla wszystkich zaangażowanych w wytwarzanie produktu, dzień drugi o automatyzacji dla osób technicznych.

Źródło zdjęcia: Flickr

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *