Statuses

10 éves a “Kiáltvány az agilis szoftverfejlesztésért”

In Kurrens/ajánlott on 2011. március 2. szerda by Nacsa Sándor Címkézve: , , , , , , ,

Manifesto for Agile Software Development [Feb 12, 2001]
magyarra fordítva
Kiáltvány az agilis szoftverfejlesztésért
[2010. december 12.]

A két dátum közötti különbség szembetűnő lehet, pedig megjegyzendő, hogy első klubdélutánját éppen a kiáltvány megjelenése után 7 évvel rendezte a tagtoborzást 2007. október 10-én megkezdő Magyar Agilis Szoftverfejlesztők Egyesülete, és azóta 14 klubdélutánt tartott összesen.

Mi a helyzet ma az agilitás témájában úgy itthon, mint határainkon túl? A következők ezt mutatják be egy február végi, március eleji intenzív prog.hu diszkusszió, illetve a 10 éves jubileum alkalmából rendezett amerikai összejövetel alapján.

A 10 évvel ezelőtti kiáltvány lényege:


azaz értékesebb:

  • az egyének és azok együttműködése, mint az eljárások és  eszközök
  • a működő szoftver, mint a mindenre kiterjedő dokumentáció
  • a megrendelővel való együttműködés, mint a szerződéses alkudozás
  • a változásokra való reagálás, mint a terv követése

Hazai helyzet

Ha prog.hu-n megjelenteket vesszük, akkor ennek széleskörű hazai elérésétől még messze állunk. Legjobban az érdemben mindössze egy hete lezajlott intenzív Miért nem tudunk minőségi szoftvert alkotni? [2011. február 21- 24, … mai napig] igencsak intenzívre sikeredett diszkussziója mutatja ezt. Az érdemi vita szvsz a “VBandi válasza nova76 (12:42) hozzászólására 2011.02.24. 13:17″-el ért véget, nevezetesen ezzel (csak ezt a számomra “végkifejleti részt” kivonatolva, időbeli sorrendbe rendezve és a tőlem származó kiemelésekkel):

[LC:] Nekem van egy kedvenc ügyfelem, az vizuális típusú. Ami azt jelenti, hogy megmondja nagy vonalakban mit akar, erre én írok neki egy 10 oldalas word doksit amiben leírom hogy én ebből mit értettem meg, és hogy ezt hogy lehet megvalósítani, erre ő azt válaszolja hogy neki ezt nincs ideje elolvasni, meg amúgy sem tudja ezt a leírás alapján értelmezni, csináljam meg, és majd az alapján eldönti hogy így akarta-e ?

[VBandi:] Na, ezért csinálok én már tizensok éve prototípust a specifikáció részeként.

True story: egy közepes cég fontos, de igencsak rosszul megírt rendszerét kellett újraírni, mert már használhatatlan volt. Megkérték a fejlesztőjét, hogy specifikáljon. Lerakott az asztalra egy 1200 (!) oldalas tömény UML speckót, amiben az ügyfél számára az egyetlen érthető mondat az volt, hogy “Ez a specifikáció a szokásosnál kevésbé szakmai nyelvezettel készült, hogy a T. ügyfél is megérthesse”. Megkértek engem, hogy mondjam meg, hogy nekik vajon arra a rendszerre van-e szükségük, ami az 1200 oldalban benne van.

Hazavittem a csomagot (izomlázam lett másnapra), és elkezdtem böngészni. Megnéztem az “új telephely felvitele” feature-t, találtam benne 3 hibát. Megmondtam, hogy én ezt az elemzést nem vállalom, mi különben sem így szoktunk specifikálni.
– Hát akkor hogy?
Elmondtam. Végigtoltunk egy közel 3 hónapos feltárási fázist, aminek az eredménye lett egy .exe alapú kattintgatható prototípus. A prototípus az olyan állat, hogy tartalmazza a képernyőket, azon belül a mezőket, még talán egy javasolt layoutot is, és működik a navigáció. De se DB, se logika, se végleges design nincs benne. A user végigkattinthatja (ott ülünk mellette), még a raktáros is eljátszhatja benne egy napját, és szólhat, hogy ez a funkció nagyon el van rejtve, azon a képernyőn / reportban még két mezőt szeretne látni, mittomén. Ezen felül készült 40-50 oldal írott specifikáció (olyan dolgokkal, mint workflow, hw követelmények, stb – ami a protóból nem olvasható ki). Nálunk a specifikáció = prototípus + doksi, és a szerződés is a kettőre együtt vonatkozik. A prototípus könnyen (tehát olcsón) változtatható, pláne manapság, a Sketchflow korában. A fejlesztő, architekt is ezekből dolgozik, amikor rá kerül a sor.

