د سافټویر د پراختیا پروسې په اړه هر بحث د ډیری کلاسیک لارښوونې پر بنسټ چې څنګه د عصري سافټویر جوړ کړي. موږ باید د محصولاتو وړاندې کولو لپاره ځینې وختونه جوړ کړي چې د بازار اړتیاوې په ذهن کې انتظار شوي فریکونسۍ سره وړاندې کړي. د iteration اوږدوالی باید د محصول backlog بدلونونو ته اړتیا وړ سرعت وده ورکړي. ټیمونه باید د هر iteration لپاره چمتو شي او د backlog توکي رامینځته کړي. او البته، باید priorities وي. دا ښکاري چې د ترټولو مهمې مدیریت لارښوونې په بشپړه توګه حساس دی او تاسو ته اړتیا نلري چې په معیاري کولو کې د دې په خپل سافټویر پراختیا کې کار واخلئ. په هرصورت، د هر پروسه جوړولو لپاره د هر ټیم غړي لپاره د عمومي اصولو اعلان کولو معنی لري. او دلته پیچلې شتون لري: څنګه د هر ټیم غړي لپاره توضیح کړئ چې د یو کار یا محصول بیګ سره څه معنی لري؟ په ځانګړې توګه په ډیری ټیمونو پروژو کې. دا په هر وخت کې امکان دی چې ستاسو د priorities سيستم اختراع کړئ، مګر دا د خپل سيستم لپاره د هر نوی ډلې غړي لپاره اړتيا لري. که پروژې لوی دی او تاسو ډیری نوي همکارانو لري، نو دا یو ستونزه ده. له همدې امله دا په اسانۍ سره د ځینې وخت آزموینې نړیوالو معیارونو یا لارښوونې کارولو لپاره آسانه ده. په دې مقاله کې زه به د محصول د پرمختګ کې د priorization لپاره د MoSCoW پروژې په کارولو په اړه بحث وکړم لکه څنګه چې په واقعیت کې د iterations په ترڅ کې د کار د ساده کولو لپاره تر ټولو عام لاره ده، کوم چې چټک او اندازه کولی شي. د مثال په توګه، زه به د ګمرک شوي ترټولو لپاره د ترټولو ستونزو او ستونزو د مثال وړاندې کولی شي چې زه د دې روښانه کولو سره راشي. بيا موږ به د MoSCoW روښانه کولو په پام کې ونیسئ ترڅو هر ترټولو سره د ژوند د مثالونو په اړه پوه شي. یو مقاله ممکن د محصول مدیرانو یا هر څوک چې د ښه کار د محصول د پراختیا پروسه په لټه کې وي. د موضوع اولویت په اړه د custom-made لارښوونې سره تفریح ډیری وختونه مخکې، په یو محصول ټیم کې، موږ هڅه وکړه چې په زموږ د پراختیا چرګانو کې د محصول ترټولو ترټولو ترټولو ترټولو ترټولو بیلابیلو پروسه حل کړي. د پروسس په ځان کې خورا بیلابیلو وه: د پیژندنې ترټولو وختونه اغیزمنه وه، د ټیم باید اضافي وختونه کار وکړي، او د محصول وړاندیزونه د ناوړه کیفیت دي. په دې وخت کې موږ د شمیره ترټولو ترټولو ترټولو 1-2-3-4 کاروئ او دوی په هرصورت نه مرسته کوي. بيا موږ د ټیم غړي ترمنځ اړیکو د سټاکولو لپاره ونیسئ او د اضافي ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو مهم وي، د "1" څخه ډیر Why is “5” more important than “1”? Because historically we had myriad priority “1” items, and “0” was used for the tasks that had to be prioritised later. Changing the meaning of “0” means a thoughtful review of the entire backlog, implementation of some migration, and nobody wanted to do it. How does it happen that we have so many priority “1” tasks in the iteration that we have to introduce an additional priority? And what is the purpose of 2-3-4? These are the most important questions that show the process immaturity, because team members had no idea what the difference was between 2-3-4. All these tasks were just “optional”. How do we explain these illogical rules to new team members? These rules were impossible to explain, and this improvement didn’t help to make things right. په دې پروسه کې د ترټولو ستونزه نه وه. د پلان، د خطر د مدیریت او د ستراتیژۍ په اړه بنسټیز ستونزه شتون لري. مګر که تاسو په جدول کې ډیری چالونه لرئ، ستاسو د خپل مخکښ methodology اختراع به د غوره فیصلہ نه وي. په دې توګه، زه غواړم په نرم افزار د پرمختګ کې دنده ترټولو ته د معیارونو په کارولو کې د معیارونو په کارولو کې حرکت وکړي. د "MoSCoW" لارښوونې جوړولو ځینې معیارونه د IETF یا IEEE په څیر د نړیوالو غوره عملیاتو RFCs په سخته توګه کوډ شوي دي، په داسې حال کې چې نورو په خپل حق کې معیارونه شوي دي. هغه چې زه غواړم د وروستیو کټګوریو ته ورسیږي. د MoSCoW methodology نه یوازې دنده ترټولو ترټولو مهمه نه ده، مګر د کارونو په سمه توګه پیل کولو لپاره ترټولو اغیزمن او جامع طریقې یو. د لارښوونې په کتاب کې Dai Clegg لخوا پیشنهاد شوی " ” (1994) او ډیر مشهور شو. د نوم “MoSCoW” د شمالي پټلۍ سره اړیکه نلري او د ترټولو مهمو کټګوریو په توګه جوړ شو: اټکلونه لري باید لري، د الوتنې، ایا نه. دا ټولګيونه کولی شي د 1-2-3-4 شمولیتونو سره تړل شي او د محصول د پراختیا په تکرار کې د کارونو یا برخو لړ په بیلابیلو ترتیب کې مرسته وکړي. د هر ټولګي واضح هدف دا روش د دې ګيچ جوړوي، او په دې مقاله کې، زه به د Agile پراختیا په مثالونو سره هر priority پوښښ. Case Method Fast-Track: د RAD لارښوونې M S Co W لومړی، دا اړتیا لري چې د لارښوونې کارولو لپاره د مثال scenario جوړ کړي. په دې محصول کې، زموږ مشتریانو کولی شي د خپلو پروژو لپاره فایلونه ذخیره او تبادله کړي. د ساده کولو لپاره، زموږ ټیم به ځینې بنسټیز ځانګړتیاوې اضافه کړي، لکه "د کاروونکي دعوت" - د پروژې لپاره د نوي ګډون کوونکي اضافه کولو ځانګړتیاوې. موږ خپل مشتریانو ته وعده کړ چې موږ به د دې ځانګړتیاو لپاره د ځینې وخت په کارولو کې ونیسئ؛ موږ یو وعده لري. اوس، د ټیم باید د محصول د نوي ورژن د رخصتۍ دمخه د شرکت د شهرت د ساتلو لپاره د راتلونکي تکرار لپاره پلان وکړي. په دې مثال کې، موږ به په تخصص (Dev، DevOps، QA) د ټیم غړي برخه نلري، او به زموږ د ټیم په توګه د کینیکي جامع Scrum ټیم تصور کړي. د کاروونکي د وړاندیز سټینټ د تخنیکي اړتیاوې، UX / UI جوړ کړ. د ځانګړتیاوو په دې وخت کې د معنوي توکي ته وده ورکړل شوي دي چې معنی لري، او د دې ځانګړتیاو په ټول ډول ارزښت شوي دي. موږ پوه شو چې موږ باید په دې ځانګړتیاوو کې څومره رسولو وکړي. دا وخت دی چې د ترټولو مهمو لارښوونې په کارولو لپاره، او د اضافي ستونزو له الرې، د دې توکي راټول کړئ. اړتیا لري - 1 د Must Have "1" ترټولو لپاره کارونه، ځانګړتیاوې، د محصول backlog توکي، د کاروونکي تاریخونه یا بکسونه کارول کیږي چې په راتلونکي پراختیا انټرنټ کې شامل شي. د مثال په توګه، په پلان کولو کې موږ پوه شو چې ځینې کارونه باید د مشتریانو سره د قراردادونو په واسطه پراختیا شي یا دوی د نورو دلیلونو له امله سوداګرۍ مهم دي. اصلي مفکوره دا ده چې دا توکي مهم دي او غیر معامله کیدی شي. ټیم باید دوی تبادله کړي، ریسکونه واخلئ او دوی پلان کړي. که تبادله د وړیا وخت څخه ډیر وي، توکي باید د تبادله کولو په وخت کې د لږ تر لږه ارزښت محصول (MVP) جوړ شي. د نوي محصول ځانګړتیاوې مثال پر بنسټ، اجازه ورکړئ چې موږ غواړو چې د "د نوي کاروونکي ته د پروژې ته د وړاندیز کولو" ځانګړتیاوو ترسره کړي. د "د باید لري" کټګوریو د MVP ورکشاپونه وده ورکوي او بنسټیز فعالیتونه جوړوي. د تکرار پایلې باید د "1" ترټولو مهم scenario او مناسب ورکشاپونه برابر کړي: Implement the <Invite user> button in the project users list. Develop basic functions of the “Invite user” pop-up. Send a notification to the new user with authentication instructions. باید لري - 2 دویم ډول د "د باید لري" په قبيله ده. مګر دا یو څه دی چې موږ کولی شو وروسته اخلي یا وړاندې کړي. که موږ د کاروونکي دعوتونو په اړه د مشتریانو سره توافق لرو، د MVP فعالیتونه به د اولویت "1" کې د اړتیا وړ اختیارات په توګه وړاندیز شي. په هرصورت، تل ډیری پرمختګونه شتون لري چې اړتیا لري، مګر دوی ممکن په اعلان شوي کچې کې نندارې شي. په پراختیا مرحله کې، ټیم کولی شي د "Must Have" کارونو سره ځینې خطرونو سره مخنیوی شي، او د دومره اولویت فعالیتونه باید تبادله شي ځکه چې دوی د MVP برخه نه دي. د مثال په توګه، په ځانګړتیاوو کې "د کاروونکي د دعوت" د محصول باید د نوي کاروونکو ته مرسته وکړي. په "د باید لري" ترټولو مهمه کې، ټیم به د جوړولو او د دعوت د مهمې سټینټ پراختیا کړي. مګر دا هم مهمه ده چې د وړاندیز کولو مدیریت ته پیژندنه ورکړئ چې یو نوی کاروونکي په بریالیتوب سره لاس رسیږي. دا امکان دی چې د دې پیژندنې له امله د ځانګړتیاو کارول شي، مګر د دې خبرتیا سره، د محصول په بشپړه توګه ښه دی او د مدیریت به پوه شي چې هر څه ښه دی. دا دا د دوهم ترټولو مهمې جوړوي - موږ د اصلي پروسه، د سوداګرۍ لپاره مهمه شي، یوازې په یاد ولرئ چې دا ځانګړتیاو اضافي دی. د "Should Have" محصول بګ دی کوم چې د سکرینګ څخه راټول کیږي، مګر د عادي او غیر تخنیکي کاروونکي لپاره وړاندیز شوي ځینې مناسب حلونه شتون لري. دا بهتره ده چې په هر وخت کې د دې بګونه حل کړئ، مګر دوی کولی شي په اوږدوالي کې معامله شي، ځکه چې دا هم ممکن دی چې دوی له دې سره راټول شي. کولی شي - 3 دا ټولګي د پرمختګونو یا کوچني بصری نقصونو په اړه دی چې په عمومي توګه توپیر لري او د محصول په عمومي توګه احساس ته وده ورکړي، مګر دوی اوس مهال مهم نه دي یا د سکرینګ لپاره په عمده توګه اختیاري دي. دا به ښه وي چې د دې شیانو پرمختګ کړي، یوازې که د "د باید لري" یا "د باید لري" ترټولو خطرونه کم شي. په پلان کولو کې، د محصول ټیم باید د "کولی شي لري" توکي په دې ډول فکر وکړي: لومړی ترټولو باید ترسره شي. موږ باید د دوهم ترټولو ترټولو هڅه ورکړي. که هر څه ښه وي، موږ انتظار کوو چې د ترټولو ترټولو ترټولو ترټولو توکي پراختیا کړي، مګر که موږ ناکام شو، دا باید د سوداګرۍ ته اغیز نه کوي. په صورت کې د "د کاروونکي د غوښتنلیک" ځانګړتیاوې، د ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو تر د محصول بګ په توګه "کولی" ترټولو مهمه ده چې په ځینو غیر معمولي چاپیریالونو کې reproduced شتون لري یا بصری بګونه. دا بګونه کولی شي حل شي که موږ غیر معمولي ځانګړتیاوې یا د نورو کټګوریو محصول بګونه نه لرو. د تیسری ترټولو مهمه بګونه کولی شي د راتلونکي تکرار ته بدل شي د اوږد معاملو له امله، ځکه چې دوی د محصول وړاندیز مخنیوی نه کوي. د مثال په توګه، زموږ د پیرودونکي بیس اکثریت په یو ځانګړي انجن کې ویب براؤزرونه کاروي او موږ په یو غیر مشهور انجن کې یو ناڅاپي غلطی لري. دا به ښه وي چې دا بګ حل شي، مګر که هرڅه د ډیر مهمو کارونو سره کار کوي، د دې ستونزو په به نه وي - 4 یو ګټور کټګوریو چې د هغه اشیاء ښودل کیږي چې په بشپړ ډول د تکرار په وخت کې نه رامینځته کیږي. په هرصورت، دا مهمه ده چې دوی ته ورسيږي که څه هم وړتیا لري. د محصول ټیم کولی شي د تکرار او سیسټمې ورکشاپونه او بګونه د لومړي، دوهم او دریم ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو وخت لري. دا اشیاء تل په شاوخوا کې پراختیا شوي دي او هیڅکله په اوسني تکرار کې یوځای شي، مګر دا کارونه د راتلونکي تکرار لپاره آسانه کوي. د کوم ډول کارونه د "Won't Have" backlog په توګه مناسب دي؟ لومړی، د تخنیکي لګښتونه شتون لري. ډیری مهمې کولی شي د "د باید لري" یا "د باید لري" اولویت هم وي، مګر د کوډ بیس ساتنې لپاره منظم کوډ پرمختګونه د څلور اولویت یو ښه مثال دی. پراختیا کوډ د سوداګرۍ مهمو کارونو وروسته پرمختګ کولو فرصت لري او د دې پرمختګونه په راتلونکي تکرارونو کې کاروي. که ځینې بدلونونه خراب شوي دي او غیر معمولي QA اجرا ته اړتيا لري، د نوي تکرار مخکې پرمختګونه کولو هم د وخت لپاره چمتو کولو فرصت دی. همدارنګه، دا ګټور دی چې د "Won't Have" لومړیتوب په توګه ځينې توکي اضافه کړئ چې په راتلونکي تکرار کې لومړی "Must Have" لومړیتوب وي. موږ پوهیږو چې د بنسټیز کاروونکي غوښتنلیک وروسته، موږ باید په دې scenario کې تفصيلات کاروونکي اجازه تنظیمات شامل کړئ، د مدیریت د جریان ساده کولو لپاره. دا ځانګړتیا به د راتلونکي تکرار د MVP وي. که موږ ځینې ظرفیت لري، دا ښه ده چې دا د څلور ترټولو ترټولو په توګه وده ورکړي؛ دا به په راتلونکي کې خطرونه کم کړي. د راتلونکي تکرار د پلان کولو په وخت کې، د دې ځانګړیتوب ترټولو به د "Must Have" ته تازه شي. دا ښه نه ده چې د نړيوال ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټ د ترټولو غوره لارښوونې کارولو لپاره د عمومي یو - دا د ترټولو مهمې معنی د واضح درک دی. د دې مقاله په پیل کې، زه د وړاندیز شوي ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو مهمه ترټولو ترټولو مهمه ترټولو ترټولو مهمه ترټولو ترټولو مهمه ترټولو مهمه ترټولو ترټولو مهمه ترټولو ترټولو مهمه ترټولو مهمه ترټولو ترټولو مهمه ترټولو مهمه ترټولو ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو مهم ترټولو دا قواعد هم د ټیم معیارونو په توګه کار کوي او په ټیم پلان کولو لارښوونې کې ستونزو ښودلوي. د مثال په توګه، که ټیم د لومړي "Must Have" ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټولو ترټ د ځانګړتیاوو اړتیاوې نه ډېر ښه او واضح دي. د ځانګړتیاوو د خراب کولو کې یو غلطی شتون نلري. د ټیم په چمتو ډول د غوښتنلیکونو پیچیدو نیسي. هغه څوک چې د iteration په وخت کې د نظریاتو بدلولو هڅه وکړه. ټیم باید retrospective وړاندې کړي او دا د ستونزو سرچینه ونیسئ او د حل حل د خراب پرمختګ پروسه حل کړي. د ځينو iterations وروسته د پروسه باید سټینټول شي. په ورته وخت کې د درېې او د څلورې اولویتونو ثابته بشپړولو هم نه ده چې ښه ده. دا معنی لري چې موږ په ارزښتونو او خطر مدیریت کې ښه دي، مګر دا هم ښيي چې ټیم ډیره آرام یا زیرمه ده. ښايي موږ کولی شو د "د باید لري" یا "د باید لري" اولویتونو اضافي برخو پلان کړي. د پراختیا پروسه د توازن او ځینې هڅو ته اړتيا لري ترڅو ټول ټیمینګانو ښکلي ونیسئ او د پرمختګونو په لټه کې وي. د لارښوونې لګښت په دې مثال کې، کارونه د يو ځانګړي iteration لپاره د priority له مخې رامینځته شوي دي، مګر دا د شرکت د سوداګرۍ له مخې د عمومي priority له مخې معنی نه لري. کارونه چې په اوسني iteration کې د "کولی شي" په توګه تادیه شوي دي ممکن په راتلونکي کې د "کولی شي" وي، او دا بدلونونه د iteration مدیر لپاره د هر پروګرام سیشن کې اضافي وخت اړتیا لري. برسېره پر دې، د لارښوونې په یوه ټولګي کې د غوښتنلیکونو لړ سره هم ستونزه لري. که د تکرار کې لږ "د باید لري" توکي شتون لري، هغه چې باید لومړی وده ورکړي؟ دا sequence هم باید د تکرار پلان او د ځانګړي سافټویر له لارې هماهنگ شي. د ټولو پراختیا پروسه لپاره د سپری بل نه شتون لري، مګر د MoSCoW څارنې کارولو سره د بنسټیز پروسې سټینډ کولو کې مرسته کوي. د پایلو په هرصورت، زه فکر کوم چې د MoSCoW لاره د سافټویر د پراختیا پروسه په عمومي توګه د ښه کولو سره پیل کولو لپاره خورا آسانه ده. دا لاره د B2B بازار محصولات او د محصول د پراختیا لپاره ډیر مناسب دی چې د کارونو او لید په واضح ډول بیان شوي دي. دا اړتیا لري چې د راتلونکي تکرارونو لپاره د دې روښانه کارولو لپاره د پلان لري. په يو ناقانونه او چټک بدلون چاپیریال کې دا روښانه کولی شي ناکام شي او ډیری لوړ ترټولو مهمې جوړ کړي، کوم چې د وړاندیز وړتیا ته اغیزمن شي. دا ورته ستونزه ممکن د مناسب پلان او اندازې پروسې له الرې ښودل شي. مګر په هرصورت، د دې روښانه کولو سره به د ټولو دغو ستونزو په چټکۍ سره وټاک
