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

نگاهی نزدیک‌تر به مانیفست چابک

توسعه چابک (Agile) یکی از متدهای محبوب تولید نرم‌افزار است که به جای تولید و تحویل یکباره محصول، آن را در چرخه‌های کوتاه مدت تولید و به مشتری تحویل می‌دهد. متد چابک در سال ۲۰۰۱ توسط ۱۷ توسعه‌دهنده نرم‌افزار معرفی شد، آنها برای توصیف این نگرش مانیفستی را متشکل از ۴ اصل منتشر کردند. اکثر افرادی که با این متد سر و کار دارند با بیانیه چابک آشنا هستند. اما لازم است تا با نگاهی دقیق‌تر به بیان مثال‌هایی از این اصول بپردازیم، این مثال‌ها فعالیت‌هایی هستند که ممکن است روزانه انجام می‌دهیم.

  1. افراد و تعاملات بالاتر از فرایندها و ابزارها هستند
  2. نرم‌افزار کار کننده بالاتر از مستندات جامع است
  3. مشارکت مشتری بالاتر از قرارداد کاری است
  4. پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه است

۱- افراد و تعاملات بالاتر از فرایندها و ابزارها هستند
ما همیشه به دنبال بهترین ابزارها هستیم تا فعالیت‌های کاری را بهتر از گذشته انجام دهیم. ولی قبل از انتخاب یک ابزار جدید باید توجه داشته باشیم که این ابزار علاوه بر کمک به ما قرار است چه تاثیری بر روی ارتباط افراد یک تیم بگذارد؟ این تاکید به این دلیل است که افراد و تعاملات بین آنها هستند که عملکرد مناسب یک تیم را تضمین می‌کنند نه صرفا ابزارهای جدید. برنامه‌نویسی دونفره (Pair Programming)، ادغام مداوم کدها (Continuous Integration)، جلسه هماهنگی روزانه (Stand Up) همه از نمونه فعالیت‌هایی هستند که در آنها فرآیندها و ابزارها را در خدمت ایجاد تعامل و ارتباط افراد با هم هستند. توجه به این اصل باعث می‌شود تا ارزش‌های زیر در یک تیم ایجاد شود:

  • احترام به ارزش هر فرد
  • شفافیت در تمام اطلاعات، تصمیمات و فعالیت‌ها
  • اطمینان از این موضوع که هر فردی از تیم خود حمایت می‌کند
  • تعهد به تیم و اهداف آن

۲- نرم‌افزار کارکننده بالاتر از مستندات جامع
مستندسازی در توسعه ‌نرم‌افزار همیشه زمان بسیاری را از اعضای تیم می‌گرفته. عدم مستندسازی مناسب می‌تواند در چرخه‌های بعدی توسعه باعث درک اشتباه دیگر توسعه‌دهندگان از سیستم شود. ولی هدف ما در چابک ارایه قطعه کدهای کوچک در بازهای زمانی کوتاه است. نباید بگذاریم صرف زمان بر روی مستندسازی خللی در کارمان ایجاد کند. به همین دلیل برای شروع مستندات را به دو دسته تقسیم می‌کنیم:

  • مستندانی که به کاربران کمک می‌کند تا کار با سیستم را یاد بگیرند.
  • مستندانی که به توسعه‌دهندگان کمک خواهد کرد تا نحوه برخورد با مشکلات و باگ‌های محصول را متوجه شوند.

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

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

۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه است
جمله معروفی است که می‌گوید مردم هیچ وقت نمی‌دادنند که چه می‌خواهند مگر زمانی ‌که شما آن چیز را به آن‌ها نشان دهید. حتی «هنری فورد» هم گفت: اگر از مشتری‌هایم می‌پرسیدم چه می‌خواهند، می‌گفتند یک اسب تندروتر!
در مدل سنتی توسعه نرم‌افزار حتی زمانی که یک محصول با توجه به برنامه‌ریزی قبلی با موفقیت به سرانجام می‌رسید، باز هم رضایت کامل مشتریان را به دنبال نداشت. همین موضوع باعث شد تا تیم‌های چابک تغییرات را با آغوش باز بپذیرند و نگران بهبود چند باره فیچرهای جدید نباشند.
در واقع ما به دنبال رضایت مشتری هستیم و همانطور که بازخوردهای او را در انتهای هر چرخه تحویل می‌گیریم. باید نتایج را تحلیل و تغییرات جدید را اعمال کنیم.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *