Odwieczna dyskusja o metodyce
- Antoni Bielewicz,
- 13.02.2007
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.
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.
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.
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.
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.