A legutóbbi post után egyik olvasóm (feltéve, hogy több is van), arra kért, írjak az Agile módszerekről.

(Jövő héttől esküszöm, programozni fogunk. Suszter meg kaptafa, ugye.)

(Illetve lehet, hogy nem értek hozzá: viszont mi tudtunk határidőre is hozni dolgokat, nagyjából ezzel a készlettel. Azért ebben az iparban ez nem egyértelmű…)

A baj az, én nagyon rég vezettem projekteket, akkor is inkább vezetőfejlesztő voltam (úgy hívtam: szakmai / műszaki projektmenedzser), de leírhatom, hogy mik voltak az alapelveim a jó-hely és az azt megelőző projektek idején, és hogy látom most, akár az agilis módszertanok tükrében.

Itt szeretném halkan megjegyezni, biztos-ami-tuti, hogy ennek nem feltétlen van köze ahhoz, ahogy mostani munkahelyemen vezetnek projekteket, nem mintha nem csinálnának egy csomó dolgot nagyon jól, csak én ott fejlesztő vagyok, és nehogy valaki összekeverje.

Először is: a projekt csapatmunka. Az egyszemélyes projekt az az ott b… tad meg kategóriája. Tisztában vagyok vele, hogy sok van ilyen. De egyszerűen nincs mit projektmenedzselni vele! Vagy van motivációd, erőd, kitartásod végigcsinálni (aminek szerves része az, hogy a pénzt adó - ügyfél főnök, stb - rendszeresen cseszeget, illetve van merszed kérdezni), vagy nincs, és kb. itt van vége a történetnek. Ilyenkor problémák lehetnek, hogy:

  • Nincs aki átnézze a kódod, lehet, szar az egész.
  • Nincs akivel megbeszéld a problémáidat, ha megakadtál, meg vagy akadva, a Google vagy segít, vagy nem.
  • Nincs, aki megvédjen attól, hogy az ügyfél hülyeséget beszél
  • Ha nincs ötleted, nincs ötleted, valamit kiszenvedhetsz magadból, nem derül ki, hogy jó-e, még a végén se (maga a dolog szívás, vagy az elején félreértetted az ügyfelet / túlbonyolítottad? Sose fogod megtudni!)

Ezért én nem is szeretem az egyszemélyes projekteket. Emellett ugyanakkor a legfontosabb dolog a motiváció. Mondok egy példát: Georgy és Void, a KSZK két ikonikus veteránja, volt szobatársak. Előbbi egyszer azt mondta, hogy az egyetemi fejlődésének szerves része volt, hogy egymást húzták az újabb és újabb kihívásokkal, és így alakult ki pl. a saját funkcionális nyelvük (az SchML). De hozhatnánk példának a Szilícium-völgyet is, az is pontosan ezért működhet.

Ellenben számtalan olyan egyszemélyes projektem van, amit egyszerűen nem bírtam végigvinni, akkor se, ha fizettek volna érte. Egyszerűen nem ment, ott voltam a semmibe egyedül, tudom, hogy meg tudnám csinálni, tudom, hogy pénzt kapnék érte, de nem megy, nem megy és kész… Irigylem azokat, akiknek ez könnyen megy.

(Néha persze átszenvedtem magamat ezen.)

Tanulság: mindig legyetek legalább ketten.

A nap menete

Reggeli standup: Azt gondolom, az Agile legfontosabb vívmányainak egyike, hogy megtalálta azt a formátumot, amivel 10-15 percessé lehet tenni egy meetinget. Minden egyes napot ezzel a meetinggel kell kezdeni. A legfontosabb a rendszeressége, minden munkanap legyen!

Egy ilyen meeting pontosan 3 dologról szól:

  • mit csináltam tegnap
  • mit tervezek mára
  • milyen elakadásaim vannak, amikhez szükségem lenne segítségre.

A részvétel kivétel nélkül kötelező. Figyelemelterelő eszközök (számítógép, mobiltelefon) használata tilos!

Ez nem azt jelenti, hogy amúgy szóba se álltok egymással, csak ebből világosan látszik, hogy épp veszted el a motivációdat (ha már két napja van fontosabb dolgod, jó esély van rá, számodra a projekt belül már véget ért, nincs erőd rá), világosan látszik, mik azok, amik nélkül nem tudsz továbblépni, így nem leszel napokig elakadva, és az is kiderülhet, ha valakinek épp keresztbe tennél nem szándékosan.

Ezen kívül én egyébként figyelni szoktam az embereket: ha azt látom, hogy valaki már két órája iwiwezik, chatel, vagy nem nyúlt a billentyűzethez, akkor ott általában elakadás van. Egyébként is meg szoktam kérdezni 2-3 óránként, hogy áll, ilyenkor időszerűnek látom. Félreértés ne essék: nem a chateléssel van a bajom, vagy a pár perces pihenéssel, talán az arckifejezésen is látszik, ha valaki épp nem tud mit kezdeni a feladatával. Ekkor kell az, hogy még egy szem lássa a feladatot, és ne azért hogy azt mondogassa: márpedig ezt meg kell csinálni, hanem hogy vagy segítsen megoldani, vagy feladatváltást eszközöljön, hátha másnap, friss fejjel már egyértelmű lesz a megoldás.

Ezen túl is fontos, hogy a beküldött kódokat valaki nézze át: elvárásom szokott lenni a napi egy commit per fejlesztő, hogy tényleg tevékeny legyen a nap, és ezeket a kódokat átnézem. Ahogy öregszem, egyre szigorúbb a rostám, de ettől függetlenül még mindig abból derül ki bármi, ha ketten is látják azt a kódot, és csak attól fejlődhetsz.

