اکثر سازمان‌ها امروزه نوعی توسعه چابک را انجام می‌دهند، اما همیشه اینطور نبود. برای درک موفقیت چابک، نگاه کردن به دوران اوج روش شناسی آبشار و تولد مانیفست چابک کمک می کند.
به نظر می‌رسد این روزها هر سازمان فناوری نسخه‌ای از روش‌شناسی چابک را تمرین می‌کند. یا حداقل آنها معتقدند که دارند. چه در توسعه نرم افزار تازه کار باشید و چه دهه ها پیش کار خود را شروع کرده اید، کار امروز شما حداقل تحت تاثیر روش های چابک است.
اما چابک چیست، و توسعه‌دهندگان و سازمان‌ها چگونه متدولوژی‌های چابک را ترکیب می‌کنند؟ این مقاله تاریخچه مختصری از توسعه چابک و تفاوت آن با روش کلاسیک آبشار است. من تفاوت‌های بین روش‌های چابک و آبشار را در عمل مورد بحث قرار می‌دهم و توضیح می‌دهم که چرا چابک برای نحوه عملکرد توسعه‌دهندگان و تیم‌ها، به ویژه در محیط‌های توسعه امروزی، بسیار مناسب‌تر است.
قبل از چابکی: روش شناسی آبشار
دست‌های قدیمی مثل من به یاد می‌آورند که روش آبشار استاندارد طلایی بود. برای توسعه نرم افزار استفاده از روش آبشار، قبل از شروع هر گونه کدگذاری، نیاز به اسناد زیادی داشت. معمولاً، این فرآیند با نوشتن یک سند الزامات تجاری توسط یک تحلیلگر تجاری شروع می شود که آنچه را که کسب و کار از برنامه نیاز دارد، نشان می دهد. این اسناد طولانی و مفصل بودند و شامل همه چیز از استراتژی کلی گرفته تا مشخصات عملکردی جامع و طراحی های رابط کاربری بصری بودند.
تکنولوژیست ها از سند الزامات تجاری برای توسعه یک سند الزامات فنی استفاده کردند. این سند معماری برنامه، ساختارهای داده، طرح‌های کاربردی شی‌گرا، رابط‌های کاربر و سایر الزامات غیر کاربردی را تعریف می‌کند.
هنگامی که اسناد الزامات فنی و تجاری کامل شد، توسعه‌دهندگان برنامه‌نویسی، سپس ادغام و در نهایت آزمایش را آغاز می‌کنند. همه اینها باید قبل از اینکه یک برنامه آماده تولید تشخیص داده شود، انجام می شد. کل فرآیند به راحتی ممکن است چند سال طول بکشد.
روش شناسی آبشار در عمل
اسناد مورد استفاده برای متدولوژی آبشار “مشخصات” نامیده می‌شد و انتظار می‌رفت توسعه‌دهندگان آن را به خوبی نویسندگانش بدانند. ممکن است شما به دلیل عدم اجرای صحیح جزئیات کلیدی، مثلاً در صفحه ۷۷ یک سند ۲۰۰ صفحه ای، محکوم شوید.
ابزارهای توسعه نرم‌افزار نیز به آموزش تخصصی نیاز داشتند و ابزارهای زیادی برای انتخاب وجود نداشت. ما همه چیزهای سطح پایین را خودمان توسعه دادیم، مانند باز کردن اتصالات پایگاه داده و پردازش داده هایمان چند رشته ای.
حتی برای کاربردهای اساسی، تیم‌ها بزرگ بودند و ابزارهای ارتباطی محدود بودند. مشخصات فنی ما ما را هماهنگ کرد و مانند کتاب مقدس از آنها استفاده کردیم. اگر یک الزام تغییر کند، ما رهبران کسب و کار را در یک فرآیند طولانی بررسی و امضا قرار می دهیم. برقراری ارتباط بین تغییرات در تیم و اصلاح کد رویه های گران قیمتی بود.
از آنجایی که نرم‌افزار بر اساس معماری فنی توسعه داده شد، ابتدا مصنوعات سطح پایین‌تر و مصنوعات وابسته در مرحله بعدی قرار گرفتند. وظایف بر اساس مهارت تعیین می شدند و برای مهندسان پایگاه داده معمول بود که ابتدا جداول و دیگر مصنوعات پایگاه داده را بسازند. توسعه دهندگان برنامه در مرحله بعد عملکرد و منطق تجاری را کدگذاری کردند و رابط کاربری آخرین بار روی آن قرار گرفت. ماه ها طول کشید تا کسی ببیند این برنامه کار می کند. در آن زمان، ذینفعان معمولاً عصبانی می‌شدند – و اغلب در مورد آنچه واقعاً می‌خواستند هوشمندتر بودند. جای تعجب نیست که اجرای تغییرات آنقدر گران بود!
در پایان، هر چیزی که در مقابل کاربران قرار می‌دهید مطابق انتظار عمل نمی‌کند. گاهی اوقات، آنها اصلا از یک ویژگی استفاده نمی کنند. در مواقع دیگر، یک قابلیت به طور گسترده ای موفق بود، اما برای پشتیبانی از مقیاس پذیری و عملکرد به مهندسی مجدد نیاز داشت. در دنیای آبشار، شما این چیزها را فقط پس از استقرار نرم افزار و پس از یک چرخه توسعه طولانی یاد گرفتید.
ویدئوی مرتبط: روش شناسی چابک واقعا چگونه کار می کند
همه درباره توسعه نرم‌افزار چابک صحبت می‌کنند، اما بسیاری از سازمان‌ها نمی‌دانند که در عمل چگونه کار می‌کند. این ویدیوی پنج دقیقه ای آن را تجزیه می کند.
مزایا و معایب روش شناسی آبشار
متدولوژی آبشار که در سال ۱۹۷۰ اختراع شد انقلابی بود، زیرا نظم و انضباط را در توسعه نرم افزار به ارمغان آورد و اطمینان حاصل کرد که مشخصات واضحی برای دنبال کردن وجود دارد. این بر اساس روش ساخت آبشار برگرفته از ابداعات خط مونتاژ هنری فورد در سال ۱۹۱۳ بود که اطمینانی در مورد هر مرحله از فرآیند تولید فراهم می کرد. هدف از روش آبشار این بود که اطمینان حاصل شود که محصول نهایی با آنچه در ابتدا مشخص شده بود مطابقت دارد.
زمانی که تیم‌های نرم‌افزاری شروع به اتخاذ روش‌شناسی آبشار کردند، سیستم‌های محاسباتی و کاربردهای آنها معمولاً پیچیده و یکپارچه بودند و برای ارائه به نظم و انضباط و نتایج واضح نیاز داشتند. الزامات نیز در مقایسه با امروز به کندی تغییر کرد، بنابراین تلاش‌های گسترده با مشکل کمتری همراه بود. در واقع، سیستم‌ها با این فرض ساخته شدند که تغییر نخواهند کرد اما نبرد ناوهای دائمی خواهند بود. بازه های زمانی چند ساله نه تنها در توسعه نرم افزار بلکه در تولید و سایر فعالیت های سازمانی رایج بود. اما با ورود به عصر اینترنت، سختی آبشار به سقوط آن تبدیل شد و سرعت و انعطاف پذیری بیشتر مورد توجه قرار گرفت.
مانیفست چابک
Agile به طور رسمی در سال ۲۰۰۱ راه اندازی شد، زمانی که ۱۷ فناور پیش نویس مانیفست چابک را تهیه کردند. آنها چهار اصل اصلی را برای مدیریت پروژه چابک نوشتند که هدف آنها هدایت تیم ها برای توسعه نرم افزار بهتر است:
- افراد و تعاملات بر روی فرآیندها و ابزارها
- نرم افزار کار بر روی اسناد جامع
- همکاری با مشتری بر سر مذاکره قرارداد
- پاسخ به تغییر به دنبال طرح
محور به روش های چابک
توسعه نرم افزار زمانی شروع به تغییر کرد که توسعه دهندگان شروع به کار بر روی برنامه های اینترنتی کردند. بسیاری از کارهای اولیه در استارت‌آپ‌هایی انجام می‌شد که تیم‌ها کوچک‌تر بودند، در همسایگی قرار داشتند و اغلب پیش‌زمینه‌های سنتی علوم رایانه را نداشتند. فشارهای مالی و رقابتی برای ارائه سریعتر وب سایت ها، برنامه ها و قابلیت های جدید به بازار وجود داشت. ابزارها و پلتفرم‌های توسعه در پاسخ به سرعت تغییر کردند.
این باعث شد بسیاری از ما که در استارتاپ‌ها کار می‌کنیم روش‌شناسی آبشار را زیر سوال ببریم و به دنبال راه‌هایی برای کارآمدتر باشیم. ما نمی‌توانستیم تمام مستندات دقیق را از قبل انجام دهیم، و به یک فرآیند تکراری و مشارکتی‌تر نیاز داشتیم. ما هنوز در مورد تغییرات در الزامات بحث می‌کردیم، اما بیشتر برای آزمایش و تطبیق نرم‌افزار خود بر اساس بازخورد کاربران باز بودیم. سازمان‌های ما ساختار کمتری داشتند، و برنامه‌های کاربردی ما نسبت به سیستم‌های قدیمی سازمانی پیچیده‌تر بودند، بنابراین ما نسبت به ساخت برنامه‌ها در مقابل خرید بازتر بودیم. مهمتر از آن، ما در تلاش برای رشد کسب‌وکار بودیم، بنابراین وقتی کاربران به ما می‌گفتند چیزی کار نمی‌کند، معمولاً به آنها گوش می‌دادیم.
داشتن مهارت‌ها و توانایی‌های نوآوری از نظر استراتژیک مهم شد. شما می‌توانید تمام پولی را که می‌خواهید جمع‌آوری کنید، اما نمی‌توانید توسعه‌دهندگان نرم‌افزار با استعدادی را جذب کنید که بتوانند با فناوری‌های اینترنتی که به سرعت در حال تغییر هستند کار کنند، و سپس آنها را مجبور کنید از «مشخصات» پیروی کنند. توسعه‌دهندگان مدیران پروژه‌ای را رد کردند که با برنامه‌ریزی‌های سرتاسری توضیح می‌دادند که چه چیزی را باید توسعه دهیم، چه زمانی برنامه‌ها باید ارسال شوند و گاهی اوقات حتی نحوه ساختار کد را توضیح می‌دادند. ما در اجرای برنامه‌های سه ماهه و شش ماهه‌ای که مدیران پروژه ما پیش‌نویس می‌کردند و بی‌وقفه به‌روزرسانی می‌کردند، بسیار وحشتناک بودیم.
در عوض، شروع کردیم به گفتن اینکه برنامه‌های اینترنتی چگونه باید مهندسی شوند، و نتایج را بر اساس برنامه‌ای که به طور مکرر ترسیم کرده بودیم، ارائه کردیم. به نظر می‌رسد که ما در ارائه آنچه گفته‌ایم زمانی که به آن متعهد بودیم در فواصل زمانی یک هفته تا چهار هفته، آنقدر بد نبودیم.
در سال ۲۰۰۱، گروهی از توسعه دهندگان نرم افزار باتجربه متوجه شدند که به طور جمعی توسعه نرم افزار را متفاوت از روش کلاسیک آبشار تمرین می کنند. همه آنها در استارتاپ ها نیز حضور نداشتند. این گروه – که شامل کنت بک، مارتین فاولر، ران جفریس، کن شوابر و جف ساترلند می‌شد، با مانیفست چابک< /a> که باورهای مشترک آنها را در مورد چگونگی عملکرد یک فرآیند توسعه نرم افزار مدرن مستند کرد. آنها بر همکاری بر سر اسناد، خودسازماندهی به جای شیوه های مدیریت سفت و سخت، و توانایی مدیریت تغییرات دائمی به جای قفل شدن در فرآیند توسعه آبشار سفت و سخت، تاکید کردند.
از آن اصول متدولوژی چابک برای توسعه نرم افزار متولد شد.
چرا توسعه چابک نرم افزار بهتری ارائه می دهد
وقتی مجموعه اصول چابک را در نظر می گیرید، آنها را در یک چارچوب چابک اجرا می کنید، از ابزارهای همکاری استفاده می کنید، و شیوه های توسعه چابک را به کار می گیرید، معمولاً برنامه هایی دریافت می کنید که کیفیت بهتری دارند و توسعه آنها سریعتر است. همچنین روش‌های فنی بهتری را دریافت می‌کنید، معروف به بهداشت.
دلیل اصلی این است که چابک برای انعطاف پذیری و سازگاری طراحی شده است. لازم نیست همه پاسخ ها را از قبل تعریف کنید، همانطور که در روش آبشار انجام می دهید. در عوض، شما مشکل را به اجزای قابل هضم تقسیم می‌کنید که سپس توسعه داده و با کاربران آزمایش می کنید. اگر چیزی به خوبی یا همانطور که انتظار می‌رود کار نمی‌کند، یا اگر تلاش چیزی را نشان می‌دهد که شما در نظر نگرفته‌اید، می‌توانید تلاش را تطبیق دهید و به سرعت به مسیر خود بازگردید – یا حتی اگر این چیزی است که لازم است مسیر را تغییر دهید. Agile به هر یک از اعضای تیم اجازه می دهد تا در راه حل سهیم باشند و لازم است که هر عضو مسئولیت شخصی کار خود را بپذیرد.
اصول، چارچوب‌ها و شیوه‌های چابک برای شرایط عملیاتی امروزی طراحی شده‌اند. Agile معمولاً توسعه تکراری و استفاده از بازخورد را برای بهبود برنامه و فرآیند توسعه در اولویت قرار می دهد. هم تکرار و هم بازخورد برای دنیای امروز عملکرد هوشمندتر و سریعتر.
توسعه چابک نیز بهبود مستمر را تشویق می کند. تصور کنید که مایکروسافت پس از نسخه ۳.۱ به توسعه ویندوز پایان دهد یا گوگل در سال ۲۰۰۲ بهبود الگوریتم های جستجوی خود را متوقف کند. روش شناسی چابک هم طرز فکر و هم فرآیندی را برای آن بهبود مستمر ایجاد می کند.
در نهایت، توسعه چابک منجر به نرم‌افزار بهتر می‌شود، زیرا افراد در تیم‌های چابک معمولاً سازنده‌تر و شادتر هستند. مهندسان در مورد میزان کاری که انجام می دهند نظر دارند و به نشان دادن نتایج خود افتخار می کنند. صاحبان محصولات دوست دارند دیدگاه خود را زودتر در نرم افزار بیان کنند و بتوانند اولویت ها را بر اساس آخرین بینش ها تغییر دهند. کاربران دوست دارند نرم افزاری را دریافت کنند که آنچه را که واقعاً به آن نیاز دارند انجام دهد.
امروزه، شرکت‌ها به سطح بالایی از صلاحیت نرم‌افزاری نیاز دارند تا تجربیات دیجیتالی استثنایی را در دنیای پررقابت ارائه کنند. و آنها برای ساختن نرم افزارهای عالی نیاز به جذب و حفظ استعدادهای بزرگ دارند. توسعه چابک به شرکت ها کمک می کند تا هر دو را انجام دهند.
پست های مرتبط
تاریخچه مختصری از روش شناسی چابک
تاریخچه مختصری از روش شناسی چابک
تاریخچه مختصری از روش شناسی چابک