اسکرام ساده شده

در طی مقالاتی که بنده در مورد Scrum به رشته تحریر درآوردم , اشکالی که وارد می باشد این است که کل مقالات به صورت بریده های روزنامه می باشد که خواننده نمی تواند جمع بندی بکند . در این پست قصد دارم کل اسکرام را به صورت کامل و با بیان ساده تشریح نمایم . امید بر انجام این مهم است .


قسمت اول – توضیحات تکمیلی

اسکرام چیست ؟

در روش‌های قدیمی و معمول ساخت نرم‌افزار، طراحان نرم‌افزار معمولاً  ابتدا فرض می‌کنند که تمامی نیازهای کاربران سیستم را درک کرده‌اند. اما همیشه نیازهای کاربران سیستم در ابتدا مشخص نیست و کاربران ممکن است در همان مراحل ابتدایی، نیازهای خود را تغییر دهند و این چیزی است که برنامه‌نویسان و طراحان سیستم همیشه از آن شکایت می‌کنند و به دنبال راه‌حلی  برای رفع این موضوع می‌گردند. به‌عنوان مثال مدل قدیمی آبشاری (waterfall) را در نظر بگیرید. ادامه توضیحات

تجهیزات خود را آماده کنید

در نخستین گام نیاز داریم که یک گروه اسکرام تشکیل دهیم . این گروه برای تولید محصول و تحت دستور SCRUM Master فعالیت خواهند کرد . حداقل افراد مورد نیاز بعد از مدیریت یک نفر می باشد . یک نفری که باید به صورت اختصاصی با این محصول باشد .


گفتم محصول نه پروژه !

اسکرام محصول محور است نه پروژه محور و تمام تلاشش برای تکمیل یک محصول است ولی ممکن است در یک پروژه چندین محصول باشد.

قدمی بعدی پیدا کردن مالک محصول (Product Owner) است

ما به نفری نیاز داریم که به او بگوییم مالک محصول یا Product Owner . یک نفری که اولویت های انجام گام های پروژه را تعیین نماید (نسبت به نیاز خودش) . یک نفری که نیاز های اساسی محصول را بداند . یک نفری که بتواند نیاز های محصول را به طور احسنت و دقیق به تیم توسعه گر انتقال دهد . یک نفری که بتواند گارانتی کند محصول به صورت کامل و با موفقیت به اتمام رسیده است ( با توجه به نیاز های واقعی و درخواست شده) .

قابل ذکر می باشد که این نفر می تواند نماینده سازمان درخواست کننده باشد . در متدلوژِی مانند RUP ما از کارفرما فقط مستندات دریافت می کنیم که در اکثر اوقات نیز ناقص می باشند و این می تواند حسن Scrum باشد زیرا که ما مستقیما و بدون واسطه با Product Owner مشورت و طراحی و پیاده سازی می نماییم و در نهایت به تایید او می رسانیم .

همانند یک Scrum master عمل کنید

اکنون شما محصول را سروسامان داده اید . تیم اسکرام خود را تشکیل داده اید . یک نفر دارید که به صورت اختصاصی در خدمت محصول است . یک نفر دارید که وی مالک محصول می باشد . احتمالا شما الان یک SCRUM Master می باشید .

شما به عنوان اسکرام مستر , موظف به پشتیبانی , هدایت , راهنمایی و حذف هر نوع مانع از پیش روی تیم اسکرام در طی پروسه تولید می باشید.


قسمت دوم- شروع به اسکرامینگ

ساخت Backlog محصول

Backlog محصول عبارتست از یک فرم و یا لیست ساده که , عنوان مواردی که باید در محصول گنجانده شود در آن قید شده است , البته با احتساب حق تقدم در پیاده سازی هر مورد . تعیین اولویت وظیفه Product Owner می باشد .

Product Backlog را می توان قلب اسکرام فرض کرد , زیرا کل اسکرام از این منبع تغذیه خواهد شد , پس باید در ساخت Product Backlog دقت لازم لحاظ شود.

هر کس از اعضای گروه اسکرام و یا مالک محصول و یا افرادی از طرف مالک می توانند نظر خود را در بک لاگ محصول یادداشت نماید و نباید مانع آنها شد . اصلا اساس , پروسه Scrum و توسعه نرم افزار Agile برپایه شرکت عموم و نظرات جمع می باشد . اما نکته مهم اینست که فقط مالک محصول حق اولویت بندی انجام هر یک از این ویژگی ها را دارد بدلیل اینکه وی تنها کسی است که با نیاز های محصول دقیقا آشنا می باشد.

Backlog محصول می تواند شامل همه چیز باشد . هرچیزی که در رابطه با محصول باشد . آیتم های موجود در Backlog باید به صورت واضح باشد و تا حد امکان از اصلاحات تجاری به جای اصلاحات تکنیکی استفاده کنید (مشتری شما تاجر است نه برنامه نویس مایکروسافت) .

اولویت بندی در Backlog

همانطور که قبلا در بالا اشاره شد , کار اولویت بندی آیتم های Backlog بر عهده مالک محصول می باشد . البته نیاز نیست که مالک محصول را مجبور کنید تا با متدلوژی های مدیریت نرم افزار آشنا بشود , فقط از او بخواهید در تکمیل یک لیست ساده به شما کمک کند .

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

اگر به نظر شما آیتمی در Backlog می باشد که واقعا وقت تلف کردن است , با رعایت صبر و آرامش به صورت کامل به مالک محصول توضیح دهید که این آیتم باید از لیست حذف شود و یا باید اولویت آن را کم در نظر گرفته شود و در ته صف قرار گیرد.

شما می توانید از برنامه Excel برای ساخت Product Backlog خود استفاده نمایید . ستون های این فایل می تواند به شرح زیر باشد :

  • ID – شماره ای برای هر آیتم در نظر می گیریم که این شماره یکتا می باشد .
  • Name – توضیح مختصری از موردی که باید پیاده سازی شود . به اندازه ای باید باشد که PO و توسعه گرها بتوانند بدون مشکل , کاری که باید انجام شود را درک نمایند .
  • Importance – درجه اهمیت و رتبه آیتم می باشد . همانطور که اشاره شد این مورد وظیفه PO می باشد .
  • Initial Estimate – دلالت بر این دارد که آیتم مورد نظر در چه مدت زمانی می تواند توسط تیم توسعه انجام شود . معمولا بر حسب روز و یا ساعت بیان می شود.
    • مثال – به تیم توسعه اعلام می کنیم که ما میخواهیم مورد “مشاهده تراکنش توسط مشتری” را پیاده سازی نماییم . شما چند نفره و چند روزه می توانید این مورد را برای ما پیاده سازی نمایید . تیم توسعه اعلام می کند 4 روزه با 3 نفر , پس 3*4 برابر 12 می باشد که این عدد همان Initial Estimate این آیتم می باشد. واحدی که برای برآورد در نظر می گیریم Story Point است که مثال بالا برابر 12 Story Point می باشد.
  • دمو چگونه خواهد بود – بدلیل اینکه در آخر هر Sprint به PO یک دمو داده می شود , پس باید معلوم شود زمانی که کاربر با این قسمت کار خواهد کرد چه انتظاراتی خواهد داشت . این مورد بیشتر برای کسانی که به صورت TDD عمل می کنند سودمند می باشد .
  • Note – هر توضیحی که باعث وضوح بیشتر این آیتم شود باید در این جا درج شود .

در پایین نمونه ای از Product Backlog را مشاهده می نمایید که شامل تمام ستون هایی که در بالا اشاره شد , می باشد :

Sprint Planning

قبل از اینکه Sprint Planning را شروع نماییم , توجه نمایید که Product Backlog تمیز باشد .


منظور از Product Backlog تمیز چیست ؟

  • باید Product Backlog موجود باشد . یعنی تهیه شده باشد .
  • به ازای هر محصول باید یک Product Backlog و یک Product Owner داشته باشیم.
  • تمام آیتم های Product Backlog باید قابل فهم برای PO باشند و از اختصارات و علائم فنی استفاده نشود.
  • تمام آیتم های Product Backlog باید از نظر اهمیت توسط PO رتبه بندی شده باشند.

Sprint Planning چگونه انجام می شود ؟

هدف Sprint Planning این است که به هر یک از اعضای تیم اطلاعات کافی در مورد محصول بدهیم تا بتوانند بر روی هر یک از بخش ها بدون مشکل کار بکنند علاوه بر این ما به PO اعتماد به نفس لازم را می دهیم که بتواند در آینده همکاری لازم را داشته باشد .

