Gestión de hitos y desarrollo web Proyecto

Question

Estoy tratando de implementar Trac + SVN. Pero me encuentro con un problema de gestión de proyectos. Para darle un trasfondo, la mayoría de mis proyectos están relacionados con el desarrollo web (pasan por fases como diseño, programación, pruebas, etc.).

Ahora estoy implementando Trac para mis proyectos. Ahora el problema es qué debería colocar como hitos y boletos. Para boletos, ¿qué tan granular debería obtener? p.ej. debería decir Make X parte de la función Y o solo la función Hacer Y. Cuantas más entradas haya, más tiempo pasaré haciendo estas entradas.

También, para hitos, he visto proyectos como CakePHP, etc. Cuando usan Trac, establecen sus hitos como números de versión (correspondientes a las etiquetas en el SVN). ¿Es esa la mejor manera?

Entonces digo que tengo un cliente cuyo plazo final es X fecha. Luego configuré mi hito como 1.0 con la fecha límite como X. Pero entonces, ¿cómo hago un seguimiento semanal del proyecto? Porque no quiero darme cuenta un día antes de la fecha de lanzamiento que eso queda demasiado. Quiero tener cheques semanales de alguna manera.

También quiero tener en cuenta mejoras/errores también como tickets y agruparlos como hitos.

He imaginado algo así como 1.x.x donde la primera x corresponde al grupo de mejoras de funciones, mientras que la segunda x corresponde a las correcciones de errores. ¿Hay una mejor manera? ¿Cómo administro el estado semanal en dicho sistema?

¿Hay una manera estándar de hacer esto? ¿Cómo lo hago? Estoy totalmente confundido.

Gracias.

Answer 1

Bueno, depende. No especificó qué tan grande es el proyecto, cuántos programadores trabajarán, con qué frecuencia planea entregarlo.

Afirmando que, así es como usamos Trac en un gran proyecto que abarca varios años que consiste en el número de subproyectos más pequeños.

• hitos se definen como puntos en los que tenemos algunas características en subproyecto listos para su entrega. El primer hito en cada subproyecto suele ser el más largo. Por lo general, nombramos hitos como "Nombre del subproyecto v0.01". Las versiones son solo incrementos 0.01, 0.02, ... Cuando implementamos todo lo esperado para el subproyecto, marcamos el último hito como v1.00. Las correcciones de errores posteriores van a un hito que marcamos "Nombre del subproyecto - v1.00 - corrección de errores"

• Descripción de Milestone contiene solo una lista de nuevas características o correcciones de errores. La documentación está escrita en wiki y en tickets.

• Trac Wiki suelen tener al menos una página sobre las nuevas funciones que se implementarán en un hito específico. Por lo general, es una descripción de mayor nivel del comportamiento esperado de la aplicación. A menudo, hay ejemplos de resultados esperados que la aplicación debe producir.

• Las entradas contienen una descripción detallada de la característica o error que deben implementarse.

  • Los tickets de informes de fallos contienen una descripción del error y pasos para reproducir (casi siempre).
  • Los tickets de funciones contienen una descripción detallada de la función que debe implementarse. Un boleto contiene trabajo por hasta 6 horas. Cuando planificamos el trabajo, dividimos las características para que estén en el rango de 1 a 6 horas de trabajo. Si estimamos que la función necesita más tiempo, la dividimos en varias entradas para que cada una de ellas pueda caber en 1-6 horas de trabajo. Elegimos 6 horas porque creemos que es la parte superior que podemos estimar con un error no mayor que 30% (lo que significa que esta estimación de 6 horas casi siempre se puede hacer en un rango de 4 a 8 horas). Por supuesto, hay excepciones de estas estadísticas. En nuestra experiencia, la razón principal de las estimaciones erróneas son las malas especificaciones que escribimos. Eso, casi siempre, sucede porque nosotros (los desarrolladores) entendimos mal los requisitos comerciales de nuestros usuarios.

• Hay pocos plugins de Trac para estimar y rastrear el tiempo. Compruebe esta página: http://trac.edgewall.org/wiki/TimeTracking. Usamos Timing And Estimation Plugin . Puede ingresar el tiempo estimado para el boleto y el tiempo dedicado a trabajar en el boleto. Luego puede obtener informes sobre cuánto tiempo pasó en boletos/hitos y cuánto tiempo necesita para terminar.

Después de dos años, podemos estimar con bastante precisión el tiempo necesario para hacer algún trabajo. Cuando comprendemos correctamente las necesidades y los requisitos de los usuarios, por lo general podemos cumplir el plazo prometido. Actualmente, nuestras estadísticas muestran que sobreestimamos el tiempo necesario para las entradas en aproximadamente un 10%.

Answer 2

Establecer su hito de 1.0 a la fecha de entrega está bien, pero querrá definir hitos anteriores: hágalos semanalmente si ese es un buen intervalo para usted y numere de forma adecuada. Para un proyecto de 4 semanas, tal vez 0.2, 0.5, 0.7 y 1.0 funcionarían. Enumere los bits relevantes en cada hito: 'Diseño completo', 'Codificación completa', 'Prueba completa', etc. ¡Si no está en el objetivo, entonces comienza el verdadero trabajo de administración de proyectos!

Answer 3

Veo que tiene varias opciones y un par de decisiones que tomar.

