مدیریت پروژه چابک، یک رویکرد تکراری برای مدیریت پروژه است که روی تقسیم و تجزیه پروژه‌های بزرگ به تسک‌های قابل‌کنترل و کوچکتر تمرکز دارد. مدیریت چابک به تیم‌ها این امکان را میدهد که برای تغییر سریع جهت و تمرکز پروژه، از تجهیزات بهتری برخوردار شوند.
با توجه به پیشرفت مداوم کسب‌وکارها، روش مدیریت چابک می‌تواند چشم‌انداز موفقیت پروژه شما را تا حد زیادی افزایش دهد. رویکرد چابک به عنوان راهی برای تکمیل کارها در دنیای پیچیده و همیشه در حال تغییر، به سرعت در حال کسب محبوبیت است. رویکرد چابک در فرهنگ‌های سازگاری رشد میکند که اعضای تیم با سرعت تغییر ایجاد می‌کنند. در این راهنما، درباره مدیریت پروژه چابک، مولفه‌ها و اصول کلیدی آن و نحوه اجرای رویکرد چابک، نکات مفیدی خواهید آموخت.
مدیریت پروژه چابک یا اجایل (Agile Project Management - APM)، یک رویکرد تکراری برای مدیریت پروژه است که روی تقسیم و تجزیه پروژه‌های بزرگ به وظایف (Task) قابل کنترل و کوچکتر تمرکز دارد؛ پروژه‌هایی که با تکرارهای کوتاه در طول چرخه عمر پروژه تکمیل می‌شوند. Agile برای تمرکز بر بهبود مستمر در توسعه محصول یا خدمات، از چرخه‌های توسعه کوتاه به نام اسپرینت (Sprint) استفاده میکند.
تطبیق پذیری؛ یعنی توانایی تغییر دادن یا تغییر کردن، متناسب با شرایط جدید و توانایی انطباق سریع و کارآمد با تغییرات، یک مهارت حیاتی برای رهبران است. این موضوع برابر با هنر انعطاف‌پذیری تحت تأثیر تغییر سریع شرایط خارجی است. رهبر چابک بودن به معنای انعطاف‌پذیری، پاسخگویی در برابر تغییرات و تمایل به یادگیری و اتخاذ راه‌های جدید است که منجر به بقای موثر و موفقیت در فضای رقابتی تجارت مدرن می‌شود. افرادی که از نظر سازگاری و توانایی چابکی امتیاز بالایی کسب می‌کنند، می‌توانند با تغییر کردن مقابله مثبت‌تری داشته باشند و می‌توانند رویکرد خود را برای تغییر نیازها تطبیق داده و اولویت‌های خود را تغییر دهند.
مدیریت چابک همانطور که از نامش پیداست، به تیم‌ها این امکان را میدهد که برای تغییر سریع جهت و تمرکز پروژه، از تجهیزات بهتری برخوردار شوند. شرکت‌های نرم‌افزاری و آژانس‌های بازاریابی، بیش از هر کسب‌وکار دیگری از تمایل ذینفعان پروژه به تغییر پروژه، آگاه هستند. رویکرد چابک، تیم‌ها را قادر می‌سازد تا کارهایی که انجام می‌دهند را دوباره ارزیابی کرده و تنظیم کنند تا مطمئن شوند با تغییر کار و چشم‌انداز مشتری، تمرکز تیم نیز تغییر میکند.
اگر در مدیریت پروژه چابک تازه‌کار باشید، ممکن است این روش در ابتدا برایتان یک سیستم پیچیده و دشوار برای مدیریت به نظر برسد. اما، چه متوجه آن شوید چه نشوید، در حال حاضر هم بسیاری از کارهایی را که به رویکرد چابک نیاز دارد، انجام می‌دهید. به این صورت که با وقوع چند تغییر سریع، به دنبال چرخه‌های توسعه کوتاه‌تر و عرضه محصولات کوچکتر و مکرر هستید.
رویکرد چابک در مدیریت پروژه که در ابتدا برای توسعه نرم‌افزار و تیمهای کسب‌وکارهای IT ایجاد شده بود، اکنون توسط انواع دیگری از کسب‌وکارها نیز مورداستفاده قرار گرفته‌است. بازاریابان، دانشگاه‌ها، ارتش و حتی صنعت خودرو نیز به دنبال مدیریت پروژه با رویکرد چابک هستند تا بتوانند محصولاتی نوآورانه را در محیط‌های نامشخص ارائه دهند.
در دنیای نرم‌افزار، وقتی تصمیم به ساخت یا توسعه بیشتر یک فناوری موجود گرفته می‌شود، تعریف محصول نهایی دشوار است. Agile این ابهام را به دلیل انعطاف‌پذیری در تغییر جهت پروژه، همزمان با حرکت روند کار به سمت آینده، امکان‌پذیر می‌سازد.
هر تیمِ Agile منحصربهفرد است و درک اصول آن می‌تواند به شما کمک کند یک روش Agile که برای شما و تیمتان مناسب است را تنظیم کنید.
هر پروژه‌ای که به روش چابک مدیریت می‌شود دارای پنج جزء کلیدی است. این اجزاء در قسمت‌های مختلف پروژه بررسی و به‌کار گرفته می‌شوند که در ادامه با آنها آشنا می‌شوید:
۱- داستان‌های کاربر (User stories): به زبان ساده، داستان کاربر تعریف سطح بالایی از درخواست کار است که شامل اطلاعات کافی برای این است که تیم بتواند برآورد معقولی از تلاش مورد نیاز برای انجام درخواست، ارائه دهد. این توضیح کوتاه و ساده از دیدگاه کاربر نوشته شده است و بر تشریح خواسته‌های مشتری شما (اهدافشان) و دلیل آن متمرکز است.
۲- اسپرینت (Sprints): Sprint در لغت به معنی «دوی سرعت» است؛ اما در مدیریت چابک، اسپرینت یک تکرار کوتاه از کار است که معمولاً بین یک تا سه هفته، در زمانی که تیم‌ها روی وظایف تعیین شده در جلسه برنامه‌ریزی اسپرینت کار می‌کنند، تکمیل می‌شود. ایده این است که همزمان با پیش‌روی پروژه، این اسپرینت‌ها را به طور مداوم تکرار کنید تا محصول شما آماده شود. پس از اتمام هر اسپرینت، شما محصول را مرور می‌کنید تا ببینید چه چیزهایی کار می‌کنند و چه چیزهایی کار نمی‌کنند، تنظیمات مورد نیاز را انجام می‌دهید و دوباره یک اسپرینت دیگر را برای بهبود محصول یا خدمات خود شروع می‌کنید.
۳- جلسات استندآپ (Stand-up meetings): جلسات استندآپ روزانه که مدت آن معمولا زیر 10 دقیقه است و به آن «جلسات روزانه اسکرام» نیز می‌گویند، یک روش عالی برای اطمینان از این است که همه از تمام موضوعات مربوط به پروژه آگاه و در مسیر درستی هستند. این تعاملات روزمره به این دلیل با عنوان «استندآپ» شناخته می‌شوند که شرکت‌کنندگان باید در آن بایستند و کمک کنند که جلسات بصورت کوتاه و با پرداختن به موضوع هدف اصلی، برگزار شوند.
۴- تخته چابک (Agile board): استفاده از یک تخته چابک به تیم شما کمک میکند که پیشرفت پروژه را دنبال کنند. این تخته می‌تواند یک تخته سفید ساده با یادداشت‌های روی آن باشد و یا عملکردی در نرم‌افزار مدیریت پروژه شما.
۵- بک لاگ (Backlog): همانطور که درخواست‌های پروژه از طریق سیستم ورودی شما دریافت می‌شوند، در موارد عقب مانده به داستان‌های برجسته تبدیل می‌شوند. در طول جلسات برنامه‌ریزی چابک، تیم شما امتیازات داستانی مربوط به هر کار را تخمین می‌زند. در طول برنامه‌ریزی اسپرینت‌ها، داستان‌های موجود در بک لاگ به درون اسپرینت منتقل می‌شوند تا در طول تکرار چرخه اسپرینت تکمیل شوند. مدیریت بک لاگ‌ها برای مدیران پروژه در یک محیط چابک نقش حیاتی دارد.
مدیریت پروژه چابک مزایای بی‌شماری را برای سازمان‌ها، تیمهای پروژه و محصولات فراهم میکند. مزایای اصلی و چگونگی به حداکثر رساندن آنها به شرح زیر است:
۱- کیفیت بهتر محصول: متدهای چابک دارای تضمینی برای اطمینان از بالاترین حد کیفیت محصولات را دارند که توسط عومل زیر ایجاد می‌شود:
- اتخاذ رویکردی پیشگیرانه نسبت به کیفیت، برای جلوگیری از مشکلات محصول
- استفاده از مزیت‌های تکنولوژی، طراحی خوب و توسعه پایدار در پروژه‌ها
- تعیین و شرح دقیق به موقع الزامات و نیازمندی‌های پروژه، به طوری که اطلاعات موجود درباره ویژگی‌های محصول، تا حد ممکن مرتبط باشد.
- آزمایش روزانه در فرآیند توسعه که به تیم توسعه، امکان حل مسائل تازه را میدهد.
- استفاده از ابزارهای تست اتوماتیک به منظور توسعه در طول روز
- بازنگری اسپرینت‌ها که به تیم اسکرام امکان بهبود مداوم فرآیندها و کار را میدهد.
۲- رضایت بیشتر مشتری: تیمهای پروژه چابک مشتریان را از طریق روش‌های زیر، راضی نگه می‌دارند:
- در جریان نگه داشتن مشتریان در طول پروژه‌ها
- داشتن یک مالک محصول که در زمینه نیازهای محصول و نیازهای مشتری خبره باشد.
- به روزرسانی و اولویت‌بندی بک لاگ محصولات، به منظور پاسخ سریع به تغییرات
- نشان دادن عملکرد کار به مشتریان در هر اسپرینت
- عرضه سریع‌تر و بیشتر هر نسخه از محصولات به بازار
۳- روحیه‌ی تیمی بالاتر: عضویت در یک تیم خودگردان به اعضای آن اجازه میدهد که خلاق، نوآور و متخصص شناخته شوند. داشتن اسکرام مستر موانع را برطرف میکند و تیم توسعه را از تداخل خارجی محافظت میکند. کارکرد متقابل عملکردی به اعضای تیم توسعه این امکان را میدهد تا مهارت‌های جدید را بیاموزند و با آموزش به دیگران، رشد کنند.
۴- افزایش همکاری و مالکیت: تیم توسعه‌دهنده، مدیرمحصول و اسکرام مستر به طور روزانه با هم همکاری نزدیک دارند. جلسات اسکرام روزانه به تیم توسعه اجازه میدهد تا در مورد کارهای انجام شده، کارهای آینده و موانع بر سر راه، با یکدیگر مشورت و آنها را سازماندهی کنند. در طی بررسی‌های اسپرینت‌ها، تیم توسعه می‌تواند محصول را مستقیماً برای ذینفعان به نمایش بگذارد و در مورد آنها بحث کند.
۵- ساختارهای تیمی سفارشی: به دلیل اندازه محدود تیمهای توسعه (پنج تا نه نفر)، پروژه‌های چابک می‌توانند چندین تیم اسکرام را درون یک پروژه داشته باشند. خودمدیریتی و محدودیت اندازه به این معنی است که پروژه‌های چابک می‌توانند فرصت‌های منحصر به فردی برای سفارشی‌سازی ساختارهای تیمی و محیط کار فراهم کنند.
۶- قابلیت بهتر مشاهده عملکرد پروژه: در پروژه‌های چابک، هر یک از اعضای تیم پروژه این فرصت را دارند که بدانند پروژه در هر زمان مشخص چگونه پیش می‌رود. جلسات روزانه اسکرام، مرور روزانه اسپرینت و نمودارهای پیشرفت پروژه، روش‌های مشخصی را برای دیدن میزان پیشرفت پروژه ارائه می‌دهند.
۷- افزایش کنترل پروژه: فرصت‌های فراوانی که برای بازرسی و سازگاری در طول پروژه‌های چابک وجود دارد، به همه اعضای تیم پروژه یعنی تیم توسعه‌دهنده، مدیر محصول، اسکرام مستر و ذینفعان، امکان کنترل و تولید محصولات بهتر را میدهد.
جمع‌بندی
موارد ذکر شده اساسی‌ترین قسمت‌های مدیریت پروژه جابک هستند. وقتی که شما روش مدیریت تیم خود را به متد چابک منتقل می‌کنید، این فرایندها، نرم‌افزار و ابزارها، نقش‌ها و اصول رویکرد چابک، به شما کمک می‌کنند که طرز تفکر خود را تغییر داده و کاری مشترک را شروع کنید تا انعطاف پذیرتر باشد و با تغییراتی که ایجاد می‌شود، سازگار شوید. مدیریت چابک برای همه مناسب نیست، اما تیم‌هایی که به درستی از آن استفاده می‌کنند، مزایای زیادی از جمله روند کار ساده و نوآوری سریع را تجربه می‌کنند.
به طور خلاصه مزایای این مدیریت شامل ایجاد سریع راه حل‌ها، استفاده موثر از منابع، انعطاف پذیری بیشتر و سازگاری با نیازهای متغیر، تشخیص سریع‌تر مشکلات و از این رو رفع سریع‌تر مشکلات است. همچنین از دیگر مزایای آن همکاری و تعامل با کاربران است که باعث می‌شود محصولاتی که به نیازهای کاربران بیشتر و بهتر پاسخ میدهد افزایش یابد.
پروژه‌ها برای طی مسیر، اسناد کمتری دارند که در نتیجه کمتر قابل پیش بینی هستند.
ممکن است متدولوژی‌های چابک در سازمان‌های بزرگ و انواع خاصی از پروژه‌ها ناکارآمد باشند.
متدهای چابک برای پروژه‌های توسعه‌ای و غیردائمی مناسب است.
بسیاری از سازمان‌ها باور دارند متدولوژی‌های چابک بسیار قوی هستند و با یک رویکرد مخلوط که ترکیبی از المان‌های رویکردهای چابک و برنامه‌محور است، سازگار می‌شوند.
مدیریت پروژه چابک یا همان Agile Project Management که آن را با نام اختصاری (APM) نیز می‌شناسند یک رویکرد با استفاده از تکرار برای پروسه برنامه ریزی و مدیریت پروژه است.
یک پروژه چابک درواقع درست مانند توسعه نرم افزار چابک، با بخش‌های کوچک تکمیل می‌شود که این بخش‌های کوچک تکرار شونده‌ها نامیده می‌شوند. هر بخش یا همان تکرار شونده توسط تیم پروژه بررسی و نقد می‌شود. اعضای این تیم باید متشکل از نمایندگان ذینفغان مختلف پروژه باشند. در نهایت بینش‌هایی که از نقد یک تکرار حاصل شده است، به منظور تعیین قدم بعدی هرچه بهتر در پروژه استفاده می‌شوند.
مزیت اصلی مدیریت پروژه چابک توانایی آن برای بررسی و حل مسائلی است که در طول دوره پروژه به وجود می‌آیند. ایجاد تغییرات لازم در پروژه در زمان مناسب باعث ذخیره منابع و در نهایت منجر به ارائه یک پروژه موفق در زمان درست و با بودجه کم می‌شود.
درواقع روش مدیریت پروژه چابک، پروژه را به بخش‌های کوچک تقسیم میکند که این بخش‌ها در جلسات کاری، از مرحله طراحی تا تست و تضمین کیفیت اجرا و تکمیل می‌شوند. این بخش‌های کوچک یا همان تکرارها «اسپرینت» نامیده می‌شوند و در یک تکنیک خاص و ویژه مدیریت پروژه چابک به نام « اسکرام» به کار برده می‌شود.
اسپرینت‌ها به طور کلی کوتاه هستند و بیش از چند روز یا چند هفته اجرا می‌شوند و معمولا ۲ تا ۴ هفته به طول می‌انجامند.
متد چابک تیم‌ها را قادر می‌سازد تا در طول تکمیل پروژه بخش‌های مختلف را رصد کنند که این برنامه کنترل مداوم بخش‌ها باعث می‌شود تا تشخیص دهند که آیا این بخش‌ها موفق عمل کرده‌اند یا خیر و در غیر اینصورت بلافاصله و به سرعت نقص‌ها را برطرف کنند. اعتقاد بر این است که این روش کمک میکند تا احتمال شکست در بخش‌های بزرگ و کلی تا حد زیادی کاهش یابد، زیرا بخش‌های کوچک در طول چرخه عمر پروژه به طور مداوم در حال بررسی و بهبود یافتن هستند.
تیمهای مدیریت چابک، بازخوردهای خیلی سریع، سازگاری مداوم و بهترین شیوه‌ها در تکرار آنها را می‌سازند.
آنها شیوه‌هایی مانند استقرار مداوم و پیوستگی مداوم را با استفاده از تکنولوژی‌های خودکار برای سرعت بخشیدن به انتشار و استفاده از محصولات اتخاذ می‌کنند.
به علاوه، مدیریت پروژه چابک از تیم‌ها می‌خواهد که همزمان با انجام کار، به طور مداوم زمان و هزینه را برآورد و ارزیابی کنند. آنها به جای نمودار گانت (Gantt Chart)، برای ارزیابی و اندازه‌گیری پیشرفت کار از نمودارهای burndown و burnup استفاده می‌کنند.
مدیریت پروژه چابک نیاز به حضور یا مشارکت یک مدیر پروژه ندارد. اگرچه در روش‌های سنتی مانند روش مدیریت پروژه آبشاری Waterfall (برای مدیریت بودجه، مدیریت پرسنل، دامنه پروژه، کیفیت، الزامات و سایر عناصر کلیدی) به منظور دستیابی به موفقیت حضور یک مدیر پروژه ضروری است، اما در روش مدیریت پروژه چابک، نقش مدیر پروژه در بین اعضای تیم تقسیم می‌شود.
به عنوان مثال، اهداف پروژه توسط صاحب محصول یا صاحب پروژه تعیین می‌شود و اعضای تیم برنامه ریزی، گزارش پیشرفت و سایر کارها را تقسیم می‌کنند. برخی از روش‌های مدیریت چابک پروژه لایه‌های دیگری از مدیریت را نیز اضافه می‌کنند مانند: استفاده از رویکرد اسکروم که به تعیین اولویت‌ها کمک میکند و می‌تواند پروسه تکمیل پروژه را بهبود بخشد.
با این حال در روش مدیریت پروژه چابک، مدیران پروژه هنوز منسوخ نشده‌اند و از آنها استفاده می‌شود. بسیاری از سازمان‌ها به خصوص در پروژه‌های بزرگ‌تر و پیچیده‌ترهنوز برای این روش از مدیران پروژه استفاده می‌کنند. البته سازمان‌ها بیشتر این مدیران پروژه را در نقش هماهنگ کننده با مسئول پروژه به کار می‌گیرند.
حتما بخوانید: تفاوت بیزینس پلن (Business Plan) با پروپوزال (Business Proposal) چیست؟
با توجه به تغییر کار از مدیران پروژه به تیمهای چابک، متد مدیریت پروژه چابک از اعضای تیم می‌خواهد که چگونگی کار در این متد جدید را بیاموزند. آنها باید قادر باشند که با همان کیفیت که با کاربران در تعامل هستند با دیگر اعضای تیم نیز در تعامل باشند. علاوه بر این باید بتوانند با یکدیگر به طور صحیح ارتباط برقرار کنند تا پروژه‌ها در مسیر درست خود و با موفقیت پیش روند. همچنین باید توانایی انجام اقدامات مناسب در زمان مناسب را داشته باشند تا بتوانند با تحولات مداوم پروژه هماهنگ باشند.
روش مدیریت پروژه چابک در مقابل روش مدیریت آبشاری
روش مدیریت پروژه چابک با روش مدیریت آبشاری متناسب بوده و متناسب نیز خواهد ماند. درواقع روش مدیریت آبشاری یک رویکرد دقیق تدریجی به پروژه‌ها دارد. به طوریکه با جمع آوری تمام الزامات قبل از شروع کار آغاز می‌شود، منابع مورد نیاز محاسبه می‌گردد، جدول زمانی و بودجه برآورد می‌شود، کار واقعی انجام می‌شود، تست می‌شود و سپس پروژه به عنوان یک کار تکمیل شده ارائه می‌گردد.
توسعه چابک نرم‌افزار یا توسعه نرم‌افزاری چابک گروهی از متدهای توسعهٔ نرم‌افزار مبتنی بر تکرار و به شکل تدریجی است که در آنها، راه‌حل‌ها از طریق خودسازماندهی و همکاری بین تیمهای مختلف کاری، انجام می‌شوند. این روش برنامه‌ریزی تطبیقی، توسعه و تحویل تکاملی و رویکرد زمان بسته‌بندیِ تکرارشونده را ارتقا می‌بخشد و پاسخ‌های سریع و انعطاف‌پذیر برای انجام تغییرات را تقویت میکند. در واقع چابک‌سازی یک چارچوب مفهومی است که پیش‌بینی تعاملات در سراسر چرخهٔ توسعه را بهبود می‌بخشد. بیانیهٔ چابک در سال ۲۰۰۱ این اصطلاح را معرفی کرد.[۱]
تاریخچه
سوابق
مارتین فولر، به عنوان یکی از بنیان‌گذاران کلیدی متدهای چابک شناخته می‌شود.
متدهای توسعهٔ افزایشی نرم‌افزار به سال ۱۹۵۷ برمی‌گردند.[۲] در سال ۱۹۷۴، E.A. Edmonds در مقاله‌ای فرایند توسعهٔ تطبیقی نرم‌افزار را معرفی کرد.[۳] همزمان و به‌طور مستقل متدهای مشابه توسعه یافت و توسط مرکز توسعهٔ سیستم‌های شرکت تلفن نیویورک زیر نظر Dan Gielan گسترش یافت. اوایل دههٔ ۱۹۷۰، Tom Gilb شروع به انتشار مفاهیمی در مورد کنترل تحولی پروژه (EVO) کرد، که به مهندسی رقابتی توسعه یافت.[۴] در طول نیمه تا انتهای دههٔ 1970 Gielan به‌طور گسترده در ایالات متحده در مورد این متدولوژی، تجارب و فواید آن سخنرانی‌هایی ارائه داد.[۲]
متدهای توسعهٔ به اصطلاح چالاک و چابک نرم‌افزار اواسط دههٔ ۱۹۹۰ به صورت یک عکس‌العمل در مقابل متدهای سنگین آبشاری مطرح شد، که توسط منتقدان آن به صورت یک مدل توسعهٔ به شدت منظم، دسته‌بندی‌شده، میکرو مدیریتی و آبشاری توصیف شده‌است. استدلال‌کنندگان متدهای چالاک و چابک ادعا می‌کنند، این متدها به منزلهٔ بازگشت به تجارب توسعهٔ نرم‌افزار در اوایل تاریخ هستند. پیاده‌سازی‌های اولیهٔ متدهای چابک، شامل Rational Unified Process (1994)، Scrum
(1995)، Crystal Clear، برنامه‌نویسیExtreme (1996)، توسعهٔ تطبیقی نرم‌افزار، توسعهٔ ویژگی‌محور و متد توسعهٔ سیستم‌های دینامیک (DSDM، ۱۹۹۵) می‌شود. بعد از انتشار بیانیهٔ چابک در سال ۲۰۰۱، اکنون این‌ها به‌طور معمول به متدولوژی‌های چابک برمی‌گردند.[۵]
در فوریهٔ ۲۰۰۱، تعداد ۱۷ توسعه‌دهندهٔ نرم‌افزار،[۶] در Snowbird یوتا ملاقاتی داشتند تا در مورد متدهای توسعهٔ چالاک گفتگو کنند.
آنها برای توصیف رویکردی که اکنون به عنوان «توسعهٔ چابک نرم‌افزار» شناخته می‌شود، بیانیه‌ای برای توسعهٔ چابک نرم‌افزار منتشر کردند. بعضی از نویسندگان این بیانیه، اتحاد Agile را ایجاد کردند؛[۱] یک سازمان غیرانتفاعی که توسعهٔ نرم‌افزار را بر اساس اصول این بیانیه ترویج میدهد.
بیانیهٔ چابک به شرح زیر است:
ما با توسعه نرم‌افزار و کمک به دیگران در انجام آن، در حال کشف راه‌های بهتری برای توسعهٔ نرم‌افزار هستیم. از این کار به ارزش‌های زیر می‌رسیم:
۱- افراد و تعاملات بالاتر از فرایندها و ابزارها
۲- نرم‌افزار کارکننده بالاتر از مستندات جامع
۳- مشارکت مشتری بالاتر از قرارداد کاری
۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.[۱]
معنی موارد سمت راست این بیانیه در مفهوم توسعهٔ چابک نرم‌افزار در زیر توضیح داده شده است:
افراد و تعاملات بالاتر از فرایندها و ابزارها
افراد مهم‌ترین نقش را در پیروزی یک پروژه دارند. یک فرایند عالی بدون نیروی مناسب منجر به شکست می‌گردد و بر عکس افراد قوی تحت فرایند وضعیت ناکارآمد خواهند بود.
یک نیروی قوی لازم نیست که برنامه‌نویسی عالی باشد، بلکه کافیست که یک برنامه‌نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران و تعامل درست و سازنده با سایر اعضای تیم خیلی مهم‌تر از این است که یک برنامه‌نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفق‌تر هستند از تعدادی برنامه‌نویس عالی که قدرت تعامل مناسب با یکدیگر را ندارند.
در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال می‌توانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گران‌قیمت از برنامه رایگان کدباز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفاً به آنها به عنوان امکانی جهت تسهیل فرایندها نگاه کنید.
نرم‌افزار کارکننده بالاتر از مستندات جامع
نرم‌افزار بدون مستندات فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم‌افزاری نیست. تیم باید مستندات قابل فهم برای مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده‌سازی آن را تشریح نماید.
با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می‌گیرد تا آن را با کد برنامه به روز نمایید. اگر آنها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم می‌شوند.
بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نمایید. البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نمایند.
اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می‌توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آنها است. ما دانش خود را با نشستن در کنار آنها و کمک کردن به آنها انتقال می‌دهیم. ما آنها را بخشی از تیم می‌کنیم و با تعامل نزدیک و رو در رو به آنها آموزش می‌دهیم.
مشارکت مشتری بالاتر از قرارداد کاری
نرم‌افزار نمی‌تواند مثل یک جنس سفارش داده شود. شما نمی‌توانید یک توصیف از نرم‌افزاری که می‌خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.
این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آنها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آنها را برآورده میکند بسازند. اما این تعامل به کیفیت پایین نرم‌افزار و در نهایت شکست آن می‌انجامد. پروژه‌های موفق بر اساس دریافت بازخورد مشتری در بازه‌های زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به‌طور تنگاتنگ با تیم توسعه کار کرده و مرتباً اعمال نظر میکند.
قراردادی که مشخص‌کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساساً نقص دارد. بهترین قرارداد این است که مشتری در ازای اینکه زودتر به نرم‌افزار سفارش داده شده خود برسد متعهد شود دفعات بیشتری به‌طور تنگاتنگ با تیم توسعه تعامل داشته باشد.
پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
توانایی پاسخ به تغییرات اغلب تعیین‌کنندهٔ موفقیت یا شکست یک پروژهٔ نرم‌افزاری است. وقتی که طرحی را می‌ریزیم باید مطمئن شویم که به اندازهٔ کافی انعطاف‌پذیر است و آمادگی پذیرش تغییرات در سطح تجاری و تکنولوژی را دارد.
مسیر یک پروژهٔ نرم‌افزاری نمی‌تواند برای بازه زمانی طولانی برنامه‌ریزی شود. اولاً احتمالاً محیط تغییر میکند و باعث تغییر در نیازمندیها می‌شود. ثانیاً همین که سیستم شروع به کار کند مشتریان نیازمندی‌های خود را تغییر می‌دهند؛ بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمی‌کنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است.
یک استراتژی خوب برای برنامه‌ریزی این است که یک برنامه‌ریزی دقیق برای یک هفتهٔ بعد داشته باشیم و یک برنامه‌ریزی کلی برای سه ماه بعد.[۷]
بر اساس نظرات Kent Beck[۸]، بیانیهٔ چابک، بر ۱۲ اصل استوار است:
رضایت مشتری از طریق تحویل زود و مداومِ نرم‌افزار مفید؛
استقبال از تغییر نیازمندیها، حتی در اواخر توسعه؛
تحویل زود به زود نرم‌افزار قابل استفاده (هفتگی به جای ماهانه)؛
نرم‌افزار قابل استفاده اصلی‌ترین معیار سنجش پیشرفت است ؛
توسعهٔ پایدار که قادر به حفظ سرعت ثابت است؛
همکاری نزدیک و روزانه بین افراد کسب‌وکار و تیم توسعه؛
گفتگوی رو در رو بهترین شکل ارتباطات است (محل مشترک)؛
پروژه‌ها در اطراف افراد باانگیزه، که باید به آنها اعتماد کرد، شکل می‌گیرند؛
توجه مستمر به برتری فنی و طراحی خوب؛
سادگی- هنر به حداکثر رساندن کارهای انجام‌نشده- ضروری است؛
بهترین معماری‌ها، نیازمندیها و طراحی‌ها از تیمهای خودسازمانده پدیدار می‌شوند ؛
در فواصل منظم تیم بر چگونگی مؤثرتر شدن تامل وتفکر می‌نماید و سپس رفتار خود را بر اساس بازتاب این تفکر تنظیم و همسو میکند.
در سال ۲۰۰۵، گروهی به ریاست Alistair Cockburn و Jim Highsmith ضمیمه‌ای تحت عنوان «اعلامیهٔ وابستگی» برای اصول مدیریت پروژه نوشتند، که مدیریت پروژه‌های نرم‌افزاری را بر اساس متدهای توسعهٔ نرم‌افزار پیش ببرد.[۹].
برنامه‌نویسی دونفره، یکی از تکنیک‌های توسعهٔ چابک از طریق XP است. به رادیاتورهای اطلاعات در پس‌زمینه توجه کنید.
متدهای توسعهٔ چابک مشخص زیادی وجود دارند، که بیشترشان توسعه، کار تیمی، همکاری و سازگاری فرایند در چرخهٔ حیات پروژه را ترفیع می‌دهند. متدهای چابک وظایف را به گام‌های کوچک با کمترین میزان برنامه‌ریزی می‌شکنند که به‌طور مستقیم با برنامه‌ریزی‌های طولانی‌مدت درگیر نیستند. تکرارها فریم‌های (بسته‌های زمانی) کوتاه‌مدتی هستند که معمولاً بین یک تا چهار هفته طول می‌کشند. هر تکرار دارای یک تیم متقابل عملکردی در تمام مأموریت‌ها است: تحلیل نیازمندیها، طراحی، کدنویسی، واحد تست، و قبولی در تست. در پایان هر تکرار یک محصول کاری به ذینفعان نشان داده می‌شود. این، ریسک کلی را به حداقل رسانده و اجازه میدهد پروژه خیلی سریع با تغییرات منطبق شود. ممکن است یک تکرار قابلیت کافی برای تضمین پخش در بازار را نیفزاید، اما هدف، انتشار در دسترس (با حداقل شکاف) در پایان هر تکرار است. شاید تکرارهای چندگانه نیاز به انتشار یک محصول یا ویژگی‌های جدید داشته باشند.[۱۰] ترکیب تیم در یک پروژهٔ چابک معمولاً عملکردی متقابل و خودسازماندهی است، بدون توجه به هرگونه سلسله‌مراتب شرکتی یا نقش‌های شرکتی اعضای تیم. اعضای تیم به‌طور معمول مسئولیت وظایفی را که قابلیت نیازهای تکرار را ارائه میدهد، بر عهده می‌گیرند. آنها به صورت جداگانه تصمیم می‌گیرند که چگونه با نیازمندی‌های یک تکرار مواجه شوند.
متدهای چابک، وقتی تیم‌ها با هم در یک مکان هستند، بر ارتباطات رو در رو برای تمام مستندات نوشته‌شده تأکید دارد. بیشتر تیمهای چابک در یک دفتر تک‌واحدی (به نام bullpen) کار می‌کنند، که چنین ارتباطاتی را تسهیل میکند. به منظور ساده کردن ارتباطات و همکاری تیمی، گروه معمولاً کوچک (بین ۵ تا ۹ نفره) است. پروژه‌های بزرگ توسعه می‌توانند توسط تیمهای کاری چندگانه در راستای یک هدف رایج یا در بخش‌های متفاوت یک پروژه تحویل شوند. ممکن است این امر نیاز به هماهنگی اولویت‌های تمام تیم‌ها داشته باشد. وقتی تیمی در مکان‌های مختلفی کار میکند، افراد ارتباط روزانه‌شان را از طریق ویدئو کنفرانس، صدا، ایمیل و... حفظ می‌کنند.
مهم نیست چه دیسیپلین‌های توسعه‌ای لازم است، هر تیم چابک، یک پاسخگوی مشتری دارد. این شخص توسط ذینفعان به نمایندگی انتخاب می‌شود و یک تعهد فردی ایجاد میکند که برای پاسخگویی به سؤالات اواسط تکرار، در دسترس توسعه‌دهندگان باشد.[۱۱] در انتهای هر تکرار، ذینفعان و نمایندهٔ مشتریان پیشرفت را بررسی می‌کنند، اولویت‌ها را با دید بهینه‌سازی بازگشت سرمایه (ROI) مجدداً می‌سنجند و از انطباق نیازهای مشتری با اهداف شرکت اطمینان حاصل می‌کنند. بیشتر پیاده‌سازی‌های چابک از ارتباطات غیررسمی، روزانه و رو در رو در میان اعضای تیم بهره می‌گیرند. این به‌طور خاص شامل نمایندهٔ مشتری و هر کدام از ذینفعان علاقه‌مند به عنوان ناظر می‌شود. در یک جلسهٔ مختصر، هر کدام از اعضای تیم گزارش می‌دهند که در روز گذشته چه کرده‌اند، قصد دارند در روز جاری چه کارهایی انجام دهند و موانع پیش روی‌شان کدامند. این ارتباطات رو در رو مشکلات را به محض بروز، افشا میکند. «این جلسات روزانه، گاهی به صورت ایستاده یا نشست‌های اسکرام هر روز در یک زمان و مکان ثابت برگزار می‌شوند و نباید بیش از ۱۵ دقیقه طول بکشند. معمولاً جلسات ایستاده این نقش را دارند.»[۱۲]
توسعهٔ چابک بر کار نرم‌افزار به عنوان مقیاس اصلی پیشرفت تأکید دارد، که با مزیت ارتباطات رو در رو در هم آمیخته شده، و نسبت به سایر متدها مستندات مکتوب کمتری تولید می‌شود. متد چابک ذینفعان را به اولویت‌بندی «خواسته‌ها» با نتایج حاصل از سایر تکرارها، بر اساس ارزش کسب‌وکار مشاهده‌شده در ابتدای تکرار (که با عنوان ارزش‌محور شناخته می‌شود) ترغیب میکند.[۱۳]
ابزارها و تکنیک‌های خاص، مانند یکپارچه‌سازی مستمر، تست اتوماتیک یا xUnit، برنامه‌نویسی دوجزئی، توسعهٔ آزمون‌محور، الگوهای طراحی، طراحی دامنه‌محور، code refactoring و دیگر تکنیک‌ها اغلب برای بهبود کیفیت و افزایش چابکی پروژه به کار می‌روند.
توسعهٔ کمی‌چابک (LAD) چاشنی متدولوژی چابک است که تکنیک‌های دست‌چین را (از طیف وسیع‌تری از پروژه‌های چابک) برای شرکت‌های مناسب مختلف، تیم‌ها، موقعیت‌ها و محیط‌های توسعه به کار می‌بندد. یکی دیگر از جنبه‌های کلیدی LAD متمایل به کاربرمحور بودن است، در درجهٔ اول بر تجارب کاربر و واسط‌های نرم‌افزاری قابل‌استفاده تمرکز میکند و برای تحویل آنها متدولوژی‌های چابک را به کار می‌بندد. بیشتر پیاده‌سازی‌های چابک دنیای واقعی در عمل واقعاً LAD هستند، چون ارزش اصلی متدولوژی به انعطاف‌پذیری، معقول بودن و تمرکز بر کارهایی که انجام شده، است.
در توسعهٔ چابک نرم‌افزار، یک رادیاتور اطلاعات، صفحه‌نمایشی فیزیکی (معمولاً بزرگ) واقع در صدر دفتر کار است، جایی که رهگذران بتوانند آن را ببینند. این صفحه‌نمایش خلاصه‌ای از آخرین وضعیت محصول (های) نرم‌افزاری را نمایش میدهد. این نام توسط Alistair Cockburn ابداع و در کتاب «توسعهٔ چابک نرم‌افزار» در سال ۲۰۰۲ توصیف شد.[۱۴][۱۵] ممکن است یک نشانگر نوری برای آگاه کردن اعضای تیم در مورد وضعیت فعلی پروژه‌شان به کار رود.
متدهایی در زنجیرهٔ بین انطباقی تا پیشگویانه وجود دارند.[۱۶] متدهای چابک در بخش انطباقی این زنجیره قرار دارند. متدهای انطباقی بر انطباق سریع با واقعیات تغییریافته متمرکز است. وقتی نیازهای یک پروژه تغییر میکند، یک تیم انطباقی نیز تغییر میکند. یک تیم انطباقی به سختی توضیح میدهد که در آینده دقیقاً چه اتفاقی خواهد افتاد. در متد انطباقی هرچه تاریخ دورتر باشد، ابهام در بیان اینکه در آن تاریخ چه اتفاقی خواهد افتاد، بیشتر است. یک تیم انطباقی نمی‌تواند وظایفی را که اعضا در هفتهٔ آینده خواهد داشت گزارش دهد، تنها می‌تواند ترکیب کارهایی را که برای ماه آینده قرار است انجام شود بیان کند. وقتی در مورد انتشار شش ماه از حالا سؤال می‌شود، یک تیم انطباقی ممکن است فقط بتواند بیانیهٔ مأموریت (برای آن انتشار) یا بیانیهٔ ارزش موردانتظار در مقابل هزینه را گزارش دهد.
در مقابل، متدهای پیشگویانه، بر تحلیل و برنامه‌ریزی آینده به صورت جزئی و برای ریسک‌های شناخته‌شده تمرکز دارد. در نهایت، یک تیم پیشگویانه می‌تواند دقیقاً گزارش دهد که چه ترکیب کار و چه وظایفی در سرتاسر فرایند توسعه برنامه‌ریزی شده‌است. متدهای پیشگویانه بر فاز ابتدایی و اثربخش تحلیل تکیه دارد و اگر این فاز با اشتباه زیادی پیش رود، ممکن است جهت پروژه به سختی اصلاح شود. تیمهای پیشگویانه اغلب یک هیئت کنترل تغییر ایجاد می‌کنند تا اطمینان یابند که تنها به تغییرات با ارزش فکر می‌شود.
متدهای رسمی، بر خلاف متدهای انطباقی و پیشگویانه، بر تئوری علوم کامپیوتری با طیف گسترده‌ای از انواع مفاهیم ثابت تکیه دارد. یک متد رسمی می‌کوشد تا نبود خطاها را با درجه‌ای از جبرگرایی ثابت کند. بعضی متدهای رسمی مبتنی بر بررسی مدل هستند و مثال‌های متضادی برای کدهایی که نمی‌توان ثابت کرد، فراهم می‌کنند. تیمهای چابک ممکن است متدهای رسمی بسیار منظمی به کار گیرند.[۱۷]
متدهای چابک که از دههٔ ۹۰–۱۹۸۰ توسط James Martin و دیگران حمایت شدند، اشتراکات زیادی با «توسعهٔ سریع اپلیکیشن‌ها» دارند. علاوه بر متدهای مبتنی بر تکنولوژی، متدهای مشتری‌محور و طراحی‌محور (مانند نمونه‌سازی سریع تجسم‌محور که توسط Brian Willison توسعه یافت)، مشتریان و کاربران نهایی را به تسهیل توسعهٔ چابک نرم‌افزار تشویق می‌کنند.
در سال ۲۰۰۸ مؤسسهٔ مهندسی نرم‌افزار (SEI) گزارش فنی «CMMI یا چابک: چرا هر دو نه؟» را برای روشن کردن اینکه مدل یکپارچهٔ قابلیت بلوغ (CMMI) و مدل چابک هر دو می‌توانند وجود داشته باشند، منتشر کرد. CMMI ورژن ۱٫۳ شامل تیپ‌هایی برای پیاده‌سازی چابک و CMMI است.[۱۸][۱۹]
یکی از تفاوت‌های بین چابک و آبشاری، این است که تست نرم‌افزار در نقاط مختلفی در چرخهٔ عمر توسعهٔ نرم‌افزار انجام می‌شود. در مدل آبشاری، یک فاز تست به صورت جداگانه بعد از پیاده‌سازی وجود دارد. در چابک XP، به‌طور همزمان با پیاده‌سازی انجام می‌شود. به‌طور کلی اگر بیشتر ناشناخته‌ها شناخته شوند (مانند نیازمندی‌های خوبی که تا آن زمان تحلیل شده‌اند)، رویکرد پیشگویانه ممکن است مناسب‌تر باشد. اما اگر ناشناخته‌های شناخته‌نشدهٔ زیادی وجود داشته باشد (مانند نیازمندی‌هایی که ضعیف شناخته‌شده‌اند و هنوز بهبود نیافته‌اند)، رویکرد چابک اجازهٔ بلوغ تدریجی و پیاده‌سازی را میدهد.
متدهای معروف توسعهٔ چابک نرم‌افزار عبارتند از:
مدل‌سازی چابک
فرایند یکپارچهٔ چابک (AUP)
Crystal Clear
متدهای Crystal
متدهای توسعهٔ سیستم‌های دینامیک (Dynamic Systems Development Method)
برنامه‌نویسی اکستریم (Extreme Programming)
توسعهٔ ویژگی‌محور (Feature-driven Development)
طراحی گرافیکی سیستم (Graphical System Design)
توسعه Kanban
توسعه Lean
Scrum
ردیابی سرعت
سازماندهی متد
در، اصطلاحات متفاوتی به مفهوم متد انطباقی برمی‌گردد، شامل «سازماندهی متد»، «تطابق قطعات متد» و «مهندسی موقعیتی متد». مناسب‌سازی متد به صورت زیر تعریف می‌شود:
فرایند یا قابلیتی که در آن عوامل انسانی یک رویکرد توسعهٔ سیستم را برای موقعیت پروژه‌ای خاص از طریق تغییرات پاسخگو در، و اثرات متقابل دینامیک بین زمینه‌ها، مفاهیم و قطعات متد تعریف می‌کنند.[۲۰]
به‌طور بالقوه، تقریباً تمام متدهای چابک برای سازماندهی متد مناسب هستند. حتی متد DSDM نیز با این هدف به کار گرفته شده و با موفقیت در یک زمینهٔ CMM سازماندهی می‌شود.[۲۱] اقتضای وضعیت، به عنوان یک مشخصهٔ متمایز بین متدهای چابک و متدهای توسعهٔ سنتی نرم‌افزار مطرح است، دومی نسبتاً جدی‌تر و تجویزی است.
پیاده‌سازی کاربردی این است که متدهای چابک به تیمهای پروژه اجازهٔ تطبیق روش‌های کاری را با نیازهای پروژه‌های منحصربهفرد بدهند. روشها فعالیت‌ها و محصولات به هم پیوسته‌ای هستند که بخشی از یک چارچوب متد را تشکیل می‌دهند. در یک سطح خیلی بالاتر، فلسفهٔ پشت متد، شامل تعدادی اصول است که می‌توانند منطبق باشند (Aydin، 2004).[۲۰]
برنامه‌نویسی Extreme (XP) نیاز به انطباق متد را شفاف میکند. یکی از ایده‌های بنیادین XP این است که هیچ فرایندی برای تمام پروژه‌ها مناسب نیست، اما ترجیحاً روشها باید برای هر پروژهٔ منحصربهفرد سازماندهی [مناسب‌سازی] شوند. انطباق جزئی روش‌های XP، که توسط Beck طرح شد، در موارد مختلفی گزارش شده‌است.[۲۲]
یک روش سازماندهی پیشنهاد میکند که یک نقشهٔ راه و راهنماهای مناسب برای انطباق با تمام روشها ارائه میدهد. روش RDP برای سفارشی‌سازی XP طراحی شده‌است. این روش، برای اولین بار در کارگاه APSO در کنفرانس ICSE 2008، به عنوان یک مقالهٔ تحقیقاتی طولانی طرح شد، و اکنون نیز تنها متد طراحی‌شده و قابل‌اجرا برای سفارشی‌سازی XP است. اگرچه این روش به‌طور خاص راه‌حلی برای XP است، اما قابلیت توسعه برای سایر متدولوژی‌ها را دارد.[۲۳]
در نگاه اول، این روش در گروه متدهای استاتیک انطباق به نظر می‌رسد، اما آزمایش‌ها با روش RDP می‌گوید این روش می‌تواند مانند یک متد دینامیک انطباق عمل کند. تفاوت ظریفی بین متدهای استاتیک انطباق و متدهای دینامیک انطباق وجود دارد. فرض کلیدی در مورد متد استاتیک انطباق این است که زمینهٔ پروژه در ابتدای یک پروژه داده می‌شود و در طول اجرای پروژه نیز ثابت می‌ماند. نتیجه یک تعریف استاتیک از زمینهٔ پروژه است. با دادن چنین تعریفی و با استفاده از مسیر نقشه‌ها می‌توان تعیین کرد کدام قسمت متد ساخت‌یافته، بر اساس مجموعه‌ای از معیارهای از پیش‌تعیین‌شده، باید برای آن پروژهٔ خاص به کار رود. در مقابل، متد دینامیک انطباق، فرض میکند پروژه در یک زمینهٔ نوظهور واقع شده‌است. یک زمینهٔ نوظهور به این موضوع اشاره میکند که یک پروژه با فاکتورهای نوظهوری سر و کار خواهد داشت که بر شرایط مربوطه اثر می‌گذارند، اما قابل‌پیش‌بینی نیستند. همچنین به این معناست که زمینهٔ پروژه ثابت نیست و در طول اجرا تغییر میکند. در چنین موردی نقشه‌های مسیر تجویزی مناسب نیستند. مفهوم کاربردی متد دینامیک انطباق این است که مدیران پروژه اغلب ناچارند در طول اجرای یک پروژه، قسمت‌های ساخت‌یافته را تغییر دهند یا حتی قسمت‌های جدیدی ابداع کنند (Aydin و همکاران، 2005).[۲۳]
چرخهٔ عمر پشتیبانی از توسعهٔ نرم‌افزار[۲۲]
متدهای چابک بر جنبه‌های متفاوتی از چرخهٔ عمر توسعهٔ نرم‌افزار تمرکز دارند. بعضی از آنها بر روشها (برنامه‌نویسی extreme، برنامه‌نویسی فعال مدل‌سازی چابک) تمرکز دارند، در حالی که بعضی دیگر بر مدیریت پروژه‌های نرم‌افزاری تأکید دارند (مانند رویکرد Scrum ). هنوز، رویکردهایی وجود دارند که تمام چرخهٔ عمر توسعه را پوشش می‌دهند (متدهای توسعهٔ سیستم دینامیک (DSDM) و Rational Unified Process (RUP))، در حالی که بیشتر آنها از فاز تعیین نیازمندیها مناسب هستند (مثلاً ویژگی‌محور در توسعه یا FDD). بنابراین، یک تفاوت آشکار بین متدهای گوناگون توسعهٔ چابک نرم‌افزار در این مورد است. اگرچه DSDM و RUP نیازی به رویکردهای مکمل برای پشتیبانی از توسعهٔ نرم‌افزار ندارند، بقیهٔ آنها با درجات متفاوت این نیاز را دارند. DSDM می‌تواند توسط هر کسی به کار رود (علیرغم اینکه فقط اعضای DSDM می‌توانند محصولات یا خدمات DSDM را عرضه کنند). RUP یک محیط توسعه تجاری فروشی است (Abrahamsson، Salo، Rankainen & Warsta، 2002).[۲۲]
اندازه‌گیری میزان چابکی
اگرچه چابکی به عنوان ابزاری برای پایان دیده می‌شود، تعدادی رویکرد پیشنهاد شده‌اند که کیفیت چابکی را تعیین می‌کنند. اندازه‌گیری شاخص‌های چابکی (AIM) پروژه‌ها را برای کسب یک امتیاز کل، در مقابل تعدادی از فاکتورهای چابکی امتیازدهی می‌کنند. نام مشابه «شاخص اندازه‌گیری چابکی»، توسعه‌ها را در برابر ۵ بعد یک پروژهٔ نرم‌افزاری (مدت‌زمان، ریسک، تازگی، تلاش و تعامل) امتیازدهی میکند. تکنیک‌های دیگر مبتنی بر اهداف قابل‌اندازه‌گیری هستند.
مطالعهٔ دیگری با استفاده از ریاضیات فازی (fuzzy)، می‌گوید سرعت پروژه می‌تواند یکی از استانداردهای چابکی باشد. خودارزیابی‌هایی در چابکی وجود دارد که تعیین میکند آیا یک تیم از روش‌های چابک استفاده میکند یا خیر (آزمون Nokia، آزمون Karlskrona، ۴۲ آزمون نکته‌ای).[۲۴][۲۵]
اگرچه چنین رویکردهایی برای اندازه‌گیری چابکی پیشنهاد شده‌اند، کاربرد عملی چنین معیارهایی هنوز دیده می‌شود. از لحاظ تاریخی، در پروژه‌های چابکی که نتوانسته‌اند نتایج مطلوبی تولید کنند، کمبود داده وجود دارد. می‌توان مطالعاتی را یافت که پروژه‌ها را با پیاده‌سازی ناکارآمد یک (یا چند) متد چابک، ضعیف گزارش کرده‌اند، اما هیچ‌جا احساس نشد که به درستی اجرا شده‌اند و در تحویل تعهدات خود شکست خورده‌اند.[۲۶][۲۷][۲۸]
«این ممکن است یک دلیل بی‌میلی برای انتشار مقالات در مورد پروژه‌های ناموفق باشد، یا ممکن است نشان‌دهندهٔ آن باشد که وقتی متدهای چابک کار می‌کنند که پیاده‌سازی درست انجام شود.». اگرچه، داده‌هایی از ROI توسعهٔ چابک نرم‌افزار از CSIAC ROI Dashboard در دسترس است.[۲۹][۳۰]).[۳۱]
آزمودگی و پذیرش
یکی از مطالعات اخیر که دستاوردهای کیفیت، بهره‌وری و رضایت کسب‌وکار با استفاده از متدهای چابک را گزارش میدهد، یک بررسی بود که توسط Shine Technologies از نوامبر ۲۰۰۲ تا ژانویهٔ ۲۰۰۳ انجام شد.[۳۲]
یک بررسی مشابه در سال ۲۰۰۶ توسط Scott Ambler (رهبر تمرین توسعهٔ چابک با گروه متدهای عقلانی IBM) انجام شد که همین فواید را بیان کرد. در بررسی انجام‌شده توسط VersionOne (یک تهیه‌کنندهٔ نرم‌افزار برای برنامه‌ریزی و پیگیری پروژه‌های توسعهٔ چابک نرم‌افزار) در سال ۲۰۰۸، ۵۵ درصد پاسخ‌دهندگان گفتند متدهای چابک در ۹۰ تا ۱۰۰ درصد موارد موفق بوده‌اند.[۳۳]
برخی دیگر ادعا می‌کنند متدهای توسعهٔ چابک بسیار جوان‌تر از آن هستند که نیاز به اثبات گسترده و علمی موفقیت‌شان داشته باشند.[۳۴][۳۵]
سازگاری
بخش وسیعی از توسعهٔ چابک نرم‌افزار به صورت یک زمینهٔ تحقیقاتی پرکار باقی مانده‌است. به‌طور گسترده توسعهٔ چابک برای انواع مشخصی از محیط‌ها، شامل تیمهای کوچک متخصصان، مناسب‌تر به نظر می‌رسد. در سال‌های اخیر برخورد مثبت با متدهای چابک در دامنهٔ Embedded در اروپا مشاهده شده‌است. بعضی مواردی که ممکن است بر موفقیت یک پروژهٔ چابک، تأثیر منفی بگذارد، عبارتند از:
تلاش‌های توسعه در مقیاس وسیع (>۲۰ توسعه‌گر)، اگرچه استراتژی‌های مقیاس‌گذاری و مدارک بعضی پروژه‌های بزرگ توضیح داده شده‌است؛
تلاش‌های توسعهٔ توزیع‌شده (تیمهای غیرهم‌مکان). استراتژی‌ها در «پل‌بندی و فاصله» و «استفاده از فرایند چابک نرم‌افزار با توسعهٔ دور [دورکاری]» توضیح داده شده‌است؛
تحمیل یک فرایند چابک به یک تیم توسعه؛ سیستم‌های مأموریت بحرانی که در آنها شکست، به هر قیمتی یک گزینه نیست (مثل نرم‌افزار کنترل ترافیک هوایی).
اخیراً موفقیت‌ها، چالش‌ها و محدودیت‌هایی که در انطباق با متدهای چابک در یک سازمان بزرگ مشاهده می‌شوند، مستندسازی شده‌اند. در شرایط برون‌سپاری توسعهٔ چابک، Michael Hckett، معاون رئیس شرکت LogiGear گفته‌است «یک تیم دورکار... باید این موارد را داشته باشد: تخصص، تجربه، مهارت‌های ارتباطی خوب، تفاهم بین فرهنگ‌ها، اعتماد و تفاهم بین اعضا، گروه‌ها و با یکدیگر.». متدهای چابک به‌طور گسترده برای توسعهٔ محصولات نرم‌افزاری به کار رفته‌اند، بعضی از آنها نیز از خصوصیات مشخصی از نرم‌افزار، مانند فناوری‌های موضوع استفاده می‌کنند. اگرچه این فناوری‌ها می‌توانند برای محصولات غیر نرم‌افزاری (مانند کامپیوترها، وسایل نقلیهٔ موتوری، وسایل پزشکی، خوراک و پوشاک) نیز به کار گرفته شوند. همچنین تحلیل ریسک می‌تواند برای انتخاب بین متدهای انطباقی (چابک یا ارزش‌محور) و پیشگویانه (برنامه‌محور) استفاده شود. Barry Boehm و Richard Turner می‌گویند که هر سوی این زنجیره پایهٔ اصلی (home ground) خاص خود را دارد، که به شرح زیر است:
| پایهٔ اصلی چابک | پایهٔ اصلی ارزش‌محور | متدهای رسمی |
|---|---|---|
| حساسیت پایین | حساسیت بالا | حساسیت شدید |
| توسعه‌دهندگان ارشد | توسعه‌دهندگان تازه‌کار | توسعه‌دهندگان ارشد |
| نیازمندیها اغلب تغییر می‌کنند. | نیازمندیها اغلب تغییر نمی‌کنند. | نیازمندی‌های محدود، خصوصیات محدود |
| تعداد کمی از توسعه‌دهندگان | تعداد زیادی از توسعه‌دهندگان | نیازمندیها می‌توانند مدل‌سازی شوند |
| فرهنگ پاسخ به تغییر | فرهنگ نیاز به نظم | کیفیت بسیار زیاد |
مقدمه
مدیریت‌کردن پروژه‌ها یکی از مهم‌ترین اقداماتی است که باید توسط سازمان‌ها و شرکت‌ها انجام شود. امروزه روشها و متدولوژی‌های مختلفی برای مدیریت‌کردن انواع پروژه موجود است. یکی از محبوب‌ترین این متدها، متد اجایل یا agile است. اما agile چیست؟
agile یک روش مدیریت پروژه بوده که بر همکاری مداوم و تکرار استوار است. مدیریت پروژه agile براین‌اساس کار خواهد کرد که یک پروژه را می‌توان در طول مد زمان استفاده از آن با تغییرات سریع، بهبود بخشید.
Agile چیست؟ اولین سؤالی که بعد از برخورد با این مفهوم با آن مواجه خواهید شد این است که agile یا اجایل چیست. توسعه نرم‌افزار Agile در واقع به گروهی از متدولوژی‌های توسعه نرم‌افزار بر اساس توسعه به روش تکرار اشاره داد. در این روش نیازمندیها و راه‌حل‌ها از طریق همکاری بین تیمهای متقابل خودسازماندهی شده، تکامل پیدا میکند. روش‌های Agile یا فرایندهای Agile به‌طورکلی یک فرایند مدیریت پروژه منظم را ترویج خواهند کرد.
شاید بپرسید که فرایند مدیریت Agile چیست و چگونه اجرا می‌شود. این فرایند که بررسی برنامه و انطباق مکرر آن را مدنظر قرار میدهد، به‌عنوان یک فلسفه رهبری نیز شناخته می‌شود. در این فلسفه اصل بر روی تشویق به کار تیمی، خودسازماندهی و مسئولیت‌پذیری خواهد بود؛ ازاین‌رو می‌توان عنوان کرد که فرایند مدیریت Agile مجموعه از بهترین شیوه‌های مهندسی باهدف امکان تحویل سریع نرم‌افزار باکیفیت بالا است که با یک رویکرد تجاری که توسعه را با نیازهای مشتری و اهداف شرکت هماهنگ میکند، شناخته می‌شود.
پس در پاسخ به توسعه Agile چیست می‌توان گفت که این توسعه به هر فرایند توسعه‌ای اشاره دارد که با مفاهیم مانیفست Agile یا اجایل همسو باشد. این مانیفست توسط گروهی متشکل از ۱۴ شخصیت برجسته در صنعت نرم‌افزار توسعه داده شده است.
اسکرام چیست؟
بعد از پاسخ به سؤال Agile چیست، شاید زمان آن رسیده تا در خصوص SCRUM نیز کمی صحبت کنیم. SCRUM را می‌توان زیرمجموعه‌ای از Agile دانست. اسکرام یک چارچوب فرایندی سبک برای توسعه Agile بوده و بسیار پرکاربرد است. یک فرایند SCRUM باتکیه‌بر مفاهیم و شیوه‌های به خصوصی از سایر فرایندهای Agile متمایز می‌شود؛ ازاین‌رو یک اسکرام به سه دسته نقش‌ها، مصنوعات و جعبه‌های زمانی تقسیم خواهد شد.
اما وجه تمایز اسکرام و Agile چیست. باید بدانید که اسکرام بیشتر برای مدیریت نرم‌افزارهای پیچیده و توسعه محصول با استفاده از شیوه‌های تکراری و افزایشی استفاده می‌شود. اسکرام می‌تواند به طور قابل‌توجهی بهره‌وری را افزایش داده و زمان رسیدن به مزایا را کاهش دهد. فرایندهای اسکرام به سازمان‌ها این امکان را میدهد که به‌آرامی با الزامات در حال تغییر سازگار شوند. همچنین می‌توانند محصولی تولید کنند که اهداف تجاری در حال تحول را برآورده کند.
الزامات اسکرام چیست؟
در ادامه مقاله Agile چیست، به بررسی اسکرام پرداختیم. اما آیا می‌دانید که الزامات اسکرام چیست؟ اسکرام نه‌تنها فرم موردنیاز را تعریف میکند، می‌تواند عنوان کند که آنها در بکلاگ (Backlog) محصول جمع‌آوری می‌شوند؛ ازاین‌رو به‌طورکلی به آنها عنوان اقلام بکلاگ محصول یا به‌اختصار PBIs می‌گویند. باتوجه‌به ماهیت جعبه زمانی یک اسپرینت، می‌توانیم چنین برداشت کنیم که اجرای هر مجموعه به زمان بسیار کمتری از مدت‌زمان اسپرینت نیاز خواهد داشت.
اکثر پروژه‌های اسکرام از روش XP (برنامه‌نویسی شدید) استفاده می‌کنند. این روش یک درخواست ویژگی را به‌عنوان داستان کاربر توصیف خواهد کرد. از مهم‌ترین الزامات استاندارد معقول که در بکلاگ محصول یافت می‌شود می‌توان به موارد زیر اشاره کرد:
• داستان کاربر
• داستان
• کاستی
نقش‌های اسکرام چیست؟
اجازه دهید تا در این قسمت از مقاله اجایل چیست در خصوص نقش‌های اسکرام بیشتر صحبت کنیم. در اسکرام به نقش عمده وجود دارد: اسکرام مستر، مالک محصول و تیم. افرادی که این نقش‌ها را ایفا می‌کنند، به طور روزانه با یکدیگر همکاری خواهند کرد. بدین صورت در جریان روند اطلاعات و حل سریع مسائل قرار گرفته و دراین‌خصوص اطمینان کسب می‌کنند. اما اجازه دهید تا این نقش‌ها را به شما بیشتر معرفی کنیم:
اسکرام مستر:
اسکرام مستر به‌عنوان نگهدارنده اصلی فرایند شناخته می‌شود؛ ازاین‌رو به اسکرام مستر مسئول اجرایی فرایند گفته می‌شود. او وظیفه دارد تا تمامی موانعی که بر روی بهره‌وری تأثیر می‌گذارد را از میان بردارد. از سوی دیگر به مالک محصول آموزش میدهد که چگونه بازدهی سرمایه را به حداکثر برساند و از طریق اسکرام به اهداف خود برسد. اسکرام مستر همچنین می‌تواند با توانمندسازی، تیم توسعه را روبه‌جلو حرکت دهد.
مالک محصول:
مالک محصول، حافظ الزامات است. در عمل مالک محصول، رابط بین کسب‌وکار، مشتریان و نیازهای مرتبط با محصول آنها و تیم است. مالک محصول تیم توسعه را از درخواست‌های مربوط به ویژگی‌ها و رفع اشکال مطلع میکند. او همچنین تنها نقطه تماس برای همه سؤالات در مورد الزامات محصول است. مالک محصول از نزدیک با تیم همکاری میکند تا الزامات فنی و کاربر را تعریف کند.
تیم:
تیم یک گروه خودسازمانده و متقابل از افراد است. این بخش کار عملی توسعه و آزمایش محصول را به عهده دارد. از آن جایی که تیم، مسئول تولید محصول است، باید اختیار تصمیم‌گیری در مورد نحوه انجام کار را داشته باشد. ازاین‌رو خود تیم تصمیم می‌گیرد که اعضای تیم چه کاری انجام دهند، چگونه تقسیم وظایف کنند و … . به‌صورت معمول، تعداد اعضای تیم بین ۵ تا ۹ نفر است. تعداد بیشتر ارتباط را دشوار کرده و باعث کاهش بهره‌وری خواهد شد.
مزایای agile چیست؟
Agile چگونه در پول شما صرفه‌جویی میکند؟
بعد از اینکه به‌صورت کامل در خصوص اینکه agile چیست و تفاوت بین اسکرام و اجایل چیست صحبت کردیم، زمان آن رسیده است تا در خصوص مزایا و ویژگی‌های آن نیز صحبت کنیم. یکی از مهم‌ترین مزایای استفاده از اجایل این است که می‌تواند به سازمان‌ها و شرکت‌ها در ذخیره هرچه بیشتر پول کمک کند. Agile دارای انعطاف‌پذیری بالایی است؛ ازاین‌رو اجازه نمی‌دهد تا بعد از برخورد با مشکلات زیاد، سودآوری کسب‌وکارتان را متوقف کنید.
اما دیگر مزایای Agile چیست که باعث صرفه‌جویی در هزینه‌ها می‌شود؟ به کمک اجایل می‌توانید دقیقاً به همان محصولی دست پیدا کنید که فکرش را می‌کنید. تولید نرم‌افزار سفارشی گران بوده و ممکن است محصول نهایی آن چه که شما نیاز دارید، نباشد. اما بعد از اینکه دانستید Agile چیست و چه مزایای دارد، می‌توانید این ریسک را کاهش دهید؛ ازاین‌رو با Agile تضمین می‌کنید که سرمایه‌گذاری شما در نرم‌افزار، نتیجه خواهد داد.
استفاده از Agile باعث کاهش فرسودگی و گردش مالی خواهد شد. از سوی دیگر، می‌تواند هدررفت را به‌شدت کاهش دهد. اگر بپرسید که دیگر ویژگی‌های اجایل چیست، باید به این نکته اشاره کرد که به کمک آن دیگر زمان زیادی را صرف ویژگی‌های غیرضروری نمی‌کنید؛ به همین دلیل بودجه مشتری را هدر نخواهی داد. از سوی دیگر، رویکرد کار تیمی به توسعه‌دهندگان کمک میکند تا محصول باکیفیت بالاتری را سریع‌تر آماده کنند. دلیل این امر نیز آن است که همه می‌دانند چه کاری را باید انجام داد.
برخی از معیارهای Agile که می‌توانم برای گزارش‌دهی استفاده کنم چیست؟
اینکه معیارهای اندازه‌گیری برای گزارش‌دهی در Agile چیست، می‌تواند سؤال مهمی باشد. قبل از اینکه در خصوص معیارها اندازه‌گیری Agile صحبت کنیم، باید بدانید که دو فیلتر اصلی قبل از اندازه‌گیری وجود دارد که باید به آن توجه کرد. اول این است که آیا اندازه‌گیری آماده‌سازی ارزش را تسریع میکند و آیا این اندازه‌گیری اعتماد را افزایش میدهد. آن چیزی که در معیارهای اندازه‌گیری اجایل مهم است، تحویل ارزش به‌جای تحویل خروجی است.
از سوی دیگر، کاری که در اجایل باید انجام داد، ثبات انگیزه در سرعت است، نه سرعتی که در حال تغییر باشد؛ به همین دلیل باید انگیزه‌هایی را برای افزایش سرعت قرار دهیم. حال باز هم به سؤال ابتدایی بازمی‌گردیم. معیارهای اندازه‌گیری برای گزارش‌دهی در Agile چیست؟ این معیارها به دسته‌بندی‌های زیر تقسیم می‌شوند.
نمونه معیارهای عملیاتی:
-- زمان بین شروع و اتمام فرایند تولید
-- زمان چرخه
-- نمودارهای سوختگی
-- نمونه معیارهای خروجی
توان عملیاتی:
-- مدل ارزیابی Agile
-- کیفیت فنی، اندازه‌گیری نقص، پوشش کد
-- تعداد ویژگی‌ها و …
-- نمونه معیارهای نتیجه / ارزش
روحیه تیم:
-- رضایت مشتری / NPS
-- ارزش تجاری
تیمهای توزیع شده agile چیست؟
چگونه با تیمهای توزیع شده در Agile برخورد کنم؟
یکی دیگر از سؤالات مهم و کاربردی این است که نحوه برخورد با تیمهای توزیع شده در Agile چیست؟ این سؤال دو بعد مختلف دارد. اول اینکه تیمهای توزیع شده دارای اعضای تیمی از راه دور است یا تمام تیمهای محلی دست‌نخورده‌اند، اما در مکان‌های جغرافیایی مختلفی قرار دارند. پیشنهاد ما این است که از گزینه اول به هر قیمتی که شده است، استفاده نکنید!
تیمهای دست‌نخورده در مکان‌های جغرافیایی مختلف
یکی از بهترین نوع تیمهای توزیع شده که مورد استقبال سازمان‌ها قرار دارند، تیمهای دست‌نخورده در مکان‌های جغرافیایی مختلف است. این تیم‌ها بهترین نتایج را به همراه دارند. افرادی که در این تیم‌ها کار می‌کنند، اطلاعات کافی را در اختیار دارند؛ ازاین‌رو خود تیم‌ها مشکلات را حل خواهند کرد و سازمان‌ها باید به آنها اعتماد کرده، بودجه در اختیارشان قرار دهد و حمایتشان کند.
تیم‌هایی با اعضای از راه دور
در ادامه مقاله Agile چیست و راه‌های برخورد با تیمهای توزیع شده، به تیم‌هایی با اعضا از راه دور رسیدیم. این مدل از تیم‌ها به دلیل ایجاد اختلال‌های ارتباطی زیاد، می‌توانند مشکلات فراوانی را به وجود بیاورند. یکی از این مشکلات این است که تیم در خصوص محصولات، آگاهی کافی را پیدا نخواهد کرد. اما بهترین راه‌حل برای حل این مشکل در تیمهای توزیع Agile چیست؟ باید سعی کنیم تا تیم‌هایی با افراد محلی ایجاد کرد.
Agile چگونه با DEVOPS ارتباط دارد؟
می‌دانید که نحوه برقراری ارتباط بین DEVOPS و Agile چیست؟ درحالی‌که هم Agile و هم DEVOPS به‌عنوان جنبش‌های روش‌شناختی مستقل شناخته می‌شوند، اما در تعدادی ویژگی‌های دیگر مانند بهبود کارایی و سرعت تیم‌ها مشترک هستند. به همان نسبتی که سازمان‌ها چابک‌تر می‌شوند، مجموعه مهارت‌های مدیریت پروژه خود را هم اصلاح می‌کنند. از سوی دیگر این سازمان‌ها به تیمهای فنی وابسته بوده که بتوانند سرعت خود را حفظ کرده و انعطاف‌پذیری خاصی داشته باشند.
اما رویکرد DEVOPS در Agile چیست؟ این رویکرد به گروه‌های توسعه‌دهنده کمک میکند تا ابزارهای جدید، اتوماسیون و استراتژی‌های فرهنگی مختلف برای تغییر را به کار بگیرند. همین رویکرد می‌تواند باعث شود تا تیمهای محصول دست در دست توسعه‌دهندگان و آزمایش‌کنندگان قرار دهند. بدین صورت اطمینان حاصل می‌شود که همه از آگاهی زمینه‌ای مشترکی برخوردار هستند. اگر بپرسید که مزیت این رویکرد در Agile چیست، باید بگویم که در نهایت باعث افزایش کیفیت محصول در زمان کمتر خواهد شد.
بهترین رویکرد پذیرش agile چیست؟
بهترین رویکرد پذیرش اجایل به فاکتورهای مهم سازمانی بازمی‌گردد
بهترین رویکرد جامع برای پذیرش Agile چیست؟
حال که به‌صورت کامل دانستید که Agile چیست و چه کاربردهایی دارد، شاید بپرسید که بهترین رویکرد جامع برای پذیرش Agile چیست؟ برای پاسخ‌دادن به این سؤال باید به فاکتورهای بسیار مختلفی توجه کرد. از جمله این فاکتورها می‌توان به نیازهای تجاری، اندازه شرکت، ساختار سازمانی و … اشاره کرد. تا حد بسیار زیادی، فرمول موفقیت مستلزم گنجاندن تمام جنبه‌های کسب‌وکار خواهد بود. تفکر سیستمی، یعنی درک این که همه حوزه‌های شرکت به ارائه ارزش دست می‌یابند و با هم، کار می‌کنند.
از سوی دیگر، کسب‌وکارها به‌احتمال زیاد مجبور به تغییر ساختار و سبک‌های مدیریتی برای دستیابی به همسویی سازمان خواهند شد. بهترین نتایج زمانی اتفاق می‌افتد که تیم رهبری، با دیدی باز به فرصت‌ها در هنگام همکاری بپردازد. اگر باز بپرسید که بهترین رویکرد جامع برای پذیرش Agile چیست، پاسخ می‌دهیم که: بهترین رویکرد هنگام درنظرگرفتن پذیرش اجایل، به سازمان شما و فاکتورهای مهم آن بستگی خواهد داشت.
نتیجه‌گیری
ما در این مقاله به‌صورت کامل در خصوص اینکه Agile چیست صحبت کردیم. مشاهده کردید که اجایل به متدولوژی‌های توسعه نرم‌افزار اشاره دارد که حول ایده توسعه تکراری متمرکز است. به کمک اجایل می‌توان ارزش را سریع‌تر، باکیفیت بیشتر و پیش‌بینی‌پذیری بالاتری ارائه کرد. همچنین اشاره کردیم که مزایای اجایل چیست و دیدیم که استفاده از این روش هم برای مشتری، هم برای فروشندگان و هم‌تیم‌های توسعه مفید خواهد بود. این مزایا عبارت خواهند بود از سادگی، حذف اضافات، ارتقا تضمین و … .
اسکرام یک چارچوب است و نه یک متدلوژی.
در ابتدا به بررسی معنا و تفاوت چارچوب و متدلوژی می‌پردازیم سپس اسکرام را تعریف می‌کنیم.
آنچه درمورد اسکرام می‌خوانید
تفاوت چارچوب و متدلوژی چیست؟ چرا اسکرام یک چارچوب است؟
اسکرام چیست؟
ویژگی‌های اسکرام
شفاف سازی چارچوب اسکرام
باور غلط
واقعیت
چرا از اسکرام استفاده کنیم؟
1- سازگاری با شرایط (Adaptability)
2- کسب رضایت ذینفعان (Stakeholder Satisfaction)
3- تحویل با ارزش‌ترین بخش کار در اولین اولویت (Early Delivery of high value product)
4- بازخورد و بهبود مستمر (Continuous Development)
آشنایی با تیم اسکرام
مالک محصول یا Product Owner
وظایف مالک محصول در تیم اسکرام
تیم توسعه یا Development Team
نقش و وظایف تیم توسعه
اندازه تیم توسعه
اسکرام مستر یا Scrum Master در تیم اسکرام
نقش و وظایف اسکرام مستر در تیم اسکرام
خدمات اسکرام مستر برای سازمان
جلسات اسکرام
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
جمع‌بندی
تفاوت چارچوب و متدلوژی چیست؟ چرا اسکرام یک چارچوب است؟
متدلوژی مجموعه‌ای از روشها و مراحلی است که در محیطی مشخص پیاده سازی می‌شود.
چارچوب یک زیرساخت اساسی است که زیربنای یک سیستم را می‌سازد.
اسکرام چیست؟
اسکرام یک چارچوب برای توسعه، تحویل و نگهداری محصولات پیچیده است، در نتیجه اسکرام به جای وضع قوانین سخت‌گیرانه که شما را وادار به انجام آن کند، در واقع راهنمایی برای پیشبرد کارها پیش روی ما می‌گذارد.
اسکرام بجای اینکه دستوالعمل‌ها و فرآیندهای از پیش تعیین شده‌ای را پیش روی شما بگذارد، خودش را با محیط کسب و کار شما سازگار (Adapt) میکند تا بتوانید مطابق با نیازها و اهدافی که دارید از آن استفاده کنید.
طبق نسخه 2017 راهنمای اسکرام این چارچوب از تیم‌هایی به همراه نقش‌ها، رویدادها، مصنوعات و قوانین مرتبط با آنها تشکیل شده است.
ویژگی‌های اسکرام
سبک وزن است.
فهم آن ساده است.
تسلط بر آن و استفاده از آن دشوار است.
شفاف سازی چارچوب اسکرام
باور غلط
اسکرام تمامی مشکلاتی که در توسعه نرم افزارها وجود دارد را حل میکند.
واقعیت
اسکرام مشکلاتی که در پروژه‌های چابک وجود دارد را به ما نشان (برایمان مشخص میکند) تا برای حل آن اقدام کنیم.
اسکرام مشکلات موجود در کار ما را حل نمی‌کند، بلکه آنها به شکل واضحی به ما نشان میدهد تا پس از آن تیم خودسازمانده اسکرام (Self- organize team) برای حل آن اقدام کنند.
اسکرام یک مفهوم و چارچوب وسیع است که در همه فرآیندهای ساخت و یا توسعه محصولات پیچیده و تمامی کسب و کارهایی که با رویکرد چابک مدیریت می‌شوند کاربرد دارد.
چرا از اسکرام استفاده کنیم؟
1- سازگاری با شرایط (Adaptability)
اسکرام تغییرات در پروژه‌ها را در آغوش می‌گیرد. در واقع فرآیندهای اسکرام برای رویارویی با تغییرات طراحی شده‌اند تا بتوان با استفاده از این قابلیت محصول بهتری را به مشتری ارائه داد.
2- کسب رضایت ذینفعان (Stakeholder Satisfaction)
یکی از مهم‌ترین اهداف در هر نوع پروژه‌ای جلب رضایت ذینفعان آن پروژه است که اسکرام توانسته با استفاده از رویکرد مشارکت گونه‌ای که در فرآیندهایش دارد به این هدف مهم دست پیدا کند.
3- تحویل با ارزش‌ترین بخش کار در اولین اولویت (Early Delivery of high value product)
در چارچوب اسکرام میزان ارزش حاصل شده تعیین کننده خواهد بود. اسکرام به گونه‌ای طراحی شده که حداقل در هر بازه‌ای از ماه (اسپرینت) بخشی از محصول به مشتری تحویل داده می‌شود، در این بین نحوه‌ی چیدمان کارها به گونه‌ای است که کار با بالاترین ارزش در اولین اولویت قرار می‌گیرد تا تحویل مشتری داده شود.
4- بازخورد و بهبود مستمر (Continuous Development)
حتما تا به حال دربار‌ه‌ی مفهوم بهبود مستمر و یا چرخه‌ی دمینگ شنیده‌اید. در بهبود مستمر شما همواره به بهتر شدن روند انجام کارها می‌اندیشید به این شکل که پس از برنامه ریزی و انجام کار، نحوه‌ی عملکرد و بهره‌وری کارتان را بررسی می‌کنید و در صورتی که نیاز به اصلاح بود آن را اصلاح می‌کنید.
این چرخه و یا بهتر است بگوییم طرز تفکر در هر کتاب و استانداردی یک ردپایی از خودش گذاشته است و چارچوب اسکرام هم از این قاعده مستثنی نیست.
در اسکرام با دریافت بازخوردهای مستمر و تحویل بخشی از محصول در هر بازه‌ی زمانی که با آن اسپرینت (Sprint) می‌گوییم و دریافت بازخورد از مشتری نحوه‌ی انجام کارها را بهبود می‌بخشیم.
برای استفاده از اسکرام در پروژه‌ها دلایل بیشتری وجود دارد که در این بین به بیان برخی از آنها بسنده کردیم.
تیم اسکرام به طور کلی شامل 3 نقش است:
مالک محصول
تیم توسعه
اسکرام مستر
تیمهای اسکرام خود سازمانده و فرا وظیفه‌ای هستند. تیم‌ها خودشان بهترین روش انجام کار را انتخاب می‌کنند. تیمهای فراوظیفه‌ای و خودسازمانده به جای اینکه توسط شخص دیگری از خارج تیم مدیریت شوند تمام شایستگی‌های لازم برای انجام کار را بدون وابستگی به خارج تیم دارند.
الگوی تیم در اسکرام به گونه‌ای طراحی شده تا انعطاف‌پذیری، خلاقیت و تولید بهبود پیدا کند. تیم اسکرام ثابت کرده است که به طور فزاینده‌ای می‌تواند در همه مواردی که قبلاً به آنها اشاره شد و هر کار پیچیده دیگری مؤثر عمل کند.
تیمهای اسکرام محصولات را به صورت تکراری و افزایشی عرضه می‌کنند که امکان دریافت بازخورد را به حداکثر می‌رساند.
ارائه‌های افزایشی این اطمینان را می‌دهند که همیشه یک نسخه قابل استفاده از محصول در دسترس است.
مالک محصول یا Product Owner
مالک محصول در مرحله اول الزامات و خواسته‌های مشتری را از او می‌گیرد و آنها را به تیم اسکرام توضیح میدهد.
سپس تمامی کارهایی که برای ساخت این سایت لازم است را در یک لیست به نام لیست محصول یا Product Backlog می‌نویسد.
در مرحله‌ی بعد تمامی کارهای لیست شده در Product Backlog (اصطلاحا بکلاگ محصول) را به گونه‌ای که ارزش کار به بیشترین میزان خود برسد، دسته بندی و اولویت بندی میکند و برای انجام آنها، در بازه‌های زمانی مشخص شده و جلسات از پیش تعیین شده با تیم اسکرام برنامه‌ریزی میکند.
به عنوان مثال او راه اندازی این سایت را به 5 بخش زیر تقسیم میکند:
تحقیقات بازار
تهیه دامنه و‌هاست
تهیه و پیاده‌سازی سیستم فروشگاه ساز مناسب
نهایی کردن سایت و بهره برداری
و برای انجام هر کدام یا دسته‌ای از این بخش‌ها یک ماه زمان در نظر می‌گیرد که در اسکرام به هر یک از این بازه‌های زمانی اسپرینت (Sprint) می‌گویند.
حالا در اسپرینت اول مالک محصول تمامی کارهای موجود در بکلاگ را که به این اسپرینت مربوط می‌شود در یک لیست جدا قرار میدهد که به آن Sprint Backlog می‌گویند.
حال که با این مثال متوجه مفهوم مالک محصول شده‌اید، به طور دقیق به شرح مسئولیت‌ها و وظایف کلی او می‌پردازیم.
وظایف مالک محصول در تیم اسکرام
مالک محصول، مسئول به حداکثر رساندن ارزش محصولی است که از کار تیم توسعه حاصل می‌شود.
اینکه این کار چگونه انجام می‌پذیرد ممکن است به طور وسیعی در بین سازمان‌ها، تیمهای اسکرام و افراد متفاوت باشد.
مالک محصول تنها فرد مسئول برای مدیریت بکلاگ محصول است. مدیریت بکلاگ محصول شامل موارد زیر می‌شود:
شرح و توصیف اقلام بکلاگ محصول به صورت شفاف
رتبه‌بندی اقلام موجود در بکلاگ محصول به منظور دستیابی بهتر به اهداف و مأموریت‌ها
بهینه‌سازی ارزش کارهایی که تیم توسعه انجام میدهد.
حصول اطمینان از اینکه بکلاگ محصول برای همه شفاف، واضح و قابل مشاهده بوده و کاری که تیم اسکرام در قدم‌های بعدی انجام خواهد داد را به خوبی نمایش میدهد.
حصول اطمینان از اینکه تیم توسعه به درکی کافی و لازم از اقلام درون بکلاگ محصول رسیده است.
موارد بالا را ممکن است مالک محصول خودش انجام دهد یا تیم توسعه اقدام به انجام آنها کند. در هر صورت مالک محصول همچنان مسئول و پاسخگو باقی می‌ماند.
مالک محصول تنها یک نفر است و نه یک کمیته. مالک محصول ممکن است بیان‌کننده‌ی خواسته‌های یک کمیته در قالب بکلاگ محصول باشد، ولی کسانی که مایل به تغییر اولویتِ اقلام بکلاگ محصول هستند باید مالک محصول را مخاطب خود قرار دهند.
برای موفقیت مالک محصول، کل سازمان باید به تصمیمات او احترام بگذارد. تصمیمات مالک محصول در قالبِ محتوا و رتبه بندی بکلاگ محصول عینیت پیدا میکند. هیچکس نمی‌تواند تیم توسعه را مجبور به کار بر روی یک سری نیازمندی دیگر کند.
تیم توسعه یا Development Team
تیم توسعه شامل افرادی است که برای انجام این پروژه تخصص‌های لازم را دارند. در این تیم و بطور کلی در اسکرام شخصی به عنوان رئیس و یا مدیر تعریف نشده است بلکه انتظار می‌رود کارها به شکل مشارکت گونه و خود سازمان یافته پیش رود.
حالا در اسپرینت اول تیم اسکرام (که شامل تیم توسعه، اسکرام مستر، مالک محصول است) برای انجام کارهای موجود در Backlog Sprint برنامه‌ریزی می‌کنند.
همینطور تیم اسکرام باید برای انجام هر کدام از کارهای موجود در Sprint Backlog تخمین بزند. طبق منطق اسکرام تیم توسعه به عنوان انجام‌دهنگان کارها بهترین گزینه برای تخمین زدن مدت زمان کارها می‌باشند.
خب حالا که با تیم توسعه نیز به طور تقریبی آشنا شده‌اید در ادامه وظایف و نقش تیم توسعه را نیز به طور رسمی و دقیق‌تر شرح می‌دهیم.
نقش و وظایف تیم توسعه
تیم توسعه شامل متخصصانی است که کار تحویل فرآورده (محصول) بالقوه قابل ارائه در انتهای هر اسپرینت را انجام می‌دهند.
برای جلسه بازبینی اسپرینت وجود یک فرآورده تکمیل شده ضروری است و تنها اعضای تیم توسعه هستند که فرآورده‌ها را تولید می‌کنند.
تیمهای توسعه توسط سازمان به شکلی ساماندهی و توانمند می‌شوند که کارهایشان را خودشان سازماندهی و مدیریت کنند. هم‌افزایی حاصله باعث بهبود بهره وری و کارایی همه جانبه تیم توسعه می‌شود. تیمهای توسعه دارای مشخصات زیر هستند:
خود سازمانده هستند. هیچکس (حتی اسکرام مستر) به تیم توسعه نمی‌گوید که چگونه بکلاگ محصول را به فرآورده‌ای بالقوه قابل ارائه تبدیل کند.
تیمهای توسعه، فراوظیفه‌ای هستند، در قالب یک تیم که تمام مهارت‌های موردنیاز برای ساخت یک فرآورده محصول را دارا است.
اسکرام سِمَت یا عنوانی را برای اعضای تیم توسعه، صرف نظر از نوع کاری که هر شخص انجام میدهد، به رسمیت نمیشناسد.
صرف نظر از حوزه‌هایی که باید مورد توجه قرار گیرند مانند آزمون، معماری، عملیات یا تحلیل کسب‌وکار، اسکرام تشکیل تیمهای فرعی در تیم توسعه را به رسمیت نمیشناسد.
بعضی از اعضای تیم توسعه ممکن است دارای مهارت‌ها و یا حوزه‌های تمرکز ویژه‌ای باشند، اما به‌طور کل مسئولیت پاسخگویی به تیم توسعه تعلق دارد.
اندازه تیم توسعه
اندازه مطلوب تیم توسعه آنقدر کوچک است که چالاک باقی بماند و آنقدر بزرگ است تا بتواند کار قابل توجهی را در طول اسپرینت به سرانجام برساند.
کمتر از 3 نفر برای تیم توسعه، باعث کاهش سطح تعاملات شده و منجر به دستاوردهای با سودمندی کمتر می‌شود. تیمهای توسعه کوچکتر ممکن است در طول اسپرینت با محدودیت و کمبود مهارت مواجه شوند به طوریکه باعث شود نتوانند یک فرآوردۀ بالقوه قابل عرضه در انتهای اسپرینت ارائه دهند.
داشتن بیش از 9 نفر در تیم توسعه نیازمند هماهنگی‌های خیلی زیاد است. تیمهای توسعه بزرگ پیچیدگی خیلی زیادی را برای مفید بودن یک فرآیند تجربی به وجود می‌آورند. نقش‌های مالک محصول و اسکرام مستر تا زمانی که تکلیفی در بکلاگ اسپرینت بر عهده نداشته باشند در این شمارش محاسبه نمی‌شوند.
اسکرام مستر یا Scrum Master در تیم اسکرام
به زبان ساده، اسکرام مستر یک تسهیل‌گر است که سعی میکند موانعی که بر سر راه تیم اسکرام قرار می‌گیرد را بردارد. اسکرام مستر تیم را در راستای رسیدن به اهداف اسپرینت حمایت میکند. او کسی است که مطمئن می‌شود تیم اسکرام جلسات برنامه ریزی و بررسی کار را به طور منظم برگزار میکند و به طور کلی اسکرام مستر باید اطمینان حاصل کند که همه چیز رو به راه است.
نقش و وظایف اسکرام مستر در تیم اسکرام
مسئولیت ترویج و حمایت از اسکرام به گونه‌ای که در راهنمای اسکرام تعریف شده است را بر عهده دارد. اسکرام مستر این کار را از طریق کمک به دیگران برای درک مبانی نظری، روشها، قوانین و ارزش‌های اسکرام انجام میدهد.
اسکرام مستر یک رهبر خدمتگزار برای تیم اسکرام است. اسکرام مستر به افراد خارج از تیم کمک میکند تا درک کنند که کدامیک از رفتارها و تعاملاتشان با تیم اسکرام، مفید بوده و کدامیک نبوده است.
اسکرام مستر به منظور بیشینه ساختن ارزش آفرینی تیم اسکرام، به همه کمک میکند این رفتارها و تعاملات را تغییر دهند.
خدمات اسکرام مستر برای مالک محصول
اسکرام مستر از طرق مختلفی به مالک محصول خدمت‌رسانی میکند، از جمله:
حصول اطمینان از اینکه همه افراد تیم اسکرام به خوبی اهداف و دامنه محصول را درک کرده باشند
یافتن شگردهایی جهت مدیریت مؤثر بکلاگ محصول
کمک به تیم اسکرام برای درک نیاز به داشتن اقلام بکلاگ محصول شفاف، کوتاه و موجز
درک نحوه برنامه ریزی محصول در یک محیط تجربی
حصول اطمینان از اینکه مالک محصول می‌داند به منظور بیشینه سازی ارزش چگونه بکلاگ محصول را مرتب کند
درک و تمرین چابکی
تسهیل رویدادهای اسکرام به محض درخواست یا نیاز
خدمات اسکرام مستر برای تیم توسعه
اسکرام مستر از طرق مختلفی به تیم توسعه خدمت رسانی میکند، از آن جمله:
مربیگری تیم توسعه در مسیر خودسازمانده و فراوظیفه‌ای شدن
کمک به تیم توسعه برای خلق محصولات با ارزش
حذف موانع موجود بر سر راه پیشرفت تیم توسعه
تسهیل رویدادهای اسکرام به محض درخواست یا نیاز
مربیگری تیم توسعه در محیط‌های سازمانی که هنوز اسکرام به صورت کامل در آنها پذیرفته یا درک نشده است.
خدمات اسکرام مستر برای سازمان
اسکرام مستر از طرق مختلفی به سازمان خدمت رسانی میکند، از جمله:
هدایت و مربیگری سازمان در مسیر پذیرش اسکرام
طرح ریزیِ پیاده سازی‌های اسکرام در سازمان
کمک به کارمندان و ذینفعان برای درک و برگزاری عملی اسکرام و توسعه تجربی محصول
سبب ساز و آغازگر تغییری که موجب افزایش سودمندی تیم اسکرام می‌شود
همکاری با اسکرام مسترهای دیگر برای افزایش سودمندیِ کاربرد اسکرام در سازمان
جلسات اسکرام
جلسات و یا رویدادهای اسکرام برای ایجاد شفافیت لازم سازماندهی می‌شوند. اسکرام از رویدادها برای ایجاد نظم و کاهش نیاز به جلساتی که بخشی از چارچوب اسکرام نیستند استفاده میکند.
برای ساده کردن پیچیدگی، همه رویدادها باید در یک زمان و مکان برگزار شوند.
Sprint Planning
در Sprint Planning چه اتفاقی می‌افتد؟
در طول برنامه ریزی اسپرینت، کل تیم اسکرام با هم همکاری می‌کنند و در مورد کار با اولویت بالا برای اسپرینت بحث می‌کنند و هدف اسپرینت را تعریف می‌کنند. نقش استاد اسکرام در درجه اول تسهیل جلسه است. صاحب محصول هدف محصول را توصیف میکند و همچنین به سؤالات تیم توسعه در مورد معیارهای اجرا و پذیرش معیارهای رضایت پاسخ میدهد. توسعه‌دهندگان در مورد اینکه چه مقدار از کارهای با اولویت بالایی که می‌تواند در طول دوی سرعت انجام دهد، حرف آخر را می‌زنند.
چه کسی در برنامه‌ریزی اسپرینت اسکرام شرکت میکند؟
برنامه‌ریزی اسپرینت شامل کل تیم اسکرام است: تیم توسعه، مالک محصول و اسکرام مستر.
برنامه‌ریزی اسپرینت چقدر باید ادامه داشته باشد؟
برنامه‌ریزی اسپرینت حداکثر به هشت ساعت محدود می‌شود.
Daily Scrum
در Daily Scrum چه اتفاقی می‌افتد؟
تیم توسعه به مدت 15 دقیقه (یا کمتر) هر روز از اسپرینت برای بررسی پیشرفت به سمت هدف اسپرینت گرد هم می‌آیند. آنها برای یکدیگر توصیف می‌کنند که کارشان چگونه پیش می‌رود، در صورت نیاز درخواست کمک می‌کنند و در نظر می‌گیرند که آیا هنوز در مسیر رسیدن به هدف سرعت هستند یا خیر. این یک جلسه وضعیت نیست، بلکه فرصتی برای تیم توسعه است تا محصول و فرآیند را به صورت روزانه بررسی و تطبیق دهد.
تعریف انجام شده (Definition Of Done) موجب شفافیت می‌شود. تا زمانی که DOD محقق نشود، نمی‌توان Increment را نهایی و قابل تحویل تلقی کرد! از طرفی تعریف نادرست DOD می‌تواند صدمات زیادی در پی داشته باشد!
Sprint Review
در Sprint Review چه اتفاقی می‌افتد؟
بررسی‌های اسپرینت بر روی محصول در حال توسعه تمرکز دارد، به ویژه بر افزایش محصول بالقوه قابل حمل که در طول اسپرینت ایجاد می‌شود. در طول بررسی اسپرینت، تیم اسکرام از ذی‌اثران دعوت میکند تا در مورد آنچه در طول اسپرینت تکمیل شده است صحبت کنند. آنها بر اساس این بازخورد، Backlog محصول را در صورت نیاز تطبیق می‌دهند.
چه کسی در بررسی اسپرینت شرکت میکند؟
کل تیم اسکرام در بررسی اسپرینت شرکت می‌کنند. این تیم از کاربران، مشتریان، ذی‌اثران، مدیران ارشد و بخش‌های تحت تأثیر (مانند بازاریابی، پشتیبانی مشتری) دعوت میکند تا در آن شرکت کنند و بازخورد بدهند. تیمهای اسکرام تشویق می‌شوند تا تعداد افراد زیادی را که اتاق می‌تواند داشته باشد دعوت کنند – بازخوردهای متنوع برای ایجاد محصولات عالی ضروری است.
بررسی‌های اسپرینت چقدر باید دوام داشته باشد؟
بررسی‌های اسپرینت حداکثر به چهار ساعت محدود می‌شود.
قاعده کلی این است که هر یک هفته از طول اسپرینت، یک ساعت برای مرور سرعت در نظر گرفته شود. این بدان معناست که تیم‌ها باید بازبینی تایم باکس را به دو ساعت برای دو هفته و چهار ساعت برای یک ماه سرعت بازبینی کنند.
Sprint Retrospective
در یک Sprint Retrospective چه اتفاقی می‌افتد؟
بررسی‌های گذشته اسپرینت بر روی این فرآیند تمرکز دارد. تیم اسکرام در طول یک Sprint Retrospective، در مورد آنچه درست پیش رفت و زمینه‌هایی برای بهبود در اسپرینت بحث میکند. آنها برنامه‌های ملموسی برای بهبود فرآیند، ابزار و روابط خود می‌سازند.
بازنگری‌های اسپرینت چه مدت باید طول بکشد؟
بازنگری‌های اسپرینت حداکثر به سه ساعت محدود می‌شود.
یسسیبسی
همه کسب‌وکارها تمایل دارند که روند کارها را سریع و پیشرونده طراحی کنند و در عمل نیز شاهد پیشرفت سریع فرایندها باشند؛ اما آیا این اتفاق به‌راحتی و برای همه مشاغل به‌صورت یکسان تحقق پیدا میکند؟ میزان پیچیدگی و سهولت برخی از روال‌ها در برخی از کسب‌وکارها ایجاب میکند تا چارچوب‌ها و راهکارهایی برای موفقیت عملیات پروژه طراحی و پیاده‌سازی شود. ایده‌پردازی این راهکار، به‌عنوان یکی از مهارت‌های سخت، در برخی از مشاغل به رسمیت شناخته شده و برای آن یک موقعیت شغلی تعریف شده است. در این مطلب به این می‌پردازیم که اسکرام چیست و عملکرد و متدولوژی اسکرام در مدیریت پروژه چگونه است.
اسکرام یک چارچوب تکرار‌شدنی با قابلیت افزودن عنصر و فاکتور یا به‌اصطلاح، چرخشی برای کنترل پروژه‌هاست. این چارچوب بخشی از شاخه فرایند تولید نرم‌افزار چابک و سریع است؛ بنابراین، مدلی در مهندسی نرم‌افزار به حساب می‌آید. تفکر و فلسفه اصلی اسکرام بر مبنای چابک یا اجایل (Agile) بنا شده است و برای حل مسائل پیچیده بسیار کارآمد است؛ یعنی مسائلی که دانش ما نسبت به آن ناقص است و به‌تدریج کامل می‌شود. در این دسته از مسائل، اول از همه، نیازمندی‌های ابتدایی پروژه در رأس کار قرار می‌گیرد و سپس با دریافت بازخورد از مشتری می‌توان نظرات جدید یا متفاوت را در قالب یک نیاز طرح‌شدنی به پروژه اضافه کرد.
این نوع مسائل پیچیده در شرکت‌های تجاری و کسب‌وکارها به‌وفور وجود دارد یا بروز میکند. با پیچیده‌ترشدن روزافزون روال کارها، نیاز به تسریع در فرایند تولید محصولات و رسیدن به چابکی بیشتر همراه با جبران کمبود نیروی انسانی، بیش از پیش احساس می‌شود؛ یعنی همان چیزی که اسکرام می‌تواند به آن پاسخ دهد؛ بنابراین، به این نکته توجه کنید اسکرام چیست، اسکرام یک فرایند یا تکنیک تولید محصول نیست، بلکه چارچوبی است که به‌وسیله آن می‌توان تولید محصول را بهینه کرد.
مطلب مرتبط: معرفی شغل اسکرام مستر
متدولوژی اسکرام چگونه کار میکند؟
اسکرام، این مهارت مهم برای حل مسائل پیچیده، چطور کار میکند؟ درمورد نام‌گذاری نحوه عملکرد اسکرام، نظرات متفاوتی وجود دارد. برخی از لفظ چارچوب و برخی دیگر از واژه متدولوژی یا روش‌شناسی استفاده می‌کنند. فارغ از اینکه چگونگی اجرای یک پروژه بر مبنای اسکرام یا توسعه نرم‌افزار چابک را چه بنامیم، مهم این است که بدانی ماهیت اسکرام چیست، اسکرام بر تقسیم‌بندی یک پروژه بزرگ با مراحل و پیچیدگی‌های بسیار، به چندین کار با بخش ثابت و تکرارپذیر استوار است.
اسکرام برای بهینه‌سازی پیش‌بینی و مدیریت ریسک در طول مدیریت پروژه از یک روش چرخشی-افزایشی استفاده میکند؛ این کار برای پاسخ به این ۲ سؤال است:
-- آیا ما «محصول درستی» را می‌سازیم؟
-- آیا ما محصول را به «شیوه درستی» می‌سازیم؟
برای برخی از پروژه‌ها پاسخ به این سؤالات دشوار نیست، اما در برخی از پروژه‌ها امکان دارد که یک بازخورد از سوی مشتری در انتهای پروژه، ما را غافل‌گیر کند؛ اینجاست که مشخص می‌شود کاربرد و اهمیت اسکرام چیست.
برای آشنایی با عملکرد و متدولوژی اسکرام لازم است که چند مفهوم را بدانید:
اسپرینت و بک لاگ
پس از آشنایی با این که اسکرام چیست به نحوه عملکرد و متدولوژی اسکرام می‌پردازیم، هسته اصلی اسکرام را اسپرینت (Sprint) تشکیل می‌دهند. اسپرینت‌ها دوره‌های زمانی تکرارشونده است. همان طور که گفتیم، متدولوژی اسکرام بر تکرارشوندگی بنا شده است. در این دوره‌های تکراری است که محصول به‌تدریج کامل می‌شود و در پایان دوره زمانی هر تکرار، شرایط محصول بررسی می‌شود. این روند تکراری آنقدر ادامه می‌یابد تا در پایان، محصول نهایی تولید شود. در اسپرینت‌ها باید مشخص شود که چه کارهایی قرار است انجام شود، چه نیازمندی‌هایی وجود دارد و چطور می‌توان به آنها جامه عمل پوشاند.
به‌عبارت دقیق‌تر، در هر اسپرینت به این موارد رسیدگی می‌شود:
-- شفافیت: مشخص و واضح بودن تمامی جنبه‌های فرایند برای همه اعضای تیم (مشتری و برنامه‌نویس)؛
-- بازبینی: تشخیص سریع انحراف احتمالی در هر مرحله از فرایند؛
-- تطبیق: تعدیل هرچه‌سریع‌تر انحراف‌های شناسایی‌شده در کمترین زمان ممکن.
و در هر اسپرینت که جلسات روزانه‌ای با حضور اعضای تیم (تیم تولید و ذینفعان) است، پیشرفت‌های پروژه در قالب ۳ پرسش زیر پاسخ داده می‌شود:
-- چه پیشرفت‌هایی حاصل شده است؟
-- چه موفقیت‌هایی در اسپرینت بعدی حاصل می‌شود؟
-- چه موانعی برای ادامه کار پیش رو است؟
اسکرام از ۴ رویداد رسمی تشکیل می‌شود که فرایند کار را آسان‌تر پیش ببرد:
-- برنامه‌ریزی اسپرینت (Sprint Planning)
-- اسکرام روزانه (Daily Scrum)
-- بازبینی اسپرینت (Sprint Review)
-- بازاندیشی اسپرینت (Scrum Retrospective)
یکی دیگر از مفاهیم کارا در دنیای اسکرام، بک لاگ (backlog) است. منظور از بک لاگ نیز مجموعه نیازمندی‌های عملیاتی و غیرعملیاتی است که باید در هر اسپرینت تمام شوند و به نام اسپرینت بک لاک (sprint backlog) گفته می‌شود. هر دوره اسپرینت (sprintcycle) تا زمانی که محصول آماده انتشار باشد، ادامه می‌یابد و ممکن است که صاحب پروژه بعد از انتشار، نیازمندی‌های جدیدی را به پروژه اضافه کند که به آن product backlog می‌گویند.
حالا که با متوجه شدید متدولوژی اسکرام و مفاهیم مهم در نحوه اجرای یک پروژه با راه‌ورسم اسکرام چیست، وقت آن است که بدانید در یک جلسه اسپرینت چه کسانی و با چه نقش‌ها و وظایفی حضور دارند.
مطلب مرتبط: نرم افزار مدیریت پروژه airtable
۳ نقش اصلی دارد:
مالک محصول یا نماینده صاحب پروژه یا ذی‌نفع
مالک محصول فردی است که نماینده کسب‌وکار در تیم شماست و وظیفه دارد که ارزشی را که در هر اسپرینت برای محصول حاصل می‌شود، به بالاترین حد ممکن برساند.
تیم توسعه
افراد این تیم با توجه به این که چارچوب قوانین اسکرام چیست، وظیفه تولید آنچه را صاحب پروژه درخواست کرده بود، بر عهده دارند. این تیم فنی به بُعد فنی توسعه محصول رسیدگی می‌کنند.
اسکرام مستر یا مدیر اسکرام
این فرد هم وظیفه کلید‌زدن فرایند اسکرام را در سازمان بر عهده دارد و هم فرایند درست اجرا‌شدن اسکرام را توسط تیم و مالک محصول کنترل میکند؛ همچنین باید برای حذف موانع از سر راه تیم نیز اقدام کند.
برای آشنایی بیشتر نسبت به این نقش مهم در فرایند اسکرام، لازم است بدانید که اسکرام مستر با مدیر پروژه در معنای سنتی آن تفاوت دارد؛ چراکه بر خلاف مدیر پروژه، تیم توسعه را به‌صورت روزانه هدایت نمی‌کند و وظیفه تعیین تکلیف و وظایف افراد را بر عهده ندارد.
در عوض، کسی که این نقش را بر عهده دارد باید تیم را از انحرافات بیرونی دور نگه دارد و به اعضا کمک کند تا در طول دوره اسپرینت بر هدفی که انتخاب کرده‌اند، به‌طور عمیق تمرکز کنند.
برای پاسخ به این سوال که وظایف مدیر اسکرام چیست باید بگوییم که به‌طور کلی اسکرام مستر ۲ وظیفه کلی را بر عهده دارد:
-- حفظ بهره‌وری بالا در توسعه؛
-- هدایت توسعه.
اما این وظایف را می‌توان به مجموعه تکالیف جزئی‌تری تجزیه کرد:
-- برگزاری و مدیریت جلسات؛
-- تضمین نرم‌افزار کارکننده؛
-- تسهیل ارتباطات؛
-- هدایت جلسه برنامه‌ریزی اسپرینت؛
-- ردگیری اسپرینت و Release؛
-- نمایندگی گروه؛
-- بهره‌وری؛
-- کوچک نگه‌داشتن تیم؛
-- هم‌سوکردن افراد با مشاغل؛
-- پیشگیری از موانع و رفع آنها هنگام وقوع.
آیا شما هم‌اکنون در همین موقعیت شغلی مشغول به کار هستید؟ اگر نه با استفاده از این مطلب با این که اسکرام چیست آشنا شدید؟ ما همچنین در این مطلب به متدولوژی و روش اسکرام و نحوه عملکرد آن پرداختیم. نظرات و پیشنهادات خود را با ما در میان بگذارید.
مطلب مرتبط: مدرک PMP (مدیریت پروژه حرفه‌ای) چیست؟
رزومه ساز
با ساختن یک رزومه حرفه‌ای، برای استخدام در بهترین فرصت‌های شغلی اقدام کنید.
منبع
scrum.ir
mountaingoatsoftware.com
parsdata.com
danup.ir
DevOps
jira
trello
Lean
Kanban
DAD
SAFe
Agile
Scrum
Waterfall
Hybrid project management combines elements of waterfall and agile methodologies to make the project management approach best suited for an individual use case.
