Mamy „typowy” zespół SCRUM i zobowiązujemy się do pracy na sprincie, a także utrzymywania zaległości. Ostatnio napotkaliśmy problem z próbą zintegrowania / obsługi pracy nadrzędnego programisty wykonującego pracę poza pasmem (wybranie pracy poza normalnymi godzinami pracy / sprintem).

Na przykład, jeśli zespół przyjmie 50 punktów pracy, powiedzmy, że wykonają całą pracę w ramach SCRUM do końca sprintu, a oni i firma będą zadowoleni. Jeden z członków zespołu decyduje się na pracę na własną rękę, na element zaległości, w wolnym czasie. Nie sprawdzają tej pracy, ale ją zapisują (używamy TFS i jest na półce).

Jak sobie z tym poradzić? Kilka problemów ..

• Podczas następnego sprintu członkowie tego zespołu twierdzą, że programowanie zostało wykonane w 99% i wymaga jedynie przeglądu i testowania kodu. Jak sobie z tym radzisz w SCRUM i metodologii zwinnej?
• Inni deweloperzy narzekają, że nie byli zaangażowani w decyzje projektowe związane z tymi historiami, ponieważ praca została wykonana poza zespołem.
• Nasz właściciel produktu ma pokusę, aby zaangażować się w tę „darmową” pracę, a przeważający członkowie prawdopodobnie robią to celowo, aby uzyskać więcej funkcji w produkcie, których zespół w innym przypadku nie byłby w stanie wykonać w sprincie (sprintach). Istnieje pogląd, że łamie to „proces”. Oczywiście prace związane z kontrolą jakości, interfejsem użytkownika i dokumentacją wciąż wymagają wykonania.

Widzę wiele dyskusji na temat nie zmuszania zespołu SCRUM do pracy w godzinach nadliczbowych, ale co z członkiem zespołu pracującym ponad oczekiwania wykraczające poza oczekiwania przedstawione podczas planowania i wykonywania sprintu? Wahałbym się, aby zapanować nad tą osobą i powiedzieć, że nie możesz pracować dodatkowo (oczywiście ostrzegając przed wypaleniem), ale jednocześnie wydaje się, że powoduje to pewne problemy z niektórymi członkami zespołu (ale nie wszystkimi).

Jak zintegrować pracę wykonaną przez nadrzędnego członka z SCRUM i sprawnym procesem tworzenia oprogramowania?

W porządku, więc ktoś entuzjastycznie pisze świetny kod, który należy wykonać, ale nie w porządku. Z całym należytym naciskiem:

POZWÓL IM

Powoduje to pewne komplikacje w twoich sprintach. Czy to naprawdę ma znaczenie w wielkim schemacie rzeczy? Jeśli osiąga to, co powinien, pozwól mu kontynuować i budować dla Ciebie wspaniałe rzeczy.

Znam kilku niesamowitych programistów, którzy opuścili firmy, ponieważ nie pozwolili programistom wykroczyć poza ograniczenia sztucznego systemu, takiego jak Scrum (sam zrezygnowałem z mojej ostatniej pracy po tym, jak byłem traktowany jak chwalona QA). Jeśli pojawią się skargi innych programistów na temat danych wejściowych (dodam idealnie poprawne skargi, dodaję), najlepiej wprowadzić program „20% czasu”, aby pozwolić mu (i innym) robić to, co robią najlepiej, przy minimalnej ingerencji.

Zamiast przyszłych opowiadań (które mogą wymagać wkładu innych), pozwól programistom eksperymentować z nowymi technologiami lub funkcjami. Możesz znaleźć świetną nową okazję, która nigdy nie zostałaby zbadana inaczej. Jestem pewien, że ten programista ma kilka rzeczy, które chcieliby wypróbować, jeśli im na to pozwolisz.

Są dwie rzeczy, które myślę, że powinieneś rozważyć tutaj:

1. Nie utrudniaj komuś kreatywnego przepływu.
   • Jeśli deweloper chce pracować poza godzinami pracy, pozwól mu.
2. Nie twórz pracy dla innych.
   • Jeśli deweloper chce wykonywać pracę poza godzinami pracy, to na pewno lepiej nie tworzyć więcej pracy dla innych .

Punkt 2 jest prawdopodobnie tym, o co martwią się inni programiści.

Jak wspomniałeś, nie podoba im się to, że kod jest napisany bez udziału całego zespołu. Może to wynikać z tego, że pod względem projektu jest on gorszy. A kod o gorszym designie może zainfekować inny kod wokół niego.

