Scrum là gì?

“Scrum là một khung làm việc để phát triển bền vững các sản phẩm phức tạp” (Theo Hướng dẫn Scrum – Scrum Guide). Có thể hiểu đây là khung tổ chức công việc tổng quát hướng đến phát triển các sản phẩm phức tạp, chủ yếu là phần mềm. Tuy vậy, Scrum có thể được dùng như là nền tảng tổ chức các công việc khác nhau, từ quản trị dự án linh hoạt nói chung, đến phát triển sản phẩm, thực hiện các chiến dịch marketing, tổ chức dạy học, sản xuất ô tô module hóa hoặc những công việc cá nhân khác.

Hiện nay, định nghĩa Scrum được ghi trong tài liệu Scrum Guide (Hướng dẫn Scrum) và được cập nhật thường xuyên bởi chính các tác giả tại ScrumGuides.

Cần lưu ý rằn Scrum là một khung làm việc (framework) chứ không phải một phương pháp (method) cụ thể. Khi vận dụng, Scrum cung cấp các nền tảng cơ bản, kết hợp với các phương pháp hay biện pháp thực hành khác để phát huy tác dụng.

Khung làm việc Scrum có gì?

Dựa trên lý thuyết quản lý thực nghiệm (empirical process control), Scrum sử dụng cơ chế lặp (iterative) và tăng trưởng (incremental) để tối ưu hóa tính hiệu quả và kiểm soát rủi ro. Scrum rất đơn giản, dễ học và có khả năng ứng dụng rất rộng. Để có thể dùng Scrum, chúng ta cần hiểu rõ và vận dụng đúng các thành tố tạo nên Scrum bao gồm các giá trị cốt lõi (còn gọi là “ba chân”, hay ba trụ cột của Scrum), các vai trò, các sự kiện, và các công cụ (artifacts) đặc thù của Scrum.

Ba chân (hay giá trị cốt lõi) của Scrum

Scrum là một phương pháp linh hoạt (agile), vì thế nó tuân thủ các nguyên tắc của Tuyên ngôn Agile (Manifesto for Agile Software Development) (xem thêm Tuyên ngôn Agile). Ngoài ra Scrum hoạt động dựa trên ba giá trị cốt lõi, còn gọi là Ba chân của Scrum bao gồm Minh bạch, Thanh tra và Thích nghi.

• Minh bạch (transparency)

Trong Scrum, tính minh bạch được đề cao như là giá trị cốt lõi cơ bản nhất. Muốn thành công với Scrum, thông tin liên quan tới quá trình phát triển phải minh bạch và thông suốt. Các thông tin đó có thể là: tầm nhìn (vision) về sản phẩm, yêu cầu khách hàng, tiến độ công việc, các khúc mắc và rào cản v.v. Từ đó mọi người ở các vai trò các nhau có đủ thông tin cần thiết để tiến hành các quyết định có giá trị để nâng cao hiệu quả công việc. Các công cụ và cuộc họp trong Scrum luôn đảm bảo thông tin được minh bạch cho các bên.

• Thanh tra (inspection)

Công tác thanh tra liên tục các hoạt động trong Scrum đảm bảo cho việc phát lộ các vấn đề cũng như giải pháp để thông tin đa dạng và hữu ích đến được với các bên tham gia dự án. Truy xét kĩ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và các cải tiến liên tục trong Scrum.

• Thích nghi (adaptation)

Scrum rất linh hoạt như các phương pháp phát triển linh hoạt (agile software development) khác. Nhờ đó nó mang lại tính thích nghi rất cao. Dựa trên các thông tin minh bạch hóa từ các quá trình thanh tra và làm việc, Scrum có thể phản hồi lại các thay đổi một cách tích cực, nhờ đó mang lại thành công cho dự án.

Ba Vai trò

Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra ba vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù. Ba vai trò này bao gồm: Product Owner(chủ sản phẩm), Scrum Master và Development Team (Đội sản xuất hay Nhóm Phát triển).

• Product Owner (chủ sản phẩm)

Là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm.

• Scrum Master

Là người có hiểu biết sâu sắc về Scrum và đảm bảo nhóm có thể làm việc hiệu quả với Scrum.

• Development Team (Đội sản xuất, hay Nhóm phát triển)

Một nhóm liên chức năng (cross-functional) tự quản lý để tiến hành chuyển đổi các yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ thống.

Bốn Sự kiện (4 Events)

Scrum định nghĩa quy tắc cho bốn sự kiện chủ chốt nhằm tạo môi trường và quy cách hoạt động và cộng tác cho các thành viên trong dự án. Các sự kiện này diễn ra trước khi Sprint bắt đầu (là sự kiện lập kế hoạch  – Sprint Planning), trong khi Sprint diễn ra (sự kiện Daily Scrum) và sau khi Sprint kết thúc (sự kiện Sprint Review và Sprint Retrospective).

