Share via

Javaslatok a szoftverfejlesztés és -kezelés formalizálásához

  • Cikk

Erre az Azure Well-Architected Framework Operational Excellence ellenőrzőlistára vonatkozó javaslatra vonatkozik:

OE:03 A szoftver ideációs és tervezési folyamatainak formalizálása. Merítsen a meglévő iparági és szervezeti szabványokból. Használjon egy gyakori, rangsorolással rendelkező hátralékot és megfelelően részletes specifikációkat. Az eredmények alapján folyamatos fejlesztéseket hajt végre a tervezési folyamatban.

Ez az útmutató ismerteti a szoftverfejlesztési eljárásoknak a bevált szabványoknak megfelelő kezelésére vonatkozó javaslatokat. A csapat kiváló minőségű szoftverek előállításának képessége a fejlesztési tervezés strukturált, együttműködésen alapuló megközelítésén alapul. A terméktulajdonosoknak és a vezetőknek képesnek kell lenniük arra, hogy világosan megértsék és megfogalmazhassák az érdekelt felek számára azt a munkát, amelyet a fejlesztők a fejlesztési ciklus során bármikor végeznek. Ezzel szemben a fejlesztőknek jól megírt funkciókkal, felhasználói történetekkel és elfogadási kritériumokkal kell megérteniük a fejlesztési ciklus céljait. A létrehozott szabványok meghatározzák a fejlesztési gyakorlatok végrehajtását, és lehetővé teszik a számítási feladatok csapatának hatékony együttműködését, csökkentve a célok és az elvárások zavarának kockázatát.

Fő tervezési stratégiák

A szoftverfejlesztési gyakorlatok formalizálása annak biztosítása érdekében, hogy a terméktulajdonosok, a projektmenedzserek és a fejlesztők megértsék az egyes futamok céljait, és egységes minőséget biztosítsanak az érdekelt feleknek. A fejlesztési gyakorlatokkal kapcsolatos útmutatást a folyamatos integrációs útmutatóban tekintheti meg.

Fejlesztési tervezésre vonatkozó szabványok

  • Együttműködés: A számítási feladat javasolt módosításainak meghatározásához együttműködésre van szükség. A számítási feladat legtöbb módosítása több függvényre és/vagy összetevőre is hatással lesz, így a lehető legtöbb számítási feladatért felelős csapattag bevonása segít biztosítani, hogy a fontos szempontok ne maradjanak le, és hogy mindenki tisztában legyen az adott tartományra gyakorolt hatásokkal. Az együttműködés abban is segít, hogy egyértelműen meghatározzuk a változások hatókörét, és hogy miként oszthatjuk fel a módosítás végrehajtásához szükséges feladatokat jól meghatározott munkaelemekre, mivel egy nagyobb, tartományokra kiterjedő szakértelemmel rendelkező csoport képes lesz tapasztalatokkal alátámasztott becsléseket nyújtani a szükséges erőfeszítésekhez.

  • Eszközök: Használjon olyan bevált, iparágban bevált eszközöket és folyamatokat, mint az Agile, a Scrum és a Kanban táblák. A saját eszközök és folyamatok fejlesztése jelentős vállalkozás, amely időt és fejlesztési ciklusokat vesz igénybe, amelyeket egyébként a számítási feladatra fordíthat. A legtöbb tapasztalt DevOps-mérnök és terméktulajdonos ismeri az ilyen típusú eszközöket és folyamatokat, ezért a bevezetésük tanulási görbéjének minimálisnak kell lennie. Hasonlóképpen, az új alkalmazottak előkészítési folyamata is előnyös lesz a standard eszközök és folyamatok használata szempontjából, mivel valószínűleg már ugyanolyan eszközökkel és folyamatokkal lesznek kitéve.

