خانه / Agile / اجایل به معنی اسکرام نیست!

اجایل به معنی اسکرام نیست!

اجایل به معنی اسکرام نیست! گزاره ای به ظاهر بدیهی و روشن؛ در عمل اما خلاف این امر صادق است. و در بیشتر اوقات دچار این اپیدمی خطرناک هستیم. بخصوص مواردی که هنوز تفکر و فرهنگ چابکی و ارزش ها و تاثیرات آن برایشان روشن نیست؛ و سعی در استفاده از اسکرام به روش خود دارند؛ که باعث می شود با این تفکر که ما اسکرام را برای خود شخصی سازی می کنیم سعی در حذف بخش هایی از اسکرام نمایند و بخش هایی از آن را بی اهمیت تشخیص دهند! و یک اسکرام ناقص و دست و پا شکسته را پیاده سازی کنند؛ غافل از اینکه با بستن دست و پای یک شیر نمی توان از آن انتظار سلطانی جنگل را داشت؛ و نکته ی مهمتر اینکه اسکرام به خودی خود به اندازه کافی “تیم را به خود وا بگذار” هست؛ که همین هم ممکن است نشانه ای باشد برای اینکه اسکرام برای هر تیمی شاید مناسب نباشد؛ بخصوص تیم هایی که ممکن است در برخی practice ها هنوز به سطح mature نرسیده باشند. حال با کاستن و زدن و پروبال زدن به این متدولوژی-محبوب- باعث می شود که تیم را بیشتر به سمت “تیم را به خود وا بگذار” سوق دهیم؛ وانگهی ممکن است-در بیشتر موارد- تیم همچین ظرفیتی نداشته باشد.

نکته ای که باید توجه کنیم در اینجا این هست که اجایل و چابکی فقط محدود به اسکرام نیست؛ اگر اسکرام مناسب و متناسب با شرایط ما نیست؛ بمعنی دوری جستن از چابکی و اجایل نیست؛ اجایل به عنوان چتری از چندین و چند متدولوژی محبوب دیگر می باشد؛ از آن جمله می توان به اسکرام؛ ایکس پی؛ کانبان؛ ناب اشاره کرد. مواردی را مشاهده کرده ام که بدون توجه و نظر به ارزش ها و فرهنگ چابکی؛ به سمت اسکرام رفته؛ اما برخی موارد مهم اسکرام را عملا قبول نداشته و کنار می گذارند؛ به عنوان نمونه می توان به time-boxed بودن اسکرام اشاره کرد؛ time-boxed نبودن یعنی بی معنی شدن commit و سبک شمرده شدن جلساتی مثل گرومینگ و پلنینگ و در ادامه کار شکایت های بیش از حد اعضای تیم از سر درگمی و گیجی و شنیدن جمله ی معروف که “قبلا خیلی بهتر بودیم؛ و این اسکرام کار را بسیار سخت و درهم و برهم کرده است”. نکته ی دیگری که در پی این اتفاق می افتد مثلا معمولا کارهای اضافه شده به تیم بسیار زیاد و بی برنامه خواهد بود-WIP بیش از حد-. بخصوص ما وقتی با افرادی سروکار داریم مثل Product Manager که مثلا تبدیل میشود که به SM یا PO ولی چون هنوز از نقش و تاثیر و جایگاه این role در فضای اسکرام آگاهی کافی ندارد؛ همین امر باعث می شود که این موارد نیز باعث مزید بر علت شدن اینکه اسکرام و چابک مانع کسب و کار ما و پاسخ گویی به مشتریانمان و کم شدن سرعت ما خواهد شد.

شرایطی زیادی پیش خواهد آمد که متدولوژی مثل XP یا کانبان بسیار مناسب تر از اسکرام می باشد. به عنوان نمونه فرض کنید که شما در سازمانتان با تیمی سروکار دارید که از نظر تجربه فنی و از بعد technical excellence دارای شرایط مطلوبی متناسب با محصولی که در حال توسعه آن می باشند؛ نیستند؛ در این حالت پرکتیس های XP می تواند نسبت به اسکرام برای تیم شما بهتر باشد.

