Khó khăn khi áp dụng Scrum
Một người phát triển phần mềm viết cho tôi: “Chúng tôi đang áp dụng phương pháp Scrum cho dự án phần mềm của chúng tôi nhưng chúng tôi gặp phải nhiều vấn đề. Mặc dầu người quản lí dự án của chúng tôi đã theo lớp đào tạo Agile nhưng anh ấy không thể giải quyết được vấn đề. Chúng tôi nghĩ về chuyển trở lại phương pháp cũ. Xin thầy lời khuyên.”
Đáp: Scrum là phương pháp tuyệt vời cho dự án phần mềm nhỏ. Khác biệt then chốt giữa Scrum và các cách tiếp cận khác là cách tiếp cận đơn giản của nó. Scrum cho phép dự án được thực hiện tăng dần, từng mảnh mỗi lúc. Để làm cho Scrum làm việc, bạn cần có các thành viên tổ có kinh nghiệm bởi vì Scrum yêu cầu tổ tự quản, điều có nghĩa là không có người quản lí dự án hay người lãnh đạo tổ để chỉ đạo tổ nhưng mọi thành viên của tổ đều phải làm việc cùng nhau để làm cho công việc được thực hiện. Vì bạn có người quản lí dự án, dường như là bạn có thể không dùng Scrum đúng đắn. Nếu người đó là người duy nhất có được đào tạo về Agile thì đó là sai lầm. Tôi khuyên là toàn thể tổ ghi danh vào đào tạo Scrum để cho bạn có thể làm mọi thứ đúng đắn.
Có ba vai trò trong dự án Scrum: Người chủ Scrum, Người sở hữu sản phẩm, và các Thành viên tổ. Người chủ Scrum chịu trách nhiệm đảm bảo rằng tổ tuân theo qui trình Scrum. Người sở hữu sản phẩm đại diện cho cách nhìn của khách hàng và hướng dẫn tổ làm việc đáp ứng nhu cầu của người dùng. Các thành viên tổ chịu trách nhiệm làm cho công việc được thực hiện. Không có một trong những vai trò then chốt này, dự án có thể thất bại. Không có người quản lí dự án, không có người lãnh đạo tổ, không có người kiểm thử, và không có vai trò đảm bảo chất lượng phần mềm trong dự án Scrum. Bất kì ai trong những vai trò phụ này sẽ tạo ra xung đột không cần thiết. (Đó là lí do tại sao tổ được gọi là “tự quản.”)
Có các cách nhìn khác nhau liên quan tới kích cỡ của dự án Scrum. Một số người tin tổ Scrum nên có từ 5 tới 10 người; số khác nghĩ nó có thể lên tới 20 hay thậm chí 40 người.
Theo kinh nghiệm của tôi, 6 tới 8 người làm việc tốt nhất vì quá nhiều người sẽ làm khó chia sẻ thông tin. Mọi người làm việc tốt nhất theo các tổ nhỏ hơn và đó là lí do tại sao cách tiếp cận linh động có tác dụng tốt cho các dự án nhỏ. Nếu dự án của bạn có 15 hay 25 người, bạn có thể có vấn đề.
Dự án Scrum được chia thành nhiều “đơn vị công việc” nhỏ hơn có tên là “Sprint”. Sprint bao giờ cũng có chiều dài thời gian cố định cho nên tổ có đích xác cùng khối lượng thời gian để làm việc. Bằng việc làm cho mọi Sprint có cùng chiều dài, tổ biết năng lực riêng của nó cho công việc. Nếu chiều dài Sprint thay đổi, tổ sẽ không biết năng lực của nó (Cần bao lâu để hoàn thành một số nhiệm vụ) điều làm cho lập kế hoạch thành khó khăn hơn. Đây là vấn đề tinh tế mà nhiều người không chú ý nhưng điều rất quan trọng là mọi Sprints có cùng chiều dài. Nếu dự án của bạn không tuân theo qui tắc này, bạn cũng có thể có vấn đề. Tôi thường cho tổ của tôi thời gian cố định 4 tuần vì tôi nghĩ 2 tuần quá ngắn và 5 tuần là quá dài.
Từng Sprint đều là một cơ hội để học vì tổ làm việc cùng nhau và điều chỉnh theo năng lực của nhau. Mọi Sprint đều bắt đầu với cuộc họp lập kế hoạch cho Sprint nơi các thành viên tổ thảo luận xây dựng “CÁI GÌ” và họ sẽ xây dựng nó “NHƯ THẾ NÀO”. Tập trung của cuộc họp là chọn một số nhiệm vụ từ Các khoản mục tồn dư sản phẩm - Product Backlog Items (yêu cầu phần mềm) và chia chúng thành một danh sách các nhiệm vụ có tên là Tồn dư Sprint (Sprint Backlog). Mục đích của Lập kế hoạch Sprint là để lập kế hoạch công việc cho Sprint đó, và chắc các thành viên tổ hiểu công việc của nó dựa trên phản hồi thừ Sprint trước. Mọi thành viên tổ phạm sai lầm ở vài Sprints ban đầu, khi họ làm việc cùng nhau; họ học cùng nhau và cuối cùng trở nên giỏi hơn. Mọi sự thường cải tiến ở Sprint thứ ba hay thứ tư. Nếu bạn có vấn đề trong vài Sprint đầu, đừng lo lắng vì bạn vẫn đang học cách làm việc cùng nhau khi bạn xây dựng sản phẩm cho một Sprint và một lúc.
Mỗi sáng tổ ngồi cùng nhau vào cuộc họp Scrum hàng ngày để chia sẻ thông tin và phân công nhiệm vụ (Ai làm gì ngày hôm đó). Cuộc họp Scrum hàng ngày thường kéo dài quãng 10 phút nhưng sai lầm chung là các thành viên thường quyết định bỏ qua cuộc họp hàng ngày. Theo kinh nghiệm của tôi, nếu tổ không có cuộc họp Scrum hàng ngày, tổ sẽ không làm việc tốt khi xung đột xảy ra. Scrum hàng ngày là thời gian mà các thành viên tổ thảo luận về công việc của họ với nhau cũng như chia sẻ kinh nghiệm và học từ nhau. Người chủ Scrum phải giám sát và đo tiến bộ của Sprint (tức là, việc đo được thực hiện hàng ngày trên tiến bộ của tổ). Nếu tổ của bạn không có cuộc họp Scrum hàng ngày, đó có thể là lí do tại sao dự án của bạn có vấn đề.
Phần cuối cùng của Sprint là suy ngẫm Sprint và kiểm điểm Sprint nơi toàn tổ (kể cả người chủ Scrum và người sở hữu Sản phẩm) thảo luận về cách họ đã làm việc trong Sprint đã qua và đi tới cách cải tiến công việc của họ trong Sprint tiếp. Suy ngẫm Sprint được giữ riêng trong tổ chỉ khi họ thảo luận nó đã được thực hiện “THẾ NÀO”. Hoạt động này là mấu chốt cho tổ vì nó là quá trình học tập cho mọi thành viên. Nó là việc làm của người chủ Scrum để chắc các thành viên tổ tham dự tất cả các cuộc họp và chia sẻ kinh nghiệm.
Kiểm điểm Sprint là chỗ tổ duyệt qua “CÁI GÌ” đã được thực hiện với khách hàng để xem liệu tổ có hoàn thành điều họ lập kế hoạch trong Lập kế hoạch Sprint không. Trong buổi kiểm điểm này, các thành viên tổ giải thích và làm đề mô công việc và khách hàng cung cấp phản hồi về sản phẩm. Việc trao đổi thông tin được làm tài liệu bởi người sở hữu sản phẩm trong tồn dư sản phẩm - Product Backlog.
Vì bạn không giải thích chi tiết về các vấn đề với Scrum, tôi chỉ đoán nhưng trước khi bạn chuyển trở lại phương pháp cũ, bạn cần kiểm điểm công việc của bạn và phải chắc rằng bạn không phạm phải những sai lầm mà tôi đã nhắc tới ở trên. Giống như bất kì phương pháp mới nào, cần thời gian để làm nó tốt và điều quan trọng nhất là toàn bộ tổ phải có được đào tạo đúng để làm nó tốt. Scrum có tác dụng tốt với dự án phần mềm nhỏ và nó đang ngày càng phổ biến hơn với các dự án phát triển ứng dụng Di động và Tính toán mây. Nếu bạn vẫn còn có vấn đề, bạn có thể cần ai đó có kinh nghiệm để giúp. Có thể bạn cần đem vào một nhà tư vấn Agile.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
