اسکرام چیست؟

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

Agile یک طرز تفکر در زمینهٔ فرایند توسعهٔ نرم‌افزار است که در واقع چیزی جز ارزش‌های زیر نیست:

- ارزش افراد و تعاملات بیشتر از ابزارها و فرآیندها است.
- ارزش نرم‌افزاری کارا بیشتر از یک مستندسازی عالی است.
- ارزش همکاری با مشتری بیشتر از قرارداد کاری است.
- ارزش پاسخگویی به تغییرات بیشتر از پیروی از یک طرح پیش‌نویس است.

بنابراین در یک محیط اجایل (چابک) باید این ارزش‌ها برقرار باشند که اسکرام یکی از رویکردهای دربرگیرندهٔ روش‌هایی است که با پیروی از آن‌ها در پروژه‌های نرم‌افزاری می‌توان به اصول و ارزش‌های تفکر چابک دست یافت و پروژه‌های نرم‌افزاری خود را به شکلی اصولی پیش برد (Scrum اسم خاص است و معنی لغوی ندارد اما اصطلاحاً به «شروع دوبارهٔ بازی راگبی» که به هر دلیلی مثل خطا یا بیرون افتادن توپ متوقف شده باشد اسکرام گفته می‌شود و شاید وجه‌تسمیهٔ این رویکرد توسعهٔ نرم‌افزار هم شباهت فرآیند تکرارشونده کدنویسی با این فرآیند باشد که در بازی راگبی بازیکن‌ها دور هم جمع می‌شوند، سرشان را پایین می‌گیرند و احتمالاً پس از گفت‌وگو و هماهنگی‌های لازم، بازی را مجدد شروع می‌کنند.)

روی هم رفته، با پیروی از یکسری اصول می‌تواند تیم‌های توسعهٔ نرم‌افزار را به معنای واقعی کلمه چابک کرد که در ادامه برخی از کلیدی‌ترین ابزارهای اسکرام را معرفی خواهیم کرد.

به نقش تک‌تک اعضای تیم توجه کنید
نقش‌هایی که به طور دقیق و شفاف تعریف شده‌اند، در به‌کارگیری بهتر اسکرام مؤثرند. بدون توجه به اینکه عنوان شغلی شما در تیم چه می‌تواند باشد، در اسکرام این سمَت‌ها به مدیر اسکرام (Scrum Master)، مالک محصول (Product Owner) و اعضای تیم توسعه (Development Team) محدود می‌شوند. اعضای تیم توسعه می‌توانند عناوین شغلی دیگر را هم داشته باشند، اما در یک آنِ واحد باید تنها یک نقش را بر عهده گیرند.

مالکان محصول گزارش درخواست‌های مشتری (User Stories) را می‌نویسند، به منظور اطلاع از نیازهای تجاری با ذی‌نفعان گفتگو می‌کند و فهرست سفارشات محصول (Product Backlog) را به ترتیب اولویت حفظ می‌کنند. مدیر اسکرام، رویدادهای اسکرام (Scrum Event) را سازماندهی می‌کند و موانع اِسپرینت را شناسایی و برطرف می‌کند (در پروسهٔ اسکرام، برای تولید یک محصول چند فرایند تکرار در نظر گرفته می‌شود و در پایان دورهٔ زمانی هر فرایند تکرار، یک دستاورد قابل‌ارائه وجود دارد که به این دوره‌های زمانی تکرارشونده Sprint گفته می‌شود.) اعضای تیم توسعه وارد عمل شده و سند سفارشات اِسپرینت را آمادهٔ تحویل می‌کنند و هر کس نقشی را بر عهده می‌گیرد و لازم به ذکر است که هر فرد جزئی اساسی و جدایی‌ناپذیر از یک تیم اسکرامی است و هیچ دولوپری نسبت به بقیه برتری ندارد.

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

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

رویدادهای اسکرام
مزیت دیگر اسکرام این است که از فعالیت‌هایی که به طور واضح تعریف شده‌اند (Scrum Event) تشکیل شده است به طوری که این فعالیت‌ها برنامه‌ریزی اِسپرینت، جلسات روزانه، اصلاح فهرست درخواست‌ها، مرور و بازنگری اِسپرینت را در بر می‌گیرند. اگر تیم شما به تازگی کار با اسکرام را آغاز کرده است، اجرای این رویدادها در کنار هم به موفقیت زودهنگام شما کمک خواهد کرد و اگر تیم شما مدتی است که از اسکرام استفاده می‌کند، می‌تواند شما را در تمرکز مجدد بر این رویدادها و اطمینان از اینکه به تمام ارزش‌های آن‌ها دست خواهید یافت، یاری کند.

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

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

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

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