Zbiegły się dwa fakty: gorąca dyskusja na forum na temat umiejętności programistów i przy okazji ich roli w procesie wytwarzania oprogramowania oraz przesyłka z kolejną nową książką na moja półkę. Ale po kolei. Najpierw fazy cyklu wytwarzania oprogramowania a potem kilka uwag. Zakupiona książka opisuje całość, ja tu skupie się na jej wstępie. Nie będę jej tłumaczył a jedynie opisze idee. Zwrócę także uwagę na pewne aspekty związane z dostarczaniem gotowego oprogramowania, np. systemów typu ERP lub ich komponentów.
Fazy procesu tworzenia oprogramowania
Cykl życia projektu tworzenia oprogramowania ma cztery kluczowe fazy:
- Planowanie
- Analiza
- Projektowanie
- Implementacja
Nie należy tego mylić z fazami cyklu życia oprogramowania, doszły by do powyższych jeszcze: wdrożenie, utrzymanie oraz wyłączenie.
Planowanie
Jest to kluczowa faza w projekcie. Na tym etapie należy sobie odpowiedzieć po co tworzymy to oprogramowanie oraz jak ono powstanie. Na tym etapie są (powinny być) znane wyniki analizy biznesowej i studium wykonywalności. Innymi słowy powinna być podjęta decyzja, że oprogramowanie ma powstać. Tu ustala się: czy potrafimy to zrobić, czy projekt ma wartości biznesowe i jakie, czy będzie możliwe użycie oprogramowania jeśli powstanie (np. czy będzie możliwe jest wdrożenie, bo to nie jest takie oczywiste).
Kolejny krok to inicjacja projektu, w szczególności opracowanie harmonogramu. Rozpoczyna się proces zarządzania projektem.
Analiza
Na tym etapie ustala się kto będzie używał systemu, co system ma robić, oraz gdzie i kiedy będzie używany. To tu ma miejsce analiza biznesowa i analiza wymagań. Na tym etapie system zostaje opisany wymaganiami jako czarna skrzynka. Jest to także pierwsza faza projektowania, jej produktem może być model przypadków użycia.
Projektowanie
To pierwsza decyzja o tym, jak system ma to (wymagania użytkownika) robić. Tu powstaje koncepcja wewnętrznej logiki systemu, jego architektura, interfejsy (w tym użytkownika). Obecnie stosuje się metody obiektowe, więc projekt często stanowi abstrakcje, dość dokładna jednak, przyszłego systemu. Abstrakcja ta jest niezależna od metody implementacji jednak musi (powinna) sobą stanowić projekt w obiektowym paradygmacie.
Implementacja
To końcowa faza procesu tworzenia oprogramowania. W ramach niej powstają projekt implementacji i kod, instalacja i testy, opracowywany jest plan pozostałych elementów cyklu życia systemu to jest plan wsparcia i zarządzania oraz rozwoju.
Metodologie tworzenia oprogramowania
Opisane pokrótce fazy procesu tworzenia mogą być ułożone na kilka sposobów. Uznane i opisane w literaturze typowe metodologie można podzielić na trzy grupy:
- strukturalne (metody wodospadowa, równoległa, etapowa)
- szybkie metody (rapid, metoda etapowa, prototypowanie, odrzucane prototypy)
- zwinne (agile, programowanie ekstremalne)
W ramach każdej z tych grup można wyróżnić jedną lub kilka stosowanych metodologii (jak powyżej).
Metodyka wodospadowa
Najstarsza metodyka wytwarzania oprogramowania. Opisane cztery fazy tworzenia realizowane są szeregowo, jedna po drugiej.
Każda faza kończy się swoim produktem (kolejnym elementem dokumentacji). Proces kontynuowany na bazie pierwotnego szczegółowego planu (bez korekt lub z niewielkimi korektami), praktycznie zakłada się, że produkt każdej fazy jest ostateczną wersją dokumentu. System powstaje jako efekt liniowego procesu.
Proces jest dość długotrwały, wymaga bardzo szczegółowego planowania w pierwszej fazie, jest bardzo kosztowny: kosztowne jest planowanie i kosztowne są pomyłki. Można uznać, że od tej prostej wersji metodologii się odchodzi. Metodologia ta cieszy się jednak opinią dobrze zarządzalnej.
Metodologia bazuje na metodach strukturalnych analizy: budowa modelu systemu zorientowanego na dane. Model danych jako fundament systemu czyni go praktycznie niezmiennym podczas całego procesu. System projektowany jest jako układ system-model danych co wymaga bardzo żmudnej pracy na etapie analizy i projektowania. Metodyka ta wymaga także wykonania pełnego projektu systemu przed rozpoczęciem jego implementacji.
Zalety metodyki: wymagania muszą być dokładnie opracowane na długo zanim zacznie się proces implementacji, minimalizacja zmian wymagań w trakcie procesu implementacji.
Wady metodyki: długi proces wytwarzania (znacznie dłuższy niż zachodzące zmiany w otoczeniu biznesowym), wymaga bardzo dużej (setki, bywa tysiące stron) dokumentacji, wprowadzanie zmian wymaga cofnięcia się praktycznie do początku procesu.
Metodyka równoległa
W tej wersji modyfikacja typowego wodospadu polega na podjęciu próby skrócenia całego procesu poprzez podział wymagań (wyników analizy) na odrębne quasi-niezależne podsystemy. Wymaga to dwóch dodatkowych etapów: wstępnego projektu by podzielić system na podsystemy oraz integracji na zakończenie całości.
Korzyścią jakę przynosi podział na podsystemy jest szybsze dostarczenie produktu jednak projekt staje się jeszcze kosztowniejszy. Nadal pozostaje ryzyko nieodwracalności i potrzeby czekania na produkt w wersji ostatecznej.
Zalety i Wady jak w metodyce wodospadowej, osiągnięto pewne skrócenie czasu dostarczenia produktu jednak kosztem dodatkowej dokumentacji. Proces nadal jest praktycznie nieodwracalny.
Metodyka etapowa
Jest to pierwsza próba zamiany potrzeby opracowania kompletnej funkcjonalności na samym początku i szybszego ([[RAD]]) dostarczenia produktu, kosztem ograniczonej początkowo funkcjonalności. Jest to także pierwsza metodyka zakładająca użycia oprogramowania wspomagającego analizę i projektowanie klasy [[CASE]].
Jak widać powstają kolejne wersje systemu. Pierwsza to minimalna przydatna do pracy (użytkownikowi) wersja, kolejne wersje to przybliżenia wersji ostatecznej.
Zaletą tego podejścia jest skrócenie czasu oczekiwania na produkt, użytkownik otrzymuje stosunkowo szybko produkt, zaczyna on zarabiać na siebie. Kolejne wersje implementują kolejne wymagania. Jest to pierwsza próba naprawy wad systemu wodospadowego.
Wadą jest nadal potrzeba początkowego opracowania wszystkich wymagań w wersji ostatecznej, wprowadzanie zmian wymaga cofania się do początku procesu gdyż cały czas ciąży model analizy strukturalnej zamrażającej model systemu w modelu danych.
Wszystkie trzy opisane metody mają więc tę wadę, że wszelkie zmiany wymagań lub odkryte wymagania w trakcie trwania procesu (niewykryte na etapie analizy, źle opracowane) silnie podnoszą koszty gdyż cofają projekt niemalże do początku.
Metodyka prototypowania
Po etapie planowania ma miejsce równoległy proces analizy, projektowania i implementacji. Analiza w tym przypadku jest czymś w rodzaju rozpoznania bojem. W miarę trwania analizy od razu powstaje projekt i implementacja tego co już poznano. Szybko powstaje prototyp, tak zwany szybki i brudny program, który realizuje pierwsze poznane wymagania użytkownika jednak daleko mu do optymalności i jakości. Sponsor projektu lub użytkownik zgłasza zmiany, który są nanoszone na tym prototypie. Po uznaniu, że wymagania zrealizowano prototyp, uzupełniony o wymagane cechy, staje się docelowym produktem.
Zaletą tej metodologii jest bardzo szybki czas dostarczenie najważniejszych funkcjonalniej, wymagania są weryfikowane na bieżąco.
Wada, poważną, tej metodologii jest to, że ostateczny produkt jest zlepkiem pośrednich pomysłów, brak analizy całości (produkt powstaje niemalże ad-hoc) powoduje, że pojawienie się w przyszłości nowych potrzeb często wymaga przeprojektowania znacznej części, a nawet całości systemu.
Metodyka z prototypem odrzucanym
Ta metoda, bazując na poprzedniej, zakłada tworzenie prototypu tylko jak narzędzia analitycznego. Celem tworzenia prototypu nie jest tu rozpoczęcie tworzenia docelowego systemu a testowanie hipotezy jaką jest propozycje projektowa.
W tej wersji po etapie planowania mamy analizę, której celem jest opracowanie wymagań. Następnie równoległy proces analizy, projektowania i implementacji. Tu analiza polega na zrozumieniu wymagań, implementacją jest jednak bardzo uproszczony model systemu (jego konkretne cechy np. tylko interfejs użytkownika). Model ten (np. same mockupy ekranów, elementy logiki) jest testowany. testy tu służą wyłącznie do oceny przydatności pomysłów na etapie analizy i projektowania. testowane modele nie są elementami przyszłego systemu (nie są dalej używane, są wyrzucane).
Jak widać, proces ma trzy wyraźne fazy:
- Planowanie i analiza
- Analiza i projektowanie
- Projektowanie i implementacja
W pewnym sensie dokumentacja przetestowanego prototypu staje dokumentacją wymagań przekazana do ostatecznej zaprojektowania ostatecznej implementacji.
Wadą metody jest potrzeba tworzenia prototypów i testowania każdej koncepcji (wymaga czasu i kompetencji).
Zaletą, bardzo dużą, tej metody jest to, że proste prototypy, które nie są kodem implementacji, są relatywnie tanie w przygotowaniu (mniej pracochłonne niż kod prototypu poprzedniej metody). To pierwsza metodyka zakładająca powstanie prototypu jako testowanej hipotezy (wstępnej decyzji projektowej). Biorąc pod uwagę kosztowne odkrywanie wymagań i wprowadzanie zmian w poprzednich metodykach, ta niweluje ten problem. Jak widać na diagramie, testowanie prototypów ma miejsce na etapie analizy i projektowania. Do implementacji kierowany jest przetestowany projekt. Wersja ostateczna nie zawiera więc w sobie bagażu ad-hoc wprowadzanych zmian – prototypy są odrzucane (nie są elementami docelowego systemu). Można wiec bez problemu zaprojektować system na bazie przetestowanych i spójnych wymagań w przemyślany sposób.
Wadę, potrzebę tworzenia prototypów, niweluje dziś istnienie narzędzi CASE, łatwości tworzenia atrap systemu (prototypów) w graficznych narzędziach projektowania i implementacji. Technologie obiektowe także bardzo ułatwiają ten proces gdyż projekt nie jest uzależniony od modelu danych, w 100% jest funkcjonalnością (modele danych powstają na końcu procesu w metodyka obiektowych).
Poważną wadą poprzednich metodologii jest bardzo kosztowny proces reagowania na zmiany wymagań i niedostatków samego projektu. Pamiętamy, że kompletny projekt powstaje na początku procesu a jego testem jest tak na prawdę dopiero finalny produkt. Praktyka pokazała, że nawet w przypadku średnio złożonych projektów opracowanie systemu pozbawionego wad (głownie logiki i danych) jest niemalże niemożliwe.
Dlatego jeszcze przed rozpoczęciem implementacji tworzony jest i testowany prototyp systemu. Jest to dodatkowy koszt jednak usuwanie usterek projektu na tym etapie jest o rząd a nawet dwa mniej kosztowne niż na etapie ostatecznej implementacji. Jeżeli uznamy fakt, że wersja wodospadowa wiąże się niemalże pewnością odkrycia wad projektu, koszt ten jest wart poniesienia.
Metodyka z odrzucanym prototypem (tak na prawdę prototypami) daje w efekcie bardzo stabilny i spełniajacy oczekiwania system.
Metodyki zwinne – XP
Na koniec metodyki zwinne zwane często [[agile development]]. Są to metodyki ukierunkowane na programowanie (implementację). Przykładami metodyk zwinna są [[SCRUM]], XP ([[extreme programming]]), DSDM ([[dynamic systems development method]]).
Powyżej diagram procesy wytwarzania oprogramowania metodyką XP. Bazuje ona na komunikacji, prostocie, informacji zwrotnej (od klienta) i wzajemnym wsparciu zespołu. Zespołem są tu zarówno programiści jak i przyszły użytkownik (jednak nie sponsor). Proces ten nastawiony jest na szybkie dostarczenie produktu możliwie najprostsza metodą. Bazuje na pełnej integracji zespołu, komunikacji, interaktywnym procesie analizy i projektowania.
W metodykach zwinnych proces tworzenia oprogramowania bazuje na tak zwanych [[user story]], są to opisy aktualnej wiedzy i potrzeb (wymagań) autorstwa przyszłych użytkowników systemu. Proces ten nie ma wyróżnionej fazy planowania całości, gdyż całość dzieje się dynamicznie.
Dla małych systemów silnie zmotywowany, zgrany i doświadczony zespół może pracować wydajnie. Jednakże jeśli projekt nie jest mały, skuteczność tej metodyki pracy staje się wątpliwa. Podzielenie pracy na większy zespół, kontaktorów, wzmaga potrzebę planowania i dokumentowania projektu. Poleganie na opisach przyszłych użytkowników (nie mających doświadczenia w inżynierii oprogramowania) dodatkowo czyni takie projektu ryzykownymi.
Projekty XP wymagają ogromnej dyscypliny, w przeciwnym wypadku prowadzą do chaosu. Konsekwencją braku pełnej początkowej analizy często jest system będący zlepkiem doraźnych, nieudokumentowanych koncepcji, co przy większych projektach czyni tę metodę wyjątkowo ryzykowną. Tezy o dokumentowaniu w kodzie nie sprawdzają się jeśli potrzebna jest wiedza o koncepcji, abstrakcyjnym opisie idei systemu.
Prymat działającego kodu nad jego dokumentowaniem bardzo często prowadzi do bardzo wysokich kosztów utrzymania systemu w przyszłości.
Wadą metodologii jest właśnie jej zwinność, która jeśli sprawdza się, to w nieskomplikowanych projektach serwisów internetowych i oprogramowaniu biznesowych o małej liczbie wymagań rzędu kilku. Jednak jeśli projekt mieści sie w takich granicach jest to bardzo dobry sposób na realizowanie projektów o dużych rygorach czasowych.
Wybór właściwej metodologii
Wśród wymienionych każda ma wady i zalety, wybór najlepszej dla danego projektu nie jest prosty. Do wyboru należy brać pod uwagę znane cechy nadchodzącego projektu.
Jasność wymagań użytkownika. Często wymagania nie są na początku jasne, zrozumiałe, nie raz nie są nawet dobrze udokumentowane. Pierwszym etapem projektu jest nie raz tak na prawdę dopiero odkrycie i zrozumienie celu przyszłego użytkownika. Tu przydaje się dobra analiza biznesowa i prototypowanie.
Innym typem utrudnienia może być nowa technologia. W takim przypadku dotychczasowe doświadczenie zespołu przestaje być wystarczające. W takich przypadkach przydaje się wstępne projektowanie i testowanie hipotez, najlepiej wraz z zatrudnionym ekspertem znającym tę technologię. Prototypy odrzucane doskonale się sprawdzają w takich przypadkach.
Złożone systemy nie nadają się, z powodu swej złożoności, do pracy na bazie intuicji. Wymagają udokumentowanej analizy i projektowania, testowania, gdyż każda pomyłka jest bardzo kosztowna. Systemy tego typu z założenia mają długi cykl życia dlatego przyszłe zarządzanie nim wymaga bardzo dobrze opracowanej dokumentacji.
Systemy wymagające niezawodności i stanowiące (ich wadliwe działanie) duże ryzyko (biznesowe, zagrożenie życia) dla użytkownika także wymagają bardzo dobrego planowania i testowania (błąd w programie niesie za sobą ogromne koszty).
Zdarza się, że krytycznym czynnikiem jest ograniczony czas na wykonanie (np. ograniczony dostęp do zasobów) lub ściśle określony termin oddania produktu do eksploatacji. W obu tych przypadkach projekt już na etapie planowana musi być bardzo przewidywalny.
Poniżej zestawiono opisane metody oraz cechy projektów i czynniki ograniczające ich swobodę.
(powyższy opis na podstawie Systems Analysis and Design with UML Version 2.0, Alan Dennis, Barbara Halley Wixom, David Tegarden, Second edition, John Wiley and Sons, Inc. 2005, USA)
Jak się mają na tym tle gotowe systemy, nie tylko ERP
Gotowy system to dla użytkownika coś co zobaczy i użyje do pracy dopiero po zainstalowaniu i wdrożeniu. Spróbujmy wpasować gotowe oprogramowanie w powyższe procesy. Dlaczego? Bo można założyć, że inicjatorem jest jednak kupujący. Gotowego systemu nie musimy projektować i wytwarzać, więc oszczędzany czas, jednak nie możemy ominąć fazy analizy wymagań gdyż musi istnieć jakieś zamówienie.
Mamy więc plan i opis potrze, pomijamy projektowanie i wytworzenie, otrzymujemy gotowy produkt. Jak widać pierwszym przybliżeniem jest klasyczny wodospad, gdzie pierwszy kontakt użytkownika z systemem ma miejsce dopiero w momencie oddania do użytku! Dlatego, ze analiza wymagań (ich opis) musi być bardzo szczegółowa bo nie ma odwrotu. Jednak nadmierna szczegółowość analizy wymagań prowadzić może do sytuacji gdy okaże się, że żaden produkt na rynku ich nie spełnia naszych wymagań.
Jednak niewątpliwą zaletą jest szybki czas otrzymania gotowego produktu ale pod jednym warunkiem, że spełnia oczekiwania i koło się zamyka.
Nasuwa się wniosek, by zamiast szukać produktu na bazie setek a nawet tysięcy drobnych funkcjonalności, pójść w kierunku wartości biznesowych. Oznacza to, że godząc się na zmianę pewnych nawyków pracy (np. pewne czynności będą wykonywane inaczej) uzyskamy narzędzie wspierające cele same w sobie np. system ma pomagać wystawiać faktury VAT ale to w jaki sposób to robi może być przedmiotem kompromisu. Produkty różnych producentów się różnią między sobą, liczba cech dużego zintegrowanego systemu idzie w tysiące. Im więcej cech tym trudniej osiągnąc kompromis, im większy kompromis tym mniej spełnionych wymagań. Wydaje się więc, że należy zmniejszyć wielość poszukiwanego systemu. Łatwiej wybrać kilka dedykowanych niż jeden uniwersalnych. Koszt integracji? Owszem ale otrzymujemy to co jest potrzebne a nie coś co tylko to przypomina.
Pojawia się w ofercie dostawcy hasło kastomizacja. Cóż to takiego? To wprowadzanie zmian do dostarczonego gotowego, dużego systemu. Znowu ten pierwotny, kosztowny wodospad.
Wydaj się wiec, że optymalnych sposobem jest:
- Zaplanowanie projektu
- Analiza
- Projektowanie logiki systemu i testowanie prototypów tej logiki czy dobrze została zaprojektowana
- Opisanie projektu, podzielenie go na spójne obszary (komponenty)
- Wybór metody dalszego postępowania dla każdego komponentu
Tak więc nasuwa się metodyka łącząca metodologie prototypu traconego na etapie analizy i projektowania oraz równoległą na etapie wytwarzania i dostarczania.
Opisany prze Pana faza “planowania” wskazuje na to, że wyniki analizy biznesowej powinna być znana na etapie planowania i ten pogląd również stosuję w praktyce. Jednak w opisie kolejnej fazy “Analiza” napisano, że ma w tym etapie miejsce (znowu) “Analiza biznesowa”. Czy argumentuje Pan wykonywanie drugiej analizy biznesowej? A możne chodzi o analizę procesów biznesowych? Proszę o wyjaśnienie.
Na etapie planowania powinien być znany (poznany) model biznesowy i cele biznesowe sponsora projektu wraz z ich miernikami. Analiza biznesowa to analiza i modelowanie procesów biznesowych oraz taksonomii. Faktem jest, że pojęcie “analizy biznesowej” nie posiada ścisłej definicji dlatego faktycznie nie raz bezpieczniej jest posługiwać się definicją tego co powstanie (produktem danej analizy). Jednak najważniejsze jest by modele procesów i taksonomia były wykonane z pomocą formalnych notacji. Modelowanie metodami nieformalnymi (lub łamanie zasad sformalizowanej notacji) najczęściej prowadzi do diagramów, których jakość nie odbiega wiele od tekstowego opisu… Dobre modele to nie zastąpienie tekstu jakimiś symbolami a zastąpienie niejednoznacznego tekstu ściśle zdefiniowanymi symbolami i ich złożeniami (konstrukcjami) mającymi proste i zarazem jednoznaczne znaczenia.
W szczególności w przypadku technik zwinnych następuje powtarzalność etapu analizy biznesowej, ale na różnym poziomie szczegółowości. Na początku określana jest lista wymagań (“wiemy co chcemy”), a potem określając zakres wymagań dla danego przebiegu (“wiemy, co teraz robimy”), wymagania mogą zostać uszczegóławiane w sposób pozwalający na realizację danej części systemu. Jest wiele technik pozwalających na usprawnienie tego procesu.
Wadą wielu metod, tych zwinnych w szczególności, jest zaczynanie od “wiemy co chcemy” i kolejne podejścia do tematu, a praktyka pokazuje, że najczęściej “nie wiemy czeto chcemy” i należy to porządnie zbadać. Odkrywanie wymagań metodą kolejnych przybliżeń prototypu kodu jest bardzo kosztowne i czasochłonne. Tu próbka sposobu rozwiązania tego problemu: https://it-consulting.pl/2020/12/11/analiza-biznesowa-od-zlecenia-do-kompletnego-projektu-technicznego-z-uzyciem-narzedzia-case/
Kluczowe etapy powinny być jednak wodospadem (cofanie się do analizy jest najkosztowniejsze w każdym projekcie), dlatego wskazałem proces z prototypem odrzucanym jako najefektywniejszy kompromis – przy założeniu że prototypy to jednak modele a nie kod.
W Scrumie początek i koniec projektu są dobrze zdefiniowanymi procesami – czyli właśnie wodospadami. Na początku ma miejsce w szczególności właśnie analiza oraz high-level design.
W SCRUM’ie mnie “boli” to, że praca projektowa cały czas w zasadzie odbywa się “na kodzie” czyli pracuje kosztowny zasób “zespół programistów”, w metodykach, o których ja piszę (i jestem orędownikiem), weryfikacja poprawności projektu ma miejsce na modelach, i nie jest tu modelem kod (nawet uproszczony) a diagramy z logiką systemu a to testuje jedna osoba. Do tego wykonanie diagramu zajmuje o wiele mniej czasu niż napisanie odpowiadającego mu kodu. Po drugie nieformalne “historyjki” są nieweryfikowalne, ich sens lub brak sensu wyjdzie dopiero przy kolejnym “sprincie”… to kosztuje…
W pewnej klasie projektów dających się “ogarnąć” kilkoma nieskomplikowanymi przypadkami użycia SCRUM się sprawdza, jednak wraz ze wzrostem złożoności jest kosztowny…
w scrumie powstają wszystkie modele jakie mogą powstać w tradycyjnym modelu. jest tam jak najbardziej miejsce dla analityka.
przed rozpoczęciem sprintów ma miejsce pełna analiza, jej testowanie itp – taka jaka jest promowana na tym blogu, ponieważ początek i koniec projektu w scrumie jest dobrze zdefiniowanym procesem. jeśli projekt jest złożony to czas analizy się wydłuża tak jak jest tutaj napisane a sprinty się nie zaczynają.
ciekawe jest to, co się dzieje dalej. w przypadku scruma po pierwszym sprincie modele powinny być aktualizowane zgodnie z informacją zwrotną od klienta. w przypadku o którym piszesz, model idzie do kosza. pytanie co lepsze.
dużo rzeczy napisanych o scrum jest niestety nieprawdziwych. nie można tak tendencyjnie przedstawiać swoich poglądów kosztem innych. najgorsze jest to, że ktoś młody i niedoświadczony może to przyjąć za prawdę.
Najdziwniejsze w tym wszystkim jest to, że np. o SCRUM mam informacje głównie z literatury na temat metodyk zwinnych. Osobiście brałem udział w jednym projekcie, o którym kierownik projektu poważnie mówił, że “to SCRUM”. Jednak nie chodzi tu o to czy to czysty SCRUM czy nie a o to, że w metodykach zwinnych opisanych jak powyżej, produkt końcowy nie ma swojej pełnej dokumentacji na początku implementacji. Innymi słowy “powstanie to co powstanie”. Mogę się oczywiście mylić jednak tu bazuje na literaturze, także WIKI (za która nie przepadam ale tworzą ją głownie ludzie od “Agile”). Metodyka, która “promuję” to analiza i testy modeli traconych, jednak tu modelem jest sformalizowany diagram a nie kod. Tak więc po pierwsze, koszt “iteracji” jest nieporównanie mniejszy, po drugie testy robi analityk a więc ten kto ma największą wiedzę o “biznesie klienta” a nie programista. Moim zdaniem metodyki zwinne są doskonałe tam gdzie projekt jest na tyle mało złożony, że mały zespół programistów (lub nawet jeden) “ogarnia” go bez problemu i niektóre testy mogą być nawet przeprowadzone “myślowo” lub tylko “dyskusyjnie”.
ja widziałem projekty na których kierownik i uczestnicy mówili “to scrum” a ze scrumem nie miało nic wspólnego 🙂 jeśli o takich jest tu pisane, to nie dziwię się błędnym wnioskom.
nie dziwię się, że idea scruma jest tutaj źle pojmowana bo spotkałem bardzo wielu developerów i pm’ów, którzy promowali podobne pomysły a teoretycznie mieli w tym praktykę.
jak pisałem, przed rozpoczęciem sprintów ma miejsce pełna analiza i powstaje dokumentacja. pisanie, że w scrumie dokumentacja jest kodem to jakaś pomyłka.
proponuję sobie przeczytać zamiast wiki coś u źródeł:
jest tam napisane w szczególności:
“Perform domain analysis to the extent required to build, enhance, or update the
domain models to reflect the new system context and requirements.”
wstaw tu jakiś sensowny link z opisem SCRUM, bo faktycznie chyba jest za bardzo kojarzony z XP….
Czym się różni WDROŻENIE od IMPLENTACJI?
Myślałam że to to samo….
“Cykl życia projektu tworzenia oprogramowania ma cztery kluczowe fazy:
Planowanie
Analiza
Projektowanie
Implementacja
Nie należy tego mylić z fazami cyklu życia oprogramowania, doszły by do powyższych jeszcze: wdrożenie, utrzymanie oraz wyłączenie.”
Jeżeli oprogramowanie nie istnieje, zostanie zaprojektowane i przekazane developerowi, który wykona implementację czyli powstanie działający kod. Powstałe działające oprogramowanie, zostanie wdrożone w firmie, czyli pracownicy firmy nauczą się go używać i zaczną stosować w pracy.
Polecam ciekawy wpis na zbliżony temat:
“In sum, for greater responsiveness and a higher benefits realization ratio, ?product-mode? is a more effective way of working than projects.”
https://martinfowler.com/articles/products-over-projects.html#ChallengesOfOperatingInProduct-mode