بایگانی

Posts Tagged ‘Agile’

Release Plan

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

«طرح ها چیزی نیستند، طرح ریزی ها همه چیز هستند»، گفته دوایت آیزن هاور. این بینش کاملا مناسب طرح ارائه یا همان Release Plan خودمان می باشد. هر چند در اسکرام تیم ها مجبور نیستند که طرح ارائه داشته باشند، ولی آنها مجبورند که ارائه را طرح ریزی بکنند. در پروژه های بزرگ اسکرام، یا آنهایی که مجبور هستند با پروژه های دیگر، شرکاء یا تامین کنندگان هماهنگ باشند معمولا از یک طرح رسمی استفاده می کنند.

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

رییلیز پلن بر پایه چهار المان می باشد: آیتم های بک لاگ محصول، مقدار کار باقی مانده در بک لاگ، سرعت و زمان.

طرح ارائه را نمی توان ثابت در نظر گرفت. این طرح با تکامل و درک کارهای لازم و بهبود سرعت تغییر می کند. جلسه بازبینی اسپرینت یا همان Sprint Review بهترین زمان برای ایجاد و آپدیت تعاملی طرح ارائه می باشد.

برای بدست آوردن بیشتر این طرح، معمولا من تمایل دارم قابلیت های موجود در هر ارائه را به صورت Theme یا اپیک نشان دهم.  نشان دادن داستان ها در طرح ارائه، ما را به سمت جزئی تر کردن آنها درسوق خواهد داد. آوردن هر اطلاعاتی برای هماهنگ شدن با دیگران در طرح ارائه می تواند مفید باشد و می توان تغییرات شناخته شده ای که بر روی سرعت تاثیر می گذارند را نیز ذکر کرد، مانند تغییر در ترکیب تیم ها یا سازمان پروژه. جدول زیر نشان دهنده یک طرح ارائه نمونه می باشد:

طرح ارائه نمونه برای یک محصول ارتباطاتی
اسپرینت 1 2 3 4 5 6 7 8
پیش بینی سرعت 12 – 32 18 – 28 21 – 28 11 – 18 16 – 23 21 – 28 21 – 28
سرعت واقعی 20 25 28
وابستگی ها Imaging library
ارائه ها آلفا : تماس ها، پیام کوتاه پایه تعطیلات بتا : کنفرانس تلفنی ، تماس های تصویری نسخه 1.0
اسپرینت جاری

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

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

پیش بینی سرعت یا Velocity

برای پیش بینی سرعت، گام های زیر را دنبال می کنیم: اگر یک محصول جدید در حال توسعه می باشد، اگر تیم هرگز باهم کار نکرده اند یا ترکیب تیم به طور محسوسی تغییر کرده است، سرعت را معمولا بعد از انجام حداقل یک اسپرینت ( دو یا سه اسپرینت ترجیحا) ملاحظه می کنیم. معمولا دو یا سه اسپرینت طول می کشد تا سرعت تیم پایدار شود. با استفاده از رنج سرعت اسپرینت های گذرانده شده، سرعت اسپرینت های باقی مانده را حدس می زنیم. در طرح ارائه جدول بالا ، دلیل اینکه محدوده اسپرینت چهارم 20 تا 28 شده است این است که میانگین امتیازهای بدست آمده 24 بوده است.

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

ضرایب سرعت بر اساس تعداد اسپرینت تکمیل شده
اسپرینت های تکمیل شده ضریب پایین ضریب بالا
1 0.6 1.60
2 0.8 1.25
3 0.85 1.15
4 یا بیشتر 0.9 1.10
از کتاب برآورد و طرح ریزی چابک مایک کان

برای بدست آوردن سرعت، میانگین بدست آمده از سه اسپرینت اول ، در مثال ما همان 24 را با ضرایب پایین و بالای مناسب و اشاره شده در جدول بالا ضرب می کنیم. نتیجه حد سرعت 21 – 28 می باشد.

بعد از اینکه تیم چهار یا پنج اسپرینت را انجام داد، می توانیم پیش بینی های قابل اعتماد تری را داشته باشیم.  فرض کنید در اسپرینت آخر یا همان اسپرینت 8 طرح ارائه جدول اول هستیم و اکنون می خواهیم سرعت تیم در ارائه بعدی را پیش بینی کنیم. سرعت اسپرینت های تکمیل شده به این صورت می باشد: 20 – 25 – 28 – 26 – 16 – 20 – 26 – 26. اکنون هر داده ای مربوط به اسپرینت های غیر معمول را به دور می اندازیم، مانند اسپرینتی که کل اعضای تیم مریض شده بودند یا برای چند روز مشغول نصب سرور یکپارچه ساز بودند. سپس ما لیست را به صورتی صعودی مرتب می کنیم : 16 – 20 – 20 – 25 – 26 – 26 – 26 – 28. سپس ما با استفاده از جدول زیر می توانیم برای اسپرینت های بعدی پیش بینی با صحت 90% داشته باشیم.

استفاده از تعدادی از سرعت های اسپرینت قبلی برای پیش بینی آینده با صحت 90%
سرعت های شمرده شده چندمین سرعت شمرده شده
5 1
8 2
11 3
13 4
16 5
18 6
21 7
23 8
26 9
ذکر شده از کتاب موفقیت با چابک : توسعه نرم افزار با استفاده از اسکرام

بدلیل اینکه فقط 8 اسپرینت را اجرا کردیم، دومین سرعت را در لیست مرتب کرده مان انتخاب می کنیم. این به ما نشان می دهد در رنج 20 – 26 سرعت متوسط مان 23 خواهد بود. با این جدول می توانیم مطمئن شویم که 90 درصد سرعت واقعی برابر با رنج پیش بینی شده خواهد بود.

ایجاد طرح ارائه

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

به جدول طرح ارائه یا همان جدول اول بنگرید. این جدول سرعت واقعی سه اسپرینت را 20 – 25 و 28 مشخص کرده است. پس سرعت میانگین به ازای اسپرینت 24 می باشد.  تیم اسکرام برای اسپرینت چهارم با توجه به جدول دوم حدود سرعت را 21 تا 28 امتیاز پیش بینی می کند. طرح ارائه همچنین برای اسپرینت های پنجم و ششم افت سرعت را پیش بینی می کند، جایی که برخی از اعضای تیم به مرخصی خواهند رفت.

ابزار مورد علاقه برای ثبت طرح ارائه یک وایت برد در اتاق تیم می باشد. وایت بردهایی که چرخ دارند و می توان آن ها را به راحتی به اتاق های دیگر نیز حرکت داد. مسلما می توان طرح ارائه را در ابزار الکترونیک نیز نگه داری کرد. گذشته از هر ابزاری، به خاطر داشته باشید این طرح باید شفاف و با تعامل تیم اسکرام و ذی نفعان ایجاد شود.

این مطلب از کتاب جدیدم مدیریت محصولات چابک آورده شده است که به زودی منتشر خواهد شد.
چابک و موفق باشید
دسته‌ها:Agile, Scrum برچسب‌ها: , , ,

اولویت بندی نیازمندی های مشتری

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

اما چرا اولویت بندی مهم است و چرا اساسا باید چنین کاری انجام داد؟

در پروژه ای که از روش کانبان بهره گرفته بودیم، لیستی از نیازمندی های محصول را در آورده بودیم ولی این لیست نیازمندی ها دو ایراد اساسی داشت : 1- اولویت بندی نشده بود 2- کاملا تشریح شده بود

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

قضیه اساسی و مشکل اینجا بود که این نیازمندی ها اساسا لازم نبودند، یعنی ارائه هم نمی شد چیزی از این جهان هستی کم و زیاد نمی شد.اما مسئله اینجاست که مشتری ما عادت دارد وقتی قرار داد می بندیم همه چیز بخواهد ، «این رو هم میخام، این هم باشه، تون رو هم اونجا دیدم خوبه و … «. ما هم معمولا برای از دست ندادن مشتری از دیالوگ «عیب نداره، می سازمیت برات» استفاده می کنیم. اما آیا واقعا چقدر یا چه میزانی از این ویژگی ها مورد استفاده قرار می گیرد؟

