Jakich metod używają programiści do oceny zadań?

Cześć wszystkim! Teoria wymagana do rozpoczęcia rozwoju jest bardzo obszerna. Niektórzy specjaliści (programiści backendowi w Javie i innych językach) mają go więcej, inni (np. programiści frontendowi w JavaScript - React Native) mają go nieco mniej. Obaj jednak muszą posiadać duży zasób wiedzy nie tylko technicznej, ale i „organizacyjnej”. Ta wiedza „organizacyjna” jest jednym z punktów styku programistów frontendowych i backendowych. Dziś chcę poruszyć jeden aspekt takiej wiedzy nietechnicznej, organizacyjnej – ocenę (szacowanie) zadania . A ponieważ pracowałem wyłącznie w metodyce Agile (która faktycznie jest uważana za najpopularniejszą), w jej podczęści Scrum , rozważę ocenę zadań w kontekście Scruma . Od razu powiem, że ocena, zwana też estymacją, jest trudna. Dla mnie osobiście jako programisty jest to jeden z najtrudniejszych/niepożądanych aspektów tej pracy. Należy wziąć pod uwagę wiele różnych czynników, które mogą mieć wpływ na ocenę zadania. Jednocześnie plany dalszego rozwoju będą oparte na Twoich prognozach.

A co jeśli nie otrzymasz właściwej oceny?

Jeśli programista spędzi nad zadaniem o wiele więcej godzin, niż zostanie mu ostatecznie wydane, może się wydawać, że nie jest najlepszym specjalistą, bo wycena była bardzo niedokładna. Że tak powiem, palec na niebie. Jednocześnie, jeśli deweloper nie zainwestuje w przewidywanym czasie, naraża na szwank plany klienta dotyczące wypuszczenia produktu/nowej funkcji. To jest biznes, a biznes to pieniądze, a takie przebicie spodoba się niewielu klientom. Właśnie dlatego nie lubię szacować, bo czasami tak trudno określić dokładny czas wykonania zadania.

Jak ocenia się czas?

Z reguły estymację przeprowadza się w godzinach lub punktach fabularnych. Osobiście dużo bliżej mi do procesu oceny w punktach fabularnych . Jeśli zegarek jest czymś fizycznym, to czymś, co można pomylić, punkty fabularne dotyczą czegoś innego, bardziej abstrakcyjnego. Zazwyczaj zespoły programistów podają szacunki w formacie czasu: godziny, dni, tygodnie, miesiące. Takie szacunki czasu opierają się głównie na osobistym doświadczeniu, domysłach lub intuicji. W tym przypadku programiści po prostu przyglądają się zadaniu i szacują, ile czasu im to zajmie. W efekcie bardzo rzadko są one dokładne, gdyż zbyt wiele czynników może mieć wpływ na termin wykonania pracy. Dlatego wiele zespołów pracujących według metodologii Agile wykorzystuje punkty historii. Rozwiążmy to.

Co to są punkty fabularne

Story point to jednostka miary wyrażająca ocenę całkowitego wysiłku niezbędnego do pełnego wdrożenia określonego obszaru pracy (funkcjonalności). Oznacza to, że jest to taka względna złożoność . Zespoły przydzielają punkty historii w oparciu o złożoność pracy, zakres pracy oraz ryzyko lub niepewność. Zwykle wartości te przypisuje się, aby efektywniej rozbić pracę na mniejsze części, eliminując w ten sposób niepewność. Z biegiem czasu pomaga to zespołom zrozumieć, co mogą osiągnąć w danym okresie i pozwala dokładniej planować kolejne obszary pracy. Może się to wydawać całkowicie sprzeczne z intuicją, ale ta abstrakcja jest w rzeczywistości całkiem użyteczna: zmusza zespół do podejmowania trudniejszych decyzji dotyczących złożoności pracy. Przyjrzyjmy się kilku powodom, dla których warto wykorzystywać punkty historii w planowaniu:

• można uniknąć niedokładności estymacji w przedziałach czasowych;
• W przeciwieństwie do szacowania w czasie, koszty ogólne można lepiej uwzględnić: komunikację między członkami zespołu a klientem, różne dyskusje i planowanie w zespole, a także nieprzewidziane sytuacje;
• Każdy zespół będzie oceniał pracę w innej skali, co oznacza, że ​​ich prędkość (mierzona w punktach) będzie inna;
• Definiując skalę przypisywania każdemu punktowi historii, możesz szybko i bez większych kontrowersji rozdzielać punkty.

