10.7 ایجائل

جائزہ اور محرکات

ایجائل سافٹ ویئر (اور قدر) کو بتدریج، اضافوں میں، اور ان لوگوں کے قریبی تعاون سے پہنچانے کی سوچ ہے جو اسے استعمال کریں گے۔ 2001 کے Manifesto for Agile Software Development میں مدون، اسے عمل کی بجائے اقدار اور اصولوں کے مجموعے کے طور پر سمجھنا بہتر ہے: افراد اور تعاملات، کام کرتا سافٹ ویئر، گاہک کے ساتھ تعاون، اور تبدیلی کا جواب، اس سے پہلے کے منصوبے سے بھاری، معاہدے سے بھاری، دستاویزات سے بھاری ڈیفالٹس پر ترجیح پاتے ہیں۔ Scrum، Kanban، اور Extreme Programming (XP) جیسے فریم ورکس اس سوچ کے نفاذ ہیں۔ وہ مفید آغاز کے نقطے ہیں، مگر خود سوچ نہیں۔ یہ باب باب 1.4 (کام کرنے کے طریقے، جو طریقوں کا وسیع جائزہ لیتا ہے) کی تکمیل کرتا ہے ایجائل میں خاص طور پر گہرائی میں جا کر۔

ایجائل اسی قوت سے چلتی ہے جو دریافت اور ترسیل کی pipelines (ابواب 11.1–11.2) کو زندہ رکھتی ہے: سافٹ ویئر کے تقاضے پہلے سے مکمل معلوم ہونے کی بجائے دریافت ہوتے ہیں، اور دنیا اس سے تیز بدلتی ہے جتنا لمبا منصوبہ جذب کر سکے۔ Big-bang، پہلے سب کچھ منصوبہ بنانے والی ترسیل بار بار ایسے نظام پیدا کرتی ہے جو دیر سے، بجٹ سے زیادہ، اور، بدترین، غلط ہوتے ہیں، کیونکہ سارا سیکھنا آخر میں آتا ہے، جب اس پر عمل کرنا سب سے مہنگا ہے۔ ایجائل کا مرکزی داؤ سادہ ہے: حقیقی، کام کرتا سافٹ ویئر بنانے اور حقیقی رائے لینے کے مختصر چکر قیاس آرائی کے لمبے چکروں پر غالب ہیں۔ اچھی طرح کیا جائے تو یہ خطرہ موخر کرنے کی بجائے مسلسل گھٹاتی ہے۔

بڑی ٹیموں، انٹرپرائز، اور حکومت کے لیے ایجائل طاقتور بھی ہے اور اکثر بگاڑی بھی جاتی ہے۔ انٹرپرائز اسے سینکڑوں ٹیموں میں اپناتے اور اکثر فیصلے کیسے کیے جاتے ہیں یا قدر کیسے ناپی جاتی ہے بدلے بغیر اسے رسم تک گھٹا دیتے ہیں (“ہم اب stand-ups کرتے ہیں”)۔ حکومت نے ایجائل کو دانستہ اپنایا ہے، کیونکہ بتدریج، صارف پر مرکوز ترسیل بڑے عوامی پروگراموں کا خطرہ ثابت شدہ طور پر گھٹاتی ہے: U.S. Digital Service اور اس کی Digital Services Playbook، UK کی Government Digital Service اور Service Standard، اور ایجائل خریداری کی اصلاحات سب جزوی طور پر ہائی پروفائل waterfall ناکامیوں کے جواب میں ابھریں۔ انعام حقیقی ہے۔ “صرف نام کی ایجائل” کی ناکامی کا انداز بھی۔

بنیادی اصول

Manifesto کی چار اقدار (لوگ، کام کرتا سافٹ ویئر، تعاون، اور ردعمل) کو عمل کے آرٹیفیکٹس پر ترجیح دیں۔
کام کرتا سافٹ ویئر کثرت سے چھوٹے اضافوں میں پہنچائیں؛ کام کرتا سافٹ ویئر پیش رفت کا بنیادی پیمانہ ہے۔
تبدیلی کا خیر مقدم کریں، دیر سے بھی؛ موافقت فیچر ہے، ناکامی نہیں۔
متحرک، بااختیار، خود منظم ٹیموں کے گرد بنائیں۔
صارفین اور حصہ داروں کے ساتھ مسلسل تعاون کریں۔
باقاعدہ تال پر غور کریں اور بہتر ہوں۔
انسان دوست رفتار اور تکنیکی عمدگی برقرار رکھیں: دستکاری کے بغیر رفتار ڈھ جاتی ہے۔

سفارشات

رسموں پر نہیں، اقدار اور اصولوں پر لنگر ڈالیں

ایجائل کی سب سے اہم سفارش کیوں سے شروع کرنا ہے۔ جو ٹیم روزانہ stand-up، sprint ریویو، اور retrospective کرتی ہے مگر پھر بھی مقررہ تاریخ پر مقررہ دائرے کا commit کرتی، بری خبر چھپاتی، اور منصوبہ کبھی نہیں بدلتی وہ ایجائل نہیں۔ یہ میٹنگوں والی waterfall ہے۔ حقیقی چستی کی چیک لسٹ کے طور پر بارہ اصول استعمال کریں۔ کیا آپ کام کرتا سافٹ ویئر اکثر پہنچا رہے ہیں؟ کیا آپ اگلی iteration میں تبدیلی کا خیر مقدم کر سکتے ہیں؟ کیا ٹیم طے کرتی ہے کہ کام کیسے کرنا ہے؟ کیا گاہک واقعی loop میں ہے؟ اگر رسمیں وہ نتائج نہیں دے رہیں تو رسمیں نہیں، نتائج ٹھیک کریں۔