شما در هر شرایطی بخصوص در مراحل اولیه که سازمان شما به دنبال استفاده از متدولوژی های چابک می باشد؛ حتما نیازمند یک مربی اجایل باتجربه و آشنا به پرکتیس های اجایل خواهید بود؛ و بدون شک از حضور یک مربی چابک بی نیاز نخواهید بود. مربی که بتواند فرآیندهای سازمان رو بخوبی Inspect کند و تجویز های مناسب و متناسب با سازمان شما را به شما ارائه بدهد؛ و موانع احتمالی و جاهایی که سازمان در حال حرکت به سمت و مسیر نامناسب می باشد؛ این موارد را کنترل کند. شخصی که بتواند سازمان را از سطح مناسبی از shu به مرحله ri از چرخه ی shu-ha-ri ببرد.

در این نوشته سعی خواهم کردم نگاهی اجمالی بین سه متدولوژی متدوالتر چابکی یعنی اسکرام؛ کانبان و ایکس پی داشته باشم.

اسکرام

بنا به تعریف Scrum Alliance اسکرام به عنوان یکی از چهارچوب های اجایل سعی در تکمیل و پرداختن به پروژه های پیچیده می باشد. این متدولوژی بر خلاق متدولوژی های از جمله کانبان که عقبه ی آن به شرکت تویوتا در صنعت خودروسازی می باشد؛ در اصل برای پروژ های نرم افزاری توصیه و طراحی شده است. و این در حالی است که این فریمورک با توجه به ماهیت که دارای جهت غلبه بر پیچیدگی موجود در اکثر کارها و فعالیت های قابلیت استفاده را خواهد داشت. نمونه های زیادی از استفاده از اسکرام در فعالیت های غیر نرم افزاری را می توان مشاهده نمود. از جمله استفاده از اسکرام در مدارس؛ در بخش های مالی یا منابع انسانی در سازمانها و موارد مشابه می توان مشاهده نمود. سادگی و غیر تجویزی بودن یکی از ویژگی های اصلی اسکرام می باشد. که شامل یکسری نقش ها و جلسات ساده می باشد که در ادامه توضیح داده خواهد شد.

از تاکیدات اصلی در اسکرام می توان به هماهنگی و همکاری تیمی-team collaborations- را اشاره کرد. به پشتوانه نقش های ساده و جلساتی که در اسکرام در نظر گرفته شده است ساختاری ساده بدست می آید که می توان به هماهنگی و همکاری تیمی و هم چنین تیم های خود سازمانده درست یافت.

یکی از قدرت های اصلی که اسکرام به بیزنیس می دهد قابلیت اولیت بندی نیازمندی ها و حتی تغییر نیازمندی ها بواسطه داشتن لیست اولیت بندی شده از کارهایی که تیم باید انجام دهد می باشد. از طرف دیگر همچنین این توانایی به تیم داده می شود که بسته به توانایی خود در بازه های زمانی مشخص بنام اسپرینت تعهد به انجام کار را داشته باشند.

یکی از نیازمندیهای اصلی اسکرام داشتن یک تیم چند وظیفه ای دارای اعضای t-shape می باشد. افرادی که تک وظیفه ای و تک مهارتی نیستند و ضمن اینکه در مهارت خاصی متخصص هستند می توانند در سایر حوزه ها نیز کار را پیش ببرند. در صورتی که از داشتن همچین تیمی محروم هستید یا داشتن همچین تیمی با سیاست سازمان شما بهر دلیل همخوانی ندارد-هستند سازمانهایی که سیاست تک تخصصی و سیلویی را هنوز می پسند- حتما در فضای اسکرام با مشکلات بسیار زیادی مواجه خواهید شد. فرض کنید نیرویی ui کار متخصص دارید اما در iteration جاری کار ui به اندازه کافی ندارید؛ در این حالت با نیرو(هایی) مواجهید که بیکار خواهند بود.

