بررسی چارچوب‌های مقیاس‌گذاری چابک (Scaling Agile Frameworks)

وقتی‌که در سال ۲۰۰۱ با مانیفست چابک راه جدیدی در مدیریت پروژه باز شد، چندین روش که گاهی «روش‌های سبک» نامیده می‌شوند تحت روش چابک ترکیب شدند. اسکرام (Scrum)، DSDM، ExtremeProgramming (XP)، و کریستال (Crystal) همه روش‌های چابکی بودند که به مانیفست روح می‌بخشیدند. با این روش‌ها تیم‌های کوچک می‌توانند به بهترین شکل عمل کنند، کاغذبازی‌ها را دور بزنند و مشتری را به صحبت وادارند.

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

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

ازاین‌رو در ادامه به این موضوعات می‌پردازیم.

Scrum  و XP چه ارائه کرده‌اند؟

تیم‌ها پروژه را یکسره انجام می‌دهند (البته امیدواریم). سازمان‌ها برنامه‌ها را اجرا می‌کنند؛ برنامه، ترکیبی از چندین پروژه هستند که ممکن است تداخل داشته باشند. تیمی از تیم‌ها، یا تیمی از تیم‌های تیم‌ها، پروژه‌های بزرگ‌تر را انجام می‌دهند، ممکن است این تیم‌ها در مکان‌های فیزیکی مختلفی کار کنند. در این صورت باید هم‌راستایی را رعایت کرد. سازمان‌های بزرگ‌تر معمولاً نیاز به یک توازن بینابینی دارند؛ هم باید تیم‌ها را برای نوآوری آزاد بگذارند و هم اینکه با ایجاد انتظارات مشترک، هماهنگی میان‌تیمی ایجاد کنند. به همین دلیل مدیریت کار در جریان[1]، کار برنامه‌ریزی‌شده و زمان‌بندی شروع و پایان پروژه‌ها بسیار پیچیده‌تر می‌شوند.

به‌علاوه مشکل همیشگیِ تغییر به رویکرد چابک باقی است. یکی از مدیران ارشد زنجیره هتل عضو فرچون ۵۰۰[2] روند بازگشایی مجموعه خود را این‌گونه توصیف می‌کند که انگار «ده نفر سعی کنند که در یک جلسه کنفرانس تلفنی پنج‌ساعته سیستم‌ها را تفکیک کنند و دوباره پیاده کنند.».

در اسکرام، XP و کریستال و دیگر روش‌های توسعه نسل اول، راهکاری برای این مشکلات ارائه نشده است. در ادامه برای حل این مشکلات روش‌های جدید را بررسی می‌کنیم.

SaFE

با عمومی شدن روش دین لفینول، SAFe یا Scaled Agile Framework  (چارچوب مقیاسی چابک)، برخورداری از آموزش و مشاوره آسان‌تر شده است. مقالات، خودآموزها و ویدئوهای آنلاین زیادی هستند و روند اخذ گواهی مشخص و تقریباٌ مناسب است.

نه‌تنها گذار سازمان‌ها به SAFe آسان است بلکه SAFe ماهیتی تجویزکننده دارد؛ با SEFe می‌توان به سازمان‌ها نشان داد که دقیقاً چه باید انجام بدهند. یک مدیر برنامه از یک شرکت جزء فهرست فرچون ۵۰۰ که مایل است هویتش ناشناس بماند، معتقد است که اگر منافع هر بخش از SAFe به‌طور جدا فهمیده نشود، مدیر ارشد معمولاً کل آن را اتخاذ می‌کند که شامل کار تیم، کار برنامه، «رسم‌های تجاری» (Business epics)، «رسم‌های فنی» (technical epics) و معیارهای سنجش (متریک‌هایی) در تمام سطوح و نیازمندی‌های متعدد است. ممکن است که این بخش‌های اضافی، به پیچیدگی سازمان بیفزایند- که با هدف رویکرد چابک در تعارض است.

LeSS

