¿La mejor manera de planificar la programación para equipos pequeños? [cerrado]

Soy el director de una pequeña organización de inicio. Actualmente tenemos dos programadores (uno con experiencia y otro con menos experiencia) que están creando una plataforma de aplicación web.

Uno de los mayores desafíos hasta ahora es el proceso de planificación. Los programadores generalmente están a cargo de planificar su propio trabajo, pero seguimos excediendo sus plazos autoimpuestos. Por ejemplo, una tarea que estiman tomará 2 días, termina tomando 8 días.

Para mí es difícil apoyarlos en la planificación, ya que me falta el conocimiento técnico para estimar con precisión cuánto tiempo durará una determinada tarea.

Tienes alguna idea:

1. ¿Cuál es la razón de esto? ¿Es esto común para los programadores?
2. ¿Qué puedo hacer para apoyarlos en la planificación? ¿Hay algún método o herramienta que sea útil para los programadores en equipos pequeños?

Las técnicas generales son de sentido común, lo importante es saber que no requieren mucha experiencia técnica.

El punto de partida con la planificación es identificar el problema exacto que debe resolverse y tener un requisito claro e inequívoco. Si no tiene eso, sus estimaciones serán incorrectas. Tener esto documentado en algún tipo de especificación de características antes de que alguien comience a escribir código significará que cualquier pregunta que deba hacerse se habrá hecho antes de que comience la codificación. Este es un ahorro de tiempo sorprendentemente efectivo. Retroceder y aclarar los requisitos interrumpe el flujo de uno como programador y esperar respuestas puede bloquear el progreso.

Una vez que haya identificado el requisito, debe identificar las tareas de trabajo involucradas en su resolución. Este es un ejercicio clásico de divide y vencerás: cualquier tarea que pueda desglosarse aún más debe desglosarse aún más.

En un equipo más grande, puede usar el póker de estimación para obtener una estimación basada en la experiencia de todos los involucrados. Eso no funciona tan bien en un equipo más pequeño, pero sigue siendo útil obtener una estimación independiente de sus desarrolladores y tal vez incluir una de usted también; su falta de experiencia específica puede ser útil aquí porque al explicarle lo que La tarea implica desde su perspectiva, el equipo de desarrollo probablemente comprenderá mejor el problema.

Con un equipo más pequeño puede ayudar a obtener una estimación del mejor / esperado / peor de los casos para cada tarea, eso le da un rango de valores, pero si está obteniendo muchas estimaciones desbordadas, puede inclinarse hacia el peor de los casos hasta que sus desarrolladores aprende a estimar con mayor precisión.

En una tienda pequeña, los desarrolladores a menudo terminan doblándose como administradores de sistemas, equipo de soporte e incluso probadores (aunque de todas las cosas que podrían estar haciendo, las pruebas son las que debe intentar evitar a toda costa), por lo que debe tener en cuenta eso. Calcule cuánto tiempo dedican sus desarrolladores a trabajar en nuevas funciones y tómelo en sus estimaciones. Si una tarea se estima en 2 días, pero sus desarrolladores solo pueden trabajar en un nuevo desarrollo el 60% del tiempo, entonces necesitará 4 días para que se complete. Es posible que también pueda ayudar con esto controlando el flujo de otras tareas que deben manejar para que las tareas de administración o soporte no urgentes se puedan agrupar en lugar de ser manejadas de manera ad-hoc. Muchos programadores (ciertamente incluyéndome a mí en este caso) no son buenos administradores de tiempo, así que cualquier cosa que puedas hacer para echar una mano a ese respecto te ayudará La tarea única siempre es más fácil para los programadores que la multitarea. Bloquear el tiempo durante el día también puede ayudar con esto.

Mantenga un registro : cada vez que tenga una sesión de planificación, registre las estimaciones y los datos reales. Luego puede usar esto a) como una guía sobre cuánto inflar sus estimaciones durante la planificación yb) para ayudarlos a refinar sus habilidades de estimación. Al final de cada iteración (o cualquier equivalente que tenga), todo el equipo debería revisar el trabajo realizado y descubrir por qué tardó más de lo esperado para que esto pueda incorporarse en estimaciones futuras. Esto debe ser una tarea irreprochable: parece que tiene la actitud correcta aquí, pero esta respuesta puede demorar un tiempo, así que haré la observación. Si alguien dice "Cometí un error aquí", puede convertir eso en "qué podría haber hecho mejor", pero decirle a la gente que fueron demasiado lentos o que hicieron las cosas mal solo empeorará las cosas.

Soy consciente de que no hay una bala de plata para este tipo de problema, pero el factor más importante es la comunicación, que en realidad es más fácil con un equipo más pequeño, y el uso de comentarios para refinar sus habilidades colectivas.

¿Cuál es la razón de [su estimación de 2 días que toman 8 días], es esto común para los programadores?

Es, si:

• En realidad, no está claro qué se supone que deben hacer, por lo que tardan más tiempo en hacerlo bien (y luego deberían decirlo, no adivinar cuánto tiempo llevará)
• No están familiarizados con la tarea en cuestión (entonces deberían mencionar eso e incluir la investigación en la estimación)
• La integración de la tarea finalizada con el producto más grande lleva más tiempo de lo previsto (lo que podría significar que la arquitectura del producto es inferior)
• Al desarrollador le gusta reinventar la rueda, y al hacerlo tropieza con problemas que otros han resuelto, disponibles gratuitamente en una biblioteca
• El propietario del producto introduce los cambios mientras se implementa la tarea, lo que requiere un enfoque diferente y el rehacer el trabajo ya realizado
• Los desarrolladores no trabajan en un entorno productivo (por lo que cuando están en casa suponen que les tomaría dos días, pero en el trabajo requerirán ocho para compensar todas las distracciones)

Por nombrar algunas cosas.

Quizás sea mejor preguntar a sus desarrolladores por qué creen que sus estimaciones están muy lejos. :-)

No sería el primero en tratar de descubrir la mejor manera de planificar el tiempo de desarrollo. Esto se debe en parte al hecho de que es difícil cuantificar algo que realmente no se puede ver que se está construyendo, y en parte debido al mítico hombre-mes , que es un contraste directo con la idea intuitiva de que si tienes 2 programadores, deberías ser capaz de desarrollar el doble de rápido que si tuviera 1 programador.

Como probablemente ya te hayas dado cuenta, es mucho más complicado que eso. Un enfoque para estimar el tiempo de desarrollo es redondear a un grupo de personas altamente calificadas para lo que concierne al desarrollo de software y pedirles que calculen la cantidad de tiempo que tomaría terminar un proyecto (explicando lo más detallado posible). Tomas la más alta de todas las estimaciones y la duplicas . Sí, leíste correctamente. usted doblala estimación más alta y usted tendrá una estimación razonablemente precisa. Lo sé, porque con el tiempo, así es como he podido decir con precisión a mis jefes cuánto tiempo me lleva hacer algo. Reúno las opiniones de mis compañeros programadores y las mías y doblo la estimación más alta. Si esto parece un valor demasiado alto, considere que probar la nueva funcionalidad es crucial y considere posibles correcciones de errores después, y parecerá una cifra más razonable.

En mi propia experiencia personal como programador, puedo decirle que ayuda a dividir los proyectos en hitos. ¿Cuánto tiempo lleva alcanzar el hito 1, luego del hito 1 al hito 2, luego el hito 2 al hito 3, etc.? Cuando se desglosa así, la respuesta suele ser mucho más precisa que tratar de estimar todo el proyecto en su totalidad. Por extraño que parezca, si resume las estimaciones de todos estos hitos, generalmente será mayor que la estimación original en todo el proyecto (si el programador es honesto consigo mismo de todos modos), lo que solo me lleva a pensar que los detalles son la clave aquí.

