This commit is contained in:
337
Career/Software Development Methodologies.md
Normal file
337
Career/Software Development Methodologies.md
Normal file
@@ -0,0 +1,337 @@
|
||||
# Software Development Methodologies
|
||||
|
||||
A software development methodology defines the *process, structure, and principles*
|
||||
used to plan, manage, and execute software projects.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
- Ensures predictability and consistency across teams
|
||||
- Reduces risk of project failure
|
||||
- Aligns stakeholders and developers on expectations
|
||||
- Provides tools for handling change and uncertainty
|
||||
|
||||
-----
|
||||
|
||||
# 1\. Waterfall
|
||||
|
||||
## Overview
|
||||
|
||||
A **linear, sequential** model where each phase must be completed before the next begins.
|
||||
|
||||
## Phases
|
||||
|
||||
1. Requirements
|
||||
2. System Design
|
||||
3. Implementation
|
||||
4. Testing
|
||||
5. Deployment
|
||||
6. Maintenance
|
||||
|
||||
## Example
|
||||
|
||||
``` example
|
||||
A government agency contracts a firm to build a tax portal.
|
||||
Requirements are frozen at sign-off; code is written six months
|
||||
later; testing follows; the portal launches two years in.
|
||||
```
|
||||
|
||||
## Pros & Cons
|
||||
|
||||
| Pros | Cons |
|
||||
| --------------------------- | ----------------------------------- |
|
||||
| Clear structure and phases | Very rigid; change is costly |
|
||||
| Easy to manage milestones | Late discovery of defects |
|
||||
| Good for fixed requirements | Customer sees nothing until the end |
|
||||
|
||||
## Best For
|
||||
|
||||
- Projects with well-defined, stable requirements
|
||||
- Regulatory/compliance-heavy environments (aerospace, medical devices)
|
||||
|
||||
-----
|
||||
|
||||
# 2\. Agile
|
||||
|
||||
## Overview
|
||||
|
||||
An **iterative, incremental** philosophy that values:
|
||||
|
||||
> Individuals and interactions over processes and tools.
|
||||
> Working software over comprehensive documentation.
|
||||
> Customer collaboration over contract negotiation.
|
||||
> Responding to change over following a plan.
|
||||
> — The Agile Manifesto (2001)
|
||||
|
||||
## Core Concepts
|
||||
|
||||
- **Iterations (sprints)**: Short delivery cycles (1–4 weeks)
|
||||
- **Incremental delivery**: Working software shipped frequently
|
||||
- **Feedback loops**: Customers review and redirect regularly
|
||||
- **Cross-functional teams**: Dev, QA, design collaborate continuously
|
||||
|
||||
## Example
|
||||
|
||||
``` example
|
||||
A startup builds a mobile app in 2-week sprints.
|
||||
Sprint 1 → user login
|
||||
Sprint 2 → profile page
|
||||
Sprint 3 → search feature
|
||||
After each sprint, real users test and give feedback,
|
||||
shaping what gets built next.
|
||||
```
|
||||
|
||||
## Agile Values vs Waterfall
|
||||
|
||||
| Dimension | Waterfall | Agile |
|
||||
| ------------- | -------------- | -------------------- |
|
||||
| Planning | Upfront, fixed | Continuous, adaptive |
|
||||
| Delivery | End of project | Every sprint |
|
||||
| Change | Discouraged | Embraced |
|
||||
| Customer role | Sign-off only | Active partner |
|
||||
| Risk exposure | High (late) | Low (early) |
|
||||
|
||||
## Best For
|
||||
|
||||
- Products with evolving requirements
|
||||
- Startups, SaaS, consumer apps
|
||||
|
||||
-----
|
||||
|
||||
# 3\. Scrum
|
||||
|
||||
## Overview
|
||||
|
||||
Scrum is the most popular **Agile framework**. It imposes a specific
|
||||
structure of roles, events, and artefacts on top of Agile principles.
|
||||
|
||||
## Roles
|
||||
|
||||
| Role | Responsibility |
|
||||
| ----------------- | ------------------------------------------- |
|
||||
| **Product Owner** | Owns the backlog; prioritises what to build |
|
||||
| **Scrum Master** | Removes blockers; facilitates ceremonies |
|
||||
| **Dev Team** | Self-organising; delivers the increment |
|
||||
|
||||
## Artefacts
|
||||
|
||||
- **Product Backlog** — ordered list of all desired features/fixes
|
||||
- **Sprint Backlog** — subset of items pulled into the current sprint
|
||||
- **Increment** — shippable product at end of each sprint
|
||||
|
||||
## Ceremonies (Events)
|
||||
|
||||
``` example
|
||||
[Sprint Planning] → [Daily Standup × N] → [Sprint Review] → [Retrospective]
|
||||
↑_____________________________ repeat (1–4 weeks) ___________________|
|
||||
```
|
||||
|
||||
| Event | Duration | Purpose |
|
||||
| --------------- | -------- | ---------------------------------- |
|
||||
| Sprint Planning | ≤ 8 hrs | Decide what goes into the sprint |
|
||||
| Daily Standup | 15 min | Sync on progress, surface blockers |
|
||||
| Sprint Review | ≤ 4 hrs | Demo increment to stakeholders |
|
||||
| Retrospective | ≤ 3 hrs | Reflect and improve the process |
|
||||
|
||||
## Example: Daily Standup Format
|
||||
|
||||
``` example
|
||||
Each team member answers three questions:
|
||||
1. What did I complete yesterday?
|
||||
2. What will I work on today?
|
||||
3. Is anything blocking me?
|
||||
```
|
||||
|
||||
## Best For
|
||||
|
||||
- Teams of 3–9 people
|
||||
- Products with frequent reprioritisation
|
||||
|
||||
-----
|
||||
|
||||
# 4\. Kanban
|
||||
|
||||
## Overview
|
||||
|
||||
A **flow-based** method focused on visualising work and limiting
|
||||
work-in-progress (WIP) to maximise throughput. No fixed sprints.
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. Visualise the workflow (the Kanban board)
|
||||
2. Limit WIP per column
|
||||
3. Manage and improve flow
|
||||
4. Make policies explicit
|
||||
|
||||
## Example Board
|
||||
|
||||
``` example
|
||||
| Backlog | In Progress (WIP:2) | Review (WIP:1) | Done |
|
||||
|---------|---------------------|----------------|------|
|
||||
| Task D | Task B | Task A | Task X|
|
||||
| Task E | Task C | | Task Y|
|
||||
```
|
||||
|
||||
WIP limits prevent bottlenecks — new work cannot start until a slot opens.
|
||||
|
||||
## Scrum vs Kanban
|
||||
|
||||
| Dimension | Scrum | Kanban |
|
||||
| --------- | ------------------- | ---------------------- |
|
||||
| Cadence | Fixed sprints | Continuous flow |
|
||||
| Roles | PO, SM, Dev Team | No prescribed roles |
|
||||
| Change | After sprint | Anytime |
|
||||
| Metrics | Velocity | Cycle time, throughput |
|
||||
| Best for | Feature development | Operations, support |
|
||||
|
||||
-----
|
||||
|
||||
# 5\. Extreme Programming (XP)
|
||||
|
||||
## Overview
|
||||
|
||||
An Agile methodology with an extreme focus on **engineering practices**
|
||||
and code quality.
|
||||
|
||||
## Key Practices
|
||||
|
||||
- **Test-Driven Development (TDD)**: Write the test before the code
|
||||
- **Pair Programming**: Two developers work at one machine
|
||||
- **Continuous Integration (CI)**: Merge and test code multiple times a day
|
||||
- **Refactoring**: Continuously improve code structure
|
||||
- **Small Releases**: Deploy frequently, in small increments
|
||||
- **Collective Code Ownership**: Anyone can change any code at any time
|
||||
|
||||
## Example: TDD Cycle
|
||||
|
||||
``` example
|
||||
Red → Write a failing test
|
||||
Green → Write the minimum code to pass it
|
||||
Refactor → Clean up without breaking the test
|
||||
Repeat.
|
||||
```
|
||||
|
||||
## Best For
|
||||
|
||||
- Teams prioritising code quality and technical excellence
|
||||
- Projects with rapidly changing requirements
|
||||
|
||||
-----
|
||||
|
||||
# 6\. SAFe (Scaled Agile Framework)
|
||||
|
||||
## Overview
|
||||
|
||||
SAFe scales Agile practices across **large enterprises** with multiple
|
||||
teams working on the same product.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Agile Release Train (ART)**: A long-lived team of 50–125 people
|
||||
- **Program Increment (PI)**: A 8–12 week planning cycle (like a "super sprint")
|
||||
- **PI Planning**: All teams plan together face-to-face every PI
|
||||
|
||||
## Levels
|
||||
|
||||
``` example
|
||||
Essential SAFe: Team + Program levels
|
||||
Large Solution: + Solution Train (multiple ARTs)
|
||||
Portfolio SAFe: + Portfolio strategy & funding
|
||||
```
|
||||
|
||||
## Best For
|
||||
|
||||
- Enterprises with 100+ engineers
|
||||
- Organisations migrating from Waterfall to Agile at scale
|
||||
|
||||
-----
|
||||
|
||||
# 7\. DevOps (Methodology + Culture)
|
||||
|
||||
## Overview
|
||||
|
||||
DevOps bridges **development and operations** to enable faster, more
|
||||
reliable software delivery through automation and collaboration.
|
||||
|
||||
## Core Pillars
|
||||
|
||||
| Pillar | Description |
|
||||
| -------------------------- | -------------------------------------------- |
|
||||
| **CI/CD** | Automate build, test, and deploy pipelines |
|
||||
| **Infrastructure as Code** | Manage servers via code (Terraform, Ansible) |
|
||||
| **Monitoring** | Observe systems in production continuously |
|
||||
| **Blameless Culture** | Learn from failures without finger-pointing |
|
||||
|
||||
## Example: CI/CD Pipeline
|
||||
|
||||
``` example
|
||||
Code Push → Build → Unit Tests → Integration Tests → Deploy to Staging
|
||||
→ Manual Approval → Deploy to Production → Monitor
|
||||
```
|
||||
|
||||
## Best For
|
||||
|
||||
- Any team wanting faster, safer releases
|
||||
- Organisations running cloud-native infrastructure
|
||||
|
||||
-----
|
||||
|
||||
# Comparison Summary
|
||||
|
||||
| Methodology | Structure | Delivery Cadence | Flexibility | Team Size | Best Fit |
|
||||
| ----------- | ---------- | ---------------- | ----------- | --------- | ----------------------- |
|
||||
| Waterfall | Sequential | End of project | Low | Any | Fixed scope, compliance |
|
||||
| Agile | Iterative | Every sprint | High | Small–Med | Evolving requirements |
|
||||
| Scrum | Iterative | Every 1–4 weeks | High | 3–9 | Feature development |
|
||||
| Kanban | Flow-based | Continuous | Very High | Any | Ops, support, flow work |
|
||||
| XP | Iterative | Weekly | High | Small | Quality-critical code |
|
||||
| SAFe | Iterative | Every 8–12 weeks | Medium | 50–125+ | Enterprise Agile |
|
||||
| DevOps | Continuous | On every commit | High | Any | Fast, reliable delivery |
|
||||
|
||||
-----
|
||||
|
||||
# Choosing the Right Methodology
|
||||
|
||||
Ask these questions:
|
||||
|
||||
1. **How stable are the requirements?**
|
||||
- Stable → Waterfall / SAFe
|
||||
- Changing → Agile / Scrum / Kanban
|
||||
2. **How large is the team?**
|
||||
- 3–9 → Scrum
|
||||
- 50+ → SAFe
|
||||
- Any size ops team → Kanban
|
||||
3. **How important is engineering quality?**
|
||||
- Very high → XP (TDD, pair programming)
|
||||
4. **How often do you need to ship?**
|
||||
- Daily → DevOps + CI/CD
|
||||
- Weekly → Scrum / XP
|
||||
- Continuously → Kanban
|
||||
5. **What is the regulatory environment?**
|
||||
- High compliance → Waterfall or hybrid
|
||||
|
||||
<!-- end list -->
|
||||
|
||||
``` example
|
||||
Most modern teams use a HYBRID approach:
|
||||
Scrum (planning cadence)
|
||||
+ Kanban board (visual workflow)
|
||||
+ XP practices (TDD, CI)
|
||||
+ DevOps (automated pipelines)
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
# Key Terminology Glossary
|
||||
|
||||
| Term | Definition |
|
||||
| ------------------ | ------------------------------------------------------------ |
|
||||
| Sprint | A fixed time-box (1–4 wks) in Scrum for delivering work |
|
||||
| Backlog | Prioritised list of work items |
|
||||
| Velocity | Amount of work a team completes per sprint |
|
||||
| WIP Limit | Maximum items allowed in a workflow stage simultaneously |
|
||||
| CI/CD | Continuous Integration / Continuous Delivery (or Deployment) |
|
||||
| TDD | Test-Driven Development |
|
||||
| Retrospective | Meeting to inspect and improve team process |
|
||||
| Definition of Done | Agreed criteria for when a task is truly "complete" |
|
||||
| Epic | Large body of work broken into smaller user stories |
|
||||
| User Story | Feature described from end-user perspective |
|
||||
Reference in New Issue
Block a user