Czy w punktach historii należy brać pod uwagę indywidualną zdolność?

Rozumiem szacowanie historii w taki sposób, że należy oszacować rozmiar opowieści, tak jak w przypadku wyobrażonego przeciętnego autora - trochę jak koncepcja „rozsądnego obserwatora” w prawie. Oznacza to, że nie powinieneś szacować wielkości historii, zakładając, że musisz to zrobić .

Na przykład: w poprzedniej pracy należałem do zespołu, w którym byłem zdecydowanie najbardziej zaufanym programistą Ruby. Moi koledzy z drużyny rutynowo oceniają historie związane z Ruby o wiele bardziej niż ja, z argumentami takimi jak: „Cóż, nie wiem, jak X działa w Ruby, więc zajęłoby mi to wieki”.

Mój argument przeciw to wynika z faktu, że sprint planowania jest gdzie pojemność zespołu wchodzi w grę. To prawidłowe forum do powiedzenia: „Nasza zdolność do tego sprintu będzie nieco niższa niż zwykle, ponieważ większość zadań jest oparta na Ruby, a my mamy tylko jednego silnego programistę Ruby”. Uwzględnienie tego podczas szacowania podwoiłoby ten aspekt.

Będę wdzięczny za wszelkie autorytatywne odniesienia w odpowiedziach, ale proste opinie też byłyby świetne.

Punkty fabularne są względną oceną. Zatem dwa punkty oznaczają dwa razy więcej wysiłku. Względne szacunki są mniej zależne od zmian poziomu umiejętności. Pytanie nie polega na tym, ile czasu zajęłoby ci 1 punkt, ale że 2 punkty wymagają 2 razy więcej potencjalnego wysiłku. Poziom umiejętności może mieć większe znaczenie, jeśli weźmiesz idealne dni zamiast punktów fabularnych, ponieważ zakładasz indywidualny poziom wydajności.

Względne szacunki są bardziej wiarygodne. Ponadto ocena punktu fabularnego nie powinna być przeprowadzana przez osobę, ale wynikać ze wspólnego wysiłku zespołu . W przypadku mniej skomplikowanych historii zazwyczaj istnieje szybka zgoda. W przypadku trudniejszych historii zespół przyjdzie z wynikiem, z którym większość członków się zgodzi, a zatem pośrednio weźmie pod uwagę zbiorowy poziom umiejętności zespołu.

Wreszcie, ocena historii jest przeprowadzana w momencie, gdy zadania w zespole niekoniecznie są już ustalone. To kolejny argument, aby nie brać pod uwagę poziomu umiejętności poszczególnych osób. Podczas planowania sprintu weźmiesz pojemność zespołu, która będzie ewoluować w oparciu o rzeczywiste wyniki, tak aby dostosowała się do globalnego poziomu umiejętności Twojego zespołu.

Podsumowując, ocena indywidualna nie powinna być brana pod uwagę. Ale nawet gdyby tak się stało, ze względu na zbiorowe szacunki i solidność względnego podejścia, nie miałoby to tak wielkiego znaczenia.

Odpowiedzią kanoniczną jest to, że nie powinieneś zmieniać oszacowań na programistę. Oznaczałoby to, że dostajesz o wiele więcej punktów za sprint niż inni, i to dobrze, ponieważ punkty mierzą prędkość zespołu , a nie deweloperów. Firma może oszacować, ile wyprodukuje zespół, aby uzyskać surowe oczekiwania dotyczące dostawy, a wszystko jest świetne.

To jednak powoduje różnego rodzaju problemy w praktyce. Co się stanie, jeśli będziesz na wakacjach w tym tygodniu? Co się stanie, gdy nadejdzie czas przeglądu i zdasz sobie sprawę, że produkujesz 200% średnich punktów opowieści za 110% średniej pensji? Co się stanie, gdy biznes zacznie myśleć, że prędkość zespołu podzielona przez ludzi jest w rzeczywistości dokładnym przybliżeniem? Co się stanie, gdy firma zda sobie sprawę, że produkujesz znacznie więcej błędów niż inni (ignorując, że produkujesz o wiele więcej funkcji)? Co składa się na historie „wielkości ugryzienia”, gdy ludzie mają tak różnorodne ugryzienia?

