Állandó téma minden szervezetben, annak méretétől függetlenül, az agilitás. Mit is jelent ez, és milyen kihívásokkal szembesülhetünk ennek kapcsán?
Ez a cikk egy három részes sorozat második része. Ha a többit még nem olvastad, tedd meg itt:
6. A fejlesztői csapaton belül az információátadás leghatásosabb és leghatékonyabb módszere a személyes beszélgetés.
➔ Korábban nagyon gyakori volt (és még ma sem ritka) az, hogy az információt dokumentációk formájában osztják meg a részt vevő felek között.
Sokan hajlamosan lebecsülni az információátadás fontosságát. Kutatásokból tudjuk, hogy az információ nem egyenlő a tudással, az információ csak a tudás részhalmaza. A tudásnak egy része megfogalmazható a tulajdonosa által (explicit tudás), egy része viszont hallgatólagos (angolul: tacit) tudás. Legtöbbször a birtokosa sincs tudatában e titkos tudás meglétének, amit szociális interakciókon keresztül lehet megismerni (kétirányú személyes beszélgetés), mivel ehhez érzékelnünk kell a másik hangjából kicsendülő és a testbeszéde által elárult érzéseit, vagyis értelmeznünk kell a metakommunikációját. A reakciónk a másikból is újabb reakciót vált ki, tehát kellően nyitott hozzáállás esetén a dialógus a mélyebb rétegek feltárása felé tolódhat. Bizonyos források szerint egy vállalaton belüli tudás 80%-a tacit tudás.
A megfelelő tudásátadás a fejlesztői csapaton belül is kritikus fontosságú (a kód tanulmányozása önmagában nem elégséges), de emellett az ügyféloldallal/felhasználóval is kiemelten fontos a megfelelő tudásmegosztás. Ugyanis hogyan szállíthatnánk megfelelő terméket, ha nem ismerjük a felhasználóinkat és a szándékaikat?
A megfelelő tudásátadás, tudásmegosztás nem csupán a közös megértés alapját teremti meg, de általa nagymértékben növelhető a csoporton belül a felek közötti kölcsönös bizalom. Ennek eredményeként partneri viszonyok létesülnek, továbbá leépülnek a hamis feltételezések, előítéletek, elenyésznek a kulturális különbségek, ez az egységérzés megerősödéséhez vezet a csapaton belül, ennek következtében pedig kevesebb lesz az egóharc, és sokkal inkább előtérbe kerül a közös cél.
Kihívások:
- A tacit tudás befogadása szociális interakciókon keresztül lehetséges. Nyitottság, megértés, empátia szükségeltetik hozzá, amikkel nem mindenki rendelkezik.
- Azon szereplők, akiknek a feladata a fejlesztői csapatban az üzleti problémák megértése (pl. PO, BA), gyakran kész tényeket közölnek, ezzel terelve a csapatot a konkrét végrehajtás mint cél felé. Egy ilyen alá-fölé rendeltségi viszonyban háttérbe szorul a tacit tudás megosztásának lehetősége és igénye.
- Sok esetben azért döntenek az információátadás írásos formája mellett, mert a részt vevő felek között nincs megfelelő bizalom.
7. A működő szoftver az előrehaladás elsődleges mércéje.
➔ Ez szorosan kapcsolódik az 1. agilis elvhez (a működő szoftver mielőbbi és folyamatos szállítása).
Még ma is hallhatunk olyan kijelentéseket, hogy egy szoftver 80%-ban van „készen”. Ha a szoftver még nincs használatba véve, akkor szinte biztosra vehetjük, hogy a befejezés még igen messze van. Mindig a használatbavétel után derül ki, hogy mennyi minden nem készült el, vagy nem úgy készült el, és a rendszer tele van hibákkal.
Nem az a fontos, hogy a projekttervben eddig hány feladattal végeztünk, hanem az, hogy szállítottunk-e működő szoftvert, amit aztán használatba vehettek a felhasználók. Ezzel alakítható ki és tartható fenn a megfelelő bizalmi szint a megrendelő és a szállító között. De ha nincs megrendelő, akkor a cégen belül a menedzsment vagy a felettük elhelyezkedő tulajdonosok számára a működő szoftver megléte adhatja az elszámoltatás tekintetében a biztos fogódzót.
Nem csak az elszámoltathatóság miatt fontos a működő szoftver: ha a fejlesztői csapat nem működő, nem használható szoftveren dolgozik, az rövid időn belül alááshatja a projekt iránti elkötelezettségüket és motivációjukat.
Kihívások:
- Előfordulhat, hogy a megrendelő számára a hatékonyság nem elsődleges prioritás (ld. államigazgatás), és/vagy nem szab meg rövid határidőt a szoftver szállítására.
- Sokszor félnek a csapatok a szállítástól, mert bizonytalanok a leszállított szoftver minőségével (működőképességével) kapcsolatban. Ilyenkor a csapat könnyen a könnyebb utat választhatja, és abba a hibába eshet, hogy elhúzza a szállítást. Így végül a minőség valóban romlani fog, mivel nem kényszerítik rá magukat arra, hogy a sűrű release-ek jelentette nyomás hatására fejlődjenek. Az egyedüli megoldást az jelentheti, ha a korai szállítást helyezzük előtérbe, és pl. rendszeres, fix időpontokban szállítunk.
8. Az agilis eljárások a fenntartható fejlesztést helyezik előtérbe. Fontos, hogy a szponzorok, a fejlesztők és a felhasználók mindig képesek legyenek tartani határozatlan ideig egy állandó ütemet.
➔ A fázisokra szakaszolt szoftverfejlesztési projektekben előre meghatározott terv szerint szállítják a projektet. Amennyiben már látszik, hogy a projekt elkezd csúszni a tervhez képest, a vezetők – a hierarchikus rend alapján – nyomást gyakorolnak a szervezetre. Ez sok stresszt, sok esetben túlórázást, és ezáltal csökkent koncentrációt is eredményez. Utolsó pillanatban elkészülő fejlesztések, éjszakai debuggolások és last minute hibajavítások jellemzik ezeket az időszakokat, amelyek műszaki adósság (technical debt) formájában örökre nyomot hagynak a szoftver minőségén.
Az agilis szoftverfejlesztés egyik alapvetése, hogy a tervhez képest bármikor bármi megváltozhat (és rendszerint meg is változik). Ahhoz, hogy elkerüljük a változások okozta állandó frusztrációt, szükséges kialakítani. Ez pedig csak akkor lehetséges, ha a csapat és környezete állandó munkatempó mellett, fenntartható módon dolgozhat.
Kihívások:
- A fenntartható fejlesztés csak olyan környezetben valósítható meg, ahol ez minden fél számára fontos.
- A fenntartható fejlesztés egyre nagyobb kihívássá válik, ahogy a projekt egyre komplexebb lesz. Ezért a fenntartható fejlesztés csakis műszaki kiválósággal és közös akarattal tartható fenn.
9. A műszaki kiválóság és a jó design folyamatos szem előtt tartása fokozza az agilitást.
➔ Ahhoz, hogy kellőképpen gyorsak és mozgékonyak lehessünk (agilitás szó jelentése), a kódunknak is rugalmasnak kell lennie. Rugalmas kód jó designnal és műszaki kiválósággal érhető el.
Kihívások:
- A jelenlegi erősen kompetitív környezetben nehéz feladat kiváló szakembereket találni és felvenni.
- A műszaki kiválóságot érvényesíteni is kell, érvényesülni is hagyni kell. Egyrészt a műszaki szakemberek között is gyakran merül fel véleménykülönbség, másrészt pedig az üzleti oldalt képviselő személy (tipikusan a PO) és a csapat között is megfelelő összhangnak (nyitottság és bizalom) kell lennie, máskülönben a műszaki vélemények nem kerülnek kiaknázásra, vagy elnyomásra kerülhetnek.
Ez a cikk egy három részes sorozat második része. Ha a többit még nem olvastad, tedd meg itt:
