{"id":247,"date":"2022-01-25T10:25:00","date_gmt":"2022-01-25T10:25:00","guid":{"rendered":"https:\/\/www.cybermedian.com\/pl\/?p=247"},"modified":"2025-02-19T17:36:49","modified_gmt":"2025-02-19T09:36:49","slug":"why-scrum-defined-process-vs-empirical-process","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/pl\/why-scrum-defined-process-vs-empirical-process\/","title":{"rendered":"Dlaczego Scrum: Zdefiniowany proces vs Proces empiryczny"},"content":{"rendered":"

Istniej\u0105 projekty, kt\u00f3re s\u0105 do\u015b\u0107 proste i wzgl\u0119dnie przewidywalne, gdzie mo\u017cna zastosowa\u0107 racjonalne narz\u0119dzia planowania i podejmowania decyzji. Inne projekty, kt\u00f3re s\u0105 bardziej z\u0142o\u017cone lub nieprzewidywalne, wymagaj\u0105 innego podej\u015bcia, opieraj\u0105cego si\u0119 bardziej na samoorganizacji i innowacjach.<\/p>\n

Wi\u0119kszo\u015b\u0107 projekt\u00f3w dotycz\u0105cych oprogramowania uwa\u017ca si\u0119 za z\u0142o\u017cone i nieprzewidywalne z powodu zbiegu trzech czynnik\u00f3w: ludzi, wymaga\u0144 i technologii. R\u00f3\u017cne podej\u015bcia stosowane do realizacji i zarz\u0105dzania projektami mo\u017cna \u0142atwiej zrozumie\u0107 w kontek\u015bcie modeli kontroli proces\u00f3w i z\u0142o\u017cono\u015bci projekt\u00f3w.<\/p>\n

Typy Kontroli Proces\u00f3w<\/figcaption><\/figure>\n

Zdefiniowany Proces\u200a\u2014\u200aTradycyjne Podej\u015bcie Sterowane Planem<\/strong><\/p>\n

Tradycyjnie, po rozpocz\u0119ciu projektu tworzony jest pakiet wymaga\u0144, a nast\u0119pnie jest \u201ezaakceptowany\u201d. Kierownik projektu zak\u0142ada, \u017ce ta akceptacja oznacza ustalony zestaw wymaga\u0144 i \u017ce teraz mo\u017cna rozpocz\u0105\u0107 planowanie. Kierownik projektu szacuje, jak d\u0142ugo zajmie spe\u0142nienie wymaga\u0144 i tworzy plan projektu. Plan przewiduje, \u017ce projekt zostanie uko\u0144czony do okre\u015blonej daty, a ta data jest komunikowana klientowi.<\/p>\n

Podstawowy b\u0142\u0105d w tym podej\u015bciu polega na tym, \u017ce plan, kt\u00f3ry nap\u0119dza wszystko, opiera si\u0119 na za\u0142o\u017ceniu, \u017ce wymagania s\u0105 ustalone i nie ulegn\u0105 zmianie. Do\u015bwiadczenie pokazuje, \u017ce nigdy tak nie jest; wymagania nigdy nie s\u0105 ustalone\u200a\u2014\u200azawsze si\u0119 zmieniaj\u0105. Gdy wymagania ulegaj\u0105 zmianie, plan jest dotkni\u0119ty; w rezultacie data zako\u0144czenia musi si\u0119 r\u00f3wnie\u017c zmieni\u0107. Niestety, w wielu przypadkach jest to niemo\u017cliwe, a zesp\u00f3\u0142 musi dostarczy\u0107 projekt do daty, na kt\u00f3r\u0105 si\u0119 zobowi\u0105za\u0142. Wtedy nast\u0119puje powa\u017cny kryzys, a projekt zaczyna wymyka\u0107 si\u0119 spod kontroli.<\/p>\n

Proces Empiryczny\u200a\u2014\u200aZwinne Podej\u015bcie Sterowane Warto\u015bci\u0105<\/strong><\/p>\n

Zwinne podej\u015bcie sterowane warto\u015bci\u0105 opiera si\u0119 na\u00a0empiryzmie<\/strong>, kt\u00f3ry zmienia ca\u0142e my\u015blenie. Od samego pocz\u0105tku zak\u0142ada, \u017ce jakiekolwiek wymagania istniej\u0105ce na pocz\u0105tku nie s\u0105 ustalone i \u017ce ulegn\u0105 zmianie.<\/p>\n

Zwinne my\u015blenie zak\u0142ada r\u00f3wnie\u017c, \u017ce trzeba dostarczy\u0107 projekt do okre\u015blonej daty. To podej\u015bcie ustala czas i zasoby, pozostawiaj\u0105c wymagania nieokre\u015blone. Dla nas to podej\u015bcie bardziej przypomina rzeczywisto\u015b\u0107 tworzenia oprogramowania. Teraz ca\u0142e poj\u0119cie sterowania warto\u015bci\u0105 ma doskona\u0142y sens. Kiedy masz ustalony czas, w kt\u00f3rym nie jeste\u015b pewien, czy zdo\u0142asz dostarczy\u0107 wszystkie wymagania (poniewa\u017c si\u0119 zmieni\u0105 i tym samym czas potrzebny na ich zrealizowanie), naturaln\u0105 reakcj\u0105 jest ustalenie priorytet\u00f3w wymaga\u0144 i najpierw zrealizowanie tych, kt\u00f3re dodaj\u0105 najwi\u0119ksz\u0105 warto\u015b\u0107 dla klienta.<\/p>\n

Mo\u017cesz my\u015ble\u0107: \u201eA co z wymaganiami, kt\u00f3re nie zostan\u0105 zrealizowane do daty dostarczenia?\u201d To jest pow\u00f3d, dla kt\u00f3rego stosuje si\u0119 podej\u015bcie sterowane warto\u015bci\u0105. Uznajesz fakt, \u017ce nie wszystkie wymagania zostan\u0105 zrealizowane do daty dostarczenia. Wa\u017cne pytanie brzmi: czy dostarczono wystarczaj\u0105co funkcji, aby wspiera\u0107 system, kt\u00f3ry dostarcza warto\u015b\u0107 klientowi.<\/p>\n

Wska\u017anik Niepowodze\u0144 Projekt\u00f3w Oprogramowania<\/strong><\/p>\n

Raport CHAOS na rok 2015 zosta\u0142 niedawno opublikowany przez\u00a0Standish Group<\/a>. Raporty CHAOS s\u0105 publikowane co roku od 1994 roku i stanowi\u0105 przekr\u00f3j stanu przemys\u0142u oprogramowania. W tym roku raport bada\u0142 50 000 projekt\u00f3w na ca\u0142ym \u015bwiecie, od niewielkich ulepsze\u0144 po ogromne implementacje przebudowy system\u00f3w. W tym roku raport zawiera rozszerzon\u0105 definicj\u0119 sukcesu, uwzgl\u0119dniaj\u0105c kilka dodatkowych czynnik\u00f3w, kt\u00f3re by\u0142y omawiane w poprzednich badaniach.<\/p>\n

Wyniki wskazuj\u0105, \u017ce nadal jest wiele do zrobienia w celu osi\u0105gni\u0119cia sukces\u00f3w w projektach dotycz\u0105cych oprogramowania. Poni\u017csza tabela podsumowuje wyniki projekt\u00f3w z ostatnich pi\u0119ciu lat, wykorzystuj\u0105c now\u0105 definicj\u0119 czynnik\u00f3w sukcesu (w terminie, w bud\u017cecie z zadowalaj\u0105cym wynikiem).<\/p>\n

Wska\u017anik Niepowodze\u0144 Projekt\u00f3w Oprogramowania<\/figcaption><\/figure>\n

Dzi\u0119ki zastosowaniu metod zwinnego rozwoju oprogramowania w ostatnich latach mo\u017cliwe by\u0142o por\u00f3wnanie wynik\u00f3w projekt\u00f3w mi\u0119dzy zwinno\u015bci\u0105 a tradycyjnymi projektami wodospadowymi. We wszystkich rozmiarach projekt\u00f3w podej\u015bcia zwinne dawa\u0142y wi\u0119cej sukces\u00f3w i mniej ca\u0142kowitych niepowodze\u0144, jak pokazuje poni\u017csza tabela<\/p>\n

<\/figure>\n

Jakie s\u0105 Problemy z Tradycyjnym Podej\u015bciem?<\/strong><\/p>\n

Tradycyjne podej\u015bcie oparte na planie nie jest wadliwe samo w sobie; po prostu nie nadaje si\u0119 do dzisiejszego przemys\u0142u oprogramowania. Podej\u015bcie oparte na planie pierwotnie opiera\u0142o si\u0119 na tradycyjnych koncepcjach zarz\u0105dzania projektami, kt\u00f3re pochodzi\u0142y z bran\u017cy budowlanej. W bran\u017cy budowlanej podej\u015bcie oparte na planie jest odpowiednie: plany, czyli wymagania, s\u0105 ustalone i prawdopodobnie si\u0119 nie zmieni\u0105 podczas budowy. Mo\u017cna oszacowa\u0107, jak d\u0142ugo zajmie budowa stalowych filar\u00f3w, wylewanie betonu itd.<\/p>\n

Pow\u00f3d, dla kt\u00f3rego tradycyjne podej\u015bcie oparte na planie nadaje si\u0119 do bran\u017cy budowlanej, ale nie do bran\u017cy oprogramowania, tkwi w r\u00f3\u017cnicy w sposobie kontrolowania system\u00f3w empirycznych (takich jak tworzenie oprogramowania) i system\u00f3w zdefiniowanych (takich jak budownictwo lub produkcja). Poni\u017csza tabela pokazuje r\u00f3\u017cnice mi\u0119dzy cechami procesu zdefiniowanego a procesu empirycznego.<\/p>\n

Proces Zdefiniowany vs Proces Empiryczny<\/figcaption><\/figure>\n

Po przeczytaniu tabeli \u0142atwo zauwa\u017cy\u0107, \u017ce tworzenie oprogramowania jest zdecydowanie procesem empirycznym, a nie zdefiniowanym. Problem polega na tym, \u017ce przez lata podej\u015bcie do tworzenia oprogramowania traktowano jako proces zdefiniowany\u200a\u2014\u200aa to podej\u015bcie nie dzia\u0142a.<\/p>\n

\u0179r\u00f3d\u0142a<\/h3>\n
    \n
  1. Raport CHAOS Standish Group 2015<\/a><\/li>\n
  2. Becoming Agile in an Imperfect Word\u200a\u2014\u200aautorzy Greg Smith & Ahmed Sidky<\/li>\n<\/ol>\n

    Inne Lektury na Temat Scrum<\/h3>\n