Więc co możesz zrobić?

Pozwól ambitnemu programistowi napisać kod do jego serca, ale wyjaśnij, że nie ma powodu, aby zakładać, że jego kod pozalekcyjny zostanie użyty .

W końcu jest częścią zespołu, dlatego zespół powinien być zaangażowany w rozwój całego kodu.

Jeśli jednak jego praca jest solidna i pasuje do uzgodnionego projektu zespołu, będzie mógł wykorzystać wiele z tego, co już napisał (premia!). Jeśli nie, zmusi go do przemyślenia swojego projektu następnym razem, gdy zdecyduje się na przewagę.

W ten sposób nikt nie zostanie powiadomiony NIE i nikt nie stworzył dla nich dodatkowej pracy.

Doprowadź go z powrotem do zespołu

Powinieneś zadać sobie pytanie (lub lepiej zespół, w tym nadzorcę):

Dlaczego to zachowanie jest problemem?

Skoro określasz programistę jako nadrzędnego, myślę, że jego praca jest dobrej jakości, więc zakładam, że to nie jest problem.

Są jednak inne problemy:

• Dodatkowa praca nie jest odpowiednio testowana
• nie jest to udokumentowane
• reszta zespołu tego nie wie
• deweloper decyduje o kolejnej rzeczy do wdrożenia, a nie PO
• programista nie otrzymuje żadnych opinii od różnych interesariuszy, aby mógł włączyć je do swojej pracy.

Następnym Dlaczego chciałbym tak jest:

Dlaczego programista to robi?

• Jeśli pod koniec sprintu nie pozostanie wystarczająco dużo pracy, powinna zostać podjęta decyzja zespołu (w tym PO) o tym, co będzie dalej robić. Dlaczego deweloper unika tej decyzji?

Po uzyskaniu odpowiedzi na te pytania możesz zacząć odpowiadać na własne pytanie:

• jeśli to nie jest problem, pozwól mu zrobić swoje. Chociaż niektórzy ludzie traktują SCRUM jako religię, nie powinno tak być.
• Bardziej prawdopodobne jest, że masz dwa problemy w zespole: jeden (y) spowodowane przez nieuczciwego programistę i ten (y) wywołujący zachowanie nieuczciwego programisty. Znajdź sposób na rozwiązanie tego później, a pierwszy odejdzie.

Chociaż podoba mi się pomysł, że dodawanie darmowej pracy do miksu jest dobrą rzeczą, nie jest to wolna praca - chyba że ten pojedynczy programista jest również testerem, a także QA, facet od kompilacji, projektant i wszystko inne. Jeśli jego dzieło może zostać wprowadzone do następnego sprintu bez żadnego wpływu, to ... idź do niego. Ale myślę, że nigdy tak nie jest. Wszyscy inni muszą przynajmniej zrozumieć, co zrobił i jaki ma na nich wpływ. Muszą zrozumieć, że jego zmiany są w toku, więc nie powielają jego wysiłków - ciężko jest powiedzieć komuś, że ciężko pracowali nad zadaniem, tylko po to, by znaleźć nieuczciwego faceta, który to zrobił w zeszłym tygodniu.

Pracujesz w środowisku zwinnym, a jedną rzeczą, którą wiem o zwinnym, jest to, że jest on zaprojektowany dla ciebie, a nie przeciwko tobie. Musisz więc zmienić sposób pracy, aby umożliwić realizację tego rodzaju zajęć pozalekcyjnych. Oznacza to uzyskanie wkładu i zgody wszystkich, nie można tego zrobić bez ich wpisowego. Jest to niezbędne. Jeśli drużynie to się nie podoba, łobuz przestaje to robić. Koniec. To nie jeden facet robi to, co lubi, bez względu na to, jak dobra może być jego praca, to wysiłek całego zespołu. Zespół jest na pierwszym miejscu.

Musisz więc usiąść na następnym spotkaniu planistycznym i omówić to, wszyscy członkowie zespołu muszą zdecydować się na to lub zmienić proces, aby lepiej zarządzać tego rodzaju działaniami.

Być może dostaniesz rozwiązanie, w którym każdy pracuje nad swoimi ulubionymi projektami i przynosi je do stołu (możesz sobie wyobrazić chaos związany z dostawą, który spowodowałby :), który podkreśla problem z nim w pierwszej kolejności) lub możesz zlecić dziedziną, w której każdy deweloper ma automatykę do opracowania dowolnego rozwiązania, które mu się podoba, jest „wniesiony” podobnie jak liczba projektów typu open source, lub możesz dać wszystkim trochę czasu na eksperymentowanie (stary czas 20%).

