Kto, dlaczego i jak w zarządzaniu projektami w tworzeniu oprogramowania

Rozpoczynasz tworzenie oprogramowania. Masz pomysł na przyszłość, szczegółowe wymagania, wystarczającą wiedzę techniczną i wykwalifikowany zespół. Brakuje ci tylko doświadczonego kierownika projektu. Biorąc pod uwagę te dane, jakie są szanse na ukończenie projektu?

Smutną prawdą jest to, że szanse na sukces nie są tak duże. Różne badania sugerują, że główne przyczyny niepowodzeń w tworzeniu oprogramowania są w większości związane ze złym zarządzaniem projektami.

Typowe błędy w zarządzaniu projektami rozwoju oprogramowania, które powodują ich niepowodzenie, to zmiana celów projektu, nieodpowiednia komunikacja, złe zarządzanie zmianami, niedokładne szacunki kosztów, niezidentyfikowane ryzyko i inne.

Tak więc, aby mieć pewność, że Twój projekt nie wymknie się spod kontroli, musisz nadać priorytet zdrowemu zarządzaniu projektami. Poniżej dzielimy się naszą wiedzą w zakresie tworzenia oprogramowania dla przedsiębiorstw, odpowiadając na nurtujące pytania dotyczące zarządzania projektami rozwoju oprogramowania.

Jak ważne jest zarządzanie projektami dla sukcesu projektu rozwoju oprogramowania?

Krótko mówiąc, bardzo.

Projekty rozwoju oprogramowania są zazwyczaj bardzo złożone. Aby projekt został uznany za udany, musi spełniać wymagania i gwarantować wysoką jakość wykonania, a jednocześnie być ukończony na czas iw ramach budżetu. I za to odpowiada kierownik projektu.

Korzyści z zatrudniania dedykowanych talentów do zarządzania projektami rozwoju oprogramowania obejmują:

• Zmniejszone ryzyko
• Za efektywne zarządzanie ryzykiem odpowiada kierownik projektu. Na samym początku projektu mapują, dokumentują i ustalają priorytety potencjalnych zagrożeń, a także projektują strategię reagowania na ryzyko.

Cztery typowe sposoby reagowania na różne rodzaje ryzyka:

• Unikaj: wyeliminuj lub zrezygnuj z zagrożenia
• Łagodzenie: zmniejszanie prawdopodobieństwa lub wpływu zagrożenia
• Przenieś: przypisz lub przenieś zagrożenie na stronę trzecią
• Zaakceptuj: potwierdź zagrożenie i zdecyduj się nie rozwiązywać, nie przenosić ani nie łagodzić go.

Aby opracować odpowiednią strategię reagowania na ryzyko, kierownik projektu może zorganizować sesje burzy mózgów z zespołem, skorzystać ze scenorysów lub przeprowadzić wywiady z osobami ze wszystkich części operacji. Mając pod ręką strategię zarządzania ryzykiem, zespołowi projektowemu łatwiej jest przewidywać zagrożenia i zapobiegać im na czas.

