27/03/2023
6 Thực Hành Yêu Cầu Quan Trọng Nhất.
Các tác giả đôi khi làm cho mọi thứ dài hơn và phức tạp hơn mức cần thiết. Một số độc giả có thể cảm thấy rằng chính tôi đã phạm tội này. Ấn bản thứ ba của cuốn sách Yêu cầu phần mềm của tôi , đồng tác giả với Joy Beatty, dài khoảng 245.000 từ, gần 640 trang với phông chữ khá nhỏ. Có thể điều đó có vẻ như quá mức cần thiết, nhưng công bằng mà nói, miền yêu cầu rất lớn và phức tạp.
Những cuốn sách như Yêu cầu phần mềm , Nắm vững quy trình yêu cầu của Suzanne và James Robertson, và Cơ quan kiến thức phân tích nghiệp vụ của IIBA mô tả hàng chục kỹ thuật có giá trị để khơi gợi, phân tích, đặc tả, xác nhận và quản lý yêu cầu. Tất cả chúng đều hữu ích khi được áp dụng một cách thận trọng trong các tình huống thích hợp. Nhưng nếu bạn không có thời gian để lướt qua những khối lượng lớn này, bạn có thể thích phiên bản TL; DR này về sáu thực tiễn yêu cầu quan trọng nhất mà mọi nhóm dự án nên thực hiện. Bài viết này được điều chỉnh từ Những điều cơ bản về yêu cầu phần mềm: Thực tiễn cốt lõi để phân tích kinh doanh thành công của Karl Wiegers và Candase Hokanson.
Thực Hành Số 1: Xác Định Mục Tiêu Kinh Doanh
Các tổ chức thực hiện một dự án để giải quyết vấn đề, khai thác cơ hội kinh doanh hoặc tạo ra một thị trường mới. Xác định các mục tiêu kinh doanh của dự án truyền đạt tới tất cả những người tham gia và các bên liên quan khác lý do tại sao họ đang làm việc trong dự án . Tổ chức có thể hy vọng đạt được cả mục tiêu kinh doanh tài chính và phi tài chính với sản phẩm mới. Cố gắng định lượng các mục tiêu kinh doanh và làm cho chúng có thể đo lường được bằng các tuyên bố như sau:
• Chiếm thị phần X phần trăm trong vòng Y tháng.
• Đạt doanh số X đơn vị hoặc doanh thu $Y trong vòng Z tháng.
• Tiết kiệm X đô la mỗi năm hiện đang chi cho một hệ thống kế thừa cần bảo trì cao.
Việc sử dụng các mục tiêu kinh doanh sẽ điều chỉnh tất cả công việc của nhóm và các quyết định quan trọng. Nếu không có các mục tiêu kinh doanh được xác định, bạn không thể tạo ra một tuyên bố về tầm nhìn sản phẩm rõ ràng hoặc thiết lập phạm vi của toàn bộ dự án hoặc bất kỳ giai đoạn phát triển nào. Nhóm không thể đưa ra quyết định đúng đắn về các thay đổi phạm vi hoặc chức năng được đề xuất trừ khi họ biết những thay đổi đó phù hợp với mục tiêu kinh doanh như thế nào.
Tập trung vào phạm vi sẽ giúp nhóm tránh phạm vi leo thang trong khi vẫn thích ứng với thực tế kinh doanh đang thay đổi. Và làm thế nào bạn có thể biết liệu dự án có thành công hay không trừ khi ai đó xác định trước các mục tiêu kinh doanh và tiêu chí thành công của nó?
Thực Hành #2: Hiểu Người Dùng Cần Làm Gì Với Sản Phẩm
Tôi thực sự ủng hộ việc sử dụng cách tiếp cận lấy người dùng làm trung tâm để phát triển yêu cầu và thiết kế giải pháp, thay vì cách tiếp cận lấy tính năng hoặc sản phẩm làm trung tâm. Hiểu các tác vụ mà người dùng cần thực hiện và mục tiêu họ muốn đạt được cho phép nhà phân tích nghiệp vụ (BA) rút ra chức năng mà các nhà phát triển phải triển khai.
Khi bạn tập trung vào việc khám phá các tính năng hơn là mục tiêu của người dùng, bạn rất dễ bỏ qua một số chức năng cần thiết. Cũng dễ dàng bao gồm chức năng có vẻ thú vị nhưng không giúp người dùng hoàn thành công việc của họ. Các trường hợp sử dụng là một kỹ thuật hiệu quả để duy trì tư duy tập trung vào việc sử dụng này.
Tìm cách hiểu người dùng cần làm gì với sản phẩm ngụ ý một số hoạt động BA quan trọng khác, bao gồm:
• Xác định một loạt các bên liên quan của dự án
• Đặc trưng cho các lớp người dùng riêng biệt có các yêu cầu phần lớn khác nhau
• Xác định các cá nhân đóng vai trò là tiếng nói của khách hàng cho từng lớp người dùng ( nhà vô địch sản phẩm )
• Lựa chọn các kỹ thuật khơi gợi yêu cầu phù hợp để tương tác với người dùng
• Thiết lập quy trình ra quyết định để giải quyết xung đột và ưu tiên giữa các lớp người dùng
• Xây dựng và đánh giá nguyên mẫu hoặc bản phát hành sớm để kích thích phản hồi của người dùng
Thực Hành Số 3: Ưu Tiên Các Yêu Cầu
Tôi nghi ngờ rằng bất kỳ dự án nào đã từng thực hiện mọi chức năng được yêu cầu. Ngay cả khi bạn có thể thực hiện tất cả, bạn cũng không thể thực hiện tất cả cùng một lúc. Mục tiêu của bạn là mang lại giá trị kinh doanh tối đa cho khách hàng với chi phí thấp nhất và trong thời gian ngắn nhất. Để đạt được mục tiêu này, bạn phải ưu tiên các yêu cầu để nhóm có thể làm việc với chúng theo trình tự thích hợp nhất.
Việc sắp xếp thứ tự ưu tiên liên quan đến việc xem xét mỗi yêu cầu được đề xuất đóng góp bao nhiêu vào việc đạt được các mục tiêu kinh doanh của dự án. Việc sắp xếp thứ tự ưu tiên cho các yêu cầu cho phép nhóm quyết định mục công việc nào còn lại trong hồ sơ tồn đọng cần trì hoãn hoặc bỏ qua do hạn chế về thời gian và nguồn lực. Có rất nhiều kỹ thuật ưu tiên yêu cầu có sẵn, bao gồm :
• Vào hoặc ra
• So sánh theo cặp và thứ tự xếp hạng
• quy mô ba cấp độ
• MoSCoW
• Trọng số tương đối
• bài kiểm tra $100
Một số phương pháp này cần nhiều nỗ lực hơn những phương pháp khác, nhưng những phương pháp đó cũng giúp người quản lý dự án hoặc chủ sở hữu sản phẩm đưa ra các lựa chọn chi tiết hơn. Chọn bất kỳ kỹ thuật nào cho phép các bên liên quan phù hợp đưa ra quyết định kinh doanh tốt trong suốt dự án để tránh “giai đoạn giải mã nhanh” điên cuồng vào cuối trò chơi.
Thực Hành #4: Khám Phá Các Yêu Cầu Phi Chức Năng
Mọi người thường tập trung vào chức năng của sản phẩm khi thảo luận về các yêu cầu, nhưng đó chỉ là một phần của giải pháp. Các yêu cầu phi chức năng góp phần quan trọng vào sự hài lòng của người dùng và sự phù hợp để sử dụng. Khi nói về “các yêu cầu phi chức năng”, mọi người thường nghĩ đến các thuộc tính chất lượng , đôi khi được gọi là “các đặc tính”. Những đặc điểm sản phẩm này bao gồm khả năng sử dụng, khả năng bảo trì, bảo mật, độ tin cậy và nhiều đặc điểm khác. Để giúp các nhà thiết kế đưa ra giải pháp phù hợp nhất, BA cần thảo luận về các yêu cầu phi chức năng như một phần của việc khơi gợi yêu cầu.
Các nhà phát triển thường không trực tiếp thực hiện các yêu cầu mô tả tính an toàn, độ tin cậy, tính di động, bảo mật hoặc các đặc điểm khác. Thay vào đó, các thuộc tính này đóng vai trò là nguồn gốc của nhiều yêu cầu chức năng và thúc đẩy các quyết định thiết kế. Bảng 1 chỉ ra các loại thông tin kỹ thuật mà các loại thuộc tính chất lượng khác nhau sẽ tạo ra.
Một thách thức khác là không thể tối ưu hóa tất cả các yếu tố chất lượng mong muốn cùng một lúc. Các nhà thiết kế phải đưa ra các quyết định đánh đổi giữa các thuộc tính khác nhau. Do đó, nhóm cần xác định cái nào là quan trọng nhất đối với sự thành công của khách hàng và tối ưu hóa chúng. Việc xác định cẩn thận các thuộc tính chất lượng cho phép bạn xây dựng một sản phẩm làm hài lòng người dùng, chứ không chỉ đơn thuần là làm những gì nó phải làm.
Bài Thực Hành Số 5: Xem Lại Các Yêu Cầu
Làm thế nào để bạn biết nếu yêu cầu của bạn là chính xác? Làm thế nào bạn có thể biết liệu chúng có đủ rõ ràng để tất cả các thành viên trong nhóm biết phải làm gì với chúng và các bên liên quan khác biết những gì mong đợi trong giải pháp? Dù bạn chọn cách thể hiện kiến thức về yêu cầu như thế nào, đôi khi nó vẫn mơ hồ, không đầy đủ hoặc đơn giản là không chính xác.
Một trong những thực hành chất lượng mạnh mẽ nhất hiện có là đánh giá ngang hàng các yêu cầu. Triệu tập một số đồng nghiệp để xem xét cả yêu cầu văn bản và sơ đồ. Những người tham gia dự án khác nhau — BA, nhà thiết kế, nhà phát triển, người thử nghiệm, người dùng — sẽ tìm thấy các loại vấn đề khác nhau trong quá trình đánh giá này. Đánh giá yêu cầu đặt ra một số thách thức cụ thể . Thay vì chỉ mời mọi người xem qua các yêu cầu, hãy cung cấp một số khóa đào tạo để người đánh giá biết cách tham gia hiệu quả và có thể tìm ra càng nhiều vấn đề càng tốt.
Một thực hành xác nhận yêu cầu liên quan là viết các bài kiểm tra khái niệm dựa trên các yêu cầu . Yêu cầu kiểm tra là điều bạn có thể thực hiện sớm trong mỗi chu kỳ phát triển để phát hiện ra nhiều lỗi trước khi chúng được đưa vào mã. Yêu cầu và bài kiểm tra là quan điểm bổ sung cho cùng một kiến thức. Các yêu cầu mô tả cách thức hoạt động của sản phẩm trong các điều kiện nhất định; các bài kiểm tra mô tả làm thế nào để biết liệu nó có thể hiện các hành vi đúng hay không.
Thực Hành Số 6: Lập Kế Hoạch Thay Đổi Yêu Cầu
Cho dù bạn hiểu rõ vấn đề đến đâu và chuẩn bị các yêu cầu cẩn thận đến đâu thì chúng cũng không thể hoàn hảo, trọn vẹn hay tĩnh tại được. Thế giới thay đổi xung quanh chúng ta khi chúng ta làm việc. Người dùng mới và ý tưởng mới xuất hiện. Quy tắc kinh doanh bề mặt và phát triển. Các dự án chắc chắn sẽ phát triển vượt ra ngoài phạm vi hình dung ban đầu của chúng. Mọi nhóm phải lường trước các thay đổi về yêu cầu và thiết lập các cơ chế để giải quyết chúng mà không làm hỏng các cam kết của nhóm.
Khi bạn biết kết quả của dự án chưa được xác định đầy đủ và có khả năng thay đổi nhiều, thì một cách tiếp cận linh hoạt, gia tăng là một cách tốt để đối phó với nó. Bạn dự định xây dựng các yêu cầu—và giải pháp—trong một loạt các phần nhỏ, mong đợi hướng thay đổi và chấp nhận sự không chắc chắn về những gì bạn sẽ có ở cuối và khi nào bạn sẽ có nó.
Khi mức độ thay đổi có thể ít nghiêm trọng hơn, hãy lập kế hoạch để đáp ứng một số tăng trưởng (cùng với rủi ro, ước tính không chính xác và các sự kiện bất ngờ) bằng cách xây dựng các vùng đệm dự phòng trong lịch trình phát triển. Thiết lập quy trình thay đổi yêu cầu để những người phù hợp có thể nhận được thông tin phù hợp nhằm đưa ra quyết định kinh doanh đúng đắn về những thay đổi được đề xuất sẽ kết hợp để gia tăng giá trị với sự gián đoạn tối thiểu.
Tuy nhiên, đừng sử dụng kỳ vọng về sự thay đổi để biện minh cho việc bỏ qua suy nghĩ về các yêu cầu. Yêu cầu quá mức thường chỉ ra rằng các mục tiêu không rõ ràng hoặc phương pháp khơi gợi không hiệu quả.
Bỏ Bê Những Thực Hành Này Trong Tình Trạng Nguy Hiểm Của Bạn
Tất nhiên, có nhiều hoạt động yêu cầu có giá trị khác ngoài sáu hoạt động này. Tuy nhiên, những thực tiễn này làm tăng đáng kể cơ hội xây dựng giải pháp giúp bạn đạt được kết quả kinh doanh mong muốn một cách hiệu quả và hiệu quả. Việc áp dụng chúng không đảm bảo thành công cho bất kỳ BA, chủ sở hữu sản phẩm hoặc người quản lý sản phẩm nào. Nhưng bỏ bê chúng có thể dẫn đến thất bại.