Livssyklusen min i smidig plattform

En ting som trakk meg til OutSystems Agile Platform var utviklingslivssyklusen; produktet er designet fra grunnen av for å oppmuntre til smidig praksis. Du trenger ikke å bruke noe Agile for å jobbe med systemet, men det muliggjør Agile-metodikk veldig bra. Her er en gjennomgang av livssyklusen til et typisk prosjekt med Agile Platform som fungerer bra for meg. (Merk: Andre i økosystemet kan gjøre ting annerledes.)

Iterasjonene

En iterasjon er en definert tidsblokk for å utføre utviklingsarbeid som en komplett enhet. På prosjektene mine finner jeg at en iterasjon som er basert på 10 timers estimert utviklingsarbeid er helt riktig. I begynnelsen av en iterasjon setter jeg meg sammen med klienten, går gjennom listen over ønskede endringer og gir et grovt tidsestimat for hver vare; Dette inkluderer test / fiksetid (jeg antar at for hver åttende times utvikling, trenger jeg to timer med testing og fiksering). Klienten velger hva som vil passe inn i 10 timer ut fra deres behov og prioriteringer, og så kommer jeg på jobb. Når jeg er ferdig, demonstrerer jeg funksjonaliteten tilbake til dem. Hvis de er fornøyde, distribuerer vi det til deres Staging-server for testing. Eventuelle feilrettinger ("fungerer ikke så spesifikt") jeg gjør som en del av iterasjonen. Eventuelle endringer ("spesifikasjoner samsvarer ikke med behov") går i forespørselsbøtten. Generelt har iterasjoner en behandlingstid på en uke.

Du synes kanskje 10-timers iterasjoner er ganske korte, ikke sant? Vel, egentlig ikke. Først og fremst gjør jeg dette arbeidet på frilansbasis; Jeg vil ikke ha en situasjon der hvis jeg går over de 10 timene jeg brenner lyset i begge ender eller er en fraværende mann / far. Et 10% overskudd på en 10-timers iterasjon er en time; det er fire timer i en 40 timers iterasjon! For det andre har jeg funnet ut at Agile-plattformen er så effektiv for meg, at jeg kan gjøre på 10 timer det de fleste heltidsutviklere trenger en hel arbeidsuke for å oppnå i ASP.NET eller lignende teknologi. Som et resultat kommer regningen min mye lavere enn en typisk utvikler for den samme arbeidsmengden, selv om jeg belaster en ryddig sum per iterasjon. For det tredje har det vært min erfaring at estimeringsfeil har en tendens til å snøball veldig lett. En 10-timers iterasjon begrenser problemet. I tillegg er 10 timers utviklingsarbeid lite nok til at arbeidet raskt og enkelt kan spesifiseres, uten stort behov for endringer midt i utviklingen. Til slutt, med antall funksjoner gjort i en av mine iterasjoner, ønsker kunden en sjanse til å gjennomgå ting før han velger neste sett med funksjoner som skal implementeres eller endringer som skal gjøres.

Innledende prosjektdiskusjon

En ting jeg nekter å gjøre er å gi et anslag foran. I beste fall, hvis jeg tror at prosjektet kan gjøres i tre eller færre iterasjoner, vil jeg fortelle det til klienten. Noen kunder liker ikke dette, fordi de vil se en "garantert" pris og tidslinje. Jeg minner dem om de andre "garanterte" prosjektene de hadde med andre leverandører som raskt gikk over tid og budsjett, og forklarer forsiktig at i utviklingsverdenen kan ingenting garanteres. Når de ser at iterasjonsmetodikken min holder kostnadene begrenset og ikke gir meg fri regjering for å ringe opp en enorm regning, eller skape en situasjon der jeg trenger å "descope og erklære seier" for å tjene penger, blir de vanligvis solgt. For en kunde som ikke kan være overbevist om dette, spiller jeg ikke ball. Jeg har rett og slett ikke tid eller energi til å bruke på kontrakter som jeg vet vil være vanskelig å tjene penger på.