• Lepsza kontrola nad kosztami projektu
• Przekroczenia kosztów są powszechne w zarządzaniu projektami rozwoju oprogramowania. Ponieważ nie tylko wpływają one na marże, ale także utrudniają realizację projektu, doświadczony kierownik projektu proponuje optymalne podejście do zarządzania kosztami.
• Szacują, budują i kontrolują koszty przez cały cykl życia projektu, mając na celu utrzymanie wydatków w zatwierdzonym pomieszczeniu. Zdrowe zarządzanie kosztami pomaga również w ustalaniu oczekiwań dla interesariuszy, kontrolowaniu rozszerzania zakresu, zwiększaniu zwrotu z inwestycji w projekt i monitorowaniu długoterminowych trendów kosztów.
• Optymalne wykorzystanie zasobów
• Zdrowe zarządzanie projektami w tworzeniu oprogramowania pomaga zapewnić, że wszystkie zasoby projektowe obejmujące ludzi, ich umiejętności, czas, narzędzia, sprzęt i usługi są skoordynowane i efektywnie wykorzystywane.
• W fazie odkrywczej projektu kierownik projektu szacuje, przydziela i planuje potrzebne zasoby, a także rozdziela je według priorytetów. Podczas opracowywania kierownik projektu śledzi wykorzystanie zasobów i usuwa wszelkie wąskie gardła, które mogą utrudniać realizację projektu.
• Lepsza kontrola nad zakresem projektu
• Częstym problemem w zarządzaniu projektami rozwoju oprogramowania jest pełzanie zakresu, którego należy unikać. Niekontrolowane zmiany wpływają na harmonogram projektu, budżet, koszty i alokację zasobów, a także utrudniają realizację kamieni milowych.
• Podchodząc do zarządzania projektami w tworzeniu oprogramowania, kierownik projektu ustala procedurę żądania zmiany i upewnia się, że jest ona przestrzegana dla każdego nowego wymagania. Celem jest uniknięcie niekontrolowanego pełzania zakresu i upewnienie się, że projekt zostanie dostarczony na czas i w ramach budżetu. Po zatwierdzeniu nowego działania i dodaniu go do zakresu harmonogram projektu i plany bazowe budżetu są odpowiednio aktualizowane.

Czym jest zarządzanie projektami w tworzeniu oprogramowania?

Zarządzanie projektami w tworzeniu oprogramowania to sztuka planowania, harmonogramowania i śledzenia działań projektowych, biorąc pod uwagę dostępne zasoby i ograniczenia.

Jak wspomniano powyżej, projekty rozwoju oprogramowania są dość złożone i obejmują wiele etapów. Kierownik projektu planuje i nadzoruje realizację projektu na tych etapach.

Według Project Management Institute istnieje pięć kluczowych etapów cyklu życia oprogramowania z punktu widzenia kierownika projektu.

• Koncepcja projektu

Kluczowym celem etapu koncepcji projektu jest określenie głównych celów projektu, zdefiniowanie potrzeb biznesowych oraz sporządzenie zestawienia prac. Te ostatnie powinny zawierać przede wszystkim wymagania dotyczące przyszłego rozwiązania oraz harmonogram realizacji projektu. Koncepcja projektu zazwyczaj wymaga ścisłej współpracy między wszystkimi interesariuszami projektu, z analitykiem biznesowym i kierownikiem projektu na czele.

• Planowanie

Etap planowania projektu to wspólny wysiłek kierownika projektu i zespołu projektowego. Zespół projektowy projektuje architekturę techniczną rozwiązania oraz opracowuje jego wygląd i działanie. Z kolei kierownik projektu opracowuje plan projektu, opracowuje strukturę podziału pracy i przygotowuje harmonogram projektu. Ostatecznym celem etapu jest jasne zrozumienie zakresu projektu i ustanowienie podstaw do monitorowania i kontroli realizacji projektu.

Na tym etapie kierownik projektu ustala również narzędzia komunikacji i śledzenia postępów, a także plany przyszłych wdrożeń, definiując kryteria akceptacji.

• Uruchomienie i realizacja projektu

Podczas gdy zespół projektowy zajmuje się inżynierią i testowaniem przyszłego rozwiązania, kierownik projektu monitoruje wydajność zespołu, usuwa wąskie gardła, które mogą utrudniać pracę nad projektem, ułatwia komunikację między członkami zespołu a interesariuszami projektu, dokumentuje postęp projektu, śledzi wyzwalacze ryzyka i raporty klientowi lub kierownictwu wyższego szczebla.

• Akceptacja projektu

Na etapie akceptacji projektu rozwiązanie lub zestaw produktów dostarczanych jest do środowiska pomostowego, gdzie jest testowane w wersji beta. W razie potrzeby zespół programistów zapewnia niezbędne lisy. Kierownik projektu dba o to, aby rozwiązanie zostało dostarczone w całości i na czas, a także gwarantuje, że dostarczone oprogramowanie spełnia uzgodnione kryteria akceptacji. Kolejną częścią zarządzania projektami w tworzeniu oprogramowania na etapie akceptacji projektu jest przygotowanie instrukcji obsługi, instrukcji instalacji i innej dokumentacji projektowej.