W trakcie mojej kariery odkryłem, że w dużej mierze nie ma to znaczenia. Proces służy wam, a nie odwrotnie. Jeśli Twoja organizacja musi ocenić, czy deweloperzy są przeciążeni, dobrym pomysłem są punkty fabularne na twórcę. Jeśli Twoja organizacja musi zmierzyć prędkość drużyny, to Dev-agnostyczne punkty historii zapewnią wyraźniejszy obraz. Jednak zawsze są one przybliżeniem i zawsze będą nadużywane i źle interpretowane.

W końcu są to punkty za złożony proces, który musisz dostosować do swojego środowiska.

TL; DR
Zawsze należy zakładać, że tylko kompetentni programiści zostaną przypisani do konkretnej historii.

Kompetencje (lub ich brak) nie są obrazą. Jest to po prostu rozsądny miernik umiejętności programisty, który nie pozostaje w tyle ani nie ma wyjątkowego doświadczenia.

Może to być kwestia podejścia konkretnej firmy. Widziałem, jak firmy dostosowują szacunki do konkretnych programistów. Widziałem także firmy, które wprowadziły system, w którym trzech losowo wybranych programistów dokonuje oszacowań historii, zanim niemal losowo przypisuje programistę (nie jedną z pierwszych trzech) do zadania.

Każdy system może działać, każdy system może zawieść. Nie chodzi o to, który system jest lepszy, ale o to, jakie wady firma jest w stanie / jest w stanie sobie poradzić .

Zasadniczo nie należy uwzględniać czasu nauki na opanowanie języka / struktury. Niewielka styczna: chociaż nie powinny istnieć w idealnym świecie, należy uwzględnić czas poświęcony na przeszkody związane z projektem lub historią.

Jest na to wiele uzasadnień, ale uważam, że takie podejście jest ogólnie lepszym wyborem, ponieważ jest zgodne z intencją oszacowania obciążenia pracą. To może być tylko kwestia mojej opinii, a nie obiektywności. Nie mogę powiedzieć na pewno.

Czas nauki jest osobisty . Jest to możliwe dla konkretnego programisty, który musi pracować nad określoną technologią. Nie ma to znaczenia przy ocenie obciążenia historii użytkownika, ponieważ historia użytkownika leży wyłącznie w zakresie aplikacji (i stosowanej przez nią technologii).

Czas nauki na ogół się nie kumuluje. Powiedzmy, że nasz debiutant niewiele wie o C # i szacujemy, że potrzebuje trzech dodatkowych dni, aby dowiedzieć się o środowisku, zanim będzie mógł wykonać pracę. Jak to często bywa w wielu firmach, w których pracowałem, jesteśmy teraz na spotkaniu, na którym spodziewamy się oszacowania kilku historii użytkowników (indywidualnie). Dla przykładu załóżmy, że mamy trzy historie do rozwiązania.

• Czy dodajemy trzy dni do każdej historii? Jeśli wszystkie trzy historie mają podobny techniczny charakter, oznacza to, że debiutant nie będzie potrzebował dodatkowego czasu na drugą i trzecią historię. Przeceniliśmy pracę o sześć dni.
• Czy dodajemy jeden dzień do każdej historii? To też nie jest poprawne. Jeśli skończymy tylko przypisywaniem nowicjusza do jednej z trzech opowieści, to zmieniliśmy mu dwa potrzebne dni nauki; i daliśmy dwa niepotrzebne dni na naukę innym programistom.
• Czy dodajemy trzy dni do jednej historii? Jak możemy zagwarantować, że ta historia zostanie omówiona przed pozostałymi dwoma? Cały sens tworzenia oddzielnych historii użytkowników polega na tym, że historie można zazwyczaj rozwiązywać niezależnie od siebie. Poprawność naszych szacunków opiera się teraz zarówno na założeniu, że nasz debiut wykona pracę, a także na kolejności, w której przydzielono mu te zadania (jeśli ma to znaczenie, np. Jeśli łączny nakład pracy przekracza pojedynczy sprint).

