Hướng dẫn đầy đủ nhất về quản lý yêu cầu và truy xuất nguồn gốc

Yêu cầu mất bao lâu?

Bạn đã bao giờ tự hỏi sẽ mất bao nhiêu thời gian để tạo ra các yêu cầu cho dự án sắp tới của mình chưa? Các nhà phân tích và quản lý kinh doanh thường hỏi câu hỏi này.

Đối với hầu hết các vấn đề liên quan đến phát triển sản phẩm và phần mềm, không có câu trả lời chung cho tất cả; phản ứng thực sự phụ thuộc vào hoàn cảnh duy nhất của bạn.

Một số biến góp phần vào vấn đề này, mức trung bình hàng đầu của ngành đề xuất tỷ lệ phần trăm nỗ lực của dự án nên được dành cho việc phát triển yêu cầu chẳng hạn như thu thập và khơi gợi.

Làm thế nào bạn có thể xác định lượng thời gian và nỗ lực thích hợp cần thiết cho các hoạt động như thu thập yêu cầu? Không có gì đáng ngạc nhiên, dữ liệu từ các điểm chuẩn khác nhau không phải lúc nào cũng đi đôi với nhau. Người ta cũng tranh luận liệu những dự án “thông thường” này có giống với dự án của riêng bạn hay không. Để giúp bạn giải quyết vấn đề này, tôi đã điều chỉnh một số ý tưởng từ cuốn sách “Thông tin thêm về các yêu cầu phần mềm” của mình trong bài viết này – hãy xem thử!

Điểm chuẩn ngành

Để cung cấp ví dụ về tính hữu dụng tiềm năng của điểm chuẩn, vui lòng tham khảo Bảng 1. Dữ liệu được trình bày cho biết mức trung bình của ngành đối với các nỗ lực tạo mẫu và tạo mẫu yêu cầu khác nhau liên quan đến các dự án có quy mô 10,000 điểm chức năng (xấp xỉ một triệu dòng mã), được lấy từ Capers Jones' “Đánh giá phần mềm, Điểm chuẩn và Thực tiễn tốt nhất.” Làm thế nào thích hợp là những số liệu cho dự án của riêng bạn?

Việc sử dụng các tiêu chuẩn ngành như thế này không phải là không có nhược điểm của nó. Dữ liệu không cho chúng tôi biết liệu các dự án có thực sự thành công hay không hoặc liệu có bất kỳ mối tương quan nào giữa thành công và nỗ lực đặt ra các yêu cầu hay không. Thông tin này chỉ cung cấp cho chúng tôi mức trung bình của những gì đã được thực hiện, do đó rất khó để mô tả chính xác mức độ thành công của từng dự án riêng lẻ.

Phân bổ 10% hoặc ít hơn nỗ lực của nhóm cho các nhiệm vụ như thu thập yêu cầu có thể mang lại lợi ích, miễn là họ không bị mắc kẹt trong tình trạng tê liệt phân tích. Trái ngược với niềm tin phổ biến, đầu tư nhiều nỗ lực hơn vào việc nâng cao quy trình phát triển yêu cầu của bạn sẽ thực sự tăng tốc độ sản xuất. Tận dụng khái niệm này mang lại lợi tức đầu tư lớn cho bất kỳ dự án nào!

Khi tôi làm việc trên các dự án nhỏ hơn khi làm việc tại Kodak, nhóm của chúng tôi thường phân bổ 15% đến 18% tổng nỗ lực cho các hoạt động yêu cầu. Chúng tôi thấy rằng khoản đầu tư này đã làm giảm số lượng thay đổi cần thiết sau khi giao hàng. Thật khó để kết nối nguyên nhân và kết quả một cách chắc chắn, nhưng có khả năng tỷ lệ bảo trì thấp của chúng tôi phần lớn là do việc thu hút sự tham gia đáng kể của người dùng.

Cố gắng tìm ra chính xác lượng thời gian thu thập yêu cầu cho dự án tiếp theo của bạn là một câu hỏi khó và có thể khó đánh giá chính xác. Tuy nhiên, may mắn thay, Hình 1 cho chúng ta một số hiểu biết sâu sắc về các biến số có thể rút ngắn hoặc kéo dài quá trình nói trên; giúp bạn ước tính hiệu quả hơn khi tạo ra các yêu cầu cần thiết đó.

Kinh nghiệm của riêng bạn

Để bắt đầu, có thể hữu ích khi xem xét dữ liệu từ các dự án trước đây để xác định loại nỗ lực nào được dành riêng cho việc thu thập yêu cầu. Điều này sẽ cho phép bạn đánh giá quá trình phát triển của bạn đã thành công như thế nào trong quá khứ và sử dụng thông tin này khi ước tính chi phí cho các nỗ lực trong tương lai. Là một yếu tố bổ sung, hãy điều chỉnh các ước tính ban đầu của bạn bằng cách tham khảo Hình 1, trong đó nêu rõ sự khác biệt giữa các dự án sắp tới và các dự án chuẩn cũng như tính đến bất kỳ cân nhắc liên quan nào khác liên quan đến dự án của bạn. Bằng cách đánh giá từng yếu tố được liệt kê trong Hình 1 trên thang điểm từ 0 (không ảnh hưởng) đến 5 (ảnh hưởng lớn), đánh giá này có thể giúp bạn phát hiện các yếu tố rủi ro có thể mở rộng quy trình phát triển yêu cầu của bạn.

