LeadershipTechnical ManagerExecution and Process

Session 01: Agile Scrum – Nền Tảng Thực Chiến

"Scrum đơn giản để hiểu, nhưng cực khó để làm đúng." - Ken Schwaber


1️⃣ Agile Manifesto – Bản Chất Thật Sự

Agile không phải một quy trình, nó là tư duy. 4 giá trị cốt lõi:

Ưu tiên hơnHơn là
Individuals & interactionsProcesses & tools
Working softwareComprehensive documentation
Customer collaborationContract negotiation
Responding to changeFollowing a plan

⚠️ Sai lầm phổ biến: Nhiều team nghĩ Agile = "không cần tài liệu". Sai. Agile nói: tài liệu vừa đủ, không phải không có. Một API contract spec vẫn cần thiết, nhưng một bản Word 200 trang mô tả hệ thống chưa build thì không.


2️⃣ Ba Trụ Cột Scrum (Three Pillars)

┌─────────────────────────────────────────────┐
│               SCRUM FRAMEWORK               │
│                                             │
│   🔍 Transparency   🔄 Inspection           │
│                 🔧 Adaptation               │
│                                             │
│   "Nhìn thấy → Kiểm tra → Điều chỉnh"     │
└─────────────────────────────────────────────┘
  1. Transparency (Minh bạch): Mọi người cùng nhìn thấy tiến độ thật. Sprint Backlog không phải thứ chỉ Scrum Master nhìn.
  2. Inspection (Kiểm tra): Trong mỗi Daily Standup, Sprint Review, bạn đang "kiểm tra" sản phẩm và quy trình.
  3. Adaptation (Thích nghi): Nếu kiểm tra thấy sai, đổi ngay. Retro là nơi để thực hiện điều này.

3️⃣ Scrum Roles – Ai Làm Gì?

Product Owner (PO)

  • Một người duy nhất chịu trách nhiệm tối đa hoá giá trị sản phẩm.
  • Sở hữu và sắp xếp Product Backlog theo ROI & Business Value.
  • PO không phải người viết ticket, PO là người quyết định cái gì KHÔNG làm.

Scrum Master (SM)

  • Servant-leader: phục vụ team, loại bỏ impediments.
  • Không phải Project Manager. SM không giao việc, không quản lý timeline.
  • Bảo vệ team khỏi bị kéo ra ngoài Sprint Goal bởi stakeholders.

Development Team

  • Cross-functional (5–9 người, lý tưởng là 7±2).
  • Tự tổ chức: team tự quyết định "làm cái gì trong Sprint" và "làm như thế nào".
  • Không có sub-team, không có title BA/QA/Dev riêng biệt (trong lý thuyết Scrum thuần).

4️⃣ Scrum Events (Ceremonies)

Sprint (Time-box: 1–4 tuần, khuyến khích 2 tuần)

Sprint là "nhịp tim" của Scrum.

Sprint Planning (Time-box: tối đa 8 giờ cho Sprint 1 tháng)

  1. WHAT: PO trình bày Sprint Goal + các PBI ưu tiên cao nhất.
  2. HOW: Dev Team phân tách PBI thành Tasks, estimate effort.
  3. Đầu ra: Sprint Backlog (danh sách việc cam kết hoàn thành trong Sprint).

Daily Standup (Time-box: 15 phút, đứng)

Mỗi người trả lời 3 câu:

  1. Hôm qua tôi đã làm gì giúp đạt Sprint Goal?
  2. Hôm nay tôi sẽ làm gì?
  3. Có gì blocking tôi không?

💡 Anti-pattern: Daily biến thành báo cáo cho Scrum Master/Manager. Sai. Daily là để team đồng bộ với nhau.

Sprint Review (Time-box: 4 giờ cho Sprint 1 tháng)

  • Demo working software cho Stakeholders.
  • Thu thập feedback → cập nhật Product Backlog.
  • Không phải buổi trình chiếu slide tóm tắt công việc.

Sprint Retrospective (Time-box: 3 giờ cho Sprint 1 tháng)

Câu hỏi vàng:

  1. Cái gì đã tốt? (Keep doing)
  2. Cái gì cần cải thiện? (Stop doing / Start doing)
  3. Action items cụ thể cho Sprint tiếp theo.

5️⃣ Scrum Artifacts

Product Backlog

  • Danh sách sống (living document), được sắp xếp theo ưu tiên.
  • Item trên cùng luôn được refine rõ ràng nhất (Definition of Ready).
  • PO là owner duy nhất.

Sprint Backlog

  • Tập con của Product Backlog, được team cam kết hoàn thành trong Sprint.
  • Team có quyền thêm/bỏ task (nhưng không đổi Sprint Goal).

Increment

  • Tổng hợp tất cả PBI hoàn thành trong Sprint + các Sprint trước.
  • Phải đạt Definition of Done (DoD): code review ✅, unit test ✅, deploy staging ✅, PO accepted ✅.

6️⃣ Definition of Ready (DoR) vs Definition of Done (DoD)

DoR (Trước khi vào Sprint)DoD (Trước khi gọi là "Done")
Mục đíchĐảm bảo PBI đủ rõ để dev bắt tay làmĐảm bảo Increment đạt chất lượng release
Ví dụAcceptance Criteria rõ ràng, UI mockup có, API spec readyCode reviewed, 80%+ test coverage, deployed staging, PO sign-off

⚠️ Bàn luận thực chiến: Nhiều team bỏ qua DoR, dẫn tới giữa Sprint mới phát hiện "chưa có design" hoặc "chưa rõ yêu cầu" → Sprint bị phá sản. DoR là tấm khiên bảo vệ Development Team.


Session tiếp theo: Session 02 – Story Point Estimation đi sâu vào cách ước lượng chính xác nhất với Fibonacci và kỹ thuật Planning Poker.