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

Question

Howdy there. 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 ido a través de:

SourceControl:
CVS => VSS => SVN

Gestión de Proyectos, Bug y Seguimiento de asuntos :
papel => Notas PostIt => OneNote => bugnet => OnTime

Wiki y Documentación:
Palabra + recurso compartido de red => ScrewTurn Wiki

constructor Automatización:
Cruise Control + MSBuild

Ahora, especialmente debido a la SVN y la situación Wiki, estoy buscando a partir de este equipo con algo fresco 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 registro de repositorio.
Así, el nuevo equipo y yo hemos estado hablando esto durante un par de días, y creo que hemos reducido a 2 posibilidades:

1. TFS 2010
Pros:
- Solución todo en uno. Realmente lo tiene todo, incluida una nueva plantilla de proceso SCRUM.
- Interfaz de usuario muy amigable e integración de SharePoint.
- Wiki WYSIWYG y integración de Office.
Contras:
- Los altos costos iniciales en hardware y tiempo 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 origen de TFS. SC está basado en archivos y con un repositorio central como SVN y VSS. Realmente no quiero caer en los mismos problemas que hemos tenido en el pasado.

2. FugBUgs + horno + CC
Pros:
- horno utiliza Mercurial, con todos los beneficios del control de fuente distribuida.
- Costos iniciales mínimos y tiempo de planificación para ponerlo en funcionamiento. $ 30.00 por usuario por mes.
- Interfaz de usuario web muy amigable.
- Editor Wiki WYSIWYG.
- Rastreador de problemas muy simple y herramientas de gestión de proyectos. Sería fácil integrar procesos SCRUM.
Contras:
- Carece de herramientas de automatización del constructor para procesos más integrados (como TFS). Entonces, esto significará que tendremos que seguir golpeando nuestras cabezas con las funciones de línea de comando 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 me llevé los mejores recuerdos del 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 procesos, 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. Herramientas Integración
   1.1. Source Control
   1.2. Wiki
   1.3. Automatización de compilación
   1.4. Gestión de proyectos
   1.5. Con control de incidencias
2. Minimizar Fuente de Control de ramificación y fusión de conflictos (sí, es necesario que diversificarse y fusionamos)
3. interfaz de usuario amigable (no todo el mundo es CMD pirata informático)
4. WYSIWYG Wiki.
5. Learning Curve para desarrolladores.
6. Tiempo para hacer que todo funcione VS. Valor a largo plazo

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

Answer 1

que sugerimos utilizar TFS 2010 y Visual Studio 2010 (si está desarrollando aplicaciones .NET)

Usted no necesita preocuparse por SC en TFS. TFS almacena todo en SQL Server DB. TFS funciona en un servidor 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 procesos de software adicionales como MSF, CMMI o Agile.

Las capacidades de prueba 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 fuentes antes de las sucursales y fusiones.

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

TFS 2010 tiene una operación de administración más fácil entonces TFS 2008 y 2005. Se puede crear fácilmente agentes de construcción, máquinas, colecciones de proyectos, etc ...

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

TFS no es sólo un sistema de gestión de código fuente, TFS es un sistema de gestión de proyectos, sistema de gestión de ciclo de vida de aplicaciones, sistema de seguimiento de elemento de trabajo, y así sucesivamente ..

pero sé que no se puede utilizar TFS de MSDN Subs para fines comerciales. Porque esto es solo para prueba y solo 5 usuarios se pueden conectar (no estoy del todo seguro)

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

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

Answer 2

Hasta ahora estoy muy satisfecho con atlassian producto (s). JIRA se integra muy bien con la subversión. Si proporciona una etiqueta de texto en su mensaje 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á buscando una 'wiki', foswiki hace un buen trabajo. Pero estoy buscando más desde un ángulo de Linux en la cadena de herramientas.

Answer 3

Parece que está buscando algo así como Trac.

Trac es un sistema mejorado de seguimiento de problemas y wiki para proyectos de desarrollo de software. Trac utiliza un enfoque minimalista 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 menos posible en el proceso 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 indicado para los complementos.

Aquí hay otra pregunta de stackoverflow pidiendo recommended Trac plugins.

Answer 4

Redmine al rescate.

Answer 5

¿Qué tan grande será su equipo, y qué metodología/roles usará todo el mundo?

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

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

Answer 6

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 tiempo y esfuerzo para lograrlo esta vez.

Sin asesorar sobre herramientas específicas, le aconsejaré que haga dos cosas.

1) busque una herramienta cadena - no solo una colección de herramientas. Véase, por ejemplo, Seeking a true "tool-chain" que trata sobre herramientas que funcionan bien juntas. Un flujo de trabajo más suave debería ahorrar tiempo y podría aumentar las posibilidades de éxito del proyecto.

observo que se dice “Se puede imaginar que bugnet + SVN + ScrewTurn + climatizador + MSBuild son bastante diferentes animales, por lo que la integración y sinergia es muy importante ”, por lo que creo que estamos de acuerdo en que uno

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