Tartalomjegyzék:
Fürge szoftverfejlesztő csapatnak lenni minden bizonnyal mást jelent a különböző emberek számára. A befogadás mértéke nagyon széles spektrumban létezik, és nyilvánvalóan csak kevés szervezet gondolja úgy, hogy jól csinálja. A VersionOne 2017. évi agilis állapotfelmérése szerint válaszadóik 80% -a azt állítja, hogy „még mindig érlelődik vagy alacsonyabb szinten van”. Sajnos a fejlesztői csapatok gyakran nem fektetnek sokat az iteráció „tanulás” részébe. Sietni akarunk és véget vetni a Scrum szertartásoknak, hogy visszatérhessünk a kódíráshoz. Végül is annyi munka van! De vajon valóban az elégtelen kódolási idő a probléma?
Sokunk számára a tűzoltást is pontosan fel lehet sorolni munkaköri leírásunkban. Minden nap munkába járunk, tudván, hogy készen kell állnunk arra, hogy egy pillanatra lecsússzunk az oszlopon, megragadjuk a kalapunkat és felugrunk a teherautóra. Elfogadjuk, ahogy a dolgok vannak, és feltételezzük, hogy semmit sem tehetünk ellene. De mi van akkor, ha küzdelmeink kiváltó oka a hatékonyság súlyos hiánya? Mindenki tudja, mennyire fontos, hogy jobban csinálja, mint az a másik cég. Úgy tűnik, egyszerűen nem jutunk el oda - úgy tűnik, nincs meg a sávszélességünk. A menedzserek több embert adnak hozzá, és növelik szervezetük méretét, és továbbra is ugyanazok a küzdelmek. Úgy tűnik, nem lehet túltenni a púpot, mert a csapatok nem fejlesztik hatékonyan a szoftvert (és nem vagy egyedül).
A hatékony fejlődés alapelvei
Pixabay
Mi okozza tehát, hogy nem vagyunk hatékonyak? Legtöbbünk számára az első dolog, ami az automatizálás hiánya jut eszünkbe (automatizált összeállítások, telepítések, tesztelés). "Ha elegendő automatizálásunk lesz, az élet jobb lesz." Sajnos ez csak a megoldás része. Vegye figyelembe az átdolgozásnak a projektre gyakorolt hatását. A funkció létrehozásának leghatékonyabb módja az, ha egyszer helyesen építi fel, és soha többé nem megy vissza, és nem érinti újra. A hibák, a refaktorálás és más hasonló tevékenységek lényegében újranyitják a beteget, miután elhagyta a műtőt, és ezzel eredendő kockázat jár. Nem tudjuk kiküszöbölni az újrafeldolgozást, de mindenképpen törekednünk kell annak minimalizálására.
"De az agilis nem veszi át az átdolgozást (pl. Refaktorálást)?" Valójában így is van, mert az agilis megalkotói megértették, hogy az átdolgozás két fő oka az előre nem látható körülmények és a változó üzleti követelmények. Kiderült, hogy az emberek szörnyen jósolják a jövõt. Az agilis alkotók azt is megértették, hogy az eredménytelenség óriási hozzájárulása az, amit a fejlesztők „aranyozásnak” neveznek - a funkcionalitásba való csomagolást úgy gondoljuk, hogy valaki használni fogja, annak ellenére, hogy a végfelhasználók soha nem is kérték. Olyan, mint a sertéshús a szoftvertermékhez - teljes időpazarlás. "Ne építsen űrállomást, amikor csak egy Volvo-t kérnek." Tehát a vállalatok okosan kezdték elhagyni a sertéshúst, és helyette átépíteni az újrafeldolgozást, csak akkor adtak hozzá funkcionalitást, ha egyértelmű szükség van rá. De nem csak az élet kiszámíthatatlansága ösztönzi az átdolgozást?
A funkciók fejlesztésének bármely szakaszában kimaradt részletek végül időt és pénzt pazarolnak. A hatékony, előzetes együttműködés idővel rengeteg átdolgozást takarít meg (az elmulasztott követelmények kezelése, rövidlátó tervezés stb.). Mindannyiunknak van vakfoltja, és mindannyiunknak szüksége van további szemkészletekre. Számos fejlesztőcsapat ezt a háttérbe foglalja a kód felülvizsgálata során, de sokkal kevesebb energiát fordít az együttműködésre már a korai szakaszban, amikor a problémákat olcsón és minimális befektetés után meg lehet oldani.
Hányszor valósított meg egy funkciót, és a vége felé talált olyan jelentős hibákat, amelyeket el kellett volna találni a követelmények / tervezési megbeszélések során? Ez olyan, mintha megpróbálna Atlantától Montgomeryig vezetni, és néhány óra múlva rájönne, hogy véletlenül inkább Birminghambe hajtott. Mennyi időt töltött el a kód megfelelő megszerzésével, hogy csak később nyissák meg a beteget, mert a jelentős követelmények nem teljesültek? A kollektív intelligencia kihasználása abszolút időt és pénzt takarít meg, ehelyett azonban a fejlesztők gyakran elszigetelten dolgoznak a funkciókon.
Hagyományos rajzás
Pixabay
A hagyományos rajzás azt jelenti, hogy a csapat közösen dolgozik a történeteken több emberrel, akik egyszerre dolgoznak egy kis funkción, lerövidítve a visszacsatolási ciklust és csökkentve a szolgáltatás teljes befejezési idejét (azaz megosztani és meghódítani). Ez lényegében az egyes tudományterületeken (háttérfejlesztők, felhasználói felület fejlesztők stb.) Rajong. A fejlesztés megkezdése előtt a felhasználói felület fejlesztői azon dolgoznak, hogy azonosítsák az egyidejűleg elvégezhető független feladatokat. Megbeszélik az interfész pontjait, így mindenki tudja, hogyan illeszkedik darabja az egészbe. A csapattagok ezután folytathatják a rájuk ruházott feladatokat, és az integráció során a végén mindent összehozhatnak. A gyakori elkövetések és az időszakos kódellenőrzések segítenek abban, hogy minden a síneken maradjon. Ehhez a megközelítéshez a fejlesztők együttműködésére van szükség,ami amúgy is jobb végeredmény előállításában segít. Gyakran elsőbbséget élvezünk a kód (bármelyik kód) írására fordított idő helyett az eltöltött idővel, hogy megbizonyosodjunk arról, hogy nem rossz kódot írunk. Ha figyelembe vesszük a potenciálisan megtakarított időt, akkor az érték egyértelművé válik.
Feloldás feloldása
Pixabay
A rajzás másik értékes megközelítése, hogy a csapatot a függőség mérséklésének korai szakaszában kell összpontosítani annak érdekében, hogy megkönnyítsék az egyidejű fejlődést a tudományterületek között. Vegye figyelembe a felhasználói felület természetes fejlődésének áramlását. Az automatizálási tesztelők (SDET) egy működő felhasználói felülettől függenek, a teszteléshez, a kezelőfelület-fejlesztők egy működő háttér-API-tól, a háttér-fejlesztők pedig a konfigurációtól, az adatbázis-frissítésektől és az automatikus összeállításoktól / telepítésektől függenek. Tehát előfordulhat, hogy a felhasználói felület fejlesztői nem kezdik meg a munkájukat, amíg az API-k nem készek, és az SDET-ek nem indulhatnak el, amíg a szolgáltatás nem fejeződik be. Mindegyik tudományág elszigetelten működik, ami akadályozza az együttműködést, mert az emberek, akikkel kapcsolatba kell lépnie, elfoglaltak más dolgokon.De mi lenne, ha korábban csökkentené a függőségeket, és lehetővé tenné, hogy a tudományterületek mindegyike egyidejűleg működjön ugyanazon a tulajdonságon?
Íme néhány példa:
1. Telepített funkcionális felhasználói felület csonkokkal
Az SDET-ek feloldása érdekében a felhasználói felület fejlesztői működőképes felhasználói felületet adhatnak nekik, amely épp annyira működik, hogy teszteket írhassanak nekik. A Backend API integrációja és a CSS stílusok továbbra is függőben lehetnek, mivel az olyan automatikus tesztkeretek, mint a Selenium, nem fognak törődni azzal, hogy ezek a dolgok befejezetlenek. Ez mind füst és tükör lehet. Bár olyan változások történhetnek, amelyek némi átdolgozást okoznak, a tesztek korai megkezdésének előnyei meghaladják ezt a kockázatot.
2. Telepített Backend API-k (elakasztott, kemény kódolású adatok)
Olyan háttér-API-k biztosítása, amelyek ellen a felhasználói felület fejlesztői tesztelhetik, lehetővé teszi a kezelőfelület és az API (k) közötti integrációs problémák korai felismerését. Néha kiderül, hogy a megadott API nem felel meg a kezelőfelület fejlesztőinek igényeinek. Előfordulhat, hogy hiányzik a teljes hívás, az aláírás hibás, vagy az adatok felépítésével lehetnek problémák. Ha megszakad a kapcsolat, akkor még korán megtudhatja, mielőtt bármi megkeményedne.
3. Hozzon létre az új alkalmazások és szolgáltatások HelloWorld verzióját.
Ha új szolgáltatásra van szükség (pl. Mikrotermék), hozza létre a repót, és készítse el a szolgáltatás „hello world” változatát. Ez lehetővé teszi, hogy a dev-ops erőforrások a szolgáltatás tényleges fejlesztése előtt elindulhassanak a Jenkins jobokon és telepítési szkripteken.
Ezek az optimalizálások megkönnyítik a korai visszacsatolási ciklust, ahol valaki azt mondhatja, hogy „valami másra van szükségem”, mielőtt a fejlesztés befejeződik a változtatást igénylő komponensen.
Csomagolás
Hihetetlenül fontos, hogy rájöjjünk, hogyan lehet lerövidíteni az általunk fejlesztett funkciók piacra jutásának idejét. Az üzlet nem ér értéket azzal, hogy rengeteg folyamatban lévő funkcióval rendelkezik, és a fejlesztőknek nagy szükségük van a funkciók gyors megvalósítására, hogy a hibák a lehető legközelebb kerüljenek az injekció beadásának pontjához. A fejlesztőknek is nagy szükségük van egymásra, még akkor is, ha csak kódot akarnak írni. Jobb minden érintett számára, beleértve a végfelhasználót is, aki csak jobb terméket szeretne. Ha nem adod meg nekik, akkor máshová mennek megkeresni.
A rajzás rendkívül értékes eszköz a szervezet eszköztárában, ha az emberek időt szánnak arra, hogy megtanulják, hogyan kell csinálni. Ez nem egy keret vagy akár egy tevékenység - ez egy gondolkodásmód. Minden felhasználói történethez a csapat tagjai két kérdést tesznek fel maguknak:
- Hogyan szervezhetünk feladatokat ehhez a történethez, hogy egyszerre többen is közreműködjenek?
- Mi a minimum, amit meg kell tennem ahhoz, hogy feloldhassak valakit, aki rám vár?
Mi lenne, ha csapata gyorsan összeépítené a funkciókat, ahelyett, hogy lassan önállóan építene egy csomó funkciót? Valójában válaszolhatnak a változó üzleti követelményekre és kielégíthetik a vállalkozás igényeit, amikor a vállalkozásnak szüksége van rájuk. A versenytársak félnének tőled - az ügyfelek szeretnek. Ez egy sikeres üzleti recept.
© 2017 Mike Shoemake