مترجم: مهندس علیرضا اسماعیلی
بخش اول
بخش دوم
بخش سوم
بخش چهارم
بخش پنجم
بخش ششم
۱-۵-اجرای اسپرینت(Sprint execution)
پس از برنامهریزی اسپرینت و توافق در مورد دستور کار اسپرینت جاری، تیم توسعه وظیفهها(Task) را با هدایت استاد اسکرام انجام میدهد، با این هدف که ویژگیها به عنوان «انجامشده»(Done) پذیرفته شوند. «انجامشده» بدین معناست که کارهای لازم برای توسعهی یک ویژگی با کیفیت، با درجهی بالایی از اطمینان انجام شده است.
وظایفی که تیم انجام میدهد، دقیقاً به ماهیت کار بستگی دارد. برای نمونه میتواند کارهای صرفاً نرمافزاری یا ترکیب آن با کارهای سختافزاری و حتی کارهای بازاریابی باشد.
چگونگی و ترتیب انجام وظیفهها را کسی به تیم توسعه تحمیل نمیکند. بلکه اعضای تیم، کارها و وظایفشان را تعریف نموده و سپس خود را به بهترین شیوه برای تحقق اهداف اسپرینت سازماندهی میکنند.
۱-۶-اسکرام روزانه(Daily Scrum)
اعضای تیم توسعه، جلسه‌ی «اسکرام روزانه» را در هر روز از اسپرینت و ترجیحاً در یک زمان مشخص برگزار می‌نمایند که مدت آن ثابت و حداکثر 15 دقیقه است. برای ترغیب به کاهش زمان جلسه، افراد آن را به صورت ایستاده برگزار میکنند و از این رو آن را «جلسه ایستاده روزانه»(Daily stand-up) نیز مینامند.
رویکرد رایج در اجرای اسکرام روزانه این است که هر یک از اعضای تیم برای اطلاع دیگران به کمک استاد اسکرام و به سه پرسش زیر پاسخ میدهد:
○ بعد از اسکرام روزانه‌ی قبلی، چه کارهایی را انجام داده‌ام؟
○ تا اسکرام روزانه‌ی بعدی، چه کارهایی را برنامهریزی کرده‌ام؟
○ چه مشکلات و موانعی جلوی پیشرفت مرا می‌گیرند؟
با پاسخ هر یک از اعضا، دیگر اعضای تیم در جریان کلی امور، میزان تحقق اهداف اسپرینت، تغییرات برنامه‌ی روز جاری و کارهای ضروری و فوری قرار می‌گیرند. اسکرام روزانه امری مهم برای کمک به تیم و به منظور مدیریت سریع و منعطف کارهای اسپرینت است.
اسکرام روزانه جلسه‌ای برای حل مشکلات نیست. در بسیاری از تیمها گفت‌وگو درباره‌ی مشکلات پس از جلسه و در گروه‌هایی کوچک با حضور افراد علاقه‌مند به موضوع انجام می‌شود. اسکرام روزانه با جلسات مرسومِ گزارش وضعیت کار در پروژه‌ها متفاوت است؛ به‌ویژه جلساتی که اغلب به دعوت مدیر پروژه و برای به‌روزرسانی وضعیت پروژه برگزار می‌شود. با وجود این تفاوت، اسکرام روزانه نیز برای اطلاع‌رسانی وضعیت اقلام بک‌لاگ به اعضای تیم مفید است. اساساً اسکرام روزانه فعالیتی برای «بازرسیِ» برنامهریزی روزانه، ایجاد هماهنگی و تطبیق آن با شرایط جاری است که به تیم خودسازمانده(Self-organizing team) در انجام بهتر کارها کمک میکند.
اسکرام از تمثیل «خوک» و «مرغ» استفاده میکند تا افراد شرکت‌کننده در اسکرام روزانه را به دو دسته تقسیم کند: دسته اول افرادی هستند که باید مشارکت و حضوری فعال داشته باشند (افراد اصلی) و دسته دوم افرادی که فقط می‌توانند شنونده باشند (افراد فرعی). حیوانات مزرعه از یک داستان قدیمی اقتباس شده‌اند: «خوک و مرغ تصمیم می‌گیرند تا شریکی رستورانی تأسیس کنند. مرغ پیشنهاد میکند که فهرست غذای آنها شامل ژامبون گوشت (سهم خوک) و تخم‌مرغ (سهم مرغ) باشد. خوک با این پیشنهاد مخالفت میکند، چرا که سهم آن دو در شراکت به یک اندازه نیست. خوک برای تهیه ژامبون گوشت باید از جانش (گوشتش) مایه بگذارد ولی مرغ نیازی ندارد که از جانش مایه بگذارد و فقط کافی است که تخم بگذارد.» در اینجا، «مرغ فقط مشارکت میکند، در حالی که خوک متعهد (Committed) است و باید از جانش مایه بگذارد». روشن است که کاربرد چنین تمثیلی در اسکرام، جداکردن افراد فرعی (مرغ‌ها) از افرادی اصلی (خوک‌ها) است که متعهد به تحقق اهداف اسپرینت هستند. در اسکرام روزانه، فقط خوک‌ها مجازند صحبت کنند و مرغ‌ها و افراد دیگر فقط به عنوان شنونده حضور دارند.
اگر چه بسیاری با این موضوع موافق نیستند، اما به تجربه پی‌برده‌ام که تعیین جایگاه تمثیلی اعضای تیم اسکرام در قالب خوک یا مرغ بسیار مهم است. برای نمونه در اسکرام، حضور مالک محصول در اسکرامِ روزانه اجباری نیست، پس وی نقش مرغ را دارد؛ حال این پرسش پیش می‌آید که «چگونه وی میتواند متعهد باشد، در حالی که الزامی به حضور وی نیست؟» با این استدلال، «اجباری نبودن حضور مالک محصول در جلسه اسکرام روزانه» نادرست خواهد بود. قابل پذیرش نیست که مالک محصول به عنوان عضوی از تیم اسکرام، تعهد کمتری از تیم توسعه در قبال نتایج اسپرینت داشته باشد. اگر قصد دارید این موضوع یعنی حضور اختیاری مالک محصول را اعمال کنید، به تمثیل خوک و مرغ فکر کنید و از این کار منصرف شوید.
۱-۷-انجامشده (Done)
نتیجه‌ی هر اسپرینت بخشی از محصول است که بالقوه قابل عرضه است و بدین معناست که هر آن چه که قرار بود تیم اسکرام انجام دهد، بر اساس توافق صورت گرفته در مورد واژه‌ی «تعریف انجامشده» (Definition of Done)، واقعاً تمام شده است. این واژه درجهی اطمینان از کیفیت و قابل عرضه بودن کارهای تمام‌شده را مشخص میکند. برای مثال واژه‌ی «انجامشده» در توسعهی نرم‌افزار میتواند به معنای طراحی، ساخت، یکپارچه‌سازی، آزمایش و مستندسازی بخشی از محصول باشد.
با تعریف سخت‌گیرانه از واژه‌ی «انجامشده»، کسب‌وکار میتواند ارزیابی کند که در صورت عرضه یعنی استقرار (Deploy) یا انتشار محصول در پایان اسپرینت، چه چیزی عاید مشتریانش خواهد شد.
لازم به یادآوری است که «قابل عرضه بودن» (Potentially shippable) بدین معنا نیست که آنچه ساخته شده، حتماً تحویل می‌شود. تصمیم درباره‌ی تحویل محصول، تصمیمی در سطح مدیران کسب‌وکار است که اغلب متأثر از موضوعاتی مانند موارد زیر است:
آیا ویژگی‌های اضافه شده برای استقرار نسخه جدید کافی است؟
آیا بخشی از فرایندهای مشتری که در محصول پوشش داده شده، استقرار نسخه جدید را توجیه میکند؟
با توجه به نصب دو هفته پیش محصول، آیا کاربران آمادگی پذیرش تغییرات را، آن هم پس از دو هفته دارند؟
مفهوم «محصول قابل عرضه» معیار مناسبی برای کسب اطمینان از کامل شدن کارهای اسپرینت است. چرا که اگر کسب‌وکار بخواهد محصول را به مشتری تحویل دهد، نباید کار مهمی مانند آزمون یا یکپارچه‌سازی تا پایان اسپرینت باقی مانده باشد.
برخی از تیمها به مرور زمان و با کسب تجربه، واژه «تعریف انجامشده» را تغییر می‌دهند. برای مثال در تولید بازی‌های رایانه‌ای، ممکن است ارائه ویژگی‌های قابل تحویل در مراحل ابتدایی از نظر اقتصادی امکان‌پذیر و مطلوب نباشد. در این شرایط، «تعریف انجامشده» میتواند بخشی از کارکرد محصول باشد که امکان دریافت نظرات و بازخورد دیگران را فراهم کند. با این کار، تیم میتواند درباره کارهای آتی و روش انجام آنها تصمیم‌گیری کند.
گزیده:
آن‌که انتظار دارد هر چهار فصل سال بهار باشد، نه خود را می‌شناسد، نه طبیعت را و نه زندگی را !
فرانسوا ولتر
