A kód lefagy: továbbra is relevánsak az agilis termékmenedzserek számára?

úgy tűnik, mint egy nyitott ügy.

a kód lefagyása ereklye. A maradék azokból a napokból, amikor a merev vízesés módszertan az egyetlen lehetőséget kínálta a termékfejlesztéshez és a kiadáshoz. A gyártás leállításának és a kiadás késleltetésének—csak a hibák és egyéb funkcionális problémák tesztelésére—nincs helye a modern, agilis termékmenedzsmentben.

legalábbis úgy tűnik, hogy sok agilis Guru konszenzusos nézete van.

de vajon megáll? Miután megkarcolta a leggyakoribb érvek felületét a kódfagyasztás agilis termékkezelésbe történő beépítése ellen, továbbra is archaikusnak tűnnek?

ebben a cikkben megvizsgáljuk a kódfagyasztások agilis termékmenedzsmentbe történő beépítése elleni három fő érvet, és lebontjuk, hogy ezek az érvek hol esnek szét, mindez segít abban, hogy jobb döntést hozzon arról, hogy be kell-e építenie a kódfagyasztásokat az agilis termékmenedzsmentbe.

1. érv: A kódfagyasztás irreleváns és szükségtelen

ez az érv meglehetősen egyszerű és konkrét-a modern agilis módszertanok és eszközök kiküszöbölték a dedikált minőségbiztosítási és tesztelési ablak szükségességét.

az olyan agilis módszerek, mint a társkódok áttekintése, a páros programozás és a rendszer állapotának folyamatos ellenőrzése, sokkal nagyobb rálátást biztosítanak egy alkalmazás vagy funkció teljesítményére a fejlesztés alatt. A hibákat és problémákat könnyebb és valószínűbb, hogy elkapják a fejlesztés során, és megoldják minden dedikált tesztelési és minőségbiztosítási tevékenység előtt.

az új eszközök számos tesztet automatizáltak. Folyamatosan értékelik a kódot, hogy megbizonyosodjanak arról, hogy az mindig tiszta és készen áll a gyártásra. A problémákat valós időben azonosítják, és a riasztásokat azonnal elküldik az ASAP megoldására. Az automatizált tesztek száma már most is széles körű, és folyamatosan növekszik, drasztikusan csökkentve az elvégzendő kézi tesztek mennyiségét.

ezeknek az új agilis módszereknek és eszközöknek az eredménye könnyen látható. A kódfagyasztás során végrehajtott alapvető tesztelési és minőségbiztosítási tevékenységek többsége vagy a fejlesztés során, vagy szoftver által történik. Az Agile – ban a szoftverek és funkciók most sokkal magasabb szintű bizalommal lépnek ki a fejlesztésből, mint korábban, így a dedikált kódfagyasztást egyre nehezebb igazolni.

argumentum 2: Kód lefagy Break a Core Agile Principle

ez a második argumentum egy kicsit magasabb szintű. Alapvetően azt állítja, hogy a kódfagyasztásoknak nincs otthonuk az agilis módszertanban, mert megsértik az agilis módszertan egyik alapelvét— csökkentve a fejlesztés és a kiadás közötti időt.

minél kifinomultabb az agilis megközelítés, annál inkább megpróbálja csökkenteni ezt az időablakot. Az Agile legkifinomultabb jelenlegi megközelítései a folyamatos integráció és a folyamatos fejlesztés (CICD), és céljuk, hogy a fejlesztést apró, növekményes változásokra bontsák annak érdekében, hogy a kód módosításait a lehető leggyorsabban “felszabadítsák”. A CICD legtisztább alkalmazásában a fejlesztés és a kiadás alig létezik különálló fázisként— az új kód szinte azonnal beépül az alkalmazásba, amint elkészült.

ezzel szemben külön fejlesztési és kiadási fázisokat kell fenntartania, ha a kódfagyasztást szeretné telepíteni. Végül, itt él a kódfagyasztás-e két különálló szakasz között. Ahelyett, hogy megpróbálná minimalizálni vagy megszüntetni a fejlesztés és a kiadás közötti időt, mint a legtöbb agilis módszertan, a kódfagyasztás arra kényszeríti Önt, hogy formalizálja ezt az ablakot arra a pontra, hogy köré kell építenie a fejlesztési és kiadási ütemtervet.