Jak NIE wykorzystywać punktów fabularnych

Niestety punkty fabularne są często wykorzystywane do innych celów. Punkty fabularne mogą być błędne, jeśli wykorzystuje się je do oceny ludzi, określania szczegółowych terminów i zasobów oraz gdy błędnie traktuje się je jako miarę wyników. Zamiast tego zespoły muszą z nich korzystać, aby zrozumieć ilość/złożoność pracy przy każdym zadaniu i ustalić priorytety. Możliwe jest, że części ocenione jako trudniejsze zostaną wykonane w pierwszej kolejności, aby można je było ukończyć przed końcem sprintu , ale te łatwiejsze można odłożyć na później. Przypomnę czym jest sprint w kontekście metodyki Scrum : Długość tego okresu ustalana jest na początku rozwoju w drodze porozumienia pomiędzy zespołem a klientem. Może to być okres dwóch tygodni, miesiąca lub dowolnego innego okresu. Z reguły estymacja zadań przeprowadzana jest na początku sprintu, aby zaplanować możliwą ilość pracy wykonanej do końca sprintu, kiedy ukończona praca zostanie dostarczona do klienta. Pomaga zobaczyć postępy w rozwoju produktu, uzyskać informację zwrotną od klienta i dostosować rozwój projektu zgodnie z wizją klienta. Ale mimo to zróbmy małą dygresję: wróćmy do szacunków. Ocena zadań tylko przez jednego programistę byłaby zbyt subiektywna. Dlatego z reguły jest to praca zespołowa. Istnieje wiele technik oceny zespołu. Dziś przyjrzymy się najczęściej używanemu z nich – pokerowi Scrum . Ta technika wymaga menedżera, który będzie kimś w rodzaju lidera w pokerze Scrum . Może to być osoba specjalizująca się w Scrum Masterze lub PM .

Czym jest Scrum Poker

Poker Scrum – czyli poker planistyczny – to technika oceny oparta na osiągnięciu porozumienia. Używane głównie do oceny złożoności przyszłej pracy lub względnej liczby zadań do rozwiązania podczas tworzenia oprogramowania. Od razu zaznaczę, że poker Scrum jest powszechną praktyką w rozwoju i zdecydowanie musisz wiedzieć, co to za bestia. Do tego procesu wykorzystujemy zazwyczaj jakąś aplikację lub stronę internetową, która pozwala nam zorganizować zespołową ocenę konkretnego zadania. Jak to się stało? Zespół bierze element backlogu (nowe zadanie, funkcjonalność), krótko omawia możliwe pułapki i inne niuanse z nim związane. Następnie każdy uczestnik wybiera kartę z liczbą reprezentującą jego stopień trudności. Aha, i przy szacowaniu nie używa się zwykłych szeregów, ale liczby Fibonacciego . Liczby Fibonacciego są tak popularne w pokerze scrumowym , ponieważ różnica między nimi zwiększa się z czasem (przypominając poziomy piramid). Istnieją zadania, które będą miały ogromną złożoność i nie da się osiągnąć niewielkiej liczby punktów fabularnych. Wyjaśnienie nietypowych kart:

nieznana liczba punktów końcowych

nieskończenie długie zadanie

potrzebować przerwy

Rzadsze metody szacowania:

• w rozmiarach T-shirtów - S, M, L, XL
• albo u psów - chihuahua, mops, jamnik, buldog i tak dalej (moim zdaniem to najdziwniejsza jednostka oceny zadań =D)