خروجی Sprint Planning می تواند مواد زیر باشد :

  • هدف یک اسپرینت
  • لیست اعضا و میزان زمانی که می توانند در این اسپرینت همکاری نمایند
  • یک Sprint Backlog (شامل Story هایی می شود که باید در این اسپرینت پیاده سازی شود)
  • روزی که برای ارائه دموی اسپرینت تعیین شده است

چرا Product Owner اهمیت زیادی برای ما دارد ؟

در متدلوژِی مانند RUP ما از کارفرما فقط مستندات دریافت می کنیم که در اکثر اوقات نیز ناقص می باشند ولی اگر در اسکرام هم بخواهیم به مستندات بسنده کنیم به دردسر خواهیم افتاد .

به این دلیل مکررا گفته می شود که در جلسات اسکرام باید کل تیم اسکرام و PO حضور داشته باشد زبرا که هر Story به 3 عامل بستگی دارد که هر یک از این 3 عامل هم به یکدیگر وابسته هستند :

Scope و Importance یک Story توسط Product Owner مشخص می شود . Estimate یک Story هم توسط تیم اسکرام تعیین می شود . در جلسه Sprint Planning با تغییر مثلا درجه اهمیت یک داستان شاید Estimate ای که تیم انجام داده بود تغییر پیدا کند که باید دوباره بررسی و تغییرات ثبت شود .

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

مشخص کردن طول Sprint

یکی از خروجی های Sprint Planning تعیین زمان ارائه دموی اسپرینت به PO می باشد . که همان اندازه و طول یک اسپرینت می شود .

طول مناسب برای یک اسپرینت چقدر می باشد ؟

بهترین طول , یک طول کوتاه می باشد که اگر اینگونه عمل کنید در واقع سنت حسنه Agile که اصل بر کوتاهی ارائه محصول به مشتری می باشد را به جا خواهید آورد . اسپرینت کوتاه = بازخورد سریع = تحویل فوری به صورت مکرر= جلوگیری از کج روی در مدت کوتاه = بهبود و پیش بری محصول سریع تر و … .

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

مشخص کردن هدف اسپرینت

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

هدفی که ما انتخاب می کنیم باید بتواند به سوال , “اسکرام مستر عزیز , چرا باید این اسپرینت را پیاده سازی بکنیم ؟” جواب دهد .

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

کدام Story در کدام اسپرینت باشد ؟یکی از مهمترین کارهایی که باید در طی Sprint Planning انجام بشود تعیین Story هایی است که باید در اسپرینت باشند . همان Story هایی که در Product Backlog قرار دارند . در واقع ما Story ها را از Product Backlog به Sprint Backlog کپی می نماییم .


به عکس بالا توجه نمایید . هر یک از مستطیل های یک Story می باشد که بر اساس اهمیت از بالا به پایین مرتب شده اند . اندازه آنها بر اساس برآوردی که انجام داده ایم تعیین شده است این بر آورد را ما براساس Story Point خواهیم گفت . مثلا Story1 را در نظر بگیرید , 3 روز با 4 نفر نیروی کار نیاز دارد , که سرجمع 12 می شود . 12 همان Story Point ما خواهد شد . مقدار قسمتی که با آکلولاد یا براکت مشخص شده نمایان گر برآورد Velocity (سرعت) تیم می باشد که تیم می تواند در طی یک اسپرینت 3 هفتگی چند Story Point را پیاده سازی نماید .

در واقع Sprint Backlog نمایی از Product Backlog می باشد . این شامل Story هایی می شود که باید در طول مدت اسپرینت پیاده سازی شوند .

تعیین اینکه کدام Story در کدام Sprint باشد بر عهده تیم اسکرام خواهد بود . ولی PO می تواند با افزایش Story Point ها نقشی موثری را در جابجایی و جایگیری Story ها در اسپرینت ها داشته باشد.

چگونه تیم اسکرام تصمیم میگیرد که کدام Story ها در اسپرینت قرار بگیرد ؟

ما برای اینکار 2 روش داریم :

1- بوسیله تجربه

2-بوسیله محاسبه Velocity


برآورد بوسیله تجربه

در این روش اسکرام مستر به اعضای تیم Story را معرفی می نماید و از اعضای تیم سوال میکند که آیا می توانیم در طول این اسپرینت این مورد را انجام بدهیم یا به زمان بیشتری نیاز دارد ؟ در صورت جواب مثبت آن مورد در Sprint Backlog قرار می گیرد و مورد بعدی .

این روش در تیم های کوچک با طول اسپرینت کوتاه موثر می باشد .

برآورد بوسیله Velocity

برای تشریح این مسئله مثالی را عرض می نمایم :

عکس بالا را مشاهده نمایید , هر یک از مستطیل ها یک Story و عدد های نوشته شده بر روی آنها Story Point هر یک می باشد .

زمان هر اسپرینت ما 3 هفته در نظر گرفتیم (18 روز کاری) بعلاوه اینکه ما در تیم خود 4 نفر داریم . علی 2 روز نمی تواند حضور داشته باشد , رضا فقط 50% می تواند همکاری نماید و بهمن و رامین 100% هستند .

خوب ما باید اینها را با هم جمع کنیم :

رامین 18

بهمن 18

علی 16

رضا 9

————–

61 Man-Days

خوب این عدد به چه دردی می خورد ؟ این یعنی اینکه ما در واقع به اندازه 61 Man-Days وقت خواهیم داشت .

برآورد Velocity اسپرینت :

(Man-Days ) * (ضریب توجه ) = Velocity

ضریب توجه , برآورد میزان توجه یک تیم بر روی کار می باشد . بهترین راه برای پیداکردن استفاده از تجربیات اسپرینت های قبلی می باشد . برای محاسبه ضریب توجه می توانید از فرمول زیر استفاده نمایید :

فرض کنید ما قبلا یک اسپرینت را تمام کرده بودیم , که تیم ما توانسته اند فقط 18 Story point انجام دهند . پس Actual Velocity ما برابر با 18 می شود . این تیم شامل 3 نفر بود که Man-Days هم برابر 45 بود . پس FF یا ضریب توجه ما در اسپرینت قبلی برابر با 40% بوده است .

پس از اینکه ضریب توجه را پیدا کردیم کافی است , آن را در Man-Days جاری ضرب کنیم که در مثال قبلی 61 * 40% = 24.4 Story point

این عدد یعنی اینکه تیم ما حدودا می تواند 24.4 Story Point را در این اسپرینت پیاده سازی نماید . البته همانطور که مشاهده نمودید ما از اطلاعات و آگاهی های اسپرینت های قبلی استفاده کردیم که اگر این اطلاعات اشتباه باشد , محاسبه ما هم نادرست خواهد بود و بعدا با مشکل مواجه خواهیم شد .

در مثال بالا ما فقط 18 story point داشتیم که می توانیم به راحتی در یک اسپرینت همه آنها را انجام دهیم .


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


استفاده از Index Card

Index Card یک کارت مخصوصی است که مشخصات یک Story بر روی آن نوشته شده است و به دیوار چسبانده شده است . همانطور که قبلا گفته شد, Product Backlog ما می تواند درون یک فایل Excel باشد و ما برای بحث باید از یک پروژکتور استفاده نماییم که دردسرهایی در این روش داریم . ما از Index Card استفاده میکنیم بدلیل اینکه :

  • اعضای تیم باید ایستاده به دور این کارت ها بحث نمایند که باعث جلوگیری از خواب افراد تیم توسعه و PO می شود .
  • همه اعضا احساس می کنند باید با کار درگیر شوند و نه فقط آقایی که کیبورد رافشار می دهد .
  • همزمان ویرایش انجام می شود , مثلا برآورد تغییر پیدا می کند .
  • بعد از اتمام Sprint Planning این Index Card ها در قسمت TaskBoard قرار می گیرد.

نمونه ای از یک Index Card :

شکست Story به Task

بعد از ایجاد Index Card نوبت این است که ما آن Story را به وظیفه و یا یک فعالیت بشکنیم . برای مثال Deposit را در نظر بگیرید , این Story را می توان به Task های زیر شکست :

DB Design – Write Failing Test – DAO – Integrate Test ,…


