Trong ngành công nghiệp phần mềm, phương thức sản xuất phần mềm có một vai trò vô cùng quan trọng, nó quyết định cấu trúc tổ chức, qui trình phát triển, khả năng thành công của các dự án. Trong những năm gần đây SCRUM nổi lên như một phương thức tổ chức sản xuất ưu việt được nhiều công ty phần mềm áp dụng và thành công.
Nhằm giúp các bạn hiểu rõ hơn về phương thức này, chúng tôi chia sẻ loạt bài Giới thiệu cơ bản về Srcum, cách tổ chức nhóm và teamwork trong SCRUM, so sánh với mô hình truyền thống và cách thức chuyển từ mô hình sản xuất truyền thống sang SCRUM. Hy vọng, sẽ giúp các bạn có cái nhìn khái quát về phương thức này và nghiên cứu áp dụng cho đơn vị mình.
- Khái niệm về SCRUM
SCRUM là một phương thức phát triển phần mềm chỉ ra cách để Team (nhóm phát triển) làm việc một cách hiệu quả để tạo ra sản phẩm phần mềm. Với nguyên tắc chủ đạo là chia nhỏ phần mềm cần sản xuất ra thành các phần nhỏ để phát triển (các phần nhỏ này phải đọc lập và Release được), lấy ý kiến khách hàng và thay đổi cho phù hợp ngay trong quá trình phát triển để đảm bảo sản phẩm release đáp ứng những gì khách hàng mong muốn.
Cũng có thể nói SCRUM là một nền tảng đơn giản để phát triển phần mềm, trong đó nó qui định một số qui luật cơ bản nhằm đảm bảo tạo ra cấu trúc của nhóm dự án và giữ cho nó phát triển, sáng tạo và tạo ra sự hấp dẫn đối với những người tham gia.
SCRUM vận hành dựa trên đặc tính tư nhiên của người phát triển nên rất dễ hiểu, dễ áp dụng, tạo nên tính tương tác cao giữa những lập trình viên trong nhóm và cùng nhau tạo ra những sản phẩm tốt. Thay vì chịu sự áp đặt từ bên ngoài.
- Một số đặc tính của SCRUM
- Tập trung vào sản phẩm, sản phẩm mới là đích cuối cùng chứ không phải quy trình.
- Thích ứng nhanh với sự thay đổi yêu cầu.
- Nhấn mạnh vai trò của Team, Team mới là người đưa ra giải pháp và thực hiện nó.
- Tạo nên sự tương tác cao giữa khách hàng, nhóm phát triển sản phẩm để chắc chắn sản phẩm đầu ra đúng với yêu cầu của khách hàng.
- Vì sao nên dùng SCRUM?
– Sản phẩm của mỗi dự án phần mềm không giống nhau nên việc áp dụng để phát triển hàng loạt là rất khó khăn. Do vậy, nếu để có một qui trình chi tiết áp dụng được để phát triển cho tất cả các sản phẩm thì đó là một tác phẩm đồ sộ và tốn kém. Giả sử có một qui trình như vậy thì việc nhớ để áp dụng nó một cách hiệu quả cũng là một thách thức lớn.
– Phần mềm là một sản phẩm phức tạp nên ngay từ đầu khách hàng khó có thể hình dung đầy đủ các yêu cầu đặt ra cho sản phẩm mà phải qua quá trình phát triển những chi tiết ấy mới hình thành nên việc ứng phó tốt với những thay đổi yêu cầu sẽ giúp giảm bớt rủi ro. SCRUM đáp ứng rất tốt cho vấn đề này.
– Như chúng ta đã nói ở trên quá trình phát triển phần mềm khá phức tạp và có nhiều khác nhau giữa các sản phẩm nên nếu không trực tiếp tham gia sản xuất sẽ rất khó hiểu hoặc hiểu không đúng. Do vậy, hãy để cho Team phát triển quyết định giải pháp cho sản phẩm và khách hàng quan tâm đến chức năng của sản phẩm để đáp ứng nhu cầu của họ là tốt nhất.
– Khách hàng nên tham gia vào quá trình phát triển phần mềm để đảm bảo sản phẩm đầu ra đáp ứng nhu cầu phát triển của mình.
– Một số tổ chức trên thống kê rằng trước khi áp dụng SCRUM tỷ lệ thành công của các dự án lớn chỉ 40% nhưng sau khi áp dụng SCRUM tỷ lệ này đã tăng lên 80%.
- Các nhân tố quan trọng trong Scrum
Một cách đơn giản có 03 thành tố quan trọng cấu thành nên SCRUM: Tổ chức (Organization), Qui trình (Process), Tài liệu (Atifacts). Trong mỗi thành tố có 03 thành tố con. Như vậy, chúng ta chỉ cần hiểu và áp dụng được 9 thành tố này là có thể áp dụng SCRUM.
– Tổ chức (Organization): Tổ chức nhóm dự án và Roles (Vài trò)
- Product Owner (Người sở hữu sản phẩm)
- ScrumMaster (Người điều phối )
- Development Team (Nhóm phát triển)
– Tài liệu (Atifacts): các kết quả đầu ra
- Product Backlog (Danh sách các chức năng cần phát triển của sản phẩm)
- Sprint Backlog (Danh sách các chức năng cần phát triển cho mỗi giai đoạn)
- Estimation (Kết quả ước lượng của Team)
– Qui trình(Process): Qui định cách thức vận hành của SCRUM
- Sprint Planning meeting (Họp để hoạch định cho mỗi giai đoạn)
- Sprint Review (Họp để tổng kết cho mỗi giai đoạn)
- Daily Scrum Meeting (Họp review hàng ngày)
4.1 Tổ chức của dự án (Organization)
Product Owner
Product Owner là người sở hữu sản phẩm, người quyết định sản phẩm có những chức năng nào và là người quyết định Product Backlog. Thông thường Role này được khách hàng hoặc người đại diện cho khách hàng đảm nhận.
ScrumMaster
Scrum Master là người đảm bảo các qui trình của Scrum được thực hiện đúng và thuận lợi, giúp đỡ cho Team thực hiện công việc phát triển sản phẩm một cách tốt nhất.
Development Team (Nhóm phát triển)
Một nhóm từ 4-7 kỹ sư phần mềm chịu trách nhiệm phát triển sản phẩm. Nhóm dự án phải làm việc với Product Owner để quyết định những gì sẽ làm trong Sprint (giai đoạn )này và kết quả sẽ ra sao. Đồng thời nhóm cũng thảo luận để đưa ra các giải pháp, ước lượng thời gian thực hiện công việc, họp đánh giá kết quả công việc. Nếu dự án lớn chúng ta cần chia ra thành các dự án nhỏ.
4.2 Tài liệu (Atifacts)
Product Backlog
Product Backlog là danh sách các chức năng cần được phát triển của sản phẩm. Danh sách này do Product Owner quyết định. Nó thường xuyên được cập nhật để đáp ứng được nhu cầu thay đổi của khách hàng cũng như các điều kiện của dự án.
Sprint Backlog
Sprint là một giai đoạn phát triển trong quá trình phát triển sản phẩm, nó được khuyến khích có chiều dài từ 2 – 4 tuần. Mỗi Sprint được xác định bằng thời gian phát triển, danh sách các chức năng phát triển (Sprint Backlog). Mỗi sprint phải Release được sản phẩm để đảm bảo lấy được ý kiến khách hàng, qua được các qui trình phát triển của sản phẩm nhằm rút kinh nghiệm và tránh sự cố sau này.
Sprint Backlog là danh sách chức năng phát triển trong Sprint, nó được quyết định bởi cuộc họp Sprint Planning. Sprint Backlog là các chức năng được chọn từ Product Backlog dựa trên mức độ ưu tiên và khả năng của team phát triển.
Estimation (ước lượng)
Trong SCRUM thì các thành viên của Team sẽ tự lựa chọn Task cho mình và ước lượng thời gian phát triển dự kiến và chịu trách nhiệm với ước lượng này. Sau khi hoàn thành sẽ cập nhật vào bảng Sprint Backlog.
4.3 Qui trình(Process)
Sprint Planning meeting (Họp lập kế hoạch cho mỗi Sprint)
Như chúng ta đã biết ở trên Sprint là một giai đoạn phát triển có thời gian từ 2-4 tuần. Để chuẩn bị cho mỗi Sprint team cần phải họp để xác định những chức năng nào (story) sẽ phát triển trong giai đoạn này (sprint backlog), kết quả đầu ra dự kiến (Goal, kết quả Release), Estimate (ước lượng ai làm việc gì) và thảo luận các giải pháp. Tất cả được ghi thành biên bản để có cơ sở thực hiện và Review sau này.
Sprint Review
Là cuộc họp để đánh giá lại kết quả thực hiện của Sprint vừa qua, xác định những chức năng được Release, những chức năng tiếp tục sửa hoặc phát triển thêm, xác định những vấn đề phát sinh và bàn phương án giải quyết, bổ sung Product Backlog v….
Daily Scrum Meeting (hay còn gọi là Standup Meeting)
Daily Scrum Meeting là cuộc họp hàng ngày và được đề nghị không quá 15 phút và họp đứng để đảm bảo thời gian họp không bị kéo dài vào đầu mỗi ngày, mỗi thành viên chỉ trả lời 3 câu hỏi:
– Hôm qua bạn làm được gì?
– Phát sinh vấn đề gì?
– Hôm nay bạn sẽ làm gì
Nếu thành viên gặp vấn đề thì nên làm việc riêng để giải quyết để không mất nhiều thời gian của các thành viên. Scrum Master phải đảm bảo cuộc họp này được thực hiện đúng qui định.
- Công cụ quản lý
Vì Scrum là Framework để quản lý và giúp Team thực hiện dự án nên bạn cần có công cụ quản lý sẽ dễ dàng và hiệu quả hơn. Bạn có thể tham khảo các cách sau:
- Xây dựng 1 file mẫu Excel (Xem hình 2,3 và bổ sung thêm danh sách Team member)
- Sử dụng công cụ Online:
- Hoặc cài đặt các công cụ chuyên nghiệp như Redmine
Việc sử dụng công cụ sẽ giúp bạn hiểu tốt hơn về Scrum và áp dụng nó hiệu quả hơn.
- Kết luận
Bài viết này chỉ hy vọng giúp các bạn hiểu cơ bản về SCRUM và lý do vì sao nó được chọn làm mô hình phát triển phần mềm được ưa chuộng nhất hiện nay. Bạn cần tìm hiểu thêm để có thể hiểu sâu hơn về mô hình này cũng như áp dụng hiệu quả nó vào công ty bạn.
