Zarządzanie ryzykiem w rozwoju oprogramowania

Zarządzanie ryzykiem to system identyfikacji, rozwiązywania i eliminowania problemów, które mogą być szkodliwe dla kosztów, harmonogramu lub technicznego sukcesu projektu lub dla morale zespołu projektowego.

„Problemy jutra to ryzyka dzisiaj.” Dlatego „ryzyko” jest wyraźnie definiowane jako problem, który może spowodować pewne szkody lub zagrozić harmonogramowi projektu, ale jeszcze się nie zdarzył.

Jeśli nie podejmiesz inicjatywy w zarządzaniu ryzykiem, będziesz musiał stawić czoła ryzyku.

Rozwój oprogramowaniajest działalnością wysokiego ryzyka, a ryzyka mogą występować na każdym etapie procesu rozwoju projektu. Przyjęcie aktywnej metody zarządzania ryzykiem może uczynić proces projektu bardziej stabilnym, uzyskać wysoką zdolność do śledzenia i kontrolowania projektu oraz może unikać i przenosić ryzyka lub łagodzić negatywne skutki ryzyk.

Zarządzanie ryzykiem to proces identyfikacji, analizy, reagowania i monitorowania ryzyk projektowych. Jest to bardzo ważna działalność zarządzająca w zarządzaniu projektami. Skuteczna realizacja zarządzania ryzykiem w oprogramowaniu jest gwarancją płynnego zakończenia rozwoju projektu oprogramowania.

Osiągnięcie zarządzania ryzykiem musi obejmować trzy elementy:

  • Plan zarządzania ryzykiem musi być sformułowany w planie rozwoju projektu;
  • Budżet projektu musi obejmować środki potrzebne do rozwiązania ryzyka;
  • Podczas oceny ryzyka należy również uwzględnić wpływ ryzyka na planowanie projektu.

Porozmawiajmy o tym, jak możemy podjąć działania zapobiegawcze w celu złagodzenia ryzyk, które często występują podczas rozwoju oprogramowania.

  1. Niejasne wymagania— Niejasne wymagania to często napotykane problemy w procesie rozwoju oprogramowania. Takie problemy często manifestują się w wielu aspektach, takich jak nieokreślony zakres wymagań, nieprecyzyjne wymagania, niejasny opis wymagań, brakujące wymagania i sprzeczne wymagania. W cyklu życia procesu rozwoju oprogramowania, marnotrawstwo spowodowane niejasnymi wymaganiami jest największe i musi być rozwiązane jak najszybciej. Bardzo trudno jest określić potrzeby użytkowników.

Działania zapobiegawcze

  • Pozwól użytkownikom uczestniczyć w rozwoju poprzez krótkie i częstsze dyskusje oraz spotkania
  • Opracuj i komunikuj się z interesariuszami, korzystając z prototypów interfejsu użytkownika / makiet

2. W przypadku projektów z szeroką dystrybucją użytkowników i dużą liczbą użytkowników często trudno jest kompleksowo zbierać wymagania użytkowników, a zazwyczaj organizuje się spotkania badawcze w celu potwierdzenia wymagań.

Działania zapobiegawcze

Kilka tygodni przed spotkaniem przeprowadziliśmy badanie potrzeb użytkowników w różnych regionach i działach, a następnie zebraliśmy przedstawicieli użytkowników ze wszystkich regionów lub działów, aby zorganizować seminarium dotyczące wymagań w celu zebrania wymagań podczas spotkania. Ta metoda jest odpowiednia dla użytkowników, którzy mają pewne doświadczenie w IT.

2. Pułapka 80/20— Kiedy kierownik projektu lub programista mówi, że 80% zadania zostało ukończone, musisz być ostrożny. Ponieważ pozostałe 20% może zająć 80% czasu lub może nigdy nie zostać ukończone.

Projekty rozwoju oprogramowania często brakuje widoczności w zakresie postępu projektu i jakości oprogramowania. Im mniej widoczny jest projekt, tym trudniej jest nim zarządzać, a tym bardziej prawdopodobne jest, że zakończy się niepowodzeniem. Możemy zwiększyć widoczność projektu poprzez rozwój iteracyjny, przegląd techniczny i ciągłą integrację.