توجه داشته باشید که بعضا می شود یک Story را به چندین Story کوچکتر شکست داد , البته این در Story هایی صدق می کند که بزرگ می باشند . البته نباید این شکستن تاحدی باشد که این Story در یک واحد زمانی قرار نگیرد , مثلا طوری شود که بتوان آن را در 30 دقیقه انجام داد , خوب این مورد را نمی توان در هیچ برآوردی شرکت داد و بهتر است Story را در این حالت شکست داده نشود.


بعد ار شکست دادن هر Task را به صورت یادداشت کوچک در زیر Index Card خود نصب می نماییم . و در واقع این وظایفی است که برنامه نویس ها باید پیاده سازی نمایند .



تعریفی از Done برای خود داشته باشید

منظور از Done تکمیل یک Task می باشد . حالا شما به چه چیزی می گویید تکمیل , باید این را روشن کنید و به اعضای تیم ابلاغ نمایید . آیا فقط کدنویسی Done می باشد ؟ آیا مواردی که Acceptance Test شده اند Done می باشند ؟

اگر Done مشخص نباشد , هر کس تا اندازه ای کار خواهد کرد و مهر Done بروی Task خواهد زد و بعدا خواهید دید که ای بابا این مورد که هنوز تست هم نشده است .

تعیین زمان جلسات روزانه اسکرام

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


در شروع هر روز کاری در گروه های تولید نرم افزار به سبک اسکرام جلساتی را به مدت 10 تا 15 دقیقه به صورت ایستاده برگزار می کنند که این جلسات به Stand up meeting مشهور می باشد. در این جلسه کوتاه 3 سوال اصلی مطرح می شود :

1- دیروز چه کار انجام داده ام ؟

2- امروز چه کاری می خواهم انجام بدهم ؟

3- مشکلاتی که در سر راه دارم چه چیزهایی هستند ؟

اتمام Sprint Planning

در صورتی که بتوانید این مرحله را به درستی به اتمام برسانید به موفقیت بزرگی نائل شده اید زیراکه Sprint Planning مهم ترین و در واقع هسته مرکزی اسکرام به حساب می آید و اگر درست انجام نشود همان مثل تا سریا دیوار کج خواهد شد .

تنها کاری که الان ما نیاز داریم آن را انجام بدهیم این است که صفحه Sprint info را درست نماییم و در معرض دید تیم خودمان و تیم های دیگر قرار بدهیم .


نمونه ای از Sprint info page

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

چگونه به Sprint Backlog عمل نماییم ؟

خوب الان ما در جلسه Sprint Planning توانستیم Spring Backlog را بسازیم و حالا می خواهیم عملیات اجرایی را شروع نماییم . حالا شما می پرسید از کجا شروع کنیم ؟ که سوال بسیار به جا و خوبی می باشد .

Task Board خود را بسازیم

ما ابتدا نیاز داریم که برای تیم یک Task Board بسازیم که این برد معمولا بر روی یک دیوار قرار دارد . یک دیوار حدودا 2*2 پیدا کنید که خالی باشد . فرمت هایی گوناگونی برای یک Task Board وجود دارد که من ساده ترین آنها را شرح می دهم . شکل زیر نمایی از یک Task Board می باشد :

در این فرمت ما 3 ستون داریم . ستون اول همان Index Card ها و Task های مربوطه می باشد. ستون دوم قسمت وظیفه هایی می باشد که الان در دست کار می باشد , یعنی یک از اعضای تیم روی آن کار می کند . بعد از اتمام این Task , این Task به قسمت Done منتقل خواهد شد .


البته این انتقالات در هنگام جلسات روزانه خواهد بود . فرضا علی می گوید که من امروز میخواهم Task1 را کار کنم پس این Task را در قسمت Check out قرار می دهد و او می گوید من دیروز Task2 را تمام کردم پس او این Task را در قسمت Done قرار می دهد.


نمونه از Task Board بعد از چند روز :


BurnDown Chart

این چارت نمودار پیشرفت محصول را به صورت شمارش معکوس نشان می دهد . به نمونه از BurnDown Char دقت نمایید :



محور Y این چارت نشان دهنده Story Point باقی مانده است و محور X روزهای اسپرینت را نشان می دهد . در این مثال در روز 1 ما محاسبه کردیم که 70 Story Point باقی مانده است پس خط از آنجا کشیده شده است . در روز 16 هم محاسبه کردیم دیدیم 15 Story Point پس خط به آنجا کشیده شد است .