تحقیقات جهانی Standish Group نشان داد که تنها و تنها 20% قابلیت های محصول ما توسط مشتری معمولا استفاده می شه و 64% اون هرگز یا بندرت استفاده می شود.

features.jpg (529×256)

این آمار برای آن پروژه ما زنگ خطری بود چرا که :

  • زمانیکه فقط 20% ویژگی ها استفاده می شوند و ارزش آفرین هستند، چرا ما اولویت بندی نکردیم تا بیشتر بر روی این 20% متمرکز شویم؟
  • ما لیست کلی از کارهای کل پروژه به صورت تشریح شده داشتیم، ولی چرا باید همه آنها تشریح شده باشند؟ آیا امکان ندارد آنها با جلو رفتن تغییر کنند؟ پس مقدار زمان و هزینه ای که در اول پروژه برای تشریح آنها صرف کرده ایم احتمالا تلف خواهد شد.

در بیانیه چابک اصلی داریم با عنوان سادگی که متن آن بدین گونه است :

سادگی — هنر به حداکثر رساندن مقدار کار انجام نشده — ضروری است

و مشتری ها معمولا دو خصیصه اساسی دارند، اولا همه چیز می خواهند ، ثانیا همه چیز برای آنها با اولویت می باشد.

اما ما به عنوان تیم چابک هم باید هنر مند باشیم تا بتوانیم اولا با اصل سادگی مقدار کاری که نباید انجام شود را به حداکثر برسانیم ، ثانیا بتوانیم اولویت بندی مناسبی بر اساس معیارهای کسب و کار داشته باشیم.

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

چابک و موفق باشید.

تحول چابک

DigitalTransition_LandingPage_Hero.png (317×356)نزدیک عید هستیم و صحبت ها بیشتر مبنی بر آغاز سال جدید و لزوم تغییرات است ، تغییراتی که همیشه از سال جدید آغاز خواهند شد و من هم لازم دیدم حتما مطلبی در این رابطه داشته باشم.

تحول چیست ؟

تحول یعنی گذر از حالتی و آغاز حالتی دیگر.

قبل از اینکه توضیح بیشتری در این رابطه داشته باشم از کتاب «مکتوب» پائولو کوئلیو مطلبی را نقل قول می کنم :

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

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

مرد جوان طبق دستور عمل کرد. هنگام بازگشت سگ ها و بازهای گرسنه آن تکه گوشت ، به او حمله کردند.

به پدر روحانی گفت : من برگشتم ! و بدن زخمی و لباس های پاره پاره اش را نشان داد.

قدیس گفت : آنانی که به راه نوینی گام می گذارند و می خواهند اندکی از زندگی پیشین خود را نگه دارند ، سرانجام مجروح گذشته خود خواهند شد.

بلی ، آنانی که به راه نوینی گام می گذارند و می خواهند اندکی از زندگی پیشین خود را نگه دارند ، سرانجام مجروح گذشته خود خواهند شد. این داستان اشاره خوبی به موضوع بحث ما یعنی همان تحول دارد . یعنی قهرمان داستان ما می خواهد متحول شود (از حالتی به حالت نوینی گذر کند) ولی موفق نیست زیرا گذشته خود را به همراه دارد.

تحول شامل سه مرحله می باشد : پایان ، منطقه خنثی یا برزخ و شروع جدید.

هر تحول که در انگلیسی به Transition معروف است ، با یک پایان شروع می شود. بلی ، درست شنیدید ، هر آغاز تحول همراه با پایان چیزی خواهد بود. باید با عادتی که می خواهید آن را تغییر دهید خداحافظی کنید ، یعنی هر وقت که گفتید «کد کثیف ، بای بای » تحول شما شروع شده است .

این مرحله از تحول بدلیل ترک عادت ها باعث خشم و ترس خواهد بود ، ولی باید برای شروع تحول به آن عادت یا روش خاتمه دهید.

مرحله دوم که خود به خود با پایان چیزی شروع و تا پایان تحول ادامه پیدامی کند ، منطقه خنثی یا برزخ تحول می باشد. زمانیکه شما با «نوشتن کد کثیف» خداحافظی کردید ، آیا «کد تمیز» نوشتید؟ این حالت که نه در حالت قبلی و نه در حالت جدید هستیم را منطقه برزخ تحول گفته می شود. این مرحله از تحول سخترین مرحله تحول می باشد و اگر مدیریت تحول نشود ، امکان برگشت به نقطه قبلی و شروع عادت ها و روش ها قبلی خواهد بود.