• Zakończenie projektu

Po zakończeniu projektu kierownik projektu przeprowadza przegląd retrospektywny, podczas którego ocenia i dokumentuje wzloty i upadki całego projektu. Zapewniają również przekazanie pełnego zakresu rezultatów do klienta/właściciela produktu, w tym całego kodu źródłowego, dokumentacji oprogramowania, środowiska programistycznego i innych.

Te zasadnicze etapy mogą następować po sobie liniowo lub pozwalać na większe nakładanie się — w zależności od wybranego podejścia do zarządzania projektami rozwoju oprogramowania.

Zarządzanie projektami w tworzeniu oprogramowania: popularne metodologie

Do najczęściej stosowanych metodologii zarządzania projektami oprogramowania należą Scrum, Kanban (oba należące do rodziny Agile) i Waterfall.

Inne, mniej popularne podejścia do zarządzania projektami w zakresie wytwarzania oprogramowania: przyrostowy model rozwoju, model spiralny PRINCE2 i Rational Unified Process (RUP).

Scrum

Scrum, jedno z najpopularniejszych podejść do zarządzania projektami w tworzeniu oprogramowania, dzieli proces rozwoju na sprinty, każdy po dwa do czterech tygodni. Sprinty są zazwyczaj poprzedzone dokładnym planowaniem. Dobrze pasuje do projektów o wysokim poziomie niepewności, Scrum opiera się na wielofunkcyjnych, samoorganizujących się zespołach i przyjmuje ideę rozwoju przyrostowego opartego na obserwacji i eksperymentowaniu.

Zarządzanie projektami w oparciu o Scrum w tworzeniu oprogramowania różni się nieco od tradycyjnego zarządzania, ponieważ nie ma PM jako takiego. Zamiast tego obowiązki jednego są dzielone między Właściciela Produktu i Scrum Mastera.

Kanban

Osobliwością Kanbana jest to, że nie ma wyraźnie zdefiniowanych iteracji. Jest to szczupłe podejście do zarządzania projektami rozwoju oprogramowania, które pomaga zwizualizować zakres projektu, ograniczyć pracę w toku i zapewnić płynny przepływ pracy. Metodologia wykorzystuje fizyczne lub cyfrowe tablice kanban, które reprezentują unikalny proces pracy zespołu.

Ze względu na swój charakter model dobrze sprawdza się w projektach wsparcia i utrzymania.

Inną osobliwością Kanbana jest ograniczenie ilości pracy w toku. Metodologia ma na celu zrównoważenie zakresu i zasobów. Zadania są pobierane, gdy pozwala na to dostępna pojemność, a nie są wpychane do procesu na żądanie.

Obowiązki związane z zarządzaniem projektem rozwoju oprogramowania są zwykle dzielone między dwie role niezbędne dla Kanban: menedżera dostarczania usług i menedżera zgłoszeń serwisowych. Pierwszy odpowiada za zwiększenie efektywności przepływów pracy, drugi zajmuje się głównie interpretacją potrzeb i oczekiwań klienta.

Nie ma jednak potrzeby zatrudniania dodatkowych członków zespołu, aby dopasować się do zasad Kanban. W rzeczywistości doświadczony PM zwykle dobrze nadaje się do obu ról.

Wodospad

W przeciwieństwie do rodziny Agile, zarządzanie projektami oparte na wodospadzie dzieli projekt na odrębne, sekwencyjne fazy.

Tradycyjnie nowy etap rozpoczyna się po całkowitym zakończeniu poprzedniego. Nowoczesne projekty Waterfall pozwalają jednak na pewne nakładanie się. Na przykład, dość często zdarza się, że zespół testowy zaczyna weryfikować poszczególne funkcje podczas tworzenia.

