شکستن اپیک ها و ویژگی ها به داستان های کوچک تر

اپیک­ ها و ویژگی­ ها داستان­ های بزرگی هستند که قصد داریم برای کاربر انجام دهیم. اغلب این داستان­ های با ارزش و بزرگ را در طول فرایند استخراج کشف می­ کنیم و در بک ­لاگ قرار می ­دهیم. این داستان­ ها معمولا برای پیاده ­سازی در یک تکرار بزرگ­ اند و تیم آن ­ها را به داستان­ های کوچک ­تری می ­شکند تا پیاده­ سازی آن­ ها ممکن شود. مجموعه­ ای روتین برای شکستن اپیک­ ها و ویژگی ­ها وجود ندارد. اما می­ توانید از «ده الگوی رایج برای شکستن داستان­ های کاربر» استفاده کنید.

1- گام ­های گردش کار

گام­ های خاصی که کاربر برای انجام گردش کار طی می­ کند را شناسایی کنید و سپس گردش کار را به صورت تدریجی پیاده­ سازی کنید.

As a utility, I want to update and publish pricing programs to my customer.

• . . . I can publish pricing programs to the customer’s in-home display.
• . . . I can send a message to the customer’s web portal.
• . . . I can publish the pricing table to a customer’s smart thermostat.

 

2- متنوع بودن قاعده کسب و کار

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

As a utility, I can sort customers by different demographics.

• . . . sort by ZIP code.
• . . . sort by home demographics.
• . . . sort by energy consumption.

3- تلاش عمده

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

As a user, I want to be able to select/change my pricing program with my utility through my web portal.

• . . . I want to use time-of-use pricing.
• . . . I want to prepay for my energy.
• . . . I want to enroll in critical-peak pricing.

4- ساده/پیچیده

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

As a user, I basically want a fixed price, but I also want to be notified of critical-peak pricing events.

• . . . respond to the time and the duration of the criticalpeak pricing event.
• . . . respond to emergency events.

5- تنوع داده­ ها

تنوع داده­ ها و منابع داده­ ها، منبعی دیگر برای محدوده و پیچیدگی هستند. داستان­ هایی را در نظر بگیرید که به موقع پس از ساختن ساده ­ترین نسخه اضافه می­ کنید. مثال محلی ­سازی در اینجا آمده است:

As a utility, I can send messages to customers.

• . . . customers who want their messages:
• . . . in Spanish
• . . . in Arabic, and so on.

6- روش­ های ورود داده­ ها

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

As a user, I can view my energy consumption in various graphs.

• . . . using bar charts that compare weekly consumption.
• . . . in a comparison chart, so I can compare my usage to those who have the same or similar household demographics.

7- به تعویق انداختن کیفیت ­های سیستم

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

As a user, I want to see real-time consumption from my meter.

• . . . interpolate data from the last known reading.
• . . . display real-time data from the meter.

8- عملیات­ (به عنوان مثال: ایجاد، خواندن، به روز رسانی و حذف کردن)

کلماتی همانند «مدیریت» و «کنترل» نشان می ­دهند که داستان چندین عملیات را پوشش می ­دهد. در این حالت می­ توانیم یک روش طبیعی برای تقسیم داستان پیشنهاد کنیم.

As a user, I can manage my account.

• . . . I can sign up for an account.
• . . . I can edit my account settings.
• . . . I can cancel my account.
• . . . I can add more devices to my account.

9- سناریوهای مورد کاربرد

اگر موارد کاربرد ایجاد شده­ اند تا تعامل پیچیده­ بین کاربر با سیستم یا سیستم با سیستم را نشان ­دهند، در این حالت می­ توان داستان را براساس سناریوهای منفرد مورد کاربرد به داستان­ های کوچک ­تر شکست.

I want to enroll in the energy savings program through a retail distributor.

• Use case/story #1 (happy path): Notify utility that consumer has equipment.
• Use case/story #2: Utility provisions equipment and data and notifies consumer.
• Use case/story #3 (alternate scenario): Handle data validation errors.

10- انجام اسپایک

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