Tóm tắt
Quy trình Scrum là một framework phổ biến dựa trên phương pháp Agile. Scrum phù hợp nhất với các dự án cần được xây dựng và cải tiến liên tục. Bài viết này sẽ giúp bạn hiểu cách Scrum hoạt động và sử dụng Scrum như thế nào để mang lại lợi ích tối đa nhất cho mọi cấp độ trong tổ chức của bạn. Scrum là một framework được thiết kế để áp dụng cho các dự án cần xây dựng và liên tục tối ưu. Áp dụng Scrum sẽ giúp team cùng nhau giải quyết các vấn đề phức tạp trong những dự án kiểu thế này.
Scrum là một framework dựa trên phương pháp Agile, giúp các team cộng tác và hoàn thành những công việc/dự án quan trọng. Scrum cung cấp một quy trình hoàn chỉnh với các vai trò và nhiệm vụ rất cụ thể, từ đó các thành viên trong team chỉ cần tập trung vào việc lặp lại và cải tiến quy trình này.
Quy trình Scrum giúp rã một dự án lớn thành các nhiệm vụ nhỏ và cụ thể mà team có thể bắt tay vào thực hiện ngay và lặp đi lặp lại quá trình đó. Quy trình Scrum phù hợp nhất khi chúng ta hướng đến việc liên tục cải thiện các sản phẩm của mình cho đến khi toàn bộ dự án được hoàn thành.
"Scrum" lần đầu tiên được giới thiệu trong bài báo “The New New Product Development Game” năm 1986 của Harvard Business Review, được viết bởi Hirotaka Takeuchi và Ikujiro Nonaka. Tên gọi "Scrum" được lấy ý tưởng từ môn thể thao phổ biến của Mỹ - bóng bầu dục, vì trong một trận bóng bầu dục, quả bóng sẽ được chuyền trong team và mỗi dịch chuyển của quả bóng tương đương với từng điểm số ghi được trong trận. (bóng càng vào sâu trong sân đối phương thì điểm càng cao, và ngược lại.)
Scrum tiếp tục được phát triển và hệ thống hóa bởi Ken Schwaber và Jeff Sutherland vào năm 1995, khi họ xuất bản Tuyên ngôn Agile và Quy trình Phát triển SCRUM của mình.
Framework Scrum được phát triển bởi Schwaber và Sutherland, mục đích là để thay thế cho framework waterfall. Với waterfall, các dự án được chia thành các giai đoạn tuần tự, giai đoạn sau tiếp nối giai đoạn trước. Schwaber và Sutherland nhận thấy rằng các lập trình viên có thể tạo ra các sản phẩm tốt hơn nếu được trở đi trở lại với các đoạn code đã hoàn thành, cũng như chủ động và linh hoạt hơn với các yêu cầu từ khách hàng.
Ngay khi giới thiệu veêề Scrum với thế giới, Schwaber và Sutherland đã xuất bản Scrum Guide — một tài liệu được họ cập nhật thường xuyên. Theo Scrum Guide, Scrum sẽ giúp team đánh giá hiệu quả của phương pháp làm việc đang được áp dụng, cũng như liên tục phát triển và cải thiện các phương pháp hiện có của mình.
Theo truyền thống, Scrum được chạy trong một sprint, thường là các phiên làm việc kéo dài hai tuần với các sản phẩm cụ thể sẽ đến hạn vào cuối.
Có hai sự kiện phụ trong 1 quy trình Scrum:
Điều cốt lõi nhất cần ghi nhớ trước khi áp dụng Scrum cho team của mình là framework Scrum là cơ sở để team có thể liên tục cải tiến (cả sản phẩm và quy trình). Với Scrum, bạn không cần biết cách làm trước khi bắt đầu Sprint, bạn và team luôn có thể liên tục điều chỉnh cách làm và mục tiêu dựa trên những kinh nghiệm thu thập được trong quá trình làm việc.
Các sự kiện là các yếu tố không thể thiếu trong mỗi sprint. Mỗi sự kiện sẽ phục vụ một mục đích cụ thể để đảm bảo các sprint có cấu trúc nhất quán, từ đó có thể giúp team đạt kết quả kỳ vọng của sprint.
Mặc dù những sự kiện này có vẻ bị lặp đi lặp lại quá nhiều, nhưng đây chính là những yếu tố cốt lõi trong một sprint, đặc biệt quan trọng hơn cả nếu team của bạn mới làm quen với Scrum. Việc tuân thủ các nguyên tắc này sẽ giúp đảm bảo rằng tất cả mọi người trong team luôn nhìn cùng một hướng và tất cả các trở ngại đều được giải quyết. Các sự kiện này được tạo ra đều nhằm mục đích cuối là để giúp các sprint diễn ra một cách trơn tru.
Hình sau mô tả mối tương quan của 3 tạo phẩm.
Product Backlog chứa toàn bộ việc cần làm của một dự án
Sprint Backlog chứa toàn bộ việc cần làm trong một sprint
Qua các sprint, nhóm dự án tạo ra các Increments và tổng hợp tất cả các Increments này vào thành phẩm (Final Product)
Product backlog là danh sách tổng thể các công việc cần phải được thực hiện. Danh sách này nên được thực hiện bởi Project manager hoặc Product owner. Lưu ý rằng không phải chỉ vì công việc đó nằm trong Product backlog thì team sẽ phải thực hiện nó — thay vào đó, các mục trong Product backlog là các đầu việc mà team có thể tuỳ chọn để triển khai trong từng sprint. Các Product owner nên thường xuyên sắp xếp và cập nhật Product backlog dựa trên những thông tin mới từ khách hàng, từ thị trường hoặc từ team dự án.
Sprint backlog là tập hợp các công việc hoặc sản phẩm mà nhóm của bạn cam kết thực hiện được trong Sprint. Các mục này được chọn từ Product backlog trong phiên Sprint planning và chuyển sang Srpint backlog.
Nếu team thường xuyên không hoàn thành được các đầu việc có trong Sprint backlog hoặc thường hoàn thành sớm hơn dự kiến và phải thêm việc vào Sprint backlog giữa chừng thì team cần dành nhiều thời gian hơn ở Sprint planning để lập kế hoạch cụ thể và gần với thực tế hơn.
Product Increment là kết quả của quá trình phát triển phần mềm trong mỗi Sprint. Nó là một sản phẩm phần mềm hoàn chỉnh được xây dựng từ những yêu cầu của khách hàng và được Scrum team phát triển trong một khoảng thời gian ngắn (một sprint), thường là trong vòng 1 đến 4 tuần.
Increment có thể là một tính năng mới, một cải tiến, một bản sửa lỗi hoặc một phần mềm hoàn chỉnh, tùy thuộc vào nhu cầu của dự án. Mục tiêu của việc tạo Increment sau mỗi Sprint là để đảm bảo rằng sản phẩm phần mềm được phát triển liên tục và luôn cải thiện với chất lượng tốt nhất.
Sau khi hoàn thành Sprint, Increment được kiểm tra và đánh giá bởi Scrum teamđể xác định liệu nó có đáp ứng được tiêu chí "Hoàn thành" hay không. Nếu đáp ứng được, Increment sẽ được cho khách hàng hoặc các bên liên quan khác, nếu không, Scrum team sẽ tiếp tục làm việc để hoàn thành nó trong Sprint tiếp theo.
Với Scrum, không có gì là hoàn hảo, bởi vì team sẽ cần linh hoạt và cải thiện liên tục. Vì thế, "Hoàn thành" không có nghĩa là "điều này không thể trở nên tốt hơn" — mà là team sẽ ngừng làm công việc này, ngay lập tức.
Ví dụ: đây là một vài định nghĩa về "Hoàn thành" (Definition of Don - DoD) tham khảo:
Bất kể định nghĩa của team về "Hoàn thành" là gì, hãy đảm bảo rằng mọi người đều hiểu cùng một ý. Khi bạn đã có định nghĩa cho team của mình, tốt hơn hết những định nghĩa này nên được tổng hợp ở một nơi mà mọi người có thể dễ dàng tham khảo, đặc biệt là trong những lần Sprint review (tham khảo Project Overview của Asana).
Trong Scrum, các thành viên sẽ được chỉ định vai trò cụ thể, có 3 vai trò gồm: Product owner, Scrum master và Scrum team. Các thành viên sẽ nhận nhiệm vụ cụ thể phù hợp với vai trò mình đảm nhiệm.
Đây là người phụ trách product backlog. Họ có nhiệm vụ thu thập yêu cầu từ khách hàng và truyền đạt câu chuyển của khách hàng lại cho team, cũng như các bên liên quan. Một người Product owner giỏi sẽ giúp mọi người có cái nhìn rõ ràng nhất về những kết quả quan trọng cần đạt được trong suốt dự án. Cuối cùng, họ chính là người quyết định khi nào thì một sản phẩm sẵn sàng để trình bày cho khách hàng (với tinh thần thường xuyên phải cập nhật và trình bày cho khách hàng về dự án).
Scrum master là người điều hành các sự kiện trong Scrum. Họ có thể được xem là người quản lý và điều phối dự án. Scrum master cần sắp xếp mọi thứ thuận lợi để tổ chức đầy đủ các sự kiện Scrum như standup daily và sprint planning, sprint review và sprint retropective.
Scrum team là tất cả những người đang làm việc trong sprint. Các thành viên trong nhóm nên tự tổ chức và hợp tác để đạt được mục tiêu của Scrum là cải tiến liên tục.
Scrum cũng dựa trên sáu nguyên tắc cơ bản để đảm bảo nhóm duy trì sự tập trung và giữ cho dự án đi đúng hướng. Sáu nguyên tắc đó là:
Để hưởng lợi từ Scrum, các nhóm cần tuân thủ năm giá trị cốt lõi của Scrum, như được định nghĩa trong Scrum Guide:
Scrum là một trong những framework phổ biến nhất để thực hành phương pháp Agile. Framework Scrum có các vai trò, hệ thống và quy trình bổ sung để giúp tăng tính “agile” (linh hoạt) của team.
Dù là Agile hay Scrum thì kim chỉ nam đều hướng về sự cải tiến liên tục. Nhưng không giống như Agile, vốn thiên về tính lý thuyết, Scrum định nghĩa những cách cụ thể để các nhóm có thể “liên tục cải tiến”, linh hoạt (agile) hơn, thông qua các công cụ như Sprint, Daily standup, và Sprint retropective.
Framework Kanban tuy cũng là một phần tử con của Agile như Scrum, nhưng 2 framework này lại phục vụ các mục đích khác nhau.
Kanban sẽ giúp cả team hình dung công việc di chuyển qua các giai đoạn khác nhau như thế nào cho đến khi hoàn thành. Còn Scrum tập trung vào chia dự án/sản phẩm ra thành các phần nhỏ để có thể hoàn thành trong một khoảng thời gian ngắn, thay vì tập trung vào bức tranh lớn của toàn bộ dự án. Trong khi một chu kỳ của Kanban sẽ kéo dài xuyên suốt dự án thì Scrum Sprint thường chỉ kéo dài từ một đến bốn tuần.
Thông thường, các Scrum team cũng tổ chức task của mình trên Kanban board, mặc dù đó không phải là một yêu cầu bắt buộc của framework Scrum. Sự kết hợp của Scrum và Kanban cũng là một sự kết hợp phổ biến, còn được gọi là Scrumban.
Scrum không dành cho tất cả mọi người — nhưng nó cũng không chỉ giới hạn ở các nhóm sản phẩm, phát triển phần mềm và kỹ thuật. Bất kỳ nhóm nào cũng có thể áp dụng framework Scrum và sử dụng cải tiến liên tục để hoàn thành công việc tuyệt vời. Dưới đây là một số ưu và nhược điểm của việc sử dụng Scrum:
Scrum hiệu quả nhất đối với các dự án cần xây dựng và tạo ra kết quả thường xuyên, thường thấy trong lĩnh vực lập trình, marketing và sáng tạo. Các lợi ích cụ thể gồm:
Các dự án sử dụng Scrum để quản lý thường bị mất kiểm soát trong phạm vị dự án vì Scrum chấp nhận và khuyến khích sự thay đổi. Nếu có quá nhiều sự thay đổi hoặc quá nhiều phản hồi tiêu cực từ khách hàng, một nhiệm vụ có thể bị lặp đi lặp lại nhiều lần mà không có được kết quả cụ thể.
Các team Scrum có rất nhiều buổi họp — ngoài các buổi họp định kỳ như Sprint planning và Sprint retropective, còn có những buổi Daily standup.
Áp dụng được Scrum một cách bài bản là rất khó đối với các team không phải là team công nghệ (nhưng không phải là không thể)