Data Driven Development (DDD)

Data Driven Development (andmetepõhine arendus) on tarkvaraarenduse metoodika, kus otsuseid ja prioriteete ei määra mitte "kõhutunne" või hierarhia (nt kõrgeima palgaga isiku arvamus), vaid kogutud kvantitatiivsed ja kvalitatiivsed andmed.

Selle mudeli eesmärk on vähendada ebakindlust, valideerides hüpoteese reaalsete kasutajate peal võimalikult vara. See on tihedalt seotud Lean Startup ja Agile põhimõtetega.

Arendusmudeli etapid

DDD protsess on tsükliline, mitte lineaarne. Tüüpilised etapid on järgmised:

1. Eesmärgi seadmine ja hüpotees: Määratletakse, millist mõõdikut (KPI) tahetakse parandada ja püstitatakse hüpotees (nt "Nupu värvi muutmine tõstab konversiooni 5%").
2. Andmete kogumise planeerimine: Otsustatakse, milliseid andmeid on vaja hüpoteesi tõestamiseks ja kuidas neid logida.
3. Arendus (Build): Luuakse minimaalne vajalik funktsionaalsus (MVP) või muudatus.
4. Mõõtmine (Measure): Funktsionaalsus lastakse kasutajateni ja kogutakse kasutusstatistikat.
5. Analüüs ja õppimine (Learn): Võrreldakse tulemusi eesmärgiga. Kas hüpotees pidas paika?
6. Otsustamine: Kas jätkata (persevere), muuta suunda (pivot) või lahendus hüljata.

Kas sellel on alamvariante?

Kuigi DDD ise on pigem katusmõiste või "mõtteviis", eksisteerib selle all spetsiifilisemaid lähenemisi ja alamvariante:

Tähelepanu: Ära aja segi TDD-ga (Test Driven Development). TDD räägib koodi tehnilisest testimisest, DDD aga toote ärilisest valideerimisest andmete abil.

Hypothesis-Driven Development (HDD): Väga rangelt teaduslikule meetodile allutatud variant. Iga arendusülesanne sõnastatakse eksperimendina: "Usume, et [tegevus] toob kaasa [tulemuse]. Teame, et see on tõsi, kui näeme [mõõdik]."
A/B Testimine kui arendusmudel: Lähenemine, kus uusi lahendusi ei rullita kunagi välja 100% kasutajatele korraga, vaid arendusprotsessi loomulik osa on pidev variantide võrdlemine kontrollgrupiga.
Telemetry-First Development: DevOps-keskne alamliik, kus monitooring ja logimine ehitatakse süsteemi sisse enne äriloogikat, et tagada kohene nähtavus (observability).

Arendusmudel joonisena

Data Driven Development mudelit kujutatakse kõige sagedamini ringdiagrammina (tagasiside silmusena), mis on tuntud kui "Build-Measure-Learn" tsükkel.

Joonis: Build-Measure-Learn tagasiside tsükkel

Joonis on iteratiivne: see algab ideest, liigub koodi kirjutamiseni, sealt andmete kogumiseni ja lõpuks tagasi uue ideeni, mis põhineb õpitul.

Mudeli tähtsaim omadus

Tagasiside ahel (Feedback Loop)

Kõige kriitilisem omadus on lühike ja objektiivne tagasiside ahel.

Miks? Ilma kiire tagasisideta on andmete kogumine vaid "edevusmõõdik" (vanity metric). Mudeli väärtus seisneb selles, et arendustiim ei raiska aega funktsioonidele, mida keegi ei kasuta. See asendab subjektiivsed arvamused objektiivse reaalsusega, võimaldades ebaõnnestuda kiiresti ja odavalt (fail fast).

Heade ja Veade tabel

Positiivne (Head)	Negatiivne (Vead) / Riskid
Objektiivsus: Vähendab isiklikel arvamustel põhinevaid vaidlusi ja poliitikat organisatsioonis.	Analüüsi halvatus (Analysis Paralysis): Oht jääda andmeid jõllitama ja lõputult analüüsima, lükates otsuseid edasi.
Parem ROI (Tasuvus): Ressurss suunatakse sinna, mis päriselt toob tulu või väärtust kasutajale.	Konteksti puudumine: Andmed näitavad "mis" juhtus, aga harva "miks". Võib tekkida valesid järeldusi ilma kvalitatiivse uuringuta.
Parem kasutajakogemus (UX): Toodet arendatakse vastavalt sellele, kuidas inimesed seda tegelikult kasutavad.	Lokaalne maksimum: Andmed võivad optimeerida olemasolevat lahendust, kuid ei pruugi viidata vajadusele radikaalse innovatsiooni järele (mida andmetes veel pole).
Riskide maandamine: Vigased ideed praagitakse välja enne suuremahulist investeeringut.	Privaatsusprobleemid: Liigne andmekorje võib minna vastuollu GDPR-i või kasutajate usaldusega.
Loe lähemalt: How to Implement Hypothesis-Driven Development (ThoughtWorks)

Viited

ThoughtWorks / Barry O'Reilly - "How to Implement Hypothesis-Driven Development". Link artiklile