Podejście Waterfall do zarządzania projektami rozwoju oprogramowania sprawdza się dobrze w przypadku projektów o przewidywalnym zakresie, jednak może pozostawić zespoły programistów z trudem i nie mogą dostosować się szybciej niż konkurencja.

Ponieważ istnieją osobliwości w zarządzaniu projektami w Waterfall i Agile, przyjrzyjmy się kluczowym różnicom.

Jaka jest różnica między zarządzaniem projektami Waterfall a Agile?

Przyjrzyjmy się teraz bardziej szczegółowo, jak różnią się praktyki zarządzania w projektach Waterfall i Agile. Porównujemy te dwie metody, ponieważ są one bardziej powszechne niż inne metodologie zarządzania projektami i istnieją znaczne różnice w sposobie organizacji pracy projektowej w obu. Ta ostatnia wpływa na rolę i obowiązki kierownika projektu (lub odpowiednią rolę w Agile).

Planowanie

W Wodospadzie nie da się iść do przodu bez dokładnego zrozumienia tego, co budujesz i dlaczego. Dlatego stworzenie wyczerpującej specyfikacji wymagań oprogramowania jest priorytetem numer jeden w projektach Waterfall. Zazwyczaj SRS jest pisany przez analityka biznesowego. Ale w przypadku jego braku kierownik projektu może przejąć kontrolę.

Z drugiej strony Agile pozwala na większą elastyczność. Wprowadzanie usprawnień produktów i procesów w ruchu to esencja metodologii Agile. Czynności planistyczne są zwykle przeprowadzane na jeden sprint z wyprzedzeniem. Backlog jest tworzony podczas tzw. sprintu zero.

Podczas sprintu zero zespół wymyśla minimalną liczbę historyjek użytkownika, aby przekształcić się w działający produkt i opcjonalnie konfiguruje infrastrukturę do rozwoju. Sprint jest zwykle utrzymywany na lekkim i wysokim poziomie.

Zarządzanie zakresem projektu i budżetowanie

W Waterfall zakres rozwiązania musi pozostać nienaruszony przez cały czas trwania projektów. Żądania zmiany są zarządzane zgodnie z procedurą zarządzania zmianą i są rozliczane oddzielnie. Zarządzanie projektami w rozwoju oprogramowania Agile oferuje większą elastyczność w zakresie zarządzania zakresem, ale utrudnia ocenę wpływu zmian zakresu na ostateczne koszty oprogramowania. Wpływa to na podejście do budżetowania projektów.

W Waterfall budżetowanie jest odgórne, kontrolowane i oparte na szczegółowym uzasadnieniu biznesowym. Takie podejście pozwala na realistyczne oszacowanie kosztów po zebraniu i przeanalizowaniu wymagań. Główną wadą jest to, że takie podejście nie działa w niestabilnych, niepewnych i niejednoznacznych środowiskach, którymi często są projekty programistyczne.

Sposób zarządzania kosztami projektów rozwoju oprogramowania w Agile jest wrażliwy na zmiany. A to jest zarówno zaleta, jak i złożoność. Budżetowanie zwinne jest dostosowane do struktury i harmonogramu projektu. A ponieważ jest on również zgodny ze strukturą sprintu, zespołowi łatwiej jest dostosować się do zmieniających się okoliczności — bez wpływu na cały budżet projektu. Kierownik projektu po prostu ponownie kalibruje wydatki w następnej rundzie planowania.

Wyniki projektu

Podążając ścieżką Agile, firmy uzyskują przyrost nowej funkcjonalności lub jakiś inny wynik — czy to wizja techniczna, działająca funkcja, czy MVP — po każdej iteracji.

Z kolei w klasycznym Waterfall, klient nie otrzymuje tak naprawdę żadnego spójnego, działającego rozwiązania do końca projektu. Działania związane z testowaniem na pełną skalę są również prowadzone na późniejszym etapie procesu rozwoju, co może mieć wpływ na czas wprowadzenia na rynek.

