logo_largelogo_largelogo_largelogo_large
  • خانه
  • چشم‌انداز
  • دانش‌نامه
  • منابع آموزشی
  • مقاله‌ها
  • دوره‌های تخصصی
  • بازگفت‌های ناب و چابک
  • تماس با ما
ثبت‌نام دوره
✕

شکستن اپیک ها و ویژگی ها

27 تیر 1399

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

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

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- انجام اسپایک

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

Share
علیرضا افشار

علیرضا افشار

Related posts

24 مرداد 1399

تفکر ناب


Read more

دیدگاهتان را بنویسید لغو پاسخ

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

نیازمندی­‌های چابک

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

اطلاعات تماس


جهت تماس با ما از روش‌های زیر یا صفحه تماس با ما استفاده کنید.

۰۹۳۶۴۳۳۱۷۰۸
Agile.Requirement@gmail.com

تمامی حقوق برای سایت نیازمندی‌های چابک محفوظ است.
ثبت‌نام دوره