Min applikationslivscyklus i Agile Platform

Én ting, der tiltrækkede mig til OutSystems Agile Platform var udviklingslivscyklussen; Produktet er designet fra bunden af ​​for at opmuntre til agile praksis. Du behøver ikke at bruge noget Agile til at arbejde med systemet, men det muliggør Agile-metodologi meget godt. Her er en gennemgang af livscyklussen til et typisk projekt med Agile Platform, der fungerer godt for mig. (Bemærk: Andre i økosystemet gør muligvis tingene anderledes.)

Iterationerne

En iteration er en defineret tidsblok til at udføre udviklingsarbejde som en komplet enhed. På mine projekter finder jeg, at en iteration, der er baseret på 10 timers estimeret udviklingsarbejde, er helt rigtig. I begyndelsen af ​​en iteration sætter jeg mig sammen med klienten, gennemgår deres liste over ønskede ændringer og giver et groft tidsestimat for hver artikel; dette inkluderer test / fix tid (jeg antager, at for hver otte timers udvikling, har jeg brug for to timers test og fixing). Klienten vælger, hvad der passer ind i 10 timer, baseret på deres behov og prioriteter, og så kommer jeg på arbejde. Når jeg er færdig, demonstrerer jeg funktionaliteten tilbage til dem. Hvis de er glade, distribuerer vi det på deres Staging-server til deres test. Eventuelle fejlrettelser ("fungerer ikke som specificeret"), jeg gør som en del af iterationen. Eventuelle ændringer ("spec matcher ikke behov") går i anmodningspanden. Generelt har iterationer en omdrejningstid på en uge.

Du synes måske, at 10-timers iterationer er ret korte, ikke? Ikke rigtig. Først og fremmest udfører jeg dette arbejde på freelance-basis; Jeg vil ikke have en situation, hvor hvis jeg går over de 10 timer, jeg brænder lyset i begge ender eller er en fraværende mand / far. En 10% overskud på en 10-timers iteration er en time; det er fire timer i en 40 timers iteration! For det andet har jeg fundet ud af, at Agile-platformen er så effektiv for mig, at jeg kan gøre på 10 timer, hvad de fleste fuldtidsudviklere har brug for en fuld arbejdsuge for at udføre i ASP.NET eller en lignende teknologi. Som et resultat kommer min regning meget lavere end en typisk udvikler for den samme arbejdsbyrde, selvom jeg opkræver en ryddig sum pr. Iteration. For det tredje har det været min oplevelse, at estimeringsfejl har en tendens til snebold meget let. En 10-timers iteration begrænser dette problem. Derudover er 10 timers udviklingsarbejde lille nok til, at arbejdet hurtigt og let kan specificeres uden stort behov for ændringer midt i udviklingen. Endelig, med antallet af funktioner, der er udført i en af ​​mine iterationer, ønsker kunden en chance for at gennemgå tingene, før han vælger det næste sæt funktioner, der skal implementeres eller ændringer, der skal foretages.

Indledende projektdiskussion

Én ting, jeg nægter at gøre, er at give et overslag. Hvis jeg i bedste fald tror, ​​at projektet kan udføres i tre eller færre iterationer, vil jeg fortælle det til klienten. Nogle kunder kan ikke lide dette, fordi de ønsker at se en "garanteret" pris og tidslinje. Jeg minder dem om de andre "garanterede" projekter, de havde med andre leverandører, der hurtigt gik over tid og budget, og forklar forsigtigt, at der i udviklingsverdenen intet kan garanteres. Når de ser, at min iterationsmetodik holder deres omkostninger begrænset og ikke giver mig fri regeringsperiode til at ringe til en enorm regning, eller skabe en situation, hvor jeg er nødt til at "afkaste og erklære sejr" for at tjene penge, sælges de normalt. For en kunde, der ikke kan overbevises om dette, spiller jeg ikke bold. Jeg har simpelthen ikke tid eller energi til at bruge på kontrakter, som jeg ved, at det vil være svært at tjene penge på.

