Las mejores herramientas de gestión de proyectos, control de fuente, generador y wiki

Hola. Estoy armando un nuevo equipo de software y estoy buscando diferentes herramientas que superen las pesadillas anteriores que tuve con otros equipos.

En los últimos 5-6 años, estas son algunas transiciones que he pasado:

Fuente de control:
CVS => VSS => SVN

Gestión de proyectos, errores y seguimiento de problemas:
Papel => PostIt Notes => OneNote => BugNet => OnTime

Wiki y documentation:
Word + Network Share => ScrewTurn Wiki

Automatización del generador:
Cruise Control + MSBuild

Ahora, especialmente por SVN y la situación Wiki, estoy buscando comenzar este equipo con algo nuevo. En el pasado hemos tenido pesadillas de ramificación con SVN, y cuanto más tratamos de arreglarlo, peor se vuelve. El otro desafío que tengo es encontrar algo que sea estable e integrado. Puedes imaginar que BugNet + SVN + ScrewTurn + CruiseControl + MSBuild son animales muy diferentes, por lo que la integración y la sinergia es muy importante; No quiero saltar entre 10 aplicaciones diferentes para informar un error o asignar tareas y revisar el trabajo completado y mirar el logging de repository.
Entonces, el nuevo equipo y yo hemos estado hablando de esto durante un par de días, y creo que lo hemos networkingucido a 2 posibilidades:

1. TFS 2010
Pros:
– Solución todo en uno. Realmente lo tiene todo, incluida una nueva plantilla de process SCRUM.
– Interfaz de usuario muy amigable e integración de SharePoint.
– WYSIWYG Wiki y Office Integration.
Contras:
– Costos iniciales elevados en hardware y time de administración. Software también, pero no nos afecta porque tenemos una suscripción a MSDN con software gratuito.
– Tengo dudas sobre el control de fuente de TFS. SC está basado en files y tiene un repository central como SVN y VSS. Realmente no quiero caer en los mismos problemas que hemos tenido en el pasado.

2. FugBUgs + horno + CC
Pros:
– El horno usa Mercurial, con todos los beneficios del control de fuente distribuida.
– Costos iniciales mínimos y time de planificación para ponerlo en funcionamiento. $ 30.00 por usuario por mes.
– Interfaz de usuario web muy amigable.
– Editor WYSIWYG Wiki.
– Muy simple rastreador de problemas y herramientas de gestión de proyectos. Sería fácil integrar processs SCRUM.
Contras:
– Carece de herramientas de automation del constructor para processs más integrados (como TFS). Entonces, esto significará que tendremos que seguir golpeando nuestras cabezas con las funciones de línea de command y las tareas de la comunidad para mantener a nuestros trabajadores de construcción.

De vuelta en el día, utilicé Visual Studio Team System 2005 y no llevé conmigo los mejores recuerdos sobre el sistema; pero el nuevo TFS 2010 parece una apuesta muy sólida. FogBugz y Mercurial son como los nuevos niños en el bloque y traen nuevas ideas a los nuevos processs, pero como siempre, esta es una espada de doble filo.
¿Alguien con sólida experiencia con alguno de estos? ¿Nos falta esa tercera opción? ¿Tienes esa bala de plata para mis problemas?

  1. Integración de herramientas
    1.1. Fuente de control
    1.2. Wiki
    1.3. Automatización de compilation
    1.4. Gestión de proyectos
    1.5. Seguimiento de problemas
  2. Minimice conflictos de split y control de código fuente (sí, es necesario que nos ramifiquemos y fusionemos)
  3. Interfaz de usuario amigable (no todo el mundo es hacker de CMD)
  4. WYSIWYG Wiki.
  5. Learning Curve para desarrolladores.
  6. Es hora de hacer que todo funcione VS. Valor a largo ploop

El nuevo equipo tiene 4 miembros de equipo + 1 Gerente de Proyecto (Scrum Master) y 1 Gerente de Producto (Product Owner). Entonces estamos hablando de un equipo relativamente pequeño y nuevo. el scope y los proyectos en los que trabajaremos son grandes aplicaciones empresariales con múltiples proyectos y variaciones de ramificación

Le sugiero que use TFS 2010 y Visual Studio 2010 (si está desarrollando aplicaciones .Net)

No necesita preocuparse por SC en TFS. TFS almacena todo en SQL Server DB. TFS funciona en un server web, por lo que puede conectar su control de origen donde lo desee.

