Cumpla con sus plazos: métodos que usan los desarrolladores para estimar el esfuerzo

¡Hola a todos! Hay una cantidad colosal de teoría que necesita saber para comenzar en el desarrollo de software. Algunos especialistas (por ejemplo, los desarrolladores de backend que usan Java y otros lenguajes) saben más, mientras que otros (por ejemplo, los desarrolladores de frontend que usan JavaScript y React Native) pueden saber un poco menos. Dicho esto, ambos grupos deben poseer una gran cantidad de conocimientos no solo técnicos, sino también "organizacionales". Este conocimiento "organizacional" es un área de superposición para los desarrolladores frontend y backend. Hoy quiero hablar de un aspecto de este conocimiento organizativo no técnico. Hoy hablaremos de la estimación del esfuerzo . Porque solo tengo experiencia usando la metodología Agile(que se considera el más popular), más específicamente el marco Scrum, consideraré la estimación del esfuerzo en el contexto de Scrum . De entrada, debo decir que la estimación del esfuerzo es difícil. Para mí, es uno de los aspectos más desafiantes/desagradables de mi trabajo como desarrollador. Hay muchos factores diferentes a considerar que pueden afectar su estimación del esfuerzo requerido para una tarea. Además, los planes de desarrollo futuros se basarán en sus estimaciones.

¿Qué pasa si proporciona una mala estimación?

Si un desarrollador estima muchas más horas para una tarea de las que finalmente dedica a la tarea, su experiencia puede ponerse en duda debido a que la estimación fue muy inexacta. En otras palabras, fue una suposición descabellada. Al mismo tiempo, si un desarrollador no realiza el trabajo en el tiempo previsto, pone en peligro los planes del cliente para lanzar el producto o la nueva función. Esto es negocio, y el negocio es dinero. Pocos clientes estarán satisfechos con tal desliz. De hecho, es por eso que no me gusta la estimación, porque a veces es muy complicado determinar con precisión el tiempo necesario para completar una tarea.

Cómo hacer una estimación de tiempo

Por regla general, las estimaciones se realizan en horas o puntos de historia. Mi preferencia personal es hacer el proceso de estimación usando puntos de la historia . Es difícil equivocarse acerca de los objetos físicos concretos, pero los puntos de la historia son un poco más abstractos. Los equipos de desarrollo de software suelen proporcionar estimaciones como cantidades de tiempo: horas, días, semanas, meses. Estas estimaciones de tiempo se basan principalmente en la experiencia personal, las conjeturas y/o la intuición. En este caso, los desarrolladores simplemente miran la tarea y expresan su suposición sobre cuánto tiempo les llevará. Como resultado, estas estimaciones rara vez son precisas, porque hay demasiados factores que pueden afectar la duración del trabajo. Es por eso que muchos equipos que usan la metodología Agile también usan puntos de historia. ¡Vamos a sumergirnos!

¿Qué son los puntos de la historia?

Un punto de historia es una unidad de medida para expresar una estimación del esfuerzo total requerido para implementar completamente una determinada funcionalidad. Es decir, estamos hablando de relativocomplejidad. Los equipos asignan una estimación en puntos de historia en función de la complejidad del trabajo, el volumen de trabajo y el riesgo o la incertidumbre. Estos valores generalmente se asignan para dividir el trabajo de manera más eficiente en partes más pequeñas, eliminando así la ambigüedad. Con el tiempo, esto ayuda a los equipos a comprender lo que pueden lograr en un período de tiempo determinado y les ayuda a planificar con mayor precisión las siguientes partes del trabajo. Esto puede sonar completamente contradictorio para usted, pero esta abstracción es realmente útil: empuja al equipo a tomar decisiones difíciles sobre la complejidad del trabajo. Echemos un vistazo a algunas de las razones para usar puntos de historia al planificar:

• Puede evitar estimaciones de tiempo inexactas.
• A diferencia de las estimaciones realizadas en unidades de tiempo, los puntos de la historia le permiten contabilizar los costos generales: comunicaciones entre los miembros del equipo y el cliente, varias discusiones del equipo y actividades de planificación, así como situaciones imprevistas.
• Cada equipo estimará su trabajo utilizando diferentes escalas, lo que significa que su capacidad (medida en puntos) será diferente.
• Al definir una escala para asignar cada punto de la historia, puede asignar puntos rápidamente sin mucha controversia.

Cómo NO usar puntos de historia

Desafortunadamente, los puntos de la historia a menudo se usan incorrectamente. Los puntos de la historia pueden ser engañosos cuando se utilizan para evaluar personas, definir plazos y recursos detallados, y cuando se confunden con una medida de desempeño. En cambio, los equipos deben usarlos para comprender el alcance/complejidad de cada tarea y establecer prioridades. Tal vez, las partes que se consideran más difíciles deberían abordarse primero, para que puedan hacerse antes del final del sprint , posiblemente cambiando las tareas más fáciles para más adelante. Déjame recordarte qué es un sprint en el contexto de la metodología Scrum : La duración de este período de tiempo se determina cuando comienza el desarrollo y se acuerda entre el equipo y el cliente. Esto puede ser un período de dos semanas o un mes, o cualquier otro período. Como regla general, las estimaciones de esfuerzo se realizan al comienzo de cada sprint para planificar el trabajo que se puede completar al final del sprint, cuando el trabajo completo se entrega al cliente. La demostración lo ayuda a ver su progreso en el desarrollo del producto, recibir comentarios del cliente y ajustar la trayectoria del proyecto de acuerdo con la visión del cliente. Pero nos desviamos un poco. Volvamos a las estimaciones. Sería demasiado subjetivo que un solo desarrollador proporcione estimaciones para todas las tareas. Así que este proceso suele ser un esfuerzo de equipo. Existen bastantes técnicas que los equipos pueden usar para generar estimaciones. Hoy veremos la técnica más popular: el scrum poker . Esta técnica requiere un gerente que actuará como moderador del scrum poker . Puede ser alguien que sea un experto en scrum o posiblemente un PM .

¿Qué es el póquer Scrum?

El Scrum Poker , o Planning Poker, es una técnica de estimación que se basa en llegar a un acuerdo. Se utiliza principalmente para estimar la complejidad del trabajo por delante o el tamaño relativo de las tareas de desarrollo de software. Diré de inmediato que el scrum pokeres una práctica común de desarrollo de software y necesita saber de qué se trata. Por lo general, involucra una aplicación o sitio web para facilitar la creación colaborativa de un equipo de una estimación para una tarea en particular. ¿Como sucedió esto? El equipo toma algo del trabajo atrasado (una nueva tarea, alguna funcionalidad) y analiza brevemente las posibles dificultades y otros matices asociados. Luego, cada participante elige una tarjeta con un número que refleja su estimación de complejidad. Oh, una cosa más, al hacer estas estimaciones, usamos números en la secuencia de Fibonacci en lugar de números ordinarios. Los números de Fibonacci son populares en el scrum poker, porque hay una brecha cada vez más grande entre ellos (parecidos a los niveles de una pirámide). Algunas tareas serán muy complejas y no podremos salirnos con la nuestra con una pequeña cantidad de puntos de la historia. Hay algunas cartas inusuales que tienen los siguientes significados:

Número desconocido de puntos finales

Tarea infinitamente larga

Necesitar un descanso

Los métodos de estimación menos comunes utilizan:

• Tallas de camiseta: S, M, L, XL
• Razas de perros: chihuahua, pug, dachshund, bulldog, etc. (personalmente, creo que esta es la unidad de medida más extraña para estimar el esfuerzo =D)