Végül tőlünk rendelték meg a teljes fejlesztést, úgy, hogy a másik cég kb. a mi árunk felét mondta. Meg is csináltuk, a végeredmény 90%-ban ugyanaz lett, mint a prototípus, és mindenki heppi volt. Amikor eőadásokon megkérdezem, hogy ki hány százalékban szokta eltalálni az 1.0-t a szerződésben, általában 50-70%-os számokat szoktam kapni, de nem ritka a 30-as sem… ehhez képest a 90 igencsak jónak számít.

Szóval, száz szónak is egy a vége – a prototípussal mindenki csak nyer. A megrendelő érti, hogy mit fog kapni a pénzéért, a fejlesztő meg biztos lehet abban, hogy a szoksásosnál jóval kevesebb lesz a change request, és a megrendelő nem az átadásnál találkozik először a művével.

[nadamhu:] Igen, nem véletlen, hogy az ‘agilis módszertanok’ vannak terjedőben ma már.
Egy jó fejlesztő ‘iteratív’ igényfelmérést folytat korai prototípusokkal, refactoringgal, stb…
Egyedi fejleszténél ez elgengedhetetlen.
De már termékfejlesztésnél is ezt alkalmazzák, a neve ‘customer development’, nem simán piackutatnak, hanem korai ügyfelekkel iteratíve együtt dolgozzák ki azt, hogy egyáltalán mire van szükség a piacon.

(Közelben sem úgy működik ez jobb helyeken, hogy az istenek UML diagrammokat rajzolgatnak, a ‘kóderek’ meg ez alapján mechanikusan kódolnak. Ezért is nevetséges a szoftverfejlesztő munkáját a kőműves munkájával összehasonlítani.)

[VBandi:] Tudod, mi a mókás? Hogy az általam leírt megközelítéssel sokkal közelebb jutunk a waterfall-hoz, és ezáltal a megjósolható költségekhez. Mindössze a specifikációs fázis agilis, az ajánlat nyilván ezt követi, és az már jól meghatározott követelmények mentén történik, amit mindkét fél ért. Így – elméletileg – csak azért kell változtatni menet közben a projekten, mert pl. az üzleti környezet is változik, (pl. adószabályok, mittomén).

[nova76:] Azért néha a prototipus sem kis feladat. Ingyen nem lehet lerakni, különösen a feladat ismeretének hiányában nehéz.

[VBandi:] Nem a prototípus a költséges, hanem bármilyen előzetes specifikáció elkészítése. Az az ügyfél, aki pedig nem hajlandó a feltárásért fizetni, menjen máshová – jó eséllyel a kész programért sem fog. A feltárás ugye igen komoly konzultációs feladat, ahol a konzulens évtizedes tapasztalatából profitál az ügyfél is.

Nem mellesleg prototípust csinálni sokkal olcsóbb, mint egy sokszáz- vagy ezer oldalas doksit leírni, és végig konzisztensen tartani. És azt se csinálnád ingyen… több millás projektre pedig nem lehet 4-5 oldalas speckó alapján szerződni, az tuti bukás.

No ez az a pont, ahol egy klasszikus szemléltető ábrával hangsúlyozni lehet a fenti, egyedül a lényeggel foglalkozó diszkussziót:

Előtte: sok-sok hozzászóláson keresztül csak a programok műszaki természetének más műszaki alkotásokénál sokkal nagyobb összetettségéről folyik lényegében a vita, belekeverve olyan dolgokat is, hogy más műszaki alkotásoknál a tervező és a kivitelező szerepköre már régen különválik, majd lassan eljutva oda, hogy megrendelő nem tudja megfogalmazni a megoldandó feladatot, a programozónak pedig nincs módja “akadékoskodni” ez ügyben, mert meg kell élnie valamiből.

Alatta: az addig diszkussziót folytatók zöme ehhez nem szól hozzá (a fenti diszkusszióban csak hurka vesz még részt, azzal, hogy “Ebben van valami, csak olyan ügyfél is kell hozzá… előzmény“), miközben mások (devel62, Mekkelek5) a korábbi vonalat folytatják.

Utána: minden folytatódik az eredeti kerékvágásban majd senki feb. 27-ről 28-ra virradóra igen hosszasan összegzi a diszkussziót, mégpedig ilyen keretben:

Érdekes ez a téma és szerintem mind a két itt körvonalazódó oldalnak megvan a maga igaza.

Egyrészt a programozás szerintem igenis egy összetett folyamat és vannak bizony olyan buktatók ami más szakmák esetén nem vagy csak ritkán merülhet fel:

<roppant hosszas felsorolás> …

Szóval van itt mindenféle probléma és nehézség azért. Ezek közül sok persze előfordul más szakmáknál is, de nem feltétlen egyszerre és nem feltétlen ilyen arányban.