Derudover bruger jeg denne periode til at få en god idé om klientens up-front behov, især for at forstå deres fremtidige køreplanideer for at sikre, at applikationsarkitekturen gør det realistisk.

Deployment

Som henvist til, kan jeg først demonstrere arbejdet på mine servere. Jeg har en server, som mine kunder kan få adgang til. Jeg anbefaler mine kunder, at de har to servere - en til produktion og en til iscenesættelse - men det er ikke verdens ende, hvis de ikke har råd til det. Pænt nok inkluderer high-end Agile Platform-licenser en ikke-til-produktionsbrug licens, og jeg tror, ​​at cloud-tilbudet fra OutSystems også gør det. Ellers står klienten frit til at eksperimentere med projektet på min server.

Når klienten er tilfreds med resultaterne, implementerer jeg deres systemer. Agile Platform gør implementeringen virkelig let. Typisk behøver jeg bare at logge ind på den webbaserede administration, uploade den enkelte OML- eller Solution-fil (afhængigt af hvordan jeg arbejder), og når den er uploadet og kompileres er den klar til at gå. Alle databaseskemaændringer håndteres automatisk. Jeg skal bruge fremgangsmåden "Løsning", fordi den giver mig mulighed for at klippe en enkelt, samlet fil med alle udvidelserne i den, men da jeg sjældent ændrer udvidelser, har jeg en tendens til ikke for at reducere filstørrelsen.

Nogle gange kræver en ny version, at nogle data indsættes i databasen eller på anden måde manipuleres. I et projekt har for eksempel hver kundekonto en liste over status, som de kan bruge til arbejdsordrer. Listen kan tilpasses, så når kontoen oprettes, kopieres den fra en masterliste. Nogle gange er jeg nødt til at injicere en ny værdi på listen for en ny funktion. I stedet for at have brug for direkte databaseadgang opretter jeg en handling, der håndterer datamanipulationen og derefter binder den til en timer uden nogen defineret tidsplan. Efter installationen udløser jeg Timeren manuelt til at køre fra det webbaserede servicecenter, og når det først er kørt, deaktiverer jeg timeren. Jeg sørger for, at fremtidige versioner fjerner handlingen og timeren helt. Som et resultat er de eneste gange, jeg har brug for direkte adgang til databasen, datakontrol eller rettelse af lavt niveau.

Prisfastsættelse

For at gøre livet let for alle involverede opkræver jeg en fast sats pr. Iteration. Det er en rimelig pris for kunden, især i betragtning af at fejlrettelser håndteres gratis som en del af iterationen. Hvis iterationen går markant over tid, er det min skyld at estimere dårligt, og det er en god lektion for mig. Hvis jeg er langt væk, tilbyder jeg en "lavprisgaranti": når kunden logger af på arbejdet og er klar til fakturering, opkræver jeg dem en timesats, hvis den rigtige tid brugt på iterationen (fra top-til- bund, herunder planlægning, gennemgang, implementering, rettelser osv.) er under syv timer. Dette lader kunden vide, at jeg ikke mejsler dem, og giver mig et stort incitament til at planlægge korrekt.

Resultater

Siden jeg begyndte med konsulentarbejde med Agile Platform i begyndelsen af ​​2011, har jeg lært en masse lektioner. Jeg fik et projekt til at blive meget mere arbejde, end jeg havde til hensigt, fordi arbejdsomfanget til den indledende iteration havde for mange åbne spørgsmål i begyndelsen. Jeg stillede ikke nok detaljerede spørgsmål på forhånd til at indse, at den foreslåede algoritme havde en masse logiske uoverensstemmelser, og det endte med at blive implementeret og geninstalleret en række gange. Det er en klassisk programmeringsfejl, som jeg håber, at jeg ikke gentager. Men for det meste har de korte iterationer plus fast prisfastsættelse gjort et godt stykke arbejde med at isolere alle parter fra de farer, som kontrakter pr. Time og fast rente typisk har.

J.Ja

© Copyright 2021 | mobilegn.com