تمرین تیم‌سازی در چارچوب Scrum

پیشرفت از دل چالش‌ها، تجربه تنظیم Working Agreement برای یک تیم دیجیتال

داستان یک تیم پرچالش: تنظیم Working Agreement

مقدمه

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

در این داستان، از طریق پرسشنامه‌ای که برای تنظیم یک Working Agreement استفاده شده، وضعیت تیم «بلندپروازان دیجیتال» را بررسی می‌کنیم.


فصل ۱: اهداف و رویکرد تیم

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

  • «هدف این اسپرینت چیست؟ چرا ما این کارها را انجام می‌دهیم؟»

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

پاسخ تیم:
در جلسه‌ای که اسکرام‌مستر (کاترین) ترتیب داد، تیم تصمیم گرفت که هدف اسپرینت را هر هفته با همکاری مالک محصول (PO) شفاف‌سازی کند و هر روز در دیلی اسکرام روی آن تمرکز کنند.


فصل ۲: ارتباطات درون تیمی

ارتباطات تیم به شدت تحت تاثیر عدم شفافیت و ابزارهای پراکنده قرار داشت. تیم از چندین ابزار مختلف (ایمیل، پیام‌رسان، Trello) برای برقراری ارتباط استفاده می‌کرد که باعث سردرگمی و اتلاف وقت می‌شد.

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

پاسخ تیم:
تیم تصمیم گرفت که تمامی ارتباطات باید از Slack برای هماهنگی استفاده شود و برای مسائل بحرانی حتماً اعضای تیم باید در ۱۲ ساعت به هم پاسخ دهند. برای مسائل غیرضروری، ایمیل یا پیام‌های طولانی‌تر ارسال می‌شد.


فصل ۳: میزان دسترسی و هماهنگی

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

در یکی از روزها، آلیس که در ساعت ۹ شب مشغول حل یک مشکل فنی بود، متوجه شد که برای پیاده‌سازی یک ویژگی جدید باید با تام هماهنگ شود. ولی از آنجایی که تام به خواب رفته بود، هماهنگی به تعویق افتاد و این باعث تاخیر در تکمیل وظایف شد.

پاسخ تیم:
تیم تصمیم گرفت که ساعات کاری هماهنگ (مثلاً ۱۰ صبح تا ۳ بعد از ظهر) را تعیین کنند تا در این ساعات، تمام اعضای تیم به راحتی به یکدیگر دسترسی داشته باشند.


فصل ۴: نحوه مدیریت تصمیمات فنی و کیفیت

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

در جلسه‌ای که اسکرام‌مستر برگزار کرد، این سوال مطرح شد:

  • چگونه تصمیمات فنی بهتری بگیریم؟

پاسخ تیم:
تیم توافق کرد که تصمیمات فنی باید از طریق اجماع عمومی (Consent) اتخاذ شوند. اعضای تیم باید تمامی گزینه‌های سند‌DOD را بررسی کنند و تصمیم‌گیری با بررسی و اسپایک انجام شود.
تیم باید تعریف شفاف و مشترک از Definition of Done و معیارهای کیفیت (تست‌های خودکار، بازبینی کد) ایجاد کند و آن را در هر اسپرینت مرور کند. باید از فرآیند مذاکره و اجماع استفاده کنیم و اگر نظر فردی همچنان متفاوت بود، از Test/Experiment (اسپایک) استفاده کنیم.


فصل ۵: فرآیندهای توسعه و همکاری

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

پاسخ تیم:
تیم توافق کرد که برای هر اسپرینت، کارها به‌طور مساوی بین اعضا تقسیم شوند و از روش‌های Pair Programming برای انتقال مهارت‌های جدید به دیگران استفاده کنند.


فصل ۶: رتروسپکتیو و بازبینی فرآیندها

یکی از اعضای تیم، مایکل، در یک رتروسپکتیو به مشکل اشاره کرد:

«ما هیچ‌وقت از اشتباهاتمان یاد نمی‌گیریم و فقط از آن‌ها رد می‌شویم.»

تیم به این نتیجه رسید که فرآیند رتروسپکتیو به‌درستی انجام نمی‌شود و بازخورد کافی برای بهبود نهایی از مشکلات گرفته نمی‌شود.

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


نتیجه‌گیری

تیم «بلندپروازان دیجیتال» پس از مشکلات اولیه و اختلافات متعدد، موفق شد که Working Agreement خود را تنظیم کند. با اجرای این توافقات، بسیاری از مشکلات ارتباطی و مدیریتی تیم حل شد و به تدریج تیم توانست هماهنگ‌تر و مؤثرتر عمل کند.

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

