Kako poboljšavate brzinu isporuke bez žrtvovanja kvalitete?

Question

Accepted Answer

Brzina i kvaliteta **nisu suprotnosti** na bilo kojem horizontu duljem od sprinta — stvari koje vas čine brzima (mali batchevi, automatizacija, brz feedback) iste su stvari koje vas drže sigurnima. Pravi neprijatelj nije "kvaliteta", to su **veliki batchevi, ručni rad i duge povratne petlje**. Napadni njih.

## Odakle brzina zapravo dolazi

- **Manje veličine batcheva.** Manji PR-ovi i manja izdanja pregledavaju se brže, testiraju bolje i čišće se rollbackaju. Većina sporosti je čekanje u redu, a ne tipkanje.
- **Smanji posao u tijeku.** Dovršavanje pobjeđuje započinjanje. Visok WIP stvara prebacivanje konteksta i zaglavljene reviewe; ograniči ga i propusnost raste.
- **Automatiziraj gateove.** CI, testovi, linting i deploy jednim klikom uklanjaju ručne korake koji tiho jedu sate i pozivaju ljudsku grešku.
- **Skrati povratne petlje.** Trunk-based development, feature flagovi i brzi pipelineovi omogućuju da pronađete defekte u minutama umjesto tjednima.

## Okvir koji koristim

1. **Prvo mjeri** s DORA metrikama — učestalost deploya, lead time, change-fail rate, MTTR. Pokazuju jeste li postali brži *i* sigurniji, ili samo brži.
2. **Pronađi usko grlo**, obično red reviewa, nestabilan ručni QA korak ili spor environment. Optimiziraj to jedno ograničenje, ne sve.
3. **Zaštiti kvalitetu automatizacijom, ne gateovima ljudskog odobrenja.** Testovi i flagovi omogućuju da idete brzo i sigurno; odbori za odobravanje samo dodaju latenciju.

## Kompromisi i zamke

- Rezanje testova kupuje nekoliko dana, a košta mjesece u **incidentima i preradama** — lažna ušteda.
- Brzina bez **observabilnosti** znači da isporučujete naslijepo; upari brzinu s praćenjem i lakim rollbackom.
- Ne dopusti da "kreći se brzo" postane izgovor za preskakanje dizajna na **nepovratnim odlukama** (sheme, javni API-ji). Reverzibilne stvari idu brzo; jednosmjerna vrata dobivaju pažnju.
- Čuvaj se lokalne optimizacije — brži IDE ne pomaže ako je usko grlo dvodnevno čekanje na review.

## Zašto je to važno

Većina timova vjeruje da moraju mijenjati kvalitetu za brzinu, pa usporavaju da bi se osjećali sigurno i ne dobiju ni jedno ni drugo. Tech Lead koji može pokazati da je **inženjerska disciplina ono što tim čini brzim** otključava održiv velocity — onaj koji se akumulira umjesto da se uruši u hrpu incidenata i tech debta.