Megosztás a következőn keresztül:


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

Az Azure Well-Architected Framework operatív kiválósági ellenőrzőlistájára vonatkozó javaslat:

OE:03 A szoftver ideációs és tervezési folyamatainak formalizálása. Merítsen a már meglévő iparági és szervezeti szabványokból. Használjon közös, rangsorban megadott teendőlistát és kellően részletes specifikációkat. Az eredmények alapján folyamatosan fejlesztheti a tervezési folyamatot.

Ez az útmutató a szoftverfejlesztési gyakorlatoknak a megállapított szabványoknak megfelelő kezelésére vonatkozó javaslatokat ismerteti. 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 megállapított 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 keveredésének kockázatát.

Főbb tervezési stratégiák

A szoftverfejlesztési gyakorlatok formalizálásával biztosítható, 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 gyakorlatokra vonatkozó útmutatást a folyamatos integrációs útmutatóban tekintheti át.

Együttműködési és kommunikációs szabványok létrehozása

  • 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 számítási feladatok csapatának lehető legtöbb tagját bevonva biztosítható, hogy a fontos szempontok ne maradjanak le, és mindenki tisztában legyen az adott tartományra gyakorolt hatásokkal. Az együttműködés segít egyértelműen meghatározni a változás hatókörét, és azt is, hogy miként oszthatja fel a változá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 tapasztalatalapú becsléseket nyújtani a szükséges erőfeszítésekhez.

  • Kommunikáció: Határozza meg a terméktulajdonosok és 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.

  • Áttekintés: A fejlesztési gyakorlatok belső auditálásának rendszeres végrehajtása a fejlesztési ciklusok visszamenőleges és utólagos vizsgálatával. A folyamatvisszaveré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 a felhasználói történet és a feladatok hatékonyságát 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 nyújtó, az érdekelt felek számára készült jelentések szabványosítása. A változásra összpontosítva nyomon követheti a termékek 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éhez, 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.

Iparági szabványoknak megfelelő eszközök kiválasztása

Használjon olyan bevált, iparágilag bevált eszközöket és folyamatokat, mint az Agile, a Scrum és a Kanban táblák. A saját eszközei és folyamatai 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 kihasználhatja a standard eszközök és folyamatok használatát, mivel valószínű, hogy már bizonyos mértékben ki vannak téve ugyanazoknak az eszközöknek és folyamatoknak.

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

Szabvány bevezetése a végfelhasználói forgatókönyvek rögzítéséhez

  • 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 íródott. 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 való függetlenítése elkerüli az átfedésben lévő munka zavarait, és segít a csapatnak megérteni, hogy egy adott felhasználói történeten végzett munka támaszkodik-e másra, ami segít az ütemezésben és a rangsorolásban.

    • Minden felhasználói történet tárgyalható. A végfelhasználói és számítási feladatok csapattagjainak perspektívái 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 felhasználói történeteket ír a végfelhasználó szemszögéből, 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 bontva 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 munka nagy megbízhatósággal megbecsülhető. Az adott felhasználói történethez szükséges órák közelítése nélkül a tervezés nehéz lesz, és a hiányzó határidők száma nőhet, ami kaszkádolt hatással lehet más tervezett munkákra.

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

    • 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 bízhat 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ó megvalósításának bizonyítására.

  • Elfogadási feltételek: Az elfogadási feltételek sablonjának szabványosítása. 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 teszttel egyértelműen bizonyíthatók.

Üzembehelyezési eljárások szabványosítása

  • Üzembe helyezés: Tervezze meg a gyakori kis, iteratív üzemelő példányok használatát a nagy ritkán használt üzemelő példányok helyett. Ezzel a módszerrel a felhasználói történetek és a 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 annak érdekében, 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.

  • 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ésre, az elfogadási feltételekre, a felhasználói történetekre és a funkciókra. A részletes nyomkövetés bizonyos esetekben szabályozási követelmény is lehet, például az egészségügyi ellátás.

Az Azure megkönnyítése

Az Azure Boards egy webalapú szolgáltatás, amellyel a csapatok megtervezheti, nyomon követheti és megvitathatja a teljes fejlesztési folyamatot. Kiválóan alkalmas agilis alapú fejlesztési eljárásokhoz.

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ági ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.