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

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

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

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

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

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

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

سطح تیم

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

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

سطح تیم: نقش تیم توسعه

تیم توسعه

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

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

سطح تیم: نقش استاد اسکرام

استاد اسکرام

(استاد اسکرام)

«استاد اسکرام» نقش با اهمیتی برای تیم هایی است که اسکرام را پیاده سازی می کنند. استاد اسکرام تیم را در هنگام گذار به متد جدید راهنمایی کرده و به طور مداوم هدف پویای تیم را در راستای بیشینه کردن کارایی تسهیل می کند.

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

سطح تیم: تکرارها

سطح تیم

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

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

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

سطح تیم: نقش مالک محصول

مالک محصول

(مالک محصول)

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

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

سطح تیم: مجموعه ای از تیم های چابک

مجموعه ای از تیم های چابک

(مجموعه ای از تیم های چابک)

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

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

سطح تیم: تیم چابک


تیم چابک

(تیم چابک)

خط مقدم توسعه نرم افزار شامل تعدادی «تیم چابک» است که وظیفه پیاده سازی و آزمون کد را بر عهده دارند و برای ساختن سیستم های بزرگتر با یکدیگر همکاری می کنند. هر تیم چابک حداکثر دارای 5 تا 9 عضو است و شامل نقش هایی است که برای تعریف/ساخت/آزمون «ویژگی ها» و «اجزاء» نرم افزار ضروری هستند.نقش های موجود در تیم چابک شامل استاد اسکرام/چابک ، مالک محصول و تیم کوچکی از توسعه دهندگان آزمون گران، متخصصان آزمون خودکار و احتمالا رهبر فنی می باشد. تیم چابک در کار روزانه خود توسط معماران، منابع تضمین کیفیت خارجی، متخصصان مستندسازی، متخصصان پایگاه داده، پرسنل پشتیبانی مدیریت مخزن کد/ساخت/زیرساخت، تکنولوژی اطلاعات داخلی و ... پشتیبانی می شود تا با کمک آن ها بتواند بتواند به تعریف، توسعه، آزمون و تحویل نرم افزار قابل استفاده و آزمون شده بپردازد.

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

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

سطح سبد محصول

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

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

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

سطح برنامه

در این سطح، کارکرد سیستم های با مقیاس بزرگ توسط چند تیم در «قطار انتشار چابک» توسعه داده می شود. قطار انتشار چابک ریتمی استاندارد از «تکرارها» و «نقاط عطف» زمان ثابت هست که در آن ها زمان و کیفیت ثابت، اما محدوده پروژه قابل تغییر است. قطار انتشار چابک، «انتشارها» یا «بخش های قابل عرضه» را به طور مکرر در زمان های حدودا 60 تا 120 روزه ایجاد می کند. بخش های قابل ارزیابی را می توان بر مبنای ظرفیت جذب محصول جدید توسط مشتری و رویدادهای خارجی موثر بر زمانبندی انتشار داد. در این سطح «مدیر محصول» وظیفه تعریف ویژگی ها را بر  عهده دارد.

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