A manutenção de um programador Wiki [fechado]

Question

Recentemente, fui encarregado do wiki para a equipe de desenvolvimento. O wiki ainda está em sua infância, então eu tenho um monte de espaço para trabalhar. É objetivo é abrigar interna para a equipe de desenvolvimento. Atualmente, a principal peça de informação que o wiki detém é Padrões de Codificação.

• Quais são algumas das melhores práticas seus usos Dev Team para a sua wiki interna?
• Que informação é importante ter em um wiki dev?
• Se você fosse para ir para o wiki para sua equipe dev quais informações você poderia esperar para ver?
• Existe alguma informação que não deve ir na wiki mesmo que parece ser uma boa ideia?

- edição -

• Além disso, existe uma boa maneira de organizar a informação? (Tal como por camada (dados, IU), porject, ou outro)

Answer 1

• Introdução à base de fonte para novos programadores
• Documentação geral (não a documentação da API per-se, mas mais tutorial como coisas)
• As listas de pessoal / quem está fazendo o que e como alcançá-los
• Notas / recursos / artigos que explicam conceitos utilizados no software
• Documentação do processo de construção e o layout do sistema de arquivos da base de código

Outras coisas que eu costumo colocar-se há

• Planejamento / listas de tarefas
• A informação que é interessante para outros lerem
• Tudo o resto que eu sinto deve ser compartilhada

Answer 2

Nós tivemos um wiki de desenvolvimento e foi uma grande ferramenta. Nós usamos isso para tudo !

• Quando brainstorming de novas ideias, nós capturá-los no wiki. A baixa natureza atrito do wiki tornou fácil para qualquer pessoa na organização (estávamos uma pequena empresa) para adicionar ideias como eles pensavam deles. Tivemos um alto nível de "brainstorm" página que ligava para páginas detalhadas, contendo uma descrição completa de cada idéia.
• Para cada iteração, estaríamos "Move" itens recurso ideia da lista de "brainstorm" para a lista de recursos para a iteração. Os detalhes do recurso foram liberadas para incluir design e implementação detalhes.
• Como características foram concluídas, a página iteração se tornou nossa página de notas de versão -. Que também incluiu a tag lançamento do nosso sistema de controle de versão
• Tivemos uma página de erro que trabalhou muito semelhante às páginas de recurso. correções de bugs foram adicionados às páginas iteração / libertação como eles foram trabalhados / completa.
• Também criamos nossa documentação de usuário no wiki e exportados essas páginas com o lançamento.

Conforme o tempo passava. Esta ferramenta foi visto mais e mais valioso. Nós acabou criando novos wikis para diferentes produtos que a empresa estava trabalhando.

Eu espero que você encontrar o seu wiki desenvolvimento tão útil como fizemos!

Answer 3

Wikipatterns é um site dedicado a documentar as melhores práticas wiki. Eles também descrevem anti-padrões e falar sobre maneiras de lidar com eles. Eu li seu livro e foi um grande trunfo para mim para obter um wiki fora da terra em uma organização 150+ pessoa.

Answer 4

Uma coisa que insistimos em nosso wiki dev é que ele é atualizado quando as coisas mudam. Nós não queremos que a nossa wiki que se destina a fornecer informações e ser uma fonte central de conhecimento coletado para tornar-se tão fora de data que é inútil. Como o código é atualizado, os desenvolvedores são convidados a atualizar qualquer informação relacionada sobre o wiki.

Além de Padrões de Codificação, mantemos dicas e truques para trabalhar com a nossa base de código, informações de configuração para novas contratações, e informações gerais meio ambiente.

Answer 5

• gráficos Burndown
• informações de configuração comum para ambientes de desenvolvimento (bom para quando novas pessoas começam a)
• Specs
• Problemas conhecidos e soluções com ferramentas de desenvolvimento

Answer 6

Come-se com algum tipo de guia de estilo, e ensinar aos outros como coisas estilo. Quando eu estava no comando de um wiki corporativo, todos os outros desenvolvedores faria prosa crummy apenas gravação que foi mal formatado, e parecia terrível.

Mantenha longe de coisas que requerem discussão. Tentei encaixar em uma seção crítica de livros, mas era muito difícil ter outros comentário sobre as coisas.

Exemplos de bibliotecas em casa são bons. E / ou "storyboards" andar um usuário através de um processo quando MethodX é chamado.

Answer 7

Quais são algumas das melhores práticas seus usos Dev Team para a sua wiki interna?

torná-la agradável. Eu sei que isso não soa importante, mas se você gastar um pouco de tempo a marca vale a pena em termos de pessoas realmente utilizá-lo. E absorção é fundamental, ou ela só vai murchar e morrer.

Que informação é importante ter em um wiki dev?

• Informações gerais sobre um projeto, marcos, datas de entrega, etc.
• Sínteses da decisões de design / reuniões. tão importante que você não re-visitar o mesmo áreas e outra vez.
• HowTo guias para o desenvolvimento geral dos projectos em curso (por exemplo, como desenvolver um novo plug-in)

Se você fosse para ir para o wiki para sua equipe dev quais informações você esperaria ver?

As informações do projeto, que está trabalhando no que etc. decisões de design. Também as melhores práticas e links para sites úteis.

Existe alguma informação que não deve ir na wiki mesmo que parece ser uma boa ideia?

listas de tarefas de baixo nível tendem a flutuar e não ser mantido up-to-date, e pode ser enganosa. Além disso, as comunicações críticas entre departamentos são mais adequados para e-mail, então a conversa pode ser copiado para o wiki. É muito fácil de ignorá-lo de outra maneira!

Answer 8

Lembre-se que um wiki é interativo. Se você está pensando sobre a publicação, como em publicar gráficos de burndown, então você não está pensando longe o suficiente. Distribuindo essa informação é apenas uma parte dela.

Por exemplo, em vez de ter uma página "Burndown atual Chart", criar uma página para "Burndown Chart para a semana de 2008/10/27" e, em seguida, encorajar as pessoas a comentar sobre a carta, eo que isso significa, e por que você fez tão mal naquela semana.

Answer 9

A parte mais difícil é obter os desenvolvedores a usar o seu wiki. Eu tenho algumas sugestões de longa data aqui: http://possibility.com/wiki/index. php? title = GettingYourWikiAdopted

Conseguir um Wiki adotado é resistente

Tenha um campeão

Remover Objeções

Criar conteúdo

enredam o Processos Wiki Na Companhia

Evangelize

Do not Give Up

Considere não usar Wiki para conversas

Just Do It! Não espere por um orçamento

Tenha um Plano de Transição

Promover o seu Wiki

Uma boa prática é ter toda a documentação e código fonte para cada compilação disponível através do seu wiki. Em seguida, os desenvolvedores irão para o wiki para informações de acesso de construção e que o torna inestimável.

Answer 10

Wikis podem ser um recurso valioso para as equipes de desenvolvimento de software, mas eles não são uma bala de prata. É muito fácil criar um Wiki que rapidamente cair em desuso ou tornar-se grosseiramente ultrapassada.

Na minha opinião, a chave para um Wiki bem sucedida está ficando toda a equipe a bordo. Isso significa levar as pessoas longe de outros recursos (nomeadamente os arquivos de e-mail) como repositórios de conhecimento, e oferecendo um incentivo para as pessoas a contribuir.

No entanto, também é importante para não ser um czar formato: Se você tem um monte de documentos que você gera em, digamos, MS WORD, pode ser ideal para fazê-los todos em formato Wiki, mas isso leva tempo e pode ser irritante se você tem diagramas, documentos, etc. nesses casos, é melhor compromisso e deixar as pessoas mantê-lo em formato de texto, contanto que a única forma de acesso a versão mais recente é através do Wiki.

Se você não tiver um gerente, você precisa para obter um gerente a bordo porque exigiria algum "execução".

Não foi acumulando pesquisa e experiência em Wikis e seu uso em engenharia de software. Você pode pesquisar na biblioteca digital da ACM, por exemplo. Eu sou um co-organizador de um workshop anual sobre wikis para SE e tivemos vários relatos de experiência interessante e existem materiais adicionais no simpósio internacional sobre Wikis.

Answer 11

Nós abrigar e wiki equipe inhouse. E lá vamos colocar todas as informações necessárias para cada projeto que estamos desenvolvendo:

• repositórios
• endereços para máquinas virtuais
• senhas
• documentações do projeto
• Visão geral do projeto
• status do projeto

e necessidades enchemos qualquer outra coisa a ser escrito em um projeto. E é a aplicação web mais útil que estão em execução (além Mantis ). Em páginas mais gerais, colocamos uma definição de cada taxonomia estamos usando, as diretrizes gerais do projeto, políticas, codificação e desenvolvimento de práticas que usamos. É lá, é simples e eficaz e eu acho que cada equipe deve ter um desses.