Uwaga :
Istnieją inne przypadki, w których czas na naukę się kumuluje, np. Jeśli trzy historie dotyczą bardzo różnych tematów i wymagają różnych umiejętności.
Aby dowiedzieć się, czy tak jest w istocie, musielibyśmy spojrzeć na wszystkie trzy historie jednocześnie, co powoli zaczyna naruszać zasadę niezależnych historii użytkowników. Gdybyśmy omawiali te szacunki na osobnych spotkaniach, być może z udziałem różnych programistów; nie bylibyśmy w stanie dokładnie ocenić nakładania się opowieści.

Ponieważ nie możemy zagwarantować, które historie faktycznie zostaną ukończone (klient może odmówić dużego oszacowania) i kto zostanie do nich przypisany, próba przypisania konkretnego dewelopera do określonej historii jest daremna. Kończy się to tylko zabłoceniem wody.

Zamiast tego powinniśmy oszacować obciążenie pracą, zakładając, że nowicjusz został już przyspieszony (i dlatego jest równym programistą dla swoich współpracowników).
Takie oszacowanie jest niezależne od dewelopera, a zatem poprawność oszacowania nie zmienia się w zależności od tego, który deweloper ostatecznie zostanie przypisany do historii.

Uwaga
Należy nadal pamiętać , że konkretny programista może potrzebować dodatkowego czasu na naukę, zanim będzie mógł zająć się określoną historią. To wciąż bardzo ważna kwestia. Ale ta uwaga nie powinna być powiązana z historią , ale raczej przypisaniem tego konkretnego autora do tej konkretnej historii.

Ale od samego początku może się to różnić w zależności od firmy. Niektóre firmy mogą nie przejmować się czasem nauki (np. Czy programista i tak nieuchronnie będzie musiał nauczyć się korzystać z technologii). Inni mogą w dużym stopniu polegać na dokładności tych szacunków, ponieważ mają one wpływ na fakturowanie klienta.

Ostatecznie chodzi o to, żeby wybrać swoją truciznę. Żadne z tych podejść nie jest gwarantowane bardziej dokładne niż inne.

To złożony temat i często odbywają się na nim debaty. Nie podoba mi się koncepcja „kanonicznej” opinii na ten temat: są różne opinie o wartości. Istnieją jednak wartości wspierające, zasady i praktyki, które powinny kierować podejściem.

Poniższe informacje oparte są na moich własnych opiniach dotyczących współpracy z zespołami scrumowymi od ponad 10 lat. Ale to tylko MOJA opinia.

