Mejores prácticas para el envío de software a tiempo

Question

Imagínese que no tiene el problema del deslizamiento de características, tiene un equipo motivado y estable, tiene problemas claros que resolver y conoce el dominio/idioma/herramientas relacionadas con su proyecto.

¿Cómo se seguir un horario y lograr ese hito 1.0?
¿Cuál es su enfoque para un envío iterativo ?

Me gustaría recomendaciones especialmente para un equipo pequeño, donde hay pocos o casi ningún problema de comunicación.

Answer 1

1. Enfóquese en las características, no en las tareas de implementación.
2. Trabaja en iteraciones (como semanal o quincenal).
3. Libere las características de trabajo en el entorno de ensayo por orden de prioridad.
4. Unidad de prueba de su código sobre la marcha, por lo que no se ralentiza por una lista de errores que aumenta geométricamente a medida que se acerca la fecha de lanzamiento.
5. Prepárese para reducir el alcance de las funciones menos importantes. Las cosas siempre tardan más de lo que crees que sucederá.
6. Asegúrese de bocetar la IU por adelantado (si hay una IU) y muéstrela a los usuarios potenciales.
7. Pruebe, pruebe y pruebe un poco más. Esto parece contrario a la intuición, pero ahorra más tiempo que toma.

Answer 2

Probablemente sea un escenario utópico ;-). Pero de todos modos, si no hay un exceso de prestaciones, muy buen equipo y requisitos claramente definidos con absolutamente ningún problema de comunicación entonces probablemente la mejor manera de entregar el producto en el tiempo sería

1. reunión semanal con el equipo para evaluar el estado actual (PM con el equipo, si hay un PM)
2. El líder del equipo puede tener una pequeña reunión diaria con los miembros del equipo para evaluar su estado en los problemas/requisitos que se les delegan. Si hay problemas, entonces él/ella debe tomar los pasos necesarios para resolver el problema.
3. Seguimiento del plan del proyecto y delegación del trabajo (el jefe del equipo necesitaría conocer las fortalezas individuales de cada miembro del equipo para delegar el trabajo de manera apropiada).
4. Las pruebas se pueden automatizar en la medida en que la tecnología lo permita.
5. Propiedad del trabajo de cada miembro del equipo.

Al final del día, todo se reduce a cuán apasionada es una persona hacia su trabajo.

Sólo mi 2 de paise ;-)

Answer 3

Question: How does a large software project get to be one year late? Answer: One day at a time!

que no proporciona una respuesta a su pregunta, pero creo que sí apunta a la necesidad de cumplir con su horario - si es que se un día atrasado, necesitas alcanzarlo de alguna manera. (Desafortunadamente, el resto del Mes de Mythical Man se trata de cómo en la mayoría de los proyectos no hay "de alguna manera" ...)

Además, eche un vistazo a la programación basada en evidencia en productos como FogBugz.Esto le dará una estimación actualizada de cuándo es probable que el producto se envíe; de ​​hecho, brinda un rango de fechas, con probabilidades para cada fecha. Si ve que su probable fecha de lanzamiento pasa de la fecha límite, esto le permitirá saber que debe hacer algo al respecto, y con tiempo suficiente para tener un efecto.

Answer 4

Hay un pequeño punto perdido por los carteles anteriores. Para cumplir con la fecha límite, primero debe definirse el cronograma realista. El proyecto debe dividirse en una tarea pequeña, depende del tamaño del proyecto, pero en mi mundo con proyectos que tardan entre 3 y 4 meses, intentamos dividirlos en una tarea máxima de 2-3 días. De esta forma, la estimación del tiempo es principalmente realista y los riesgos se calculan por adelantado y se agregan al cronograma propuesto.

Answer 5

Hay muchos buenos consejos en este hilo. Lo único que tengo que agregar es adoptar un horario regular para las publicaciones. Mi empresa cambió a esto hace unos años y fue doloroso al principio, pero tiene muchos beneficios, el mayor de los cuales es permitir que las personas difieran fácilmente las funciones.

Se puede aplazar las funciones porque sabe que su característica puede pasar a la siguiente versión y sabe cuándo será esa versión. Esto significa que en lugar de apresurarse a obtener su función a medio cocer en el último minuto, puede pasar un poco más y tenerla al comienzo de la siguiente versión.

Answer 6

Excluyendo plazos irrazonables de ventas/marketing/administración, prácticamente ha descartado todas las razones por las que un proyecto no se envía a tiempo. La historia de las metodologías de desarrollo de software es una colección de métodos para evitar, reducir el impacto de y/o evitar:

• alcance pobremente definida
• función de fluencia
• falta de conocimiento del dominio
• equipos grandes con problemas de comunicación
• /desarrolladores incompetentes sin motivación

Answer 7

Escenario periódico (¿mensual? ¿semanalmente?) recorridos de productos utilizando la compilación actual aceptada, para el beneficio del equipo del producto. Comience esto lo antes posible. Demostrar todas las características, independientemente de su utilidad actual; no se salte los que están rezagados.

El objetivo es dar a los interesados ​​una idea clara del estado actual del producto en el transcurso del proyecto. De esta forma, es más probable que los responsables de la toma de decisiones aborden los riesgos del cronograma de inmediato, en lugar de poner en peligro la fecha de envío.

Answer 8

Conozca cuáles son las características de misión crítica para el cliente. Protege el progreso en ellos. A menudo es muy cierto que el 80% del éxito proviene del 20% del trabajo.

Answer 9

Me gustaría decir que puede elegir un conjunto de características o una fecha de envío, pero no ambas.

Éstos son algunos pensamientos individuales: - no ser optimistas - hacer la parte difícil primera - no agregar características sin resbalar el horario - escribir características de tal manera que se puede soltar a golpear calendario

http://shipcamp.com