خانه / 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 یا خودداری از نوشتن ویژگی هایی است که در حال حاضر نیازی به آنها نمی باشد. داشتن یک ساختار مدیریتی هم سطح و نه سلسله مراتبی، رعایت اصول سادگی و شفافیت در نوشتن کد و تعامل و  ارتباط زیاد با مشتری از ویژگی های XP می باشند. ذکر این نکته هم شاید خالی از لطف نباشد که این متدولوژی اسم خودش را از بهره وری و منفعت در پرکتیس هایی گرفته است که در سطح ‘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، پرکتیس های آن در چهار گروه کلی برای دستیابی و پشتیبانی این موارد در این متدولوژی معرفی و طراحی شده است.


  • 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 Board جهت پیگیری پیشرفت کارها در هر اسپرینت استفاده کنند.

محدودیت کار در جریان یا 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

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

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل هرچند تفکر و ایده ی ورای Microservices …

فرآیند آزمون AB

AB Testing Approach مقدمه بی شک یکی از سخت ترین و مشکل ترین فعالیت های …

پاسخ دهید

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

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

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

پیوستن بستن