همین ابتدا توضیح بدم که:

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

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

تحقیق شرکت Voke

برای شروع بحث، از نتایج یک تحقیق شروع می‌کنم.

شرکت Voke (لینک)، یه شرکت تحلیلگر آمریکایی با تمرکز بر روی چرخه عمر و تغییر شکل فناوری‌هاست که تحقیقی در مورد متدولوژی چابک و پیاده‌سازی اون در شرکت‌ها انجام داده است. در این تحقیق، بیشتر از ۲۰۰ نفر شرکت کرده‌اند که نماینده شرکت‌های فناوری و غیرفناوری‌ای بوده‌اند که از توسعه چابک استفاده کرده‌اند یا می‌کنند. این بررسی، نتایج جنجالی به همراه داشت. از اونجایی که مشاهده گزارش تفصیلی (لینک) نیاز به اکانت پریمیوم داره، تعدادی از نتایج این نظرسنجی رو در ادامه ببینید:

• ۶۴% تغییر به چابک رو گیج‌کننده، سخت یا کند درک کرده‌اند.
• فقط ۴ بازخورد تفصیلی برای توصیف موفقیت با چابک داده شده است.
• ۴۰% هیچ مزیتی در چابک پیدا نکرده‌اند.
• ۱۴% به ریلیز سریعتر و ۱۳% به بازخورد بیشتر به عنوان مزیت اولیه‌ی درک شده اشاره کرده‌اند. ۷% گفته‌اند که برنامه‎نویس‌های چابک خوشحالند که برنامه‌ریزی برای آینده و مستندسازی کمتره.
• شرکت‌کننده‌های ارزیابی گزارش کردند که دولوپرها از چابک برای جلوگیری از برنامه‌ریزی و جلوگیری از مستندسازی (که برای نگهداریِ آتی مورد نیازه) استفاده می‌کنند.
• در مورد سطح شایستگی، حرفه‌ای بودن و نگرش برخی از اعضای جنبش چابک، اظهار نظرهای هولناک، تکان‌دهنده و بی‌سابقه‌ای دریافت شد.
• باید آگاه بود که جنبش چابک ممکنه تا حد زیادی عصیان برنامه‌نویس‌ها در برابر وظیفه‌ها و زمانبندی‌هایی باشه که نمی‌خواهند؛ و یا فقط فرصتی برای فروش خدمات چابک از جمله مدرک و آموزش باشه.

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

این گزارش طولانی با این متن تموم شده: «همه نرم‌افزارها نیازمند الزامات موثر و مدیریت هزینه، کیفیت و زمان هستند. این معضل کلاسیک نرم‌افزار است و به همین ترتیب باقی خواهد ماند. سازمان‌هایی که فکر می‌کنند یک راه حل سریع برای این مشکلِ پیر وجود دارد، باید بدانند که راهکارهای امروز تا حد زیادی همان مشکلات فردا هستند. به یاد داشته باشید، قبل از جهش نگاه کنید!»

بازخورد عصبانی!

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

«

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

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

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

و قبل از اینکه کسی برگرده بگه «خب ملومه که اون پروژه، چابک رو درست انجام نداده»، بگم که همه این پروژه‌ها پر بودن از آدمایی که یه عالم کتاب در مورد این موضوع داشتند. عاشق این کار بودند و وسواس زیادی روی پیاده‌سازی اسکرام و اسپرینت‌ها داشتند. در واقع سر کار و تو خونه و تو کافه، حرفی غیر از این نداشتند. پس اگه اینها نتونستند اسکرام رو درست انجام بدن، کی میتونه؟

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

عصبانی به نظر میام؟ خب، چون هستم. چابک یه فریبه. آدم‌ها چابک رو دوست دارند چون اونها رو از فکر کردن و انجام کارشون عفو میکنه. چابک، کار من رو به بدبختی میکشه و پول زیادی رو از جیب مشتری بیرون میکشه.

اگه فکر میکنید من در اشتباهم، ثابت کنید. و منظور من اینه که ثابت کنید چابک به درد میخوره، با مدرک. ادعاهای فوق‌العاده نیاز به مدرک فوق‌العاده داره. من نمیام تو زندگی شما و بگم چجوری کار کنید ولی اگه شما میخواین به بقیه بگید چطور کار کنند، بهتره دیتایی داشته باشید که پشتیبانِ حرفتون باشه.

»

سه کلمه حرف حساب

خب اجازه بدید در آخرین بخشِ این نوشته، در سه تکه به نقد چابک و اسکرام از نگاه خودم بپردازم. امیدوارم کسانی که می‌خواهند از این روش برای پیشبرد پروژه‌هاشون استفاده کنند، کمی عمیق‌تر و همه‌جانبه‌تر اون رو بررسی کنند.

۱. دوگانه‌سازی