Puedes pensar en Feature Driven Development. Puede usar trac para admitir la comunicación en lugar de ese control. Tareas de grano grueso, boletos de grano fino y lanzamientos tempranos.

Haga una lista de las características que se desarrollarán e indique que la versión, digamos ... la versión 1.0, ocurre cuando todas las características se desarrollan y se prueban. Haga boletos paraguas para todas las funciones. Son de grano grueso y definirán el ritmo de desarrollo.

Defina ahora un par de hitos según la cantidad de funciones planificadas y el tiempo. El primer hito debe contener al menos una característica, ya que el objetivo de un hito es lograr que el proyecto se construya para las pruebas y los comentarios. Defina uno o más hitos para marcar cuando se completen todas las funciones, llámelos "beta", "lanzamiento candidato" o lo que sea.

Si durante el desarrollo hay una necesidad de tareas de grano fino, no sea tímido en hacerlas. Y haga que las tareas del paraguas dependan de estos boletos más nuevos.

No es necesario que haya un informe de errores debajo de ninguno de ellos, y puede tener tantos detalles como sea necesario. Estos son de grano fino. Estos no definen el ritmo de desarrollo. Una excepción es un sprint de eliminación de errores para eliminar los obstáculos.Publique los nombres de los desarrolladores con más errores asignados y no resueltos para obligarlos a resolver los problemas.

Parte del proceso de creación de un hito, una versión beta o una versión candidata etiqueta la fuente para hacer que el proceso sea repetible, y para detectar errores incluso cuando la fuente del tronco ya ha cambiado. En SVN, la forma habitual de etiquetar consiste en copiar el origen del enlace a un directorio en "etiquetas" y asegurarse de que nadie se comprometa con esa rama.

Creo que un número de versión de dos números es suficiente para la mayoría de los casos. El primer número denota compatibilidad y el segundo, el lanzamiento. Pero hay varias variables que pueden estar dentro de un número de versión: compatibilidad de origen, compatibilidad binaria, nivel de solución de fallas, lanzamiento, versión de producto complementario (ala Oracle), compatibilidad de protocolo, etc.

Answer 4

He estado usando Trac/SVN durante dos años y medio ahora.

Aquí es lo que sugieren: la producción

• Dividir la versión de software en varias iteraciones: creación, elaboración, de transición (o llamar lo que quieras)
• Las características del plan para la primera iteración. Para otros planes de mejoras y correcciones de errores
• Las tareas (tickets) deben ser lo más detalladas posible siempre que cada ticket tenga un entregable valiosa para el cliente
• Ahorrar tiempo en la creación de tickets no es una buena idea. Tareas más granulares y más pequeñas: más control sobre el progreso. Por lo tanto, el descubrimiento anterior de deficiencias de planificación y más tiempo para gestionar.
• Las entradas se pueden dividir incluso cuando están en progreso. Si el desarrollador alcanzó el resultado que puede mostrarse al cliente pero no completó la tarea completa, el desarrollador puede dividir la tarea y marcar la parte completa como "cerrada" o "resuelta", lo que le da un control más detallado.
• realizar el seguimiento del progreso diario, semanal no (o al menos varias veces a la semana)

El Trac es una herramienta muy agradable. La mejor característica o Trac es la capacidad de poner WikiLinks en todas partes, incluidos los comentarios changeets. Si exige poner el ticket # en changeset comment y luego poner el número de conjunto de cambios en el comentario del ticket, esto vincula las tareas y los cambios al código. Más tarde, estos enlaces facilitan el seguimiento de la evolución del software. Es un salvavidas, especialmente si el proyecto va más allá de un par de meses de duración.

Answer 5

Una pequeña advertencia al frente: no tengo ni idea de usar Trac ... o SVN. Creo que tus hitos no deberían ser establecidos por el control de versiones/sistema de seguimiento de errores.

Normalmente, los hitos son solo eventos importantes en su proyecto. Deben ser importantes para todos los interesados. La finalización de un entregable importante es un hito. La finalización de algunas características no lo es. Cerrar sesión en todos los planes y contratos es un evento significativo, pero la finalización de 10 maquetas no lo es.

Tiendo a utilizar el horario y las tareas para trabajar con el equipo. Marque las tareas mientras están hechas. A todos los demás solo les informo sobre hitos. ¿Vamos a hacer UAT antes del 15 de mayo? Sí somos.

Dado que los hitos son herramientas para informar a los patrocinadores y otras partes interesadas, debe configurarlos para que sean lo que consideren importantes. Mis patrocinadores querrán saber cuándo se completa un conjunto básico de características, por lo que es un hito. Querrán saber cuándo se cierra la sesión de UAT, por lo que es un hito.

Establezca muy pocos hitos y nadie sabrá cómo está progresando hasta el final. Establecer demasiados y el valor se perderá.

No existe una fórmula mágica, pero los proyectos con cientos de tareas y miles de horas hombre solo pueden tener 4 hitos.

alt text http://officeadd.in/Images/articles/ProjectMilestones-scribblea.png

Lo sentimos, este no se refiere a Trac y SVN directamente, pero espero que esto le da una idea aproximada de cómo se utilizan generalmente hitos. Ah, y disculpas de antemano por el uso excesivo de Comic Sans ... puaj.