در اسکرام سه نقش اساسی وجود دارد:

  1. مالک محصول که به عنوان صدای مشتری و دینفعان پروژه؛ وظیفه ی بگ لاگ آرایی و اولویت بندی این بک لاگ را بر عهده خواهد داشت.
  2. استاد اسکرام این وظیفه را بر عهده دارد که سلامت فرآیندهای اسکرام در تیم را مانیتور کند. و این اطمینان را بدست دهد که فرآیند های اسکرام بدون مانع و مشکلات به پیش خواهند رفت.
  3. اعضای تیم؛ شامل برنامه نویسان و آزمون کننده ها و هر فردی که در تیم حضور دارد و وظیفه ی به پیاده سازی آیتم های تعهد شده توسط تیم در پایان هر iteration را بر عهده دارند.

در اسکرام اصطلاحات مهمی نیز وجود دارد از جمله بک لاگ یا سبد محصول؛ که شامل لیستی اولویت بندی شده از آیتم هایی است که توسط مالک محصول تکمیل و پر خواهد شد؛ و در ابتدای هر iteration مقداری آیتم از این لیست انتخاب و تیم متعهد به تکمیل آنها خواهد بود. اسپرینت؛ در اسکرام اشاره به بازه های زمانی بین دو تا چهار هفته ای می باشد؛ که بصورت زمان ثابت یا time-boxed می باشد؛ و در این بازه و حدود زمانی تیم تعهد به انجام آیتم های انتخاب شده از بالای بگ لاگ محصول می باشد.

علاوه بر نقش ها اسکرام دارای جلساتی نیز می باشد از جمله جلسه ی برنامه ریزی اسپرینت که در ابتدای هر اسپرینت برگزار می شود و در طی آن تیم اقدام به انتخاب آیتم هایی بسته به ظرفیت تیم برای اسپرینت جاری خواهند نمود. جلسات روزانه و سرپایی که شامل جلساتی کوتاه مدت می باشد که در ابتدای هر روز برگزار می شود و تیم از این جلسه برای برنامه ریز روزانه جهت شفاف شدن کار بین تیم برگزار می شود. در پایان هر اسپرینت تیم در جلسه ی دمو اقدام به نمایش گذاشتن نتیجه ی کار اسپرینت جاری به ذینفعان خود خواهد نمود. پایان هر اسپرینت به منتهی می شود به جلسه گذشته نگر یا retro که تیم نگاهی به اسپرینت گذشته خواهد نمود و سعی خواهد نمود از تجربیات این اسپرینت و اسپرینت های قبلی برای بهبود مستمر خود درس هایی را فرا بگیرد.

کانبان

این متدولوژی از فلسفه ی سیستم Just-In time شرکت تویوتا اقتباس شده است. آیا تجربه ی لیست بلندبالایی از کارهای ناتمام در اتمام هر روز را دارید؟ آیا عقیده دارید که تیم شما دارد از multitasking رنج می برد؟ کانبان سعی در حل این مشکلات و مشکلات مشابه را دارد.

به زبان توجه و تاکید اصلی در این متدولوژی شفاف سازی کارهایی در حال انجام و فعالیت می باشد؛ است. کانبان در تلاش است که از طریق کارتهای تصویری و از طریق برد کانبان؛ فعالیت هایی که در لحظه تیم در حال کار بر روی آن می باشد را مورد مانیتور و بررسی قرار دهد و برای اینکار تاکید زیادی Work In Progress خواهد داشت. تلاش کانبان در ایجاده محدودیت و حفظ محدودیت برای کار در جریان می باشد. Over-commit از جمله مشکلات رایجی است که برخی تیم ها با آن مواجه هستند و همواره بدون توجه و تاکید بر ظرفیت تیم؛ تیم دارای تعهد بیش از حد جهت انجام می باشد که این باعث می شود که تیم دچار نوعی سردرگمی از نظر ازدیاد کارها باشد. کانبان دارای بردی است که این برد شامل سطرهایی است که هر کدام از این سطرحها نشان دهنده یکی از وضعیت های موجود برای آیتم می باشد؛ مهمترین این سطح های سطح in progress یا ongoing می باشد؛ که هدف کانبان حفظ حد مناسبی بسته به ظرفیت تیم برای این سطح می باشد؛ و در تلاش است که تیم در هر لحظه از زمان دارای آیتم های in progress بیش از حد نباشد. به محض اینکه آیتمی به سرانجام رسید این آیتم به سطح آخر برد منتقل شده و آیتم دیگری از ستون اول یعنی ستون to do به ستون in progress منتقل خواهد شد. آیتم های ستون to do بر اساس اولویت مرتب شده هستند. نکته ی اصلی و رمز موفقیت در کانبان توجه و تحلیل work in progress جهت رسیدن به بهبود مستمر و و بیشینه کردن هماهنگی و همکاری بین تیمی می باشد. یکی از مزیت های محدود نمودن WIP تطبیق نمودن ظرفیت و توانایی تیم توسعه با میزان کارهای در حال انجام می باشد. این محدود هم می تواند بر اساس شخص باشد و هم تیم. به محض رسیدن تیم به ظرفیت تعیین شده؛ وقت آن فرا می رسد که تیم به این فکر کند که چرا دچار همچین شرایطی شده است و سعی در رفع مشکلات و موانع نماید.

