Agile چیست و چه تفاوتی با Scrum دارد؟

در گفت‌وگوی روزمره، خیلی‌ها می‌گویند «ما Agile کار می‌کنیم» و منظورشان جلسات روزانه یا بورد تسک است. دقیق‌تر این است: Agile یک نام برای مجموعه‌ای از ارزش‌ها و اصول است که در Manifesto for Agile Software Development (۲۰۰۱) صورت‌بندی شد؛ Scrum یک چارچوب مشخص با نقش‌ها، رویدادها و آرتیفکت‌های تعریف‌شده در Scrum Guide است.

رابطه شبیه «تغذیه سالم» و «یک رژیم مشخص با قواعد اندازه‌گیری» است: می‌توانید بدون Scrum به روح Agile نزدیک شوید؛ و می‌توانید نام Scrum را داشته باشید ولی خلاف ارزش‌های Agile رفتار کنید. این مقاله مرزها را روشن می‌کند تا در استخدام، قرارداد و طراحی فرایند، واژهٔ درست به کار ببرید.

منابع این صفحه همان صفحات رسمی‌اند: agilemanifesto.org برای ارزش‌ها، صفحهٔ principles برای دوازده اصل، و Scrum Guide برای تعریف Scrum.

پاسخ کوتاه

Agile: جهت‌گیری ارزشی — افراد و تعاملات بر فرایند و ابزار؛ نرم‌افزار کارکننده بر مستندسازی جامع؛ همکاری با مشتری بر مذاکرهٔ قراردادی سخت؛ پاسخ به تغییر بر پیروی از طرح. (در عین حال ارزش سمت راست انکار نمی‌شود؛ سمت چپ اولویت دارد.)

Scrum: چارچوب عملی برای تولید ارزش در مسائل پیچیده با Sprint، حساب‌پذیری‌های مشخص، و حلقهٔ شفافیت/بازرسی/تطبیق. Scrum می‌تواند یکی از راه‌های تحقق اصول Agile باشد، اما Agile ≠ Scrum. Kanban، XP و رویکردهای ترکیبی دیگر هم می‌توانند Agile باشند بدون اینکه Scrum باشند.

ارزش‌های بیانیهٔ Agile

نویسندگان بیانیه می‌گویند با کار عملی و کمک به دیگران، راه‌های بهتری برای توسعهٔ نرم‌افزار کشف می‌کنند و به این‌ها ارزش می‌دهند:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

جملهٔ کلیدی بعدی اغلب فراموش می‌شود: در آیتم‌های سمت راست هم ارزش هست؛ فقط سمت چپ را بیشتر ارج می‌نهیم. پس Agile ضدمستند یا ضدبرنامه نیست؛ ضد مستندسازی یا برنامه‌ای است که جایگزین یادگیری و همکاری شود.

دوازده اصل — خلاصهٔ تصمیم‌محور

صفحهٔ اصول، اولویت رضایت مشتری با تحویل زودهنگام و پیوستهٔ نرم‌افزار باارزش را در صدر می‌گذارد. چند اصل که مستقیماً روی تصمیم تیم اثر می‌گذارند:

• خوشامد به تغییر نیازمندی حتی دیرهنگام — تغییر برای مزیت رقابتی مشتری مهار می‌شود.
• تحویل مکرر نرم‌افزار کارکننده در مقیاس هفته تا ماه، با ترجیح بازهٔ کوتاه‌تر.
• همکاری روزانهٔ افراد کسب‌وکار و توسعه‌دهندگان در طول پروژه.
• ساخت پروژه حول افراد بالنگیزه؛ محیط و اعتماد لازم را بدهید.
• نرم‌افزار کارکننده معیار اصلی پیشرفت است.
• توسعهٔ پایدار: حامیان، توسعه‌دهندگان و کاربران بتوانند آهنگ ثابت را نامحدود حفظ کنند.
• توجه پیوسته به برتری فنی و طراحی خوب، چابکی را تقویت می‌کند.
• سادگی — هنر بیشینه کردن کار انجام‌نشده — ضروری است.
• بهترین معماری‌ها، نیازمندی‌ها و طراحی‌ها از تیم‌های خودسازمان‌دهنده برمی‌آیند.
• در فواصل منظم تیم بازتاب می‌دهد چگونه مؤثرتر شود و رفتارش را تنظیم می‌کند.