Utover det bruker jeg denne perioden for å få en god ide om klientens forhåndsbehov, spesielt for å forstå deres fremtidige veikartideer for å sikre at applikasjonsarkitekturen gjør den realistisk.

Utplassering

Som nevnt, liker jeg først å demonstrere arbeidet på serverne mine. Jeg har en server som kundene mine kan få tilgang til. Jeg anbefaler kundene mine at de har to servere - en for produksjon og en for iscenesettelse - men det er ikke verdens ende hvis de ikke har råd til det. Pent nok inkluderer high-end Agile Platform-lisenser en ikke-til-produksjon-bruk lisens, og jeg tror at nettsky-tilbudet fra OutSystems gjør det også. Ellers står klienten fritt til å eksperimentere med prosjektet på serveren min.

Når klienten er fornøyd med resultatene, distribuerer jeg til systemene deres. Agile Platform gjør distribusjonen veldig enkel. Vanligvis trenger jeg bare å logge inn på den nettbaserte administrasjonen, laste opp den ene OML- eller løsningsfilen (avhengig av hvordan jeg jobber), og etter at den har lastet opp og kompilert er den klar til å gå. Alle databaseskjemaendringene håndteres automatisk. Jeg bør bruke "Solution" -tilnærmingen fordi den lar meg klippe en enkelt enhetlig fil med alle utvidelsene i den, men siden jeg sjelden endrer utvidelser, har jeg en tendens til å ikke gjøre det for å redusere filstørrelsen.

Noen ganger vil en ny versjon kreve at noen data settes inn i databasen eller på annen måte manipuleres. I et prosjekt har for eksempel hver kundekonto en liste over statuser som de kan bruke for arbeidsordrer. Listen kan tilpasses, så når kontoen opprettes, kopieres den fra en masterliste. Noen ganger trenger jeg å injisere en ny verdi i listen for en ny funksjon. I stedet for å trenge direkte databasetilgang, oppretter jeg en handling som håndterer datamanipulasjonen, og knytter den deretter til en tidsur uten definert plan. Etter distribusjon trigger jeg Timeren manuelt til å kjøres fra det nettbaserte servicesenteret, og når den har kjørt, deaktiverer jeg Timeren. Jeg sørger for at fremtidige versjoner fjerner Action og Timer fullstendig. Som et resultat, de eneste gangene jeg trenger direkte tilgang til databasen, er datakontroll eller fiksing av lavt nivå.

Priser

For å gjøre livet enkelt for alle involverte, belaster jeg en fast sats per iterasjon. Det er en rimelig pris for kunden, spesielt med tanke på at eventuelle feilrettinger håndteres gratis som en del av iterasjonen. Hvis iterasjonen går betydelig over tid, er det min feil å estimere dårlig, og det er en god leksjon for meg. Hvis jeg er underveis, tilbyr jeg en "lavprisgaranti": når kunden har meldt seg på arbeidet og er klar for fakturering, belaster jeg dem en timesats hvis den sanne tiden brukt på iterasjonen (fra topp til- bunnen, inkludert planlegging, gjennomgang, distribusjon, rettelser osv.) er under syv timer. Dette lar kunden vite at jeg ikke meisler dem, og gir meg et stort insentiv til å planlegge ordentlig.

resultater

Siden jeg begynte med konsulentarbeid med Agile Platform tidlig i 2011, har jeg lært mye. Jeg fikk ett prosjekt til å bli mye mer arbeid enn jeg hadde tenkt fordi arbeidsomfanget for den første iterasjonen hadde for mange åpne spørsmål i begynnelsen. Jeg stilte ikke nok detaljerte spørsmål på forhånd til å innse at den foreslåtte algoritmen hadde mange logiske inkonsekvenser, og det endte med at den ble implementert og implementert på nytt en rekke ganger. Det er en klassisk programmeringsfeil som jeg håper jeg ikke gjentar. Men for det meste har de korte iterasjonene pluss fast pris gjort en god jobb med å isolere alle parter fra farene per time og fast rente kontrakter vanligvis har.

J.Ja

© Copyright 2021 | pepebotifarra.com