¿Qué métodos utilizan los desarrolladores para evaluar las tareas?

¡Hola a todos! La teoría necesaria para iniciar el desarrollo es muy extensa. Algunos especialistas (desarrolladores backend en Java y otros lenguajes) tienen más, mientras que otros (por ejemplo, desarrolladores frontend en JavaScript - React Native) tienen un poco menos. Sin embargo, ambos deben tener un gran acervo de conocimientos no sólo técnicos, sino también "organizativos". Este conocimiento "organizacional" es uno de los puntos de intersección para los desarrolladores frontend y backend. Hoy quiero hablar sobre un aspecto de este conocimiento organizacional no técnico: la evaluación de tareas (estimación). Y como trabajé solo en la metodología Agile (que de hecho se considera la más popular), en su subparte, Scrum , consideraré la evaluación de tareas en el contexto de Scrum . Diré de inmediato que la evaluación, también llamada estimación, es difícil. Para mí, personalmente, como desarrollador, este es uno de los aspectos más difíciles/indeseables del trabajo. Hay muchos factores diferentes a considerar que pueden influir en la evaluación de una tarea. Al mismo tiempo, los planes para un mayor desarrollo se basarán en sus previsiones.

¿Qué pasa si no obtienes la calificación correcta?

Si un desarrollador dedica muchas más horas a una tarea de las que finalmente dedicará, puede parecer que no es el mejor especialista, porque la estimación fue muy inexacta. Por así decirlo, un dedo en el cielo. Al mismo tiempo, si el desarrollador no invierte en el tiempo previsto, pone en peligro los planes del cliente de lanzar el producto/nueva característica. Esto es un negocio, y un negocio significa dinero, y a pocos clientes les gustará ese pinchazo. En realidad, por eso no me gustan las estimaciones, porque a veces es muy difícil determinar el tiempo exacto para completar una tarea.

¿Cómo se evalúa el tiempo?

Como regla general, la estimación se realiza en horas o puntos de historia. Personalmente, estoy mucho más cerca del proceso de evaluación en puntos de historia . Si un reloj es algo físico, entonces algo que puede confundirse, los puntos de la historia son un poco más sobre otra cosa, más abstracta. Normalmente, los equipos de desarrollo de software dan estimaciones en formato de tiempo: horas, días, semanas, meses. Estas estimaciones de tiempo se basan principalmente en experiencia personal, conjeturas o intuición. En este caso, los desarrolladores simplemente miran la tarea y expresan una estimación de cuánto tiempo les llevaría. Como resultado, rara vez son precisos, porque hay demasiados factores que pueden afectar el plazo para completar el trabajo. Por lo tanto, muchos equipos que trabajan según la metodología Agile utilizan puntos de historia. Vamos a resolverlo.

¿Qué son los puntos de la historia?

Un punto de historia es una unidad de medida que expresa una evaluación del esfuerzo total que es necesario para implementar plenamente una determinada área de trabajo (funcionalidad). Es decir, se trata de una complejidad tan relativa . Los equipos asignan puntos de la historia según la complejidad del trabajo, el alcance del trabajo y el riesgo o incertidumbre. Normalmente, estos valores se asignan para dividir el trabajo en partes más pequeñas de manera más eficiente, eliminando así la incertidumbre. 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 las siguientes áreas de trabajo con mayor precisión. Esto puede parecerle completamente contradictorio, pero esta abstracción es realmente bastante útil: empuja al equipo a tomar decisiones más difíciles sobre la complejidad del trabajo. Veamos algunas razones para utilizar puntos de la historia en la planificación:

• se puede evitar la imprecisión en las estimaciones en intervalos de tiempo;
• A diferencia de las estimaciones en el tiempo, los costos generales se pueden tener mejor en cuenta: comunicaciones entre los miembros del equipo y el cliente, diversas discusiones y planificación del equipo, así como situaciones imprevistas;
• Cada equipo calificará el trabajo en una escala diferente, lo que significa que su velocidad (medida en puntos) será diferente;
• Al definir una escala para asignar cada punto de la historia, puedes distribuir puntos rápidamente sin mucha controversia.

Cómo NO usar puntos de historia

Desafortunadamente, los puntos de la historia se utilizan a menudo para otros fines. Los puntos de la historia pueden tener fallas cuando se utilizan para evaluar personas, definir plazos y recursos detallados, y cuando se toman erróneamente como una medida de desempeño. En cambio, los equipos deben utilizarlos para comprender el volumen/complejidad del trabajo en cada tarea y priorizar. Es posible que las partes clasificadas como más difíciles deban hacerse primero para poder completarlas antes del final del sprint , pero las más fáciles se pueden posponer para más adelante. Permítanme recordarles qué es un sprint en el contexto de la metodología Scrum : La duración de este período se determina al comienzo del desarrollo mediante acuerdo entre el equipo y el cliente. Este podría ser un período de dos semanas o un mes, o cualquier otro período. Como regla general, la estimación de tareas se lleva a cabo al comienzo del sprint para planificar la posible cantidad de trabajo completado al final del sprint, cuando el trabajo completado se entrega al cliente. Le ayuda a ver su progreso en el desarrollo del producto, recibir comentarios del cliente y ajustar el desarrollo del proyecto de acuerdo con la visión del cliente. Pero aún así, nos desviamos un poco: volvamos a la estimación. Evaluar las tareas de un solo desarrollador sería demasiado subjetivo. Por tanto, por regla general, se trata de un trabajo en equipo. Existen bastantes técnicas para la evaluación de equipos. Hoy veremos el más utilizado: Scrum Poker . Esta técnica requiere de un manager que será alguien como el líder de este Scrum Poker . Podría ser una persona especializada en Scrum Master o PM .

