Määritä ketterän sovelluskehityksen vaikutus

Tämä viesti julkaistiin alun perin IT-konsulttiblogissa marraskuussa 2012.

Ketterä on täällä jäädäkseen. Kun radikaali vaihtoehto vesiputouskehitysmenetelmille, nämä vanhat metodologiat häiriintyvät ja korvataan ketterillä käytännöillä, jotka parantavat markkinoille saattamista, vähentävät kehityskustannuksia ja tuottavat laadukkaampia ohjelmistoja, jotka vastaavat paremmin asiakkaiden odotuksia. Kun maailma vaatii enemmän ohjelmistoja, kehitysryhmät - scrappy-startupista suuryrityksiin - vastaavat haasteeseen Agile-palvelun avulla.

Mutta vaikka ketterät ohjelmistokehitysprojektit ulottuvat koko yritykselle, johto etsii edelleen parasta tapaa saada syvempi näkyvyys näihin projekteihin. Suuret organisaatiot eivät voi luottaa teokseen lähimpien subjektiivisiin anekdooteihin; he vaativat kvantitatiivista näkemystä, jonka pohjalta liiketoimintapäätökset tehdään.

Tässä on joitain nopeita vinkkejä kvantitatiivisten valintojen vaikutuksen määrittämiseksi ketterän muutoksen aikana ja sen jälkeen.

1. Aloita halutuista tuloksista, EI siitä, mitä on helppo mitata.

Parempi mittaus johtaa parempiin käsityksiin, mikä puolestaan ​​johtaa parempiin päätöksiin ja lopulta parempiin tuloksiin. Suurin osa ihmisistä aloittaa mittaamalla helppoa. Mutta helpon mittaaminen voi johtaa väärään käyttäytymiseen. Katsotaanpa tätä tarinaa kahdesta NBA-pelaajasta.

Vuonna 2010 Monta Ellis, yhdessä Golden State Warriors -tapahtuman kanssa, oli NBA: n 9. korkein maalintekijä. Carmelo Anthony, Denver Nuggets, oli kahdeksas eniten maalintekijä. Yksittäisten pisteytysten kokonaismäärien mittaaminen on helppoa. Voit olettaa, että koska he olivat tuotteliaita maalintekijöitä, heidän joukkueet voittavat.

Pelissä ollessaan joukkueet voittivat kuitenkin vähemmän . Pisteytys on kahden muun toimenpiteen funktio: 1) laukausten lukumäärä ja 2) korissa käyvien laukausten prosenttiosuus. Osoittautuu, että näillä kahdella "tähdellä" on alhaiset mitat sijalle 2, niiden ampumisprosentti. Ainoa syy siihen, että he ovat korkeita maalintekijöitä, on se, että he ottavat enemmän laukauksia. He varastavat kirjaimellisesti laukauksia joukkuetovereilta, joilla saattaa olla paremmat mahdollisuudet pisteet.

Joten vaikka oppimisen virta kulkee toimenpiteistä tuloksiin, sen ajattelutavan tulisi alkaa tuloksista. Siksi kutsumme tätä ODIM: ksi.

paremmat O UTOMIT ← paremmat D MÄÄRITELMÄT ← paremmin I TUNNISTEET ← paremmat M TAPAHTUMAT

NBA-pelaajien tulisi keskittyä tulokseen voittaa enemmän pelejä sen sijaan, että olisivat korkea maalintekijä. Jos he käyttäisivät joukkueen pisteytystodennäköisyyttä erilaisissa olosuhteissa palautteena, se auttaisi heitä tekemään parempia peliaikaisia ​​päätöksiä lopullisen voitotuloksen saavuttamiseksi. Tämä vie meidät toiseen kärkeen.

2. Ajattele mittausta palautteena, EI vipuina.

Toistuva palaute on ensisijainen ero vesiputouksen ja ketterän kehityksen välillä. Onnistuneet Agile-projektit sisältävät lyhyitä iteraatioita ja nopeaa palautetta asiakkailta. Avain tehokkaaseen ketterään mittaukseen on ajatella mittausta palautteen perusteella, ei perinteisenä vivuna käyttäytymisen motivoimiseksi. Tämä johtaa usein pisteiden pitämiseen, missä mittausten pimeä puoli alkaa - välttää sitä.

