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

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ą?

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.

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.

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ł.

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.

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.

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.