اگر تیمی Sprint دارد اما هیچ بازتاب منظمی ندارد، یا «نرم‌افزار کارکننده» را با اسلاید وضعیت عوض کرده، برچسب Agile با اصول هم‌خوان نیست — حتی اگر ابزار گران قیمت داشته باشد.

Scrum در یک نگاه مقایسه‌ای

Scrum Guide، Scrum را چارچوب سبکی تعریف می‌کند که به تولید ارزش از راه‌حل‌های تطبیقی برای مسائل پیچیده کمک می‌کند. بر empiricism و lean thinking استوار است؛ رویدادهای رسمی برای بازرسی و تطبیق دارد؛ و عناصرش (تیم، رویدادها، آرتیفکت‌ها) برای هدف مشخصی آنجا هستند.

آنچه Scrum اضافه می‌کند و بیانیهٔ Agile به‌تنهایی مشخص نمی‌کند:

• حساب‌پذیری‌های Product Owner، Developers، Scrum Master
• Sprint با طول ثابت حداکثر یک ماه به‌عنوان ظرف کار
• رویدادهای Planning، Daily Scrum، Review، Retrospective با timebox
• آرتیفکت‌های Product Backlog، Sprint Backlog، Increment با تعهدهای Product Goal، Sprint Goal، Definition of Done

پس چرا این دو را با هم قاطی می‌کنند؟

چون در صنعت نرم‌افزار، Scrum رایج‌ترین دروازهٔ ورود به ادبیات Agile بوده است. دوره‌ها، آگهی‌های شغلی و ابزارها اغلب Scrum را به‌عنوان «همان Agile» می‌فروشند. نتیجه: مدیر می‌گوید Agile می‌خواهد و منظورش Daily و Story Point است؛ مربی می‌گوید Agile و منظورش ارزش‌های بیانیه است.

هزینهٔ این قاطی‌شدن عملی است: تیم فکر می‌کند با حذف مستند «Agile شده»، در حالی که اصل مربوطه مستند جامع را پایین‌رتبه می‌کند نه همکاری و نرم‌افزار کارکننده را. یا فکر می‌کند بدون Retrospective هم Scrum است، در حالی که Guide حذف رویداد را از دست دادن فرصت بازرسی/تطبیق می‌داند.

آیا می‌توان Agile بود بدون Scrum؟

بله. نمونه‌های رایج:

1. جریان کاری مبتنی بر Kanban با حد کار در جریان (WIP)، بدون Sprint ثابت.
2. شیوه‌های XP مانند TDD، pair programming و یکپارچه‌سازی مکرر، با یا بدون رویدادهای Scrum.
3. حلقهٔ تحویل کوتاه سفارشی: هر دو هفته Increment، بازبینی با کاربر، بدون عنوان Scrum Master.

آزمون عملی هم‌راستایی با Agile: آیا زود و مکرر ارزش قابل استفاده می‌رسانید؟ آیا تغییر را جذب می‌کنید نه انکار؟ آیا پیشرفت را با خروجی کارکننده می‌سنجید؟ آیا تیم منظم خودش را بهبود می‌دهد؟ اگر بله، جهت‌گیری Agile دارید — مستقل از نام چارچوب.

آیا می‌توان Scrum داشت و غیرAgile بود؟

متأسفانه بله. نشانه‌ها:

• Sprint فقط برای فشردن deadline ثابت سه‌ماهه به تکه‌های تقویمی، بدون اجازهٔ تغییر اولویت بر اساس یادگیری.
• Daily Scrum به‌عنوان گزارش سلسله‌مراتبی با ترس از شفافیت.
• Review بدون ذی‌نفع واقعی و بدون تصمیم دربارهٔ بعد.
• Definition of Done که کیفیت را فدای «تمام‌شدن ظاهری» می‌کند.
• افراد به‌عنوان منبع قابل تعویض در فرایند خشک، خلاف ارزش Individuals and interactions.

در این حالت تقویم شبیه Scrum است؛ روح بیانیه غایب است. Guide هم هشدار می‌دهد تغییر طراحی هسته یا جا انداختن عناصر، مشکلات را می‌پوشاند و منافع را محدود می‌کند.

چطور در سازمان حرف بزنید

پیشنهاد زبانی ساده:

• وقتی از ارزش‌ها و اصول می‌گویید: Agile.
• وقتی از Sprint، PO، SM، Review و Retrospective طبق Guide می‌گویید: Scrum.
• وقتی بورد و جریان کار بدون Sprint ثابت دارید: جریان Kanban یا سیستم کششی — و در صورت هم‌راستایی، «رویکرد Agile».

در RFP و قرارداد، به‌جای «اجرای Agile»، بگویید چه خروجی‌هایی، در چه ریتمی، با چه تعریف Done و چه نقش تصمیم‌گیرندهٔ اولویت می‌خواهید. ابهام واژه‌ای بعداً به اختلاف تحویل تبدیل می‌شود.

جمع‌بندی برای تصمیم

Agile قطب‌نماست؛ Scrum یکی از نقشه‌های پرتکرار. تفاوت اصلی در سطح انتزاع است: ارزش/اصل در برابر چارچوب با حساب‌پذیری و رویداد. شرکت سالم اول مشکل هماهنگی و پیچیدگی را می‌فهمد، بعد چارچوب را انتخاب می‌کند — نه برعکس.

اگر Scrum را انتخاب کردید، Guide را جدی بگیرید (مقالهٔ ۰۵۹). اگر فقط به اصول نیاز دارید، با تحویل مکرر، همکاری نزدیک با مشتری و بازتاب منظم شروع کنید؛ بعد ببینید آیا قواعد Scrum کمکتان می‌کند یا اضافه‌بار است.

نقشهٔ انتخاب سریع برای مدیر

اگر نیاز شما «زبان مشترک ارزش‌ها برای چند تیم با روش‌های مختلف» است، از Agile Manifesto و اصولش شروع کنید و هر تیم را مجبور به یک چارچوب نکنید. اگر نیاز شما «ریتم ثابت تحویل، نقش اولویت‌دهندهٔ واحد، و بازبینی منظم با ذی‌نفع» است، Scrum کاندیدای مستقیم است. اگر کارتان بیشتر جریان عملیاتی با ورودی پیوسته است و Sprint مصنوعی ایجاد صف می‌کند، سیستم کششی شبیه Kanban را بررسی کنید — و در صورت هم‌راستایی با اصول، همان را Agile بنامید.

علائم انتخاب اشتباه

• اجبار Sprint ثابت روی صف پشتیبانی که ماهیت وقفه دارد.
• اعلام Agile برای حذف همهٔ مستندات معماری در سیستمی با ریسک ایمنی یا مالی بالا.
• خرید ابزار قبل از توافق روی Product Goal و Done.
• تغییر ماهانهٔ چارچوب بدون اتمام یک چرخهٔ یادگیری معنادار.

Agile در قرارداد و فرهنگ ایرانی تیم‌های کوچک

در عمل بسیاری از پروژه‌های سفارشی هنوز با محدودهٔ ثابت و قیمت ثابت شروع می‌شوند. می‌توانید روح Agile را وارد کنید بدون نقض قرارداد: تحویل مرحله‌ای Incrementهای قابل پذیرش، معیار پذیرش روشن برای هر مرحله، و پنجرهٔ بازنگری اولویت داخل بودجهٔ توافق‌شده. برچسب Scrum فقط وقتی مفید است که PO واقعی، Sprint واقعی و Review واقعی داشته باشید — وگرنه همان تحویل مرحله‌ای را بدون ادعای چارچوب کامل بهتر است بنامید.

فرهنگ شفاهی قوی مزیت تعاملات افراد را دارد (هم‌راستا با ارزش اول بیانیه)؛ نقطهٔ ضعفش وقتی است که تصمیم‌ها در چت گم می‌شوند. حداقل شفافیت Agile/Scrum اینجا یعنی تصمیم اولویت و Done جایی نوشته شود که فردا قابل ارجاع باشد.

جمع‌بندی واژه‌ها برای جلسهٔ kickoff

روی تخته سه خط بنویسید: ۱) ارزش‌های Agile که رعایت می‌کنیم، ۲) آیا Scrum را کامل اجرا می‌کنیم یا نه، ۳) اگر نه، کدام حلقهٔ بازخورد جایگزین را داریم. این سه خط از ماه‌ها سوءتفاهم بعدی جلوگیری می‌کند.

جدول تصمیم سه‌گزینه‌ای

این جدول جایگزین تشخیص دقیق نیست؛ نقطهٔ شروع گفت‌وگوی تیم و مدیریت است. بعد از یک ماه، با دادهٔ واقعی (تعداد Incrementهای Done، میزان بازکاری، رضایت ذی‌نفع) مسیر را تنظیم کنید.

هم‌زیستی Scrum و بهبودهای فنی Agile

اصل «توجه پیوسته به برتری فنی و طراحی خوب» مستقیماً به کیفیت Sprint وصل است. تیمی که Sprint را با بدهی فنی بی‌مهار پر می‌کند، به‌تدریج توان پاسخ به تغییر را از دست می‌دهد — یعنی ضد ارزش Responding to change. بنابراین اختلاف Agile/Scrum فقط واژه‌ای نیست؛ اگر چارچوب رویدادها را بگیرید ولی مهندسی را رها کنید، هر دو را ضعیف اجرا کرده‌اید.

تمرین مشترک: در هر Retrospective حداقل یک بهبود فنی کوچک قابل انجام در Sprint بعد را کنار بهبود فرایندی بگذارید. این کار بیانیه و Guide را در یک عادت روزانه به هم نزدیک می‌کند.

مطالعهٔ موردی کوتاه: برچسب درست، نتیجهٔ متفاوت

تیم A هر روز Daily برگزار می‌کند، اما Product Owner کمیته است، Review بدون ذی‌نفع است، و Done نوشته نشده. آن‌ها خود را Agile/Scrum می‌نامند؛ در عمل نه ارزش‌های بیانیه را جدی گرفته‌اند (همکاری مشتری، نرم‌افزار کارکننده به‌عنوان معیار) و نه قواعد Guide را. خروجی: سرعت ظاهری بالا، بازکاری پنهان.

تیم B نام Scrum را روی در نمی‌گذارد، اما هر دو هفته Increment قابل استفاده به مشتری داخلی می‌دهد، اولویت را یک نفر نهایی می‌کند، و ماهانه رفتارش را تنظیم می‌کند. از نظر اصول، به Agile نزدیک‌تر است. درس: اول رفتار قابل مشاهده را بسنجید، بعد برچسب بزنید.

سؤالاتی که قبل از آموزش سازمانی بپرسید

• مشکل اصلی ما پیچیدگی و تغییر است یا کمبود انضباط تحویل؟
• آیا یک نفر می‌تواند ترتیب بک‌لاگ را نهایی کند؟
• آیا ذی‌نفعان حاضرند در Review تصمیم بگیرند؟
• آیا کیفیت قابل مذاکره در انتهای بازه هست یا خط قرمز دارد؟

اگر به این سؤال‌ها جواب صادقانه ندهید، خرید دورهٔ Scrum فقط واژگان جدید به همان تعارض‌های قدیمی اضافه می‌کند.

منابع و مراجع

• Manifesto for Agile Software Development — https://agilemanifesto.org/
• Principles behind the Agile Manifesto — https://agilemanifesto.org/principles.html
• The 2020 Scrum Guide™ — https://scrumguides.org/scrum-guide.html