د کمپیوټر صنعت د مبهم ژبې، سختو جملو، او پیچلو نظرونو سره ډک دی چې پوهیدل ستونزمن دي او کولی شي ستاسو ذهن د کمپیوټري بفرینګ جنون ته واستوي.
آبشار؟ سکروم؟ چټل؟
که دا جملې ستاسو لپاره په بشپړه توګه بهرنۍ وي، اندیښنه مه کوئ؛ ستاسو د هشډورک ټیک ګیکس ګټور ټیم دلته دی چې تاسو سره مرسته وکړي ترڅو د پراختیا پروسې د دې مهم مرحلو ترمینځ توپیرونه پوه شي ترڅو تاسو پوه شئ.
ځیرک، سکرم، او د آبشار تخنیکونه به ټول پدې بلاګ پوسټ کې پوښل شي، سره له دې چې هر یو څنګه کولی شي ستاسو ټیم سره په بشپړ ډول مرسته وکړي.
راځئ چې په چټکۍ سره پیل وکړو، او موږ به د پاتې نورو سره یوځای کړو.
زحمت څه شی دی؟
د چټک سافټویر پراختیا یو تکراري، زیاتیدونکي چلند تعقیبوي. د پروژې په پیل کې د پراخه چمتووالي پرځای ، د وخت په تیریدو سره د اړتیاو بدلولو لپاره د انعطاف وړ تخنیکونه او د پای کاروونکو څخه دوامداره فیډبیک هڅوي.
کراس-فعال ټیمونه د وخت په تیریدو سره د محصول تکرارونو باندې کار کوي، او دا کار په بیکلاګ کې طبقه بندي کیږي او د سوداګرۍ یا پیرودونکي ارزښت پراساس لومړیتوب ورکول کیږي. د هر تکرار هدف د کارولو وړ محصول رامینځته کول دي.
رهبري د ایجیل میتودولوژیو کې همکارۍ ، مسؤلیت او د مخابراتو مخابراتو ته وده ورکوي.
د سوداګرۍ برخه اخیستونکي او پراختیا کونکي باید همکاري وکړي ترڅو ډاډ ترلاسه کړي چې محصول د مصرف کونکي غوښتنې او د شرکت اهداف پوره کوي.
د "چټک پرمختګ" کلمه یو شمیر میتودونو او چوکاټونو ته اشاره کوي چې د ایډیالونو او اصولو پراساس دي چې په کې بیان شوي. د زیار منشور.
کارپوهان مشوره ورکوي چې ګړندي اصولو او ارزښتونو ته غاړه کیږدي او د لارښود په توګه یې وکاروي ترڅو د سافټویر پراختیا ته نږدې کیدو پرمهال په ځانګړي چاپیریال کې د ترسره کولو لپاره سم عملونو پریکړه وکړي.
همکار او د ځان تنظیم کونکي ټیم د چټک سافټویر پرمختیا ټولنې لپاره د تمرکز اصلي ساحې دي.
ټیمونه اجازه لري چې په خپلواکه توګه پریکړه وکړي چې دوی به څنګه د یوې ځانګړې پروژې سره مبارزه وکړي، مګر دا پدې معنی ندي چې څارونکي شتون نلري. نو ځکه چټل ټیمونه کراس فعال دي.
په ځیرک تمثیل کې، مدیران لاهم اړین دي. دوی ډاډ ترلاسه کوي چې د ټیم هر غړی د پروژې لپاره اړین وړتیاوې لري یا ترلاسه کوي.
مدیران په ځیرک چوکاټ کې د داسې فضا رامینځته کولو سره کار کوي چې په ټیم کې غوره راوړي. مګر د دې پرځای چې مشري وکړي ، دوی ډیری وختونه شاته څوکۍ نیسي او ټیم ته اجازه ورکوي چې پریکړه وکړي چې دوی به څنګه شیان وړاندې کړي.
مدیران یوازې هغه وخت ښکیل کیږي کله چې ټیمونه په مکرر ډول هڅه کوي پرته له بریا پرته ستونزې حل کړي.
د چټک پرمختګ دوره
د Agile پراختیا دورې مرحلې لاندې لیست شوي دي. دا مهمه ده چې په یاد ولرئ چې دا مرحلې باید په ترتیب سره ترسره نشي ځکه چې دوی انعطاف منونکي او په دوامداره توګه بدلیږي. ډیری دا مرحلې په ورته وخت کې ترسره کیږي.
- پلان جوړونه: وروسته له دې چې د پروژې ټیم پریکړه وکړه چې یو نظر عملي او د کار وړ وي، دوی د ځانګړتیاوو په لټه کې پیل کوي. د دې پړاو موخه دا ده چې هر ځانګړتیا ته لومړیتوب ورکړي او دا نظر په کوچنیو کاري برخو (خصوصیتونو) کې ماتولو وروسته تکرار ته وټاکي.
- د اړتیاو تحلیل: د سوداګرۍ اړتیاوو ټاکلو لپاره، دا ګام د مدیرانو، شریکانو، او کاروونکو سره ډیری بحثونه لري. څوک به محصول وکاروي او څنګه به یې وکاروي د هغه توضیحاتو څخه دي چې ټیم یې باید راټول کړي. دا معیارونه باید مشخص، د تطبیق وړ، او کمیت وي.
- ډيزاين: هغه اړتیاوې چې په تیرو مرحلو کې موندل شوي د سیسټم او سافټویر ډیزاین چمتو کولو لپاره کارول کیږي. د محصول یا د حل ظهور لپاره غور باید د ټیم لخوا ترسره شي. د ازموینې لپاره یوه تګلاره یا پلان هم د ازموینې ټیم لخوا رامینځته کیږي.
- تطبیق، کوډ کول، یا پراختیا: د دې مرحلې تمرکز د ځانګړتیاوو په جوړولو او ارزونه او د تکرارونو پلي کولو پلان کول دي (د تکراري او زیاتیدونکي پراختیا طریقې تعقیب [IID]). ځکه چې هیڅ ځانګړتیاوې شتون نلري، د پراختیا دورې 0 تکرار پیل کیږي. د فعالیتونو په بشپړولو سره لکه قرارداد کول، د ترتیباتو ترتیب کول، او تمویل، دا تکرار د راتلونکي ودې لپاره زمینه برابروي.
- د آزموینې: وروسته له دې چې کوډ جوړ شو، دا د اړتیاوو په وړاندې ازمول کیږي ترڅو ډاډ ترلاسه شي چې محصول واقعیا د کاروونکو غوښتنې پوره کوي او د سوداګرۍ اهداف پوره کوي. واحد، ادغام، سیسټم، او د منلو وړ ازموینه پدې مرحله کې ترسره کیږي.
- تعین کول: د ازموینې وروسته، محصول پیرودونکو ته لیږل کیږي ترڅو دوی وکولی شي ګټه واخلي. که څه هم، پروژه د ګمارلو وروسته پای ته نه ده رسیدلې. پیرودونکي کولی شي د محصول کارولو پیل کولو وروسته اضافي مسلو سره مخ شي، کوم چې به د حل موندلو لپاره د پروژې ټیم ته اړتیا ولري.
ګټي
- ګړندی ، د لوړ کیفیت تحویل: د پروژې په تکرارولو (د مدیریت وړ واحدونو) په ماتولو سره، ټیم کولی شي د لوړ کیفیت همکارۍ، پراختیا، او ازموینې تمرکز وکړي. کله چې ازموینه د هر تکرار سره ترسره کیږي، مسلې موندل کیږي او په چټکۍ سره حل کیږي. برسېره پردې، د دوامداره، وروسته بیاکتنې سره، دا د لوړ کیفیت سافټویر ډیر چټک چمتو کیدی شي.
- بدلون ته ښه راغلاست ویل کیږي: که څه هم د پلان کولو دورې لنډې دي، دا د پروژې په هر ځای کې د بدلونونو منلو او ځای په ځای کول ساده دي. بیکلاګ تل ښه کیدی شي او له سره لومړیتوب ورکول کیږي، ټیمونو ته اجازه ورکوي چې په څو اونیو کې په پروژه کې بدلون راولي.
- د پای هدف ممکن معلوم نه وي: هوښیارتیا د پروژو لپاره غوره ده کله چې پای هدف په روښانه توګه تعریف شوی نه وي. لکه څنګه چې پروژه نوره هم حرکت کوي، موخې به روښانه شي، او پراختیا به په اسانۍ سره د دې بدلون اړتیاوې پوره کړي.
- دوامداره پرمختګ: ګړندي پروګرامونه د پروژې په ټولو مرحلو کې د کاروونکي او ټیم ان پټ ته وده ورکوي، د هغه څه پلي کولو ته اجازه ورکوي چې د راتلونکي تکرار ښه کولو لپاره زده شوي.
- د پیرودونکو نظرونه ارزښت لري: د پیرودونکو لپاره ډیری فرصتونه شتون لري چې د کار بشپړیدل وګوري، فیډبیک وړاندې کړي، او واقعیا وروستۍ پایلې اغیزه وکړي. د پروژې ټیم سره په خورا نږدې اړیکو سره، دوی ممکن د مالکیت احساس رامینځته کړي.
- قوي ټیم کار: چټل د منظم اړیکو او په شخصی توګه د مخامخ کیدو په اهمیت ټینګار کوي. خلک کولی شي مسؤلیت په غاړه واخلي او د پروژې ځینې برخې ولري کله چې په ټیمونو کې کار کوي.
زيانونه
- د ټیم غړي باید پوه ويe: چټک ټیمونه اکثرا کوچني وي. په دې توګه، د ټیم غړي باید د مهارتونو پراخه لړۍ ولري. سربیره پردې ، دوی باید د ټاکل شوي Agile تخنیک په کارولو سره درک او په اسانۍ احساس وکړي.
- پلان کول ممکن لږ دقیق وي: دا ممکن کله ناکله ننګونه وي چې د سپارلو دقیق نیټه وټاکي. Agile د وخت په بکس شوي تحویلي باندې رامینځته شوی ، او د پروژې مدیران په مکرر ډول د دندو لومړیتوبونه تنظیموي. په دې توګه، دا احتمال لري چې ځینې تحویلي چې په پیل کې د تحویل لپاره ټاکل شوي و په خپل وخت پای ته ونه رسیږي. برسیره پردې، د پروژې په اوږدو کې په هر وخت کې نور سپریټونه اضافه کیدی شي، ټول مهالویش اوږدوي.
- اسناد ښايي له پامه غورځول شي: د ټیم ځینې غړي ممکن پدې باور وي چې په اسنادو تمرکز کول لږ مهم دي ځکه چې د ایجیل منشور د بشپړ اسنادو څخه پورته کاري سافټویر خوښوي. هوښیار ټیمونه باید د اسنادو او خبرو اترو تر مینځ مثالی توازن رامینځته کړي، حتی پداسې حال کې چې بشپړ اسناد نشي کولی پخپله د پروژې بریالیتوب تضمین کړي.
- وروستی محصول ممکن خورا توپیر ولري: ممکن د ابتدايي Agile پروژې لپاره روښانه ستراتیژي شتون ونلري، او له همدې امله پای ته رسیدل ممکن د هغه څه څخه ډیر بدلون ومومي کوم چې لومړی اټکل شوی و. د پام وړ مختلف وروستی محصول ممکن د پیرودونکي ان پټ بدلولو پراساس د نوي تکرار اضافه کولو پایله ولري ، ځکه چې ایجیل خورا د تطبیق وړ دی.
- د پراختیا کونکو وخت ژمنې: پرمختیایي ټیم باید پروژې ته په بشپړ ډول ژمن وي ترڅو چټکه اغیزمنه وي. د چال چلند طریقه، چې د دودیز چلند څخه ډیر وخت نیسي، دوامداره فعال ګډون او همکارۍ ته اړتیا لري. سربیره پردې، دا پدې معنی ده چې پراختیا کونکي باید د پروژې بشپړ اوږدوالي ته ژمن وي.
آبشار څه شی دی؟
د سافټویر انجینرۍ او معلوماتي ټیکنالوژۍ پروژو لپاره د سیسټم د پراختیا د ژوند دورې (SDLC) خورا مشهور تکرار د "آبشار طریقې" په نوم پیژندل کیږي، کوم چې یو ترتیب، خطي کړنلاره تعقیبوي.
د ګانټ چارټ، د بار چارټ بڼه چې د هرې دندې پیل او پای نیټې ښیي، کله ناکله د پالن کولو لپاره کارول کیږي.
پرمختیایی ټیم د اتو مرحلو څخه یو له پای ته رسیدو وروسته لاندې کچې ته وده ورکوي. ټیم نشي کولی د ټول طرزالعمل بیا پیل کولو پرته مخکینۍ مرحلې ته راستون شي.
برسیره پردې، پیرودونکي ممکن اړتیاوې ارزونه وکړي او اړتیاوې ومني مخکې له دې چې ټیم بلې کچې ته لاړ شي.
د آبشار ماډل د تولید او ساختماني سکتورونو په خورا منظم چاپیریال کې رامینځته شوی ، چیرې چې تنظیم کول ممکن خورا ګران یا حتی ناممکن وي.
د آبشار تخنیک دومره نومول شوی ځکه چې دا د آبشار په څیر یوازې په یو لوري - ښکته لور ته د جریان لپاره ټاکل شوی. په دې پړاوونو کې تحلیل، پیل، ازموینه، ډیزاین، ودانۍ، ځای پرځای کول، ساتنه، او ازموینه شامله ده.
د آبشار تخنیک د هرې بلې ستراتیژۍ په څیر ډیری ګټې لري. یو دا چې د پروژې پلان جوړونې او ډیزاین مرحلې ډیر ښه تنظیم شوي.
پیرودونکي او پراختیایی ټیم ډیر یوځای کیږي کله چې دا د پروژې تحویلۍ ته راځي پداسې حال کې چې د آبشار سافټویر پراختیا کاروي. ځکه چې تاسو د پروژې له پیل څخه خبر یاست، د آبشار پراختیا هم د پرمختګ څارنه اسانه کوي.
د آبشار پروسه متخصصین، پراختیا کونکي، شنونکي، او ټیسټران کاروي ترڅو په پروژه کې د دوی دندو تمرکز وکړي د دې پرځای چې ټول ټیم په یو ګام ټینګار وکړي.
د آبشار مرحلې
د آبشار شپږ مرحلې باید یو له بل وروسته واقع شي:
- د راټولولو او ذخیره کولو اړتیاوې: تاسو باید په دې اړه بشپړه پوهه راټول کړئ چې دا پروژه پدې وخت کې څه غوښتنه کوي. د دې معلوماتو د راټولولو لپاره ډیری تخنیکونه شتون لري، په شمول د مرکې، سروې، او د ګډو مغزونو په شمول. د پروژې اړتیاوې باید د دې پړاو پای ته رسیدو پورې ښکاره شي، او ستاسو ټیم باید د اړتیاو سند یوه کاپي ترلاسه کړي.
- د سیسټم ډیزاین: سیسټم ستاسو د ټیم لخوا د مخکې ټاکل شوي مشخصاتو په کارولو سره ډیزاین شوی. د دې مرحلې په جریان کې، هیڅ کوډ نه ترسره کیږي، مګر ټیم د هارډویر یا پروګرام کولو ژبې اړتیاوې ټاکي.
- تطبیق: پدې مرحله کې کوډ کول شامل دي. د مخکینۍ مرحلې ډیټا د پروګرام کونکو لخوا د کارولو وړ محصول جوړولو لپاره کارول کیږي. کوډ اکثرا په کوچنیو ټوټو کې پلي کیږي چې د یوې مرحلې په پایله کې یا د بل په پیل کې یوځای کیږي.
- د آزموینې: محصول د کوډ بشپړیدو وروسته ازمول کیدی شي. هر ډول مسلې په دقت سره موندل کیږي او د ازموینې کونکو لخوا راپور شوي. ستاسو پروژه ممکن د بیا ارزونې لپاره لومړی پړاو ته لاړ شي که چیرې مهمې ستونزې څرګندې شي.
- تحویل / ځای پرځای کول: محصول په دې وخت کې پای ته رسیږي، او ستاسو ټیم د ځای پرځای کولو یا خوشې کولو لپاره تحویلي وسپاري.
- د ساتنې او: پیرودونکي محصول ترلاسه کړی او کاروي یې. ستاسو ټیم ممکن د اصلاحاتو او تازه معلوماتو رامینځته کولو ته اړتیا ولري کله چې ستونزې د دوی د حل لپاره څرګندیږي. یوځل بیا ، د پام وړ ستونزې کولی شي لومړي ګام ته د راستنیدو غوښتنه وکړي.
ګټي
- د چلولو او اداره کولو لپاره ساده: د آبشار طریقه د کارولو او پوهیدو لپاره ساده ده ځکه چې هره پروژه په ورته ترتیب سره اداره کیږي. د آبشار پروژې پیل کولو دمخه، ټیم ته اړتیا نشته چې کوم مخکینۍ تخصص یا روزنه ولري. د آبشار چلند خورا سخت دی؛ هره مرحله د تحویلۍ او بیاکتنې یوه سیټ لري چې اداره کول او ساتل یې اسانه کوي.
- یو ښه مستند میتودولوژی ته اړتیا ده: هغه اسناد چې د آبشار میتودولوژي لخوا اړین دي د ازموینو او کوډ ترشا دلیل روښانه کولو کې مرسته کوي. برسیره پردې، دا د کاغذ لاره رامینځته کوي په هغه صورت کې چې شریکان د یو ځانګړي پړاو یا د راتلونکي نوښتونو لپاره اضافي معلومات غواړي.
- د ډسپلین پلي کول: د آبشار په پروژه کې هر ګام یو پیل او پای لري، دا د شریکانو او پیرودونکو لپاره د پرمختګ په اړه خبرې کول اسانه کوي. ټیم کولی شي د کوډ تولید کولو دمخه د اړتیاو او ډیزاین په ځای کولو سره د نیټې له لاسه ورکولو احتمال کم کړي.
زيانونه
- د دقیقو اړتیاو راټولول ستونزمن کیدی شي: د مصرف کونکو او شریکانو سره خبرې کول د دوی اړتیاوې مشخص کول د آبشار پروژې یو له لومړیو مرحلو څخه دی. د پروژې په دې لومړی پړاو کې، دا ممکن ستونزمن وي چې د دوی ځانګړي اړتیاوې معلومې کړي. پیرودونکي په مکرر ډول د دوی اړتیاو په اړه زده کوي ځکه چې پروژه د دوی د څرګندولو پرځای وده کوي.
- بدلونونه د ځای کولو لپاره ستونزمن دي: عمله نشي کولی د یوې مرحلې پای ته رسیدو وروسته کار بیا پیل کړي. دا خورا سخت او ګران دی چې بیرته لاړشئ او ترمیم یې کړئ که چیرې دوی د ازموینې مرحلې په جریان کې زده کړي چې فعالیت د اړتیاو پروسې په جریان کې ورک و.
- سافټویر د هغې نیټې څخه وروسته چمتو کیږي: د پروژې دوه څخه تر څلورو پړاوونو باید مخکې له دې چې اصلي کوډ پیل شي پای ته ورسیږي. برخه اخیستونکي به د پایلې په توګه د ژوند دورې تر ناوخته پورې فعال سافټویر ونه ګوري.
سکرم څه شی دی؟
د Agile د عملي کولو لپاره یو له خورا غوره خوښ شوي پروسې چوکاټ سکرم دی ، کوم چې د Agile فرعي سیټ دی.
دا د پیچلي سافټویر او محصولاتو رامینځته کولو اداره کولو لپاره تکراري تمثیل دی. سپرینټ، کوم چې د ثابت اوږدوالی تکرارونه دي چې له یوې څخه تر دوو اونیو پورې دوام کوي، ټیم ته وړتیا ورکوي چې په منظم مهال ویش کې سافټویر خپور کړي.
برخه اخیستونکي او د ټیم غړي سره یوځای کیږي ترڅو د هر سپرینټ وروسته د راتلونکو ګامونو په اړه بحث وکړي. په سکرم کې رولونه، مسؤلیتونه، او غونډې ثابت پاتې دي.
د مثال په توګه، سکرم د سپرینټ پلان جوړونه، ورځنی سټینډ اپ، د سپرینټ ډیمو، او د سپرینټ بیرته ستنیدل د څلورو رسمونو په توګه مشخصوي چې د هر سپرینټ جوړښت چمتو کوي.
ټیم به د هر سپرینټ په جریان کې بصري آثار لکه ټاسک بورډونه یا د سوځولو چارټونو څخه کار واخلي ترڅو پرمختګ وښیې او زیاتیدونکي فیډبیک ترلاسه کړي.
په سکرم کې، ټیم او د محصول مالک د سیسټم فعالیت پیژندلو او لومړیتوب ورکولو لپاره په ګډه کار کوي. دوی دا د محصول بیکلاګ رامینځته کولو سره ترلاسه کوي ، کوم چې د سافټویر تولید لپاره اړین ټولې دندې لري چې د هدف په توګه کار کوي.
د بګ پیچونه، غیر فعال اړتیاوې، او ځانګړتیاوې باید ټول په قطار کې شامل شي. کراس-فعاله ټیمونه باید اټکل وکړي او لاسلیک کړي ترڅو د دوامداره سپرینټ په اوږدو کې د سافټویر زیاتوالي وړاندې کړي، کوم چې عموما 30 ورځې دوام کوي، کله چې اهداف تاسیس شي.
یوازې ټیم کولی شي د دې سپرینټ لپاره بیکلاګ ترسره کولو وروسته په سپرینټ کې فعالیت اضافه کړي.
د سپرینټ بل تحویلي ، د محصول بیک لاګ ارزول کیږي او که اړتیا وي ، بیا لومړیتوب ورکول کیږي ، او لاندې تحویلي سیټ د لاندې سپرینټ برخې په توګه غوره کیږي.
د سکرم پروسه
- د محصول بیکلاګ: د محصول په بیکلاګ کې د توکو امر کولو لپاره، د محصول مالک او سکرم ټیم سره لیدنه کوي (د محصول بیکلاګ کار د کارونکي کیسې او غوښتنو څخه راځي). د محصول بیکلاګ د محصول لپاره د ټولو مطلوبو ځانګړتیاو لیست دی نه د دندو لیست چې باید بشپړ شي. د هغې په تعقیب، پراختیایی ټیم د هر سپرینټ په اوږدو کې د اجرا کولو لپاره د محصول بیکلاګ څخه دندې غوره کوي.
- د سپرنټ پلان: د هر سپرینټ څخه دمخه، د محصول مالک ټیم ته د سپرینټ پلان کولو په غونډه کې د بیکلاګ غوره توکي وړاندې کوي. بیا ډله د محصول بیک لاګ څخه توکي غوره کوي چې دوی کولی شي د سپرینټ په جریان کې پای ته ورسوي او د سپرینټ بیک لاګ ته یې لیږدوي (کوم چې په سپرینټ کې د بشپړولو لپاره د دندو لیست دی).
- د شاتګ اصالح کول/سمه کول: د دې لپاره چې ډاډ ترلاسه شي چې بیکلاګ د لاندې سپرینټ لپاره چمتو شوی، ټیم او د محصول مالک د یو سپرینټ په پایله کې سره ګوري. ټیم کولی شي د کارونکي کیسې له مینځه یوسي چې نور اړین ندي، نوي اضافه کړي، هغه ترتیب بیاکتنه وکړي چې باید ورته په ګوته شي، یا د کاروونکي کیسې په کوچنیو دندو ویشل کیږي. د دې "ښکلا" غونډې په جریان کې، دا به ډاډ ترلاسه شي چې په شاتړ کې یوازې هغه شیان شامل دي چې مناسب، ژور او د پروژې اهدافو سره سمون لري.
- هره ورځ د سکرم غونډې: د ډیلي سکرم په نوم په 15 دقیقو ولاړه ناسته کې د ټیم هر غړی د خپلو اهدافو او کومې ستونزې چې رامینځته شوي بحث کوي. هره ورځ د سپرینټ په اوږدو کې، ټیم په ورځني سکرم کې برخه اخلي، کوم چې هرڅوک په دنده کې ساتي.
- د سپرین ارزولو لپاره غونډهt: ټیم د هر سپرینټ په پای کې د سپرینټ بیاکتنې په غونډه کې خپل کار وړاندې کوي. د راپور یا پاورپواینټ پریزنټیشن پر ځای، دا غونډه باید یو ریښتینې مظاهره ولري.
- د بیرته ستنیدو سپرنټ غونډه: ټیم د هر ډول تعدیلاتو په اړه بحث کوي چې په لاندې سپرینټ کې باید رامینځته شي او همدارنګه د هر سپرینټ په پایله کې سکرم د دوی لپاره څومره ښه کار کوي. ټیم کولی شي د سپرنټ مثبت اړخونه، منفي اړخونه، او د پرمختګ لپاره ساحې په اړه بحث وکړي.
ګټي
- د ټیم څخه ډیر مسؤلیت: د پروژې مدیر نشته چې د سکرم ټیم ته لارښوونه وکړي چې څه وکړي او کله. هغه کار چې په هر سپرینټ کې پای ته رسیدلی شي د دې پرځای د ټیم لخوا په بشپړ ډول پریکړه کیږي. دوی ټول همکاري کوي او یو بل ته لاسونه چمتو کوي، د ټیم کار ته وده ورکوي او د هر ټیم غړي کې انفراديت ته وده ورکوي.
- د پروژې لید او روڼتیا ښه شوی: لږ غلط فهمۍ او ناڅرګندتیا شتون لري ځکه چې په ټیم کې هرڅوک د پرله پسې غونډو له امله د خپلو مسؤلیتونو څخه خبر دي. ټیم کولی شي د ستونزو سره معامله وکړي مخکې لدې چې دوی له کنټرول څخه بهر شي ځکه چې مسلې دمخه لیدل کیږي.
- د لګښت کمول زیات شوي: دوامداره اړیکه ټیم ته د هرې ستونزې یا بدلون په اړه خبر ورکوي کله چې پیښ شي، کوم چې د لګښتونو خوندي کولو او کیفیت ښه کولو کې مرسته کوي. د ځانګړتیاوو کوچنۍ برخې د دوامداره فیډبیک لپاره چمتو کوي او مخکې له دې چې لویې تېروتنې د درملنې لپاره خورا ګران شي د ابتدايي تېروتنې سمون ته اجازه ورکوي.
- د بدلونونو سره د تطبیق لپاره ساده: دا د بدلونونو سره معامله کول او موافقت کول اسانه دي کله چې په مکرر ډول فیډبیک لوپونه او لنډ سپرینټ شتون ولري. د مثال په توګه، که ټیم د یو سپرینټ په جریان کې د نوي کارونکي کیسه سره مخ شي، دوی کولی شي دا فیچر په چټکۍ سره د بیکلاګ اصالح کولو غونډې کې لاندې سپرینټ ته اضافه کړي.
زيانونه
- د خطرونو ساحه: د بشپړیدو د ټاکل شوې نیټې د نشتوالي له امله، د سکرم ځینې پروژې ممکن د پراخیدو سره مخ شي. برخه اخیستونکي کولی شي د نورو ځانګړتیاو غوښتنې ته دوام ورکړي که چیرې د بشپړولو لپاره نیټه شتون نلري.
- یو خراب سکرم ماسټر ممکن هرڅه له مینځه یوسي: د پروژې مدیر د سکرم ماسټر په څیر نه دی. د سکرم ماسټر باید په هغه ټیم باور وکړي چې دوی یې نظارت کوي او هیڅکله ورته لارښوونې نه کوي. د سکرم ماسټر په ټیم کې واک نلري. پروژه به ناکامه شي که چیرې د سکرم ماسټر د ټیم اداره کولو هڅه وکړي.
- د دقت مسلې ممکن د ضعیف بیان شوي کارونو پایله وي: که کارونه په روښانه توګه نه وي مشخص شوي، د پروژې لګښتونه او مهال ویش به سم نه وي. پلان کول ننګونکي کیږي او سپرینټونه ممکن د اټکل څخه ډیر وخت ونیسي که چیرې لومړني اهداف تعریف شوي نه وي.
- تجربه او وقف د ټیم لپاره اړین دی: د دې لپاره چې ټیم بریالی وي، رول او دندې باید په روښانه توګه تعریف شي. د سکرم ټیم د ټیم غړو ته اړتیا لري چې تخنیکي مهارتونه ولري ځکه چې په واضح ډول تعریف شوي رولونه شتون نلري (هرڅوک هرڅه کوي). ټیم باید د سکرم ورځني غونډو کې برخه اخیستو او د پروژې ژوند لپاره یوځای پاتې کیدو ته هم ژمن وي.
ځیرک بمقابله سکرم
که څه هم Agile او Scrum ورته میتودولوژي کاروي، د دواړو ترمنځ ځینې توپیرونه شتون لري. د ایجیل منشور د تکراري پراختیا له لارې د سافټویر رامینځته کولو لپاره د اصولو سیټ په ګوته کوي.
سکرم، له بلې خوا، د لارښوونو مجموعه ده چې باید د Agile سافټویر پراختیا په وخت کې تعقیب شي. ځیرک یو مفهوم دی، پداسې حال کې چې سکرم د عمل کولو لپاره یو تخنیک دی.
سکرم د ایجیل پلي کولو میتود دی ، له همدې امله دوی دواړه ډیری شیان مشترک لري. دواړه طریقې تکراري دي، د سافټویر لومړني او پرله پسې تحویل ته لومړیتوب ورکوي، او بدلون ومني. دوی د خلاصون او دوامداره پرمختګ ملاتړ هم کوي.
ځیرک بمقابله آبشار
ریګیډ بمقابله انعطاف وړ د آبشار پروسې او ایجیل ترمینځ توپیرونه په غوره توګه بیانوي. پداسې حال کې چې چټل مایع دی او په دوامداره توګه بدلیږي، آبشار خورا سخت، ډیر سخت میتودولوژي ده.
د دوی تر منځ نور توپیرونه په لاندې ډول دي:
- ګړندی خطي چلند ته اړتیا نلري ، پداسې حال کې چې آبشار ترتیب دی.
- پداسې حال کې چې اړتیاوې اکثرا د آبشار په پروژو کې مخکې تعریف شوي، دوی تمه کیږي چې په چټک نوښتونو کې بدلون او تطبیق شي.
- د Agile په مقابل کې، د آبشار پروژې د کار کولو لپاره د بدلونونو اجازه نه ورکوي چې په مخکینۍ مرحله کې بشپړ شوي.
- آبشار یو منظم کړنلاره ده په کوم کې چې تاسو باید بل ګام ته د تګ دمخه هر ګام پای ته ورسوئ. په هرصورت، Agile یو انعطاف وړ میتودولوژي ده چې تاسو ته اجازه درکوي د پروژې سره په خپل سرعت سره پرمخ بوځي.
چټل Vs آبشار Vs سکرم
- آبشار په هغه څه باور زیاتوي چې ډیر ژر به د پلان کیدو وروسته چمتو شي. چټل د پرمختیایي چاپیریال په غوره کړنو تکیه کوي. دلته، د پروژې یو شمیر خطرونه په ښه توګه اداره کیدی شي ځکه چې پایلې په دوامداره توګه ارزول کیږي.
- آبشار اټکل نه کوي چې ټیم او پروژه به په ورته ځای کې میشته وي. پداسې حال کې چې سکرم او چټک د کارمندانو ګډ ځای ته اړتیا لري.
- Agile د پروژې بیا کار کمولو باندې تمرکز کوي او بدلونونه هڅوي چې ډیر دمخه پکې شامل شي. د آبشار په مقابل کې، کوم چې په بل ډول ځواب ورکوي، سکرم هم د بدلونونو ابتدايي موندنې وړوي.
- د وروستي محصول لپاره یو ډیر کمپیکٹ بلوپرینټ د چټک او سکرم لخوا چمتو شوی. دا د پیرودونکي سره د ژمنو سره ستونزه رامینځته کوي. په مقابل کې، د آبشار ګرافیک پیرودونکو او پراختیا کونکو ته د بشپړې شوې پایلې غوره تاثیر ورکوي.
- د دې تخنیکونو هر یو د دوی په جوړولو کې دخیل دندو تنظیم او سمولو لپاره د وسیلو سیټ لري.
پایله
که تاسو تر دې دمه تعقیب کړی وي او د واټرفال، ایجیل او سکرم پروسو ترمنځ د توپیرونو په اړه ستاسو په پوهه باوري یاست، تاسو باید دمخه پوه شئ چې کومه تګلاره به ستاسو او ستاسو ټیم لپاره غوره کار وکړي.
د آبشار تخنیک، کوم چې د یوې ټاکلې ساحې، مهال ویش، او بودیجې سره د پروژو لپاره دی، ستاسو غوره انتخاب کیدی شي که تاسو سخت قواعد او طرزالعملونه خوښ کړئ او ومومئ چې دوی روښانه کوي.
له بلې خوا، که چیرې د آزادۍ او تطابق وړتیا ایجیل تاسو ته الهام درکړي، دا هغه ځای دی چې تاسو باید خپل پام واړوئ.
سکرم د تګ لاره ده، که څه هم، که تاسو د انعطاف وړ چوکاټ دننه لږ ډسپلین غواړئ.
په هرصورت، تاسو باید دا طریقې د هغه پروژې په رڼا کې په پام کې ونیسئ چې تاسو یې کار کوئ او ستاسو وروستۍ پایلې.
یو ځواب ورکړئ ووځي