Dokumentacja projektu

Właściwe, udokumentowane planowanie jest koniecznością w zarządzaniu projektami rozwoju oprogramowania zgodnie z Waterfall. Wymagania projektowe muszą być jasne z góry i każdy członek zespołu powinien być ich świadomy. Każdy członek zespołu powinien również rozumieć, jaka jest jego rola w projekcie i czego się od niego oczekuje. Te informacje są zwykle również dokumentowane i rozpowszechniane wśród zespołu projektowego.

Zespoły kaskadowe często odwołują się do dokumentacji w trakcie procesu tworzenia, aby ułatwić śledzenie postępów. I to jedyny sposób, aby to zrobić — biorąc pod uwagę długość i złożoność projektów zwykle zarządzanych zgodnie z Waterfall. Dokumentacja odbywa się na każdym etapie, dzięki czemu wszyscy są na tej samej stronie na temat postępów projektu, pomimo sekwencyjnego charakteru modelu.

Chociaż obszerna dokumentacja służy zmniejszeniu ryzyka w Waterfall, obniża zdolność adaptacji do zmian w Agile. Dlatego w projektach Agile często powstaje mniej dokumentacji. A jeśli jest produkowany, dokumenty są zwięzłe.

Jednak pomimo powszechnego błędnego przekonania, w metodologii Agile nie ma nic, co z natury rzeczy uniemożliwia zespołom tworzenie tylu dokumentacji, ile potrzebują. Niektóre dokumenty są w rzeczywistości absolutnie niezbędne. Dodawanie historyjek użytkowników do zaległości, tworzenie makiet i dokumentowanie spotkań z klientami jest koniecznością. Agile sugeruje, że mądrzejszy jest proces dokumentowania i unikanie zbyt długiej dokumentacji.

Jakie są obowiązki kierownika projektu?

Obowiązki kierownika projektu również będą się różnić w zależności od podejścia do zarządzania projektem rozwoju oprogramowania. Zobaczmy, co dokładnie robi PM lub odpowiednia rola Agile na każdym etapie projektu.

W wodospadzie

Kierownik projektu to najważniejsza rola w każdym zespole Waterfall. Odpowiadają za jakość produktów i realizację projektu zgodnie z harmonogramem. Do ich głównych obowiązków należy nadzór nad działaniami projektowymi oraz wyznaczanie zadań dla członków zespołu.

Podzielmy teraz zakres prac PM na fazy.

W Agile

Kierownik projektu Agile ustala priorytety pozycji backlogu dla każdego sprintu, monitoruje postępy w rozwoju i nawiązuje skuteczną komunikację w zespole, a także między zespołem a interesariuszami. Monitorują również ryzyko na każdym etapie projektu i upewniają się, że proces rozwoju jest zgodny z zasadami Agile.

To właśnie robi kierownik projektu na każdym etapie projektu Agile:

Na jakie pułapki musi zwracać uwagę kierownik projektu?

Kluczem do sukcesu w zarządzaniu projektami rozwoju oprogramowania jest umiejętność zapobiegania i unikania ryzyka. Typowe pułapki, na które dobry PM powinien zwracać uwagę:

Brak kontroli nad zakresem

Szczególnie w Agile często zdarza się, że klienci żądają dodatkowych funkcji w podróży, co często powoduje, że projekty kończą się niepowodzeniem. Dlatego kierownik projektu musi wprowadzić jasną procedurę zarządzania zmianą, aby zapobiec rozszerzaniu się zakresu. Muszą również upewnić się, że interesariusze są na tej samej stronie na temat wpływu zmian na harmonogram i zasoby projektu.

Nie skupianie się na dotrzymaniu terminu dostawy

