فرز و چابک به سبک اسکرام : چارچوب Cynefin

در قسمت قبل سری مطالب Scrum (اسکرام)، در رابطه با تاریخچه‌ی ظهور Agile، تعریف کلی این فلسفه‌ی فکری، ارزش‌های اون و همینطور عملکرد چارچوب‌های مبتنی بر این فلسفه‌ی فکری توضیح داده شد و البته اشاره هم شد که یکی از چارچوب‌های مبتنی بر این فلسفه‌ی فکری، اسکرام هست. در این قسمت به طور خلاصه قرار هست مروری بر تاریخچه‌ی پیدایش Scrum و از طرف دیگه بررسی چارچوبی به اسم Cynefin داشته باشیم و ببینم ارتباط بین اسکرام و این چارچوب چی هست و چطور این چارچوب میتونه به ما در انتخاب یا رد استفاده از Scrum کمک کنه.

تاریخچه ی Scrum

پیدایش Scrum رو معمولاً به انتشار یک مقاله در سال 1986 تحت عنوان: “The New New Product Development Game” نوشته‌ی : Takeuchi و Nonaka، نسبت میدن. مقاله‌ای در توصیف این که چطور شرکت‌هایی مثل هوندا، Canon و Fuji-Xerox با استفاده از روش‌های مقیاس‌پذیر و مبتنی بر تیم به جای روش‌های سنّتی تولید محصول، تونستن سهم نسبتاً خوبی از بازار جهانی رو برای خودشون به دست بیارن. از طرف دیگه، این اولین مقاله‌ای بوده تا اون زمان، که به اهمیت تیم‌های قدرتمند و self-organized اشاره میکنه و نقش مدیریت رو در روند توسعه‌ی محصول مشخص میکنه.

در این مقاله آقایون Takeuchi و Nonaka، برای توصیف روند توسعه‌ی محصول از یک استعاره کمک می‌گیرن. این استعاره در واقع عملی بوده در ورزش راگبی تحت عنوان: Scrum.

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

در این مقاله اینطوری عنوان میشه که:

“همونطور که در بازی راگبی در هنگام شروع مجدد (یا اسکرام) تیم باید به گونه‌ای چیده بشه که بتونه با بیشترین قدرت و سرعت، توپ رو به دست بیاره و بازی رو در دست بگیره، در شرایط رقابتی بازار امروز هم دقیقاً همین نکته صدق میکنه. یعنی اگر قرار هست بازار یک محصول رو به دست بیاری باید تیمی داشته باشی که در کم‌ترین زمان، با بیشترین قدرت و سرعت، با کیفیت‌ترین محصول رو ارائه بدن.”

 

در سال 1993، آقای Jeff Sutherland به همراه تیمش، مفاهیمی که از مقاله‌ی سال 1986 رو برداشت کرده بودن، تحت عنوان فرآیند اسکرام با مفاهیم شی‌گرا (object-oriented) ترکیب کردن و روش حاصل شده از این ترکیب رو برای فرآیند توسعه نرم افزار در شرکت Easel به کار بردن.

در سال 1995، آقای Ken Schwaber اولین مقاله‌ی اسکرام رو منتشر کرد. بعدها Ken Schwaber و Sutherland با هم و به صورت جداگانه نوشته‌های متعدّدی رو برای اسکرام منتشر کردن (تا سال 2011).

هرچند که Scrum اغلب روشی برای توسعه‌ی محصولات نرم‌افزاری معرفی میشه و بیشتر در این نوع پروژه‌ها به کار میره امّا اسکرام و اصول و ارزش‌هایی که این روش تعریف میکنه، میتونن برای توسعه‌ی هر محصول یا در هر سازمانی مورد استفاده قرار بگیرن.امّا قبلش باید بررسی کرد که آیا برای پروژه یا سازمان ما اسکرام مناسب هست؟

آیا Scrum همیشه میتونه در هر نوع پروژه‌ای به ما کمک کنه؟

هرچند اسکرام مزایای متعدّدی مثل: دست‌یابی سریعتر به نتایج، بهبود بازگشت سرمایه، کاهش هزینه‌ها و … رو فراهم میکنه امّا این به این معنی نیست که میشه از اسکرام در هر پروژه‌ای استفاده کرد.

برای تشخیص اینکه کجا اسکرام میتونه مفید باشه و کجا نه، از چارچوب Cynefin (یه کلمه‌ی ولزی به معنی زیستگاه یا محل سکونت که “کانِ وین” تلفظ میشه) که یک چارچوب مدیریتی محسوب میشه، کمک می‌گیریم. این چارچوب با تعریف 5 دامنه یا حوزه و مقایسه‌ی مشخصات هر حوزه، میتونه کمک خیلی خوبی باشه که در هر شرایطی چه روشی مناسب هست. این پنج تا حوزه عبارتند از:

