سهیل صمدزاده
سهیل صمدزاده
خواندن ۵ دقیقه·۵ سال پیش

تیری به قلب SAFe؟!

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

شواهد متعدد نشان می‌دهد که ارتش و بخصوص وزارت دفاع ایالات‌متحده در مسیر چابکی بیشتر برای توسعه نرم افزارهایش، قصد تغییر و پذیرش یکی از این چارچوب‌ها را داشته است و منجر به آن شد که آقای نیکولاس چِیلان – Nicolas M. Chaillan، افسر ارشد نرم‌افزار و مسئول پروژه DevSecOps در نیروی هوایی ایالات‌متحده، در قالب یک گزارش جامع، علاوه بر پوشش سوالات و چالش‌های نرم‌افزاری متنوع، بخشی را نیز به بیان دیدگاه خود و گروهش نسبت به استفاده از چارچوب‌های مقیاس‌پذیر به‌ویژه چارچوب SAFe در سازمان متبوعش اختصاص دهد.

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

تولد چیزی به نام آرپانت به‌عنوان نتیجه پروژه‌ای در آژانس DARPA در سال 1967 که امروز همه آن را به‌عنوان اینترنت می‌شناسیم، پذیرش و استانداردسازی سوتفاهمی به نام Waterfall در سال 1985 (استاندارد شده در وزارت دفاع آمریکا DOD-STD-2167A)، آن‌هم پس از انتشار مقاله آقای وینستون دبلیو رویس در سال 1970، سرمایه‌گذاری بر روی حلقه اودا - OODA که توسط یک سرهنگ و استراتژیست اسطوره‌ای نیروی هوایی به نام «جان بوید – John Boyd» توسعه داده شد و دستاوردهای آن بعدها پشتوانۀ تحقیقات یک خلبان کارکشته و باهوش فانتوم اف-4 به نام دکتر جف سادرلند برای خلق چارچوب محبوب اسکرام قرار گرفت! این گراف آن‌قدر پهناور، درهم‌تنیده و جذاب است که می‌تواند انگیزه یک تحقیق جامع و دوست‌داشتنی باشد! به نظر می‌رسد همه‌چیز از ارتش شروع‌شده باشد و آن‌طور که معلوم است درنهایت هم در ارتش خواهد مرد!

به نظر می‌رسد همه‌چیز از ارتش شروع‌شده باشد و آن‌طور که معلوم است درنهایت هم در ارتش خواهد مرد!
Scrum: The Art of Doing Twice the Work in Half the Time
Scrum: The Art of Doing Twice the Work in Half the Time

تمرکز و حساسیت غریزی ارتش در گزینش فناوری و این بار روی چارچوب‌های مقیاس‌پذیر، نکاتی کلیدی را هویدا کرده است. بازار مکاره تجارت چارچوب‌های رنگ‌ووارنگ در جهان بسیار داغ است و ایران نیز از گزند آن در امان نمانده و در سال‌های اخیر بسیاری از سازمان‌های متوسط و بزرگ، توسط مشاوران و بازاریابان چشم آبی این چارچوب‌ها، تور شده و هزینه‌های گزافی را نیز برای تقریباً هیچ متحمل شده‌اند! گزارش آقای چِیلان به‌روشنی نشان می‌دهد که این چارچوب‌ها و به‌ویژه چارچوب معظم SAFe، چندان هم چابک و «ایمن» نیستند!

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


اسلاید شماره 12
اسلاید شماره 12

ترجمه اسلاید 12: Questions about the Agile/SAFe Memo

یادداشتی با موضوع به‌کارگیری DevSecOps و Agile، با امضای افسر ارشد نرم‌افزار در تاریخ 26 نوامبر 2019 ثبت و به‌تمامی مدیران اجرایی برنامه (PEO) و مدیران پروژه (PM) ارسال گردیده و در آن نسبت به استفاده از چارچوب‌های سخت‌گیرانه و تجویزی مانند چارچوب SAFe، به‌شدت ابراز نگرانی و یاس شده است.

چرا؟

  • وزارت دفاع (DoD) هنوز از ساختارهای آبشاری (Waterfall) یا آبچاری (Water-Agile-Fall) استفاده می‌کند پس تا زمانی که نتوانیم واقعاً اسکرام یا کانبان بنیادین را پیاده‌سازی کنیم، چیزی برای «مقیاس دهی (SCALE)» وجود نخواهد داشت. چابکی باید بر سرتاسر برنامه (Program) اعمال شود و نه‌فقط بر روی تیم توسعه، که شامل این موارد است: قراردادها و پیمان‌ها، مدیریت برنامه، گزارش دهی مستقیم به رهبران (نه واحد مدیریت ارزش کسب‌شده – EVM) و غیره!

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

  • چارچوب SAFe ممکن است برای تیم‌هایی که از مفاهیم DevSecOps یا DevOps استفاده نمی‌کنند، مفید باشد ولی اصل کلیدی در DevSecOps، تفکیک کردن کارها و تیم‌ها از هم است و هماهنگی‌ها و همگام‌سازی‌های موردنیاز احتمالی تنها باید از طریق «مالکان محصول» انجام شود. تیم‌ها اگر از یک سرویس‌مِش، طراحی DDD و یا مایکروسرویس‌ها استفاده می‌کنند، اصولاً نباید نیازی به همگام‌سازی و هماهنگی‌های پیچیده داشته باشند. در این حالت نیازی به چارچوب‌های سفت‌وسخت نیست. اگر در پیاده‌سازی این موضوع مسئله دارید پس مدل صحیحی از DevSecOps را پیاده نکرده‌اید.
  • بخش‌های خوب از هر چارچوب را بگیرید و در تیم خود بکار ببندید. مدارک و گواهی‌نامه‌ها همیشه پاسخگو نیستند.
  • اساساً «هدف» اصلی در توسعه نرم‌افزار در «امنیت - SAFE» بودن نیست، بلکه «نوآوری» کردن و «ساختن» است! نمی‌توانید بدون اینکه ریسک کنید، چیزی بسازید ... بلکه کاملاً برعکس:

«یادگیری مستمر: سریع شکست بخور ولی از یک دلیل واحد، دو بار شکست نخور!» - تغییرات افزایشی کوچک که ریسک‌ها را تخفیف داده و شرایطی امن برای انجام سریع تغییرات (تغییرات سریع) ایجاد می‌کنند.

  • چارچوب SAFe تاکنون توسط هیچ‌کدام از سازمان‌های تجاریِ موفق، مورداستفاده قرار نگرفته است (فیس‌بوک، گوگل، نتفلیکس و غیره)
  • عملکردها و وظایف بالاسری بیش اندازه و افراطی (آبشاری‌مانند)
  • به دنبال هماهنگی و همگامی کارهای مالکان محصولتان می‌گردید؟ مدل‌های بسیار زیادی مانند اسکرام در اسکرام وجود دارند. این کار (هماهنگی مالکان محصول) نباید تأثیری بر روی توسعه‌دهنده‌ها داشته باشد.

پایان ترجمه/


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

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

و توضیحات جالب مقامات ارشد ارتش در خصوص حلقه اودا - OODA:

چابکاسکرام
مربی و مشاور چابک‌سازی سازمانی، توسعه دهنده
شاید از این پست‌ها خوشتان بیاید