Zespół ciągle nie osiąga celów sprintu

Jesteśmy małą firmą programistyczną z jednym produktem.

Używamy scrum , a nasi programiści wybierają funkcje, które chcą uwzględnić w każdym sprincie. Niestety w ciągu ostatnich 18 miesięcy zespół ani razu nie udostępnił funkcji, do których zobowiązał się podczas sprintu.

Przeczytałem wiele postów / odpowiedzi, w których napisano, że „oprogramowanie jest wykonywane, gdy jest gotowe, nie wcześniej, nie później ... nie pomaga wywierać presji na zespół, umieszczać na nim więcej osób, ... ”Otrzymałem podobną opinię od jednego z programistów na moje pytanie, w jaki sposób możemy poprawić wskaźnik sukcesu sprintów. No i tak, używamy retrospekcji .

Moje pytanie jest w zasadzie:

Kiedy można szukać problemu w jakości programistów?

Zaczynam myśleć, że jeśli wybierzesz własną pracę / funkcje i nadal nie uda ci się każdy sprint: - Nie będziesz w stanie nadzorować złożoności własnego kodu; - lub kod jest tak złożony, że nikt nie może nadzorować złożoności.

Czy coś brakuje?

Najpierw zapytaj: „kogo to obchodzi”?

Ukończenie sprintu jest przyjemne, a w niektórych firmach rodzą się pliki cookie od rodzica scrum. Ale ostatecznym sprawdzianem jest to, czy firma osiąga swoje cele.

To jest żartobliwe. Jeśli firma odniesie sukces, a nigdy nie ukończy planowanej zawartości sprintu, równie dobrze możesz użyć Kanban: sortujesz zaległości, pracujesz nad tym, co najważniejsze, i nie martwisz się tak bardzo o zdefiniowane iteracje.

Jedną z wartości zdefiniowanych iteracji jest usprawnienie procesu (lub wyparcie słabszych w niektórych mentalnościach). Teraz tego nie rozumiesz. Możesz więc przyjąć resztę procesu, która usprawnia proces (i ostatecznie kończy sprinty), lub możesz zdecydować, że podoba ci się to, co masz.

Czy coś brakuje?

TAK!

Wyjechałeś 18 miesięcy - lub gdzieś w okolicy 36 sprintów z retrospektywami, ale jakoś nie mogłeś tego naprawić? Zarząd nie trzymać odpowiedzialny zespół, a następnie ich kierownictwo nie trzymać ich do odpowiedzialności za nie trzyma odpowiedzialny zespołu?

Tęsknisz za tym, że Twoja firma jest wszechobecnie niekompetentna .

Jak to naprawić. Ty (twórca) przestajesz angażować się w tak dużo pracy. Jeśli historie są tak duże, że nie możesz tego zrobić, musisz podzielić je na mniejsze części. A potem możesz pociągnąć ludzi do odpowiedzialności za zrobienie tego, co według nich zostanie zrobione. Jeśli okaże się, że przy każdym sprincie mogą wykonać tylko niewielką funkcję, to dowiedz się, dlaczego i popraw go (co może wymagać wymiany dewelopera). Jeśli okaże się, że nie są w stanie dowiedzieć się, jak podjąć rozsądną pracę, zwalniasz ich .

Ale przedtem przyjrzałem się zarządowi, który pozwalał na to tak długo, i ustaliłem, dlaczego nie wykonują swojej pracy.

Chciałbym zasugerować ci małą zmianę i wypróbowanie Kanbana przez kilka tygodni zamiast Scruma . Może działać lepiej dla Twojego zespołu.

Podczas gdy Scrum napędza produktywność poprzez ograniczenie czasu pracy dostępnego podczas sprintu, Kanban napędza produktywność i prędkość poprzez ograniczenie liczby aktywnych, współbieżnych problemów. Szacowanie czasu nie jest już częścią tego procesu. ( źródło )

W skrócie, czym jest Kanban?

Kanban jest również narzędziem służącym do organizowania pracy w celu zwiększenia wydajności. Podobnie jak Scrum, Kanban zachęca do dzielenia pracy na porcje do zarządzania i wykorzystuje Tablicę Kanban (bardzo podobną do Tablicy Scrum) do wizualizacji tej pracy w miarę jej przebiegu. Tam, gdzie Scrum ogranicza czas przeznaczony na wykonanie określonej ilości pracy (za pomocą sprintu), Kanban ogranicza ilość pracy dozwoloną w jednym warunku (tylko tyle zadań może być w toku, tylko tyle może być na -zrobić listę.)

W jaki sposób SCRUM i Kanban są takie same?

Zarówno Scrum, jak i Kanban pozwalają na rozkładanie i wykonywanie dużych i złożonych zadań. Oba przywiązują dużą wagę do ciągłego doskonalenia, optymalizacji pracy i procesu. Obaj dzielą bardzo podobny nacisk na bardzo widoczny przepływ pracy, który utrzymuje wszystkich członków zespołu w pętli na temat WIP i tego, co ma nadejść.

Zobacz resztę szczegółów z tego linku

Moje pytanie jest w zasadzie: kiedy można szukać problemu w jakości programistów

