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

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

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

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

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

بک لاگ

(داستان ها و بک لاگ تیم)


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

داستان یک قلم کاری است که در بک لاگ تیم قرار می گیرد.

از دیدگاه مدل، «داستان یک نوع قلم بک لاگ» است.


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

سطح تیم: آزمون گران

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

سطح تیم

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

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

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

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

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

بستر معماری

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


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

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

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

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