Zagrożenia dla projektów rozwoju oprogramowania są często minimalizowane lub pomijane, ponieważ nie są tak namacalne, jak zagrożenia dla projektów w innych branżach. Istnieją jednak zagrożenia i mogą wykoleić projekt rozwoju oprogramowania, podobnie jak projekt w każdej innej branży.
Większość kierowników projektów informacyjnych miała doświadczenie w planowaniu projektu rozwoju oprogramowania w najdrobniejszych szczegółach, planowaniu wysiłku dla każdego zadania w planie do ostatniej godziny, a następnie nieprzewidzianym problemie, który rozwiązuje problem projektu i uniemożliwia dostarczać na czas lub z pierwotnie zamierzonym zakresem funkcji.
Skuteczni menedżerowie projektów w każdej branży muszą być również wykwalifikowanymi menedżerami ryzyka. Rzeczywiście branża ubezpieczeniowa sformalizowała stanowisko menedżera ryzyka. Aby skutecznie zarządzać ryzykiem związanym z projektem rozwoju oprogramowania, musisz najpierw zidentyfikować te zagrożenia. Ten artykuł został napisany, aby dać ci kilka wskazówek i technik, które pomogą ci to zrobić. Istnieją pewne warunki, które nie mają bezpośredniego zastosowania do identyfikacji ryzyka, co pomaga zrozumieć przed badaniem identyfikacji ryzyka. Oto niektóre z tych definicji:
- Zdarzenie ryzyka – To zdarzenie wpływa na projekt, jeśli powinno ono nastąpić.
- Zagrożenie – Zdarzenie ryzyka, które w razie wystąpienia negatywnie wpływa na zakres, jakość, harmonogram lub budżet projektu.
- Okazja – Nie wszystkie zagrożenia są zagrożeniami, niektóre z nich mają pozytywny wpływ na zakres, jakość, harmonogram lub budżet, jeśli powinny się pojawić. Zagrożeń należy unikać lub ograniczać ich skutki, promować szanse lub zwiększać ich skutki.
- Prawdopodobieństwo – prawdopodobieństwo wystąpienia zdarzenia ryzyka. Tak nazywają się ludzie z branży gier.
- Wpływ – Zwykle odnosi się do porównawczej rangi głównej lub kolejności związanej ze zdarzeniem ryzyka. Może również odnosić się do bezwzględnej wartości pieniężnej, okresu, zakresu funkcji lub poziomu jakości.
- Tolerancja ryzyka – Dotyczy to podejścia Twojej firmy do podejmowania ryzyka. Czy to jest konserwatywne? Czy Twoja organizacja chętnie oblicza ryzyko?
- Próg ryzyka – Tolerancja ryzyka dla Twojej organizacji jest zwykle wyrażana jako główny lub komparator, przy użyciu prawdopodobieństwa i wpływu zdarzeń ryzyka do zbudowania komparatora. Ryzyko, którego wartość prawdopodobieństwa / wpływu przekracza ten próg, jest unikane lub zmniejszane. Ryzyko z wynikiem poniżej progu jest dopuszczalne.
- Nieprzewidziane ryzyko – Jest to suma przeznaczona na projekt w celu zarządzania ryzykiem. Należy go podzielić na dwie kwoty: jedną na ryzyko zidentyfikowane przez kierownictwo i jedną na ryzyko niezidentyfikowane przez kierownictwo lub nieznane nieznane. Suma może być kwotą pieniędzy lub okresem czasu.
Kierownik projektu projektu rozwoju oprogramowania może korzystać z różnych źródeł w celu identyfikacji ryzyk: ryzyka ogólnego (ryzyka, które dotyczą każdego projektu rozwoju oprogramowania), ryzyka zidentyfikowanego w organizacji wykonującej, ryzyka zidentyfikowanego za pomocą metodologii SDLC wybranej dla projektu ryzyko specyficzne dla działalności deweloperskiej, ekspertów merytorycznych, warsztatów ryzyka i ankiet.
Typowe ryzyko
Istnieje wiele zagrożeń wspólnych dla każdego projektu rozwoju oprogramowania, niezależnie od wielkości, złożoności, komponentów technicznych, narzędzi, umiejętności i klientów. Poniższa lista zawiera większość z nich:
- Brakujące wymagania – Wymagania, że system oprogramowania musi zostać opracowany, aby osiągnąć cele biznesowe i założenia projektu.
- Niewłaściwe wymagania – Wymagania, które zostały schwytane, ale których pierwotna intencja została utracona lub źle zinterpretowana podczas przechwytywania.
- Ważne lub krytyczne zasoby zostały utracone dla projektu – Zasoby te są zwykle indywidualnymi pracownikami lub członkami zespołu o ograniczonych umiejętnościach, na które istnieje duże zapotrzebowanie w organizacji wykonującej. Potencjalny wpływ utraty zasobu na pewien czas zwiększa się, jeśli zadania zostaną mu przypisane na ścieżce krytycznej.
- Złe oszacowanie – Szacunki dotyczące wysiłków na rzecz rozwoju oprogramowania są albo wyraźnie niedoszacowane (złe), albo przereklamowane (również złe). Niedocenianie jest najczęstszym wydarzeniem. Praca jest zwykle przedłużana, aż zajmuje cały czas z powodu przeszacowania.
- Brakujące lub niekompletne umiejętności – Wyniki tego zdarzenia ryzyka odpowiadają wynikom złego oszacowania, ale ryzyko jest zmniejszane w różny sposób. Wynikiem zidentyfikowania młodszego programisty jako programisty pośredniego może być znaczny wzrost wysiłku wymaganego do uzyskania jego wyników lub całkowita niezdolność do ich uzyskania.
– Te zdarzenia ryzyka powinny być rejestrowane przez kierownika projektu na początku każdego ćwiczenia identyfikacji ryzyka, nawet jeśli prawdopodobne jest, że zostaną zidentyfikowane przez inną osobę w zespole. Jeśli uczynisz je widocznymi dla zespołu przed wszystkimi ćwiczeniami identyfikacji ryzyka, unikniesz marnowania czasu na rozmowę i możesz pobudzić do myślenia o związanych z tym zagrożeniach („….. co, jeśli Jane zostanie powołana do projektu o wyższym priorytecie?”) czy to oznacza również, że Fred zagubił się w projekcie? „).
Ryzyko organizacyjne
Są to ryzyka, które dotyczą tylko organizacji prowadzącej projekt. Możesz dodać niektóre z zagrożeń do listy ogólnych zagrożeń i innych źródeł, ale obejmują one również ryzyka, dla których nie ma innych źródeł.
Kierownik projektu powinien zapoznać się z archiwami poprzednich projektów programistycznych w sprawie ogólnych zagrożeń, które zostały zarchiwizowane. Zbierz rejestry ryzyka ze wszystkich poprzednich projektów (lub przynajmniej tyle, aby zapewnić reprezentatywny wybór rejestrów ryzyka) i spróbuj dopasować ryzyko w każdym rejestrze. Jest bardzo mało prawdopodobne, aby ryzyko było takie samo dla wszystkich projektów z dobrym wyborem rejestrów. Powinieneś jednak dokładnie zbadać ryzyko wymienione w dwóch lub więcej rejestrach pod kątem ich zastosowania do twojego projektu.
Skonsultuj się z kierownikami projektów odpowiedzialnymi za poprzednie projekty rozwoju oprogramowania w Twojej organizacji, dla których nie są dostępne archiwa. Możliwe jest, że ci kierownicy projektów zarchiwizowali artefakty projektu, w tym rejestry ryzyka, w osobistej przestrzeni, nawet jeśli organizacja nie ma ustrukturyzowanego podejścia do archiwizacji. Wykorzystanie doświadczenia doświadczonych kierowników projektów z poprzednich projektów jest również pomocne przy dekodowaniu ryzyka zarejestrowanego w zarchiwizowanych rejestrach ryzyka.
Ryzyka nie są określone w dwóch językach w różnych rejestrach (lub w różnych menedżerach projektów). Musisz przeanalizować oświadczenie o ryzyku, aby ustalić, gdzie dwa lub więcej zdarzeń ryzyka jest takich samych, pomimo różnych opisów.
Ryzyko specyficzne dla SDLC
Twój projekt rozwoju oprogramowania jest narażony na pewne ryzyko i chroniony przed innymi, w zależności od metody cyklu rozwoju oprogramowania (SDLC), której używasz w swoim projekcie. Unikanie ryzyka jest ważnym czynnikiem przy wyborze SDLC dla projektu, a twój projekt powinien wybrać SDLC, który pozwala uniknąć lub złagodzić skutki najbardziej prawdopodobnego ryzyka w twoim przypadku. W tym celu identyfikacja zagrożeń i wybór SDLC, takich jak kurczak i jajko, są trudne: trudno jest ustalić, co będzie pierwsze. Oto wskazówka dotycząca sekwencjonowania tych dwóch. Wybierz SDLC w oparciu o rodzaj oprogramowania, które ma zostać opracowane, oraz organizację, w której go rozwijasz (na ile doświadczona jest organizacja z zaangażowanymi narzędziami i komponentami? Jakie masz doświadczenie z każdym SDLC? Jakie są priorytety projektu? Itd.) . ). Po wybraniu SDLC możesz zidentyfikować związane z tym ryzyko. Jeśli powiązane ryzyko przekracza tolerancję ryzyka w firmie, możesz wybrać ponownie.
Każdy typ SDLC lub kategoria SDLC niesie ryzyko. Porozmawiamy o niektórych typowych zagrożeniach dla najpopularniejszych typów lub kategorii SDLC.
Wodospad
Projekty wykorzystujące metodologię Waterfall do rozwoju są najbardziej narażone na zdarzenia ryzyka, które wpływają na harmonogram. Wynika to z faktu, że metoda nie zawiera żadnych pośrednich punktów kontrolnych umożliwiających identyfikację problemów na wczesnym etapie tworzenia. Opóźnienia w działaniach od zebrania wymagań do testowania akceptacji użytkownika opóźniają ostateczną dostawę do projektu. Zdarzenia ryzyka należące do kategorii opóźnień obejmują: opóźnienia wynikające z nieznajomości narzędzi lub komponentów (np. Języków programowania, narzędzi testowych), opóźnienia wynikające z niedoszacowania wysiłku, opóźnienia wynikające z braku doświadczenia i opóźnienia wynikające z niedotrzymania terminów Requester.
Opóźnienia nie są jedynymi zdarzeniami ryzyka, na które narażony jest projekt wodospadu. Projekty wodospadów nie są dobrze zaprojektowane, aby rozpowszechniać naukę w całym projekcie, więc błąd popełniony w jednym obszarze rozwoju można powtórzyć w innych obszarach i ujawnić się dopiero pod koniec projektu. Błędy te mogą powodować, że programowanie będzie trwać dłużej niż to konieczne lub planowane, może spowodować więcej przeróbek, niż pierwotnie planowano, zmniejszyć rozmiar poprzez odrzucenie niepoprawnego kodu lub obniżyć jakość produktu.
Metodę wodospadu zwykle stosuje się w większych projektach, które zajmują więcej czasu niż inne metody programistyczne, co czyni je podatnymi na zmiany. Zadaniem procesu zarządzania zmianami jest prawidłowe obsługiwanie wszystkich żądanych zmian. Jednak wraz ze wzrostem czasu trwania projektu prawdopodobieństwo wyczerpania projektu przez żądania zmian i bufory do analizy itp. Wyczerpuje się. Prowadzi to do opóźnień projektu i przekroczenia budżetu.
Szybkie tworzenie aplikacji (RAD)
Szybki rozwój aplikacji powinien skrócić czas wymagany do opracowania aplikacji. Główną zaletą tego podejścia jest eliminacja wniosków o zmianę. Teoria jest taka, że zmiany nie są konieczne do szybkiego przetwarzania. Jest to jednak obosieczny miecz. Fakt, że metoda opiera się na braku wniosków o zmianę, poważnie ograniczy zdolność projektu do ich uwzględnienia.
Ryzyka, które najprawdopodobniej wystąpią w projekcie stosującym tę metodologię, są związane z użytecznością aplikacji. Rynek lub firma mogą ulec zmianie w trakcie projektu i mogą nie być w stanie odpowiedzieć na wynikłe żądanie zmiany w pierwotnym harmonogramie. Albo harmonogram jest opóźniany podczas wprowadzania zmiany, albo zmiana nie jest wprowadzana, co skutkuje zbudowaniem systemu, który nie spełnia wymagań klienta.
Metoda RAD wymaga stosunkowo niewielkiego zespołu i stosunkowo niewielkiego zakresu funkcji do obsługi szybkiego przetwarzania. Możliwym skutkiem małego zespołu jest brak niezbędnych umiejętności w zespole. Innym powodem jest brak redundancji umiejętności, co oznacza, że choroby członka zespołu nie można wchłonąć bez opóźnienia harmonogramu lub otrzymania pomocy z zewnątrz.
Crush
Cechą wyróżniającą tę metodę programowania jest brak kierownika projektu. Rolę tę zastępuje lider zespołu. Lider zespołu może być kierownikiem projektu, ale jest mało prawdopodobne, aby organizacja wykonawcza znalazła i zatrudniła doświadczonego kierownika projektu do pełnienia tej roli. Metoda ta pozwala uniknąć zarządzania kierownikiem projektu, aby uniknąć niektórych rygorystycznych najlepszych praktyk zarządzania projektem i zoptymalizować rozwój. Ryzyko związane z tym podejściem polega na tym, że zespół nie ma wymaganej dyscypliny: zarządzania zmianami, zarządzania wymaganiami, zarządzania harmonogramem, zarządzania jakością, zarządzania kosztami, zarządzania zasobami ludzkimi, zarządzania zaopatrzeniem i zarządzania ryzykiem.
Brak dyscypliny zarządzania projektem może spowodować, że projekt nie będzie w stanie odpowiednio uwzględnić zmian, co spowoduje ignorowanie zmian lub ich nieprawidłowe wdrożenie. Brak doświadczenia w zarządzaniu zasobami ludzkimi może prowadzić do nierozwiązanych konfliktów lub niewłaściwych zleceń pracy.
Metody iteracyjne
Główne metody iteracyjne to RUP (Rational Unified Process) i Agile. Metody te mają iteracyjne podejście do projektowania i rozwoju i zostały tutaj streszczone. Ta metoda powinna uwzględniać zmiany w projekcie wymagane przez dynamiczną firmę. Cykl definiowania, projektowania, tworzenia i testowania wymagań jest wykonywany iteracyjnie, z każdym cyklem trwającym kilka tygodni (czas trwania cykli zależy od metodologii). Iteracyjny rozwój umożliwia zespołowi projektowemu wyciąganie wniosków z wcześniejszych błędów i efektywne wprowadzanie zmian.
Wszystkie metody iteracyjne opierają się na podziale systemu na komponenty, które można projektować, budować, testować i udostępniać. Jedną z zalet tej metody jest możliwość zapewnienia modelu roboczego na wczesnym etapie projektu. Ryzykiem związanym z tą metodą jest ryzyko, że architektura nie obsługuje podziału systemu na komponenty, które można wykazać. Grozi to nieuczeniem się na podstawie błędu, który można znaleźć tylko podczas testowania systemu przez użytkowników.
W iteracyjny rozwój zaangażowany jest kompromis: opracuj podstawową funkcjonalność, którą można zademonstrować w pierwszej kolejności, i opracuj komponent, który zapewnia największą wiedzę. Jeśli wybierzesz podstawową funkcjonalność do opracowania, istnieje ryzyko, że możesz nie dowiedzieć się wystarczająco dużo o rozwijanym systemie do obsługi przyszłych iteracji. Wybór najbardziej złożonego lub najtrudniejszego elementu może stwarzać ryzyko, że system, którego potrzebuje klient, nie zostanie wyprodukowany.
Ryzyko związane z działalnością
Każde działanie w cyklu rozwojowym wiąże się z własnym ryzykiem, niezależnie od wybranej metodologii. Działalność związana z gromadzeniem wymagań wiąże się z następującymi ryzykami: zebrane wymagania mogą być niekompletne, zebrane wymagania mogą być niepoprawne lub wymagania dotyczące gromadzenia czynności mogą potrwać zbyt długo.
Część projektowa cyklu wiąże się z następującymi zagrożeniami: Projekt może nieprawidłowo interpretować wymagania, więc stworzona funkcjonalność nie spełnia wymagań klienta. Projekt można zaprojektować tak, aby kod był bardziej złożony niż to konieczne. Projekt można napisać w taki sposób, że programiści nie mogą opracować poprawnie działającego kodu. Projekt może być napisany w taki sposób, aby nie był jasny lub trudny do naśladowania, wymagał więcej pytań lub ryzykowałby słabą implementacją. Może istnieć wiele faz projektowania, od specyfikacji handlowej do szczegółowego dokumentu projektowego. Interpretacja wymagań na każdym etapie naraża określone wymagania na błędną interpretację.
Programiści mogą błędnie interpretować specyfikacje, nawet jeśli są idealnie napisane, co grozi opracowaniem aplikacji, która nie spełnia wymagań. Testy urządzenia, funkcji i systemu mogą być wadliwe i powodować błędy w środowisku kontroli jakości, co wymaga dodatkowego czasu. Różni programiści mogą różnie interpretować tę samą specyfikację podczas opracowywania modułów lub funkcji, które muszą ze sobą współpracować. Na przykład sekcja specyfikacji funkcji może obsługiwać zarówno wejście jednego modułu, jak i wyjście innego modułu, które są przekazywane dwóm różnym programistom w celu opracowania. Istnieje ryzyko, że rozbieżność nie zostanie znaleziona, dopóki oprogramowanie nie zostanie zintegrowane i system nie zostanie przetestowany.
Testowanie tutaj odnosi się do testów zapewnienia jakości i testów akceptacyjnych użytkownika. Chociaż te dwie czynności różnią się z perspektywy testera, są one wystarczająco podobne, aby podsumować dla naszych celów. Rzeczywisty wysiłek testowy może przekroczyć planowany wysiłek z powodu liczby znalezionych błędów. Nadmierna liczba błędów wykrytych podczas testowania prowadzi do nadmiernej przeróbki i ponownego testowania. Autorzy testów mogą interpretować specyfikacje, z którymi pracują inaczej niż analitycy, programiści lub klienci. Testerzy akceptacji użytkowników pochodzą ze świata biznesu i dlatego są narażeni na ryzyko związane z ograniczeniem lub wykluczeniem wymagań biznesowych.
Specjaliści (MŚP)
W oparciu o swoją wiedzę eksperci merytoryczni są kluczem do sukcesu projektu. Specjaliści mogą wnosić wkład we wszystkie obszary projektu, ale są szczególnie ważne przy gromadzeniu wymagań, analizie wniosków o zmianę, analizie biznesowej, identyfikacji ryzyka, analizie ryzyka i testowaniu. Główne ryzyko dla MŚP polega na tym, że klucz MŚP dla twojego projektu może nie być dostępny, jeśli zostanie obiecany. Jest to szczególnie szkodliwe, jeśli MŚP jest odpowiedzialne za wynik na ścieżce krytycznej.
Warsztaty ryzyka
Warsztaty dotyczące ryzyka są doskonałym narzędziem do identyfikacji ryzyka. Warsztaty mają tę zaletę, że grupa ekspertów jest zgromadzona w jednym pomieszczeniu, dzięki czemu ich wiedza jest dzielona. Rezultatem powinna być identyfikacja ryzyk, których nie wykryto by podczas indywidualnego badania MŚP oraz identyfikacja strategii ograniczania ryzyka, które mogą uwzględniać wiele zdarzeń związanych z ryzykiem.
Porady dotyczące prowadzenia produktywnych warsztatów nie wchodzą w zakres tego artykułu, ale dam ci kilka wskazówek, które pomogą Ci zacząć:
- Zaproś odpowiednie MŚP – musisz uwzględnić wszystkie fazy i działania projektu.
- Przekaż wszystkie szczegóły znanego projektu. Obejmuje to wyniki, kamienie milowe, priorytety itp.
- Uzyskaj aktywne wsparcie od sponsora projektu. W miarę możliwości powinno to obejmować udział w warsztatach.
- Zaproś co najmniej jedno MŚP dla każdego obszaru lub fazy.
- Podziel grupę na podgrupy według obszarów tematycznych lub faz projektu, w których masz dużą liczbę MŚP.
- Upewnij się, że różne grupy lub MŚP informują się wzajemnie o swoim ryzyku, aby promować nowe perspektywy w swoich obszarach.
Warsztaty ryzyka nie kończą się na identyfikacji ryzyk. Należy je przeanalizować, skompilować, ocenić pod kątem prawdopodobieństwa i wpływu oraz opracować strategie ograniczania lub unikania szkód.
Ankiety
Ankiety lub ankiety są akceptowalną alternatywą dla warsztatów ryzyka, w których eksperci w danej dziedzinie nie spotykają się. Jednak brak synergii, którą otrzymujesz podczas warsztatów, musi zostać zrekompensowany przez Ciebie. Musisz podać specjalistom, których zidentyfikujesz na początku ćwiczenia, wszelkie informacje, które mogą być pomocne. Gdy to zrobisz, możesz wysłać formularze do MŚP, które rejestrują zdarzenia ryzyka, źródło ryzyka i wpływ zdarzenia ryzyka na cele projektu.
Zbieraj ryzyka po ich otrzymaniu i szukaj zdarzeń ryzyka, które są albo różnymi podejściami do opisu tego samego ryzyka, w które można połączyć dwa zdarzenia ryzyka lub które można rozwiązać za pomocą tej samej strategii ograniczania ryzyka .
Brak uczestnictwa jest kolejną wadą ankiety lub metody badania. Być może będziesz w stanie dogadać się z jednym MŚP w fazie projektu lub temacie, ale będziesz musiał wyśledzić niechętnych współpracowników. Nie wahaj się poprosić sponsora projektu o pomoc w osiągnięciu wymaganego udziału. Możesz nawet poprosić ich, aby najpierw wysłali zaproszenia i ankiety.
Spotkania zespołu
Do tej pory wszystkie omówione przez nas źródła zidentyfikowanego ryzyka były związane z fazą planowania projektu. Jeśli zostanie to właściwie wykonane podczas fazy planowania, możesz skompletować wyczerpującą listę ryzyk. Jednak odzwierciedlają one ryzyko dla wcześniejszych faz projektu bardziej niż dla późniejszych. Po utworzeniu pierwszego rejestru ryzyka należy aktualizować ten dokument, aby dowiedzieć się więcej o projekcie wykonując pracę, a ryzyko staje się nieaktualne, ponieważ praca zagrożona została zakończona.
Spotkania zespołu są idealnym miejscem do aktualizacji rejestru ryzyka. Problemy pojawiające się podczas omawiania przez zespół postępów w zakresie osiągania wyników często wiążą się z ryzykiem niedotrzymania terminów osiągnięcia wyniku. Możesz zaplanować część przeglądu wpływu i oceny prawdopodobieństwa istniejących zagrożeń, aby określić wpływ, jaki miał na nich tydzień. Powinieneś również monitorować zespół pod kątem nowych zagrożeń, które może zidentyfikować. Ryzyka, które pozostały niezauważone podczas planowania pracy po raz pierwszy, mogą ujawnić się w miarę zbliżania się daty rozpoczęcia pracy lub więcej informacji na temat pracy. Projekt może zidentyfikować nowe prace, jeśli zostaną przeprowadzone zaplanowane prace, które nie zostały uwzględnione przy pierwszej identyfikacji ryzyka.
Możesz przeprowadzić osobne spotkania poświęcone strategii ryzyka z MŚP, jeśli zespół nie jest wystarczająco zaznajomiony z ryzykiem związanym z projektem, aby aktywnie uczestniczyć w bieżącym rejestrze ryzyka. Powinieneś stosować to podejście oprócz spotkań zespołu, jeśli projekt rozwoju oprogramowania jest wystarczająco duży, aby wymagać podprojektów. Przejrzyj każde aktywne ryzyko w rejestrze i przeanalizuj je pod kątem wpływu czasu na rejestr. W miarę zbliżania się do pracy prawdopodobieństwo zdarzenia i / lub wpływu ryzyka zwykle wzrasta. Im więcej pracy zostanie zrobione, prawdopodobieństwo i wpływ będą się zmniejszać.
Powinieneś monitorować plan projektu pod kątem ukończonych prac. Ryzyko dla właśnie zakończonej pracy jest nieaktualne i nie powinno już być częścią dyskusji na temat prawdopodobieństwa i wpływu ryzyka.
[ff id=”3″]