Pour un projet de développement logiciel, quel est le meilleur type de wiki? [fermé]


32

J'essaie de mettre en place un wiki / système de gestion pour un projet logiciel et je continue à être confus par la myriade d'options disponibles.

J'ai déjà vu TWiki et Plone , qui se présentent comme des composants de niveau entreprise. Seraient-ils mieux à utiliser que quelque chose comme, disons, MediaWiki?

Quelles sont quelques autres suggestions pour le logiciel wiki / gestion?


2
Voulez-vous connecter votre wiki à d'autres systèmes? Suivi des bugs, support client, planification?
Anthony Mastrean

S'agit-il d'un projet isolé et d'un projet open source ou d'un projet professionnel?
Gelatin

5
Appartient à StackOverflow
Casebash

2
@Casebash: Je ne suis pas d'accord. Ce n'est pas une question de codage. Et s'il demandait le meilleur wiki pour un cabinet fiscal?
Prestaul

Prestaul: Alors ça irait ici. Les outils couramment utilisés par les développeurs de logiciels appartiennent à Stack Overflow - c'est indiqué dans la FAQ. Je crois que les wikis d'entreprise et d'équipe gagnent en popularité - les trois derniers emplois que j'ai utilisés dans une sorte d'espace de travail partagé (wiki ou référentiel de fichiers où l'équipe avait un accès en lecture / écriture) pour la collaboration.
Thomas Owens

Réponses:


16

Vous ne pouvez vraiment pas battre Confluence , surtout pour 10 $ (pour 10 utilisateurs ou moins). Nous l'utilisons dans mon travail et c'est vraiment fantastique. L'organisation prend cependant un peu de temps pour s'y habituer.


1
C'est peut-être la façon dont mon entreprise l'utilise, mais j'ai trouvé que Confluence était pénible à utiliser.
Marc

1
En fait, j'utilise déjà Jira, donc entendre de bonnes choses sur Confluence est utile!
samoz

1
Confluence prend souvent plus d'une minute (parfois beaucoup plus) juste pour "se réchauffer" le matin. Non seulement cela, mais il est incapable d'échapper à certains personnages (comme bashslash), ce qui rend ce wiki inutile pour spécifier les chemins Windows. C'est un produit mal pensé et terriblement inadéquat pour l'entreprise.
PP.


9

Avertissement: je travaille pour Fog Creek

Le wiki FogBugz est génial car il est intégré au reste de l'application, mais l'éditeur est bogué. La bonne nouvelle est que nous procédons à une refonte majeure.


8

Je suggère ScrewTurn pour wiki.

Vous pouvez également jeter un œil à AxoSoft OnTime qui est un très bon logiciel pour le suivi des bogues, la gestion de projet Scrum / Agile, le wiki de développement, le service d'assistance et plus encore.


2
attention .. le développement du tour de vis est interrompu
nWorx

8

J'ai un Wiki non recommandé: celui disponible pour les sites intranet Sharepoint. Tout à fait une douleur à utiliser.


Je suis d'accord avec vous, mais je ne sais pas si je voterai pour ou contre.
Kyralessa

Je ne pourrais plus être d'accord avec toi ...
Gang Yin

4

Nous utilisons DokuWiki

Voici un tableau de comparaison entre DokuWiki, MediaWiki, TWiki et TracWiki


Une bonne chose à propos de DokuWiki est parce que c'est une base de données de fichiers plats qui ne coûte pas la plupart des ressources du serveur, vous pouvez donc avoir un wiki par projet.
Myles Braithwaite

4

Dans le cas où quelqu'un envisage TWiki (le Wiki sur lequel j'étais développeur de 2000 à 2008), n'oubliez pas de vérifier la fourchette - http://foswiki.org . Nous pensons que nous avons été obligés de bifurquer lorsque le détenteur de la marque TWiki a réinventé le projet comme «open source commercial» et a réduit notre capacité à déterminer comment nous ferions du bénévolat.


3

J'ai mis en place un site intranet pour diffuser la recherche de et vers la foule techniquement avertie, mais certainement pas techniquement compétente. J'ai essayé plusieurs solutions, et PMWiki est le meilleur. Facile à administrer, BEAUCOUP de "plugins", skins et extensions des personnes qui l'utilisent, facile à utiliser pour les gens moins techniques et avec une grande base, il ne sera pas abandonné de sitôt.

Il s'agissait de configurer une alternative aux e-mails aléatoires ou aux documents Word sur un serveur de fichiers. Un «système de gestion des connaissances». Je l'ai trouvé beaucoup plus facile à utiliser que TWiki.


Je gère une installation pmwiki au travail et quelques sites Web personnels l'utilisant comme CMS. Excellent soutien communautaire.
Michael Paulukonis

3

Nous utilisons Assembla dans l'entreprise que je dirige. Ils fournissent l'hébergement de code illimité (Git / SVN), la billetterie, le wiki, la mêlée et d'autres outils utiles, et ne coûtent pas beaucoup.


