از زمان ارائه چارچوب اسکرام ، در مورد نحوه نوشتن ، زمان و جزئیات PBI ها ( آیتم های بک لاگ محصول ) و User Storyها ( داستان های کاربر ) نظرات و دیدگاه های متنوعی مطرح شده است.
آیا باید قبل از اولین اسپرینت، بخشی از بک لاگ محصول و داستان های کاربران را بنویسیم؟ برخی از افراد معتقد هستند که هیچ کاری نباید قبل از اسپرینت انجام شود. که به وضوح غیر قابل دفاع است. برای اینکه بفهمیم چرا، نیازمند این خواهیم بود تا به جزئیات بیشتری بپردازیم : اگر قبل از شروع کاری نمی دانیم چه چیزی می خواهیم تولید و ارائه کنیم ، در جلسه برنامه‌ریزی اسپرینت حاضر خواهیم شد و زمانی را باید صرف ارائه نظرات اختصاص دهیم و در عمل اصطلاحا واژه پردازی خواهیم داشت و این موجب می شود چند روز اول هر اسپرینت صرف تحلیل و تعاریف گردد.
لذا با رد این مورد که هیچ کاری نباید از قبل انجام شود، ما باید این سؤال را در نظر بگیریم که چقدر کار باید از قبل انجام شود؟ بسیاری معتقد هستند که تا حد امکان باید موارد کاری خلاصه نوشته شوند و تیم نباید بیشتر از نوشتن چند کلمه از یک داستان کاربر بر روی یک کارت برای نشان دادن هر PBI انجام دهد. ممکن است در بسیاری از موارد درست باشد، اما به وضوح کافی نخواهد بود.
به نظر من ، هر PBI باید دقیقاً به موقع و با جزئیات کافی ثبت شود تا تیم بتواند هر آیتم را در طول اسپرینت توسعه و تست نماید. برای اینکه بدانیم چطور “زمان مناسب و جزئیات کافی ” می تواند تیم را به هدف اصلی خود و ارائه Increment ( فرآورده ) در هر اسپرینت برساند مثال زیر را در نظر بگیرید :
فرض کنید در حال طراحی یک Device هستیم و قصد داریم یک بک لاگ اولیه محصول ایجاد نماییم که شامل دو داستان کاربر زیر باشد :
- به‌عنوان یک کاربر، بتوانم وارد صفحه « درباره محصول » شوم تا اطلاعات مفید و مدل و سال ساخت دستگاه را مشاهده نمایم.
- به عنوان یک کاربر بتوانم وارد صفحه WIFI شوم و تنظیمات و نحوه اتصال به شبکه های مختلف را انجام دهم.
داستان اول می تواند با همان توضیحات کوتاه به راحتی در یک اسپرینت پیاده سازی شود. بدین صورت که تحلیلگر زمان خواهد داشت تا متوجه شود دقیقا خواسته چه می باشد. طراح تجربه کاربر ( UXD ) زمان خواهد داشت تا دو یا سه صفحه نمایش را شبیه سازی کند، آنها را به برخی از کاربران نشان دهد، بازخورد دریافت کند و بهترین صفحه نمایش “درباره دستگاه” را ایجاد کند. و برنامه نویسان زمان برای کدنویسی و آزمایش کنندگان برای آزمایش آن خواهند داشت. به طور خلاصه می توان گفت جزئیات جهت معیار پذیرش کافی می باشد.
داستان کاربر دوم، ” به عنوان یک کاربر بتوانم وارد صفحه WIFI شوم و تنظیمات و نحوه اتصال به شبکه های مختلف را انجام دهم “برای انجام در یک اسپرینت بسیار حجیم و بزرگ خواهد بود و ممکن است موارد زیر اصطلاحا گنگ و یا ناشفاف باشند :
- کلیه موارد و شرایط UI را شامل می شود.
- آیا امکان برقراری ارتباط با Access Point در لیست WIFI صورت پذیرد؟
- آیا نیاز به افزودن قابلیت نمایش قدرت سیگنال Access Point ها وجود دارد؟
- آیا نیاز است لیست WIFI های ذخیره شده نمایش داده شود و امکان Forget نمودن شبکه وجود داشته باشد؟
- آیا نیاز است آخرین وضعیت WIFI ذخیره و پس از راه اندازی مجدد دستگاه اعمال گردد؟
هیچ راهی وجود ندارد که UXD ها بتوانند همه موارد فوق را در یک اسپرینت مثلا دو هفته ای بفهمند. این داستان کاربر به اندازه کافی با جزئیات توضیح داده نشده است. این همان قسمتی است که ویژگی دوم مورد اشاره این مقاله ( به اندازه کافی یا جزئیات مناسب ) نمود پیدا می کند .
از سوی دیگر جزئیات باید به موقع و در زمان مناسب به این داستان کاربر یا PBI اضافه شود. شاید در ابتدای پروژه مورد یا فیچری تعریف گردیده باشد و ذینفعان و مالک محصول در مورد آن اتفاق نظر داشته اند ، باید این PBI خلاصه ای از اجرا یا تعریفی در بک لاگ محصول داشته باشد اما اگر تیم به مدت شش ماه روی این داستان کاربر کار نکند، نیازی به گسترش یا تشریح جزئیات آنچه قبلاً نوشته شده است نیست. از سوی دیگر، اگر تیم امیدوار است که آن را در چند اسپرینت آینده ممکن است شروع کند، احتمالاً زمان آن فرا رسیده است که UXDs پاسخ سوالات فهرست شده در بالا را بیابند.
برای انجام این کار، آنها باید زمانی را برای «پیدا کردن پاسخ ها » در اسپرینت های آتی اختصاص دهند . می توان گفت که در طول اولین اسپرینت ، تیم تصمیم می‌گیرد تا روی داستان «درباره دستگاه » کار کند. آنها همچنین موافقت می کنند که مدتی را صرف UI برای سیستم کنند. در این مدت UXD ممکن است چند صفحه نمایش طراحی کند و آنها را به چندین کاربر نشان دهد و بازخورد دریافت کند و دوباره این کار را انجام دهد. این ممکن است چند بار اتفاق بیفتد. هنگامی که آنها به پایان می رسند، ممکن است داستان کاربر دوم (به عنوان یک کاربر بتوانم وارد صفحه WIFI شوم و تنظیمات و نحوه اتصال به شبکه های مختلف را انجام دهم) به ده ها داستان کوچکتر تبدیل کرده باشند، شاید مشخص کنند که چه جزئیات و فیلدهایی مورد نیاز است.
در برخی موارد، تقسیم یک داستان بزرگ به موارد کوچکتر برای نشان دادن موارد جدید در سطح درست خود کافی است. اگر اینطور نیست، می‌توانیم داستان کاربر را با اطلاعات بیشتر تقویت کنیم. من دوست دارم داستان های کاربر را روی کارت ها فهرست وار بنویسم. این مورد برای داستان «درباره دستگاه» کافی بود. اما برای داستان کاربر بزرگ مورد اشاره دوم که شاکله اصلی UI سیستم ما را در بر می گیرد، کافی نیست. اگر تقسیم یک داستان به چند داستان کوچکتر به اندازه کافی جزئیات را تشریح نمی کند، UXD و دیگران ممکن است بخواهند مشخصات طراحی UI را به کارت اضافه کنند. (اگر از یک سیستم نرم‌افزاری برای مدیریت بک لاگ محصول خود استفاده می‌کنید، ممکن است پیوندی به یک صفحه باشد.)
هدف UXD (و هر کس دیگری که در آن زمان درگیر کار می باشد) اضافه کردن جزئیات به داستان در زمان مناسب است. اگر برای مدتی طولانی روی آیتم بک لاگ محصول کار نکنیم ، معمولاً هیچ ارزشی برای تقسیم یک داستان کاربر بزرگ در حال حاضر یا منگنه کردن یک سند در آن وجود ندارد. در حالی که برای مواردی که به تازگی مقرر هست بر روی آن ها کار کنیم باید به اندازه کافی جزئیات اضافه کنیم که تکمیل هیچ موردی بیش از یک اسپرینت طول نکشد.
حرف آخر :
برای اینکه تیم دقیقا بداند چطور باید فیچرها را ارائه دهد باید PBI ها یا داستان های کاربر به صورت شفاف و با جزئیات مشخص گردد.که این مورد از دو طریق قابل اجرا می باشد : یا داستان حجیم و بزرگ بوده و باید جهت مشخص شدن اصطلاحا شکسته و به چند داستان کوچک تر تبدیل شوند و یا از طریق پیوست یا یادداشت در پشت کارت ها جزئیات قید شوند.
موضوع دیگر زمان مناسب نوشتن آیتم ها یا داستان ها می باشد تا با نزدیک شدن به موضوعات در زمان خودش جزئیات پرداخته و نوشته شوند.
با نوشتن به موقع و اندازه کافی PBI ها به هدف سازماندهی و ایجاد یک جریان روان از بک لاگ محصول به بک لاگ اسپرینت برسیم.
دیدگاهتان را بنویسید