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

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

تاریخچه ی Scrum

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

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

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

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

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

 

معنی اسکرام ادامه خواندن “فرز و چابک به سبک اسکرام : چارچوب Cynefin”

فرز و چابک به سبک Scrum! (مقدمه)

Scrum که یکی از چارچوب‌ها یا همون framework‌های Agile محسوب میشه در واقع چارچوبی مدیریتی هست برای تولید و توسعه‌ی پروژه‌ها و محصولات خلاقانه! (البته خیلی جاها این خلاقانه رو میگن پروژه‌های پیچیده)

اصلاً اسکرام (Scrum) چیه؟ Agile چیه؟ قضیه چیه؟ چارچوب مدیریتی رو چه به شبکه؟؟؟ 😐

پاراگراف Bold شده‌ی بالا به همراه سوالاتی که مطرح شد، نقشه راه موضوعی هستن که قراره یه چند وقتی زیاد باهاش سر وکار داشته باشیم و به سراغش بریم 🙂

***

تا حالا شده شما هم مثل من به این فکر بیوفتین که چرا خیلی از پروژه‌ها با وجود داشتن سرمایه‌گذاری خوب، تیم خبره و حتی ایده‌های اولیه‌ی فوق‌العاده، به نتیجه‌ی مطلوب نمی‌رسن و اکثر اوقات با انبوهی از پروژه‌های به سرانجام نرسیده و نیمه‌کاره و یا با خروجی که در حد انتظار نبوده، چه در حد کلان و چه در حد سازمان‌های متوسط و کوچیک، در اکثر حوزه‌ها، حتی همین حوزه‌ی IT که بیشتر باهاش آشنا هستیم، روبه‌رو می‌شیم؟

برای پیدا کردن جواب این چراها بیاین برگردیم به دهه‌ی ۱۹۹۰ میلادی، زمانی که این مشکلات خیلی خیلی بیشتر از حال حاضر بودن و ریشه‌‌‌ی این مشکلات و راهکارهایی که برای حلشون داده شد رو از اونجا رهگیری کنیم.

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

علتش هم واضح بود: زمانی که تأخیر زیادی تا تحویل محصول نهایی رخ بده، مطمئناً نیازهای بازار و مشتریان در طی این مدت تغییر می کنه. در نتیجه محصول نهایی دیگه اون چیزی نیست که مشتری می‌خواد.

برای مثال بیاین بریم سراغ حوزه‌ای در دنیای تکنولوژی که بیشتر باهاش آشنایی داریم یعنی حوزه‌ی نرم افزار و ببینیم در اون زمان اوضاعش چه شکلی بوده.

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

مدل آبشاری
فازهای مدل Waterfall منبع: Scrum Reference by Michael James and Luke Walter

مشکل بزرگ مدل Waterfall تأخیر زمانی زیاد تا تحویل نهایی محصول بود. بنابراین این روش قادر نبود به فرآیند تولید سرعت ببخشه و عملاً نمی‌تونست پاسخگوی نیازهای دنیای صنعت باشه. همین مشکل باعث شد تا یک سری از رهبرای فکری دنیای نرم‌افزار (یه گروه هفده نفره)، در سال ۲۰۰۰ و بعدش ۲۰۰۱ دور هم جمع بشن و با معرفی یه فلسفه‌ی فکری و عملکردی جدید و انتشار یه بیانیه در رابطه با این فلسفه‌ی فکری، سعی کنن به این اوضاع نابه‌سامون اندکی سروسامون بدن.

این فلسفه‌ی فکری جدید Agile نام داشت و بیانیه‌ای که به معرفی ارزش‌های اون پرداخت تحت عنوان Agile Manifesto یا ارزش‌های Agile، منتشر شد. ادامه خواندن “فرز و چابک به سبک Scrum! (مقدمه)”