فریم ورک کو آغاز کا نقطہ چنیں، مذہب نہیں

وہ فریم ورک چنیں جو کام کو موزوں ہو اور اسے ڈھالیں:

Scrum: وقت کی حد والے sprints، ترجیحی backlog، اور متعین کردار (product owner، scrum master، ڈویلپرز)۔ واضح product owner کے ساتھ فیچر کی ترسیل کے لیے اچھا؛ جب کام شدید طور پر مداخلت سے چلتا ہو تو کمزور۔
Kanban: واضح جاری-کام کی حدوں اور pull نظام کے ساتھ مسلسل بہاؤ۔ سپورٹ، آپریشنز، اور غیر متوقع آمد کے لیے اچھا (اور براہ راست بہاؤ اور queueing theory میں بنیاد رکھتا ہے، ابواب 11.2، 11.3 دیکھیں)۔ WIP محدود کرنا lead time مختصر کرتا ہے (Little’s Law)۔
Extreme Programming (XP): انجینئرنگ کے عمل بشمول test-driven development، pair programming، continuous integration، refactoring، چھوٹی ریلیزز۔ وہ تکنیکی ریڑھ جو کسی بھی فریم ورک کو پائیدار بناتی ہے۔
Scrumban اور امتزاج: عملی ملاپ جن پر بہت سی پختہ ٹیمیں آ ٹھہرتی ہیں۔

فریم ورکس سہارا ہیں۔ جو مدد کرے رکھیں، جو نہ کرے چھوڑیں، اور کبھی “فریم ورک ایسا کہتا ہے” کو “اصول بتاتے ہیں کیوں” پر غالب نہ آنے دیں۔

تکنیکی عمدگی پر اصرار کریں

انجینئرنگ کے نظم و ضبط کے بغیر ایجائل جلد ناقابل دیکھ بھال کوڈ کی تیز پیداوار میں گر جاتی ہے، “dark scrum”، جہاں ٹیمیں خود کو نقائص اور تکنیکی قرض کے دلدل میں sprint کراتی ہیں۔ XP کے عمل اختیاری اضافے نہیں۔ Continuous integration (باب 8.1)، خودکار ٹیسٹنگ (باب 2.4)، refactoring، trunk-based development (باب 2.6)، اور صاف ڈیزائن (باب 2.2) وہی ہیں جو ٹیم کو سافٹ ویئر سستے میں بدلتے رہنے دیتے ہیں، جو چستی کا پورا مفروضہ ہے۔ پائیدار رفتار اسی وجہ سے اہم ہے: تھکی ٹیمیں معیار یا ردعمل برقرار نہیں رکھ سکتیں۔

احتیاط سے پھیلائیں، اور سمیٹنے کو ترجیح دیں

پھیلاؤ کے فریم ورکس، جیسے SAFe (Scaled Agile Framework)، LeSS، Nexus، اور Scrum@Scale، بہت سی ٹیموں کو مشترک اہداف کی طرف ہم آہنگ کرتے ہیں۔ وہ مدد کر سکتے ہیں، مگر وہ انتباہ اٹھاتے ہیں (باب 1.4 کی گونج): بھاری پھیلاؤ کے فریم ورکس اکثر وہی command-and-control، منصوبے سے بھاری بالائی لاگت واپس لاتے ہیں جسے ہٹانے کے لیے ایجائل تھی۔ بڑا فریم ورک اپنانے سے پہلے سمیٹنے کی کوشش کریں۔ واضح ملکیت اور کم سے کم کثیر ٹیم انحصار والی آزاد، stream سے ہم آہنگ ٹیموں کے گرد منظم کریں (باب 1.2)، تاکہ آپ کو پہلے ہی کم ہم آہنگی کی مشینری چاہیے۔ جہاں ہم آہنگی واقعی ضروری ہو وہاں سب سے ہلکا ڈھانچہ جوڑیں جو کام کرے، اور اسے پیداوار سے نہیں بلکہ نتائج (OKRs، objectives and key results، باب 11.1) سے جوڑیں۔

انٹرپرائز اور حکومت میں چستی کو حقیقی بنائیں

تطبیقی ترسیل اور ادارہ جاتی پابندیاں ساتھ رہ سکتی ہیں، لیکن اس کے لیے دانستہ ڈیزائن چاہیے:

Hybrid نظم و نسق: predictive فنڈنگ/تعمیل کے خول کے اندر تطبیقی ترسیل کا مرکز (باب 10.6)، تاکہ iteration نگرانی سے لڑنے کی بجائے اسے مطمئن کرے۔
ایجائل خریداری: ایک مقررہ دائرے کے megacontract کی بجائے modular، نتائج پر مبنی معاہدے اور مختصر اضافے؛ یہی وہ جگہ ہے جہاں عوامی شعبے کی ایجائل اکثر کامیاب یا ناکام ہوتی ہے۔
چلتے چلتے تعمیل: آڈٹ، رسائی پذیری (باب 5.3)، اور سیکیورٹی (باب 4.1) کو خودکاری اور fitness functions (خودکار جانچیں جو فن تعمیر اور معیار کی خصوصیات کی مسلسل توثیق کرتی ہیں؛ ابواب 8.5، 1.6) کے ذریعے اضافے میں بنائیں، دیر سے دروازہ نہیں۔
حقیقی صارف تک رسائی: سب سے مشکل اور سب سے اہم۔ ٹیموں کو شہریوں یا گاہکوں سے حقیقی رابطہ چاہیے، جسے خریداری اور سیکیورٹی کے قواعد اکثر روکتے ہیں۔

