Với nhu cầu của khách hàng ngày càng tăng với tốc độ theo cấp số nhân, các công ty buộc phải phát hành phần mềm với tốc độ nhanh hơn để đáp ứng những nhu cầu này. Các đội chịu nhiều áp lực phải cung cấp càng nhiều tính năng càng tốt trong một khoảng thời gian hạn chế. Kết quả là, khi người dùng trải nghiệm qua các giai đoạn khác nhau của Vòng đời phát triển phần mềm (SDLC), nó liên tục được cập nhật cho đến khi tính năng này thực sự được phát hành cho khách hàng. Đây được gọi là phạm vi thay đổi và là nguyên nhân số một của sự chậm trễ trong các mốc thời gian phát hành.

Khi các yêu cầu liên tục thay đổi, kỳ vọng về cách một chức năng sẽ hoạt động cũng thay đổi mạnh mẽ; dẫn đến tính năng cuối cùng hoàn toàn khác với mong đợi ban đầu. Điều này gây ra sự lãng phí không cần thiết về chi phí, thời gian và công sức. Vì vậy, làm thế nào để chúng ta giảm phạm vi thay đổi trong một dự án? Dưới đây là một số cách để giải quyết vấn đề này:

Làm rõ yêu cầu phần mềm càng sớm càng tốt

Các nhóm cần thảo luận về các yêu cầu của phần mềm ngay trong giai đoạn lập kế hoạch. Đây là cuộc họp mà toàn bộ nhóm cần ngồi lại với nhau và thảo luận về từng yêu cầu. Thông thường, quản lý dự án sẽ dẫn dắt cuộc thảo luận này và giải thích chi tiết các yêu cầu và mong muốn của khách hàng. Các nhóm cần nhân cơ hội này để đưa ra các câu hỏi, các mối quan tâm, các vấn đề đang gặp phải để hiểu rõ hơn về các yêu cầu, thảo luận chi tiết để hiểu rõ về độ phức tạp, những thách thức trong quá trình phát triển và kiểm thử. Cuộc thảo luận này sẽ giúp loại bỏ hầu hết sự mơ hồ trong các yêu cầu của phần mềm.

Có buổi họp kick-off dự án

Đây là các cuộc họp diễn ra ngay trước khi quá trình phát triển bắt đầu. Ở giai đoạn này, những yêu cầu từ phía của người dùng sẽ chi tiết, rõ ràng hơn so với giai đoạn lập kế hoạch. Đội phát triển bao gồm đội lập trình và đội kiểm thử cùng với đại diện khách hàng cùng ngồi lại với nhau và thảo luận về các yêu cầu của sản phẩm. Một số những thảo luận chi tiết trong buổi họp như những chỗ còn thiếu cần bổ sung trong tài liệu yêu cầu hay những yêu cầu trong quá trình phát triển: kiểm thử đơn vị, kiểm thử tự động, dữ liệu kiểm thử,... cũng sẽ được thảo luận trong cuộc họp này. Chúng sẽ thường được thảo luận trong vòng 5-10 phút. Cuộc họp này sẽ cung cấp rõ ràng hơn cho nhóm về những tính năng cần được phát triển và kiểm thử.

Không thay đổi yêu cầu khi công việc phát triển bắt đầu

Một trong những vấn đề chính mà các nhóm thường gặp phải là yêu cầu thay đổi liên tục cho những chức năng đang hoặc đã được phát triển và kiểm thử. Không có một quy trình cụ thể để hoàn thiện yêu cầu cuối cùng cho các chức năng. Vì vậy, việc đầu tiên của doanh nghiệp là chốt phạm vi của yêu cầu sau khi công việc phát triển bắt đầu cho từng chức năng. Nếu có bất kỳ những thay đổi đối với các chức năng nó phải được thực hiện sau thời điểm này, nó phải trải qua một quy trình quản lý thay đổi nghiêm ngặt.

Có quy trình quản lý thay đổi nghiêm ngặt

Bất kỳ thay đổi nào đối với các chức năng đang được phát triển đều cần phải trải qua quy trình quản lý thay đổi do nhóm thiết lập. Quá trình có thể khác nhau tùy thuộc vào bối cảnh của dự án và tổ chức, nhưng đều chung là chỉ cho phép các thay đổi quan trọng được thêm vào khi các chức năng đang tiến hành phát triển / kiểm thử. Tất cả những thay đổi khác phải được thảo luận thực hiện sau và phải được lên kế hoạch cụ thể. Điều này giúp làm giảm thay đổi liên tục về yêu cầu sản phẩm khi quá trình phát triển/kiểm thử sản phẩm đã hoàn tất. Ngoài ra, nó còn giúp tiết kiệm đáng kể thời gian, chi phí và công sức.

Xây dựng nhận thức bằng cách trao quyền cho các nhóm.

Thay đổi phạm vi yêu cầu ảnh hưởng đến tất cả các vai trò trong một dự án: đội phát triển sản phẩm, đội kiểm thử sản phẩm, nhóm thiết kế UX và các bên liên quan khác. Vì vậy, cần phải xây dựng nhận thức về tầm quan trọng của việc ngăn chặn phạm vi thay đổi? Tại sao chúng ta không nên trao quyền cho các nhóm để khi họ nhận thấy vấn đề tại bất kỳ thời điểm nào của quá trình phát triển? Các nhà lãnh đạo nên trao đổi rõ ràng về lý do tại sao vấn đề này cần được ngăn chặn càng sớm càng tốt và mọi người nên có trách nhiệm đảm bảo những thay đổi không xảy ra trong quá trình phát triển. Mọi người nên được trao quyền nói KHÔNG khi họ nhận thấy những thay đổi trong các yêu cầu không tuân theo quy trình quản lý thay đổi.

Như đã nói ở trên, những thay đổi trong yêu cầu có thể có lợi cho các nhóm, giúp làm cho các tính năng tốt hơn và có thể sử dụng nhiều hơn cho người dùng cuối; nhưng cần phải có có một quy trình phù hợp khi nào thực hiện những thay đổi đó và chú ý đến việc nó có thể tác động đến các nhóm như thế nào. Có sự cân bằng tốt giữa việc cập nhật các yêu cầu khi cần thiết (miễn là trải qua quy trình quản lý thay đổi) và chốt các yêu cầu để ngăn các thay đổi tiếp theo ảnh hưởng đến nỗ lực phát triển và kiểm thử.

Nguồn: https://qablog.practitest.com/strategies-to-reduce-creep-in-requirements/