Odwieczna dyskusja o metodyce

W połowie lat 90. badacze doliczyli się ponad 1000 metodyk rozwoju oprogramowania, opartych na różnych cyklach życia systemu. Liczba ta jest zapewne nawet wyższa, gdyż ewolucja modeli cyklu życia systemu i metodyk rozwoju oprogramowania nadal trwa.

W połowie lat 90. badacze doliczyli się ponad 1000 metodyk rozwoju oprogramowania, opartych na różnych cyklach życia systemu. Liczba ta jest zapewne nawet wyższa, gdyż ewolucja modeli cyklu życia systemu i metodyk rozwoju oprogramowania nadal trwa.

Odwieczna dyskusja o metodyce
Dyskusje o tym, który z modeli cyklu życia systemu najtrafniej oddaje charakter pracy programistów, a także która z metodyk opartych na tych modelach najlepiej sprawdza się podczas realizacji projektów IT, są niemal tak stare, jak pierwsze złożone systemy IT. Od prawie trzydziestu lat badacze starali się uporządkować doświadczenia praktyczne, nadając im postać modeli, od tych najprostszych, takich jak model kaskadowy, poprzez modele ewolucyjny i przyrostowy, aż po bardziej skomplikowane, takie jak model spiralny.

Opracowywanie kolejnych modeli i opartych na nich metodyk doprowadziło do powstania setek mniej lub bardziej dopracowanych metod rozwoju oprogramowania. Jak oszacował Nimal Jayaratna, profesor Manchester Metropolitan University Business School i autor książki "Understanding and Evaluating Methodologies - NIMSAD: A Systemic Framework" przed ponad dziesięciu laty programiści korzystali z ponad 1000 różnych metodologii, z czego aż 80% z nich zostało wykorzystane w mniej niż dziesięciu projektach.

Odwieczna dyskusja o metodyce

Przemysław Gnitecki, Chief Technology Officer w ABG Ster-Projekt

Wiele wskazuje na to, że ewolucja modeli cyklu życia systemu i metodyk rozwoju oprogramowania będzie trwać nadal. "Każdy szef projektu korzysta z modeli i metodyk, które najlepiej przystają do przyjętych celów. Nie można zatem oceniać wypracowanych do tej pory modeli jako lepsze lub gorsze. Można raczej mówić o lepszym lub gorszym dopasowaniu metodyki do realizowanych celów" - mówi Paweł Zawadka, dyrektor ds. rozwoju w firmie ATENA Usługi Informatyczne i Finansowe. Zgadza się z nim Błażej Kotełko, dyrektor ds. oprogramowania w firmie InsERT. "Każda firma powinna dobrać własną metodykę pracy" - mówi.

Na kierunek tej ewolucji mają wpływ co najmniej dwa czynniki. "Przede wszystkim jest to rosnąca wiedza i oczekiwania odbiorców, a więc zamawiających i użytkowników rozwiązań IT. Są oni coraz bardziej świadomi oczekiwań względem przygotowywanych aplikacji" - podkreśla Paweł Zawadka. "Nowoczesne metodyki projektowe akcentują coraz większą współpracę twórców systemu z użytkownikiem oraz podkreślają znaczenie zarządzania zmianami. Dzięki tym elementom systemy coraz lepiej spełniają oczekiwania i potrzeby użytkowników" - dodaje. Zmieniają się przy tym dużo częściej niż technologie stosowane w budownictwie. "Ciekawe, czy dzięki temu zbliżymy się kiedyś poziomem biegłości np. do architektów?" - zastanawia się Błażej Kotełko.

Odwieczna dyskusja o metodyce

Paweł Zawadka, dyrektor ds. rozwoju w ATENA Usługi Informatyczne i Finansowe

Z drugiej strony widać stale rosnący stopień komplikacji projektowanych systemów przy jednoczesnym nacisku na tempo ich przygotowania. "Warto pamiętać o tym, że OS 360 był przygotowywany przez dziesięć lat. Dziś nikt nie może pozwolić sobie na luksus tak długiej pracy nad rozwiązaniem. Nawet jeśli ma do dyspozycji nieporównywalnie więcej środków" - mówi Jan Pieczykolan, odpowiedzialny m.in. za rozwój procesu inżynierii oprogramowania w firmie DRQ.

Wybór nie do końca niezależny

