Trong các buổi tư vấn, nói chuyện và khi đào tạo tôi nhận được rất nhiều câu hỏi: Liệu Scrum có phù hợp với nhóm phát triển phần mềm của tôi không? Do tần suất lặp lại câu hỏi kiểu như vậy là tương đối lớn nên tôi muốn dành một bài viết để đưa ra nhận định “khi nào Scrum phù hợp và khi nào chúng ta nên tìm kiếm một phương pháp khác“.
Trong Scrum, Sprint được đóng khung, không có sự thay đổi về yêu cầu hoặc thành viên nhóm trong suốt Sprint. Nhóm Scrum có năng suất và chất lượng cao do:
- Sự tập trung không bị ảnh hưởng bởi các yếu tố bên ngoài,
- Giữ một nhịp làm việc đều đặn hằng ngày và từng Sprint,
- Duy trì các trụ cột: thích nghi, thanh tra và minh bạch.
Trạng thái sản phẩm có thể là một yếu tố để chúng ta quyết định có sử dụng Scrum hay không. Khi sản phẩm ở giai đoạn mới phát triển, có nhiều thay đổi, nhưng không quá cấp bách, có nhiều rủi ro liên quan tới con người và công nghệ thì Scrum rất phù hợp.
Khi sản phẩm đã bước vào giai đoạn ổn định, công việc chủ yếu là làm mịn sản phẩm, sửa lỗi, tính bất định không còn nhiều, nhưng chúng lại yêu cầu khả năng phản ứng cao hơn thì Scrum lại là cản trở bởi tính đóng khung thời gian Sprint, khi đó Kanban là một lựa chọn tốt hơn.
Tuy vậy, Kanban cũng không thực sự tốt khi sản phẩm của bạn vẫn cần phát triển những tính năng mới, lựa chọn nên là Scrumban để đạt được hiệu quả quản trị dự án tốt hơn. Tuy nhiên một nhóm vừa phải phát triển những tính năng mới vừa phải sửa lỗi thì có thể sẽ xảy ra tình trạng đa nhiệm và không tập trung, không giữ được nhịp sẽ dẫn đến năng suất và chất lượng giảm. Một giải pháp là chia thành hai nhóm làm việc. Nhóm phát triển mới sử dụng Scrum, và nhóm Kanban hoặc Scrumban thực hiện việc bảo trì. Việc chia này có thể xảy ra tình trạng nhóm Scrum được làm những công việc mới và giữ được động lực với nhịp, nhóm bảo trì sẽ bị bào mòn bởi không được làm theo nhịp và thực hiện công việc bảo trì thường nhàm chán và chịu áp lực deadline. Để giảm tình trạng này, hai nhóm có thể luân phiên thay đổi thành viên, nhưng cần giữ cho cả hai nhóm tương đối ổn định.
Với sản phẩm bảo trì nếu bộ phận kinh doanh và Product Owner có khả năng đảm bảo một khung thời gian nào đó (ví dụ 1 tuần) thì nhóm nên sử dụng Scrum để đạt được năng suất và chất lượng tốt nhất cũng như giữ nhịp và động lực làm việc của Nhóm Phát triển.
Ngoài yếu tố sản phẩm, việc quyết định có sử dụng Scrum còn phụ thuộc vào nhiều yếu tố khác như: tổ chức, sự hỗ trợ từ lãnh đạo, văn hóa, con người, khách hàng, v.v..
Nếu công ty bạn có cơ cấu tổ chức theo phòng ban chức năng, mọi người sẽ làm việc cùng với nhau dưới hình thức tổ (group) chứ không phải nhóm (team), việc áp dụng Scrum sẽ chỉ đạt được một chút giá trị.
Nếu công ty bạn có cơ cấu tổ chức dạng ma trận, việc dùng Scrum là không nên vì rất khó kiểm soát khả năng và mức độ tập trung của nhóm dự án.
Scrum không phải là một phép màu. Việc sử dụng Scrum cần sự thay đổi sâu sắc về cách nghĩ và cách làm. Nếu tổ chức của bạn chưa sẵn sàng cho những thay đổi mà Scrum yêu cầu thì việc áp dụng sẽ khó đem lại giá trị.
Dù các cấp lãnh đạo cao nhất đã cam kết với sự thay đổi, Scrum cũng không mang lại giá trị trong một sớm một chiều. Scrum như một tảng băng trôi, tổ chức của bạn không những phải thực hành đúng những gì mô tả được – phần nổi của tảng băng trôi – mà còn phải thực hiện cả phần chìm của tảng đó nữa – các giá trị và trụ cột Scrum.
Theo Hocvienagile.com
