Bỏ qua

Scrum

Trong thế giới rộng lớn của phát triển linh hoạt (Agile), nếu Agile là tập hợp các "giá trị" hướng dẫn chúng ta đón nhận sự thay đổi, thì Scrum chính là khung làm việc nhẹ nhàng phổ biến và được áp dụng rộng rãi nhất để hiện thực hóa các giá trị đó. Scrum không phải là một quy trình hay phương pháp chi tiết, mà là một "luật chơi" được thiết kế để giúp các nhóm làm việc hiệu quả và liên tục tạo ra giá trị khi phát triển các sản phẩm phức tạp. Nó cung cấp một nhịp điệu làm việc lặp lại đơn giản, rõ ràng nhưng mạnh mẽ cho các nhóm thông qua việc xác định rõ ràng các vai trò, sự kiện và sản phẩm công việc.

Tên gọi Scrum bắt nguồn từ hành động "scrum" trong môn bóng bầu dục (rugby), nhấn mạnh rằng toàn bộ nhóm làm việc cùng nhau như một đơn vị gắn kết, cùng hướng tới một mục tiêu chung. Scrum công nhận rằng khi đối mặt với các vấn đề phức tạp, chúng ta không thể có sẵn tất cả câu trả lời từ đầu. Do đó, cốt lõi của Scrum là chia nhỏ một vấn đề lớn, không chắc chắn thành một chuỗi các thí nghiệm nhỏ, dễ quản lý thông qua các vòng lặp có thời gian cố định (tức là "Sprint"). Sau mỗi Sprint, nhóm sẽ tạo ra một sản phẩm có thể sử dụng được và phản hồi, điều chỉnh để học hỏi từ kinh nghiệm và tiến lên phía trước giữa những thay đổi.

Ba nền tảng của khung Scrum

Toàn bộ khung Scrum được xây dựng dựa trên ba nền tảng thực nghiệm:

  1. Minh bạch (Transparency): Tất cả các yếu tố quan trọng ảnh hưởng đến kết quả phải được hiển thị rõ ràng cho tất cả những người chịu trách nhiệm về kết quả (bao gồm cả khách hàng). Điều này có nghĩa là tiến độ công việc, các trở ngại, danh sách việc cần làm (backlog), v.v., phải được công khai và minh bạch.
  2. Kiểm tra (Inspection): Các sản phẩm công việc của Scrum và tiến độ hướng tới mục tiêu phải được kiểm tra thường xuyên và kỹ lưỡng để kịp thời phát hiện các sai lệch hoặc vấn đề không mong muốn.
  3. Điều chỉnh (Adaptation): Khi việc kiểm tra xác định rằng công việc hiện tại lệch khỏi ngưỡng chấp nhận được và sản phẩm tạo ra sẽ không thể chấp nhận được, thì quá trình hoặc các yếu tố đang được xử lý phải được điều chỉnh càng sớm càng tốt.

Cấu trúc 3-5-3 của Scrum

"Luật chơi" của Scrum có thể được tóm tắt ngắn gọn thành cấu trúc "3-5-3": 3 vai trò, 5 sự kiện, 3 sản phẩm công việc.

graph TD
    subgraph Scrum Framework (3-5-3)
        subgraph 3 Roles
            A(<b>Product Owner</b><br/><i>Responsible for maximizing product value</i>)
            B(<b>Scrum Master</b><br/><i>Responsible for ensuring Scrum is properly practiced</i>)
            C(<b>Developers</b><br/><i>Responsible for delivering product increments</i>)
        end

        subgraph 5 Events
            D(<b>Sprint</b><br/><i>Core event, 1-4 week iteration cycle</i>) --> E(<b>Sprint Planning</b>);
            E --> F(<b>Daily Scrum</b>);
            F --> G(<b>Sprint Review</b>);
            G --> H(<b>Sprint Retrospective</b>);
        end

        subgraph 3 Artifacts
            I(<b>Product Backlog</b><br/><i>Overall requirements list</i>)
            J(<b>Sprint Backlog</b><br/><i>Task list for current sprint</i>)
            K(<b>Increment</b><br/><i>Usable product portion completed in current sprint</i>)
        end
    end

3 Vai trò

  • Product Owner: Người duy nhất chịu trách nhiệm về "giá trị" của sản phẩm. Công việc chính của họ là quản lý và tối ưu hóa Product Backlog, đảm bảo nhóm phát triển luôn làm những việc tạo ra giá trị cao nhất cho khách hàng và doanh nghiệp. Họ quyết định "việc gì nên làm."
  • Scrum Master: Là "người lãnh đạo phục vụ" và "huấn luyện viên" của khung Scrum. Họ không quản lý nhóm mà phục vụ nhóm, chịu trách nhiệm loại bỏ các trở ngại, điều phối các sự kiện và đảm bảo các quy tắc và giá trị của Scrum được nhóm hiểu và thực hiện đúng.
  • Developers: Một nhóm chuyên nghiệp, đa chức năng và tự tổ chức, cùng nhau chịu trách nhiệm chuyển đổi các mục trong danh sách việc cần làm thành một sản phẩm hoàn chỉnh, chất lượng cao trong từng Sprint. Họ quyết định "làm thế nào."