¿Qué es el póquer Scrum?

Scrum Poker -o poker de planificación- es una técnica de evaluación que se basa en llegar a un acuerdo. Se utiliza principalmente para evaluar la complejidad del trabajo por delante o el volumen relativo de tareas a resolver durante el desarrollo de software. Señalaré de inmediato que Scrum Poker es una práctica común en el desarrollo y definitivamente necesitas saber qué tipo de bestia es. Para este proceso solemos utilizar algún tipo de aplicación o sitio web que nos permita organizar una evaluación en equipo de una tarea concreta. ¿Como sucedió esto? El equipo toma un elemento del trabajo pendiente (nueva tarea, funcionalidad), analiza brevemente los posibles obstáculos y otros matices asociados con él. Luego, cada participante elige una tarjeta con un número que representa su clasificación de dificultad. Ah, y a la hora de estimar no se utilizan las series habituales, sino los números de Fibonacci . Los números de Fibonacci son tan populares en el scrum poker porque la brecha entre ellos aumenta con el tiempo (que recuerda a los niveles de la pirámide). Hay tareas que tendrán una complejidad enorme y no se pueden lograr una pequeña cantidad de puntos de la historia. Explicación de tarjetas inusuales:

número desconocido de puntos finales

una tarea infinitamente larga

Necesitar un descanso

Métodos de estimación más raros:

• en tallas de camiseta: S, M, L, XL
• o en perros: chihuahua, pug, dachshund, bulldog, etc. (en mi opinión, esta es la unidad más extraña para evaluar tareas =D)

Luego, el equipo compara las estimaciones dadas para el mismo problema por diferentes desarrolladores y, si están de acuerdo, ¡genial! En caso contrario, es necesario discutir las razones de las diferencias de valoración (argumentos). Después de esto, podemos llegar juntos a una estimación única, con la que todos, más o menos, estarán de acuerdo. Bueno, ¿por qué se utiliza el póquer para planificar un proyecto de software serio? Después de todo, esto es algo extraño. De hecho, esta gamificación anima a los miembros del equipo a pensar de forma independiente, pidiéndoles que muestren sus resultados al mismo tiempo que sus compañeros. Esto, a su vez, evita la dependencia de las opiniones de otros miembros del equipo. De lo contrario, los desarrolladores menos experimentados buscarán y confiarán en las evaluaciones de miembros más experimentados del equipo, lo que anulará la utilidad de su propia evaluación. Pero con la apertura simultánea de los resultados, esto es esencialmente imposible. Un ejemplo de una aplicación de programación de Scrum Poker es de Atlassian .

Ejemplo de evaluación de tareas

Imaginemos que su equipo ha identificado una determinada escala de evaluación en los puntos de la historia: Scrum Poker comienza con una tarea y la evalúas así:

• nunca antes ha trabajado con la implementación de una funcionalidad similar - +3
• funcionalidad de una tarea de tamaño mediano - +2
• la implementación de la tarea tiene alta complejidad - +3
• alta complejidad de escribir pruebas para esta funcionalidad - +3

Como resultado, obtienes 11 puntos de historia, pero como no existe tal tarjeta, ofreces 13. Otro colega tuyo evalúa la tarea:

• Trabajé con un problema similar antes - +1
• funcionalidad de una tarea de tamaño mediano - +2
• la implementación de la tarea tiene una complejidad media - +2
• complejidad promedio de escribir pruebas para esta funcionalidad - +2

Como resultado, obtiene 7 puntos de historia, pero no existe tal cosa en los números de Fibonacci, y coloca una tarjeta con el número más cercano posible: 8. En consecuencia, otros miembros del equipo dan estimaciones basadas en sus puntos de vista subjetivos. A continuación, muestras tus resultados y descubres que casi todos tus compañeros dieron la estimación 13, excepto un desarrollador que le dio 8. En este caso, se le da la palabra y razona. Y ellos, por ejemplo, son así: él trabajó anteriormente con el mismo problema, y ​​no es tan difícil como podría parecer, y al final convence al resto del equipo para que cambien su solución de 13 a 8 pisos. puntos, diciendo que ayudará a quien asuma esta tarea a resolverlo. O al final lo hará él mismo. Y, en general, no importa si los demás escuchan sus argumentos o no, porque de una forma u otra se le asignará una calificación a esta tarea y el equipo pasará a familiarizarse con la siguiente. Las primeras veces, las estimaciones serán inexactas, al igual que las estimaciones de la cantidad de trabajo que planeas realizar durante el próximo período de tiempo (sprint). Después de todo, estas estimaciones se hacen precisamente sobre la base de estimaciones. Después de un tiempo, aproximadamente tres meses, el equipo comenzará a estimar las tareas con mayor precisión y se hará visible la cantidad promedio de trabajo que el equipo puede completar por sprint. Pero esto es una planificación general del alcance del trabajo, es más bien una cuestión de tiempo, y en este caso puede haber muchos factores diferentes que influyan. Por ejemplo, uno de los desarrolladores se fue de vacaciones durante dos semanas. Es decir, es necesario tachar una cierta cantidad de trabajo planificado (funcionalidad planificada). O ha llegado un nuevo desarrollador al equipo, pero no es necesario contar plenamente con él, porque... hay que tener en cuenta el tiempo necesario para adaptarse al proyecto, llamado onboarding . 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 sus conocimientos en una parte del conocimiento tan no técnica como la estimación de problemas. Si quieres profundizar en este tema, así como en los detalles de Scrum, te recomiendo encarecidamente que leas el libro “SCRUM” de Jeff Sutherland. No puedo responder por las consecuencias, porque tal vez después tengas un deseo molesto de convertirte en un Scrum Master =D