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à gì?
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.
Lịch sử ra đời của Scrum
"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.
Cách thức hoạt động của quy trình Scrum
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:
- Daily Standups. Như tên cho thấy, đứng hàng ngày xảy ra một lần một ngày. Đây là cơ hội để đội ngũ Scrum kết nối trong 15 phút và điều phối các hoạt động hàng ngày.
- Sprint retropective. Sẽ được tổ chức sau khi kết thúc một sprint. Trong quá trình sprint retropective, được dẫn dắt bởi Scrum master, team sẽ có cơ hội để nhìn lại sprint vừa rồi và đưa ra các sáng kiến để các sprint tiếp theo được tốt hơn.
Đ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 TRONG SCRUM
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.
- SPRINT Thông thường, một sprint sẽ kéo dài hai tuần, có thể ngắn hơn hoặc dài hơn tùy vào bối cảnh cụ thể của team. Để bắt đầu một sprint, leader sẽ cần xác định công việc cần phải hoàn thành (sprint backlog). Để có một sprint tốt nhất trong khả năng, bạn cần đảm bảo tất cả các task tồn đọng được ghi lại một cách cụ thể ở một nơi. Cân nhắc sử dụng các công cụ quản lý dự án như Asana hay Trello để sắp xếp tất cả thông tin này.
- SPRINT PLANNING Trước khi bắt đầu một sprint, bạn cần biết những nhiệm vụ cần tập trung trong sprint và tại sao lại cần tập trung trong sprint này. Trong buổi họp này, bạn sẽ cần xác định các mục tiêu của sprint và truyền đạt cho nhóm của mình lý do tại sao sprint này quan trọng. Từ đó, bạn sẽ xác định sprint backlog (nhiệm vụ tồn đọng) sẽ cần được giải quyết trong sprint này và cách hoàn thành công việc.
- DAILY STANDUP Họp nhanh mỗi ngày. Lên kế hoạch để team gặp nhau 15 phút mỗi ngày. Các cuộc họp hàng ngày là cơ hội để bạn xem xét lại về những gì team đang làm và nhanh chóng xác định được các cản trở team có thể gặp phải.
- SPRINT REVIEW Mỗi khi kết thúc một sprint, team nên cùng nhau review lại sprint. Trong buổi sprint review này, team sẽ trình bày những công việc đã được "Hoàn thành" để các bên liên quan phê duyệt hoặc kiểm tra.
- SPRINT RETROSPECTIVE Sau khi kết thúc mộ sprint là khoảng thời gian để thảo luận về diễn tiến của sprint đó và những gì có thể được cải thiện trong tương lai. Hãy luôn nhớ rằng tôn chỉ của Scrum là hoạt động cải tiến liên tục — vì vậy đừng ngại thử cách làm mới hoặc thực thi các chiến lược khác trong sprint tiếp theo.
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.
TẠO PHẨM CỦA SCRUM (ARTIFACTS)
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
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
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
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:
- Sản phẩm đã sẵn sàng để phát hành.
- Sản phẩm đã được test và sẵn sàng để phát hành trong môi trường beta (bản thử nghiệm).
- Sản phẩm đã được vượt qua test và có thể phát hành cho tất cả người dùng.
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).
3 VAI TRÒ TRONG SCRUM TEAM
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.
Product owner
Đâ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
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
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.
6 NGUYÊN TẮC CỦA SCRUM
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à:
- Linh hoạt theo tình hình thực tế. Nền tảng để xây dựng nên một Scrum team là tính minh bạch, kiểm tra và thích ứng.
- Tự tổ chức. Mặc dù Scrum team của bạn sẽ có vai trò và quy tắc, mọi thành viên Scrum đều được trao quyền để làm chủ các nhiệm vụ và công việc của họ. Scrum tin rằng quyền sở hữu chung dẫn đến các nhóm sáng tạo và năng động hơn.
- Cộng tác. Team sẽ tạo ra giá trị lớn nhất khi luôn đồng hành cùng nhau dù là trước, trong hay sau sprint.
- Sắp xếp ưu tiên dựa trên giá trị tạo ra. Mục tiêu của Scrum sprint là tạo ra nhiều giá trị nhất cho doanh nghiệp. Để làm được điều đó, bạn phải sắp xếp ưu tiên công việc của mình ngay từ khi bắt đầu quá trình Scrum.
- Timeboxing - có giới hạn về thời gian. Quy trình Scrum có nhiều hoạt động tiêu tốn thời gian, chẳng hạn như sprint, daily standup hay retropective. Vì Scrum hướng đến sự cải tiến liên tục, thế nên mỗi việc chỉ nên làm trong một thời gian nhất định, hết thời hạn đó thì cần chuyển sang nhiệm vụ tiếp theo, trong tương lai luôn có thể quay lại để cải thiện kết quả công việc.
- Liên tục cải tiến và phát triển. Sản phẩm đầu tiên sẽ không cần hoàn hảo. Nhưng bằng cách liên tục xây dựng và cải tiến, team sẽ có thể bắt kịp nhu cầu của khách hàng, điều chỉnh sản phẩm và kết quả cuối cùng để tạo ra giá trị cao nhất.
5 GIÁ TRỊ CỐT LÕI CỦA SCRUM
Để 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:
- Cam kết Nền tảng của một team chính là sự tin tưởng. Sự cam kết, tận tâm với tinh thần cải tiến liên tục để tìm ra giải pháp tốt nhất phải luôn được đề cao trong suốt cả sprint.
- Can đảm Trong một dự án, team rất có thể sẽ gặp những vấn đề khó nhằn và không có đáp án cụ thể. Trong những tình huống như thế, team cần can đảm trong việc đặt những câu hỏi mở, khó và trả lời trung thực để đi đến giải pháp tốt nhất.
- Tập trung Trong bất kỳ sprint nào, các công việc đều được lấy ra từ Product backlog. Team cần tập trung vào những công việc đã được chọn để có thể tạo ra được kết quả như mong đợi ở cuối mỗi sprint.
- Cởi mở Mọi thứ sẽ không bao giờ diễn ra hoàn hảo như kế hoạch. Các thành viên cần giữ được tinh thần cởi mở với những ý tưởng và cơ hội mới, điều này có thể vừa giúp họ phát triển bản thân, vừa có thể giúp cải thiện sản phẩm hoặc quy trình của dự án.
- Tôn trọng Cộng tác là chìa khóa của Scrum — và để mọi người có thể cộng tác tốt với nhau, các thành viên cần nhất là sự tôn trọng lẫn nhau, tôn trọng scrum master và quy trình Scrum.
Sự khác biệt giữa Scrum và Agile là gì?
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.
Kanban và Scrum, cái nào hơn?
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.
Team của tôi có phù hợp với Scrum không?
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:
Lợi ích của framework 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:
- Linh hoạt thích ứng: Scrum được thiết kế để team có thể tạo ra một sản phẩm đáp ứng tốt nhất với sự thay đổi của thị trường và yêu cầu của khách hàng. Và sự uyển chuyển đó có được là nhờ team có thể linh hoạt thay đổi cách thức hoạt động dựa trên kinh nghiệm rút kết được từ các sprint trước đó.
- Kỳ vọng rõ ràng: Vì framework Scrum phân công rất rõ vai trò và trách nhiệm cụ thể cho từng thành viên trong team Scrum, vì thế mọi người sẽ biết rất rõ mình cần phải làm gì trong một sprint.
- Sắp xếp ưu tiên dựa trên ROI (tỉ suất sinh lợi trên đầu tư): Điều này đặc biệt đúng đối với các dự án phát triển phần mềm, Scrum giúp team chọn ra được các tính năng quan trọng nhất để sắp xếp ưu tiên triển khai ở từng Sprint. Với Scrum, team không cần chờ toàn bộ dự án hoàn thiện mới có thể phát hành mà có thể cho ra mắt từng phần, từng tính năng trước để đảm bảo được các yêu cầu cơ bản nhất của người dùng, từ đó giúp việc đầu tư vào dự án nhanh chóng thu được những tín hiệu tích cực đầu tiên.
- Giảm rủi ro: Scrum sẽ giúp team tránh được những rủi ro nghiêm trọng và khó giải quyết vì các rủi ro đã được đánh giá ngay trong từng Sprint. Với cấu trúc chặt chẽ này, sẽ rất ít có sai sót nào có thể lọt ra ngoài tầm kiểm soát.
Những hạn chế của Scrum
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ể.
- Giải pháp: Đảm bảo xác định rõ mục tiêu và giới hạn của từng sprint. Ngoài ra, hãy đảm bảo rằng team của bạn rõ ràng về định nghĩa của của trạng thái "Hoàn thành", để không vượt quá mức độ "Hoàn thành". Nếu cần, hãy thực hiện quy trình kiểm soát thay đổi để tránh những vấn đề này.
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.
- Giải pháp: Nếu các buổi daily standup không hiệu quả, hãy tìm cách thay đổi. Chỉ định các thành viên khác đứng ở vai trò Scrum master để thu thập được những góc nhìn mới về dự án và quy trình.
Á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ể)
- Giải pháp: Nếu đã quyết định sử dụng Scrum để quản lý dự án, hãy đảm bảo rằng mọi người đều hiểu rõ về việc tại sao cần sử dụng Scrum cho dự án. Nếu có thể, hãy xác định các painpoint (nỗi đau) hiện tại và sắp đặt nó vào các sự kiện Scrum phù hợp. Ngoài ra, hãy lên kế hoạch tổ chức một số buổi đào tạo trong vài sprint đầu tiên để giúp team thành thục.