1- simple
2- complicated
3- chaotic
4- complex
5- disorder

اگر قرار باشه به صورت خلاصه این حوزه‌ها و مشخصاتشون رو نشون بدیم میشه چیزی که در تصویر زیر مشاهده می‌کنید:

نکته: قبل از بررسی هر کدوم از این حوزه‌ها باید این حقیقت رو در نظر گرفت که خیلی وقتا تمام نیازها و حقایق یک پروژه به طور کامل فقط در یک حوزه قرار نمی‌گیرن و گاهی ممکنه نیازها و الزامات، هم‌پوشانی داشته باشن و در تمام حوزه‌ها قرار بگیرن. این اتّفاق مخصوصاً زمانی که پروژه، توسعه‌ی نرم‌افزار باشه، زیاد رخ میده.

1- حوزه‌ی Complex یا Complex Domain

زمانی که با مشکلات پیچیده روبه‌رو می‌شیم همیشه اتّفاقات و مسایلی که غیر قابل پیش‌بینی هستن، بیشتر از مواردین که میشه پیش‌بینیشون کرد. در واقع پیش روی ما جهانی از ناشناخته‌هاست که حتّی نمیدونیم چه سؤالی درسته که بپرسیمش و کار رو از اونجا شروع کنیم. در همچین شرایطی فقط میشه بر اساس ادراک و حواس پیش رفت.

1. در این حوزه اول باید یک کند و کاو صورت بگیره تا مشکلات کشف بشن و راجع به اون‌ها شناختی حاصل بشه. یعنی در همچین شرایطی برای شناخت مشکلات هم نیازه تا آزمایش و سعی و خطا صورت بگیره.
2. بعد از اون، بر طبق شناختی که از مشکلات به دست میاد، باید دنبال راه‌حل‌ها و انطباق این راه‌حل‌ها با مشکلات براومد. در طول این تجزیه و تحلیلا ممکنه راه‌حل نهایی خیلی روشن و شفاف به نظر برسه امّا در واقع اصلاً اینطوری نیست و هرچی بیشتر مشکلات کشف میشن این باور کم رنگ‌تر میشه.

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

🔸 کار در این حوزه نیازمند روش‌های خلاقانه و نوآورانه است و روش‌های معمولی و ساده برای این حوزه مناسب نیستن.

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

🔸 همینطور در این حوزه تعاملات و ارتباطات سطح بالا یک امر ضروری محسوب میشه. یعنی گروهی از افراد با توانایی‌ها و استعدادهای مختلف رو در قالب یک تیم جمع‌آوری کرد و از روش‌هایی مثل طوفان یا بارش فکری (یا همون brainstorming) بهره گرفت و تیم رو تشویق کرد که در رابطه با احتمالات و ایده‌های مطرح شده مدام مباحثه داشته باشن.

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

✅ اسکرام یک روش مناسب برای کار در این حوزه محسوب میشه.در این محیط، تیم اسکرام باید توانایی بالایی در:

🔹 کشف (explore)
🔹 درک (sense)
🔹 پاسخ دادن (respond) 

داشته باشه.

2- حوزه‌ی Complicated یا Complicated Domain

در این حوزه ما با شناخته‌هایی ناشناخته سرو کار داریم 🙂 یعنی چی؟ یعنی راجع به اون مسئله یا مشکل یک دید کلی داریم و میدونیم که باید چی بپرسیم و چطور به جواب این سؤالا برسیم امّا برای اون مشکلات ممکنه چندتا راه‌حلِ درست وجود داشته باشه که ما رو مجاب میکنه برای به‌دست آوردن روش درست‌تر، از نظر کارشناس اون حوزه کمک بگیریم.

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

تو این حوزه با در نظر گرفتن یک بازه زمانی مناسب، میشه ریسک‌ها رو شناسایی کرد و برای حل مشکلات یک برنامه‌ی نسبتاً دقیق طراحی کرد.

در این حوزه روش تصمیم‌گیری بر مبنای موارد زیر هست:

🔹 درک (sense)
🔹 تجزیه و تحلیل (Analyze)
🔹 پاسخ دادن (response)