Wybór modelu i metodyki zależy od kilku czynników, przede wszystkim od charakteru realizowanego projektu. "Innych będą używali programiści zatrudnieni w firmie, która przygotowuje system na rynek masowy i decyduje o zakresie funkcjonalnym oraz terminach realizacji poszczególnych faz projektu. Innych zaś specjaliści zajmujący się realizacją systemów na zamówienie" - mówi Zbigniew Gajewski, dyrektor działu badań i rozwoju systemów ERP w Comarchu. Wybór zależy także od rozmiarów zespołu. Inaczej wyglądać będzie model pracy programistów w dużej firmie, w której nad projektem pracuje kilkadziesiąt, a nawet kilkaset osób. Inaczej w małej firmie programistycznej, gdzie - ze względu na brak barier komunikacyjnych - decyzje podejmowane są szybciej, a każdy z członków zespołu ma znacznie większy wpływ na ostateczny kształt projektu.

Odwieczna dyskusja o metodyce

Jan Pieczykolan, odpowiedzialny m.in. za rozwój procesu inżynieriioprogramowania w firmie DRQ

W tym drugim przypadku zarządzający zespołem mogą pozwolić sobie na pewną elastyczność. "Przed przystąpieniem do tworzenia systemu tworzymy ogólny zarys projektu: architekturę bazową oraz podział na moduły" - mówi Marcin Kosieradzki, główny architekt w firmie P2ware zajmującej się rozwojem pakietu wspomagającego zarządzanie projektami. To bardzo istotny element każdego projektu. Pozwala na podział pracy, dalszy rozwój poszczególnych elementów systemu niezależnie od siebie, a także dodawanie lub rezygnowanie z różnych funkcjonalności. "W takim modelu pracy najważniejszy jest odpowiedni podział funkcjonalności na moduły, określenie punktów styku pomiędzy nimi, a także konsekwentne trzymanie się przyjętej architektury" - dodaje.

Oczywiście takie podejście do tworzenia oprogramowania wymaga od pracowników wysokich kwalifikacji i doświadczenia. Istotna jest również samodyscyplina, aby konsekwentnie unikać stosowania rozwiązań na skróty. "Jednym z najważniejszych kryteriów jakości kodu jest jego «utrzymywalność», a więc możliwość dalszego rozwoju. Aby uniknąć kłopotów, wiedzę o tym jak dany kod działa rozpraszamy pomiędzy programistów, chociażby stosując technikę przeglądów kodu - code review" - mówi Marcin Kosieradzki.

W przypadku firm realizujących tzw. systemy pod klucz wybór modelu i metodyki jest związany ze specyfiką zamawiającego. Bardzo silnie zależy od stopnia znajomości zagadnień związanych z implementacją systemów czy ewentualną historią współpracy pomiędzy dostawcą a klientem. "Wciągnięcie klienta w realizację projektu, także jeśli chodzi o metodologię, jest bardzo ważne. Dzięki takiemu działaniu odbiorca systemu zaczyna lepiej rozumieć uwarunkowania związane z realizacją projektu. Ma świadomość, że to co dostaje w postaci systemu, jest wynikiem analiz, a nie tylko naszej nieskrępowanej inwencji" - mówi Przemysław Gnitecki, Chief Technology Officer w ABG Ster-Projekt. Z tego m.in. powodu firma ta szkoli klientów z metodologii, a nawet elementów analizy biznesowej i systemowej.

Jak mówi Przemysław Gnitecki, jego firma stosuje wiele różnych metodyk projektowych. "Tam gdzie problem nie jest nadmiernie złożony, a termin realizacji zadań jest krótki, uciekamy się do różnego rodzaju metodyk lekkich" - przyznaje. "W przypadku zaś gdy współpracujemy z klientem po raz pierwszy, zwykle korzystamy z tradycyjnych metodyk, ze ściśle podzielonymi etapami prac, regularnymi spotkaniami podsumowującymi z klientem" - dodaje. Taki model pracy pozwala na pewną niezależność zespołów. Opóźnienia w jednym z etapów zazwyczaj nie mają dużego wpływu na terminowość zakończenia projektu. Zupełnie inaczej niż w przypadku lekkich metodyk, takich jak Scrum, w których brak przygotowania jednego członka zespołu w znacznie większym stopniu może zaważyć na efekcie pracy grupy.

Umiejętny wybór i kompromis pomiędzy metodami lekkimi i ciężkimi to jeden z czynników ułatwiających terminową realizację projektów. "Warto jednak pamiętać o tym, że metodyki lekkie jedynie nieznacznie różnią się od podejść klasycznych. Bardzo często są to kolejne wersje modelu spiralnego bądź iteracyjnego, z większym zaakcentowaniem roli inżyniera jako twórcy, a nie jedynie wykonawcy. Jest to cenne, gdyż angażując zdolnych ludzi zwiększamy jakość tworzonych rozwiązań i zadowolenie klientów" - przypomina Jan Pieczykolan.

Artykuł powstał na podstawie dyskusji poświęconej ewolucji modeli cyklu życia systemów zorganizowanej przez Computerworld 24 stycznia br. w Warszawie. Partnerem Okrągłego Stołu był Microsoft Polska.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200