آموزش اسکرام؛ قسمت دهم: محدودیت‌های WIP و برنامه‌ریزی محصول

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

این بورد به چندین نکته‌ی واضح و ضمنی دلالت می‌کند:

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

درمقابل، به بورد زیر توجه کنید که محدودیت WIP در آن اجرا شده است.

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

نکته: چهار مرحله‌ی توسعه‌ی پروژه را در ذهن داشته باشید.

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

۱. واقعیت این است که محدودیت‌های WIP فرهنگ Done را ترویج می‌کنند. به‌علاوه، این محدودیت‌ها با متمرکزشدن روی مجموعه‌ی کوچک‌تری از وظایف، سرعت تیم را افزایش و نرخ کارهای نیمه‌تمام یا «تقریبا نزدیک به پایان» را کاهش می‌دهند.

۲. محدودیت‌های WIP باتلنک‌ها را به‌طور واضح مشخص می‌کنند. تیم مسائل مسدودکننده را مطرح و درک و برای تمامی موانع پروژه، راه‌حلی پیدا می‌کند. هنگامی‌که باتلنک‌ها یا خطاها رفع می‌شوند، گروه‌ها می‌توانند جریان کار را از سر بگیرند. همان‌طورکه می‌بینید، محدودیت‌های WIP ابزار ارزشمندی محسوب می‌شود؛ زیرا طبق فرایند مذکور تضمین می‌کند مشتری محصول باکیفیتی دریافت می‌کند.

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

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

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

درنهایت، محدودیت‌های WIP باعث می‌شوند اعضای تیم نه‌تنها روی وظایف خود، بلکه روی کل فرایند‌ در‌حال‌اجرا متمرکز شوند.

محدودیت‌های WIP معمولا به‌واسطه‌ی رویکرد Kanban شناخته می‌شوند؛ اما در رویکرد اسکرام نیز به‌همان اندازه مفید هستند. به‌عنوان‌ مثال در بخش بک‌لاگ اسپرینت، اعضای تیم محدودیت WIP را باتوجه‌به‌ سرعت و ظرفیت خود تعیین می‌کنند. به‌عبارت‌دیگر، تیم مشخص می‌کند هریک از اعضا باید «چه نوع کارهایی» را انتخاب کنند یا چه سطحی از محدودیت‌های WIP را بپذیرند.

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

برای شروع، هر عضو تیم باید مقداری از کار را بپذیرد که با آن احساس راحتی می‌کند و می‌تواند در بازه‌ی زمانی مفروض، روی آن متمرکز بماند. سپس درصورت نیاز، جلسه‌ی بازنگری برگزار می‌شود که اعضای تیم درباره‌ی موفقیت و ادامه‌ی رویکرد قبلی یا تغییر آن گفت‌وگو می‌کنند. هرچه تیم بالغ‌تر می‌شود، محدودیت‌های WIP نیز کوچک‌تر می‌شوند. محدودیت ایده‌آل WIP برای تیم باید «یک» باشد؛ اما در دنیای واقعی، احتمالا چنین اتفاقی نمی‌افتد. به‌همین‌دلیل، تیم با قضاوتی صحیح به راه‌حلی می‌رسد که برای همه‌ی اعضا مؤثر است.

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

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

هر محصول جدید باید با اندیشه‌ی نوآورانه جدیدی ساخته شود و بهبود یابد. پیش‌بینی (Envisioning) محصول درواقع همان برنامه‌ریزی فعالیت‌های ساخت محصول است که برای پشتیبانی به سازمان‌ها ارائه می‌شود و دستور کار پروژه نیز بر پایه‌ی آن طرح‌ریزی می‌شود. برنامه‌ریزی محصول یکی از فرایندهای سبک اسکرام است و با این هدف پیش می‌رود که «مرحله‌ی تخمین‌زدن» را در اسرع وقت پشت‌سر بگذاریم.

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

• حفظ چشم‌انداز محصول
• اطلاعات مناسب برای شناخت ویژگی‌ها و نتیجه‌گیری‌های سطح بالا و ذی‌نفعان
• برآورد هزینه‌ی محصول

سازمان‌ها با کمک این نکات می‌توانند سرمایه‌گذاری‌های آتی خود را برای مراحل آینده‌ی توسعه‌ی محصول برنامه‌ریزی کنند.

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

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

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

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

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

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

در چهارچوب اسکرام، چشم‌انداز محصول، توصیفی کوتاه از آینده‌ی محصولی توسعه‌یافته است. این توصیف باید دستورالعمل‌های واضح و روشنی دراختیار کاربرانی بگذارد که می‌خواهند محصول را شناسایی کنند. در سال ۲۰۰۹، جیم های‌اسمیت برخی از قالب‌های استاندارد چشم‌انداز محصول را در کتاب «مدیریت محصولات چابک: خلق محصولات نوآورانه» ارائه داد:

اسلایدهای کنفرانس کاربری: در این روش، می‌توانید با ارائه‌ی دو تا سه اسلاید در کنفرانس کاربری، محصول را معرفی کنید. توصیه می‌شود از بولت‌پوینت‌ها اجتناب کنید.

نشریات: یکی از نشریات صفحه‌ای به معرفی محصول جدید اختصاص می‌دهد.

برگه‌ی مشخصات (Datasheet) محصول: بازاریابی محصول در یک صفحه

جعبه‌ی چشم‌انداز محصول: جعبه‌ی احتمالی محصول که روی برچسب آن، سه یا چهار نکته‌ی مهم بیان‌ شده است.

بیانیه یا سخنرانی آسانسوری: توضیحی کوتاه از چشم‌انداز محصول که در مدت‌ ۳۰ ثانیه تا یک دقیقه بیان می‌شود.

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

اغلب سازمان‌ها پس از تعیین چشم‌انداز اصلی و بک‌لاگ باکیفیت محصول، نقشه‌ی راه محصول را در تکمیل چشم‌انداز ایجاد می‌کنند. نقشه‌ی راه مجموعه‌های کوچک ریلیز (Release)های افزایشی و تکراری محصول را شامل می‌شود. این مجموعه‌های کوچک عبارت‌اند از:

• حداقل ویژگی‌های عرضه‌شدنی (یا) حداقل ویژگی‌های فروختنی
• حداقل محصولات پذیرفتنی

در نقشه‌ی راه محصول، هریک از ریلیزهای افزایشی روی تعداد معدودی از حداقل ویژگی‌های عرضه‌شدنی (MRF) متمرکز می‌شود، با این فرض که مشتریان درباره‌ی این MRFها عمیقا به‌توافق رسیده‌اند.

حداقل ویژگی‌ها فروختنی (MMF) معادل است با کوچک‌ترین فیچرها یا قابلیت‌های مهمی که هم سازمان می‌تواند آن‌ها را به بازار عرضه کند و هم کاربران می‌توانند از آن استفاده کنند. هنگامی‌که محصولات با موفقیت توسعه پیدا می‌کنند، به‌تدریج به مرحله‌ی تولید فرستاده می‌شوند. درواقع، هر بخش از محصول که به مرحله‌ی تولید می‌رسد، از ریلیز مهمی حاصل‌ شده است. بر‌این اساس هر MRF، یکی از خروجی‌های محصول است و حداقل قابلیت‌هایی دارد که الزامات فعلی ذی‌نفعان ما را برآورده می‌کند. چرا از MRF استفاده می‌کنیم؟ مزیت MRF این است که فاصله‌ی زمانی بین ریلیزهایی را کاهش می‌دهد که به بازار عرضه می‌شوند و برای کاربران ارزش ایجاد می‌کنند.

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

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