خوب مهمترین مسئله در این روش تعیین مرز مناسب برای WIP می باشد. طبیعتا در ابتدای کار تعیین این مقدار براحتی نمی باشد و ممکن دچار اشتباه شود؛ و حتما نیاز به تجربه تیم دارد. همچنین باید به این نکته مهم نیز توجه کنیم که یکی از اصول کانبان “start where you are” می باشد. پس به عنوان نقطه ی شروع می توان به این نکته نیز توجه نمود که می توان تعداد آیتم های در حال پردازش فعلی را به عنوان نقطه ی شروع در نظر گرفت. ولی خوب این اندازه بطور کامل به تیم و ظرفیت آن وابسته است. اما می توان مثل با این فرض ساده شروع کرد که WIP را برای هر فرد معادل یک در نظر گرفت؛ و بدین ترتیب برای یک تیم 4 نفری این عد معادل 4 به ازای تیم می باشد. با گذشت زمان این عدد بسته به شخص و موقعیت آنها می تواند تغییر کند. و مثلا برای هر فردی این عدد به 2 یا 3 برسد. یکی دیگر از مواردی که می تواند بر این عدد تاثیر گذار باشد overlapداشتن افراد تشکیل دهنده ی تیم باشد؛ در صورتی که اعضای تیم با هم overlap نداشته باشند برای یک تیم 5 نفره طبیعتا این عدد نباید به ازای تیم؛ بیش از 5 باشد. در صورتی که تیم مثلا نیازمند pair programing باشد که دارای وظایفی باشد که منجر به overlap بین اعضای تیم باشد این عدد باید کمتر از تعداد اعضای تیم باشد مثلا می تواند بصورت n-1 در ابتدای کار در نظر گرفته شود که n تعداد اعضای تیم می باشد. هم عدد بالا و هم عدد پایین می تواند نشانه هایی از فرآیند اشتباه باشد؛ مثلا عدد خیلی بالا می تواند نشانه ی over commit تیم و همچنین task switching زیاد برای اعضای تیم باشد. و عدد خیلی پایین هم می تواند نشان دهنده ی این باشد که تیم احتمالا بر روی کاری برای چندمین مدت زمان زیادی گرفتار شده و باید به آن رسیدگی شود. نکته ی مهم دیگر در اینکه سعی می شود این محدود کردن WIP به سایر وضعیت ها نیز استفاده شود. همانطور که می دانیم کانبان در واقع بصورت یک سیستم pull-queue می باشد؛ که در این سیستم هر آیتم کاری از مرحله ی شروع مراحل و state هایی را طی می کند تا به اتمام برسد. این مراحل شامل in progress ؛ test و غیره می باشد. خوب فرض بفرمایید در تیم شما یک نفر مسئول تست می باشد؛ طبیعی است که WIP limit برای این مرحله نیز بر اساس صحبت های گفته شده در نظر گرفته شود. که همان یک می باشد و بسته به شرایط تیم می تواند بیشتر نیز باشد. به عبارت دیگر این WIP limitation باید برای تمامی سطرهای برد کانبان در نظر گرفته شود.

