Jest wiele sposobów prowadzenia projektu i analizy. Mamy do wyboru mnóstwo dobrych praktyk. Czesto jednak wychodzi wielka improwizacja. Przedstawiam dwie moje ulubione:) Nie znamy dobrych praktych czy po prostu lubimy dreszczyk projektów bez trzymanki? 😉
Poniżej wybrane trzy modele cyklu wytwarzania oprogramowania: model kaskadowy (klasyczny, wodospad, ang. waterfall), spiralny i przyrostowy.
Model kaskadowy (zwany też klasycznym cyklem życia oprogramowania) zakłada, że każda z faz następuje po zakończeniu poprzedniej. Taka pojedyncza sekwencja doprowadza do końca projektu i utrzymania systemu.
Taki sposób pracy wprowadza systematykę. Wszystko ma ręce i nogi. Rozpoczynając kolejną fazę mamy wszystko, co nam potrzebne do jej przeprowadzenia – np. projektując system znamy już wymagania pozyskane w czasie analizy.
Jest to dobry sposób na systemy, w których od początku wiemy, co powinno powstać (np. regulowane przepisami, wpierające organizację, której struktura szybko się nie zmienia) lub są duże wymagania bezpieczeństwa systemu (potrzebne dobre zaplanowanie). Jeśli jednak wymagania mogą się często zmieniać w trakcie projektu (np. produkty wymyślane przez klienta), lepiej wybrać inną metodę i częściej pokazywać klientowi efekty pracy niż raz i to po zakończeniu 🙂
Model spiralny zakłada kilka cykli przechodzenia przez fazy projektu. Po planowaniu i analizie bada się ryzyko, następnie konstruuje rozwiązanie i przedstawia klientowi do oceny. W tym ostatnim etapie klient zgłasza uwagi, które stają się podstawą do rozpoczęcia kolejnego cyklu i lepszego dopasowania rozwiązania do jego potrzeb.
Taki sposób pracy zmniejsza ryzyko dalekiego odejścia od oczekiwań klienta. Dobrze nadaje się do systemów, w których zakres nie jest dobrze znany na początku (wiele pomysłów), od jakości i bezpieczeństwa rozwiązania ważniejsze jest jego dopasowanie do potrzeb.
Model przyrostowy zakłada wstępne planowanie projektu, analizę i ogólny projekt architektury, a następnie wprowadzanie kolejnych części systemu. Na początku ustalamy zarys rozwiązania, a później doprecyzowujemy, wykonujemy i przekazujemy klientowi. Pozwala to skupić się na mniejszej części i skupić się dokładniej:)
Zaletami tego podejścia jest uniknięcie tworzenia 10000-stronicowego dokumentu z ustaleniami na początku. Dzięki podziałowi pracy można dodawać nowe funkcje, każdą część wytwarzać oddzielnie (później lub przez inny zespół), dokładniej testować skupiając się na małym wycinku, przekazywać już coś klientowi i nie denerwować go długim oczekiwaniem. Wymogiem jest możliwość podziału rozwiązania na niezależne części.
Można też łączyć metody i działać np. przyrostowo-ewolucyjnie 😉
Jak widać jest wiele sposobów prowadzenia projektu i przeprowadzania analizy, choć nie wspomniałam nawet o innych modelach, metodykach, itd. Często jednak wybierana jest inna droga…
Niekiedy w imię oszczędności analiza wykonywana jest w “1 dzień”. Poniżej obrazek wzięty od J. Żelińskiego z dyskusji na Golden Line. Przedstawia on wyniki badań IBM na temat skutków krótkiej analizy w projekcie i kosztowną pętlę odkrywania wymagań.
Moim “ulubionym” modelem jest jednak ten. Zakłada on zrównoleglenie prac. Żeby zaoszczędzić czas i wykorzystać zasoby, przed zakończeniem analizy rozpoczyna się wykonanie (implementacja). Trwa ona równolegle z projektowaniem (o ile ono występuje) oraz wdrożeniem, a nawet po zakończeniu wdrożenia (dostrzeżone problemy jeszcze się naprawia) 😉
Taki styl pracy powoduje, że rozpoczyna się implementację z mglistym pojęciem, brakiem konkretów lub konkretami, które nie są potwierdzone i mogą się zmienić. Często w trakcie projektu wychodzą jednak zmiany, które okazują się burzyć programistyczne struktury. Konieczne jest wtedy budowanie obejść, łatek i konstrukcji tak misternych, że sami twórcy zaczynają się w nich gubić i raczej nie wykorzystają ich w przyszłości, bo mogłoby to przysporzyć więcej problemów niż oszczędności.
Głównymi zaletami dwóch ostatnich modeli jest to, że nie pozwalają zespołowi programistycznemu pozostawać w bezczynności. Zapewniają one dużo zadań zarówno podczas wytwarzania jak i po przekazaniu systemu.
Zdarzyło mi się widzieć nie jeden projekt improwizowany, który dzięki swojej „swobodności” stał się tworem trudnym do okiełznania przez kierowników projektów, a dla realizujących doświadczeniem, o którym woleliby zapomnieć i się lepiej pod tym nie podpisywać swoim nazwiskiem. Z kolei nigdy nie spotkałam kogoś, kto wykorzystał dobre praktyki i metodykę i postanowił wrócić do metod improwizowanych. Wiele osób stało się gorącymi zwolennikami np. Scruma po projektach, w których brali udział z jego wykorzystaniem.
Lubisz jazdę bez trzymanki? Czy Twoi ludzie podzielają to wrażenie siedząc jako pasażerowie takiego projektu?
A może spróbujesz dobrych praktyk i zbudujesz coś, czym można się chwalić zarówno innym programistom jak i zadowolonemu klientowi?
Źródła:
1. Bobkowska A., Jarzębowicz A., Szejko S. (2009): Inżynieria oprogramowania, Niepublikowane materiały, Politechnika Gdańska.
Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.
Tomasz
Jaka jest główna różnica pomiędzy modelem spiralnym i przyrostowym?
Hania
No w spiralnym robisz cały system i zmieniasz go po uwagach, a w przyrostowym robisz kolejne części systemu i nie wracasz do zakończonych.
Kamil
Model spiralny zakłada powtarzanie cyklu na całym projekcie, model przyrostowy zakłada powtarzanie cyklu na kolejnych niezależnych częściach systemu.
Ostatni model jest również moim “ulubionym” 😉
Niezapomniane wspomnienia ze szpachlowania systemu gwarantowane.
Może zaciekawi Cię także:
Zmiany w certyfikacie ECBA IIBA
Zobacz co IIBA zmienia w zakresie egzaminu ECBA. Co to oznacza dla z zdających? Kiedy zmiany wchodzą w życie? Skąd
Kurs Analiza w 7 krokach
Badania pokazują, że jedną z najczęstszych przyczyn porażek projektów są problemy z wymaganiami. Mimo wielu lat doświadczeń w branży, wciąż nie
Książki o analizie biznesowej i nie tylko
Na goodreads zebrałam książki, które przeczytałam lub chcę przeczytać. Zajrzyj, może któraś Cię zaciekawi. Podziel się swoimi wrażeniami. Poleć coś
FAQ
Najczęściej zadawane przez Was pytania 🙂 Odpowiedzi w jednym miejscu. Masz inne pytanie? Dodaj w komentarzu 🙂 Jestem X. Mam
aw3m #006 Przekwalifikowanie na/z Scrum Mastera, Product Ownera, testera, itp.
“Scrum Master, Product Owner, PM, Tester – kto najlepiej sprawdzi się w roli Analityka? I odwrotnie, jakie rolę może sprawnie
Czy da się przekwalifikować na analityka spoza IT – historia Natalii
Masz za sobą parę lat przepracowanych w różnych firmach i na różnych stanowiskach. Dziś postanawiasz, że pójdziesz do świata IT,
NA004: Jak zdobyć pracę analityka biznesowego?
Jak zdobyć pracę analityka biznesowego? Zbieraj wiedzę i doświadczenie, przygotuj CV, przejdź rozmowę kwalifikacyjną! Wskazówki na każdy z tych etapów –
99 pytań rekrutacyjnych na analityka biznesowego
O co zapytają Cię na rozmowie rekrutacyjnej na analityka biznesowego? Możesz trafić na wiele z tej listy. A może Tobie
NA003: Analiza luk (gap analysis) z Michałem Wolskim
Analiza luk to proste i doskonałe narzędzie do usprawniania biznesu i IT. Pokazuje drogę, jaką musimy przebyć od miejsca, gdzie
Młodszy Analityk Biznesowy i Stażysta – staż, wiek, zarobki
W ramach oczekiwania na pełny Raport Zarobków i Kompetencji Analityków Biznesowych 2016, nieco o Młodszych Analitykach i Stażystach w analizie.
13 powodów, żeby nie marnować życia w analizie biznesowej
Do tego wpisu zainspirował mnie jeden z ostatnich artykułów Harvard Business Review. Mówił o tym, że żyjesz mrzonkami, bo nie
Jak zostać analitykiem biznesowym
Olśniło Cię, że ten fascynujący zawód może być dla Ciebie? Tylko jak się do tego zabrać? Od czego zacząć? Jak
Stażyści w analizie – warto czy nie warto?
Czy warto zatrudniać stażystów do prac analitycznych? Wdrożenie młodej osoby w tajniki naszej firmy i samej analizy może być bardzo
5 podstawowych narzędzi każdego analityka
Nawet najlepszy mechanik niewiele będzie w stanie naprawić bez swojej skrzynki z narzędziami. Podobnie jest z pracą analityka. Ilość i
IC, MRP, MRPII, MRPIII, ERP, ERPII, SCM
IC, MRP, MRPII, MRPIII, ERP, ERPII, SCM. Co je łączy? Wszystkie przedstawiają klasy systemów – kompleksowych rozwiązań dla przedsiębiorstw. Co
Ile zarabiają analitycy biznesowi w Polsce?
Ile zarabiają analitycy? Na to pytanie szukają odpowiedzi wchodzący w branżę, zastanawiający się nad wybraniem kierunku specjalizacji jak i starsi
Ile zarabiają analitycy biznesowi w Polsce? (2013)
Ile zarabiają analitycy? Na to pytanie szukają odpowiedzi wchodzący w branżę, zastanawiający się nad wybraniem kierunku specjalizacji jak i starsi
Analityk i UX – dobre rozwiązanie na dwa sposoby
Spotkałeś się kiedyś z User eXperience? Osoba, która zajmuje się UX projektuje doświadczenia użytkownika (user experience), w IT za pomocą
Gdzie się podziali analitycy biznesowi w Polsce?
Jedna z ciekawych konferencji w Trójmieście została odwołana z powodu małego zainteresowania. Patrząc na zestawienia wydarzeń z IT, w Gdańsku,
Nie pracuj dla kogoś. Pracuj dla siebie
Nie chodzi tu o zakładanie własnej firmy. Ani o robienie zleceń pod stołem w czasie pracy. Praca na etacie zajmuje
Certyfikaty dla analityka
Zdobycie certyfikatu czy dyplomu (choć nie gwarantuje, że przyswojone wiadomości dobrze wykorzystasz) daje możliwość zweryfikowania swojej wiedzy i przyrównania jej
Czy Twój system pamięta o swoim powołaniu?
Są systemy, które zapominają o swoim powołaniu. Wprost przeszkadzają w ich używaniu. Skąd się biorą? Powstają wtedy, gdy przestajemy szukać
Do czego Ci przypadki użycia?
Po co są przypadki użycia? Zastanów się nad tym, zanim powiesz “nie, my tego nie potrzebujemy”. Najpierw poznanie potrzeb projektu
Jak znieść trudnego klienta?
Zdarzają się ludzie, którzy już od pierwszego spotkania nie budzą Twojej sympatii. Irytują swoim sposobem bycia albo celowo wyprowadzają z
Dzień kariery i rozwoju w IT – Future3
23 października w Gdańsku odbędzie się Future3, czyli dzień kariery i rozwoju w branży IT. Zapowiada się największa impreza branżowa
Spotkania branżowe w październiku
W październiku obrodziło kilkoma bardzo ciekawymi branżowymi spotkaniami w Trójmieście, na których można spotkać równie ciekawych ludzi z pogranicza dziedziny analizy
Jakim jesteś kierownikiem projektu? A on?
W małych spółkach IT powodzenie firmy ciąży na kierownikach projektów. Zdolni, potrafią zapewnić jej przetrwanie, sukces i dobrobyt. Niezdolni –
Prezentacja z tech.3campa
3 camp i po 3 campie:) Było naprawdę sympatycznie. Dla tych, którzy chcieliby przypomnieć sobie tamte chwile i sjady, wrzucam
Na jakim poziomie jest analiza w Twojej firmie?
Masz już analityka? Super! Ale czy to wystarczy? Przed firmą jeszcze daleka droga, żeby analiza w pełni służyła projektom, żeby
Zapraszam na prezentację na TECH.3CAMP
26 września odbędzie się w Gdyni spotkanie TECH.3CAMP. Będę mówić na nim o trudach i sposobach zbierania wymagań oraz poruszę
Co robi analityk?
Czym zajmuje się analityk? Próbowałam wyjaśnić to znajomym spoza branży i kolegom z IT. Zebrałam odpowiedzi dla różnych poziomów wtajemniczenia
Jak rozmawiać z klientem, który nie wie, czego chce? – recenzja książki
Natknęłam się na genialną książkę o tym, jak rozmawiać z klientem podczas zbierania wymagań do projektu. Powinien przeczytać ją każdy
Jak wygląda analiza i proces wytwarzania?
Jest wiele sposobów prowadzenia projektu i analizy. Mamy do wyboru mnóstwo dobrych praktyk. Czesto jednak wychodzi wielka improwizacja. Przedstawiam dwie
Jak opisywać przypadki użycia?
Przypadki użycia pozwalają nam określić, w jaki sposób użytkownik będzie mógł korzystać z systemu. Diagram umożliwia jednym rzutem oka sprawdzić
Analiza interesariuszy – nie pomiń nikogo!
Jeśli pominiesz ważne osoby, grupy czy organizacje, tracisz źródła wymagań i ryzykujesz, że rozwiązanie nie spełni swojego zadania. Pomoże Ci
Analiza interesariuszy – nie pomiń nikogo!
Problemy z wymaganiami to najczęstsza przyczyna niepowodzeń projektów, a wymagania w dużej mierze pochodzą od interesariuszy. Jako analityk czy kierownik
Czy klient musi wiedzieć, czego chce?
Wspólną bolączką ludzi z branży IT jest fakt, że klient nie wie, czego chce. Przygotowujemy oprogramowanie zgodnie z jego wytycznymi,
Sprint przez metodyki zwinne (agile)
Jeśli agile był do tej pory workiem, do którego wrzucałeś wszystko, co swobodne i nie wymaga zbędnej dokumentacji, zrób w