تصور کنید در حال ساخت یک آسمانخراش هستید. شما ابتدا باید تمام نقشهها را از قبل آماده کنید، مواد اولیه را یکجا بخرید و سپس ساخت را شروع کنید. هیچ فرصتی برای تغییر در میانه کار ندارید، زیرا هر اشتباه، میتواند هزینههای سنگینی به پروژه تحمیل کند. این دقیقاً همان مشکلی است که روش آبشاری / Waterfall در توسعه نرمافزار ایجاد میکند.
اما حالا تصور کنید که بهجای ساخت یک آسمانخراش از ابتدا تا انتها، هر طبقه را بهطور جداگانه و بر اساس نیازهای لحظهای کاربران بسازید. در هر مرحله، شما فرصت دارید بازخورد بگیرید، مشکلات را اصلاح کنید و ویژگیهای جدیدی اضافه کنید. این همان چیزی است که توسعه تکرارپذیر و افزایشی / Iterative & Incremental Development در دنیای نرمافزار ممکن میکند!
در این مقاله، نگاهی عمیقتر به این رویکرد میاندازیم و میبینیم چگونه شرکتهای موفق با استفاده از این روش، نرمافزارهای خود را بهصورت گامبهگام و با حداقل ریسک توسعه میدهند.
همچنین مقایسهای خواهیم داشت بین این روش و مدل سنتی آبشاری تا ببینیم چرا توسعه نرمافزار نباید مثل ساخت یک آسمانخراش باشد، بلکه باید شبیه سازماندهی یک شهر پویا و در حال پیشرفت باشد!
توسعه افزایشی چیست؟
توسعه افزایشی / Incremental Development که گاهی به آن توسعه تدریجی و افزایشی نیز میگویند، فرایندی است که سعی دارد کار را به بخشهای کوچکتری به نام Increment یا افزایش تقسیم کند.
هر بخش یا افزایش بر روی آنچه قبلاً ساخته شده است توسعه مییابد و قرار میگیرد. بهاینترتیب، ماژولها و حوزههای کاملاً کاربردی بهتدریج ساخته شده و هر یک، قابلیتهای جدیدی را به سیستم میافزایند. این روش باعث میشود که در هر مرحله، بخشی از محصول بهصورت آزمایششده و قابلاستفاده در دسترس باشد.
مثلاً در یک پروژه نرمافزاری که به روش توسعه چابک نرم افزار اداره میشود، ابتدا نسخهای اولیه با حداقل محصول پذیرفتنی / MVP ساخته میشود، سپس در هر مرحله، ویژگیهای بیشتری به آن افزوده شده و سیستم تکامل میابد.
توسعه تکرارشونده چیست؟
در کنار توسعه افزایشی، توسعه تکراری / Iterative Development نیز وجود دارد که هدف آن بهبود مستمر از طریق تکرارهای متوالی در توسعه است.
در این روش، یک چرخه مشخص از طراحی / Design، توسعه / Development، آزمایش / Testing و بازخوردگیری / Feedback Collecting بهطور مداوم در سراسر رشد پروژه اجرا میشود تا هر بار محصول بیشتر اصلاح شود و نسخه جدیدی از آن با اصلاحات و بهینهسازیهای جدید ارائه شود.
به این شکل که برای افزودن یک بخش بزرگ به محصول، ابتدا آن را به بخشهای کوچکتر تقسیم میکنند، سپس طراحی آن بخش انجام میشود و بعد تیم توسعه مشغول به کار میشود. در مرحله بعدی، بخش تازهاضافهشده تست میشود و سپس در اختیار مشتریان یا ذینفعان قرار میگیرد و از آنها بازخوردهای مثبت و منفی در مورد فیچر اضافه شده جمعآوری میشود.
ترکیب مدل افزایشی و تکرارشونده در توسعه، بهعنوان یک رویکرد نوین در رویکرد اجایل، باعث میشود محصول نهایی با کیفیت بالاتر، انعطافپذیرتر و متناسب با نیازهای واقعی کاربران ساخته شود، چرا که در هر مرحله، امکان بررسی، آزمایش و اعمال تغییرات بر اساس بازخوردهای دریافتشده وجود دارد.
این رویکرد شبیه به روشهایی همچون رویکرد کایزن / Kaizen Approach یا روش 5S است که در صنایع مختلف پیادهسازی میشود و موجب افزایش بهرهوری و پیشبرد اهداف سازمانی میشود.
بد نیست برای مطالعه بیشتر درباره «محصول» سری به مقالات زیر بزنید تا با همه ابعاد ساخت و توسعه یک محصول دقیقاً آشنا شوید.
چرا رویکرد اجایل، هم تکرارپذیر است و هم افزایشی؟
رویکرد چابک / Agile ترکیبی از دو روش تکراری / Iterative و افزایشی / Incremental است. این روش بر اساس توسعه تدریجی نرمافزار شکل گرفته، به این معنا که قابلیتهای جدید بهمرور اضافه میشوند و محصول در یک چرخه مداوم منتشر و بهروزرسانی میشود.
در هر تکرار، نسخه جدیدی از محصول ارائه میشود که نسبت به نسخه قبلی بهبودیافته و تکاملیافتهتر است. این روند تا انتها ادامه پیدا میکند تا محصول تمام قابلیتهای مورد نیاز خود را به دست آورد.
در روش اسکرام که یکی از زیرمجموعه های تفکر اجایل است، توسعه در قالب چرخههای کوتاه و تکراری (بین ۱ تا ۴ هفته) به نام اسپرینت انجام میشود. در پایان هر اسپرینت، یک نسخه قابل استفاده از نرمافزار ارائه میشود، بازخورد کاربران مستقیماً دریافت میشود و بر اساس آن اصلاحات و فیچرهای جدیدی به محصول اضافه میشود. این روند نهتنها در پایان هر اسپرینت (یا در اینجا تکرار)، بلکه در طول کل فرایند نیز انجام میشود.
مایک کوهن / Mike Cohn در این رابطه میگوید:
«روش اسکرام و تفکر چابک هم افزایشی هستند هم تکراری. تکراری از این جهت که کار یا وظیفهای که در یک تکرار انجام شده است در تکرارهای بعدی بهبود پیدا میکند؛ و افزایشی از این نظر که در طول پروژه، بهطور مداوم بخشهای جدیدی به محصول اضافه میشوند.»
اما در ادامه ببینیم روش توسعه تکرارپذیر و افزایشی در قالب مثالهای واقعی چگونه معنی پیدا میکند.
مثالهای واقعی روش توسعه تکرارشونده و افزایشی
در این بخش میخواهیم روش توسعه تکراری و افزایشی را در مقابل روش سنتی آبشاری / Waterfall که پیش از رویکرد اجایل اجرا میشد مقایسه و بررسی کنیم.
مثال ۱: توسعه اپلیکیشن موبایل
فرض میکنیم یک تیم توسعه قصد دارد یک اپلیکیشن پیامرسان موبایل طراحی کند که قرار است ویژگیهایی مانند ارسال و دریافت پیام متنی، برقراری تماس صوتی و تصویری و رمزگذاری دادهها را داشته باشد.
حالا ببینیم اگر بخواهیم این فرایند را به سبک روش اجایل (توسعه تکراری و افزایشی) انجام دهیم چگونه پیش میرود و در مقابل در مدل آبشاری چگونه خواهد بود.
روش اجایل (توسعه تکراری و افزایشی)
-
اسپرینت اول (۲-۴ هفته):
-
طراحی رابط کاربری ساده
-
پیادهسازی قابلیت ارسال پیام متنی
-
ارائه نسخه اولیه به کاربران و دریافت بازخوردهای مستقیم
-
اسپرینت دوم:
-
بهبود عملکرد ارسال پیام بر اساس بازخورد کاربران
-
افزودن قابلیت ارسال فایل و تصویر
-
اسپرینت سوم:
-
پیادهسازی تماس صوتی و آزمایش اولیه آن
-
دریافت بازخورد از کاربران برای بهبود کیفیت صدا
-
اسپرینت چهارم و بعد از آن:
-
افزودن قابلیت تماس تصویری
-
اضافهکردن رمزگذاری سرتاسری
-
بهینهسازی تجربه کاربری / UX بر اساس رفتار کاربران
نتیجه: با توجه به مثال بالا، در هر مرحله یک نسخه قابلاستفاده از اپلیکیشن در اختیار کاربران قرار میگیرد و همزمان مشکلات زودتر شناسایی شده و تیم توسعه بر اساس نیازهای واقعی کاربران، مسیر خود را اصلاح میکند.
اما اگر از روش آبشاری استفاده میکردیم:
روش آبشاری / Waterfall
-
تحلیل و مستندسازی کامل کل پروژه (۱-۲ ماه)
-
طراحی تمام صفحات و ویژگیهای اپلیکیشن روی کاغذ (۲ ماه)
-
توسعه تمامی فیچرها بهصورت همزمان بدون دریافت بازخورد (۴-۶ ماه)
-
آزمایش کل سیستم پس از تکمیل کامل توسعه (۲-۳ ماه)
-
انتشار نسخه نهایی پس از ۱۰-۱۲ ماه توسعه بدون بازخورد
نتیجه: مشاهده میشود که پس از یک سال توسعه، اولین نسخه اپلیکیشن تازه به کاربران ارائه میشود. ممکن است کاربران از طراحی و قابلیتها رضایت نداشته باشند و از اپلیکیشن استقبال نکنند. بهاینترتیب تغییرات اساسی برای جلب رضایت آنها نیاز است که هزینه و زمان زیادی میطلبد.
مثال ۲: توسعه یک پلتفرم فروشگاهی پیشرفته
فرض میکنیم یک شرکت در حال ساخت یک پلتفرم فروشگاهی آنلاین مشابه دیجیکالا یا آمازون است که شامل فیچرهایی مانند سبد خرید، سیستم پیشنهاد محصولات، پرداخت آنلاین، مدیریت انبار و پشتیبانی مشتریان باشد.
ببینیم این پروژه در روش اجایل چگونه پیش میرود و اگر با روش آبشاری انجام شود، چه مشکلاتی پیش میآید.
روش اجایل
در این روش، محصول بهصورت قدمبهقدم و بر اساس بازخورد کاربران ساخته میشود.
-
اسپرینت اول (۳-۴ هفته)
-
پیادهسازی صفحه اصلی فروشگاه و نمایش ساده و ابتدایی محصولات
-
امکان جستجوی محصولات و مشاهده جزئیات آنها
-
انتشار نسخه اولیه برای تست و دریافت بازخورد کاربران
-
اسپرینت دوم
-
اضافهکردن سیستم سبد خرید و مدیریت سفارشها
-
پیادهسازی فرایند ثبتنام و ورود کاربران
-
آزمایش عملکرد سبد خرید و دریافت بازخورد
-
اسپرینت سوم
-
اضافهکردن درگاه پرداخت آنلاین و امکان خرید واقعی
-
بررسی رفتار کاربران برای بهبود فرایند خرید
-
رفع مشکلات امنیتی و بهبود تجربه کاربری
-
اسپرینت چهارم و بعد از آن
-
توسعه سیستم پیشنهاد هوشمند کالا بر اساس سابقه خرید کاربران
-
پیادهسازی پنل مدیریت انبار و موجودی کالا
-
اضافهکردن پشتیبانی آنلاین و چت با مشتریان
نتیجه: مزیت این روش این است که از همان مراحل اولیه، کاربران میتوانند از نسخههای ابتدایی فروشگاه استفاده کنند. سپس در هر مرحله، بهبودهایی بر اساس نیازهای واقعی کاربران اعمال میشود و محصول بهمرور تکمیل میشود
روش آبشاری
در این روش، کل سیستم از ابتدا بهصورت یکپارچه طراحی و توسعه مییابد و هیچ نسخه قابل استفادهای تا پایان رونمایی از پروژه منتشر نمیشود.
-
مرحله تحلیل و مستندسازی کامل کل سیستم (۲-۳ ماه)
-
طراحی تمامی صفحات و ویژگیهای فروشگاه روی کاغذ (۲ ماه)
-
توسعه تمامی فیچرها بدون دریافت بازخورد از کاربران (۵-۷ ماه)
-
آزمایش کل سیستم پس از تکمیل توسعه (۲-۳ ماه)
-
انتشار نسخه نهایی پس از ۱۲-۱۵ ماه توسعه مداوم بدون هیچ تعاملی با کاربران
نتیجه:
-
بعد از بیش از یک سال توسعه، اولین نسخه فروشگاه به کاربران عرضه میشود.
-
ممکن است کاربران از فرایند خرید، طراحی سایت یا نحوه نمایش محصولات ناراضی باشند، اما اصلاح این مشکلات هزینه بسیار بالایی خواهد داشت.
-
تیم توسعه تا پایان پروژه بازخوردی از کاربران دریافت نمیکند، بنابراین ممکن است برخی قابلیتهای ساختهشده اصلاً مورد نیاز بازار نباشند.
جمعبندی مثالها
در هر دو مثال بالا، روش تکرارشونده و مدل ساخت افزایشی باعث میشود محصول بهصورت قدمبهقدم و بر اساس بازخورد کاربران رشد کند. از همان مراحل اولیه، نسخههای قابلاستفاده و آزمایششده در اختیار کاربران قرار میگیرد، مشکلات زودتر شناسایی میشوند و قابلیتها بر اساس نیاز واقعی کاربران بهینه و تکمیل میشوند.
در مقابل، در روش آبشاری تیم توسعه ماهها بدون دریافت بازخورد واقعی کار میکند و محصولی را بهصورت یکجا عرضه میکند که ممکن است با نیازهای کاربران همخوانی نداشته باشد. تغییرات و اصلاحات در این روش هزینهبر و زمانبر است، درحالیکه در روش اجایل، این تغییرات بهصورت تدریجی و کنترلشده اتفاق میافتند.
جمعبندی: چرا روش تکرارپذیر و افزایشی را انتخاب کنیم؟
بهطور خلاصه روش توسعه Incremental and Iterative مزیتهای زیر را دارد:
-
محصول زودتر به دست کاربران میرسد و بهمرور تکمیل میشود.
-
تغییرات و بهبودها سریعتر و با هزینه بسیار کمتر اعمال میشوند.
-
تجربه کاربری بر اساس دادههای واقعی کاربران بهینه میشود.
-
ریسک شکست پروژه کاهش پیدا میکند، زیرا توسعه بر اساس نیازهای واقعی کاربران پیش میرود.
در نتیجه: اگر بخواهیم محصولی بسازیم که نهتنها سریعتر وارد بازار میشود، بلکه همواره مطابق با نیازهای کاربران تکامل مییابد، توسعه تکرارشونده و افزایشی بهترین انتخاب ماست!