Phương pháp Scrum được triển khai qua những vai trò và sự kiện nào?

Một Scrum Team gồm ba nhóm trách nhiệm: Product Owner, Scrum Master và Developers. Các trách nhiệm này vận hành trong năm sự kiện gồm Sprint, Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective. Công việc được minh bạch hóa qua Product Backlog, Sprint Backlog và Increment. Khi các thành phần này liên kết đúng cách, mỗi Sprint trở thành một vòng lặp quản lý hoàn chỉnh: xác định mục tiêu, lựa chọn công việc, thực hiện, kiểm tra kết quả và cải tiến cách làm.

Phương pháp Scrum là gì?

Phương pháp Scrum dựa trên chủ nghĩa kinh nghiệm và tư duy tinh gọn. Chủ nghĩa kinh nghiệm cho rằng kiến thức hình thành từ trải nghiệm và các quyết định nên dựa trên những gì có thể quan sát được. Tư duy tinh gọn hướng đến giảm lãng phí và tập trung vào những yếu tố thiết yếu. Vì vậy, Scrum không cố dự đoán chính xác mọi diễn biến từ đầu mà tạo ra các vòng phản hồi ngắn để nhóm liên tục học hỏi.

Cơ chế vận hành của Scrum dựa trên ba trụ cột:

·         Minh bạch: Công việc, tiến độ, tiêu chuẩn chất lượng và các vấn đề phải đủ rõ để những người liên quan cùng hiểu trạng thái thực tế

·         Kiểm tra: Nhóm thường xuyên xem xét sản phẩm, kế hoạch và mức độ tiến gần tới mục tiêu

·         Thích nghi: Khi phát hiện sai lệch hoặc xuất hiện thông tin mới, nhóm điều chỉnh công việc càng sớm càng tốt

Ba trụ cột này được hiện thực hóa qua các sự kiện Scrum. Nếu nhóm chỉ tổ chức họp nhưng không công khai tình trạng công việc, không kiểm tra kết quả hoặc không thay đổi sau khi phát hiện vấn đề, nhóm mới đang thực hiện hình thức của Scrum chứ chưa vận hành đúng cơ chế của framework.

Scrum cũng được định hướng bởi năm giá trị: cam kết, tập trung, cởi mở, tôn trọng và can đảm. Các giá trị này tạo nền tảng hành vi để thành viên chia sẻ vấn đề trung thực, tập trung vào Sprint Goal và chịu trách nhiệm đối với kết quả chung.

Ba vai trò trong Scrum Team chịu trách nhiệm như thế nào?

Scrum Guide 2020 sử dụng thuật ngữ “accountabilities”, nhấn mạnh trách nhiệm đối với kết quả thay vì chức danh hành chính. Trong giao tiếp thông thường, Product Owner, Scrum Master và Developers vẫn thường được gọi là ba vai trò của Scrum.

Scrum Team là một đơn vị thống nhất, không có nhóm con hoặc hệ thống cấp bậc nội bộ theo thiết kế của Scrum. Nhóm có tính liên chức năng, nghĩa là tập hợp đủ kỹ năng cần thiết để tạo ra giá trị trong mỗi Sprint, đồng thời có khả năng tự quản lý việc ai làm gì, khi nào và bằng cách nào. Scrum Guide cho biết Scrum Team thường có không quá 10 người để duy trì khả năng phối hợp linh hoạt.

Product Owner định hướng giá trị và sắp xếp ưu tiên

Product Owner chịu trách nhiệm tối đa hóa giá trị tạo ra từ công việc của Scrum Team. Trách nhiệm này được thể hiện qua việc xác lập Product Goal và quản lý Product Backlog hiệu quả.

Các nhiệm vụ trọng tâm của Product Owner gồm:

·         Phát triển và truyền đạt rõ Product Goal

·         Xây dựng và diễn giải các Product Backlog Item

·         Sắp xếp thứ tự ưu tiên trong Product Backlog

·         Bảo đảm Product Backlog minh bạch, dễ tiếp cận và được nhóm hiểu đúng

Product Owner có thể nhờ người khác hỗ trợ một số hoạt động, nhưng vẫn là người chịu trách nhiệm cuối cùng. Đây là một cá nhân, không phải hội đồng. Cơ chế này giúp nhóm có một đầu mối rõ ràng khi phải lựa chọn giữa nhiều nhu cầu cạnh tranh.

Trong thực tế, Product Owner không nên phân công chi tiết từng nhiệm vụ cho Developers. Vai trò này xác định vấn đề nào đáng giải quyết và kết quả nào tạo ra giá trị; Developers quyết định cách biến mục tiêu đó thành Increment.

