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

شما در این سایت با مفاهیم نیازمندیهای نرم افزار چابک آشنا می شوید

سطح برنامه: مدیریت محصول

مدیریت محصول

مسئولیت های مدیر محصول چابک در سازمان های نرم افزاری شامل موارد ذیل هستند:

  • مالک چشم انداز و بک لاگ برنامه است
  • محتویات انتشار را مدیریت می کند
  • نقشه راه محصول را نگهداری می کند
  • تیمِ مدیر محصول/ مالک محصول موثری را ایجاد می کند
۰ نظر
علیرضا قاقالو

سطح برنامه: نقشه راه محصول

نقشه راه محصول

نتایج برنامه ریزی انتشار برای بروز رسانی نقشه راه محصول استفاده می شود. سازمان با استفاده از نقشه راه محصول می تواند نحوه تحویل ارزش به مشتری در طول زمان را درک کند و نسبت به آن حس پیدا نماید. نقشه راه محصول شامل مجموعه ای از تاریخ های انتشار برنامه ریزی شده است که دارای تم، مجموعه ای از اهداف و مجموعه ای از ویژگی های اولویت بندی شده است. سازمان، انتشار بعدی بر روی نقشه راه محصول را تعهد می کند و چون سایر انتشارها دارای محدوده شفافی نیستند مورد تعهد قرار نمی گیردند(به عنوان مثال: در شکل بالا اولین انتشار به دلیل داشتن محدوده مشخص توسط سازمان تعهد می شود و کار بر روی آن آغاز می گردد اما انتشارهای دوم و سوم به دلیل شفاف نبودن و احتمال تغییر محدوده مورد تعهد قرار نمی گیرند). نقشه راه محصول، هدف جاری سازمان برای انتشارهای بعدی و آینده را نمایش می دهد. هرچند، ممکن است نقشه راه محصول به دلایلی از قبیل وجود باگ، اولویت های کسب وکار و تغییر نیاز مشتریان مورد تغییر قرار بگیرد. به همین دلیل، در نقشه راه محصول فقط یک انتشار مورد تعهد قرار می گیرد و برای سایر انتشارها هیچ تعهد خارجی انجام نمی شود.
۰ نظر
علیرضا قاقالو

سطح برنامه: برنامه ریزی انتشار

هر انتشار زمان ثابت یک جلسه برنامه ریزی دارد که سازمان از آن برای هماهنگ کردن تیم ها به سوی اهداف مشترک کسب و کار استفاده می کند. چشم انداز جاری محصول (مجموعه ای از ویژگی های اولویت بندی شده) به همراه مجموعه ای از اهداف و خواسته ها، ورودی جلسه برنامه ریزی انتشار هستند.

تیم با تجزیه ویژگی ها به داستان ها و اِعمال ریتم تکرار موافقت شده و با آگاهی از سرعت خود، انتشار را برنامه ریزی می کند. تیم در طول فرایند برنامه ریزی انتشار بر روی وابستگی های داخلی خود کار می کند و داستان ها را به تکرارهای موجود در انتشار زمان ثابت تخصیص می دهد. همچنین، تیم براساس سرعت شناخته شده خود و برآوردی که برای داستان های جدید انجام داده است با مدیریت محصول در مورد محدوه سیستم مذاکره می کند تا آنچه که قابل انجام است (یا قابل انجام نیست) مشخص گردد. علاوه بر خود برنامه ریزی، نتیجه اصلی دیگر این فرایند تعهد مجموعه ای از اهداف انتشار است (به همراه مجموعه ای از ویژگی های اولویت شده). سپس، تیم تلاش می کند تعهدات خود را با دستیابی به اهداف انتشار برآورده کند.

۰ نظر
علیرضا قاقالو

سطح برنامه: محتویات اصلی چشم انداز

محتویات اصلی چشم انداز، مجموعه ای از ویژگی ها هستند

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

نیازمندی های غیرکارکردی

علاوه بر این، چشم انداز محصول باید شامل نیازمندی های غیرکارکردی از قبیل قابلیت اطمینان، صحت، کارایی، کیفیت، استاندارهای سازگاری و ... باشد(سیستم برای دستیابی به اهدافش باید این نیازمندی ها را برآورده نماید).

۰ نظر
علیرضا قاقالو

سطح برنامه: ویژگی های تحویل نشده در بک لاگ برنامه قرار می گیرند

