Yhteiskehityksen hallinto

Tehokkaan yhteiskehittämisen hallintokehyksen luominen on tärkeä osa yhdenmukaisuuden ja toistettavuuden varmistamista tekijälähtöisille projekteille ja fuusiotiimeille. Tässä artikkelissa kuvataan menetelmä, joka määrittää hallinnon vuokaavion.

Koko prosessin määrittäminen

Voit käyttää esimerkkinä seuraavaa prosessia ja mukauttaa sen organisaatiosi parhaiden käytäntöjen mukaisesti. Jokaista vaihetta ei tarvitse suorittaa, kunhan saavutat vaaditun tuloksen.

Lisää ominaisuuksia tehtävälistaan

Tehtävälistojen avulla voit suunnitella projektiasi lisäämällä toimintoja, jotka edistävät yleistä käyttökokemusta. Tehtävälista sisältää myös yleisen etenemissuunnitelman, jonka ryhmän tarkoitus toteuttaa.

Kun uusi ominaisuus lisätään tehtävälistaan, tavoitteena on kuvailla yleistä vaikutusaluetta. Jokainen ominaisuus määrittää koodin kehittämisen kannalta tarvittavat liiketoiminta-arvot, luonnoskertomusten otsikot, vaikutusalueen ja tietomallin muutokset.

Lisäksi on suositeltavaa lisättäessä liiketoiminnan kannalta tärkeää ominaisuutta tunnistaa kaikki tärkeät skenaariot testauksen automatisoinnissa. Kun olet lisännyt ominaisuudet, voit aikatauluttaa vaikutusalueen yhtenäisyyskokouksen.

Vaikutusalueen yhtenäisyyskokous

Tämän kokouksen painopisteenä on oltava ainoastaan kunkin ehdotetun uuden ominaisuuden tarkistaminen ja sen jälkeen sen tarkistaminen, onko olemassa sovelluksia, skenaarioita tai tietomalleja, jotka jo tarjoavat tämän toiminnon, jotta päällekkäisiä toimia ei tehdä. Tässä tapaamisessa on myös mahdollisuus keskustella vaikutuksesta muihin sovelluksiin. Tarkista lopuksi, edellyttääkö tämä ominaisuus käyttökokemuksen arviointia.

Tarinoiden ja tarinataulukon lisääminen tehtävälistaan

Vaikutusalueen yhtenäisyyskokouksen jälkeen ominaisuuden alle voidaan lisätä käyttäjäkertomuksen luonnosotsikot. Tässä vaiheessa yksityiskohdat eivät ole pakollisia ja käyttäjätarinan tila on "Uusi". Voit tarkastella tarinoita joko tehtävälista- tai taulukkonäkymässä.

Seuraavassa kuvassa näkyy tehtävälistaan lisätty esimerkkikäyttäjäkertomus.

Tässä vaiheessa on tärkeää ylläpitää laatua järjestämällä työt työvirran ja sovelluksen mukaan. Tämä tapa auttaa pitämään toisiinsa liittyvät työkohteet yhdessä ja antaa asiantuntijoiden kehittää ja ylläpitää syvällistä ymmärrystä kunkin sovelluksen toiminnoista ja tietojen käytöstä.

Käyttökokemuksen arviointi

Käyttökokemusten arviointien tulisi keskittyä käyttäjien kokemukseen ja varmistaa, että ryhmäsi noudattaa organisaation parhaita käytäntöjä. Tämä yhdenmukaisuus varmistaa, että kaikki sovellukset tarjoavat luotettavan ja toistettavan käyttökokemuksen loppukäyttäjille ja tukiryhmille.

Lisää tarinan tiedot

Tyypillisen käyttäjätarinan lisääminen voi sisältää seuraavat tiedot:

