Dotrzymuj terminów: metody stosowane przez programistów do szacowania nakładu pracy

Witam wszystkich! Istnieje kolosalna ilość teorii, którą musisz znać, aby rozpocząć tworzenie oprogramowania. Niektórzy specjaliści (na przykład programiści backendu używający Javy i innych języków) wiedzą o tym więcej, podczas gdy inni (na przykład programiści frontendu używający JavaScript i React Native) mogą wiedzieć trochę mniej. To powiedziawszy, obie grupy muszą posiadać duży zasób wiedzy nie tylko technicznej, ale także „organizacyjnej”. Ta „organizacyjna” wiedza jest jednym z obszarów nakładania się dla programistów frontendu i backendu. Dzisiaj chcę mówić o pewnym aspekcie tej nietechnicznej, organizacyjnej wiedzy. Dzisiaj porozmawiamy o szacowaniu nakładu pracy . Ponieważ mam doświadczenie tylko w stosowaniu metodyki Agile(który jest uważany za najbardziej popularny), a dokładniej framework Scrum, rozważę szacowanie nakładu pracy w kontekście Scruma . Już na wstępie muszę powiedzieć, że oszacowanie nakładu pracy jest trudne. Dla mnie jest to jeden z najtrudniejszych/nieprzyjemnych aspektów mojej pracy programisty. Należy wziąć pod uwagę wiele różnych czynników, które mogą wpłynąć na oszacowanie nakładu pracy wymaganego do wykonania zadania. Dodatkowo, przyszłe plany rozwoju będą oparte na Twoich szacunkach.

Co się stanie, jeśli podasz złą wycenę?

Jeśli programista szacuje znacznie więcej godzin na wykonanie zadania, niż ostatecznie poświęca na to zadanie, jego wiedza specjalistyczna może zostać poddana w wątpliwość, ponieważ oszacowanie było tak niedokładne. Innymi słowy, było to szalone przypuszczenie. Jednocześnie, jeśli programista nie wykona pracy w przewidywanym czasie, narazi na szwank plany klienta dotyczące wydania produktu lub nowej funkcji. To jest biznes, a biznes to pieniądze. Niewielu klientów będzie zadowolonych z takiego poślizgu. Właśnie dlatego nie lubię szacowania — ponieważ czasami bardzo trudno jest dokładnie określić czas potrzebny do wykonania zadania.

Jak oszacować czas

Z reguły szacunki są dokonywane w godzinach lub punktach historii. Osobiście preferuję przeprowadzanie procesu szacowania przy użyciu punktów fabularnych . Trudno pomylić się co do konkretnych obiektów fizycznych, ale punkty fabularne są nieco bardziej abstrakcyjne. Zespoły programistów zwykle dostarczają szacunki w postaci ilości czasu: godzin, dni, tygodni, miesięcy. Te szacunki czasu są oparte głównie na osobistych doświadczeniach, domysłach i/lub intuicji. W tym przypadku programiści po prostu patrzą na zadanie i wyrażają swoje przypuszczenia, ile czasu im to zajmie. W rezultacie szacunki te bardzo rzadko są dokładne, ponieważ istnieje zbyt wiele czynników, które mogą wpływać na czas trwania prac. Dlatego wiele zespołów stosujących metodologię Agile wykorzystuje również punkty historii. Zanurzmy się!

Co to są punkty fabularne?

Punkt fabularny to jednostka miary służąca do wyrażenia oszacowania całkowitego nakładu pracy wymaganego do pełnego wdrożenia określonej funkcjonalności. To znaczy mówimy o krewnymzłożoność. Zespoły przypisują oszacowanie w punktach historii na podstawie złożoności pracy, jej objętości oraz ryzyka lub niepewności. Wartości te są zwykle przypisywane w celu wydajniejszego podziału pracy na mniejsze części, eliminując w ten sposób niejednoznaczność. Z biegiem czasu pomaga to zespołom zrozumieć, co mogą osiągnąć w danym okresie i pomaga im dokładniej planować kolejne części pracy. Może ci się to wydawać całkowicie sprzeczne z intuicją, ale ta abstrakcja jest naprawdę przydatna: popycha zespół do podejmowania trudnych decyzji dotyczących złożoności pracy. Przyjrzyjmy się niektórym powodom, dla których warto używać punktów historii podczas planowania:

• Możesz uniknąć niedokładnych szacunków czasu.
• W przeciwieństwie do szacunków dokonywanych w jednostkach czasu, punkty historii pozwalają uwzględnić koszty ogólne: komunikację między członkami zespołu a klientem, różne dyskusje zespołowe i planowanie działań, a także nieprzewidziane sytuacje.
• Każdy zespół będzie oceniał swoją pracę za pomocą innych skal, co oznacza, że ​​ich możliwości (mierzone w punktach) będą różne.
• Definiując skalę przypisywania każdego punktu historii, możesz szybko przydzielić punkty bez większych kontrowersji.

Jak NIE używać punktów historii

Niestety, punkty fabularne są często niewłaściwie wykorzystywane. Punkty fabularne mogą wprowadzać w błąd, gdy są używane do oceny ludzi, określania szczegółowych terminów i zasobów oraz gdy są mylone z miarą wydajności. Zamiast tego zespoły powinny ich używać, aby zrozumieć zakres/złożoność każdego zadania i ustalić priorytety. Być może najpierw należy zająć się częściami, które są uważane za trudniejsze, aby można było je wykonać przed końcem sprintu , ewentualnie przesuwając łatwiejsze zadania na później. Przypomnę czym jest sprint w kontekście metodologii Scrum : Długość tego okresu jest określana w momencie rozpoczęcia rozwoju i jest uzgadniana między zespołem a klientem. Może to być okres dwóch tygodni lub miesiąca lub dowolny inny okres. Z reguły szacunki pracochłonności dokonywane są na początku każdego sprintu w celu zaplanowania pracy, która może zostać wykonana do końca sprintu, kiedy ukończona praca zostanie dostarczona klientowi. Demo pomaga zobaczyć postępy w rozwoju produktu, otrzymać informację zwrotną od klienta i dostosować trajektorię projektu zgodnie z wizją klienta. Ale trochę dywagujemy. Wróćmy do szacunków. Byłoby zbyt subiektywne, aby tylko jeden programista przedstawił szacunki dla wszystkich zadań. Proces ten jest więc zwykle wysiłkiem zespołowym. Istnieje wiele technik, których zespoły mogą używać do generowania szacunków. Dzisiaj przyjrzymy się najpopularniejszej technice: pokerowi scrumowemu . Ta technika wymaga menedżera, który będzie pełnił rolę moderatora pokera scrumowego . Może to być ktoś, kto jest mistrzem scrum lub ewentualnie PM .

Czym jest poker Scrum?

Scrum poker , czyli poker planistyczny, to technika szacowania, która polega na osiągnięciu porozumienia. Służy głównie do oszacowania złożoności przyszłych prac lub względnej wielkości zadań związanych z tworzeniem oprogramowania. Od razu powiem, że scrum pokerjest powszechną praktyką programistyczną i musisz wiedzieć, o co w tym wszystkim chodzi. Zwykle obejmuje aplikację lub stronę internetową, aby ułatwić zespołowi wspólne tworzenie kosztorysu dla określonego zadania. Jak to się stało? Zespół bierze coś z backlogu (nowe zadanie, jakaś funkcjonalność) i krótko omawia możliwe pułapki i inne niuanse z tym związane. Następnie każdy uczestnik wybiera kartę z numerem, który odzwierciedla jego ocenę złożoności. Aha, jeszcze jedno, dokonując tych szacunków, używamy liczb w ciągu Fibonacciego , a nie zwykłych liczb. Liczby Fibonacciego są popularne w pokerze scrumowym, bo między nimi jest coraz większa przepaść (przypominająca poziomy piramidy). Niektóre zadania będą bardzo złożone i nie ujdzie nam na sucho niewielka liczba punktów fabularnych. Istnieje kilka niezwykłych kart, które mają następujące znaczenie:

Nieznana liczba punktów końcowych

Nieskończenie długie zadanie

Potrzebować przerwy

Mniej powszechne metody szacowania wykorzystują:

• Rozmiary koszulek — S, M, L, XL
• Rasy psów — chihuahua, mops, jamnik, buldog i tak dalej (osobiście uważam, że jest to najdziwniejsza jednostka miary do szacowania wysiłku = D)

