Bài 1: Agile - Scrum

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

1.1 Agile (Tư duy Linh hoạt)

• Khái niệm: Là một tư duy phát triển phần mềm lặp đi lặp lại (iterative) và tăng trưởng (incremental).
• Diễn giải: Thay vì cố gắng lên kế hoạch hoàn hảo 100% từ đầu rồi mất nhiều tháng để làm (thường dẫn đến sản phẩm lỗi thời khi ra mắt), Agile chia nhỏ dự án thành nhiều phần. Làm xong phần nào, đưa cho khách hàng dùng thử phần đó để lấy phản hồi và điều chỉnh ngay lập tức.
• Ví dụ thực tế: Bạn đang làm một ứng dụng Đặt xe công nghệ (giống Grab).
  • Không Agile: Cắm đầu code 1 năm cả Đặt xe máy, Ô tô, Giao hàng, Tích điểm. Ra mắt xong phát hiện khách hàng khu vực đó chỉ thích đi xe máy.
  • Agile: Trong 1 tháng đầu, bạn chỉ code đúng tính năng "Đặt xe máy" rồi tung ra thị trường. Khách hàng dùng tốt, bạn mới tiếp tục code thêm tính năng "Giao hàng".

1.2 Scrum (Khung làm việc)

• Khái niệm: Là một khung làm việc (Framework) phổ biến nhất để thực hành tư duy Agile. Nó cung cấp các quy tắc rõ ràng gồm: 3 Vai trò, 3 Tạo tác (Sản phẩm) và 5 Sự kiện.
• Diễn giải: Scrum đóng gói thời gian làm việc thành các vòng lặp ngắn hạn, liên tục (thường là 2 tuần) gọi là Sprint. Hết 1 vòng lặp, team phải có sản phẩm chạy được.
• Ví dụ thực tế: Dự án dự kiến chạy trong 6 tháng. Thay vì đợi 6 tháng mới tổng kết 1 lần, team của bạn quy định: Cứ chặng 2 tuần sẽ họp lấy yêu cầu 1 lần (Sprint Planning), mỗi buổi sáng đứng họp báo cáo 15 phút (Daily Scrum), và cuối tuần thứ 2 sẽ chạy thử code cho sếp xem (Sprint Review).

Tóm lại:
    Agile là một tư duy phát triển phần mềm, có tính linh hoạt
    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. Các Vai Trò Trong Scrum (Scrum 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.

• Ví dụ thực tế: PO (Thường là BA hoặc Giám đốc sản phẩm): Quyết định: "Tháng này chúng ta phải ra mắt tính năng Thanh toán qua Momo trước nhé".

  • Bạn (Senior Developer): Quyết định: "Để làm thanh toán Momo bảo mật, tôi sẽ dùng kiến trúc Microservices và Redis để xử lý". Không ai được cãi bạn về mặt kỹ thuật này.
  • SM: Khi bạn đang code thì Server Dev bị lỗi. Anh SM lật đật chạy đi cãi nhau với bên IT/Infra để xin cấp lại server cho bạn kịp tiến độ code.

3. Product Backlog vs. Sprint Backlog

• Khái niệm:
  • Product Backlog là nơi lưu trữ danh sách các công việc, là kho chứa tổng của cả dự án.
  • Sprint Backlog là kho chứa nhỏ dành riêng cho 1 Sprint.
• Diễn giải: Product Backlog có thể thay đổi bất cứ lúc nào, ai thêm bớt gì cũng được (dưới sự duyệt của PO). Nhưng Sprint Backlog một khi đã chốt đầu Sprint thì bị "đóng băng", tuyệt đối không được nhét thêm việc vào giữa chừng làm vỡ kế hoạch của Dev.
• Ví dụ thực tế: Sếp gửi một file Excel chứa 50 tính năng cần có của App (Đây là Product Backlog). Sáng thứ Hai họp Planning, team bạn bốc ra 5 tính năng ưu tiên nhất và nói: "Trong 2 tuần tới team chỉ tập trung làm 5 cái này thôi nhé" (Đây là Sprint Backlog). Hôm thứ Tư, sếp đòi nhét thêm tính năng số 6 vào -> Team từ chối, bảo sếp cất lại vào Product Backlog chờ 2 tuần sau tính tiếp.

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. DoR, AC và DoD (Bộ 3 kiểm soát chất lượng)

• Khái niệm:
  • DoR (Definition of Ready): Tiêu chuẩn để bắt đầu nhận task.
  • AC (Acceptance Criteria): Yêu cầu nghiệp vụ của khách hàng.
  • DoD (Definition of Done): Tiêu chuẩn kỹ thuật của team Dev.
• Diễn giải: Một task chỉ được kéo vào Sprint khi đạt DoR. Nó chỉ được coi là hoàn thành (Done) khi thỏa mãn ĐỒNG THỜI ý muốn của khách (AC) và chuẩn kỹ thuật của team (DoD).
• Ví dụ thực tế cho task "Tạo tính năng Đăng nhập":
  • Chốt DoR: PM giao task nhưng mới chỉ nói miệng. Bạn nói: "Task này chưa có bản vẽ Figma và chưa có luồng Data (Thiếu DoR), em không nhận làm tuần này đâu". PM đành phải đi bổ sung.
  • Chốt AC: Trong task ghi rõ: "Phải đăng nhập được bằng Google; Nếu nhập sai mật khẩu 3 lần phải khóa acc" (Yêu cầu của khách).
  • Chốt DoD: Bạn code xong đăng nhập Google (Đạt AC). Nhưng bạn quên viết Unit Test và chưa nhờ Senior khác Review Code (Thiếu DoD của team). Cuối cùng, task đó vẫn tính là CHƯA XONG và không được mang đi demo cho sếp.

6. 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).