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:
- ¿Cuál es la razón de esto? ¿Es esto común para los programadores?
- ¿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?
Respuestas:
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.
fuente
Es, si:
Por nombrar algunas cosas.
Quizás sea mejor preguntar a sus desarrolladores por qué creen que sus estimaciones están muy lejos. :-)
fuente
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!
fuente
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
Esto funciona bastante bien en pequeños equipos ágiles.
Extracto de wikipedia:
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:
Al ponderar esas tres estimaciones, obtiene una estimación más confiable.
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.
fuente
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.
fuente
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
fuente