HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • sagabona: szia... elég régen született ez a bejegyzés, én csak most akadtam rá véletlenül. Érdekes dolgokat írsz, részben egyetértek az általad gondoltakkal, azonban pár dologban messze más a véleményem - ez ... (2018.10.19. 11:14) Gondolatfoszlányok a pályaválasztásról
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

Agilis fejlesztéshez agilis szerződést!

Agilis fejlesztéshez agilis szerződést!

A cikksorozat 1. része, 2. része és 3. része után itt a folytatás, ahol rendhagyó módon nem egy éles, hanem egy szerződés sablon kerül terítékre. A sablon az Agilis Szoftverfejlesztők Szövetsége web oldalán érhető el itt: http://www.agilealliance.hu/ProfessonalMaterials/107

A dokumentum megtekintéséhez ingyenes regisztráció szükséges. Nem adok közvetlen elérést, mert nem szeretném senkinek a szerzői jogait megsérteni.

A szerződés egy feltételezett nagyvállalat és informatikai kkv közötti megállapodást körvonalazza. Az agilis fejlesztés sok szempontból eltérő a hagyományos fejlesztési folyamattól, ezért szükséges a módszertanhoz jobban illeszkedő megállapodással előállni.

Nagyon örülök, hogy valaki végre kézbe vette ezt a témát és önzetlenül segítséget nyújt a magyar kkv-knak. Ez úton is köszönöm szépen Zsuffa Zsoltnak, hogy felhívta rá a figyelmet.

És most jöjjön maga a szerződés!

Mi a szerződés tárgya?
A legeslegelső kérdés amit az ügyvéd feltesz, hogy mit nyújt a Vállalkozó a Megrendelő részére. Ez tipikusan egy termék (például a kész szoftver) vagy szolgáltatás (például szoftver fejlesztés vagy tanácsadás).
A szoftver fejlesztési projektek tipikusan a termékről, az átadandókról szólnak, vagyis minden az elkészítendő szoftver körül forog. Az agilis fejlesztés tipikusan nem a scope-ról, hanem az együttműködésről szól, ezért úgy érzem, ezt szolgáltatásként kellene definiálni.
Éppen ezért célszerű lenne elkerülni az ezzel ellentétes kijelentéseket. Például „üzleti folyamat szoftveres támogatásának megvalósítása” helyett „támogatást nyújt az üzleti folyamat szoftveres megvalósításához”. A különbség az, hogy az első esetben a hangsúly a megvalósításon van, és az ember azt hiszi, hogy előáll valamilyen késztermék a munka eredményeként (leszállítandó). A második esetben a hangsúly a támogatáson van, ami értelemszerűen szolgáltatás.
Hasonló okok miatt nem tetszik a megvalósítási időszak. Azt sugallja, hogy van határidő. A nyújtandó szolgáltatásnak van időszaka, de jó lenne ezt tisztességesen meghatározni. Például mi történik, ha az iteráció túlnyúlik a megadott végdátumon? Azonnal abbahagyjuk a munkát?

Az együttműködés módja
Nagyon helyes, hogy a szerződés kitér az együttműködés részleteire. A szerződés szintjén le kell fektetni az agilis munka kereteit, későbbi félreértések elkerülése végett.
Célszerű lenne nyomatékosabban hivatkozni a módszertanra. A módszertan standard, tehát objektívan és konkrétan leírja a szolgáltatás minőségi mutatóit illetve az elvégzendő feladatokat. Fontos, hogy a módszertan pontosan meg legyen hivatkozva, azaz például ha valaki SCRUM szerint fejleszt, akkor ezt írja bele. (Találós kérdés: megszegi-e a megállapodást a Vállalkozó, ha teljesíti az iterációt de eltér a módszertantól?)
Jelen pillanatban olyan kitételek is szerepelnek is, amik feleslegesek, vagy legalábbis nem így kellene ezeket leírni. Például 1.2.7
Habár az iteráció leírását szerintem frappánsabban is meg lehet fogalmazni, de ez így ebben formában is jó és használható.

Mit nyújt a Vállalkozó?
Ami viszont nagyon hiányzik, az a Vállalkozó által nyújtandó feladatok/szerepkörök (vagyis hogy a Vállalkozó konkrétan milyen tevékenységeket végez). Hiszen nem mindent a Vállalkozó csinál. Értelemszerűen ennek összhangban kell lennie a hivatkozott módszertannal. Például jelenleg sehol sincs leírva, hogy a Vállalkozónak szoftvert kell fejlesztenie, hogy azt tesztelnie kell, hogy műszaki tanácsadást kell nyújtania, hogy elő kell állítania a szükséges dokumentációt, stand-up-meeting-eket tartani, SCRUM Master-t delegálni, stb stb.
A Vállalkozó kötelezettségei leírják, hogy x fő fejlesztőt delegál a projektbe, de nincs megadva, hogy ezek a fejlesztők mit csinálnak.

Szakmai halandzsa
Problémának érzem, hogy időnként rejtélyes szakszavak bukkannak fel. A szerződést elsősorban üzleti döntéshozók, cégvezetők, ügyvédek és beszerzők olvassák. Kizártnak tartom, hogy egy ügyvéd tudja, mit jelent a tesztlefedettség. Azt még kevésbé, hogy ebben a formában átengedi a dokumentumot.
A helyzetet tovább rontja, hogy a szolgáltatás minőségi mutatója nem közérthető módon (hanem tesztlefedettséggel) lett meghatározva. Az sincs meghatározva, hogy ennek a – csak szakmailag érthető – mutatónak a mérését és ellenőrzését ki és hogyan fogja végezni (az nem válasz, hogy a Vállalkozó saját bemondásra).
Ez így ebben a formában egyértelműen a Vállalkozónak kedvez.

Jogdíj, szerzői jog
A jogdíjról szóló rész szándékosan nincs kidolgozva. A lehetséges verziókkal nagyon furcsák, de nyilván nem ez jelenti a sablon lényegi részét.

Teljesítés
Már említettem, hogy nem célszerű szakmai halandzsát keverni a szerződésbe, ezért az 1.6.1-es pontot ki lehetne szedni. Esetleg a átrakni a Vállalkozó kötelezettségei közé.
Az 1.6.2-es pont koncepcionálisan jó, de pontosításra szorul. A felek az iteráció elején megállapodnak a feladatokban, azokat a Vállalkozó végrehatja, az iteráció végén az ügyfél nyilatkozik, hogy megfelelően lettek-e végrehajtva a feladatok.
A Megrendelő nem a teljesítés igazolásra fizet, hanem a Vállalkozó által benyújtott számlára. A számla alapját a Megrendelő által igazolt teljesítés jelenti. Mintha az 1.6.2 ellentmondásban lenne az 1.8.1-gyel.

Díjazás
Nagyon nem egyértelmű, hogy mi történik nézeteltérésnél. Tegyük fel, hogy egy feladatot előzetesen 1 hétre becsülnek. Aztán valami történik, és lesz belőle 2 hét. Ki fizeti ki a különbözetet? Mi van akkor, ha az 1 hétre becsült munka 1 hétig tart, de az ügyfél hibát talál benne, és plusz 1 hétig tart kijavítani?
Gondolom a válasz egyértelmű, hasonlóan egyértelműen kellene megjelennie a szerződésben is.
Az 1.8.3-as pont felesleges.

Titoktartás
Az 1.9.2 és 1.9.3 pontok feleslegesek. Az 1.9.4 ponttal kapcsolatban az a kérdésem, hogy pontosan ki is az a „közreműködő”? Ugyanis adva van a Megrendelő, és az ő munkatársai. Adva vannak a Vállalkozó oldalán a fejlesztők, illetve a Vállalkozó alvállalkozói. Rajtuk kívül senkinek semmi köze a projekthez, ugyebár?
Hiányzik az a pont, hogy az együttműködés bármilyen megszűnése esetén a Vállalkozó mit tegyen a részére átadott dokumentumokkal (megsemmisíti?).

Felmondás
Feltennék pár segítő kérdést, amit nem sikerült a felmondással kapcsolatban tisztázni:
Hogyan lehet egy határidővel nem rendelkező, határozatlan időre szóló szerződésnél értelmezni a projekt hossz 50%-át?
Határozatlan időre szóló szerződésnél – ahol szigorúan véve leszállítandók sincsenek - miért nem lehet rendes felmondást alkalmazni?
Mi a teendő, ha iteráció közepén elszámolási kötelezettségbe bonyolódnak a felek, és az egyik oldal rendes felmondással kiszállna a történetből?
Bármilyen felmondás esetén a Vállalkozó mit ad át a Megrendelőnek? Forráskód, dokumentáció, adatbázis, oktatás?

