Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


26.10.2020

Nowa wersja nVision

Można już pobierać nową wersję nVision
26.10.2020

Monitorowanie infrastruktury

Vertiv Environet Alert
23.10.2020

Telefonia w chmurze

NFON Cloudya
23.10.2020

Nowości w EDR

Bitdefender GravityZone
23.10.2020

Wykrywanie anomalii

Flowmon ADS11
23.10.2020

Mobilny monitor

AOC 16T2
22.10.2020

HP Pavilion

HP zaprezentowało nowe laptopy z linii Pavilion.
22.10.2020

Inteligentny monitoring

WD Purple SC QD101
22.10.2020

Przełącznik 2,5GbE

QNAP QSW-1105-5T

Prawo a zwinne metody tworzenia oprogramowania

Data publikacji: 23-02-2017 Autor: Piotr Grzelczak

Dla wielu firm po obu stronach kontraktowej barykady (a najczęściej wśród dostawców oprogramowania) stosowanie metodologii Agile jest tak naturalne jak oddychanie. Niemniej, rozmawiając o realizacji projektów w tym modelu, często można spotkać znaczny opór ze strony prawników. Co jest tego powodem oraz jakie są zalety stosowania modelu Agile, opisujemy w niniejszym artykule.

Agile to pojęcie zbiorcze, obejmujące tzw. zwinne metody tworzenia oprogramowania, takie jak Scrum, Extreme Programming, DSDM, Crystal Clear i inne. Pojęcie to ukute zostało w 2001 roku wraz z opublikowaniem manifestu Agile (agilemanifesto.org),
który postuluje zmianę akcentów w procesie tworzenia oprogramowania. Twórcy manifestu dostrzegli i uwypuklili znaczenie dla tego procesu takich elementów, jak: interakcje, działające oprogramowanie, współpraca z klientem oraz reagowanie na zmiany. Wymienione elementy są w klasycznym modelu często przysłaniane przez sprawy formalne oraz procesy, narzędzia, dokumentację, kontrakty i plany.

Dlaczego zmiana akcentów jest istotna? Ano dlatego, że tworzenie oprogramowania ma swoją szczególną specyfikę. Technologie informatyczne rozwijają się w błyskawicznym tempie, więc programowanie następuje w bardzo dynamicznym i zmiennym środowisku. Klasyczne podejście inżynierskie, pasujące idealnie np. do inwestycji infrastrukturalnych i zakładające podział realizacji zadania na ściśle określone, niezależne i następujące po sobie etapy (planowanie, projektowanie, wykonanie, odbiory, oddanie do użytkowania), często się tutaj nie sprawdzało. I właśnie niedostatkom tego klasycznego, kaskadowego podejścia, zwanego dalej modelem Waterfall, stara się zaradzić metodologia Agile. Poniżej opisujemy pokrótce kilka wybranych aspektów umów na tworzenie oprogramowania według obu tych modeli – w przypadku Agile będzie to najpopularniejsza obecnie metoda Scrum.

> SPECYFIKACJA OPROGRAMOWANIA

W modelu kaskadowym specyfikacja oprogramowania jest czymś absolutnie nadrzędnym i niezbędnym. Klient informuje wykonawcę o tym, na czym mu zależy, a wykonawca przygotowuje w oparciu o to szczegółowy opis tego, jak program powinien wyglądać i działać. Przygotowana specyfikacja jest następnie zatwierdzana przez klienta. Tak ustalony zakres prac nie podlega z reguły późniejszym modyfikacjom i wyznacza ramy produktu końcowego, jaki powinien być dostarczony przez wykonawcę. Jakie są skutki takiego działania? Po pierwsze, brak elastyczności – przede wszystkim liczy się uzgodniony zakres prac, nie rzeczywiste potrzeby klienta. Co prawda, w umowach opartych na klasycznym modelu przewiduje się pewien wentyl bezpieczeństwa w postaci procedury zmiany, lecz jej stosowanie jest zwykle skomplikowane i ograniczone, a ponadto wiąże się dla klienta z dodatkowymi kosztami. Po drugie, koncentracja wykonawcy na produkcie, który ma zostać dostarczony, co sprawia, że wszelkie inne sprawy schodzą na dalszy plan. Można to ująć inaczej – z chwilą zatwierdzenia specyfikacji przez klienta wykonawcę interesuje głównie to, czy zdoła dostarczyć na czas zgodny z nią program komputerowy, ponieważ od tego zależy, czy otrzyma wynagrodzenie i czy nie będzie pociągnięty do odpowiedzialności za nienależyte wykonanie kontraktu. W efekcie rzeczywisty interes klienta traci na znaczeniu. Zdarzają się sytuacje, gdy w trakcie prac umówiona funkcjonalność przestaje być klientowi potrzebna, a wykonawca i tak ją realizuje, i to nawet gdy wie, że lepiej byłoby skoncentrować wysiłki programistów na innym, bardziej istotnym z punktu widzenia potrzeb klienta elemencie aplikacji. Po trzecie, sztywna specyfikacja to większe koszty. Mając jasno określony zakres prac, klient oczekuje ceny ryczałtowej. Z racji tego, że – jak wspomniano – tworzenie oprogramowania jest procesem dynamicznym i często nieprzewidywalnym, wykonawca zawsze zakłada sobie pewien margines bezpieczeństwa, dodając do kalkulacji dodatkowy narzut związany z ryzykiem (czasem nawet do 30-40%). Kwota ta jest często skrzętnie kamuflowana np. poprzez odpowiednie zwiększanie liczby roboczogodzin niezbędnych do wykonania poszczególnych funkcjonalności, a ujętych w przedstawianej klientowi kalkulacji wynagrodzenia. Z drugiej strony, za zwiększone koszty często odpowiada również i sam klient. Skoro bowiem raz ustalony zakres prac trudno będzie zmienić, istnieje silna pokusa, by zawrzeć w nim „na wszelki wypadek” jak najwięcej elementów. Nigdy nie wiadomo bowiem, czy po zakończeniu projektu (a więc zwykle po co najmniej kilku miesiącach) elementy te nie będą przydatne.

 

[...]

 

Piotr Grzelczak
Autor jest radcą prawnym, partnerem w Kancelarii Prawnej GFP_Legal we Wrocławiu, specjalistą z zakresu własności intelektualnej, realizacji projektów IT i ochrony danych osobowych.

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"