Developers tạo ra Increment sử dụng được

Developers là những thành viên trực tiếp tạo ra các khía cạnh cần thiết của một Increment có thể sử dụng trong mỗi Sprint. Tùy lĩnh vực, nhóm này có thể gồm lập trình viên, nhà thiết kế, kiểm thử viên, chuyên gia dữ liệu, chuyên viên nội dung hoặc các chuyên môn khác. Từ “Developers” trong Scrum không chỉ giới hạn ở phát triển phần mềm.

Developers chịu trách nhiệm:

·         Lập kế hoạch Sprint dưới dạng Sprint Backlog

·         Duy trì chất lượng bằng cách tuân thủ Definition of Done

·         Điều chỉnh kế hoạch hằng ngày để tiến tới Sprint Goal

·         Chịu trách nhiệm nghề nghiệp với nhau về công việc chung

Developers không chỉ nhận đầu việc rồi thực hiện riêng lẻ. Họ phải cùng quản lý kế hoạch, trao đổi các phụ thuộc và bảo đảm tổng thể Increment đạt tiêu chuẩn hoàn thành. Việc một cá nhân hoàn tất phần việc của mình chưa đủ nếu Increment chung chưa sử dụng được.

Scrum Master xây dựng môi trường vận hành Scrum

Scrum Master chịu trách nhiệm thiết lập Scrum theo định nghĩa của Scrum Guide và nâng cao hiệu quả của Scrum Team. Scrum Master thực hiện điều này bằng cách giúp mọi người hiểu lý thuyết, quy tắc và thực hành Scrum, đồng thời hỗ trợ nhóm cải thiện cách làm việc trong khuôn khổ Scrum.

Scrum Master hỗ trợ Scrum Team bằng cách:

·         Huấn luyện thành viên về tự quản lý và làm việc liên chức năng

·         Giúp nhóm tập trung tạo ra Increment có giá trị và đạt Definition of Done

·         Thúc đẩy việc loại bỏ các trở ngại cản trở tiến độ

·         Bảo đảm các sự kiện Scrum diễn ra tích cực, hiệu quả và đúng timebox

Scrum Master không phải thư ký cuộc họp, người giao việc hay quản lý trực tiếp của Developers. Một Scrum Master có thể điều phối khi cần, nhưng mục tiêu dài hạn là giúp nhóm đủ năng lực tự điều hành các hoạt động kiểm tra và thích nghi.

Sprint tạo ra chu kỳ quản lý công việc như thế nào?

Sprint là sự kiện bao chứa tất cả các sự kiện Scrum còn lại và được xem là nhịp tim của Scrum. Mỗi Sprint có độ dài cố định không quá một tháng. Sprint mới bắt đầu ngay sau khi Sprint trước kết thúc, nhờ đó nhóm duy trì một nhịp làm việc và phản hồi đều đặn.

Trong một Sprint, nhóm thực hiện toàn bộ công việc cần thiết để tiến tới Product Goal, bao gồm Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective. Mỗi Sprint có thể được xem như một dự án ngắn nhưng không tách rời khỏi định hướng dài hạn của sản phẩm.

Trong suốt Sprint:

·         Không thực hiện thay đổi làm nguy hại Sprint Goal

·         Chất lượng không được giảm xuống

·         Product Backlog tiếp tục được làm rõ khi cần

·         Phạm vi có thể được thương lượng lại với Product Owner khi nhóm học được điều mới

Điểm quan trọng là Scrum không cấm thay đổi. Framework chỉ bảo vệ Sprint Goal để nhóm duy trì sự tập trung. Khi cách thực hiện hoặc khối lượng công việc cần thay đổi, Developers và Product Owner có thể điều chỉnh phạm vi Sprint Backlog mà không phá vỡ mục tiêu chung.

Sprint ngắn tạo ra nhiều vòng học hỏi hơn và giới hạn rủi ro chi phí, công sức trong một khoảng thời gian nhỏ hơn. Ngược lại, Sprint quá dài có thể làm mục tiêu mất tính phù hợp, gia tăng độ phức tạp và trì hoãn phản hồi.

Năm sự kiện Scrum được triển khai theo trình tự nào?

Mỗi sự kiện Scrum là một cơ hội chính thức để kiểm tra và thích nghi. Các sự kiện tạo ra nhịp vận hành ổn định, đồng thời giảm nhu cầu tổ chức nhiều cuộc họp bổ sung không có mục đích rõ ràng.

Sprint Planning xác định tại sao, làm gì và làm như thế nào

