بحث زیبای تحلیل نرم افزار و استخراج الزامات، ابتدا عنوان مطلب رو الزامات و روایت کاربر در اسکرام گذاشته بودم، ولی خب دیدم این مبحث جامعتر از اسکرام هست و داخل اسکرام هم داره استفاده می شود. تمامی مطالب مرجع دارند که در انتهای مطلب درج شده اند.
بحث اصلی استخراج الزامات هست که احتمالا اگر مثل من از فارغ التحصیلان حدود ۱۰ سال پیش باشید، با روند های استخراج الزامات به صورت کامل برای رویکرد های آبشاری یا افزایشی آشنا هستید که باید ابتدای پروژه تمامی الزامات به صورت کامل تهیه می شدند، هر چه ریزتر و جزیی تر بهتر، اما با ورود رویکردهایی همچون چابک و فریمورک اسکرام، رویه استخراج الزامات خیلی فرق کرده است.
مقدمه
در استخراج الزامات سنتی گذشته، مذاکره روی الزامات جایی نداشت و جزییات از اول به وجود می آمد. اما در اسکرام الزامات در طول مکالماتی که در طول توسعه ادامه دار هستند به مذاکره گذاشته می شود و تکمیل می شوند. در توسعه های سنتی تغییر در الزامات تقریبا غیر ممکن بود و اگر تغییری رخ می داد حجم وسیعی از پروژه را تحت تاثیر قرار می داد، منتهی در پروژه های اسکرام این طور نیست، برای مثال اگر در اسکرام زمان یا پول در حال اتمام باشد، الزامات سطح پایین رو بیخیال می شیم و اگر حین کار یک الزام خیلی ضروری جدیدی کشف شد، وارد پروژه و توسعه اش می کنیم.
تقریبا همه ما تجربه نوشتن الزامات کامل و با جزییات راداشتیم و اگر در الزامات چیزی رو جا انداخته بودیم احتمالا چینین مکالمه ای پیش می امد:
مشتری: الان که دارم ویژگی های ساخته شده را می بینم، به این نتیجه رسیدم که این ویژگی های اضافه را نیاز داریم که در اسناد الزامات نبود.
توسعه دهنده: اگر این ویژگی را می خواستید چرا از اول نگفته بودید؟
مشتری: درسته، من فکر نمیکردم که چنین ویژگی را بخوایم تا اینکه محصول نهایی رو دیدم
توسعه دهنده: بسیار خب، اگر شما بیشتر و با دقت تر برای الزامات فکر کرده بودید، شما می توانستید به جای الان و در این لحظه، همون موقع الزامات را پیدا کنید.
در حقیقت زمانی که یک محصول ابتکاری را دارید توسعه می دهید، شما نمی توانید الزامات کاملی را بسازید. بعضی از الزامات به وقت اینکه محصول اومد بالا تازه خودشون رو نشون می دهند، هر چقدر کار زیاد و کاملی ام برای استخراج الزامات صورت بگیره، باز تا محصول ابتکاری نیاد بالا نمیشه تمام الزامات را بدست آورد.
در چارچوبی مانند اسکرام، ما در ابتدا نه زمان و نو پول به مثدار کافی داریم تا بخواهیم الزامات را به صورت کامل استخراج کنیم، به همین دلیل برای الزامات محل های نگهداری (Placeholders) را در نظر می گیریم که آیتم های بکلاگ محصول (Product backlog Items – PBIs) می نامیم شان. به تصویر (تصویر ۱) زیرنگاه کنید:
در ابتدا آیتم های بکلاگ محصول بزرگ هستند، و جزییات خیلی کمی با هر آیتم هست. با گذشت زمان ما این آیتم های بکلاگ محصول را در مجموعه ای از سلسله گفتگوها بین ذینفعان، صاحب مصحول و تیم توسعه جاری می کنیم و آنها را به مجموعه PBI های کوچکتربا جزییات بیشتر پالایش می کنیم. سرانجام یک PBI به اندازه کافی کوچک و جزیی شده که در یک اسپرینت از آن استفاده کنیم، جایی که در آن طراحی، ساخته و تست شود. با این حال حتی در طول اسپرینت نیز با وجود سلسله گفتگو ها بین تیم توسعه و صاحب محصول، این آیتم ها جزیی تر و کوچکتر می شوند.
اسکرام فرمت خاصی را برای بکلاگ محصول در نظر نگرفته، منتهی خیلی ها از روایت کاربر (User Story) برای این منظور استفاده می کنند.
استفاده از سلسله گفتگوها
به عنوان وسیله نقلیه ارتباطی ، الزامات درک مشترک از آنچه باید ساخته شود را تسهیل می کند. آنها به افرادی که می فهمند چه چیزی باید خلق شوند اجازه می دهند تا خواسته های خود را به وضوح با افرادی که موظف به ایجاد آن هستند، انتقال دهند.
یک روش خوب برای اطمینان از اینکه ویژگی های مورد نظر ساخته می شوند، افزایش مکالمات بین افرادی که می دانند چه می خواهیم و افرادی که قرار به ساخت، طراحی و تست هستند می باشد. در اسکرام از مکالمات و جلسات برای اطمینان از مطرح شدن و خوب بحث شدن روی الزامات بهره برده می شود. ارتباط کلامی به نفع و منجر به ارائه بازخورد سریع ، دستیابی به درک مشترک آسانتر و ارزانتر می شود.
علاوه بر این ، مکالمات ارتباط دو طرفه ای را امکان پذیر می سازند که می تواند ایده هایی را درباره مشکلات و فرصتها ایجاد کند – بحث هایی که احتمالاً از خواندن یک سند بوجود نمی آیند. گفتگو ، با این حال ، فقط یک ابزار است. و جایگزین همه اسناد نمی باشد. در اسکرام ، بکلاگ محصول یک “سند زنده” است که در همه زمانها در طول توسعه محصول موجود است.
پالایش پیشرفت
در توسعه محصول پی در پی (Sequential) تمامی الزامات باید در یک زمان در یک سطح از جزییات باشند. به طور خاص ، سند الزامات مصوب باید شرایط لازم و ضروری را مشخص کند تا تیم هایی که کار طراحی ، ساخت و آزمایش را انجام می دهند بتوانند نحوه انطباق با مشخصات را درک کنند. هیچ جزئیاتی برای اضافه شدن در اینده نباید وجود داشته باشد.
اجبار مستندات به داشتن جزییات در یک سطح در یک زمان مشخص، معایبی خواهد داشت:
- باید تمامی نیازمندی ها را در ابتدای توسعه و زمانی که کمترین اطلاعات را داریم، پیش بینی کنیم.
- ما با همه جزییات بدون در نظر گرفتن اولیویت آنها به طور یکسان رفتار می کنیم، ما را وادار می کند منابع با ارزشی را برای الزاماتی که ممکن اصلا پیاده سازی نشوند مصرف کنیم.
- ما فهرست بزرگی از الزامات تهیه می کنیم که تغییر یا کار مجدد روی آنها بسیار هزینه بر خواهد بود.
- ما احتمال استفاده از مکالمات که تاثیرشان روی وضوح الزامات علنی می باشد را با توجه به کامل بودن ازلامات از دست می دهیم.
همان طور که در تصویر فوق نشان داده شده، در اسکرام در یک زمان، لازم نیست که نیازمندی ها در یک سطح باشند. الزاماتی که به زودی روی آنها کار خواهیم کرد کوچک و جزییتر نسبت به الزاماتی که در آینده احتمالا از آنها استفاده کنیم هستند.
روایت کاربر چیست؟
روایت کاربر (User Story) فرمتی مناسب و آسان برای تشریح ارزشهای تجاری مطلوب برای انواع زیادی از آیتم های بکلاگ محصول می باشد، مخصوصا برای ویژگی ها. روایت کاربر به گونه ای مطرح می شود که هم برای افراد تجاری و هم افراد فنی قابل درک باشد. ساختارا ساده می باشند و ظرفیت مناسبی برای مکالمه و گفتگو فراهم می کنند. در سطوح مختلفی از دانه بندی می توانند نوشته شوند و به سادگی می توانند پالایش پیشرفت شوند.
روایت کاربر دقیقا چیست ؟ Ron Jeffries روشی موثر و ساده در مورد فکر کردن پیرامون روایت کاربر پیشنهاد داده است، او انها را در سه تا C تعریف کرده است : «Card – کارت» ، «Conversation – گفتگو» و «Confirmation – تائید».
کارت – Card
ایده کارت خیلی ساده سات، افراد اوایل (در حال حاضر هم خیلی ها همین کار را می کنند) روی برگه های ۳ در ۵ اینچی روایت های کاربر را می نوشتند (برگه های برچسب دار)، شکل زیر را مشاهده کنید (شکل ۲).
قالب فرمت رایج برای نوشتن روایت کاربر که در شکل سمت چپ تصویر ۲ نشان داده شده است، کلاس کاربران را مشخص می کند (نقش کاربر – User Role)، کاری که آن نقش میخواهد انجام دهد و به آن برسد (هدف – Goal) و اینکه چرا کاربران یم خواهند به آن هدف دست یابند (سود – Benefit). قسمت «به طوریکه – So that» در روایت کاربر اختیاری است، منتهی برای آنکه هدف روایت برای همه کاملا آشکار باشد، باید آن را در هر روایت کاربر بگنجانیم. قسمت راست از تصویر ۲، مثالی از روایت کاربر مبتنی بر این فرمت را نشان می دهد.
این کار قصد ندارد که تمام اطلاعات الزام را ضبط کند. در واقع، ما به عمد از کارت های کوچک با فضای محدود برای ترویج اختصار و ایجاز استفاده کرده ایم. کارت باید چند جمله را نگه داشته باشد که جوهر یا هدف یک نیاز/الزام را ضبط می کند. به عنوان مکانی برای گفتگوهای جزیی تر و بیشتر که بین تیم توسعه دهنده، دینفعان و صاحب محصول برقرار می شود، عمل کند.
گفتگو – Conversation
جزییات الزامات در گفتگوی بین ذینفعان، تیم توسعه دهنده و صاحب محصول به بحث گذاشته شده و بسط داده می شوند. روایت کاربر به سادگی وعده ای برای گفتگو می باشد.
ما از «گفتگو» استفاده کرده ایم، ولی در عمل یک گفتگو و رویداد در یک زمان مشخص نیست، بلکه ادامه دار می باشد. می تونیم یه گفتگو اولیه داشته باشیم که در آن روایت کاربر نوشته میشه، گفتگوی بعدی همان روایت کاربر را پالایش کنیم، گفتگوی بعدی برای تخمین آن، و دیگری بهنگام برنامه ریزی اسپرینت باشد و در انتها گفتگوهای پیش رو برای طراحی، ساخت و تست در طول اسپرینت.
یکی از مزیت های روایت کاربر این هست که مقداری از تمرکز را از نوشتن به گفتگو می برد. اگرچه گفتگوها معمولا شفاهی هستند، ولی می توان همان ها را مستند کرد. گفتگو ها می تواند منجر به تهیه UI Sketch شود. برای مثال در یک سازمان که در حال توسعه نرم افزار تصاویر پزشکی بود، تصویر (تصویر ۳) زیر به عنوان یک روایت کاربر مطرح شده بود.
توجه داشته باشید که روایت کاربر به یک مقاله کامل برای مطالعه بعدی، ارجاع داده شده است.
بنابراین ما نمیخواهیم تمام اسناد را به خاطر روایت کاربر و کارتهای روایت حذف کنیم. روایت های کاربر نقطه شروع خوبی برای استخراج ماهیت اصلی آنچه که مورد نظر است به آن برسیم، می باشد و همچنین یک یادآوری برای بحث بیشتر جهت جزییات بیشتر روی الزامات در زمان مناسب می باشد.
تائیدیه – Confirmation
یک روایت کاربر همچنین شامل اطلاعات تائیدیه در قالب شرایط رضایتمندی می باشد. اینها معیارهای پذیریش هستند که رفتار مورد نظر را روشن و واضح می کنند. این اطلاعات توسط تیم توسعه دهنده استفاده می شوند تا بهتر بدانند چه چیزی را باید بسازند، تست بگیرند و توسط صاحب محصول تاییدیه بگیرند که روایت کاربر با رضایت مندی پیاده سازی شده است.
اگر روی کارت چند خط اطلاعات توضیحی در مورد روایت کاربر دارد، پشت کار باید شرایط رضایت مندی را مشخص کرده باشد. (تصویر۴)
این شرایط رضایت می توانند به عنوان تست های پذیرش سطح بالا مطرح شوند. گرچه این تست ها نباید تنها تست های ممکن برای توسعه روایت کاربر باشند. در واقع برای تعداد محدودی از تست های پذیرش که با یک روایت کاربر مرتبط هستند، تیم توسعه باید تست های بیشتری در سطح فنی انجام دهد که حتی صاحب محصول هم از آنها خبری ندارد. (شاید ۱۰ تا ۱۰۰ بار تست بیشتر)
تست های پذیرش برای روایت کاربر به چند دلیل وجود دارند. اول اینکه آنها رویش مهم جهت ضبط و برقراری ارتباط از سمت چشم انداز صاحبان محصول می باشد تا چطور تضخیص دهند که یک روایت به درستی پیاده سازی شده است.
این تست ها همچنین می توانند روش کمک کننده ای برای ساخت روایت های اولیه باشد و آنها را برای دشاتن اطلاعات مفید بیشتر اصلاح کند(پالایش). این رویکرد گاهی «مشخصات توسط مثال – specification by example» یا «توسعه بر محور تست پذیرش – acceptance-test-driven development (ATTD) » نامیده می شود. توضیحات در مورد روایت ها می تواند اغلب با تمرکز بر تعریف یک مثال مشخص یا رفتار مورد نظر باشد. برای مثال روایت «Upload File» را در (تصویر ۴) ببینید، \فت\و احتمالا چیزی شبیه زیر بوده:
Initially, let’s limit uploaded file sizes to be 1 GB or less. Also, make sure that we can properly load common text and graphics files. And for legal reasons we can’t have any files with digital rights management (DRM) restrictions loaded to the wiki.
در ابتدا اجازه دهید سایت بارگذاری فایل را ب۰ ۱ گیگابایت یا کمتر محدود کنیم. همچنین مطمین شویم که ما می توانیم به درستی فایل های رایج متنی و گرافیکی را بارگذاری کنیم. و برای دلایل قانونی نمی توانیم هیچ فایلی با محدویت های مدیریت قوانین دیجیتال (digital rights management (DRM)) را روی ویکی بارگذاری کنیم.
سطح جزییات
روایت های کاربر ماشین فوق العاده ای برای حمل آیتم های مشتری یا ارزش کاربر از طریق جریان ایجاد ارزش اسکرام می باشد. گرچه اگر ما تنها یک سایز روایت داشته باشیم (سایزی که بتواند به راحتی در طول یک اسپرینت کوتاه جا شود)، سخت خواهد بود که برنامه ریزی سطح بالا داشته باشیم و مزیت های پالایش پیشرفت را بدست بیاوریم.
روایت های کوچک مورد استفاده در سطح اسپرینت برای پشتیبانی از محصول سطح بالاتر و برنامه ریزی انتشار، بسیار کوچک و همچنین خیلی متعدد هستند. در این سطح ما به آیتم هایی کمتر با جزییات کمترو انتزاعی بیشترنیازمندیم. در غیر اینصورت ما در یک باتلاق با جزییات غیر مرتبط قرار می گیریم. تصور کنید ۵۰۰ روایت خیلی کوچک دارید و از شما خواسته شده است که توضیحات در سطح اجرایی ار محصول پیشنهادی برای تامین بودجه خود ارائه دهید. یا از بین آن ۵۰۰ نمونه کوچک سعی بر اولویت بندی جهت تعریف انتشار بعدی داشته باشید.
همچنین اگر فقط یک استوری با سایز کوچک وجود داشت، ما متعهد می شویم تا تمام نیازمندی ها را در یک سطح دانه بندی خیلی خوب از جزییات و خیلی قبل از اینکه بخواهیم، تعریف کنیم. داشتن فقط روایت های کوچک مانعی در راه مزیت های پالایش تدریجی الزامات بر مبنای در زمان کافی و درست، ایجاد می کند.
خوشبختانه روایت های کاربر می توانند برای ضبط نیازمندی های کاربر و مشتری در سطح های مختلفی از انتزاع نوشته شوند (تصویر ۵)
تصویر۵ روایت ها را در چند سطح انتزاع نمایش می دهد. بزرگترین ها روایت خواهند بود که در سایز یکی دو ماه تا چندماه هستند و ممکن است یک انتشار یا چند انتشار را پوشش دهد. بعضی افراد اینها را به عنوان «حماسه-epic» ترجیه می دهند. حماسه ها کمک کننده هستند چرا که آنها یک Big-Picture و سطح بالایی از چیزی که مورد انتظار هست می دهند. (تصویر ۶)
ما هیچگاه از یک حماسه برای اسپرینت استفاده نمی کنیم چرا که خیلی بزرگ هست و خیلی جزیی نمی باشد. در عوض حماسه ها مکان های مناسبی برای مجموعه ی بزرگی از روایت های دقیق هستند که در یک زمان مناسب در آینده ساخته خواهند شد.
سایز بعدی در تصویر ۵، آنهایی هستند که اغلی مناسب سایزهای هفته می باشند و در نتیجه برای یک اسپرینت خیلی بزرگ می باشند. بعضی از تیم ها این دسته را «ویژگی ها – features» می نامند.
کوچکترین قالب روایت ها آنهایی هستند که معمولا آنها را «روایت ها-stories» یاد می کنیم. برای جلوگیری از هرگونه سردرگمی این دسته از روایت ها با epics، features یا دیگر آیتم های بزرگتر که آنها نیز روایت – Story هستند، بعضی افراد این روایت ها را sprintable stories یا implementable stories می نامند تا نشان دهند که آنها در سایز روز هستند و بنابراین به اندازه کافی کوچک هستند تا در یک اسپرینت جا شوند و پیاده سازی شوند. تصویر ۲ یک نمونه از استوری قابل اسپرینت شدن (sprintable stories) را نشان می دهد.
بعضی از تیم ها از واژه «زمینه-Theme» برای اشاره به مجموعه روایت های مرتبط استفاده می کنند. زمینه ها راه مناسبی برای گفتن این هستند که دسته ای از روایت ها چیزی مشترک دارند، ماننتد اینکه در یک ناحیه عملکردی یکسان قرار دارند. در تصویر ۷ «زمینه-Theme» نمایانگر مجموعه روایت هایی می باشد که جزییاتی از چگونگی انجام دادن یادگیری کلیدواژه را نشان می دهد.
من همچنین فکر می کنم Theme کارت خلاصه ای از یک دسته کارت می باشد که با یک روبان به یکدیگر جمع و بسته شده اند تا نشان دهند که آنها در یک محدوده ای به یکدیگر شبیه هستند که برای ما مهم می باشد.
وظایف/Tasks لایه های زیر Stories می باشد، معمولا توسط یک نفر انجام می شود یا شاید توسط دو نفر. Task ها معمولا چندین ساعت برای انجام شان نیاز است. زمانی که به لایه Task می رویم، ما مشخص می کنیم که چطور چیزی را بسازیم بجای آنکه چه چیزی بسازیم. Task ها Story نیستند، پس باید بهنگام نوشتن Storyها از نوشتن جزییات سطح-tak پرهیز کنیم.
این مهمه که توجه داشته باشید واژگانی همچون epic، Feature، Storyو Theme تنها برچسب هایی برای راحتی هستند و به صورت جهانی به اشتراک گذاشته نشده اند. و در کل مهم نیست که در طی استفاده تان از چه برچسبی استفاده کنید. چیزی که مهمه این هست که تشخیص بدهیم که Storyها را در چندین سطح از انتزاع وجود دارند و این کار به خوبی از تلاش های ما برای برنامه ریزی درچند سطح انتزاع و پالایش تدریجی آیتم های بزرگ به آیتم های کوچک در گذر زمان پشتیبانی می کند.
سرمایه گذاری روی روایت های خوب
حالا که روایت نوشتیم، چطور فهمیم که روایت نوشته شده خوب هسیت یا نه ؟Bill Wake شش معیار ارائه داده است. (به صورت مخفف INVEST خلاصه می شود) که اثبات کرده برای زمانی که می خواهیم بفهمیم روایت ها برای چیز مورد انتظارشان مناسب هستند یا خیر، مفید می باشد.
معیارهای INVEST عبارت هستند از Independent مستقل، Negotiable قابل مذاکره، Valuableباارزش، Estimatable قابل تخمین، Small کوچک (سایز مناسب)، و Testable تست پذیر بودن. وقتی که اطلاعات استخراج شده از اعمال هر کدام از این معیارها را ترکیب می کنیم، تصویر واضحی از آنچه که از روایت می خواهیم یا هر تغییری که نیاز است روی آن اعمال شود را به ما می دهد. حال به هر معیار می پردازیم:
مستقل – Independent
به همان اندازه که عملی است، روایت های کاربر باید مستقل باشند یا حداقل خیلی شُل و وِل یا یکدیگر جفت شوند. روایت هایی که میزان زیادی از وابستگی متقابل دارند، تخمین زدن، اولویت بندی و برنامه ریزی را پیچیده می کنند. برای مثال، در سمت چپ تصویر ۸، روایت ۱۰ به چند روایت دیگر وابسته است.
قبل از اینکه ما روی روایت ۱۰ کار کنیم، ابتدا باید تمامی روایت های مرتبط را پیاده سازی کنیم. حالا فرض کنید سیستمی دارید همانند تصویر سمت راست که هر روایت به تعدادی روایت دیگر وابستگی متقابل داشته باشد، سعی کنید تا ببینید چطور میشه اولیوت بندی کرد!؟ و تصمیم بگیرید اسپرینت را با کدام روایت شروع به کار کنیم؟
زمانی که معیار استقلال را اعمال کنید، هدف این نیست که تمام وابستگی ها را حذف کنید، بلکه سعی بر نوشتن روایت ها به شکلی است که این وابستگی ها را کم کرد.
قابل مذاکره بودن – Negotiable
جزییات روایت ها باید قابل بحث و مذاکره باشند. روایت ها قرارداد نوشته شده ای در قالب یک سند الزامات رو به جلو نیستند، در عوض روایت ها مکان هایی برای گفتگوهستند که در آن مذاکره و بحث رخ می دهد.
روایت های خوب به وضوح ماهیت اینکه عملکرد بیزینس مورد نظر چه است و چرایی آن را ضبط می کنند. گرچه انها اتاق را برای ذینفعان، صاحب محصول و تیم جهت مذاکره و بحث روی جزییات ترک می کنند.
این قابلیت مذاکره و بحث به همه یافراد درگیر کمک می کند تا از «ما-درمقابل-آنها» و ذهنیت انگشت اشاره که در اسناد الزامات روبه جلو خیلی رایج است، پرهیز شود.زمانی که روایت ها قابل مذاکره باشند، توسعه دهنده ها براستی نمی توانند بگویند«هی، اگر تو این را میخواهی، تو باید داخل اسناد آن را قرار بدی»، زیرا که جزییات با توسعه دهندگان مذاکره می شود. و افراد بیزینس براستی نمی توانند بگویند: «هِی، تو به وضوح مستندات را درک نکردی، چرا که چیز اشتباهی را ساخته ای»، چرا که افراد بیزینس گفتگوهای مکرری با توسعه دهندگان دارند تا ابهامات برطرف شود و اطمینان حاصل کنند که وضوح به اشتراک گذاشته شده است.
مثال واضح از نقض قابلیت مذاکره جایی است که صاحب محصول می گوید چطور روایت را می سازید. روایت ها در مورد «چه what» و «چراWhy» هستند، نه «چگونهHow»! زمانی که «چگونه» غیر قابل مذاکره شود، فرصت های ابتکار عمل برای تیم کاهش می یابد.ضایعات نوآوری حاصل شده، می تواند عواقب اقتصادی مخربی داشته باشد.
با این وجود، مواقعی وجود دارد که چگونگی ساخت چیزی برای صاحب محصول مهم است. برای مثال ممکن است یک تعهد نظارتی جهت توسعه یک ویژگی در روش خاصی وجود دشاته باشد، یا یا ممکن است یک محدودیت تجاری وجود داشته باشد که استفاده از یک فناوری خاص را هدایت کند. در چنین مواردی، روایت ها ممکن است قابلیت مذاکره شان کم شود چرا که بعضی از جنبه های «چگونه» مورد نیاز است. همه روایت ها به طور کامل قابل مذاکره نیستند.، اما بیشتر داستانها باید قابل مذاکره باشند.
با ارزش – Valuable
نیاز است که روایت ها برای کاربر، مشتری یا هر جفت آنها با ارزش باشد. مشتریان (یا انتخاب کننده ها) محصول را انتخاب و برای آن هزینه می کنند. کاربران در حقیقت از محصول استفاده می کنند. اگر روایت برای هیچ کدام انها با ارزش نباشد، به Product Backlog متعلق نمی باشد. نمیشه تصور کرد که گفته بشه «روایت شماره ۱۰ باارزش نمی باشد، اما بیاید تا در هر صورت آن را بسازیم». می می توانیم یک روایت را مجدد بنمویسیم تا برای کاربر یا مشتری با ارزشش کنیم یا اینکه فقط کافیه تا آن را دور بیاندازیم.
اما در مورد روایت هایی که برای توسعه دهندگان با ارزش محسوب می شود ولی برای مشتریان یا کاربران ارزش شهودی ندارد چه باید کرد؟ خوبه که یکسری روایت فنی (technical stories) داشته باشیم که در تصویر ۹ نشان داده شده است.
مشکل اساسی با روایت های فنی این هست که صاحب محصول هیچ درکی از ارزش آنها نخواهد کرد، و اگر نتواند آنها را در برابر روایت های با ارزش بیزینس اولویت بندی کند، مشکل ساز می شود. برای وجود داشتن یک روایت فنی، صاحب محصول باید بفهمد که چرا او برای آن هزینه می کند و چه ارزشی از آن بدست خواهد آورد.
برای نمونه، روایت «مهاجرت به نسخه جدید اوراکل»، صاحب محصول احتمالا درک پایه ای از اینکه چرا تغییر پایگاه دااده ارزشمند هست، نداشته باشد.. اگر چه اگر یکی از اعضای تیم توسعه برای صاحب محصول ریسک ادامه دادن به استفاده از نسخه ای که از آن پشتیبانی نمی شود را بدهد، احتمالا صاحب محصول تصمیم خواهد گرفت که به اندازه کافی ارزش دارد که تا زمان تکمیل ارتقا، ار ساخحت ویژگی های جدید دست کشید. با درک ارزش، صاحب محصول با روایت فنی همانند دیگر روایت های ارزشمند بیزینسی رفتار خواهد کرد. به عنوان نتیجه این روایت فنی احتمالا در Product Backlogجا بگیرد.
در عمل، خیلی از روایت های فنی مانند تصویر ۱۰، نباید در Product Backlog قرار بگیرند.
در عوض این نوع روایت ها باید وظایفی (Task) باشند که به هنگام انجام روایت های تجاری (بیزینسی) با ارزش انجام می شوند.
مسئله دشوار در معیار ارزشمند بودن این هست که تمامی روایت ها در Backlogباید از چشمانداز صاحب محصول ارزشمند باشند، که ارائه دهنده چشمانداز و دیگاه مشتری و کاربر می باشد. تمام روایت ها مستقل نیستند، و تمامی روایت ها نیز قابل مذاکره نیستند، اما تمامی آنها باید ارزشمند باشند.
قابل تخمین بودن – Estimatable
روایت ها باید توسط تیمی که می خواهد آن را طراحی کند، بسازد و تست کند، تخمین پذیر باشد. تخمین ها نشان دهنده سایز و در نتیجه میزان تلاش و هزینه روایت ها می باشد (روایت های بزرگتر نیازمند تلاش بیشتر هستند و در نتیجه در مقایسه با روایت های کوچکتر، پول بیشتری برای توسعه آنها باید هزینه شود).
دانستن سایز روایت، اطلاعات عملیاتی را برای تیم اسکرام (مستند ساز) فراهم می کند. برای مصال صاحب محصول، باید هزینه روایت را بداند تا اولویت نهایی آن را در Backlog مشخص کند. از طرف دیگر، تیم اسکرام از روی سایز روایت می تواند تشخیص دهد که پلایش اضافی یا تفکیک نیاز هست یا خیر. یک روایت بزرگ که برنامه ریزی می کنیم به زودی روی آن کار کنیم، نیاز دارد که به مجموعه ای از روایت های کوچکتر تبدیل شود.
اگر روایت خیلی بزرگ بود، تیم باید با صاحب محصوپل همکاری کند تا آن را به روایت های قابل مدیریت بیشتر بشکنند. اگر دانش تم کم بود که بتواند روایت را تخمین بزند، بعضی فعالیت های اکتشافی نیاز است تا اطلاعات استخراج شود.
اندازه مناسب (کوچک) – Sized Appropriately (Small)
روایت ها باید به هنگام برنامه ریزی جهت کار روی آنها، دارای سایز مناسبی باشند. روایت ها داخل یک اسپرینت باید کوچک باشند. بهتر است که داخل یک اسپرینت چند تا روایت کوچک داشته باشید تا اینکه برای یک اسپرینت دو هفته ای یک روایت دو هفته ای داشته باشیم، چرا که ریسک تمام نشدن اسپرینت افزایش می یابد.
پس در نهایت ما نیاز به روایت های کوچک داریم، ولی فقط به دلیل اینکه روایتی بزرگ است، نشانه این نیست که روایت بدی است.
تست پذیر بودن – Testable
روایت ها در یک روش دودویی باید تست پذیر باشند، آنها تست مورد نظر را یا قبول می شوند یا مردود. تست پذیر بودن یعنی یک معیار پذیرش خوبی برای روایت داشته باشیم (مطابق با شرایط ویژگی ها)، همان جنبه «تایید-confirmation» از روایت کاربر که پیشتر در همین مقاله در مورد آن صحبت کردیم.
بدون معیار تست پذیری، چگونه بفهمیم که روایت «انجام شده» و اسپرینت پایان یافته است؟ همچنین به دلیل آنکه این تست ها اغلب شامل جزییات روایت مهمی هستند، انها احتمالا قبل از آنکه تیم بتواند روایت را تخحمین بزند، نیاز باشند.
همیشه ضروری نیست یا امکانش نیست که روایت تست شود. برای مثال روایت های حماسی «epic-size» احتمالا تستی همراهشان ارائه نمی شود، کما اینکه نیازی به تست ندارند (ما مستقیما روایت حماسی را نمی سازیم).
همچنین مواردی وجود دارد که صاحب محصول می پندارد که روایت ارشمند است، در حالی که احتمالا روشی عملی برای تست آن وجود ندارد. برای مثال «به عنوان کاربر، می خواهم که سیستم در ۹۹.۹ درصد مواقع بالا باشد». اگرچه معیار پذیرش احتمالا خیلی واضح و روشن است، منتهی مجموعه تستسی وجود نداره که به هنگام کار کردن یستم اجرا شود و اثبات کنم که سیستم ۹۹.۹ درصد دردسترس می باشد.
الزامات غیر کاربردی – Nonfunctional Requirements
الزامات غیر کاربدری بیانگر محدودیت های سطح سیستم می باشد. من اغلب نیازمندی های غیر کاربدری را به عنوان روایت کاربر می نویسم (سمت چپ تصویر ۱۱ را توجه کنید)، اما هیچ تعهدی برای انجام حس نمی کنم، به خصوص اگر غیر استادانه به نظر رسد یا نوشتن شان به قالبی دیگر خیلی راحت باشد (سمت راست تصویر ۱۱)
به عنوان محدودیت های سطح سیستم، الزامات غیر عملکردی مهم هستند زیرا که روی طراحی و تست کردن بیشتر یا همه ی روایت ها در Backlogمحصول تاثیر می گذارند. برای مثال «پشتیبانی از مروگر» الزامات غیر عملکردی است که در اغلب پروژه های تحت وب مطرح و رایج می باشد. زمانی که تیم ویژگی ها را توسعه می دهد باید از اجرا شدن ویژگی ها روی مرورگرهای خواسته شده، اطمینان حاصل کنند.
تیم همچنین باید تصمیم بگیرند که چه زمانی تمامی مرورگر ها را تست کنند. هر الزام غیر کاربردی هدفی اصلی برای گنجاندن در تعریف تیم از «Done» می باشد. اگر تیم «پشتیبانی از مرورگر» را به عنوان الزام غیرکاربردی در تعریف Done بگنجاند، تیم باید هر ویژگی جدید که به اسپرینت اضافه می شود راب رای هنخوانمی با مرورگر ها تست کند. اگر ویژگی با تمام مرورگرها سازکگار نباشد، عمل «Done» اتفاق نیافتاده است.
پیشنهاد این است تا جایی که می توانند، الزامات غیر کاربردی را در تعریفشان از «Done» بگنجانند.
روایت های کسب دانش
گاهی اوقات ما نیاز داریم تا Product backlog item بسازیم که تمرکز بر کسب دانش داشته باشد. شاید ما دانش کافی قابل بهره برداری در مورد محصول یا روند ساخت محصول چهت حرکت به جلو نداریم. پس ما نیاز به کشف و کشفیات داریم. چنین اکتشاف هایی با نام های زیادی شناخته می شوند: نمونه اولیه (prototype)، اثبات مفهوم (proof of concept)، آزمایش، مطالعه و غیره. همه شان اساسا فعالیت هایی اکتشافی برای خرید اطلاعات هستند.
اغلب یک user story را برای نقش کشف اطلاعات در نظر گرفته می شود (تصویر ۵.۱۲)
در مثال، تیم میخواهد دو معماری احتمالی را برای موتور فیلتر جدید ارزیابی کند. این پیشنهاد می شود که نمونه اولیه را از هر دو نوع معماری تهیه کرد و سپس آزمایشات سرعت، مقیاس و نوع را برای هر دو نمونه اولیه انجام داد. فرم تحویلی از سمت فعالیت نمونه سازی اولیه یادداشت کوتاهی خواهد بود که آژمایشات انجام شده را شرح می دهد.
روایت کسب دانش مانند روایت فنی به نظر می رسد و همانطور که قبلا گفته شد، ارزش تجاری هر روایت باید برای صاحب محصول قابل توجیه باشد. از آنجا که صاحبان محصول از نظر اقتصادی فکر می کنند، انجام این کار نمونه سازی باید توجیه اقتصادی داشته باشد. احتمالا استدلال فنی قانع کننده ای برای انجام یک روایت کسب دانش وجود داشته باشد زیرا تیم معمولا از پیشرفت رو به جلو عقب می ماند تا اینکه دانش تولید شده توسط روایت بدست آید. سوالی که برای تیم اسکرام مطرح است این می باشد که آیا ارزش اطلاعات بدست آمده از هزینه بدسیت آوردن آنها بیشتر است؟
در ادامه نحوه پاسخ دادن تیم اسکرام به این سوال آمده است. ابتدا تیم باید از هزینه نمونه اولیه (prototyping)مطلع شود. هیچ صاحب محصول خوبی اجازه ی اکتشاف بی حد و مرز را نخواهد داد. تیم ممکن است تا زمانی که تصمیم معماری گرفته شود، نتواند به سوالات خاص جواب دهد، اما باید بتواند به سوالات در مورد اینکه چه مقدار تلاش برای خرید اطلاعات ضروری نیاز است تا تصمیم معماری گرفته شود را بدهد. پس ما از تیم می خواهیم که رایت نمونه سازی اولیه را اندازه گیری کنند.
بگذارید بگوییم که تخمین اندازه نشان می دهد یک تیم کامل برای کار روی روایت در طول یک روایت نیاز است. ما می دانیم تیم را چه کسانی تشکیل می دهند و طول یه اسپرینت چقدر است، در نتیجه ما هزینه کسب اطلاعات را می توانیم بدست آوریم (بیاید بگیم ۱۰ هزار دلار). حال نیاز است تا ارزش اطلاعات را بدست آوریم.
حال به یکی از روش های تخمین ارزش می پردازیم. تصور کنید که یک سکه می اندازیم. اگر شیر بیاید ما معماری A را انتخاب می کنیم و اگر خط بیاید معماری Bرا. حال، من از تیم می پرسم که هزینه اشتباه را تخمین بزند. برای مثال اگر من سکه بیاندازیم و شیر بیاید و ما شروع به ساختن ویژگی های تجاری بالای معماری A کنیم، و مشخص شود که معماری A انتخاب اشتباه بوده است، هزینه ی انجام مجدد بخاطر تصمیم اشتباه و ساخت مجدد (بازسازی) معماری B چقدر است؟ بیاید در نظر بگیریم که تیم تخمین می زند ۵۰۰ هزار دلار.
در حال حاضر ما اطلاعات کافی برای تصمیم گیری منطقی اقتصادی داریم. آیا حاظریم ۱۰ هزار تا برای اطلاعاتی که ارزش آن ۲۵۰ هزار تا است هزینه کنیم (نصف مواردی که سکه می اندازیم احتمال درست بودن وجود دارد)؟ مطمینا این یک تصمیم تجاری منطقی به ظنر می رسد. اکنون صاحب محصول می تواند توجیه کند که چرا روایت در Backlog وجود دارد.
به عنوان تصویر نهایی استفاده از اقتصاد جهت توجیه کسب روایت دانش، بیاید اعدا را تغییر دهیم. اگر پاسخ تیم به این که« اگر اشتباه می کردیم چقدر هزینه می کردیم؟»، ۱۵ هزارتا باشد؟ در این صورت انجام روایت نمونه سازی اولیه انتخاب اشتباهی خواهد بود. ما ۱۰ هزار تا برای خرید اطلاعات می دهیم که ارزش مورد انتظار آن ۷.۵ هزار تا می باشد. در این حالت بهتر است فقط سکه بیاندازیم یا یک حدس از روی تحصیل و دانش بزنیم و اگر اشتباه کنیم، به آسانی کار با معماری دیگر را انجام می دهیم. در واقع با توجه به پیشرفت روزافزون تکنولوژی های امروز، این سناریو آنچنان که به نظر می رسد دور از ذهن نیست. این نمونه ای از مواردی است که مردم آن را استراتژی شکست-سریع (fail-fast strategy) می نامند (چیزی را امتحان کن، بازخورد سریع بگیر و به سرعت بازرسی کن و سازگار شو)
جمع آوری روایت ها
روایت های کاربر چگونه به وجود می آیند؟رویکردهای سنتی در گردآوری الزامات، شامل پرسیدن از کاربران است که چه می خواهند. من خودم هیچ وقت با این رویکرد خیلی موفق نبودم. از نظر من کاربران بسیار منتقدتر نسبت به نویسنده بودنشان هستند.
بنابراین اگر از یک کاربر بپرسید «چه چیزی می خواهید؟» او ممکن است قادر به پاسخ دادن باشد یا نباشد. حتی اگر او به سوال پاسخ دهد و ما نیز دقیقا چیزی که او خواسته را بسازیم، ممکن است بگوید، «بله شما دقیقا چیزی که من خواستم را ساختید و حالا که آن را دیدم، چیز دیگری می خواهم»، من به قطع مطمینم اگر تجربه برنامه نویسی داشته باشید، حتما به چنین مسئله ای برخورده اید.
رویکرد بهتر درگیر کردن کاربران به عنوان بخضی از تیمی است که تعیین می کند چه چیزی را بسازد و به صورت پیوسته چیزی که در حال ساخت است را بررسی کند. برای ارتقا این سطح از مشارکت، خیلی از شرکت ها ترجیح می دهند کارمندان نویسنده user-story به کار بگیرند تا حداقل مجموعه اولیه user-story ها را آنها تهیه کنند. بعضی حتی کارمند story mapping را به کار می گیرند تا محتوی مبتنی بر کاربر را برای روایت هایشان سازماندهی و فراهم کند. در ادامه به طور خلاصه هر یک از تکنیک ها شرح داده می شود.
کارگاه روایت کاربر نویسی
هدف اصلی از این کارگاه ایجاد طوفان فکری مشترک برای ارزش تجاری مورد نظر و ایجاد روایت کاربر برای آنچه محصول یا خدمات قرار است انجام دهد می باشد.
این کارگاه به طور مکرر شامل صاحب محصول، استاد اسکرام، تیم توسعه و در همکاری با ذینفعان داخلی و خارجی می باشد. بیشتر این کارگاه ها از چند ساعت تا چند روز ادامه دارند. هدف این نیست که یک مجموعه کامل از روایت های کاربر را در جلو لیست کنید (مانند استخراج الزامات کامل در یک پروژه آبشاری). در عوض، کارگاه به طور معمول تمرکز ویژه ای دارد. برای مثال اغلب کارگاهی آموزشی در رابطه با برنامه ریزی اولیه برای تولید روایت هایی جهت انتشار نسخه اولیه برگذار می شود.
در اوبین کارگاه معمولا با تجزیه و تحلیل نقش کاربر شروع می شود. هدف از این کار، تعیین مجموعه نقش های کاربری است که می تواند برای پر کردن بخش نقش کاربر در روایت ها استفاده شود ({به عنوان «نقش کاربر» می خواهم که })
همچنین ممکن است شخصیت هایی (personas) داشته باشیم که افراد اولیه هستند و ویژگی های اصلی یک نقش را نشان می دهند. برای مثال «لیلی» با توجه به توضیحات خودش، ممکن است شخصیتی مربوط به نقش بازیکن زن ۷ الی ۹ ساله در یک بازی ویدیووی دخترانه باشد. پس از توضیحات لیلی، ما به جای نقش انتزاعی تر «بازیکن زن جوان، »به نوشتن روایت ها با لیلی در موقعیت نقش کاربر می پردازیم. مثلا می نویسیم، «به عنوان لیلی، من می خواهم که از بین چندید لباس یکی را انتخاب کنم و در نتیجه آواتار خودم را با توجه به سلیقه خودم تنظیم کنم.»
در طول کارگاه، هیچ روش استانداردی برای تولید روایت کاربر وجود ندارد. بعضی از تیم ها تریجح می دهند از بالا-به-پایین کار کنند و باقی تریجیح می دهند از پایین به بالا. رویکرد از بالا یه پایین تیم را با شروع از روایت های بزرگ درگیر می کند (مانند epic) و سپس دغدغه شان روی تلاش بر ایجاد مجموعه ای روایت معقول کوچکتر مرتبط با epic می شود.
یک راه حل این هست که از پایین به بالا کار کنیم و بلافاصله روایت های طوفان فکری را که با انتشار بعدی از سیستم فعلی مرتبط هستند را شروع کنیم. رویکرد غلط یا درست وجود نداره، از هر رویکردی که به خوبی کار می کند استفاده کنید یا روش را تغییر دهید تا از هر دو رویکرد بهترین استفاده را کنید.
نگاشت روایت (Story Mapping)
نگاشت روایت روشی است که توسط جف پاتون در سال ۲۰۰۹ رواج پیدا کرد و برای ایجاد مجموعه ای از روایت های کاربر از دیگاه مبتنی بر کاربر استفاده می کند. ایده اصلی تجزیه فعالیت های سطح بالا کاربر یه یک گردش کاری است که بتواند با تجزیه بیشتر به مجموعه ای از وظایف دقیق تجزیه شود (شکل ۱۳)
جف پاتن از واژگانی همچون فعالیت، وظیفه و زیروظیفه (activity, task, and subtask) جهت توصیف سلسله مراتب داخل یک story map استفاده کرد. برای سازگاری با اصلاحاتی که قبلا در این مقاله معرفی شده بودند. در اینجا از epic، theme و sprintable story استفاده شده است. در بالاترین سطح، epic ها هستند که نشان دهنده فعالیت های بزرگ با ارزش اقتصادی قابل اندازه گیری هستند، به عنوان مثال «خرید یک محصول» یک epi هست. در ادامه ما در مورد دنباله یا گردش کار رایج وظایف کاربر که epic را می سازند، فکر می کنیم (که توسط مضامین – مجموعه ای از روایت های مرتبط – نشان داده می شوند). ما مضامین (موضوعات) را در امتداد یک جدول زمانی ارائه می دهیم، جایی که مضامینی (موضوعات) که به طور طبیعی در گردش کار زودتر اتفاق می افتند، سمت چپ دیگر مضامینی که دیرتر اتفاق می افتند، قرار میگیرند. برای مثال موضوع «جستجو برای محصول» سمت چپ موضوع «مدیریت سبد خرید» قرار می گیرد.
هر موضوع سپس به مجموعه ای از روایت های قابل پیاده سازی که با ترتیب اولویت در یک ستون مرتب شده اند، تجزیه می شود. تمامی روایت های داخل یک موضوع نیازی نیست حتما در انتشار نسخه اول وجود داشته باشند، برای مثال «جستجو با رنگ» ممکن است در انتشار اولیه نباشد ولی احتمالا «جستجو با نام» باشد.
نگاشت روایت، مفاهیم طراحی مبتنی بر کاربر و تجزیه روایت را ترکیب می کند. نگاشت روایت خوب، جریانی از فعالیت ها از سمت چشم انداز کاربر را شنان می دهد و محتوایی را برای فهم روایت های خصوصی و روابطشان با واحد های بزرگتر از ارزش مشتری را فراهم می کند.
مرجع اصلی فصل پنجم از کتاب:
Essential Scrum: A Practical Guide to the Most Popular Agile Process