Huyền thoại Scrum (Scrum myths): Scrum xung đột với ngày cố định (fixed Date)

Đây là một vấn đề phổ biến của Scrum, đặc biệt là đối với những người thường phát triển phần mềm trong phạm vi kín (dự án truyền thống). Khung làm việc Scrum là không có tính thuyết phục khi đặt trong bối cảnh phát triển phần mềm, nó chỉ nói về "phát triển sản phẩm phức tạp" . Nó chung, phát triển phần mềm theo Agile tránh sử dụng khái niệm dự án này.

The iron Triangle (tam giác sắt)

Phát triển phần mềm là một hoạt động thường được thuê ngoài cho các công ty IT với hiểu biết về kỹ thuật và nghiệp vụ thích hợp. Trong phần lớn các trường hợp, sự hợp tác được hình thảnh bởi một "hợp đồng dự án" dựa trên tam giác sắt (the iron triangle). Mô hình này xác định bốn khía cạnh của nỗ lực phát triển phần mềm có liên quan chặt chẽ với nhau :

• Phạm vi sản phẩm
• Thời gian giao hàng
• Chi phí
• Chất lượng sản phẩm Trong đó khía cạnh chất lượng sản phẩm thường xuyên bị bỏ qua. Điều này xảy ra quá thường xuyên dẫn tới những ràng buộc này trở thành những trở ngại dẫn tới dự án không chính xác và những thay đổi cần được nhất trí để dự án có thể thành công. Tại sao lại như vậy ? Lý do chủ yếu để tiếp tục sử dụng dự án có phạm vi cố định là :
• Sự thiếu tin tưởng giữa khách hàng và nhà cung cấp phần mềm
• Các công ty lớn không thích rủi ro
• "Chúng tôi luôn làm theo cách này" Phiên bản cuối cùng (2015) của Chaos Report nổi tiếng của Standish Group cho thấy ít hơn 1/3 số dự án được coi là thành công, vì vậy người mua các dự án phần mềm sẽ làm tốt trong việc xem xét tại sao lại tiếp tục thực hiện nó. Cố gắng tối đa hóa cả bốn khía cạnh của tam giác sắt cùng một lúc thường dẫn tới việc tất cả bị giảm sút. Phát triển phần mềm theo Agile đã thay đổi cách tiếp cận "dự án có phạm vi cố định" , xác định nguồn lực, thời gian và chất lượng, và dự tính phạm vi. Do sự minh bạch và ưu tiên của các tính năng được cung cấp bởi Product Backlog trong Scrum, xác suất dự án gặp khó khăn được giảm đáng kể.

Unused software (phần mềm không được sử dụng)

Một nguồn chỉ trích nữa dành cho dự án có phạm vi cố định đó là chúng sản xuất ra phần mềm với nhiều chức năng không được sử dụng. Nghiên cứu " ROI, đó là việc của bạn" của Jim Johnson cho thấy rằng 64% các tính năng do dự án cung cấp hiếm khi hoặc không bao giờ được sử dụng. Mặc dù mẫu của các dự án rất nhỏ, cảm giác thực của tôi cho tôi biết rằng thực tế có thể không khác biệt nhiều lắm với kết quả đó, đúng là một sự lãng phí lớn về tiền bạc và thời gian của con người.

Sử dụng Scrum để lập kế hoạch dự án

Các dự án có thể được lập kế hoạch bởi Scrum. Từ quan điểm của quản lý sản phẩm, nó thường được gọi là " quản lý bản phát hành". Công cụ để quản lý phạm vi dự án là Product Backlog, và nó có thể được dự tính trước khi bắt đầu phát triển. Scrum kêu gọi sự kiểm soát quy trình thực nghiệm để tránh lãng phí do các yêu cầu được xác định quá sớm nên cần phải có định nghĩa về phạm vi nhẹ nhất để tạo ra sự tin tưởng về phần sản phẩm được mua. "Chân minh bạch" của chủ nghĩa kinh nghiệm đòi hỏi sự trung thực tuyệt đối với khách hàng về nguy cơ không cung cấp đầy đủ toàn bộ phạm vi dự án trong khoảng thời gian dự kiến và cuối cùng, phân bổ một khoản dự phòng hợp lý ví dụ như thêm các Sprints. Product Owner chịu trách nhiệm trong việc kết hợp các bên liên quan trong quá trình theo dõi và giúp đỡ họ chuyển từ "tư duy phạm vi ban đầu" s ang "tư duy chuyển giao giá trị".

Kết luận

Scrum có thể được sử dụng để lập kế hoạch và quản lý dự án phát triển có phạm vi cố định, mặc dù cần phải xem xét một số quan điểm phổ biến về quản lý dự án truyền thống cũng như khái niệm về dự án có phạm vi cố định, nhằm giúp khách hàng phát triển thành một tinh thần về quản lý sản phẩm lành mạnh hơn