Tổ chức phát triển ứng dụng wiki? [đóng cửa]


9

Tìm kiếm cấu trúc thực hành tốt nhất để thiết lập wiki cho nhà phát triển?

Tôi sẽ quản lý một nhóm chưa có hồ sơ theo dõi tốt nhất cho tài liệu, truyền thông và chia sẻ kiến ​​thức. Tôi muốn có một khung được thiết lập để giúp nhóm bắt đầu dễ dàng hơn trong lĩnh vực này.


Tôi đang nghĩ đến việc có một trang chủ cơ bản cho từng dự án hoặc đơn vị công việc bao gồm các tiêu đề như mô tả chức năng, liên hệ chính, phê duyệt, danh sách mã nguồn, ai đang thử nghiệm và với dữ liệu nào, v.v. họ có vui khi chia sẻ? Một cái gì đó sẽ tạo thành một trang bìa trực tuyến cho từng hoạt động phát triển. Cảm ơn một lần nữa
kerrin

Câu trả lời:


10

Đừng tập trung quá nhiều vào việc đưa một cấu trúc hoàn hảo lên phía trước, tốt hơn hãy để nó phát triển hữu cơ . Đó là văn hóa giao tiếp và quá trình quan trọng.

Dưới đây là một số lời khuyên để duy trì đội wiki.

nguyên tắc cơ bản

phản hồi giá trị

Yêu cầu, thu thập và ghi lại bất kỳ phản hồi nào bạn có thể nhận được - thư, nhận xét trang wiki (btw thuận tiện nhất), trình nhắn tin, cuộc trò chuyện.

  • ghi lại phản hồi

    • H: nếu hiện tại tôi không có thời gian để xử lý thông tin đúng cách thì sao?
    • Trả lời: lưu nó tại trang như hiện tại - để xử lý trong tương lai và ẩn nó khỏi các trình đọc thông thường như sau:{excerpt:hidden=true}information to be processed later{excerpt}
  • xử lý phản hồi

    • cố gắng làm nó càng nhanh càng tốt Chi tiết và bối cảnh có vẻ rõ ràng đối với bạn hoặc người nộp ngay bây giờ, có thể bị lãng quên một ngày hoặc tuần hoặc tháng sau  
    • xem xét các giải pháp thay thế cho (các) vấn đề được chỉ ra trong phản hồi. Thí dụ:
      • (thông tin phản hồi) hey thông tin tôi cần được trộn lẫn với thông tin vô dụng
      • (hành động sai) OK Tôi xóa những thứ bạn không cần
      • (hành động đúng) OK Tôi sẽ chia thông tin cho một trong những sở thích của bạn và phần còn lại có thể được người khác quan tâm

đề xuất xử lý ngụ ý công việc lâu dài

  • H: điều gì xảy ra nếu đề xuất giống như nói "thu thập và sắp xếp lại tất cả dữ liệu có liên quan được ghi lại ở hàng nghìn trang khác"?
  • Trả lời: thêm phần TODO-s vào trang của bạn (nếu chưa có) và ghi lại đề xuất trong phần này. Sau đó, bạn cũng có thể sử dụng nó để theo dõi tiến trình của mình
    update DD.MM.YYYY: 475 pages of 1000 are processed

xử lý các đề xuất có vẻ sai đối với bạn

Lưu ý bên cạnh không bao giờ đau lòng để yêu cầu người nộp đề nghị để làm rõ. Mặc dù vậy, trước tiên bạn nên thực hiện phần công việc của mình:

  • kiểm tra lịch sử trang, đưa vào ngày xem xét tài khoản. Luôn có cơ hội người gửi chỉ ra vấn đề từ phiên bản cũ hơn đã được sửa
  • nhìn kỹ hơn vào trang / phần được đề cập và tự hỏi, điều gì có thể khiến anh ấy / cô ấy nghĩ như vậy?
  • (sau khi được đào tạo một chút với mẹo như trên) bạn sẽ thấy rằng trong hầu hết các trường hợp nếu không phải tất cả các trường hợp, có một khu vực riêng biệt để cải thiện ở đó.
    • Ví dụ, hãy tưởng tượng, người dùng phàn nàn về thông tin bị thiếu thực sự hiện diện ở đâu đó trong trang. Mặc dù nhìn sai trên bề mặt, một khiếu nại như vậy thường chỉ ra một vấn đề nghiêm trọng tại trang: cụ thể là một số thông tin quan trọng rất khó tìm. Cung cấp cho nó một khả năng hiển thị mà nó xứng đáng sẽ cải thiện trang.

