Kiedy mój menedżer powiedział zespołowi, że „ historie użytkowników, które odniosą sukces, będą brane pod uwagę do oceny! ”
Siedzieliśmy tam zszokowani i to był jeden z kilku niesamowitych momentów, które nam dał :-)
Uznaliśmy, że to głupi pomysł, ponieważ zrujnuje to wszystkie koncepcje i cel zwinnej metodologii rozwoju.
Daj mi znać, co myślisz? i jak go przekonać?
Odpowiedzi:
Sandy, niestety oświadczenie twojego kierownika jest klasycznym nieporozumieniem w szczególności scrum i zwinnym w ogóle.
Proponowane podejście zabija współpracę i przeciwstawia się zasadzie zbiorowego posiadania kodu . Historie użytkownika w zwinnym (jeśli jest to naprawdę zwinne) rzadko kończą się zanim zostaną dotknięte przez wiele osób. Ponadto od czasu do czasu będziesz mieć historie użytkowników, które wymagają roju , aby zakończyć się w iteracji. Jak do tego dojdziecie, gdy poszczególne zachęty zostaną wyrównane o 180 stopni w przeciwnym kierunku?
Instynkty twojego zespołu są prawidłowe. Jakie źródła zasugerowałbym w najbliższym czasie do przeczytania podczas burzy mózgów na temat odpowiedzi do swojego przełożonego? Przejrzyj blogi znanych ekspertów zwinnych, takich jak Mike Cohn , Martin Fowler , Elizabeth Hendrickson , Jurgen Appelo , Esther Derby i kilku innych, i poszukaj artykułów na temat zwinnej organizacji zespołu.
Mój główny sprzeciw wobec tej metody oceny jest taki, że może ona stanowić przeszkodę we współpracy między programistami. Myślę, że ważną częścią wydajności zespołu programistów jest chęć członków zespołu, aby sobie pomagali. Jak rozumiem sugerowany schemat, może to prowadzić do tego, że programiści będą trzymać się przypisanych im zadań i ignorować innych członków zespołu, którzy utknęli i mogliby łatwo zostać zablokowani przez niewielką pomoc.
Zawsze szukamy wkładu, jaki programista wnosi w zespół i biznes.
Jest to na równi z mierzeniem linii kodu lub liczby błędów - ale nieco bardziej wyrafinowane.
Na pierwszy rzut oka nie ma nic złego w pomiarze, ale kiedy o tym pomyślisz, zaczynasz zgłaszać zastrzeżenia:
jest najbardziej oczywisty, jaki przychodzi mi do głowy - jestem pewien, że są jeszcze inni.
Twój kierownik oczywiście uważa, że jest to dobry pomysł, więc musisz uważać, aby zgłaszając zastrzeżenia, można również przedstawić rozwiązania. To rozwiązanie może być modyfikacją jego schematu, a nie nowym schematem.
Na przykład możesz wskazać, że ktoś, kto pracuje nad „łatwymi” historiami, ukończy więcej niż ktoś, kto pracuje nad „trudniejszą” historią, co może prowadzić do koncentracji na mniej ważnych aspektach rozwoju. Tak więc jednym rozwiązaniem może być rozważenie liczby punktów opowieści, a nie tylko liczby opowieści.
Zgadzam się z ChrisF, że w przypadku każdego pomiaru powraca ten sam problem. To, co chwalisz, to to, co dostajesz. Zawsze znajdą się ludzie, którzy będą grać w system, czymkolwiek będzie ten system.
Jedyna prawdziwa skuteczna metoda nagradzania programisty składa się z trzech kroków.
Cały klucz polega na tym, że programiści nie są trybikami w maszynie, którą można „dostroić”, patrząc na statystyki. Prawdziwi ludzie muszą zostać zbadani i ulepszeni jako całość, a zespół musi być w stanie polegać na sobie w sposób kooperacyjny, a nie konkurencyjny.
Słabi wykonawcy w zespole mają wszelkie możliwości poprawy i wzbogacenia, zanim zostaną uznani za zwolnionych. W końcu dobrzy programiści będą prosperować w tym środowisku, a biedni programiści, którzy odmawiają poprawy, zostaną wypuszczeni.
Przez większość czasu historie użytkowników są wypełniane wspólnie. To praktycznie uniemożliwia oparcie indywidualnej oceny na tym wskaźniku.
Metryką można łatwo manipulować, ponieważ proces planowania jest również wysiłkiem zespołu, a nawet wcześniej niż później cały system zostaje zmontowany. Tego zdecydowanie nie chcesz w procesie skoncentrowanym na ludziach.
Myślę, że dobrą wydajność musi docenić jakiś system premiowy oparty na sukcesie zespołu, ale Historie użytkowników nie są dobrym wskaźnikiem sukcesu.