Tổng quan về quy trình Scrum và áp dụng Scrum trong quản lý dự án

Có nhiều nhận định cho rằng “Scrum tăng khả năng thành công cho dự án lên gấp 3 lần”. Nhưng cần phải học hỏi kỹ lưỡng để tránh sai lầm. Sau đây, Vinaseco xin trình bày những điểm nổi bật nhất về Scrum. Chúng tôi mong rằng những thông tin này sẽ có ích cho bạn đọc.

1. Khái niệm quy trình Scrum

Scrum là một quy trình phát triển phần mềm theo mô hình linh hoạt (agile). Công nghệ Agile cung cấp rất nhiều phương pháp luận, quy trình và các thực nghiệm để cho việc phát triển phần mềm trở nên nhanh chóng và dễ dàng. Hiện nay tại Việt Nam, quy trình này đang được thử nghiệm tại các đội phát triển phần mềm của một số công ty lớn.

2. Vai trò của các thành viên

Người chủ sản phẩm: Là tiếng nói của khách hàng trong việc đánh giá sản phẩm. Người hiểu rõ cái mà khách hàng cần. Thông thường PO (Product Owner) là khách hàng hoặc một Business Analysis, chịu trách nhiệm cho những điều sau:

– Xác định tính năng của sản phẩm.

– Quyết định về ngày đưa ra và nội dung.

– Ưu tiên hoá các tính năng tương ứng với nhu cầu của khách hàng.

– Điều chỉnh các tính năng sau 30 ngày.

– Chấp nhận hay bác bỏ kết quả công việc.

Người chủ Scrum (Scrum Master): Là người chịu trách nhiệm đảm bảo thành viên dự án tuân thủ phương thức làm việc. Công việc chính của SM là loại bỏ những thứ cản trở sự thành công của dự án. Đây là người lãnh đạo tổ làm việc chặt chẽ cùng với người chủ sản phẩm để:

– Đảm bảo rằng tổ hoạt động và có năng suất đầy đủ.

– Tạo khả năng cho hợp tác chặt chẽ qua tất cả các vai trò và chức năng.

– Che chắn cho tổ khỏi bị can nhiễu bên ngoài và đảm bảo rằng qui trình được tuân theo

Tổ, nhóm (Team):

– Thực hiện các task trong backlog, xây dựng sản phẩm đúng với yêu cẩu của khách hàng.

– Xuyên chéo chức năng, với các thành viên có kinh nghiệm.

– Lựa chọn mục đích việc chạy nước rút (Sprint) và xác định kết quả công việc.

– Có quyền tự tổ chức bên trong biên giới của hướng dẫn để đạt tới mục đích của Sprint.

– Demo kết quả công việc cho người chủ sản phẩm.

3. Các cuộc họp cần thiết

– Sprint Planning Meeting (Họp kế hoạch Sprint)

– Daily Scrum and Sprint Execution (Họp hằng ngày)

– Sprint Review Meeting (Họp sơ kết )

– Sprint Retrospective Meeting (Họp cải tiến Sprint)

4. Tài liệu của quy trình Scrum

Product Backlog: 

Là một danh sách các đầu mục cần phải làm để phát triển sản phẩm bao gồm đủ loại như chức năng của sản phẩm, lỗi cần sửa, nghiên cứu công nghệ hay những việc công việc liên quan khác. Những đầu mục này thường được mô tả dưới dạng “câu chuyện người dùng” (user story). Ví dụ như “Là người dùng, tôi muốn xem lại danh sách các sản phẩm đã chọn trong giỏ hàng để tôi có thể biết được tôi đã chọn những gì”.

Sprint Backlog:

Là một danh sách các đầu mục mà nhóm cam kết hoàn thành trong Sprint sau buổi họp sơ kết Sprint. Trong thời gian diễn ra Sprint, nhóm phát triển sẽ chỉ tập trung vào danh sách này và cập nhật tiến độ hoàn thành của chúng.

Biểu đồ Burndown (Burndown chart):

Được dùng để đo tiến độ của Sprint hay dự án. Không giống như biểu đồ Gantt chart (biểu đồ Gantt cho thấy ai làm việc gì và mất bao nhiêu thời gian để hoàn thành) thì biểu đồ Burndown sẽ cho thấy nhóm còn bao nhiêu thời gian để hoàn thành công việc đã được định ra lúc đầu. Biểu đồ Burndown đi xuống là một dấu hiệu tốt cho tiến độ hoàn thành công việc.

Bảng công việc:

Được dùng để hiển thị những “câu chuyện người dùng” trong Sprint, những công việc nào cần làm cho “câu chuyện” đó, trạng thái của chúng cũng như những ghi chú cần thiết khác. Bạn nên lưu ý “Bảng công việc” theo đúng nghĩa của nó là công việc được biểu diễn trên một tấm bảng trắng. Nhóm sẽ dùng những sticky note nhiều màu sắc để ghi thông tin và dán lên trên tấm bảng đó. Việc đó sẽ giúp nhóm cập nhật thông tin một cách trực quan và nhanh hơn. Tuy nhiên, có một số dự án, nếu đội phát triển không cùng một nơi thì có thể dùng công cụ để thể hiện “Bảng công việc” nhưng bản chất thì không thay đổi.

