چابک-اسکرام و نقش‌های آن

علی بهرامی‌نژاد - - زمان تقریبی مطالعه: 6 دقیقه

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

SCRUM life cycle

اخیراً خواندن کتاب Adaptive Code via C#: Agile coding with design patterns and SOLID principles را آغاز کرده‌‌ام. جمله بالا از همین کتاب انتخاب شده است. این کتاب به نظرم یکی از کتاب‌های خوب در رابطه با توسعه نرم‌افزار با استفاده از چهارچوب‌های چابک و اصول شی‌گرایی SOLID است. در فصل اول این کتاب توجه بسیار خوبی به چهارچوب اسکرام شده است و در آن نقش‌ها، فرآورده‌ها و چهارچوب کلی آن شرح داده شده است. در صفحات ابتدایی کتاب نکات بسیار جالبی نوشته شده است که آن‌ها را به شکل خلاصه در این نوشتار آورده‌ام.

نقشها و مسئولیتها

اسکرام تنها یک فرآیند است و تنها به اندازه ای کارآمد است که اعضای تیم از آن پیروی کنند. این افراد دارای نقش‌ها و وظایفی هستند که این نقش‌ها رفتار آنان را هدایت میکند. اسکرام دارای 3 نقش اصلی «مالک محصول»، «مدیر اسکرام» و اعضای تیم است.

مالک محصول – Product Owner ( به اختضار PO )

نقش مالک محصول در پروژه بسیار حیاتی است. مالک محصول ارتباط بین مشتری و تیم توسعه را فراهم می‌آورد. مالک محصول در حقیقت صاحب محصول نهایی است و بر همین اساس نقش آن شامل موار زیر می‌شود:

  1. تصمیم‌گیری در رابطه به اینکه چه ویژگی‌هایی در محصول پیاده سازی شوند
  2. اولویت‌بندی ویژگی‌ها براساس ارزش تجاری
  3. تایید یا رد کار انجام شده

PO یک ذینفع کلیدی برای موفقیت پروژه است. PO باید در کنار اعضای تیم حضور داشته باشد تا در رابطه با چشم انداز پروژه با اعضای تیم صحبت کند. اهداف بلند مدت پروژ برای تیم توسعه باید واضح باشند و تغییرات به شکل و در زمان مناسب به کل اعضای تیم منتقل شود. در برنامه ریزی کوتاه مدت اسپرینت؛ PO تعیین میکند که چه ویژگی‌هایی توسعه پیدا کنند و چه ویژگی هایی در مسیر تولید و ارائه یک نسخه مورد نیاز است. این کار با تعیین اولیت‌های بک‌لاگ محصول صورت می‌گیرد. اگرچه نقش PO نقشی کلیدیست؛ اما نفوذ کامل برروی فرآیند را اسکرام ندارد. مالک محصول نمیتواند تعیین کند که اعضای تیم به چه میزان متعهد برای هر اسپرینت هستند، زیرا این میزان از تعهد توسط تیم براساس سرعت تیم تعیین میشود. PO همچنین نحوه انجام کار را دیکته نمیکد و این تیم توسعه است که کنترل برروی نحوه پیاده‌سازی براساس یک story ( user-story یا روایت کاربر ) مشخص در سطح فنی را دارا هستند. وقتی اسپرینت در حال پیشرفت است؛ مالک محصول نمی‌تواند اهداف اسپرینت ، شرایط قابل قبول را تغییر دهد و یا یک یا چند story را حذف یا اضافه کند. اسپرینت در حال پیشرفت غیر قابل تغییر است. وقتی اهداف تصمیم‌گیری شدند و storyهای اسپرینت پس از برنامه‌ریزی تعیین شدند پس از آغاز اسپرینت امکان تغییر آن‌ها نیست. هر تغییری می‌بایست منتظر اسپرینت بعدی باشد، مگر اینکه تغییر جهت لغو اسپرینت جاری و یا پروژه بصورت کامل جهت شروع مجدد باشد، این ویژگی به تیم توسعه این امکان را می‌دهد که تمام تمرکز را برروی به ثمر رساندن اهداف اسپرینت باشد؛ اهدافی که تغییر نخواهند یافت.

در هر اسپرینت، هر میزان که storyها پیشرفت میکنند و کامل میشوند، مالک محصول درباره کارکرد یک ویژگی پرسجو می‌کند تا از کارکرد آن مطمئن شود و یا بر روی یک وظیفه در حال پیشرفت نظراتی را بیان کند. بسیار مهم است که PO در طول چرخه اسپرینت در صورت رخداد هرگونه سردرگمی یا موارد غیر منتظره ای حتماً زمانی را با اعضای تیم بگذارند. در این حالت؛ در انتهای هر اسپرینت storyهایی که از چشم‌انداز اسپرینت و اهداف آن منحرف شده باشند به PO ارائه نمی‌شوند. مالک محصول اگرچه، تصمیم می‌گیرد که کدام story مطابق با معیارهای قابل‌ پذیرش است و آیا میتوان آنرا به عنوان story کامل شده در نظر گرفت و در انتهای اسپرینت ارائه داد.

مدیر اسکرام ( Scrum Master به اختضار SM )

