Sikeres szoftverfejlesztés: a pontosság, ellenőrzés és irányítás fontossága (I. rész)

BEVEZETÉS

Félő, hogy az összetettsége miatt megbomlik a szoftvergyártás eddig bevett folyamata. A mobil- és felhőmegoldások, valamint a fogyasztók növekvő nyomása ösztönözte változások viharos sebessége arra kényszerítik a szervezeteket, hogy egyre darabosabban működjenek.

A hagyományos IT osztályok harmadik féllé kezdenek válni az ügyfeleik által igényelt szakmai tudás és szállítási határidők tekintetében. Ugyanakkor a korábban esetleg meglévő tulajdonosi érzésüket alámossa a személyes eszközök beáramlása a munkahelyre és az olyan „IT projektek” növekvő száma, amelyek kívül esnek az IT osztályon.

A fejlesztési vezetők kétszeresen is érintettek: nemcsak ők a felelősek az ügyfeleik által igényelt fogyasztóbarát alkalmazások létrehozásáért, de mindezt olyan lazán összerakott csapatokkal kell teljesíteniük, amelyek maguk is mobilok, és eltökéltek a saját technológiájuk és módszereik használatára; végül is a fejlesztők is fogyasztók.

Természetesen a felsorolt jelenségek egyike sem új, de az innováció és a korábbi állapotok felforgatásának méretei és sebessége példa nélküliek. Ahhoz, hogy fenntartsuk a hatékony szoftvergyártói láncot és megfeleljünk az ügyfelek támasztotta követelményeknek ilyen sokféleség és fragmentáltság mellett, új megközelítésre van szükségünk.

A sikeres szoftverfejlesztő csapatok visszanyúlnak az alapokhoz, megvizsgálják a más iparágakban történteket, azok tanulságait, és végül erőfeszítéseiket arra összpontosítják, hogy egy hármas alapra épült szoftverfejlesztési ökoszisztémát hozzanak létre. Az alap három eleme: pontosság, ellenőrzés és irányítás.

Szoftverfejlesztés a 21. században

Milyen gyakran hallottuk, hogy a szoftverfejlesztés nem hatékony és hibákra hajlamos? Úgy tűnik, az évek óta tartó mérések ezt általában alá is támasztják; a projektek későn érkeznek, túl sokba kerülnek és olyan funkciókat tartalmaznak, amelyeket senki nem kért. Gyakran ér minket a bírálat, hogy miért nem veszünk példát más iparágakról és esetlen kamaszként leszidnak minket a lassú munkavégzésért és a dolgok elrontásáért. Miért nem lehetünk olyanok, mint a nagyobb testvéreink?

Életkorunk csak viszonylagosan zsenge: már ötven is elmúltunk. Ez csak elég ahhoz, hogy tudjuk hogyan kell valamit hatékonyan létrehozni, majd bevezetni a piacra? De még a legújabb tanulmányok szerint is úgy tűnik, hogy ez az esetek kevesebb mint 40%-ában sikerül csak.

A Standish Group 1994 óta méri fel a szoftverfejlesztés hatékonyságát, és az idei 39%-os adat valójában javulást mutat a projektek sikerességének tekintetében. A Gartner becslése ennél derűlátóbb; szerinte az időben befejezett projektek száma 55,8%, a költségkereten belül elvégzetteké pedig 67,5% volt 2013-ban, de bőven van még mit fejlődni különösen, ha figyelembe vesszük, hogy ezek az adatok átlagértékek, vagyis sok látványos kudarcot is rejtenek. Még szomorúbb, hogy a Standish szerint „a funkciók 50%-át alig, vagy egyáltalán nem használják”.

A dolgok még nyugtalanítóbbak, ha a Gartner 2012-es előrejelzésére gondolunk: „2015-ben a mobil fejlesztések 20%-kal csökkentik az alkalmazásfejlesztői csapatok hatékonyságát”; az állítás pontosságát 2013-ban újra felmérték ezzel az eredménnyel:

„Az előrejelzésünkhöz vezető körülmények nem pusztán fennmaradtak, de romlottak. A mobil fejlesztések száma csak növekedni fog. Még mindig nem dolgoztunk ki megfelelő fejlesztési folyamatokat.”

Gartner, 2013. 

