نهمین رویداد اجایل‌کافه‌گپ
The 9th AgileCafeGap Event
اسکرام در تیم‌های غیر‌نرم‌افزاری: وقتی چابکی به زبان خلاقیت ترجمه می‌شود
در نهمین رویداد اجایل‌کافه‌گپ، پدرام کشاورزی، علی سخایی، حانیه احمدپور، فربد بهارلو، علیرضا شرف‌الاسلامی، امید حاجی‌شکری و خسرو واحدی، گرد هم آمدند تا در مورد کاربرد اسکرام در تیم‌های غیر نرافزاری گفتگو کنند. مقاله‌ی زیر شالوده‌ی این صحبت‌ها را پوشش می‌دهد.
مقدمه
سال‌ها پیش وقتی برای اولین بار با اسکرام آشنا شدم، مثل بسیاری تصور می‌کردم این روش فقط برای تیم‌های نرم‌افزاری طراحی شده است؛ مخصوص برنامه‌نویس‌ها، تسک‌های فنی و ابزارهایی مثل جیرا. اما هرچه جلوتر رفتم، دیدم اسکرام بیش از آنکه درباره‌ی نرم‌افزار باشد، درباره‌ی همکاری، تطبیق‌پذیری و خلق ارزش در محیط‌های پیچیده است.
و جالب اینجاست که محیط‌های خلاق مثل تولید محتوا، مارکتینگ، طراحی یا حتی ساخت پادکست، درست در همین دسته از محیط‌ها قرار می‌گیرند: جایی که قطعیت وجود ندارد، مسیر با تجربه شکل می‌گیرد و نتیجه با بازخورد ساخته می‌شود.
فلسفه و کارکرد اسکرام چیست؟
اسکرام از یک حرکت تیمی در راگبی الهام گرفته شده است؛ جایی که بازیکنان در قالب یک حلقه، هماهنگ و فشرده به سمت هدف مشترک پیش می‌روند. در اسکرام هم اصل بر همین هماهنگی و حرکت جمعی است. ما به آن «فریم‌ورک» می‌گوییم چون مجموعه‌ای ساده از قوانین دارد که به تیم کمک می‌کند کار را در قالب تکرارهای کوتاه پیش ببرد، یاد بگیرد و خود را تطبیق دهد.
اسکرام بر پایه‌ی یادگیری و انطباق بنا شده است (Adaptive Solution). یعنی تیم به جای دنبال‌کردن برنامه‌ای ثابت، مدام با واقعیت جدید سازگار می‌شود. در هر چرخه یا اسپرینت، ما تجربه می‌کنیم، بازخورد می‌گیریم و مسیر را تنظیم می‌کنیم. همین نگاه تطبیقی است که باعث می‌شود اسکرام در محیط‌های غیر‌نرم‌افزاری هم کاربردی و زنده باشد.
برای پاسخ به مسائل روش اسکرام چیست؟
اسکرام بر این فرض استوار است که مسئله‌ای که در حال حلش هست پیچیده است. در فریم ورک کانوین (Cynefin Framework)، این محیط را «Complex» می‌نامند — جایی که پاسخ درست را نمی‌دانیم و باید آن را از طریق تجربه کشف کنیم.
اینجاست که اسکرام با تکیه بر شفافیت، بررسی و انطباق، به ما کمک می‌کند.
ما چیزی می‌سازیم (مثلاً یک طرح گرافیکی یا اپیزود پادکست)، بازخورد می‌گیریم، اصلاح می‌کنیم، و دوباره تکرار.
به‌جای آنکه پروژه را تا پایان جلو ببریم و بعد بفهمیم مسیر اشتباه بوده، اسکرام به ما می‌گوید در قدم‌های کوچک ولی هدفمند حرکت کن و خروجی را تحویل بده و فیدبک بگیر، تا هزینه‌ی اشتباه کم و سرعت یادگیری زیاد شود.
تعریف تیم و معنای آن در فضای خلاق در اسکرام چیست؟
در اسکرام، تیم فقط مجموعه‌ای از افراد نیست؛ یک واحد یادگیری مشترک است. تیم جایی است که اعضا برای رسیدن به هدف محصول با یکدیگر همکاری می‌کنند، نه اینکه صرفاً وظایفشان را انجام دهند.
در تیم‌های خلاق هم همین معنا صدق می‌کند. مثلاً در تیم پادکست، نویسنده، گوینده، تدوین‌گر و طراح کاور، هرکدام نقش دارند اما هدف نهایی‌شان یکی است: خلق یک تجربه‌ی شنیداری باکیفیت.
در چنین تیمی، دیگر نمی‌توان گفت «کار من فقط نوشتن است». همان‌طور که در تیم نرم‌افزاری همه مسئول محصول نهایی‌اند، در تیم پادکست هم همه مسئول کیفیت خروجی‌اند.
نقش‌ها و جلسات اسکرام در فضای غیر‌فنی چگونه تعریف می‌شود؟
مالک محصول (Product Owner) کسی است که مسیر ارزش را تعریف می‌کند. در تیم‌های خلاق، ممکن است این نقش را سردبیر محتوا، مدیر برند یا کارفرمای پروژه برعهده بگیرد. او تصمیم می‌گیرد چه چیزی برای مخاطب یا مشتری بیشترین ارزش را دارد و اولویت‌ها را مشخص می‌کند.
اسکرام‌مستر (Scrum Master) تسهیل‌گر تغییر است؛ کسی که فضای یادگیری و هماهنگی را نگه می‌دارد و موانع را برطرف می‌کند. در تیم‌های غیر‌فنی، معمولاً این فرد نقشی شبیه رهبر پروژه یا کوچ دارد — کسی که با تغییر طرز فکر تیم، به تدریج حتی فرهنگ سازمان را نیز تغییر می‌دهد.
توسعه‌دهندگان (Developers) همان افرادی‌اند که دست‌به‌کار تولید می‌شوند؛ از طراح و نویسنده تا صدابردار و تدوین‌گر. مهم این است که تیم خودسازمان‌یافته باشد، یعنی خودش تصمیم بگیرد چطور کار را انجام دهد، نه اینکه از بیرون دستور بگیرد.
در اسکرام چند مراسم کلیدی داریم که به نظم و یادگیری تیم کمک می‌کنند:
برنامه‌ریزی اسپرینت: آغاز دوره‌ای کوتاه (مثلاً دو هفته) که در آن تصمیم می‌گیریم چه کاری را انجام دهیم.
دیلی اسکرام: جلسه‌ی روزانه‌ی کوتاه برای هم‌ترازی و شفاف‌سازی وضعیت کار.
نقد و بازاندیشی اسپرینت: در پایان هر اسپرینت، تیم نتیجه‌ی کار را ارائه می‌دهد و سپس درباره‌ی روند کارش گفت‌وگو می‌کند چه چیزی خوب بود، چه چیزی باید تغییر کند، و چطور می‌توان بهتر شد.
به‌عنوان نمونه، در تیمی که برای تولید محتوای برند کار می‌کردم، ما اسپرینت را به بازه‌ی دو هفته‌ای تقسیم کرده بودیم. در هر اسپرینت، مجموعه‌ای از پست‌ها و کمپین‌ها تولید می‌شد، سپس در جلسه‌ی نقد اسپرینت نتایج بررسی و بازخورد گرفته می‌شد. در رترو، تیم درباره‌ی چالش‌ها حرف می‌زد — مثلاً طولانی‌بودن فرایند بازبینی — و خودش برای رفع آن راه‌حل می‌یافت.
 |
|