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

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

۲ مطلب در تیر ۱۳۹۸ ثبت شده است

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

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

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

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

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

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

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

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

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

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

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

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

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