Các yêu cầu được xác định như thế nào trong các dự án phần mềm nguồn mở?

Trong phát triển phần mềm nội bộ của công ty, thông thường các yêu cầu được xác định thông qua một quy trình chính thức dẫn đến việc tạo ra một số tài liệu yêu cầu. Trong phát triển phần mềm nguồn mở, điều này dường như thường không có. Do đó, câu hỏi của tôi là: các yêu cầu được xác định như thế nào trong các dự án phần mềm nguồn mở?

Bằng cách "xác định các yêu cầu" tôi chỉ đơn giản là "tìm ra các tính năng, v.v. nên được phát triển như một phần của một phần mềm cụ thể".

Các dự án nguồn mở đôi khi có những luồng phản hồi mạnh mẽ của người dùng và đôi khi các công ty chỉ trả tiền để thực hiện một số tính năng nhất định (bằng cách thuê các nhà phát triển của riêng họ hoặc các nhà phát triển ban đầu).

Nếu dự án của bạn có 100 người dùng, có lẽ bạn có thể phát triển bất cứ điều gì thú vị nhất để viết mã.

Nếu dự án của bạn có 100 nghìn người dùng, rất có thể bạn đã có một danh sách các điểm đau mà hầu hết người dùng muốn sửa trong phiên bản tiếp theo và danh sách các tính năng N hàng đầu mà người dùng yêu cầu trong trình theo dõi vấn đề của bạn và tiếp tục hỏi về các diễn đàn.

Với phản hồi này, bạn có thể viết tài liệu yêu cầu cho nhóm nòng cốt của mình, tạo lộ trình để giúp những người đóng góp độc lập hiểu được tầm nhìn của bạn và hy vọng rằng một số người dùng 100 nghìn sẽ gửi bản vá.

Tôi đã theo dõi nguồn mở kể từ lần đầu tiên tôi nghe về linux vào khoảng năm 1995 và tôi không thể nhớ đã từng nghe từ 'yêu cầu' được sử dụng trong ngữ cảnh đó.

Eric Raymond có một bài luận hay, Nhà thờ và Chợ , trong đó anh nói về 'gãi ngứa của chính mình'. Nếu bạn đang cố gắng giải quyết vấn đề mà cá nhân bạn đang đối mặt, bạn không phải tham khảo các tài liệu yêu cầu để tìm hiểu xem bạn đã giải quyết hay chưa.

Bài tiểu luận tương tự cũng nói về việc lắng nghe người dùng của bạn, đó là lời khuyên tốt cho mọi người, không chỉ các dự án nguồn mở. Các dự án nguồn mở có xu hướng mang tính công bằng, vì vậy, 'người viết mã, đưa ra các quy tắc', ít nhiều.

Trong phát triển phần mềm nội bộ của công ty, thông thường các yêu cầu được xác định thông qua một quy trình chính thức dẫn đến việc tạo ra một số tài liệu yêu cầu.

Để kinh nghiệm của tôi đây là nhiều phổ biến hơn khi thực hiện phát triển dựa trên hợp đồng, đặc biệt là khi có một bên ngoài công ty làm việc phát triển cho công ty của bạn, và có nhu cầu pháp lý cho một hợp đồng. Nhưng nhiều công ty khác kiểm soát sự phát triển kênh của họ bởi chính người của họ theo một cách khác:

• giao tiếp không chính thức

• yêu cầu ưu tiên / lỗi / vấn đề / danh sách vé (và đó chắc chắn không phải là một phát minh từ cộng đồng "nhanh nhẹn")

Đây là cách tương tự như hầu hết các dự án nguồn mở hoạt động - vì không cần hợp đồng chính thức, không ai bận tâm để tạo ra các tài liệu yêu cầu chính thức, chi tiết, chính thức, chỉ là các danh sách nhỏ, không đau đớn về các tính năng bị thiếu hoặc vé được thu thập trong một vấn đề theo dõi để được giải quyết.

Nếu vấn đề là một vấn đề phổ biến như, viết trình biên dịch hoặc trình duyệt, thì các yêu cầu được đưa ra khá nhiều dưới dạng tiêu chuẩn ngôn ngữ, hệ điều hành đích và phần cứng đích, v.v.

Đối với những thứ như GNU Emacs, rất nhiều thứ bên cạnh việc hoàn thành xuất sắc mục tiêu ban đầu là trở thành một trình soạn thảo văn bản, tôi nghĩ rằng các yêu cầu có ý nghĩa vì phạm vi rộng lớn để mở rộng nó. Trò chuyện, email, nhóm tin tức, chỉnh sửa mã, kiểm soát phiên bản xuất hiện trong tâm trí. Có một nhà khoa học nghiên cứu về Emacspeak. Tôi nghĩ những điều tương tự có thể được nói về trình duyệt và những thứ khác cho phép mở rộng.

Nếu phần mềm đang bắt kịp một chức năng chỉ có sẵn trong phần mềm không nguồn mở, thì yêu cầu này lại được đưa ra khá nhiều.

BIÊN TẬP:

Khi phần mềm nguồn mở tiếp tục bảo trì và các yêu cầu ban đầu ít hơn vẫn chưa được đáp ứng, hầu hết các yêu cầu có thể đến từ các lỗi, cần phải thích ứng với các nền tảng mới như CPU ​​đa lõi và phần cứng khác cung cấp hiệu suất tốt hơn khi khai thác và như vậy.

Trong một dự án hoàn toàn dựa trên nghiên cứu như GNU Hurd, tôi nghĩ rằng các yêu cầu đến từ kết quả nghiên cứu và tài liệu.

Tóm lại,

• khi bắt đầu, các yêu cầu đối với phần mềm cố gắng giải quyết các vấn đề phổ biến có thể đến từ các tài liệu tiêu chuẩn

• đối với phần mềm bắt kịp với phần mềm hiện có khác, các yêu cầu có thể là sản xuất tất cả hoặc hầu hết bộ tính năng của phần mềm hiện có và một số tính năng khác mà nhà phát triển / người dùng thấy thú vị

• cho các dự án nghiên cứu, bài báo và các ấn phẩm khác có thể đặt ra các yêu cầu

• Khi bảo trì, lỗi, cần thích nghi với môi trường mới hơn có thể là nguồn chính cho các yêu cầu

Tôi không biết chắc chắn, nhưng một khi gợi ý là sử dụng phương pháp giống như Agile, trong đó các yêu cầu được đưa ra dưới dạng vé (hoặc "thẻ"), sử dụng một cái gì đó như JIRA, với mỗi vé đại diện cho một tính năng hoặc yêu cầu. Mỗi vé sau đó có thể được phân tách thành các vé khác đại diện cho các đơn vị công việc nhỏ hơn.

Đối với việc thực sự tìm ra những gì một ứng dụng hoặc một phần mềm nên làm, câu trả lời đơn giản là "nói chuyện với các nhà phát triển khác." :) "Nói chuyện" trong trường hợp này có thể có nghĩa là danh sách phân phối e-mail, diễn đàn hoặc thậm chí IRC, bất cứ điều gì cho phép mọi người ở các múi giờ và vị trí địa lý khác nhau trò chuyện.