Następnie zespół porównuje szacunki podane dla tego samego problemu przez różnych programistów i jeśli się zgadzają, świetnie! Jeżeli nie, należy omówić przyczyny różnic w ocenach (argumenty). Następnie możemy wspólnie dojść do jednego oszacowania, z którym wszyscy, plus lub minus, się zgodzą. Cóż, dlaczego poker jest w ogóle używany do planowania poważnego projektu oprogramowania? W końcu jest to w jakiś sposób dziwne. W rzeczywistości taka grywalizacja zachęca członków zespołu do samodzielnego myślenia, prosząc ich o pokazanie wyników w tym samym czasie, co ich koledzy z drużyny. To z kolei pozwala uniknąć uzależnienia od poglądów innych członków zespołu. W przeciwnym razie mniej doświadczeni programiści będą szukać i polegać na ocenach bardziej doświadczonych członków zespołu, co zanegowie przydatność własnej oceny. Ale przy jednoczesnym otwarciu wyników jest to w zasadzie niemożliwe. Przykładem aplikacji do planowania Scrum Poker jest firma Atlassian .

Przykład oceny zadania

Wyobraźmy sobie, że Twój zespół określił pewną skalę oceny w punktach historii: Scrum Poker rozpoczyna się od zadania, które oceniasz w następujący sposób:

• nigdy wcześniej nie pracowałeś z wdrożeniem podobnej funkcjonalności - +3
• funkcjonalność zadania średniej wielkości - +2
• realizacja zadania ma dużą złożoność - +3
• duża złożoność pisania testów dla tej funkcjonalności - +3

W rezultacie otrzymujesz 11 punktów historii, ale ponieważ nie ma takiej karty, oferujesz 13. Inny Twój kolega ocenia zadanie:

• pracowałem wcześniej z podobnym problemem - +1
• funkcjonalność zadania średniej wielkości - +2
• realizacja zadania ma średnią złożoność - +2
• średnia złożoność pisania testów dla tej funkcjonalności - +2

W rezultacie otrzymuje 7 punktów historii, ale w liczbach Fibonacciego nie ma czegoś takiego i kładzie kartę z najbliższą możliwą liczbą - 8. Odpowiednio pozostali członkowie zespołu podają szacunki na podstawie swoich subiektywnych poglądów. Następnie pokazujesz swoje wyniki i odkrywasz, że prawie wszyscy Twoi koledzy podali szacunkową kwotę 13, z wyjątkiem jednego programisty, który dał tę liczbę 8. W tym przypadku udziela się mu głosu i podaje powody. A oni na przykład są tacy: pracował wcześniej z tym samym problemem i wcale nie jest to takie trudne jak mogłoby się wydawać, a w końcu przekonuje resztę członków zespołu do zmiany rozwiązania z 13 na 8 pięter punktów, mówiąc, że pomoże temu, kto podejmie się tego zadania, rozwiąże to. Albo w końcu zrobi to sam. I w sumie nie ma znaczenia, czy inni słuchają jego argumentów, czy nie, ponieważ tak czy inaczej temu zadaniu zostanie przypisana ocena, a zespół przejdzie do zapoznania się z kolejnym. Za pierwszym razem szacunki będą niedokładne, podobnie jak szacunki ilości pracy, którą planujesz wykonać w następnym okresie (sprint). Przecież te szacunki są dokonywane właśnie na podstawie szacunków. Po pewnym czasie, około trzech miesiącach, zespół zacznie dokładniej szacować zadania i widoczny będzie średni nakład pracy, jaki zespół jest w stanie wykonać w ciągu jednego sprintu. Ale to jest ogólne planowanie zakresu prac, bardziej chodzi o czas i w tym przypadku wpływ może mieć wiele różnych czynników. Na przykład jeden z programistów wyjechał na dwa tygodnie na wakacje. Oznacza to, że musisz przekreślić określoną ilość planowanej pracy (planowana funkcjonalność). Albo do zespołu dołączył nowy programista, ale nie trzeba na nim w pełni polegać, bo... trzeba liczyć się z czasem potrzebnym na adaptację do projektu, tzw. onboardingiem . Mogą to być dwa tygodnie plus minus tydzień, w zależności od złożoności projektu. To tyle na dziś, mam nadzieję, że choć trochę poszerzyłem Waszą wiedzę w tak nietechnicznej części wiedzy jak szacowanie problemu. Jeśli chcesz zgłębić ten temat, a także szczegóły Scruma, gorąco radzę przeczytać książkę „SCRUM” Jeffa Sutherlanda. Za konsekwencje nie ręczę, bo być może po tym będziesz miał irytującą chęć zostania Scrum Masterem =D