11 Kỹ thuật thu thập yêu cầu cho Agile Product Teams

Trong quá trình phát triển các sản phẩm Agile, việc hiểu rõ yêu cầu của người dùng là một bước tiền đề để đảm bảo sản phẩm đáp ứng được nhu cầu thực tế. Để thu thập yêu cầu một cách hiệu quả thì nhóm sản phẩm cần áp dụng linh hoạt các kỹ thuật phù hợp. Bài viết này BAC sẽ giới thiệu đến bạn 11 kỹ thuật thu thập yêu cầu dành cho Agile Product Teams. Điều này không chỉ giúp bạn xây dựng sản phẩm cuối cùng chất lượng mà còn có thể đáp ứng tốt nhu cầu của người dùng.

Nếu việc thu thập yêu cầu đơn giản như việc hỏi khách hàng và các bên liên quan xem họ muốn hệ thống của bạn làm gì thì thật sự quá may mắn. Tuy nhiên, thực tế công việc này không bao giờ đơn giản như vậy. Trong hầu hết các trường hợp, các bên liên quan thường bị hạn chế tầm nhìn và không nhận thức được tất cả các lựa chọn thay thế khi phát triển một sản phẩm cụ thể.

Hiện nay môi trường Agile đang trở thành một trong những phương pháp phát triển phần mềm phổ biến nhất hiện nay. Để thu thập yêu cầu hiệu quả, BA cần áp dụng các phương pháp tiếp cận đa diện. Chần chờ gì mà không cùng BAC tìm hiểu 11 kỹ thuật thu thập yêu cầu cho Agile Product Teams nhằm giúp cải thiện quá trình phát triển phần mềm trong bài viết sau.

Phỏng vấn

Phỏng vấn được coi là cách thức hữu hiệu để bắt đầu quá trình thu thập yêu cầu. Đây là một kỹ thuật phổ biến để hiểu rõ nhu cầu và yêu cầu của người dùng cuối. Phỏng vấn giúp BA thu thập các thông tin cơ bản về nhu cầu kinh doanh, các yêu cầu của khách hàng, người dùng hay mối quan tâm của các bên liên quan khác. Cuộc phỏng vấn giúp tạo ra một diễn đàn để người dùng chia sẻ thông tin và ý kiến của họ.

BA nên tạo các cuộc phỏng vấn với đa dạng người tham gia đồng thời phải mang tính đại diện của các bên liên quan với hệ thống. Để có cái nhìn đúng đắn về các nhu cầu cạnh tranh công bằng, bạn cần có đầy đủ các hồ sơ khách hàng và người dùng. Ngoài ra, khi tiến hành phỏng vấn, BA cần đặt các câu hỏi mở để người nghe suy nghĩ và rút ra những thông tin cụ thể. Nếu bạn muốn hỏi thêm thì nên đi sâu chi tiết vấn đề để có cái nhìn tổng quát về ngữ cảnh.

Bảng câu hỏi/khảo sát

Thực tế kỹ thuật thu thập yêu cầu bằng phỏng vấn có thể rất khó sắp xếp và tốn khá nhiều thời gian cho người phỏng vấn. Để khắc phục tình trạng này, BA có thể sử dụng giải pháp thay thế với các bảng câu hỏi và form khảo sát.

Bảng khảo sát nên được trình bày rõ ràng và chứa các câu hỏi thăm dò. Bạn có thể sử dụng các khảo sát trực tuyến hoặc định danh để thu thập thông tin từ người dùng. Khảo sát cho phép theo dõi với nhiều bên liên quan cùng một lúc từ đó có thể thu thập dữ liệu với số lượng lớn từ nhiều nguồn khác nhau.

Quan sát người dùng

Quan sát những hành động người dùng thực hiện hàng ngày là một trong những cách tốt nhất để hiểu họ thực sự cần gì. Khi quan sát, BA nên ghi chú chi tiết lại những công việc được người dùng thực hiện từ đó đánh giá xem những điều đó có giúp ích hay gây khó khăn, trở ngại cho họ không.