فرض کنید بخواهیم بین مایکروسافت پراجکت و اوراکل پریماورا یکی رو انتخاب کنیم. بررسی و مقایسه این دو و رسیدن به نرم‌افزار بهینه برای شرایط کاری و پروژه ما، کاری حرفه‌ای و معقوله ولی اگه بخواهیم طرفداری و تعصب داشته باشیم، وارد فضای زرد دعواهای بی‌پایانی مثل «اندروید بهتره یا iOS؟» میشیم. مشخصن هیچ محصولی، بهترینِ مطلق نیست و فقط با توجه به نیاز میتونیم محصولِ بهینه رو پیدا کنیم. در بحثِ روش‌های مدیریت پروژه هم نیازی به این بحث زرد نیست. مدیریت پروژه، جدا از اینکه پروژه در چه صنعتیه، با روش‌های مختلفی قابل انجامه. تعدادی از اونها رو اینجا (لینک) قبلن توضیح داده‌م و در همون نوشته گفته‌ام که چیزی به نام بهترین چارچوب مدیریت پروژه وجود نداره. همه چیز بستگی به زمینه (کانتکست) کار شما داره. متاسفانه خیلی از طرفداران اسکرام (در دنیا و ایران)، وقتی بنا به تعریف از این روش میگذارند، اون رو مقابل روش مدیریت پروژه مرسوم (فرمان و کنترل یا آبشاری) (لینک) قرار میدهند و از کهنه، غیرمنعطف و تک چرخه‌ای بودن این روش میگن. جدا از اینکه افرادی با چنین رویکردی، احتمالن شناخت کافی از روش آبشاری ندارند، شناخت خوبی از خود اسکرام هم ندارند. اسکرام در واقع تلاش میکنه بین فضای چابک و مرسوم حرکت کنه، تا هر دو گروه رو خوشحال کنه. اسکرام از یک طرف میخواد چابک باشه و از چیزهای خوبی مثه تحویل فزاینده و بهبود مستمر حرف میزنه و در عین حال میخواد مدیران پروژه سنتی رو هم خوشحال نگه داره و روی کنترل با بکلاگ، تخمین و برنامه‌ریزی تاکید میکنه. در واقع نه تنها نیازی به این دوگانه‌سازی و تقابل زرد نیست، بلکه راهی هم برای اون وجود نداره.

۲. فرقه‌سازی

در مانیفستو یا بیانیه‌ی چابک نوشته شده: افراد و تعامل‌ها مهمتر از فرایندها و ابزارها هستند (Individuals and interactions over processes and tools). به شکل خنده‌داری، خود چابک و طرفدارانش تشابه کمی به همین بیانیه دارند. اولین مشکل از همینجا شروع میشه که مشاوران چابک و اسکرام شروع به فروختن «فرایند» می‌کنند و بهبود کمی در بخش «افراد و تعامل‌ها» ایجاد می‌کنند. در واقع بیشتر تلاش میشه که این روش رو برای مدیران دلپذیر نشون بدهند و تعداد زیادی شاخص جدید رو معرفی کنند تا در ظاهر همه چیز درست به نظر بیاد. ولی در عمل هیچ اصلاحی دیده نمیشه و همه به همون رفتار قدیمیشون برمیگردند. فقط چند مدل جلسه جدید و اصطلاحات جدید تو شرکت به وجود میاد. چیزی که در پیاده‌سازی اسکرام در بیشتر شرکت‌ها دیده میشه مثل یه مراسم اعتقادیه که انجام میشه، حتا اگه نتیجه‌ای نداشته باشه. پیروان فرقه اسکرام، حداقل در این یکجا، این مانیفست رو قبول ندارند و فرایندشون از آدم‌ها مهمتر میشه.

۳. دکان‌سازی

با اینکه دهه‌هاست که از روش مدیریت پروژه مرسوم آبشاری در ایران استفاده میشه، افراد کمی مدعی حرفه‌ای بودن در کانسپت و انتقال دانش اون به دیگران هستند. حداقل بنده تعداد انگشت شماری از مدرسین رو به یاد دارم که بعد از سالها کار و مطالعه وارد بخش آموزش شده‌اند. و حالا اسکرام وارد می‌شود، در این شاید ده سالی که این موضوع در محیط مدیریت پروژه ایران مطرح شده، تعداد نامحدودی اسکرام کوچ! (Scrum Coach) تولید شده است که به سرعت تکثیر می‌شوند. تقریبن هر کسی که چند وقتی در جلسات اسپرینت نشسته باشه و یه برگه مدرک گرفته باشه، به این لقب مفتخر میشه. تعداد بالای آموزشگاه‌ها و مدرسین اسکرام، نشان از باز شدن درب جدیدی برای درآمدسازی است.

با وجود اینکه بدنه‌ی دانشی چابک و اسکرام محدود است ولی مدارک زیادی برای اون به وجود اومده که کاسبی خوبی به صورت مستقیم برای موسسین این کسب و کار (از جمله، این لینک) و به صورت غیرمستقیم برای کوچ‌های وطنی ایجاد کرده است. تعدادی از این مدارک رو ببینید (لینک)، که بسته به نقش در تیم اسکرام قابل دریافت است. البته اعضای سیرکِ مدارکِ اسکرام فعلن ۲۳۶ تاست. بله، ۲۳۶ مدرک توسط ۳۴ سازمان مربوطه در دنیا ارائه میشه.