پرسشنامه جامع برای تنظیم Working Agreement

برای تنظیم یک Working Agreement موثر و جامع که تیم‌های اسکرام بتوانند به‌طور مؤثر با یکدیگر همکاری کنند، نیاز است که تمامی جوانب همکاری، فرآیندهای تیمی، تعاملات و تعهدات مشترک بررسی شوند. در اینجا یک پرسشنامه جامع برای تنظیم Working Agreement ارائه می‌شود که تمامی ابعاد کلیدی را پوشش می‌دهد و می‌تواند به تیم‌ها کمک کند تا قواعد مشترک و شفاف را برای همکاری روزانه خود تعریف کنند.

پرسشنامه جامع برای تنظیم Working Agreement

1. اهداف و رویکرد تیم

  • هدف اصلی تیم ما چیست و چگونه می‌توانیم بهترین نتیجه را در هر اسپرینت ارائه دهیم؟
  • آیا اهداف اسپرینت همیشه برای همه اعضای تیم شفاف و قابل‌فهم است؟
  • چه اقداماتی می‌توانیم انجام دهیم تا در مسیر دست‌یابی به هدف اسپرینت هماهنگ‌تر عمل کنیم؟
  • آیا تیم در هنگام مواجهه با چالش‌ها به سرعت با هم هماهنگ می‌شود؟

2. ارتباطات درون تیمی

  • بهترین روش برای برقراری ارتباط در تیم چیست؟ (جلسات دیلی، Slack، ایمیل و…)
  • چه زمانی باید از جلسات رسمی (مثل دیلی اسکرام، رتروسپکتیو و…) استفاده کنیم و چه زمانی از ارتباطات غیررسمی؟
  • چگونه مطمئن شویم که تمام اعضای تیم فرصت بیان نظر خود را دارند؟
  • در صورت بروز سوءتفاهم یا تعارضات، چگونه باید آن‌ها را شفاف و محترمانه حل کنیم؟
  • در صورت نبود پاسخ سریع از یک عضو تیم، چه زمانی باید اقدام کنیم؟

3. میزان دسترسی و هماهنگی

  • ساعات کاری تیم چگونه است و چه زمان‌هایی برای همکاری بیشتر در دسترس هستیم؟
  • چه مدت زمان لازم است تا اعضای تیم به یکدیگر پاسخ دهند؟
  • چه کانال‌های ارتباطی را برای هماهنگی بهتر در نظر می‌گیریم؟ (کانال‌های Slack، ایمیل، جلسات و…)
  • آیا برای ملاقات‌های خارج از ساعات رسمی (جلسات اضطراری، جلسات تفکر گروهی) باید توافقی داشته باشیم؟

4. نحوه مدیریت تصمیمات فنی و کیفیت

  • چگونه باید تصمیمات فنی اتخاذ کنیم؟ (اجماع، رضایت کافی، یا تصمیم‌گیری توسط شخص خاص)
  • چه معیاری برای تعیین کیفیت کار داریم؟ (مثلاً Definition of Done، تست‌های خودکار، بازبینی کد)
  • اگر فردی در تیم نظری متفاوت از دیگران داشته باشد، چگونه می‌توانیم به اجماع برسیم؟
  • آیا باید برای تکنولوژی‌های خاص، ابزارها یا روش‌های استفاده از آن‌ها در تیم استانداردهایی تعیین کنیم؟
  • چه فرآیندهایی باید برای ارزیابی کیفیت کد و جلوگیری از خطاهای احتمالی پیاده‌سازی کنیم؟

5. فرآیندهای توسعه و همکاری

  • چگونه برای هر اسپرینت کار را تقسیم می‌کنیم؟
  • چه مقدار از زمان اسپرینت باید به کارهای مربوط به یادگیری، مستندسازی و بررسی کیفیت اختصاص یابد؟
  • آیا روش‌هایی مانند Pair Programming یا Mob Programming برای همکاری بهتر و انتقال مهارت مناسب است؟
  • آیا می‌خواهیم برای پیاده‌سازی ویژگی‌ها از رویکردهایی مانند T-Shaping استفاده کنیم تا همه اعضای تیم بتوانند روی بخش‌های مختلف محصول کار کنند؟
  • چگونه می‌توانیم وابستگی‌ها بین کارهای مختلف را مدیریت کنیم و اطمینان حاصل کنیم که هر کسی روی وظایف خود متمرکز است؟