A változás viharos üteme alapján azt is mondhatnánk, hogy a termelés és hatékonyság szintjének puszta megtartása is eredmény. És ebben van némi igazság. De csak üres igazság, ami nem sokat segít egy olyan üzletágon, amely innovációra és a növekedésre törekszik. Ha gyorsan kell loholni ahhoz, hogy egy helyben maradjunk, az nem kellemes, és a Gartner által megjövendölt még nehezebb idők ígéretét tekintve nem is elég jó.

Az alkalmazáskiszervezés változó helyzete

Minden informatikai felsővezető egyik legfontosabb szempontja az innováció. Mivel a fogyasztói nyomás a munkahelyen is érződik, az IT-részlegek ráébredtek, hogy a meglévő szakértelmüket újabb jellegű szakértelemmel kell gazdagítaniuk: olyan emberekre van szükségük, akik értik és ismerik a mobilalkalmazások fejlesztését és a felhasználói élményt tekintetbe vevő tervezés. Olyanokra akik bele tudják venni a közösségi és felhőalapú megoldásokat a portfóliójukba. Ilyen szakértelmet nehéz találni és általában még nehezebb az ilyen munkaerőt fel is venni a hagyományos fejlesztő csapatokba. Ezért a cégek egyre inkább külsős szolgáltatók segítségét kérik.

A nagy kiszervezők olyan gyorsan próbálnak megfelelni az igényeknek, amennyire csak tudnak, de az ügyfeleik a növekvő számú kicsi „szakosodott” ügynökségekhez fordulnak, akik az adott szükséges szakértelmet tudják nyújtani, ezzel is tovább fragmentálva, darabolva a szoftverfejlesztői láncot.

Az Agile módszerek egyre gyakoribb alkalmazása a problémák másik területe. Mivel széles körben elfogadott, hogy ez az egyetlen mód amellyel az információtechnológia jelentősen előrébb juthat, a vezetők külső szakértelmet keresnek a vállalat belső Agile módszerben meglévő lehetőségeik bővítésére. A Gartner egy másik előrejelzése az említett jelentésben: „2016-ra az Agile megoldások több mint 50%-a meglehetős kihívásokkal fog szembenézni, mert nem lesz elég Agile-hoz értő szakember”, és sok szervezet “tervezni fogja, hogy külső szakértelmet hoz be, hogy segítsenek az Agile módszer használatára történő átállásban”.

Az irány világos, és az is ezt bizonyította, amikor nemrég közvélemény-kutatást végeztek informatikai felsővezetők körében. A válaszadók azt állították, hogy két éven belül a tesztelés és a fejlesztés túlnyomó részét (56, illetve 54%-át) a cégen kívül fogják végeztetni. Amikor az okokról kérdezték őket, a dobogós válaszok nem meglepően a sebesség (56%), a szakértelem (51%) és a költségek (50%) voltak.

Ebben az irányzatban az az aggasztó, hogy a válaszadók 23%-a jelezte, hogy a kiszervezett projektek nem teljesítették a követelményeket, 31%-uk pedig az idővel vagy a költségekkel kapcsolatos problémákról számolt be. A kudarcok első számú oka az volt a beszámolók szerint, hogy a követelményekben túl sok változás történt a projekt során.

Múltbéli tanulságok

Ahhoz, hogy a szoftverfejlesztés megszabaduljon a régóta fennálló nem megfelelő hatékonyságtól, és javítsa a projektek sikerességi mutatóját egyértelmű, hogy változtatni kell mind a folyamatokon, mind az eszközök felhasználásán. Ennek során a viszonylag fiatal szoftverfejlesztő üzletágnak sokat kell tanulnia más termelő iparágaktól. A gépkocsiiparnak például több mint 100 éve volt a ma látott kifinomult, roppant hatékony ellátó lánc kifejlesztésére.

Amikor a Ford Motor Company előállt a T-modellel az akkori gyártási módszerek mellett, nem tudott megfelelni a piaci igényeknek, hiszen az első teljes gyártási hónap során mindössze 11 autót készítettek. A folyamat csak négy évvel később korszerűsödött annyira, hogy mindössze 93 perc kellett egy gépkocsi összeszereléséhez, és így a Ford abban az évben több autót gyártott, mint az összes vetélytárs együtt.