اساس کار این است که این چارت هم در کنار Task Board نصب می شود و در هروز نسب به کارهایی که انجام شده است , همانقدر Story point کم شده است نمودار به سمت پایین کشیده می شود .

یک خط چین از Story point 70 به روز 20 کشیده شده است , این در مواقع نرمال ترین حالت نمودار شما در آخر باید باشد .

حالت ها نمودار شما :

1- نمودار شما از خط مطلوب بالاتر حرکت کند , همان مثل این ره به کردستان است و زود باید یک بازنگری در Story های Sprint Backlog داشته باشید و به احتمال زیاد باید تعدادی از Story ها را از این Sprint خارج نمایید . احتمالا برآورد زمانی و سرعت اشتباه کرده اید .

2- نمودار شما از خط مطلوب پایین تر حرکت کند , در این حالت هم می توانید تعدادی Story جدید به این Sprint اضافه نمایید .

این روند ادامه پیدا خواهد کرد تا زمانی که اسپرینت تکمیل و دموی اسپرینت به PO تحویل داده شود . و بعد شروع اسپرینت بعدی … .

یاشیاسیز

درباره اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

41 دیدگاه در “اسکرام ساده شده

  1. سلام.
    واقعا خسته نباشید.از معدود مقالاتی بود که می خونم و در آخرش تمام نکات رو متوجه میشم.
    معمولا نویسنده های این جور مقالات به توضیحات رو خیلی کلی میگن ولی شما خیلی رون و ساده توضیح دادید…
    بازم خسته نباشید.

  2. سلام
    می خواستم بپرسم می تونیم هنگام محاسبه stroypoint به جای روز ، ساعت در نظر بگیریم؟ یعنی برای مثال 10 ساعت، ضرب در 3 نفر مساوی با 30 stroypoint

    ممنون از دنیای چابک

  3. سلام می خواستم بپرسم می تونیم هنگام محاسبه stroypoint به جای روز ، ساعت در نظر بگیریم؟ یعنی برای مثال 10 ساعت، ضرب در 3 نفر مساوی با 30 stroypoint

    ممنون از دنیای چابک

    1. نه اگر ساعت رو ضربدر تعداد نفر کنیم دیگه از حالت Story Point خارج می شود. البته روی این قضیه خیلی بحث شده است و می تونید به مراجع رو اینترنت مراجعه کنید . به نظر من شما می توانید واحد ساعت رو تبدیل به Story Point کنید تا معادلتون درست در بیاد . بدین صورت که : اگر 1 نفر یک Story را در طول یک روز انجام بدهد و هر روز کاری ما 10 ساعت باشد پس می توان نتیجه گرفت هر Story Point برابر با 10 ساعت می باشد . پس شما هر 10 ساعت را می توانید به عنوان یک Story Point در نظر بگیرید.

      البته توجه داشته باشید این برای یک نفر بود اگر شما دو نفر برروی یک Story کار بکنند مثلا 10 ساعت توجه داشته باشید که این همان 10 ساعت نیست بلکه 10+10 است که می شود 20 ساعت که این برابر با 2 Story Point می باشد .

      موفق باشید

    2. در یک کتاب در مورد اسکرام که چندی پیش مطالعه میکردم یک فرمول ارائه کرده بود که هر یک Man-day برابر با 7 Man-hour است .

  4. سلام
    مرسی از مقاله بسیار عالیتون خیلی خیلی مفید بود.
    میخواستم بدونم کدوم نرم افزار رو برای مدیریت پروژه(محصول) توصیه میکنید؟ ترجیحا OpenSource و با SVN سازگار باشه
    یاشاسین

    1. من JIRA رو پیشنهاد میدم این رو میدونم که می تونه با انواع source Control ها کار بکند ولی فکر نکنم اوپن سورس باشد .

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

    1. بهتر بود با دقت تر مطالعه می فرمودید :

      گفتم محصول نه پروژه !

      اسکرام محصول محور است نه پروژه محور و تمام تلاشش برای تکمیل یک محصول است ولی ممکن است در یک پروژه چندین محصول باشد.

  6. سلام
    یه سوال: اگه در یک sprint مثلا ۱۰ story انتخاب شد ولی مثلا علی که یکی از اعضای تیم هست در اواسط sprint کارش تموم شد، باید چی کار کنه؟ ۱- بره مرخصی؟ ۲- storyجدیدی وارد بشه (که این کار در اواسط sprint به نظر نا معقول میرسه) ۳- بره کمک بقیه اعضای تیم؟؟؟؟

    یه سوال دیگه اگه همچین اتفاقی بیافته، ضریب توجه در محاسبات بعدی بالای صددرصد میشه که یه مقدار نامعقول به نظر میرسه مثلا اگه تیم ۶۰ ساعت وقت دارند ما میگیم تیم ۷۰ ساعت وقت داره!؟ که البته اگر تصور کنیم تخمین‌ها اشتباه بوده مشکلی پیش نمیآد!!!

    1. حمید رضا :

      سلام
      یه سوال: اگه در یک sprint مثلا ۱۰ story انتخاب شد ولی مثلا علی که یکی از اعضای تیم هست در اواسط sprint کارش تموم شد، باید چی کار کنه؟ ۱- بره مرخصی؟ ۲- storyجدیدی وارد بشه (که این کار در اواسط sprint به نظر نا معقول میرسه) ۳- بره کمک بقیه اعضای تیم؟؟؟؟

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

      حالت ها نمودار برن داوون شما :

      1- نمودار شما از خط مطلوب بالاتر حرکت کند , همان مثل این ره به کردستان است و زود باید یک بازنگری در Story های Sprint Backlog داشته باشید و به احتمال زیاد باید تعدادی از Story ها را از این Sprint خارج نمایید . احتمالا برآورد زمانی و سرعت اشتباه کرده اید .

      2- نمودار شما از خط مطلوب پایین تر حرکت کند , در این حالت هم می توانید تعدادی Story جدید به این Sprint اضافه نمایید .

      مورد شما همان مورد 2 است .

      حمید رضا :

      یه سوال دیگه اگه همچین اتفاقی بیافته، ضریب توجه در محاسبات بعدی بالای صددرصد میشه که یه مقدار نامعقول به نظر میرسه مثلا اگه تیم ۶۰ ساعت وقت دارند ما میگیم تیم ۷۰ ساعت وقت داره!؟ که البته اگر تصور کنیم تخمین‌ها اشتباه بوده مشکلی پیش نمیآد!!!

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

      در اسکرام نترسید . در هر کجا که متوجه شدید در حال کج روی هستید یک جلسه بگذارید (با عنوان مرور عمکرد) و عملکرد خود را بررسی و اصلاح نمایید .

      موفق باشید

  7. سلام
    دو سوال داشتم:‌
    ۱- آنالیز و تحلیل پروژه در کدام قسمت از scrum انجام میشود؟ آیا به عنوان یکی از task های هر sprint، قسمت آنالیز و تحلیل پروژه انجام میشود؟ یا قبل از sprint این کار انجام میشود؟
    ۲- برای مستند سازی بحث زیاد مطرح نیست! مستند سازی نیازمندی ها را میتوان در انباره محصول و … دید ولی مستند تحلیل و … کجا قرار دارند و به چه نحوی هستند؟

    1. 1 – با عرض پوزش نمی توانم کاربری وبلاگ را به فروم تغییر دهم .
      2- کتاب اسکرام و اکس پی ساده شده را خدمت حضرت عالی معرفی می کنم و اعتقاد دارم به خیلی از سوالات شما جواب خواهد داد.

      موفق باشید

  8. سلام مطلب بسیار خوبی بود،فقط دو تا نکته، اول اینکه املای کلمه ی ثریا به اشتباه سریا نوشته شده و دوم اینکه ره به ترکستان درسته نه ره به کردستان،خیلی ممنون.

  9. سلام وقتتون بخیر،

    در خصوص ابزار اسکرام من وب سایت http://www.manday.ir رو دیدم،

    اگر کسی از این سایت استفاده کرده ممنون میشم که به من راهنمایی بدید که آیا جوابگوی نیاز یک تیم 5 نفره هست یا خیر.

    ممنونم.

دیدگاهتان را بنویسید

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

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.