6. مدیریت زمان و اولویت‌بندی

  • چگونه تصمیم می‌گیریم که کدام آیتم از بک‌لاگ اسپرینت اولویت بیشتری دارد؟
  • چه روش‌هایی برای زمان‌بندی کارها و تعیین WIP (Work In Progress) استفاده خواهیم کرد؟
  • آیا در هنگام بروز موانع یا تأخیر، چه اقداماتی باید انجام دهیم؟
  • چه زمانی باید از روش‌هایی مثل Escalation برای حل مشکلات استفاده کنیم؟

7. مشارکت و یادگیری تیمی

  • چگونه اعضای تیم را تشویق کنیم که مهارت‌های جدید یاد بگیرند و هم‌زمان با هم رشد کنند؟
  • آیا هر کسی مسئولیت‌هایی در حوزه‌های مختلف (به غیر از تخصص خود) را به عهده می‌گیرد؟
  • آیا باید زمان‌هایی را برای یادگیری گروهی در نظر بگیریم (مثلاً جلسات آموزشی، خواندن مستندات و…)؟
  • آیا اعضای تیم باید به‌طور مداوم با یکدیگر بازخورد بدهند تا عملکردشان بهتر شود؟

8. رتروسپکتیو و بازبینی فرآیندها

  • چه مدت پس از پایان هر اسپرینت باید جلسات رتروسپکتیو برگزار شود؟
  • چه فرآیندهایی باید بررسی شوند تا اطمینان حاصل کنیم که تیم به بهبود مستمر متعهد است؟
  • چگونه می‌توانیم ایده‌های جدید برای بهبود عملکرد تیم به کار بگیریم؟
  • آیا می‌خواهیم روی موارد خاصی در هر رترو تمرکز کنیم (مانند توسعه مهارت‌ها، ارتباطات بهتر، کیفیت کد و …)؟

9. حمایت از اعضای تیم و رفاه

  • چگونه می‌توانیم از یکدیگر حمایت کنیم که استرس کمتری داشته باشیم و در نتیجه کار باکیفیت‌تری ارائه دهیم؟
  • آیا تیم نیاز به زمان‌های استراحت یا فاصله‌هایی برای جلوگیری از فرسودگی شغلی دارد؟
  • چه اقداماتی برای حفظ تعادل کار و زندگی اعضای تیم در نظر گرفته‌ایم؟

10. تغییرات و انطباق با شرایط جدید

  • در صورتی که به‌طور موقت یا دائم شرایط کاری تغییر کرد (برای مثال، تغییر در تیم، محصولات یا فناوری‌ها)، چگونه باید پروسه‌های کاری را به‌روزرسانی کنیم؟
  • چگونه باید موازی‌کاری و هماهنگی با دیگر تیم‌ها را انجام دهیم؟
  • چه زمانی باید قراردادهای کاری، قوانین و توافق‌ها را بازبینی و اصلاح کنیم؟

توصیه‌های تکمیلی

  • تیم باید از این پرسش‌ها برای آغاز کار و پس از هر رتروسپکتیو استفاده کند و به‌طور منظم به روزرسانی‌های مورد نیاز را انجام دهد.
  • این پرسشنامه می‌تواند در جلسات آغازین تیم برای تعریف پایه‌ای از توافقات کاری استفاده شود و به‌طور دوره‌ای در رتروسپکتیو بازبینی شود.
  • پیشنهاد می‌شود که تمام اعضای تیم در فرآیند تدوین Working Agreement مشارکت کنند تا احساس مالکیت و تعهد جمعی در تیم ایجاد شود.

این پرسشنامه به تیم کمک می‌کند تا یک قالب شفاف، کارا و هم‌راستا با اهداف مشترک برای همکاری و تعاملات روزانه خود تنظیم کند و پایه‌گذار تعاملات موفق و کارآمد شود.


منتورینگ رایگان مالکین محصول

«اگر در یک شرکت نرم‌افزاری مشغول به کارهای روزانه یک PO هستید و دوست دارید در مورد پیاده‌سازی اجایل، اسکرام و چالش‌های نقش PO در چهارچوب اسکرام یا تفکر استراتژیک در محصول، راهنمایی و مشاوره بگیرید، در خدمتتون هستم. یک وقت در adplist بگیرید.»


دیدگاه‌ها

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

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

error: اجازه کپی محتوا وجود ندارد