اپیک ها و ویژگی ها داستان های بزرگی هستند که قصد داریم برای کاربر انجام دهیم. اغلب این داستان های با ارزش و
بزرگ را در طول فرایند استخراج کشف می کنیم و در بک لاگ قرار می دهیم. این داستان ها
معمولا برای پیاده سازی در یک تکرار بزرگ اند و تیم آن ها را به داستان های کوچک تری
می شکند تا پیاده سازی آن ها ممکن شود. مجموعه ای روتین برای شکستن اپیک ها و ویژگی ها
وجود ندارد. اما می توانید از «ده الگوی رایج برای شکستن داستان های کاربر» استفاده کنید.
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- انجام اسپایک
در برخی
موارد، داستان ممکن است خیلی بزرگ یا خیلی پیچیده باشد و یا شاید درک کمی در
مورد پیاده سازی آن وجود داشته باشد. در این مورد، از اسپایک فنی یا کارکردی
استفاده می شود و سپس براساس نتیجه بدست آمده داستان شکسته می شود.
|