Tôi nhận được một email từ một người phát triển phần mềm, có viết: “Công ti chúng em chọn Scrum là phương pháp phát triển duy nhất và chúng em nhận được đào tạo Scrum từ một công ti tư vấn. Tuy nhiên sau vài tháng, nhiều dự án đã thất bại và người quản lí giận chúng em. Chúng em không biết điều gì xảy ra. Xin thầy giúp đỡ.”

Đáp: “Scrum là cách tiếp cận Agile phổ biến nhất hiện đang được dùng trong các công ti phần mềm toàn thế giới. Nó là qui trình đơn giản nhưng quản lí rất hiệu quả cho phát triển phần mềm. Scrum có thể giúp tổ dự án quản lí thay đổi trong phạm vi của dự án. Các lặp Scrum giúp tổ phát triển sản phẩm trong vài bước gia tăng được gọi là Sprint (1 tới 4 tuần) nơi tổ có thể lấy được phản hồi từ người dùng một cách nhanh chóng. Qui trình Scrum là đơn giản, rõ ràng và dễ học, những cuộc họp “đứng hàng ngày” của nó cho phép tổ chia sẻ thông tin một cách hiệu quả ; “Sơ đồ Burndown (cháy xuống)” giúp các thành viên tổ kiểm tra trạng thái dễ dàng.

Vấn đề chung nhất của dự án dùng Scrum là họ không tuân theo qui trình mà thường nhảy qua vài bước khi họ thấy khớp. Chẳng hạn, các thành viên tổ có thể nói với nhau: “Chúng ta đã biết phải làm gì rồi, tại sao bận tâm cập nhập tồn dư của bước nước rút sprint? Điều đó là phí thời gian.” Mọi qui trình được xác định cho một chủ định, nếu bạn không tuân theo nó thì bạn không dùng Scrum tương ứng. Trong trường hợp đó bạn có thể có vấn đề nhưng đó không phải là vì Scrum.

Scrum được thiết kế như “qui trình phát triển nhẹ” cho dự án nhỏ với tổ nhỏ (3 tới 8 người) những người làm việc cùng nhau ở cùng chỗ. Nó KHÔNG phải là thiết kế cho dự án lớn với tổ phân bố lớn nơi các thành viên ở nhiều khu vực địa lí và trong các múi giờ khác nhau. Nếu dự án của bạn là lớn hay tổ của bạn bao gồm nhiều người và nhiều người không ở cùng một vị trí, tôi gợi ý rằng bạn KHÔNG dùng Scrum. Cho dù nó có thể “tăng qui mô” như một số nhà tư vấn đã gợi ý nhưng tôi sẽ không khuyến cáo nó. Xin nhớ cho rằng Scrum không phải là “một cỡ khớp cho tất cả” và việc tăng qui mô yêu cầu nhiều nỗ lực, điều phối và chừng nào bạn còn chưa có kinh nghiệm, đừng dùng Scrum cho cái gì đó mà nó không được thiết kế cho.

Scrum là tuyệt cho dự án Web, cho dự án cần cập nhật nhanh nhưng KHÔNG cho hệ thống mấu chốt như thiết bị y tế, hàng không và vũ khí, hay hệ thống quốc phòng. Những dự án này yêu cầu nhiều chăm nom bởi vì rủi ro cao. Chúng cần đáp ứng mong đợi an toàn như phân tích yêu cầu, đảm bảo chất lượng, và thiết kế cho tin cậy, kiểm thử chất lượng, tài liệu dự án, quản lí cấu hình và theo dõi vết được. Những dự án này là phù hợp cho thực hành vòng đời phần mềm truyền thống hơn là Scrum.

Công ti phần mềm nên có vài phương pháp luận phát triển chứ không chỉ một. Người quản lí dự án nên lựa phương pháp thích hợp cho từng dự án tương ứng. Scrum có thể không là phương pháp đúng cho nên công ti phải chọn một cách khôn ngoan.

—-English version—-

SCRUM

I received an email from a software developer who wrote: “Our company selects Scrum to be the only development method and we receive Scrum training from a consultant company. However after few months, many projects have failed and managers were angry at us. We do not know what happened. Please help.”

Answer: “Scrum is the most popular Agile approach and is being used in software companies worldwide. It is a simple but very effective management process for software development. Scrum can help project team to manage changes in scope of the project. Scrum iterations help the team to develop products in several incremental steps called Sprint (1 to 4 weeks) where the team can get feedback from users quickly. Scrum process is simple, clear and easy to learn, its “Daily Standup” meetings allow the team to share information effectively; the “Burndown chart” helps team members to check status easily.

The most common issue of project that uses Scrum is they do not follow the process but often skip some steps as they see fit. For example, team members may say to each other: “We already know what to do, why bother to update the sprint backlog? It is a waste of time.” Every process is defined for a purpose, if you do not follow it than you do not use Scrum accordingly. In that case, you may have problems but it is not because of Scrum.

Scrum is designed as a “lightweight development process” for small project with small teams (3 to 8 people) who work together in the same place. It is NOT design for larger project with large distributed team where members are located in several geographical areas and in different time zones. If your project is large or your team consists of a lot of people and many are not located in the same place, I suggest that you DO NOT use Scrum. Even it is possible to “scale up” as some consultants have suggested but I would not recommend it. Please remember that Scrum is not a “one size fits all” and scale up requires a lot of efforts, coordinations and unless you are experienced, do not use Scrum for something it is not designed for.

Scrum is excellent for Web project, for project that need fast update but NOT for critical systems such as medical devices, aviation and weapon, or defense systems. These projects require a lot of care because of high risks. They need to meet safety expectations such as requirements analysis, quality assurance, and design for reliability, qualification testing, project documentation, configuration management and traceability. These projects are better suited for traditional software lifecycle practices rather than Scrum.

Software company should have several development methodologies not just one. Project managers should select appropriate methods for each project accordingly. Scrum might not be correct method so company must chose wisely.