Bài 1: Agile - Scrum

1. Phân biệt rõ: Agile và Scrum là gì?

• Nhiều người hay gọi gộp "Agile/Scrum", nhưng thực chất chúng là hai khái niệm ở hai tầng khác nhau:
  • Agile là tư duy (mindset) và triết lý quản lý dự án
  • Scrum là một KHUNG LÀM VIỆC (Framework): Nó là cách thức cụ thể để thực hiện tư duy Agile.
  • Ví dụ: Agile là "Sống khỏe mạnh" và để "SSống khỏe mạnh", bạn chọn phương pháp (Scrum) là "Tập Gym 3 buổi/tuần kết hợp ăn Eat Clean"

Tóm lại:
    Agile là bộ nguyên tắc
    còn Scrum là cách cụ thể để thực hiện các nguyên tắc đó.
    Bạn có thể thực hiện tư duy Agile bằng cách áp dụng cách làm việc Scrum.

2. Vai trò (Roles)

• Product Owner (PO - Người sở hữu sản phẩm): Là người định nghĩa What (Chúng ta sẽ làm cái gì?). PO nắm giữ Product Backlog, tối ưu hóa giá trị kinh doanh và là tiếng nói của khách hàng.
• Scrum Master (SM): Là người định nghĩa Process (Chúng ta làm việc cùng nhau như thế nào?). SM không phải là sếp của bạn! PMP gọi đây là Servant Leader (Lãnh đạo phục vụ) – người đi dọn dẹp các chướng ngại vật (impediments) để team yên tâm code, và đảm bảo mọi người hiểu đúng luật Scrum.
• Developers (Nhóm phát triển): Nắm giữ chữ How (Làm điều đó như thế nào?). Trong PMP, nhóm này phải là Self-organizing (Tự quản). Nghĩa là, khi PO đưa ra yêu cầu, team sẽ tự quyết định giải pháp kỹ thuật (architecture, database design) và tự phân công task cho nhau, không cần ai chỉ tay năm ngón.

3. Artifacts - Sản phẩm đầu ra

• Product Backlog: Danh sách tất cả các tính năng cần có của sản phẩm. Nó không bao giờ hoàn thiện mà luôn được cập nhật.
• Sprint Backlog: Danh sách các task team cam kết sẽ hoàn thành trong 1 Sprint ngắn (thường là 2 tuần). Một khi Sprint bắt đầu, tuyệt đối không ai (kể cả sếp lớn) được phép nhét thêm việc vào đây làm phá vỡ cam kết của team.
• Increment (Phần tăng trưởng): Đây là quan trọng nhất! Cuối Sprint, bạn phải giao ra được một đoạn code/tính năng có thể chạy được và sẵn sàng đưa lên production (Done), chứ không phải là những dòng code đang viết dở.

4. Sự kiện (Events)

• The Sprint: Vòng lặp thời gian cốt lõi (thường 2-4 tuần). Nó bao trùm 4 sự kiện bên dưới (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective)
  • Sprint Planning (Họp lập kế hoạch): Cả team ngồi lại xem Sprint này làm gì và làm như thế nào. Bạn (Senior SWE) sẽ tham gia estimate (ước lượng) độ khó của task ở bước này.
  • Daily Scrum (Họp hằng ngày): 15 phút đứng họp. PMP nhấn mạnh: Đây không phải là buổi báo cáo tiến độ cho sếp, mà là buổi đồng bộ thông tin của team dev để xem có ai đang bị block (kẹt) ở đâu không.
  • Sprint Retrospective (Cải tiến Sprint - Rất quan trọng trong PMP): Buổi họp nội bộ team để xem Sprint vừa rồi cái gì làm tốt, cái gì dở, và tìm ra ít nhất 1 hành động cải tiến cho Sprint sau. (PMP gọi đây là quá trình Continuous Improvement - Cải tiến liên tục).

5. Ví dụ thực tế

• Thay vì chỉ nói lý thuyết suông, chúng ta hãy cùng "chạy thử" một Sprint kéo dài 2 tuần chuẩn Scrum.
• Hãy tưởng tượng bạn đang làm trong một dự án E-commerce (Thương mại điện tử). Đội ngũ (Scrum Team) gồm có: 1 Product Owner (PO), 1 Scrum Master (SM), và Nhóm Dev (gồm bạn là Senior Backend, 1 bạn Frontend, 1 bạn QA). Không có khái niệm "Project Leader chia việc" ở đây.
  • Dưới đây là nhật ký công việc của bạn:
    • Ngày 1: Sprint Planning (Lập kế hoạch Sprint)
      • Không phải là: Nhận một file Excel ghi rõ "Em code API A mất 2 ngày nhé".
      • Thực tế chuẩn Scrum:
        • PO đưa ra một yêu cầu (User Story) quan trọng nhất: "Là người dùng muốn nhập được Mã giảm giá ở giỏ hàng để được giảm tiền".
        • Bạn (Senior SWE) lên tiếng: "Tính năng này dính đến tính toán tiền nong và chịu tải cao lúc săn sale. Em đề xuất dùng Redis để cache và check limit mã giảm giá".
        • Cả team thảo luận giải pháp kỹ thuật. Sau đó, team dùng bài Planning Poker để ước lượng (Estimate). Cả team thống nhất task này có độ khó là 5 Story Points.
        • Team tự tin "nhận" (Pull) task này vào Sprint Backlog và cam kết sẽ làm xong trong 2 tuần.
    • Ngày 2 - 13: Trong chặng nước rút (Development & Daily Scrum)
      • Không phải là: PL nhắn tin hỏi "Task mã giảm giá đến đâu rồi em?".
      • Thực tế chuẩn Scrum:
        • Chủ động nhận việc: Sáng ra, bạn mở Jira, tự kéo task "Viết API Check Mã Giảm Giá" từ cột To Do sang In Progress.
        • Daily Scrum (15 phút đứng họp): Bạn không báo cáo cho sếp. Bạn nói với đồng đội: "Hôm qua anh đã dựng xong Database cho Mã giảm giá. Hôm nay anh sẽ code API check logic. Frontend ơi, chiều nay API lên môi trường Dev nhé, anh em mình ghép nối thử luôn. QA có cần anh support tạo data test không?".
        • Khi có rủi ro: Giữa Sprint, server dev bị sập. Thay vì bạn cắm đầu tự sửa hoặc chờ PL đi cứu, Scrum Master sẽ là người đứng ra làm việc với team DevOps/Infra để khôi phục server, giúp bạn tập trung hoàn toàn vào việc code.
    • Chạm mốc Definition of Done (Hoàn thành thực sự)
      • Bạn code xong API. Nhưng task chưa được kéo sang cột Done.
      • Bạn tự viết Unit Test (Coverage > 80%).
      • Bạn tạo Pull Request (PR) và nhờ bạn Senior khác review code.
      • Sau khi code được merge, CI/CD tự động deploy lên môi trường Staging. Bạn QA test pass.
      • Lúc này, task mới chính thức được kéo sang DONE. (Chỉ có 0% hoặc 100%, không có 90%).
    • Ngày 14 (Sáng): Sprint Review (Sơ kết - Demo sản phẩm)
      • Không phải là: Gửi báo cáo tiến độ bằng file Word.
      • Thực tế chuẩn Scrum: Cả team mời team Marketing (Khách hàng nội bộ) vào họp. Bạn hoặc PO mở màn hình, trực tiếp thao tác nhập thử một mã "GIAM50K" trên giao diện thật để mọi người thấy tiền giỏ hàng thực sự giảm xuống. Phần mềm chạy "ngon lành" trước mắt khách hàng.
    • Ngày 14 (Chiều): Sprint Retrospective (Họp Cải tiến)
      • Buổi này đóng cửa nội bộ, chỉ có team Dev, SM và PO.
      • Bạn lên tiếng: "Sprint vừa rồi khâu Code Review hơi chậm do mọi người bận, khiến QA bị dồn việc vào cuối Sprint".
      • Team thống nhất quy tắc mới: "Bất cứ khi nào có Pull Request mới, trong vòng 4 tiếng phải có người review". (Đây chính là quá trình Cải tiến liên tục - Continuous Improvement).