Manutenzione di un programmatore Wiki [chiuso]

Question

Di recente sono stato incaricato del wiki per il team di sviluppo. Il wiki è ancora agli inizi, quindi ho un sacco di spazio con cui lavorare. L'obiettivo è alloggiare all'interno del team di sviluppo. Attualmente, la principale informazione contenuta nella wiki sono gli standard di codifica.

• Quali sono le migliori pratiche che il tuo team di sviluppo utilizza per il suo wiki interno?
• Quali informazioni sono importanti su un wiki di sviluppo?
• Se dovessi andare sul wiki per il tuo team di sviluppo quali informazioni ti aspetteresti di vedere?
• Ci sono alcune informazioni che non dovrebbero andare sul wiki anche se sembra una buona idea?

- modifica -

• Inoltre, c'è un buon modo per organizzare le informazioni? (come per layer (data, ui), per porject o altro)

Answer 1

• Introduzione alla base di sorgenti per i nuovi programmatori
• Documentazione generale (non la documentazione API di per sé, ma più tutorial come le cose)
• Elenchi del personale / chi sta facendo cosa e come raggiungerli
• Note / risorse / articoli che spiegano i concetti utilizzati nel software
• Documentazione del processo di compilazione e del layout del filesystem della base di codice

Altre cose che di solito metto lì sono

• Pianificazione / liste todo
• Informazioni interessanti per gli altri da leggere
• Tutto il resto che sento dovrebbe essere condiviso

Answer 2

Avevamo un wiki di sviluppo ed è stato un ottimo strumento. L'abbiamo usato per tutto !

• Durante il brainstorming di nuove idee, le cattureremmo sul wiki. La natura a basso attrito della wiki ha reso facile per chiunque nell'organizzazione (eravamo una piccola startup) aggiungere idee mentre pensavano a loro. Abbiamo avuto un "brainstorming" di alto livello pagina collegata a pagine dettagliate contenenti una descrizione completa di ciascuna idea.
• Per ogni iterazione, dovremmo " spostare " presentano elementi dell'idea del "brainstorming" elencare l'elenco delle funzionalità per quella iterazione. I dettagli della funzione sono stati eliminati per includere dettagli di progettazione e implementazione.
• Man mano che le funzionalità venivano completate, la pagina di iterazione è diventata la nostra pagina delle note di rilascio, che includeva anche il tag di rilascio dal nostro sistema di controllo della versione.
• Avevamo una pagina di bug che funzionava in modo molto simile alle pagine delle funzionalità. Correzioni di bug sono state aggiunte alle pagine di iterazione / rilascio man mano che venivano elaborate / completate.
• Abbiamo anche creato la documentazione per l'utente sul wiki ed esportato quelle pagine con il rilascio.

Col ??passare del tempo. Questo strumento è stato visto sempre più prezioso. Abbiamo finito per creare nuovi wiki per diversi prodotti su cui l'azienda stava lavorando.

Spero che il tuo wiki di sviluppo sia utile quanto noi!

Answer 3

Wikipatterns è un sito web dedicato alla documentazione delle migliori pratiche wiki. Descrivono anche gli anti-schemi e parlano dei modi per affrontarli. Ho letto il loro libro ed è stata una grande risorsa per me far decollare una wiki in un'organizzazione di oltre 150 persone.

Answer 4

Una cosa che sottolineiamo sul nostro wiki dev è che viene aggiornato quando le cose cambiano. Non vogliamo che la nostra wiki che abbia lo scopo di fornire informazioni ed essere una fonte centrale di conoscenza raccolta divenga così obsoleta da renderla inutile. Man mano che il codice viene aggiornato, agli sviluppatori viene richiesto di aggiornare tutte le informazioni correlate sul wiki.

Oltre agli standard di codifica, manteniamo suggerimenti e trucchi per lavorare con la nostra base di codice, informazioni sulla configurazione per i nuovi assunti e informazioni generali sull'ambiente.

Answer 5