Quizás carece de los conocimientos técnicos, pero aún así debería intentar seguir en un nivel más general. Los programadores no tienen problemas con la repetición. Son los giros y vueltas que ocupan todo el tiempo en el desarrollo de un programa. Lo más probable es que, cuanta más funcionalidad desee incluir, más complicado se volverá el programa, y ​​suponiendo que esta nueva funcionalidad no tenga influencia en las secciones implementadas previamente del código, el desarrollo será lineal de acuerdo con la cantidad de trabajo para ser hecho Lo más probable es que la nueva funcionalidad influya mucho en las secciones implementadas anteriormente y, por lo tanto, el desarrollo implica no solo implementar la nueva funcionalidad sino también corregir el código anterior, lo que hace que el tiempo de desarrollo sea exponencial.

Mi consejo para usted sería que, sin decirle a los programadores cómo hacer su trabajo, intente comprender cómo funciona el programa a nivel general y pronto podrá ver cómo las nuevas funciones modificarían ese comportamiento y, por lo tanto, proporcionarían Una estimación razonable de cuánto tiempo llevaría hacerlo. Combine esto con sus estimaciones (el doble más alto), y comenzará a tener una mejor idea de cómo estimar el tiempo de desarrollo.

¡Espero que eso ayude!

Una de las razones por las que las estimaciones a menudo están muy alejadas es porque la estimación en realidad es bastante difícil y requiere experiencia y conocimiento sobre el sistema para cambiar. En la mayoría de los casos, es útil dividir los grandes pasos en pequeños.

Ahora tiene muchas posibilidades de las que mencionaré dos:

• Planning Poker
• PERT (técnica de evaluación y revisión del programa)

Planning Poker

Esto funciona bastante bien en pequeños equipos ágiles.

Extracto de wikipedia:

• Un moderador, que no jugará, preside la reunión.
• El Product Manager ofrece una breve descripción general. El equipo tiene la oportunidad de hacer preguntas y discutir para aclarar supuestos y riesgos. El gerente del proyecto registra un resumen de la discusión.
• Cada individuo coloca una tarjeta boca abajo que representa su estimación. Las unidades utilizadas varían: pueden ser días de duración, días ideales o puntos de historia. Durante la discusión, los números no deben mencionarse en absoluto en relación con el tamaño de la característica para evitar el anclaje.
• Todos llaman a sus cartas simultáneamente dándoles la vuelta.
• Las personas con estimaciones altas y bajas reciben una caja de jabón para ofrecer su justificación para su estimación y luego continúa la discusión.
• Repita el proceso de estimación hasta llegar a un consenso. El desarrollador que probablemente sea el propietario de la entrega tiene una gran parte del "voto de consenso", aunque el Moderador puede negociar el consenso.
• Se utiliza un temporizador de huevos para garantizar que la discusión esté estructurada; el Moderador o el Gerente de Proyecto pueden en cualquier momento entregar el reloj de arena y cuando se agote, toda discusión debe cesar y se juega otra ronda de póker. La estructura en la conversación es reintroducida por las cajas de jabón.

Los bits importantes aquí son la aclaración, la discusión, al mismo tiempo llamar a la estimación, de modo que no se introduzca ningún sesgo, y el consenso.

IMPERTINENTE

A menudo es difícil dar una estimación exacta. Lo que es más fácil es dar una probabilidad. PERT utiliza 3 valores para la estimación:

• tiempo más optimista para terminar (si surgen menos problemas de lo esperado)
• tiempo más pesimista para terminar (si todo sale mal, excluyendo grandes catástrofes)
• tiempo más probable para terminar (si todo va como se esperaba) <- esto es lo que sus desarrolladores probablemente estimen en este momento

Al ponderar esas tres estimaciones, obtiene una estimación más confiable.

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

Y / o puede utilizar estos tres valores para construir una distribución de probabilidad que pueda reflejar aún más la incertidumbre del mundo real. La distribución beta y la distribución triangular son opciones destacadas. Con esto, ahora puede aplicar estadísticas como "qué tan probable es que termine en la fecha x según las estimaciones actuales" o "si quiero un 95% de certeza, en qué momento se terminará".

