Trong lĩnh vực phát triển phần mềm, việc khách hàng thay đổi yêu cầu luôn là vấn đề khó đối với nhà phát triển. Sự ra đời của Agile với nguyên tắc "Welcome changing requirements" đã góp phần giải quyết vấn đề trên. Kỹ năng quản lý thay đổi đối với QA nói chung hay đối với QA trong dự án áp dụng Agile nói riêng là vô cùng cần thiết. Bài viết này, mình xin phép chia sẻ một số tip để quản lý Specs cũng như phạm vi của dự án, từ đó đảm bảo chất lượng cho dự án.

1. Đặt vấn đề

Chắc hẳn ai cũng đã từng gặp những trường hợp khách hàng nay muốn thế này, mai muốn thế khác. Không ít trường hợp nhận Feedback và sửa một hồi sau đó họ lại lựa chọn version đầu. Một câu hỏi được đặt ra là: Tại sao khách hàng hay thay đổi?

Phần mềm gồm một hay nhiều ứng dụng là một tập hợp các chương trình thực hiện tự động hóa một số các nhiệm vụ nghiệp vụ. Nghiệp vụ bao gồm tập hợp các chức năng như: tìm hiểu thị trường, kiểm toán, sản xuất và quản lý nhân sự... Sản phẩm phần mềm rất trừu tượng, ban đầu nó chỉ được mô tả bằng ngôn ngữ tự nhiên.

Khách hàng nói tôi muốn có chức năng A, chức năng B,... Nhưng ngay lúc đó họ cũng chưa hình dung ra được chức năng A/B sẽ hoạt động thế nào, giao diện ra sao. Khách hàng không biết thực sự họ muốn gì. Cho đến khi nhận được một phần sản phẩm thì họ nghĩ rằng đó chưa phải điều họ thật sự muốn và họ thay đổi.

Vậy có cách nào để ngăn chặn sự thay đổi này hay không thì câu trả lời là không.

2. Quản lý thay đổi

Không thể bảo khách hàng ngưng thay đổi, vì vậy ta cần chủ động ứng phó với thay đổi. Sau đây là một số việc mình hay làm khi có thay đổi về Specs.

Tạo task để dễ theo dõi

Một số lưu ý khi tạo task:

• Cần tao task ngay khi có thay đổi.
• Tên task nên đặt sao cho dễ phân biệt từng lần thay đổi của khách hàng. VD: "Change_Specs_01012018".
• Có thể assign luôn cho thành viên trong team nếu còn effort.
• Nếu là thay đổi lớn thì nên chia thành nhiều task con và gán quan hệ cha-con cho các task.

Việc tạo task sẽ đảm bảo bạn không bỏ sót bất cứ thay đổi nào của khách hàng. Giúp team biết được khối lượng công việc còn lại, từ đó có kế hoạch bố trí nhân lực hợp lý.

Update Specs

Specs là tài liệu quan trọng trong quá trình phát triển phần mềm. Dựa vào đó, dev biết mình phải xây dựng hệ thống như thế nào, QA biết mình phải test ra sao. Specs cần được update liên tục khi có thay đổi để đảm bảo team đang làm đúng.

Update tài liệu test

Cần update tài liệu test ngay khi có thay đổi. Phải đảm bảo testcase/checklist của bạn là đúng với yêu cầu mới nhất. Trên cơ sở đó, chất lượng phần mềm sẽ được đảm bảo.

Tạo tài liệu quản lý thay đổi

Khi khách hàng thay đổi quá nhiều, thật khó để comfirm một vấn đề khi bạn không biết nó nằm ở lần thay đổi nào. Để giải quyết việc này, ta nên có một file quả lý thay đổi bao gồm những thông tin cần thiết: ID, Requester, CR's Channel, Date of Request, Expected, Duedate, Priority, Features, Screen, Change Description, Impact Description, Estimated Effort (hours), Planned, Finish Date, Redmine Ticket, Status, Actual Finish Date, Update Spec, Updated Date.

File template: https://docs.google.com/spreadsheets/d/1oGxE9D1ydbXh1aRONWkMwiC2V36Wk0FlMpYjX7MZvME/edit?usp=sharing

Kết luận

Trong mỗi dự án, khách hàng thay đổi là vấn đề không thể tránh khỏi. Mong rằng những chia sẻ ở trên sẽ giúp ích cho các bạn trong việc thực hiện nguyên tắc số 2 của Agile "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." Thanks for reading ^^