ڪمن جو جائزو وٺڻ لاءِ ڊولپر ڪهڙا طريقا استعمال ڪندا آهن؟

هيلو سڀ! ترقي شروع ڪرڻ لاءِ گهربل نظريو تمام وسيع آهي. ڪجهه ماهرن (جاوا ۽ ٻين ٻولين ۾ پس منظر ڊولپرز) وٽ ان کان وڌيڪ آهي، جڏهن ته ٻيا (مثال طور، جاوا اسڪرپٽ ۾ فرنٽ اينڊ ڊولپرز - React Native) وٽ ٿورڙو گهٽ آهن. بهرحال، انهن ٻنهي وٽ نه رڳو ٽيڪنيڪل، پر "تنظيمي" علم جو هڪ وڏو ذخيرو هجڻ گهرجي. هي ”تنظيمي“ علم فرنٽ اينڊ ۽ پس منظر ڊولپرز لاءِ چونڪ پوائنٽن مان هڪ آهي. اڄ مان اهڙي غير ٽيڪنيڪل، تنظيمي علم جي هڪ پهلوءَ بابت ڳالهائڻ چاهيان ٿو - ٽاسڪ اسيسمينٽ (انداز) بابت. ۽ جيئن ته مون صرف Agile طريقي ۾ ڪم ڪيو آهي (جيڪو حقيقت ۾ سڀ کان وڌيڪ مشهور سمجهيو ويندو آهي)، ان جي ذيلي حصي ۾، اسڪرم ، مان اسڪرم جي حوالي سان ڪم جي تشخيص تي غور ڪندس . مان فوري طور تي چوندس ته تشخيص، جنهن کي اندازو پڻ سڏيو ويندو آهي، ڏکيو آهي. مون لاءِ ذاتي طور تي هڪ ڊولپر جي طور تي هي نوڪري جي سڀ کان مشڪل/ناپسنديده حصن مان هڪ آهي. غور ڪرڻ لاءِ ڪيترائي مختلف عنصر آھن جيڪي ڪم جي تشخيص تي اثرانداز ٿي سگھن ٿا. ساڳئي وقت، وڌيڪ ترقي لاء منصوبا توهان جي اڳڪٿين تي ٻڌل هوندا.

ڇا جيڪڏهن توهان کي درجه بندي صحيح نه ملي؟

جيڪڏهن هڪ ڊولپر هڪ ڪم تي ڪيترائي ڪلاڪ خرچ ڪري ٿو آخر ۾ خرچ ڪيو ويندو، اهو لڳي سگهي ٿو ته هو بهترين ماهر نه آهي، ڇاڪاڻ ته اندازو بلڪل غلط هو. سو ڳالهائڻ، آسمان ۾ آڱر. ساڳئي وقت، جيڪڏهن ڊولپر اڳڪٿي ڪيل وقت ۾ سيڙپڪاري نه ڪندو آهي، هو پراڊڪٽ/نئين فيچر کي ڇڏڻ لاءِ گراهڪ جي منصوبن کي خطري ۾ وجهي ٿو. هي هڪ ڪاروبار آهي، ۽ ڪاروبار جو مطلب آهي پئسا، ۽ ٿورا گراهڪ اهڙي پنڪچر پسند ڪندا. اهو ئي سبب آهي ته مون کي اندازو لڳائڻ پسند ناهي، ڇو ته ڪڏهن ڪڏهن اهو تمام ڏکيو هوندو آهي ته ڪنهن ڪم کي مڪمل ڪرڻ لاءِ صحيح وقت جو تعين ڪرڻ.

وقت جو اندازو ڪيئن لڳايو ويو آهي؟