W Twoim poście nie ma wystarczających informacji, aby odpowiedzieć na to pytanie. Nie ma sposobu, aby wiedzieć, czy ponoszą porażkę, ponieważ są niekompetentni, lub ponoszą porażkę, ponieważ zobowiązują się do wykonania większej ilości pracy niż jest to uzasadnione.

Jeśli jestem niesamowicie utalentowanym programistą, w zespole niesamowicie utalentowanych programistów i nie uda nam się ukończyć historii X w dwóch sprintach (lub 36!), Czy jesteśmy niekompetentni? A może po prostu jesteśmy do kitu? To zależy od tego, czy historie to „utwórz ekran logowania” czy „wyślij bezpiecznie człowieka na marsa”.

Problem zaczyna się od złych historii i / lub złych szacunków

Ocena jest trudna. Naprawdę trudny. Ludzie to ssają, dlatego Scrum kazał nam rozbić pracę na bloki, które nie powinny zająć więcej niż jeden dzień lub dwa, i zebrać małe grupy tych bloków, które jesteśmy pewni, że możemy je ukończyć w krótkim czasie . Im większe bloki i im dłuższy okres czasu, tym mniej dokładne są nasze szacunki.

Jakie są twoje sklepy? Czy są dobrze napisane i mają dobre kryteria akceptacji? Czy każdy z nich jest wystarczająco mały, aby zrobić to w kilka dni? Bez dobrze napisanych historii (co jest winą całego zespołu programistów, w tym właściciela produktu), nie można oczekiwać, że zespół dokona dobrego oszacowania.

Problem pogarszają złe perspektywy

Najwyraźniej źle postępujesz, ponieważ nie korzystasz z retrospekcji. Minęło 18 miesięcy bez rozwiązania tego problemu, więc albo zespół nie zauważa problemu, albo nie rozwiązuje go w swoich retrospektywach.

Czy każda retrospekcja kończy się co najmniej jednym przedmiotem akcji, który drużyna musi wykonać, aby lepiej sobie radzić podczas następnego sprintu. Czy każda retrospekcja obejmuje rozmowę o przedmiotach akcji z poprzedniego sprintu, aby sprawdzić, czy zostały wykonane i czy były skuteczne?

Rozwiązaniem nie jest obwinianie, to nauka

Pierwszym krokiem powinno być przestanie szukać winy, a zamiast tego rozpoczęcie prac nad ulepszeniem zespołu. Twój zespół prawdopodobnie nie jest niekompetentny, po prostu źle oceniany i planowany. Zmuś zespół do ukończenia sprintu, nawet jeśli oznacza to, że wybiorą jedną historię i ukończą tydzień wcześniej. Jeśli nie mogą tego zrobić, to albo są niekompetentni, albo opowiadania są po prostu zbyt skomplikowane. Odpowiedź na to pytanie powinna być oczywista.

Gdy będą w stanie ukończyć jedną historię, będą z wystarczającą pewnością wiedzieć, że mogą wykonać X punktów historii w sprincie. Prosta matematyka pomoże odpowiedzieć na pytanie, czy mogą robić więcej historii, czy nie.

Ciągłe doskonalenie jest rozwiązaniem

Kiedy ukończą jedną historię w sprincie, czas sprawdzić, czy dadzą radę zrobić dwie. Spłucz, spłucz, powtórz. Kiedy zaczynają nie osiągać celów sprintu, znalazłeś limit ich umiejętności szacunkowych. Wróć do liczby punktów opowieści z poprzedniej historii i trzymaj się jej przez chwilę.

Przez cały czas poważnie podchodź do retrospekcji. Jeśli nie ukończyli sprintu, dowiedz się, dlaczego i działaj na nim. Czy mieli zbyt wiele niewiadomych? Czy mają niewłaściwy zestaw umiejętności? Jak dobre były ich oceny? Jeśli oszacowali historię na X punktów, czy wymagało to stosunkowo równej ilości pracy niż opowieści priory warte X punktów? Jeśli nie, użyj tego, aby dostosować punkty historii do przodu.

Mówisz, że „korzystasz z retrospekcji”. Ale co tak naprawdę zespół robi w tych retrospektywach? Ponieważ minęło 18 miesięcy, nie zajmując się tym aspektem procesu, zgaduję, że odpowiedź brzmi: nic bardzo przydatnego.

Dla mnie retrospekcja jest najważniejszą częścią tego procesu. Wyrzucaj lub zmieniaj cokolwiek innego o scrumie, ile chcesz (oczywiście za obopólną zgodą zespołu podczas retrospekcji, ale zobowiązuj się regularnie poświęcać czas na rozmowę o tym, jak proces działa dla wszystkich, dziel się tym, co działało, a co nie) działają i proponują pomysły do ​​poprawy. Staraj się stopniowo ulepszać swój proces każdego sprintu, a wcześniej czy później możesz mieć coś, co działa całkiem dobrze.

W twoim przypadku ten proces nie działa. Ponieważ cele sprintu nie są osiągane, rozsądne jest, aby retrospektywnie skupić się na tym, dlaczego tak się dzieje. Oczywiście zespół wziął za dużo pracy na sprint. Ale dlaczego to zrobili?

• Czy nie docenili złożoności pracy?
• Czy kierownictwo wywierało na nich presję, aby podejmowali więcej pracy, niż zespół sądził, że sobie poradzi?
• Czy mieli zbyt wiele przerw / nagłych wypadków, które zabierały środki na ukończenie planowanej pracy?
• Czy napotkali wąskie gardła, które opóźniały zakończenie prac (powiedzmy, czekając na zasoby z zewnętrznego zespołu projektowego)?
• A nawet: czy jeden lub więcej członków zespołu w ogóle nie było w stanie wykonać pracy?

To pytania, które zespół powinien zadawać sobie każdego sprintu przez ostatnie 18 miesięcy. Następnie, uzbrojeni w odpowiedzi, mogą zaproponować sugerowane ulepszenia procesu do próby na kolejny sprint. Mogą to być:

• Wykonaj mniej pracy w następnym sprincie (duh!)
• Bądź bardziej konserwatywny w szacunkach
• Powiedz, kto naciska na nas, abyśmy wykonali więcej pracy, aby oderwać się, ponieważ już teraz podejmujemy więcej, niż możemy osiągnąć
• Lepiej zarządzaj przerwami i dostosuj ilość pracy w następnym sprincie, aby uwzględnić nieuniknione sytuacje awaryjne
• Napraw wąskie gardła lub zaplanuj te, których nie możesz uniknąć
• Nie przypisuj historii członkom zespołu, którzy nie mogą ich zrealizować (i osobno wymyśl reakcję kierownictwa, aby rozwiązać sytuację ze słabym członkiem zespołu, od szkolenia i mentoringu po zwolnienie)

Jest to rodzaj rozmowy, która powinna mieć miejsce podczas każdego sprintu w ciągu ostatnich 18 miesięcy. Nie chodzi o wywieranie presji na zespół lub dodawanie większej ilości zasobów, ale o stosowanie retrospektyw do ciągłego doskonalenia procesu. To wyraźnie się tutaj nie dzieje.

Można by pomyśleć, że do 15. sprintu z nieosiągniętymi bramkami zespół tak wiele razy dyskutowałby o tym w swojej retrospektywie, aż do momentu, w którym postanowił po prostu przyjąć jak najmniejszą liczbę możliwych celów sprintu tylko po to, aby uzyskać jeden kompletny. Do 25. nieukończonego sprintu wykonałem sprint z pojedynczą zmianą struny i niczym więcej. Jeśli zespół nie poradzi sobie z tym podczas sprintu, problemy są jeszcze gorsze niż na to pozwalasz.

Żeby było jasne, jak już kilkakrotnie tutaj wskazywało, cele sprintu są prognozami, a nie żelaznymi zobowiązaniami, a brakujące cele same w sobie nie wskazują na nic innego, jak tylko niedokładne prognozy. Świetny zespół może stracić mnóstwo bramek, ponieważ są złymi prognozami, podczas gdy okropny zespół może spełnić każdy cel i nie przynieść żadnej rzeczywistej wartości. Ale jeśli twoje prognozy są błędne w tym samym kierunku przez 18 miesięcy z rzędu, ta część twojego procesu nie działa. Skorzystaj z retrospekcji, aby naprawić proces, aby prognozy były dość zbliżone do rzeczywistej rzeczywistości, jaką zespół może dostarczyć podczas każdego sprintu.

„oprogramowanie jest gotowe, gdy jest gotowe, nie wcześniej, nie później”.

To prawda, ale czy dla każdego zadania, nad którym zaczynają pracować twoi programiści, czy wszyscy w Twojej organizacji rozumieją definicję ukończenia dla każdego zadania?

Wydaje się, że jednym z twoich największych problemów jest Szacowanie , ale programiści mogą przedstawić realistyczne oszacowanie tylko wtedy, gdy mają jednoznaczną i jasno określoną „definicję wykonania”. (W tym kwestie związane z procesami firmy - np. Dokumentacja użytkownika, pakiety robocze w formalnej wersji itp.)

Nic dziwnego, że przeszacowanie powoduje problem, biorąc pod uwagę, że większość programistów uważa, że ​​oszacowanie czasu wymaganego do ukończenia zadania jest najtrudniejsze, o co proszeni są.

Jednak większość programistów ma rozsądny (choć optymistyczny ) sposób na określenie wysiłku, jaki są w stanie włożyć w danym okresie czasu.

Problem często polega na tym, że programiści próbują stworzyć związek między zadaniem a całkowitym nakładem pracy wymaganym, gdy mają do czynienia z niekompletnymi informacjami - szczególnie jeśli są zmuszeni do przedstawienia wszystkich odpowiedzi z góry na naprawdę ogromne zadanie .

To naturalnie prowadzi do odłączenia się szacunków czasu od rzeczywistości i tracą z oczu rzeczy takie jak proces kompilacji i dokumentacja użytkownika.

Rozłączenie zwykle zaczyna się na samym początku, gdy opisano zadanie; i zwykle komplikuje go osoba nietechniczna, która sporządza listę wymagań, nie mając pojęcia o wymaganym nakładzie pracy.

Czasami osoby na kierownictwie wyższego szczebla określają zadania i całkowicie ignorują problemy związane z procesami firmy; często zdarza się, że kierownictwo wyższego szczebla myśli, że takie rzeczy, jak definiowanie testów, tworzenie formalnie wydanej kompilacji lub aktualizowanie dokumentu użytkownika dzieje się magicznie bez żadnego czasu i wysiłku. wymagany.

Czasami projekty kończą się niepowodzeniem, zanim programista nie napisał nawet wiersza kodu, ponieważ ktoś nie wykonuje poprawnie swojej pracy.

Jeśli zespół programistów nie jest zaangażowany w uzgadnianie wymagań lub przechwytywanie kryteriów akceptacji, oznacza to niepowodzenie zarządzania - ponieważ oznacza to, że ktoś, kto nie rozumie w wystarczającym stopniu kodu i problemów technicznych, zobowiązał firmę do niekompletnego zestawu wymagań, i pozostawił projekt otwarty na błędną interpretację, pełzanie lunety, złocenie itp.

Jeśli zespół programistów jest zaangażowany w uchwycenie i uzgodnienie wymagań, zespół może ponieść porażkę, która jest odpowiedzialna za wyjaśnienie szczegółów (i kryteriów akceptacji - tj. „Jak wygląda produkt dostarczany? Kiedy to się robi ?”). ). Zespół programistów odpowiada również za NIE, gdy występują inne problemy z blokowaniem lub gdy wymaganie jest po prostu nierealne.

Więc jeśli programiści są zaangażowani w przechwytywanie wymagań:

• Czy zespół ma okazję usiąść z menadżerem produktu w celu wyjaśnienia wymagań / definicji wykonanych?
• Czy zespół zadaje wystarczające pytania, aby wyjaśnić dorozumiane / zakładane wymagania? Jak często odpowiedzi na te pytania są zadowalające?
• Czy zespół wymaga kryteriów akceptacji (definicji dokonanej) przed przedstawieniem szacunku?
• Jak dobrze kryteria akceptacji są zwykle rejestrowane dla każdego zadania? Czy jest to niejasny dokument ze szczegółowymi szczegółami, czy też opisuje namacalną funkcjonalność i sformułowanie, które programista może jednoznacznie przełożyć na test?

Możliwe, że produktywność twojego zespołu nie stanowi problemu; Twój zespół prawdopodobnie wkłada tyle wysiłku, ile może włożyć w rozwój. Twoje prawdziwe problemy mogą być następujące:

• Niekompletne i niejasne wymagania.
• Wymagania / zadania, które są po prostu zbyt duże.
• Słaba komunikacja między zespołem programistycznym a wyższym kierownictwem.
• Brak jasno określonych kryteriów akceptacji przed przekazaniem zadań zespołowi.
• Niekompletna lub niejasna / niejednoznaczna specyfikacja testów akceptacyjnych. (tj. definicja ukończenia)
• Za mało czasu przeznaczonego na zdefiniowanie / uzgodnienie kryteriów akceptacji.
• Programiści nie zastanawiali się nad czasem na przetestowanie istniejącego kodu bazowego ani naprawienie istniejących błędów
• Deweloperzy przetestowali istniejący kod bazowy, ale nie zgłosili błędów jako problemy z blokowaniem przed przedstawieniem oszacowań wymagań
• Kierownictwo zobaczyło problemy / błędy i zdecydowało, że błędów nie trzeba naprawiać przed napisaniem nowego kodu.
• Deweloperzy są pod presją, aby spędzali 100% swojego czasu, chociaż prawdopodobnie 20% (lub podobna liczba) ich czasu jest prawdopodobnie zajmowana przez spotkania, rozrywki, e-maile itp.
• Szacunki są ustalane według wartości nominalnej i nikt nie dostosowuje miejsca na błędy lub nieprzewidziane okoliczności (np. „Zdecydowaliśmy, że powinno to potrwać 5 dni, więc spodziewamy się, że nastąpi to w 8.”).
• Szacunki są traktowane przez wszystkich (programistów i kierownictwo) jako pojedyncze liczby zamiast realistycznych liczb „zakresowych” - tj
  • Najlepsze oszacowanie przypadku
  • Realistyczne oszacowanie
  • Szacunek najgorszego przypadku

... lista może trwać o wiele dłużej.

Musisz dokonać „ustalenia faktów” i dowiedzieć się dokładnie, dlaczego szacunki są konsekwentnie odłączane od rzeczywistości. Czy istniejące oprogramowanie podstawowe jest złe? Czy brakuje pokrycia testami jednostkowymi? Czy Twoi programiści unikają komunikacji z zarządem? Czy kierownictwo unika komunikacji z programistami? Czy istnieje rozdźwięk między oczekiwaniami kierownictwa a oczekiwaniami programistów, jeśli chodzi o „Definicja ukończenia” ?

Moja rada, aby zrestartować zespół, polega na wybraniu najmniejszej możliwej historii na zespół, na sprincie i ukończenie tej jednej historii i tylko jednej historii!

Zgadzam się z innymi plakatami, albo zespół jest niekompetentny, albo próbują robić zbyt wiele rzeczy.

Zacznij od najmniejszych rzeczy, najłatwiejszych historii i ukończ jeden sprint. Poproś zespół, aby ukończył sprint i odniósł sukces, a pomoże im to ustalić, jak priorytetowo traktować czas i zobowiązania do pracy. Z czasem zespół będzie mógł podejmować coraz więcej pracy, dopóki nie osiągnie maksymalnej wydajności.

Powinieneś gromadzić dane i budować poziomy zaufania w oparciu o wcześniejsze wyniki.

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

Najprostszym przykładem są ciągłe sprinty czasowe, takie jak co dwa tygodnie. Oszacuj, ile punktów historii ukończy zespół w ciągu dwóch tygodni. Następnie po dwutygodniowym sprincie sprawdź, ile punktów historii zostało faktycznie ukończonych. Z czasem możesz zobaczyć, że szacujesz 15 punktów, ale dopiero kończysz 10. W tym prostym przypadku możesz zacząć iść do przodu z regulacją prędkości, dzięki czemu planujesz tylko 10 punktów na sprint. Lub że planujesz zakończyć 66% szacowanej pracy.

Budując poziomy ufności ze standardowymi odchyleniami, możesz powiedzieć zarządowi: zgodnie z obecnymi celami projektu oczekujemy tylko 50% pewności, którą możemy ukończyć w 3 tygodnie, ale 95% pewności, którą możemy ukończyć w 5 tygodni.

Ideą Agile i Scrum jest zbudowanie ciasnej pętli sprzężenia zwrotnego, abyś mógł zmierzyć swój proces. Musisz zapytać „Gdzie to się zepsuło?”, Ponieważ wydaje się, że całkowicie się zepsuło.

1. Zaplanuj, co zamierzasz zrobić, i sporządzić listę
   • Powinno to polegać na pobieraniu elementów z listy zaległych elementów, które należy uzupełnić. Zanim cokolwiek zostanie umieszczone na liście zadań do sprintu, zespół musi się zgodzić, że w pełni to rozumie i że z grubsza szacuje, że ukończenie sprintu zajmie mniej niż sprint.
   • Idealnie, zaległości są uporządkowane według priorytetu (do firmy) i można pobrać w kolejności priorytetowej.
   • Jeśli elementy z zaległości są zbyt duże, podziel je na mniejsze części. Następnie podziel fragmenty na poszczególne zadania, które można wykonać w ciągu jednego dnia lub krócej.
   • Nie oczekuj, że takie planowanie będzie łatwe lub szybkie.
2. Wykonaj na elementach z listy przez określony czas (sprint)
3. Sprawdź, co osiągnąłeś
   • Jakie historie zostały ukończone?
   • Jeśli żadne historie nie zostały ukończone, jakie zadania związane z tworzeniem historii zostały ukończone?
   • Jeśli nie ukończono żadnych zadań, to co dokładnie wszyscy zrobili w ostatni poniedziałek? W zeszły wtorek itd. - w tym momencie nadszedł czas na poważną introspekcję ...

4. Rozwiąż problemy (przeanalizuj opinie i dostosuj)

   • Jak długo zajęły rzeczy, które zostały ukończone?
   • Co uniemożliwiło ukończenie zadań?
   • Czy członkowie zespołu dzielą historie (funkcje) na zadania, które można wykonać w ciągu 1 dnia lub krócej? Jeśli nie, zrób to i umieść go na liście zadań do wykonania.
   • Jakie zmiany na liście zadań lub elementach na liście zadań zostały wprowadzone podczas sprintu? Czy to był powód nieukończenia? Jeśli tak, nie zmieniaj listy ani funkcji. Rzuć zmienioną funkcję w zaległości, aż będzie stabilna.
   • Jak możesz zmniejszyć rozmiar i zakres kilku przedmiotów do czegoś, co można ukończyć w sprincie? Wybierz coś malutkiego, na przykład ulepszenie rejestrowania, prostą naprawę błędu, literówkę, aby skończyć niektóre rzeczy, aby umożliwić zespołowi ocenę tego, co mogą zrobić. Jeśli nie możesz tego zrobić, przestań biegać i ponownie zaplanuj .

5. Wróć do kroku pierwszego i powtarzaj aż do wydania ...

Czy istnieją przeszkody w dokumentacji, problemy z łączeniem, powodujące zależności, problemy z komunikacją, niewystarczająca ilość informacji w wymaganiach? ... Co? Czy programiści spędzili czas próbując nauczyć się nowych technologii? Czy spędzili dużo czasu na projektowaniu? Czy na liście zadań sprintu uwzględniono uczenie się?

Czy uważasz, że twój zespół myślał, że izolowali swoje problemy w każdej retrospekcji? Czy zespół podjął działania w celu rozwiązania problemów? Czy zespół nie zareagował, a kierownictwo po prostu dyktowało rozwiązania i sposób działania?

Biorąc pod uwagę długi okres, coś jest nie tak systemowo, nie tylko z programistami. W pewnym momencie (przed rokiem było up) ktoś w zespole (w tym kapitan scrum) powinny Poprosiłem, co jednak niewielkie, może to osiągnąć?

