Trong bài trước chúng ta đã hiểu cơ bản về SCRUM, những thành tố cơ bản của SCRUM. Trong bài này chúng ta sẽ nói về cách áp dụng SCRUM vào tổ chức và thực hiện dự án, với hy vọng sẽ giúp các bạn có cái nhìn rõ hơn về SCRUM.
Bài này sẽ đi từng bước áp dụng SCRUM nhằm giúp các bạn dễ dàng thực hành áp dụng và đánh giá mô hình này. Có thể nó sẽ không thể khái quát tất cả các khía cạnh của SCRUM nhưng sẽ đơn giản và dễ tiếp cận khi chúng ta mới bắt đầu áp dụng SCRUM.
Trong bài này chúng ta thống nhất là thực hiện dự án nên chúng ta sẽ dùng từ dự án thay cho sản phẩm.
- Chuẩn bị
SCRUM được áp dụng cho giai đoạn phát triển của dự án. Do vậy, các công việc như nghiên cứu khả thi, hồ sơ giải pháp (Proposal), v…v… được xem như đã hoàn tất. Bây giờ là giai đoạn chuẩn bị cho quá trình phát triển sản phẩm. Các hồ sơ đầu vào bao gồm:
Hồ sơ đề xuất của dự án (Proposal): Đây là hồ sơ mô tả dự án gồm các yêu cầu, giải pháp của dự án như:
- Mô tả sản phẩm: Mục đích, Chức năng, Yêu cầu chi tiết các chức năng
- Giải pháp: kiến trúc, công nghệ, phương pháp phát triển, triển khai
- Thời gian phát triển dự án
- Tài chính được cấp cho dự án
Các công tác chuẩn bị như con người, nơi làm việc, máy móc v.v….
Công cụ quản lý SCRUM:
- File Excel
- Hệ thống phần mềm quản lý như Scrumdo.com hoặc Redmine
Sau quá trình chuẩn bị chúng ta thực hiện các bước sau để áp dụng SCRUM.
- Thành lập nhóm dự án
Trong bài trước chúng ta đã biết thành phần của nhóm dự án gồm: Product Owner, Scrum Master và Team Development. Chúng ta xem lại cấu trúc nhóm dự án:
Ngoài ra, chúng ta cần một đội kiểm thử (Tester) nhằm giúp kiểm thử cho dự án. Đội Tester nên độc lập và thực hiện việc kiểm thử như một dịch vụ cho dự án.
Chọn Product Owner
Product Owner là người sở hữu sản phẩm, hiểu rõ nhất về sản phẩm và các yêu cầu của sản phẩm. Thông thường vai trò này được đảm nhiệm bởi khách hàng. Nếu khách hàng không có người thực hiện việc này thì có thể người đóng vai trò Business Analyst của công ty phần mềm hoặc của đơn vị tư vấn thực hiện vai trò này. Product Owner chịu trách nhiệm về yêu cầu đầu ra của sản phẩm và là người chấp nhận sản phẩm.
Chọn Scrum Master
Scrum Master là người quản lý hỗ trợ, nghĩa là không phải người đưa ra quyết định cho dự án mà là người hỗ trợ. Scrum Master sắp xếp, tổ chức, hỗ trợ cho nhóm dự án hoạt động và theo dõi sự hoạt động của nhóm dự án để đáp ứng yêu cầu của SCRUM.
Xây dựng Team Development
Nhóm dự án, thành phần chủ lực phát triển dự án, nhóm dự án nên từ 4-7 người để vận hành có năng suất cao. Nhóm phải tập hợp những người đủ kiến thức và kỹ năng để phát triển sản phẩm (kỹ năng lập trình, phân tích thiết kế hệ thống, kiến thức về sản phẩm v.v..). Theo yêu cầu của SCRUM nhóm làm việc dựa trên khả năng làm việc độc lập của các thành viên và tương tác bình đẳng với nhau. Quyết định được đưa ra dựa trên sự thống nhất chung của nhóm.
Tuy nhiên, nếu nhóm dự án có nhiều người mới hoặc không đều nhau, chúng ta có thể có một nhóm trưởng (Team Leader) để điều phối việc thảo luận, phân chia công việc và ra quyết định. Cần lưu ý, không nên lạm dụng vai trò của nhóm trưởng, việc càng đưa nhóm về sát với yêu cầu của SCRUM càng sớm càng tốt để tăng hiệu quả của nhóm.
Dựa trên yêu cầu của dự án (khối lượng công việc, thời gian hoàn thành), nhân lực hiện có bạn xây dựng nhóm dự án phù hợp để phát triển sản phẩm đúng chất lượng và thời hạn bàn giao sản phẩm. Sau đó khai báo vào bảng nhân lực theo mẫu sau:
- Hình thành ProductBacklog
ProductBacklog là thành tố quan trọng trong SCRUM, nó mô tả danh sách chức năng cần phát triển của sản phẩm. ProductBacklog được Product Owner tạo ra và chịu trách nhiệm cập nhật theo từng giai đoạn của dự án. Kèm Product Backlog là các yêu cầu chi tiết cho từng chức năng.
ProductBacklog giai đoạn đầu có thể được lấy từ hồ sơ đề xuất của dự án (Proposal). Nếu vì lý do nào đó bạn chưa có tài liệu này thì bạn có thể xây dựng nó thông qua việc phân tích và thiết kế sơ bộ của dự án. Bảng vẽ Use Case sẽ giúp bạn dễ dàng xây dựng được Product Backlog. Chúng ta sẽ bàn về bảng vẽ này trong phần Phân tích, thiết kế hệ thống theo mô hình hướng đối tượng sử dụng UML.
Product Backlog trên chỉ minh họa để bạn dễ hình dung, bạn cần khảo sát và phân tích kỹ để xác định chính xác hơn các chức năng hệ thống cần xây dựng để xây dựng Product Backlog hoàn chỉnh.
Point là đơn vị tính về effort (nỗ lực hay công) trong quá trình sản xuất phần mềm. Nó có thể là 1 giờ, một buổi, một ngày tùy theo qui định của bạn. Ở đây chúng ta lấy ví dụ là 1 buổi = 4 giờ của một Lập trình viên trung bình.
- Sprint Planning meeting và hình thành Sprint Backlog
Giai đoạn này bạn đã thực sự bước vào giai đoạn phát triển của dự án. Chúng ta cần nhìn lại qui trình của SCRUM đã trình bày ở phần trước:
Chúng ta thấy SCRUM chia dự án ra thành nhiều Sprint, mỗi Sprint từ 2-4 tuần và lặp lại cho đến khi hết ProductBacklog. Các Sprint phải đảm bảo các yếu tố sau:
- Phải xác định rõ được Sprint Backlog (danh sách chức năng) để phát triển trong Sprint này
- Phải Release được
- Phải phân công được công việc hiệu quả cho các thành viên trong nhóm dự án
- Do vậy, bạn cần có cuộc họp Sprint Planning để lên kế hoạch cho mỗi Sprint. Cuộc họp này sẽ:
- Thảo luận và chọn ra danh sách các chức năng thực hiện
- Xác định ngày bắt đầu, ngày kết thúc, kết quả đầu ra
- Phân công công việc của từng thành viên
- Bàn các giải pháp cho các vấn đề chung cho Sprint
- Kết thúc cuộc họp sẽ hình thành được Sprint Backlog.
- Daily Scrum Meeting
Daily Scrum Meeting là một Process rất tuyệt vời trong Scrum, nó giúp Team phát hiện sớm các vấn đề phát sinh trong quá trình phát triển, đồng bộ công việc giữa các thành viên và là cách vận dụng teamwork rất tốt.
Bạn cần nhớ rằng mỗi cuộc họp Daily Scrum được thực hiện hàng ngày và chỉ nên kéo dài 15 phút và mỗi thành viên trả lời đúng 3 câu:
- Hôm qua bạn làm gì?
- Bạn gặp những vấn đề gì?
- Hôm nay bạn làm gì?
Sau khi các thành viên đã thông báo toàn bộ những nội dung trên, các thành viên quay về làm việc. Scrum Master sắp xếp các cuộc họp riêng để giải quyết các vấn đề phát sinh.
Bạn có thể chọn họp cuối hoặc đầu ngày, theo quan điểm của chúng tôi, chúng tôi khuyên bạn họp đầu ngày để kích thích tinh thần làm việc của các thành viên.
Những vấn đề được phát hiện sẽ được xử lý trong một cuộc họp riêng có những thành viên liên quan chứ không giải quyết trong cuộc họp Dialy Scrum.
Việc duy trì cuộc họp này cũng giống như bạn cần ôn bài mỗi ngày thay vì phải chờ đến kỳ thi cuối kỳ mới vắt chân lên cổ mà chạy. Lúc đây nguy cơ trễ rất cao mà chất lượng cũng không đảm bảo.
- Sprint Review Meeting
Sprint Review Meeting là cuộc họp rà soát kết quả thực hiện của mỗi Sprint. Nó xem xét:
- Kết quả, chất lượng của những stories đã thực hiện xong
- Những Stories cần chuyển sang Sprint tiếp theo
- Xem xét và giải quyết các vấn đề phát sinh
- Rút ra bài học kinh nghiệm
Kết quả cuộc họp này sẽ được sử dụng cho cuộc họp Sprint Planing cho Sprint tiếp theo.
Tiếp tục lặp lại qui trình trên cho đến khi hoàn tất hết danh sách stories trên Product Backlog bạn sẽ hoàn thành dự án.
- Kết luận
Như vậy bạn đã biết cách đơn giản để áp dụng SCRUM vào các dự án. Trong quá trình áp dụng sẽ phát sinh những vấn đề, việc giải quyết các vấn đề sẽ giúp bạn hiểu rõ hơn về SCRUM. Chúc các bạn thành công.
