Hola. Déjeme contarle sobre mi experiencia en la evaluación de productos de software. He estado haciendo esto sin interrupción durante 15 años y me gustaría compartir mi experiencia y la evolución de mis puntos de vista sobre la evaluación. Estoy seguro de que te será de utilidad. Comencemos con el establecimiento de metas. ¿Por qué medir en absoluto? Quien lo necesita
La respuesta es realmente muy simple: la gente quiere certeza, en particular la respuesta a la pregunta "¿cuándo estará lista?" Cuándo puedo irme de vacaciones, cuándo comienzan las ventas, cuándo realizar una tarea relacionada. Por otro lado, nunca se sabe lo que la gente quiere, ¿por qué debido a los deseos de otras personas de perder el tiempo en esta actividad?
Pero, en última instancia, a todos nos gustaría recibir un salario, y el salario no aparece de la nada, la empresa lo toma de los ingresos, en un caso separado, de las inversiones. Y para que estos mismos ingresos sean, debemos lograr un objetivo comercial. Y a las personas que formulan objetivos comerciales les gustan mucho todo tipo de fórmulas financieras: ROI, LTV y otros EBITDA. Y estas fórmulas presentan constantemente fechas límite. Sin ellos, el cocodrilo no se atrapa, el coco no crece.
También hay una segunda razón, un poco menos importante: si las estimaciones de las características son claras, esto afecta su prioridad, las tareas más simples tienden a recibir una mayor prioridad. Dado que en el enfoque ágil convencional, la acumulación de trabajos pendientes se modifica regularmente, la información de entrada sobre las calificaciones de las tareas ayuda a que el proceso de repriorización sea más eficiente.
Como consecuencia: lo más probable es que todavía tengas que evaluar. Humíllate .
Ahora hablemos de cómo hacer esto, para no maldecir a todo y a todos en el proceso. ¿Cómo suelen calificar las personas que no saben cómo evaluar las cosas de TI? Como esto:
- Evaluamos todo el trabajo en días persona.
- Agregue un 10% por si acaso.
- Divida por la cantidad de desarrolladores.
- Agregamos el número de días resultante a la fecha actual y obtenemos la fecha final.
- Eso es todo.
Debido a esto, los flashbacks vietnamitas de la imagen del título siguen apareciendo ante mis ojos: muchos de mis nervios se perdieron en esta guerra. Y morirá por usted si comienza a evaluar de esta manera. El problema es que este es exactamente el tipo de evaluación que se espera de usted:
"No juegue con sus historias, muestre su mano".
Qué problemas se enfrentarán durante la evaluación
Comencemos con una situación ideal:
- Tenemos una tarea atómica (simple, indivisible).
- No depende de otras tareas, no es necesario coordinar nada.
- Hay una persona 100% dedicada a la tarea que sabe cómo realizarla.
Incluso en este caso, surge la pregunta "¿Quién hará la evaluación?" En este momento, se pone en marcha la implacable máquina de control. Primero, el gerente piensa: si el desarrollador va a hacer esto, ¿qué le impedirá especificar enormes costos laborales para perder el tiempo? -> Por lo tanto, el gerente evalúa la tarea él mismo. -> Sin embargo, el gerente no comprende el tema con la suficiente profundidad y no ve (o no quiere ver) las trampas. -> La estimación resulta irreparablemente subestimada. -> El equipo no cumple con el plazo. -> Muerte y decadencia.
La situación descrita anteriormente es un problema clásico de la cultura empresarial de desconfianza hacia sus empleados. Sin embargo, la mayoría de los desarrolladores tienen una motivación intrínseca para resolver problemas interesantes, para ellos es mucho más atractivo que hacerse el tonto en la computadora, por lo que no hay razón para una desconfianza generalizada. En general, una empresa debe construirse sobre la base de la presunción de confianza en sus empleados y no torcer los procesos comerciales normales para que parezcan ovejas negras.
Una cultura de desconfianza es muy común junto con una cultura corporativa de miedo: incluso si un desarrollador está evaluando una tarea, ¿qué sucede en su cabeza durante la evaluación? Responde a la pregunta: "¿Cómo reacciona mi empresa a la discrepancia entre las fechas planificadas y reales?" Si el desarrollador es regañado por los plazos fallidos, los sobreestimará. Si las evaluaciones posteriores del desarrollador se cortan para las tareas realizadas con anticipación, no entregará las tareas por adelantado.
El ejemplo más reciente de una cultura del miedo es el lanzamiento de Cyberpunk 2077. El juego fue lanzado con una calidad repugnante en las consolas de generaciones anteriores. El CEO de la compañía dijo en un comunicado que "resulta que muchos de los problemas que encontraste en el juego no se encontraron durante las pruebas". Lo cual, por supuesto, es una mentira total. Los problemas eran visibles a simple vista, los probadores físicamente no podían perderse esto. Ésta es una situación típica en una cultura del miedo: los problemas se silencian. Así que la información a lo largo del camino hacia el piso superior de la gerencia pasó de "juego no jugable en consolas base" a "lanzemos".
Si este no es su caso, puede evaluar más. Si no tiene suerte con la cultura de la empresa, no siga leyendo, porque necesita emitir evaluaciones no por precisión, sino para minimizar las patadas de las autoridades, y esta es una tarea completamente diferente.
Y entonces dio una estimación, por ejemplo: 1 semana. Esta es solo tu suposición, nada más. La evaluación determina la fecha de finalización planificada de una tarea, pero no puede determinar cuándo se completará realmente. El lugar exacto en el que estará el tiempo real de finalización de la tarea se describe mediante una distribución normal. Por ahora, recordemos esto como un axioma, al final habrá un giro en la trama.
Todo se complica aún más por el hecho de que algunas tareas no se dividen fundamentalmente en partes, y también sucede que no se pueden paralelizar. También hay tareas interdependientes, necesita sumergirse en el contexto de las tareas. Además, durante el desarrollo, el equipo necesita comunicarse para sincronizar sus actividades.
Tampoco sabemos cómo ver el futuro. Como resultado, constantemente surgen tareas que no previmos y no pudimos prever. ¿Qué podría ser?
- Deseos del cliente o propietario del producto.
- Problemas repentinos, para los que hay que mejorar algo.
- Legal inesperado.
- Y toneladas de cosas.
El más impredecible es el problema de la diferente velocidad de los desarrolladores.
Para desarrolladores reales del mismo nivel y con el mismo salario, la productividad puede diferir en un orden de magnitud:
- Alguien cortará y depurará el código durante una semana, y alguien arruinará la biblioteca abierta en medio día.
- Alguien fumará Stack overflow, y alguien ya ha resuelto esos problemas y comenzará a beneficiarse de inmediato.
Como resultado, nuestro gaussiano se convierte en algo como esto (la estimación se ve igual cuando la tarea no tiene el tamaño suficiente):
En general, todo es complicado, no estamos cavando trincheras aquí. ¿Cómo puedes sacar una buena nota en tales condiciones?
Buen criterio de calificación:
- Alta velocidad de evaluación: la evaluación en sí misma no tiene ningún valor comercial, por lo que es lógico realizarla lo más rápido posible para no distraerse del desarrollo.
- La evaluación es responsabilidad de todo el equipo, y hay un buen principio de “tu calificas, lo haces” que protege al equipo de las marcas límite.
- No se olvide de todos los componentes de la salida de una función en producción: análisis, desarrollo, pruebas unitarias, pruebas automáticas, pruebas de integración, devops. Todo esto debe evaluarse.
Como puede ver, no he escrito nada sobre precisión. Durante los 15 años que llevo haciendo estimaciones, no he aprendido cómo hacerlas con precisión, así que seamos más modestos e intentemos estimar al menos aproximadamente. Todo el proceso de evaluación se ve así:
- Incluir tareas en la cartera de productos.
- Evaluamos las historias de mayor prioridad en el backlog utilizando cualquier método (hay muchos métodos, los contaré a continuación).
- Empezamos a trabajar (por ejemplo, en Scrum - por sprints).
- Después de varios sprints, medimos cuántos puntos de historia obtenemos en promedio en cada iteración. Esta es nuestra Velocidad: velocidad promedio de desarrollo del equipo.
- . burndown chart. , .
Pero el mundo no es perfecto, así que arreglamos cuántas funciones nuevas (también estimadas en puntos de la historia) genera nuestro Product Owner en cada sprint. La línea roja mostrará el crecimiento de la acumulación, ahora la intersección de las líneas roja y azul es la fecha deseada.
Si el Product Owner es muy creativo, entonces puede incluso ser así:
Y ahora recordamos que la evaluación obedece a las leyes de la distribución normal, pero el giro de la trama: tales gaussianos se suman perfectamente. Por lo tanto, esto es lo que resulta (esto se llama un gráfico quemado mejorado):
Parecería que el sueño de un joven matemático se ha hecho realidad: de un montón de caos obtuvimos un gráfico hermoso y podemos transmitir con una mirada inteligente que “ con un 50% de probabilidad terminaremos en el sprint 14, con un 80% de probabilidad en el 17, desde el 95% - en el 19 ”.
Hay una serie de obstáculos en todo este proceso.
En primer lugar, diré inmediatamente sobre el elefante en la habitación: la acumulación es grande, hay muchas tareas de las que no se sabe nada excepto la descripción en el formato de la historia del usuario, por lo que la estimación será muy aproximada en cualquier caso. Ya he mostrado más arriba cómo se ve una estimación aproximada en el lenguaje de las matemáticas.
En segundo lugar, el problema "los desarrolladores trabajan con una productividad diferente" no se resuelve de ninguna manera en principio.... Esto significa que obtenemos un aumento muy plano en la probabilidad, lo que no ayuda mucho a tomar decisiones de gestión: “con un 50% de probabilidad terminaremos en el 14º sprint, con un 80% de probabilidad - en el 27, con un 95% - en el 39 ”, por lo que en el lenguaje de las matemáticas, suena como“ un dedo al cielo ”.
Por lo tanto, maximizo personalmente la métrica de "tasa de evaluación" y ahora le diré los métodos que probé.
Planificación del método de póquer
Ésta es una de las técnicas de evaluación más populares, probablemente porque es la más antigua.
- Los participantes en el proceso utilizan tarjetas especialmente numeradas con números de Fibonacci.
- El propietario del producto hace un breve anuncio de la próxima historia y responde a las preguntas del equipo.
- Después de recibir la información, los participantes del "póquer" eligen una tarjeta con una valoración adecuada, en su opinión, y no se la muestran a nadie.
- Luego, todos se revelan juntos, y los participantes con los puntajes más bajos y más altos dan breves comentarios explicando su elección de puntaje.
- Como resultado del proceso de discusión, el equipo toma una única decisión y luego pasa a la siguiente historia.
Durante una sesión de una hora de esta manera, puede evaluar de 4 a 8 historias. Este es el mayor problema con este método: es largo, la gente se aburre y se distrae. No fue en vano que utilicé la frase "todos se revelan juntos".
El método de "orden de construcción"
Este es el enfoque que estamos usando actualmente en el trabajo. El punto es evaluar las tareas en relación con las demás. Así se construye una secuencia de tareas ordenadas por dificultad. Para este método, primero debe acumular un grupo de tareas evaluadas y colocarlas en la báscula.
- Cuando llega el momento de evaluar, cada miembro del equipo se turna para realizar su movimiento (como en un juego de mesa). Los movimientos pueden ser los siguientes: poner la tarea en la escala, mover la tarea a lo largo de la escala, discutir la historia con sus colegas, omitir su movimiento.
- Como resultado, las tareas se mueven constantemente alrededor del tablero, su evaluación relativa entre sí se refina hasta que se obtiene un estado que satisface a todo el equipo.
- Cuando todos los participantes pierdan su turno, habrá terminado.
Esta es una técnica rápida. Con su ayuda, puede estimar de 15 a 20 historias por hora, lo que suele ser suficiente.
Método grande / pequeño / oscuro
Lo he usado varias veces, pero no echó raíces.
- En el tablero están marcadas tres zonas: "tarea grande", "tarea pequeña" e "información insuficiente".
- , «/». « » = « ».
- .
El método tiene una gran ventaja: es súper rápido. De modo que puede procesar 50 historias de usuario por hora.
Aquí hay un problema al traducir estas estimaciones en puntos de la historia, pero cuando ya se conoce la velocidad del equipo, entonces entendemos cuántos puntos de la historia masticará una persona por sprint en Jira y evaluamos pequeñas tareas en torno a esta métrica.
En cuanto al resto de tareas. Envié tareas del área de "información insuficiente" al análisis, y tareas de la "tarea grande" a la descomposición, para que pudieran ser reevaluadas en la próxima sesión.
Como resultado, en nuestro producto simplemente dibujamos una hoja de ruta con características que creemos que tendremos tiempo de escribir en un futuro cercano. Si no tenemos tiempo, bueno, pasa. Y usamos estimaciones solo para las tareas inmediatas, que hemos normalizado, e incluso entonces, no siempre.
Tal vez me dedique a arrojar mi incompetencia en el campo de la evaluación en términos pseudocientíficos, pero para mí, personalmente, el proceso en sí parece bastante tonto, como un extraño culto de carga que jugamos para fingir que somos los mismos estables y industria predecible, como alguna otra industria realmente estable y predecible. Me encantaría leer sobre su experiencia en esta área, tal vez me esté perdiendo algo.