يكي از سخت ترين و مهمترين جلسه هايي كه اعضاي يك تيم اسكرام در آن شركت مي كنند، بك لاگ آرايي است: زماني كه تيم با صاحب محصول مي نشيند تا داستان هاي جديد را به بك لاگ بيافزايند و داستان هاي نزديك تر به بالاي بك لاگ را شفاف تر و كوچكتر كنند. متن زير مروري مي كند بر آنچه در يكي از اين دست جلسات مي گذرد. سامان صاحب محصولي است كه به تازگي وارد دنياي چابك شده، و تيم اسكرام سعي دارند در اين جلسه او را با روش كارشان آشنا كنند. اين متن را چارلز بردلي در سايت شخصيش scrumcrazy.com نوشته و شما آن را با ترجمه ي عليكس مي خوانيد؛ نويسنده ي تازه وارد بلاگ دنياي چابك.
شخصیت ها:
- سامان: صاحب محصول (product owner)
- جواد: برنامه نویس جاوا – به شخصی که نقش پایتون را بازی می کند: نقش شما تا حدی کمیک است، و کمیک تر می شود اگر شما در جاهایی که گفته شده “با تاکید” کمی اغراق آمیز بازی کنید
- برنا: برنامه نویس
- آذر: آزمونگر
- تجری: تحلیلگر تجاری
متن:
– برنا: سلام به همه. ممنون از اینکه در جلسه بک لاگ آرایی (backlog grooming) ما، یا همان کارگاه داستان نویسی، یا هر اسم دیگری که این هفته برایش بگذاریم، شرکت کردید. من می خواهم سامان را به شما معرفی کنم، که صاحب محصول جدید ماست. سامان یک مدیر محصول با تجربه است. البته او تجربه زیادی درباره نوشتن داستان کاربر ندارد، بنابراین ما باید به او در این خصوص کمک کنیم. او اصول و کلیاتی درباره داستان کاربر مطالعه کرده است. خوش آمدی سامان. من الان نوبت را به تو می دهم.
– سامان: سلام به همه، و ممنون از معرفی. شروع کنیم. اولین داستانی که من می خواهم درباره اش صحبت کنیم یک صفحه تایید سفارش برای سفارشات برخط است.
– برنا: (یک کارت یادداشت بر می دارد و روی آن می نویسد “صفحه ی تایید”)
– سامان: در حال حاضر، همانطور که می دانید، وقتی یک مشتری در وب سایت ما سفارشی ثبت می کند، بعد از فشردن دکمه تایید نهایی سفارش، کاربر مستقیم به صفحه ی اول سایت برده می شود. من می خواهم این را بهبود دهم.
– آذر: من مدتهاست منتظرم یک نفر به این قضیه اولویت بدهد. راستی من آذر هستم، آزمونگر تیم.
– سامان: سلام آذر، خوشبختم. بنابراین من یک لیست از چیزهایی که دوست دارم در صفحه ی تایید باشد دارم: شماره سفارش، زمان تخمینی ارسال سفارش، جزییات خود سفارش، جزییات پرداخت، تعدادی کالای مرتبط پیشنهادی، و لینکی با اسمی شبیه “ادامه ی خرید”.
– جواد: (با تاکید، مثل وقتی که به یک اسب دستور ایست می دهید) هی هی هی! (با صدای معمولی) ببخشید که حرفت رو قطع می کنم سامان. من جواد هستم، یک برنامه نویس جاوا در تیم، و مجبورم تو را اینجا کمی متوقف کنم. سوء تفاهم نشه، این ها همه ایده های خوبی هستند، ولی من سعی می کنیم داستان هایمان بیشتر از 2 تا 3 روز طول نکشند.
– سامان: اوه ببخشید. واقعا اینها بیشتر از 2-3 روز طول میکشند؟
– جواد: منظورم 2 تا 3 نفر روز بود. یعنی یک نفر حدودا 2 تا 3 روز رویش کار کند. ما می توانیم همه کارهایی را که گفتی انجام دهیم، فقط آنها را به تکه های کوچکتر تقسیم می کنیم تا هضم آنها برایمان آسان تر باشد.
– سامان: آهان، باشه. خب شما ایده ای دارید که چطور این داستان را تکه تکه کنیم؟
– جواد: ما معمولا اولویت را به ارزش تجاری می دهیم. این یکی از ویژگیهای بک لاگ در اسکرام است. حالا چی بیشتر از همه برای تو مهم است؟
– سامان: هوممم… احتمالا مهمترین چیزها در صفحه ی تایید، شماره سفارش و زمان تخمینی ارسال سفارش هستند، و لینک ادامه ی خرید.
– تجری: سلام سامان. من تجری هستم، یک تحلیلگر تجاری در تیم. نظرت چیه که آدرس ایمیل یا تلفن بخش خدمات مشتریان را هم در این صفحه اضافه کنیم؟ وقتی من یک سفارش برخط ثبت می کنم، معمولا صفحه ی تایید را چاپ می کنم و خوب است که در آن اطلاعات تماس خدمات مشتریان هم باشد.
– سامان: از این ایده خوشم اومد. آدرس ایمیل را اضافه کنیم.
– برنا: بسیار خب، تا حالا من این چیزها را روی کارت داستان نوشته ام (برنا کارت را بالا می گیرد): عنوان، که البته “صفحه ی تایید” است. بعلاوه نوشتم که ما باید شماره سفارش، زمان تخمینی ارسال سفارش، لینک ادامه ی خرید، و آدرس ایمیل خدمات مشتریان را در این صفحه نمایش دهیم.
– سامان: بله. ولی بقیه چیزهایی که من گفتم چی؟
– برنا: نگران نباش، به آنها هم می رسیم. من کارت یادداشت هایی برای آنها هم ایجاد میکنم. (برنا کارتهای جدیدی بر می دارد و شروع به نوشتن می کند) من یک کارت با عنوان “ص.ت. جزییات سفارش” دارم، که ص.ت. خلاصه ی صفحه ی تایید است. یکی با عنوان “ص.پ. جزییات پرداخت” و یکی با عنوان “ص.پ. کالای پیشنهادی مرتبط”. چیزی جا نمانده؟
– سامان: بله… و یکی هم برای ارسال صفحه تایید به آدرس ایمیل مشتری اضافه کن لطفا.
– برنا: هوم… این به نظر کار زیادی لازم داره. بسیار خب، “ص.پ. ایمیل تایید”. حالا برگردیم به داستان اصلی صفحه ی تایید و درباره ی آن بیشتر حرف بزنیم.
– سامان: بسیار خب.
– برنا: فکر می کنم ما می توانیم شماره سفارش و ایمیل خدمات مشتریان را به راحتی انجام بدهیم. منظورت از لینک ادامه ی خرید چیه؟
– سامان: فعلا این لینک کاربر را به همان صفحه اول سایت بر می گرداند.
– برنا: آهان، خوبه.
– سامان: برنا، لازم نیست این را بنویسی؟
– برنا: نه. من “ادامه ی خرید” را نوشته ام. برای جزییاتی به این کوچکی، ما معمولا چیزی نمی نویسیم. واقعا ارزشش را ندارد. ما در چند روز آینده قرار است روی این داستان کار کنیم، و از آنجایی که همه ی ما اینجا هستیم، من مطمئنم یک نفر یادش می ماند که لینک ادامه ی خرید باید مشتری را به صفحه ی اول برگرداند.
– سامان: درسته.
– برنا: خب، اگر به نظر شما چیز مهمی از قلم افتاده، حتما بگویید تا آن را بنویسیم.خودتان هم می توانید این کار را یک وقتی بکنید.
– سامان: بسیار خب. لازم نیست این را که لینک ادامه ی خرید مشتری را به صفحه ی اول می برد بنویسیم. مطمئنم کسی این را یادش می ماند.
– جواد: سامان، من یک سوال درباره ی زمان تخمینی ارسال سفارش دارم. ما چطور باید این زمان را تخمین بزنیم؟
– سامان: خوب، من وب سایت شما را دیدم… منظورم اینه که وب سایت *خودمون* را دیدم. دیدم که ما سه گزینه برای ارسال داریم: همان شب، 2 روزه، و ارسال با پست زمینی. بنابراین به نظرم می تونیم برهمین اساس تخمین بزنیم.
– جواد: هومم. اینطوری به نظرم میشه. من فکر می کنم تا 3 روز طول میکشه که ما سفارش را برای ارسال آماده کنیم، بنابراین فرض من اینه که تو میخوای ما این را هم به حساب بیاوریم، درسته؟
– سامان: بله، دقیقا. من نمی خواهم که ما زمان دقیق رسیدن سفارش را پیش بینی کنیم. پیامی که ما اینجا می خواهیم به مشتری بدیم چیزی شبیه اینه: اگر شما محصول را تا زمان تخمینی دریافت نکردید، یک ایمیل برای ما بفرستید. ما حتی میتونیم یک روز اضافه هم برای خطاهای احتمالی در نظر بگیریم.
– آذر: این خوبه، چون من نگران بودم که ما روز را چطور در نظر می گیریم. آیا سه روز را معادل 72 ساعت از زمان ثبت سفارش در نظر می گیریم، یا جور دیگری حساب می کنیم؟ به هر حال به نظر می رسد که تو این حد از دقت برایت مهم نیست.
– سامان: نه، نمی خواهم اینقدر سختش کنم. یک تخمین تقریبی کافی است.
– تجری: سامان، من فکر می کنم ما می تونیم نحوه محاسبه تخمین را هم در سایت توضیح دهیم، که شامل زمانی که برای بیرون کشیدن اجناس از انبار و بسته بندی آن لازم است هم می شود.
– سامان: بسیار خب، مثلا چیزی شبیه این چطوره…
– برنا: سامان، بهتره تو و تجری این رو بعدا با هم حلش کنین. من اینجا روی کارت می نویسم که “توضیح درباره تخمین” و تو می تونی این توضیح را بعدا که به زمان توسعه این داستان نزدیک شدیم نهایی کنی.
– سامان: خوبه. آیا من باید این را جایی به عنوان یک آیتم کاری برای خودم یادداشت کنم؟ یا شما به شکل دیگری این رو هندل میکنین؟
– برنا: نه لازم نیست کسی الان آیتم کاری برای خودش ثبت کند. من این را روی کارت نوشتم. وقتی یک برنامه نیس کار روی داستان را شروع کنه، خودش میاد سراغ تو تا درباره جزییات این توضیح ازت سوال کنه. تو این یادداشت را می بینی و اون موقع فرصت داری که قبل از تایید داستان اصلاحش کنی.
– سامان: برنا من می خواستم یه سوالی هم ازت بپرسم: شما اینجا چطوری جزییات واسط کاربری و نیازهای مرتبط با آن را در داستان کاربر می آورید؟
– برنا: به طور کلی، وقتی یک برنامه نیس کار روی یک داستان را شروع می کند، او یا برای کشیدن یک طرح اولیه دستی از واسط کاربری به سراغ تو می آید، یا در بیشتر مواقع که مثل این یکی تغییر جزیی است، یک جوری کار را روی صفحه می آورد و بعد آن را به تو نشان می دهد و از تو فیدبک می گیرد.
– سامان: آیا این کار را موقع تایید داستان یا شبیه آن انجام می دهند؟
– برنا: بهتر است که این کار را زودتر انجام دهند، به محض اینکه نسخه اولیه ای از صفحه درست شده باشد. بعد هم احتمالا چند بار دیگر تا پیش از تایید داستان. وقتی که تو تایید را انجام می دهی، ترجیح ما این است که اصلاحات بسیار جزیی روی واسط کاربری داشته باشیم. ما سعی می کنیم دوره های فیدبک را هرچه می شود کوتاهتر کنیم، و تلاشمان این است برای هر استوری در مدت توسعه اش چندین بار فیدبک بگیریم.
– سامان: فکر می کنم این مقدار تعامل برای یک داستان که قرار است دو یا سه روز طول بکشد کافی باشد. به نظرم من لازم باشد سه الی چهار برابر این مقدار زمان بگذارم، اگر بقیه شما هم در حال کار روی بقیه داستان ها باشید، درسته؟
– برنا: بله البته. پیاده سازی داستان های کاربر، وقتی درست انجام شود، نیازمند مقدار زیادی ارتباطات کلامی، بخصوص با صاحب محصول است. این یک شغل تمام وقته. برای همینه که تو توی همان اتاقی که ما هستیم می نشینی. تو احتمالا حدود دو سوم از وقتت را با ما می گذرونی، و یک سوم بقیه هم صرف تعامل با مشتری ها و سایر واحدهای سازمان برای یافتن با ارزش ترین قابلیت ها میشه.
– سامان: منظور داستان های کاربره نه؟
– برنا: بله. قابلیت، داستان کاربر، یا هر اسم دیگری که رویش بگذاریم. آنها کلا یک چیز هستند. تفاوت اصلی اینه که تا یک سال قبل ما وقتی درباره یک قابلیت حرف می زدیم، معمولا چیز بزرگی بود و نیاز به صرف تلاش زیادی داشت، مثلا چیزی در حدود 2 تا 6 نفر هفته. داستان کاربر باید خیلی کوچکتر باشد، بخاطر اینکه ما خیلی روی ارتباطات کلامی تکیه می کنیم. بعلاوه اگر شما داستانهای کاربر را بزرگ در نظر بگیرید، جواد پلیس داستان کاربر را صدا می زند و شما دستگیر می شوید! شوخی کردم، شوخی کردم. بنابراین میشه داستان کاربر را قابلیت های بسیار کوچک در نظر گرفت، که حداکثر 2 تا 3 نفر روز زمان برای انجام شدن لازم داره.
– سامان: این شامل زمان تست هم میشه؟
– برنا: بله، این شامل زمان لازم برای کل کاره. از زمانی که برنامه نویس داستان را برمیداره و شروع به کد نوشتن میکنه، تا زمانی که آزمونگر صرف تست و اتوماتیک کردن اون میکنه. این حتی شامل زمانی که برای گرفتن تایید تو و تغییرات جزیی که تو در آخرین لحظه درخواست میکنی هم میشه.
– سامان: بیشتر برنامه نویس هایی که من می شناسم تغییرات آخرین لحظه را دوست ندارند.
– برنا: خب ما با اونها مشکلی نداریم، تا وقتی که جزیی باشند. اگر بیشتر از جزیی باشند، ممکنه ما از تو بخواهیم که برای تغییرات یک داستان جدید ایجاد کنی. ولی حتی اون موقع هم ما می تونیم کار را بعدش نسبتا سریع انجام بدیم. بهرحال اجازه بدین جلو بریم. به نظرم درباره این داستان به اندازه کافی صحبت کردیم.
– سامان: تست پذیرش چطور؟ یا شاید شما بهش بگید “تست تایید”؟
– برنا: بعععععله… ممکنه این هفته هر چیزی صداش کنیم.
– سامان: کتاب مایک کوهن چند توصیه خوب در این باره داره. اون میگه شما میتونین هر تستی را با کلمات “تست شود که” شروع کنید.
– برنا: بله، این خوبه. ولی درباره این داستان، بیشتر چیزهایی که ما گفتیم تست پذیرش های بدیهی دارند و ما آنها را در توضیحات داستان نوشته ایم. مثلا ما می دونیم که نیاز به یک لینک “ادامه ی خرید” داریم. بنابراین بدیهیه که باید تستی شبیه این برایش داشته باشیم: “تست شود که لینک ادامه ی خرید کاربر را به صفحه ی خانه بر می گرداند”. می تونیم همه ی اینها را بنویسیم، ولی چرا؟ ما داستان ها را کوتاه نگه می داریم، و بنابراین به راحتی میشه مواردی که باید تست شوند را به صورت نکاتی روی کارت بنویسیم. به همین دلیل بود که جواد اولش آن “هی هی هی” را سر داده بود. او می داند که چقدر مهم است که داستان ها کوتاه بمانند. ما روی داستان کاربر فقط تست های پذیرش سطح بالا را می نویسیم. مثلا: “تست شود که زمان تخمینی ارسال درست محاسبه شده”. وقتی که یک برنامه نویس کار روی داستان را شروع کرد، اول باید چند مثال برای تست منطق کار پیدا کند.
– سامان: چه کسی این مثالها را ارائه می کند؟
– آذر: معمولا من این کار را می کنم. من کسی هستم که در تیم بیشتر روی تست تمرکز دارم.
– سامان: آیا فقط چیزی شبیه این می نویسیم؟ “تست شود که برای سفارشهایی که روش ارسال شبانه است زمان ارسال 5 روز، برای سفارشهای دو روزه 7 و برای پس زمینی 12 روز است”.
– آذر: میتونی این کار رو بکنی. ولی ما یک تکنیک جالب یاد گرفته ایم که برای این جور سناریوها خیلی آسانتر و بهتر است. بجای نوشتن همه ی این “تست شود که…”ها روی کارت، ما فقط چند مثال از سفارش با تاریخ ها انواع ارسال متفاوت می نویسیم به همراه زمان تخمینی مورد انتظار برای هر یک. بعد چک می کنیم که زمان تخمینی ارسالی که ما حساب کرده ایم با آن چیزی که در صفحه ی تایید آمده یکی باشد. اسم این تکنیک هست: “شرح خصوصیات با مثال” (Specification by example)
– سامان: آیا شما این مثالها را روی کارت داستان می نویسید؟
– آذر: معمولا راحت تره که این ها را در یک جدول در یک صفحه ویکی بنویسیم. ما اینجا از ابزاری به نام Fitnesse برای تست های اتوماتیک پذیرش استفاده می کنیم، و این ابزار یک ویکی داخل خودش دارد که اجازه می دهد جدولهایی برای ورودیهای تست و خروجیهای مورد انتظار ایجاد کنیم. بعدا نشانت می دهم. نشان دادنش از توضیح دادنش راحت تره.
– سامان: باز هم ارتباطات کلامی، نه؟
– آذر: دقیقا. برای توسعه نرم افزار، من حرف زدن و همکاری کردن را به تولید مستندات و برنامه های مفصل آزمون ترجیح می دهم.
– سامان: من هم همینطور! (مکث) برنا، سوال آخر من درباره داستان کاربر اینه: تو قبلا درباره تایید داستان ها حرف زدی. من کی باید این کار را انجام بدهم؟ در آخر اسپرینت؟
– برنا: اوه نه! ما معمولا وقتی از تو می خواهیم داستان را تایید کنی که از نظر تیم داستان کامل است و چگونگی تست پذیرش آن روشن است. دلایل زیادی داریم که تایید داستان را هرچه ممکن است زودتر انجام دهیم، ولی من به طور خلاصه می گویم که ما یاد گرفته ایم به این شکل کارآمد تر عمل می کنیم. آیا جواب سوالت را دادم؟
– سامان: بله. آیا شما اسم این کار را “امضای صاحب محصول” می گذارید یا “تایید داستان”؟
– برنا: بستگی دارد کدام هفته باشد! شوخی کردم، شوخی کردم. ما هر دو اسم را به کار می بریم. مثل هر چیز دیگری در دنیای چابک، برای یک چیز واحد چندین اسم وجود دارد. مهم این است که همه بدانیم داریم درباره چی صحبت می کنیم. بسیار خب هم تیمی های عزیز، به نظر میاد این داستان کامل شده. من بحث درباره این داستان را با این سوال معمول مان تمام می کنم: “آیا همه اینجا موافقند که ما حداقل 90 درصد از چیزی را که برای انجام دادن این داستان لازم داریم می دانیم؟”
– جواد: بعله
– آذر: من نظرم مثبته
– تجری: منم همینطور. من فکر می کنم درباره این داستان تقریبا 100 درصد مطالب رو می دونیم.
– برنا: آه… زیبایی کوچک نگه داشتن داستان ها.
– جواد: (با تاکید) خدا رو شکر
– برنا: بسیار خب تیم! بریم سراغ داستان بعدی…
پایان سکانس
اصل مقاله: http://www.scrumcrazy.com/file/view/Script_UserStoryUtopia.pdf
نوشته شده توسط: علیکس (مهر 1390)
گزینش نام ها بسیار خوب بود.
جالب بود .