احیای شیوه‌های مهندسی در روش چابک

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

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

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

فراسوی تعصبات: بازگشت به بنیان‌های چابک

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

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

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

برخی نمونه‌هایی که به یاد دارم (تا حدی که حافظه‌ام یاری می‌کند) از ارائه جان:

• هیچ درخواست الحاق نباید بیش از ۴ ساعت برای بازبینی منتظر بماند و حداکثر تا ۲۴ ساعت ادغام شود.
• هیچ شاخه‌ای نباید بیش از ۷ روز عمر کند. (اگر کار نمی‌تواند در ۷ روز انجام و ادغام شود، راه‌حل دیگری بیابید یا شاخه حذف خواهد شد.)
• توسعه‌دهندگان پس از ساعت ظهر در جلسات شرکت نمی‌کنند.
• گروه‌ها بزرگ‌تر از ۲ یا ۳ توسعه‌دهنده نیستند.
• ماموریت تیم‌ها به ری‌اکت (برای رابط کاربری سمت مشتری) و گو (برای APIهای سمت سرور) تقسیم شده است. چگونه مستقل کار می‌کنند؟ آن‌ها ابتدا یک قرارداد API طراحی می‌کنند، سپس هر دو طرف بر اساس آن قرارداد می‌سازند.
• پرچم‌های قابلیت در زمان اجرا قابل پیکربندی هستند (نیازی به استقرار کد جدید ندارند).
• تیم‌ها یک 'بودجه خطا' دارند: در چارچوب این بودجه، خطاهای گزارش شده بلافاصله در صدر اولویت‌ها قرار گرفته و رفع می‌شوند.
• آزمون دستی کاملاً ناهمگام و در محیط عملیاتی انجام می‌شود. چگونه؟
  • در تمام محیط‌ها انجام می‌شود، اما محیط عملیاتی نمایانگر مسائل واقعی مشتریان است، بنابراین تمرکز بیشتری بر آن وجود دارد.
  • تیم‌های توسعه، آزمون‌های واحد و پایان به پایان خود را می‌نویسند و کدی را منتشر می‌کنند که می‌دانند (یا باور دارند) عاری از خطاست.
  • توسعه‌دهندگان همچنین آزمون‌های یکپارچه‌سازی می‌نویسند و اکنون شروع به گنجاندن آزمون مؤلفه و قرارداد کرده‌اند.
  • آزمون دستی برای بررسی‌های عملکردی یا بازگشت نیست. (اگر یک آزمون خودکار بتواند آن را انجام دهد، آن آزمون توسط توسعه‌دهندگان نوشته و اجرا می‌شود. آزمونگران انسانی باید کاری را انجام دهند که آزمون‌های خودکار نمی‌توانند.) پرسنل کنترل کیفیت، نگرانی‌های گسترده کاربردپذیری، جریان تجربه کاربری در برنامه، انسجام قابلیت، سازگاری با دستگاه‌های در حالت‌های خاص و مواردی از این دست را آزمایش می‌کنند.
• بودجه‌ها به تحویل‌ها متصل نیستند؛ تیم‌ها برای سال تأمین مالی می‌شوند.
• برآوردها به ندرت درخواست می‌شوند و تصمیم‌گیری درباره اولویت یا زمان‌بندی را هدایت نمی‌کنند. هنگامی که برآوردها خواسته می‌شوند، گزینه‌های پیاده‌سازی را روشن می‌کنند.
• تیم‌ها چندین بار در روز کد جدید را به محیط عملیاتی می‌فرستند. قابلیت‌ها غالباً به صورت انتخابی و با ریتمی مستقل از استقرار، در معرض کاربران نهایی قرار می‌گیرند.
• ابزارهای هوش مصنوعی عموماً برای توسعه‌دهندگان تازه‌کار مجاز نیستند. به توسعه‌دهندگان ارشد مجوز ابزارهای خاص هوش مصنوعی داده می‌شود اگر بتوانند چگونگی استفاده از آن ابزار را توضیح دهند. (فکر می‌کنم این محدودیت هدفش تشویق توسعه‌دهندگان به استفاده سنجیده و آگاهانه از هوش مصنوعی است.)
• انتشارات پرسر و صدای عملکردهای جدید، با اهداف بازاریابی اعلام و زمان‌بندی می‌شوند (نه بر اساس محدوده قابلیت). تیم‌ها پیاده‌سازی خود را به سمت آن تاریخ‌ها مدیریت می‌کنند. این‌ها ضرب‌الاجل‌های همراه با محدوده ثابت نیستند؛ بلکه نقاط کانونی هستند که به تیم‌های مستقل کمک می‌کنند تلاش خود را در بخش‌های مختلف هم‌سو کنند.

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

نگاهی به آینده

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

سخن پایانی

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