1. Punkty opowieści jako metoda prognozowania Pierwotnym celem punktów opowieści było znalezienie szybkiej metody oszacowania wysiłku w celu prognozowania, co zespół może ukończyć w danym okresie. Niektóre z „opraw oświetleniowych” stwierdzają, że punkty są używane tylko do prognozowania zakresu długoterminowego (na przykład w ramach wydania), a nie do określania wydajności na poziomie sprintu. Dodatkowo, koncepcja polega na tym, że zespoły stosują „względny dobór” w oparciu o wartości historyczne (wysiłek X jest podobny do wysiłku B, który wynosił 3 punkty). Przyspiesza to proces szacowania, dzięki czemu zespoły nie muszą dzielić przyszłej pracy na szczegółowe pakiety robocze i stosować godzin do wszystkich zadań. Wysoko wydajne zespoły starają się, aby wszyscy pracownicy techniczni stali się bardzo kompetentnymi członkami o podobnych poziomach umiejętności. (Ta koncepcja zostanie omówiona bardziej szczegółowo w punkcie # 4). Po osiągnięciu tego poziomu indywidualny poziom umiejętności nie jest tak naprawdę zmienny w doborze. ALE: Osiągnięcie tego celu zajmuje zwykle sporo czasu i wysiłku. SO ... co robimy, zanim tam dotrzemy?

2. Godziny zadań określają pojemność sprintu: Według tych samych „opraw”, którzy twierdzą, że punkty są wykorzystywane do prognozowania długoterminowego, proponują również użycie godzin zadania do określenia zdolności sprintu, a nie punktów. Moim zdaniem jest to w porządku, ale powiem, że kiedy pomogłem drużynom trenerskim w „wysokiej wydajności”, ich wyrównywane umiejętności uśredniały do ​​miejsca, w którym mogliby dokładnie określić, co mogą ukończyć w sprincie, używając tylko Punktów Story . Ponownie może to być cel, do którego dążymy, ale nowsze zespoły nie są na to przygotowane. Dlatego w jednym sprincie możesz znaleźć Historię z 2 punktami, która ma 12 godzin wysiłku zadania, a druga z 25 godzinami wysiłku. Więc co robisz? Niektórzy ludzie, których nazywam „zwinnymi purystami” stwierdzą, że wielkość Opowieści (w punktach) powinna być agnostyczna do czasu trwania. Inni się nie zgadzają. Przeczytaj logikę punktu 3 i zobacz, co myślisz.

3. Opowiadanie historii przez konsensus: stosowanie tomu, niewiadomych, złożoności, wiedzy

Zespoły patrzą więc na kawałek pracy i muszą uzgodnić punkty, które będą wyznacznikiem poziomu wysiłku. Dobrze? Zakładając, że wszystkie umiejętności są równe, łatwo jest osiągnąć konsensus. Ale często zespoły mają faceta, który jest guru Java, innym, który nie jest tak świetny w Javie (może była osobą C # lub .Net lub Cobol i uczy się Java). Zadanie X dla Boba jest bardzo proste. Dla Jane jest to trudniejsze.

Zwinne zespoły starają się promować zbiorowe prawa własności do kodu oraz poszerzanie / poszerzanie wiedzy specjalistycznej. Dlatego zwykle nie przypisujemy historii osobom na podstawie ich wiedzy: wolimy zespoły wspólnie pracują nad historiami i uczą się razem. Jest to zgodne z koncepcją „zwolnij, aby przyspieszyć”: jeśli poświęcimy czas na zapewnienie Jane doświadczenia z Javą, podczas gdy może to nas początkowo spowolnić, później będziemy mieli bardziej kompetentnych programistów Java. W rzeczywistości, jeśli mamy tylko JEDNEGO eksperta Java i wszyscy pracują nad własnymi obszarami specjalizacji, tworzymy sytuację z wieloma potencjalnymi „punktami awarii”. Co dzieje się w sprincie, gdy 90% pracy to Java, ale Bob (nasz ekspert Java) jest chory lub na wakacjach? Rozwijając umiejętności, eliminujemy potencjalne wąskie gardła i zmniejszamy ryzyko. Pamiętając o tym: Kiedy zespół patrzy na historię, powinien mieć na uwadze kilka koncepcji przy doborze. Możesz pomyśleć o akronimie VUCK, aby to zapamiętać.

Tom: Niektóre wysiłki są dość proste, ale wymagają dużej ilości powtarzanych zadań. (Miałem faceta, który musiał skopiować i ponownie sformatować stoły 50+, który powiedział, że był to 1 punkt, ponieważ było to proste. Ale po zastanowieniu zespół zdał sobie sprawę, że chociaż jest to łatwe, to jest czasochłonne i istnieje duża liczba stołów do zostać przeniesionym i zoptymalizowanym. Musieliśmy więc dostosować punkty ze względu na ilość pracy)

Nieznane: czasami MYŚLIMY, że wiemy, co robić, ale identyfikujemy również pewne niewiadome - reprezentują one RYZYKO . Oznacza to, że możemy napotkać nieoczekiwane problemy, które musimy rozwiązać, przeprojektować lub wypróbować inne rozwiązanie.

Złożoność: ta jest dość oczywista. Niektóre rozwiązania są technicznie złożone. Wiemy dokładnie, co robić, ale wymaga to specjalistycznej wiedzy technicznej. Złożoność wiąże się również z pewnym ryzykiem, prawda? Więc nawet jeśli wszyscy mamy takie same umiejętności, złożoność techniczna oznacza, że ​​możemy napotkać nieprzewidziane wyzwania. Możemy więc powiększyć tę historię.

Wiedza: Czy NAPRAWDĘ wiemy, co rozwiązujemy? Czasami klienci nie do końca wiedzą, jakiego chcą rozwiązania, i eksperymentujemy trochę. A może nikt nigdy nie wdrożył tego rozwiązania (nowa technologia nigdy wcześniej nie była używana), więc nie wiemy, czego nie wiemy.

Moim zdaniem każde z tych rozważań jest w rzeczywistości pełnomocnikiem na dłuższy czas. Łatwa historia, dużo objętości? Zajmie to więcej czasu lub musimy podzielić historię. Nieznane? Dodatkowe ryzyko, badania, eksperymenty, może to potrwać dłużej lub musimy podzielić historię. Złożony? Dodano ryzyko, trzeba naprawić błędy, przeprojektować itp., Więc może to potrwać dłużej. Nie wiesz, czy mamy wymaganą Wiedzę? Mamy dodatkowe ryzyko, być może będziemy musieli eksperymentować itp., Więc może to potrwać dłużej ...

Widzisz dokąd to zmierza? Tak więc, chociaż koncepcja punktów opowieści zniechęca nas do myślenia o czasie trwania przy szacowaniu, z drugiej strony nielogiczne byłoby posiadanie 1-punktowej historii, którą możemy ukończyć w 4 godziny, i kolejnej 1-punktowej historii, która jest prosta, ale zajmie 2 tygodnie.

4. Zespoły o wysokich wynikach eliminują silosy i wąskie gardła: ponieważ zespoły próbują wyrównać wszystkich członków, czasami mają mniej doświadczonych członków podejmujących nowe wyzwania lub łączą w pary, aby dzielić się wiedzą w celu poprawy jako zespół. Jak wspomniano wcześniej, jest to konieczne, jeśli zespół kiedykolwiek osiągnie prawdziwy poziom wysokich osiągów.

Więc jeśli Jane zgłosi się na ochotnika, aby podjąć wysiłek związany z Javą, a to spowodowałoby, że wysiłek ten byłby 2x lub 3x dłuższy niż ten sam wysiłek, gdyby Bob to zrobił, co robisz? Z biegiem czasu moje zespoły zdecydowały się na sortowanie opowieści na podstawie poziomu wysiłku (LOE) / VUCK dla osób pracujących. Bob, zespół Guru, nie ma sensu mówić „to jest 1”, kiedy dla Jane nie będzie to łatwe i zajmie tydzień, a do tego zajmie trochę czasu Boba na kodowanie par i przegląd kodu. Dlatego podnieśliśmy te punkty, aby odzwierciedlić prawdziwą LOE. Następnym razem, gdy pojawiła się podobna historia, 8 to dla Jane wcześniej 5. W końcu wszyscy zgodzili się, że to łatwe 3. W tym momencie wiedzieliśmy, że rozwijamy się jako zespół.

TLDR

Nie, ale może nie z tego powodu, dla którego myślisz.

Długa wersja

Wiele innych odpowiedzi wyjaśnia, że ​​punkty fabularne należy obliczać wyłącznie w odniesieniu do innych prac. To jest absolutna prawda. Ponieważ Punkty Story szacują ilość pracy, a nie czas potrzebny na jej ukończenie, nie ma sensu dawanie Punktów Story na podstawie osoby.

Na przykład (jeden z moich ulubionych), rozważ swoje zadanie „Wykop dziurę”. Możesz to oszacować na podstawie ilości ziemi do usunięcia lub czasu, który zajmie ci usunięcie ziemi. Mój przyjaciel kopie całość w tempie 3 metrów na godzinę, mam dużą koparkę mechaniczną, więc mogę zarządzać 100! Jedyną stałą jest ilość ziemi - dlatego właśnie tego używamy jako naszej jednostki szacunkowej.

Jednak drugim (i moim zdaniem ważniejszym) powodem obniżenia zdolności programistów do szacowania historii użytkowników jest fakt, że prawie każda historia użytkownika będzie prawdopodobnie przetwarzana przez wiele osób.

Możesz mieć architekta, programistę, testera, być może drugiego programistę, który wykona interfejs użytkownika. Zanim Twoja historia użytkownika zostanie oznaczona jako Gotowa (najlepiej wdrożona i wykonana), wiele różnych osób będzie nad nią pracować. Nagle pomysł oszacowania na podstawie danego dewelopera nie ma większego sensu, jedynym sposobem na dokładne oszacowanie, ile wysiłku będzie wymagał zespół, jest zmierzenie prędkości zespołu i oszacowanie pracy zespołu do ukończenia.

W zespole nie ma „ja” i absolutnie nie ma zwinnego planowania!