tốt hơn nhanh

Dựa vào đánh giá và phản hồi. Nếu một cái gì đó thực sự cần chỉnh sửa, thời gian sẽ sắp xếp nó cho bạn

  • điều này cũng áp dụng để tự xem xét. Ghi lại bản nháp của những gì bạn muốn đưa vào trang và xem lại bản thân một giờ (hoặc ngày hoặc tuần) sau - thủ thuật này có thể làm nên điều kỳ diệu
  • đừng lãng phí thời gian để làm cho mọi thứ trở nên hoàn hảo ngay lần thử đầu tiên - điều đó là không thể
    • ghi lại thông tin ngay khi nó trông có vẻ chấp nhận được và yêu cầu những người quan tâm xem xét nó

được in đậm

Hãy mạnh dạn khi cập nhật các trang: sửa lỗi , sửa lỗi ngữ pháp, thêm sự kiện, đảm bảo từ ngữ chính xác, v.v.

  • Trên đây là dựa trên nguyên tắc Wikipedia và được giải thích tốt nhất, tốt, tại Wikipedia
    • ... nhưng xin hãy cẩn thận - quan tâm đến lợi ích chung và không chỉnh sửa một cách thiếu thận trọng: một sự làm rõ về nguyên tắc trên,
      cũng được giải thích tại Wikipedia

nâng cao

biết ơn

Những người đưa ra phản hồi là một tài sản quý giá, hãy biết ơn họ. Những người này đã dành thời gian và nỗ lực của họ để không chỉ đọc trang của bạn mà còn cung cấp phản hồi của họ. Phần lớn người dùng của bạn sẽ không hào phóng với bạn. Những người chia sẻ suy nghĩ của họ là "kem" của khán giả của bạn, hãy biết ơn vì sự đóng góp của họ.

giải thích TLA-s

Nếu bạn không thể tìm ra TLA là gì? - bạn đã hiểu

  • sử dụng các liên kết cho điều đó nếu có thể: TLA

ghi câu trả lời cho câu hỏi

Tôn trọng thời gian của người khác - ghi lại câu trả lời

  • Bạn có thể mất một giây để trả lời câu hỏi, nhưng hãy nghĩ về chàng trai đã hỏi nó? (S) anh ấy đã dành thời gian để đọc trang của bạn, để cố gắng tìm câu trả lời, liên hệ với bạn và chờ câu trả lời của bạn. Nếu bạn ghi lại câu trả lời tại trang, bạn sẽ tiết kiệm tất cả thời gian đó cho chàng trai tiếp theo có câu hỏi này.
  • Ghi câu trả lời cho câu hỏi của riêng bạn. Những gì không rõ ràng với bạn, có thể không rõ ràng cho người đọc tiếp theo.

sử dụng dấu hỏi

Khi nghi ngờ, hãy sử dụng dấu hỏi

  • Confluence cú pháp như một ví dụ: (?) Ví dụ:(?)<this info> needs checking(?)
  • bằng cách này, bất kỳ người đọc nào cũng có thể thấy rõ loại thông tin bạn cần; rất có thể ai đó có thể giúp bạn làm rõ mọi chuyện

liên kết là bạn của bạn

  • DRY - đừng cố sao chép thông tin khi bạn có thể cung cấp liên kết thay thế
  • học cách tóm tắt khi cần

