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.
4 odpowiedzi