I denne artikel skal vi tale om Agile Development og dens fordele og ulemper i forhold til en Waterfall-tilgang. Vi giver dig tilstrækkelig indsigt til at hjælpe dig med at beslutte den bedste plan for dit næste store digitale produkt.
Før vi går i gang, mener vi, at det er vigtigt at give dig et hurtigt overblik over vores historie og ekspertise som virksomhed.
RebelDot startede som et teknologisk datterselskab af et stort produktfirma i Washington, USA, i 2008. I et par solide år arbejdede vi på at opbygge digitale produkter til store & anerkendte forsikringsselskaber såvel som Fortune 500-virksomheder. Vi brugte fire år på at perfektionere og styrke vores tilgang til at opbygge digitale produkter. Senere i 2012 besluttede vi, at vi ville bruge vores produktviden og erfaring til at hjælpe virksomheder, startups og virksomheder med at accelerere deres vej mod digitalisering og teknologiinnovation. Spol frem i dag har vores tværfunktionelle teams hjulpet mere end 50 virksomheder med at bringe digitale produkter på markedet.
I dag er vi heldige nok til at have oplevet mange forskellige scenarier og tilgange, når det kommer til at bygge produkter. Vores interaktioner med forskellige virksomheder og forretningsscenarier har en gang for alle vist os vigtigheden af at være Agile, når det kommer til både startups og enterprise virksomheder.
Hvad er Agile Methodology?
Før vi går videre med Agile Development, lad os tage et kig på betydningen af det.
Det er vores forståelse, at forfatterne af Agile Manifesto gik for Agile som en etiket for denne idé, fordi ordet repræsenterer tilpasningsevne, hvilket er så vigtigt for hele tilgangen.
Ved at omsætte hele dette agilitetskoncept til produktudviklingsverdenen ser vi, hvordan det at være Agile betyder at vedtage en iterativ tilgang til produktstyring og softwareudvikling, hvilket hjælper teams med at levere værdi til kunderne i et hurtigt tempo.
Så i stedet for store afsløringer og big bang-lanceringer udvikler et agilt team sig i små iterationer. Produktkøreplaner, krav og funktioner evalueres løbende, hvilket skaber en naturlig mekanisme til hurtig reaktion på ændringer. Temmelig sejt, ikke?
Kundefeedback er ekstremt vigtigt i opbygningen af digitale produkter efter en agil tilgang, og både test og udvikling udføres baseret på kundefeedback og respons.
Agile Methodology & Waterfall — hvilken skal du vælge til dit digitale produkt?
Mens Waterfall er en lineær model for softwareudvikling, er Agile en inkrementel og iterativ tilgang til at bygge software. Selv med nyere historie har Agile-udvikling vundet stor popularitet, især inden for teknologi-start-up-scenen, hvor åbenhed over for forandring og tilpasningsevne til markedets krav er afgørende.
Nedenfor er et par af de vigtigste punkter, du bør tage i betragtning, når du skal vælge mellem Agile og Waterfall til ny produktudvikling.
Med et hurtigt kig på historien om Agile Development kom denne nye metode til at løse nogle af de mest tydelige problemer og udfordringer, produktteams stod over for, når de fulgte en Waterfall-tilgang.
Kundefeedback og være åben for forandring.
Planlægningen om at lancere nye digitale produkter i nutidens ultra-konkurrencedygtige teknologiscene skal komme med en ekstraordinær evne til at tilpasse sig ændringer og kundefeedback. Hvis du har fulgt os i et stykke tid, ved du, at vi lægger stor vægt på kundefeedback af en vigtig grund: det hjælper interessenter med at sikre, at det, de bygger, svarer til reelle kundebehov. Ved at tilskynde til trinvis udvikling giver agil udvikling en ramme for at undgå store produktafsløringer efter fordybelse i måneder, måske år med udvikling.
Agil udvikling hjælper interessenter med at prioritere de funktioner, de ønsker at inkludere i deres produkt, ved at tilskynde produktteams til at tænke over de udfordringer og de problemer, det digitale produkt løser for det marked, de lancerer på.
Mens en Waterfall-tilgang lægger stor vægt på omfattende planlægning, inden du går i dybden med udviklingen, kan det at være Agile betyde, at du ikke er 100% sikker på, hvordan det digitale produkt kan ende med at se ud. Alligevel er du sikker på, at det, du bygger, er, hvad dine kunder ønsker
Betyder det at være Agile mindre økonomisk forudsigelighed?
Kort svar, ja. Alligevel vil du blive overrasket over at finde ud af, hvordan mindre budgetforudsigelighed kan fungere til din fordel. Her er hvorfor:
Du har en god produktidé, det vil sige (håber vi) baseret på et problem, du har identificeret, og du ønsker at løse for dine kunder. Af hensyn til denne historie, lad os antage, at du planlægger at opbygge en platform, der sigter mod at forbinde kunstnere med kunstsamlere med omfanget af at købe kunstværker. De vigtigste og første, der skal udvikles, funktioner på din digitale platform vil være centreret omkring at løse netop dette problem: at skabe en måde for kunstsamlere at oprette forbindelse til kunstnere. Nu har du måske en idé om andre interessante funktioner, der måske passer til formålet med din app, men du kan ikke vide med sikkerhed, om disse funktioner tilføjer værdi til hele brugernes oplevelse. Efter en Agile-metode frigiver du den første version af dit digitale produkt eller en MVP, indsamler feedback fra den måde, brugerne interagerer med applikationerne på, og først derefter beslutter du, hvilke funktioner der skal gå ind i den anden version af dit digitale produkt.
Da der ikke er fuld synlighed over hele produktplanen, vil udviklingsteams finde ud af, at det er næsten umuligt at nøjagtigt estimere hele udviklingsindsatsen for din app. I stedet vil de oprette en ballpark-estimering, fremhæve den minimale indsats for at udvikle din app såvel som den maksimale indsats, med det omtale, at hvis anvendelsesområdet ændres, vil estimaterne også ende med at blive ændret.
Lad os tænke på det samme forretningsscenarie efter en Waterfall-metode til produktudvikling. Vi ville se på alle de funktioner, der forestilles til denne specifikke digitale platform, og estimere alt med større nøjagtighed.
Risikoen? Da kundefeedback i tilfælde af Waterfalls produktudvikling udsættes til meget sent i projektet, kan du falde i den (meget farlige) fælde at bygge et produkt, som din kundebase ikke har brug for. Det er fordi du bygger på antagelser og ikke på reel feedback, som i tilfældet med Agile Development. Så ender du med at have et klart overblik over hele udviklingsindsatsen, der måske ender med at være meningsløs, når du indser, at din kundebase har brug for noget andet. At komme i gang med at ændre hele systemet er som at hoppe ind i en faldgrube.
Tid til markedsføring.
Hvis du ønsker at markedsføre et produkt så hurtigt som muligt, så er Agile Development uden tvivl vejen at gå. Tilskynder feedbackbaserede iterationer og trinvis udvikling, og Agile Development-teamet vil rådgive hurtige udgivelser efterfulgt af hurtige forbedringer.
I tilfælde af vandfaldsmetoden skal du muligvis vente i måneder og år for at have dit produkt på markedet.
Brugerindlæringskurve.
Selvom der ikke er så meget diskussion omkring dette emne, har vores mange års udvikling for virksomheder vist os et andet vigtigt, brugercentreret aspekt, når det kommer til agil produktudvikling: hurtige og trinvise udgivelser hjælper brugerne med at tilpasse sig adfærden i din mobil eller webapplikation på farten. Du vil først lancere et produkt med færre funktioner og langsomt opgradere oplevelsen for at sikre en kort læringskurve for dine brugere. Jo mere problemfri og minimal den første version af dit produkt er, jo højere er adoptions- og brugsraten.
For bedre at illustrere dette, lad os tage et kig på Facebook og de otte hovedfunktioner i den første version af appen - udgivet i 2004:
Ifølge Adam D'Angelo & Business Insider, de er:
- Brugerkonti (med rigtige navne påkrævet), begrænset til @harvard .edu e-mail-adresser;
- Venner, herunder venneanmodninger;
- Invitationer (ingen kontaktimportør; du skulle indtaste hver e-mail-adresse individuelt);
- Profiler, med et enkelt foto for hver bruger;
- Evne til at liste brugermetadata som køn, fødselsdag, kollegie, telefonnummer, yndlingsmusik, yndlingsbøger, „om mig“, kurser (struktureret);
- Søg efter navn, klasseår, kurser, andre metadata;
- Nogle privatlivsbegrænsninger for at begrænse, hvem der kunne se din profil (kun venner, kun folk i mit klasseår);
- En funktion til at visualisere en brugers vennegraf, som senere blev klippet.
I dag er Facebook et hav af kompleks funktionalitet, der tager meget tid og energi at lære, og at nå dette niveau af kompleksitet krævede en masse brugerfeedback og analyser, der stadig er i gang.
At placere et overkomplekst, funktionsfyldt produkt på markedet med at give dine brugere tid til at tilpasse sig for at lære din platform vil i sidste ende dræbe din brugerbase.
At bygge eller ikke at bygge et minimum levedygtigt produkt.
Som en Agile udviklingsteamVi opfordrer både startups og virksomheder til først at opbygge et minimum levedygtigt produkt (MVP).
At være Agile hjælper dig med at identificere de problemer, du ønsker at løse for dine kunder, før du identificerer funktionerne.
Vi ved, hvor fristende det er at tale om de fantastiske funktioner og funktionaliteter i dit nye produkt, men sørg for ikke at skynde dig ind i dette. Vi har set en masse iværksættere, der bare vil gå ud og bygge en masse ting uden et klart mål, og det er bare penge smidt ud på vinduet.
Ikke desto mindre er en MVP en stor del af at være Agile. Vi dækkede alt hvad du bør vide om opbygning af en MVP i denne artikel om hvordan man innoverer med et minimum af levedygtige produkter og hurtig kundefeedback.
Vi håber, at denne artikel gav dig et godt overblik over, hvad det vil sige at bygge digitale produkter — på den agile måde. Hvis du føler, at der er nogle aspekter, vi ikke dækkede, række ud og vi vil være glade for at bruge tid i samtale med dig.