5 Sự kiện

  • Sprint: Trái tim của Scrum, là một khoảng thời gian cố định (thường là 1-4 tuần). Trong một Sprint, nhóm tập trung vào đạt được một mục tiêu Sprint có giá trị.
  • Sprint Planning: Diễn ra vào đầu mỗi Sprint. Product Owner trình bày các mục ưu tiên cao nhất từ Product Backlog cho nhóm phát triển. Nhóm cùng nhau chọn và cam kết với những việc họ có thể hoàn thành trong Sprint và lập kế hoạch sơ bộ, tạo thành Sprint Backlog.
  • Daily Scrum: Cuộc họp đồng bộ hóa hàng ngày không quá 15 phút. Mỗi thành viên trong nhóm phát triển lần lượt trả lời ba câu hỏi: "Tôi đã làm gì hôm qua?" "Tôi sẽ làm gì hôm nay?" "Tôi gặp trở ngại gì?" Mục đích là để đồng bộ tiến độ và xác định trở ngại nhanh chóng, không phải để báo cáo với quản lý.
  • Sprint Review: Diễn ra vào cuối Sprint. Nhóm phát triển trình diễn sản phẩm hoàn chỉnh, đang hoạt động (Increment) cho Product Owner, khách hàng và các bên liên quan, đồng thời thu thập phản hồi. Đây là một cuộc họp không chính thức về "sản phẩm."
  • Sprint Retrospective: Diễn ra sau Sprint Review và trước khi Sprint mới bắt đầu. Nhóm Scrum (PO, SM, Devs) cùng nhau phản tư về những việc đã làm tốt và những điểm cần cải thiện liên quan đến con người, mối quan hệ, quy trình và công cụ trong Sprint vừa qua, đồng thời lập kế hoạch cải tiến cụ thể cho Sprint tiếp theo.

3 Sản phẩm công việc (Artifacts)

  • Product Backlog: Danh sách động, có thứ tự ưu tiên và toàn diện của tất cả các yêu cầu, tính năng, sửa lỗi và cải tiến sản phẩm đã biết. Nó chỉ được quản lý bởi Product Owner.
  • Sprint Backlog: Danh sách các công việc mà nhóm phát triển cam kết hoàn thành trong Sprint hiện tại, cùng với kế hoạch để đạt được "Sprint Goal". Nó thuộc quyền sở hữu và quản lý duy nhất của nhóm phát triển.
  • Increment: Tổng hợp tất cả các mục Product Backlog đã hoàn thành vào cuối mỗi Sprint. Nó phải có thể sử dụng được và phù hợp với "Định nghĩa Hoàn thành (Definition of Done)." Đây là minh chứng trực tiếp cho kết quả làm việc của nhóm.

Các trường hợp áp dụng

Trường hợp 1: Phát triển ứng dụng đặt đồ ăn trực tuyến

  • Product Backlog: Chứa hàng trăm câu chuyện người dùng như "đăng ký người dùng," "xem thực đơn," "thanh toán trực tuyến," "theo dõi đơn hàng," v.v.
  • Sprint 1 (2 tuần):
    • Sprint Goal: "Người dùng có thể đăng ký và đăng nhập thành công."
    • Sprint Backlog: Nhóm chọn 5 câu chuyện người dùng liên quan đến đăng ký và đăng nhập.
    • Daily Scrum: Nhóm đồng bộ tiến độ hàng ngày và phát hiện "giao diện gửi mã xác thực SMS không ổn định" là một trở ngại. Scrum Master lập tức phối hợp để giải quyết.
    • Sprint Review: Nhóm trình diễn quy trình đăng ký và đăng nhập hoàn chỉnh, đang hoạt động.
    • Sprint Retrospective: Nhóm phản tư rằng ước lượng công việc của họ quá lạc quan và quyết định áp dụng phương pháp ước lượng thận trọng hơn trong Sprint tới.