Opracowując produkt o ścisłych wymaganiach dotyczących czasu wprowadzenia na rynek, na przykład aplikację edukacyjną, która musi zostać wydana przed rozpoczęciem roku szkolnego lub aplikację detaliczną, która musi zostać wprowadzona na czas przed wyprzedażami świątecznymi, musi uderzyć PM odpowiednia równowaga między terminowością a zapewnieniem wysokiej jakości.

Muszą zainwestować dodatkowy wysiłek w ustalanie priorytetów funkcji i ustalanie terminów dostarczenia każdej funkcji. Wymagania jakościowe muszą być również określone z góry, aby uniknąć problemów pojawiających się po wdrożeniu.

Nieumiejętność nawiązania skutecznej komunikacji

Efektywne zarządzanie projektami w tworzeniu oprogramowania wymaga efektywnej i przejrzystej komunikacji. Ustanowienie jednego z nich to kluczowa odpowiedzialność premiera. Muszą informować zespół o decyzjach interesariuszy i regularnie informować interesariuszy o wszystkich działaniach projektowych, wąskich gardłach i wyzwaniach.

Nieustanowienie jasnych procesów

Śledzenie procesu tworzenia oprogramowania może wydawać się obciążeniem dla członków zespołu. Mimo to konieczne jest stworzenie przejrzystego przepływu pracy, dostosowanego do specyfiki projektu. Uporządkuje pracę i jasno określi oczekiwania.

Poleganie na nieznanej technologii

Kierownik projektu musi upewnić się, że zespół inżynierów skupia się na rozwiązaniu problemu biznesowego klienta podczas dokonywania wyborów technologicznych. Muszą również sprawdzić, czy wybrany stos technologiczny jest zgodny z najlepszymi praktykami inżynierskimi.

Inną pułapką związaną z technologią jest brak planowania skalowalności na wczesnych etapach rozwoju produktu. Dlatego doradzamy, aby z góry zdefiniować wymagania dotyczące skalowalności wraz z innymi wymaganiami niefunkcjonalnymi.

Nieprzemyślanie z wyprzedzeniem procesu wdrażania

Proces wdrażania jest często pomijany na wcześniejszych etapach rozwoju, co prowadzi do krytycznych opóźnień podczas wdrażania. Zdrowe zarządzanie projektami w tworzeniu oprogramowania wymaga od kierownika projektu, aby upewnić się, że problemy związane z wdrażaniem i instalacją są przemyślane na wczesnym etapie procesu rozwoju.

Jak podejść do zarządzania projektami w tworzeniu oprogramowania: perspektywa ITRex

Spotkaliśmy się z Alexandrem Belkavetsem, Lead PM w ITRex, i przeprowadziliśmy z nim wywiad na temat tego, jak w ITRex podchodzimy do zarządzania projektami oprogramowania. Oto czego się nauczyliśmy.

Na jakich czynnikach kierujesz się przy wyborze odpowiedniego modelu zarządzania projektami dla naszych klientów?

Alexander: Istnieje wiele czynników decydujących o wyborze takiego lub innego podejścia do zarządzania projektami. Najważniejsze z nich to zakres projektu, budżet i czas wprowadzenia produktu na rynek.

Jeśli pracujemy nad produktem, który musi być regularnie aktualizowany, aby stale generować wartość dla użytkowników końcowych, powiedzmy, aplikacją do gier, naturalnie wybralibyśmy Scrum lub podejście podobne do Scrum.

Z drugiej strony, jeśli pracujemy nad oprogramowaniem zleconym przez podmiot rządowy, co zwykle oznacza, że ​​budżet jest ustalony, wolelibyśmy raczej zastosować podejście przypominające wodospad, aby zapewnić niezbędną przewidywalność. Nierzadko zdarza się jednak dzielenie fazy rozwoju na mniejsze iteracje. Dlatego często uciekamy się do podejścia hybrydowego, które pozwala nam czerpać korzyści z przewidywalności Waterfall oraz ciągłego doskonalenia i szybkości dostarczania Agile.

Czy na wybór metodyki zarządzania projektami mają wpływ inne czynniki?

