344 lines
11 KiB
Markdown
Executable File
344 lines
11 KiB
Markdown
Executable File
---
|
||
note type:
|
||
- theory
|
||
date: 2026-06-03
|
||
done: true
|
||
---
|
||
# 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 |
|