El seguimiento de WI es un plus. TFS tiene un increíble mecanismo de seguimiento de WI. Puede personalizar sus WI si lo desea. TFS admite processs de software adicionales como MSF, CMMI o Agile.

Las capacidades de testing de TFS 2010 son perfectas. Si usa Visual Studio 2010, puede maximizar su efectividad con TFS 2010.

La ramificación es siempre molesta cuando llega el momento de fusionarse; pero TFS 2010 siempre te ayuda. Puede rastrear los cambios en sus fonts antes de las sucursales y fusiones.

El mecanismo de compilation TFS 2010 es compatible con WorkFlow. Entonces puedes personalizar tu process de compilation fácilmente; si esto no es correcto para usted, puede usar files por lotes adicionales (MsBuild).

TFS 2010 tiene una operación de administración más sencilla que TFS 2008 y 2005. Puede crear fácilmente agentes de construcción, máquinas, collections de proyectos, etc.

TFS 2010 es compatible con casi todos los productos de MS; como MS Office. Excel tiene una gran integración con TFS O MS Project. No te olvides de Sharepoint.

TFS no es solo un sistema de gestión de código fuente, TFS es un sistema de gestión de proyectos, un sistema de gestión del ciclo de vida de la aplicación, un sistema de seguimiento del sitio de trabajo, etc.

Pero sé que no puede usar TFS de MSDN Subs para fines comerciales. Porque esto es solo para testing y solo 5 usuarios pueden conectarse (no estoy del todo seguro)

Al less, no tiene que configurar TFS en un server dedicado si lo desea (esto no se recomienda). Puede configurar Win7 si lo desea y TFS puede funcionar en SQL Server Express

Así que te sugiero TFS 2010. Si estás desarrollando aplicaciones .Net, nada puede ser mejor que TFS.

¿Qué tan grande será su equipo, y qué metodología / roles usarán todos?

Diría que si se trata de un gran equipo, TFS podría adaptarse mejor a sus necesidades.
Especialmente si necesita publicar en sharepoint o tener roles más definidos en su equipo.

Sin embargo, si desea una solución a menor escala, que se adapte mejor a un equipo más pequeño, algo como SVN / Trac / Cruise Control podría ajustarse mejor a sus necesidades.

Parece que estás buscando algo como Trac .

Trac es un wiki mejorado y un sistema de seguimiento de problemas para proyectos de desarrollo de software. Trac utiliza un enfoque minimalist para la administración de proyectos de software basados ​​en la web. Nuestra misión es ayudar a los desarrolladores a escribir un excelente software sin molestarnos. Trac debería imponer lo less posible en el process de desarrollo y las políticas establecidas por un equipo.

Proporciona una interfaz para Subversion (u otros sistemas de control de versiones), una Wiki integrada y facilidades de informes convenientes.

Trac se puede ampliar con complementos. El wiki de Trac-Hack es el lugar para search complementos.

Aquí hay otra pregunta de stackoverflow preguntando por los complementos de Trac recomendados .

Redmine al rescate.

Hasta ahora, he estado muy satisfecho con los productos de atlassian . JIRA se integra muy bien con la subversión. Si proporciona una label de text en su post de confirmación, JIRA también mostrará los cambios en el código relacionado con el problema. En lugar de utilizar FishEye, websvn fue la herramienta de elección como svn web front end. Si solo estás buscando un 'wiki', foswiki hace un buen trabajo. Pero estoy buscando más desde un ángulo de Linux en la cadena de herramientas.

Absolutamente sin intención de ofender, pero … sigues cambiando, ¿has considerado por qué? Y qué tan seguro puede estar de que no se encontrará cambiando de nuevo. Invierta más time y esfuerzo para lograrlo esta vez.

Sin asesorar sobre herramientas específicas, te aconsejaré que hagas dos cosas.

1) busque una cadena de herramientas, no solo una colección de herramientas. Ver, por ejemplo, buscando una verdadera "cadena de herramientas" que discuta herramientas que funcionan bien juntas. Un flujo de trabajo más suave debería ahorrar time y podría boost las posibilidades de éxito del proyecto.

Noto que dices "Puedes imaginar que BugNet + SVN + ScrewTurn + CruiseControl + MSBuild son animales muy diferentes, por lo que la integración y la sinergia es muy importante", así que creo que estamos de acuerdo en eso

2) necesita la aceptación de las personas que usarán estas herramientas. No los presente con un hecho consumdo, pregunte lo que piensan, de antemano. De hecho, lánzalos para sugerencias. Este punto puede ser complicado a la luz del punto anterior.