Sposoby dzielenia User Stories na małe części

Efektem każdego sprintu w Scrumie powinien być działający fragment oprogramowania. Problematyczne dla wielu zespołów – szczególnie jeśli wcześniej pracowali w modelu kaskadowym – jest dzielenie wymagań produktowych na małe, zbywalne przyrosty. Często słyszy się głosy z zespołu mówiące, że krótkie sprinty uniemożliwiają oddanie sensownego przyrostu, a jako rozwiązanie proponują wydłużyć sprint.

Idąc tym tokiem myślenia możemy założyć, że skoro w ciągu jednotygodniowego sprintu oddajemy zero działającego oprogramowania, to w ciągu dwutygodniowego sprintu oddamy… 2 razy zero.

Jak zatem uporać się ze wspomnianym zerem? Przy dzieleniu wymagań na mniejsze części, pomocne może być spojrzenie z kilku perspektyw i próba odpowiedzi na proste pytania:

  • użytkownik – Która rola jest najważniejsza? Czy możemy obsłużyć na początku tylko zwykłego użytkownika? Który typ użytkownika jest najczęściej wykorzystywany?
  • dane – Czy możemy pewne dane odczytać z pliku zamiast z bazy? Czy możemy użyć wygenerowanych danych? Które dane są najistotniejsze, a które opcjonalne?
  • algorytmy – Jak możemy maksymalnie uprościć algorytm? Czy zamiast pisać kompletny algorytm, możemy go zasymulować? Czy możemy użyć Mechanicznego Turka?
  • wydajność – Czy zanim wydajność będzie satysfakcjonująca, funkcjonalność może po prostu zacząć działać? Czy musimy od razu umożliwiać obsługę 100 tys żądań na sekundę? Czy możemy póki co poczekać 5 sekund na wynik zapytania i upewnić się, że wynik (dane) jest dla nas satysfakcjonujący?
  • bezpieczeństwo – Czy moglibyśmy najpierw udowodnić, że nasz pomysł działa, zanim zabezpieczymy się przed każdym możliwym sposobem ataku?
  • interfejs – Czy możemy wyświetlić wynik w konsoli zamiast na stronie internetowej? Czy możemy odczytać wynik z logów? Czy możemy przygotować formularz w czystym HTML’u, zanim zaczniemy zaokrągląć rogi w CSS?
  • ścieżki procesu – Czy możemy obsłużyć najbardziej prawdopodobną scieżkę procesu bez ścieżek warunkowych? Która ścieżka jest najbardziej prawdopodobna? Którą scieżką użytkownicy porusząją się najczęściej?
  • walidacja danych – Czy możemy zrezygnować z walidacji danych w formularzu? Czy możemy zrezygnować z walidacji w Javascripcie? Czy możemy tymczasowo przyjąć, że klient wie co wpisuje?
  • zarządzanie danych – Czy potrzebujemy panel administratora, czy możemy aktualizować dane bezpośrednio w bazie danych? Czy możemy aktualizować pliki z danymi ręcznie? Czy możemy przyjąć domyślne dane i póki co ich nie aktualizować?
  • częstotliwość użycia – Które funkcje są najważniejsze/najczęściej używane przez użytkowników? Które składają się na MVP (ang. Minimum Viable Product)?

Gdy następnym usłyszysz, że „tej historyjki się nie da pociąć na mniejsze części”, zaproponuj spojrzenie na problem z perspektywy powyższej listy.

Photo by ivan Torres on Unsplash
Facebook
Twitter
LinkedIn
Jacek Wieczorek

Jacek Wieczorek

Jestem konsultantem zwinności i praktykiem podejścia agile. Napisałem książkę "Labirynty Scruma" o sprawdzonych sposobach na najczęstsze pułapki w Scrumie. Pomagam przekształcać organizacje w miejsca, w których efektywnie tworzone są wartościowe produkty. Prowadzę bloga jacekwieczorek.pl, współtworzę podcast Porządny Agile oraz portal Agile247. Na co dzień pomagam klientom działając jako konsultant w firmie 202 Procent, którą współtworzę z pasjonatami zwinności.

4 odpowiedzi

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.