Trong mô hình phát triển phần mềm hiện nay, chắc hẳn các bạn sẽ nghe tới rất nhiều những thuật ngữ như “Scrum”, “Agile”, “Scrum Master” … Vậy chúng là gì, có vai trò như thế nào trong phát triển phần mềm? Vai trò của từng vị trí trong 1 dự án Scrum như nào?
Scrum là gì?
Scrum là một quy trình phát triển sản phẩm theo phương pháp Agile và được xây dựng trên thuyết thực nghiệm. Scrum là khung làm việc để phát triển, chuyển giao và duy trì các sản phẩm phức tạp theo cách thức lặp và tăng trưởng (Theo Scrum Guide).
Với Scrum, sản phẩm được xây dựng trên 1 chuỗi các quy trình lặp lại (gọi là Sprint). Scrum có 3 yếu tố để tạo thành một mô hình quản lý tiến trình thực nghiệm gồm:
- Minh bạch (transparency): Quá trình và công việc phải được hiển thị rõ ràng cho những người thực hiện công việc cũng như những người tiếp nhận kết quả công việc.
- Kiểm tra (inspection): Các công việc và tiến trình hướng tới các mục tiêu đã thống nhất của Scrum phải được kiểm tra thường xuyên để phát hiện các vấn đề hoặc sự sai lệch không mong muốn, từ đó đưa ra sự điều chỉnh phù hợp.
- Thích ứng (adaptation): Nếu bất kỳ khía cạnh nào của quá trình lệch ra ngoài giới hạn cho phép hoặc nếu sản phẩm tạo thành không được chấp nhận, thì phải nhanh chóng đưa ra sự điều chỉnh để giảm thiểu sai lệch.
1.Các giá trị của Scrum
Việc áp dụng thành công Scrum phụ thuộc vào các thành viên trong Scrum Team hiểu và thành thạo 5 giá trị của Scrum:
- Cam kết (Commitment)
- Tập trung (Focus)
- Cởi mở (Openness)
- Tôn trọng (Respect)
- Dũng cảm (Courage)
2.Thành viên của một Scrum Team
Đơn vị cơ bản của Scrum là một nhóm nhỏ các thành viên gọi là Scrum Team. Trong Scrum Team, không có nhóm con hoặc hệ thống phân cấp.
Các thành viên Scrum Team có khả năng hoán đổi nghiệp vụ (cross-functional) , nghĩa là các thành viên có tất cả các kỹ năng cần thiết để tạo ra giá trị cho mỗi Sprint. Họ cũng có năng lực tự quản lý, nghĩa là họ tự quyết định ai làm gì, khi nào và làm như thế nào.
Scrum Team phải đủ nhỏ để luôn linh hoạt và đủ lớn để hoàn thành công việc quan trọng trong một Sprint, và thường là có 10 người trở xuống.
Nếu các Scrum Team trở nên quá lớn, nên xem xét tổ chức lại thành nhiều nhóm Scrum có sự gắn kết với nhau, mỗi nhóm tập trung vào cùng một sản phẩm.
Scrum xác định ba vai trò trách nhiệm cụ thể trong một Nhóm Scrum:Developers, Product Owner và Scrum Master.
2.1.Developers
Là những người cam kết tạo ra sản phẩm sau mỗi Sprint – đội ngũ thực hiện 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.
Các kỹ năng cụ thể mà Developers cần có thường rất rộng và sẽ thay đổi theo lĩnh vực công việc. Tuy nhiên, họ luôn phải chịu trách nhiệm về:
- Lập kế hoạch cho Sprint, Sprint Backlog
- Nâng cao chất lượng bằng cách tuân thủ Định nghĩa Hoàn thành
- Điều chỉnh kế hoạch hằng ngày sao cho đạt được Mục tiêu của Sprint
- Chịu trách nhiệm với tư cách là những người chuyên nghiệp
2.2.Product Owner
Product Owner có trách nhiệm tối đa hóa giá trị của sản phẩm tạo ra bởi công việc của Scrum Team.
Product Owner cũng chịu trách nhiệm chính trong việc quản lý Product Backlog hiệu quả, bao gồm:
- Phát triển và truyền đạt rõ ràng Mục tiêu Sản phẩm
- Tạo ra và truyền đạt rõ ràng các hạng mục Product Backlog
- Sắp xếp thứ tự ưu tiên các hạng mục trong Product Backlog
- Đảm bảo rằng Product Backlog là minh bạch, dễ thấy và dễ hiểu
2.3.Scrum Master
Scrum Master là những người có hiểu biết sâu sắc về Scrum, phục vụ cho Scrum Team, Product Owner và rộng hơn là phục vụ cho tổ chức, các bạn có thể tìm hiểu rõ hơn tại đây.
Một cách tổng quan nhất thì Scrum Master là người đảm bảo cho mọi thành viên hiểu và thực hiện đúng vai trò cũng như công việc của mình trong Scrum.
3.Các sự kiện trong Scrum
Mỗi sự kiện trong Scrum là một cơ hội để kiểm tra và điều chỉnh Scrum. Những sự kiện này được thiết kế đặc biệt để tạo ra sự minh bạch cần thiết. Nếu không thực hiện một sự kiện nào đó trong số những sự kiện đã chỉ dẫn sẽ dẫn đến hậu quả mất cơ hội để kiểm tra và thích ứng.
Scrum có 5 sự kiện chính: Sprint, Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective.
3.1.Sprint
Sprint được coi như nhịp tim của Scrum, nơi các ý tưởng được biến thành giá trị.
Chúng có độ dài cố định từ một tháng trở xuống để tạo sự nhất quán. Một Sprint mới bắt đầu ngay sau khi kết thúc Sprint trước.
Tất cảcác công việc cần thiết để đạt được Mục tiêu Sản phẩm, bao gồm cả các buổi Sprint Planning, Daily Scrums, Sprint Review, và Sprint Retrospective, đều diễn ra trong Sprint.
Các Sprint cho phép khả năng dự đoán bằng cách đảm bảo kiểm tra và điều chỉnh tiến độ thực hiện mục tiêu sản phẩm ít nhất mỗi tháng một lần. Có nhiều phương pháp thực hành khác nhau để dự báo tiến độ, chẳng hạn như các biểu đồ burn-down, burn-up hoặc biểu đồ dòng chảy tích lũy (cumulative flow).
Một Sprint có thể bị hủy bỏ nếu mục tiêu Sprint không đáp ứng được mục tiêu chung đề ra. Chỉ Product Owner mới có quyền hủy Sprint.
3.2.Sprint Planning
Sprint Planning khởi đầu Sprint bằng cách sắp xếp công việc cần thực hiện cho Sprint. Kế hoạch kết quả này được tạo nên bởi sự cộng tác của toàn bộ Scrum Team.
Product Owner phải đảm bảo rằng những người tham dự được chuẩn bị để thảo luận về các hạng mục Product Backlog quan trọng nhất và cách chúng phải có liên kết với mục tiêu chung của sản phẩm.
Có 3 chủ đề chính sẽ được đưa ra thảo luận trong buổi Sprint Planning là:
- Sprint này mang lại giá trị gì?
- Các công việc có thể hoàn thành trong Sprint này?
- Công việc đã chọn sẽ được hoàn thành bằng cách nào?
Sprint Planning có khung thời gian tối đa là 8 giờ cho Sprint một tháng. Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn.
3.3.Daily Scrum
Mục đích của Daily Scrum là kiểm tra tiến độ thực hiện Mục tiêu Sprint và điều chỉnh Sprint Backlog khi cần thiết, điều chỉnh kế hoạch sắp tới.
Daily Scrumlà một sự kiện kéo dài 15 phút dành cho Developers của Scrum Team. Để giảm bớt sự phức tạp, nó được tổ chức vào thời gian cố định và diễn ra hằng ngày trong Sprint.
3.4.Sprint Review
Mục đích của Sprint Review là kiểm tra kết quả công việc của Sprint và xác định các sự điều chỉnh trong tương lai. Scrum team trình bày kết quả công việc của họ cho các bên liên quan chính và thảo luận về mục tiêu – tiến trình thực hiện Sprint tiếp theo.
Product Backlog cũng có thể được điều chỉnh trong một buổi Sprint Review để đáp ứng các cơ hội mới.
Sprint Review là sự kiện gần cuối cùng của một Sprint và có khung thời gian tối đa là 4 giờ cho Sprint có khung một tháng. Đối với Sprint ngắn hơn, sự kiện này thường ngắn hơn.
3.5.Sprint Retrospective
Mục đích của Sprint Retrospective là hoạch định biện pháp để tăng chất lượng và hiệu quả.
Scrum Team sẽ kiểm tra xem Sprint đã diễn ra như thế nào trên các khía cạnh: các cá nhân, sự tương tác, quy trình, công cụ và định nghĩa hoàn thành. Từ đó xác định những thay đổi hữu ích nhất để cải thiện hiệu quả của nhóm. Những cải tiến có ảnh hưởng nhất nên được thực hiện càng sớm càng tốt. Chúng thậm chí có thể được đưa vào Sprint Backlog của Sprint tiếp theo.
Sprint Retrospective là sự kiện cuối cùng của Sprint. Nó có khung thời gian tối đa là 3 giờ cho Sprint có khung một tháng. Đối với Sprint ngắn hơn, sựkiện thường ngắn hơn.
Tổng kết
Trên đây là những kiến thức cơ bản về Scrum mà mình đã tìm hiểu và tóm tắt, nội dung chủ yếu là kiến thức ngắn gọn được rút ra từ Scrum Guide 2020 và Scrum Guide 2017.
Lý thuyết chung về Scrum có thể hơi khó hình dung đối với những bạn mới chỉ bắt đầu đọc tài kiệu mà chưa tham gia vào quá trình thực tế. Tuy nhiên hiểu một cách đơn giản thì một dự án hoạt động theo Scrum có nghĩa là bạn chia một công việc chung thành các phần công việc nhỏ hơn với các mục đích khác nhau và tổng kết lại các mục tiêu nhỏ đó sẽ tạo nên kết quả là mục tiêu lớn chung – đã được đề ra trước đó. Mỗi phần công việc nhỏ sẽ có các quá trình thực hiện lặp lại và được kiểm tra một cách kỹ càng.
Việc hiểu rõ vai trò trách nhiệm của mình trong dự án sẽ góp phần giúp cho dự án phát triển hoàn thiện, tránh được các rủi ro không đáng có và cũng phần nào giúp bản thân xác định được lộ trình phát triển nghề nghiệp trong tương lai.
Mong rằng bài viết sẽ hữu ích đối với các bạn cũng đang tìm hiểu và xác định lộ trình phát triển như mình. 
Tài liệu tham khảo
https://hocvienagile.com/scrum-la-gi/
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf
Nguồn: viblo.asia