مروری بر تاریخچه مدیریت چابک (Agile) و اصول آن

امروزه، روش مدیریت چابک (Agile)‌ یک روش توسعه شناخته شده و رویکرد انتخابی برای بسیاری از تیم‌های توسعه‌دهنده است. به ویژه کسانی که سعی در ایجاد یک محیط تحویل مداوم (Continuous Delivery) دارند. وقتی به چابک فکر می‌کنیم، اغلب به سطح بالایی از همکاری و انعطاف‌پذیری و همچنین یک محیط کار تکراری می‌افتیم که در آن نیازها اصلی در کنار تغییر نیازهای فرعی، تکامل می‌یابند.

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

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

تصور کنید در موقعیتی هستید که باید سال‌ها صبر کنید تا راه‌حلی برای حل مشکلات اساسی کسب و کار شما ارائه شود. کمتر از ۳۰ سال پیش، این نوع زمان انتظار عادی بود. ما می‌توانیم اولین ریشه‌های تاریخ مدیریت چابک را به این مشکل برسانیم. قبل از شروع روش چابک، تیم‌های توسعه‌دهنده (به ویژه کسانی که در صنعت نرم‌افزار، تولید، هوا و فضا و صنایع دفاعی هستند) مشکلات را شناسایی کرده و برای حل آن برنامه‌ریزی می‌کنند. سپس آنها تلاش کردند تا آن راه‌حل را توسعه دهند و آن را به طور کامل به بازار عرضه نمایند.

یک قدم قبل از چابک

به طور خاص، اکثر تیم‌ها از روش آبشاری‌ (Waterfall) استفاده می‌کردند، یک روش توسعه که مسیر مشخصی را دنبال می‌کند که در آن تیم‌ها:

• نیازمندی‌های پروژه و دامنه کار را تعیین می‌کنند.
• محصولی را براساس آن نیازهای از پیش تعیین شده، طراحی می‌کنند.
• محصول را می‌سازند.
• محصول را تست می‌کنند.
• هر گونه مشکل هنگام آزمایش را برطرف می‌کنند.
• یک محصول تمام شده را راه‌اندازی می‌کنند.

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

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

در طرف دیگر ماجرا

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

تاریخچه شکل‌گیری رویکرد چابک

تاریخچه چابک از وضعیت موجود که ناامید شده است، چندین تیم توسعه نرم‌افزار شروع به تغییر رویکرد خود برای برنامه‌ریزی و تحویل محصولات جدید در طول دهه ۱۹۹۰ کردند. در این مدت، ما شاهد معرفی روش‌های توسعه مانند اسکرام‌ (Scrum)، برنامه توسعه سریع، برنامه نویسی شدید، DSDM، توسعه مبتنی بر ویژگی و برنامه نویسی عملی هستیم.

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

نتیجه سخن

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