1. Otsikko: Roolissa <persona> voin <do something>, jotta <impact/priority/value>
2. Kuvaus: Kuvaus sisältää (vaikka se ei rajoitu siihen) tiettyjä tärkeitä tietoja, kuten seuraavat:
   • Skenaarion lyhyt kuvaus, joka tiivistää halutun tuloksen
   • Kertomus – kuvaa toimintoja, joita käyttäjien on tehtävä siirtyäkseen skenaariossa ja toteuttaakseen sen.
   • Vaihtoehtoinen kertomus – kuvaa muita tapoja, joilla käyttäjät voivat saavuttaa saman tuloksen
   • Suunnittelutiedot – tallentaa käyttäjätarinaan liittyvät entiteetit, kentät, näkymät, mallinäytöt ja liiketoimintasäännöt
   • Liittyvät käyttöoikeusroolit – luetellaan kaikki käyttöoikeusroolit, jotka liittyvät käyttäjäkertomukseen.

Kun olet lisännyt kaikki nämä tiedot, vaihda käyttäjätarinan tilaksi Valmis tarkistettavaksi. Useimmissa tapauksissa ominaisuusryhmä ja liiketoimintaryhmä (jos käytettävissä) tarkistavat käyttäjätarinat.

Tarinan tarkistus

Tarinan tarkistukset esiintyvät yleensä fuusiotiimeissä, jotta voidaan varmistaa, että kaikki tiedot on mainittu tarinassa ja ettei tarinassa ole moniselitteisyyttä. Kun kaikki arviot on suoritettu, suositus on delegoida käyttäjätarina ryhmän jäsenelle. Tiimin yhdenmukaisen toiminnan varmistaminen kehitysprosessin aikana on tärkeää yleistavoitteiden saavuttamiseksi.

Tehtävien ja testitapausten lisääminen

Kun olet tarkistanut tarinat, ryhmän jäsenet luovat tehtävät Azure DevOpsissa. Tehtävien ja testitapausten lisäämisprosessi on seuraava:

1. Avaa sprintin tehtävälista. Voit vaihtoehtoisesti luoda uuden sprintin.
2. Lisää aiemmin luodut työkohteet sprinttiin. Jos olet jo lisännyt työkohteita, jotka eivät näy sprintissä, tarkista niiden alue ja iterointipolut. Muista delegoida kaikki tehtävät, joilla ei ole päätasoa asianomaisille työnimikkeille.
3. Lisää tehtäviä tehtävälistakohteisiin. Jos sinulle ei ole delegoitu tehtävälistakohteita sprinttiin, tee se nyt. Määritä myös sprintin aloitus- ja päättymispäivät.
4. Täytä tehtävälomake. Tehtävien suorittamisen pitäisi kestää yleensä enintään yhden päivän. Tätä aikaväliä suuremmat tehtävät tulisi jakaa pienemmiksi tehtäviksi.
5. Voit seurata tai integroida tehtävät, joilla ei ole päätasoa. Voit seurata päätasottomia tehtäviä kuten muitakin tehtäviä tai vetää ne aiemmin luotuun tehtävälistakohteeseen, josta tulee sille päätaso.

Kun olet lisännyt tehtävät ja testitapaukset, voit siirtyä määrittämään sprintin kapasiteettia.

Lisätietoja tehtävien lisäämisestä on ohjeaiheessa Tehtävien lisääminen tehtävälistan kohteisiin sprintin suunnittelua varten.

Ratkaisujen valmistelu

Yksi onnistuneen yhteiskehityksen tärkeistä näkökohdista on jäsennelty julkaisunhallintaprosessi. Ratkaisut ovat sovelluksen elinkaaren hallinnan (ALM) toteutuksen mekanismi, jonka avulla voit jakaa komponentteja eri ympäristöihin viennin ja tuonnin kautta. Komponentti edustaa sovelluksessasi käytettyä artefaktia ja jotain, jota voit mahdollisesti mukauttaa. Kaikki, mitä ratkaisuun voidaan sisällyttää, on komponentti, kuten taulukot, sarakkeet, kaaviot ja mallipohjaiset sovellukset, Power Automate -työt, chatbotit, taulukot ja laajennukset.

Käyttöönotot

