Szacowanie wymagań biznesowych – Zagrajmy w Pokera!
Szacowanie wymagań – dlaczego jest ważne!
Inżynieria oprogramowania to niezwykle obszerna dziedzina. Dzieli się na co najmniej kilka różnych obszarów, które definiują procesy wytwarzania oprogramowania. Bardziej skomplikowanych oraz tych mniej. Do jednych z tych „kłopotliwych” na pewno można, a nawet trzeba zaliczyć proces jakim jest szacowanie oprogramowania. W tym konkretnym przypadku, wymagań. Praktycznie każdy projekt jest wytwarzany w celu rozwiązania jakiegoś problemu. Przynajmniej powinien być. Ma spełniać konkretne wymagania oraz odpowiadać na potrzeby biznesu. Czy na jego powodzenie może mieć wpływ kwestia szacowania? Może!
Po co szacujemy?
Mógłbym tu opisać swoimi słowami kilka linijek, które tak naprawdę można zastąpić jednym porządnym cytatem:
Najważniejszym celem szacowania oprogramowania nie jest przewidzenie wyniku projektu; chodzi tu o ustalenie, czy cele projektu są do tego stopnia realistyczne, aby można było poprowadzić projekt w sposób umożliwiający ich osiągnięcie.
Steve McConnell „Szacowanie oprogramowania. Kulisy czarnej magii”
Ps. w tym miejscu, chciałbym mocno zachęcić do zaglądnięcia do powyższej książki. Naprawdę sporo wartościowej wiedzy, którą można potem wykorzystać w codziennej pracy.
Przez wiele osób temat szacowania jest uważany jako jeden z trudniejszych. I rzeczywiście tak jest, ponieważ trudno jest przewidzieć ile „waży” oraz „kosztuje” wytworzenie danego wymagania czy całego zbioru wymagań.
Z szacowaniem największą trudność mają zapewne mniej doświadczeni członkowie zespołu. Szacują z licznymi błędami, które przekładają się na problemy w projekcie. Nagminnie można spotkać się sytuacjami, że wymagania są przeszacowane dla „świętego spokoju”. Robi się to dla bezpieczeństwa, natomiast nie jest to nic dobrego. Są też sytuacje odwrotne, kiedy wymagania są niedoszacowane.
Szacowanie w Agile. Zagrajmy w Pokera!
Metod szacowania wymagań jest kilka albo i kilkanaście. Które są lepsze, a które gorsze ciężko jest stwierdzić. Na pewno duże znaczenie ma na tutaj doświadczenie zespołu, rodzaj projektu i kilka innych kwestii. Proces ten trzeba sobie wypracować i go udoskonalać.
Z racji tego, że bardzo bliskie są mi metodyki zwinne (podejściem Agile prowadzimy również procesy sprzedażowe) to w tym przypadku opiszę jedną z naszych ulubionych metod jaką jest „Planning Poker”
Metoda ta jest opracowana przez Jamesa Grenninga. Natomiast kwestia tego, że używa ją w tym momencie dużo zespołów jest wynikiem jej popularyzacji przez Mike’a Cohna (Mike jest autorem świetnych książek, których tytuły podam na samym końcu).
Okej, zagrajmy! Jak sama nazwa wskazuje, podczas szacowania posługujemy się kartami. W tym przypadku są to karty, które zawierają specjalne liczy. Dość często jest to Ciąg Fibonacciego. Pamiętajmy też, że mamy już dobrze przygotowane historyjki użytkownika, które opisywałem we wcześniejszych artykułach. Bo przecież to je będziemy szacować:
- Każdy z uczestników szacowania ma swój zestaw kart, a moderator całej imprezy przedstawia konkretny przedmiot szacowania, tj. historyjkę.
- Kolejnym punktem, jest zawzięta dyskusja na temat danego wymagania (moim zdaniem to najważniejsza i najbardziej wartościowa część gry), która trwa dwie minuty. W dyskusji bierze udział również przedstawiciel biznesu, który odpowiada na wszystkie pytania deweloperów. Wszystko odbywa się z timerem w dłoni.
- Po zawziętej dyskusji, każdy wybiera swoją kartę z odpowiednią wartością. Na znak prowadzącego, wszyscy w tym samym momencie odkrywają swoje karty. Jeśli większość jest taka sama, to jest ona wynikiem szacowania! Ale… nie zawsze kończy się to tak optymistycznie, ponieważ czasami zdarzają się sprzeczności. Jeśli różnice są zbyt duże, powtarzamy proces od początku, aż do uzyskania zgodności.
- Po wybraniu konkretnej wartości, przechodzimy do kolejnej historyjki.
Za co lubimy Planning Pokera?
Przede wszystkim, jest bardzo przyjemny i szybki. Daje pewną formę rozluźnienia i możliwość wypowiedzenia się na pewne tematy, bez nacisku innych osób. Niezwykłą wartością jest wspomniana wcześniej dyskusja, która prowadzi do rzetelniejszych estymacji. Należy pamiętać jednak, że trzeba przestrzegać pewnych norm oraz ram. Początki nie należą do łatwych, z czasem jednak są przyjemniejsze i bardziej efektywne.
Warte uwagi lektury:
- „Ile gumisiów zmieści się w pudełku” Krystian Kaczor,
- „Agile estimating and planning” Mike Cohn,
- „Planning Poker or How to avoid analysis paralysis while release planning” Grenning James,
W kolejnym artykule przeczytasz o technikach priorytetyzacji. Zapraszam.