En realidad, PERT consiste en más de estos aspectos mencionados aquí, que omití por razones de brevedad.

Es un hecho que si no mantiene métricas históricas, entonces ni siquiera puede acercarse a dar estimaciones razonables con un grado razonable de precisión. Y preguntarle a alguna otra compañía / persona cuánto tiempo les tomará tampoco ayuda. El problema es que cada empresa y desarrollador tiene su propia forma de hacer las cosas. Por lo tanto, cada empresa tendrá diferentes períodos de tiempo para hacer exactamente la misma tarea. Cada desarrollador tendrá diferentes períodos de tiempo para hacer exactamente la misma tarea.

Su mejor curso de acción es comenzar a registrar el tiempo y de alguna manera descubrir cómo clasificar el grado de dificultad para la tarea. Algunas compañías usan líneas de código, algunas usan características, algunas simplemente se sienten instintivas. Además, también debe tener en cuenta si esto es similar a algo que los desarrolladores ya han construido o algo nuevo, como una nueva tecnología, una nueva característica nunca antes construida por el equipo, etc. sistema de tiempo, entonces la complejidad generalmente sube bastante.

A menos que recopile datos reales, no importa cuántas veces sus desarrolladores le den estimaciones, en realidad solo extraerán números de sus atrasos cada vez que les pregunte. Sí, la recopilación de datos reales es una molestia y al principio no proporciona mucha información útil, pero con el tiempo realmente comienza a proporcionar estimaciones razonablemente precisas.

También me gustaría señalar que, en general, las estimaciones solo son buenas para el panorama general y no para mediciones a corto plazo. Por ejemplo, el desarrollador estima 2 días, pero lleva 8. Bueno, el desarrollador no tuvo en cuenta la necesidad de configurar un entorno de prueba y desarrollar un simulador o que había una tecnología completamente nueva que tenían que aprender o se quedaron atrapados en un error no podían entenderlo o la funcionalidad requería una refactorización del sistema existente. No siempre se puede predecir ese tipo de cosas para tareas pequeñas. Sin embargo, en el transcurso de un proyecto completo, esos 6 días adicionales pueden verse afectados por otras tareas que demoran 6 días menos.

He sido un desarrollador exclusivo en algunos proyectos pequeños por mi cuenta y tengo algo de experiencia industrial trabajando con un gran equipo. Me di cuenta de que las técnicas que utiliza una gran empresa no necesariamente funcionan para un equipo pequeño. En un momento estaba haciendo más planificación y documentación en lugar de escribir código. Sugiero que intente encontrar una buena manera de trabajar primero probando diferentes técnicas (las otras respuestas proporcionan una gran comprensión) y herramientas, esto le costará algo de tiempo y esfuerzo, pero se beneficiará más adelante. Algunas herramientas / técnicas que encontré útiles fueron:

-Pivotal Tracker: un gran programa para realizar un seguimiento de las historias y alienta el desglose de las tareas, se aligera rápidamente al ingresar historias y deduce automáticamente la velocidad. https://www.pivotaltracker.com/ .

-Gdocs para documentación, ya que es fácil tener múltiples usuarios editando y discutiendo al mismo tiempo.

-En una empresa para la que solía trabajar, teníamos una reunión para cada una de las historias que iniciamos, esta reunión tenía que incluir un programador senior, ya que sería mejor para juzgar cuánto tiempo llevaría una tarea. También sería mejor para juzgar cuál podría ser la parte difícil de una tarea.

En resumen, creo que la clave para trabajar en equipos pequeños es tener un régimen de planificación sólido, rápido y fluido. Además, cualquier dificultad con la historia se puede identificar temprano para que la planificación de una tarea lo tenga en cuenta (esto podría conducir a construir algo diferente).

Espero que esto ayude