Czy ten programista pisze testy i czysty / solidny kod, czy też wypycha wszystko, co może zrobić szybko? Osobiście nie pozwolę, aby ktokolwiek pracował poza wyznaczonymi godzinami, ponieważ zepsuje to twoje szacunki i jak zauważyłeś, że występują inne problemy.

Jednak nigdy nie powinieneś być sztywny w swoim procesie. Scrum jest tylko strukturą, więc zawsze możesz dostosować proces, aby uwzględnić dodatkowy czas (ale znowu trudno jest zaplanować, co ktoś może zrobić).

Możesz również poprosić go, aby pracował nad rzeczami innymi niż projekt. Patrząc na nową technologię lub tworząc szkolenie na temat rzeczy, które robi inaczej. Ostatecznie jednak wszystko, co dzieje się poza planowanym harmonogramem, zniszczy twoje prognozy i nie pozwolę, aby tak się stało.

musieliśmy zmierzyć się z tym samym, w zasadzie popełniliśmy około 20 punktów, ale w zeszłym tygodniu lub nawet w połowie sprintu zabrakło nam zadania kodowania, jednak z powodu Testowania i reszty procesu nie ryzykowaliśmy wybrać innego PBI, więc co programiści musieli sprawdzić zaległości i zacząć opracowywać przyszłe PBI (po cichu!) i poinformować resztę zespołu, że PBI jest gotowe do przeglądu i testowania kodu! tak jak powiedziałeś.

W rzeczywistości wzbudziło to obawy naszych organizacji producentów, że wydaje się, że jesteśmy w stanie więcej, ale nie w pełni wykorzystujemy potencjał naszego zespołu, co było częściowo prawdą, ale tak, może nasi programiści mogliby zrobić więcej, ale nasi testerzy nie mogli podążać za tą prędkością, więc istniało ryzyko niepowodzenia sprintu. po zastanowieniu się nad tym problemem stwierdziliśmy, że musimy zmienić nasze zdanie na temat scrum, a głównym problemem jest to, że ludzie nie chcą podejmować tego ryzyka, ponieważ zobowiązujemy się do PBI, więc zespół nie czuł się dobrze, podejmując ryzyko wybrania nowe PBI w przypadku, gdy mamy darmowego programistę.

Po prostu zaczęliśmy prognozować PBI, a nie podejmować zobowiązania. Prognozowanie w zasadzie oznacza, że ​​wybieramy 25 punktów podczas planowania i rozpoczęcia sprintu, a kiedy programista uwalnia się w połowie sprintu, ponieważ nie ma już zadania kodowania, więc wybiera jedną z przyszłych PBI i umieszcza ją w bieżącym sprincie i zaczyna działać na nim, jeśli PBI może przejść cały proces (testowanie, łączenie i itp.) w ramach tego samego sprintu, jest to punkt bonusowy dla zespołu, jeśli NIE NIE zawiedliśmy sprintu z powodu tego PBI i po prostu kontynuując pozostałą pracę ( testowanie, meging itp.) do następnego sprintu i ponownie zagraj w pokera za pozostałą pracę. W najgorszym przypadku można to zrobić w dwóch różnych przebiegach. Wiem, że to może brzmieć jak Scrumbut, ale tak naprawdę poprawiło sposób, w jaki działamy. Mogę tylko podsumować jego zalety, jak poniżej:

• Pokonuje fobię polegającą na nieudanym sprincie ze względu na ryzyko podjęcia większej ilości PBI
• Dzięki temu widoczna jest dodatkowa praca programistów i zespołu
• Zwiększa prędkość twojej drużyny

Jednak może dla zespołu z mniejszym doświadczeniem, może to zmniejszyło nacisk na zaangażowanie zespołu w ukończenie PBI

Niektóre inne odpowiedzi sugerują, że „przeważający” programista jest „nieuczciwy” lub „narusza zasady Scruma”. Jest to niepoprawne i należy zachęcać tego programistę (chociaż nie należy prosić ludzi o pracę nad czymś konkretnym w tym dodatkowym czasie, ale można zgłaszać sugestie i pomagać w promowaniu pomysłów).

W Scrumie nie ma nic, co by opisywało, jak ludzie pracują, a wszystko, co zrobił, naturalnie byłoby uwzględnione w szybkości zespołu.

