Phase แบบ sequential#

1
Requirements → Design → Implementation → Testing → Deployment → Maintenance
2
     (1)          (2)         (3)            (4)        (5)            (6)

กฎ: Phase ก่อนเสร็จ → phase ถัดไปเริ่ม ไม่กลับ — ถ้าเจอปัญหาตอน Testing → “ก็ทำไง — เลยมา 3 phases แล้ว”

Waterfall จุดเด่น#

✅ Predictable — รู้ schedule + cost ตั้งแต่ต้น (เกือบ) ✅ Documentation ดี — phase ก่อนต้องเสร็จเอกสารก่อน phase ถัดไป ✅ Compliance friendly — regulator + audit ตามได้ง่าย ✅ Contract-friendly — fixed price ที่ vendor accept ได้ ✅ เหมาะกับ stable requirement

Waterfall จุดด้อย#

❌ Big-bang release — feedback หลังจบทุกอย่าง = ถ้าผิดก็ผิดทั้งหมด ❌ Late testing — เจอ bug ตอน phase 4 = แพง ❌ No learning — ตอน build ไม่ได้ learn อะไร — design + spec ตอน phase 1 ครอบงำ ❌ Customer ไม่เห็น product จนจบ — feedback ช้า ❌ Change Request แพง — เปลี่ยน scope กลาง project = re-baseline

Waterfall เหมาะเมื่อ#

Waterfall เคสที่ work#

Bangkok Mass Transit (รถไฟฟ้า): Waterfall ทุกเส้น — เพราะ:

• Civil engineering — design เปลี่ยนกลาง project = น้ำตา
• กฎหมาย + permit ต้องครบ
• Contract กับ contractor = fixed price

Boeing 747 (1960s): Waterfall — เพราะตอนนั้น aerospace ไม่มีทาง iterate physical product

Iteration แทน sequential#

1
[Plan → Build → Test → Deploy → Learn] × N
2
   ↑___________________________|
3
       วนทุก 2-4 อาทิตย์

Agile Manifesto — 4 ค่านิยม#

1. Individuals and interactions > processes and tools
2. Working software > comprehensive documentation
3. Customer collaboration > contract negotiation
4. Responding to change > following a plan

ฝั่งซ้ายมาก่อน — แต่ฝั่งขวาก็มีค่า ไม่ได้ทิ้ง

Agile จุดเด่น#

✅ Fast feedback — ทุก 2-4 อาทิตย์มี output ให้ stakeholder ดู ✅ Embrace change — scope ปรับได้ ✅ Customer collaboration — ทำงานใกล้ลูกค้า ✅ Reduce risk — bug เจอเร็ว = แก้ถูก ✅ Team morale — autonomy + visible progress ✅ เหมาะกับ uncertain requirement

Agile จุดด้อย#

❌ Hard to predict — บอก budget + date ตั้งแต่ต้นยาก ❌ Compliance hard — audit ตาม sprint ไม่ง่าย ❌ Scope creep — “embrace change” → no end ❌ Documentation weak — “working software > documentation” ถูกตีความเป็น “no doc” ❌ Need engaged customer — PO หรือ customer ที่ตัดสินใจไม่ได้ → ทีม block ❌ Architecture decay — sprint-by-sprint thinking → no long-term tech direction

Agile เหมาะเมื่อ#

Agile เคสที่ work#

Spotify — Agile (squad model) — เพราะ:

• Music streaming = product ที่ต้อง iterate กับ user behavior
• Tech stack ที่ flexible
• Engineer culture

Banking app — Agile front-end — เพราะ:

• UX เปลี่ยนตามความต้องการลูกค้า
• A/B testing ทุก feature

Water-Scrum-Fall pattern#

1
Waterfall: Funding + Annual planning + Compliance
2
       │
3
       ▼
4
Scrum:    Build + Iteration (sprint)
5
       │
6
       ▼
7
Waterfall: Release + Compliance audit + Operational handover

Phase 1 (Water): Strategy + budget + governance

• Annual planning (Waterfall)
• Compliance review
• Architecture approval

Phase 2 (Scrum): Build phase

• Sprint
• Daily standup
• Iteration

Phase 3 (Fall): Release + ops

• Big-bang release window (regulator approval)
• Compliance audit
• Operational handover

ทำไม Hybrid#

เพราะ part ต่างกันมี constraint ต่างกัน:

• Finance — ต้อง budget ปี ไม่ได้ “เห็นกันทุก 2 อาทิตย์”
• Legal/Compliance — ต้อง review formal
• Engineering — อยาก iterate ได้
• Operations — ต้อง release window ที่ regulator อนุมัติ

1. Phased approach (Stage-Gate + Agile)#

ใช้ใน big enterprise:

1
Phase 1: Initiation (Waterfall) — business case + approval
2
       │ Gate 1
3
       ▼
4
Phase 2: Discovery (Agile) — UX research + prototyping
5
       │ Gate 2
6
       ▼
7
Phase 3: Build (Agile) — Scrum sprints
8
       │ Gate 3
9
       ▼
10
Phase 4: Release (Waterfall) — production deployment + handover

ทุก gate ต้อง approve โดย Steering Committee

2. Dual-track Agile#

แบ่งทีมเป็น 2 track ขนานกัน:

Discovery track (UX/Product)

• Continuous research
• Prototype
• Validate ideas

Delivery track (Engineering)

• Build only validated ideas
• Sprint cadence

→ ลด wasted code (build แต่ของที่มี user demand)

3. SAFe (Hybrid by design)#

(ดู EP.10)

PI Planning ทุก 12 อาทิตย์ = pseudo-Waterfall layer Sprint ใต้นั้น = Agile layer

”Agile by name only” — Waterfall in disguise#

อาการ:

• “Sprint” ที่จริงคือ phase
• “User Story” ที่จริงคือ requirement spec
• ไม่มี real iteration — ขั้นที่ 1 ต้องเสร็จก่อนขั้นที่ 2

นี่คือ Waterfall ที่ใส่หน้ากาก — ไม่ได้ benefit ของ Agile

”Cowboy Agile” — Agile by name, chaos in reality#

อาการ:

• “เราใช้ Agile” = ไม่ plan
• ไม่มี Definition of Done
• ไม่มี acceptance criteria
• “เราตอบสนอง change” = scope ลอย

นี่คือ no methodology — ไม่ใช่ Agile

”Scaled Waterfall” — SAFe ที่ทำผิด#

อาการ:

• PI Planning = Big upfront design
• Sprint = phase
• ทุกอย่าง top-down

ทำให้ SAFe ได้แต่ overhead ไม่ได้ benefit

บริษัท startup → enterprise#

Stage 1 (10 คน): Lightweight Scrum-ish ↓ Stage 2 (50 คน): Scrum + multiple teams ↓ Stage 3 (200 คน): SAFe หรือ LeSS ↓ Stage 4 (1000+ คน): Hybrid + Portfolio Management

ทุก stage methodology ต้องเปลี่ยน — เพราะ constraint เปลี่ยน

บริษัท legacy → digital#

Stage 1: Pure Waterfall (legacy) ↓ Stage 2: Pilot Agile ในบาง team ↓ Stage 3: Hybrid (Water-Scrum-Fall) ↓ Stage 4: Agile core + Waterfall edges (compliance, infra)

ต้องเอา 5-10 ปี — ไม่ใช่เปลี่ยนได้ในไตรมาสเดียว