انتخاب روش ساخت محصول
روش مناسب برای ساخت هر محصول فقط بستگی به نوع محصول دارد و نه مسایل دیگری مانند ترجیح تیم، مدیر پروژه، سازمان، یا کارفرما.
آیا می‌توانید محصولی که پاسخگوی نیازها و خواسته‌ها باشد را پیش‌بینی کنید یا با خواسته‌هایی پیش‌بینی‌ناپذیر سروکار دارید و لازم است که آن‌ها را به‌تدریج و با نمایش دادن نسخه‌هایی قابل استفاده از محصول (increment) کشف کنید؟ آیا اصلا امکان ساخت نسخه‌های قابل استفاده محصول برای ارزیابی خواسته‌های بازار وجود دارد؟
در روش تطبیقی باید بتوانیم نسخه‌های متعددی از محصول بسازیم، به‌گونه‌ای که هر نسخه قابلیت‌های بیشتری داشته باشد و همواره قابل استفاده باشد زیرا فقط اینگونه می‌توان بازخورد مناسب از محیط دریافت کرد. با بهره‌مندی از بازخورد هر نسخه، حدس میزنیم که بهترین کاری که در نسخه بعد می‌توان انجام داد چیست و بر آن پایه جلو می‌رویم. فراموش نکنید که هدف اصلی از گردآوری بازخورد در سیستم‌های متعین کشف مسیر مناسب برای آینده است و نه اصلاح گذشته. اصلاح گذشته بر پایه بازخورد در همه پروژه‌ها وجود دارد و به معنی تطبیقی بودن نیست.
برای این‌که بتوان به ترتیب گفته شده جلو رفت، باید در هر نسخه بر زیرمجموعه‌ای از ویژگی‌های تازه تمرکز کنیم و آن اجزا را جدا از سایر اجزا تعریف، طراحی، و تولید کرده، با خروجی‌های پیشین ترکیب کنیم. اگر فرآیندهای توسعه (تعریف، طراحی، …) را نتوانیم از هم جدا کنیم، اجزای سازنده پروژه آزادی کامل نخواهد داشت و سطحی از انعطاف‌پذیری که برای چابکی لازم است فراهم نخواهد شد.
برای نمونه، ساختمانی را فرض کنید: فونداسیون آن را نمی‌توان جدا از سایر عناصر طراحی کرد و ساخت، زیرا برای طراحی فونداسیون باید باری که بر آن وارد می‌شود را دانست و تنها راه برای دانستن آن این است که کل ساختمان طراحی شود. به عبارت دیگر، درجه‌ای از آزادی که برای چابکی لازم است در پروژه‌های ساختمانی وجود ندارد.
از سوی دیگر، در پروژه‌های ساختمانی نمی‌توان نسخه‌هایی نخستین از محصول آماده کرد که قابل استفاده باشند تا بر پایه آن‌ها بازخورد واقعی دریافت کرد؛ ساختمان فقط زمانی قابل استفاده است که کامل شده باشد. از این رو، حتی اگر آزادی عمل در چنین محصولی وجود می‌داشت، باز هم امکان چابک اجرا کردنش فراهم نمی‌شد.
اگر برآنید که نرم‌افزاری برای کاربرد همگان بسازید، پیش‌بینی پذیرش همگانی‌اش مکان‌پذیر نخواهد بود. اجزای سازنده نرم‌افزار را برخلاف ساختمان می‌توان مستقل از هم ساخت و نسخه‌هایی نخستین از نرم‌افزار ساخت که قابل استفاده باشند. این نسخه‌ها را می‌توان به کاربران محدودی نشان داد و بر پایه نوع استفاده و نظر آن‌ها حدس زد که گام بعدی چه باشد و بر آن پایه پیش رفت. چنین روشی برای این نوع پروژه بهترین نتیجه را می‌دهد و ریسک‌هایی که برآمده از پیچیدگی پیش‌بینی رفتار انسانیست را حداقل می‌کند.
هر پروژه نرم‌افزاری‌ای نیز نباید تطبیقی انجام شود. برای نمونه، اگر قرار است سیستم‌عامل و برخی دیگر از نرم‌افزارهای یک دیتاسنتر را تغییر دهید، خبری از پیچیدگی‌های رفتار انسانی نخواهد بود و بهتر است آن را متعین اجرا کنید. اگر قرار است نرم‌افزاری برای دستگاهی بیمارستانی یا نوعی هواپیما بسازید، هم پیچیدگی‌های گفته شده وجود ندارند و هم امکانی برای آزمایش و خطا ندارید، زیرا با جان انسان‌ها سروکار دارید؛ از آن‌رو، لازم است که محصول را به شیوه متعین و با تیزبینی و وسواس فراوان اجرا کنید.
برای پرهیز از اشتباه‌های رایج در این حوزه به این موارد توجه داشته باشید:
- چابکی به معنی ساخت محصول تطبیقی است و نه به‌کار بردن برچسب‌ها و مراسم ویژه.
- هر نسخه قابل استفاده‌ای از محصول مجموعه‌ای از تحویل‌شدنی‌هاست، ولی هر مجموعه‌ای از تحویل‌شدنی‌ها نسخه‌ای قابل استفاده از محصول نیست.
- هدف اصلی از گردآوری بازخورد در روش‌های متعین شناسایی مسیر پیش‌روست و نه اصلاح آنچه پیشتر انجام شده است.
در پایان، به این موضوع هم توجه داشته باشید که منظور از روش ساخت محصول تطبیقی، روش ساختیست که درون یک پروژه و برای یک محصول به کار می‌رود. اگر یک پروژه‌ای را اجرا کنید و بر پایه آموخته‌هایتان پروژه بعدی را بهتر اجرا کنید، نوعی از انطباق وجود دارد، ولی این انطباق مفهوم دیگریست که ارتباط مستقیمی با انطباق مدنظر در روش‌های تطبیقی ندارد.