در LeSS یا Large Scale Scrum (به معنای «اسکرام بزرگ‌مقیاس») فعالیت‌ها در اسکرام افزایش می‌یابند و در سطح تیم تیم‌ها قرار می‌گیرند. در LeSS برای برنامه‌ریزی در مقیاس بزرگ، جلسه ثانویه‌ای با شرکت یک یا دو عضو از هر تیم تشکیل می‌شود؛ علاوه بر اسکرام روزانه یک جلسه سرپایی[3] نیز تشکیل می‌شود. در «گذشته‌نگری همه‌گیر» که هفته بعد از پایان اسپرینت برگزار می‌شود با گذشته‌نگری مختص هر تیم، مشکلات به بحث گذاشته می‌شود. در LeSS علاوه بر این جلسات، جلسات سالنی[4] و فضای باز و دیگر فعالیت‌های ارتباطی و تعاملی وجود دارد.

قوانین رسمی LeSS  برای ۲ تا ۸ تیم که می‌توان آن‌ها را در پشت و روی یک صفحه نوشت مناسب است؛ نسخه‌ی مناسب برای تیم‌های محصولی که تا هزار نفر عضو دارند، LeSS Huge است که چندان بزرگ‌تر نیست. سازنده‌ی همکار LeSS، کِرِگ لارمَن ادعا می‌کند که گروه‌های تک‌کارکردی، دست‌به‌دست کردن‌ها و بازخوردهای ضعیف و کُندِ سازمان‌های بزرگ، پیچیدگی غیرضروری ایجاد می‌کند. او معتقد است: «به‌جای اینکه برای این زخم‌های عمیق چسب‌زخم‌های سطحی تجویز کنیم… تلاش ما برای تغییر در طراحی سازمانی و ایجاد تیم‌های چندمهارتی است.»

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

DaD

همیشه در اسکرام فرض بر این است که تیم پرواز می‌کند، بااین‌حال اینکه تیم از کجا شروع کند، یا چطور باید در «اسپرنیت صفر» [5] مثلاً در مورد پلتفرم فناوری مبنا، زبان برنامه‌نویسی و معماری تصمیم‌گیری کرد مشخص نیست.

در اینجا است که باید با چارچوب اسکات اَمبلِر، DaD یا Disciplined Agile Delivery (تحویل منظم چابک) دست‌به‌کار شد؛ در این چارچوب، نحوه شروع پروژه، تشکیل تیم و معماری و درنهایت، تولید، پشتیبانی و کاربرد عملیاتی در نظر گرفته می‌شود. برخلاف اسکرام که معمولاً تیمی برای وضعیت نگهداری فرض می‌شود، در DaD چنین فرضی نیست و تیم برای تصمیم‌گیری در مورد پلتفرم، ساخت ابزار، زمان‌بندی پروژه و دیگر چالش‌های پیش‌رو برای توسعه بیشتر محصول و زحمت کمتر نگهداری، زمان دارد.

LeadingAgile

LeadingAgile در سال ۲۰۱۰ در آتلانتا تأسیس شد و به‌سرعت به‌عنوان شرکت مشاوره‌ برای انتقال‌های بزرگ‌مقیاس چابک شهرتی بین‌المللی پیدا کرد. درLeadingAgile  به‌جای یک «چارچوب مقیاس‌گذار» یک «چارچوب انتقال» ارائه می‌شود. این چارچوب با ارزیابی اهداف برنامه‌ریزی شرکت برای پیش‌بینی‌پذیری و انطباق‌پذیری شروع می‌شود. به‌علاوه در این روش بررسی می‌شود که انتظار کدام می‌رود: ظهور کارکرد محصول (کشف برحسب نیاز بازار) یا پوشش کارکرد محصول (تحویل ویژگی‌ها و نیازمندی‌های ویژه در وقفه‌های معین).

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

جایگزین‌هایی برای چارچوب‌های «بزرگ»

بعد از سه چارچوب بزرگ ذکرشده  و LeadingAgile تعداد زیادی روش و چارچوب مقایس‌گذار کوچک‌تر وجود دارند. به‌طور مثال Slim یا Scrum Lean in Motion  که سَم لِینگ طراح آن است، برای تکمیل LeSS طراحی شده است. این مؤلف، خالق SCARE یا Sustainable Cultural Agile Release in the Enterprise است که نظریه محدودیت‌ها[6] را در چابک به کار گرفته است. SCARE بر مبنای الگوهایی است که از پروژه‌های مقیاس‌گذار موفق استخراج شده است. FAST Agile که سازنده آن ران کوارتل است، اخیراً در گردهمایی Agile Roots معرفی شد و تمرکز در آن بر بهبود سرعت یکپارچه‌سازی گروه‌های بزرگ (و کاهش اتلاف) از طریق جلسات فضای باز [7] مستمر برای برنامه‌ریزی است.