• Sprint Planning (Họp Kế hoạch Sprint)

Nhóm phát triển gặp gỡ với Product Owner để lên kế hoạch làm việc cho một Sprint (xem thêm phần Sprint bên dưới).  Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các tác vụ. Scrum sử dụng cách thức lập kế hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm.

• Daily Scrum (Họp Scrum hằng ngày)

Scrum Master tổ chức cho Đội sản xuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát triển chia sẻ tiến độ công việc cũng như chia sẻ các khó khăn gặp phải trong quá trình phát triển phần mềm suốt một Sprint.

• Sprint Review (Họp Sơ kết Sprint)

Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm.

• Sprint Retrospective (Họp Cải tiến Sprint)

Dưới sự trợ giúp của Scrum Master, nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm.

Các tạo tác (artifacts) Scrum

Scrum sử dụng các công cụ rất đơn giản nhưng hiệu quả để trợ giúp công việc. Chúng bao gồm bản yêu cầu của ProductOwner  được gọi là Product Backlog, bản kế hoạch của từng Sprint (Sprint Backlog) và phần sản phẩm chuyển giao được cuối mỗi Sprint (Increment).

• Product Backlog

Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án, có thể hiểu như là danh sách yêu cầu (requirement) của dự án. Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong  Product Backlog dựa trên các giá trị do Product Owner định nghĩa (thường là giá trị thương mại – business value).

• Sprint Backlog

Đây là bản kế hoạch cho một Sprint; là kết quả của buổi họp lập kế hoạch (Sprint Planning). Với sự kết hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc (TODO list).

• Phần tăng trưởng (Increment)

Sau mỗi Sprint, nhóm phát triển phải chuyển giao một phần công việc hoàn chỉnh cho ProductOwner hoặc khách hàng, gọi là Increment (Phần sản phẩm hoàn chỉnh chuyển giao được). Phần này chính là phần công việc hoàn chỉnh tính tới thời điểm chuyển giao, tích hợp tốt với những phần công việc trước đó và đáp ứng tiêu chuẩn hoàn thành của nhóm

Trước đây, Tài liệu hướng dẫn Scrum còn đưa các Biểu đồ Burndown vào là tạo tác Scrum. Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại để hoàn tất công việc. Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart). Tuy nhiên, do đây không phải là thành phần thiết yếu bắt buộc cho mỗi nhóm triển khai Scrum, nên đã bị đưa ra khỏi Scrum Guide. Biểu đồ burndown không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó.

Scrum vận hành như thế nào?

Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án với các hạng mục được sắp theo thứ tự ưu tiên. Đội sản xuất sẽ thực hiện việc hiện thực hóa dần các yêu cầu của Product Owner với sự lặp đi lặp lại các giai đoạn nước rút từ 1 đến 4 tuần làm việc (gọi là Sprint) với đầu vào là các hạng mục trong Product Backlog, đầu ra là các gói phần mềm hoàn chỉnh có thể chuyển giao được (Potentially Shippable Product Increment). Trước khi cả nhóm cùng đua nước rút trong Sprint, đội sản xuất cùng họp với Product Owner để lập kế hoạch cho từng Sprint. Kết quả của buổi lập kế hoạch (theo cách làm của Scrum) là Sprint Backlog chứa các công việc cần làm trong suốt một Sprint. Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật Sprint Backlog và thực hiện công việc họp hằng ngày (Daily Scrum) để chia sẻ tiến độ công việc cũng như các vướng mắc trong quá trình làm việc cùng nhau. Nhóm được trao quyền để tự quản lí và tổ chức lấy công việc của mình để hoàn thành công việc trong Sprint. Khi kết thúc Sprint, nhóm tạo ra các gói phần mềm có chức năng hoàn chỉnh, sẵn sàng chuyển giao (shippable) cho khác hàng. Buổi họp Sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ giúp khách hàng thấy được nhóm đã có thể chuyển giao những gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiến. Sau khi kết thúc việc đánh giá Sprint, Scrum Master và nhóm cùng tổ chức họp Cải tiến Sprint (Sprint Retrospective)  để tìm kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu, điều này sẽ giúp nhómliên tục học hỏi và trưởng thành qua từng Sprint.

Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product Backlog đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căn cứ tình hình thực tế. Do sử dụng chiến thuật “có giá trị hơn làm trước” nên các hạng mục mang lại nhiều giá trị hơn cho chủ dự án luôn được hoàn tất trước. Do đó Scrum luôn mang lại giá trị cao nhất cho người đầu tư cho dự án. Do quy trình luôn luôn được cải tiến, nhóm Scrum thường có năng suất lao động rất cao. Đây là hai lợi ích to lớn mà Scrum mang lại cho tổ chức.

Nguồn: HanoiScrum