Maintenir un wiki de programmeur [fermé]

Question

J'ai récemment été nommé responsable du wiki pour l'équipe de développement. Le wiki en est encore à ses balbutiements, j'ai donc beaucoup de place pour travailler. Son objectif est de loger à l’intérieur de l’équipe de développement. Actuellement, la principale information contenue dans le wiki concerne les normes de codage.

• Quelles sont les meilleures pratiques que votre équipe de développement utilise pour son wiki interne?
• Quelles informations est-il important d'avoir sur un wiki de dev?
• Si vous deviez accéder au wiki de votre équipe de développement, quelles informations souhaiteriez-vous voir?
• Existe-t-il des informations qui ne devraient pas figurer sur le wiki, même si cela semble être une bonne idée?

- modifier -

• En outre, existe-t-il un bon moyen d'organiser les informations? (comme par couche (données, interface utilisateur), par projet ou autre)

Answer 1

• Introduction à la base des sources pour les nouveaux programmeurs
• Documentation générale (pas la documentation de l'API en tant que telle, mais davantage de didacticiels similaires)
• Listes du personnel / qui fait quoi et comment les contacter
• Notes / ressources / articles expliquant les concepts utilisés dans le logiciel
• Documentation du processus de construction et de la structure du système de fichiers de la base de code

Les autres choses que je mets habituellement en place sont

• Listes de planification / tâches
• Informations intéressantes à lire pour les autres
• Tout ce qui, à mon avis, devrait être partagé

Answer 2

Nous avions un wiki de développement et c’était un excellent outil. Nous l'avons utilisé pour tout !

• Lorsque nous réfléchissions à de nouvelles idées, nous les capturions sur le wiki. La nature peu glissante du wiki a permis à n'importe qui dans l’organisation (nous étions une petite startup) d’ajouter des idées au fur et à mesure qu’ils y pensaient. Nous avons eu un "niveau de brainstorming" de haut niveau. Cette page est liée à des pages détaillées contenant une description détaillée de chaque idée.
• Pour chaque itération, nous "bougerons" Présenter des idées du "brainstorming" liste à la liste des fonctionnalités pour cette itération. Les détails de la fonctionnalité ont été supprimés afin d'inclure les détails de conception et de mise en œuvre.
• Une fois les fonctionnalités terminées, la page d'itération est devenue notre page de notes de publication, qui comprenait également la balise de publication de notre système de contrôle de version.
• Nous avions une page de bogue qui fonctionnait de manière très similaire aux pages de fonctionnalité. Des corrections de bugs ont été ajoutées aux pages d'itération / édition au fur et à mesure de leur travail / achèvement.
• Nous avons également créé notre documentation utilisateur sur le wiki et exporté ces pages avec la version.

Au fil du temps. Cet outil a été vu de plus en plus précieux. Nous avons fini par créer de nouveaux wikis pour différents produits sur lesquels la société travaillait.

J'espère que votre wiki de développement sera aussi utile que nous!

Answer 3

Wikipatterns est un site Web dédié à la documentation des meilleures pratiques de wiki. Ils décrivent également les anti-modèles et discutent des moyens de les traiter. J'ai lu leur livre et c'était un grand atout pour moi de lancer un wiki dans une organisation de plus de 150 personnes.

Answer 4

Une chose sur laquelle nous insistons sur notre wiki de développement est qu’il est mis à jour lorsque les choses changent. Nous ne voulons pas que notre wiki destiné à fournir des informations et à constituer une source centrale de connaissances collectées devienne tellement obsolète qu’il est inutile. À mesure que le code est mis à jour, les développeurs sont invités à mettre à jour les informations connexes sur le wiki.

Hormis les normes de codage, nous conservons des astuces pour travailler avec notre base de code, des informations de configuration pour les nouveaux employés et des informations générales sur l'environnement.

Answer 5

• graphiques de Burndown
• informations de configuration communes pour les environnements de développement (utile lorsque de nouvelles personnes démarrent)
• Spécifications
• Problèmes connus et solutions de contournement avec les outils de développement

Answer 6

Élaborez une sorte de guide de style et apprenez aux autres comment styliser des objets. Quand j'étais responsable d'un wiki d'entreprise, tous les autres développeurs écrivaient simplement une prose minable qui était à peine formatée et qui avait l'air horrible.

Éloignez-vous des choses qui nécessitent une discussion. J'ai essayé le chausse-pied dans une section de critique de livre, mais il était trop difficile de laisser les autres commenter.

Les exemples de bibliothèques internes sont bons. Et / ou "Scénarimage" guider un utilisateur dans un processus lorsque MethodX est appelé.

Answer 7

Quelles sont les meilleures pratiques que votre équipe de développement utilise pour son wiki interne?

Faites que ça paraisse bien. Je sais que cela ne semble pas important, mais si vous passez un peu de temps à le valoriser, cela vaut la peine d'être utilisé par les gens. Et la participation est la clé, sinon elle fléchira et mourra.

Quelles informations est-il important d'avoir sur un dev wiki?

• Informations générales sur un projet, jalons, dates de livraison, etc.
• Résumés des décisions / réunions de conception. Important pour que vous ne reveniez pas sans cesse dans les mêmes zones.
• Guides pratiques pour le développement général des projets en cours (par exemple, comment développer un nouveau plugin)

Si vous deviez aller sur le wiki de votre équipe de développement, quelles informations souhaiteriez-vous voir?

Informations sur le projet, qui travaille sur quoi, etc. Décisions de conception. Également les meilleures pratiques et des liens vers des sites utiles.

Existe-t-il des informations qui ne devraient pas figurer sur le wiki même si cela semble être une bonne idée?

Les listes de tâches de bas niveau ont tendance à fluctuer et à ne pas être tenues à jour, et peuvent être trompeuses. En outre, les communications critiques entre les services sont mieux adaptées au courrier électronique, alors la conversation peut être copiée sur le wiki. Il est trop facile de l'ignorer autrement!

Answer 8

Rappelez-vous qu'un wiki est interactif. Si vous songez à publier, par exemple en publiant des graphiques de burndown, vous ne songez pas assez loin. La diffusion de ces informations n’en est qu’une partie.

Par exemple, au lieu d’avoir un " Current Burndown Chart " page, créez une page pour " Burndown Chart pour la semaine du 27.10.2008 " et encouragez ensuite les gens à commenter le graphique, et ce qu’il signifie, et pourquoi vous avez si mal fait cette semaine.

Answer 9

Le plus difficile est d’amener les développeurs à utiliser votre wiki. J'ai quelques suggestions de longue date ici: http://possibility.com/wiki/index. php? title = ObtenirVotreWikiAdopté

Adopter un wiki est difficile

Avoir un champion

Supprimer les objections

Créer du contenu

Intégrer le Wiki dans les processus de l'entreprise

Évangéliser

N'abandonnez pas

Envisagez de ne pas utiliser le wiki pour les conversations

Faites-le! N'attendez pas un budget

Avoir un plan de transition

Promotion de votre wiki

Une bonne pratique consiste à disposer de toute la documentation et du code source de chaque version disponible sur votre wiki. Ensuite, les développeurs iront sur wiki pour accéder aux informations de construction, ce qui les rend inestimables.

Answer 10

Les wikis peuvent constituer une ressource précieuse pour les équipes de développement de logiciels, mais ils ne sont pas une solution miracle. Il est trop facile de créer un wiki qui tomberait rapidement en désuétude ou deviendrait complètement obsolète.

À mon avis, la clé d'un Wiki réussi consiste à impliquer toute l'équipe. Cela signifie que les gens doivent se détourner d'autres ressources (notamment les archives de courrier électronique) en tant que référentiels de connaissances, et offrir une incitation à la contribution des personnes.

Cependant, il est également important de ne pas être un czar au format: si vous générez beaucoup de documents, par exemple, MS WORD, il peut être idéal de les faire tous au format Wiki, mais cela prend du temps et peut-être ennuyeux si vous avez des diagrammes, des documents, etc. Dans ces cas, il est préférable de faire des compromis et de laisser les gens le conserver au format Word, tant que le seul moyen d'accéder à la version la plus récente est via le Wiki.

Si vous n'êtes pas un responsable, vous devez engager un responsable, car cela nécessiterait un certain "contrôle".

De nombreuses recherches et expériences ont été menées sur les wikis et leur utilisation en génie logiciel. Vous pouvez rechercher dans la bibliothèque numérique ACM, par exemple. Je suis coorganisateur d'un atelier annuel sur les wikis pour SE et nous avons eu plusieurs rapports d'expérience intéressants. De plus, le symposium international sur les wikis contient des informations supplémentaires.

Answer 11

Nous hébergeons et intégrons le wiki de l'équipe. Et nous avons mis toutes les informations nécessaires pour chaque projet que nous développons:

• référentiels
• adresses pour les machines virtuelles
• mots de passe
• documentation du projet
• aperçu du projet
• statut du projet

et tout ce que nous remplissons doit être écrit sur un projet. Et c’est l’application Web la plus utile que nous exécutons (à part Mantis ). Sur des pages plus générales, nous donnons une définition de chaque taxonomie que nous utilisons, des directives de projet générales, des politiques, des pratiques de codage et de développement que nous utilisons. C’est là, c’est simple et efficace et je pense que chaque équipe devrait en avoir un.