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

Małe, zbywalne kawałki - tak myśl o user stories

Małe, zbywalne kawałki – tak myśl o user stories

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.

Fotografia użyta na licencji Creative Commons od użytkownika Ben Sutherland.

Share on Facebook0Tweet about this on TwitterShare on LinkedIn0Share on Google+0

2 myśli nt. „Sposoby dzielenia User Stories na małe części

  1. Pingback: „No Estimates” – Vasco Duarte | Agile Coaching

  2. Pingback: Budowanie wspólnego zrozumienia #storymapping | Agile Coaching

Dodaj komentarz

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