سڀني کي سلام! اتي نظريو جو ھڪڙو وڏو مقدار آھي جيڪو توھان کي ڄاڻڻ جي ضرورت آھي سافٽ ويئر ڊولپمينٽ ۾ شروع ڪرڻ لاء. ڪجهه ماهر (مثال طور، پس منظر ڊولپر جيڪي جاوا ۽ ٻيون ٻوليون استعمال ڪن ٿا) ان کان وڌيڪ ڄاڻن ٿا، جڏهن ته ٻيا (مثال طور، فرنٽ اينڊ ڊولپر جيڪي JavaScript استعمال ڪن ٿا ۽ اصلي رد عمل) شايد ٿورڙي ڄاڻن. اهو چيو ته، ٻنهي گروهن کي نه رڳو فني، پر "تنظيمي" علم جو هڪ وڏو جسم هجڻ گهرجي. هي "تنظيمي" علم فرنٽ اينڊ ۽ پس منظر ڊولپرز لاءِ اوورليپ جو هڪ علائقو آهي. اڄ مان هن غير ٽيڪنيڪل، تنظيمي علم جي هڪ پهلو بابت ڳالهائڻ چاهيان ٿو. اڄ اسان ڪوشش جي اندازي بابت ڳالهائينداسين . ڇاڪاڻ ته مون کي صرف Agile طريقو استعمال ڪرڻ جو تجربو آهي (جنهن کي سڀ کان وڌيڪ مشهور سمجهيو ويندو آهي)، خاص طور تي اسڪرم فريم ورڪ، مان اسڪرم جي حوالي سان ڪوشش جي تخميني تي غور ڪندس . شروع ۾، مون کي ضرور چوڻ گهرجي ته ڪوشش جو اندازو لڳائڻ ڏکيو آهي. مون لاء، اهو هڪ ڊولپر جي حيثيت سان منهنجي نوڪري جي سڀ کان وڌيڪ مشڪل / ناپسنديده حصن مان هڪ آهي. غور ڪرڻ لاءِ ڪيترائي مختلف عنصر آھن جيڪي توھان جي ڪم لاءِ گھربل ڪوشش جي اندازي کي متاثر ڪري سگھن ٿا. اضافي طور تي، مستقبل جي ترقياتي منصوبا توهان جي اندازن تي ٻڌل هوندا.
ڇا جيڪڏهن توهان هڪ خراب تخمينو مهيا ڪندا آهيو؟
جيڪڏهن هڪ ڊولپر هڪ ڪم لاءِ وڌيڪ ڪلاڪ جو اندازو لڳائي ٿو آخرڪار ڪم تي خرچ ڪيو ويو آهي، انهن جي ماهريت کي شڪ ۾ وجهي سگهجي ٿو ڇاڪاڻ ته اندازو ايترو غلط هو. ٻين لفظن ۾، اهو هڪ جهنگلي اندازو هو. ساڳي ئي وقت، جيڪڏهن هڪ ڊولپر اڳڪٿي ڪيل وقت ۾ ڪم نه ٿو ڪري، ته هوءَ پراڊڪٽ يا نئين خصوصيت کي ڇڏڻ لاءِ گراهڪ جي منصوبن کي خطري ۾ وجهي ٿي. اهو ڪاروبار آهي، ۽ ڪاروبار پئسا آهي. ٿورا گراهڪ اهڙي پرچي سان راضي ٿي ويندا. حقيقت ۾، اهو ئي سبب آهي جو مان اندازو لڳائڻ پسند نٿو ڪريان - ڇاڪاڻ ته ڪڏهن ڪڏهن اهو انتهائي مشڪل هوندو آهي ته ڪنهن ڪم کي مڪمل ڪرڻ لاءِ گهربل وقت جو صحيح اندازو لڳايو وڃي.
وقت جو اندازو ڪيئن ڪجي
ضابطي جي طور تي، اندازو لڳايو ويو آهي ڪلاڪ يا ڪهاڻي پوائنٽن ۾. منهنجي ذاتي ترجيح ڪهاڻي پوائنٽ استعمال ڪندي اندازي جي عمل کي ڪرڻ آهي . ڪنڪريٽ فزيڪل شين جي باري ۾ غلط ٿيڻ ڏکيو آهي، پر ڪهاڻي جا نقطا ٿورڙا وڌيڪ تجريدي آهن. سافٽ ويئر ڊولپمينٽ ٽيمون عام طور تي تخمينو مهيا ڪن ٿيون جيئن وقت جي مقدار: ڪلاڪ، ڏينهن، هفتا، مهينا. اهي وقت جو تخمينو بنيادي طور تي ذاتي تجربو، اندازو لڳائڻ، ۽/يا وجدان تي ٻڌل آهن. انهي حالت ۾، ڊولپرز صرف ڪم تي نظر اچن ٿا ۽ انهن جي مفروضي جو اظهار ڪيو ته اهو ڪيترو وقت وٺندو. نتيجي طور، اهي تخمينو تمام گهٽ ئي صحيح آهن، ڇاڪاڻ ته اهڙا ڪيترائي عنصر آهن جيڪي ڪم جي مدت کي متاثر ڪري سگهن ٿيون. اهو ئي سبب آهي ته ڪيتريون ئي ٽيمون جيڪي استعمال ڪن ٿيون Agile طريقي سان پڻ ڪهاڻي پوائنٽون استعمال ڪن ٿيون. اچو ته اندر وڃو!
ڪهاڻي جا نقطا ڇا آهن؟
هڪ ڪهاڻي نقطو ماپ جو هڪ يونٽ آهي جيڪو مڪمل طور تي ڪارڪردگي جي هڪ خاص حصي کي لاڳو ڪرڻ لاء گهربل مجموعي ڪوشش جي اندازي کي بيان ڪرڻ لاء. اهو آهي، اسان نسبتا پيچيدگي بابت ڳالهائي رهيا آهيون. ٽيمون ڪم جي پيچيدگي، ڪم جي مقدار، ۽ خطري يا غير يقيني صورتحال جي بنياد تي ڪهاڻي پوائنٽن ۾ تخمينو لڳايو. اهي قدر عام طور تي مقرر ڪيا ويا آهن وڌيڪ موثر طريقي سان ڪم کي ننڍڙن ٽڪرن ۾ ورهائڻ، ان ڪري ابهام کي ختم ڪرڻ. وقت گذرڻ سان گڏ، هي ٽيمن کي اهو سمجهڻ ۾ مدد ڪري ٿو ته اهي ڏنل وقت ۾ ڇا حاصل ڪري سگهن ٿا ۽ انهن کي وڌيڪ صحيح طريقي سان ڪم جي ايندڙ حصن جي منصوبابندي ڪرڻ ۾ مدد ڪري ٿي. اهو شايد توهان لاءِ مڪمل طور تي متضاد لڳي سگهي ٿو، پر هي خلاصو واقعي ڪارآمد آهي: اهو ٽيم کي ڪم جي پيچيدگي بابت سخت فيصلا ڪرڻ لاءِ زور ڏئي ٿو. اچو ته ڪجهه سببن تي نظر رکون ته ڪهاڻي پوائنٽس کي استعمال ڪرڻ جي منصوبابندي ڪرڻ وقت:
توهان غلط وقت جي تخميني کان پاسو ڪري سگهو ٿا.
وقت جي يونٽن ۾ ڪيل تخميني جي برعڪس، ڪهاڻي پوائنٽون توهان کي اوور هيڊ خرچن جو حساب ڏيڻ ڏين ٿا: ٽيم جي ميمبرن ۽ گراهڪ جي وچ ۾ رابطي، ٽيم جي مختلف بحثن ۽ منصوبابندي جي سرگرمين، گڏوگڏ غير متوقع حالتون.
هر ٽيم مختلف اسڪيل استعمال ڪندي پنهنجي ڪم جو اندازو لڳائيندي، جنهن جو مطلب آهي ته انهن جي گنجائش (پوائنٽس ۾ ماپيل) مختلف هوندي.
هر ڪهاڻي نقطي کي تفويض ڪرڻ لاء هڪ پيماني جي وضاحت ڪندي، توهان تمام گهڻو تڪرار کان سواء جلدي پوائنٽ مختص ڪري سگهو ٿا.
ڪهاڻي پوائنٽس کي ڪيئن استعمال نه ڪجي
بدقسمتي سان، ڪهاڻي پوائنٽون اڪثر غلط استعمال ڪيا ويا آهن. ڪهاڻي پوائنٽون گمراهه ٿي سگهن ٿيون جڏهن اهي استعمال ڪيا وڃن ماڻهن جو جائزو وٺڻ لاءِ، تفصيلي آخري حدن ۽ وسيلن جي وضاحت ڪرڻ، ۽ جڏهن انهن کي ڪارڪردگي جي ماپ لاءِ غلط قرار ڏنو وڃي. ان جي بدران، ٽيمن کي انهن کي استعمال ڪرڻ گهرجي هر ڪم جي گنجائش / پيچيدگي کي سمجهڻ ۽ ترجيحن کي مقرر ڪرڻ لاء. ٿي سگهي ٿو ته اهي حصا جيڪي وڌيڪ مشڪل سمجهيا وڃن ٿا انهن کي پهرين حل ڪيو وڃي، تنهنڪري اهي اسپرنٽ جي آخر کان اڳ ڪري سگهجن ٿا ، ممڪن طور تي آسان ڪمن کي بعد ۾ منتقل ڪرڻ. اچو ته مان توهان کي ياد ڏيان ته اسپرنٽ ڇا آهي اسڪرم جي طريقي جي حوالي سان:
هڪ اسپرنٽ هڪ ورهايل مقرر وقت جو وقفو آهي جنهن دوران ڪارڪردگي جو ڪجهه منصوبابندي ڪيل ٽڪرا لاڳو ڪيو ويندو آهي.
هن وقت جي مدت جو اندازو لڳايو ويندو آهي جڏهن ترقي شروع ٿئي ٿي ۽ ٽيم ۽ گراهڪ جي وچ ۾ اتفاق ڪيو وڃي. اهو عرصو ٻه هفتا يا هڪ مهينو، يا ڪنهن ٻئي دور جو ٿي سگهي ٿو. ضابطي جي طور تي، هر اسپرنٽ جي شروعات ۾ ڪوشش جو اندازو لڳايو وڃي ٿو ته ڪم جي منصوبابندي ڪرڻ لاءِ جيڪو اسپرنٽ جي آخر تائين مڪمل ٿي سگهي ٿو، جڏهن مڪمل ٿيل ڪم گراهڪ کي پهچايو ويندو آهي.
جڏهن اسپرنٽ دوران مڪمل ٿيل ڪم گراهڪ کي پيش ڪيو ويو آهي، اسان ان کي ڊيمو سڏين ٿا.
ڊيمو توهان جي مدد ڪري ٿو توهان جي پيداوار کي ترقي ڪرڻ ۾ توهان جي ترقي کي ڏسڻ، ڪسٽمر کان موٽ حاصل ڪرڻ، ۽ گراهڪ جي نظر جي مطابق منصوبي جي رفتار کي ترتيب ڏيڻ. پر اسان ٿورڙو ڦٽو ڪريون ٿا. اچو ته تخميني ڏانهن واپس وڃو. اهو تمام گهڻو تابع هوندو ته صرف هڪ ڊولپر سڀني ڪمن لاءِ تخمينو مهيا ڪري. تنهن ڪري اهو عمل عام طور تي هڪ ٽيم جي ڪوشش آهي. ڪافي ڪجھ ٽيڪنالاجيون آھن جيڪي ٽيمون استعمال ڪري سگھن ٿيون تخمينو پيدا ڪرڻ لاءِ. اڄ اسين سڀ کان وڌيڪ مشهور ٽيڪنڪ تي نظر ڪنداسين: اسڪرم پوکر . هن ٽيڪنڪ کي هڪ مينيجر جي ضرورت آهي جيڪو اسڪرم پوکر لاءِ منتظم جي حيثيت سان ڪم ڪندو . اهو ٿي سگهي ٿو ڪو ماڻهو جيڪو اسڪرم ماسٽر آهي يا ممڪن آهي ته PM .
Scrum پوکر ڇا آهي؟
اسڪرم پوکر ، يا پلاننگ پوکر، هڪ اندازي جي ٽيڪنڪ آهي جيڪا هڪ معاهدي تائين پهچڻ تي ٻڌل آهي. اهو بنيادي طور تي ڪم جي پيچيدگي جو اندازو لڳائڻ يا سافٽ ويئر ڊولپمينٽ ڪمن جي لاڳاپي سائيز جو اندازو لڳائڻ لاء استعمال ڪيو ويندو آهي. مان سڌو چوندس ته اسڪرم پوکر هڪ عام سافٽ ويئر ڊولپمينٽ مشق آهي، ۽ توهان کي ڄاڻڻ جي ضرورت آهي ته اهو سڀ ڪجهه ڇا آهي. اهو عام طور تي شامل آهي هڪ ايپ يا ويب سائيٽ کي سهولت ڏيڻ لاءِ ٽيم جي تعاون سان هڪ خاص ڪم لاءِ تخمينو ٺاهڻ. اهو ڪيئن ٿو ٿئي؟ ٽيم پٺتي پيل (هڪ نئون ڪم، ڪجهه ڪارڪردگي) مان ڪجهه وٺندو آهي ۽ مختصر طور تي ان سان لاڳاپيل ممڪن نقصانن ۽ ٻين نونسن تي بحث ڪندو آهي. ان کان پوء هر شرڪت ڪندڙ هڪ نمبر سان ڪارڊ چونڊيندو آهي جيڪو انهن جي پيچيدگي جي اندازي کي ظاهر ڪري ٿو. اوه، هڪ ٻي شيءِ، جڏهن اهي اندازو لڳايون ته، اسان فبونيڪي جي ترتيب
۾ انگن کي استعمال ڪريون ٿا بلڪه عام انگن جي. فبونيڪي نمبر اسڪرم پوکر ۾ مشهور آهن ، ڇاڪاڻ ته انهن جي وچ ۾ هڪ تمام وڏو خال آهي (هڪ پرامڊ جي سطح وانگر). ڪجهه ڪم انتهائي پيچيده هوندا، ۽ اسان ٿوري تعداد ۾ ڪهاڻي پوائنٽن سان پري نه ٿي سگهنداسين. ڪجھ غير معمولي ڪارڊ آھن جن جا ھيٺيان مطلب آھن:
آخري پوائنٽن جو اڻڄاتل تعداد
لامحدود ڊگهو ڪم
هڪ وقفو جي ضرورت آهي
گھٽ عام اندازي جا طريقا استعمال ڪن ٿا:
ٽي شرٽ جو سائز - S, M, L, XL
ڪتن جون نسلون - چيهوا، پگ، ڊچشنڊ، بلڊاگ، وغيره (ذاتي طور تي، مان سمجهان ٿو ته هي ڪوشش جي اندازي جي ماپ جو عجيب يونٽ آهي =D)
ٽيم وري ساڳي ڪم لاءِ مختلف ڊولپرز پاران ڏنل تخميني جو مقابلو ڪري ٿي. جيڪڏهن اهي متفق آهن، پوء عظيم! جيڪڏهن نه، ته پوءِ مختلف اندازن جي سببن (دلائل) تي بحث ڪرڻ جي ضرورت آهي. ان کان پوء، ٽيم گڏجي ڪم ڪري ٿو هڪ واحد اندازي ٺاهڻ لاء جيڪو هرڪو قبول ڪري ٿو، گهٽ يا گهٽ. پوء ڇو پوکر به استعمال ڪيو ويندو آهي سنگين سافٽ ويئر منصوبن جي منصوبابندي ڪرڻ لاء؟ توهان کي تسليم ڪرڻو پوندو ته اهو عجيب آهي. حقيقت اها آهي ته هن قسم جي گيميشن ٽيم جي ميمبرن کي آزاديء سان سوچڻ جي حوصلا افزائي ڪري ٿي، انهن کي دعوت ڏئي ٿو ته انهن جي اندازن کي ظاهر ڪرڻ لاء ساڳئي وقت انهن جي ٽيمن وانگر. اهو، موڙ ۾، اهڙي صورتحال پيدا ڪرڻ کان بچي ٿو جتي ڪجهه ٽيم ميمبر ٻين جي راء تي ڀاڙين ٿا. جيڪڏهن اهو هن طريقي سان نه ڪيو وڃي ها، ته پوءِ گهٽ تجربيڪار ڊولپرز وڌيڪ تجربيڪار ٽيم جي ميمبرن پاران مهيا ڪيل تخميني تي نظر وجهندا ۽ ڌيان ڏيندا، ۽ اهو انهن جي پنهنجي تخميني کي گهٽ مفيد بڻائيندو. پر ساڳئي وقت تخمينو ڏيکارڻ ان کي لازمي طور تي ناممڪن بڻائي ٿو. Atlassian رٿابندي جي عمل ۾ استعمال ڪرڻ لاءِ اسڪرم پوکر ايپ پيش ڪري ٿي.
ڪوشش جو اندازو لڳائڻ جو مثال
فرض ڪريو ته توھان جي ٽيم ھيٺين پيماني تي قائم ڪئي آھي ڪهاڻي پوائنٽن کي تخميني ڪرڻ لاءِ:
1. ڇا توھان وٽ ھن قسم جي ڪم سان ڪو تجربو آھي؟
+1 — مون هي ڪم اڳي به ڪيو آهي
+2 — مون اهو ڪم نه ڪيو آهي، پر ساڳئي ڪم تي ڪم ڪيو آهي
+3 — مون هي ڪم نه ڪيو آهي ۽ نه ئي اهڙي ڪنهن شيءِ جو تجربو آهي
توهان اڳ ۾ اهڙي ڪارڪردگي ڪڏهن به لاڳو نه ڪئي آهي: +3
ڪارڪردگي اوسط-سائيز آهي: +2
عمل درآمد انتهائي پيچيده ٿيندو: +3
ڪارڪردگي لاءِ لکڻ جا امتحان انتهائي پيچيده هوندا: +3
هر جزو کي شامل ڪرڻ سان، توهان کي ڪل 11 ڪهاڻي پوائنٽ ملندا، پر اهڙو ڪو به ڪارڊ نه آهي، تنهنڪري توهان 13 جو مشورو ڏيو. هڪ همراهه ڪم لاءِ هيٺين تخميني کي اڳيان رکي ٿو:
هن کان اڳ هڪ اهڙي ڪم سان ڪم ڪيو آهي: +1
ڪارڪردگي اوسط-سائيز آهي: +2
عمل درآمد اوسط پيچيدگي جو ٿيندو: +2
ڪارڪردگي لاءِ لکڻ جا امتحان سراسري پيچيدگي جا هوندا: +2
هن جو وچولي نتيجو 7 ڪهاڻي پوائنٽس آهي، پر اهو نمبر Fibonacci سيريز ۾ موجود ناهي، تنهن ڪري هو سڀ کان وڌيڪ لڳ ڀڳ نمبر سان ڪارڊ جمع ڪري ٿو - 8. ٽيم جا ٻيا ميمبر پڻ پنهنجا تخمينو ٺاهي انهن جي موضوعي نظرين جي بنياد تي. پوءِ هرڪو پنهنجا ڪارڊ ڏيکاريندو آهي ۽ توهان ڏسندا آهيو ته توهان جي تقريبن سڀني همراهن 13 جو تخمينو ڏنو، سواءِ هڪ ڊولپر جي جنهن 8 تجويز ڪيو هو. ان صورت ۾، هن کي اجازت آهي ته هو پنهنجي گهٽ تخميني جا سبب ٻڌائي. فرض ڪريو ته هو هن جواز پيش ڪري ٿو: هن اڳ ۾ ئي ساڳئي ڪم تي ڪم ڪيو، ۽ اهو ايترو ڏکيو ناهي جيترو اهو لڳي سگهي ٿو. آخرڪار، هو باقي ٽيم کي قائل ڪري ٿو ته هو پنهنجي ذهن کي 13 کان 8 ڪهاڻي پوائنٽن کان تبديل ڪن، چيو ته هو مدد ڪندو جيڪو هن ڪم کي ختم ڪري ڇڏيندو. يا شايد هو پاڻ ئي ڪندو. ڪنهن به صورت ۾، اهو مسئلو ناهي ته ٻيا هن جي دليلن کي قبول ڪن يا نه، ڇاڪاڻ ته هڪ طريقو يا ٻيو اندازو لڳايو ويندو ڪم لاء، ۽ ٽيم اڳتي وڌندي ايندڙ هڪ تي غور ڪرڻ لاء. شروعاتي طور تي، تخمينو غلط ھوندا، جيئن ڪم جي مقدار جو اندازو لڳايو ويندو جيڪو توھان ايندڙ وقت (اسپرنٽ) ۾ حاصل ڪرڻ جو ارادو ڪيو. آخرڪار، اهي تخمينو استعمال ڪندي ٺاهيا ويا. ڪجهه وقت کان پوءِ، شايد ٽن مهينن کان پوءِ، ٽيم ڪمن لاءِ گهربل وقت جو وڌيڪ صحيح اندازو لڳائڻ شروع ڪندي، ۽ ڪم جي سراسري مقدار جيڪا ٽيم سپرنٽ ۾ انجام ڏيڻ جي قابل آهي، ظاهر ٿي ويندي. پر اهو ڪم جي دائري لاء هڪ عام منصوبو ٺاهڻ جو عمل آهي. اهو خاص طور تي وقت تي ڌيان ڏئي ٿو، پر هن معاملي ۾ ڪيترائي مختلف لاڳاپيل عنصر ٿي سگهن ٿا. مثال طور، فرض ڪريو هڪ ڊولپر ٻن هفتن لاءِ موڪلن تي ويو. توھان کي ھڪڙي خاص رقم کي ڪٽڻ جي ضرورت پوندي منصوبابندي ڪيل ڪم (منصوبابندي ڪيل ڪارڪردگي). يا فرض ڪريو هڪ نئون ڊولپر ٽيم ۾ شامل ٿيو آهي، پر اڃا تائين مڪمل طور تي تيز نه آهي، تنهن ڪري توهان کي ضرورت آهي ته هن کي وقت ڏيڻ جي اجازت ڏيو ته هو ان بورڊنگ جي عمل ذريعي پروجيڪٽ سان واقف ٿي وڃي. اهو ٻه هفتا ٿي سگهي ٿو، هڪ هفتو ڏيو يا وٺو، منصوبي جي پيچيدگي جي لحاظ سان. اهو سڀ ڪجهه اڄ لاء آهي! مون کي اميد آهي ته مون توهان جي ڪوشش جي تخميني جي ڄاڻ کي ٿورو بهتر ڪيو، سافٽ ويئر ڊولپمينٽ جو هڪ ضروري غير ٽيڪنيڪل پاسو. جيڪڏھن توھان چاھيو ٿا ھن موضوع ۾، ۽ اسڪرم جي تفصيلن ۾، مون کي ڏاڍي صلاح ڏني ته توھان پڙھو "SCRUM" ڪتاب جيف سدرلينڊ جو. مان نتيجن جي باري ۾ ڪو به واعدو نٿو ڪري سگهان، ڇاڪاڻ ته ان کي پڙهڻ کان پوءِ توهان کي هڪ اسڪرم ماسٽر =D ٿيڻ جي ڏکوئيندڙ خواهش پيدا ٿيندي.
اڄ مان هن غير ٽيڪنيڪل، تنظيمي علم جي هڪ پهلو بابت ڳالهائڻ چاهيان ٿو. اڄ اسان ڪوشش جي اندازي بابت ڳالهائينداسين . ڇاڪاڻ ته مون کي صرف Agile طريقو استعمال ڪرڻ جو تجربو آهي (جنهن کي سڀ کان وڌيڪ مشهور سمجهيو ويندو آهي)، خاص طور تي اسڪرم فريم ورڪ، مان اسڪرم جي حوالي سان ڪوشش جي تخميني تي غور ڪندس . شروع ۾، مون کي ضرور چوڻ گهرجي ته ڪوشش جو اندازو لڳائڻ ڏکيو آهي. مون لاء، اهو هڪ ڊولپر جي حيثيت سان منهنجي نوڪري جي سڀ کان وڌيڪ مشڪل / ناپسنديده حصن مان هڪ آهي. غور ڪرڻ لاءِ ڪيترائي مختلف عنصر آھن جيڪي توھان جي ڪم لاءِ گھربل ڪوشش جي اندازي کي متاثر ڪري سگھن ٿا. اضافي طور تي، مستقبل جي ترقياتي منصوبا توهان جي اندازن تي ٻڌل هوندا.
ڪجھ غير معمولي ڪارڊ آھن جن جا ھيٺيان مطلب آھن: 
GO TO FULL VERSION