BA có thể hiểu rõ những gì người dùng đang gặp phải và đề xuất những cải tiến hoạt động thông qua việc quan sát người dùng cuối trong bối cảnh thực tế nơi họ thực hiện nhiệm vụ của mình.

Phân tích tài liệu

Phân tích tài liệu của hệ thống có thể giúp BA thực hiện phân tích quá trình AS-IS và phân tích lỗ hổng (gap analysis). Phân tích quá trình AS-IS giúp bạn nhìn thấy nơi bạn có thể cải thiện quy trình của người dùng. Phân tích lỗ hổng sẽ giúp bạn xác định nơi những nhu cầu nghiệp vụ đã được khơi gợi trước đó không được đáp ứng.

Tuy nhiên, ngoài việc phân tích các tài liệu yêu cầu sẵn có của hệ thống, bạn cũng nên xem xét các tài liệu hệ thống khác, chẳng hạn như hướng dẫn sử dụng hay báo cáo sự cố của người dùng.

Phân tích giao diện

Để đảm bảo tính đầy đủ của yêu cầu và khả năng sử dụng của hệ thống, Business Analyst nên phân tích giao diện của hệ thống. Phân tích giao diện kỹ càng sẽ đem đến cho bạn những hiểu biết không ngờ về bối cảnh tương tác của hệ thống, từ đó có thể khám phá những yêu cầu người dùng tiềm ẩn. Thông thường giao diện cho một sản phẩm phần mềm sẽ gồm có:

• Người dùng cuối

• Các thành phần hệ thống mà phần mềm tương tác (ví dụ: cảm biến hoặc các thiết bị ngoại vi khác)

• Các hệ thống bên ngoài

Động não (Brainstorming)

Brainstorming là việc tổ chức các buổi họp nhóm tập trung với các thành viên quan trọng như người dùng, nhà phát triển và người quản lý dự án. Đây là cơ hội để mọi người thảo luận, chia sẻ ý kiến và đưa ra những gợi ý quan trọng. Động não có thể được thực hiện như một phần của hội thảo hoặc riêng lẻ.

Trong phiên động não, hãy xem xét các phần khác nhau của hệ thống một cách riêng lẻ. Đồng thời khám phá nhiều kịch bản giả định và đưa ra ý tưởng để thảo luận từ đó dẫn đến ý tưởng chung và xem xét những ý tưởng có tầm nhìn vượt qua các ranh giới hiện tại. Các công cụ hỗ trợ cho các buổi động não bao gồm bảng trắng, phần mềm lập bản đồ tư duy và bản đồ giúp khám phá nhu cầu của người dùng.

Hội thảo

Hội thảo về yêu cầu là một phương pháp tốt để giải quyết những xung đột bởi ý kiến trái chiều từ các bên liên quan. Hội thảo là bước sau khi bạn đã xác định và sắp xếp sơ bộ về danh sách yêu cầu thu thập được. Chính hội thảo là nơi để triệu tập và bản bạc với các bên liên quan về danh sách trên. BA nên tạo môi trường cho mọi người có nhiều cơ hội để đưa ra lý do cho quan điểm của họ với mục tiêu cuối cùng là tìm cách giải quyết những khác biệt và xung đột, đạt được sự đồng thuận và xác nhận yêu cầu.

Nhập vai

Trong một phiên nhập vai, những người khác nhau sẽ đảm nhận vai trò của những loại người dùng khác nhau. Sau đó họ sẽ tương tác với nhau để giúp kiểm tra các yêu cầu hệ thống riêng lẻ từ các quan điểm riêng nhằm tạo ra các cuộc thảo luận cũng như ý tưởng mới. Trên thực tế, nhập vai là một kỹ thuật động não bổ sung. Đó là một cách tốt để có được sự hiểu biết vững chắc về cách các bộ phận khác nhau cần hoạt động như thế nào để hỗ trợ quá trình tổng thể của hệ thống.

Use Cases và Scenarios

Use Case là một kỹ thuật hỗ trợ các đối tượng người dùng khác nhau có thể nắm rõ được các yêu cầu chức năng của hệ thống. Use Cases mô tả các thực thể bên ngoài hoạt động trên hệ thống cùng với các tương tác cụ thể. Các Use Case được thể hiện dưới dạng danh sách trình tự từng bước các hoạt động được thực hiện trong một quy trình.

