چارچوب اسکرام (Scrum Framework) چارچوب سبکی است که در آن سه نقش (Role)، سه مصنوع (Artifact) و پنج رویداد (Event) تعریف می‌شوند؛ این چارچوب در توسعه و نگهداری محصولات پیچیده در محیط‌های پیچیده کاربرد دارد. اسکرام کارهای الزامی زیادی را تجویز نمی‌کند، و روش‌ها و مستندات و جلسات گسترده‌ای- که تبعیت از آن اجباری است- ندارد. بااین‌حال در راهنمای اسکرام (Scrum Guide) چند قانون وجود دارد. سعی نکنید چارچوب اسکرام را تغییر بدهید؛ تا چارچوب اسکرام را به شیوۀ ذکرشده در راهنمای اسکرام پیاده‌سازی نکرده‌اید، از هیچ مؤلفه‌ای چشم‌پوشی نکنید. در این مقاله به 10 راهکار دربارۀ چارچوب اسکرام می‌پردازیم.
- هدفِ اسپرینت (Sprint Goal) داشته باشید
مسئولیت اصلی شما، به‌عنوانِ مالک محصول، بیشینه کردن ارزش محصول (محصولاتی) است که به مشتریان و کاربران تحویل داده می‌شود. برای بیشینه کردن ارزش، چند تصمیم‌گیری دشوار، دربارۀ این که چه بسازید و چه نسازید، پیشِ رو دارید. همچنین باید دربارۀ زمان ساخت نیز تصمیم بگیرید. بک‌لاگ محصول را طوری تنظیم کنید که فرصت‌ها به حداکثر و ریسک‌ها به حداقل برسند و تیم اسکرام متمرکز بماند. تمرکز از معیارهای اصلی اسکرام است و واقعاً ضرورت دارد. حفظ تمرکز تیم اسکرام به شما کمک می‌کند که بهره‌وری خروجی و ارزش را افزایش بدهید؛ به‌علاوه بهره‌وری تیم را نیز بالا میبرد و آن را اثرگذارتر و خودسامان‌ده‌تر می‌سازد. مالک محصول با افزایش تمرکز تیم اسکرام می‌تواند بر موفقیت یک اسپرینت جداً اثرگذار باشد. یکی از راه‌های ایجاد تمرکز تعیین یک هدف اسپرینت (Sprint Goal) برای هدایت تیم است. با هدف اسپرینت، تیم مقصد و جهتش را درمی‌یابد و به‌وضوح می‌بیند که آیا اسپرنیت موفق خواهد بود یا خیر. بسیاری از مالکان محصول در کارهای روزانه‌شان هدف اسپرینت ندارند؛ که این موضوع اصلا خوب نیست.
- بخشی از تیم اسکرام باشید
تیم اسکرام شامل یک مالک محصول، یک اسکرام‌مستر، و یک تیم توسعه است. در بسیاری از تیم‌های اسکرام شاهد هستیم که مالک محصول مثل یک عضوِ واقعیِ تیمِ اسکرام عمل نمی‌کند. در اسپرنیت حضور ندارند، با تیم اسکرام مشارکت نمی‌کند، در پیشروی‌های پیوسته پشتیبان تیم نیست و مانند آن. به‌عنوانِ یک مالک محصول، باید عضوی از تیم اسکرام باشید؛ زیرا این تیم است که به شما در بهینه کردن ارزش محصول یاری می‌کند. اگر شما به تیم اسکرام کمک کنید آن‌ها نیز درعوض کمک خوبی برای شما خواهند بود!
- تمرکز تیم اسکرام را حفظ کنید
همان‌طور که در راهنمایی 1 ذکر شد، متمرکز کردنِ تیم اسکرام ضرورت دارد. علاوه‌بر تعیین یک هدف اسپرینت برای تیم، با انتخاب اقلام مربوط‌به بک‌لاگ محصول، می‌توانید تمرکز بیشتری بر اسپرنیت ایجاد کنید. به‌طورمثال در تنظیم بک‌لاگ محصول، اقلامی از بک‌لاگ محصول را، که نیازمندِ کار بر بخش معینی از یک سیستم یا بر همان فرایندند، گروه‌بندی کنید.
- اسکرام روزانه را «مدیریت» نکنید
اسکرام روزانه یک رویداد مربوط‌به تیم توسعه است که اعضای تیم توسعه در آن به پیشرفت فعلی رسیدگی می‌کنند و برنامه‌شان را برای 24 ساعت آینده انطباق می‌دهند. حضور مالک محصول و اسکرام‌مستر طی اسکرام روزانه، برای پاسخ دادن به سؤال‌های تیم، و راهنمایی آن‌ها، درصورت تمایل یا درخواستشان، مفید اما نه ضروری است. بااین‌حال درعمل مالکان محصول و اسکرام‌مسترهای زیادی را می‌بینیم که اسکرام روزانه را «مدیریت» می‌کنند؛ وظایف را میان اعضای تیم تقسیم می‌کنند؛ می‌پرسند که افراد در روز قبل چه کردند و قرار است چه کنند؛ بک‌لاگِ اسپرینت را به‌روزرسانی می‌کنند و غیره. از اکنون به بعد، دیگر چنین نکنید! اسکرام روزانه رویدادی مربوط‌به تیم توسعه است، نه یک جلسۀ به‌روزرسانی وضعیت که تیم توسعه به اطلاعِ اسکرام‌مستر و مالک محصول می‌رساند! وقتی از مدیریت اسکرام روزانه دست بردارید، می‌بینید که تیمِ توسعه خودسامان‌دهیِ بیشتری می‌یابند؛ ازاین‌رو شما، به‌عنوان مالک محصول، زمان و فضای بیشتری برای تمرکز بر ذینفعان و نقشه‌های درازمدت می‌یابید.
- زمانی را به بهسازی بک‌لاگ محصول(Product Backlog Refinement) تخصیص دهید و آن را تنظیم کنید
با بهسازی بک‌لاگ محصول می‌توانید بک‌لاگ محصول را مرتب کنید یا مجدداً تنظیم کنید. این کار به جداسازی اقلام بک‌لاگ محصول نیز کمک می‌کند و اقلامِ بک‌لاگ محصول را شفاف‌تر می‌سازد. پیشنهاد می‌شود که 10 درصد از ظرفیت تیم‌های توسعه برای بهسازی صرف شود؛ اما این فقط یک پیشنهاد است. بنابراین باید بر میزان زمانی که صرف تنظیم می‌شود نظارت داشته باشید و آن را تنظیم کنید. به‌این‌ترتیب روند بهسازی، یک ریتم و وزن می‌یابد. مثلاً می‌توان یک جلسۀ بهسازی با اسکرام‌مستر (و درصورت‌نیاز ذینفعان)، دوبار در هفته، مثلاً در سه‌شنبه‌ها و پنج‌شنبه‌ها، به‌مدت یک یا دو ساعت، تشکیل داد. ریتم تشکیل جلسات بهسازی باعث کاهش پیچیدگی و افزایش توانمندیِ تیم اسکرام و ذینفعان در پیش‌بینی امور می‌شود. علاوه‌بر ایجاد ریتم، بررسی کنید چقدر زمان برای بهسازی لازم است. برای برخی از تیم‌ها 5 درصد و برای برخی 10 درصد و برای برخی دیگر 20 درصد؛ بنابراین بررسی کنید چقدر زمان لازم است. پیشنهاد می‌شود که برای این کار، هدفتان را بک‌لاگ محصولی با اقلام «آماده» برای دو یا سه اسپرینت بعدی قرار بدهید.
- در انتهای هر اسپرینت یک مورد «انجام‌شده» یا Done تحویل بدهید
تیم‌های اسکرام زیادی را مشاهده می‌کنیم که در یک اسپرینت، متحملِ کارهای بسیار زیادی می‌شوند؛ که غالباً نتیجه‌اش نرساندن به هیچ «انجام‌شده‌ای» (Done) است. مطمئناً تیم کارهای زیادی کرده است، بی‌شک کار بر اقلام بسیاری را آغاز کرده، اما در آخر اسپرینت تمام کار (یا بخشی از آن) به اسپرنیت بعدی محول می‌شود. اگر متوجه این موضوع شده‌اید این راهنمایی را به‌خوبی می‌فهمید. لازم است تعداد اقلامی را که تیم در اسپرینت درنظر می‌گیرد کاهش دهید. زیرا می‌خواهید ارزش محصول را بیشینه کنید؛ هدفتان خروجی دادن تاحد ممکن نیست، بلکه نتیجه دادن تا حد ممکن است. بنابراین تیم ممکن است خروجی‌های زیادی تحویل بدهد؛ مثلاً آیا 20 اقلام تحویل بک‌لاگ (PBI) که 80 درصد آن «انجام‌شده» یا Done است فوق‌العاده به‌نظر می‌رسد؟ خیر! زیرا 20 ارزش صفر دارید! اگر «انجام‌نشده» باشند، هیچ ارزشی به مشتری‌ها و کاربران تحویل داده نمی‌شود .بنابراین مرجح است که 10 اقلام داشته باشید که 100 درصد تکمیل شده باشند؛ زیرا 10 قلم ارزش دارید نه صفر ارزش.
- به معنای «انجام‌شده» یا Definition of Done احترام بگذارید
تحت فشارهای خارجی و داخلی (مثل موعدهای تحویل، رویدادهای بازاریابی یا دیگر فرصت‌ها) بسیاری از مالکان محصول تیم پروژه را به تحویل سریع‌تر وامی‌دارند. اما محدودۀ تحویل را کاهش نمی‌دهند؛ معمولاً تیم را به این وامی‌دارند که محدودۀ یکسانی (یا بیشتری) را در زمان کمتری تحویل بدهند. این کار غالباً (نه همیشه) به افت کیفیت منجر می‌شود. وقتی تیم اسکرام از معنای «انجام‌شده» تبعیت نکند، کیفیت نامناسبی تحویل می‌دهد. در کوتاه‌مدت به‌نظر نمی‌رسد که بد باشد، اما در درازمدت منجربه کار انجام‌نشده و بدهی فنی می‌شود. در بسیاری از سازمان‌ها شاهد هستیم که از 10 تیم حدود 4 تا 6 تیم فقط بر حل مسئله، برطرفی باگ، مدیریت مشکلات و پرداختِ بدهی فنی کار می‌کنند. همیشه بهتر کردن کیفیت بعد از راه‌اندازی محصول از باکیفیت ساختن از همان ابتدا پرهزینه‌تر است. پس قائل به معنای انجام‌شده یا Definition of Done باشید و بگذارید تیم توسعه محصولات کیفی تحویل بدهند.
دِین فنی یا Technical Debt مفهومی در توسعۀ نرم‌افزار است که بیانگر هزینۀ احتمالیِ دوباره‌کاری اضافی است که به‌دلیل انتخاب یک راهکار آسان‌تر درعوض راهکار بهتری که زمان بیبشتری می‌گرفت ایجاد می‌شود. اگر دِین فنی پرداخته نشود، «بهره» پیدا می‌کند و بعداً پرداخت آن دشوارتر می‌شود. بی‌توجه ماندن به دِین فنی می‌تواند موجب «درگاشت (آنتروپی) نرم‌افزار» شود. دِین فنی الزاماً بد نیست بلکه گاهی در اثبات مفهوم (proof of concept) برای پیشبرد اولیۀ پروژه لازم است. بااین‌حال برخی از کارشناسان معتقدند که استعارۀ «دین فنی» تأثیر آن را کم جلوه می‌دهد و نتیجه، جهت‌گیری ناکافی برای تصحیح آن است.
- بررسی اسپرینت (Sprint Review) را با دمو(demo) اشتباه نگیرید
در بسیاری از سازمان‌ها بررسی اسپرینت یا Sprint Review را یک دمو درنظر می‌گیرند. دمو دادنِ افزایش محصول (Product Increment) بخشی از بررسی اسپرینت است؛ اما تنها هدف آن نیست! هدفِ «بررسی اسپرینت» تعامل با ذینفعان به‌منظور فیدبک گرفتن دربارۀ افزایش محصول، بررسی بازار، بررسی نقشۀ راه محصول، و نیز همکاری برای قدم‌های بعدیِ موردنیاز برای بیشنیه کردن ارزش محصول است. معنایش این است که «بررسی اسپرینت» بخشی از تعاملات مربوط‌به کار است، نه یک جلسۀ به‌روزرسانی وضعیت که تیم توسعه (با استفاده از پاورپوینت) به اطلاع ذینفعان یا بدتر، به اطلاع مالک محصول می‌رسانند. جلسه‌ای است که به تیم اسکرام کمک می‌کند که ذینفعان را مطلع نگه دارند، و بررسی را با آن‌ها انجام بدهند و ایده‌ها و بازخوردهایی را مبادله کنند و تصمیم بگیرند که قدم بعدی برای محصول چیست.
- با اسکرام‌مستر، روزانه، همکاری کنید
به‌عنوان مالکِ محصول، اسکرام‌مستر (یا مربی چابک) دوست شماست. او می‌تواند به شما کمک کند، مربی شما باشد، با شما مشورت کند، شما را آموزش بدهد و در هر نوع چالشی ناظر شما باشد. بااین‌حال مالکان محصول بسیاری را دیده‌ایم که به‌ندرت با اسکرام‌مستر خود همکاری می‌کنند. تأسف‌آور است! اسکرام‌مستر می‌تواند در هدایت ذینفعان، تسهیل رویدادهای مربوط‌به ذینفعان، و بهبود مهارت‌های مالک محصول در مدیریت بک‌لاگ محصول و ذینفعان و مدیران و غیره کمک کنند. اسکرام‌مستر فقط برای تیم توسعه نیست، اسکرام‌مستر برای شما و سازمان نیز هست. بنابراین برای تحویل ارزش بیشتر همکاری کنید.
- مشارکت خود را ادامه بدهید و به حفظ پیشرفت پیوسته متعهد باشید
در بسیاری از تیم‌های اسکرام، مالکان محصول طی اسپرینت قطع ارتباط می‌کنند و در دسترس نیستند و یا در پیشرفت پیوسته مشارکتی ندارند. تیم‌های اسکرام بسیاری هستند که گذشتهنگری اسپرینت (Sprint Retrospective) برای آن‌ها رویدادی است که اسکرام‌مستر و تیم توسعه اجرا می‌کنند و مالک محصول حضور ندارد، یا فقط در چند اسپرنیت حضور داشته است. این سؤ تفاهم بزرگی دربارۀ گذشتهنگری اسپرینت و کمبود بزرگی برای تیم اسکرام است. اگر مالک محصول هستید، شکی نیست که باید در گذشتهنگری اسپرینت حضور داشته باشید. مالک محصول، که عضوِ تیم اسکرام به‌حساب می‌آید، باید در پیشروی پیوسته مشارکت داشته باشد. به‌عنوان مالک محصول، شاید اموری باشد که شاید شما بهتر قادر به انجام آن باشید، شاید در همکاری شما و تیم توسعه پیشرفت‌هایی حاصل شود، شاید تصمیمات مهمی را بتوان اتخاذ کرد، پس باید در این جلسه حضور داشته باشید. به‌علاوه مگر نمی‌خواهید ارزش را بیشینه کنید؟ لازم است از پیشرفت‌های تیم اسکرام دربارۀ فرایندها، تعاملات و ارتباطات و غیره مطلع بمانید. زیرا هرچه تیم مؤثرتر شود شما می‌توانید ارزش بیشتری به مشتریان و کاربران تحویل بدهید.
امیدواریم این 10 راهنمایی برای موفقیت مالکان محصول در چارچوب اسکرام مفید واقع شوند. با تغییر دیدگاهتان به وظایف مالک محصول، می‌توانید در تحویل ارزش بهینه به مشتری‌ها و کاربران موفق شوید.