در کانبان چند اصل و ارزش مهم دنبال می شود:

  1. Visualize work: ایجاد یک مدل تصویری از کار و فعالیت و فعالیت های در حال جریان جهت کنترل و مانیتور کردن کارهای در حال جریان. با آنالیز نمودن این مدل می توان bottleneck های احتمالی را شناسایی نموده؛ و با رفع این موارد اقدام به بالابردن بهره وری و تعاملات درون تیمی نمود.
  2. Limit work in process: شعار مهم کانبان “تمام کردن را شروع کنید؛ شروع کردن را تمام کنید.” می باشد. در کانبان سعی می شود کارهای به اتمام نرسیده را یک حد مورد نظر محدود کرد؛ و افزایش بیش از حد کار به این سطح قبل از اتمام کارهای قبلی جلوگیری به عمل می آید. مشکلاتی از جمله Task-switching که معمولا گریبانگیر توسعه دهنده ها می باشد را می توان از این طریق رفع کند.
  3. Focus on flow: با محدود نمودن WIP کانبان در تلاش است که به آرامی و با سرعت ملایم سعی در بهبود جریان کار نماید؛ و با جمع آوری داده های متریکی و آنالیز آنها بهبود مستمر را برای تیم به ارمغان آورد.

در کانبان هیچ نقش خاصی وجود ندارد. در اینجا همچنین با فرآیندهای زمان ثابت(اسپرینت) نیز سروکار نداریم. همانطور که بیان شد هدف و تاکید کانبان حفظ سرعت مناسب در چرخه ی تولید می باشد.

ایکس پی

 

بدون شک یکی از پرکاربردترین و مناسب ترین متدولوژی های چابک برای اکثر تیم ها eXtreme Programming می باشد. از زمان معرفی و استفاده این تکنولوژی؛ تجربه های بسیار موفقی از استفاده از این متدولوژی در شرکت ها و سازمان های و پروژه های مختلف دیده شده است. Ron Jefferies و Kent Beck و Ward Cunningham از پیشروهای این متدولوژی محبوب می باشد. XP نیز همانند سایر چارچوب های چابک تاکید زیادی بر تطابق پذیری دارد. در این متدولوژی بر Practice  های روزانه ای که افراد تیم باید با آنها سروکار داشته باشند؛ تاکید بسیار وجود دارد. باید به این نکته اشاره کرد؛ که XP بر خلاف کانبان و اسکرام؛ یک متدلوژی تجویزی تر با مقدار زیادی ازش و نقش و پرکتیس می باشد.  در اینجا نیز تاکید بسیار زیادی بر ‘release’ های سریعتر و زودتر جهت کوتاهتر کردن چرخه های توسعه بمنظور بیشتر کردن productivity تاکید وجود دارد.

بخش های دیگر XP که بسیار هم مهم و مورد تاکید می باشند شامل برنامه نویسی جفتی؛ مرور کردن کد یا code review؛ نوشتن آزمون های واحد برای تمامی کدها؛ توجه ویژه به اصل YAGNI یا خود داری از نوشتن ویژگی هایی که در حال حاضر به آنها نیازی نیست؛ داشتن یک ساختار مدیریتی هم سطح و نه سلسله مراتبی؛ رعایت اصول سادگی و شفافیت در نوشتن کد؛ و تعامل و  ارتباط زیاد با مشتری می باشند. ذکر این نکته هم شاید خالی از لطف نباشد که این متدولوژی اسم خودش رو از مورد گرفته که بیشتر بهره وری و منفعت در پرکتیس هایی گرفته می شود که د سطح ‘extreme’ می باشند؛ همانند نوشتن و تاکید و توجه ویژه به کد نویسی که در سطح ‘extreme’ می باشد.

XP اولین بار توسط آقای کنت بک که مشغول کار بر روی پروژه ای در Chrysler Comprehensive Compensation System بود در سال 1996 معرفی و استفاده شد. در حول و حوش همان سال تا اوایل سال 2000 سایر سازمانها نیز به سمت استفاده از این متدولوژی روی آوردند و بسیار از پرکتیس ها و دیسیپلین های XP در خلال همین سال ها و با تاکید بر سطح ‘extreme’ معرفی شدند؛ به عنوان مثال می توان به پرکتیس test-first development که توسط پروژه ی Mercury در NASA اتفاق افتاد اشاره کرد.