1. در این حوزه ابتدا شرایط و موقعیتی که در اون قرار داریم رو مشخص می‌کنیم.
2. در گام بعدی، آن‌چه که راجع بهشون شناخت داریم (سؤالاتی که میدونیم باید پرسیده بشن و جواب هایی که به دست میاریم) رو مورد تجزیه و تحلیل قرار میدیم و برای پیدا کردن جواب درست از نظر کارشناس یا کارشناس‌های اون حوزه کمک میگیرم.
3. و نهایتاً برای تصمیم‌گیری و تعیین راه‌حل درست، از نتایج حاصل از تجزیه و تحلیل و جوابی (اینجا منظور از جواب good practice هست و نه best practice) که کارشناس‌ها به اون مشکل دادن، بهره میگیریم.

امّا یک اخطار برای این حوزه وجود داره. در این حوزه ممکنه مدیران فقط بر نظر کارشناس‌ها تکیه و اعتماد بکنن و دیدگاه‌های خلاقانه‌ی سایر اعضای تیم رو نادیده بگیرن. برای حل این مشکل، باید تیمی از افرادی با تخصص‌های متنوّع رو گرد هم آوارد و برای مدیریت این تیم از روش هایی مثل روش یادداشت نویسی کرافورد (Crawford’s Slip Writing) که یکی از متدهای کمکی برای بارش فکری محسوب میشه، استفاده کرد تا اطمینان حاصل بشه که نظر همه‌ی اعضای تیم شنیده میشه.

در روش یادداشت نویسی کرافورد به عقيده‌ی همه‌ی اعضاي تيم، هرقدر هم ساكت باشن، وزن مساوي داده میشه.

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

3- حوزه‌ی Simple یا Simple Domain

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

مثلاً در یک call center یا اغلب مشکلاتی که help deskها باهاشون روبه‌رو میشن، مشکلات، تکراری و قابل پیش‌بینی هستن و پاسخ این مشکلات هم از قبل تعیین شده و آماده هست: یک سری مراحل که در اختیار مشتری قرار میگیره و مشکلش حل میشه.

به این دامنه، دامنه ی Best practiceها هم گفته میشه. مراحل حل مشکل در این دامنه به صورت زیر هست:

🔹 درک کردن (Sense)
🔹 طبقه بندی کردن (Categorize)
🔹 پاسخ دادن (Respond)

1. در این حوزه اول مشکل ارزیابی شده و نوعش مشخص میشه
2. بعد بر حسب نوعش، به دسته‌ای که به اون تعلّق داره اختصاص پیدا میکنه
3. و نهایتاً از Best Practice مشخص شده برای اون دسته، برای پاسخگویی به مشکل استفاده میشه. در این حوزه برای هر مشکلی فقط یک پاسخ وجود داره.

دو تا خطری که این حوزه رو تهدید میکنه:

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

اسکرام میتونه به عنوان روشی در این حوزه مورد استفاده قرار بگیره اما شاید همیشه یک ابزار کارآمد برای حل مشکلاتی که در این حوزه قرار میگیرن، نباشه. معمولاً پیشنهاد میشه از روش‌هایی در این حوزه استفاده بشه که یک مجموعه مشخص و قابل تکرار از گام‌هایی هستن که باید طی بشن تا به پاسخ رسید. به عنوان مثال، سازمانی که قصد بازتولید یک محصول رو به صورت پی‌درپی داره، بهتره به جای اسکرام به دنبال یک خط مونتاژ خوب باشه. یا مثلاً اگر یک محصول تجاری که قبلاً در یک مجموعه‌ی 100تایی نصب و پیکربندی شده و حالا قصد داریم تا این محصول رو در یک مجموعه‌ی 500تایی نصب و استفاده کنیم، بهتره تا از همون دستورالعمل‌هایی که قبلاً برای نصب و پیکربندی محصول تدوین شده استفاده بشه تا یک تیم اسکرام!

4- حوزه‌ی Chaotic یا Chaotic Domain

در این حوزه ما در یک شرایط بحرانی قرار داریم که برای کاهش ضررهای احتمالی آینده، باید هرچه سریعتر برای حل مشکل اقدام کنیم. از طرف دیگه در این حوزه هیچ رابطه‌ای بین علّت و معلول وجود نداره و تمام تلاش‌ها باید در جهت برقراری ثبات و نظم دادن به شرایط باشه.

یک مثال برای همچین شرایطی، زمانی هست که یک محصول رو ساختیم و تحویل مشتری دادیم، ولی متأسفانه محصول نهایی تحویل شده ناگهان دچار نقص عملکردی در شرایطی خاص در محیط واقعی میشه.

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

🔹 اقدام کردن (Act)
🔹 دریافتن (Sense)
🔹 پاسخ دادن (Response)