Aleksander: Jasne. Sektor, w którym będzie zastosowane przyszłe rozwiązanie, potrzeby certyfikacyjne, gotowość klienta do zaangażowania się w proces i wiele innych czynników wpływa również na projekt.

Opracowując na przykład rozwiązania w zakresie opieki zdrowotnej, często wybiera się wodospad. W Stanach Zjednoczonych, zanim będzie można wprowadzić na rynek, powiedzmy, nowatorskie urządzenie medyczne, trzeba je zatwierdzić przez FDA; a to wymaga obszernej dokumentacji, która byłaby niemożliwa do zapewnienia po Agile.

Na czym dokładnie polega Twoja rola jako kierownika projektu? Jaki jest Twój główny cel w zarządzaniu projektami naszych klientów?

Alexander: Na swoją rolę kierownika projektu patrzę z dwóch perspektyw.

Pierwszy to: zarządzanie projektem to zarządzanie ryzykiem. Projekty rozwoju oprogramowania są podatne na wiele zagrożeń — od z natury wadliwych wymagań, przez nieodpowiednie zaopatrzenie, po zmieniające się krajobrazy technologiczne i nie tylko. Kluczowym celem kierownika projektu w tym zakresie jest minimalizacja wpływu ryzyk na projekt, a tym samym maksymalizacja możliwości pomyślnego dostarczenia oprogramowania.

Druga perspektywa to: zarządzanie projektem staje się swego rodzaju integratorem, który umożliwia harmonijne połączenie wielu podsystemów projektowych, takich jak rozwój, testowanie i wdrażanie. Kluczowym celem kierownika projektu jest zorganizowanie wszystkich procesów w ramach projektu w sposób, który powoduje mniejsze ryzyko i zapewnia maksymalne wykorzystanie zasobów.

Czy można wrócić myślami do projektu, w którym wybrane podejście do zarządzania projektami okazało się decydującym czynnikiem sukcesu produktu?

Alexander: Tworzyliśmy aplikację mobilną dla naszego klienta i rozpoczęliśmy projekt od Scrum. Po wydaniu pierwszej wersji aplikacji i uzyskaniu pierwszych metryk produktu postanowiliśmy przejść na Kanban.

Aby zatrzymać pierwszych użytkowników, musieliśmy regularnie dostarczać nowe funkcje, chociaż dwutygodniowe sprinty nie były już potrzebne. Kanban pozwolił nam dostosować długość sprintu do złożoności nowych funkcji, ze średnim sprintem od trzech do czterech tygodni, więc utrzymaliśmy tempo dostarczania bez wywierania dodatkowej presji na zespół programistów. Dzięki temu naszemu klientowi udało się zatrzymać i pozyskać nowych użytkowników.

Ponieważ zespoły zwinne są pozycjonowane do samodzielnego zarządzania, kuszące jest, aby uwierzyć, że projekt można równie dobrze ukończyć bez dedykowanego kierownika projektu. Czy tak jest?

Alexander: W przypadku braku dedykowanego PM, obowiązki jednego musiałyby być rozłożone na wszystkich członków zespołu. Nadal trzeba będzie poświęcić czas na ustalanie priorytetów zaległości, pozyskiwanie zasobów, raportowanie i wykonywanie innych istotnych zadań zarządczych. Ale w przypadku braku PM zadania te byłyby delegowane na osoby bez specjalistycznej wiedzy. To nie pomaga zmaksymalizować wykorzystania talentów.

Podejście „no-PM” może działać w małym zespole składającym się z 3-4 osób, ale gdy liczba ta rośnie, posiadanie dedykowanego kierownika projektu staje się niezbędne.

Jeśli nadal masz pytania dotyczące zarządzania projektami rozwoju oprogramowania lub chcesz przekazać odpowiedzialność za prowadzenie swojego projektu doświadczonemu partnerowi, skontaktuj się z ITRex.

Pierwotnie opublikowany na https://itrexgroup.com 24 października 2022 r.