اگر مدیریت یک سازمان بسیار بزرگ فناوری اطلاعات را نوعی پورتفولیو و مقیاس‌گذاری در نظر بگیریم، کار جوهانا روفمن در Project Portfolio و Program Management شایان توجه است.

دیگر چارچوب‌های مقیاس‌گذار

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

چند رهبر دیگر، ازجمله آرلو بِلشی، مَت بارکام و آلیستِیر کاکبِرن ایده‌هایی را در مورد «چارچوب مقیاس‌گذار» ارائه داده‌اند.

چه کسانی به چارچوب مقیاس‌گذار نیاز دارند؟

در ۲۰۰۸ جایزه گودون پاسک (Godon Pask Award)، جایزه رسمی سازمان اتحادیه چابک (Agile Alliance) برای مشارکت در روش، به آرلو بِلشی اهدا شد. بلشی بعد از گرفتن جایزه Pask جایگاه تدریس و مربی‌گری در مایکروسافت را یافت. او این تجربه را در پست وبلاگ خود در ۲۰۱۳ با عنوان «مقیاس‌گذاری چابک، کاری آسان» به اطلاع رساند که در آن ادعا می‌کند انتقاد از مقیاس‌گذاری چابک ناشی از عدم اطلاع افراد است؛ وقتی شرکت‌ها تیم‌هایی را پرورش می‌دهند که واقعاً چندزمینه‌ای هستند و مرتباً نرم‌افزار عرضه می‌کنند، مشکلات از بین می‌رود. بلشی توضیح می‌دهد که برای این منظور تیم‌ها باید به مهارت رسیده باشند:

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

فقط بلشی نیست که راهکار ارائه داده است.

مت بارکام که یک مربی چابک مستقل و نایب‌رئیس قبلی توسعه محصول Taxware است، معتقد است مشکل «مقیاس» دشوارتر به نظر می‌رسد و معمولاً شامل سه موضوع است: گسترش، هماهنگی، هم‌راستایی. بارکام معتقد است که درک مشکلات بزرگ سازمانی نسبتاً آسان است:

«یا موفقیت به یک زمینه محدود شده و لازم است تیم‌های بیشتری موفق شوند (گسترش)، یا مشکل این است که پروژه، بزرگ و چندتیمی است (هماهنگی) -که مفاهیم ارائه‌شده در کتاب‌های رافمن یا کانبان پورتفولیو و نقشه‌راه‌های گردش‌بنیاد به همین می‌پردازد- یا مدیر ارشد از اینکه تیم‌ها از مدیریت میانی به پایین نتوانند اهداف موردنظر را دنبال کنند وحشت‌زده است (هم‌راستایی). در این صورت معمولاً کنترل بیشتر، فرایندهایی با جزئیات بیشتر و اقدامات بیشتر («چارچوب‌ها») پیشنهاد می‌شوند که دقیقاً نتیجه عکس دارند.»

در رویکرد بارکام مانند LeadingAgile، محل فاصله تشخیص داده می‌شود و بر این فاصله کار می‌شود و در این مسیر، پیشرفت‌هایی در مهارت و فرهنگ صورت می‌گیرد.

آلیستیر کاکبِرن، گردهمایی Snowboard را که مانیفست چابک در آن شکل گرفت سازمان‌دهی می‌کند او چه قبل و چه بعد از این گردهمایی، یکی از متفکران هدایت‌کننده این موضوع محسوب می‌شود.

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

1. صرف‌نظر از اینکه امور چطور پیش برود، چگونه همکاری‌ها را افزایش می‌دهید؟
2. برحسب پیشروی امور، چگونه می‌توانید نمونه‌های آزمایشی و اقلام واقعی تحویلی را افزایش بدهید؟
3. چگونه افراد را به مکث‌کردن و تأمل بر آنچه اطراف آن‌ها اتفاق می‌افتد وامی‌دارید؟
4. افراد در سطوح مختلف سازمان برای ایجاد تغییرات کوچک چه آزمایش‌هایی را انجام می‌دهند؟

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

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

نتیجه‌گیری

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

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

[1] WIS

[2] Fortune ۵۰۰

[3] Standup meeting

[4] town hall meeting

[5] sprint zero   اسپرینت اولیه

[6] theory of constraints

[7] open space meetings