• Grafici di burndown
• informazioni di configurazione comuni per ambienti di sviluppo (utili per l'avvio di nuove persone)
• Tutte le specifiche
• Problemi noti e soluzioni alternative con strumenti di sviluppo

Answer 6

Trova una sorta di guida di stile e insegna agli altri come modellare le cose. Quando ero responsabile di un wiki aziendale, tutti gli altri sviluppatori scrivevano solo prose scadenti che erano appena formattate e sembravano terribili.

Stai lontano dalle cose che richiedono discussione. Ho provato calzascarpe in una sezione di recensione di un libro, ma era troppo difficile avere altri commenti sulle cose.

Gli esempi di librerie interne sono buoni. E / o "storyboard" guida l'utente attraverso un processo quando viene chiamato MethodX.

Answer 7

Quali sono le migliori pratiche che il tuo team di sviluppo utilizza per il suo wiki interno?

Fallo sembrare bello. So che non sembra importante, ma se trascorri un po 'di tempo a marchiare, ripaga in termini di persone che lo usano effettivamente. E l'adozione è la chiave, o semplicemente appassirà e morirà.

Quali informazioni sono importanti su un wiki di sviluppo?

• Informazioni generali su un progetto, pietre miliari, date di consegna ecc.
• Sintesi delle decisioni / riunioni di progettazione. Importante in modo da non visitare nuovamente le stesse aree più volte.
• Guide per lo sviluppo generale dei progetti attuali (ad esempio, come sviluppare un nuovo plugin)

Se dovessi andare sul wiki per il tuo team di sviluppo quali informazioni ti aspetteresti di vedere?

Informazioni sul progetto, chi sta lavorando su cosa ecc. Decisioni di progettazione. Anche le migliori pratiche e collegamenti a siti utili.

Ci sono alcune informazioni che non dovrebbero andare sul wiki anche se sembra una buona idea?

Gli elenchi di attività di basso livello tendono a fluttuare e non essere aggiornati e possono essere fuorvianti. Inoltre, le comunicazioni critiche tra i reparti sono più adatte all'e-mail, POI la conversazione può essere copiata sul wiki. È troppo facile ignorarlo altrimenti!

Answer 8

Ricorda che un wiki è interattivo. Se stai pensando di pubblicare, come nel pubblicare grafici di burndown, allora non stai pensando abbastanza lontano. La distribuzione di tali informazioni è solo una parte di esse.

Ad esempio, anziché avere un " grafico di burndown attuale " pagina, crea una pagina per " Burndown Chart per la settimana del 10-27-2008 " e poi incoraggia le persone a commentare sul grafico, cosa significa e perché hai fatto così male quella settimana.

Answer 9

La parte più difficile è convincere gli sviluppatori a usare la tua wiki. Ho alcuni suggerimenti di vecchia data qui: http://possibility.com/wiki/index. php? title = GettingYourWikiAdopted

Ottenere un Wiki adottato è difficile

Avere un campione

Rimuovi obiezioni

Crea contenuto

Incanta il Wiki nei processi aziendali

Evangelizza

Non mollare

Considera di non utilizzare Wiki per le conversazioni

Fallo e basta! Non aspettare un budget

Avere un piano di transizione

Promuovi il tuo Wiki

Una buona pratica è quella di avere l'intera documentazione e il codice sorgente per ogni build disponibile attraverso la tua wiki. Quindi gli sviluppatori accederanno al wiki per accedere alle informazioni di build e questo lo rende prezioso.

Answer 10

I wiki possono essere una risorsa preziosa per i team di sviluppo software, ma non sono un proiettile d'argento. È fin troppo facile creare un Wiki che cadrebbe rapidamente in disuso o diventasse gravemente obsoleto.

Secondo me, la chiave per un Wiki di successo è far entrare tutto il team. Ciò significa allontanare le persone da altre risorse (e in particolare archivi di posta elettronica) come archivi di conoscenza e offrire un incentivo alle persone per contribuire.

Tuttavia, è anche importante non essere uno zar di formato: se hai molti documenti che generi in, diciamo, MS WORD, potrebbe essere l'ideale per farli tutti in formato Wiki ma ciò richiede tempo e potrebbe essere fastidioso se hai diagrammi, documenti, ecc. In questi casi, è meglio scendere a compromessi e lasciare che le persone lo mantengano in formato word, purché l'unico modo per accedere alla versione più recente sia tramite il Wiki.

Se non sei un manager, devi ingaggiarlo perché richiederebbe un po 'di "applicazione".

Si sono accumulate ricerche ed esperienze su Wiki e il loro uso nell'ingegneria del software. È possibile cercare nella libreria digitale ACM, ad esempio. Sono un organizzatore di un seminario annuale sui wiki per SE e abbiamo avuto diversi rapporti di esperienza interessanti e ci sono materiali aggiuntivi nel simposio internazionale su Wiki.

Answer 11

Ospitiamo il wiki del team interno. E lì mettiamo tutte le informazioni necessarie per ogni progetto che stiamo sviluppando:

• repository
• indirizzi per macchine virtuali
• password
• documentazione del progetto
• panoramica del progetto
• stato del progetto

e qualsiasi altra cosa che riempiamo deve essere scritta su un progetto. Ed è l'applicazione web più utile che stiamo eseguendo (oltre a Mantis ). In pagine più generali mettiamo una definizione di ogni tassonomia che stiamo usando, linee guida generali di progetto, politiche, codifica e pratiche di sviluppo che usiamo. È lì, è semplice ed efficace e penso che ogni squadra dovrebbe averne uno.