Istnieją projekty, które są dość proste i względnie przewidywalne, gdzie można zastosować racjonalne narzędzia planowania i podejmowania decyzji. Inne projekty, które są bardziej złożone lub nieprzewidywalne, wymagają innego podejścia, opierającego się bardziej na samoorganizacji i innowacjach.
Większość projektów dotyczących oprogramowania uważa się za złożone i nieprzewidywalne z powodu zbiegu trzech czynników: ludzi, wymagań i technologii. Różne podejścia stosowane do realizacji i zarządzania projektami można łatwiej zrozumieć w kontekście modeli kontroli procesów i złożoności projektów.
Zdefiniowany Proces — Tradycyjne Podejście Sterowane Planem
Tradycyjnie, po rozpoczęciu projektu tworzony jest pakiet wymagań, a następnie jest „zaakceptowany”. Kierownik projektu zakłada, że ta akceptacja oznacza ustalony zestaw wymagań i że teraz można rozpocząć planowanie. Kierownik projektu szacuje, jak długo zajmie spełnienie wymagań i tworzy plan projektu. Plan przewiduje, że projekt zostanie ukończony do określonej daty, a ta data jest komunikowana klientowi.
Podstawowy błąd w tym podejściu polega na tym, że plan, który napędza wszystko, opiera się na założeniu, że wymagania są ustalone i nie ulegną zmianie. Doświadczenie pokazuje, że nigdy tak nie jest; wymagania nigdy nie są ustalone — zawsze się zmieniają. Gdy wymagania ulegają zmianie, plan jest dotknięty; w rezultacie data zakończenia musi się również zmienić. Niestety, w wielu przypadkach jest to niemożliwe, a zespół musi dostarczyć projekt do daty, na którą się zobowiązał. Wtedy następuje poważny kryzys, a projekt zaczyna wymykać się spod kontroli.
Proces Empiryczny — Zwinne Podejście Sterowane Wartością
Zwinne podejście sterowane wartością opiera się na empiryzmie, który zmienia całe myślenie. Od samego początku zakłada, że jakiekolwiek wymagania istniejące na początku nie są ustalone i że ulegną zmianie.
Zwinne myślenie zakłada również, że trzeba dostarczyć projekt do określonej daty. To podejście ustala czas i zasoby, pozostawiając wymagania nieokreślone. Dla nas to podejście bardziej przypomina rzeczywistość tworzenia oprogramowania. Teraz całe pojęcie sterowania wartością ma doskonały sens. Kiedy masz ustalony czas, w którym nie jesteś pewien, czy zdołasz dostarczyć wszystkie wymagania (ponieważ się zmienią i tym samym czas potrzebny na ich zrealizowanie), naturalną reakcją jest ustalenie priorytetów wymagań i najpierw zrealizowanie tych, które dodają największą wartość dla klienta.
Możesz myśleć: „A co z wymaganiami, które nie zostaną zrealizowane do daty dostarczenia?” To jest powód, dla którego stosuje się podejście sterowane wartością. Uznajesz fakt, że nie wszystkie wymagania zostaną zrealizowane do daty dostarczenia. Ważne pytanie brzmi: czy dostarczono wystarczająco funkcji, aby wspierać system, który dostarcza wartość klientowi.
Wskaźnik Niepowodzeń Projektów Oprogramowania
Raport CHAOS na rok 2015 został niedawno opublikowany przez Standish Group. Raporty CHAOS są publikowane co roku od 1994 roku i stanowią przekrój stanu przemysłu oprogramowania. W tym roku raport badał 50 000 projektów na całym świecie, od niewielkich ulepszeń po ogromne implementacje przebudowy systemów. W tym roku raport zawiera rozszerzoną definicję sukcesu, uwzględniając kilka dodatkowych czynników, które były omawiane w poprzednich badaniach.
Wyniki wskazują, że nadal jest wiele do zrobienia w celu osiągnięcia sukcesów w projektach dotyczących oprogramowania. Poniższa tabela podsumowuje wyniki projektów z ostatnich pięciu lat, wykorzystując nową definicję czynników sukcesu (w terminie, w budżecie z zadowalającym wynikiem).
Dzięki zastosowaniu metod zwinnego rozwoju oprogramowania w ostatnich latach możliwe było porównanie wyników projektów między zwinnością a tradycyjnymi projektami wodospadowymi. We wszystkich rozmiarach projektów podejścia zwinne dawały więcej sukcesów i mniej całkowitych niepowodzeń, jak pokazuje poniższa tabela
Jakie są Problemy z Tradycyjnym Podejściem?
Tradycyjne podejście oparte na planie nie jest wadliwe samo w sobie; po prostu nie nadaje się do dzisiejszego przemysłu oprogramowania. Podejście oparte na planie pierwotnie opierało się na tradycyjnych koncepcjach zarządzania projektami, które pochodziły z branży budowlanej. W branży budowlanej podejście oparte na planie jest odpowiednie: plany, czyli wymagania, są ustalone i prawdopodobnie się nie zmienią podczas budowy. Można oszacować, jak długo zajmie budowa stalowych filarów, wylewanie betonu itd.
Powód, dla którego tradycyjne podejście oparte na planie nadaje się do branży budowlanej, ale nie do branży oprogramowania, tkwi w różnicy w sposobie kontrolowania systemów empirycznych (takich jak tworzenie oprogramowania) i systemów zdefiniowanych (takich jak budownictwo lub produkcja). Poniższa tabela pokazuje różnice między cechami procesu zdefiniowanego a procesu empirycznego.
Po przeczytaniu tabeli łatwo zauważyć, że tworzenie oprogramowania jest zdecydowanie procesem empirycznym, a nie zdefiniowanym. Problem polega na tym, że przez lata podejście do tworzenia oprogramowania traktowano jako proces zdefiniowany — a to podejście nie działa.
Źródła
- Raport CHAOS Standish Group 2015
- Becoming Agile in an Imperfect Word — autorzy Greg Smith & Ahmed Sidky
Inne Lektury na Temat Scrum
- Scrum w 3 Minuty
- Czym są 5 Wartości Scrum?
- Jakie jest Ewolucja Scrum?
- Klasyczne Zarządzanie Projektami vs Zwinne Zarządzanie Projektami
- Dlaczego Scrum jest Trudny do Opanowania?
- Co to jest Prędkość w Scrum?
- Co to jest Agile? Co to jest Scrum?
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文