مسلسل بہتر ہوں، اور سنجیدگی سے

Retrospective ایجائل کی بہتری کا انجن ہے، اور اگر وہ کوئی تبدیلی پیدا نہ کرے تو بیکار ہے۔ ایسے retrospectives چلائیں جو چند ٹھوس، مملوکہ کارروائیاں پیدا کریں، اور اگلے سے پہلے انہیں واقعی مکمل کریں۔ نتائج ناپیں (کیا تبدیلی نے کلیدی نتیجہ ہلایا؟ باب 11.1 دیکھیں) اور بہاؤ (کیا lead times سکڑ رہے ہیں؟ ابواب 11.2، 11.3 دیکھیں)۔ Velocity نہ ناپیں: یہ صلاحیت کا اشارہ ہے جو اس لمحے جھوٹ بن جاتا ہے جب آپ اسے پیداواریت کا ہدف بنائیں۔

سمجھوتے: فوائد اور نقصانات

فیصلہ	فوائد	نقصانات
ایجائل (تطبیقی)	تیز رائے؛ تبدیلی جذب کرتی ہے؛ جلد، مسلسل قدر	دائرہ/لاگت پہلے مقرر کرنا مشکل؛ مصروف گاہک اور نظم و ضبط چاہیے
Waterfall (predictive)	قابل پیش گوئی دائرہ؛ معاہدے/آڈٹ کے لیے دوستانہ	دیر سے رائے؛ big-bang کا خطرہ؛ غیر یقینی تقاضوں کو ناموزوں
Scrum	تال، کردار، توجہ؛ وسیع طور پر سمجھی گئی	رسم کا اوور ہیڈ؛ مداخلت سے چلنے والے کام میں جدوجہد
Kanban	بہاؤ، WIP کی حدیں، لچکدار؛ آپس کے لیے بہترین	کم ڈھانچہ؛ حدیں تھامنے کو نظم و ضبط چاہیے
بھاری پھیلاؤ (SAFe)	بہت سی ٹیموں کی ہم آہنگی؛ بڑے اداروں کو مانوس	command-and-control واپس لا سکتا ہے؛ رسم سے بھاری
سمیٹنا / ٹیم کی خودمختاری	کم ہم آہنگی کا اوور ہیڈ؛ تیز ٹیمیں	کم coupling اور مضبوط پلیٹ فارم/ملکیت چاہیے

تعریفی کھنچاؤ موافقت بمقابلہ قابل پیش گوئی ہونا ہے، اور کلاسیکی غلط فہمی یہ ہے کہ ایجائل کا مطلب “منصوبہ نہیں” ہے۔ ایسا نہیں۔ اس کا مطلب مسلسل منصوبہ بندی اور نتائج اور تال پر commit کرنا ہے جبکہ دائرے کو لچکنے دینا۔ دوسرا بار بار کا جال ایجائل کو صرف عمل (رسمیں) یا صرف انجینئرنگ (XP) سمجھنا ہے۔ اسے دونوں چاہییں۔

اپنی ٹیم کے ساتھ بحث کے سوالات

