Scrum là gì?
Scrum là một framework được sử dụng để phát triển và quản lý các sản phẩm trong môi trường phức tạp, đặc biệt phổ biến trong phát triển phần mềm. Scrum cung cấp một cấu trúc làm việc giúp các thành viên trong nhóm phối hợp với nhau, thường xuyên kiểm tra kết quả và thích ứng với những thay đổi trong quá trình phát triển.
Scrum là một framework đơn giản nhằm giúp các nhóm giải quyết những công việc phức tạp một cách hiệu quả, đồng thời tạo ra sản phẩm có giá trị. Sản phẩm được phát triển qua các chu kỳ lặp lại có thời gian cố định, gọi là Sprint. Mỗi Sprint là một cơ hội để nhóm tạo ra một Increment, kiểm tra kết quả, nhận phản hồi và điều chỉnh cho Sprint tiếp theo.
Scrum và Agile
Nhiều người thường nhầm lẫn Scrum và Agile là cùng một khái niệm, nhưng thực tế chúng không giống nhau. Agile là một cách tiếp cận dựa trên các giá trị và nguyên tắc định hướng cho quá trình phát triển, còn Scrum là một framework cụ thể được sử dụng để tổ chức và thực hiện công việc theo những tư tưởng đó. Ngoài Scrum, còn có những cách tiếp cận khác như Kanban, XP,…
Scrum được hình thành trước khi Agile Manifesto ra đời. Sau này, các nguyên tắc và cách làm của Scrum được xem là phù hợp với nhiều giá trị và nguyên tắc của Agile. Vì vậy, có thể hiểu đơn giản rằng Agile rộng hơn Scrum: Agile định hướng cách tư duy và các nguyên tắc, còn Scrum cung cấp một framework cụ thể để tổ chức công việc.
Scrum giải quyết vấn đề gì?
Trong quá trình phát triển sản phẩm, đặc biệt trong những môi trường phức tạp, các yêu cầu và hoàn cảnh có thể thay đổi theo thời gian. Nhóm phát triển cũng cần thường xuyên nhận phản hồi để biết sản phẩm có đang đi đúng hướng hay không, đồng thời phát hiện và xử lý các vấn đề càng sớm càng tốt.
Scrum được xây dựng để giúp các nhóm làm việc trong những môi trường như vậy thông qua việc phát triển sản phẩm theo các chu kỳ ngắn, thường xuyên kiểm tra kết quả và thích nghi với những thay đổi.
Tính minh bạch, kiểm tra và thích nghi là 3 trụ cột của chủ nghĩa kinh nghiệm (Empiricism) trong Scrum. Ba trụ cột này giúp nhóm dựa trên những gì thực tế đang diễn ra để đưa ra quyết định và điều chỉnh thay vì chỉ dựa vào kế hoạch ban đầu.
Có thể hiểu đơn giản Scrum giải quyết một số vấn đề như:
- Yêu cầu và hoàn cảnh thay đổi: Scrum cho phép nhóm thường xuyên kiểm tra và điều chỉnh hướng phát triển dựa trên những thay đổi và phản hồi mới.
- Rủi ro được phát hiện quá muộn: Việc tạo ra Increment và kiểm tra kết quả thường xuyên giúp nhóm phát hiện vấn đề sớm hơn.
- Không biết sản phẩm có thực sự đáp ứng nhu cầu hay không: Sprint Review tạo cơ hội để kiểm tra kết quả với các bên liên quan và thu thập phản hồi.
- Đội ngũ làm việc chưa hiệu quả: Scrum tạo ra một cấu trúc làm việc rõ ràng và khuyến khích Scrum Team tự quản, phối hợp với nhau để đạt được mục tiêu chung.
- Cách làm việc không được cải thiện: Sprint Retrospective giúp nhóm nhìn lại cách làm việc và xác định những thay đổi cần thực hiện trong Sprint tiếp theo.
- Giá trị được tạo ra quá muộn: Việc phát triển sản phẩm theo từng Sprint giúp nhóm có thể tạo ra các Increment có giá trị sớm hơn thay vì chờ đến cuối toàn bộ dự án.
Ba trụ cột của Scrum
Ba trụ cột của Scrum là Minh bạch (Transparency), Kiểm tra (Inspection) và Thích nghi (Adaptation). Đây là những yếu tố nền tảng giúp Scrum vận hành dựa trên chủ nghĩa kinh nghiệm (Empiricism). Nhờ ba trụ cột này, nhóm có thể dựa trên những gì đang thực sự diễn ra để đưa ra quyết định và điều chỉnh thay vì chỉ dựa vào kế hoạch ban đầu.
- Minh bạch (Transparency): Các thông tin quan trọng liên quan đến sản phẩm và quá trình phát triển cần được công khai, rõ ràng và được hiểu thống nhất bởi những người tham gia. Những thông tin này có thể bao gồm mục tiêu sản phẩm, yêu cầu, tiến độ, công việc đang thực hiện và các vấn đề đang gặp phải. Khi thông tin minh bạch, nhóm có cơ sở để kiểm tra tình trạng thực tế và đưa ra quyết định phù hợp.
- Kiểm tra (Inspection): Các thành viên trong Scrum Team và các bên liên quan cần thường xuyên kiểm tra tiến độ, kết quả và tình trạng của sản phẩm để phát hiện các vấn đề hoặc sai lệch so với mục tiêu. Việc kiểm tra giúp nhóm nhận ra những gì đang diễn ra trên thực tế và xác định những điểm cần được điều chỉnh.
- Thích nghi (Adaptation): Khi quá trình phát triển hoặc kết quả sản phẩm cho thấy cần thay đổi, nhóm cần điều chỉnh kế hoạch, sản phẩm hoặc cách làm việc cho phù hợp. Việc thích nghi giúp nhóm phản ứng với những thay đổi và tránh tiếp tục đi theo một hướng không còn phù hợp.
Hai đặc điểm của Scrum Team
Scrum Team có hai đặc điểm là tự quản (self-managing) và liên chức năng (cross-functional).
- Tự quản (self-managing): Đây là thuật ngữ được sử dụng trong Scrum Guide 2020, thay cho thuật ngữ self-organizing trong phiên bản trước. Điều này có nghĩa là Scrum Team tự quyết định cách tổ chức và thực hiện công việc để đạt được mục tiêu chung, bao gồm việc phân chia công việc và lựa chọn cách thực hiện. Nhóm không phụ thuộc vào sự chỉ đạo chi tiết từ bên ngoài mà tự quản lý công việc của mình trong phạm vi trách nhiệm của Scrum Team.
- Liên chức năng (cross-functional): Scrum Team bao gồm những người có các kỹ năng và chuyên môn khác nhau, đủ năng lực cần thiết để tạo ra một Increment có giá trị. Các thành viên phối hợp với nhau như một đơn vị thống nhất để đạt được mục tiêu chung. Trong Scrum Team không có các nhóm nhỏ hoặc các cấp bậc bên trong team.
Ba Accountabilities trong Scrum Team
Trong Scrum, có ba trách nhiệm (Accountabilities): Product Owner, Scrum Master và Developers. Ba trách nhiệm này hợp thành một Scrum Team và không có cấp bậc hay các nhóm nhỏ bên trong.
- Product Owner: Là người chịu trách nhiệm tối đa hóa giá trị của sản phẩm. Product Owner chịu trách nhiệm quản lý hiệu quả Product Backlog, bao gồm việc xác định và truyền đạt Product Goal, tạo và sắp xếp thứ tự các Product Backlog Items. Product Owner quyết định thứ tự ưu tiên của các hạng mục dựa trên giá trị mà chúng mang lại cho sản phẩm và các bên liên quan.
- Scrum Master: Là người chịu trách nhiệm giúp Scrum được hiểu và áp dụng đúng trong Scrum Team và tổ chức. Scrum Master hỗ trợ Scrum Team trở nên hiệu quả hơn, giúp loại bỏ các trở ngại và thúc đẩy việc cải tiến liên tục. Scrum Master không phải là người quản lý hay cấp trên của Scrum Team mà hoạt động theo hướng phục vụ và hỗ trợ team.
- Developers: Là những người chịu trách nhiệm tạo ra một Increment có giá trị và đáp ứng Definition of Done trong mỗi Sprint. Developers có thể có những chuyên môn khác nhau như lập trình, kiểm thử, thiết kế hoặc cơ sở dữ liệu. Tuy nhiên, trong Scrum Team không có sự phân chia thành các sub-team hay cấp bậc; các thành viên phối hợp với nhau để đạt được Sprint Goal và tạo ra Increment.
Các tạo tác trong Scrum – Scrum Artifacts
Scrum có ba tạo tác chính: Product Backlog, Sprint Backlog và Increment. Mỗi tạo tác đều có một cam kết tương ứng, giúp tạo ra sự minh bạch và tập trung vào mục tiêu trong quá trình phát triển.
- Product Backlog: Là danh sách có thứ tự về tất cả những gì cần thiết để cải thiện sản phẩm. Các hạng mục trong Product Backlog có thể bao gồm tính năng mới, sửa lỗi, cải tiến hoặc những công việc cần thiết khác. Product Backlog liên tục được cập nhật trong suốt quá trình phát triển sản phẩm. Product Owner chịu trách nhiệm về việc quản lý hiệu quả Product Backlog, bao gồm việc xây dựng và truyền đạt Product Goal, tạo và sắp xếp thứ tự các Product Backlog Items sao cho phù hợp với giá trị và mục tiêu của sản phẩm.
- Sprint Backlog: Là kế hoạch của Developers cho một Sprint. Sprint Backlog bao gồm Sprint Goal, các Product Backlog Items được lựa chọn cho Sprint và kế hoạch hành động để tạo ra Increment. Sprint Backlog được cập nhật trong suốt Sprint khi Developers hiểu rõ hơn về công việc cần thực hiện và những thay đổi phát sinh.
- Increment: Là một bước tiến cụ thể, có giá trị và sử dụng được của sản phẩm. Một Increment phải đáp ứng Definition of Done để đảm bảo nó đạt được tiêu chuẩn chất lượng cần thiết. Trong một Sprint có thể tạo ra nhiều Increment, và các Increment được tạo ra trong Sprint sẽ được tích hợp với những Increment trước đó để tạo thành một sản phẩm hoàn chỉnh hơn. Việc tạo ra Increment giúp Scrum Team thường xuyên tạo ra giá trị thay vì chờ đến cuối toàn bộ quá trình phát triển mới có sản phẩm sử dụng được.
Năm sự kiện trong Scrum
Scrum có năm sự kiện chính: Sprint, Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective. Các sự kiện này tạo ra những cơ hội để Scrum Team thực hiện việc kiểm tra và thích nghi trong quá trình phát triển.
- Sprint: Sprint là một khoảng thời gian cố định, không dài hơn một tháng, trong đó Scrum Team làm việc để đạt Sprint Goal và tạo ra một Increment có giá trị. Các Sprint có cùng độ dài và diễn ra liên tiếp nhau. Sprint kết thúc khi thời gian quy định kết thúc, ngay cả khi một số công việc trong Sprint Backlog chưa hoàn thành. Điều quan trọng là những phần công việc được đưa vào Increment phải đáp ứng Definition of Done.
- Lập kế hoạch Sprint (Sprint Planning): Là sự kiện được thực hiện ở đầu mỗi Sprint nhằm xác định mục tiêu và kế hoạch cho Sprint. Sprint Planning có thể được hiểu thông qua ba câu hỏi Why – What – How:
- Why: Tại sao Sprint này có giá trị? Scrum Team thảo luận và xác định Sprint Goal.
- What: Sprint này sẽ thực hiện những gì? Developers lựa chọn các Product Backlog Items mà họ tin rằng có thể thực hiện trong Sprint.
- How: Công việc sẽ được thực hiện như thế nào? Developers lập kế hoạch để biến các Product Backlog Items đã chọn thành một Increment đáp ứng Definition of Done.
Sprint Planning là hoạt động cộng tác của toàn bộ Scrum Team. Developers tự quyết định cách tổ chức và thực hiện công việc. Kết quả của Sprint Planning là Sprint Goal và Sprint Backlog.
- Scrum Hằng ngày (Daily Scrum): Là một sự kiện kéo dài 15 phút dành cho Developers, được thực hiện mỗi ngày trong Sprint nhằm kiểm tra tiến độ hướng tới Sprint Goal và điều chỉnh kế hoạch khi cần thiết. Daily Scrum không đơn thuần là buổi báo cáo công việc cho Scrum Master hay Product Owner. Developers có thể lựa chọn bất kỳ cách thức nào phù hợp để thực hiện sự kiện này, miễn là sự kiện giúp họ tập trung vào Sprint Goal và điều chỉnh kế hoạch làm việc.
- Sơ kết Sprint (Sprint Review): Là sự kiện diễn ra vào cuối Sprint nhằm kiểm tra kết quả của Sprint và thảo luận về những điều chỉnh tiếp theo đối với sản phẩm. Scrum Team cùng các bên liên quan xem xét những gì đã đạt được, những thay đổi trong môi trường và thảo luận về những việc cần thực hiện tiếp theo. Product Backlog có thể được điều chỉnh dựa trên những thông tin và phản hồi thu được từ Sprint Review.
- Cải tiến Sprint (Sprint Retrospective): Là sự kiện diễn ra sau Sprint Review nhằm kiểm tra cách Scrum Team đã làm việc trong Sprint vừa qua và xác định những cải tiến cần thực hiện. Team có thể xem xét các vấn đề liên quan đến cách làm việc, sự phối hợp, quy trình, công cụ hoặc Definition of Done. Những cải tiến quan trọng nhất sẽ được đưa vào áp dụng càng sớm càng tốt, có thể ngay trong Sprint tiếp theo.
Những hiểu lầm phổ biến về Scrum
Scrum thường bị hiểu sai thành một quy trình quản lý công việc cứng nhắc. Một số hiểu lầm phổ biến có thể kể đến:
- Scrum = Agile: Scrum là một framework dựa trên các giá trị và nguyên tắc của Agile, nhưng Agile rộng hơn Scrum. Agile là cách tiếp cận dựa trên các giá trị và nguyên tắc, còn Scrum là một framework cụ thể.
- Scrum Master là người quản lý nhóm: Scrum Master không phải cấp trên hay người giao việc cho Developers. Scrum Master có trách nhiệm giúp Scrum được hiểu và áp dụng đúng, hỗ trợ Scrum Team và loại bỏ các trở ngại ảnh hưởng đến hiệu quả làm việc.
- Daily Scrum là cuộc họp để báo cáo: Daily Scrum không phải buổi Developers báo cáo tiến độ cho Scrum Master hay Product Owner. Đây là sự kiện 15 phút dành cho Developers để kiểm tra tiến độ hướng tới Sprint Goal và điều chỉnh Sprint Backlog khi cần.
- Sprint chỉ là khoảng thời gian để lập trình: Sprint là một khoảng thời gian cố định, trong đó Scrum Team thực hiện công việc để tạo ra một Increment có giá trị và có thể sử dụng được. Sprint không chỉ bao gồm việc viết code.
- Sprint Review chỉ là buổi demo: Sprint Review không chỉ để trình diễn sản phẩm. Scrum Team cùng các bên liên quan kiểm tra kết quả của Sprint, trao đổi về những thay đổi và điều chỉnh hướng phát triển tiếp theo nếu cần.
- Scrum không có kế hoạch: Scrum không loại bỏ việc lập kế hoạch. Thay vào đó, kế hoạch được xây dựng và điều chỉnh thường xuyên dựa trên những gì nhóm quan sát được trong quá trình phát triển.
- Agile/Scrum nghĩa là không cần tài liệu: Agile ưu tiên phần mềm hoạt động hơn tài liệu đầy đủ, nhưng điều đó không có nghĩa là Scrum hay Agile loại bỏ tài liệu. Tài liệu vẫn được sử dụng khi cần thiết cho sản phẩm và công việc.
Kết luận
Scrum là một framework được sử dụng để phát triển và quản lý sản phẩm trong những môi trường phức tạp, nơi yêu cầu và hoàn cảnh có thể thay đổi theo thời gian. Scrum dựa trên chủ nghĩa kinh nghiệm, với ba trụ cột là Minh bạch (Transparency), Kiểm tra (Inspection) và Thích nghi (Adaptation).
Scrum Team gồm Product Owner, Scrum Master và Developers. Các thành viên phối hợp với nhau thông qua các Artifact và Event của Scrum để tạo ra những Increment có giá trị sau mỗi Sprint, đồng thời thường xuyên kiểm tra kết quả và điều chỉnh hướng phát triển khi cần thiết.
Scrum không phải là một quy trình cố định chỉ tập trung vào việc hoàn thành các công việc được giao. Mục tiêu của Scrum là giúp nhóm làm việc hiệu quả trong môi trường phức tạp bằng cách liên tục tạo ra giá trị, nhận phản hồi, phát hiện vấn đề và thích nghi với những thay đổi.
Nguồn tham khảo
Bài viết khác
Mô hình Waterfall là gì? Phân biệt Agile và Waterfall
Waterfall là gì? Mô hình Waterfall, hay còn gọi là mô hình thác nước, là một mô hình phát triển phần mềm trong đó quá trình phát triển được chia thành các giai đoạn với những nhiệm vụ và mục tiêu khác nhau. Các giai đoạn được thực hiện theo một trình tự tương đối […]
Agile
Giới thiệu Trong quá trình thực hiện dự án, đặc biệt là các dự án phần mềm, chúng ta thường gặp khó khăn trong việc xác định đầy đủ và chính xác các yêu cầu của sản phẩm để có thể lập một kế hoạch hoàn chỉnh ngay từ đầu. Điều này xuất phát từ […]
KANBAN
1. NGUỒN GỐC KANBAN: TỪ TOYOTA ĐẾN NGÀNH PHẦN MỀM 1.1. Bối cảnh ra đời tại Nhật Bản Sau Thế chiến thứ hai (1945), nền kinh tế Nhật Bản rơi vào tình trạng kiệt quệ với nguồn vốn hạn chế, tài nguyên thiên nhiên khan hiếm và cơ sở hạ tầng bị phá hủy. Ngành […]
SCRUM
Framework phát triển sản phẩm dựa trên Agile 3.1. Scrum ra đời để giải quyết vấn đề gì? Sau khi hiểu Agile, sẽ xuất hiện một câu hỏi: Agile nói rằng team cần phản hồi nhanh, thích nghi và liên tục cải tiến. Nhưng làm thế nào để tổ chức công việc thực tế? Đó […]
AGILE
2.1. Agile bắt đầu xuất hiện như thế nào? Trước năm 2001, nhiều phương pháp phát triển phần mềm đã được hình thành nhằm giải quyết những khó khăn của các dự án phần mềm truyền thống. Một số phương pháp tiêu biểu: Extreme Programming (XP) // lập trình cực hạn, tập trung vào phản […]
Waterfall: Tưởng đâu làm tuần tự là chill… ai ngờ kill
WATERFALL Mô hình phát triển phần mềm tuần tự 1.1. Trước Agile: thế giới phần mềm làm việc như thế nào? Trước khi các phương pháp Agile phổ biến, một tư duy phát triển thường gặp là: Muốn xây dựng một hệ thống lớn thì trước tiên phải lập kế hoạch thật kỹ, sau đó […]
Khoá học lập trình game con rắn cho trẻ em 
