Hiszem, hogy Magyarország megérett egy Jira-nál fejlettebb eszköz bevezetésére és használatára...

Sebesség a Szoftverfejlesztésben II.

2016/11/12. - írta: Csaba Szirják

Speed in Software Development (fordítás)

Előző rész: Sebesség a Szoftverfejlesztésben I.

A Szoftverfejlesztés Sebességének Modellje

Kezdjük egy áttekintő nézettel, megijesztelek már az elején. A kép meglehetősen rémisztőnek tűnik, de bízz bennem, el fogom magyarázni az utolsó bitig. A végén lesz egy erőteljes eszközöd amivel analizálhatsz hasonló problémákat.

map2

A diagramon olyan dolgok és tevékenységek vannak, amik valahogy érintik a fejlesztés sebességét. A zöld azt jelenti, hogy egy tevékenység növeli a sebességet. Minél több van, annál jobb. A sárga jelzi valaminek a maximalizálhatóságát. Például: felhalmozhatsz technológiai adósságokat (technical debt) és növelheted a sebességet (Short term boost), de ha túl sokat halmozol fel, akkor az jelentősen le fog téged lassítani. A piros dolgok lassítják a fejlesztést, minél kevesebb van belőlük, annál jobb. Aztán, a zöld nyilak pozitív hatással vannak az adott tevékenységre. Például a fókuszált munka (Focused Work) növeli a fejlesztés sebességét (Development Speed).

positive

A piros nyilak a csökkenését jelentik. Például a több fejlesztői jártasság (Skills) csökkenti a rendszer bonyolultságát (system complexity) (a jó fejlesztők kevésbé bonyolult rendszereket hoznak létre).

negative

Most nézz az ábrára és tegyél fel hasonló kérdéseket: Mik növelik a fejlesztés sebességét? Mik csökkentik azt? Mit tehetünk, hogy gyorsabban (és jobb!) szoftvereket hozzunk létre? A modell néha hiányos lehet, de ez rendben van. Szabadon módosíthatod.

Most pedig elmagyarázom a modell különböző részeit, analizálom azokat és ötleteket adok a sebesség növelésére. Remélem, hogy ez egy jó kezdet lesz ahhoz, hogy mélyebben kezdj el gondolkodni és még több megoldást generálj. Vágjunk bele.

Jártasság és Tapasztalat

Elég nyilvánvaló, hogy a jártasság (Skills) növeli a fejlesztés sebességét. A jártasabb fejlesztők gyorsabban oldanak meg problémákat és kevésbé bonyolult rendszereket alkotnak. Néhányan azt mondják, hogy 10x-es hatékonysági különbség is lehet egy igazán jártas és egy kevésbé jártas fejlesztő között. Habár nem hiszem, hogy ez egy általános vélekedés.

skills

A következő triviális kérdés, hogy mit lehet tenni a fejlesztői jártasság növelése érdekében? Először is, toborozhatsz  kizárólag tapasztalt fejlesztőket. Ez működhet, de ez a modell nem skálázódik túl jól. A tapasztalt emberek hajlamosak nehéz problémákon dolgozni, amik igénylik a jártasságukat. Hány cég van a világon, ami valóban nehéz feladatokon dolgozik? Nem túl sok. A másik oldalon ott van, hogy ha a terméked nem egy rakéta tudomány, akkor nincs szükséged csupa PhD-s fejlesztőre a csapatodban. Szóval minden cégnek különböző jártasságokra van szüksége. Egy tapasztalt fejlesztő a Google-nél nem egyenlő egy tapasztalt fejlesztővel egy outsourcing-os cégnél.

Rendben van, meghatároztad hát, hogy mit jelent a céged számára a Tapasztalt Fejlesztő, de még mindig küzdesz azért, hogy eleget találj belőle. A skálázhatóság problémája. Emlékszel? Szóval nem annyira tapasztalt fejlesztőket is fel kell venned, hogy növekedhess. Oké, de abszolút olyanokra lesz szükséged, akik szeretnek új dolgokat tanulni.  Hogy szerezhetne bárki is jártasságot, ha nem szeret tanulni? Kíváncsiság, élénk elme, szenvedély — ezek az értékek fontosak.

Egy cégnek meg kell adnia mindent, hogy segítse az embereket a tanulásban. Itt van néhány lehetőség:

Vegyél meg minden könyvet, amit az emberek kérnek

Minden cégnek kell, hogy legyen egy jó könyvtára. A legtöbb kiváló fejlesztő tudom, hogy sokat olvas. Nem tudod az embereknél az olvasást erőltetni, de nagyon könnyen elérhetővé teheted, hogy egy jó könyvet csak megragadjanak és elkezdjék olvasni.

library

Küldd az embereket konferenciákra

A legtöbb ember azt gondolja, hogy a konferenciák az új tudás forrásai. Talán, de én azt gondolom, hogy sokkal inkább a szenvedélyre hatnak. A konferenciák motiválnak, hogy folyamatosan tanulj, próbálj ki új dolgokat, a legjobb esetben pedig irányt mutatnak.

Szeretek olyan konferenciákat látogatni, ahol a témák újak számomra. Például, amikor elkezdtem User Experience-t tanulni, két nagy konferenciára mentem el. Az első különösen hasznos volt, a második már nem annyira.

Szervezz tanulással kapcsolatos eseményeket