ha a kódfagyasztások nem felelnek meg az agilis alapelveknek, akkor nehéz megtenni azt az esetet, hogy továbbra is a módszertanhoz tartoznak.

3.argumentum: a Kódfagyasztás lassabb, gyengébb minőségű kiadásokhoz vezet

ez az utolsó argumentum nagy, és néhány különböző szöget tartalmaz.

először azt állítja, hogy a kódfagyasztás sok bonyolultságot és további mozgó alkatrészeket ad az ütemtervhez, és természetesen növeli annak esélyét, hogy valami rosszul megy, és eldobja az idővonalat. Még akkor is, ha semmi sem megy rosszul, a kódfagyasztással kapcsolatos munka időigényes és kiszámíthatatlan (mivel nem tudja, milyen hibákat talál, vagy mennyi ideig tart a javítás), hogy a kódfagyasztások egyszerű hozzáadásával az ütemtervhez lassabb fejlesztési és kiadási ciklusokat hoz létre.

ezután azt állítja, hogy a kód lefagyása csökkenti a fejlesztőcsapat termelékenységét. Míg általában az agilis, és különösen a CICD, a fejlesztők folyamatosan dolgoznak a termelékenység töretlen láncolatában, a kódfagyások arra kényszerítik a fejlesztőket, hogy előre meghatározott időközönként leállítsák a munkát. Ezzel megtöri a ritmusukat, és arra kényszeríti őket, hogy megpróbálják megkerülni a kódfagyasztási irányelveket, ahelyett, hogy megtalálnák és fenntartanák azt a folyamatot, amely a legtermékenyebbé teszi őket.

végül azt állítja, hogy a dedikált windows létrehozása, ahol nem kap üzleti követelményeket, korlátozza a kiadások funkcióit és funkcióit a fagyasztás előtt, ami alacsonyabb minőségű, kevésbé átfogó szoftverekhez és alkalmazásokhoz vezet.

a kód lefagyásának ügye: vesztes csata?

ezen a ponton elég sötétnek tűnik mindenki számára, aki továbbra is be akarja vonni a kódfagyásokat az agilis módszertanba. Ellenzői ezt a gyakorlatot, hogy néhány nagyon meggyőző érvek, valamint egy átfogó szilárd eset, hogy, mivel a fejlesztés a modern agilis módszertan, kód lefagy váltak:

1. elavult és irreleváns
2. nincs összhangban a modern fejlesztési gyakorlatokkal
3. akadálya a gyors, jó minőségű kiadásoknak

de bár ezek az érvek meggyőzőek és sok pontos információt tartalmaznak, nem golyóállóak. Mindegyikben vannak alapvető hibák, amelyeket meg kell vitatni, mielőtt lezárnánk a kódfagyasztásról szóló könyvet, mint az agilis termékmenedzsment hasznos elemét.

a probléma az 1.érvvel: az automatizált tesztelés nem átfogó

az automatizált minőségbiztosítás és az agilis fejlesztési gyakorlatok növelték a kód minőségét, ahogy azt előállították, ez tény. De csak azért, mert egy darab kód átment az egység tesztelésén, ez nem jelenti azt, hogy valóban gyártásra kész. Még a legkifinomultabb CICD megközelítések sem mindig tartalmaznak kritikus lépéseket—például a regressziós tesztelést -, amelyek biztosítják, hogy egy kóddarab hibamentes legyen. Amikor arról van szó, hogy vannak olyan dolgok, amelyeket nem lehet tesztelni és megoldani, miközben egy darab kód készül.

ha a kódfagyasztást választja, akkor nem fogja feladni az automatizált minőségbiztosítás és az agilis legjobb gyakorlatok előnyeit. Ön és csapata egyszerűen elkapja a kód kisebb, triviálisabb problémáit a gyártás során, megtisztítva a fedélzetet, hogy összpontosítson a nagyobb, nagyobb hatású problémák elkapására a fagyasztás során, mint például az új szoftver vagy funkció általános stabilitása és megbízhatósága.

a 2.argumentum problémája: “csökkentés”, nem “megszüntetés”