Trường hợp 2: Nhóm tiếp thị lên kế hoạch sự kiện ra mắt sản phẩm

  • Scrum không chỉ áp dụng cho phát triển phần mềm.
  • Product Owner: Giám đốc tiếp thị.
  • Product Backlog: Chứa tất cả các công việc như "xác định chủ đề sự kiện ra mắt," "thiết kế hình ảnh chính," "mời báo chí và KOLs," "viết thông cáo báo chí," "đặt địa điểm tổ chức," v.v.
  • Sprint 1 (1 tuần):
    • Sprint Goal: "Hoàn tất chủ đề cốt lõi và thiết kế hình ảnh chính ban đầu cho sự kiện ra mắt."
    • Nhóm nhanh chóng tạo ra kết quả thông qua một Sprint kéo dài một tuần và trình bày tại buổi họp đánh giá, nhận được phản hồi kịp thời và tránh đầu tư quá nhiều nguồn lực thiết kế vào hướng sai.

Trường hợp 3: Nhóm sinh viên thực hiện đồ án học kỳ

  • Product Owner: Một sinh viên đóng vai trò PO, chịu trách nhiệm liên lạc với giáo sư và làm rõ yêu cầu dự án.
  • Product Backlog: Toàn bộ dự án được chia nhỏ thành các phần như "tổng quan tài liệu," "thu thập dữ liệu," "phân tích dữ liệu," "viết báo cáo," "tạo slide thuyết trình."
  • Sprints: Họ chia 8 tuần còn lại của học kỳ thành 4 Sprint kéo dài 2 tuần. Mỗi Sprint có mục tiêu rõ ràng, ví dụ mục tiêu của Sprint đầu tiên là "hoàn tất tổng quan tài liệu và thiết kế nghiên cứu." Cách tiếp cận này giúp họ tránh được việc ôn tập gấp gáp vào cuối học kỳ.

Ưu điểm và Thách thức của Scrum

Ưu điểm cốt lõi

  • Tăng năng suất và tốc độ: Thông qua các vòng lặp ngắn và tập trung, nhóm có thể tạo ra giá trị nhanh hơn.
  • Tăng tính linh hoạt và thích nghi: Có thể bình tĩnh đối mặt với các yêu cầu thay đổi và điều chỉnh hướng đi kịp thời dựa trên phản hồi.
  • Cải thiện tính minh bạch và giao tiếp: Các vai trò, sự kiện và sản phẩm công việc rõ ràng giúp rất nhiều trong việc giao tiếp và đồng bộ thông tin trong và ngoài nhóm.
  • Trao quyền cho nhóm, nâng cao tinh thần: Nhóm phát triển tự tổ chức có mức độ tự chủ cao hơn và cảm giác làm chủ mạnh mẽ hơn.

Thách thức tiềm ẩn

  • "Dễ hiểu, khó làm": Quy tắc Scrum đơn giản, nhưng thật sự hiểu được tinh thần Agile và áp dụng thành công trong văn hóa tổ chức cụ thể là rất khó.
  • Yêu cầu cao đối với Product Owner: Product Owner cần hiểu sâu về kinh doanh, thị trường và khách hàng, đồng thời có kỹ năng giao tiếp và ra quyết định xuất sắc.
  • Khả năng "phạm vi công việc lan rộng (Scope Creep)": Nếu Product Owner không quản lý tốt backlog và kỳ vọng của các bên liên quan, điều này có thể dẫn đến thay đổi thường xuyên về mục tiêu Sprint.
  • Yêu cầu cao về độ trưởng thành của nhóm: Nhóm tự tổ chức đòi hỏi các thành viên phải có tinh thần trách nhiệm cao, tinh thần hợp tác và kỹ năng đa chức năng.

Mở rộng và Liên kết

  • Phát triển linh hoạt (Agile Development): Scrum là một khung làm việc cụ thể và phổ biến để hiện thực hóa các giá trị và nguyên tắc của Agile.
  • Kanban: Một phương pháp Agile phổ biến khác. Không giống như nhịp điệu của Scrum dựa trên "thời gian cố định (Sprint)", Kanban tập trung nhiều hơn vào "dòng chảy liên tục". Trong thực tế, nhiều nhóm kết hợp cả hai phương pháp; ví dụ, sử dụng Kanban bên trong một Sprint của Scrum để trực quan hóa và quản lý dòng chảy công việc, cách tiếp cận này được gọi là "Scrumban".
  • Lập trình cực hạn (Extreme Programming - XP): Scrum cung cấp "khung quản lý", trong khi XP cung cấp một tập hợp các "thực hành kỹ thuật" tuyệt vời. Việc tích hợp các thực hành XP (như Phát triển dựa trên kiểm thử (Test-Driven Development), Lập trình đôi (Pair Programming)) vào khung Scrum có thể cải thiện đáng kể chất lượng kỹ thuật của các sản phẩm hoàn thành.

Tham khảo: Khung Scrum lần đầu tiên được Jeff Sutherland và Ken Schwaber cùng đề xuất vào đầu những năm 1990. Tác phẩm chung của họ, "The Scrum Guide," là định nghĩa chính thức duy nhất về khung Scrum và được cập nhật định kỳ để phản ánh sự phát triển trong thực tiễn.