راهنمای جامع مستندات Agile
راهنمای جامع مستندات Agile
مستندات Agile: راهنمای جامع با مثالهای عملی
در این بخش به بررسی سه سند کلیدی متدولوژی Agile میپردازیم که ستون فقرات مدیریت پروژههای چابک را تشکیل میدهند. این مستندات عبارتند از:
- Product Backlog (بکلاگ محصول)
- Sprint Backlog (بکلاگ اسپرینت)
- Release Plan (برنامه انتشار)
۱. Product Backlog (بکلاگ محصول)
تعریف
Product Backlog فهرست اولویتبندیشدهای از تمامی ویژگیها، بهبودها، وظایف فنی و رفع باگهایی است که برای محصول نیاز هستند. این سند توسط Product Owner مدیریت میشود و منبع اصلی کار تیم توسعه است.
استانداردهای نوشتن
ساختار استاندارد یک Item در Product Backlog:
عنوان: [عنوان کوتاه و توصیفی]
شرح User Story: [به فرمت Given-When-Then]
معیارهای پذیرش: [فهرست شرایط قابل تست]
اولویت: [MoSCoW: Must/Should/Could/Won’t]
تخمین: [Story Points]
وابستگیها: [شناسه Itemهای مرتبط]
مثال عملی
📋 Product Backlog – جزئیات کامل یک Item
شناسه: PB-001
عنوان: امکان ثبتنام کاربران با ایمیل
شرح User Story:
میخواهم با استفاده از ایمیل و رمز عبور ثبتنام کنم،
تا بتوانم از خدمات سایت استفاده کنم.
معیارهای پذیرش:
- فرم ثبتنام شامل فیلدهای نام، ایمیل و رمز عبور باشد
- اعتبارسنجی ایمیل به صورت real-time انجام شود
- پیام تأیید به ایمیل کاربر ارسال شود
- رمز عبور باید حداقل ۸ کاراکتر داشته باشد
- در صورت موفقیت، کاربر به داشبورد هدایت شود
اولویت: Must (باید)
تخمین: 5 Story Points
وابستگی: ندارد
مالک: علی محمدی (Product Owner)
نمونه جدول Product Backlog
| شناسه | عنوان | اولویت | تخمین | وضعیت |
|---|---|---|---|---|
| PB-001 | ثبتنام کاربران با ایمیل | Must | 5 SP | To Do |
| PB-002 | ورود با شبکههای اجتماعی | Should | 8 SP | To Do |
| PB-003 | بازیابی رمز عبور | Must | 3 SP | To Do |
| PB-004 | پروفایل کاربری | Could | 13 SP | To Do |
| PB-005 | اعلانهای ایمیلی | Won’t | – | Backlog |
۲. Sprint Backlog (بکلاگ اسپرینت)
تعریف
Sprint Backlog فهرست وظایفی است که تیم توسعه در طول یک Sprint متعهد به انجام آنها است. این سند شامل موارد انتخابشده از Product Backlog به همراه وظایف فنی لازم برای تحویل Increment است.
استانداردهای نوشتن
📋 ساختار استاندارد Sprint Backlog
اطلاعات Sprint:
- عنوان Sprint: Sprint ۱۵
- مدت: ۲ هفته (۱۴۰۱/۰۲/۱۵ تا ۱۴۰۱/۰۲/۲۹)
- هدف Sprint: راهاندازی ماژول احراز هویت
فهرست User Stories و وظایف:
| وظیفه | مسئول | تخمین | وضعیت |
|---|---|---|---|
| طراحی فرم ثبتنام | مریم | 2 ساعت | ✓ انجام |
| ایجاد API ثبتنام | علی | 4 ساعت | ⏳ در حال |
| پیادهسازی اعتبارسنجی | سارا | 2 ساعت | ⏳ در حال |
| ارسال ایمیل تأیید | علی | 3 ساعت | ○ Todo |
| نوشتن Unit Test | سارا | 3 ساعت | ○ Todo |
| یکپارچهسازی فرانتاند و بکاند | مریم | 2 ساعت | ○ Todo |
مثال عملی کامل
تاریخ: 1401/02/15 – 1401/02/29
هدف: راهاندازی سیستم احراز هویت کاربران
ظرفیت تیم: 40 Story Points
Story 1: ثبتنام کاربران (PB-001) – 5 SP
مسئول: تیم توسعه
| وظیفه | مسئول | تخمین | وضعیت |
|---|---|---|---|
| طراحی فرم ثبتنام UI/UX | مریم | 2h | ✓ |
| ایجاد جدول users در دیتابیس | علی | 1h | ✓ |
| پیادهسازی API ثبتنام | علی | 4h | ⏳ |
| اعتبارسنجی سمت سرور | سارا | 2h | ⏳ |
| ارسال ایمیل تأیید | علی | 3h | ○ |
| نوشتن Unit Tests | سارا | 3h | ○ |
| یکپارچهسازی | مریم | 2h | ○ |
Story 2: بازیابی رمز عبور (PB-003) – 3 SP
| وظیفه | مسئول | تخمین | وضعیت |
|---|---|---|---|
| طراحی فرم بازیابی | مریم | 1h | ○ |
| پیادهسازی API | علی | 3h | ○ |
| ارسال لینک بازیابی | علی | 2h | ○ |
وظایف فنی (Technical Debt)
- راهاندازی محیط توسعه Docker – 2h – ✓ انجام
- تنظیم CI/CD Pipeline – 4h – ⏳ در حال
تفاوت Product Backlog و Sprint Backlog
| معیار | Product Backlog | Sprint Backlog |
|---|---|---|
| مالک | Product Owner | تیم توسعه |
| محدوده | کل محصول | Sprint جاری |
| تغییرپذیری | بالا (هر لحظه) | محدود (فقط در Sprint Planning) |
| جزئیات | متغیر (بالا به پایین) | بسیار جزئی |
| تخمین | Story Points | ساعت/زمان |
۳. Release Plan (برنامه انتشار)
تعریف
Release Plan برنامهای است که زمانبندی و نحوه تحویل نسخههای مختلف محصول را مشخص میکند. این سند تعیین میکند که کدام ویژگیها در کدام Release عرضه میشوند.
استانداردهای نوشتن
– نام محصول: [نام محصول]
– نسخه: 1.0.0
– تاریخ انتشار هدف: [تاریخ]
– تعداد Sprintها: X
– ظرفیت کل: XX Story Pointsمعیارهای آمادگی انتشار:
□ تمام تستهای Functional پاس شده
□ تستهای امنیتی انجام شده
□ مستندات بهروز شده
□ تأیید Product Owner
مثال عملی کامل
محصول: سیستم مدیریت فروش آنلاین
تاریخ شروع: 1401/01/01
تاریخ انتشار هدف: 1401/06/01
ظرفیت کل: 240 Story Points (6 Sprint × 40 SP)
Timeline انتشار
→
Beta – 01/04
→
Release 1.0 – 01/06
محتوای هر Release
🚀 Release 0.1 – MVP (Minimum Viable Product)
تاریخ: 1401/02/15
- PB-001: ثبتنام کاربران (5 SP)
- PB-002: ورود به سیستم (3 SP)
- PB-010: مشاهده محصولات (5 SP)
- PB-011: سبد خرید (8 SP)
- PB-015: فرآیند Checkout (13 SP)
جمع: 34 SP
🚀 Release 0.5 – Beta
تاریخ: 1401/04/01
- PB-003: بازیابی رمز عبور (3 SP)
- PB-004: پروفایل کاربری (8 SP)
- PB-020: جستجوی محصولات (5 SP)
- PB-025: امتیازدهی و نظرات (8 SP)
- PB-030: پرداخت آنلاین (13 SP)
جمع: 37 SP
🚀 Release 1.0 – نسخه نهایی
تاریخ: 1401/06/01
- PB-005: داشبورد مدیریت (13 SP)
- PB-006: گزارشگیری (8 SP)
- PB-035: پنل مدیریت محصولات (8 SP)
- PB-040: سیستم تخفیف و کوپن (5 SP)
- PB-045: اعلانها (3 SP)
جمع: 37 SP
ریسکها و ملاحظات
- وابستگی به سیستم پرداخت خارجی – نیاز به Mock در MVP
- تستهای امنیتی قبل از Release 1.0 الزامی است
- در صورت کاهش سرعت، برخی ویژگیها به Release 2.0 موکول میشود
انواع Release Plan
| نوع | توضیح | مناسب برای |
|---|---|---|
| Time-Based | انتشار در بازههای زمانی ثابت | تیمهای با ثبات |
| Feature-Based | انتشار پس از تکمیل مجموعه ویژگی | محصولات با ویژگیهای وابسته |
| Hybrid | ترکیب زمان و ویژگی | اکثر پروژهها |
ابزارهای رایج برای مدیریت این مستندات
| ابزار | نوع | ویژگی |
|---|---|---|
| Jira | تجاری | کاملترین ابزار Agile |
| Trello | رایگان/پولی | ساده و بصری |
| Azure DevOps | پولی | یکپارچه با مایکروسافت |
| Linear | پولی | مدرن و سریع |
| Notion | رایگان/پولی | انعطافپذیر |
| Miro | پولی | تخته بصری برای Planning |
جمعبندی
| سند | هدف | مالک | زمان تهیه |
|---|---|---|---|
| Product Backlog | فهرست کامل نیازمندیها | Product Owner | مداوم |
| Sprint Backlog | وظایف Sprint جاری | تیم توسعه | Sprint Planning |
| Release Plan | برنامه انتشار نسخهها | Product Owner + تیم | قبل از Release |