W twojej sytuacji retrospektywy są za późno.
Czy organizujesz codzienne spotkania stand-up i naprawdę uzyskujesz status ludzi od tego, co zrobili w ciągu ostatnich 24 godzin?
Czy mistrz scrum używa tych spotkań do mierzenia postępów każdego dewelopera względem jego celów?
Musisz użyć tego fragmentu metodologii Scrum, aby monitorować postępy. Powinno to dać ci dobry wgląd w to, co robią ludzie.
Czy są rozproszeni? Spędzasz zbyt dużo czasu na kawie lub pomagasz innym osobom w SE / SO, czytasz wiadomości lub przeprowadzasz kontrole, które nie są rozliczane? A może są naprawdę zawrotni, mają pełną parę i są nadmiernie zaangażowani? Codzienny widok powinien dać ci dobry pomysł. Pomoże to również skupić deweloperów na wykonywanym zadaniu, aby nie musieli przyznać, że wczoraj nic nie zrobili.
I oczywiście, jeśli zgłaszają stały postęp przez cały czas sprintu i nadal nie dostarczają na koniec, to kłamią i może być czas na nowego programistę.

Oszacowanie wysiłku i czasu potrzebnego do wykonania złożonego zadania, takiego jak programowanie kodu, jest trudne. Jak to ujął Joel Spolsky :

Twórcy oprogramowania nie lubią tworzyć harmonogramów. Zwykle próbują uciec bez niego. „Stanie się tak, gdy będzie gotowe!”, Mówią, spodziewając się, że tak odważny, zabawny zinger zredukuje swojego szefa do chichotów, a w następnej radości harmonogram zostanie zapomniany.

Jednak firmy potrzebują terminów, aby działać. Jak sugerował Joel, spróbuj zastosować harmonogramowanie oparte na dowodach, które da oszacowania czasu z powiązanym prawdopodobieństwem, z którym kierownictwo może odnosić się do dowolnego rodzaju ryzyka.

Scrum robi kilka rzeczy.

Po pierwsze, zachęca do ustalania priorytetów. Dostawca pracy musi najpierw powiedzieć, co chce zrobić, a nie „wszystko jest równie ważne”.

Po drugie, generuje nieco użyteczny produkt, nawet jeśli nie wszystko jest skończone. To jest sens posiadania „potencjalnie nadającego się do wysyłki produktu” na końcu każdej iteracji.

Po trzecie, daje mocniejszą pętlę sprzężenia zwrotnego. Nalegając, aby „zrobić” na koniec sprintu, unikniesz problemu „ukończono 90% funkcji, ale wykonano ją tylko w połowie”; kiedy naciskasz na terminy, możesz odłożyć na bok rzeczy, które należy zrobić na bok, aby wyglądało na to, że prawie dotrzymałeś terminu lub możesz go sfałszować. Mając definicję ukończenia i nalegając na to, aby coś zostało zrobione, wiesz, czy coś jest trudniejsze, niż wygląda wcześniej niż później.

Po czwarte, unika zapasów, zbliżając szczegółowe planowanie do wykonania pracy. Planowanie rzeczy na daleko jest formą inwentaryzacji: kapitał wydawany na zasoby, które nie są dostępne do sprzedaży lub do natychmiastowego wykorzystania przez klientów. Takie zapasy mogą gnić (plany zmieniają się pod stopami, nowe informacje powodują, że stają się przestarzałe), źle dostosowywać się do potrzeb (okazuje się, że nie potrzebujemy rozproszonej sieci whatzit, ponieważ korzystanie z niej nie było tego warte) i zmniejszać wartość wysyłanych towarów (jeśli w ostatnim roku połowa twojego czasu była poświęcona na planowanie na przyszły rok i później, mógłbyś dostać dwa razy więcej wysyłek, gdybyś zamiast tego pracował nad przygotowaniem rzeczy na teraz). Jeśli możesz przenieść planowanie bliżej realizacji bez strat (trudne!), Możesz zmniejszyć zapasy.

To nie jedyny sposób na rozwiązanie tych problemów. Wygląda na to, że używasz scrum, w którym zapewnia on strumień pracy programistom do pracy w każdym okresie, z okresowym dodawaniem nowej pracy do wykonania i sprawdzaniem postępów.

Jest to przydatny sposób użycia wzorców scrum-esque. Utrzymuje przepływ pracy, planuje blisko produkcji, zapewnia pewne sprzężenia zwrotne itp. Ma nawet zalety polegające na tym, że nie wypacza rozwoju i testowania w celu dopasowania do systemu (jeśli testowanie najlepiej wykonać po zakończeniu pracy , próba ukończenia i przetestowania rzeczy w ramach tego samego sprintu zmusza zaplecze sprintu, aby nie obejmował nowego rozwoju!)

Brak umieszczenia dokładnie tego, co zamierzają zrobić w sprincie, nie świadczy o tym, że programiści nie wykonują świetnej pracy. Oznacza to, że nie podążają za SCRUM z wysokości, zamiast tego używają części frameworka.