مشابه بک لاگ محصول که حاوی «داستان ها» هستند، بک لاگ برنامه نیز حاوی «ویژگی های» اولویت بندی شده  است که هنوز پیاده سازی نشده اند. ممکن است برخی از ویژگی های موجود در بک لاگ برنامه برآورد شده باشند و برخی دیگر برآورد نشده باشند. برآورد ویژگی ها در این سطح دانه درشت و نادقیق است و لذا سرمایه گذاری بیش از حدی بر روی تشریح و تخمین زود هنگام ویژگی ها انجام نمی شود.

۰ نظر
علیرضا قاقالو

سطح برنامه: چشم انداز، ویژگی ها و بک لاگ برنامه

چشم¬انداز، ویژگی¬ها و بک¬لاگ برنامه

در سازمان، مدیر محصول وظیفه نگهداری چشم انداز محصولات، سیستم ها یا برنامه کاربردی را بر عهده دارد. چشم انداز به سوالات کلان ذیل در رابطه با سیستم، برنامه کاربردی یا محصول پاسخ می دهد:

  • چه مساله ای را این راه حل خاص حل می کند؟
  • چه ویژگی ها و مزایایی را فراهم می کند؟ 
  • برای چه افرادی این ویژگی ها و مزایا فراهم می شوند؟
  • کدام یک از نیازمندی های غیرکارکردی همانند کارایی، قابلیت اطمینان و ... را تحویل می دهد؟ 
  • کدام یک از پلتفرم ها، استانداردها، کاربردها و ... را پشتیبانی خواهد نمود؟

۱ نظر
علیرضا قاقالو

سطح برنامه: انتشارها و بخش های قابل عرضه

انتشارها  و بخش های قابل عرضه

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

علاوه بر این، دلایلی برای عرضه نکردن محصول در انتهای هر تکرار وجود دارد:

  • احتمال به وجود آمدن تداخل با قراردادهای صدور مجوز و خدمات مشتریان 
  • احتمال به وجود آمدن سربار برای مشتریان و مختل شدن کسب وکار در هنگام نصب و آموزش.
  • احتمال به وجود آمدن اختلال در عملیات موجود مشتریان به دلیل وجود نقص های کوچک.

به خاطر این دلایل، بیشتر برنامه ها یک سری تکرار را تحت عنوان بخش قابل عرضه از محصول تجمیع می کنند. این بخش از محصول با توجه به فضای جاری کسب وکار می تواند منتشر شود(یا منتشر نشود).


۰ نظر
علیرضا قاقالو

سطح تیم: وظیفه ها

تیم اسکرام داستان ها را به وظیفه ها تجزیه می کند تا بتواند فعالیت های درگیر در تحویل داستان ها را با جزئیات بیشتری پیگیری نماید. نهایتا، این وظیفه ها در جهت تکمیل داستان ها توسط اعضای تیم انجام می شوند. البته، پیگیری در سطح تکرار به جای تمرکز بر وظیفه ها باید بر روی داستان ها متمرکز باشد(به دلیل اینکه تمرکز بر داستان ها باعث تمرکز تیم بر ارزش کسب وکار می شود). وظیفه ها، ساختار شکست کار کوچکی را فراهم می کنند که به وسیله آن تیم ها می توانند هماهنگی، برآورد، پیگیری وضعیت و تخصیص مسئولیت به افراد را تسهیل کنند. علاوه بر این، وظیفه ها به ما کمک می کنند تا از تکمیل داستان ها و در نهایت تکمیل تکرار مطمئن شویم.


۰ نظر
علیرضا قاقالو

سطح تیم: بک لاگ تیم

داستان های کاربر

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

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

۰ نظر
علیرضا قاقالو

سطح تیم: داستان های کاربر

داستان های کاربر

داستان های کاربر، جایگزین چابک همه منظوره برای «نیازمندی های نرم افزار» هستند. داستان های کاربر در ابتدا توسط ایکس پی ایجاد شده اند. در چابک، داستان های کاربر اشیاء اصلی انتقال نیازمندی های مشتری از طریق جریان ارزش(از تحلیل نیازها تا کد و پیاده سازی) هستند. بر خلاف نیازمندی ها(شرح کاری که سیستم باید برای برآورده کردن نیازهای کسب وکار انجام دهد)، داستان های کاربر «عبارت های کوتاهی از هدف» هستند و آنچه که سیستم باید برای کاربر انجام دهد را توصیف می کنند. الگوی استانداردی که برای نوشتن داستان های کاربر استفاده می شود به صورت ذیل است:
به عنوان <نقش کاربر>، من می توانم <فعالیت> برای اینکه <ارزش کسب و کار>.

با این الگو، تیم می آموزد که بر روی نقش کاربر و مزیت کسب و کاری که کارکرد جدید فراهم می کند، متمرکز شود.
۰ نظر
علیرضا قاقالو