اما این مرحله سخت و همراه با شک و تردید را می توان با شروع روش ها و عادت های جدید به لبه ساحل اطمینان و آرامش رساند. که این همانا مرحله سوم تحول خواهد بود.

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

اما این چه ربطی به دنیای چابک داشت؟

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

به امید تحولات چابک

یاشیاسیز

کانبان ساده شده

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

کانبان همانند اسکرام یکی از متدهای توسعه چابک می باشد که در این متد توجه بیشتر بر روی ارائه های درجا (just-in-time) و بصری سازی فرآیند توسعه می باشد. کانبان ذاتا از متد تفکری Lean گرفته شده است و بیشتر صنعت گران (بدلیل آشنایی مانند تولید ناب و تویوتا وی) با کانبان آشنا هستند.

کانبان یک متد مدیریتی بصری (Visualize) است که می گوید چه چیزی تولید کنید ، چه زمانی تولید کنید ، چه قدر تولید کنید (بر اساس ذات ناب ، اساس آن بر تولید ناب و ارزش گرا و پرهیز از تولید تلف شده می باشد)

کانبان در اختصار

کانبان فقط شامل یک تابلو (Board) می باشد که کارهای در جریان روی آن تابلو قرار می گیرد. این تابلو توسط ستون هایی که هر ستون نشان دهنده وضعیت کاری (مثلا در حال توسعه یا در حال تست و یا …) به چندین قسمت تقسیم شده است. کارهای موجود در ستون های مختلف این تابلو سیر می نمایند تا به آخرین ستون برسند .

1.jpg (407×203)نکاتی در رابطه با کانبان

  • برای هر ستون محدودیتی در نظر گرفته می شود که فقط این تعداد کار در هر زمان می تواند در داخل این ستون قرار داشته باشد.  این محدودیت را اصلاحا محدودیت WIP یا Work-in-progress بیان می شود.
  • کانبان یک سیستم کششی می باشد . یعنی اگر تیم تست کاری برای انجام دادن در ستون خود نداشت ، مقدار کاری را (نسبت به محدودیت) از ستون قبلی خود به ستون خود می کشد (پس تیم توسعه حق ندارد کار انجامم شده خود را به ستون تیم توسعه هل بدهد ، برای اینکه آیتم های تکمیل شده هم در این ستون تجمیع نشود از ستون هایی با عنوان صف یا بافر استفاده می شود)
  • تابلوهای مختلفی می توان برای کانبان ایجاد کرد که بهترین تابلو فقط از طریق تجربه به دست خواهد آمد.
  • در کانبان کارها به صورت اسپرینتی نیست که آخر هر اسپرینت ارائه ای انجام شود ، در کانبان هر وقت که لازم شد و یا طبق برنامه ریزی خاصی می توان ارائه داشت و جلساتی مانند بازبینی و بازنگری را انجام داد.
  • نقش ها در کانبان تجویز شده نیستند ولی می توان از نقش های اسکرام (مالک محصول / اسکرام مستر / تیم ) استفاده کرد.
  • کانبان در فاز نگه داری سیستم بسیار خوب عمل می کند.
  • یک تابلوی کانبان بین همه تیم ها و اشخاص مشترک می باشد و نیازی به تابلوهای جداگانه نیست.

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

یاشیاسیز

دسته‌ها:Agile, Kanban, Lean برچسب‌ها: , , ,

پروژه های چابک سه برابر موفق تر از پروژه های غیر چابک

فوریه 18, 2012 بیان دیدگاه

مایک کان در وبلاگ خویش آمارجالب و جدیدی در مورد پروژه های چابک یا Agile  درج کرده است که ذکرآن در اینجا خالی از لطف نیست.

طبق آخرین تحقیقات و آمار ارائه شده از طرف Standish Group در سال 2012 ، میزان موفقیت پروژه های مبتنی بر تفکر چابک سه برابر بیشتر از پروژه های غیرچابک بوده است .

