ਤੁਸੀਂ ਗੁਣਵੱਤਾ ਦੀ ਕੁਰਬਾਨੀ ਦਿੱਤੇ ਬਿਨਾਂ delivery ਦੀ ਰਫ਼ਤਾਰ ਕਿਵੇਂ ਸੁਧਾਰਦੇ ਹੋ?

Question

Accepted Answer

ਇੱਕ sprint ਤੋਂ ਲੰਮੇ ਕਿਸੇ ਵੀ ਦੂਰੀ 'ਤੇ ਰਫ਼ਤਾਰ ਅਤੇ ਗੁਣਵੱਤਾ **ਉਲਟ ਨਹੀਂ ਹਨ** — ਜੋ ਚੀਜ਼ਾਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦੀਆਂ ਹਨ (ਛੋਟੇ batches, automation, ਤੇਜ਼ feedback) ਉਹੀ ਚੀਜ਼ਾਂ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੀਆਂ ਹਨ। ਅਸਲ ਦੁਸ਼ਮਣ "ਗੁਣਵੱਤਾ" ਨਹੀਂ, ਸਗੋਂ **ਵੱਡੇ batches, ਹੱਥੀਂ ਮਿਹਨਤ, ਅਤੇ ਲੰਮੇ feedback loops** ਹਨ। ਇਨ੍ਹਾਂ 'ਤੇ ਹਮਲਾ ਕਰੋ।

## ਰਫ਼ਤਾਰ ਅਸਲ ਵਿੱਚ ਕਿੱਥੋਂ ਆਉਂਦੀ ਹੈ

- **ਛੋਟੇ batch sizes।** ਛੋਟੀਆਂ PRs ਅਤੇ ਛੋਟੇ releases ਤੇਜ਼ੀ ਨਾਲ review ਹੁੰਦੇ ਹਨ, ਬਿਹਤਰ ਟੈਸਟ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਾਫ਼-ਸੁਥਰੇ roll back ਹੁੰਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਹੌਲੀਪਨ queueing ਹੈ, typing ਨਹੀਂ।
- **Work-in-progress ਘਟਾਓ।** ਪੂਰਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨ ਨੂੰ ਹਰਾ ਦਿੰਦਾ ਹੈ। ਉੱਚ WIP context-switching ਅਤੇ ਅਟਕੇ reviews ਪੈਦਾ ਕਰਦਾ ਹੈ; ਇਸ ਨੂੰ ਸੀਮਤ ਕਰੋ ਅਤੇ throughput ਵਧਦਾ ਹੈ।
- **Gates ਨੂੰ automate ਕਰੋ।** CI, tests, linting, ਅਤੇ one-click deploys ਉਹ ਹੱਥੀਂ ਕਦਮ ਹਟਾ ਦਿੰਦੇ ਹਨ ਜੋ ਚੁੱਪ-ਚਾਪ ਘੰਟੇ ਖਾ ਜਾਂਦੇ ਹਨ ਅਤੇ ਮਨੁੱਖੀ ਗ਼ਲਤੀ ਨੂੰ ਸੱਦਾ ਦਿੰਦੇ ਹਨ।
- **Feedback loops ਨੂੰ ਛੋਟਾ ਕਰੋ।** Trunk-based development, feature flags, ਅਤੇ ਤੇਜ਼ pipelines ਤੁਹਾਨੂੰ ਹਫ਼ਤਿਆਂ ਦੀ ਬਜਾਏ ਮਿੰਟਾਂ ਵਿੱਚ defects ਲੱਭਣ ਦਿੰਦੇ ਹਨ।

## ਜੋ framework ਮੈਂ ਵਰਤਦਾ ਹਾਂ

1. **ਪਹਿਲਾਂ ਮਾਪੋ** DORA metrics ਨਾਲ — deploy frequency, lead time, change-fail rate, MTTR। ਇਹ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਕੀ ਤੁਸੀਂ ਤੇਜ਼ *ਅਤੇ* ਸੁਰੱਖਿਅਤ ਹੋਏ, ਜਾਂ ਸਿਰਫ਼ ਤੇਜ਼।
2. **bottleneck ਲੱਭੋ**, ਆਮ ਤੌਰ 'ਤੇ review queue, ਇੱਕ flaky ਹੱਥੀਂ QA ਕਦਮ, ਜਾਂ ਇੱਕ ਹੌਲੀ environment। ਉਸ ਇੱਕ ਰੁਕਾਵਟ ਨੂੰ optimize ਕਰੋ, ਸਭ ਕੁਝ ਨਹੀਂ।
3. **ਗੁਣਵੱਤਾ ਨੂੰ automation ਨਾਲ ਬਚਾਓ, ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਦੇ gates ਨਾਲ ਨਹੀਂ।** Tests ਅਤੇ flags ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਤੇਜ਼ ਜਾਣ ਦਿੰਦੇ ਹਨ; sign-off ਕਮੇਟੀਆਂ ਸਿਰਫ਼ latency ਜੋੜਦੀਆਂ ਹਨ।

## Trade-offs ਅਤੇ ਗ਼ਲਤੀਆਂ

- tests ਕੱਟਣਾ ਕੁਝ ਦਿਨ ਖ਼ਰੀਦਦਾ ਹੈ ਅਤੇ **incident ਅਤੇ ਮੁੜ-ਕੰਮ** ਵਿੱਚ ਮਹੀਨੇ ਖ਼ਰਚਦਾ ਹੈ — ਝੂਠੀ ਬੱਚਤ।
- **observability** ਤੋਂ ਬਿਨਾਂ ਤੇਜ਼ ਜਾਣ ਦਾ ਮਤਲਬ ਹੈ ਤੁਸੀਂ ਅੰਨ੍ਹੇ ship ਕਰਦੇ ਹੋ; ਰਫ਼ਤਾਰ ਨੂੰ monitoring ਅਤੇ ਆਸਾਨ rollback ਨਾਲ ਜੋੜੋ।
- "ਤੇਜ਼ ਅੱਗੇ ਵਧੋ" ਨੂੰ **ਨਾ-ਉਲਟਾਉਣਯੋਗ ਫ਼ੈਸਲਿਆਂ** (schemas, public APIs) 'ਤੇ design ਛੱਡਣ ਦਾ ਬਹਾਨਾ ਨਾ ਬਣਨ ਦਿਓ। ਉਲਟਾਉਣਯੋਗ ਚੀਜ਼ਾਂ ਤੇਜ਼ ਜਾਂਦੀਆਂ ਹਨ; one-way doors ਨੂੰ ਧਿਆਨ ਮਿਲਦਾ ਹੈ।
- ਸਥਾਨਕ optimization ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ — ਇੱਕ ਤੇਜ਼ IDE ਮਦਦ ਨਹੀਂ ਕਰਦਾ ਜੇ bottleneck ਦੋ-ਦਿਨ ਦਾ review ਇੰਤਜ਼ਾਰ ਹੈ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਮੰਨਦੀਆਂ ਹਨ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਰਫ਼ਤਾਰ ਲਈ ਗੁਣਵੱਤਾ ਦਾ ਵਪਾਰ ਕਰਨਾ ਪਵੇਗਾ, ਇਸ ਲਈ ਉਹ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਨ ਲਈ ਹੌਲੀ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਨਹੀਂ ਪਾਉਂਦੀਆਂ। ਇੱਕ Tech Lead ਜੋ ਇਹ ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿ **engineering ਅਨੁਸ਼ਾਸਨ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਟੀਮ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦੀ ਹੈ** ਟਿਕਾਊ velocity ਖੋਲ੍ਹਦਾ ਹੈ — ਉਹ ਕਿਸਮ ਜੋ incidents ਅਤੇ tech debt ਦੇ ਢੇਰ ਵਿੱਚ ਢਹਿਣ ਦੀ ਬਜਾਏ ਵਧਦੀ ਜਾਂਦੀ ਹੈ।