1. در این شرایط باید اول یک اقدام سریع صورت بگیره که مشکلات به سرعت شناسایی بشن.
2. بعد از اون باید فهمیده بشه که کدوم قسمت‌ها بی‌ثبات و کدوم قسمت‌ها دارای ثبات هستن
3. و نهایتاً اولین پاسخی که پیدا بشه که مشکل رو برای مدتی حل بکنه خوب هست و باید تلاش بکنیم تا هرچه سریعتر مشکل رو از این حوزه به حوزه‌ی Complex منتقل بکنیم.

برای مدیریت موفق مشکلات در حوزه ی Chaotic، میشه از فرآیند Risk Analysis برای شناسایی ریسک‌های احتمالی و الویت‌بندی این ریسک‌های شناسایی شده از طریق نمودار Risk Impact/Probability و همینطور تدوین یک برنامه‌ی جامع برای مدیریت این ریسک‌های احتمالی، بهره گرفت.

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

در این حوزه هم اسکرام چندان روش مناسبی برای حل مشکلات محسوب نمیشه. یادمون باشه که در این حوزه شرایط بحرانی هست و باید کسی باشه که به سرعت مسئولیت حل مشکل رو قبول کنه و عکس‌العمل نشون بده و قطعاً راهکاری مثل اسکرام با تقسیم‌بندی کارهاش و تکرارهای مداومش، برای همچین موقعیتی اصلاً مناسب نیست.

5- حوزه ی Disorder یا Disorder Domain

اگر در شرایطی قرار بگیریم که ندونیم دقیقاً مشکل یا مسأله‌ی پیش اومده در کدوم یکی از 4 تا حوزه‌ی قبلی چارچوب Cynefin قرار میگیره، یعنی ما گم شدیم و در حوزه ی Disorder قرار داریم. قرار گرفتن در این حوزه یک زنگ خطر محسوب میشه چرا که ما قادر نبودیم که موقعیت پیش اومده رو به درستی درک بکنیم.

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

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

اسکرام به هیچ وجه مناسب این حوزه نیست.

حالا که با چارچوب Cynefin و حوزه‌هاش آشنا شدیم باید یک نکته‌ی دیگه رو هم به انتهای این بخش که اسکرام به درد کجاها میخوره و به درد چه جاهایی نمیخوره اضافه کنیم و این مطلب رو خاتمه بدیم. اون نکته هم در رابطه با کارهایی هست که براشون برنامه‌ریزی صورت نگرفته و ناگهان رخ میدن و ممکنه باعث وقفه و از هم گسستن برنامه‌ریزی‌های از قبل تعیین شده‌ی ما بشن. به این کارها اصطلاحاً میگن: interrupt-driven work.

مثلاً فرض کنید در بخش پشتیبانی از محصولات یک سازمان کار می‌کنید. تصمیمات اینطوری گرفته میشه که برای سازماندهی و مدیریت فعالیت‌های پشتیبانی باید از اسکرام استفاده بشه. در این شرایط product backlog براساس درخواست‌های پیوسته‌ی پشتیبانی که از طریق ایمیل یا تلفن دریافت میشن، ساخته میشه. در همچین حالتی ما product backlogای خواهیم داشت که مدام داره موارد جدیدی بهش اضافه میشه و از طرف دیگه آیتم‌هاش مدام دارن تغییر میکنن و ترتیبشون عوض میشه (توسعه و تغییراتی در حد چند دقیقه حتّی!).

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

در محیط های interrupt-driven از یک روش جایگزین (که اونم متدی در فلسفه‌ی agile هست) به اسم Kanban استفاده میشه. Kanban به خودی خود یک راه حل مستقل نیست، بلکه در کنار یک روش پیاده‌سازی شده ( مثل اسکرام یا حتی مدل waterfall !) در یک سری شرایط خاص مورد استفاده قرار میگیره و به اون روش‌ها کمک میکنه که بتونن، شرایط ویژه رو مدیریت کنن.

نتیجه: قبل از انتخاب هر روش و چارچوب مدیریتی برای سازمان، پروژه یا حتّی شرایط خاص در زندگی فردی، کمی تأمّل کنیم، شرایط رو بسنجیم، پارامترها رو بررسی کنیم، درک ابتدایی از مسائل و مشکلات حال و آینده به دست بیاریم و بعد تصمیم به انتخاب روشی برای پیشبرد و حل مسائل بگیریم. این فرصت اندک اولیه برای تحقیق و شناخت، قطعاً منجر به حفظ زمان و منابع شما در آینده خواهد شد.