Sprint Planning khởi động Sprint bằng việc xây dựng kế hoạch thực hiện. Kế hoạch này là kết quả hợp tác của toàn bộ Scrum Team, không phải kế hoạch do một người lập rồi giao xuống.

Sprint Planning giải quyết ba chủ đề:

1.    Tại sao Sprint này có giá trị?

2.    Product Owner đề xuất giá trị mà Sprint có thể tạo ra. Cả Scrum Team phối hợp xây dựng Sprint Goal

3.    Có thể hoàn thành những gì trong Sprint?

4.    Developers trao đổi với Product Owner và lựa chọn các Product Backlog Item phù hợp với năng lực, kinh nghiệm trước đây và Definition of Done

5.    Công việc đã chọn sẽ được thực hiện như thế nào?

6.    Developers lập kế hoạch tạo ra Increment đạt Definition of Done, thường bằng cách chia các Product Backlog Item thành các hạng mục nhỏ có thể quản lý

Kết quả của Sprint Planning là Sprint Backlog, gồm Sprint Goal, các Product Backlog Item được chọn và kế hoạch hành động để tạo Increment. Với Sprint kéo dài một tháng, Sprint Planning có timebox tối đa tám giờ; Sprint ngắn hơn thường có thời lượng lập kế hoạch ngắn hơn.

Một sai lầm phổ biến là biến Sprint Planning thành buổi phân công chi tiết. Cách làm đúng là cả nhóm thống nhất mục tiêu và phạm vi dự kiến, còn Developers chủ động quyết định cấu trúc công việc cần thiết.

Daily Scrum kiểm tra tiến độ hướng tới Sprint Goal

Daily Scrum là sự kiện 15 phút dành cho Developers, được tổ chức mỗi ngày làm việc trong Sprint. Mục đích của sự kiện là kiểm tra tiến độ hướng tới Sprint Goal và điều chỉnh Sprint Backlog hoặc kế hoạch sắp tới.

Developers có thể chọn cấu trúc Daily Scrum phù hợp, miễn là cuộc trao đổi tập trung vào Sprint Goal và tạo ra kế hoạch hành động cho ngày tiếp theo. Scrum không bắt buộc từng người phải lần lượt trả lời ba câu hỏi cố định.

Daily Scrum không phải buổi báo cáo cho Scrum Master hoặc Product Owner. Nếu thành viên chỉ kể những gì mình đã làm mà không xem xét khả năng đạt Sprint Goal, cuộc họp chưa hoàn thành đúng chức năng.

Nhóm cũng không phải chờ đến Daily Scrum mới được điều chỉnh kế hoạch. Developers có thể trao đổi nhiều lần trong ngày khi cần giải quyết vấn đề hoặc phối hợp công việc chi tiết.

Sprint Review kiểm tra kết quả và điều chỉnh hướng sản phẩm

Sprint Review diễn ra gần cuối Sprint để kiểm tra kết quả và xác định những thích nghi tiếp theo. Scrum Team trình bày kết quả cho các bên liên quan chủ chốt, cùng đánh giá tiến độ hướng tới Product Goal và thảo luận những thay đổi trong môi trường.

Sprint Review là một phiên làm việc, không chỉ là buổi trình diễn sản phẩm. Trọng tâm không phải chứng minh nhóm đã hoàn thành bao nhiêu nhiệm vụ mà là trả lời các câu hỏi:

·         Increment hiện tại tạo ra giá trị gì

·         Phản hồi từ người dùng và bên liên quan cho thấy điều gì

·         Bối cảnh thị trường, nghiệp vụ hoặc kỹ thuật đã thay đổi ra sao

·         Product Backlog cần điều chỉnh như thế nào

Với Sprint một tháng, Sprint Review có timebox tối đa bốn giờ; Sprint ngắn hơn thường có thời lượng ngắn hơn.

Sprint Retrospective cải tiến cách làm việc

Sprint Retrospective kết thúc Sprint và tập trung vào việc nâng cao chất lượng cùng hiệu quả của Scrum Team. Nhóm xem xét con người, tương tác, quy trình, công cụ và Definition of Done trong Sprint vừa qua.

Nhóm cần xác định:

·         Điều gì đã diễn ra tốt

·         Vấn đề nào đã xuất hiện

·         Vấn đề đã hoặc chưa được giải quyết như thế nào

·         Giả định nào dẫn đến quyết định sai

·         Thay đổi nào có tác động lớn nhất đối với hiệu quả

Các cải tiến quan trọng nên được triển khai càng sớm càng tốt và có thể được đưa vào Sprint Backlog của Sprint kế tiếp. Với Sprint một tháng, Sprint Retrospective có timebox tối đa ba giờ.