3

Nous avons essayé la plupart des packages wiki au fil des ans avec peu de succès. Il était juste difficile d'obtenir suffisamment de traction pour que les équipes de développement et de projet en utilisent réellement une.

Nous avons décroché l'or après notre conversion vers Google Apps Enterprise pour les e-mails et le calendrier, car il est également livré avec "Sites". Il s'avère que Google Sites peut fonctionner comme un outil wiki très flexible et facile à utiliser. Construit en public / privé / partage également, de sorte que certains sites peuvent être accessibles au public tandis que d'autres sont internes (par Google Apps ID) uniquement.



2

J'aime le logiciel Basecamp de 37signals . Vous obtenez une excellente solution hébergée peu coûteuse avec de nombreuses fonctionnalités utiles.


2

J'utilise Redmine avec mon équipe. Il est gratuit et possède un wiki plus que suffisant.


2

J'aime le genre d'applications CODE FORGE , comme Trac ou Redmine, si vous avez un endroit pour l'héberger. Ou Google Code / SourceForge pour les options hébergées gratuites si cela ne vous dérange pas de faire vos projets open source.


2

J'ai eu le même dilemme quel wiki utiliser pour un projet de développement il y a quelques mois. Nous avons opté pour Mindtouch car il est gratuit (Mindtouch Core), il possède de nombreuses extensions intéressantes, la conception est moderne et flexible, les capacités de connexion et de liaison de fichiers sont complètes et il peut rechercher dans le contenu des fichiers. La communauté et les forums sont également forts. Nous avons été très satisfaits de ce choix.


2

Je choisirais Trac , qui est parfait pour le développement de logiciels car il combine Wiki avec la gestion des problèmes et le contrôle des versions.

Depuis leur site,

Trac est un wiki amélioré et un système de suivi des problèmes pour les projets de développement logiciel. Trac utilise une approche minimaliste de la gestion de projets logiciels sur le Web. Notre mission est d'aider les développeurs à écrire d'excellents logiciels tout en restant à l'écart. Trac devrait imposer le moins possible au processus et aux politiques de développement d'une équipe.

Il est donc conçu pour les équipes de développement logiciel.


2

Je pense que cela dépend de vos besoins.

Le meilleur et le plus simple à configurer / utiliser que j'ai vu est:

TiddlyWiki

Un wiki dans un fichier. Il utilise JavaScript pour tout faire et fonctionne très bien!



0

XWiki est un wiki professionnel avec des fonctionnalités d'entreprise telles que Blog, gestion des droits renforcée, authentification LDAP, exportation PDF, skining complet et plus encore. Il comprend également un moteur de formulaire et de script avancé qui en fait un environnement de développement pour les applications basées sur les données. Il possède de puissantes fonctionnalités d'extensibilité telles que l'écriture de scripts dans les pages, les plugins et une architecture hautement modulaire. Consultez la liste complète des fonctionnalités pour en savoir plus.


0

Nous sommes de grands fans de dokuWiki qui est flexible, simple (pas de base de données mais vous pouvez si vous le souhaitez) et possède de superbes fonctionnalités.


0

Vous devriez considérer PBWiki qui a une interface vraiment géniale, est gratuit pour les petits projets, le contrôle d'accès au niveau utilisateur et des fonctionnalités plus amusantes. (Sans oublier que je l'ai utilisé moi-même avec d'excellents résultats.)

Fonctionnalités de PBWiki


0

Plus important encore que le logiciel que vous choisissez est de vous assurer que vous comprenez ce que vous essayez de faire avec le wiki. Sans une structure consciente globale, un wiki devient facilement inutilisable. En outre (bien que ce ne soit pas aussi crucial), il est logique d'en apprendre davantage sur le comportement des wikis, car ce n'est pas une solution miracle:

http://www.wikipatterns.com

Ensuite, vous voudrez peut-être considérer en tant qu'administrateur ce que vous recherchez dans le wiki - il y a par exemple une différence significative dans la façon dont ils sont scriptables, probablement avec le twiki se retrouvant au sommet (ou la confluence avec laquelle j'ai peu d'expérience). Par exemple, MediaWiki est complètement adapté pour les environnements principalement ouverts, leurs fonctionnalités ACL ne sont pas si bonnes. Un autre aspect est que ceux-ci peuvent être trop lourds et complexes pour ce que vous voulez faire, et vous devriez vous contenter d'un wiki comme celui intégré au système de ticket Trac.


0

J'ai défendu une entreprise similaire il y a quelque temps et j'ai choisi MoinMoin . C'est gratuit et très facile à installer et à configurer. J'ai fini par gérer plusieurs instances de wiki avec ce moteur - une pour chacun des différents projets sur lesquels l'équipe de développement travaillait.



0

Je suggère PmWiki . C'est très simple et ne monopolise pas vraiment les ressources et utilise des fichiers pour stocker des données. Je l'ai mis en service en 20 minutes environ.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.