آپ کے انٹرپرائز یا سرکاری سیاق میں، کیا آپ کے معاہدے modular اور نتائج پر مبنی ہیں، یا ترسیل ایک مقررہ دائرے کے megacontract میں بند ہے؟ ایجائل خریداری وہ جگہ ہے جہاں عوامی شعبے کی چستی اکثر کامیاب یا ناکام ہوتی ہے، کیونکہ واحد مقررہ قیمت، مقررہ دائرے کا معاہدہ waterfall مجبور کرتا ہے چاہے ترسیل کی ٹیمیں اپنی میٹنگوں کو کچھ بھی کہیں۔ مختصر اضافوں والے modular، نتائج پر مبنی معاہدے دائرے کو مقررہ فنڈنگ کے اندر قیمتی مرکز تک لچکنے دیتے ہیں، جو بالکل وہ نمونہ ہے جو جدید عوامی شعبے کی کامیابیوں کے پیچھے ہے اور ماضی کی big-bang ناکامیوں کا علاج۔ شہادت لائیں: اپنے موجودہ معاہدے دیکھیں اور پوچھیں کہ فروخت کنندہ کو دکھائے گئے کام کرتے سافٹ ویئر کی ادائیگی ہوتی ہے یا برسوں پہلے دستخط شدہ مقررہ دائرے کی۔ جواب کو اس بات کو کہیں زیادہ شکل دینی چاہیے کہ آپ اگلی خریداری کیسے ترتیب دیں بنسبت اس کے کہ آپ کی ٹیمیں اندرونی طور پر کون سا فریم ورک اپناتی ہیں۔ آپ ترسیل میں تطبیقی نہیں ہو سکتے جب آپ کا معاہدہ دور، سب یا کچھ نہیں go-live کا حکم دے۔
کیا آڈٹ، رسائی پذیری، اور سیکیورٹی خودکاری کے ذریعے ہر اضافے میں بنی ہیں، یا دیر سے دروازے کے طور پر چپکائی گئی ہیں؟ چلتے چلتے تعمیل ہی تطبیقی ترسیل کو ادارہ جاتی پابندیوں کے ساتھ رہنے دیتی ہے: جانچیں اضافے میں خودکاری اور fitness functions سے بنائیں، انہیں پری-ریلیز کی بھاگ دوڑ کے لیے بچا کر نہیں۔ دیر سے تعمیل کا دروازہ big-bang کا وہ خطرہ واپس لاتا ہے جسے ہٹانے کے لیے ایجائل ہے، کیونکہ مہنگے مسائل آخر میں سامنے آتے ہیں جب انہیں ٹھیک کرنا سب سے مشکل ہے۔ شہادت لائیں: اپنے آخری اضافے کے لیے جانچیں کہ رسائی پذیری، سیکیورٹی، اور آڈٹ کی شہادت pipeline میں خودکار طور پر توثیق ہوئی یا لانچ سے پہلے دستی ریویو تک موخر۔ جواب کو ان خصوصیات کو مسلسل خودکار جانچوں میں دھکیلنا چاہیے، تاکہ نگرانی الگ مرحلے کی بجائے بنانے کے عمل سے مطمئن ہو۔ یہی ضابطے کے پروگرام کو آڈٹس کے درمیان بھی ایماندار رکھتا ہے، صرف ان سے پہلے کے ہفتوں میں نہیں۔
آپ کو کیسے پتہ چلے گا کہ آپ کی ٹیمیں تکنیکی قرض میں sprint کر رہی ہیں، اور لانچ کے دباؤ میں پائیدار رفتار کی کیا حفاظت کرتا ہے؟ انجینئرنگ کے نظم و ضبط کے بغیر ایجائل dark scrum میں گرتی ہے، جہاں ٹیمیں تیزی سے نقائص اور ناقابل دیکھ بھال کوڈ کے دلدل میں sprint کرتی ہیں، اور تھکی ٹیمیں معیار یا ردعمل برقرار نہیں رکھ سکتیں۔ XP کے عمل (continuous integration، خودکار ٹیسٹنگ، refactoring، trunk-based development) ہی ہیں جو ٹیم کو سافٹ ویئر سستے میں بدلتے رہنے دیتے ہیں، جو چستی کا پورا مفروضہ ہے، اس لیے وہ اختیاری اضافے نہیں جنہیں تاریخ قریب آنے پر چھوڑ دیا جائے۔ شہادت لائیں: ٹریک کریں کہ lead times سکڑ رہے ہیں یا بڑھ رہے ہیں، نقائص کی شرحیں چڑھ رہی ہیں یا نہیں، اور کیا ٹیم ہر sprint پورا کرنے کو خاموشی سے لمبے اوقات کام کر رہی ہے۔ جواب کو تکنیکی عمدگی اور انسان دوست رفتار کو غیر قابل مذاکرات بنانا چاہیے، کیونکہ دستکاری قربان کر کے خریدی رفتار چند iterations میں ڈھ جاتی ہے۔ بہاؤ اور نتائج ناپیں، کبھی velocity کو ہدف کے طور پر نہیں، کیونکہ جس لمحے آپ صلاحیت کے اشارے کو پیداواریت کا ہدف بناتے ہیں وہ جھوٹ بن جاتا ہے۔
بھاری پھیلاؤ کے فریم ورک تک پہنچنے سے پہلے، کیا آپ نے ان کثیر ٹیم انحصار کو کم کرنے کی کوشش کی ہے جو ہم آہنگی کی ضرورت پہلے ہی پیدا کرتے ہیں؟ بڑے ادارے کے لیے یہ سب سے اہم ہے، کیونکہ جب بہت سی ٹیموں کو ساتھ بھیجنا ہو تو ردعمل SAFe، LeSS، یا Scrum@Scale جیسا فریم ورک خریدنا ہوتا ہے، اور بھاری پھیلاؤ کی مشینری اکثر وہ command-and-control، منصوبے سے بھاری بالائی لاگت واپس سمگل کرتی ہے جسے ہٹانے کے لیے ایجائل ہے۔ متصادم غور حقیقی ہے: کچھ ہم آہنگی واقعی ضروری ہے، اور آزاد، stream سے ہم آہنگ ٹیموں میں سمیٹنا کم coupling، واضح ملکیت، اور اتنا پختہ پلیٹ فارم مانگتا ہے کہ ٹیمیں خود خدمتی کر سکیں، جو شاید ابھی آپ کے پاس نہ ہو۔ بحث میں شہادت لائیں: وہ اصل انحصار نقشہ بند کریں جو ٹیموں کو ایک دوسرے کا انتظار کرنے پر مجبور کرتے ہیں، اور پوچھیں کہ ٹیم کی حدود اور سروس کی ملکیت کی دانستہ دوبارہ ڈیزائن سے کتنے بچیں گے۔ انٹرپرائز اور سرکاری پروگراموں میں، جہاں درجنوں ٹیموں کا تنظیمی چارٹ عام ہے، ایماندار سوال یہ ہے کہ کیا آپ اس فن تعمیر اور ٹیم ڈیزائن کی تلافی کو ہم آہنگی کا ڈھانچہ جوڑ رہے ہیں جسے آپ سادہ کر سکتے تھے، تاکہ آپ کو سرے سے کم ہم آہنگی چاہیے۔
کیا آپ کی ٹیموں کا ان شہریوں یا گاہکوں سے حقیقی، بار بار کا رابطہ ہے جن کے لیے وہ بناتی ہیں، یا رائے نمائندوں سے چھن کر آتی ہے؟ گاہک کے ساتھ تعاون Manifesto کی چار اقدار میں سے ایک ہے، اور حقیقی صارف کے رابطے سے محروم iterations خاموشی سے غلط چیز بہتر بناتی ہیں، جو وہ مہنگی ترین ناکامی ہے جسے روکنا ایجائل کا کام ہے۔ کھنچاؤ یہ ہے کہ براہ راست رسائی پیمانے پر ترتیب دینا مشکل ہے اور اکثر ٹھیک انہی خریداری، رازداری، اور سیکیورٹی کے قواعد سے روکی جاتی ہے جن کا بڑے اور عوامی اداروں کو احترام کرنا ہے، اس لیے آسان راستہ نمائندہ بدلنا ہے: کاروباری تجزیہ کار، حصہ داروں کی کمیٹی، یا پچھلی سہ ماہی کا تحقیق کا ڈیک۔ شہادت لائیں: اپنے پچھلے چند اضافوں کے لیے گنیں کتنے کی توثیق حقیقی صارف کے سافٹ ویئر استعمال کرتے ہوئے ہوئی، اور کتنے کسی کی اس رائے پر ٹکے کہ صارف کیا چاہتے ہیں۔ سرکاری سروس کے لیے جوڑیں کہ کیا آپ کی usability ٹیسٹنگ سب سے زیادہ متاثر لوگوں تک پہنچی، بشمول معاون ٹیکنالوجی کے صارفین اور کم ڈیجیٹل اعتماد والے، کیونکہ وہ عوامی سروس جو صرف پراعتماد اکثریت کے لیے کام کرے اپنی جوابدہی کی ذمہ داری میں ناکام ہو چکی ہے چاہے ہر رسم شیڈول پر چلی ہو۔
کیا آپ کی ٹیمیں نتائج اور تال کے گرد فنڈ اور منظم ہیں، یا ایسے مقررہ دائرے کے گرد جو رسموں کے پیچھے خاموشی سے waterfall مجبور کرتا ہے؟ یہ حقیقی چستی اور جعلی ایجائل کا فرق ہے، اور یہ ٹیم سے اوپر طے ہوتا ہے، پیسہ کیسے جاری ہوتا اور کامیابی کیسے رپورٹ ہوتی ہے میں، اس میں نہیں کہ stand-ups ہوتے ہیں یا نہیں۔ متصادم کشش یہ ہے کہ مالیات، پورٹ فولیو، اور نگرانی کے شعبے برسوں پہلے مقررہ بجٹ کے مقابل مقررہ دائرہ منظور کرنے کو بنے ہیں، اور ان سے لچکدار دائرے والا نتیجہ فنڈ کرنے کو کہنا کنٹرول کا نقصان لگتا ہے جس کی وہ مزاحمت کریں گے۔ شہادت لائیں: سراغ لگائیں کہ موجودہ اقدام کیسے فنڈ ہوا اور وہ کس پر رپورٹ کرتا ہے، اور جانچیں کہ ٹیمیں ترسیل شدہ نتائج اور بہاؤ پر ناپی جاتی ہیں یا story points اور طویل عرصہ پہلے منظور دائرے کی پابندی پر۔ انٹرپرائز اور سرکاری ترتیبوں میں اسے براہ راست فنڈنگ اور تعمیل کے خول (باب 10.6) سے جوڑیں: اگر پیسہ دور، سب یا کچھ نہیں go-live سے commit ہے تو ٹیمیں تطبیقی نہیں ہو سکتیں چاہے وہ رسمیں کتنی ہی وفاداری سے ادا کریں، اور حل نظم و نسق کے ماڈل کا ہے، ترسیل کی ٹیموں کا نہیں۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ اقدار پر جئیں اور فریم ورک کی بحث چھوڑ دیں۔ ہر ہفتے حقیقی صارفین کو کام کرتا ٹکڑا بھیجیں، بانیوں اور ابتدائی گاہکوں کے اتنے قریب بیٹھیں کہ رائے روزانہ آئے، اور جس لمحے شہادت کہے کہ موجودہ داؤ غلط ہے سمت کی تبدیلی کا خیر مقدم کریں۔ آپ کا نایاب ترین وسیلہ انجینئرنگ کی توجہ ہے، اس لیے لانچ کے دباؤ میں بھی تکنیکی عمدگی (continuous integration، خودکار ٹیسٹ، trunk-based development) کی حفاظت کریں، کیونکہ وہی نظم و ضبط آپ کو اگلے ہفتے سستے میں pivot کرنے کے قابل رکھتا ہے۔

