داستان ازآنجا شروع شد که چندی پیش برایان ریورا، نیگل تارلو و دیو اسنودن، از پیشگامان و اساتید دنیای چابک فرصتی داشتند تا با رهبران و مدیران فناوری ارتش و نیروی دریایی ایالات‌متحده آمریکا دیدار کرده و طی گفتگوهایی، ایشان را با پیچیدگی‌های دنیای چابک و همچنین معضلات چارچوب‌های عظیم‌الجثه، و دست و پاگیر مانند چارچوب SAFe، بیشتر آشنا کنند. به این بهانه، یک جمع بندی مستند از حواشی آن را در اینجا جمع آوری کردم.
شواهد متعدد نشان می‌دهد که ارتش و بخصوص وزارت دفاع ایالات‌متحده در مسیر چابکی بیشتر برای توسعه نرم افزارهایش، قصد تغییر و پذیرش یکی از این چارچوب‌ها را داشته است و منجر به آن شد که آقای نیکولاس چِیلان – Nicolas M. Chaillan، افسر ارشد نرم‌افزار و مسئول پروژه DevSecOps در نیروی هوایی ایالات‌متحده، در قالب یک گزارش جامع، علاوه بر پوشش سوالات و چالش‌های نرم‌افزاری متنوع، بخشی را نیز به بیان دیدگاه خود و گروهش نسبت به استفاده از چارچوب‌های مقیاس‌پذیر به‌ویژه چارچوب SAFe در سازمان متبوعش اختصاص دهد (اسلاید ۱۲ام).
انتشار این گزارش بسیار مهم، واکنش‌های بین‌المللی فراوانی را در پی داشته است. برای اینکه اهمیت این موضوع را بهتر درک کنید باید خاطرنشان کنم که مطالعه جنبش‌ها و تحولات تاریخی در صنعت نرم‌افزار نشان می‌دهد که ارتش‌های جهان به‌طور کل و وزارت دفاع و ارتش ایالات‌متحده آمریکا به‌طور خاص، همواره منشأ و خاستگاه انواع ابتکارات، چارچوب‌ها، مفاهیم، فرایندها، تکنیک‌ها و تاکتیک‌های عمدتاً خوب و گاهی هم نچندان خوب بوده‌اند!
تولد چیزی به نام آرپانت به‌عنوان نتیجه پروژه‌ای در آژانس DARPA در سال ۱۹۶۷ که امروز همه آن را به‌عنوان اینترنت می‌شناسیم، پذیرش و استانداردسازی سوتفاهمی به نام Waterfall در سال ۱۹۸۵ (استاندارد شده در وزارت دفاع آمریکا DOD-STD-2167A)، آن‌هم پس از انتشار مقاله آقای وینستون دبلیو رویس در سال ۱۹۷۰، سرمایه‌گذاری بر روی حلقه اودا – OODA که توسط یک سرهنگ و استراتژیست اسطوره‌ای نیروی هوایی به نام «جان بوید – John Boyd» توسعه داده شد و دستاوردهای آن بعدها پشتوانۀ تحقیقات یک خلبان کارکشته و باهوش فانتوم اف-۴ به نام دکتر جف سادرلند برای خلق چارچوب محبوب اسکرام قرار گرفت! این گراف آن‌قدر پهناور، درهم‌تنیده و جذاب است که می‌تواند انگیزه یک تحقیق جامع و دوست‌داشتنی باشد! به نظر می‌رسد همه‌چیز از ارتش شروع‌شده باشد و آن‌طور که معلوم است درنهایت هم در ارتش خواهد مرد!
به نظر می‌رسد همه‌چیز از ارتش شروع‌شده باشد و آن‌طور که معلوم است درنهایت هم در ارتش خواهد مرد!
تمرکز و حساسیت غریزی ارتش در گزینش فناوری و این بار روی چارچوب‌های مقیاس‌پذیر، نکاتی کلیدی را هویدا کرده است. بازار مکاره تجارت چارچوب‌های رنگ‌ووارنگ در جهان بسیار داغ است و ایران نیز از گزند آن در امان نمانده و در سال‌های اخیر بسیاری از سازمان‌های متوسط و بزرگ، توسط مشاوران و بازاریابان چشم آبی این چارچوب‌ها، تور شده و هزینه‌های گزافی را نیز برای تقریباً هیچ متحمل شده‌اند! گزارش آقای چِیلان به‌روشنی نشان می‌دهد که این چارچوب‌ها و به‌ویژه چارچوب معظم SAFe، چندان هم چابک و «ایمن» نیستند!
نظر برخی از فعالان و رهبران چابکی در مورد SAFe را در زیر میبینید:
به دلیل اهمیت اسلاید دوازده‌ام این گزارش و نکات بسیار کلیدی و آموزنده‌اش، ترجمه آن را به همراه برخی اشارات تکمیلی در ادامه خواهم آورد. امیدوارم راهگشای تصمیمات و انتخاب‌های آتی شرکت‌ها و سازمان‌ها، بخصوص آنانی که علاقه بسیار زیادی به مقیاس‌دهی به همه‌چیز دارند، قرار گیرد.
ترجمه اسلاید دوازده در مورد SAFe
عنوان: جمع‌بندی در خصوص چالش‌های چابک/سِیف؟
یادداشتی با موضوع به‌کارگیری DevSecOps و Agile، با امضای افسر ارشد نرم‌افزار در تاریخ ۲۶ نوامبر ۲۰۱۹ ثبت و به‌تمامی مدیران اجرایی برنامه (PEO) و مدیران پروژه (PM) ارسال گردیده و در آن نسبت به استفاده از چارچوب‌های سخت‌گیرانه و تجویزی مانند چارچوب SAFe، به‌شدت ابراز نگرانی و یاس شده است.
چرا؟
- وزارت دفاع (DoD) هنوز از ساختارهای آبشاری (Waterfall) یا آبچاری (Water-Agile-Fall) استفاده می‌کند پس تا زمانی که نتوانیم واقعاً اسکرام یا کانبان بنیادین را پیاده‌سازی کنیم، چیزی برای «مقیاس دهی (SCALE)» وجود نخواهد داشت. چابکی باید بر سرتاسر برنامه (Program) اعمال شود و نه‌فقط بر روی تیم توسعه، که شامل این موارد است: قراردادها و پیمان‌ها، مدیریت برنامه، گزارش دهی مستقیم به رهبران (نه واحد مدیریت ارزش کسب‌شده – EVM) و غیره!
تا زمانی که «مبانی» را به‌طور صحیح در اختیار ندارید، نمی‌توانید به چیزی مقیاس دهید. در بهترین حالت، این چارچوب‌ها به دلیل «نگاشت‌ها و الگوهایشان»، ما را درخطر سقوط به آنچه همه می‌شناسیم قرار داده و به «توسعه آبشاری» بازخواهند گرداند.
- چارچوب SAFe ممکن است برای تیم‌هایی که از مفاهیم DevSecOps یا DevOps استفاده نمی‌کنند، مفید باشد ولی اصل کلیدی در DevSecOps، تفکیک کردن کارها و تیم‌ها از هم است و هماهنگی‌ها و همگام‌سازی‌های موردنیاز احتمالی تنها باید از طریق «مالکان محصول» انجام شود. تیم‌ها اگر از یک سرویس‌مِش، طراحی DDD و یا مایکروسرویس‌ها استفاده می‌کنند، اصولاً نباید نیازی به همگام‌سازی و هماهنگی‌های پیچیده داشته باشند. در این حالت نیازی به چارچوب‌های سفت‌وسخت نیست. اگر در پیاده‌سازی این موضوع مسئله دارید پس مدل صحیحی از DevSecOps را پیاده نکرده‌اید.
- بخش‌های خوب از هر چارچوب را بگیرید و در تیم خود بکار ببندید. مدارک و گواهی‌نامه‌ها همیشه پاسخگو نیستند.
- اساساً «هدف» اصلی در توسعه نرم‌افزار در «امنیت – SAFE» بودن نیست، بلکه «نوآوری» کردن و «ساختن» است! نمی‌توانید بدون اینکه ریسک کنید، چیزی بسازید… بلکه کاملاً برعکس:
«یادگیری مستمر: سریع شکست بخور ولی از یک دلیل واحد، دو بار شکست نخور!» – تغییرات افزایشی کوچک که ریسک‌ها را تخفیف داده و شرایطی امن برای انجام سریع تغییرات (تغییرات سریع) ایجاد می‌کنند.
- چارچوب SAFe تاکنون توسط هیچ‌کدام از سازمان‌های تجاریِ موفق، مورداستفاده قرار نگرفته است (فیس‌بوک، گوگل، نتفلیکس و غیره)
- عملکردها و وظایف بالاسری بیش اندازه و افراطی (آبشاری‌مانند)
- به دنبال هماهنگی و همگامی کارهای مالکان محصولتان می‌گردید؟ مدل‌های بسیار زیادی مانند اسکرام در اسکرام وجود دارند. این کار (هماهنگی مالکان محصول) نباید تأثیری بر روی توسعه‌دهنده‌ها داشته باشد.
- پایان اسلاید/
منابع دیگر در مورد چارچوب SAFe
لیست زیر شامل منابع ارزشمند و برگزیده‌ای است که به‌نوعی از زوایای متنوع به‌نقد این ابزارها و فرایندهای سنگین‌وزن پرداخته‌اند.
شوربختانه به دلیل قرارگرفتن در بخشی بسیار ویژه از جغرافیای جهان، احتمالاً برای مشاهده برخی از این منابع علمی نیاز به مختصری ارتکاب به جرم و دور زدن فیلتر اینترنت ملی هستید!! پیشاپیش از سوی خودم بابت این موضوع از شما پوزش می‌خواهم!
- کن شوئیبر – آگوست ۲۰۱۳: unSAFe at any speed
- ویدئویی تماشایی از آقای جز هامبل در کنفرانس GOTO2015 با عنوان: Why Scaling Agile Doesn’t Work
- دیو اسنودن – مارچ ۲۰۱۴: SAFe: the infantilism of management
- کریس مَتز – آگوست ۲۰۱۳: Two Legs Good
- دومینیک ماکسیمینی – سپتامبر ۲۰۱۳: A critical view on SAFe
- ران جفریس – آوریل ۲۰۱۴: Issues with SAFe
- یادداشتی دیگر از آقای ران جفریس – فوریه ۲۰۱۴: SAFe – Good But Not Good Enough
- مایک کات مِیِر – مارچ ۲۰۱۵: Let’s Acknowledge Safe For What It Is… And Move On
- آقای نیل کیلیک – مارچ ۲۰۱۲: The Horror Of The Scaled Agile Framework
- تعبیری جالب از آقای مایک کان: L.A.F.A.B.L.E
- پیتر هاندرمارک – ژانویه ۲۰۱۴: Scaling Scrum to the Organization
- تعبیر جالب مارتین فالر: SAFe: Shitty Agile For Enterprises! در پنل هیجان‌انگیز GOTO2014 با عنوان: A Retake on the Agile Manifesto
و توضیحات جالب مقامات ارشد ارتش در خصوص حلقه اودا – OODA:
- رودریک یاپ – فوریه ۲۰۱۹: OODA Loop: The Difference Between Tempo and Speed
- رودریک یاپ – فوریه ۲۰۱۹: OODA Loop: How The Taliban Used It
دیدگاهتان را بنویسید