Następnie zespół porównuje szacunki podane przez różnych programistów dla tego samego zadania. Jeśli się zgodzą, to świetnie! Jeśli nie, należy przedyskutować przyczyny (argumenty) różnych szacunków. Następnie zespół pracuje razem, aby stworzyć jedno oszacowanie, które wszyscy mniej więcej akceptują. Dlaczego więc poker jest w ogóle używany do planowania poważnych projektów programistycznych? Musisz przyznać, że to dziwne. Faktem jest, że tego rodzaju grywalizacja zachęca członków zespołu do samodzielnego myślenia, zapraszając ich do ujawniania swoich szacunków w tym samym czasie, co ich koledzy z zespołu. To z kolei pozwala uniknąć sytuacji, w której niektórzy członkowie zespołu są zależni od opinii innych. Gdyby nie było to zrobione w ten sposób, mniej doświadczeni programiści patrzyliby i skupiali się na szacunkach dostarczonych przez bardziej doświadczonych członków zespołu, a to sprawiłoby, że ich własne szacunki byłyby mniej przydatne. Ale jednoczesne pokazanie szacunków czyni to zasadniczo niemożliwym. oferty Atlassianaaplikacja scrum poker do wykorzystania w procesie planowania.

Przykład szacowania pracochłonności

Załóżmy, że Twój zespół ustalił następującą skalę przypisywania punktów historii do szacunków: Dla każdego zadania gra się w pokera Scrum , a ty podajesz oszacowanie w następujący sposób:

• Nigdy wcześniej nie wdrażałeś podobnej funkcjonalności: +3
• Funkcjonalność jest średniej wielkości: +2
• Wdrożenie będzie bardzo złożone: +3
• Pisanie testów funkcjonalności będzie bardzo złożone: +3

Sumując każdy komponent, otrzymujesz w sumie 11 punktów historii, ale nie ma takiej karty, więc sugerujesz 13. Współpracownik przedstawia następujące oszacowanie zadania:

• Pracował już z podobnym zadaniem: +1
• Funkcjonalność jest średniej wielkości: +2
• Wdrożenie będzie miało średnią złożoność: +2
• Pisanie testów pod kątem funkcjonalności będzie miało średnią złożoność: +2

Jego wynik pośredni to 7 punktów fabularnych, ale ta liczba nie istnieje w ciągu Fibonacciego, więc przedstawia kartę z najbardziej przybliżoną liczbą — 8. Inni członkowie zespołu również dokonują szacunków na podstawie swoich subiektywnych opinii. Następnie wszyscy pokazują swoje karty i okazuje się, że prawie wszyscy twoi współpracownicy ocenili na 13, z wyjątkiem jednego programisty, który zasugerował 8. W tym przypadku wolno mu mówić, aby uzasadnić niższą ocenę. Załóżmy, że przedstawia to uzasadnienie: wcześniej pracował nad tym samym zadaniem i nie jest to tak trudne, jak mogłoby się wydawać. Ostatecznie przekonuje resztę zespołu do zmiany zdania z 13 na 8 punktów fabularnych, mówiąc, że pomoże każdemu, kto podejmie się tego zadania. A może sam to zrobi. W każdym razie nie Nie ma znaczenia, czy inni przyjmą jego argumenty, czy nie, ponieważ tak czy inaczej do zadania zostanie przypisany szacunek, a zespół przejdzie do rozważenia następnego. Początkowo szacunki będą niedokładne, podobnie jak szacunki ilości pracy, którą planujesz wykonać w następnym okresie (sprint). Przecież te szacunki wykonane za pomocą szacunków. Po jakimś czasie, może po trzech miesiącach, zespół zacznie dokładniej szacować czas potrzebny na wykonanie zadań i stanie się widoczna średnia ilość pracy, jaką zespół jest w stanie wykonać w sprincie. Ale jest to proces tworzenia ogólnego planu dotyczącego zakresu prac. Skupia się głównie na czasie, ale w tym przypadku może być wiele różnych istotnych czynników. Załóżmy na przykład, że programista wyjechał na dwutygodniowe wakacje. Będziesz musiał wyciąć pewną ilość planowanej pracy (planowanej funkcjonalności). Albo załóżmy, że do zespołu dołączył nowy programista, ale nie jest jeszcze w pełni nastawiony, więc musisz dać jej czas na zapoznanie się z projektem poprzezproces onboardingu . Może to być dwa tygodnie, plus lub tydzień, w zależności od złożoności projektu. To wszystko na dzisiaj! Mam nadzieję, że nieco poprawiłem Twoją wiedzę na temat szacowania nakładu pracy, niezbędnego nietechnicznego aspektu tworzenia oprogramowania. Jeśli chcesz zagłębić się w ten temat i poznać szczegóły scrumu, gorąco polecam przeczytanie książki „SCRUM” autorstwa Jeffa Sutherlanda. Co do konsekwencji nie mogę obiecać, bo po przeczytaniu będziesz miał irytujące pragnienie zostania scrum masterem =D