چھوٹا کاروبار۔ ایجائل کوچ کے بغیر اور تنگ بجٹ کے ساتھ، ایجائل کو چند عادتیں سمجھیں، تبدیلی کا پروگرام نہیں جس کا آپ عملہ رکھیں: مختصر ہفتہ وار چکر، جاری-کام کی حدوں والا نظر آنے والا board، اور ہر ہفتے ایک ٹھوس بہتری جو آپ واقعی مکمل کریں۔ Kanban پر ٹیک لگائیں، جسے کم رسم چاہیے اور جو مداخلت سے چلنے والے کام کو موزوں ہے، اور بھاری عمل کھڑا کرنے کی بجائے ان ٹولز میں سمائے عمل اپنائیں جو آپ پہلے سے خریدتے ہیں۔ کوشش کا فیصلہ اس سے کریں کہ آیا آپ گاہکوں کو مفید سافٹ ویئر زیادہ بار بھیج رہے ہیں، اس سے نہیں کہ آپ Scrum کی کتنی نقل کرتے ہیں۔

بڑا ادارہ۔ مسئلہ command-and-control واپس لائے بغیر بہت سی ٹیموں کی ہم آہنگی ہے۔ بھاری پھیلاؤ کا فریم ورک اپنانے سے پہلے سمیٹنے کو ترجیح دیں، یعنی stream سے ہم آہنگ ٹیم ڈیزائن اور مضبوط پلیٹ فارم سے کثیر ٹیم انحصار گھٹانا۔ مقررہ سالانہ دائرے اور story points کی بجائے نتائج (OKRs) اور تال کے گرد فنڈ اور نظم و نسق کریں، XP طرز کے انجینئرنگ کے عمل ٹیموں میں غیر قابل مذاکرات بنائیں، اور ترسیل کو بہاؤ کی میٹرکس اور نتائج کی پیمائش کے ساتھ پورٹ فولیو کے طور پر منظم کریں تاکہ گروہ رسم کی بجائے شہادت پر بہتر ہوں۔

