2.6 سائیکل ٹائم اور اس کے اجزا

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

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

یہ فرق اس لیے اہم ہے کہ “لیڈ ٹائم بہت لمبا ہے” اکیلا قابلِ عمل نہیں۔ جس ٹیم کا لیڈ ٹائم کوڈنگ کے وقت پر غالب ہو اسے اس ٹیم سے مختلف مداخلت چاہیے جس کا لیڈ ٹائم تین دن کی جائزے کی قطار پر غالب ہو، جسے پھر اس ٹیم سے مختلف مداخلت چاہیے جو اپنا زیادہ تر وقت سست، غیر مستحکم ٹیسٹ سوٹ میں کھو رہی ہو۔ سائیکل ٹائم کی تقسیم کے بغیر ٹیمیں رکاوٹ کا اندازہ لگانے کا رجحان رکھتی ہیں، اور اندازہ اتنی بار غلط ہوتا ہے کہ غلط مرحلہ ٹھیک کرنا حقیقی کوشش ضائع کرتا ہے جبکہ اصل پابندی چھوئی نہیں جاتی۔

بڑی ٹیموں کے لیے سائیکل ٹائم کی تقسیم وہ چیز ہے جو ادارے بھر کے لیڈ ٹائم کے بگاڑ کو معمے سے ایک مخصوص، قابلِ حل مسئلے میں بدل دیتی ہے۔ جب درجنوں ٹیمیں مشترکہ بنیادی ڈھانچہ بانٹتی ہیں تو مشترکہ جائزے کی رکاوٹ یا مشترکہ سست CI پائپ لائن ہر ٹیم کے لیڈ ٹائم کو یکساں طور پر نیچے کھینچ رہی ہو سکتی ہے، اور صرف ٹیموں کے آر پار سائیکل ٹائم کا موازنہ اس مشترکہ بنیادی وجہ کو ظاہر کرتا ہے، بجائے اس کے کہ ہر ٹیم آزادانہ طور پر اپنی مقامی وضاحت کا اندازہ لگائے۔

بنیادی اصول

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

سفارشات

ہر مرحلے کی حد کو صریح طور پر انسٹرومینٹ کریں

تبدیلی کے سفر کو واضح، انسٹرومینٹ کیے جا سکنے والی حدوں کے ساتھ نامزد مراحل میں توڑیں: کوڈنگ (پہلے کمٹ سے پل ریکویسٹ کھلنے تک)، اٹھانا (پل ریکویسٹ کھلنے سے پہلے جائزے تک)، جائزہ (پہلے جائزے سے منظوری تک)، اور ڈیپلائے (منظوری سے پروڈکشن تک)۔ ہر منتقلی کے ٹائم اسٹیمپ ورژن کنٹرول اور CI/CD واقعات سے خودکار طور پر جمع کریں، خود رپورٹ شدہ مرحلے کی ٹریکنگ سے نہیں، موضوع 1.5 کے انسٹرومینٹیشن بمقابلہ خود رپورٹ کا وہی اصول لاگو کرتے ہوئے۔

ہر مرحلے کے اندر انتظار کے وقت کو فعال وقت سے الگ کریں

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

ٹیم بہ ٹیم تشخیص سے پہلے مشترکہ رکاوٹ تلاش کریں

جب متعدد ٹیمیں ایک ہی مرحلے کو اپنی غالب تاخیر کے طور پر دکھائیں، سست مشترکہ CI پائپ لائن، ضرورت سے زیادہ بوجھ والا مشترکہ جائزہ پول، کبھی کبھار مشترکہ ریلیز ٹرین، تو وہ مشترکہ وجہ غیر متعلق مقامی مسائل کی سیریز کے بجائے پلیٹ فارم کی سطح کی سرمایہ کاری کا موقع ہے۔ یہ فرض کرنے سے پہلے کہ ہر ٹیم کی رکاوٹ اس ٹیم کے لیے منفرد ہے، خاص طور پر اس نمونے کی تلاش کے لیے ٹیموں کے سائیکل ٹائم کا ڈیٹا اکٹھا کریں۔

حقیقت پسندانہ، مرحلے کے مخصوص بہتری کے اہداف طے کرنے کے لیے سائیکل ٹائم استعمال کریں