Viszont a másik tábornak pedig abban van igaza, hogy mindezektől függetlenül végső soron mégiscsak a mi termékünkben van a hiba, melyet egy jó szakinak meg kellene tudnia elkerülni. Szóval még abban az esetben is, ha esetleg bonyolultabbnak tekintjük az egész termék-előállítási folyamatot más szakmák folyamatainál, akkor is oda lyukadunk ki, hogy végső soron nem végezzük jól a dolgainkat…
Szerintem ez a probléma gyakorlatilag tényleg a pénz miatt áll fenn, amiatt, hogy a programozók nagy többsége hajlandó:

<ismét hosszú fejtegetés> …

senki összefoglalójára nem reagálnak, hanem folyik a régi mederben minden tovább, majd végül eljut a használt, harmadik féltől származó “építőkockák” megvitatásához (kőműves analógia) és mostanra gondolom lezárásra jutott két igen aktív hozzászóló egyetértő véleményével:

[hurka:] Szvsz összefoglalva a válasz:
Tökéletes környezet mellett lehetne tökéletes szoftvert írni, de tökéletes környezet mellett nagy valószínűség szerint nem lenne szükség ennyi szoftverre sem, illetve pénzre sem, mindenki élne boldogan, és dolgozni sem kéne…

[inf3rno:] Ja, valahogy így . Azért akar az ember sajátot írni, mert nincsen tökéletes, és úgy gondolja, hogy majd az övé az lesz

Az én összefoglalóm ezzel szemben az, hogy a magyar szoftverfejlesztőknek egészen elenyésző körét érintette meg az agilis szoftverfejlesztés, hogy a prototípus készítésről ne is beszéljünk. Az utóbbi pedig már azért is meglepő, mert az említett diszkusszióban folyamatosan összehasonlították a programozást más műszaki tevékenységekkel, ahol pedig makettek, prototípusok stb. rendre fontos szerepet játszanak a készítendő termék fejlesztésében. Szvsz erről azonban sokkal kevésbé tehetnek maguk a programozók, mint a megrendelő vállalatok meglehetősen leegyszerűsítő szemlélete és különösen gyakorlata. Máig nem igazán honosodott meg a tőlünk nyugatra már évtizedekkel ezelőtt elfogadott, a megrendelőnél végzett munka óraráfordítás alapján történő díjazása, ráadásul a teljesítési igazolások tájékán is rendre gondok vannak, ami késedelmes kifizetésekbem jelentkezik és csak előre megemelt vállalási díjak mellett tolerálható.

Fontos későbbi adalék: Honfitársaim az agilis fejlesztésről — egy mindent alulmúló idézet (2011. március 23.)

Nemzetközi kitekintés

Határainkon túl — ezzel szemben — eljutottak oda, hogy:

  • Ma már nem az agilis szoftverfejlesztés elfogadtatása foglalkoztatja a kiáltvány megfogalmazóit, hanem az, hogy milyen problémákat sikerült megoldani, milyeneket nem, és mivel lehetne eredményesen foglalkozni a továbbiakban? Lásd: Agile Manifesto 10 Year Reunion [Feb 10, 2011]
    Ezeket a kérdéseket nem csak egy viszonylag szűk körű összejövetel, a “10 Years Agile” konferencia résztvevői (mindössze 33 fő), hanem a weben bárki megválaszolhatta. Összesen 38 válasz olvasható a Join the Dialog! blogbejegyzés kommentárjaként.
  • A tervezett 10. évfordulós összejövetel jövőre vonatkozó részére Michael Hugos tett közzé egy keretelgondolást: An Agile Future – Framework for Discussion [Feb 4, 2011], amelynek lényege a következő volt:
     

    1. The centrally controlled corporate hierarchy doesn’t work in the business world any better than the slow-moving waterfall process works in the software development arena. And rapid technical change in the form of cloud computing, social media and consumer IT is leaving the old model of corporate computing departments in the dust. Looks like it’s time  to get agile and reinvent ourselves!
      (A központi módon irányított, vállalati hierarchia semmivel sem jobb működését tekintve
      annál , ahogyan a lassan mozduló “vizeséses” folyamat zajlik a szoftverfejlesztés területén. Emellett a számítástechnikai felhő, a szociális média és a fogyasztói informatika formájában gyors technikai változás jelentkezik, ami a vállalatok informatikai részlegeinek régi működési modelljét “állva hagyja”. Ahogyan kinéz, itt az ideje, hogy agilisek legyünk és “találjuk ki önmagunkat”!)
    2. Agile IT Practices can Drive Business Operations
      (Az agilis informatikai praxis vezérelheti az üzleti működést.)
    3. Agile Operating Dynamics of the Real-Time Enterprise
      (A valós idejű vállalat agilis működési dinamikája.)

  • Michael Hugos először arról a három koncepcióról számolt be, amelyeket a mozgalom változatlan és egyben meghatározó jellemzőjeként a 10. évfordulós összejövetel résztvevői megkülönböztető jegynek tartottak (ld. Ten Years of Agile: What the Agile Community Must Do Now [Feb 21, 2011]):
    1. Agile is continuous response to changing conditions and requirements. (Agilis az, ami a változó feltételekre és követelményekre adott folyamatos válasz.)
    2. Agile is iterative and incremental development of software and system. (Agilis az, amikor a szoftver és a rendszer fejlesztése iteratív és inkrementális módon történik.)
    3. Software development isn’t going back to the traditional waterfall approach of the last century. (A szoftverfejlesztés nem tér vissza az elmúlt évszázad hagyományos, “vízeséses” megközelítéséhez.)
  • Majd négy pontban adta meg az agilis mozgalom jövőjére vonatkozóan az összejövetelen kialakított direktívákat:
    1. Demand technical excellence. (Meg kell követelni a technikai kiválóságot.)
    2. Promote individual change and lead organizational change. (Ösztönözni, elősegíteni kell az egyéni változást és elöljárni a szervezeti változás terén.)
    3. Organize knowledge and improve education. (Rendezetté, szervezetté kell tenni az ismereteket és jobbá kell tenni az oktatást.)
    4. Maximize value creation across the entire process. (Az egész folyamatra kiterjedő értékképzés maximalizására van szükség.)

    Részletes beszámolójából kitűnik, hogy mennyire nem volt triviális a negyedik pontra vonatkozóan konszenzusra jutni. Ez persze érthető, hiszen ennek kapcsán arról a szoros kapcsolatról van szó, amely az elkövetkező 10 évben az agilis szoftverfejlesztés gyakorlatát a vállalatok működtetésének gyakorlatával kell, hogy összekösse. Az egész folyamatra kiterjedő agilitás pedig az eddig csak magára a szoftverfejlesztésre kiterjedőnél jóval nagyobb problémakör.

Persze még itt is voltak aktuális kérdések. Ilyen volt például:
– a rendszerszervezőké: ld. Business Analysts versus Business Designers — Analysis is only half the job; the other half is design [Feb 15, 2011]
– az érintett vállalat és az informatika közötti bizalmi kapcsolat kiépítéséé: ld. Agile Builds Trust with Fast Feedback — Agile development builds trust by giving people systems they can work with and respond to in short periods of time [Feb 27, 2011]

Michael Hugos folytatja majd ezeket a részletes beszámolókat, amelyeket leirat és kapcsolódó videófelvétel formájában is közzétesz a CIO magazine-ban megjelenő Doing Business in Real Time blogjában.

Olvasható még beszámolója arról, hogy milyen “rádöbbennések” érték az összejövetelen, ld. My “Ahas” from 10 Years Agile [Feb 16, 2011], röviden összefoglalva:

  1. Leadership and Vision, azaz vezérszerű vezetői szerep és vízió
  2. Defining and realizing “Value”, azaz az “érték” meghatározása és realizálása
  3. Practices and Tools outside of development, azaz a fejlesztésen túlmutató praxisok és eszközök
  4. Elephants in the room, azaz a tény, hogy most már a nagyok is benyomultak az agilis fejlesztés zászlaja alá, egyszerűen abból kifolyólag, hogy komoly üzlet lett
  5. From Certification to Evaluation, azaz az oklevélszerzésről áttérni a minősítésre (különösen a 4. pont vonatkozásában)
  6. Does Agile really make a difference?, azaz az agilis megközelítés valóban [minőségi] különbséghez vezet?

Az utóbbira vonatkozóan kapott továbbá egy olyan észrevételt a szerző, ami Why isn’t agile “winning”? (part 1) [Feb 23, 2011] címmel megjelent jegyzetében csak elvezet a címben megfogalmazott kérdéshez, a válasz pedig majd a cikk második részében lesz megfogalmazva.

Ajánlható tovább az InfoQ Agile Manifesto 10th Anniversary cikksorozata, melyben három cikk jelent meg eddig:

  1. A Personal Reflection on Agile Ten Years On [Feb 11, 2011] a kiáltvány egyik aláírójától Stephen J Mellor-tól.
  2. Agile 10 Years On [Feb 18, 2011] James Coplien-től, aki — a gyakorlati objektum-orientált tervezés 90-es évekbeli úttörőjeként és a szoftver minták egyik alapító atyjaként (mindkettő InfoQ jellemzés) — a gyökerekig visszamenve írja le az eddig elérteket.
  3. Reflections on the 10 Years Since the Agile Manifesto [Feb 23, 2011] Mike Cohn-tól, aki 25 év fejlesztői gyakorlata, Scrum és agilis fejlesztési tapasztalatok, valamint oktatás és “edző felkészítés” (coaching) szempontjából nyilatkozik az eddig elértekről és a jövőbeli várakozásokról.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: