فلسفه چابک
هرچه عدم قطعیت در پروژه افزایش پیدا کند، احتمال تغییرات، دوباره‌کاری‌ها و بازنگری نیز افزایش می‌یابد که هزینه‌بر و وقت‌گیر است؛ بنابراین نیاز به رویکرد متفاوتی در مدیریت پروژه داریم. برای کاهش اثر این ریسک، محصول در طول عمر خود به صورت پیوسته و با Scope کوچک و در بازه‌های زمانی کوتاه توسعه می‌یابد. در این صورت می‌توانیم نیازهای واقعی مشتری را سریع‌تر و دقیق‌تر درک کنیم. زمانی که تیم‌ها کارهای موردنیاز را به‌صورت چرخه‌ای تکراری موردبررسی قرار می‌دهند و به‌طور مرحله‌ای و مداوم ارائه می‌دهند، تیم‌ها به‌راحتی با تغییرات سازگار می‌شوند.(رویکرد افزایشی-تکراری)
مثال‌هایی از افرادی که با کارهای پر ریسک مواجه هستند شامل مهندسین سیستم‌های نرم‌افزاری، طراحان محصول، پزشکان، معلمان، وکلا و … است.
بیانیه (مانیفست) اجایل
در سال ۲۰۰۱ ، هفده تن از خبره‌ترین توسعه دهندگان نرم افزار دنیا، بیانیه‌ای صادر کردند و در آن مانیفست اجایل را تشریح کردند:
“ما با توسعه نرم‌افزار و کمک به دیگران در این راه به دنبال کشف راه‌های بهتری در توسعه نرم‌افزار هستیم. در انجام این کارها، موارد زیر برای ما ارزشمند هستند:
افراد و تعاملات فراتر از فرآیندها و ابزارها
محصول قابل استفاده فراتر از مستندات جامع
مشارکت مشتری فراتر از قرارداد کار
پاسخگویی به تغییرات مهمتر از پیروی یک برنامه”
با وجود اینکه موارد سمت چپ نیز ارزشمند هستند ولی برای موارد سمت راست ارزش بیشتری باید قائل شد.
اصول بیانیه اجایل
- بالاترین اولویت ما جلب رضایت مشتری با تحویل به موقع و مداوم محصول ارزشمند هست.
- استقبال از تغییر نیازمندی‌ها، حتی در اواخر فرآیند توسعه نرم‌افزار. فرآیندهای چابک، تغییر را در جهت ایجاد مزیتِ رقابتی مشتری هدایت می‌کنند.
- تحویل زود به زود محصول قابل استفاده در بازه زمانی دو،سه هفته یک بار تا دو، سه ماه یک بار که ترجیح بر فاصله‌های زمانی کوتاه‌تر است.
- ذی‌نفعان کسب و کار و توسعه دهندگان می‌بایست به صورت مداوم در طول پروژه با هم کار کنند.
- پروژه‌ها باید بر دوش افراد با انگیزه بنا شوند. فضای لازم را به آنها بدهید و از نیازهای آن ها پشتیبانی کنید و به آنها اعتماد کنید تا کارها را به درستی انجام دهند.
- کارآمدترین و موثرترین روش انتقال اطلاعات به تیم‌های توسعه نرم‌افزار و تبادل آن در میان اعضای تیم ، گفتگوی چهره به چهره است.
- محصول قابل استفاده اصلی‌ترین معیار سنجش پیشرفت است.
- فرآیند های چابک توسعه پایدار را ترویج می دهند. حامیان مالی ,توسعه دهندگان و کاربران باید بتوانند سرعت پیشرفت ثابتی را برای مدت زمان نامحدودی حفظ کنند.
- توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می شود.
- سادگی — هنر به حداق رساندن کارهای نیمه تمام — ضروری است.
- بهترین معماری‌ها ,نیازمندی‌ها و طراحی ها از تیم های خودسازمان‌دهنده پدید آور می شوند.
- در فواصل منظم , تیم بر تاثیرگذاری بیشتر، تامل می‌کند و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم می‌کند.
Practice های اجایل
در توسعه نرم‌افزار با فلسفه اجایل، practice های مختلفی وجود دارد که الزاما مربوط به اجایل نیستند و برخی از آنها در چارچوب‌های قدیمی‌تر نرم افزار نیز وجود دارند. پیاده‌سازی و استفاده کامل از این practice ها در متدولوژی های مختلف متفاوت است. برخی در اکثر تیم های اجایل مورد استفاده قرار میگیرد و برخی نیز به صورت محدود مورد استفاده قرار میگیرد. در ادامه مهم‌ترین practice های اجایل ذکر گردیده است (توجه شود در برخی منابع بخشی از practice ها که بیشتر ناظر به لایه متدولوژی هستند تا عملیات فنی تحت عنوان تکنیک ذکر می شوند)
| Planning | Requirements | Design | Construction | Testing | Organization |
|---|---|---|---|---|---|
| Velocity | Configuration Management | Scrum of Scrums | |||
| Value Stream Mapping | Frequent Delivery / Frequent Releases | ||||
| Time boxing / Fixed Sprints | Product Vision / Vision Statement | Architectural Spikes / Spike Solutions | Coding Standards / Coding Guidelines | Unit Testing | Small Team |
| Task Board | Usage Scenarios | Design by Contracts | Refactoring | Exploratory Testing | On-Site Customer / Product Owner |
| Sprint Review / Iteration Demo | Source Control / Version Control | ||||
| Sprint Backlog | Use Cases | CRC Cards | Pair Programming / Code Review | System Testing | Co-located Team / Sitting Together / Common Workspace |
| Root Cause Analysis / 5 Whys | Software Metrics / Code Metrics & Analysis | ||||
| Retrospective / Reflection Workshop | |||||
| Release Planning | Product Backlog | Domain Driven Design | Test Driven Development | Smoke Testing / Build Verification Test | Cross-Functional Team |
| Process | Requirement Prioritization | Continuous Integration | Move People Around | ||
| Planning Game / Sprint Planning | User Stories | Emergent Design / Evolutionary Design | Behavior Driven Development | Integration Testing | Self-Organizing Team / Scrum Team |
| Definition of Done | Planning Poker | Daily Builds / Automated Builds | Story testing / Acceptance Testing | Sustainable Pace | |
| Daily Stand-up Meeting | Personas | System Metaphor | Collective Code Ownership | Test Automation | Scrum Master |
| Burn Down Charts / Burn Up Charts |
متدولوژی‌های اجایل و Practiceهای آنها
باتوجه به موفقیت های رویکرد agile، علاقه به استفاده از این رویکرد افزایش پیدا کرده و امروزه متدولوژی‌ها و چهارچوب‌های مختلفی از این فلسفه ایجاد گشته است. با این حال این متدولوژی ها از ابزارها و روش‌های مختلفی استفاده می کنند. در جدول زیر بیش از بیست practice متداول امروزی در متدولوژی های agile بررسی شده است. دقت شود که تعدد practice ها به معنای بهتر بودن متدولوژی نیست و تیم های مختلف برحسب فاکتورهای مختلفی می توانند از این practice ها استفاده نمایند.
| Practices | Scrum | XP | DSDM | ASD | Kanban | FDD |
|---|---|---|---|---|---|---|
| ۱-۴ week iterations | ✅ | ✅ | ||||
| Customer Driven Development | ✅ | ✅ | ||||
| Any Type of Testing | ✅ | ✅ | ✅ | |||
| Time Boxing | ✅ | ✅ | ✅ | |||
| Simple Design | ✅ | ✅ | ||||
| Resource requirement Analysis | ✅ | |||||
| Coding Standards | ✅ | |||||
| Function Point Counting | ✅ | |||||
| Refactoring | ✅ | |||||
| Continuous Integration | ✅ | ✅ | ||||
| Test Driven Development | ✅ | |||||
| Code Review | ✅ | |||||
| Iteration Planning | ✅ | ✅ | ||||
| Retrospective | ✅ | |||||
| Burn-down Tracking | ✅ | |||||
| ۴۰ Hours Week | ✅ | |||||
| User Story Usages | ✅ | ✅ | ||||
| Collaboration and Learning | ✅ | ✅ | ||||
| Daily Builds and Test | ✅ | ✅ | ✅ | |||
| Onsite Customer (Product Owner) | ✅ | |||||
| Individual Code Ownership | ✅ | |||||
| Feasibility Study | ✅ | |||||
| Business Study | ✅ | |||||
| Regular Meeting (Daily) | ✅ | ✅ | ✅ | |||
| Small Releases | ✅ | ✅ | ||||
| Component Development | ✅ | |||||
| Feature Based Teams | ✅ | ✅ | ✅ | |||
| Evolutionary Prototyping | ✅ |
رابطه فلسفه اجایل، بیانیه، اصول و Practice ها
شکل زیر تفسیر گویایی از روابط بین اجزای فلسفه اجایل است. هسته اصلی اجایل، پاسخ به تغییر است. بیانیه اجایل بر اساس این هسته اصلی شکل میگیرد. سپس اصول اجایل بر روی بیانیه استوار می شود و در نهایت این Practice ها هستند که در متدولوژی‌های مختلف مورد استفاده قرار میگیرند تا توسعه چابک محقق شود.
