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

ما نیازمندی ها را در قالب داستان کاربری یا User Story  در جیرا می‌نویسیم، بعلاوه سعی می کنیم همه توضیحات کامل باشد … مثلا “بعنوان کاربر من میخواهم …. تا بتوانم …..”، بعد پایین‌تر توضیحات رو مینویسیم، همه سناریوها و … .

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

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

“بعنوان ______

من میخواهم ___________

تا بتوانم _______________”

ما یاد گرفتیم از این به بعد به جای اینکه بنویسیم، “لاگین” بنویسیم “بعنوان کاربر، من میخواهم به سیستم لاگین کنم، تا بتوانم از امکانات سیستم استفاده کنم”.

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

مشکلاتی که دیده شد:

شرح نیازمنید دو ایراد اساسی داشت:

1. اجبار بود، یعنی همین رو میخواهیم , و قابل مذاکره نیست.
2. با توجه به دست به دست شدن،و اینکی توضیحی داده نمیشد، موجب ایجاد کج فهمی بود.

گفتگو گم شده است و همینی که هست 

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

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

گفتگو و توافق

بزرگترین کار یک مالک محصول این است،

1-مطمئن شود، که تیم نیاز واقعی کاربر یا مشتری را درک کرد باشند. (این با گفتگو و دیالوگ امکان پذیر است، مطمئن شوید که تیم سوال می پرسد)

2- بر روی شرایط با هم توافق کنند و توافق را حتما مکتوب کنند.

خلاصه،

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

اگر به این موضوع علاقمند بودید، توصیه میکنم از روش Story mapping استفاده کنید.

نظر شما در این مورد چیست؟ تجربه شما بعنوان برنامه نویس یا مالک محصول چطور بوده است؟