Scrum Framework - Mô hình phát triển phần mềm phổ biến nhất

Trong bối cảnh phát triển phần mềm ngày càng đòi hỏi sự linh hoạt cao do sự thay đổi liên tục của thị trường công nghệ, nhu cầu về một phương pháp quản lý linh hoạt, có khả năng thích nghi với thay đổi liên tục của thị trường và yêu cầu người dùng là rất lớn. Trong bối cảnh như hiện nay, Scrum Framework – một bộ khung làm việc tiêu chuẩn ngày càng được các tổ chức phần mềm tiếp nhận và ứng dụng rộng rãi trong quá trình phát triển phần mềm.

Scrum Framework là gì?

Scrum là một khung làm việc linh hoạt giúp các nhóm phát triển sản phẩm thích ứng nhanh với các vấn đề phức tạp trong quá trình phát triển một dự án phần mềm. Bộ khung giúp các nhà phát triển thích ứng nhanh với các thay đổi, đồng thời đảm bảo tiến độ, chất lượng và giá trị của sản phẩm. Scrum cung cấp một bộ quy tắc, vai trò, sự kiện và sản phẩm đầu ra – tất cả đều được thiết kế để tăng cường sự minh bạch trong việc trao đổi thông tin nội bộ giữa các bên và giúp cho quá trình làm việc trở nên hiệu quả nhất có thể. Điểm đặc biệt trong Scrum mỗi chu kỳ phát triển – gọi là Sprint – được xem như là một vòng đời phát triển phần mềm (SDLC) thu nhỏ, bao gồm việc lên kế hoạch, thực thi, kiểm thử và phản hồi. Scrum sẽ được tổ chức theo nguyên tắc 3-5-3: 3 vai trò (Roles), 5 sự kiện (Events) và 3 sản phẩm đầu ra (Artifacts).

Đọc thêm: Vòng đời phát triển sản phẩm (Software Life Cycle Development) và vai trò của IT Business Analyst

Ba vai trò cốt lõi trong Scrum Framework

Trong một dự án sử dụng Scrum Framework sẽ có ba vai trò chính: Product Owner (Quản lý sản phẩm), Scrum Master (Quản lý Scrum) và Development Team (Đội ngũ phát triển sản phẩm). Các vai trò trong nhóm phát triển sản phẩm của một dự án nằm trong Scrum Framework đề tự tổ chức và tự kiểm soát công việc của mình với một mục tiêu chung – tạo ra một sản phẩm đáp ứng đầy đủ nhu cầu của khách hàng trong khoảng thời gian và chi phí cho phép.

• Product Owner (Quản lý sản phẩm): Đây là vai trò đại diện tiếng nói cho khách hàng. Người này là người hiểu rõ nhất những mong muốn, nhu cầu và kỳ vọng của các bên liên quan đến sản phẩm (Stakeholders), và là người duy nhất chịu trách nhiệm tối đa cho giá trị mà sản phẩm mang lại cho khách hàng và tổ chức. Công việc chính của một Product Owner là thu thập hiểu rõ nhu cầu của khách hàng để điều hướng đội ngũ phát triển tạo ra một sản phẩm đúng. Họ chính là người quản lý Backlog – Danh sách các yêu cầu, tính năng, vấn đề cần giải quyết và liên tục cập nhật thứ tự ưu tiên sao cho mang lại giá trị cao nhất cho khách hàng.
• Scrum Master (Quản lý Scrum): Đây sẽ là người đảm bảo đội ngũ làm việc tuân thủ đúng các bước trong Scrum Framework, loại bỏ rào cản khi làm việc và hỗ trợ đội ngũ khi cần thiết. Người này đóng vai trò như một người huấn luyện, người gỡ rối và là người bảo vệ nhóm khỏi những yếu tố cản trở tiến độ làm việc. Ví dụ về các công việc của một Scrum Master sẽ bao gồm huấn luyện mọi người về cách hoạt động và phối hợp trong một dự án Scrum, hỗ trợ cài đặt phần mềm, xin cấp quyền truy cập để phục vụ công việc hoặc tổ chức các cuộc họp nhằm cải thiện hay điều chỉnh quy trình nếu cần thiết.
• Development Team (Đội ngũ phát triển sản phẩm): Đây sẽ là nhóm người làm việc trực tiếp để tạo ra một sản phẩm phần mềm hoàn chỉnh. Một đội ngũ phát triển sản phẩm hoàn chỉnh sẽ bao gồm người thiết kế (Designer), Lập trình viên (Developers), người kiểm thử (Tester) và người phân tích kinh doanh (Business Analyst). Tất cả các thành viên trong nhóm phát triển đều có quyền lợi và tiếng nói như nhau, do đó việc phối hợp làm việc dựa trên mục tiêu chung và sự tôn trọng lẫn nhau là vô cùng cần thiết để cả đội ngũ có thể làm việc hiệu quả. Nhóm có toàn quyền quyết định cách làm việc, phân chia công việc và cam kết tạo ra những sản phẩm hoàn chỉnh, có thể sử dụng được sau mỗi Sprint.

Một điều quan trọng khi làm việc cùng nhau giữa các bên khi sử dụng Scrum Framework đó là DOD (Definition of Done) – sự định nghĩa rõ ràng, cụ thể về khi nào thì một công việc được coi là hoàn thành. Điều này nhằm đảm bảo sự minh bạch và chất lượng của sản phẩm đầu ra, tránh trường hợp các bên không thống nhất được về tiêu chí của sản phẩm đầu ra, dẫn đến những bất đồng sau này.