مدیر اسکرام؛ در طی اسپرینت، تیم را از هرگونه عوامل بیرونی که سبب حواس‌پرتی می‌شوند حفظ و موانعی که توسط تیم در جلسات روزانه اسکرام معرفی میشوند را نیز مرتفع میکند. در این صورت تیم به شکل کاملاً کاربردی و سازنده در طول چرخه اسپرینت خواهد بود و تنها برروی اهداف اسپرینت تمرکز میکند. همانطور که PO صاحب نرم افزار است؛ مدیر اسکرام نیز صاحب فرآیند و چهارچوب و چگونگی انجام فرآیند است. این وظیفه SM است که اطمینان حصال کند که اعضای تیم فرآیند اسکرام را به درستی دنبال می‌کنند. اگرچه SM توانایی ارائه پیشنهاد برای بهبود فرآیند ( مثلاً تغییر بازه اسپرینت از 4 هفته به 2 هفته ) را داراست، اما اختیارات وی محدود است. مدیران اسکرام برای مثال نمیتوانند تعیین کنند که اعضای تیم یک story را به چه شکل باید پیاده‌سازی کنند؛ اما می‌توانند از اینکه آن فرآیند اسکرام را دنبال میکند اطمینان حاصل کنند. به عنوان صاحبان فرآیند، مدیران اسکرام مالک «جلسات روزانه اسکرام» نیز هستند. SM از حضور اعزای تیم در جلسات روزانه اسکرام و یادداشت برداری اعضای تیم برای موارد کشف نشده اطمینان حاصل می‌کند، این نکته قابل ذکر است که اعضای تیم به SM گزارش نمی‌دهند و آنان در حقیقت میزان پیشرفت خود را به اعضای دیگر تیم اعلام میکنند.

تیم توسعه در حالت ایده‌آل؛ اعضای یک تیم چابک از متخصصان عمومی تشکیل شده است. یعنی هر یک از اعزای تیم به شکل چند رشته‌ای قادر به کار با چندین تکنولوژی مختلف به شکل موثر هستند. البته هریک از آنان در یک زمینه بخصوص استعداد ، ترجیح و تخصص دارند. برای مثال یک تیم میتواند شامل 4 توسعه‌گر که هر یک از آنان تونایی کارکردن با ASPNET MVC، Windows Workflow و Windows Communication Framework (WCF) دارا هستند، اگرچه دو نفر از توسعه‌گران متخصص Windows Forms هستند و افراد باقیمانده تیم نیز ترجیح میدهند برروی SQL Server و WPF کار کنند. داشتن تیمی میان-کاربردی (cross-functional) از ایجاد سیلو‌ها، وقتی یک نفر (مثلاً نفر وب، نفر دیتابیس، نفر WPF ) به تنهایی از نحوه کارکرد یک بخش از نرم‌افزار اطلاعات دارد، جلوگیری میکند. سیلوها برای تمامی افراد درگیر پروژه به هیچ وجه خوب نیستند و تاکید بسیار زیادی است، در هر زمان که مقدور باشد سیلوها تجزیه شوند. در اسکرام کد متعلق به تمام تیم است. سیلوها برای کسب‌وکار نیز مناسب نیستند زیرا وابستگی بسیار شدیدی بر روی یک منبع برای بدست آوردن ارزش بوجود می‌آورد و افراد نیز از این مورد رنج خواهند برد زیرا آنان تنها به نقش‌هایی که فقط خودشان می‌توانند انجام دهند محدود می‌شوند. تست‌کنندگان نرم افزار وظیفه نگهداری کیفیت نرم افزار در زمان تولید آن‌را دارند. قبل از شروع یکstory، تست کنندگان ممکن است در رابطه با test-plan مکانیزه جهت تایید اینکه یک story کامل شده، مطابق با معیارهای قابل‌ پذیرش است، بحث کنند. برای پیاده‌سازی تست‌ها می‌توانند همراه تیم توسعه کارکنند یا به شکل مجزا خودشان تست‌ها را بنویسند. بعد از پیاده‌سازی یک story، توسعه‌دهنده می‌تواند آنرا برای تست ارسال کند و تحلیلگر تست آن‌را بررسی و تایید کند که به شکل مورد نیاز کار میکند یا خیر.

مرغ‌ها و خوک‌ها

هر نقش در اسکرام می‌تواند به عنوان خوک یا مرغ دسته بندی‌شود. این دسته‌بندی برگرفته از داستان زیر است: مرغ به دیدار دوستش خوک می‌رود و می‌گوید: «سلام خوک، من یه ایده دارم، باید یه رستوران باز کنیم». در ابتدا خوک بسیار مشتاق هست و می‌پرسد: «خب اسمش و چی بذاریم؟» مرغ در جواب می‌گوید: «خب اسمش می‌تونیم بذاریم ژامبون خوک و تخم مرغ» خوک بعد از کمی فکر با خشم می‌گوید: «عمراً؛ من متعهد میشم اما تو فقط مشارکت می‌کنی!». این داستان، صرفاً سطح مشارکت اعضای تیم، که در پرژه به آنان نیاز است را مشخص می‌کند. خوک‌ها تماماً به پروژه متعهد شده اند و برای نتیجه آن باید جوابگو باشند؛ در حالی که مرغ‌ها مشارکتشان بصورت محیطی است. مالک محصول، مدیر اسکرام و تیم توسعه مطابق این داستان همگی خوک و متعهد به تحویل پروژه هستند. در اکثر اوقات مشتریان مرغ‌های مشارکت کننده هستند. بطور مشابه مدیر اجرایی در پروژه مشارکت دارد؛ پس آن‌های نیز مرغ محسوب می‌شوند تا خوک!

منبع

Adaptive code via csharp ebook

همانطور که در ابتدای نوشتار ذکر گردید؛ این مطالب از فصل اول کتاب Adaptive Code via C#: Agile coding with design patterns and SOLID principles گردآوری شده است.

دیدگاه‌ها