Az ilyen hatékonyság azonban kompromisszumokkal járt, amelyek egyikét Henry Ford emlékezetesen a „bármilyen szín, csak fekete legyen” szabályban fogalmazta meg 1914-ben arra utalva, hogy korlátozásokra van szükség, ha azt akarjuk, hogy a futószalag-módszer hatékonyan működjön.

Bármilyen szín, csak zöld legyen

Könnyű párhuzamot vonni a kereskedelmi szoftvertervezés hajnalával. Henry Ford folyamatjavító újításai jogosan érdemelnek dicséretet, de nem nyújtottak elég rugalmasságot és csak az akkori statikus időkben lehettek sikeresek. A másik hasonlóság, hogy a Ford-féle futószalagos gyártásnál nem is merült fel az ügyféligényen alapuló „pull” termelés, és elkerülhetetlenül hajlamos volt a túltermelésre. Így annak ellenére, hogy nagyon is innovatív volt, ennél több változásra volt szükség, hogy a gépkocsigyártó ipar a mai helyzetébe kerüljön, amikor sok választási lehetőséggel tud minőségi terméket előállítani a gyorsan változó, dinamikus környezetben.

A szoftverfejlesztés most kezd kilábalni egy hasonló bajból. A mai gyorsan változó, meglehetősen bizonytalan körülmények igencsak messze vannak attól a világtól, ahol a modern kereskedelmi szoftverfejlesztés született, amikor a követelmények adottak voltak, a szoftverek nagyrészt azokat a jól bevált kézi eljárásokat képezték le, amelyek automatizálására készítették őket, és a hosszadalmas tesztelési idő éppannyira elfogadott volt, mint a felhasználói élmény korlátozottsága.

Lehet, hogy sok szervezetben folytatódik a vízesés-modell de – ugyanúgy, ahogyan Ford aprólékosan ügyelt a követelményekre, és ahogyan a korai szoftvergyártói láncra hatottak a szigorú folyamatok – a gépjárműipar következő jelentős újításai (a „lean”, vagyis karcsú folyamatok bevezetése) elkezdtek utat találni a szoftverfejlesztésbe.

A „lean” fejlesztés a hulladék kiküszöbölésére és az értékteremtésre összpontosít az ügyfél meghatározása szerint, és ehhez magasabb szintű együttműködésre van szükség a vállalattulajdonosok, alkalmazástervezők, tervezők, fejlesztők, tesztelők és a szoftvergyártó lánc más tagjai között, a falakon belül és kívül.

Mindenki számára nyilvánvaló, hogy a szoftvergyártó láncban nem működik az összes henger.

Telnek az évek, és ahol a módszereket korszerűsítették, még ott is a projektek meghiúsulnak a következők miatt:

• A folyamatos precizitás hiánya – az átadott termék nem felel meg a követelményeknek és ez késéseket, valamint feszültséget okoz az üzletág szereplői és az IT között.
• Korlátozott ellenőrzése – Ha csak azért tesztelünk, mert nincs elég hiba, és nem az üzleti specifikációkat vetjük össze a lefejlesztett funkcionalitással, csak tetemes mennyiségű újra elvégzett munkát és még több elégedetlenséget jelent.
• Elégtelen irányítás – amikor a változásokkal és irányítással kapcsolatos problémák miatt nem teljesülnek a határidők, nem sikerül az ügyféllel szemben vállaltaknak megfelelően teljesíteni, akkor felmerül a jó hírnév kockáztatásának veszélye.

Bár sokat tudunk az egyszerű futószalag-szerű termelésről, vagy az ügyféligényen alapuló termelés használatáról, de ha nincs megfelelő eszközünk/technológiánk irányítani ezeket a folyamatokat, továbbra is kudarcra lesz ítélve munkásságunk.

Akár egy nagy, rugalmatlan vízesés-modellben működünk, akár egy potenciálisan kaotikus Agile elrendezésben, ha nem élünk a megfelelő korszerű technológiákkal az egyes csapatok munkateljesítményének támogatására, továbbra is ugyanazon az alacsony hatékonysági szinten fogunk gyötrődni, mint az elmúlt évtizedben. A teljesítményünk pedig a sok utómunkától és a rosszul meghatározott követelményektől lesz sújtva.

Szerző: Borland