Esquema de un Sistema de Gestión de Desarrollo Software

UPDATE 090731: Se mejora la imagen del esquema y se subraya la importancia de la automatización de la alimentación del Sistema.

Me encuentro sumido en un proyecto de consultoría para definir un Sistema de Gestión de Desarrollo de Proyectos o Ecosistema Software. Así que aprovecho para compartir una primera versión del esquema lógico sobre el que estoy trabajando.


Wiki

Es el punto de entrada principal al Sistema.
Contiene la información básica de cada proyecto y la organización.
Redirige al resto de aplicaciones del Sistema.
Permite la creación de documentación de forma colaborativa.
Control de cambios automático.
Documentación exportable a formato pdf.

Cms

Sistema de Gestión Documental para los documentos binarios, como word, powerpoint, etc.
No toda la documentación puede estar en el Wiki.

Project Management

Visión de alto nivel de la gestión de proyectos.
Cuadro de mandos ágil para directivos.
Gestiona resto de estados de un proyecto que no son Desarrollo.

Issue Management

Gestión del desarrollo de cada proyecto con sus versiones, tareas, equipo, trazabilidad, etc.

Scm

Sistema de Gestión de Control de Fuentes (CVS, Subversion, Git,... etc.)

Continuous Integration Server

Descarga, construye, prueba, analiza el código, crea informes de estado y despliega en el Demos Server los proyectos de forma automática y periódica.

Demos Server

Servidor de demos del estado actual de cada proyecto.

Otros

Notificaciones vía RSS y e-mail.
Single Sign On.
Privacidad.
Integración con el IDE del equipo de desarrollo para automatizar la alimentación del Sistema y garantizar la trazabilidad.


Ahora toca analizar alternativas y seleccionar la que más se ajuste a las necesidades del cliente.
Los mayores problemas están en (1) el análisis del Wiki y el Cms por la cantidad de alternativas disponibles y (2) en la herramienta de Project Management porque cada organización tiene un punto de vista muy personal sobre la gestión de proyectos, lo que interesa y lo que no. Así que no descarto que haya que desarrollar una aplicación a medida como suelen tener todas las organizaciones.

