Rengeteg érzelemmel telített vita zajlik a fejlesztési módszertanok, tervezési gyakorlat és hasonló témák körül. A legtöbb ilyen konfliktust lehetetlen feloldani, mivel az iparágban hiányzik a képesség a szoftverfejlesztés hatákonysági alapelemeinek a mérésére. A termelékenység mérésére például nincs ésszerű módszerünk.
A termelékenységet józan paraszti ésszel valahogy úgy lehetne meghatározni, hogy megnézzük, hogy a bemeneti tevékenységek milyen kimeneti eredményeket produkálnak. Vagyis ahhoz, hogy mérjük a fejlesztés termelékenységét mérnünk kell az eredményt. És itt a baj, ugyanis az eredményt nem tudjuk mérni.
Ez természetesen nem azt jelenti, hogy még nem próbálta senki. A legjobban azok a tanulmányok zavarnak, amik a termelékenységet a leírt kódsorok száma alapján próbálják mérni. Először is, különböző programnyelvek léteznek, különböző kódolási stílussal valamint formázási megszokásokon alapuló különbségekkel. De tegyük fel, hogy a kezdetektől következetesen mérünk, ugyanazt a nyelvet és automatikusan ugyanolyan kódolási stílust használunk - nos, a sorok száma ekkor sem megfelelő arra, hogy a kimenetünket mérjük vele.
Minden jó fejlesztő tudja, hogy ugyanazt a dolgot rengeteg féle képpen lehet megvalósítani, ráadásul, azok a kódok, amik jobban vannak tervezve általában rövidebbek, mert például a duplikációkat kiszűrik a kódból. Fordítva, a másolás és beillesztés programozási módszer pedig rossz tervezéshez és magasabb számú sorhoz vezet, ugyanis gyártja a többszörözést. Ezt be is tudjuk bizonyítani olyan refactoring eszközzel, ami támogatja az egysoros függvény és a függvény kivonat használatát. Ha ezt a gyakori eljárásoknál jól és ügyesen használjuk, simán meg tudjuk duplázni a kódsorok számát.
Gondolhatnánk, hogy a kódsorok száma alapú mérések mára már kihaltak, de nem. Minden hónapban találkozhatunk erre alapuló termelékenységi tanulmányokkal - még az olyan köztiszteletben álló folyóiratoknál is mint az IEEE, pedig nekik ezt már tudniuk kellene.
Ez persze nem jelenti azt, hogy a kódsorok száma teljességgel használhatatlan. Jól tudja például jelezni egy redszer méretét. Az azért valószínű, hogy egy 100.000 soros rendszer nagyobb, mint egy 10.000 soros. De ez csak becslés, ha én írok egy rendszert 100.000 sorból, a munkatársam Joe pedig megírja ugyanazt 10.000 sorból az nem tesz engem produktívabbá. Valójában inkább azt a következtetést lehet levonni ebből, hogy a termelékenységünk nagyjából azonos, de az én rendszerem sokkal rosszabbul van tervezve.
Egy másik megközelítése a témának, ha a kimenetet a funkciópontok számával jellemezzük. Ez számomra már egy kicsit szimpatikusabb, de még mindig nem meggyőző. Ebben mondjuk az sem segít, hogy hallottam olyan történetet, amiben egyetlen rendszer különböző pontszámai között egy hármas szorzó volt, persze ugyanazt az elemző rendszert használva.
De még ha precízen tudnánk is számolni a funkciópontokat, azt hiszem akkor is elhibáznánk a termelékenységi mérést. Azt nyilván mondhatjuk, hogy a funkcionalitás mérése egy módszer a szoftverfejlesztés közvetlen kimenetének a vizsgálatához, de a valódi kimenet azért egy kicsit más. Tegyük fel, hogy van egy precíz funkciópont mérési rendszerünk. Ha például én egy évben leszállítok egy 100 funkciópontos rendszert, Joe pedig egy 50 pontosat, akkor vajon feltételezhetjük-e, hogy az én termelékenységem magasabb? Azt mondanám, hogy nem. Az is lehet például, hogy az én 100 pontomból csak 30 olyan funkcionalitás van, ami ténylegesen használható is a vásárlómnak, amíg Joe 50 pontjából mindegyik használható. Ez inkább azt jelenti, hogy bár az én nyers, közvetlen termelékenységem magasabb, Joe valódi, használható termelékenysége a jobb.
Jeff Grigg arra hívta fel a figyelmemet, hogy belső tényezők is számítanak az egyes funkciópontok szállításakor. "Az én 100 pontom feltűnően hasonló funkcionalitást takar, és elvitt egy évemet, mivel nem sikerült megfelelő szintre emelnem menet közben a kód újrafelhasználást. Joe 50 pontja feltűnően különbözik (ez volt számára a rossz hír). Gyakorlatilag semmilyen újrafelhasználás nem történt. De annak ellenére, hogy 50 látványosan különböző funkciót kellett megvalósítania, és semmilyen újrafelhasználást ehhez nem tudott kialakítani, mindössze 1 év alatt elkészült vele. Szóval Joe egyszerűen fantasztikus,"
De mindez teljességgel figyelmen kívül hagyja, hogy még a használható funkcionalitás sem jelenti a jó mérőszámot. Például, ha én 30 használható funkciópontot gyártok, Joe pedig 15-öt, de valaki rájön, hogy az ő ügyfelei 15 millió dollár extra profithoz jutottak ezáltal, míg az én munkám csak 5 millió dollárhoz vezetett. Ismét azt kell mondanom, hogy Joe valódi produktivitása nagyobb, hiszen több üzleti értéket szállított - és egyben ráébreszt, hogy a szoftverfejlesztés valódi termelékenységét mérő adatoknak a leszállított, üzletileg értékes dolgokon kellene alapulnia.
Ezek a gondolatok elvezetnek a sikeresség vizsgálatához. Általánosságban megállapítani egy szoftver sikerét nehéz ügy, mivel az emberek nem értik, mit is jelent pontosan a sikertelenség. Érvelhetek úgy, hogy a sikeres projekt az, ahol több üzleti értéket szállítok, mint amennyibe került a projekt. Rendben, akkor mi van, ha Joe is és én is öt projektet vezetünk, én sikeres vagyok néggyel, Joe pedig eggyel - most végre sikeresebb vagyok, mint Joe? Nos, nem feltétlenül. Ha az én négy sikeres projektem egyenként 1 millió dollár nyereséget hoz, de Joe az egy sikeres projekten 10 millióval több bevételt termel, mint amennyibe került az összes projektje, akkor bizony őt kell ünnepelni.
Így hát vannak olyanok, akik azt mondják, hogy amit nem tudsz mérni, azt nem is tudod kezelni. Vagyis, dobjuk el az összes szabályt. Az üzleti szereplők valójában folyamatosan kezelnek megmérhetetlen dolgokat is. Hogy méred meg egy céges jogász produktivitását, a marketing osztályét vagy éppen az oktatási intézményekét? (erről bővebben itt olvashatsz: Robert Austin
Ha egy csapat hatékonyságát nehéz megmérni, akkor sokkal nehezebb megmérni a csapatot alkotó egyének együttműködését. Figyelheted erősen a csapat által fejlesztett funkcionalitások számát fejlesztési ciklusonként. Ez nyers értelmezés, de érzékelheted, hogy melyik csapat gyorsult fel, vagy érzékelheted, ha egyik csapat sokkal gyorsabb, mint a másik. De egyének közreműködését sokkal nehezebb értékelni. Amíg egyes emberek az egyes funkcionalitások fejlesztéséért felelősek, a többiek támogató szerepet játszanak - másoknak segítenek a funkciókat megvalósítani. Az ő közreműködésük nagyon is számít a teljes csapat termelékenységében - de nagyon nehéz megérteni az ő személyes teljesítményüket, anélkül, hogy a csapatban dolgozó fejlesztő lennél.
És ha ez az egész még nem lenne elég bonyolult, az Economist (2003. szeptember 13-19) közzétett egy cikket a produktivitással kapcsolatos trendekről. Ebben az állt, hogy az újságírók már látják, hogy a 90-es években a termelékenység növekedett az informatikai beruházásoknak köszönhetően. A lényeg azonban az, hogy a növekedés időben lemaradva követi a beruházásokat: "Az informatikai beruházások nem automatikusan növelik a produktivitást; az üzleti gyakorlatot is át kell szervezni ehhez". Ugyanez az időeltolódás történt az elektronikába történő beruházásokkor.
Tehát nem csak az üzleti értéket mérése nehezíti az életet, hanem még az időeltolódást is. Vagyis, talán a csapatod termelékenységét egészen addig nem fogod tudni jól megmérni, amíg el nem telik néhány év az általuk fejlesztett szoftver kiadását követően
Teljesen érthető, hogy a termelékenység mérése miért olyan csábító cél. Ha tudnánk ilyet, akkor sokkal könnyebben értékelhetnénk a szoftvereinket, mint ahogy most ezt meg tudjuk tenni. De egy rossz mérés csak még rosszabbá teszi a dolgokat. Ezért szerintem érdemes beismernünk, hogy milyen tudatlanok is vagyunk e területen valójában.