Agile and waterfall success and failure rates

البته آمار دقیق پروژه هایی که بر روی آن تحقیق انجام شده است دقیقا معلوم نیست ولی این پروژه ها از 2002 تا 2010 انجام شده اند.

یاشیاسیز

گرومینگ بک لاگ محصول

فوریه 15, 2012 بیان دیدگاه

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

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

برای مثال فرض کنید می خواهید به آپارتمان جدید خود نقل مکان نمایید و برای اسباب کشی از چند نفر از دوستان خود خواهش کرده اید 1-2 ساعت به شما کمک نمایند تا اسباب کشی کنید. حالا فرض کنید که اسباب شما (مانند شکل زیر ) به هم ریخته و بسته بندی نشده باشند. آیا فکر می کنید این چند نفر (حتی اگر 10 نفر باشند) در 1-2 ساعت می توانند خواسته شما را برآورده نمایند؟

messy_desk_contest_winner.jpg (480×640)

چرا ؟ به این دلیل که تنها نفری که ارزش وسایل و اسباب موجود را می داند فقط شما هستید. تنها شما می دانید که چه وسایلی باید دور ریخته شوند ، چه وسایلی با ارزشتر هستند و کدام ها باید مطمئن تر بسته بندی شوند و … . چند نفر در این پروسه می توانند به شما کمک نمایند؟ مسلما همه این 10 نفر نخواهند بود و تعدادی از آنها دست به کمر نظاره گر خواهند بود.

پس اینگونه به نظر می رسد که بهتر بود قبل از اینکه دوستان خود را خبرکنید وسایل را بر اساس ارزش های خود آماده انتقال می کردید (چه خوب است که همیشه آماده انتقال باشیم) وپس از آن از دوستان خود یاری می طلبیدید.

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

این آراستگی می تواند شامل شکستن داستان های بزرگ یا Epic  به داستان های کوچکتر ، برآورد کردن داستان ها ، مشخص کردن ضوابط و تست پذیرش هر داستان و موارد دیگر باشد. به عبارت ساده تر بعد از چند اسپرینت می توان دریافت که ناآراستگی های درون و مانع بک لاگ محصول چه چیزهایی می باشند و آن ها را طی جلسه گرومینگ برطرف کرد تا همیشه بک لاگ آراسته و تمیزی داشته باشیم.

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

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

یاشیاسیز

دسته‌ها:Agile, Scrum برچسب‌ها: , , ,

راهنمای مطلق اسکرام

دسامبر 21, 2011 بیان دیدگاه

scrumGuide

اسکرام : یک چارچوب می باشد که نفرات در عین بازدهی و خلاقیت با ارائه محصولات با ارزش حداکثری ، مسائل پیچیده خود را آدرس دهی می نمایند.

اسکرام :

  • سبک وزن می باشد
  • ساده برای یادگیری می باشد
  • مسلط شدن به آن بسیار مشکل می باشد

اسکرام یک چارچوب مدیریت توسعه محصولات پیچیده می باشد که از اوایل 1990 به کارگرفته شده است. اسکرام یک فرآیند و یا تکنیک برای ساخت محصول نمی باشد. در عوض ، اسکرام چارچوبی است که می توانید در آن از تکنیک ها و فرآیندهای وسیعی استفاده نمایید. اسکرام به طور واضحی میزان سودمندی روش توسعه و مدیریت محصول شما را شفاف می سازد که می توانید آن را بهبود ببخشید.

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

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

پس پیشنهاد من این است اسکرام را با همین مستند دربیابید ، سپس هر گونه که دریافتید و خواستید اجرا نمایید .

اما این راهنما مدت ها بود در زبان های مختلفی در دسترس بود و جای زبان فارسی خالی بود ، که ما (من به همراه بچه های انجمن چابک ایران ) اقدام به ترجمه و ارائه آن در سایت Scrum.org  کردیم که امیدواریم مفید فایده قرار بگیرد.

دریافت راهنمای اسکرام به زبان فارسی

یاشیاسیز

دسته‌ها:Agile, Scrum برچسب‌ها: , ,