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

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

۶ مطلب در اسفند ۱۳۹۷ ثبت شده است

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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