Muszáj, hogy arról, amit csinálsz, rendszeresen beszéltessenek. Nem mindig, nem minden áron persze, de ha mindenkinek egyértelmű felelősségkiosztás van, egymás dolgaihoz pedig nem nyúlunk, az rosszabb lesz, mint az egyszemélyes projekt! Nem mellesleg az ilyenek úgy szoktak csúszni mint állat, mert a motiváció a legkisebb közös minimum szintjére csökken (”kész lehetnék vele, de Józsi se hajtja magát, én minek?”). (Igen, kettős játék ez: ha senki nem felelős semmiért, azért bukik be a projekt. Ha egyáltalán nincs közös felelősség, akkor meg azért.)

A hely

Fontos a legalább két helyiség: legyen egy hely, ahol meetingeltek, beszélgettek, terveztek, és legyen egy hely, ahol programoztok! Ez segít ezeket a ciklusokat jól kezelni, hogy mikor van kódolás, mikor van tervezés. Ha valami nem egyértelmű, esetleg többeket érint, sipirc be a meeting szobába megbeszélni! Mindenki lerakja az utolsó pontosvesszőt, és annyi.

Én nem szeretem, amikor a tábla a kódolóteremben - az arénában - van, csak zavarja a rendet. Annak a meetingszobában a helye. Persze a meetingszoba az is, ahol a telefonálások zajlanak, hogy ne zavarjátok a többieket!

Ide viszont csak indokolt esetben hozunk gépet, illetve nem illik hosszabb időre “kibérelni”. Erre esetleg lehet egy külön darálósarok, ami 4 csupasz falas, hogy csak arra tudj koncentrálni, amit épp csinálsz, meg egy pihenőszoba, ahol kanapé van, esetleg csocsóasztal (bár engem idegesít, ha egy pihenőszoba zajos.)

Szoftver

Nem hiszek a nagy wikizésben, se a szoftverdokumentációban általában, mert cseszettül nem frissítik őket, a kommentekkel együtt, épp ezért a minőségi kódokon szoktam inkább végigtekerni az embereket, amik pontosan azt tükrözik, amit csinálni akarsz, ha kell, kódgenerátorokon keresztül (hisz ekkor a forráskód az, amiből generálsz, a generálás tulajdonképpen fordítás egy köztes nyelvre). Így nem mondom azt, hogy tarts fenn egy wikit, de valami fájltároló azért jól tud jönni, meg szórd be az overview meg getting started doksijaid valahova, a diagramjaiddal együtt (a legtöbb diagram, amit készítek, rövidtávú felhasználásra szánt, de néha jól jön, ha még megvan.)

Viszont mindenképp legyen egy feladatkövetőd: a legtöbben a jirára esküsznek, ez ménkűdrága tud lenni, de nagyságrendileg mindent tud. Nekem az is jó, ha egy egyszerű flyspray-t felhúz valaki, az PHP-s, nem egy bonyolult dolog, a lényeg, hogy látszódjon:

  • kinek milyen dolga van még
  • mikor lesz ez az egész kész
  • mik a megbízó prioritásai (persze, minden most important, meg blocker a legtöbbnek, de erről néha le lehet beszélni)

Amit mindenképp tegyél meg, hogy ezt integráld valahogy a kommunikációs csatornáiddal: ha IRC-n kommunikálsz, legyen egy botod, ami egy parancsra felvisz egy új taszkot, ha e-mailen, akkor valami progi, aminek tudod forwardolni, és felrakja, nem érdekes, csak ne legyen plusz erőfeszítés az, hogy taszkot kell valamiből csinálni, mert annak sosincs jó vége. Ebből a kedvencem az I Want Sandy (sajna már megszűnt), klónja a cc:Betty, de biztos kitalálsz valamit. A cégnél az outlookba raktam bele egy virtuális mappát, aminek a home page-ét a projektmenedzsment rendszerre állítottam.

Az egyik legfontosabb célja a projektmenedzsmentnek, hogy mindig tudd, kinek, mit kell csinálnia, és ehhez várhatóan mire lesz szüksége, később meg konkrétan. Erre esetedben három dolog szolgál:

  • A use case-eid, amiket voltál szives felvenni, merthogy ezeket kell megoldani
  • A napi standup meeting, mert ez mondja meg, melyik use case hogy áll. Lehetséges, hogy modularizáltátok a feladatot a use case-ek alapján, nyilván, de ettől még ezt oldod meg. Hogy a use case-t user story-nak akarod hívni, az nem érdekel, a kettő közti különbség se.
  • A feladatkezelő szoftver, mert ez mondja meg, az egész projekt hogy áll. (Tőlem lehet excel tábla is, de hidd el, jobban jársz, ha mindenki magának tudja beírni a dolgokat)

Összegzés

Ha jól megnézed, ezen problémák mindig két dolog köré szerveződnek: kommunikáció és felelősség. Rossz hírem van. Egy átlag szoftverprojekt 40-60% kommunikáció, és 10-20% kódolás.

Hogy ez mennyire javítja a kódminőséget? Jó kérdés. Elsősorban határidők betartásában segít, hisz jobban fel tudsz készülni a helyzetekre, látod, ki hol tart.

Ami nagyban növeli a minőséget az a kommunikáció és a közös felelősségvállalás. Ha nem az van, mint a legtöbb cégnél ,hogy Sanyi ért a kapáláshoz, így Sanyi fog kapálni, és csak ő fog kapálni, a többiek meg azt se tudják, hogy néz ki a kapa…