Hola Habr! Mi nombre es Artyom y soy líder de equipo en Skyeng. Mi equipo de desarrollo tiene un cliente, es gerente de producto, solo es Vanya. Vanya cree que nuestro esquema de puntuación no es perfecto. Por ejemplo, una calificación de 2 días no le da nada. Verá su tarea a la venta en una semana o 10 días, o más. O menos.
Esto sucede no porque estamos fallando en las tareas, sino porque con la estimación tradicional, en realidad, solo estimamos el tiempo que le toma a un desarrollador escribir código. Pero todavía hay pruebas y revisión de código. Ok, pongamos todo esto en la evaluación. Pero también:
- tenemos una cola justo antes del desarrollo y las pruebas,
- hay mejoras, no estamos sin pecado,
- vuelan tareas urgentes
- Cuando una implementación afecta a varios servicios, estamos esperando una revisión de los equipos relacionados.
Cómo aprender a responder la pregunta "¿Cuándo?" , si la previsibilidad está fuera de la cuestión?
Cómo dudamos de la estimación
Nuestro equipo, como muchos en la empresa, tiene una reunión muy útil: una revisión técnica (o, en resumen, una revisión técnica ). Requiere una buena cantidad de tiempo y esfuerzo, pero agrega previsibilidad: pre-pintamos la solución técnica al problema y al mismo tiempo la evaluamos.
Como siempre estamos remotos, todo sucede en JIRA: hay un tablero en el que se visualizan las etapas del trabajo. La tarjeta deja el estado de Techview y pasa a Listo para el desarrollo después de que describimos y evaluamos todo. Es en este momento que nos comprometemos a hacer el trabajo.
"Listo para el desarrollo" tiene un límite WIP: no puede haber más de 8 tareas al mismo tiempo. También existe la regla opuesta: tan pronto como haya pocas tareas en una columna, iniciaremos una nueva revisión técnica.
Hecho: Pasamos un tiempo significativo evaluando. Una revisión técnica generalmente se lleva a cabo dos veces por semana, puede tomar de 1.5 a 3 horas completar 4 tareas con un estudio y evaluación detallados. ¡Pero! Entonces todavía podemos tomar tiempo para descubrir por qué se excedió la estimación.
Sin embargo, ni la calificación ni la información agregan valor a nuestro producto. Más bien, estamos perdiendo el tiempo con ellos. Y dinero. Durante mucho tiempo dudé de la necesidad de estos procedimientos, y en un momento maduré en una conversación seria con el producto. Y ambos reconocimos el problema.
"La camisa está seca y completamente ..." no XS
Decidimos: experimentemos con enfoques de evaluación. Sugerí centrarse en el tamaño de la camiseta: el tamaño de las camisetas se usa como la unidad de medida en esta técnica. Necesita encontrar la tarea más pequeña que tiene que hacer y confundirla con XS. Después de eso, las tareas restantes se evalúan en función de "cuánto más grandes son XS" y, según esto, se les asigna el tamaño S, M, L o XL.
Sobornó a la oportunidad de evaluar "a simple vista". La idea era simple: recopilaremos estadísticas sobre cuánto tarda el desarrollo en completar una tarea de una dimensión u otra, calcularemos el promedio y podremos predecir el momento.
El cliente nos perdonará un error en uno o dos días, lo que significa que no se realizarán más informes. Y en la revisión tecnológica no tendrá que perder el tiempo en votaciones interactivas y secretas. ¡Todo es suave!
Hemos estado trabajando de esta manera durante varios meses, recopilando estadísticas. Y solo Ivan nos mira con recelo.
Resultó que XS, como S, lo hacemos en 1 día, luego en 10. Y en L pasamos 5, o incluso 15 días. Porque, de hecho, tomamos algo de trabajo primero, algunos en el segundo y algunos en el quinto, y las tareas de la misma dimensión pasan diferentes tiempos en estado de espera. Vaya, aquí está el promedio.
En resumen, la propagación aquí no es en un par de días, y para Vanya, poco ha cambiado. Encontramos que el experimento no tuvo éxito, pero la idea de que las tareas pueden clasificarse de alguna manera quedó en mi cabeza. Y comencé a pensar más en esta dirección.
“Todos aman los pasteles. Puff! " Burro de Shrek
Y yo amo. ¡Además, el cumpleaños de un niño es una gran ocasión! Voy a mi sitio favorito y comienzo a elegir:
- es posible, pero no es posible
- Puedes decorar, pero no puedes decorar,
- Es posible para 2 kg, y es posible para 5 kg.
No revelaré mis preferencias de sabor, pero elegí el pastel. Y lo llevaron a la fecha señalada. Lo siguiente será la filosofía de comer en exceso la torta tímida.
Por supuesto, no soy Newton, y el pastel no es una manzana, pero la idea ha llegado.
Podía elegir entre muchas opciones, pero lo que elegí, la fecha de entrega no cambió. Necesitaba un pastel en una semana. Y estaba listo para brindar este servicio. Y el tamaño del pastel, el peso y todo tipo de campanas y silbatos no afectaron en gran medida el resultado final; más precisamente, en este caso, no afectaron en absoluto. No se trata del tamaño, como dicen. Y en que En el precio
Por ejemplo, los chicos tenían un pedido expreso: por una tarifa adicional, me habrían traído el mismo pastel de fantasía en solo un par de días, y no en 5. Mi pedido, como el más valioso en comparación con otros, se habría salido de la línea. De hecho, la pastelería tiene dos SLA: para un pedido regular y para un VIP. Hay algo en que pensar.
La idea de SLA se activó porque leí sobre ella en la Guía Kanban
Desde el punto de vista del método Kanban, todo es un servicio. Y a pesar del hecho de que no suministramos pasteles, y nuestro producto no puede ser tocado o comido, el desarrollo también es un servicio. Y también tratamos las tareas de manera diferente.
Recuerde nuestra junta: el
servicio consta de varias etapas (desarrollo, revisión de código, pruebas), y la columna "Listo para el desarrollo" es nuestro punto de compromiso con el cliente.
Hacemos algunas cosas a nuestro ritmo habitual, pero cuando llegan las tareas de grabación, dejamos todo. Queda por comprender qué SLA tenemos, y será posible llegar a un acuerdo con Vanya.
Cómo evaluar el SLA de su equipo: construir un diagrama espectral (es fácil)
Para comprender qué clases de servicio tenemos y qué SLA tienen, Kanban sugiere construir el siguiente gráfico:
- Lead Time (LT) — . « » «».
- Y — LT1, LT2, LT3 ..
Tomamos las tareas cerradas en los últimos meses y obtuvimos lo siguiente:
cerramos 3 tareas en un día, 6, en dos, sobre todo, en 5, y en algún lugar luchamos por la tarea durante más de dos semanas ...
Bueno, ahora es el momento de analizar. ¿Cuáles son estas tareas? ¿Por qué terminaron aquí? ¿Por qué hacemos más en ciertos LT que en otros, qué hay allí? Puede excavar a clientes y artistas, así como estudiar los comentarios a la tarea.
Esto es lo que tenemos que cavar. Este es nuestro trabajo habitual .
La propagación es bastante grande, pero es susceptible de análisis.
En general, la mayor parte de las tareas se distribuyeron en el intervalo de 7-14 días, y una pareja voló muy lejos, en esta cola hubo varias tareas (no todas) desde relaciones públicas hasta otros servicios. Esas tareas que se completaron en 3-4 días son la excepción y no la regla.
, , , 75% 10 .
Y con una probabilidad del 90%, tomará 14 días. Bueno, si el desarrollo afecta a otros servicios de la empresa, llevará un poco más de tiempo esperar; necesitamos una revisión de código de otro equipo y luego otro lanzamiento.
Vamos más allá. Llamamos a esta clase "Importante" .
Por alguna razón, estas tareas se toman para trabajar antes que otras: hay más valor o el costo de la demora es mayor.
Y aquí también podemos expresar el SLA: con un 75% de probabilidad de que la tarea salga a la venta en 5 días, con un 90% de probabilidad en 7. ¿Continuamos?
Las mismas tareas por las que abandonamos todo y vimos, vimos, vimos - bloqueadores .
En el 100% de los casos, se trata de mejoras menores que no tomamos en cuenta al implementar la función principal, o errores que afectan la funcionalidad vital en la producción.
A pesar de que logramos resolver todas esas situaciones en 2 días, aún anunciaremos el percentil 90. En primer lugar, no debe prometer el 100%, nunca a nadie :) En segundo lugar, debe desarrollar la variabilidad: recordemos el caso con el trabajo regular, cuando varias tareas se fueron en más de 20 días, porque apareció la dependencia de otros equipos.
¡Hecho! Podemos estar de acuerdo con Vanya en SLA para todas las clases de servicio:
hemos elegido exactamente el 90% en términos de términos; esta es, de hecho, la tolerancia del cliente por incumplimiento. Es decir, si 1 de cada 10 tareas no encaja en el SLA, estamos listos para perdonarlo.
Si su cliente no es tan amable, es mejor expresar el percentil 95, por ejemplo.
En lugar de una conclusión
- ¿Qué impide que Vanya reclute solo tareas o bloqueadores importantes?
- Límites horizontales de WIP.
Acordamos un límite en el número de tareas en la clase de servicio: no puede tomar más de dos bloqueadores, no puede tomar más de dos tareas importantes. Es posible que tenga otros números; esto es una cuestión de acuerdo con el cliente. No puede establecer tales límites en JIRA sin complementos, por lo que definitivamente se necesita un acuerdo verbal. Las herramientas son herramientas, pero sin interacción humana, en ninguna parte.
¡Gracias por su atención y planificación exitosa!