Sovellukseni elinkaari Agile-ympäristössä

Yksi asia, joka houkutteli minua OutSystems Agile -ympäristöön, oli kehityksen elinkaari; tuote on suunniteltu alusta alkaen kannustamaan ketteriin käytäntöihin. Sinun ei tarvitse käyttää jotain ketterää työskennelläksesi järjestelmän kanssa, mutta se mahdollistaa ketterän metodologian erittäin hyvin. Tässä on Agile Platformin kanssa tyypillisen projektin elinkaari, joka toimii hyvin minulle. (Huomaa: Muut ekosysteemissä voivat tehdä asioita eri tavalla.)

Iteraatiot

Toisto on määritelty ajanjakso kehitystyön suorittamiseksi kokonaisena yksikönä. Projekteistani löydän iteraation, joka perustuu 10 tunnin arvioituun kehitystyöhön aivan oikein. Iteraation alussa istun asiakkaan kanssa, tarkistan hänen toivottujen muutosten luettelon ja annan karkean aika-arvion jokaiselle kohteelle; tähän sisältyy testaus / kiinnitysaika (uskon, että jokaisesta kahdeksasta kehitystunnista tarvitsen kaksi tuntia testausta ja kiinnitystä). Asiakas valitsee, mikä sopii 10 tuntiin heidän tarpeidensa ja prioriteettiensa perusteella, ja pääsen sitten töihin. Kun olen valmis, esittelen toiminnallisuuden takaisin heille. Jos he ovat tyytyväisiä, lähetämme sen heidän Staging-palvelimelleen testausta varten. Mahdolliset virheenkorjaukset ("ei toimi määritellyllä tavalla") teen osana iteraatiota. Mahdolliset muutokset ("tekniset tiedot eivät vastaa tarpeita") menevät pyyntöäsi. Yleensä iteraatioiden käännösaika on yksi viikko.

Saatat ajatella, että 10 tunnin iteraatiot ovat melko lyhyitä, eikö niin? No eipä oikeastaan. Ensinnäkin teen tämän työn freelance-pohjalta; En halua tilannetta, jossa poltan kynttilän molemmista päistä tai olen poissaolon aviomies / isä, jos menen yli 10 tuntia. 10%: n ylitys 10 tunnin iteraatiossa on yksi tunti; se on neljä tuntia 40 tunnin iteraatiolla! Toiseksi olen huomannut, että ketterä alusta on minulle niin tehokas, että voin tehdä 10 tunnissa sen, mitä useimmat kokopäiväiset kehittäjät tarvitsevat täyden työviikon suorittaakseen ASP.NET: ssä tai vastaavassa tekniikassa. Seurauksena on, että laskuni on paljon pienempi kuin tyypillisen kehittäjän sama työmäärä, vaikka laskutan siistin summan iteraatiota kohti. Kolmanneksi, kokemukseni mukaan arviointivirheet ovat yleensä lumipalloja helposti. 10 tunnin iterointi rajoittaa tätä ongelmaa. Lisäksi 10 tuntia kehitystyötä on riittävän pieni, jotta työ voidaan nopeasti ja helposti eritellä ilman, että tarvitaan paljon muutoksia kehityksen keskellä. Lopuksi, toistuvasti tekemäni ominaisuuksien lukumäärän suhteen asiakas haluaa mahdollisuuden tarkistaa asiat ennen seuraavan toteutettavien ominaisuuksien valintaa tai tehtäviä muutoksia.

Alkuperäinen projektikeskustelu

Yksi asia, jonka kieltäyn tekemästä, on ennakkoarvio. Parhaimmillaan, jos mielestäni projekti voidaan tehdä kolmessa tai vähemmän iteraatioina, kerron sen asiakkaalle. Jotkut asiakkaat eivät pidä tästä, koska he haluavat nähdä "taatun" hinnan ja aikataulun. Muistutan heille muista "taattuista" hankkeista, joita heillä oli muiden myyjien kanssa ja jotka menivät nopeasti ajan ja budjetin suhteen, ja selitän hellästi, että kehitysmaailmassa mitään ei voida taata. Kun he näkevät, että iterointimenetelmäni pitää heidän kustannuksensa rajoitettuna, eikä anna minulle vapaata hallintaa kerätä suurta laskua tai luoda tilannetta, jossa minun täytyy "deskopoida ja julistaa voitto" voiton tuottamiseksi, ne yleensä myydään. Asiakkaalle, joka ei voi olla vakuuttunut tästä, en pelaa palloa. Minulla ei yksinkertaisesti ole aikaa tai energiaa kuluttaa sopimuksiin, joista tiedän olevan vaikeaa tuottaa voittoa.

Tämän lisäksi käytän tätä ajanjaksoa saadakseni hyvän kuvan asiakkaan ennakkotarpeista, erityisesti ymmärtääksemme heidän tulevia etenemissuunnitelman ideoita varmistaakseni, että sovellusarkkitehtuuri tekee siitä realistisen.

käyttöönotto

Kuten viitataan, haluan ensin esitellä palvelimilleni tekemän työn. Minulla on palvelin, johon asiakkaani pääsevät. Suosittelen asiakkailleni, että heillä on kaksi palvelinta - yksi tuotannolle ja toinen vaiheille - mutta se ei ole maailman loppu, jos heillä ei ole varaa siihen. Mukavasti, huippuluokan Agile Platform -lisenssit sisältävät käyttöoikeuden, jota ei ole tarkoitettu tuotantoon, ja uskon, että myös OutSystemsin pilvipakkaukset tarjoavat. Muutoin asiakas voi vapaasti kokeilla projektia palvelimellani.

Kun asiakas on tyytyväinen tuloksiin, otan sen käyttöön heidän järjestelmissä. Ketterä alusta tekee käyttöönotosta todella helpon. Tavallisesti minun on vain kirjauduttava sisään Web-pohjaiseen hallintoon, lähetettävä yksittäinen OML- tai ratkaisutiedosto (riippuen siitä kuinka työskentelen), ja sen jälkeen kun se on ladattu ja käännetty, se on valmis menemään. Kaikki tietokantakaavion muutokset käsitellään automaattisesti. Minun pitäisi käyttää "Ratkaisu" -lähestymistapaa, koska se antaa minun leikata yhden, yhtenäisen tiedoston, jossa on kaikki siihen liittyvät laajennukset, mutta koska muuten laajennuksia harvoin, en yleensä tiedoston koon pienentämiseksi.

Joskus uusi versio vaatii joidenkin tietojen lisäämistä tietokantaan tai muuten manipulointia. Esimerkiksi yhdessä projektissa jokaisella asiakastilillä on luettelo tiloista, joita he voivat käyttää työtilauksiin. Listaa voidaan mukauttaa, joten kun tili luodaan, se kopioidaan pääluettelosta. Joskus minun on lisättävä uusi arvo luetteloon uutta ominaisuutta varten. Sen sijaan, että tarvitsen suoraa tietokantakäyttöä, luon toiminnon, joka käsittelee tietojen manipuloinnin, ja sitran sen sitten ajastimeen, jolla ei ole määriteltyä aikataulua. Asennuksen jälkeen käynnistän ajastimen manuaalisesti ajamaan Web-pohjaisesta palvelukeskuksesta, ja kun se on suoritettu, käytän ajastinta. Varmistan, että tulevat versiot poistavat toiminnon ja ajastimen kokonaan. Seurauksena on, että tarvitsen vain suoran pääsyn tietokantaan vain alhaisen tason tietojen tarkistamisessa tai korjaamisessa.

hinnoittelu

Jotta kaikille osallistujille olisi helppoa elämä, veloitan kiinteämääräisen summan iteraatiota kohti. Se on kohtuullinen hinta asiakkaalle, varsinkin kun otetaan huomioon, että mahdolliset virhekorjaukset käsitellään ilmaiseksi osana iteraatiota. Jos iterointi menee huomattavasti ajan myötä, se on minun syytäni arvioida huonosti ja se on hyvä oppitunti minulle. Jos olen alle, tarjoan "alhaisen hinnan takuun": kun asiakas ilmoittaa työtään ja on valmis laskutukseen, veloitan heiltä tuntihinnan, jos toistoon käytetty aika (ylhäältä toiseen) pohja, mukaan lukien suunnittelu, arvostelu, käyttöönotto, korjaukset jne.) on alle seitsemän tuntia. Tämä antaa asiakkaalle tietää, etten taltta niitä, ja antaa minulle suuren kannustimen suunnitella oikein.

tulokset

Siitä lähtien kun aloitin konsultointityön Agile Platformin kanssa vuoden 2011 alussa, olen oppinut paljon oppitunteja. Minulla oli yhdestä projektista tullut paljon enemmän työtä kuin aikoin, koska alkuperäisen iteraation työn laajuudessa oli alussa liian monta avointa kysymystä. En kysynyt riittävän yksityiskohtaisia ​​kysymyksiä etukäteen ymmärtääkseni, että ehdotetussa algoritmissa oli paljon loogisia epäjohdonmukaisuuksia, ja se päätyi toteuttamiseen ja uudelleenasentamiseen useita kertoja. Se on klassinen ohjelmointivirhe, jota toivottavasti en toista. Mutta suurimmaksi osaksi lyhyet iteraatiot sekä kiinteähinnoittelu ovat tehneet hienoa työtä eristämällä kaikki osapuolet tunnilla ja kiinteäkorkoisilla sopimuksilla yleensä olevista vaaroista.

J.Ja

© Copyright 2020 | mobilegn.com