Sprint Review và Sprint Retrospective không thay thế cho nhau. Sprint Review tập trung vào sản phẩm và định hướng giá trị; Sprint Retrospective tập trung vào hệ thống làm việc của Scrum Team.

Ba tạo tác kết nối mục tiêu với công việc ra sao?

Các tạo tác Scrum đại diện cho công việc hoặc giá trị và được thiết kế để tối đa hóa tính minh bạch. Mỗi tạo tác gắn với một cam kết giúp nhóm có cơ sở đo lường tiến độ và đưa ra quyết định thích nghi.

Product Backlog gắn với Product Goal

Product Backlog là danh sách có thứ tự, liên tục phát triển về những gì cần thực hiện để cải thiện sản phẩm. Đây là nguồn công việc duy nhất của Scrum Team.

Product Goal mô tả trạng thái tương lai mà Scrum Team hướng đến. Mục tiêu này giúp Product Owner sắp xếp Product Backlog và giúp nhóm hiểu vì sao từng Sprint có ý nghĩa đối với định hướng dài hạn.

Product Backlog không phải tài liệu yêu cầu cố định. Các hạng mục được làm rõ, chia nhỏ, bổ sung chi tiết, ước lượng và sắp xếp lại khi nhóm thu nhận thêm thông tin.

Sprint Backlog gắn với Sprint Goal

Sprint Backlog gồm ba phần:

·         Sprint Goal thể hiện lý do thực hiện Sprint

·         Các Product Backlog Item được lựa chọn thể hiện công việc dự kiến

·         Kế hoạch hành động thể hiện cách Developers tạo ra Increment

Sprint Backlog do Developers lập và quản lý. Nó là bức tranh thời gian thực về công việc cần thiết để đạt Sprint Goal, vì vậy phải được cập nhật trong Sprint khi nhóm học được điều mới.

Sprint Goal tạo sự tập trung nhưng vẫn cho phép linh hoạt về phạm vi chi tiết. Nhóm có thể thay đổi cách làm hoặc thương lượng lại một số hạng mục với Product Owner, miễn là không làm mất mục tiêu của Sprint.

Increment gắn với Definition of Done

Increment là một bước tiến cụ thể hướng tới Product Goal. Mỗi Increment phải bổ sung vào các Increment trước, được kiểm tra đầy đủ và có thể sử dụng. Một Sprint có thể tạo ra nhiều Increment và giá trị có thể được phát hành trước Sprint Review; Sprint Review không phải cổng phê duyệt bắt buộc để phát hành.

Definition of Done mô tả chính thức trạng thái chất lượng mà Increment phải đạt. Khi một Product Backlog Item đáp ứng Definition of Done, nó mới được xem là một phần của Increment. Công việc chưa đạt tiêu chuẩn không được tính là hoàn thành và phải quay lại Product Backlog để tiếp tục xem xét.

Do đó, “hoàn thành nhiệm vụ” và “tạo ra giá trị hoàn chỉnh” không phải lúc nào cũng giống nhau. Definition of Done bảo đảm các thành viên cùng sử dụng một chuẩn chất lượng thay vì tự diễn giải mức độ hoàn thành.

Cách áp dụng phương pháp Scrum cho một Sprint thực tế

Một nhóm có thể triển khai Scrum theo quy trình sau:

Bước 1: Xác lập Product Goal

Product Owner mô tả trạng thái sản phẩm cần đạt và giá trị mong muốn. Product Goal phải đủ rõ để làm cơ sở sắp xếp Product Backlog nhưng không nên biến thành danh sách giải pháp chi tiết.

Ví dụ, mục tiêu có thể là giúp khách hàng hoàn tất quy trình đăng ký dịch vụ mà không cần hỗ trợ thủ công. Mục tiêu này định hướng giá trị tốt hơn so với yêu cầu chung chung như “xây thêm màn hình đăng ký”.

Bước 2: Xây dựng và sắp xếp Product Backlog

Product Owner tập hợp các nhu cầu, vấn đề và cơ hội thành Product Backlog Item, sau đó sắp xếp theo giá trị, rủi ro, phụ thuộc và mức độ cần thiết.

Developers tham gia làm rõ và ước lượng để Product Owner hiểu các đánh đổi kỹ thuật. Tuy nhiên, Product Owner vẫn chịu trách nhiệm cuối cùng đối với thứ tự của Product Backlog.

Bước 3: Lập kế hoạch Sprint

Cả Scrum Team xây dựng Sprint Goal. Developers lựa chọn lượng công việc phù hợp với năng lực dự kiến và lập Sprint Backlog.

