Co zrobić z głodującym zespołem programistów? [Zamknięte]

10

Bycie na krytycznej ścieżce jako normalnego programisty jest do bani, zwłaszcza jeśli się spóźniasz. Kiedy jesteś starszym programistą, którego zespół szuka przywództwa, jest jeszcze gorzej.

Kiedy praca dla większości zespołu utknie w martwym punkcie i czeka na jakiś krytyczny element, co powinna zrobić reszta zespołu? Mamy ograniczony dostęp do krytycznego fragmentu, więc inni będą po prostu czekać, bez względu na to, co zrobimy. Kiedy inni szukają porady, co zrobić, co jest dobrą odpowiedzią?

candied_orange
źródło
10
Czy masz zerowy dług techniczny do spłaty? Czy w przyszłości są jakieś funkcje, na które można by się wzbogacić? Nowe technologie lub paradygmaty, które chcesz wypróbować w ramach istniejącej funkcjonalności?
jonrsharpe
27
@StudentT, który jest niezwykle krótkowzroczny, biorąc pod uwagę prawdopodobne trudności z przyspieszeniem zespołu po rozwiązaniu problemu.
jonrsharpe
8
@StudentT raczej lider powinien zostać zwolniony za to, że nie planuje przyszłości, nie przewiduje się takich rzeczy.
jwenting
13
Głodujący deweloperzy? Jedno słowo: pizza.
Mason Wheeler
3
Jeżeli OP ma zero długu technicznego spłacić ani jednostka / testy funkcjonalne lub skrypty wdrażania napisać / poprawić, jest on zdecydowanie skarży od Deaven (Dev Nieba) i jestem nagle bardzo smutne: <
xDaizu

Odpowiedzi:

29

Ulepsz testy jednostkowe, testy funkcjonalne, dokumentację, narzędzia itp. Istnieje wiele rzeczy, które można zrobić w czasie przestoju, czekając na krytyczną ścieżkę do nadrobienia.

Może czynnik
źródło
2
To. Przeciętny twórca (w tym ja) ciągle narzeka na brak czasu na udoskonalanie. Trzymaj ich.
Traubenfuchs
4
Podoba mi się ten generał „rób wszystko, czego jeszcze nie dostałeś”. Dodam do tego recenzje kodu i refaktoryzację. Spraw, aby było to naprawdę fajne oprogramowanie, które działa jak dobrze naoliwiona maszyna i jest przyjemnością. Jest to satysfakcjonujące dla programistów.
Peter - przywróć Monikę
rzeczy, które wcześniej nie były wystarczająco ważne, prawdopodobnie nadal nie są warte teraz. po prostu „zrób pracę”
Ewan
16

Chociaż podoba mi się odpowiedź na temat ulepszania testów, dokumentacji itp., I jest to dobra odpowiedź, na którą można również spojrzeć:

  • Pomagając komponentowi ścieżki krytycznej, czy programowanie zespołowe / koleżeńskie działałoby szybciej?
  • Przekształcenie krytycznego komponentu w kilka podskładników, nad którymi każdy może pracować.
  • Ściągnij krytyczny komponent czymś, być może szorstkim, który wykonuje tę samą pracę, ale być może nie jest wystarczająco szybki do produkcji.
  • Ustanów interfejs API dla komponentu krytycznego, napraw go mniej więcej w kamieniu i pomóż uzyskać podstawową funkcjonalność dla tego komponentu (może ulec zmianie w implementacji, ale nie API).
  • Sprawdź, czy możesz wziąć wczesne, znane problematyczne wersje krytycznego komponentu do pracy w pozostałej części systemu, w której funkcjonalność jest „wystarczająco dobra na razie”.

Dobrym pomysłem jest także rozpoczęcie fazy „wyciągniętych wniosków”, rejestrując, że takie krytyczne komponenty należy rozpocząć wcześniej na etapie projektowania, być może przed montażem reszty zespołu.

Steve Barnes
źródło
2
Podoba mi się alternatywa „zawsze można coś poprawić”. Jeśli są wystarczająco dobre, lepiej skoncentrować się na bieżącym problemie i znaleźć odpowiednie obejście.
Walfrat
15

Potrzebujesz planu tworzenia kopii zapasowych dla spóźnionego dostarczenia

Jeśli element krytyczny jest już spóźniony, nie ma gwarancji, że nie poślizgnie się jeszcze bardziej. Co wtedy? Czekasz wiecznie? To nie jest odpowiedź, którą chciałbyś przekazać kierownictwu wyższego szczebla.