Kötbér, pénzügyi felelősség, jótállás, szavatosság, mulasztás
Szokás mondani, hogy a papír mindent elbír, bármit le lehet írni. Azért szoktunk kötbért, garanciát és pénzügyi felelősséget tenni a szerződésbe, hogy a teljesítésnek tétje legyen, és a szerződés betűje ne csak pusztába kiáltott szó legyen. Ha nincs tét, akkor csakis a Vállalkozó jóindulatán múlik minden.
Úgy is fogalmazhatnék, hogy az igazi szerződés és a haverokkal kötött megállapodás között a kötbér a különbség.
A dokumentumból hiányoznak ezek a biztosítékok. Célszerű lenne későbbi viták elkerülése végett minőségi mutatókat és garanciákat meghatározni.
Formális módszertannál kötbérezzük a csúszást, a nem-teljesítést, előírjuk a jótállási időszakot, a garanciális szolgáltatást, illetve a gondatlanságból eredő hibákból fakadó kár kezelését. Nyilván ezek agilis fejlesztésnél kevésbé értelmezhetőek, de akkor helyettük találni kellene valami mást. Az nem megoldás, hogy nincs semmi.

Hol van a bikkfanyelv?
A dokumentum nyelvezete, a szóhasználat és a felépítése egyértelműen arra utal, hogy informatikus írta. Hiányoznak a tipikus ügyvédi szófordulatok és meghatározások, pl. definíciók, default-ok, garanciák. Feltenném a kérdést: töltött-e elég időt ezzel a szerződéssel egy igazi ügyvéd?

Összegzésképpen: nagyon örülök, hogy a sablon létezik. A használhatóságával kapcsolatban kétségeim vannak – egyoldalúan a Vállalkozónak kedvez, a Megrendelőnek biztosan nem lesz jó így ebben a formában, bele fog javítani, és innentől kezdve borulhat a szépen felépített struktúra. (Rosszabb esetben teljes egészében elveti a sablont, és hozza a sajátját…)

Ezeket a dolgokat – úgy érzem – könnyen lehet javítani, és el lehet jutni egy mindenkinek megfelelő dokumentumig.

Címkék: szerződés agile agilis

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr865211412

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Zsuffa Zsolt · http://www.itkodex.hu 2010.10.15. 22:00:24

Köszönöm, hogy ilyen alaposan átnézted, értékelted! Megjegyzéseiddel, javaslataiddal egyetértek és a további kommentek bevárása után készítek egy új változatot. Remélem tudunk valami hasznosat kinálni a hazai fejlesztői közösségnek. Két kérdés további pontosítását várom leginkább? 1) a teszt lefedettség, (és egyéb a szoftver minőségére utaló további mutatók) tényleg nem valók szerződésbe? 2) a bikkfanyelv tényleg elengedhetetlen kelléke a szerződésnek?

Ismeretlen_102125 2010.10.16. 09:11:04

1) Teszt lefedettség Azt elhiszem/elismerem, hogy szakmailag ez lenne a legjobb megoldás, de a szerződés nem két informatikus között köttetik. A megrendelő nem fogja érteni, nem fogja tudni mérni a szoftver minőségi mutatókat. Rosszabb esetben az ügyvéd kapásból kiszedi mert nem érti, és amit nem lehet 2 perc alatt elmagyarázni neki az nem létezik. 2) Bikkfanyelv Nem elengedhetetlen kelléke a szerződésnek, csak gondoltam cipőt a cipésztől szerezzünk. Ugye a puding próbája ott van, amikor az IT-s kkv ezzel a sablonnal felszerelkezve szembetalálja magát a nagyvállalat jogi osztályának informatikai szerződésekben járatos ügyvédjével. És hogy akkor mi történik. A sikerkritérium az lenne, hogy az ügyvéd minimális változtatásokkal elfogadja ezt a szerződést, vagy legalábbis csak beszúr ezt-azt amivel a fenekét védi. El kell ismernem, hogy itt egyik-másik kérdés nagyon húzós, például a tesztesettel definiált teljesítés külön megérne egy egész könyvet.