Nhóm không nên cố lấp đầy toàn bộ thời gian của từng thành viên. Kế hoạch cần tính đến hoạt động phối hợp, kiểm thử, xử lý bất định và bảo đảm Definition of Done.

Bước 4: Thực hiện và điều chỉnh hằng ngày

Developers triển khai công việc, tích hợp kết quả và kiểm tra chất lượng liên tục. Tại Daily Scrum, nhóm đánh giá khả năng đạt Sprint Goal thay vì chỉ đối chiếu số nhiệm vụ đã hoàn tất.

Khi phát hiện công việc phức tạp hơn dự kiến, nhóm điều chỉnh kế hoạch, phối hợp lại nguồn lực hoặc trao đổi với Product Owner để làm rõ phạm vi.

Bước 5: Tạo Increment đạt Definition of Done

Công việc chỉ được công nhận khi đáp ứng Definition of Done. Việc này ngăn nhóm dồn kiểm thử, tích hợp hoặc sửa lỗi sang Sprint sau rồi vẫn báo cáo rằng Sprint đã hoàn thành.

Bước 6: Kiểm tra giá trị tại Sprint Review

Scrum Team cùng các bên liên quan đánh giá Increment trong bối cảnh thực tế. Phản hồi thu được được dùng để cập nhật Product Backlog và định hướng Sprint tiếp theo.

Bước 7: Cải tiến hệ thống làm việc

Trong Sprint Retrospective, nhóm chọn một số thay đổi có tác động rõ ràng, chẳng hạn giảm thời gian chờ phê duyệt, cải thiện tiêu chuẩn kiểm thử hoặc xử lý sớm các phụ thuộc.

Một hành động cải tiến cụ thể có giá trị hơn danh sách dài các vấn đề không có người theo dõi và thời điểm thực hiện.

Những sai lệch thường gặp khi triển khai Scrum

Biến Sprint thành một kế hoạch bất biến

Sprint Goal cần ổn định, nhưng Sprint Backlog có thể thay đổi. Cố giữ nguyên mọi nhiệm vụ bất chấp thông tin mới đi ngược cơ chế thích nghi của Scrum.

Xem Scrum Master là quản lý dự án

Scrum Master hỗ trợ hiệu quả của Scrum Team nhưng không giao việc hoặc kiểm soát thành viên. Khi mọi quyết định phải chờ Scrum Master, khả năng tự quản lý của Developers bị suy giảm.

Biến Daily Scrum thành buổi báo cáo trạng thái

Daily Scrum phục vụ Developers trong việc điều chỉnh kế hoạch. Việc báo cáo tuần tự cho cấp quản lý làm giảm khả năng hợp tác và có thể che khuất câu hỏi quan trọng nhất: nhóm có đang tiến tới Sprint Goal hay không.

Đánh đồng Sprint Review với buổi trình diễn

Một màn trình bày một chiều không tạo ra đủ phản hồi. Sprint Review phải là cuộc trao đổi về kết quả, thay đổi bối cảnh và lựa chọn tiếp theo.

Chấp nhận công việc chưa đạt Definition of Done

Khi nhóm tính cả công việc chưa kiểm thử hoặc chưa tích hợp là hoàn thành, trạng thái tiến độ mất minh bạch. Product Owner và các bên liên quan có thể đưa ra quyết định dựa trên một Increment không thực sự sử dụng được.

Áp dụng từng phần nhưng vẫn gọi là Scrum

Scrum Guide xác định rằng Scrum chỉ tồn tại đầy đủ khi các thành phần cốt lõi được vận hành cùng nhau. Bỏ sự kiện, thay đổi trách nhiệm hoặc loại bỏ các quy tắc quan trọng có thể che giấu vấn đề và làm giảm lợi ích của framework.

Phương pháp Scrum quản lý công việc không phải bằng cách dự đoán toàn bộ dự án từ đầu mà bằng các vòng lặp minh bạch, kiểm tra và thích nghi. Product Owner định hướng giá trị, Developers tạo Increment, còn Scrum Master xây dựng môi trường để Scrum vận hành hiệu quả. Năm sự kiện tạo nhịp phản hồi xuyên suốt Sprint, trong khi ba tạo tác kết nối mục tiêu dài hạn, kế hoạch ngắn hạn và kết quả có thể sử dụng.

Một nhóm triển khai Scrum hiệu quả khi không chỉ tổ chức đủ các cuộc họp mà còn bảo vệ Sprint Goal, duy trì Product Backlog minh bạch, cập nhật Sprint Backlog theo thực tế và chỉ công nhận công việc đạt Definition of Done. Khi đó, mỗi Sprint vừa tạo ra giá trị sản phẩm vừa giúp nhóm cải tiến cách quản lý công việc.