Scenarios còn được gọi là user stories. Nó tương tự như use case trong việc mô tả cách hệ thống sẽ thực hiện một quy trình để hoàn thành mục tiêu kinh doanh. Tuy nhiên, hình thức của chúng là một câu chuyện tường thuật chi tiết hơn là một danh sách liệt kê. Hiểu một cách đơn giản, Scenarios là những câu chuyện ngắn với nhân vật chính là người dùng.

Scenarios mô tả:

• Những hành động người dùng thực hiện

• Chi tiết thông tin người dùng nhìn thấy

• Cách người dùng tương tác với hệ thống

Qua việc phân tích Use Cases và Scenarios, BA có thể xác thực các tính năng và yêu cầu chức năng của hệ thống trong nhiều ngữ cảnh khác nhau. Qua đó giúp họ khám phá các trường hợp ngoại lệ cần được xem xét.

Nhóm tập trung

Nhóm tập trung khác với động não. Động não là một quá trình có sự tham gia của các bên liên quan nội bộ. Còn các nhóm tập trung thường có sự tham gia của các bên liên quan bên ngoài.

Nhóm tập trung (hoặc nhóm người dùng) là tập hợp các khách hàng hoặc đại diện người dùng gặp mặt BA để:

• Cung cấp phản hồi về sản phẩm

• Thể hiện nhu cầu của họ

• Đưa ra ý kiến để giúp team phát triển phần mềm

Các nhóm tập trung có thể được triệu tập để thu thập thông tin nhằm phát triển các yêu cầu, hoặc xác nhận các yêu cầu được đưa ra trước đó được đáp ứng hay chưa. Nhiều BA nghi ngờ việc sử dụng các nhóm tập trung để thu thập yêu cầu vì nó có thể bị chi phối bởi những quan điểm cá nhân. Tuy nhiên, các nhóm tập trung có thể cực kỳ hữu ích trong một số trường hợp nhất định, điển hình như việc đánh giá các nguyên mẫu thiết kế để giúp xác nhận và hoàn thiện các yêu cầu.

Tạo nguyên mẫu (Prototyping)

Thông thường, người dùng cuối và các bên liên quan không có ý tưởng rõ ràng về những gì họ thực sự muốn. Tuy nhiên, nếu BA có thể cho họ thử nghiệm với thứ gì đó thực tế, họ thường có thể cho bạn biết họ thích và không thích điều gì ở chúng. Đó là nguyên nhân kỹ thuật tạo nguyên mẫu để thu thập yêu cầu xuất hiện.

Các công cụ tạo nguyên mẫu hiện nay cung cấp rất nhiều mô hình tương tác hấp dẫn cho người dùng thử nghiệm. Tận dụng các công cụ này, sẽ mang lại cho người dùng cơ hội thử nghiệm các ý tưởng về giải pháp tiếp theo của họ sẽ như thế nào. Sau khi mô hình ban đầu được xây dựng, quy trình này sẽ được lặp lại theo trình tự:

• Người dùng dùng thử nguyên mẫu

• Người dùng phản hồi cho nhà phát triển

• Nhóm phát triển sửa đổi nguyên mẫu

Hy vọng bài viết đã cung cấp cho bạn hiểu rõ hơn về 11 kỹ thuật thu thập yêu cầu cho Agile Product Teams. 11 kỹ thuật được trình bày đại khái theo thứ tự chúng thường xuất hiện trong quá trình thu thập yêu cầu. Thực tế, BA không nhất thiết phải sử dụng tất cả chúng cho mọi dự án, nhưng sự kết hợp giữa các kỹ thuật này có thể sẽ cải thiện phạm vi yêu cầu của bạn và giúp bạn giảm các vấn đề phát sinh trong quá trình phát triển phần mềm. Cùng phát triển bản thân hơn trong lĩnh vực BA qua các bài viết chuyên ngành tại BAC's Blog bạn nhé.