اکیلے “لیڈ ٹائم 20 فیصد کم کریں” کے ہدف کے بجائے، جو ٹیم کو یہ رہنمائی نہیں دیتا کہ کہاں توجہ دینی ہے، مرحلے کا مخصوص ہدف طے کرنے کے لیے سائیکل ٹائم کی تقسیم استعمال کریں: “وسطانیہ جائزے کے انتظار کا وقت دو دن سے چار گھنٹے کریں۔” مخصوص، مرحلے کو ہدف بنانے والا مقصد ٹیم کے لیے عمل کرنا بھی آسان ہے اور یہ تصدیق کرنا بھی آسان ہے کہ وہ کہیں اور غیر متعلق تبدیلی کے بجائے حقیقی عمل کی تبدیلی سے حاصل ہوا۔

مرحلے کی حد کی گیمنگ پر نظر رکھیں

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

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

طریقہ	فوائد	نقصانات
موٹا سائیکل ٹائم (دو یا تین مراحل)	انسٹرومینٹ اور وضاحت میں سادہ	ہو سکتا ہے اصل رکاوٹ کی اتنی درست نشاندہی نہ کرے کہ عمل کیا جا سکے
باریک سائیکل ٹائم (بہت سے مراحل، انتظار بمقابلہ فعال تقسیم)	درست تشخیص، قابلِ عمل مرحلے کے مخصوص اہداف	زیادہ انسٹرومینٹیشن کی کوشش؛ برقرار رکھنے اور سمجھانے کے لیے زیادہ اعداد
ٹیم بہ ٹیم سائیکل ٹائم کا جائزہ	ہر ٹیم کے اصل ورک فلو کے مطابق	یکساں مقامی اعداد کے پیچھے چھپی مشترکہ، ٹیموں کے آر پار رکاوٹ چھوٹ سکتی ہے
ٹیموں کے آر پار مجموعی سائیکل ٹائم کا جائزہ	مشترکہ پلیٹ فارم کی سطح کی رکاوٹیں ظاہر کرتا ہے	بامعنی ہونے کے لیے ٹیموں میں معیاری مرحلے کی تعریفیں درکار

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

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

اگر آج لیڈ ٹائم بگڑے تو کیا ہم ایک گھنٹے کے اندر بتا سکتے ہیں کہ کون سا مخصوص مرحلہ ذمہ دار تھا، اندازے کی بجائے ڈیٹا کی مدد سے؟ یہ اس بات کا بنیادی امتحان ہے کہ آیا آپ کی سائیکل ٹائم کی انسٹرومینٹیشن اپنا تشخیصی مقصد پورا کر رہی ہے۔ اگر ایماندار جواب نہیں ہے، تو اگلے بگاڑ سے پہلے اس خلا کو بند کرنا قابلِ قدر ہے۔
ہماری غالب رکاوٹ کے مرحلے کے اندر کتنی تاخیر انتظار کا وقت ہے اور کتنی فعال وقت؟ زیادہ تر ٹیمیں جانچنے سے پہلے فرض کر لیتی ہیں کہ فعال کوشش پابندی ہے، جبکہ قطار بندی عموماً بڑی لاگت ہوتی ہے۔ اپنے سب سے سست مرحلے کی اصل تقسیم نکالیں اور دیکھیں کہ آیا فرض درست ہے۔
کیا متعدد ٹیمیں ایک ہی غالب رکاوٹ کا مرحلہ بانٹتی ہیں، جو ٹیم کی سطح کے بجائے پلیٹ فارم کی سطح کے حل کی طرف اشارہ کرتا ہے؟ اپنا سائیکل ٹائم کا ڈیٹا ٹیموں میں اکٹھا کریں اور یہ فرض کرنے سے پہلے کہ ہر ٹیم کی سستی مقامی طور پر ہے خاص طور پر اس نمونے کی تلاش کریں۔
کیا ہم نے مرحلے کے مخصوص بہتری کے اہداف طے کیے ہیں، یا صرف ایک مجموعی لیڈ ٹائم کا ہدف جس میں کہاں توجہ دینی ہے اس کی کوئی رہنمائی نہیں؟ مبہم ہدف ٹیم کو یہ اندازہ لگانے پر چھوڑتا ہے کہ کوشش کہاں لگائی جائے؛ مرحلے کا مخصوص ہدف نہیں۔ اپنے موجودہ اہداف کو اس فرق سے جانچیں۔
کیا ہماری انسٹرومینٹیشن میں کوئی سائیکل ٹائم کے مرحلے کی حد وقت کے ساتھ اپنی دستاویزی تعریف سے بھٹکی ہے؟ مرحلے کی حدیں بہاؤ کے وقت کی طرح تعریفی بھٹکاؤ کی زد میں ہیں (موضوع 2.4)۔ حالیہ مرحلے کی منتقلی کے واقعات کے نمونے کا لکھی ہوئی تعریف کے مقابلے میں آڈٹ کریں۔
جائزے پر مرکوز ثقافت اور اعتماد پر مرکوز ثقافت ہمارے سائیکل ٹائم کے ڈیٹا میں مختلف طور پر کیسے ظاہر ہوتی ہے؟ بہت تفصیلی، کئی دور کے جائزے والی ٹیم اس ٹیم سے زیادہ جائزے کے مرحلے کا وقت دکھائے گی جو اکیلی منظوری سے مرج پر بھروسا کرتی ہے؛ بحث کریں کہ آیا آپ کا موجودہ توازن دانستہ انتخاب کی عکاسی کرتا ہے یا غیر جانچا ہوا ڈیفالٹ۔