ضابطي جي طور تي، اندازو لڳايو ويندو آهي ڪلاڪن يا ڪهاڻي پوائنٽن ۾. ذاتي طور تي، مان ڪهاڻي پوائنٽس ۾ تشخيصي عمل جي تمام گهڻو ويجهو آهيان . جيڪڏهن هڪ واچ ڪجهه جسماني آهي، ته پوءِ ڪا شيءِ جيڪا غلط ٿي سگهي ٿي، ڪهاڻيءَ جا نقطا ٿورڙا آهن ڪنهن ٻئي جي باري ۾، وڌيڪ تجريدي. عام طور تي، سافٽ ويئر ڊولپمينٽ ٽيمون وقت جي شڪل ۾ تخمينو ڏين ٿيون: ڪلاڪ، ڏينهن، هفتا، مهينا. اهڙي وقت جو تخمينو بنيادي طور تي ذاتي تجربو، اندازو لڳائڻ، يا وجدان تي ٻڌل آهي. انهي حالت ۾، ڊولپرز صرف ڪم تي نظر اچن ٿا ۽ هڪ اندازو لڳايو ته اهو ڪيترو وقت وٺندو. نتيجي طور، اهي تمام گهٽ ئي صحيح آهن، ڇاڪاڻ ته اهڙا ڪيترائي عنصر آهن جيڪي ڪم مڪمل ڪرڻ جي آخري حد تي اثر انداز ڪري سگهن ٿيون. تنهن ڪري، ڪيتريون ئي ٽيمون ڪم ڪندڙ Agile طريقي جي مطابق ڪهاڻي پوائنٽ استعمال ڪن ٿيون. اچو ته ان جو اندازو لڳايو.

ڪهاڻي جا نقطا ڇا آهن

ڪهاڻي پوائنٽ ماپ جو هڪ يونٽ آهي جيڪو مجموعي ڪوشش جي تشخيص جو اظهار ڪري ٿو جيڪو ڪم جي هڪ خاص علائقي (ڪارڪردگي) کي مڪمل طور تي لاڳو ڪرڻ لاء ضروري آهي. اھو آھي، اھو ھڪڙو نسبتا پيچيدگي آھي . ٽيمون ڪم جي پيچيدگي، ڪم جي دائري، ۽ خطري يا غير يقيني صورتحال جي بنياد تي ڪهاڻي پوائنٽ تفويض ڪن ٿيون. عام طور تي، اهي قدر مقرر ڪيا ويا آهن وڌيڪ موثر طريقي سان ڪم کي ننڍن حصن ۾ ٽوڙڻ، ان ڪري غير يقيني صورتحال کي ختم ڪرڻ. وقت گذرڻ سان گڏ، هي ٽيمن کي اهو سمجهڻ ۾ مدد ڪري ٿو ته اهي ڏنل وقت ۾ ڇا حاصل ڪري سگهن ٿا ۽ انهن کي ڪم جي ايندڙ علائقن کي وڌيڪ صحيح طريقي سان منصوبه بندي ڪرڻ ۾ مدد ڪري ٿي. اهو لڳي سگهي ٿو توهان کي مڪمل طور تي ضدي، پر هي خلاصو اصل ۾ ڪافي مفيد آهي: اهو ٽيم کي زور ڏئي ٿو ڪم جي پيچيدگي بابت سخت فيصلا ڪرڻ. اچو ته ڪجهه سببن تي نظر رکون ته ڪهاڻي پوائنٽس پلاننگ ۾ استعمال ڪرڻ لاء:

• وقت جي وقفي ۾ اندازي جي غلطيءَ کان بچي سگھجي ٿو؛
• وقت گذرڻ سان گڏ تخميني ڪرڻ جي برعڪس، اوور هيڊ لاڳت کي بهتر انداز ۾ رکيو وڃي ٿو: ٽيم جي ميمبرن ۽ گراهڪ جي وچ ۾ رابطي، ٽيم جي مختلف بحثن ۽ منصوبابندي، گڏوگڏ غير متوقع حالتون؛
• هر ٽيم مختلف پيماني تي ڪم کي گريڊ ڪندي، جنهن جو مطلب آهي ته انهن جي رفتار (پوائنٽس ۾ ماپيل) مختلف هوندي؛
• هر ڪهاڻي نقطي کي تفويض ڪرڻ لاء هڪ پيماني جي وضاحت ڪندي، توهان جلدي پوائنٽن کي ورهائي سگهو ٿا بغير ڪنهن تڪرار جي.

ڪهاڻي پوائنٽس کي ڪيئن استعمال نه ڪجي

بدقسمتي سان، ڪهاڻي پوائنٽ اڪثر ڪري ٻين مقصدن لاء استعمال ٿيندا آهن. ڪهاڻي جا نقطا ناقص ٿي سگهن ٿا جڏهن اهي استعمال ڪيا وڃن ماڻهن جو جائزو وٺڻ لاءِ، تفصيلي ڊيڊ لائين ۽ وسيلن جي وضاحت ڪرڻ، ۽ جڏهن انهن کي غلطي سان ڪارڪردگي جي ماپ طور ورتو وڃي. ان جي بدران، ٽيمن کي هر ڪم ۾ ڪم جي حجم / پيچيدگي کي سمجهڻ ۽ ترجيح ڏيڻ لاء انهن کي استعمال ڪرڻ جي ضرورت آهي. اهو ممڪن آهي ته اهي حصا جن کي وڌيڪ ڏکيو قرار ڏنو ويو آهي انهن کي پهريان مڪمل ڪيو وڃي ته جيئن اهي اسپرنٽ جي پڄاڻي کان اڳ مڪمل ٿي سگهن ، پر آسان حصن کي بعد ۾ پوئتي ڌڪي سگهجي ٿو. اچو ته مان توهان کي ياد ڏيان ته اسپرنٽ ڇا آهي اسڪرم جي طريقي جي حوالي سان: ٽيم ۽ گراهڪ جي وچ ۾ معاهدي جي ذريعي ترقي جي شروعات ۾ هن وقت جي مدت ڪيتري ڊگهي آهي. اهو ٿي سگهي ٿو ٻه هفتا يا هڪ مهينو، يا ڪنهن ٻئي دور جو. ضابطي جي طور تي، اسپرنٽ جي شروعات ۾ ڪم جو اندازو لڳايو ويندو آهي ته جيئن اسپرنٽ جي آخر تائين مڪمل ٿيل ڪم جي ممڪن رقم جي منصوبابندي ڪرڻ لاء، جڏهن مڪمل ڪم ڪسٽمر تائين پهچايو وڃي. اهو توهان جي پيداوار جي ترقي ۾ توهان جي ترقي کي ڏسڻ ۾ مدد ڪري ٿي، ڪسٽمر کان موٽ حاصل ڪريو ۽ گراهڪ جي نظر جي مطابق منصوبي جي ترقي کي ترتيب ڏيو. پر اڃا تائين، اسان ٿورو اڳتي وڌو ٿا: اچو ته تخميني ڏانهن واپس وڃو. صرف هڪ ڊولپر پاران ڪمن جو جائزو وٺڻ تمام گهڻو تابع هوندو. تنهن ڪري، ضابطي جي طور تي، هي ٽيم ڪم آهي. ٽيم جي تشخيص لاء ڪافي ڪجھ ٽيڪنالاجيون آھن. اڄ اسان ڏسنداسين انهن مان سڀ کان وڌيڪ استعمال ٿيل - Scrum poker . هن ٽيڪنڪ کي هڪ مينيجر جي ضرورت آهي جيڪو هن اسڪرم پوکر جي اڳواڻ وانگر هوندو . اهو ٿي سگهي ٿو هڪ شخص جيڪو اسڪرم ماسٽر ، يا PM ۾ ماهر هجي .

Scrum پوکر ڇا آهي

اسڪرم پوکر - يا پلاننگ پوکر - هڪ تشخيص ٽيڪنڪ آهي جيڪا هڪ معاهدي تائين پهچڻ تي ٻڌل آهي. بنيادي طور تي استعمال ٿيندڙ ڪم جي پيچيدگي جو جائزو وٺڻ يا سافٽ ويئر ڊولپمينٽ دوران حل ٿيڻ واري ڪمن جي نسبتي حجم. مان فوري طور تي نوٽ ڪندس ته Scrum پوکر ترقي ۾ هڪ عام رواج آهي، ۽ توهان کي ضرور ڄاڻڻ جي ضرورت آهي ته اهو ڪهڙي قسم جو جانور آهي. هن عمل لاءِ، اسان عام طور تي ڪنهن قسم جي ايپليڪيشن يا ويب سائيٽ استعمال ڪندا آهيون جيڪا اسان کي ڪنهن خاص ڪم جي ٽيم جي تشخيص کي منظم ڪرڻ جي اجازت ڏئي ٿي. اهو ڪيئن ٿو ٿئي؟ ٽيم هڪ بيڪ لاگ آئٽم وٺي ٿي (نئون ڪم، ڪارڪردگي)، مختصر طور تي بحث ڪري ٿو ممڪن نقصانات ۽ ان سان لاڳاپيل ٻين نونسن. هر حصو وٺندڙ وري هڪ نمبر سان ڪارڊ چونڊيندو آهي جيڪو انهن جي ڏکيائي جي درجه بندي جي نمائندگي ڪري ٿو. اوه، ۽ جڏهن اندازو لڳايو، اهو عام سلسلو نه آهي جيڪو استعمال ڪيو ويندو آهي، پر فبونيڪي نمبر . فبونيڪي نمبر تمام مشهور آهن اسڪرم پوکر ۾ ڇاڪاڻ ته انهن جي وچ ۾ فرق وقت سان وڌي ٿو (پرامڊ جي سطح جي ياد ڏياريندڙ). اهڙا ڪم آهن جن ۾ تمام گهڻي پيچيدگي هوندي، ۽ ٿوري تعداد ۾ ڪهاڻي پوائنٽ حاصل نه ٿي سگهي. غير معمولي ڪارڊ جي وضاحت:

آخري پوائنٽن جو اڻڄاتل تعداد

هڪ لامحدود ڊگهو ڪم

وقفي جي ضرورت آهي

اندازي جا وڌيڪ نادر طريقا:

• ٽي شرٽ جي سائيز ۾ - S، M، L، XL
• يا ڪتن ۾ - chihuahua, pug, dachshund, bulldog, and so on (منهنجي خيال ۾، مسئلن جي تشخيص لاءِ هي عجيب يونٽ آهي = ڊي)

ٽيم وري مختلف ڊولپرز پاران ساڳئي مسئلي تي ڏنل تخميني جو مقابلو ڪري ٿي، ۽ جيڪڏهن اهي متفق آهن، عظيم! جيڪڏهن نه، اهو ضروري آهي ته تشخيص (دلائل) ۾ اختلافن جي سببن تي بحث ڪيو وڃي. ان کان پوء، اسان گڏيل طور تي هڪ واحد اندازي تي اچي سگهون ٿا، جنهن سان هرڪو، جمع يا منفي، متفق ٿيندو. خير، ڇو پوکر به هڪ سنگين سافٽ ويئر منصوبي جي رٿابندي ڪرڻ لاء استعمال ڪيو ويندو آهي؟ آخرڪار، اهو ڪجهه عجيب آهي. حقيقت ۾، اهڙي گيميشن ٽيم جي ميمبرن کي آزاديء سان سوچڻ جي حوصلا افزائي ڪري ٿي، انهن کان پڇڻ لاء انهن جي نتيجن کي انهن جي ٽيمن وانگر ساڳئي وقت ڏيکاري ٿو. اهو، موڙ ۾، ٻين ٽيم جي ميمبرن جي خيالن تي انحصار کان بچي ٿو. ٻي صورت ۾، گهٽ تجربيڪار ڊولپر وڌيڪ تجربيڪار ٽيم جي ميمبرن جي جائزي کي ڏسندا ۽ ان تي ڀروسو ڪندا، جيڪي انهن جي پنهنجي جائزي جي افاديت کي رد ڪندا. پر نتيجن جي هڪ ئي وقت کولڻ سان، اهو لازمي طور تي ناممڪن آهي. اسڪرم پوکر شيڊيولنگ ​​ايپ جو هڪ مثال Atlassian مان آهي .

ڪم جي تشخيص جو مثال

اچو ته تصور ڪريون ته توهان جي ٽيم ڪهاڻي پوائنٽن ۾ تشخيص لاءِ هڪ خاص پيماني جي نشاندهي ڪئي آهي: Scrum Poker هڪ ڪم تي شروع ٿئي ٿو ، ۽ توهان ان کي هن طرح اندازو لڳايو:

• توھان ڪڏھن به ساڳي ڪارڪردگيءَ تي عمل ڪرڻ سان اڳ ۾ ڪم نه ڪيو آھي - +3
• وچولي ڪم جي ڪارڪردگي - +2
• ڪم جي عمل ۾ اعلي پيچيدگي آهي - +3
• ھن فنڪشنلٽي لاءِ ٽيسٽ لکڻ جي اعلي پيچيدگي - +3

نتيجي ۾، توهان کي 11 ڪهاڻي پوائنٽ ملن ٿا، پر جيئن ته اهڙو ڪو به ڪارڊ نه آهي، توهان 13 پيش ڪندا آهيو. توهان جو هڪ ٻيو ساٿي ڪم جو جائزو وٺندو آهي:

• اڳي ئي ساڳئي مسئلي سان ڪم ڪيو - +1
• وچولي ڪم جي ڪارڪردگي - +2
• ڪم جي عمل ۾ اوسط پيچيدگي آهي - +2
• ھن فنڪشنلٽي لاءِ ٽيسٽ لکڻ جي اوسط پيچيدگي - +2

نتيجي طور، هو 7 ڪهاڻي پوائنٽ حاصل ڪري ٿو، پر Fibonacci انگن ۾ اهڙي ڪا به شيء ناهي، ۽ هو هڪ ڪارڊ رکي ٿو ويجهي ممڪن نمبر سان - 8. ٽيم جا ٻيا ميمبر، مطابق، تخمينو ڏيو انهن جي موضوعي نظرين جي بنياد تي. اڳيون، توهان پنهنجا نتيجا ڏيکاريو ۽ دريافت ڪيو ته توهان جي تقريبن سڀني ساٿين 13 جو اندازو لڳايو، سواءِ هڪ ڊولپر جي جنهن ان کي 8 ڏنو. ان صورت ۾، هن کي منزل ڏني وئي آهي ۽ هو دليل ڏئي ٿو. ۽ اهي، مثال طور، هن طرح آهن: هن اڳ ۾ ئي ساڳئي مسئلي سان ڪم ڪيو، ۽ اهو ايترو ڏکيو ناهي جيترو اهو لڳي سگهي ٿو، ۽ آخر ۾ هو ٽيم جي باقي ميمبرن کي قائل ڪري ٿو ته انهن جو حل 13 کان 8 ڪهاڻي تائين تبديل ڪري. پوائنٽس، چوي ٿو ته هو مدد ڪندو جيڪو به هن ڪم تي وٺندو اهو معلوم ڪندو. يا، آخر ۾، هو اهو پاڻ ڪندو. ۽ عام طور تي، اهو مسئلو ناهي ته ٻيا هن جي دليلن کي ٻڌن ٿا يا نه، ڇاڪاڻ ته هڪ طريقو يا ٻيو، هڪ درجه بندي هن ڪم کي لڳايو ويندو، ۽ ٽيم اڳتي وڌندي پاڻ کي ايندڙ هڪ سان واقف ڪرڻ لاء. پهريون ڀيرو، تخمينو غلط هوندو، جيئن ڪم جي مقدار جو اندازو لڳايو ويندو جيڪو توهان ايندڙ وقت (اسپرنٽ) دوران ڪرڻ جو ارادو ڪيو. سڀ کان پوء، اهي تخمينو صحيح طور تي تخميني جي بنياد تي ٺاهيا ويا آهن. ڪجهه وقت کان پوءِ، اٽڪل ٽن مهينن کان پوءِ، ٽيم ڪمن جو وڌيڪ صحيح اندازو لڳائڻ شروع ڪندي، ۽ ڪم جي سراسري مقدار جيڪا ٽيم في اسپرنٽ مڪمل ڪري سگهي ٿي، ظاهر ٿي ويندي. پر اهو ڪم جي دائري جي عام منصوبابندي آهي، اهو وقت جي باري ۾ وڌيڪ آهي، ۽ انهي صورت ۾ اتي ڪيترائي مختلف عنصر ٿي سگهن ٿا جن جو اثر آهي. مثال طور، هڪ ڊولپر ٻن هفتن لاء موڪلن تي ويا. اھو آھي، توھان کي ھڪڙي خاص رقم کي پار ڪرڻ جي ضرورت آھي منصوبابندي ڪيل ڪم (منصوبابندي ڪيل ڪارڪردگي). يا هڪ نئون ڊولپر ٽيم ۾ آيو آهي، پر توهان کي هن تي مڪمل طور تي ڳڻڻ جي ضرورت ناهي، ڇاڪاڻ ته ... توھان کي پروجيڪٽ سان ٺاھڻ لاءِ گھربل وقت حساب ۾ رکڻو پوندو، جنھن کي آن بورڊنگ سڏيو ويندو آھي . اهو ٿي سگهي ٿو ٻه هفتا، پلس يا مائنس هڪ هفتي، منصوبي جي پيچيدگي تي منحصر آهي. اهو سڀ ڪجهه اڄ جي لاءِ آهي، مون کي اميد آهي ته مون توهان جي ڄاڻ ۾ ڪجهه بهتري ڪئي آهي علم جي اهڙي غير ٽيڪنيڪل حصي ۾ جيئن مسئلو اندازي. جيڪڏھن توھان چاھيو ٿا ھن موضوع ۾، گڏوگڏ Scrum جي تفصيلن ۾، مان توھان کي زور سان پڙھڻ جي صلاح ڏيان ٿو ڪتاب ”اسڪريم“ جيف سدرلينڊ جو. مان نتيجن جي تصديق نه ٿو ڪري سگهان، ڇاڪاڻ ته شايد ان کان پوءِ توهان کي اسڪرم ماسٽر = ڊي ٿيڻ جي ڏکوئيندڙ خواهش هوندي.