حکومت۔ خریداری کے قواعد، شفافیت، اور عوامی جوابدہی ہر انتخاب کو شکل دیتے ہیں۔ ایک مقررہ دائرے کے megacontract کی بجائے مختصر اضافوں والے modular، نتائج پر مبنی معاہدے بنائیں، کیونکہ ایجائل خریداری وہ جگہ ہے جہاں عوامی شعبے کی چستی اکثر کامیاب یا ناکام ہوتی ہے۔ آڈٹ، رسائی پذیری، اور سیکیورٹی ہر اضافے میں خودکاری سے بنائیں تاکہ نگرانی بنانے کے عمل سے مطمئن ہو، پیش رفت اور عوامی قدر کی شہادت نگرانی کے اداروں کے لیے شائع کریں، اور ہر iteration شہریوں (بشمول معاون ٹیکنالوجی کے صارفین) تک حقیقی رسائی کے لیے لڑیں، کیونکہ یہی وہ پابندی ہے جو سب سے زیادہ مذاکرات میں چھوڑ دی جاتی ہے۔

مثالیں

اسٹارٹ اپ۔ پانچ افراد کا اسٹارٹ اپ رسم کی بحث چھوڑتا اور ایجائل کی اقدار پر براہ راست جیتا ہے۔ وہ ہر ہفتے حقیقی صارفین کو کام کرتا ٹکڑا بھیجتا ہے، بانیوں اور ابتدائی گاہکوں کے اتنے قریب بیٹھتا ہے کہ رائے روزانہ آتی ہے، اور اگلے ہفتے سمت کی تبدیلی کا خیر مقدم کرتا ہے جب شہادت کہے کہ موجودہ داؤ غلط ہے۔ ٹیم رفتار کے لیے تکنیکی عمدگی قربان کرنے سے انکار کرتی ہے، اس لیے لانچ کے دباؤ میں بھی continuous integration، خودکار ٹیسٹ، اور trunk-based development غیر قابل مذاکرات ہیں، اور ہر جمعے کا retrospective ایک ٹھوس تبدیلی پیدا کرتا ہے جسے ٹیم اگلے سے پہلے واقعی مکمل کرتی ہے۔ یہ velocity کو کبھی ہدف کے طور پر ٹریک نہیں کرتی، اس کی بجائے ناپتی ہے کہ بھیجے گئے کام نے activation ہلایا اور lead times سکڑ رہے ہیں۔

بڑا ادارہ۔ ٹیلی کام کی 60 ٹیموں کی تبدیلی ابتدا میں “Scrum کرتی” ہے مگر کوئی بہتری نہیں دیکھتی۔ ٹیمیں اب بھی مقررہ سالانہ دائرہ پاتی اور velocity پر رپورٹ کرتی ہیں۔ دوبارہ ترتیب اصولوں پر توجہ لاتی ہے: سہ ماہی OKRs فیچر کے مینڈیٹ کی جگہ لیتے ہیں، ٹیمیں کثیر ٹیم انحصار گھٹانے کو دوبارہ منظم ہوتی ہیں (سمیٹنا)، اور XP کے عمل (CI، TDD، trunk-based development) غیر قابل مذاکرات بنائے جاتے ہیں۔ Lead times گرتے ہیں، نقائص گھٹتے ہیں، اور، فیصلہ کن طور پر، کاروبار story points کی بجائے نتائج ناپنا شروع کرتا ہے، ایجائل ترسیل کو دریافت کی pipeline (باب 11.1) سے جوڑتے ہوئے۔

حکومت۔ ڈیجیٹل سروس ٹیم hybrid نظم و نسق کے خول کے اندر ایجائل سے شہریوں کے سامنے فوائد کی ایپلیکیشن دوبارہ بناتی ہے: دو ہفتے کے اضافے جو کام کرتا، صارف سے ٹیسٹ شدہ سافٹ ویئر دیتے ہیں؛ رسائی پذیری اور سیکیورٹی ہر اضافے میں بنی؛ اور modular خریداری واحد مقررہ قیمت کے معاہدے کی جگہ لیتی ہے۔ ہر iteration شہریوں (بشمول معاون ٹیکنالوجی کے صارفین) کے ساتھ حقیقی usability ٹیسٹنگ وہ مسائل پکڑتی ہے جو پرانا waterfall عمل بھیج دیتا۔ پروگرام جلد قابل استعمال سروس دیتا اور نگرانی کے اداروں کو قابل پیمائش عوامی قدر دکھاتا ہے۔ یہ جدید عوامی شعبے کی کامیابیوں کے پیچھے نمونہ ہے، اور ماضی کی big-bang ناکامیوں کا علاج۔

کاروباری جواز: محرکات، ROI اور TCO

ایجائل کی واپسی خطرے میں کمی اور تیز قدر کے حصول سے آتی ہے۔ کام کرتا سافٹ ویئر جلد اور اکثر پہنچا کر ٹیمیں غیر یقینی کو مسلسل شہادت میں بدلتی ہیں، غلط-چیز اور کام-نہیں-کرے گا والی ناکامیاں تب پکڑتی ہیں جب وہ سستی ہوں، دور، مہنگے go-live پر نہیں۔ جدید ترسیل کے پیچھے کی تحقیق (باب 11.2 میں DORA، DevOps Research and Assessment کے نتائج) دکھاتی ہے کہ جن عمل کو ایجائل فروغ دیتی ہے (چھوٹے batches، بار بار کی ریلیزز، تیز رائے، تکنیکی عمدگی) وہ بہتر ترسیل اور استحکام اور تنظیمی کارکردگی سے ہم ربط ہیں۔ ابتدائی اضافے بھی جلد قدر لوٹانا شروع کرتے ہیں، big-bang ریلیز کے مقابل ROI کا وقت اور کل سائز بہتر کرتے ہوئے جو آخر تک کچھ نہیں لوٹاتی۔

ملکیت کی کل لاگت پر، ایجائل نظام کی زندگی بھر تبدیلی کی لاگت گھٹاتی ہے، بشرطیکہ انجینئرنگ کا نظم و ضبط حقیقی ہو۔ اس کا غالب خطرہ جعلی ایجائل ہے: اصول یا دستکاری کے بغیر رسم، جو میٹنگوں کا اوور ہیڈ جوڑتی ہے جبکہ کوئی فائدہ نہیں دیتی، اور ایماندار waterfall سے بدتر ہو سکتی ہے۔ اس لیے کاروباری جواز مشروط ہے۔ ROI تب اونچا ہے جب آپ ایجائل کو سوچ جمع انجینئرنگ کے طور پر اپنائیں، اور تقریباً صفر (یا منفی) جب رسم کے طور پر۔ قیادت کے سامنے دلیل رکھیں ایجائل کو “تیز جانے” کی بجائے مسلسل خطرے میں کمی اور نتائج کی پیمائش کے طور پر پیش کر کے، اور اصرار کر کے کہ سرمایہ کاری میں صرف نئی میٹنگیں نہیں بلکہ تکنیکی عمل بھی شامل ہوں۔

ضد نمونے اور خامیاں

جعلی / cargo-cult ایجائل: رسمیں ادا ہوتی ہیں جبکہ فیصلے، فنڈنگ، اور سوچ waterfall رہتے ہیں۔
پیداواریت کے طور پر velocity: صلاحیت کے تخمینے کو ہدف بنانا، جو اسے بگاڑتا ہے (Goodhart’s Law)۔
Dark scrum: تکنیکی عمدگی کے بغیر ناقابل دیکھ بھال، نقائص سے بھرے کوڈ میں sprint کرنا۔
تبدیلی کے بغیر retrospectives: غور جو کوئی مکمل کارروائی پیدا نہیں کرتا۔
مقررہ دائرہ اور تاریخ اور لاگت: اسے ایجائل کہنا جبکہ معیار خاموشی سے دباؤ جذب کرتا ہے۔
غیر حاضر گاہک: کوئی حقیقی صارف کی رائے نہیں، اس لیے iterations غلط چیز بہتر بناتی ہیں۔
فریم ورک کی پرستش: “SAFe/Scrum ایسا کہتا ہے” کا اصولوں اور ٹیم کے فیصلے پر غالب آنا۔
سمیٹنے سے پہلے پھیلانا: انحصار گھٹانے کی بجائے بھاری ہم آہنگی کے فریم ورک جوڑنا۔

پختگی کا ماڈل