شعبے کا زاویہ

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

چھوٹا کاروبار۔ ورژن کنٹرول پلیٹ فارم کے بنیادی تجزیات عموماً حسبِ ضرورت انسٹرومینٹیشن کے بغیر کافی مرحلے کی سطح کا وقت (پہلے جائزے تک کا وقت، مرج تک کا وقت) فراہم کرتے ہیں۔ پہلے جائزے کے مرحلے پر توجہ دیں، کیونکہ یہ سب سے عام ابتدائی رکاوٹ ہے اور جائزہ لینے والوں کی باری جیسی چھوٹی عمل کی تبدیلی سے ٹھیک کرنا سب سے آسان ہے۔

بڑا ادارہ۔ درجنوں ٹیموں میں مشترکہ رکاوٹیں عام ہیں اور تلاش کرنے میں اعلیٰ اثر والی ہیں: اکیلی ضرورت سے زیادہ بوجھ والی مشترکہ CI قطار یا لازمی مرکزی جائزے کا قدم پورے ادارے میں لیڈ ٹائم پر خاموشی سے ٹیکس لگا رہا ہو سکتا ہے۔ ہر ٹیم کو آزادانہ تشخیص پر چھوڑنے کے بجائے ان مشترکہ پابندیوں کو سامنے لانے کے لیے خاص طور پر ٹیموں کے آر پار سائیکل ٹائم کی تجمیع میں سرمایہ کاری کریں۔

حکومت۔ سائیکل ٹائم کا ڈیٹا شکی اسٹیک ہولڈرز کے سامنے عمل کی جدید کاری کا جواز دینے کے لیے مضبوط، ٹھوس ٹول ہے، کیونکہ “اکیلی رکاوٹ والے منظوری کے کردار کی وجہ سے جائزے کے انتظار کا وقت اوسطاً چار دن ہے” سرمایہ کاری کے لیے مبہم “ہمارا عمل سست ہے” کے دعوے سے کہیں زیادہ قائل کرنے والا، مخصوص مقدمہ ہے۔

مثالیں

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

حکومت۔ ایک ریاستی حکومت کی ڈیجیٹل خدمات کی ٹیم پر لیڈ ٹائم کم کرنے کا دباؤ تھا، اور اس نے ابتدا میں انجینئروں سے تیز کام کرنے کو کہہ کر جواب دیا، فطری لیکن آخرکار غیر مفید جبلت۔ سائیکل ٹائم کی تقسیم نے دکھایا کہ فعال کوڈنگ کا وقت سال بہ سال مشکل سے بدلا تھا؛ تقریباً تمام بگاڑ لازمی فن تعمیر کے جائزے کے مرحلے کی بڑھتی ہوئی قطار سے آیا جو اٹھارہ ماہ پہلے تعمیل کے اقدام کے طور پر متعارف ہوا تھا۔ ٹیم نے اس جائزے کو کم خطرے والی تبدیلیوں کے لیے ہلکے، خطرے کے درجوں والے عمل میں دوبارہ ڈیزائن کیا، جائزے کے انتظار کا وقت نمایاں طور پر کم کرتے ہوئے جبکہ حقیقی طور پر زیادہ خطرے والی تبدیلیوں کے لیے مکمل جائزے کی سختی برقرار رکھی۔

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

سائیکل ٹائم کی تقسیم کا منافع ہدف والی، مؤثر سرمایہ کاری ہے: جو ادارہ بالکل جانتا ہے کہ کون سا مرحلہ رکاوٹ ہے وہ اس مخصوص مرحلے کو ٹھیک کر سکتا ہے، بجائے اس امید میں پورے عمل میں کوشش پتلی پھیلانے کے کہ کچھ مدد کرے۔ اوپر کی سیکیورٹی کے جائزے کی مثال عام ہے: درست ہدف والا حل، ایک مخصوص رکاوٹ والے وسیلے کو بڑھانا، نے ادارے بھر کا مسئلہ وسیع، غیر مرکوز “ڈیلیوری تیز کریں” کی پہل کاری سے کہیں سستے میں حل کیا۔