Jego prace powinny zostać wprowadzone do rejestru produktów i ocenione na następnym spotkaniu planistycznym. Jeśli nie możesz od razu przewidzieć, jaki jest pozostały wysiłek, powinieneś poświęcić trochę czasu na sprint, aby to rozgryźć (to znaczy Spike).

Interesujące, że opisujesz programistę jako „przepracowującego”, zakładam, że oznacza to, że dodaje o wiele więcej wartości niż inni członkowie zespołu.

Trudności w wykonywaniu dodatkowej pracy oznaczają, że w twoim zespole jest coś nieoptymalnego (a może nawet dysfunkcyjnego).

Jeśli tak jest, powinieneś zadać sobie pytanie, dlaczego osiąga o wiele więcej, przypuszczalnie tylko odrobinę więcej wysiłku?

Czy to możliwe, aby umożliwić reszcie zespołu osiągnięcie więcej?

Widziałem sytuację, w której zespołom zarządzano w sposób mikro, potencjalnie przekraczając nakazowe historie użytkowników, definicję ukończenia, co ostatecznie utrudnia programistom. Czy ten programista wykonuje pracę, którą chce? Zakładam, że podejmuje dobre decyzje. Czy taka praca w tygodniu roboczym pomogłaby również reszcie zespołu?

Niech też będą nauczycielami

To wspaniałe, że masz gwiazdorskiego programistę z najlepszymi i najbardziej zaawansowanymi umiejętnościami w grupie. Chwalę to i komplementuję. Często tacy ludzie są „klejem”, który łączy organizacje.

Postrzegałbym to wyzwanie jako „jak zbliżyć mniej doświadczonych programistów do wydajności najbardziej zaawansowanego programisty”.

Jednym świetnym sposobem na to jest skupienie się na tym, aby twórca gwiazd spędził więcej czasu na nauczaniu, szkoleniu i prowadzeniu mniej doświadczonych i wolniejszych członków zespołu. Najpierw porozmawiam o tym w rozmowie z gwiazdami, aby wiedzieli, co robisz i dlaczego. Z drugiej strony można podejrzewać, że jest to ukryty program / złe zarządzanie

Kiedy robisz pojedynki, raz lub dwa razy dziennie, jeśli ta osoba kończy pracę, a inni nadal wykonują zadania, spójrz na programowanie w parach, aby mogła sparować z młodszymi członkami i przekazać jej ogromną wiedzę i doświadczenie. Zadaj pytanie „czy ktoś potrzebuje pomocy? Czy ktoś szuka pary?”

Możesz również znaleźć pracę „boczną” dla najlepszego programisty, gdy są oni bez pracy, na przykład ulepszyć zestaw narzędzi, z którego korzystają wszyscy, prowadząc techniczną grupę dyskusyjną klubu książki lub angażując się w inne projekty organizacyjne.

Odpowiem na inne pytanie. Myślę, że sposób radzenia sobie z tą sytuacją w Scrumie nie jest tak naprawdę ważny. Scrum i tak bardziej przypomina wytyczne. Jeśli chcesz, aby tak się stało, znajdź prosty sposób dostosowania swojego procesu, na przykład zakładając, że praca została już wykonana.

Prawdziwe pytanie brzmi, czy chcesz, aby ten programista robił to, co robi. Myślę, że kilka aspektów odgrywa kluczową rolę w odpowiedzi na to pytanie:

1. Czy programista wykonuje dobrą pracę.
2. Czy wszyscy są w porządku, gdy wykonuje swoją pracę samodzielnie (czy to dobrze, czy źle). W końcu unika procesu projektowania!
3. Czy dodatkowe godziny są płatne, czy nie.

Wszystko to wpływa na to, czy dla twojego produktu ma to sens, że robi to, co robi. Ponownie włączenie decyzji w proces projektowania nie jest tak naprawdę problemem. Po prostu bądź elastyczny.

To narusza najemcę Scruma, ponieważ zespół nie decyduje o pracy w sprincie. To zespół scrumowy . Zespół musi zdyscyplinować tego programistę, jeśli dyscyplina ma być rozdana.

Innym problemem, jaki to stwarza, jest to, że śrubuje się z prędkością zespołu. Praca poza pasmem nie liczy się do prędkości i wypala się. Tak więc praca poza pasmem jest wykonywana, zespół osiąga średnią 50 punktów z prędkością, ale robi się więcej niż 50 punktów. Właściciel produktu to zobaczy i zażąda większej prędkości podczas następnego sprintu. Prędkość, która może nie być możliwa.

Zespół (nie PO lub ScrumMaster) musi rozwiązać ten problem z nieuczciwym programistą.