Là phát triển tài liệu lặp đi lặp lại có thể, và nó cung cấp tài liệu hiệu quả?

Tôi có một dự án cho trường đại học mà tôi sẽ không bắt đầu ngay lập tức, nhưng tôi đã suy nghĩ về một khoảng thời gian khá dài. Tôi hiểu rằng phát triển dự án Đại học không giống như ngành công nghiệp (tôi hiện đang là thực tập sinh) nên tình huống mà tôi sẽ chỉ ra vào lúc này có lẽ sẽ hơi vô lý đối với các nhà phát triển phần mềm thực tế. ^^ '

Bản thân dự án yêu cầu chúng tôi ghi lại rất nhiều công việc của chúng tôi. Vì vậy, bên cạnh việc phân phối mã, tính vào một số nhãn hiệu, chúng tôi phải cung cấp các tài liệu bao gồm:

Tài liệu phân tích yêu cầu
Kế hoạch dự án
Một danh sách dự kiến các trường hợp sử dụng, mô hình đối tượng và mô hình động và các thử nghiệm chấp nhận
Tài liệu về quá trình thử nghiệm và mức độ thành công của các thử nghiệm
Một số thảo luận và phân tích khác về sử dụng thời gian, vv

Những sản phẩm này sẽ được giao theo cách sau:

RAD đầu tiên
Tiếp theo là Kế hoạch dự án, Ca sử dụng, Mô hình và Thử nghiệm (khoảng 3 tuần sau)
Cuối cùng, tài liệu về chương trình thực tế, quy trình thử nghiệm, v.v. + chính chương trình thực tế (khoảng 5 tuần sau)

Vì vậy, từ những gì tôi hiểu, điều này thực sự hướng đến một cách tiếp cận theo kiểu Thác nước cho dự án. Vấn đề duy nhất (theo tôi) là đây là một dự án Đại học và sinh viên đã có đủ áp lực như khi cố gắng phát triển các dự án vào cuối học kỳ trong tuần dự án. Tôi thực sự không muốn được mã hóa / phát triển / thử nghiệm mọi thứ vào cuối học kỳ, khi tôi sẽ hoảng loạn với nhiều đánh giá khác mà tôi phải giải quyết.

Ít nhất tôi muốn thử và thực hiện một số chu trình phát triển lặp có nghĩa là chúng ta có thể bắt đầu mã hóa / tạo mẫu sớm, có một chu kỳ phát triển liên tục không tập trung vào làm mọi thứ vào phút cuối và không có quá nhiều áp lực kết thúc học kỳ để hoàn thành dự án này Và bây giờ đến (các) câu hỏi thực tế của tôi:

Tôi có thể bằng cách nào đó điều hòa việc phải cung cấp tất cả tài liệu đó với chu kỳ phát triển nhanh, lặp / tạo mẫu không?
Có chiến lược để tạo tài liệu theo cách lặp không?
Tôi có hoàn toàn không hợp lý khi hỏi điều này và mong đợi nó có thể làm được ở trường đại học không?

Ngoài ra, tôi hiểu rằng câu hỏi này cực kỳ cục bộ, vì vậy tôi muốn hỏi những câu hỏi tương tự mà tôi đã hỏi ở trên về mặt công nghiệp, và liệu có nhiều vấn đề mà các quy trình nhanh gặp phải là khác nhau đối với mỗi nhóm không hoặc công ty.

Dù sao, xin lỗi về việc này kéo dài bao lâu, và nếu bạn đã đọc xong tất cả, cảm ơn bạn! Nếu bạn có thể dành thời gian để trả lời, tôi sẽ rất biết ơn! Cảm ơn bạn!

documentation iterative-development

— blahman
nguồn

Điều này không phản hồi, vì vậy tôi không đưa ra câu trả lời. Nhưng đừng làm điều đó . Một phần của những gì người hướng dẫn của bạn muốn là để bạn sắp xếp suy nghĩ và xây dựng khả năng lập kế hoạch và thảo luận về một hệ thống mà bạn chưa viết. Đó là những kỹ năng rất tốt để có và có khả năng tiếp thị cao một khi bạn vài năm trong ngành lập trình.

— Ross Patterson

Ờ được rồi. Tuy nhiên, nếu tôi có thể hỏi, có vẻ như một số phương pháp lập kế hoạch để nhận yêu cầu và khái niệm hóa giải pháp khách hàng liên quan đến việc tạo mẫu cho một sản phẩm có thể --- đây có phải là cách tốt để giúp phát triển hoặc hỗ trợ giai đoạn lập kế hoạch và tài liệu không? Hay đó chỉ là một mong muốn vô lý?

— blahman

Chắc chắn, tạo mẫu là hợp lệ. Trên thực tế, trong một công ty lớn, bạn có thể thấy mình xây dựng một nguyên mẫu để biện minh cho R & D được viết hoa (đó là một kế toán, không phải là một kỹ thuật), ngay cả khi bạn không có ý định sử dụng nguyên mẫu làm cơ sở cho hệ thống cuối cùng. Trong thực tế, các nguyên mẫu tốt nhất là những nguyên mẫu cung cấp hướng dẫn và sau đó bị loại bỏ. Nếu tôi có một niken cho mỗi nguyên mẫu "sản xuất" cần viết lại một vài năm sau đó, tôi sẽ có rất nhiều biệt danh.

— Ross Patterson

Mối quan tâm chính (tôi có một vấn đề tương tự với công việc của mình) là nếu "Quy trình" yêu cầu bạn cung cấp một số vật phẩm nhất định vào một số thời điểm nhất định và không ai được phép thách thức "Quy trình" toàn năng, thì nếu bạn thử, bạn sẽ mất! Đó không chỉ là vấn đề đơn giản của nó là một cách tốt hơn (Phát triển tài liệu lặp đi lặp lại).

Vì vậy, những gì bạn cần làm là làm việc trong quá trình, nhưng tìm một cách để làm việc theo cách bạn muốn là tốt. Chẳng hạn, quy trình của bạn có cho phép sửa đổi tài liệu sau khi gửi không? Nếu không, thì không có phát ngôn lặp đi lặp lại là có thể. Nếu vậy, thì bạn cần phải suy nghĩ về chi phí giao hàng (Về thời gian của bạn, uy tín của bạn, v.v.) và quản lý chi phí đó. Nếu, ví dụ, nó là một bản sao tập tin và không có gì nữa, thì hãy tìm nó. Nếu (như tôi) đó là một đánh giá ngang hàng, phát hành sửa đổi, tác động đến hàng chục người và tiêu tốn hàng ngàn đô la, thì hãy suy nghĩ cẩn thận và đảm bảo tài liệu mới thực sự tăng thêm giá trị.

Một cách phổ biến để làm việc là một tài liệu tối thiểu, cần thiết, đáp ứng nhu cầu của "Quy trình" khi bắt đầu, sau đó là bản cập nhật "được xây dựng" cuối cùng, không chỉ phản ánh thực tế, mà còn có các chi tiết cần thiết, và tóm tắt nơi mã nói cho chính nó.

— mattnz
nguồn

Cảm ơn vì đầu vào của bạn! Tôi đã nghĩ thêm một chút về những gì bạn nói và làm thế nào tôi có thể áp dụng nó cho các dự án của riêng tôi. Với rất nhiều tài liệu của chúng tôi, chúng tôi phải có một khách hàng để tham khảo ý kiến, mặc dù chúng tôi phải nộp theo thời hạn và không có sửa đổi có ý nghĩa sau đó. Phát triển lặp đi lặp lại bởi tư vấn khách hàng vẫn có thể, mặc dù? Ý tôi là, đó là điểm phát triển theo chu kỳ, phải không?

— blahman