Dlaczego Story Points to fatalna metryka dla inżynierów oprogramowania

Powiedzmy to sobie szczerze, nasza branża ma obsesję na punkcie idei, że więcej znaczy lepiej — multitasking, długie godziny pracy, praca na wysokich obrotach, wiele spraw na głowie.

Jednak wraz z wejściem w życie nowego podejścia do pracy, jak np. praca zdalna, środowisko rozproszone, zdajemy sobie sprawę, że pewne rzeczy, które już się nie sprawdzają, muszą pozostać w przeszłości. Dotyczy to korzystania z vanity metrics (wskaźników próżności) oraz przestarzałych sposobów mierzenia wydajności.

Więcej nie zawsze znaczy lepiej, zwłaszcza jeśli chodzi o mierzenie wydajności inżyniera oprogramowania.

NIEDOBRZE: Wykorzystanie ukończonych Story Points do pomiaru wydajności inżyniera oprogramowania

Wykorzystanie Story Points zawsze było gorącym tematem dyskusji. Niektórzy twierdzą, że przydaje się to zespołom programowania zwinnego, inni natomiast, że jest to kompletnie nieprzydatne dla biznesu. Obie grupy mają rację. Tutaj jednak mam wyrobione zdanie, jako ktoś, kto pracował w wielu zespołach programistycznych, zarówno jako programista, jak i menedżer inżynierii oprogramowania w ciągu ostatnich dwóch dekad mojej kariery. Story Points to zła miara wydajności programisty.

Dlaczego Story Points są kiepskim wskaźnikiem wydajności?

Nie wszystkie Story Points są takie same

Story Points są miarą złożoności w odniesieniu do wiedzy osoby lub zespołu dokonującego oszacowania. W związku z tym, Story Point 3 jednego zespołu może nie być taki sam jak Story Point 3 innego zespołu. Dlatego też, gdy porównujesz wielu inżynierów z różnych zespołów w zakresie ich dostaw, Story Points nie są właściwymi metrykami, których należałoby użyć.

Większa liczba Story Points nie oznacza większego wpływu

W rozwoju oprogramowania, proste znaczy piękne. Bardzo często duża liczba Story Points jest wynikiem złożonych ścieżek kodu, a nagradzanie większą liczbą Story Points w pewien sposób zachęca programistów do bardziej złożonego sposobu myślenia i kieruje w stronę „przeinżynierowania” swoich rozwiązań. Najlepszym sposobem, aby inżynier dowiedział się o swojej wydajności, jest spojrzenie na wyniki, które dostarcza oraz na wpływ, jaki wywiera na klientów. Nie to, jak dużo kodu napisze, lub czy jest wystarczająco skomplikowany.

Story Points dają zbyt dużą elastyczność i zachęcają do mniejszej odpowiedzialności

Story Points nie mówią nam, jak odpowiedzialny i niezawodny jest inżynier. Jasne, mogą pracować nad najbardziej złożonymi (relatywnie) historyjkami, ale to nie znaczy, że robią to najlepiej, dostarczają na czas i wykazują się właściwym zachowaniem.

Najgorszą rzeczą w Story Points jest to, że umożliwiają one inżynierom brak zobowiązania się do jakiejkolwiek daty. Rozumiem, że wielu inżynierów generalnie nie chce się zobowiązać do terminu na wypadek, gdyby odkryli jakieś niewiadome, jednak brak wyznaczenia jakichkolwiek terminów, kiedy coś zostanie zrobione, lub brak wyznaczenia terminu kluczowego etapu pracy jest zwyczajnie nieodpowiedzialne.

Seniorzy mogą mieć mniej czasu na kodowanie

Wraz z rozwojem kariery inżyniera, może się okazać, że faktyczne kodowanie / praca nad developmentem będzie coraz rzadsze, ponieważ będą robić inne rzeczy wymagające dłuższego stażu, takie jak planowanie, story breakdown, mentoring, onboarding, review kodu itp. Jest to tym bardziej prawdziwe, jeśli pracują dla dużej firmy technologicznej, ponieważ wymagana jest o wiele większa koordynacja i dzielenie się wiedzą. W procentach będzie to blisko lub ponad 50%, w zależności od wielkości firmy, złożoności projektu i stażu pracy.

DOBRZE: Mierzenie wydajności w odniesieniu do kompetencji właściwych dla danego poziomu

Po pierwsze, pozwólcie, że to powiem: wydajność inżyniera nigdy nie powinna być mierzona liczbą przepracowanych godzin lub napisanych linii kodu. Miarą powinny być osiągnięte wyniki.

Brzmi to jednak nieco abstrakcyjnie, więc pozwólcie, że wyjaśnię, o co mi chodzi.

Firmy technologiczne mają tendencję do mierzenia wydajności swoich inżynierów i programistów na podstawie kompetencji właściwych dla ich poziomu i pełnionej funkcji. A duże firmy technologiczne, takie jak FAANG (Facebook, Amazon, Apple, Netflix i Google) mają udokumentowane informacje o tych oczekiwaniach, więc w pewnym sensie jest to bardzo obiektywne.

Powszechne kompetencje (w kolejności od juniora -> seniora) to:

• Umiejętności techniczne,
• Umiejętność planowania pracy (rozłożenie na części pierwsze dużego problemu na łatwe do opanowania zadania),
• Umiejętność szacowania,
• Umiejętności komunikacyjne,
• Umiejętność zarządzania kwestiami związanymi z interesariuszami,
• Umiejętność wywierania wpływu na ludzi,
• Umiejętność mentoringu.

Od juniorów niekoniecznie oczekuje się umiejętności zarządzania kwestiami związanymi z interesariuszami i wywierania wpływu, ale w miarę stopniowego wspinania się po szczeblach kariery oczekuje się, że będą wykazywać coraz więcej umiejętności z dolnej części listy.

DOBRZE: Uzyskanie wartościowego feedbacku, np.: ocena 360°, dotycząca inżyniera oprogramowania

Pracując jako inżynier oprogramowania w dzisiejszych czasach, gdzie złożoność rozwoju wzrosła, nie wystarczy, aby schować głowę w komputer i kodować. Umiejętność dobrej współpracy z innymi w celu osiągnięcia lepszych wyników jest ważną częścią roli programisty.

Dlatego ważne jest, aby otrzymać ocenę 360° na temat inżyniera od osób, z którymi współpracuje, aby zrozumiał, jak skuteczny jest w osiąganiu wyników, jako osoba będąca częścią zespołu. W dzisiejszym środowisku pracy nie ma miejsca dla błyskotliwych palantów.

Mierzyć to, co ważne

Krótko mówiąc, istnieją zarówno jakościowe, jak i ilościowe wskaźniki, kiedy myślimy o wydajności programistów. Jakościowe metryki, takie jak opinia 360° i ilościowe, takie jak wpływ zaktualizowanych funkcji są często brane pod uwagę, ale patrząc na inne wskaźniki próżności, takie jak linijki kodu lub ukończone Story Points, to powinny być od nas trzymane z daleka.

• NIEDOBRZE: Wykorzystanie ukończonych Story Points do pomiaru wydajności inżyniera oprogramowania
• DOBRZE: Mierzenie wydajności w odniesieniu do kompetencji właściwych dla danego poziomu
• DOBRZE: Uzyskanie wartościowego feedbacku, np.: ocena 360°, dotycząca inżyniera oprogramowania

Oryginał tekstu w języku angielskim przeczytasz tutaj.