اهداف XP

هدف اصلی در اینجا معرفی یک نظم در توسعه محصول است که افراد را برای ایجاد نرم افزاری با کیفیت بیشتر سازماندهی می کند. همچنین XP در تلاشه که هزینه ی تغییرات در نیازمندی ها با داشتن چرخه های توسعه هرچه کوتاهتر کاهش بده.

  • An attempt to reconcile humanity and productivity
  • A mechanism for social change
  • A path to improvement
  • A style of development
  • A software development discipline

هدف اولیه و اصلی XP کم کردن هزینه تغییرات می باشد. و برای این رسیدن به این هدف مجموعه ای از نقش ها و ارزش ها و پرکتیس ها را معرفی می کند.

ارزش های XP

  • Communication

جهت ایجاد یک دید مشترک بین توسعه دهنده و استفاده کنندگان از سیستم در XP تاکید زیادی بر ارتباط میان توسعه دهندگان سیستم و مشتریان و استفاده کنندگان از سیستم دارد.

  • Simplicity

شروع و استارت زدن با یک راه حل ساده در اینجا مورد تشویق قرار میگیرد. دلیل اصلی اینکار توجه به Coding و تمرکز به طراحی بر اساس نیازمندیهای امروز می باشد. در اینجا اصل YAGNI بخوبی مورد توجه قرار میگیرد.

  • Feedback

بازخوردهایی که از طرق و راه های مختلف گرفته می شود؛ از جمله بازخوردهای سیستم؛ مشتریان و خود تیم؛ می تواند به تیم برای ادامه کار و در صورت نیاز تغییر در مسیر جهت بهبودهای آتی بسیار کمک کننده باشد.

  • Courage

برخی کارها مثل طراحی و کد بر اساس نیازمندی های امروز؛ باعث بیشتر شدن Courage خواهد شد. Courage یا جرات به تیم این امکان را می دهد که با اطمینان بیشتری بهنگام نیاز اقدام به Refactor کردن کد موجود کنند.

  • Respect

این مورد هم شامل احتارم به خود و هم به دیگران می باشد.

Rule های XP

29 Rule مختلف بر اساس 5 دسته فعالیت مهم که نقس اساسی در این متدولوژی را دارند در اینجا تعریف شده است. این 5 دسته عبارتند از Planning, Managing, Designing, Coding, Testing. که برای توضیحات بیشتر می توانید به وب سایت XP مراجعه نمایید.

 

فعالیت های XP

XP چهار فعالیت اصلی و پایه که با فرآیندهای توسعه محصول انجام می شه رو معرفی می کنه که شامل موارد زیر می باشد.

  • Coding

در XP کد مهمترین و اصلی ترین بخش فرآیند توسعه در نظر گرفته میشود. و پرکتیس های زیاد XP توجه به بهبود همین بخش دارند

  • Testing

در این متدولوژی این تفکر وجود دارد که  if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws.

  • Listening

برنامه نویسان باید به دقت و پیوسته به مشتری و خواسته های او گوش داده و توجه کنند تا بتوانند چیزی که بیزینس نیازمند آن می باشد را توسعه بدهند.

  • Designing

طراحی منظور شناسایی و ایجاد ساختاری است که برای سازماندهی معماری سیستم که از ایجاد یک اسپاگتی کد با گذشت زمان و بزرگتر شدن محصول جلوگیری شود.

پرکتیس های XP

در کنار این اهداف، ارزش  ها و فعالیت های XP، 12 پرکتیس در چهار گروه کلی برای دستیابی و پشتیبانی این موارد در این متدولوژی معرفی و طراحی شده است.


  • Fine scale feedback
  • Pair Programming
  • Planning Game
  • Test Driven Development
  • Whole Team
  • Continuous process
  • Continuous Integration
  • Design Improvement
  • Small Releases
  • Shared understanding
  • Coding Standards
  • Collective Code Ownership
  • Simple Design
  • System Metaphor
  • Programmer welfare
  • Sustainable Pace