سطح 1، آغاز۔ Waterfall یا ایڈہاک ترسیل؛ big-bang ریلیزز؛ کام ردعملی اور منصوبے سے بھاری ہے، بغیر بتدریج رائے کے اور بغیر اس مشترک احساس کے کہ ایجائل کیوں مدد کر سکتی ہے۔
سطح 2، ترقی۔ چند ٹیمیں ایجائل رسمیں (stand-ups، sprints، retrospectives) اپناتی ہیں، لیکن عمل ادارے میں غیر مستقل ہے: سوچ اور انجینئرنگ کا نظم و ضبط رسموں سے پیچھے رہتے ہیں، velocity کو پیداوار سمجھا جاتا ہے، اور دائرہ اب بھی پہلے سے مقرر ہے۔
سطح 3، معیار بندی۔ اقدار اور اصول ادارے بھر حقیقی طور پر کام کی رہنمائی کرتے ہیں، دستاویزی اور ہر ٹیم سے متوقع: XP طرز کی تکنیکی عمدگی (CI، خودکار ٹیسٹنگ، refactoring، trunk-based development) معیاری عمل ہے، ٹیمیں خود منظم ہوتی ہیں، گاہک ہر iteration میں مصروف ہیں، اور retrospectives ٹھوس، مکمل تبدیلی پیدا کرتے ہیں۔
سطح 4، انتظام۔ ترسیل بنیادی خطوط کے مقابل ناپی اور کنٹرول کی جاتی ہے: ٹیمیں lead time، ڈیپلائمنٹ کی تعدد، تبدیلی کی ناکامی کی شرح، اور نقص کے فرار کی شرح (DORA طرز کی بہاؤ اور استحکام کی میٹرکس) ٹریک کرتی ہیں، کلیدی نتائج سے بندھی نتائج کی پیمائش کے ساتھ، اور ہر ایک کا معلوم بنیادی خط سے موازنہ کرتی ہیں۔ Retrospective کی کارروائیاں مکمل ہونے تک ٹریک ہوتی ہیں، اوور ٹائم اور تھکن جیسے پائیدار-رفتار کے اشارے مانیٹر ہوتے ہیں، اور velocity کبھی پیداواریت کا ہدف نہیں۔ Go اور no-go کے فیصلے رائے کی بجائے اس شہادت پر ٹکتے ہیں۔
سطح 5، ہم آہنگی۔ تطبیقی ترسیل ادارے بھر کاروبار اور خطرے کی منصوبہ بندی سے مربوط ہے: نتائج (OKRs) فنڈنگ اور تال چلاتے ہیں، کم-انحصار ٹیم ڈیزائن (سمیٹنا) ہم آہنگی کا اوور ہیڈ کم کرتا ہے، اور hybrid نظم و نسق ترسیل سست کیے بغیر نگرانی کو مطمئن کرتا ہے۔ مسلسل بہتری رسمی کی بجائے ثقافتی ہے، اور ادارہ شہادت اور خطرے کی تصویر بدلنے پر معمول سے اپنا پورٹ فولیو دوبارہ دائرہ بند، دوبارہ ٹیم بند، اور دوبارہ متوازن کرتا ہے۔

بحث کے لیے خیالات

بارہ ایجائل اصولوں کے مقابل اپنی ٹیم کو سکور کریں: آپ رسم میں ایجائل مگر جوہر میں نہیں کہاں ہیں؟
کیا آپ کی ٹیم میں velocity پیش گوئی کے طور پر استعمال ہوتی ہے یا ہدف کے طور پر، اور اس نے رویے کو کیا کیا؟
XP کے کون سے تکنیکی عمل غائب ہیں، اور ان کی غیر موجودگی نقائص یا سست تبدیلی کے طور پر کیسے ظاہر ہو رہی ہے؟
پھیلاؤ کا فریم ورک اپنانے سے پہلے، کیا آپ اس کی بجائے کثیر ٹیم انحصار گھٹا سکتے ہیں؟
آپ کے سیاق میں ہر iteration حقیقی صارف تک رسائی کو خاص طور پر کیا روکتا ہے، اور آپ اسے کیسے ہٹا سکتے ہیں؟
retrospective نے آخری ٹھوس تبدیلی کیا پیدا کی جو واقعی ہوئی؟

اہم نکات

ایجائل اقدار اور اصولوں کی سوچ ہے، رسموں کا مجموعہ نہیں؛ فریم ورکس آغاز کے نقطے ہیں، ہدف نہیں۔
کام کرتا سافٹ ویئر کثرت سے پہنچائیں، تبدیلی کا خیر مقدم کریں، اور خود منظم ٹیموں کو بااختیار بنائیں۔
تکنیکی عمدگی (XP کے عمل) غیر قابل مذاکرات ہے۔ اس کے بغیر چستی تیز سڑاند بن جاتی ہے۔
احتیاط سے پھیلائیں؛ سمیٹنے کو ترجیح دیں۔ ہم آہنگی کے فریم ورک جوڑنے سے پہلے انحصار گھٹائیں۔
انٹرپرائز/حکومت میں تطبیقی ترسیل کو hybrid نظم و نسق اور ایجائل خریداری سے ملائیں، اور حقیقی صارف تک رسائی کے لیے لڑیں۔
ROI مسلسل خطرے میں کمی اور جلد قدر ہے، لیکن صرف جب ایجائل حقیقی ہو، رسم نہ ہو۔ ابواب 1.4، 11.1، 11.2، 10.6، اور 11.3 دیکھیں۔

حوالہ جات اور مزید مطالعہ

Kent Beck et al., Manifesto for Agile Software Development and its twelve principles (agilemanifesto.org, 2001).
Ken Schwaber and Jeff Sutherland, The Scrum Guide.
Kent Beck, Extreme Programming Explained: Embrace Change.
David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business.
Mike Cohn, User Stories Applied and Succeeding with Agile.
Jeff Patton, User Story Mapping.
Stephen Denning, The Age of Agile.
Matthew Skelton and Manuel Pais, Team Topologies (team design and descaling).
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (evidence for agile/DevOps practices).
U.S. Digital Service, Digital Services Playbook; UK Government, Government Service Standard.