Kompromisszum: Az agilis módszertan túl szigorú lehet, ha túlságosan előíró. Törekedjen a jól meghatározott szabványok és az innováció közötti egyensúly megteremtésére.

  • Üzembe helyezés: Tervezze meg, hogy a gyakori kis, iteratív üzemelő példányokat használja a nagy ritkán használt üzemelő példányok helyett. Ezzel a megközelítéssel a felhasználói történetek és munkaelemek kezelhetők maradnak projektfelügyeleti szempontból, és csökkentik a nagy léptékű problémák kockázatát, ha az üzembe helyezés sikertelen.

  • Kifejezések: Szabványosítsa a befejezett fejlesztési ciklusok definícióját, hogy a támogató funkciók, például a tesztelés, a dokumentáció és az akadálymentességi funkciók sikeresen befejeződjenek.

  • Kommunikáció: Definiálja a terméktulajdonosok és a projektmenedzserek szabványos protokolljait, hogy belsőleg és külsőleg is előléptethesse a közelgő kiadásokat. Létrehozhat például egy szabványt a külső feleknek a közelgő kiadásokról való kommunikációhoz. A szabvány azt diktálhatja, hogy a kommunikációt két héttel a kiadás előtt kell elküldeni, és 24 órával a kiadás előtt emlékeztetőt kell küldeni.

  • Felhasználói történetek: Felhasználói történetek sablonjának szabványosítása. Győződjön meg arról, hogy minden felhasználói történet különálló munkaegység, amely a végfelhasználó szemszögéből van megírva. A jól megírt felhasználói történeteknek a következő jellemzőkkel kell rendelkezniük:

    • Minden felhasználói történetnek teljesen függetlennek kell lennie egymástól. A felhasználói történetek egymástól független tartása elkerüli az átfedésben lévő munka félreértéseit, és segít a csapatnak megérteni, hogy az adott felhasználói történeten végzett munka támaszkodik-e a többi felhasználó munkájára, ami segít az ütemezésben és a rangsorolásban.

    • Minden felhasználói történet tárgyalható. A végfelhasználók és a számítási feladatok csapattagjainak perspektívái egyaránt elengedhetetlenek a valós felhasználói történetek rögzítéséhez, amelyek rövid idő alatt elvégezhetők.

    • A felhasználói történetek értékesek a végfelhasználó számára. Amikor a végfelhasználó szemszögéből ír felhasználói történeteket, rögzíti azokat a módosításokat, amelyeket látni szeretnének, és amelyek értéket adnak a felhasználói élményüknek. Ha ezt a fókuszt a felhasználói történet munkaelemekre bontásakor tartja, azzal biztosíthatja, hogy az egyes üzemelő példányok jobb élményt biztosítsanak.

    • A felhasználói történethez szükséges erőfeszítés nagy megbízhatósággal megbecsülhető. Ha nem tudja közelíteni az adott felhasználói történethez szükséges órákat, a tervezés nehéz lesz, és nő a hiányzó határidők valószínűsége, ami kaszkádolt hatást gyakorolhat a többi tervezett munkára.

    • A jól megírt felhasználói történetek kicsik, így néhány héten belül befejeződhetnek. A kisebb hatókörű történetek segítenek megbecsülni és kezelhetővé tenni őket, valamint a munkaelemeket elérni.

    • A felhasználói történeteknek tesztelhetőnek kell lenniük. Anélkül, hogy tesztelni tudná, hogy egy szolgáltatás teljesült-e, a végfelhasználó nem biztos abban, hogy a cél teljesült. Még akkor is, ha egy teszt még nem lett megírva egy adott felhasználói történethez, tisztában kell lennie azzal, hogyan fejleszthető ki egy teszt a funkció nyújtásának bizonyításához.

  • Elfogadási feltételek: Sablon szabványosítása elfogadási feltételekhez. Győződjön meg arról, hogy az elfogadási feltételek kifejezetten a felhasználói történethez kapcsolódnak, és egy vagy több elfogadási teszt használatával egyértelműen bizonyíthatók.

  • Nyomkövetés: Győződjön meg arról, hogy a fejlesztési folyamat nyomon követhető. Egyértelműen nyomon kell követnie az éles számítási feladat állapotát és a kapcsolódó kódot a minőségbiztosítási teszteléshez, az elfogadási feltételekhez, a felhasználói történetekhez és a funkciókhoz. A részletes nyomkövetés bizonyos esetekben szabályozási követelmény is lehet, például az egészségügy.

  • Áttekintés: Rendszeresen végezzen belső ellenőrzéseket a fejlesztési gyakorlatokról a fejlesztési ciklusok visszamenőleges és utólagos vizsgálatával. A folyamatvisszaverődésnek oktalannak kell lennie, és a fejlesztésként alkalmazható tanulásra kell összpontosítania. Győződjön meg arról, hogy a csapat tükrözi, hogy a felhasználói történet és a feladatok mennyire voltak hatékonyak a szükséges feladatok meghatározásában és az időbecslések pontosságában.

  • Jelentések: A változásokra összpontosító hasznos metrikákat tartalmazó jelentések egységesítése az érdekelt felek számára. A változásra összpontosítva nyomon követheti a termék gyorsítását és lassulását. A hasznos metrikák a következőkben tartalmazhatnak módosításokat:

    • A bevezetés havi növekedési üteme.

    • Teljesítmény.

    • Betanítási idő.

    • Az incidensek gyakorisága.

    A jelentéskészítés nem használható eszközként az egyének munkájának értékelésére, ezért kerülje a metrikákat, például a történeti pontokat vagy a kódsorokat az egyes mérnökök számára.

Azure-beli facilitálás

Az Azure Boards egy webalapú szolgáltatás, amellyel a csapatok megtervezhet, nyomon követhetik és megvitathatja a teljes fejlesztési folyamatot. Kiválóan alkalmas agilis alapú fejlesztési gyakorlatokhoz.

A GitHub Projects egy testre szabható projektkezelő eszköz, amely problémák és lekéréses kérelmek használatával képes projekteket rendszerezni és integrálni a GitHubon.

Működési kiválóság ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Működési kiválóság ellenőrzőlista