Nowy prototyp laptopa w Zaltronik

Jeśli chodzi o rozkład dynamiczny, bardzo przypomina to popularną dziś metodykę Scrum. Z tą dokładnością, że w Scrum etap rozmów z klientem i planowanie trwa co najwyżej dzień, również tyle samo trwa prezentacja prototypu i retrospekcja. Uwzględniając czas potrzebny na przygotowanie końcowej prezentacji, integrację zrealizowanych zadań oraz codzienny Scrum, różnice wynikające z podziału czasu bardziej się zacierają. Uwzględniając jednak korzyści, które wynikają z przeprowadzenia prac analitycznych w Zaltronik, oraz możliwości współdzielenia uczestników projektu w innych projektach (Scrum narzuca 100% zaangażowanie zespołu w tym jednym projekcie) oraz brak ograniczeń co do liczby uczestników zespołu (w Scrum 7 plus minus 2), dostajemy metodykę równie zwinną co Scrum, ale potencjalnie dwa razy bardziej wydajną (np. w tym samym wzorcowym czasie 4 miesięcy z RUP możemy zrealizować 2 projekty).

Co do ostatniego stwierdzenia, czuję się zobowiązany ostrzec przed potencjalną pułapką w przypadku prowadzenia dwóch projektów na raz. Tak jak wspominałem wcześniej, powinno być dwóch kierowników projektu, projekty powinny się charakteryzować podobieństwem zagadnień (uczestnicy projektu powinni mieć odpowiednie kompetencje w obydwu przedsięwzięciach). Obydwa projekty powinny mieć możliwość transferu rezerwy czasowej pomiędzy sobą. Również terminy, przede wszystkim terminy akceptacji wymagań i odbiorów cząstkowych, powinny być nieuchronne. W przypadku dużego prawdopodobieństwa zmaterializowania się ryzyka współpracy z „niezdyscyplinowanym” klientem praktykę tę lepiej zaniechać, a nieskonsumowane rezerwy wliczyć w koszt projektu, jako koszta związanie z zarządzaniem ryzykiem.

Również dodam na koniec, że zgodnie z rys. 1, programowanie, jako dyscyplina projektowa, ma swoje zaangażowanie również w fazach przyległych do fazy Budowa. Oznacza to, że nie możemy 100% programistów przerzucić w 100% czasu do innego projektu. Często zdarza się jednak tak, że w przedsiębiorstwie znajduje się również starszy programista. Osoba ta może pełnić rolę integratora komponentów systemu oraz może przeprowadzać systematyczne lub sporadyczne rewizje kodu. Jeśli do bezpośrednich obowiązków takiej osoby nie należy rutynowe programowanie, a tak jak wspomniałem funkcje kontrolne, może ta osoba swoim częściowym angażem pokryć zapotrzebowanie tej dyscypliny w fazach przyległych. Również często starszy programista stanowi „naturalną ” rezerwę projektową, rzecz jasna z powodu dużego doświadczenia oraz wysokiego poziomu umiejętności.