Deadloop projektu, troszkę (samo)krytyki

Obserwuję od jakiegoś czasu w pracy pętlę sprzężenia zwrotnego. Trafiłem do projektu, który z różnych powodów jest opóźniony (w pół roku siłą 5 programistów wykonać 3-letnią pracę 10-ciu...). W czym problem?

Projekt się spóźnia - a przez to managerowie się denerwują i zwołują co chwila konferencje oraz wysyłają masę poczty aby być na bieżąco. A tym samym zajmują czas programistom którzy mają go coraz mniej, co z kolei zwiększa ilość konferencji i poczty...

Uważam, że z dobrą i doświadczoną 5-osobową ekipą, dobrze ustalonymi wymaganiami i architekturą, projekt można by spokojnie skończyć w rok - gdyby nie ta paskudna pętla i czynniki środowiskowe.

Na technikach agila nie znam się, lecz już na pierwszy rzut oka dostrzegam liczne zalety. Krótki okres między kolejnymi wersjami produktu, niezbyt liczna ekipa, komunikacja na bieżąco - to dużo pracy ale także lepsze jej warunki. Takie podejście jednak nie jest możliwe w mojej firmie, która kiedyś uchodziła za wzorzec.

Czego mi brakuje w moim obecnym projekcie:

• Dobrego systemu kontroli kodu / wymagań / zadań / dokumentacji - np. cvs/svn/git + mantis/itp. + google wave/gmail
• Sprawnego systemu kompilacji kodu (budowania) - np. ant / cmake
• Jednolitych procesów - czyli czegoś, co "nie opisuje jak chcielibyśmy aby cykl życia projektu mógłby wyglądać" a zamiast tego ukierunkowuje tenże cykl
• Automatycznych testów jednostkowych - np. JUnit
• Środowiska ułatwiającego programowanie i konserwację (AKA development i troubleshooting) - np. JBoss, Log4J, solidny szkielet (AKA framework)
• Możliwość dostosowania procesów i używanych technologii do tego, nad czym pracujemy - np. parsować XML z poziomu ksh/awk to na starcie pomyłka
• Kontrola procesu która zamiast obciążać pracowników pomaga im - ponieważ raportowanie co godzinę mojego statusu w 15 różnych aplikacjach oraz na dodatkowych konferencjach zabiera masę czasu
• Współpracy z innymi członkami grupy tak, aby nasza wiedza częściowo się pokrywała - a nie zarzucenie nas mnogością zadań i utrudnianie współpracy

Jakie problemy z mojej (i ogólnie programistów) strony dostrzegam:

• Projekt został spalony już na starcie, zanim jeszcze rozpoczęliśmy nad nim pracę - powinniśmy to zakwestionować na starcie
• Zgodziliśmy się na narzucenie technologii bez uważnego przestudiowania konsekwencji
• Projekt zaczynał z niedoświadczoną ekipą i nie zadbaliśmy o odpowiednie wprowadzenie wszystkich jej członków (udało się to zaledwie z dwójką)
• "Młodzi" dostali zbyt dużą kontrolę co doprowadziło do zrezygnowania z tzw. "code review"
• Zgodziliśmy się (my, członkowie z doświadczeniem) na brak tzw. "code review"
• Nie zablokowaliśmy projektu na starcie widząc, żę wymagania są bardzo niekompletne
• Zgodziliśmy się pracować z narzuconymi narzędziami, które to pamiętają czasy Gierka - choć tutaj nie mieliśmy wiele do gadania
• Nie uczestniczyliśmy w początkowych fazach tworzenia projektu - i tutaj także było to poza naszą kontrolą - co w rezultacie doprowadziło do niedoestymowania kosztów, wybrania niewłaściwych technologii i mylnego przeświadczenia kadry kierowniczej że możliwym jest "reuse" istniejącego kodu
• To, że ktoś stworzył taki paskudny kod jaki odziedziczyliśmy i że otrzymał tak odpowiedzialne zadanie jest także tragiczne - ale to również problem częściowo leżący po stronie programistów

Ech... praca w archaicznej korporacji to nie jest to co tygryski mogłyby lubić