Komponenttien valmistuminen voi kestää useita sprinttejä riippuen sen monimutkaisuudesta ja tiimin nopeudesta. Komponentit pitäisi lisätä ratkaisuun kehitysympäristössä sitä mukaa, kun tehtävät valmistuvat. Ratkaisut viedään sitten tuotantoympäristöön, kun ne on testattu. Suosittelemme, että ylläpidät myös yhteä testiympäristöä kokonaisvaltaista testausta varten ja kokeilet ratkaisun käyttöönottoa, ennen kuin se siirtyy tuotantoon.

Power Platform -ympäristöt

Ympäristöt ovat tiloja, jossa voi tallentaa, hallita ja jakaa organisaation liiketoimintatietoja, sovelluksia ja liiketoimintaprosesseja. Ne toimivat myös säilöinä erillisille sovelluksille, joilla voi olla eri roolit, käyttöoikeusvaatimukset tai kohdeyleisöt.

Jos organisaatiossasi on useiden tiimien fuusiorakenne, jossa kukin tiimi kehittää omat ratkaisunsa, on tärkeää koordinoida sprinttien kesto ja julkaisut. Sprinttien ei tarvitse olla pituudeltaan yhdenmukaisia projektin aikajanalla, ja niiden kesto voi vaihdella tiimeittäin kunkin ryhmän mieltymisten mukaan. Julkaisurytmi ei kuitenkaan voi olla tiheämpi kuin kaikkien tiimien lyhyin sprintin kesto.

Lähteenhallinta

Harkitse lähdekoodin hallintajärjestelmän, kuten Azure DevOpsin, käyttöönottoa. Azure DevOps sisältää kehittäjäpalveluja tukitiimeille töiden suunnittelua, koodinkehityksen yhteistyötä ja sovellusten kehittämistä ja käyttöönottoa varten.

Vie ratkaisu kehitysympäristöstä, joka sisältää sovelluksesi ja mukautukset. Pura ratkaisu ja tallenna komponentit lähteen hallintajärjestelmään.

Edistynyt aihe: hakupyyntöjen tarkastukset

Hakupyyntöjä pitäisi luoda vain sellaisille tarinoille, jotka ovat aktiivisia ja joiden ominaisuudet on tarkastettu ja hyväksytty. Varmista, että ratkaisun versioinnit ovat oikein noudattaen sprinttien ja kehityksen ohjeita, jotka on määritetty kohdassa Scrum-käytäntöjen toteuttaminen tiimille Azure Boardsissa. Pull-pyyntöjen testitulokset voivat olla näyttökuvia tai videoita, jotka kuvaavat rakennettavaa toimintoa.

Pull-pyyntöjen hallintaprosessin automatisoiminen auttaa varmistamaan koodin laadun tarvitsematta tarkistaa manuaalisesti perustarkistuksia, kuten ratkaisuversioita.

Mallit ja standardointi

Mallit ja standardointi tehostavat toimintaa, koska ne edistävät ryhmän yhtenäisyyttä. Kaikki ryhmän toimintojen näkökohdat – oli kyseessä sitten perehdytystehtävät, tarinan tarkistusesitykset tai työkohdemallit, jotka säästävät aikaa ja auttavat antavat tiimille ohjeita käyttäjätarinoiden, ominaisuuksien, vikojen tai tehtävien määrittämisessä – hyötyvät standardoinnista ja yksinkertaistamisesta.

Tehokkaan tukimallin toteuttaminen

Tehokas tukimalli on erittäin tärkeä sovelluksen pitkäaikaisen menestyksen kannalta käyttöönoton jälkeen, kuten tukimatriisin luomisessa aiemmassa osassa on korostettu. Virheet ja käyttökatkot ovat väistämättömiä, joten on erittäin tärkeää, että ryhmä käyttää rakenteellista lähestymistapaa näiden tapahtumien käsittelemiseksi, ja tukimatriisi tarjoaa tarvittavan kehyksen.

Palvelutasosopimuksen luominen