Az egyik legjobb módja hogy meganulj valamit az, ha könyvet írsz a témáról. Kevésbé extrém módja pedig az, ha felkészülsz egy prezentáció megtartására, vagy egy workshop-ra. Egy cég szervezhet belső konferenciát, hogy fellendítse ezt a folyamatot. Nem mindenki kész arra, hogy közönség előtt beszéljen, de többen megpróbálják. A mi cégünkben 2 napos konferenciák vannak 6 havonta. Nincsenek külsős előadók, minden prezentációra a mi csapatunk tagjai készülnek fel.

tau-conf

Egy másik jó gyakorlat, ha teret biztosítasz közösségi meetupoknak. Van egy kis konferencia termünk, ahol 80 ember fér el és boldogok vagyunk, hogy menedéket adhatunk a helyi UX közösségnek, .NET közösségnek és iOS közösségnek.

Természetesen van más módja is annak, hogy külsős eseményeket szervezz.

Biztosíts időt az új dolgok tanulására

Ez nem úgy hangzik, mint egy kötelező gyakorlat. Lehet, hogy nem. Mégis, ha egy cég szabadidőt biztosít kizárólagosan tanulásra, az fantasztikus. A híres 20%-os Google idő egy jó példa (vannak pletykák miszerint ez megszűnt, de ezek a pletykák nem bizonyítottak). Nálunk a Targetprocess-nél Orange Friday-ek vannak.

orange-friday

Minden péntek arra van szánva, hogy személyes projekten keresztül tanuljunk. Többen Coursera kurzusokat csinálnak, cikkeket olvasnak, vagy új technológiákat próbálnak ki. Lehetetlenség mérni ezeknek a tevékenységeknek a hatékonyságát, de itt van néhány haszon:

  • Tény, hogy ez azt jelenti 4 munkanap van egy héten. Az ötödik nap az nem egy tipikus munkanap.
  • Csábító azoknak az embereknek akik szeretnek tanulni, így ez egy hatalmas plusz a toborzásnál.
  • Könnyebb megtartani az embereket, mióta lehetőségük van kipróbálni valami újat, amit szeretnének.
  • Az emberek gyorsabban szereznek új jártasságokat.

Egy hátránya van csak — ez valószínűleg csökkenti az össz fejlesztési sebességet. Az emberek egy nappal kevesebbet dolgoznak, ami direktben 20%-kal csökkenti a fejlesztés sebességét. Mi az ami ennél fontosabb? Az attól függ. Ha nagyon közel vagy egy release-hez, taktikailag nem túl bölcs minden pénteket képzésre költeni, ha azonban Maraton üzemmódban (szerk: lásd előző bejegyzés) vagy — érdemes lehet.

logo

szemtelen hirdetés
A Targetprocess-nél dolgozom — ahol egy igazán király vizualizációs projektmenedzsment szoftvert készítünk. Ha egy agilis eszközre van szükséged, ami támogatja a Scrum, Kanban vagy egyéb típusú projekteket, akkor próbáld ki

Segíts az embereknek jobban megérteni a domain-t

A domain tudás alapvető minden szoftverfejlesztő számára. Segít a problémákat mélyebben megérteni, jobb és gyorsabb megoldásokat szállítani és csökkenteni a feladatok újbóli elvégzését. Lehetővé teszi a fejlesztőknek, hogy korábban észrevegyék a rossz megoldásokat. Domain tudás nélkül a fejlesztők vakon készítik el azt, amit a Product Owner-ek vagy a Business Analyst-ek kérnek. Egy jó domain tudással egy fejlesztő könnyen talál ki kiváló megoldásokat saját maga, vagy lesz tagja a UX csapatnak, hogy különböző megoldásokról ötleteljenek.

A domain tudás különösen fontos, ha terméket fejlesztetek. Az élet rövid, és nehéz sok domaint alaposan megismerni. Így a végén a megfelelő dolgokra kell fókuszálni. Legjobb ha megtalálod, hogy mi hajt téged és fertőz meg.

OK. Most beszéljünk egy kicsit a tapasztalatról.

Tapasztalat

A munkatapasztalat szintén sokféleképpen hat a sebességre. Egy 20 év tapasztalattal rendelkező fejlesztő jellemzően gyorsabban old meg egy problémát, mint egy 5 év tapasztalattal rendelkező (mégha valahogy azonos jártasságaik is vannak). Megjegyzem, hogy a jártasság (skill) nem egyenlő a tapasztalattal (experience). Lehet egy csomó tapasztalatod egészen irreleváns területeken és így nem fogod tudni megoldani a legtöbb cégre jellemző problémát.

Személyesen azt gondolom, hogy a jártasság az a tényező, ami a leginkább befolyásolja a szoftverfejleszés sebességének növekedését. Ha van egy csokor tapasztalt fejlesztőd, designered és tesztelőd — jó esélyetek van arra, hogy valami jót hozzatok össze. Ha csak kezdő fejlesztőid vannak — szinte semmi sem segíthet, hogy növeld a sebességet.

A legtöbb cég a problémák széles körével küzd: némelyik ezek közül egyszerű, némelyik kihívásokkal teli. A tapasztalatlan fejlesztőket minden felvillanyoz, hiszen minden probléma új tudást jelent számukra. A tapasztalt fejleszők válogatósabbak és sokkal jobb, ha megfelelő komplexitású feladatot kapnak. Így jó, ha széles skálája (jártas/tapasztalt) van az embereknek a szervezetben, de az átlag jártasságnak magasnak kell lennie. A megfelelő egyensúly persze minden cég számára egyedi, de legalább gondolkozz el a problémán.

Folytatás hamarosan...

Az erdeti cikk itt található: 

https://www.targetprocess.com/articles/speed-in-software-development/

komment

A bejegyzés trackback címe:

https://tpxp.blog.hu/api/trackback/id/tr3911955789

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

süti beállítások módosítása