Ismeretlen_6098 2010.10.17. 11:21:16

Az 1.részben szerepelt: "Gondatlanságból eredő kár: A 13.5 bekezdésben van egy hiba, mégpedig az, hogy a Vállalkozónak csak a szerződésszegő magatartás és a szerződésen kívüli károkozás róható fel. Azaz a gyenge minőség és a gondatlanság nem, pl. rosszul megírt programért vagy túl lazán elvégzett tesztért nem felelős. " Most pedig a kommentben a teszteléssel kapcsolatos felelősségvállalás mégis kihagyandónak, feleslegesnek minősíttetett. "A megrendelő nem fogja érteni, nem fogja tudni mérni a szoftver minőségi mutatókat. Rosszabb esetben az ügyvéd kapásból kiszedi mert nem érti, és amit nem lehet 2 perc alatt elmagyarázni neki az nem létezik." Véleményem szerint a szerződésben, vagy annak megfelelő mellékletében, amit a szerződésbe be is kell emelni, mint szerves részt, igeni a Megrendelő által is érthető, ellenőrizhető formában meg lehet adni, hogy milyen igényeit, vagy milyen feltételeit/megegyezett teljesítési paramétereit hogyan tudja minősíteni, és teljesítettségüket ellenőrizni. Ez agilis esetben, amikor nem is tiszta, hogy mit is fog kérni a Megrendelő, mert az csak egy későbbi szakaszban válik ismertté, mert opportunista módon - vagy várt környezeti bizonytalanságból eredően - csak később, esetleg az első szoftverelemek asztalra tételét követően fog tudni ilyet megfogalmazni, szóval agilis esetben nem is olyan egyszerű adekváltan leírni. Ezért a mérési módszer, a minősítési elvek, a felmerülő problémák kezelési folyamata lehet az egyetlen, ami a Szerződés megkötésekor mindkét fél számára ismert. Arra a felvetésre, miszerint a jogász nem ért informatikai szerződésekhez, és ezért kikukázza a megfogalmazásokat? Ki vele az utcára! Itt informatikai szerződések (jelesül Agilis szoftverfejlesztési szerződés) jogi véleményezésére kell megbízást kapjon, nem egy családjogi peranyag van az asztalon! Ennek megvannak a sajátosságai, amik különböznek az eddig megszokott szoftverfejlesztési szerződésektől. Megfelelő szakértelem nélkül akár "kontárnak" is minősülhetne, no nem a szó jogi értelmében :-( . Sajnos. Még. Mert kevés az IT-s jogász. Az IT területekre ugyanúgy képeznie kell magukat nekik is, ahogy nekünk projektvezetőknek, SLA vagy Bid Managereknek a szerződések értelmezésére, a "bikkfanyelv" munkakövetelménnyé történő lefordítására, a megfogalmazott igények és a szerződésben, SLA-ban szereplő kötelezettségek konformitására kell tudnunk odafigyelni - de most nem a jogászok vannak terítéken, hanem a szerződések :-)

Ismeretlen_102125 2010.10.18. 09:46:37

@Brainshare Félreértettük egymást. Tesztelni KELL, tesztesetekre szükség van. Azt viszont vitatom, hogy a szolgáltatás teljesülését a szerződésben - ami nem műszaki dokumentum - "tesztlefedettséggel" definiáljuk. Jogászok informatikai tudása: találkozott már valaki olyan jogásszal, aki tökéletesen értette a "tesztlefedettség" kifejezést és annak mérését? Ideális esetben persze értsen, de a nagyvállalati jogi osztály nem csak IT szerződéseket köt. Sőt, az IT szerződések jelentik munkájuk kisebb részét. A saját tapasztalatom az, hogy veszik a fáradtságot és utánajárnak, tehát tudják mit jelent a "hiba", a "teszt", mi az a szoftver és hogy a szoftver dokumentálni is kell. De hogy mi a "hibakezelés" vagy "tesztlefedettség", már nem. Egyébként meg úgy gondolom, hogy van megoldás (pl az említett mellékletes elgondolás). Csakis az agilis közösségen múlik, hogy tovább dolgozzon a szerződésmintán.