12 comentarios :: Esquema de un Sistema de Gestión de Desarrollo Software

  1. Al margen de tu selección final, te cuento mi experiencia;
    llevamos unos meses trabajando de la siguiente forma:
    - Dokuwiki - efectivamente, el punto de entrada al sistema
    - Trac - gestión de tickets, para los programadores SOLO hay 2 tipos de tickets: task y bug.
    - SVN
    - Hudson + Sonar (seré conocido ya como el pesao del sonar ;-))
    Lo MÁS IMPORTANTE que he encontrado es que configuré unos hook post-commit en SVN que añaden comentarios a los tickets Trac, e incluso pueden cerrar tickets con un simple "fix #34", y ha sido la mejor idea de todas. Al margen de lo que elijas al final, lo que hay que conseguir es que los programadores se libren de burocracia. Cuando escriban su comentario de commit, además de describir lo que suben, dan:
    - Información del avance de una tarea
    - El changeset está automáticamente linkado al ticket que lo originó: la trazabilidad es COMPLETA
    - Documenta errores: el buscador del trac es una fuente de información brutal
    - Automáticamente tenemos informes de horas: el timeline de trac es una vista muy buena de lo que se hace cada día.
    Asi que hagas lo que hagas, que los programadores puedan actualizar la información desde el mismo mensaje de commit... porque como tengan que usar otro método, al final no se hará ;-)
    Salu2

  2. Te comento lo que usamos nosotros actualmente, y alguna cosa que nos gustaría cambiar:

    Wiki: usamos Xwiki, no esta mal, nos gusta más confluence, pero Xwiki es gratis y muy personalizable. Cuidado con "sobreestructurar" el wiki, en nuestra experiencia es preferible crear espacios, dentro de los espacios documentos sueltos (como mucho algún indice simple) y usar "buscar" en el wiki que es la herramienta más util.

    Cms: estamos desarrollando uno :P, de todos modos para la gestión de proyectos software me parece excesivo un CMS, el wiki debería bastar, quiza sea un indicio de excesiva burocracia en el proceso (waste que dirian en lean). Los pocos documentos que tenemos que no están directamente en el wiki (en xWiki puedes crear paginas a modo de "template" para documentos que deban cumplir algún formato especifico) los subimos como un attachment o bien (algunos diseños uml) en el propio subversión. Otra opción que uso mucho, sobre todo para el material para algunos cursos que doy, es usar google docs y integrar los documentos luego en el wiki.

    Project management y issue management: Es preferible que sea la misma herramienta no dos separadas. Redmine la gente que conozco que lo usa lo recomienda mucho, trac también tiene buena prensa, jira es otra buena opción pero de pago. En nuestro caso usamos mantis y una herramienta propia para gestión de proyectos, recomendación: por nada del mundo hagais una herramienta a medida para esto xd, lo malo no es hacerla, es mantenerla, hay muchas buenas opciones tanto open-source como comerciales y muchas de ellas extensibles mediante plugins.

    Scm: aqui creo que la decisión esta entre un sistema centralizado (cvs, svn...) o uno distribuido (mercurial, git). Nosotros usamos svn y nos va bien, pero antes de decidir deberías evaluar cuales son los tipos de proyectos, definir la estrategia de branching que se va a seguir (por feature, por release, mainline, multiples lineas...) y en función de eso escojer el que más se ajuste a esa politica, incluso por proyecto elegir el que más se ajuste que no todos son iguales ni tienen las mismas necesidades.

    CI: aqui mi favorito sin discusión es mi amigo el señor hudson :P. Me uno a la recomendación de sonar, otra herramienta de "amor a primera vista" como hudson xd.

    Aparte de estas cosas incluira algunas más en vuestra definición de ecosistema:

    sistema de build: ant, maven etc. Nosotros estamos migrando a maven porque el proyecto crece y crece y los scripts en ant son cada vez más duros de mantener. Yo haria explicito en el ecosistema que sistema de build se usa, ya que tiene mucho impacto en otros elementos del ecosistema (sonar o hudson, mucho mejor con maven también, sobre todo si se trata de proyectos grandes con varios modulos).

    repositorio de artefactos: si usais maven se hace imprescindible un repositorio de artefactos en la compañia, que sirva como mirror de los repositorios globales y para almacenar los propios artefactos binarios que se generen en los distintos proyectos (y habilitar que facilmente el equipo X pueda usar los artefactos que genera el equipo Y, algo que en pocas organizaciones esta realmente bien resuelto). Nosotros tenemos pensado usar nexus (despues de evaluar también artifactory, nexus gana de momento porque ofrece indices y desde netbeans o elcipse te ofrece autocompletado en los pom por ejemplo, fantastico!). Además un repositorio de este tipo te permite controlar que software de terceros estas usando en tu compañia (y que versiones), algo que de nuevo en pocos sitios tienen bajo control.

    Y seguro que se me olvidan cosas, pero buena chapa he metido ya jeje, espero que te sirva de algo.

  3. Lo primero muchas gracias por comentar vuestra experiencia.

    Quizás lo que se me ha olvidado comentar es que el Sistema es para un gran cliente con multitud de proyectos y de varias tecnologías, por eso lo agnóstico de esta primera versión en cuanto a todo pero sobretodo al sistema de Build. Aunque el futuro de los proyectos Java pasa por Maven, con Nexus y Sonar! Aquí estoy totalmente de acuerdo con vosotros. También en Hudson y sus pestañas que nos vienen genial.

    Por eso también he tenido que descartar Trac. Aunque me encanta para llevar 1 proyecto, el hecho de que no sea multiproyecto lo hace inviable. Aquí si os puedo adelantar que la decisión final es JIRA.

    Desgraciadamente los directivos se pierden ante tanta información de bajo nivel, simplemente les sobra. Además para ellos existen otros estados distintos al de desarrollo (concepción, contratación, certificación, etc) y otra información económica y de alcance con la que no cuentan los Issue Managers. E increiblemente hay gente que aún pide tener sus diagramas de gant (sc). Aquí la verdad que no sé cómo acabará la cosa...
    La solución personalizada es la más costosa pero qué organización no tiene su aplicación de gestión de proyectos.
    Lo más importante es que debe estar integrada con todo el sistema y automatizar la entrada de información.

    En este aspecto coincido totalmente contigo Ibón. Lo que no se haga de forma automática en el commit, simplemente no puedes contar con que se vaya a hacer, por más manual de buenas prácticas que tengas. En este sentido recomiendo fuertemente el plugin Mylin de Eclipse. Es una maravilla!

    Lo del Scm no me preocupa en exceso. Ahora mismo usan CVS, aunque puede ser un buen momento para migrar a Subversion. El tema de tagging y branching es muy importante, pero (casi) nadie lo usa y los que lo usan no les importa excesivamente el Scm concreto. Al menos ese es mi caso.

    Como decía al principio el Cms es necesario debido al gran número de proyectos existente con documentación en binario repartida entre el CVS y carpetas compartidas. Lo que no tiene sentido es que necesites un usuario CVS para ver documentación. Aunque para organizaciones más pequeñas seguramente sobre con el sistema de adjuntos tipico de cualquier Wiki.

    De hecho estuve evaluando Bitweaver como solución Wiki+Cms, pero el Cms aún no lo tienen fino y lo peor es que vi que cuando les ponias un bug te lo resolvian con un cant reproduce sin más.

    Tambíen he probado Xwiki, pero no me gusta, lo veo poco ágil y la css falla un poco. Para la Wiki lo más importante es que de facilidades de integración para la autenticación y autorización con la bbdd existente de usuarios.

  4. @alfredo
    Después de la DURA entrada en maven (2 meses configurando bien las dependencias de test y producción por las MALDITAS dependencias de hibernate, hibernate-core, hibernate-search....etc), no lo cambio por otro bote de ariel señora ;-) En serio, sin maven no creo que hubiésemos podido llevar adelante el proyecto con las decenas de dependencias de Seam.
    Nosotros usamos artifactory, y tengo autocompletado de dependencias en el pom en NB, ¿soy raro? ;-) Lo mejor: definir un repo "virtual" que engloba todos los repositorios que usamos (nuestros releases, jboss, y alguno más).
    Sobre el wiki: totalmente de acuerdo. Mi mayor error en wikis anteriores ha sido intentar "seccionearlo" adecuadamente: al final la gente no sabe donde empezar su artículo, y lo importante es el contenido. Casi mejor que secciones, una taxonomía. Elegí dokuwiki porque:
    - Es ligero, muy ligero
    - Cantidad ENORME de plugins
    - No usa BD: las secciones son carpetas, y las páginas de wiki ficheros txt. Y si, quería que no usara BD :-)
    - La síntaxis que usa es legible: incluyo un README.txt en el proyecto con toda la información de build, estructura del proyecto y test en un fichero txt legible, que además es una página del wiki.
    - El formateado de su print.css es COJONUDO, de hecho, casi ni uso el plugin de transformación a odt.

    Puff, que pesao soy ;-)

  5. @jcesarperez
    No te envidio ;-), en la aplicación de "gestión del proyecto" es donde REALMENTE vas a tener el problema. A lo largo de mi vida he estudiado decenas de herramientas de ese tipo, open source y "privadas" (alguna hasta hecha por un amigo), y he llegado a una conclusión: el modelo de una herramienta de gestión de proyectos es como el culo, todo el mundo tiene el suyo propio (y al dueño no le suele molestar como huele ;-))
    Que dios te coja confesao ;-))

    En nuestro caso usamos los Milestones de trac, y empiezo a creer que es la mejor manera (ligera y efectiva):
    - Un Milestone tiene una fecha concreta de finalización, y TIENE unos resultados medibles (una documentación o especificaciones implementadas)
    - Las tasks (que no son más que tickets) pertenecen a determinado milestone.
    Mi sufrido jefe de proyecto ha creado los milestones, y de esa manera encajarían dentro de un maldito project, y a la vez, tienen sentido dentro de un desarrollo real iterativo.
    Pero tu solución dependerá de las ñapas que te obliguen a implementar (propongo una manifestación de informáticos en contra de usar los diagramas de gantt para la gestión de proyectos software, y que la plantilla del project para proyectos software sea declarada dañina para la salud >:-))

    Salu2

  6. Pero que agrado ver a los maestros reunidos comentando! (no pun intended)

    De partida, el artículo lo encontré muy interesante aunque no entendía específicamente de qué se trataba en un principio. Hasta que comencé a leer y ví que se mencionaba a Trac, Wiki, etc... "Ahh!!" dije yo: "el post no se trata de gestión a nivel de gerentes de área comercial, sino que de configuración de herramientas de trabajo para apoyar el ciclo de vida desarrollo de software" Genial el artículo!

    Ya el primer comentario lo encontré buenísimo, seguí leyendo y el segundo comentario me hizo expresar "vaya!, este tío sí que ha dado un excelente aporte". Luego entonces recién me vengo a fijar quien firma, ¿y quien era? Pues Alfredo Casado!! Grande Remoh!! El talento te surje natural hombre. Da gusto escucharte en los podcast y también leerte en JavaHispano.

    Gracias estimados porque ahora estoy en un proyecto que recién comienza y estamos a la espera de saber cuál va a ser nuestro servidor de integración contínua. Sería mi primer proyecto usando CI.

    Saludos y excelente artículo. Te agregaré a mis feeds Julio César Pérez.

    Atte
    Germán González

  7. Hola:

    Para los que usen TRAC y no conozcan STractistics:
    http://trac.ebabel.info/projects/opina/stractistics

    Un saludo

  8. Nosotros usamos GForge

  9. He leído los comentarios y realmente me han parecido muy buenos, pero me queda la duda de por qué no recomiendan los diagramas de gantt. Realmente veo que son muy buenos y en una sola mirada se puede ver el avance.

  10. Puff, en contra de los diagramas de gantt aplicados a proyectos software podría escribir un libro, pero intentaré ser breve:
    + Representar un proceso iterativo en un diagrama de gantt siempre resulta en algo artificial o complejo.
    + En cuanto hay varias tareas relacionadas se convierten en un caos de flechas que no aportan información.
    + La mayor parte de las veces, simplemente muestran el progreso de una tarea por el tiempo transcurrido desde su inicio, no por lo REALMENTE que se haya avanzado:
    En el desarrollo software que una tarea esté desarrollada al 73% no significa NADA. Por ejemplo, tarea de desarrollo de una API, ¿Que es un 73%? ¿que falta un 27% por implementar? (entonces por que no lo implementas?)¿Que hay que testear un 27%? ;-)
    En la mayoría de los casos significa que le dijiste a un cliente que para determinada fecha iba a estar terminado, y falta un 27% de tiempo para que llegue esa fecha, pero no muestra el progreso REAL.
    + Cualquier desviación en el proyecto (tareas no pensadas en un primer momento, retrasos...etc) o son difíciles de representar o simplemente se enmascaran.
    Por todas esas razones y alguna más, los diagramas de gantt me parece que ofrecen una información falsa, que en el mejor de los casos sirve para aliviar conciencias, y en el peor de los casos, para presionar y/o castigar a los sufridos programadores.
    Salu2

  11. mmm, me parece interesante lo que planteas, pero esto me trae otra duda ¿que herramienta te permite solventar los problemas que indicas?.

    De lo que veo la mayor parte de herramientas te lo permite manejar como una lista de tareas a las cuales se les asignan recursos, ese tipo de herramientas tampoco dan solución a este problema.

  12. Anónimo(por favor, no me gusta mantener conversaciones "anónimas" ;-)):
    No creo que la solución venga por una "herramienta", sino por una forma de trabajo. Te cuento mi experiencia actual (no soy ningún gurú que venda una metodología "nueva", por eso sólo puedo hablar de mi experiencia);
    como el desarrollo de software es un proceso iterativo creo que es conveniente delimitar esas iteraciones. No digo que apliquemos scrum a rajatabla(aunque nos hemos basado en muchas de sus ideas) , simplemente en nuestro sistema gestor de tickets(trac) marcamos ciertos milestones (de un mes de duración más o menos).
    Los tickets sólo son de dos tipos para los programadores: task o bug. Un ticket o está acabado o no lo está (nada de % de progreso); al principio el ticket lleva una estimación de horas, y en los mensajes de commit ("refs #123 (1.5) blah, blah...") se añaden horas a los tickets, pero no para ver "su" progreso: sólamente para que veamos al final como se ha desviado la estimación del número de horas reales (y así ir mejorando nuestras estimaciones).
    Un milestone tiene varios tickets asociados, y el % de progreso del milestone es el nº de tickets cerrados, ni más ni menos. Si aparecen bugs a lo largo de la iteración, como son tickets, hacen que el % de progreso descienda.
    Es simple pero muy efectivo, mostramos en todo momento un progreso real, y solemos cambiar la urgencia del ticket hablando con el programador para conseguir la mayor cantidad posible de tickets cerrados. Lo interesante es que es muy dinámico: tiene en cuenta la aparición de bugs, y en cualquier momento podemos añadir una tarea que no habíamos tenido en cuenta al inicio de la iteración y que es totalmente necesaria para llegar al milestone.
    Todo queda guardado y podemos encontrar las causas de los fallos de previsión. Y los programadores lo único que tienen que hacer es ser cuidadosos en sus mensajes de commit, lo cual redunda en la monitorización del desarrollo.
    La verdad es que estamos muy contentos y seguimos teniendo fechas de entrega (como con cualquier gantt) , pero sin perder el tiempo en gantts engañosos.
    Salu2

Publicar un comentario