صحبت درباره این متدولوژی نیازمند یک مقاله مفصل جداگانه می باشد؛ که توصیه می کنم وب سایت ایکس پی را مطالعه بفرمائید.

 

مقایسه و نتیجه گیری:

همانطور که مشاهده فرمودید ایکس پی نسبت به اسکرام و کانبان بسیار بیشتر تجویزی تر می باشد. ایکس پی تلاش می کند با ایجاد یک دیسیپلین و تجویز یکسری نقش و پرکتیس مهم توجه بسیار زیادی بر توسعه محصول با کیفیت بیشتر و بدون باگ و اعمال تغییرات مورد نیاز با هزینه کمتر  دارد. از طرف دیگر هرچند اسکرام هرچند از نظر بعد فنی و تکنیکال هیچ تجویزی ندارد؛ توجه بیشتری بر بعد فرآیندی توسعه نرم افزار دارد. کانبان اما نقطه تمرکز خود را بر جنبه ی دیگری قرار دارد. کانبان بیشتر مناسب تیم هایی است که دارای سردرگمی در میزان کار در حال انجام دارند.

اسکرام از این نظر که دارای یکسری نقش و جلسات تعریف شده است به نسبت به کانبان تجویزی تر می باشد. این در حالیست که کانبان حتی iterationها را نیز تجویز نمی کند.

برد تصویری کانبان که به منزله ی قلب آن می باشد برای تیم هایی است که همگی در یک محل مشترک کار می کنند و دارای بگ لاگی از آیتم های مختلف هستند که تغییرات بر روی آنها زیاد می باشد. و از طرف دیگر این بر تصویری ارزشمند می تواند توسط تیم های اسکرام به عنوان task bard جهت پیگیری پیشرفت کارها در هر اسپرینت استفاده کنند.

محدودیت کار در جریان یا WIP هم چنین برای تیم هایی که دارای منابع محدود هستند نیز بسیار مناسب می باشد.

در حالیکه در اسکرام اینکه چگونه کارها در هر اسپرینت به سرانجام می رسند و تکمیل می شوند و روش تکمیل آن کارها به تیم واگذار می شود؛ در XP مجموعه ای از نقش ها و پرکتیس ها معرفی شده اند که بر نحوه ی انجام هر چه بهتر تاکید خواهند داشت.

در XP توجه بسیار زیادی بر الویت کارها جهت انجام وجود دارد؛ این در حالیست که در یک اسپرینت هر چند آیتم های با اولویت بالاتر انتخاب شده اند؛ ولی تیم در انتخاب آیتم های هر اسپرینت جهت انجام دادن تاکیدی وجود ندارد و مهم این هست که آیتم های هر اسپرینت در پایان اسپرینت به انجام برسند.

هم چنین تیم های XP آیتم های جدید که دارای اندازه ای مشابه با یکی ازآیتم ها موجود در iteration هستند قابل جایگزینی هستند.

جلسات روزانه سرپایی کوتاه مدت در هر دوی اسکرام و ایکس پی وجود دارد. نقش customer در XP بسیار شبیه به نقش PO در اسکرام می باشد.

بطور خلاصه می توان به جدول زیر که توسط خانم Irina Kulikova اشاره کرد.

  Scrum Kanban  XP (eXtreme Programming)