Palautteen ja vivun välillä on hieno, mutta tärkeä ero. Palaute on jotain, jonka tavoitteena on parantaa omaa suorituskykyäsi. Vipuja käytetään vaikuttamaan toisiin. Ero on enemmän siinä, kuinka käytät mittaa kuin itse mittaa.

Esimerkiksi burndown-kaavion terveellinen käyttö kertoo joukkueelle, ovatko he tiellä sitoutumisellaan, jotta he voivat tehdä muutoksia ajoissa. Vasta-esimerkki on johtaja, joka käyttää burndown-kaavioita vaikeuksissa olevien projektien punaiseen merkitsemiseen. Vaikka se saattaa edistää parannusta, kukaan ei halua, että punainen lippu heitetään heille, joten taipumuksena on pitää mittari vihreänä tilanteen todellisuudesta riippumatta.

Et voi tehdä paremmin perusteltuja päätöksiä, jos tilastotietojesi tiedot eivät kuvaa oikein todellisuutta (katso vinkki 1). Pikemminkin johtaja voisi tarjota valmennusta työkaluilla, joita joukkue voi käyttää oman suorituskykynsä parantamiseen - hieno, mutta kriittinen ero.

3. Tasapainoinen mittausjärjestelmä tai ei ollenkaan.

Ketterän mittauksen tasapaino ( kuva A ) sisältää neljä kulmakiveä:
  1. Tee se nopeasti.
  2. Tee se oikein.
  3. Tee se ajoissa.
  4. Jatka sen tekemistä.
Kuvio A

Ilman näiden neljän elementin tasapainoa on helppo keskittyä vain yhteen. Esimerkiksi, jos keskitymme vain tuottavuuden lisäämiseen, tämä todennäköisesti heikentää laatua ja asiakastyytyväisyyttä .

4. Mittaa ohjelmistokohtaiset tulokset.

  1. tuottavuus
  2. Reagointikykyä
  3. Laatu
  4. Asiakastyytyväisyys
  5. Ennustettavuus
  6. Työntekijöiden sitoutuminen

Nämä kuusi tulosta ovat osa ohjelmistokehityksen suorituskykyindeksiä (SDPI), jota käytetään kvantifioimaan kehitystyöhön liittyviä oivalluksia ja antaa palautetta siitä, kuinka prosessi- ja teknologiapäätökset vaikuttavat kehitysryhmän suoritukseen. Tietää mitä mitata ja keskittyä jokaiseen yksittäiseen elementtiin.

5. Kuuntele asiantuntijoita.

Agile on kiinnittänyt alan johtavien analyytikoiden huomion vakuuttaen olevansa avainasemassa sovelluksen elinkaarenhallinnan (ALM) arvioinneissa. Nämä arvioinnit kattavat enemmän kuin vain kehittäjien toiminnallisuuden; He arvioivat sitoutumista ALM-markkinoihin, ALM-tuotestrategiaa, yritysstrategiaa ja läsnäoloa markkinoilla. Itse asiassa riippumaton tutkimusyhtiö Forrester Research, Inc. arvioi äskettäin merkittävimmät ALM-ohjelmistotoimittajat, kohteleen Agilea ja Leania kriittisinä testeinä ALM-myyjän tarjoamalle tuotteelle. Raportissa todettiin myös, että yritykset "eivät enää voi hyväksyä historiallisia kuiluja yritys- ja sovelluskehitys- ja toimitusryhmien välillä, koska yhä enemmän yritykset odottavat nyt hallitsevansa sovellusten kehittämisen ja toimittamisen yritykseksi ja kohtelevansa sitä osaamisena".

Ketterä näkökulma ohjelmistokehitysmittareihin

Liikkuessa ketterään yleiset tavoitteet ovat suurelta osin samat kuin aiemmin: ilahduttaa käyttäjiä laadukkaalla tuotteella, joka toimitetaan ennustettavasti ja tehokkaasti. Jopa ketterän muutoksen jälkeen, teet suurimmaksi osaksi samoja "tyyppejä": analysoida, suunnitella, koodata, testata, vapauttaa, ylläpitää ja kyllä, mitata.

Näkökulma, jonka otat tekeessäsi näitä, on erilainen ketterän kanssa.

Tämän vierasviestin kirjoitti Larry Maccherone, Analytics-johtaja, Rally Software.

© Copyright 2020 | mobilegn.com