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

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

سطح تیم: توسعه دهندگان

توسعه دهندگان برای داستان کد نویسی می کنند. آن ها برای انجام این کار ممکن است با توسعه دهنده دیگر به صورت دو نفره کدنویسی کنند، همچنین ممکن است با یک آزمون گر به صورت دو نفره کار کنند و یا ممکن است به طور کاملا مستقل عمل کند و با چندین توسعه دهنده و آزمون گر ارتباط داشته باشد. در هر صورت مسئولیت های یکسانی دارد و شامل موارد ذیل می باشد:

  • با مالکان محصول و آزمونگران برای اطمینان از درستی کد نوشته شده  تعامل می کند
  • کدنویسی می کند
  • برای کد، آزمون واحد می نویسد و آن را اجرا می کند
  • در صورت نیاز متدهایی را برای پشتیبانی آزمون های پذیرش خودکار و سایر آزمون های خودکار می نویسد
  • هر روز کد جدید را در مخزن مشترک ثبت می کند

به علاوه، توسعه دهنده به طور فعال در بهبود محیط توسعه مشارکت می نماید.

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

سطح تیم: استاد اسکرام/ استاد چابک

اسکرام در مورد این نقش کاملا خاص است و برای افرادی که این نقش را برعهده می گیرند آموزش تخصصی و عنوان خاصی(استاد اسکرام) را

در نظر می گیرد. به طور خلاصه استاد اسکرام مسئول انجام کارهای ذیل می باشد:

  • پیشروی تیم به سوی هدف را تسهیل می کند
  • تیم را به سوی بهبود مداوم رهبری می کند
  • قواعد فرایند چابک را اجرایی می کند 
  • موانع را از بین می برد
۰ نظر
علیرضا قاقالو

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

مالک محصول در اسکرام مسئول تعریف و اولویت بندی نیازمندی ها است، به همین دلیل یک نقش حیاتی در تیم چابک به شمار می آید. به طور خلاصه مالک محصول مسئول انجام کارهای ذیل است: 

  • برای تعیین نیازمندی ها با مدیران محصول، تحلیلگران کسب و کار، مشتریان و دیگر ذینفعان همکاری می کند. 
  • بگ لاگ محصول را نگهداری و اولویت ها را براساس ارزش نسبی کاربر مشخص می کند. 
  • اهداف تکرار را مشخص می نماید. 
  • داستان ها را تشریح می کند، در بررسی های پیشرفت مشارکت می نماید و داستان های جدید را می پذیرد.
۰ نظر
علیرضا قاقالو

سطح تیم: حذف سیلوهای کارکردی

سیلوهای کارکردی

(سازماندهی تیم ها به صورت سیلوهای کارکردی)

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

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

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

سازمندهی مجدد سیلوهای کارکردی به تیم های چابک

(سازماندهی مجدد سیلوهای کارکردی به تیم های چابک)

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

سطح تیم: چرخه عمر داستان

چرخه عمر داستان

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

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

سطح تیم: چرا در مورد تیم ها صحبت می کنیم؟

سطح تیم

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

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

همه اعضای تیم، اساساً در تعریف نیازمندی ها، بهینه سازی نیازمندی ها و مصالحه های طراحی، پیاده سازی، آزمون، تجمیع و تحویل آن ها به مشتریان درگیر هستند. این کار تنها هدف تیم است.

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

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

بستر معماری

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


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

سطح سبد محصول: اپیک ها و بک لاگ سبد محصول

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

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

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

تم های سرمایه گذاری

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

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

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

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

مدیریت محصول

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

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