Goal Use of cross-functional, self-organized, and empowered teams who divide
their work into short, concentrated work cycles called Sprints
To alleviate  impediments that cause us to take longer to deliver, not remove necessary pieces of the process. To organize people to produce higher-quality software more productively.
Date of birth In the mid 80’s, Hirotaka Takeuchi and Ikujiro Nonaka defined a flexible and all-inclusive product
development strategy where the development team works as a unit to reach a common goal. Scrum has
increased in popularity and is now the preferred project development methodology for many organizations
globally.
Kanban developed in the 1940s as a subcomponent of the Toyota Production System and has its origins in these Lean and Just In Time (JIT) manufacturing processes. XP has been created  in 1996 by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project.
Current state The Scrum framework can only be used for small projects. However, it can easily be
scaled for effective use in large projects.
One of the reasons many groups implement Kanban is to figure out how to deliver more consistently. Kanban, as well as many other methods/processes, is often chosen and implemented by the management or leadership layer and the values and goals are communicated down to developers or other individual contributors. One of the reasons many groups implement Kanban is to figure out how to deliver more consistently. Kanban, as well as many other methods/processes, is often chosen and implemented by the management or leadership layer and the values and goals are communicated down to developers or other individual contributors.
Speciality A key strength of Scrum lies in its use of cross-functional, self-organized, and empowered teams who divide
their work into short, concentrated work cycles called Sprints. Scrum is one of the most popular Agile methodologies. It is an adaptive, iterative, fast, flexible, and effective
methodology designed to deliver significant value quickly and throughout a project. Scrum ensures
transparency in communication and creates an environment of collective accountability and continuous
progress.
In Kanban the workflow is visualised: work is broken down into small, discrete items and written on a card which is stuck to a board; the board has different columns and as the work progresses through different stages (e.g. ready, in progress, ready for review etc) the card is moved accordingly.
In Kanban the number of items that can be in progress at any one time is strictly limited.
Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it. Extreme Programming empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team.
Values 1. Focus
2. Courage
3. Opennes
4. Commitment
5. Respect
1. Transparency
2. Agreement
3. Balance
4. Respect
5. Understanding
6. Leadership
7. Collaboration
8. Customer focus
9. Flow
1. Communication
2. Simplicity
3. Feedback
4. Courage
5. Respect
Principles 1. Roles Guide
2. Empirical Process Control
3. Self-organization
4. Collaboration
5. Value-based Prioritization
1. Start with what you do now
2. Agree to pursue incremental evolutionary change
3. Initially, respect all roles, responsibilities and job titles
The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation.
Roles Core Roles:
Product Owner
Scrum Master
Scrum Team
Non-core Roles:
Stakeholders
Scrum Guidance Body
Vendors
Chief Product Owner
Chief Scrum Master
No existing roles. Some teams enlist the help of an agile coach. Tracker, Customer, Programmer, Coach, Manager, Tester. Anyone can be Doomsayer, Gold Owner (may be the same as the Customer)
Key metrics Sprint Velocity (2 weeks) Cycle time Iteration time (2 weeks)
Activities 1. Initiate
2. Plan and Estimate
3. Implement
4. Review and Retrospect
5. Release
1. To Do
2. Development
3. Test
4. Release
5. Done
1. Planning
2. Managing
3. Designing
4. Coding
5. Testing
Practices 1. Planning
2. Daily Scrum
3. Review and retrospective: Sprint Review and Sprint Retrospective
4. Extension: Backlog reinement and Scrum of Scrums
5. Artifacts: Product Backlog, Management, Sprint Backlog, Product Increment, Extensions (Sprint burn-down chart, Release burn-up chart)
1. Visualize
2. Limit Work-in-progress
3. Manage Flow
4. Make management policies explicit
5. Improve collaboratively (using models and the scientific method)
Extreme Programming has 12 practices, grouped into four areas, derived from the best practices of software engineering:
Fine scale feedback:
Pair Programming
Planning Game
Test Driven Development
Continuous process:
Continuous Integration
Design Improvement
Small Releases
Whole Team
Shared understanding:
Coding Standards
Collective Code Ownership
Simple Design
System Metaphor
Programmer welfare:
Sustainable Pace
Change philosophy Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation. Change can happen at any time. A high degree of developer discipline along with continuous customer involvement for the duration of the project.
Cadence Regular fixed length sprints. Continuous flow. Iteration.
Release methodology At the end of each sprint if approved by the product owner. Continuous delivery or at the team’s discretion. At the end of iteration.

 

 

 

درباره ی masoud@admin

همچنین ببینید

Virtual DOM vs DOM

تفاوت میان DOM و Virtual Dom DOM DOM در واقع سر واژه عبارت Document Object …

Problem Solving و Critical Thinking حلقه های گمشده ی مهندسی

Problem Solving Problem Solving یا توانایی حل مسئله بخشی از جریان فکری و تفکر انسان …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن