آپ معیار کو قربان کیے بغیر ڈلیوری کی رفتار کیسے بہتر کرتے ہیں؟

Question

Accepted Answer

رفتار اور معیار ایک sprint سے طویل کسی بھی افق پر **متضاد نہیں** ہیں — وہ چیزیں جو آپ کو تیز بناتی ہیں (چھوٹے batches، automation، تیز feedback) وہی چیزیں ہیں جو آپ کو محفوظ رکھتی ہیں۔ اصل دشمن "معیار" نہیں ہے، یہ **بڑے batches، دستی محنت، اور لمبے feedback loops** ہیں۔ ان پر حملہ کریں۔

## رفتار دراصل کہاں سے آتی ہے

- **چھوٹے batch sizes۔** چھوٹے PRs اور چھوٹے releases تیزی سے review ہوتے ہیں، بہتر test ہوتے ہیں، اور صاف roll back ہوتے ہیں۔ زیادہ تر سستی قطار میں لگنا ہے، typing نہیں۔
- **زیر کام کو کم کریں۔** ختم کرنا شروع کرنے کو شکست دیتا ہے۔ زیادہ WIP context-switching اور رکے ہوئے reviews پیدا کرتا ہے؛ اسے محدود کریں اور throughput بڑھتا ہے۔
- **gates کو خودکار بنائیں۔** 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۔ اس ایک رکاوٹ کو بہتر کریں، ہر چیز کو نہیں۔
3. **معیار کو automation سے بچائیں، انسانی منظوری کے gates سے نہیں۔** Tests اور flags آپ کو تیزی سے محفوظ طور پر جانے دیتے ہیں؛ sign-off committees صرف تاخیر بڑھاتی ہیں۔

## Trade-offs اور نقصانات

- tests کاٹنا چند دن خریدتا ہے اور **incident اور دوبارہ کام** میں مہینوں خرچ کرتا ہے — جھوٹی بچت۔
- **observability** کے بغیر تیزی سے جانے کا مطلب ہے آپ اندھے ہو کر ship کرتے ہیں؛ رفتار کو monitoring اور آسان rollback کے ساتھ جوڑیں۔
- "تیزی سے بڑھو" کو **ناقابلِ واپسی فیصلوں** (schemas، public APIs) پر design چھوڑنے کا بہانہ نہ بننے دیں۔ قابلِ واپسی چیزیں تیزی سے جاتی ہیں؛ یک طرفہ دروازوں کا خیال رکھا جاتا ہے۔
- مقامی optimization سے ہوشیار رہیں — اگر bottleneck دو دن کا review انتظار ہے تو ایک تیز IDE مدد نہیں کرتا۔

## یہ کیوں اہم ہے

زیادہ تر ٹیمیں مانتی ہیں کہ انہیں رفتار کے لیے معیار کا سودا کرنا چاہیے، اس لیے وہ محفوظ محسوس کرنے کے لیے سست ہو جاتی ہیں اور دونوں میں سے کوئی حاصل نہیں کرتیں۔ ایک Tech Lead جو یہ دکھا سکتا ہے کہ **engineering نظم و ضبط ہی وہ چیز ہے جو ایک ٹیم کو تیز بناتی ہے** پائیدار velocity کو کھولتا ہے — وہ قسم جو منہدم ہونے کے بجائے بڑھتی ہے، نہ کہ incidents اور tech debt کے ڈھیر میں۔