Zbuduj symulator

Jednym ze sposobów zarządzania ryzykiem jest rozpoczęcie pracy na symulatorze (uprząż, podkładka, odgałęzienie, jakkolwiek chcesz to nazwać), aby zająć miejsce brakującego elementu krytycznego.

Czy ma zdefiniowany interfejs? Wdrożyć je.

Czy ma szczegółową dokumentację? Naśladuj to najlepiej jak potrafisz.

Czy to tylko czyjś pomysł? Sprawdź, czy możesz zdobyć prototyp.

Potem, kiedy znów ustalą harmonogram…

W ten sposób, kiedy ponownie ustalą harmonogram, masz asa w tylnej kieszeni, aby wypełnić lukę. Twój zespół nie tylko zostanie odblokowany (mogą się zintegrować z symulatorem), ale zyskasz cenny zasób oprogramowania.

Jeśli jeszcze bardziej wymkną się harmonogramowi, wykorzystaj czas na napisanie automatycznych testów integracyjnych (na razie na swoim symulatorze). W ten sposób, gdy dostarczają rzeczywistą rzecz, możesz po prostu uruchomić testy i wykryć wszelkie różnice behawioralne między makietą a rezultatem. Pozwoli ci to wyzerować miejsca, które musisz poprawić. Jako bonus, szybko zorientujesz się, jak bardzo skracali rogi, gdy ich czas się skończył.

John Wu
źródło
Symulator nie musi być kompletny ani fantastyczny, wystarczy, abyś mógł robić postępy.
Thorbjørn Ravn Andersen
1
Myślę, że to bardzo dobra i nie od razu oczywista rada. Zwłaszcza perspektywa poza kodowaniem, a mianowicie testy. Próbka ma podwójną wartość.
Peter - przywróć Monikę
4

Jeśli krytyczny składnik ma znanego interfejsu, a jeśli nie ma nadziei na coraz to zrobić w krótkim czasie, dlaczego nie zbudować próbę podwójnie (na przykład makiety )?

Pozwoliłoby to zespołowi kontynuować kodowanie, chociaż wyniki testów byłyby nieco mniej znaczące.

Christophe
źródło
2

Poza oczywistym „robieniem tych wszystkich rzeczy, których do tej pory nie robiłeś”, brzmi to tak, jakbyś ty i twój zespół nie mieli spokoju umysłu, aby zrobić coś niezwiązanego z późnym projektem. Co jest zrozumiałe, ale nie pomocne.

Tak więc prawdziwym problemem może być rozluźnienie się. Nie mówię obojętnie. Bądź świadomy swojej odpowiedzialności, tego, co możesz zrobić, aby pomóc, a jeśli to pozostawi Ci czas na rękach, ciesz się nią. Nie możesz ani nie musisz cały czas mieć na nogach. Jeśli jesteś liderem, powiedziałbym, że to powinna być twoja wiadomość. Przeniesienie zdenerwowania do zespołu nie uczyni bardziej produktywnym zespołem, gdy ma to znaczenie.

Martin Maat
źródło
0

Nie mówisz, jakiej metodologii używasz, co utrudnia dokładne doradztwo.

Tam, gdzie pracuję, jeśli jest bloker, to każda ręka pompy robi wszystko, co w jej mocy, aby przyspieszyć rozwój.

Zastanów się, czy może być z tobą szerszy problem, ponieważ ołów przejmuje zbyt wiele. Tak, ludzie będą cię szukać w zakresie technicznego przywództwa, ale to nie znaczy, że niektórzy z twoich bardziej zdolnych członków zespołu nie mogą dzielić obciążenia pracą, jeśli są mentorami.

Poza tym, czy jest jakaś inna niekrytyczna praca, którą mogą wykonać? Ponadto, czy wykonali jakąkolwiek pracę, którą można dopracować (przefaktoryzować, usunąć zadłużenie techniczne, dokumentację, dodać testy itp.).

Jeśli naprawdę nic nie ma, daj im coś - przejrzyj dzienniki, kompilacje, dokumenty, plany testów, projekty, diagramy, pisz agendy, umawiaj spotkania, organizuj sesje z brązową torbą, dziel się wiedzą itp. Zawsze jest coś do zrobienia. Jeśli ludzie chętnie siedzą i nie robią nic na monecie firmowej, należy to eskalować, ponieważ najwyraźniej nie są graczami zespołowymi.

Robbie Dee
źródło