vấn đề hình ảnh

  • Khi bạn có thời gian, hãy tự xem lại trang của mình để tự hỏi liệu người đọc có dễ dàng nhận được điểm mà bạn sẵn sàng thực hiện không
  • Có thể khá khó để tìm thấy chất trong một dòng ý thức không có cấu trúc

    ...Tôi đã cho anh ta tất cả niềm vui mà tôi có thể dẫn dắt anh ta cho đến khi anh ta yêu cầu tôi nói đồng ý và tôi sẽ không trả lời trước khi chỉ nhìn ra biển và bầu trời mà tôi đã nghĩ về rất nhiều điều mà anh ta không biết về Mulvey và ông Stanhope và Hester và Cha và thuyền trưởng già Groves và các thủy thủ chơi tất cả các loài chim bay và tôi nói cúi xuống và rửa chén bát, họ gọi nó trên bến tàu và lính gác trước nhà thống đốc với cái mũ tròn màu trắng của anh ta, một nửa con quỷ tội nghiệp và những cô gái Tây Ban Nha cười trong những chiếc khăn choàng của họ và những chiếc lược cao và những cuộc đấu giá vào buổi sáng, người Hy Lạp và người Do Thái và người Ả Rập và ác quỷ biết ai khác từ cuối đường Châu Âu và Duke và chợ gia cầm đang lảng vảng bên ngoài Larby Sharons và những con lừa tội nghiệp trượt nửa giấc ngủ và những người bạn mơ hồ trong chiếc áo choàng ngủ trong bóng râm trên bậc thang vàNhững bánh xe lớn của những con bò đực và lâu đài cổ hàng nghìn năm tuổi và những người Moors đẹp trai đều mặc đồ trắng và tua rua như những vị vua yêu cầu bạn ngồi xuống trong một cửa hàng nhỏ của họ và Ronda với những cửa sổ cũ của posadas 2 mắt liếc nhìn một mạng tinh thần giấu người yêu để hôn bàn ủi và những ly rượu vang mở ra vào ban đêm và những người thiến và đêm chúng tôi nhớ chiếc thuyền ở Algeciras, người canh gác đang đi thanh thản với chiếc đèn của anh ta và O màu đỏ thẫm đôi khi giống như lửa và hoàng hôn rực rỡ và những bức tượng nhỏ trong khu vườn Alameda, vâng, tất cả những con đường nhỏ kỳ quặc, những ngôi nhà màu hồng và màu xanh và màu vàng và hoa hồng và jessamine và hoa phong lữ và cây xương rồng và Gibraltar khi còn là một cô gái Một bông hoa của núi có khi tôi cài hoa hồng lên tócCác cô gái Andalusia đã sử dụng hay tôi sẽ mặc màu đỏ có và cách anh ta hôn tôi dưới bức tường Moorish và tôi cũng nghĩ anh ta như một người khác và sau đó tôi hỏi anh ta bằng mắt để hỏi lại có và sau đó anh ta hỏi tôi có đồng ý nói không vâng, bông hoa trên núi của tôi và đầu tiên tôi vòng tay ôm lấy anh ấy và kéo anh ấy xuống để anh ấy có thể cảm nhận được bộ ngực của tôi, tất cả đều là nước hoa và trái tim anh ấy như điên lên và tôi nói có, tôi sẽ đồng ý.

thư giãn và vui vẻ

Hãy nhớ rằng thông thường người đọc trang của bạn không cần phải nghiêm túc.

  • khi bạn cảm thấy thích hợp để vui chơi - hãy có nó

http://i.stack.imgur.com/CH9n7.gif

chiến đấu liên kết thối

  • Bạn sẵn sàng để di chuyển một số trang hoặc tài nguyên?
    Tốt thôi, hãy nghĩ về những kẻ giữ liên kết đến nó ở đâu đó trong dấu trang, lưu trữ email, tài liệu của họ, v.v.
  • Khi bạn (di chuyển) trang hoặc tài liệu, hãy giữ một trình giữ chỗ ở nơi nó được đặt trước đó, để giúp khách truy cập hiểu những gì đã xảy ra với nó và nơi để đi
    • <this page> has been moved to <that page>
    • <this document> has been removed because of <the reason>

Tài liệu tham khảo để đọc thêm


4

Đầu tiên, điều quan trọng là chọn một Wiki tốt. Chọn một trong đó:

  1. Được duy trì tốt và có hỗ trợ tốt.
  2. Hỗ trợ xác thực người dùng và có quyền kiểm soát truy cập trên các tài liệu hoặc không gian tên.
  3. Theo dõi các thay đổi đối với tài liệu và cung cấp một lịch sử.
  4. Cho phép thông báo E-mail về thay đổi tài liệu.
  5. Có một trình soạn thảo tốt, tốt nhất là WYSIWYG, và hỗ trợ danh sách, bảng và tải lên hình ảnh.

Điều lớn nhất mà nhóm phát triển Wiki cần là một "người làm vườn": một người chịu trách nhiệm xác định bố cục và cấu trúc của các tài liệu trong Wiki. Nó không phải là một vai trò toàn thời gian nhưng người làm vườn nên có tiếng Anh mạnh mẽ và năng khiếu để giải thích mọi thứ tốt. Người làm vườn nên tạo các mẫu tiêu chuẩn cho các trang, quy ước đặt tên và xác định không gian tên nào là bắt buộc.

Người làm vườn không chịu trách nhiệm tạo nội dung, thực thi nhiều hơn cấu trúc của nó. Ví dụ: nếu ai đó thực hiện thay đổi cho sản phẩm, người làm vườn không chịu trách nhiệm thực hiện thay đổi đối với Wiki. Tuy nhiên, người làm vườn có trách nhiệm đảm bảo thay đổi được thực hiện và nó được thực hiện theo các hướng dẫn (chẳng hạn như chỉ xử lý một trang riêng, không liên kết, chẳng hạn). Người làm vườn có thể xem xét các thay đổi hoặc ủy thác điều đó cho người khác.

Điều quan trọng là cấu trúc Wiki để đáp ứng nhu cầu của khán giả hơn là nhu cầu của những người tạo nội dung. Ví dụ: nếu bạn có một UI chuyên dụng hoặc nhóm bảo mật hoặc bản địa hóa để phát triển phần mềm, đừng đặt thông tin của họ vào các phần riêng biệt. Đặt chúng trong cùng một phần mà các nhà phát triển đang xem xét. Có mọi thứ cùng nhau giúp tìm kiếm dễ dàng hơn nhiều, đảm bảo mọi thứ không bị bỏ lỡ và xác định nội dung lỗi thời nhanh hơn.

Một Wiki cần một sự thay đổi trong tư duy. Nhiều công ty đã quen với thông tin bị ép buộc theo họ. Wiki cho phép người tiêu dùng thông tin sửa đổi nó. Điều này nên được khuyến khích mạnh mẽ (và khen thưởng nếu cần). Nếu sự không chính xác là một mối quan tâm, yêu cầu các nhà đánh giá cấu hình Wiki để E-mail cho họ khi sửa đổi được thực hiện.

Một Wiki phát triển cần một chiến lược để xử lý phiên bản. Nếu bạn có một bộ tài liệu cho phiên bản 1.0, điều gì xảy ra khi phiên bản 2.0 được phát hành? Một số tài liệu cho phiên bản 1.0 vẫn có thể áp dụng cho 2.0 nhưng một số tài liệu có thể được thay thế. Điều gì xảy ra nếu một thay đổi được thực hiện đối với tài liệu 1.0 sau khi phát hành 2.0?

Một Wiki cần một số cách đo lường thành công. Có bao nhiêu người đang sử dụng nó? Họ đã tìm thấy những gì họ đang tìm kiếm? Bạn không nhất thiết cần một hộp đánh giá và bình luận lớn, khó coi ở cuối trang nhưng một liên kết "E-mail một con người về trang này" đơn giản có thể hữu ích.

Cuối cùng, mô hình sử dụng của Wiki sẽ thay đổi theo thời gian. Hãy nhớ xem lại mọi tiêu chuẩn định kỳ để đảm bảo chúng vẫn đáp ứng nhu cầu của Wiki.


Bạn có một đề xuất cho một wiki phù hợp với những yêu cầu đó / bạn sử dụng cái gì không?
Daniel B

Hãy thử Confluence ( atlassian.com/software/confluence/overview ) hoặc SocialText ( socialtext.com ).
akton

Có, chúng tôi sử dụng Confluence (trong toàn bộ CNTT) và rất khuyến khích điều đó - đó chỉ là nhóm ứng dụng đã chống lại ngày hôm nay :)
kerrin

1

Mặc dù đó là một ý tưởng hay rằng tất cả các trang wiki dự án đều theo một chủ đề tương tự để mọi người biết nơi tìm thấy mọi thứ, nhưng điều này sẽ không thực sự giải quyết vấn đề các nhà phát triển không cập nhật trang.

Bạn cần tìm cách để các nhà phát triển của bạn thấy đủ lợi ích khi thực hiện những điều này mà họ điều khiển nó và muốn nó được thực hiện. Nếu không, họ sẽ đơn giản xem nó như một gánh nặng quan liêu từ trên xuống mà họ có thể làm mà không cần.

Tôi đã ở trong tình huống này, cả nơi wiki là một mớ hỗn độn và nơi nó được tổ chức chặt chẽ và trang trọng. Trạng thái của wiki không ảnh hưởng đến mức độ quan tâm của các nhà phát triển.


Hoàn toàn đồng ý drekka - Tôi muốn tìm một điểm giữa giữa quá quy định với cấu trúc và mẫu trang nghiêm ngặt và không có nhà phát triển bị đe dọa bởi trang trống. Ít nhất là trong trường hợp đầu tiên.
kerrin
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.