Hola a todos, mi nombre es Alexei Fedorov, soy el líder del equipo de finanzas en Citimobil. En este artículo quiero compartir cómo funciona el proceso de desarrollo ágil en nuestro equipo.
CityMobil es el segundo mayor agregador de taxis en Rusia. A lo largo del año, hemos crecido unas 10 veces y no vamos a frenar. Tal crecimiento rápido impone algunas limitaciones: necesitamos un tiempo de comercialización (TTM) muy corto, el tiempo desde la idea hasta su uso por parte de clientes reales debe ser lo más pequeño posible. Debido al hecho de que minimizamos TTM, no recopilamos la versión, sino que tiramos cada tarea / función por separado. Además, este enfoque tiene una ventaja importante: en caso de problemas en el producto, queda inmediatamente claro por qué han surgido. Esto le permite revertir la tarea, no la versión completa.
¿Por qué no Scrum?
Desde hace varios años, la metodología Agile y su variante Scrum (en lo sucesivo, Scrum) han sido populares en la industria de TI. Scrum intenta implementar de alguna manera en cada empresa. Y cada uno tiene su propia experiencia de implementación, pero, por regla general, rara vez es positivo. Más a menudo viene la desilusión y un retroceso a los procesos anteriores.
En mi opinión, los principales problemas del scrum son:
- Sprints fijos.
Rara vez se cierra el sprint a tiempo para que todo esté listo. Como regla general, queda algo de bajita que está subvalorado o no verificado. Las mejoras se transfieren a otro sprint y, para llegar a tiempo, el equipo realiza menos tareas. Equilibrar el sprint para las tareas para que todos tengan un trabajo es difícil. Las tareas de RnD generalmente no se ajustan a un marco fijo. Y lo más importante, los sprints fijos rara vez son solicitados por la propia empresa. - Una variedad de manifestaciones.
Scrum tiene muchas actividades: reuniones diarias, planificación y una retrospectiva de cada sprint. A menudo, estas reuniones se llevan a cabo para mostrar y son más cansadoras que beneficiosas.
En general, el scrum me recuerda un cierto culto a la carga, que se está introduciendo tal como está con la esperanza de que sea bueno. Nuestro enfoque es utilizar esas técnicas y procesos que ayudan a lograr el resultado y abandonar lo que interfiere.
El equipo
El papel clave en la formación del proceso lo desempeña el equipo y su estructura. Nuestro equipo incluye desarrolladores y líderes de equipo. Opcional PM, QA, analistas, diseñadores. El equipo debe ser percibido como una sola unidad de combate. Esta es una caja gris, a la entrada de la cual hay requisitos, y en la salida: el producto. La organización interna está completamente a merced del equipo y, dentro de sí misma, puede trabajar en cualquier proceso que le convenga.
Como con nosotros
Nuestro equipo eligió un proceso muy similar a Kanban. Tenemos muchas fuentes de tareas: encontradas por el servicio de soporte de errores, nuevas características de productos, deuda técnica, una característica de un equipo adyacente, etc. No importa de dónde provenga la tarea, debe enmarcarse en el rastreador de tareas, preferiblemente por el propio autor. Cualquier tarea entrante pasa por varios estados obligatorios: "Nuevo", "Para trabajar", "En progreso", "Probado", "Listo para el despliegue".
Las tareas se mueven de izquierda a derecha en el tablero, rara vez regresan. La prioridad se extiende de arriba a abajo y de derecha a izquierda. Por ejemplo, desplegar una tarea en la producción es más importante que las pruebas, y las pruebas son más importantes que el nuevo desarrollo. La columna "Al trabajo" esencialmente forma el trabajo atrasado del equipo, una lista lineal priorizada de tareas con un par de semanas de anticipación. Tan pronto como el desarrollador comprende su tarea actual, toma la siguiente columna desde arriba.
Las tareas no se arreglan de antemano para un desarrollador específico, este enfoque permite equilibrar la ejecución de tareas, aumenta el conocimiento general del código por parte de todos los desarrolladores, aumenta el factor de bus. Tratamos de lidiar con una estrecha especialización dentro del equipo. Cada miembro del equipo debe poder realizar cualquier tarea desde la cartera de pedidos. Si el desarrollador asumió la tarea por sí mismo, entonces controla completamente su movimiento en el tablero hasta que aparece en el producto. También comprueba cómo se comporta la tarea en condiciones reales.
De las reuniones que tenemos en las reuniones diarias, en esta reunión discutimos no solo planes, problemas y tareas completadas, sino también enfoques para resolver problemas, propuestas y, en general, todo lo que preocupa a los miembros del equipo. La reunión rara vez dura más de 30 minutos para 4 personas. Todos los meses realizamos una retrospectiva en una muestra de muestra: qué fue bueno / malo, qué podemos hacer con él, un plan para aumentar la eficiencia para el próximo mes. No tenemos una planificación dedicada, organizamos la planificación si es necesario, si comenzamos a desarrollar una tarea grande.
Intentamos registrar el tiempo para cada tarea, al menos el 75% del tiempo de trabajo. Con esto logramos dos objetivos:
- Buscamos y eliminamos a los asesinos de tiempo: tareas que llevaban mucho tiempo, pero que no trajeron los beneficios esperados.
- Evaluamos las tareas sobre la base de ya realizadas, lo que aumenta la precisión de la evaluación.
También tenemos turnos semanales: uno de los desarrolladores responde preguntas de la segunda línea de soporte, busca nuevos problemas en los registros / monitoreo, resuelve tareas urgentes y hace algo que no encaja en la cartera de pedidos planificada. Esto permite que otros desarrolladores se concentren más en sus tareas sin ser distraídos por mensajeros, etc.
Resumen
El proceso descrito con ligeras variaciones lo apliqué en varios equipos y empresas. Se estableció como el más flexible y transparente para todos.
No descansamos en nuestros laureles, con cada nueva retrospectiva hacemos que nuestro proceso de trabajo sea mejor y más eficiente. Cada vez que revisamos las prácticas utilizadas. No tenemos "vacas sagradas"; lo que funcionó antes puede dejar de funcionar, y muchas buenas ideas en teoría no se muestran en la práctica de la mejor manera. Los dejamos caer sin arrepentimiento.
El proceso de mejora continua es la base de nuestro equipo.