Działania zapobiegawcze:

  • Rozwój iteracyjny. Korzystając z modelu rozwoju iteracyjnego, proces dostarczania produktu jest podzielony na wiele etapów i dostarczany stopniowo zgodnie z funkcjami.
  • Przegląd techniczny jest ważną częścią zapewnienia jakości oprogramowania. Przegląd techniczny obejmuje przegląd kodu, przegląd spotkań i przegląd rówieśniczy. Przegląd kodu może być przeglądem krzyżowym między programistami lub przeglądem zwykłych programistów przez starszych programistów; Przegląd spotkań odbywa się zazwyczaj co najmniej raz na dwa tygodnie, a czas każdego przeglądu nie powinien być zbyt długi, co jest ważną gwarancją sukcesu projektu.
  • Ciągła integracja może rozproszyć końcowy proces dużej integracji i uruchamiania na tygodniowy i codzienny postęp rozwoju projektu. Dzięki temu każdy w projekcie może w każdej chwili uchwycić aktualny ogólny postęp i szybko znaleźć oraz rozwiązać problemy w procesie integracji.

3. Innowacja technologicznajest eksploracyjną i kreatywną działalnością technologiczną i ekonomiczną. W procesie rozwoju wprowadzenie nowych technologii nieuchronnie napotka różne ryzyka. Środki takie jak rozwój oprogramowania w kształcie litery T oraz prototypowanie z nową technologią z wykorzystaniem historii użytkowników typu spike.

4. Problemy z wydajnością— Z powodu braku wglądu w projektowanie oprogramowania, problemy z wydajnością często ujawniają się po wdrożeniu systemu lub używaniu nowego systemu przez pewien czas. Problemy z wydajnością zazwyczaj wymagają dużej ilości pracy optymalizacyjnej, a nawet częściowego lub kompleksowego przeprojektowania. Ani użytkownicy, ani programiści nie chcą problemów z wydajnością. Zespół musi być świadomy tego problemu, wdrożyć planowanie wydajności i testowanie w całym procesie rozwoju oraz uwzględnić wymagania dotyczące wydajności w wymaganiach niefunkcjonalnych.

5. Problemy z użytecznościąUżyteczność oprogramowania obejmuje wiele czynników, takich jak to, czy oprogramowanie jest wydajne, łatwe do nauczenia, łatwe do zapamiętania, przyjemne i niełatwe do popełnienia błędów. Często z powodu słabej użyteczności oprogramowania użytkownicy są niezadowoleni i nawet eliminowani z rynku. W rozwoju projektu należy zwrócić uwagę na problemy z użytecznością, aby uniknąć ryzyk związanych z użytecznością oprogramowania.

Struktura podziału ryzyka

Możemy użyć struktury podziału ryzyka do klasyfikacji potencjalnego ryzyka w różnych aspektach:

Struktura podziału ryzyka to hierarchiczne rozkładanie ryzyk, zaczynając od elementu węzła głównego, który reprezentuje projekt, a następnie przechodząc do różnych kategorii ryzyka, a następnie do bardziej szczegółowych poziomów ryzyk.

Oprócz przedstawiania ryzyk projektowych w strukturze podziału ryzyka, możliwe jest połączenie użycia legendy kolorów w reprezentacji wpływu ryzyka. Zobacz przykład struktury podziału ryzyka poniżej, legenda wpływu z pięcioma pozycjami została ustawiona, reprezentując pięć poziomów wpływu, jakie ryzyka mogą mieć na projekt, z pięcioma różnymi kodami kolorów.

Oto przykład struktury podziału ryzyka:

Risk Breakdown Structure Example

(Edytuj tę strukturę podziału ryzyka online)

Istnieje wiele narzędzi do zarządzania ryzykiem, które możesz wykorzystać do strukturyzacji ryzyk. Oprócz struktury podziału ryzyka, możesz rozważyć użycieDiagram przyczynowo-skutkowyrównież (znany również jako diagram rybiej ości).

Wnioski

Im wcześniej ryzyko zostanie zidentyfikowane i zarządzane, tym większe prawdopodobieństwo uniknięcia ryzyka lub zmniejszenia jego wpływu, gdy się pojawi. Szczególnie w złożonych projektach z dużą liczbą uczestników projektu, szerokim zakresem zaangażowania i wysoką zawartością techniczną należy to wzmocnić.


Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文

Leave a Reply

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *