Közös fejlesztésű cégirányítás

A közös fejlesztésű cégirányítás keretrendszert létrehozása fontos része a következetesség és az ismétlődés biztosítása érdekében a gyártó által meghatározott projekteken és csapatokon belül. Ez a cikk a folyamatábra meghatározásának megközelítését ismerteti.

A folyamat végpontokig történő meghatározása

Az alábbi folyamatot példaként használhatja, és a szervezet gyakorlati tanácsoknak megfelelően testre szabhatja. Nem szükséges minden egyes lépést végrehajtani, amíg eléri a kívánt eredményt.

Szolgáltatások hozzáadása a háttérelemhez

A háttérelemek lehetővé teszi a projekt tervezését olyan funkciók hozzáadásával, amelyek a teljes élményt biztosítják. A háttérelem azt is jelenti, hogy milyen általános változásokat kíván megvalósítani a csoport.

Amikor új szolgáltatást ad a háttérnaplóhoz, a cél az általános hatókör leírása. Ezután minden funkció meghatározza a kód fejlesztési erőfeszítéseit hajtó üzleti érték, a cikkcímek, a hatókör és az adatmodell változásait.

Emellett az üzleti tevékenység szempontjából alapvető fontosságú funkciók hozzáadásakor ajánlott bármilyen kritikus forgatókönyvet azonosítani a tesztelés automatizálása érdekében. A szolgáltatás(ok) hozzáadása után ütemezheti a Hatókör kiigazítási találkozót.

Hatókör kiigazítása találkozó

Az értekezlet fókuszát úgy kell korlátozni, hogy áttekintsen minden javasolt új jellemzőt, majd ellenőrizze a meglévő alkalmazásokat, forgatókönyveket vagy adatmodelleket, amelyek már biztosítják ezt a funkciót a duplikált erőfeszítések elkerülése érdekében. Ezen az értekezleten a más alkalmazásokra gyakorolt hatás megbeszélésére is lehetőség nyílik. Végül ellenőriznie kell, hogy a jellemzőhöz szükséges-e tapasztalati áttekintés.

Szövegek és történet hozzáadása a háttérelemhez

A hatókör kiigazítását követően a jellemző alá bármely tervezett felhasználói cikkcím hozzáadható. Jelenleg nincs szükség részletekre, és a felhasználói cikk állapota "Új". A történeteket a háttérelemben vagy a táblanézetben is megtekintheti.

A következő ábra egy háttérelemhez hozzáadott felhasználói mintatörténetet mutat.

Ezen a ponton az a cél, hogy fenntartsa a minőséget a munka adatfolyam és alkalmazás szerinti rendszerezése segítségével. Ez a megközelítés segíti a kapcsolódó munkaelemek egy egymáshoz kapcsolódó megőrzését, és lehetővé teszi az egyes munkaelemek szakértői fejlesztését és karbantartsását az egyes alkalmazásokban használható funkciókat és adathasználatot.

Tapasztalati áttekintés

A tapasztalati áttekintésnek a végfelhasználói élményre kell koncentrálnia, és gondoskodnia kell arról, hogy a csoport kövesse a szervezeti ajánlott eljárásokat. A konzisztencia gondoskodik arról, hogy minden alkalmazás megbízható és ismételhető élményt nyújtson a végfelhasználóknak és a támogatási csoportoknak.

Történei előzmények hozzáadása

A jellemző felhasználói élmények a következő információkat foglalják magukban:

1. Cím: Mint <persona> képes vagyok <do something>, így az <impact/priority/value>
2. Leírás: A leírás tartalmaz (bár nincs korlátozva) bizonyos fontos részleteket, például:
   • A forgatókönyv rövid leírása, amely a kívánt eredményt foglalja össze
   • Ez a fejezet leírja azokat a műveleteket, amelyeken a felhasználók eligazodnak és el is érik az adott forgatókönyvet
   • Alternatív módszer – ismerteti, hogyan lehet a felhasználók ugyanazt az eredményt elérni
   • Tervezési megjegyzések – rögzíti a felhasználói cikkhez kapcsolódó entitásokat, mezőket, nézeteket, mintaképernyőket és üzleti szabályokat
   • A biztonsági szerepkörökre hatással lévő – felsorolja az összes biztonsági szerepkört, amely hatással van a felhasználói történetre, illetve amelyekre hatással van.

Mindezeket az adatokat hozzáadva a felhasználói cikk állapotát át kellene változtatni „Készen áll az ellenőrzésre”. A legtöbb esetben a funkciócsoport és az üzleti csoport (ha van ilyen) áttekinti a felhasználói profilt.

Történeti áttekintés

A történeti áttekintések általában a csapatban fordulnak elő, annak érdekében, hogy minden részlet ki legyen hívva a történetben, és hogy ne legyen félreérthető. Az összes ellenőrzés befejezését követően az ajánlás az, hogy a felhasználói cikket rendelje hozzá a csoporttaghoz. Annak biztosítása, hogy a csoport a fejlesztési folyamat során folyamatosan igazodni fog a teljes célok eléréséhez.

Feladatok hozzáadása és esetek tesztelése

A csoport tagjai a vizsgálat után feladatokat hoznak létre az Azure DevOps-ban. A feladatok hozzáadásának és az esetek tesztelésének általános folyamata a következő:

1. Nyisson meg egy háttérelemet. Másik lehetőségként hozzon létre újat.
2. Vegyen fel meglévő munkaelemeket a munkahelyre. Ha már hozzáadott munkaelemeket, amelyek nem jelennek meg a munkaterületen, akkor ellenőrizze a területet és az iterációs elérési útjukat. Ne felejtse el hozzárendelni a nem hozzárendelt feladatokat a megfelelő munkaelemekhez.
3. Feladatokat adhat hozzá a háttérelem elemeihez. Ha nincsenek hozzárendelve háttérelem elemek a számítógéphez, akkor tegye meg most. Állítsa be a kezdési és befejezési dátumot is.
4. Töltse ki ezt a feladatűrlapot. A feladatok végrehajtása általában nem tart tovább egy napnál. Az ennél az időkorlátnál nagyobb feladatokat fel kell bontani.
5. A nem le nem adott feladatok nyomon követése vagy integrálása. A le nem adott feladatok a többi feladathoz hasonlóan nyomon követhetők, illetve egy meglévő háttérelem elemekhez is áthúzhatja őket fölérendelt feladatként.

A feladatok és a teszt esetek felvétele után beállíthatja a kapacitást.

A feladatok hozzáadásával kapcsolatban a Feladatok hozzáadása háttérelemekhez című cikk nyújt tájékoztatást.

Megoldások előkészítése

A sikeres együttműködés egyik fontos aspektusa a strukturált kiadáskezelési folyamat. A megoldások az Életciklus-menedzsment ALM megvalósításához szükséges mechanizmusok, amelyek segítségével az összetevők eloszthatók a környezetek között az exportálás és az importálás során. Egy összetevő olyan műtermék, amit egy alkalmazásában használ, és olyasvalami, amit esetleg testre szabhat. Minden, ami egy megoldásban szerepelhet, az egy összetevő, például táblák, oszlopok, vásznak és modellvezérelt alkalmazások, Power Automate folyamatok, csevegőrobotok, diagramok és beépülő modulok.

Telepítések

Az összetevők összetettségétől és csapatszabadságától függően több művelet is befejeződhet. A feladatok végrehajtása során összetevőket kell hozzáadni egy megoldáshoz a fejlesztési környezetben. A megoldásokat a tesztelés után importálja a működési környezetbe. Az éles üzemre való át állítás előtt ajánlott egyetlen tesztkörnyezetet fenntartani a teljes tesztelés végrehajtásához, illetve a megoldás telepítésének kipróbálása céljából.

Power Platform-környezetek

A környezet olyan hely, ahol tárolhatja, kezelheti és megoszthatja szervezetének üzleti adatait, alkalmazásait és üzleti folyamatait. Egyben tárolóként is szolgál a különböző szerepkörökkel, biztonsági követelményekkel vagy célközönségekkel rendelkezhető alkalmazások elkülönítésére.

Ha a szervezet több csapatból álló rendszert hoz létre, amelyben minden csoport saját megoldásokat fejleszt, fontos, hogy a kiadások időtartamát is koordinálni kell. A csapatnak nem kell egységes hosszúságúnak lennie a projekt ütemezése mentén, és az egyes csoportok igényeinek megfelelően változhat időtartamra. A kiadási idő azonban nem lehet kisebb minden csapatnál a leggyorsabb időtartamnál.

Forrásellenőrzés

Fontolja meg egy forráskód-ellenőrzési rendszer, például Azure DevOps bevezetését. Az Azure DevOps fejlesztői szolgáltatásokat biztosít a támogatási csoportok számára a munkatervezés, a kódfejlesztésben való együttműködés, valamint az alkalmazásépítés- és telepítés során.

Exportálja a megoldást az alkalmazásait és a testreszabásait tartalmazó fejlesztői környezetből, csomagolja ki a megoldását, és tárolja az összetevőket a forráskód-ellenőrzési rendszerben.

Speciális témakör: Kérelem (PR) felülvizsgálatok lekérése

Kizárólag aktív, és szolgáltatásokat áttekintő és jóváhagyott PR-okat szabad létrehozni. Gondoskodnia kell arról, hogy a megoldások verziószámozása pontos legyen, a Scrum-eljárások megvalósítása Azure-táblákon című irányelvek szerint. A PR eredményei lehetnek képernyőfelvételek vagy olyan videók, amelyek a beépített funkciót ábrázolják.

A PR-cégirányítási folyamat automatizálása elősegíti a kódminőséget anélkül, hogy manuálisan áttekintené az alapellenőrzéseket, például a megoldás verzióit.