5. Cách triển khai quy trình Scrum (10 bước)

– Bước 1: Thu nhập các đặc điểm của sản phẩm (backlog) trong đơn đặt hàng ~> LẬP TEAM VÀ TÌM RA PO (Product owner).

– Bước 2: Ước lượng đầy đủ các yêu cầu về sản phẩm đầu ra ~> ƯỚC LƯỢNG CÔNG VIỆC CHO MỖI TEAM

– Bước 3: Lên kế hoạch phát triển các vòng lặp Sprint ~> XÁC ĐỊNH KHOẢNG THỜI GIAN, MỤC TIÊU, PHÂN TÍCH CÁC YÊU CẦU

– Bước 4: Lên kế hoạch phát triển các nhiệm vụ của Sprint ~> ƯỚC LƯỢNG T/GIAN LÀM TỪNG TASK(GIỜ), NHẬN DẠNG TASK QUAN TRỌNG

– Bước 5: Tạo ra không gian làm việc cộng tác cho tất cả mọi người ~> VẼ NHỮNG VẤN ĐỀ ĐỂ ĐÁNH GIÁ

– Bước 6: Xây dựng từng Sprint, lập trình, kiểm thử và điều chỉnh thời gian để có hiệu quả tốt nhất.

– Bước 7: Báo cáo kết quả ~> ĐÃ ĐẠT ĐƯỢC GÌ, SẼ HOÀN THÀNH GÌ VÀ KHÓ KHĂN

– Bước 8: Tổng hợp kết quả trên biểu đồ

– Bước 9: Xem xét để hoàn tất

– Bước 10: Đánh giá, phản ánh và lặp lại ~> TRÌNH BÀY KẾT QUẢ, PHẢN HỒI VÀ THỜI HẠN CỦA SPRINT.

6. Ưu điểm và nhược điểm của quy trình Scrum:

Ưu điểm:

– Linh hoạt, không cố định thời gian hoàn thành và yêu cầu (được xác định khi phát triển thực tế)

– Phân phối sản phẩm mềm dẻo, thời gian biểu linh hoạt

– Chất lượng sản phẩm tốt và giảm rủi ro sản xuất, chi phí thấp

– Tốc độ phát triển nhanh, tiết kiệm thời gian

– Các bugs (lỗi) và các vấn đề được phát hiện sớm

– Khách hàng nhanh chóng thấy được sản phẩm qua đó đưa ra phản hồi sớm.

– Giảm thời gian dành cho quản lý, tăng thời gian dành cho việc phát triển

– Có khả năng áp dụng được cho những dự án mà yêu cầu khách hàng không rõ ràng ngay từ đầu.

Nhược điểm:

– Quy mô đội ngũ: Việc tổ chức các cuộc họp sẽ không khả thi và nền tảng của phương pháp này trở nền suy yếu nếu quá số lượng (7-10).

– Số lượng yêu cầu nhiều: có thể khó quản lý vì các khía cạnh khác nhau của chúng ~> có thể làm chậm quá trình xác nhận.

– Chất lượng phát triển: Số lượng đội ngũ càng tăng, chất lượng càng khó kiểm soát

– Vai trò của PO rất quan trọng, PO là người định hướng sản phẩm. Nếu PO làm không tốt sẽ ảnh hưởng đến kết quả chung

– Khi phát triển dự án theo Scrum thì dự án sẽ không có detail design. Do vậy mỗi thành viên của dự án cũng sẽ là một người thiết kế hệ thống

Do vậy nếu phối hợp không tốt thì có thể dẫn đến việc sản phẩm rất khó “sửa chữa” (thực tế ở VN, không có nhiều dự án có detail design)

7. So sánh các quy trình truyền thống

Mô hình waterfall

Mô hình thác nước (waterfall) chia dự án phần mềm gồm các giai đoạn: đặc tả yêu cầu, thiết kế hệ thống, cài đặt (lập trình), kiểm tra và bảo trì. Quy trình này dễ quản lý nhưng lại kém linh hoạt và không hiệu quả bởi nếu có sự thay đổi ở các giai đoạn sau sẽ ảnh hưởng rất lớn đến các giai đoạn trước.

Mô hình spiral

Quy trình xoắn ốc (spiral) chia dự án thành các giai đoạn: lập kế hoạch, phân tích rủi ro, giao tiếp khách hàng, đánh giá lại, sản xuất và phân phối. Nó vẫn chưa được sử dụng rộng rãi.

(Scrum phù hợp cho những dự án có nhiều sự thay đổi và yêu cầu tốc độ cao)