Gdyby zmniejszyli o połowę (lub podzielili na ćwiartki), ile zaangażowali się w każdy sprint, ale utrzymali wszystko inne bez zmian, to skończyliby więcej niż zobowiązali się do każdego sprintu! Otrzymasz taką samą ilość kodu. Oczywiście „awarie sprintu” nie są ważną częścią, ponieważ jest to tylko wewnętrzny szczegół procesu. Celem firmy jest zrobienie gówna i to gówno będzie dobre; nie postępować zgodnie z określonym procesem, chyba że Twoim celem jest pewien rodzaj certyfikacji procesu ISO.

Proces istnieje podporządkowany celowi rzeczy.

Z drugiej strony, ponieważ nie przestrzegają zasad SCRUM, nie otrzymujesz tego samego rodzaju informacji zwrotnych. Powinieneś sprawdzić powstałe rzeczy, aby sprawdzić, czy rodzajem powstałych wad są wady, z którymi SCRUM miał sobie poradzić; czy są historie, które żyją jak zombie na zawsze i giną dopiero późno? Czy są historie, które wydają się łatwe, eksplodują i z perspektywy czasu nie są warte całej pracy? Czy produkt jest faktycznie wysyłany w momencie, gdy potrzebujesz / chcesz go wysłać?

„Oprogramowanie powstaje, gdy jest gotowe, nie wcześniej, nie później” to przepis na niepowodzenie, jeśli nie zdefiniowałeś, jak to wygląda.

Większość inżynierów spróbuje stworzyć najlepsze możliwe rozwiązanie, ale może to łatwo doprowadzić do pozłacania, szczególnie w przypadku mniej doświadczonych inżynierów. W zaledwie obowiązki zarządzania są dokładnie określić, gdzie celem jest, aby utrzymać i inżynierów zmierza w tym kierunku. Inżynierowie często podejmą próby wprowadzenia zmian w celu ulepszenia funkcji, a to do kierownictwa należy decyzja, czy zmiana ta przyspieszy działanie w dłuższej perspektywie, czy tylko poprawi się w celu poprawy.

Istotą zwinnego rozwoju jest to, że każdy nowy utwór powinien być tak dobry, jak to konieczne, aby sprostać temu sprinkowi I NIE JEST LEPSZY !!!!!! Tak, to jest najbardziej nacisk, jaki mogę dodać w StackOverflow - i to wciąż za mało nacisku. Jeśli okaże się, że ludzie dodają w tym momencie rzeczy, które nie są wymagane , potrzebują szkolenia w zakresie prawidłowego wykonywania zwinnego programowania.

No i tak, używamy retrospekcji.

Och, dobrze, więc wiesz, dlaczego twój zespół się nie udaje, prawda? Miałeś 36 okazji, aby porozmawiać o tym, co działało, a co nie działało, więc mistrzowie scrum powinni w pełni zrozumieć, jak rozwiązać problemy, prawda?

Mam przeczucie, że według opisu, który podałeś, twoja firma wpadła w mentalność „SCRUM czyni nas produktywnymi”. Prawda jest taka, że ​​SCRUM nie czyni twojej produktywności. Przeciwnie, jest to narzędzie, które pomogą Ci bardziej produktywne w sposób, który identyfikuje realia rozwoju, które są często pomijane przez kierownictwo i programistów podobne.

Co Scrum Master zidentyfikował jako potencjalne problemy z zespołem? Czy stale przydzielają dwa razy więcej pracy, niż potrafią? Jeśli tak, mistrz scrum powinien delikatnie sugerować, że podejmują mniej pracy, ponieważ mistrz scrum może patrzeć na prędkość zespołu.

Kiedy można szukać problemu w jakości programistów?

Czas, w którym należy szukać problemu w jakości programistów, to chwila, w której masz pewność, że to jest problem. To nie jest nowy problem stworzony przez SCRUM. To jest rzeczywistość biznesu. SCRUM powinien dostarczyć ci znacznie więcej informacji o możliwościach członków twojego zespołu niż tradycyjne podejścia. Powinieneś wiedzieć, czy problem polega na tym, że „programiści nie są wystarczająco dobrzy”, a „oczekiwania dotyczące zarządzania są nierealne” w znacznie większym stopniu, niż można by to zrozumieć przy tradycyjnym podejściu. Nadszedł czas, aby kierownictwo zrobiło to, co najlepiej radzi sobie z zarządzaniem: znaleźć odpowiednich ludzi do pracy, aby firma mogła zarabiać pieniądze. Jeśli nie potrafisz powiedzieć, gdzie jest problem, wyobraź sobie, jak trudno byłoby stwierdzić bez tych wszystkich retrospekcji!

Jeśli uważasz, że ludzie mogą być wystarczająco dobrzy (sugerując, że ich zatrudnienie nie było błędem ze strony kierownictwa), radzę zacząć myśleć nieszablonowo. Jeśli praca nie jest wykonywana, rozważ zmianę kształtu pracy dla programistów. Jednym z najprostszych sposobów na ustalenie terminów ukończenia sprintu jest dostosowanie kryteriów GOTOWE, abyś był zadowolony z wyniku, bez względu na to, jak się to zrobi. W ten sposób ukończenie staje się tautologią.