Sablonok és szabványosítás

A sablonok és a szabványosítás hatékonysága elősegíti a csoport egységesítését. A csapat működésének— minden aspektusa, legyen szó bevezetési feladatokról, történetáttekintő prezentációkról vagy munkaelem-sablonokról , amelyek segítenek időt megtakarítani és útmutatást nyújtanak a csapatoknak a felhasználói történetek, funkciók, hibák vagy feladatok— meghatározásakor, a szabványosítás és az egyszerűsítés előnyeit élvezik.

Hatékony támogatási modell megvalósítása

A hatékony támogatási modell nélkülözhetetlen egy alkalmazás hosszútávú, telepítés utáni sikeréhez – amint az a korábbi, a támogatási mátrix létrehozásáról című részben is rámutatott. A hibák és leállások is elengedhetetlenek, ezért a csoportnak strukturált megközelítése van az ilyen eseményekkel való együttműködésre, és a támogatási mátrix biztosítja a szükséges keretrendszert.

A szolgáltatásiszint-szerződés létrehozása

Bármelyik támogatási modell kulcsfontosságú tényezője a Szolgáltatásiszint-megállapodás (SLA) meghatározása. Az SLA-nak hivatalos dokumentumnak kell lennie, amit a csoport készít, és amely a következő elemeket tartalmazó szakaszokat tartalmazza:

• Leállások – a szolgáltatás kimaradásának milyen szintje fogadható el, ki milyen szintű tájékoztatásra, milyen műveleteket kell végrevetnie, meg kell erősítenie a szolgáltatás újraszabadülését, illetve meg kell előznie az ismétlődéseket. A csoport által használt automatizált tesztelési eljárásoknak igazodni kell a várható kimaradáshoz és a vonatkozó SLA-hoz.
• Hibák – ki tudja értesíteni, hozzárendelni a rendszerszinteket, az osztályozást, a detektálással kapcsolatos műveleteket, ki a felelős a megoldásért és a kijelentkezésért.
• Eszkalációk – eszkalációs szintek, a munkatársak szintekhez való hozzárendelése, az egyes szintek felelősségi szintjei, terjesztési listák az egyes szintekhez stb.

Az SLA-t a csoport dokumentációs portálján kell tárolni, és szükség szerint frissíteni kell.

Alkalmazástámogatás nyújtása

Az SLA-ban megadott alkalmazástámogatás kézbesítésének legjobb módja az, ha a megoldást létrehozó csoport is felelős a támogatásáért. A rendszer előnyei a következők:

1. A jobb színvonalú fejlesztést támogatja, mert az alkalmazást létrehozók tudják, hogy támogatást kell nekik nyújtanuk.
2. Az alkotók gyorsabban találhatják meg és javítják a csapatot, mint egy független csapat, csak mert ők jobban ismerik az alkalmazást.
3. A potenciálisan kritikus szoftverek másik csoportra való delegálásának az adott csoport számára demoralizáló és időigényes lehet. Az alkalmazás létrehozásának, fejlesztésének és telepítésének más fázisaihoz a csoportnak is szükség esetén segítséget kell nyújtania az IT-nek.

Az alkalmazás elégedettségének és használhatóságának figyelése

A támogatási munka utolsó része a telepített alkalmazás elégedettségének és használhatóságának figyelése és javítása. Itt a mérőszámok a hagyományosabb módszerekkel, például a ciklikus lekérdezésekkel és a kérdőívekkel együtt hasznosak. Az alkalmazások használatának figyelésével kapcsolatos további információkért olvassa el az Admin Analytics for Power Apps című cikket.

Ha az ügyfelek nem használják a közzétett alkalmazást, akkor az alkalmazás nem teljesíti a célját. A rendszeres értekezletek ellenőrizhetik az elégedettség és a használhatóság mérőszámát, és így pozitív visszajelzési ciklust hozhatnak létre, amely megváltoztathatja vagy hozzáadhatja a háttérelemet a háttérelem létrehozásához, majd az alkalmazás frissített verziójának telepítéséhez.

Összesítés

A kódokat nem fejlesztő és alacsony kódokat is tartalmazó eszközök, például a Power Apps bővített lehetőségeket kínálnak az üzleti környezet és az alkalmazások létrehozására, fejlesztésére és telepítésére. Ez a fejlesztés leginkább egy csoportkörnyezetben működik, a terméktulajdonos, a tartomány szakértője, a fejlesztő szakember és a rendszergazda szükség esetén ki is egészül más erőforrásokban.

Agilis és scrum fejlesztési megközelítések integrálása gyorsabb alkalmazásfejlesztést és a sikeres telepítés nagyobb valószínűségét jelenti egy olyan szolgáltatáskészlet használatával, amely jelentős különbséget tesz az üzletben. A gyakorlati tanácsokat, irányelveket és javaslatokat alkalmazva a csoport felhasználhatja a Power Apps-ot szervezete digitális átalakítási kihívásainak megoldására.