ملکیت کی کل لاگت مرحلے کے ٹائم اسٹیمپ قابلِ اعتماد طریقے سے جمع کرنے کی انسٹرومینٹیشن کی کوشش، اور بھٹکاؤ کے لیے مرحلے کی حدوں کا دورانیہ وار آڈٹ کرنے کا جاری نظم ہے۔ وہ لاگت قابلِ قدر ہے کیونکہ متبادل، رکاوٹوں کا اندازہ لگانا اور غلط مرحلہ ٹھیک کرنا، وقت کے ساتھ انسٹرومینٹیشن کی اپنی لاگت سے کہیں زیادہ انجینئرنگ کی کوشش ضائع کرتا ہے۔

منفی نمونے اور خطرات

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

پختگی کا نمونہ

درجہ 1، آغاز (Initiate): سائیکل ٹائم کی بالکل تقسیم نہیں ہوتی؛ لیڈ ٹائم بگڑنے پر ٹیمیں رکاوٹوں کا اندازہ لگاتی ہیں۔
درجہ 2، ترقی (Develop): کچھ ٹیمیں غیر رسمی طور پر موٹے مرحلے کا وقت ٹریک کرتی ہیں، لیکن کوئی یکساں انسٹرومینٹیشن یا ٹیموں کے آر پار موازنہ نہیں۔
درجہ 3، معیار بندی (Standardize): مرحلے کی حدیں پورے ادارے میں یکساں انسٹرومینٹ کی جاتی ہیں، غالب رکاوٹ کے مراحل میں انتظار کا وقت فعال وقت سے الگ کیا جاتا ہے۔
درجہ 4، انتظام (Manage): ٹیموں کے آر پار سائیکل ٹائم کی تجمیع مشترکہ رکاوٹوں کو فعال طور پر سامنے لاتی ہے؛ مرحلے کے مخصوص بہتری کے اہداف مبہم مجموعی لیڈ ٹائم کے اہداف کی جگہ لیتے ہیں۔
درجہ 5، ہم آہنگی (Orchestrate): سائیکل ٹائم کا ڈیٹا براہِ راست پلیٹ فارم سرمایہ کاری کی ترجیح کو چلاتا ہے، اور ادارہ مخصوص، ہدف والے حل، جائزے کا بڑھا ہوا پول، تیز مشترکہ پائپ لائن، کی نشاندہی کر سکتا ہے جنہوں نے بہت سی ٹیموں میں ایک ساتھ لیڈ ٹائم کو ناپنے کے قابل طور پر بہتر کیا۔

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

ہمارا موجودہ غالب رکاوٹ کا مرحلہ کون سا ہے، اور ہمیں اس جواب پر کتنا اعتماد ہے؟
اس رکاوٹ والے مرحلے کا کتنا وقت انتظار کا وقت ہے اور کتنا فعال وقت؟
کیا ہماری کوئی ٹیمیں ایک ہی رکاوٹ بانٹتی ہیں، جو پلیٹ فارم کی سطح کے حل کی طرف اشارہ کرتی ہو؟
ہم نے آخری بار کب مجموعی کے بجائے مرحلے کا مخصوص ڈیلیوری بہتری کا ہدف طے کیا؟
کیا ہمارے ٹولنگ میں کبھی کسی مرحلے کی حد کی تعریف بغیر دستاویز کے بدلی ہے؟

اہم نکات

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

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

The Principles of Product Development Flow, by Donald G. Reinertsen (سائیکل ٹائم کے تجزیے کی بنیاد قطار کا نظریہ اور بیچ کے سائز کا استدلال)۔
Actionable Agile Metrics for Predictability, by Daniel S. Vacanti (سافٹ ویئر ڈیلیوری کے لیے سائیکل ٹائم اور بہاؤ پر مبنی پیمائش)۔
Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, and Gene Kim (لیڈ ٹائم اور ڈیلیوری کی کارکردگی سے اس کا تعلق)۔
The Goal, by Eliyahu M. Goldratt (پابندیوں کا نظریہ، اور ہر جگہ بہتر کرنے کے بجائے اصل رکاوٹ تلاش کر کے ٹھیک کرنے کا اصول)۔