Poniższe pytania i odpowiedzi są możliwie konkretne. Niestety im bardziej konkretna odpowiedź, tym mniejszy kontekst jej stosowalności. I jeszcze większa - niestety - szansa na zastosowanie odpowiedzi w niewłaściwym kontekście albo (z powodu nieuwagi autora) wyciągnięcie z tych odpowiedzi wniosków, których autor wcale nie miał na myśli.

Z w/w powodów proszę aby, jeśli wyciągniesz z poniższego tekstu wniosek, który jest sprzeczny ze zdrowym rozsądkiem, Twoim doświadczeniem, Scrum Guidem itp., niezwłocznie mnie o tym poinformuj w komentarzu – w miarę możliwości doprecyzuję tekst.

Problem:

  • Sprint trwa 2 tygodnie
  • Zespół planuje prace na cały sprint
  • Po wykonaniu zadania PO zleca testy biznesowe osobom z biznesu i na tej podstawie odbiera zadania ze sprintu
  • Bywa, że osoby z biznesu nie zdążają przetestować zadania przed sprint review i zadanie jest undone
  • Jak zatem planować prace i współpracować, aby dostarczać zadania, które są done?

1. Czy powinniśmy zaplanować development tylko na 1. tydzień sprintu, dając tym samym biznesowi czas na przetestowanie w 2. tygodniu sprintu tego, co zrobiliśmy w 1. sprincie?

- Nie. Tydzień siedzenia i czekania jest stratą czasu i pieniędzy. Po za tym od testowania jest zespół, biznes jest od biznesowania.

2. Czy w takim razie powinniśmy zorganizować prace tak, że testowanie biznesowe odbywa się w kolejnym sprincie?

- Nie. Poprawki zgłoszone do zadań z poprzedniego sprintu będą zaburzać wasze prace w bieżącym sprincie. Modelowo zespół pracuje time & material i otrzymuje wynagrodzenie na koniec sprintu za to, co dostarczył w sprincie. Z perspektywy zespołu nie ma sensu robić w sprincie pracy, która na koniec nie zostanie odebrana i opłacona.

Jednym z kluczowych przesłanek za pracą w iteracjach i inkrementach jest ta, że PO po każdym sprincie może zdecydować się na wstrzymanie prac programistycznych, aby skupić się na biznesowym zarabianiu na produkcie. Może też zdecydować, że już osiągnął to, co chciał i współpraca z zespołem dobiegła końca. Planowanie testów na kolejny sprint odbiera mu tę możliwość.

Ponad to to co nazywasz "testowaniem biznesowym" to odpowiedzialność zespołu. Zakładam, że jest to jakaś grupa testów zdefiniowana w trakcie refinementu. Biznes zrobi co najwyżej somoke tests, żeby upewnić się, że dostał to, co zamówił.

3. Ale nasz PO liczy mendeje, które spaliliśmy w sprincie. Musimy zaraportować prace na jakieś zadania.

- Dobrze, że je liczy. Powinien również liczyć zysk z dostarczonej pracy. Jeśli zysk jest, to w czym problem?

4. Wy tym, że przecież nie możemy przez dzień czy więcej siedzieć tylko i pić kawę.

- Częściowo to prawda. Chodzi nam o subtelną zmianę priorytetów: przestajemy dążyć do maksymalnej utylizacji Waszego czasu pracy, zaczynamy dążyć do maksymalnej wartości Waszej pracy. Jeśli zatem okazuje się, że wszystko jest DONE i macie jeszcze czas w sprincie, to warto zastanowić się nad zwiększeniem dostarczanej wartości np. poprzez planowanie większej ilości wartościowej pracy. Poza tym PO nie płaci za wykonane zadania/user story/funkcjonalności, lecz za osiągnięcie celu sprintu.

5. Przypuśćmy, że mamy taką sytuację: w pierwszym tygodniu sprintu zrobiliśmy zadania i poprosiliśmy PO o akceptację. Czym mam się zająć w następnej kolejności?

- Kolejnym zadaniem ze sprint backloga.

6. Ale wszystkie są już ‘in progress’

- Pomóż kolegom/koleżankom sprawniej uporać się z ich zadaniami, abyście szybciej osiągnęli cel sprintu.

7. Ale oni mówią, że w tej chwili nie potrzebują pomocy i że będziemy sobie przeszkadzać

- Zacznij testować zadania kolegów/koleżanek.

8. Ale oni już zaczęli swoje testy deweloperskie?

- Zacznij wykonywać kolejne testy z zaplanowanych np te, które nazywasz "biznesowymi".

9. Ale to analitycy z biznesu mają się tym zająć.

- A kto ma otrzymać wynagrodzenie za pracę, która jest done – Wy czy analitycy z biznesu?

10. Czyli analitycy mają nie testować biznesowo?

- Nie wiem jak jest ułożona Wasza współpraca. Może i mają testować, ale odpowiedzialność za dostarczenie celu sprintu spoczywa na zespole.