Luego, el equipo compara las estimaciones proporcionadas por diferentes desarrolladores para la misma tarea. Si están de acuerdo, ¡genial! Si no es así, entonces se deben discutir las razones (argumentos) de las diferentes estimaciones. Después de eso, el equipo trabaja en conjunto para formar una estimación única que todos aceptan, más o menos. Entonces, ¿por qué se usa el póquer para planificar proyectos de software serios? Tienes que admitir que esto es extraño. El hecho es que este tipo de gamificación alienta a los miembros del equipo a pensar de forma independiente, invitándolos a revelar sus estimaciones al mismo tiempo que sus compañeros de equipo. Esto, a su vez, evita crear una situación en la que algunos miembros del equipo dependan de las opiniones de los demás. Si no se hiciera de esta manera, los desarrolladores menos experimentados verían y se concentrarían en las estimaciones proporcionadas por los miembros del equipo más experimentados. y eso haría que sus propias estimaciones fueran menos útiles. Pero mostrar simultáneamente las estimaciones hace que esto sea esencialmente imposible. Ofertas de Atlassianuna aplicación de scrum poker para usar en el proceso de planificación.

Ejemplo de estimación de esfuerzo

Suponga que su equipo estableció la siguiente escala para asignar puntos de historia a las estimaciones: Se juega Scrum Poker para cada tarea, y usted proporciona una estimación de la siguiente manera:

• Nunca has implementado una funcionalidad similar antes: +3
• La funcionalidad es de tamaño medio: +2
• La implementación será muy compleja: +3
• Escribir pruebas para la funcionalidad será muy complejo: +3

Al sumar cada componente, obtiene un total de 11 puntos de historia, pero no existe tal tarjeta, por lo que sugiere 13. Un compañero de trabajo presenta la siguiente estimación para la tarea:

• Ha trabajado con una tarea similar antes: +1
• La funcionalidad es de tamaño medio: +2
• La implementación será de complejidad media: +2
• Las pruebas de escritura para la funcionalidad serán de complejidad media: +2

Su resultado intermedio es 7 puntos de historia, pero ese número no existe en la serie de Fibonacci, por lo que envía la tarjeta con el número más aproximado: 8. Otros miembros del equipo también hacen sus estimaciones en función de sus puntos de vista subjetivos. Luego, todos muestran sus tarjetas y descubre que casi todos sus compañeros de trabajo dieron una estimación de 13, excepto el desarrollador que sugirió un 8. En este caso, se le permite hablar para dar las razones de su estimación más baja. Supongamos que ofrece esta justificación: anteriormente trabajó en la misma tarea y no es tan difícil como podría parecer. En última instancia, convence al resto del equipo para que cambie de opinión de 13 a 8 puntos de historia, diciendo que ayudará a quien termine tomando esta tarea. O tal vez lo hará él mismo. En cualquier caso, no No importa si los demás aceptan o no sus argumentos, porque de una forma u otra se le asignará una estimación a la tarea, y el equipo pasará a considerar la siguiente. Inicialmente, las estimaciones serán inexactas, al igual que las estimaciones de la cantidad de trabajo que planea realizar en el próximo período de tiempo (sprint). Después de todo, estas estimaciones hechas con estimaciones. Después de algún tiempo, tal vez tres meses más tarde, el equipo comenzará a estimar el tiempo requerido para las tareas con mayor precisión, y la cantidad promedio de trabajo que el equipo es capaz de realizar en un sprint se hará evidente. Pero este es un proceso para hacer un plan general para el alcance del trabajo. Se centra principalmente en el tiempo, pero en este caso puede haber muchos factores relevantes diferentes. Por ejemplo, suponga que un desarrollador se fue de vacaciones por dos semanas. Deberá reducir una cierta cantidad de trabajo planificado (funcionalidad planificada). O suponga que un nuevo desarrollador se ha unido al equipo, pero aún no está completamente al día, por lo que debe darle tiempo para que se familiarice con el proyecto a través de unproceso de incorporación . Esto podría ser dos semanas, más o menos una semana, dependiendo de la complejidad del proyecto. ¡Eso es todo por hoy! Espero haber mejorado ligeramente su conocimiento de la estimación del esfuerzo, un aspecto no técnico necesario del desarrollo de software. Si desea profundizar en este tema y en los detalles de scrum, le recomiendo que lea el libro "SCRUM" de Jeff Sutherland. No puedo prometer nada sobre las consecuencias, porque después de leerlo tendrás un molesto deseo de convertirte en un scrum master =D