az Agile célja a fejlesztés és a kiadás közötti idő csökkentése, ez is tény. De nagy különbség van aközött, hogy megpróbáljuk csökkenteni ezt az ablakot, és megpróbáljuk teljesen megszüntetni. Ez szinte lehetetlen lenne, különösen a nagyobb projektek esetében.

a KÓDFAGYASZTÁS nagyon rövid lehet A CICD-ben— vagy csak egy adott ágra vonatkozhat, míg a Fejlesztés Más ágakon folytatódik—, de még mindig létezik. Nem számít, milyen kifinomult agilis lett, szinte mindig lesz egy pont az összes fejlesztési és kiadási ütemtervben, ahol egy új szoftvert vagy funkciót rögzített állapotban értékelnek, mielőtt a valós felhasználókhoz eljutna.

A Probléma Argumentum 3: A sebesség és a minőség újragondolása

ha kódfagyasztást használ, akkor új lépést ad a fejlesztési és kiadási ciklushoz. Efelől semmi kétség. És minden alkalommal, amikor új lépést ad hozzá bármely folyamathoz, lelassítja ezt a folyamatot, és új potenciális hibapontot hoz létre. A kód lefagyása sem kivétel.

de fontos, hogy egy lépéssel hátrébb lépjünk, és tágabb képet kapjunk a lassulásról és az elvesztett termelékenységről.

ha a funkció hibákat tartalmaz, akkor azokat ki kell javítania, függetlenül attól, hogy a kódfagyasztás során elkapta-e ezeket a hibákat, vagy a kiadás után jelentkeztek-e. Tiszta fejlesztési szempontból a javításukhoz szükséges idő mindkét esetben nagyjából azonos lesz.

de ha élő környezetben foglalkozik a hibákkal, akkor számos más kérdéssel kell foglalkoznia, többek között:

• annak eldöntése, hogy visszaállítja-e a hibás funkciót, vagy hagyja élőben.
• a fejlesztők eltávolítása az új projektekből, miután megkezdték a munkát.
• így akár a valós felhasználók, akik hatással voltak a hibákat.
• válaszadás és kezelés a belső érdekelt feleknek, akik nem túl örülnek a problémás kiadásnak.

a lista folytatódik. Semmi sem bonyolultabb, időigényes és romboló a termelékenységre-az Ön és csapata számára -, mint egy hibás funkció vagy termék kiadása. A kód lefagy, minimalizálja ennek esélyét.

és ami azt az érvet illeti, hogy a kód lefagyása alacsonyabb minőségű funkciókhoz és termékekhez vezet, mert csökkentik az összegyűjthető üzleti követelmények mennyiségét? Az üzleti követelmények mindig kicsit több, mint egy” legjobb találgatás”, hogy mi a termék vagy funkció kell működnie, mint. A legértékesebb követelmények mindig valós felhasználóktól származnak, a terméket vagy funkciót valós forgatókönyvekben telepítik. Ezeket a követelményeket pedig csak úgy gyűjtheti össze, ha olyan funkcionális kiadásokat ad a felhasználóknak, amelyeket a lehető legfolyékonyabban és hibamentesen telepíthetnek.

érdemes-e használni a Kódfagyasztást az agilis termékmenedzsmentben?

végső soron a kódfagyások továbbra is fontos szerepet játszanak sok agilis termékmenedzser számára.

most vannak olyan esetek, amikor kevésbé kritikus szerepet játszanak. Előfordulhat, hogy a nagyon kis projekteknek nincs szükségük külön kódfagyasztási időszakokra. Az új funkciók, amelyeknek viszonylag kisebb következményei vannak, ha tökéletlenül szállítják őket, nem biztos, hogy megéri a fagyasztást. Ugyanez vonatkozik a szakaszos kiadási tervekre—például a Kanári-kiadásokra -, amikor csak új funkciókat szeretne kipróbálni egy meleg közönséggel, akit arra alapozott, hogy hibás, tökéletlen élményre számítson.

de a legtöbb esetben érdemes időt szánni—akár nagyon rövid ideig is—annak biztosítására, hogy az új funkciók olyan tökéletesek legyenek, mint gondolnád, mielőtt a legfontosabb emberek kezébe adnád őket: a valós felhasználók.

ez a cikk eredetileg megjelent flagship.io