fandom - shipping logistica
Las mejores prácticas para enviar software a tiempo (9)
Imagínese que no tiene el problema del deslizamiento de características, tiene un equipo motivado y estable, problemas claros y definidos para resolver, Y conoce el dominio / idioma / herramientas relacionadas con su proyecto.
¿Cómo te apegas a un horario y logras ese hito de 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.
- Céntrate en las funciones y no en las tareas de implementación.
- Trabajar en iteraciones (como semanal o quincenal).
- Libere las funciones de trabajo en su entorno de ensayo por orden de prioridad.
- Prueba en unidades tu código sobre la marcha, para que no te ralentice una lista de errores que aumenta geométricamente a medida que te acercas a la fecha de lanzamiento.
- Esté preparado para cortar el alcance de las características menos importantes. Las cosas siempre tardan más de lo que crees que sucederá.
- Asegúrese de bocetar la IU por adelantado (si hay una IU) y muéstrela a los usuarios potenciales.
- Pruebe, pruebe y pruebe un poco más. Esto parece contrario a la intuición, pero ahorra más tiempo que toma.
Ese es probablemente un escenario utópico ;-). Pero de todos modos, si no se detectan características, un equipo muy bueno y requisitos claramente definidos sin ningún problema de comunicación, entonces probablemente la mejor manera de entregar el producto a tiempo sería
- Reunión semanal con el equipo para evaluar el estado actual (PM con el equipo, si hay un PM)
- 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, entonces él / ella debe tomar los pasos necesarios para resolver el problema.
- 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).
- Las pruebas se pueden automatizar en la medida en que la tecnología lo permita.
- 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.
Solo mi 2 paise ;-)
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 sabes que tu función puede llegar 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 de la siguiente versión.
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.
Pregunta: ¿Cómo es que un gran proyecto de software llega un año 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 cronograma; si incluso se retrasa un día, debe 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 la 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.
Realice recorridos periódicos del producto (¿mensual? Semanal?) 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.
Sepa 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.
Si no se aplican los plazos razonables de ventas / marketing / administración, habrá descartado todas las razones por las cuales los proyectos no se envían 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
Me gusta decir que puede elegir un conjunto de características o una fecha de envío, pero no ambas.
Aquí hay algunas ideas individuales: - no sea optimista - haga lo más difícil primero - no agregue características sin deslizarse el programa - escriba las características de tal forma que pueda soltarlas para ajustarlas al calendario de visitas