PO là một nghề ở DEHA mất rồi. Nó đòi hỏi nhiều kĩ năng, nhưng quan trọng nhất vẫn là kĩ năng viết Requirement. Sau đây, xin nói sơ lược về kĩ năng này.
Các PO của DEHA đa phần là dân tay ngang, có lẽ sẽ tốt hơn nếu tôi nói một chút về bức tranh tổng thể. Người ta chia việc phát triển phần mềm thành nhiều lĩnh vực, trong đó có hai lĩnh vực là Kĩ nghệ phần mềm – SE (Software Engineering) và Khoa học máy tính – CS (Computer Science). Kiến thức của các PO thuộc lĩnh vực SE. Tài liệu đầy đủ nhất dạy về vấn đề này là cuốn Software Engineering (lan Sommerville).
Trong Kĩ nghệ phần mềm, người ta dạy rằng để làm một phần mềm ta cần làm 4 công đoạn chủ yếu: Tạo yêu cầu, Phân tích, Thiết kế, Cài đặt, Bảo trì. Các bạn cần lưu ý rằng, dù có Agile hay không thì phần mềm cũng phải trải qua 4 bước này. Agile không giúp ta bỏ các bước, mà chỉ giúp ta bàn giao sản phẩm sớm hơn (nhưng không chắc là nhanh hơn) và thực hiện các bước hiệu quả hơn (chứ không phải là ít hơn).
Để tạo requirement, người ta có nhiều phương pháp, chứ không phải chỉ dùng mỗi User Story. Các phương pháp đó có thể là: WBS, Mock, Usecase, Userstory… Mỗi một phương pháp có ưu nhược điểm riêng. Với mỗi cách tạo, sang bước phân tích người ta thường sinh ra một tài liệu nữa thường được gọi là Đặc tả yêu cầu phần mềm (Software Requirement Specification). SRS sẽ mô tả phần mềm có những cái gì, nhưng chưa mô tả gì về phần mềm làm như thế nào.
Các công cụ tao yêu cầu mà tôi đã nói ở trên là cách để Nhóm khách hàng – Customer Team sử dụng để trao đổi với Nhóm phát triển – Develop Team. Ví dụ:
– Nếu bạn dùng WBS, bạn sẽ nói với Dev Team rằng: Này, hãy làm chức năng AG01 – Đăng nhập.
– Nếu bạn dùng Mock, bạn sẽ nói rằng: Này, hãy làm màn hình số S007 – Đăng nhập.
– Nếu bạn dùng UC, bạn sẽ nói với team rằng: Này, hãy làm Usecase Đăng nhập cho nhân viên thông thường.
– Nếu bạn dùng UT, bạn sẽ nói rằng: Này, là một nhân viên thông thường tôi muốn đăng nhập vào hệ thống để được chứng thực và bắt đầu truy cập các nội dung cá nhân.
Nếu không có các công cụ này, Dev team và Cus team sẽ không có ngôn ngữ chung để giao tiếp. Đơn giản là sẽ gây rối loạn và cãi cọ ỏm tỏi nhưng không cùng nghĩ về một vấn đề. Thông thường, người ta có thể kết hợp vài cách với nhau để tạo requirement tốt hơn. Ví dụ bạn có thể kết hợp giữa UT và Mock chẳng hạn (https://blog.balsamiq.com/using-mockups-in-your-agile-user-stories).
Tất nhiên, chỉ mỗi những công cụ này là chưa đủ để mô tả về yêu cầu bởi chúng chỉ tập trung nói về Nghiệp vụ – Business Domain chứ chưa nói gì về tính năng của phần mềm. Chúng ta cần làm thêm một bước nữa đó là tạo nội dung đặc tả cho từng chức năng. Có hai loại nội dung phải đặc tả là: Tính năng – Funtional và Phi tính năng – Non-Functional. Đối với đặc tả tính năng, bạn thường phải tạo: mô tả giao diện, mô tả hành vi.
Mô tả giao diện thì có thể dùng Mockup. Mô tả hành vi thì có thể dùng Scenario hoặc Gerkin Language.
Scenario là một loạt câu đơn phát biểu về hành vi của hệ thống có dạng như thế này:
1. Nhân viên nhập nội dung username, password.
2. Nhân viên nhấn nút đăng nhập
3. Hệ thống kiểm tra quyền đăng nhập của username/pass tương ứng.
4. Hệ thống thông báo người dùng đăng nhập thành công.
Gerkin Language thì có thể có dạng:
Given Nhân viên truy cập vào hệ thống bằng trình duyệt Chrome
When Nhân viên nhập username và password
Then Nhân viên nhấn nút đăng nhập
Then Hệ thống thông báo đăng nhập thành công.
Ngoài ra, bạn phải hiểu rằng những nội dung được viết ở trên kia không phải là tất cả. Nhiều nội dung cần trao đổi trực tiếp giữa Cus Team và Dev Team để cùng hiểu. Thông qua trao đổi, nhiều vấn đề sẽ sáng tỏ hơn, rõ ràng hơn. Chất lượng phần mềm phụ thuộc rất nhiều vào chất lượng communication.
Đến đây thì tôi nghĩ là đã đủ nhiều cho một bài viết sơ lược. Bài này thì vẫn còn sơ lược quá, nhưng hi vọng đã hệ thống hoá lại những nét lớn trong việc viết Yêu cầu. Nhìn chung, đây là việc rất khó khăn, phức tạp, cần nhiều kĩ năng và kiến thức. Bạn hãy xác định luôn rằng cần mất vài ba năm mới có thể gọi là biết chút nghề. Tuy nhiên, dù chặng đường có dài đến đâu, hãy cứ thoải mái đặt bước chân đầu tiên lên đó.