11. Ale nie mamy żadnej metody, żeby ich zmusić do testowania na czas

- Co do zasady, to da się zmusić współpracowników do pewnego zachowania, ale wtedy cały czas musisz podtrzymywać bodziec przymuszający np. zagrożenie eskalacją. Ostatnie 40 lat doświadczeń wskazuje, że postawienie na współpracę, budowanie relacji i podejście win-win daje w typowym środowisku biznesowym lepsze efekty.

12. A co zrobić jeśli analitycy nie mają czasu na testowanie?

- Zgłosić PO. Jeśli nie mają czasu odebrać zadania, to nie jest ono wystarczająco ważne albo nie zostało przez nich wycenione biznesowo. Osobiście rozważyłbym niebranie na sprint zadań, co do których nie ma zobowiązania, że zostaną odebrane.

13. Mówiliśmy im, że mają się zobowiązać, ale oni mówią, żeby ze sporym wyprzedzeniem podać kiedy mają testować bo muszą zaplanować swoje prace, a my nie jesteśmy w stanie tego przewidzieć

- Czyli chcecie, aby biznes zaplanował swoją pracę „pod Was”, bo wy nie jesteście w stanie zaplanować swojej?

14. To nie tak. Nie da się patrząc na zadanie podać nawet ‘mniej więcej’ kiedy będzie gotowe do testowania.

- Prawdopodobnie zadania są zbyt duże. Prawdopodobnie należy się przyjrzeć refinementowi.

15. Nie da się ich bardziej podzielić.

- Da się. Zróbmy warsztat na ten temat. Byle na Waszych przypadkach, nie na ogólnych schematach.

16. Powiedzmy, że chciałbym testować biznesowo, ale nie wiem jak, nie mam potrzebnej wiedzy.

- Zapytaj ludzi z biznesu.

17. Mówią, że nie mają czasu.

- Zapytaj jeszcze raz.

18. Znów nie mają czasu.

- Pytaj aż do skutku. Wpadnij na kawę, na lunch. Popracuj na ich piętrze.

19. Nawet jeśli się czegoś dowiem, to testowanie idzie mi wolno nie wyrobię się do końca sprintu.

- Do końca tego sprintu może i nie, ale za 2-3 może nabierzesz wprawy.

20. A co jeśli do końca sprintu zostało 2 dni, czekamy tylko na wyniki testów biznesowych. Czy możemy zacząć nowe zadanie?

- Zanim to zrobisz, to poświęć chwilę na refinement, poprawę jakości kodu, dopisanie koniecznych testów, spłatę długu technologicznego.

21. Już to wszystko zrobiliśmy…

- To dobierzcie zadanie z product backloga. Unikajcie w trakcie planingu wrzucania do sprint backloga zadań rezerwowych.

22. Dlaczego? Przecież i tak dobieramy z backloga?

- Ale z produktowego, a nie z napchanego sprint backloga.

23. Co za różnica?

- Taka, że jeśli na początku napchacie sprint backlog rezerwowymi zadaniami, to na koniec sprintu prawie na pewno zostaną Wam niewykonane zadania.

24. Ale przecież chodzi o osiągnięcie celu sprintu, a nie o wykonanie wszystkich zadań.

- To prawda. Jeśli cel jest osiągnięty i zostały jakieś zadania, to nie ma dramatu. Mimo to ludzie lepiej się czują jeśli zrobią wszystko, co sobie zaplanowali. Nawet jeśli doskonale rozumieją, że nie jest to celem, to niepusty sprint backlog ich ‘uwiera’.

25. Czyli mamy planować tak, aby wykonać wszystkie zadania ze sprintu?

- Nie. Tego nie powiedziałem. Powiedziałem tylko, żebyście unikali napychania sprint backloga rezerwowymi zadaniami. Tylko tyle. Popełniasz błąd wnioskowania polegający na niewłaściwym odwróceniu implikacji. Poczytaj o błędach poznawczych. np. Sztuka myślenia

26. Przypuśćmy zatem, że dobierzemy jakieś zdanie z product backloga. W takim razie te zadania nie zostaną przetestowane biznesowo do końca sprintu.

- To podzielcie na mniejsze i sami testujcie biznesowo.

27. No, to powiedzmy, że zostało 2h do końca sprintu, dobrałem zadanie i na pewno nie zostanie ono przetestowane biznesowo do końca sprintu.

- No, prawdopodobnie nie zostanie.

28. Ale wcześniej napisałeś, żeby nie robić takich zadań, bo jak skończymy współpracę na tym sprincie, to nam nie zapłacą za nieodebrane zadania.

- Istnieje takie ryzyko. Zmniejszasz je dobierając zdania z wierzchu product backloga w nadziei, że kolejny sprint jednak ruszy, dokończysz to zadanie i otrzymasz zapłatę.

Lecz zanim zdecydujesz się rozgrzebać zadanie, które będziesz kontynuował w kolejnym sprincie, najpierw przeprowadź w/w 28-punktowy ciąg rozumowania ;)

.