To nakłada na zarządzanie, szczególnie SCRUM master. Sztuką jest pisanie zadań, które, jeśli zostaną wykonane, są bardzo cenne, ale jeśli są niekompletne, nadal zapewniają wystarczającą wartość dodaną dla firmy, aby były warte wypłaty. Po 18 miesiącach spodziewałbym się, że twoje retrospektywy nauczyły cię czegoś. Jeśli nie, być może powinieneś napisać historie z wyraźnym zamiarem nieudanych historii, odkrywając coś, co jest nie tak w twojej firmie i ujawniając je. Dostarczyłoby to firmie cennych danych, biorąc pod uwagę, jak wiele frustracji wydaje się mieć zespół programistów. Problemem mogą być deweloperzy, o co prosisz. Problemem może być patologia firmy, o której dotąd nie miałeś pojęcia!

Jeśli rzeczywiście problem dotyczy firmy, a nie deweloperów, informacje, które pozyskujesz z tych niekompletnych historii, mogą być rzeczywiście warte więcej niż produkt, który zbierasz od udanych! Mogą to być informacje, które ratują całą firmę! Wydaje mi się to bardzo cenną informacją i możesz użyć SCRUM jako narzędzia, które pomoże ci je zebrać.

„Kiedy uczciwie jest patrzeć na jakość programistów?”

Cały czas. Oczywiście niektórzy ludzie są bardziej produktywni niż inni, nie potrzebujesz wymówki jako pracodawcy, aby zmierzyć ich wyniki.

Problem polega na tym, jak to robisz. Moja rada to zatrudnić doświadczonych kontrahentów, którzy będą pracować razem z personelem trwałym przy tym samym zestawie zadań oszacowanym przez twoich stałych facetów i sprawdzić, czy mają większą prędkość.

To da ci dobre porównanie z obecnym rynkiem bez blokowania długoterminowego wynajmu.

Może to także dać chłopakom Permalink here (line 511) kopniaka w tyłek.

Dodatkowo, jeśli narzekają, kontrahenci pomijają jakość itp., Aby uzyskać prędkość, to poprowadzi rozmowę o tym, gdzie jest wartość biznesowa. Wysyłane produkty o długoterminowej konserwacji lub krótkoterminowe.

Jeśli jest to kwestia długoterminowa, zmusi cię do kwantyfikacji i umieszczenia w sprincie jako wymagań!

Istnieje już kilka doskonałych odpowiedzi. W szczególności złe oszacowanie, nadmierne zaangażowanie i / lub nieplanowana praca są częstymi przyczynami poślizgu.

Ale jestem ciekawy, dlaczego „[Twoi] programiści wybierają funkcje, które chcą uwzględnić w każdym sprincie”. Deweloperzy zwykle powinni najpierw pracować nad funkcjami o najwyższym priorytecie - a priorytetem jest decyzja biznesowa, tzn. Decyzja powinna pochodzić od właściciela produktu działającego jako pełnomocnik dla interesariuszy biznesowych.
(Istnieją wyjątki od tego. W szczególności funkcje wysokiego ryzyka są na ogół obsługiwane wcześniej. W niektórych przypadkach funkcja skierowana do użytkownika może zależeć od innych funkcji, np. „Naprawdę musimy dodać bazę danych, zanim będziemy mogli wdrożyć X”. )

Z drugiej strony, dane szacunkowe są decyzjami technicznymi i nie powinny być podejmowane (ani wtórnie zgadywane) przez ludzi biznesu. Nic o tym nie mówisz - podnoszę tę kwestię tylko dlatego, że z mojego doświadczenia, kiedy programiści wybierają, nad czym pracować, dość często zdarza się, że ludzie biznesu próbują określić, ile czasu to zajmie.

Wygląda na to, że masz dość dysfunkcyjny proces. Odradzałbym przynajmniej konsultowanie się z programistami, przynajmniej na razie, ponieważ prawdopodobnie będzie to miało negatywny wpływ na morale. Ale wygląda na to, że Twoja organizacja mogłaby skorzystać z pomocy po stronie zarządzania projektem. Od tego chciałbym zacząć od zaangażowania doświadczonego, zwinnego trenera - jeśli nie do średnio- i długoterminowego zaangażowania, to przynajmniej do oceny lub „oceny stanu zdrowia”. Dobry trener powie ci, jeśli masz słabo rozwijających się programistów, ale przynajmniej w ten sposób cały zespół (nie tylko deweloperzy) jest pod kontrolą.

Jeszcze jedno spostrzeżenie: z mojego doświadczenia bardzo trudno jest sprawić, by Scrum odniósł sukces jako metodologia zarządzania projektami, jeśli nie przestrzegasz również dobrych procesów programistycznych. Czy przeprowadzasz automatyczne testy jednostkowe? czy jeszcze lepiej zautomatyzowane testy akceptacyjne? Czy twoi twórcy parują się, czy przynajmniej często przeprowadzasz przeglądy kodu i / lub solucje? Czy ćwiczysz jakąś formę ciągłej integracji?