هر گروهی برای دستیابی به نتایج مطلوب کاری، نیازمند مدیریت هدفمند است. اما پیروی کردن از مراحل تعریف شده در چهارچوب مدیریتی لزوما به این معنی نیست که نتیجه نهایی کار طبق خواسته‌ها و توقعات تیم مدیریتی باشد؛ بلکه این وظیفه رهبر تیم است که با انتخاب چهارچوب ساماندهی مناسب و تعریف وظایف مشخص و هدفمند، تیم کاری خود را به نتیجه‌ی ایده‌آل خود و کاربر هدایت کند.
با توجه به حوزه فعالیت اکسونیر گزینه‌های سیستم مدیرتی محدود به سیستمهای مدیریتی آبشاری و چابک و انواع پیاده‌سازی‌های آن بود.
سیستم آبشاری سنتی‌ترین روش مدیریت وظایف است که حتی اگر به آن آشنایی ندارید، بدون شک از آن استفاده کرده‌اید.
متود آبشاری یک سیستم مدیرتی ترتیبی است که در آن پیشرفت به طور مرحله‌ای، از بالا به پایین صورت میگیرد.
این سیستم برای اولین بار در سال ۱۹۷۰ میلادی توسط “وینستون رویس” تعریف شد و در مقاله‌ی “مدیریت توسعه سیستم های نرم افزاری بزرگ” مورد بررسی قرار گرفت.
سیستم آبشاری اول رویس شامل پنج مرحله‌ی مجزا از تعریف نیاز تا توسعه و نگهداری بود. در این چهارچوب، آغاز فعالیت هر مرحله وابسطه به خاتمه یافتن مرحله قبلی بود.
۱. تعریف نیاز: در این مرحله تمام نیازهای سیستم نهایی نرم‌افزار تعریف شده و در “مدرک نیاز‌ها” مکتوب میشود.
۲. طراحی: در این مرحله با هدف حل نیازهای تعریف شده، معماری سراسری نرم‌افزار شکل میگیرد.
۳. اجرا و یا پیادهسازی: پس از طراحی سراسری نرم‌افزار، خروجی فاز قبلی به واحد‌های کوچکتر تقسیم و اجرا میشوند.
۴. تایید و تستینگ: پس از به پایان رسیدن توسعه واحد‌های نرم‌افزار، تمامی آنها آزمایش و واحد‌هایی که مطابق نیازهای تعریف شده کار کنند در سیستم نهایی میشوند.
۵. توسعه و نگهداری: هر سیستم نرم افزاری پس از نهایی و ارائه شدن به بازار دچار مشکلاتی خواهد بود که به نیازمند به بروزرسانی و مدیریت خواهد بود که به صورت بلند مدت انجام میشود.
رویس برای به نمایش گذاشتن این پدیده شکلی جدید از این پروسه به تصویر کشید تا نشان دهد که فاز تستینگ و آزمایش که پس از اجرای پروژه انجام میشود ممکن است مسائلی آشکار کند که با تغییرات جزیی کد حل نشود و نیاز از سر گرفتن مراحل طراحی و اجرا شود.
فاز تستینگ که در انتها‌ی چرخه توسعه انجام میشود اولین باری است که عناصری مثل زمانبندی، ذخیره، انتقال ورودی و خروجی در کنار هم بررسی میشوند. این پدیده‌ها دقیقا قابل بررسی نیستند. [...] اما اگر آنها قادر به رفع نیازهای تعریف شده پروژه نباشند پس بدیهی است که طراحی دوباره کامل، لازم میشود. یک پچ لحظه‌ای و تغییرات تیکه‌های ایزوله شده‌ی کد برای رفع مشکلات بوجود آمده کافی نخواهد بود. تغییرات اعمال شده احتمالا به قدری موجب اختلال میشوند که تمام سیستمهای تعریف شده در فاز بررسی نیازهای نرم‌افزار که منطق سیستم را تعریف میکند، پایمال میشوند.
با اینکه سیستم مدیرتی آبشاری دارای مزیت‌های منحصر به فرد خود است؛ از جمله ساده و قابل درک بودن آن و قابلیت مستند‌سازیِ راحتِ مراحل توسعه، روند مرحله‌ای آن بسیار وقت‌گیر خواهد بود و به علت به تاخیر انداختن مرحله آزمایش، کاربر و یا مشتری قابلیت نظردهی در روند طراحی و اجرا ندارد.
این‌‌‌ها و مسائل دیگر مدیریتی فردی و گروهی سیستم ابشاری را برای تیمهای بزرگ و رسانه‌‌ای و توسعه‌ای به یک سامانه‌ی ناقص و غیر‌کاربردی تبدیل میکند.
سیستم چابک که بر پایه‌ی شیوه های تکرار و همکاری متقابل اعضای تیمهای مختلف، با تمرکز به رابطه‌ی تیم توسعه و کاربر، در سال ۲۰۰۱ میلادی به وسیله “بیانیه ی توسعه نرم افزار چابک” به شهرت رسید.
این بیانیه و اصول مدیریتی ذکر شده در آن برپایه چهارچوب‌های “سبک وزن” تولید نرم‌افزار مانند اسکرام و کَنبَن تنظیم شده است.در این سیستم تمرکز بر کامل کردن روند طراحی و توسعه واحد‌های کوچک پروژه بر پایه خودسازماندهی و رابطه‌ی متقابل و رودرروی اعضای تیم است.
افراد و تعاملات بالاتر از فرآیندها و ابزارها.
نرم افزار کارکننده بالاتر از مستندات جامع.
مشارکت مشتری در انجام کار بالاتر از قرارداد کار.
پاسخگویی به تغییرات بالاتر از پیروی یک طرح.
بر پایه این ارزش‌ها رضایت‌مندی کاربر و مشتری اولویت اول دارد و با ارائه نرم‌افزار و با سرویس قابل استفاده معیار پیشرفت سنجش میشود.
این روند طراحی کوتاه مدت به تیم قابلیت انعطافپذیزی در مقابل تغییر نیازمندی‌ها در هر مرحله از فرایند توسعه را میدهد.
۱-مرحله برنامه‌ریزی: در این مرحله نیازهای اولیه نرم‌افزار مشخص شده.
۲-طراحی: در این مرحله بخش‌‌های عملیاتی تنظیم و بین اعضای تیم تقسیم میشوند و طراحی کلی پروژه مشخص میشود
۳-توسعه و کدنویسی: جرا کردن واحد‌های مشخص شده.
۴-تستینگ و تایید واحد‌ها: واحد‌های انجام شده بصورت دوره‌ای تحویل داده شده و کار آمدی آنها بررسی میشود.
۵-اجرا: واحد‌های تایید شده نهایی شده و تیم به مرحله بعد توسعه و برنامه‌ریزی منتقل میشود.
در این روند با اجرای مکرر مراحل تستینگ، اجرا و مشخص کردن نیازمندی‌ها ریسک‌های بوجود آمده از تغییرات مدرک نیازمندی‌ها کاهش داده میشود.
در سال ۲۰۰۵ میلادی جیمز هایسمیت و الیستیر کاکبرن (از اعضای اصلی تنظیم کننده بیانیه چابک) اصول توسعه تحت سیستم چابک را به بیانیه اصلی ضمیمه کردند؛
۱. بالاترین اولویت ما جلب رضایت مشتری با تحویل زود و مداوم نرم افزاری ارزشمند می‌باشد.
۲. استقبال از تغییر نیازمندی ها، حتی در اواخر فرآیند توسعه. فرآیند های چابک، تغییر را در جهت مزیتِ رقابتی مشتری مهار میکنند.
۳. تحویل زود به زود نرم‌افزار قابل استفاده دو،سه هفته یک بار تا دو ، سه ماه یک بار با ترجیح بر فاصله‌های زمانی کوتاه‌تر.
۴. ذی نفعان کسب و کار و توسعه دهنده ها می بایست به صورت روزانه در طول پروژه با هم کار کنند.
۵. پروژه ها را بر دوش افراد با انگیزه بنا کنید. فضای لازم را به آنها بدهید و از نیازهای آن ها پشتیبانی کنید وبه آنها اعتماد کنید تا کارها را انجام دهند.
۶. کارآمدترین و موثرترین روش انتقال اطلاعات به تیم توسعهو تبادل آن در میان اعضای تیم ، گفتگوی چهره به چهره است.
۷. نرم افزار قابل استفاده اصلی ترین معیار سنجش پیشرفت است.
۸. فرآیند های چابک توسعه پایدار را ترویج می دهند حامیان مالی , توسعه دهندگان و کاربران باید بتوانند سرعت پيشرفت ثابتی را براي مدت نامحدودی حفظ كنند.
۹. توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می شود.
۱۰. سادگی -- هنر به حداکثر رساندن مقدار کار انجام نشده -- ضروری است.
۱۱. بهترین معماری ها , نیاز مندی ها و طراحی ها از تیم های خود سازمانده پدید آور می شود.
۱۲. در فواصل منظم , تیم برچگونگی موثرتر شدن تامل وتفکر می نماید و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم‌سو می نماید.
با توجه به تنوع فعالیت گروه اکسونیر و تیمهای ایزوله و مجزایی که در عرصه‌های مختلف روی یک پروژه کار می‌گنند پیادهسازی سیستم چابک برای که آنها مناسب تیم ما بود به راحتی انجام نمی‌شد. برای پیادهسازی این متود در چارچوب رسانه‌‌ای، هنری، توسعه‌ای و محتوایی و هم‌جهت کردن‌آنها تحت یک سیستم مدیرتی یکپارچه نیاز به راهکار‌های سفارشی و منحصر به فرد بود.
در مقالات آینده از نحوه استفاده تیمهای مختلف از سیستم چابک و نحو پیادهسازی آن میپردازیم.
[1]: Royce, W. W. (2021). Managing the development of Large Software Systems (1970). Ideas That Created the Future, 321–332. https://doi.org/10.7551/mitpress/12274.003.0035
