سیستم‌های مدیریتی آبشاری و چابک

exonir-agile-system-article

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

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

سیستم آبشاری

waterfall-system

سیستم آبشاری سنتی‌ترین روش مدیریت وظایف است که حتی اگر به آن آشنایی ندارید، بدون شک از آن استفاده کرده‌اید.
متود آبشاری یک سیستم مدیرتی ترتیبی است که در آن پیشرفت به طور مرحله‌ای، از بالا به پایین صورت میگیرد.
این سیستم برای اولین بار در سال ۱۹۷۰ میلادی توسط “وینستون رویس” تعریف شد و در مقاله‌ی “مدیریت توسعه سیستم های نرم افزاری بزرگ” مورد بررسی قرار گرفت.[1]
سیستم آبشاری اول رویس شامل پنج مرحله‌ی مجزا از تعریف نیاز تا توسعه و نگهداری بود. در این چهارچوب، آغاز فعالیت هر مرحله وابسته به خاتمه یافتن مرحله قبلی بود.

1

فاز‌های سیستم آبشاری در سیستم تعریف شده‌ی رویس

۱. تعریف نیازدر این مرحله تمام نیاز‌های سیستم نهایی نرم‌افزار تعریف شده و در “مدرک نیاز‌ها” مکتوب میشود.

۲. طراحیدر این مرحله با هدف حل نیاز‌های تعریف شده، معماری سراسری نرم‌افزار شکل میگیرد.

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

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

۵. توسعه و نگهداریهر سیستم نرم‌ افزاری پس از نهایی و ارائه شدن به بازار دچار مشکلاتی خواهد بود که به نیازمند بروزرسانی و مدیریت خواهد بود که به صورت بلند مدت انجام میشود.

رویس برای به نمایش گذاشتن این پدیده شکلی جدید از این پروسه به تصویر کشید تا نشان دهد که فاز تستینگ و آزمایش که پس از اجرای پروژه انجام میشود ممکن است مسائلی آشکار کند که با تغییرات جزیی کد حل نشود و نیاز از سر گرفتن مراحل طراحی و اجرا شود.[1]
waterfall-new-model-system

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

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

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

چابک

ffhh

سیستم چابک که بر پایه‌ی شیوه های تکرار و همکاری متقابل اعضای تیم‌‌های مختلف، با تمرکز به رابطه‌ی تیم توسعه و کاربر، در سال ۲۰۰۱ میلادی به وسیله “بیانیه ی توسعه نرم افزار چابک” به شهرت رسید.
این بیانیه و اصول مدیریتی ذکر شده در آن برپایه چهارچوب‌های “سبک وزن” تولید نرم‌افزار مانند اسکرام و کَنبَن تنظیم شده است.در این سیستم تمرکز بر کامل کردن روند طراحی و توسعه واحد‌های کوچک پروژه بر پایه خودسازماندهی و رابطه‌ی متقابل و رودرروی اعضای تیم است.

ارزش‌های بیانیه‌ی چابک

افراد و تعاملات بالاتر از فرآیندها و ابزارها.

نرم افزار کارکننده بالاتر از مستندات جامع.

مشارکت مشتری در انجام کار بالاتر از قرارداد کار.

پاسخگویی به تغییرات بالاتر از پیروی یک طرح.

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

این روند طراحی کوتاه مدت به تیم قابلیت انعطافپذیزی در مقابل تغییر نیازمندی‌ها در هر مرحله از فرایند توسعه را میدهد.

agile-method-system-chart

فاز‌های سیستم چابک

۱-مرحله برنامه‌ریزی: در این مرحله نیاز‌های اولیه نرم‌افزار مشخص شده.

۲-طراحی: در این مرحله بخش‌‌های عملیاتی تنظیم و بین اعضای تیم تقسیم میشوند و طراحی کلی پروژه مشخص میشود

۳توسعه و کدنویسی: جرا کردن واحد‌های مشخص شده.

۴-تستینگ و تایید واحد‌ها: واحد‌های انجام شده بصورت دوره‌ای تحویل داده شده و کار آمدی آنها بررسی میشود.

۵-اجرا: واحد‌های تایید شده نهایی شده و تیم به مرحله بعد توسعه و برنامه‌ریزی منتقل میشود.

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

در سال ۲۰۰۵ میلادی جیمز هایسمیت و الیستیر کاکبرن (از اعضای اصلی تنظیم کننده بیانیه چابک) اصول توسعه تحت سیستم چابک را به بیانیه اصلی ضمیمه کردند؛ [2]

اصول بیانیه چابک

۱. بالاترین اولویت ما جلب رضایت مشتری با تحویل زود و مداوم نرم افزاری ارزشمند می‌باشد.

۲. استقبال از تغییر نیازمندی ها، حتی در اواخر فرآیند توسعه. فرآیند های چابک، تغییر را در جهت مزیتِ رقابتی مشتری مهار میکنند.

۳. تحویل زود به زود نرم‌افزار قابل استفاده دو،سه هفته یک بار تا دو ، سه ماه یک بار با ترجیح بر فاصله‌های زمانی کوتاه‌تر.

۴. ذی نفعان کسب و کار و توسعه دهنده ها می بایست به صورت روزانه در طول پروژه با هم کار کنند.

۵. پروژه ها را بر دوش افراد با انگیزه بنا کنید. فضای لازم را به آنها بدهید و از نیازهای آن ها پشتیبانی کنید وبه آنها اعتماد کنید تا کارها را انجام دهند.

۶. کارآمدترین و موثرترین روش انتقال اطلاعات به تیم توسعه و تبادل آن در میان اعضای تیم ، گفتگوی چهره به چهره است.

۷. نرم افزار قابل استفاده اصلی ترین معیار سنجش پیشرفت است.

۸. فرآیند های چابک توسعه پایدار را ترویج می دهند حامیان مالی , توسعه دهندگان و کاربران باید بتوانند سرعت پيشرفت ثابتی را براي مدت نامحدودی حفظ كنند.

۹. توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می شود.

۱۰. سادگی — هنر به حداکثر رساندن مقدار کار انجام نشده — ضروری است.

۱۱. بهترین معماری ها , نیاز مندی ها و طراحی ها از تیم های خود سازمانده پدید آور می شود.

۱۲. در فواصل منظم , تیم برچگونگی موثرتر شدن تامل وتفکر می نماید و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم‌سو می نماید.

نتیجه‌گیری

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

در مقالات آینده از نحوه‌ استفاده تیم‌های مختلف از سیستم چابک و نحو پیاده‌سازی آن میپردازیم.

منابع

[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

[2]: https://agilemanifesto.org/iso/pr/principles.html

فهرست مطالب

نویسنده
تاریخ
دسته‌بندی