خانه / Agile / خروجی جلسات بازنگری باید شامل تصمیمات قابل انجام توسط تیم باشد

خروجی جلسات بازنگری باید شامل تصمیمات قابل انجام توسط تیم باشد

اصل دوازدهم بیانیه چابک اشاره می‌کند که تیم باید در بازه‌های زمانی مشخص و منظم در مورد اینکه چگونه می‌توانند بازده خود را بهبود ببخشند تفکر و تمرکز کنند و سپس رفتار خود را بر همین اساس تنظیم کنند:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Manifesto Principles

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

محصولی که در محیط عملیاتی منتشر شده و به دست مشتری می رسد Side effect فعالیت های تکنیکال شامد کد زدن و دیباگ کردن و فعالیت های تعاملی و ارتباطی افراد تیم است.

 

با این توضیح مختصر اگر مجدد به اصل دوازدهم نگاهی کنیم متوجه خواهیم شد که تیم در بازه هایی از زمان دورهم جمع شده و در مورد بهبود رفتار و عملکرد خود بحث و گفتگو می‌کنند. بدیهی است این بحث و گفتگوها حول دو جنبه ی تکنیکال و رفتاری خواهد چرخید.

غالبا تیم در این جلسه اشاره به نقاط ضعف و قوت خود می کند.

یک اپیدمی رایج که در همچین جلساتی مشاهده می شود این است که افراد غالبا این جلسات را مبدل به جلساتی جهت شکایت و درد و دل می کنند و پس از جلسه مجدد همان روال قبلی در تیم حاکم هست و جلسات بعدی نیز به همین منوال دنبال خواهد شد.

 


اما مشکل اصلی کجاست؟

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

 

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

 

تصمیمات می تواند به سادگی این که فلان کار را انجام ندهیم و فلان کار را انجام بدهیم باشد.

به عنوان مثالی از تصمیمات قابل انجام می توان به موارد زیر اشاره کرد:

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

 


نتیجه گیری

  • از جلسات بازنگری غافل نشویم.
  • تایم جلسات بازنگری باید کوتاه باشد و حتما منجر به تصمیمات قابل انجام شود.
  • موارد قابل بحث را محدود به موارد مهم تر کنید و سایر موارد را در جلسات بعدی بررسی کنید.

درباره ی Masoud Bahrami

همچنین ببینید

نگاهی اجمالی بر JIT

JIT(Just In Time) در این نوشتار کوتاه نگاهی اجمالی به سیستم و ایده ی ساده …

از آقا یا خانم DevOps توقع بیجا نداشته باشیم!!!

از آقا یا خانم DevOps توقع بیجا نداشته باشیم!!! احتمالا شما هم با دیدن عبارت “آقا …

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

به کانال من در تلگرام بپیوندید

اگر علاقمند به مباحث معماری و مدلسازی نرم افزار هستید می توانید به کانال تلگرام بپیوندید.

پیوستن بستن