Bên cạnh các yếu tố khác, điều cần thiết là phải xem xét vòng đời của dự án. Đừng cho rằng tất cả các yêu cầu phải được tích lũy ngay từ đầu giống như cách tiếp cận tuần tự hoặc thác nước (được minh họa bằng đường chấm trong Hình 2). Thay vì có một “giai đoạn yêu cầu” riêng biệt, hãy nghĩ về một loạt các điều kiện cần thiết trải qua từng giai đoạn phát triển. Khi Thông số kỹ thuật yêu cầu hệ thống (SRS) của chúng tôi phát triển và các yêu cầu thay đổi bắt đầu phát sinh, chúng tôi phải duy trì sự siêng năng trong việc chủ động quản lý các đường cơ sở của yêu cầu. Đây là một quá trình liên tục đòi hỏi sự chú ý nhất quán.

Phương pháp tiếp cận lặp đi lặp lại và gia tăng

Các cách tiếp cận phát triển linh hoạt, như Scrum, có lộ trình tiến bộ. Điều này cho phép người dùng có được các tính năng hữu ích tiềm năng của sản phẩm một cách nhanh chóng và dễ dàng sửa đổi các yêu cầu của họ khi cần. Do đó, các nhà phát triển có thể theo kịp nhu cầu kinh doanh luôn thay đổi một cách dễ dàng. Với các dự án linh hoạt, hiếm khi có nhu cầu về các sáng kiến yêu cầu lớn vì các nỗ lực thu thập yêu cầu nhỏ nhưng thường xuyên (đường liền nét trong Hình 2).

Thay vì tập trung vào giai đoạn đầu của dự án, nỗ lực yêu cầu trong một dự án linh hoạt được trải rộng trên nhiều giai đoạn khác nhau. Các khám phá ban đầu dẫn đến chức năng chi tiết tồn đọng dựa trên mức độ ưu tiên của nó. Khi đến lúc phát triển và thử nghiệm, các nhóm tinh chỉnh các yêu cầu để có đủ thông tin chi tiết để tiến hành một cách tự tin với mỗi lần lặp lại.

Nhiều năm trước, tôi là thành viên của nhóm phát triển phần mềm đã tận dụng cách tiếp cận gia tăng để đảm bảo thành công. Mỗi chu kỳ, dự án của chúng tôi sẽ được phát hành theo từng giai đoạn ba tuần với phần đầu tiên được dành riêng để lập kế hoạch đưa ra các yêu cầu và phát triển cho mức tăng cụ thể đó. Chúng tôi đã đạt được những kết quả tuyệt vời từ phương pháp này vì nó mang lại chức năng hữu ích vài tuần một lần cho cơ sở người dùng doanh nghiệp. Nhóm đã làm việc siêng năng để nhanh chóng cung cấp chức năng mới theo từng bước, cung cấp cho người dùng các bản cập nhật thường xuyên. Những hiểu biết sâu sắc về người dùng này là vô giá để hướng dẫn dự án và giúp đảm bảo đạt được giá trị tối đa khi hoàn thành dự án.

Không phải tất cả các sáng kiến đều phù hợp để phân phối theo từng phần nhỏ. Khi xây dựng lại một ứng dụng hiện có, hệ thống mới phải có một mức chức năng đáng kể trước khi người dùng có thể chuyển đổi sang ứng dụng đó. Bất kể nhóm của bạn hoàn thành bao nhiêu trong mỗi chu kỳ dự án, họ phải hiểu các yêu cầu đối với trình tự cụ thể đó để ngăn chặn bất kỳ việc làm lại và viết lại thiết kế, mã hoặc kiểm tra nào.

Yêu cầu lập kế hoạch

Nó thường phức tạp hơn khi bạn bắt đầu biên dịch các yêu cầu cho một dự án mới. Khi động não các hoạt động mà các nhà phân tích của bạn cần thực hiện, hãy ghi nhớ liệu họ có phải thực hiện các nhiệm vụ như sau:

Xây dựng mối quan hệ với các nhà vô địch sản phẩm thông qua đàm phán.
Thu thập thông tin chi tiết thông qua các hội thảo tương tác và phỏng vấn chuyên sâu.
Kiểm tra các hồ sơ và sản phẩm hiện có để khai thác các cải tiến tiềm năng.
Xây dựng, phổ biến và giải mã các khảo sát.
Thiết kế và đánh giá các nguyên mẫu, nghiên cứu các mô hình và các quan điểm yêu cầu khác để thành công.
Đạt được thành công thông qua đánh giá rủi ro, đảm bảo tuân thủ các giao thức an toàn và bảo mật, phân tích các lỗi tiềm ẩn và tiến hành kiểm tra nguy cơ.
Ghi nhật ký chi tiết về nhu cầu của bạn vào kho lưu trữ dữ liệu.
Xem xét kỹ lưỡng các yêu cầu chi tiết trong đặc tả yêu cầu.
Tạo các trường hợp thử nghiệm từ các yêu cầu được liệt kê và đánh giá tỉ mỉ hiệu suất của chúng.
Sau khi xem xét hoặc thử nghiệm kỹ lưỡng, hãy tinh chỉnh các thông số kỹ thuật của yêu cầu để đảm bảo độ chính xác.

Để có thể ước tính tốt hơn nỗ lực cần thiết cho các dự án trong tương lai, điều cần thiết là tìm hiểu về các nhiệm vụ khác nhau mà nhóm của bạn có thể phải thực hiện như một phần của việc tìm ra, phân tích, đặc tả và xác nhận yêu cầu. Kiến thức này sẽ giúp bạn hiểu thêm về lượng thời gian cần thiết cho mỗi nhiệm vụ và hỗ trợ cải thiện hiệu suất dự án của bạn. Điều đó không nhất thiết có nghĩa là tất cả các hoạt động cần phải được thực hiện trong mọi dự án kinh doanh mà là hiểu rõ những gì cần làm sẽ dẫn đến một kết quả thành công.

Đừng quên chia sẻ bài viết này!