Pewne grupowe uznanie wysiłków członka zespołu może być cennym czynnikiem motywującym, ale w tym przypadku wydaje się, że jest niewłaściwie stosowane. Stwierdzasz, że MVP jest wybierany w drodze głosowania, ale jest wiele wzmianek o liczbie błędów naprawionych na sprint. Wygląda na to, że Twój czas ma zabawną definicję MVP - przypuszczam, że osoba, która zasługuje na tytuł „najcenniejszego”, to osoba, która w tym sprincie zwiększyła wartość oprogramowania. Jeśli członek zespołu wybiera błędy, które można szybko naprawić, przebija je tak szybko, jak to możliwe i powoduje błędy regresji i inne problemy po ich zakończeniu, to nie dodaje wartości, tworzy więcej pracy dla każdego, kto ma śledzić je w celu zidentyfikowania i rozwiązania tych problemów.
Sugeruję, aby spróbować rozpocząć właściwą dyskusję następnym razem, gdy twój zespół uzyska jeden z tych głosów. Nie rób z tego pokazu rąk; omów to najpierw. Jeśli wydaje się, że ktoś zdobywa głosy na podstawie liczby dokonanych przez niego „poprawek”, wskaż (taktownie), gdzie te poprawki spowodowały regresje, i zasugeruj, że być może osoba, która naprawiła te regresje, powinna zostać nominowana do oczyszczenia innych osób bałagan. Jeśli ktoś spędził cały sprint podporządkowany jednemu nieprzyjemnemu problemowi, zwróć uwagę na zespół, podkreślając fakt, że chociaż liczba poprawek tej osoby wynosi jeden, to samodzielnie rozwiązali poważny problem z twoim oprogramowaniem - problem, który był tak paskudny, że nikt inny nie chciał go dotknąć.
Wybranie łatwych poprawek i wykonanie ich w pośpiechu lub przypadkiem nie jest cenne, więc programiści, którzy to robią, prawdopodobnie nie powinni kwalifikować się jako kandydaci do MVP. Wybierając nowego MVP, zapomnij o zespole i znajdujących się w nim ludziach i spójrz na oprogramowanie. Wybierz najważniejszą zmianę w tym oprogramowaniu od ostatniego razu. Mam tu na myśli singla ; „nie tak wiele drobnych błędów” nie jest znaczącą zmianą. Czy naprawiono szczególnie rażący błąd? Czy dodano świetną nową funkcję? Po ustaleniu, co to za jedna wielka zmiana, zapytaj, kto był za nią odpowiedzialny. Jedna z tych osób jest prawdopodobnie Twoim faktycznym MVP. Jeśli jedyną różnicą jest „nie tak wiele drobnych błędów”, to tylko i wyłączniewtedy liczenie błędów jest prawidłową miarą MVP - i nawet wtedy spojrzałbym na stosunek błędów naprawionych do błędów regresji spowodowanych. Każdy błąd, który ktoś powoduje, odejmuje co najmniej 1 od ich liczby. W rzeczywistości powiedziałbym więcej niż 1, ponieważ zła poprawka spowoduje nieznany błąd, który musisz następnie znaleźć, co jest gorsze niż znany błąd, który został już znaleziony. Znany błąd wymaga naprawy; nieznany błąd wymaga wysiłku zapewnienia jakości, a wysiłku programisty naprawić, a następnie istnieje ryzyko, że nie uda mu się to zrobić.
Teoretycznie, jeśli programiści zdadzą sobie sprawę, że drogą do nagrody jest rozwiązanie mniejszych, większych problemów, będą dążyć do tych trudnych, złożonych, blokujących defekty. Będzie to czasem wymagać od nich, aby się połączyli, albo dlatego, że nie ma wystarczająco dużo mięsistych problemów, aby je obejść, albo dlatego, że problem jest na tyle trudny, że wymaga więcej zestawów oczu . Być może zasugeruj, że w takich przypadkach nagroda może być dzielona, jeśli nie jest od razu jasne, który z zestawów ludzi pracował więcej w celu naprawienia błędu - i pamiętaj, praca wykonana! = Napisane wiersze kodu. Deweloperzy prawdopodobnie to wiedzą, ale powiedzieliście, że zarządzanie jest zaangażowane, a zarządzanie nie zawsze rozumie ten punkt.
I hej, jeśli wszystko inne zawiedzie, zapomnij o programie MVP. Porozmawiaj z innymi programistami spoza scrum i zwróć uwagę na negatywny wpływ nagród MVP na oprogramowanie. Sprawdź, czy uda ci się je zignorować, czy nie sprawi, że będzie to taka wielka sprawa. Zostaw trofeum w szufladzie, wydaj nagrodę pieniężną na drinka dla zespołu po pracy, skorzystaj z darmowego lunchu, aby zdobyć coś, czym możesz się podzielić, na przykład babeczki. Agile to system zespołowy; podkreślanie indywidualnych ryzyk związanych z wydajnością, które stawiają zespół przeciwko sobie. Zjednoczeni stoicie, podzieleni, wysyłacie oprogramowanie wypełnione błędami, po terminie przekroczenie budżetu.