Năm sự kiện chính trong Scrum Framework

Scrum Framework sẽ bao gồm 5 sự kiện chính giúp nhóm vận hành linh hoạt và nhịp nhàng xuyên suốt cả dự án: Sprint, Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective.

• Sprint - một chu kỳ phát triển cố định, là trái tim của Scrum. Một sprint thường kéo dài từ 2 đến 4 tuần. Sprint thường có độ dài ổn định và không thay đổi trong suốt quá trình thực hiện. Mỗi sprint bắt đầu bằng một danh sách các việc cần làm và kết thúc bằng một sản phẩm có thể sử dụng được (Product Increment)
• Sprint Planning – Đây sẽ là cuộc họp đầu tiên để lập kế hoạch cho một Sprint, thường sẽ kéo dài từ 4 -8 tiếng với sự tham gia của cả 3 vai trò.  Trong buổi họp này, Product Owner sẽ trình bày danh mục các công việc cần làm theo thứ tự ưu tiên trong sprint đó. Nhóm phát triển sau đó sẽ thảo luận và ước lượng khối lượng công việc, đưa ra cam kết hợp lý về những gì có thể hoàn thành trong một khung thời gian. Kết quả của buổi họp này sẽ là xác định mục tiêu cụ thể của Sprint và lập ra danh sách công việc của Sprint – Sprint Backlog.
• Daily Scrum – Đây là cuộc họp ngắn kéo dài 15 phút diễn ra hàng ngày, thường vào đầu giờ làm việc. Nhóm phát triển cùng Scrum Master sẽ gặp nhau để cùng cập nhật tiến độ, chia sẻ khó khăn và đảm bảo tất cả mọi người đang đồng bộ hướng về mục tiêu Sprint. Mỗi người sẽ trả lời ba câu hỏi: Hôm qua đã làm gì, hôm nay sẽ làm gì và có gặp trở ngại nào không?
• Sprint Review – Đây sẽ là cuộc họp vào cuối Sprint, thường sẽ kéo dài khoảng 4 tiếng. Sau khi sản phẩm được hoàn thành vào cuối mỗi Sprint, nhóm phát triển sẽ trình bày những gì đã hoàn thành cho Product Owner và các Stakeholders. Đây sẽ làm cơ hội để thu thập phản hồi, đánh giá mức độ đáp ứng mục tiêu và ra quyết định cho Sprint tiếp theo. Nếu công việc chưa hoàn thành, Product Owner sẽ ra quyết định có đưa các đầu mục công việc sang Sprint tiếp theo hay không.
• Sprint Retrospective – Cuộc họp cuối cùng của một Sprint ngay sau Sprint Review, kéo dài khoảng 3 tiếng. Đây sẽ là lúc cả team ngồi nhìn lại quá trình làm việc cùng nhau và đánh giá những gì đã làm tốt và chưa tốt, thống nhất lại cách thức hợp tác và đề xuất cải tiến quy trình, công cụ, kỹ năng hay phương thức giao tiếp. Thông thường Scrum master sẽ là người dẫn dắt và đảm bảo cuộc họp mang lại giá trị thực tế.

Đọc thêm: BACCM – Mô hình cơ bản dành cho các Business Analyst

3 sản phẩm đầu ra của một Sprint trong Scrum Framework

Ba sản phẩm tạo ra trong Scrum sẽ giúp cho việc quản lý công việc trở nên minh bạch, hỗ trợ việc đo lường kết quả đầu ra.

• Product Backlog: là danh sách tất cả các yêu cầu, tính năng, vấn đề, công việc cần làm cho sản phẩm. Product Owner là người duy nhất có quyền chỉnh sửa backlog này, và họ sắp xếp thứ tự ưu tiên theo giá trị mang lại cho khách hàng. Ví dụ, một ứng dụng ngân hàng có thể có các hạng mục trong Product Backlog như: đăng nhập bằng vân tay, chuyển tiền, thanh toán hóa đơn, xem lịch sử giao dịch, gửi tiết kiệm online, mở tài khoản mới.
• Sprint Backlog: đây là danh sách các mục tiêu mà nhóm phát triển cam kết hoàn thành trong một sprint cụ thể. Ví dụ: trong Sprint 1, nhóm có thể lựa chọn 3 mục chính từ Product backlog để thực hiện: tạo chức năng đăng nhập bằng vân tay, xây dựng giao diện chuyển tiền nội bộ và thanh toán hóa đơn.
• Product Increment: đây là phần tổng hợp những phần việc đã hoàn thành trong Sprint – chính là sản phẩm có thể sử dụng được. Nếu sau Sprint 1, nhóm đã hoàn thành chức năng đăng nhập và chuyển tiền nội bộ, được kiểm thử đầy đủ và sẵn sàng triển khai, thì đó chính là Product Increment của Sprint đó.

Kết

Với một cấu trúc chặt chẽ, Scrum thúc đẩy sự tự chủ, trách nhiệm và cải tiến liên tục trong từng Sprint nhỏ. Khi được áp dụng đúng cách, Scrum sẽ giúp cho các nhóm phát triển phần mềm hoạt động trơn tru và tạo ra những sản phẩm phù hợp và có giá trị cao với người dùng.