314 lines
11 KiB
Org Mode
Executable File
314 lines
11 KiB
Org Mode
Executable File
:PROPERTIES:
|
||
:ID: 67ad330b-cc11-4e8e-b054-12b9da45ea60
|
||
:END:
|
||
#+title: Software Development Methodologies
|
||
#+filetags: :notes:career:technical:
|
||
|
||
|
||
* 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
|
||
#+BEGIN_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.
|
||
#+END_EXAMPLE
|
||
|
||
** 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:
|
||
#+BEGIN_QUOTE
|
||
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)
|
||
#+END_QUOTE
|
||
|
||
** 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
|
||
#+BEGIN_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.
|
||
#+END_EXAMPLE
|
||
|
||
** 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)
|
||
#+BEGIN_EXAMPLE
|
||
[Sprint Planning] → [Daily Standup × N] → [Sprint Review] → [Retrospective]
|
||
↑_____________________________ repeat (1–4 weeks) ___________________|
|
||
#+END_EXAMPLE
|
||
|
||
| 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
|
||
#+BEGIN_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?
|
||
#+END_EXAMPLE
|
||
|
||
** 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
|
||
#+BEGIN_EXAMPLE
|
||
| Backlog | In Progress (WIP:2) | Review (WIP:1) | Done |
|
||
|---------|---------------------|----------------|------|
|
||
| Task D | Task B | Task A | Task X|
|
||
| Task E | Task C | | Task Y|
|
||
#+END_EXAMPLE
|
||
|
||
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
|
||
#+BEGIN_EXAMPLE
|
||
Red → Write a failing test
|
||
Green → Write the minimum code to pass it
|
||
Refactor → Clean up without breaking the test
|
||
Repeat.
|
||
#+END_EXAMPLE
|
||
|
||
** 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
|
||
#+BEGIN_EXAMPLE
|
||
Essential SAFe: Team + Program levels
|
||
Large Solution: + Solution Train (multiple ARTs)
|
||
Portfolio SAFe: + Portfolio strategy & funding
|
||
#+END_EXAMPLE
|
||
|
||
** 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
|
||
#+BEGIN_EXAMPLE
|
||
Code Push → Build → Unit Tests → Integration Tests → Deploy to Staging
|
||
→ Manual Approval → Deploy to Production → Monitor
|
||
#+END_EXAMPLE
|
||
|
||
** 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
|
||
|
||
#+BEGIN_EXAMPLE
|
||
Most modern teams use a HYBRID approach:
|
||
Scrum (planning cadence)
|
||
+ Kanban board (visual workflow)
|
||
+ XP practices (TDD, CI)
|
||
+ DevOps (automated pipelines)
|
||
#+END_EXAMPLE
|
||
|
||
-----
|
||
|
||
* 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 |
|