Tukimallin tärkeä osa on palvelutasosopimuksen (SLA) määritelmä. SLA:n on oltava muodollinen asiakirja, jonka ryhmä laatii ja joka sisältää seuraavia kohteita kattavat osat:

• Käyttökatkokset – mikä palvelukatkos on hyväksyttävää, kenelle on ilmoitettava, mitä toimia on määrä tehdä, palvelun uudelleen käyttöoton vahvistaminen ja toimet toistumisen estämiseksi. Ryhmän automaattisten testausmenettelyiden on sovittava yhteen oletetun käyttökatkotoleranssin ja soveltuvan SLA:n kanssa.
• Virheet – kuka voi ilmoittaa, vakavuustasojen määritys, luokitus, tunnistustoiminnot, kuka ottaa vastuun ratkaisemisesta ja kuittaamisesta.
• Eskaloinnit – eskalointitasot, henkilöstön määrittäminen tasoille, vastuualueet kullakin tasolla, jakeluluettelot kullakin tasolla ja niin edelleen.

Palvelutasosopimus on tallennettava ryhmän dokumentointiportaaliin ja päivitettävä tarpeen mukaan.

Sovellustuen toimittaminen

Paras tapa toimittaa SLA:ssa määritetty sovellustuki on käyttää ryhmää, joka loi ratkaisun, vastaamaan myös ratkaisun tuesta. Järjestelmän etuja ovat seuraavat:

1. Se kannustaa laadukkaan kehittämisen parantamiseksi, koska sovelluksen luoneet tietävät, että heidän on tuettava sitä.
2. Tekijät voivat etsiä ja korjata vikoja nopeammin kuin kolmannen osapuolen ryhmä, koska he tuntevat sovelluksen paremmin.
3. Mahdollisesti tehtäväkriittisten ohjelmistojen korjaamisen delegointi toiselle ryhmälle voi olla kyseiselle ryhmälle motivaatiota laskevaa ja aikaa vievää. Kuten muissakin sovellusten luonnin, kehittämisen ja käyttöönoton vaiheissa, fuusiotiimin tulisi tarvittaessa olla yhteistyössä IT:n kanssa.

Sovellustyytyväisyyden ja käytettävyyden valvonta

Tuen viimeinen osa on käyttöönotetun sovelluksen tyytyväisyyden ja käytettävyyden valvonta ja arviointi. Mittarit ovat hyödyllisiä tässä sekä perinteiset menetelmät, kuten kyselyt ja äänestykset. Lisätietoja sovelluksen käytön valvonnasta on ohjeaiheessa Järjestelmänvalvojan analyysit Power Appsissa.

Jos asiakkaat eivät käytä julkaistua sovellusta, sovellus ei täytä tarkoitustaan. Säännölliset tarkastelukokoukset voivat tarkistaa nämä tyytyväisyyden ja käytettävyyden mittarit ja luoda positiivisen palautteen silmukka, joka voi muuttaa tai lisätä tarinoita tehtävälistaan sovelluksen päivitetyn version luomista ja käyttöönottoa varten.

Yhteenveto

No-code- ja low-code-työkalujen, kuten Power Appsin, kehittäminen on laajentanut teknisten liiketoiminta-asiantuntijoiden tai tekijöiden mahdollisuuksia luoda, kehittää ja ottaa käyttöön sovelluksia. Tämä kehitystyö toimii parhaiten fuusiotiimiympäristössä, jossa on tuoteomistaja, toimialueasiantuntija, ammattikehittäjä ja järjestelmänvalvoja sekä muita resursseja tarpeen mukaan.

Agile- ja scrum-kehitystapojen integroiminen fuusiotiimeissä johtaa sovellusten nopeampaan kehittämiseen ja onnistuneen käyttöönoton suurempaan todennäköisyyteen ominaisuusjoukolla, joka vaikuttaa merkittävästi liiketoimintaan. Käyttämällä näitä parhaita käytäntöjä, ohjeita ja suosituksia fuusiotiimisi pystyy vastaamaan organisaation digitaalisiin muutoshaasteisiin Power Appsin avulla.