Las mejores prácticas para enviar software a tiempo

Question

Imagina que no tienes el problema de la característica de arrastre, tienes un equipo motivado y estable, problemas claros y claros para resolver, Y conoces el dominio / idioma / herramientas relacionadas con tu proyecto.

¿Cómo se apega a un horario y logra ese hito de 1.0?
¿Cuál es su enfoque para un envío iterativo ?

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

Answer 1

1. Enfocarse en funciones, no en tareas de implementación.
2. Trabaja en iteraciones (como semanalmente o quincenalmente).
3. Libere funciones de trabajo a su entorno de preparación en orden de prioridad.
4. Realice una prueba de unidad de su código a medida que avanza, de modo que una lista de errores no se ralentiza a medida que se acerca la fecha de lanzamiento.
5. Esté preparado para cortar el alcance de las características menos importantes. Las cosas siempre tardan más de lo que crees que lo harán.
6. Asegúrate de hacer un boceto de la interfaz de usuario por adelantado (si hay una interfaz de usuario) y muéstraselo a los usuarios potenciales.
7. Prueba, prueba y prueba un poco más. Esto parece contrario a la intuición, pero ahorra más tiempo del que se necesita.

Answer 2

Ese es probablemente un escenario utópico ;-). Pero, de todos modos, si no hay un aumento de características, un equipo excelente y requisitos claramente definidos sin absolutamente ningún problema de comunicación, entonces probablemente la mejor manera de entregar el producto a tiempo sería

1. Reunión semanal con el equipo para evaluar el estado actual (PM con 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 sobre los problemas / requisitos que se les delegan. Si hay problemas, él / ella debe tomar las medidas necesarias para resolver el problema.
3. Seguimiento del plan del proyecto y delegación de trabajo (el Líder del equipo deberí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 por cada miembro del equipo.

Al final del día, se reduce a lo apasionada que es una persona por su trabajo.

Solo mis 2 paises ;-)

Answer 3

Pregunta: ¿Cómo puede un proyecto de software grande llegar un año más tarde? Respuesta: ¡Un día a la vez!

Eso no proporciona una respuesta a su pregunta, pero creo que señala la necesidad de cumplir con su horario; si incluso tiene un día de atraso, debe ponerse al día de alguna manera. (Desafortunadamente, el resto de The Mythical Man Month se trata de cómo en la mayoría de los proyectos no hay "de alguna manera" ...)

También, 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 se envíe el producto; de hecho, proporciona un rango de fechas, con probabilidades para cada fecha. Si ve que su fecha de lanzamiento probable se está pasando de la fecha límite, esto le hará saber que debe hacer algo al respecto, y con suerte con el tiempo suficiente para tener efecto.

Answer 4

Hay un pequeño punto perdido por los carteles anteriores. Para cumplir con la fecha límite primero de todo el calendario realista debe definirse. El proyecto debe dividirse en tareas pequeñas, depende del tamaño del proyecto, pero en mi mundo con proyectos que demoran entre 3 y 4 meses, tratamos de dividirlos en una tarea máxima de 2-3 días. De esta manera, la estimación del tiempo es en su mayoría 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 calendario regular para los lanzamientos. Mi compañía cambió a esto hace unos años y fue doloroso al principio, pero tiene muchos beneficios, el mayor de los cuales es permitir a las personas diferir fácilmente las características.

Está bien diferir las funciones porque sabes que tu función puede pasar a la próxima versión y sabes 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 del próximo lanzamiento.

Answer 6

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

• ámbito mal definido
• característica de arrastramiento
• falta de conocimiento del dominio
• grandes equipos con problemas de comunicación
• desarrolladores desmotivados / incompetentes

Answer 7

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

Answer 8

Etapa periodic (¿mensual? ¿semanalmente?) tutoriales del producto utilizando la versión aceptada actual, en beneficio del Equipo de producto. Comience esto lo antes posible. Demuestre cada característica, independientemente de su usabilidad actual; No te saltes los que se están quedando atrás.

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 encargados de la toma de decisiones aborden los riesgos del cronograma rápidamente, en lugar de poner en peligro la fecha de envío.

Answer 9

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

Aquí hay algunos pensamientos individuales: - no seas optimista - Haz la parte difícil primero - No agregue características sin deslizarse en el horario - escriba características de tal manera que pueda colocarlas en el calendario de eventos

http://shipcamp.com