Quản lý văn bản


9

Tôi chỉ đơn giản là không thể tưởng tượng việc viết phần mềm mà không có thông số kỹ thuật. Bất kể mức độ sơ sài hay cao cấp như thế nào, thông số kỹ thuật rất quan trọng để giải thích cho các lập trình viên không biết gì về các chức năng của chương trình.

Nhưng vấn đề với thông số kỹ thuật là nó là một công dân hạng hai trong toàn bộ chu trình phát triển phần mềm; khi sự phát triển bốc hơi, nó bị bỏ qua. Nhưng khi tranh chấp xảy ra, các nhà phát triển và người thử nghiệm và bán hàng sẽ tranh giành để tìm thông số kỹ thuật để biện minh cho căn cứ của họ.

Một hoặc nhiều kịch bản sẽ xảy ra:

  1. Thông số kỹ thuật không thể được phục hồi, không ai biết thông số kỹ thuật ở đâu
  2. Các phiên bản khác nhau của thông số kỹ thuật xuất hiện từ các nguồn khác nhau; phải mất nhiều khó khăn tuyệt vời để tìm ra phiên bản là phiên bản mới nhất, hoặc cho dù đó một phiên bản mới nhất hiện có.
  3. Thông số kỹ thuật không đầy đủ, một số phần của tài liệu mà nó đề cập bị thiếu.

Vì vậy, quản lý thông số là quan trọng và điều quan trọng không kém là mọi người chỉ có một Nguồn Thông số duy nhất.

Làm thế nào để bạn quản lý thông số kỹ thuật của bạn? Tôi đã cố gắng để mọi người sử dụng Google Docs nhưng mọi người đều phản đối. Mọi người đều quá gắn bó và say mê với Microsoft Word, đó là - theo ý kiến ​​của họ - rất dễ sử dụng, rất dễ chèn hình ảnh, rất dễ gõ phương trình và không có gì.

Làm thế nào để thuyết phục họ rằng MS Word chỉ là khủng khiếp để chia sẻ?

Câu trả lời:


6

Làm thế nào để thuyết phục họ rằng MS Word chỉ là khủng khiếp để chia sẻ?

Đừng lãng phí thời gian của bạn.

Đầu tiên. Spec phải ở dạng văn bản thuần túy (thực sự) và dưới sự kiểm soát mã nguồn. Sử dụng Markdown hoặc RST hoặc một số công cụ đánh dấu nhẹ khác để tạo trang PDF hoặc HTML. Văn bản thô.

Thứ hai. Lấy các nguồn khác nhau. Hợp nhất chúng. Viết tài liệu cuối cùng của riêng bạn.

Khi họ phản đối, họ có hai lựa chọn.

  1. Sử dụng Google Docs (hoặc công cụ kiểm soát mã nguồn) để chỉnh sửa phiên bản của bạn .

  2. Tiếp tục gửi cho bạn các thay đổi mà bạn chỉnh sửa, lọc và biến thành tài liệu cuối cùng.

Tôi thích # 2. Ai đó cần "sở hữu" thông số kỹ thuật. Và một nhóm người (theo phong cách wiki) dẫn đến các cuộc tranh luận và chiến tranh thay đổi và các tài liệu phụ và các cuộc đối thoại ngoại tuyến và tương tự.


1
+1 và ghi nhớ Quy tắc tối thiểu - Bất kỳ ai muốn có phiên bản ưa thích trong trình chỉnh sửa WYSIWYG đều có thể sao chép đánh dấu được hiển thị.
l0b0

@ l0b0: Liên kết đẹp.
S.Lott

6

Tôi không nghĩ đó là vấn đề "công cụ" mà là vấn đề "quy trình" (hoặc thiếu quy trình).

Bạn có thể đã có một quy trình để phát hành phần mềm (kiểm tra đơn vị, kiểm tra tích hợp, thư phát hành, giao hàng, v.v.), bạn cũng cần phải thực hiện quy trình tài liệu.

  • Ai sẽ viết thông số kỹ thuật? Ai sẽ cập nhật hoặc duy trì chúng?
  • Ai sẽ xem xét các thông số kỹ thuật?
  • Ai sẽ phê duyệt thông số kỹ thuật? Kiến trúc sư, trưởng dự án, QA?
  • Làm thế nào các thông số kỹ thuật được lưu trữ?
  • Ai sẽ đảm bảo rằng không có phiên bản lỗi thời được sử dụng?

2
+1: các vấn đề về công cụ thường là triệu chứng của các vấn đề về quy trình.
S.Lott

chúng tôi có một quy trình nhưng mọi người chỉ thích phàn nàn rằng quy trình đó không hoạt động và cắt góc bất cứ khi nào có thể.
Graviton

@Graviton: vấn đề chính của bạn có lẽ là quản lý không thể thấy việc sử dụng tài liệu và do đó, không thực thi các quy tắc nghiêm ngặt. Nếu bạn muốn mọi thứ được cải thiện, có lẽ bạn sẽ phải cho họ thấy tầm quan trọng của nó.
Xavier T.

4

Một số loại kiểm soát được yêu cầu chắc chắn.

Nó cần phải được phiên bản, và ký tắt, và quá trình này cần phải nghiêm ngặt.

Ở quá nhiều nơi, việc đăng xuất bị bỏ qua và điều này dẫn đến việc đánh nhau.

Vị trí không quan trọng miễn là nó có thể được theo dõi

  • Điểm chia sẻ
  • một ổ đĩa được chia sẻ an toàn, được sao lưu
  • Tôi đã thấy một số nơi sử dụng kiểm soát nguồn mã của họ !!

Nhưng quan trọng hơn là bạn cần mua từ tất cả những người liên quan và 1 hoặc 2 người có trách nhiệm là quản lý cả tài liệu VÀ đăng xuất, ví dụ. Quản lý dự án.


+1, tôi thực sự khuyên bạn nên chuyển tài liệu spec vào kiểm soát nguồn nếu không có gì khác giúp. Một lợi thế là bạn có được lịch sử phiên bản. Ngay cả khi bạn không thể thực hiện các phiên bản khác nhau (trừ khi bạn tìm thấy một plugin có thể khác biệt trên các tệp Word), bạn vẫn có thể trích xuất tất cả các phiên bản và xem những gì đã thay đổi. Điều này có thể RẤT hữu ích trong một tranh chấp về thông số kỹ thuật. Việc đăng xuất cũng rất tốt để có. Và tầm quan trọng của việc mọi người tham gia vào quá trình này (vì vậy không ai có thể nói "khi nào thì quyết định đó?") Không thể được nhấn mạnh đủ.
Thất vọngWithFormsDesigner

0

MS Word là hoàn toàn tốt để tạo ra một spec. Chúng tôi quản lý chúng tôi trong SharePoint, cũng xử lý phiên bản. Nếu bạn không có SharePoint hoặc một sản phẩm quản lý tài liệu khác, Google Docs vẫn ổn (giờ bạn có thể tải lên các tệp .doc / .docx mà không cần chuyển đổi chúng sang định dạng Google Docs). Hoặc như những người khác đã đề xuất, bạn thậm chí có thể lưu trữ chúng trong hệ thống kiểm soát phiên bản mã nguồn của mình (nếu những người tạo ra thông số kỹ thuật có quyền truy cập vào hệ thống đó).


0
 > How to convince them that MS Word is just terrible for sharing?

bạn không thể dễ dàng so sánh sự khác biệt của hai trường hợp trong hệ thống kiểm soát phiên bản.

Tôi không thích thông số kỹ thuật từ vì lý do đó. Nhưng vì đó là một quyết định chính trị để sử dụng các thông số kỹ thuật, chúng tôi có trang "thông tin lịch sử" đầu tiên với các thuộc địa này:

số phiên bản (liên quan đến xác minh sản phẩm), tác giả, ngày tháng, mô tả

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.