Estás haciendo mal estado, y aquí es cómo arreglarlo.
Estás haciendo mal estado, y aquí es cómo arreglarlo.
Cuando se publicó el manifiesto para el desarrollo de software ágil, no fue un proceso, sino un conjunto de principios rectores. Dos de los principios fundamentales, fundamentales del desarrollo ágil son la reflexión y la mejora continua. Al crear una retroalimentación ajustada de la iteración, analizando el meta-proceso de desarrollo del producto y experimentando constantemente para mejorar la comunicación y la eficiencia, estos equipos ágiles tempranos pudieron ofrecer un software de alta calidad de manera eficiente y poder adaptarse rápidamente a las prioridades cambiantes del negocio.
A medida que más y más personas bebían el kool-aid, y Scrum se convirtió en la corriente principal, muchos equipos adoptaron el dogma sin los principios. Trataron Scrum como un proceso rígido en sí mismo, en lugar de un enfoque para desarrollar un proceso que funcione para el equipo. Muchos equipos han adoptado Scrum como una forma de medir y maximizar la productividad, convirtiendo efectivamente el desarrollo de software en un proceso de línea de ensamblaje. Me gusta llamar a esto el Mini-Modelo de cascada. Al enfocar toda su energía en la estimación, las tablas de quemaduras y la velocidad, al tiempo que ignoran los primeros principios de reflexión, experimentación y mejora continua, se ha convertido efectivamente en lo opuesto a los ágiles.
El modelo de línea de montaje
La línea de montaje, o modelo mini-cascada, enfoca toda su energía en la estimación, medición y control de la velocidad. En esta línea de ensamblaje, el punto de la historia es la unidad de producción, y todos los sistemas y procesos están diseñados para maximizar la productividad. En este modelo, se invierte una cantidad significativa de gastos generales en la estimación de tareas, trabajo de registro, desarrollar gráficos de incurtores y informes de Sprint, y suministro de estado en las instalaciones diarias. Para probar cosas nuevas y experimentar con el proceso introduciría el riesgo en la línea de producción. Para maximizar la salida de funciones, hay poco espacio para invertir en automatización, pagar la deuda técnica, aprender nuevas tecnologías, mejorar la documentación o experimentar con el proceso de desarrollo. Si esto suena como usted, y usted no está invirtiendo de manera significativa en una mejora continua, está haciendo Scrum, todo mal.
El papel del propietario del producto.
El propietario del producto no es el cliente del equipo Scrum, es un miembro integral del equipo de Scrum. El trabajo del propietario del producto es articular y comunicar claramente la visión y la misión del producto, las prioridades relativas y, lo que es más importante, la voz del cliente. En exitosos equipos de scrum, el propietario del producto se encuentra físicamente con el equipo todos los días y está trabajando constantemente para transmitir la visión en alta fidelidad a los ingenieros, para que puedan obtener una comprensión clara del panorama general y puede tomar decisiones de productos más intuitivos. A la inversa, los ingenieros deben explicar constantemente los aspectos técnicos del producto para que el propietario del producto pueda obtener una comprensión clara de las capacidades tecnológicas, las limitaciones y la viabilidad. Si el propietario del producto es tratado como cliente, evita que se forme un fuerte vínculo de confianza, y crea una brecha de comprensión y comunicación.
El papel del maestro de scrum
En la línea de ensamblaje Scrum Equips, el Scrum Master es simplemente un gerente de proyecto, cuyo trabajo es proporcionar informes de estado, asistir con el aseo de la acumulación, la planificación de la capacidad, etc. En los equipos de scrum exitosos, el Scrum Master es un entrenador y un mediador, cuyo trabajo es garantizar que el equipo esté estrechamente integrado, comunicándose claramente, buscando realmente comprender el problema, aumentar los problemas, comprometerse con los principios y la experimentación de conducción a continuamente. mejorar. El Scrum Master es responsable de garantizar que el equipo esté siendo ágil con una "A" en minúscula en lugar de una "A" de capital, y siguiendo los principios ágiles en lugar del dogma de Scrum.
Planificación de Sprint
El propósito de la ceremonia de planificación de Sprint es garantizar que todas las tareas de alta prioridad estén claramente definidas y procesables, que todos los equipos comprendan los criterios de éxito claro, y comprometerse con un alcance del trabajo que no se romperá ni se alterará durante el curso. del sprint. Para este tiempo, el propietario del producto ya debería haber definido y priorizado claramente la atrevida, de modo que los ingenieros puedan estimar de manera rápida y eficiente los puntos de la historia y determinar la claridad y la viabilidad de cada tarea.
El propósito de la planificación del póker no es comprometerse con una medida dura y rápida de la productividad, sino evaluar qué tan bien definidos y pensamientos son las tareas. El punto de la historia no es realmente una medida del esfuerzo, es una medida de complejidad. Si una historia se califica como un 3, entonces se conocen todas las variables, y es una simple cuestión de producir el trabajo. Si una historia es un 8, sin embargo, hay muchas dependencias, incógnitas, criterios mal definidos o riesgo para romper otras partes del código. El propósito de la planificación de Sprint es identificar historias que deben desglosarse, definirse aún más o requieren una investigación adicional para comprender completamente.
El pico
El Spike es una herramienta crítica que muchos equipos de Scrum pasan por alto cuando se maximizan para la productividad. Si el programa Sprint es rígido, lo que significa que se espera que un Sprint comience inmediatamente después de la finalización de otro, no deja tiempo para una investigación o aclaración adicional. Si, durante una reunión de planificación de Sprint, se debe iniciar demasiadas las puntuaciones de la tarea, o tiene demasiadas incógnitas, se debe iniciar un pico y el inicio de Sprint debe posponerse hasta que se complete la espiga. Una advertencia para esto es si la tarea no es crítica para el Sprint, la punta se puede tratar como la tarea para el Sprint actual, y la característica en sí puede posponerse al siguiente Sprint.
Durante el Spike, un ingeniero puede investigar una nueva tecnología, revisar un poco de código heredado, crear un prototipo, o aclarar de otra manera incógnitas y reducir la complejidad. Una vez que se ha completado el Spike, se puede hacer un verdadero compromiso y la historia ya está lista para la acción. La premisa fundamental aquí es que hay períodos de descanso y pensamiento horneados entre los sprints. El Sprint no se inicia en una fecha en particular, se inicia cuando hay una comprensión clara y un compromiso con un alcance del trabajo.
El pienso diario
En el Scrum de la línea de montaje, el Standup diario se utiliza para recopilar y actualizar la actualización de estado de modo hasta que el Scrum Master y el propietario del producto puedan actualizar sus informes de estado. Esto no hace nada para mejorar la capacidad del equipo para ejecutar el ciclo mediano. En exitosos equipos de scrum, el standup está reservado para comunicar los obstáculos.
Si falta un ingeniero, una dependencia crítica o una pieza de información, no está clara sobre los criterios del objetivo o del éxito de una historia, o está bloqueado de lo contrario, es el deber del equipo ayudar a aclarar esas obstáculos. Si el ingeniero no tiene obstáculos y tiene una dirección clara para el día, él o ella simplemente puede ceder su tiempo. El estado se puede observar fácilmente en la propia tabla de sprint. Así es como mantiene un stand hasta 15 minutos y de pie físicamente, centrándose en ayudar a los ingenieros a tener éxito, en lugar de intentar obtener el estado actualizado.
La retrospectiva
La retrospectiva es la ceremonia más importante en todo el proceso de desarrollo. Si no está realizando una retrospectiva en serio al final de cada Sprint, donde identifique lo que está funcionando y no trabaja en su proceso, y haga una lluvia de ideas y se comprometa a probar cosas nuevas, no tiene en cuenta los principios del desarrollo de software ágil.
Como entrenador de desarrollo ágil, he encontrado demasiados equipos que saltan la retrospectiva por completo, o lo hacen solo otra oportunidad para discutir las características del producto. Con algunos clientes, simplemente lo usan como una oportunidad para perra y gemen sobre las personas y las cosas que les causan dolor, sin comprometerse con ninguna solución.
El modelo estándar para conducir la retrospectiva es detener, comenzar, continuar. Esta es una forma de romper y analizar la comunicación y la entrega del producto de trabajo a través de la tubería. Es una oportunidad para identificar problemas en el proceso que resultó en la ineficiencia o el desperdicio, y para diseñar un método experimental para abordarlos. Aquí hay un ejemplo de diálogo:
"En el último Sprint, intentamos completar esta tarea de 8 pisos, pero cuando comenzamos a desarrollar, nos dimos cuenta de que dependía de alguna tecnología desconocida. Nos llevó más tiempo de lo que se espera que se aceleren con esta nueva tecnología, lo que hizo que nuestra línea de tiempo se deslizara. Como resultado, no completamos las tareas X, Y, y Z, y nos vimos obligados a apretar nuestro ciclo de control de calidad para completar el Sprint a tiempo ".
"Para evitar esto en el futuro, debemos asegurarnos de que las tareas altamente calificadas sean investigadas y aclaradas plenamente, divididas en tareas más pequeñas si es posible, y debemos darnos un tiempo no estructurado antes de iniciar un sprint para investigar estas incógnitas".
"Deberíamos dejar de forzar los sprints para comenzar inmediatamente después de completar el Sprint anterior, y comprometerse con las tareas que son demasiado complejas. Debemos comenzar a establecer la expectativa de que la reunión de planificación de Sprint probablemente será seguida por uno o dos picos, y se contabilizará una reunión de planificación de Sprint ad-hoc posterior una vez que se contacden todas las incógnitas. Solo entonces podremos realmente comprometerme con el Sprint y ejecutaremos de manera efectiva ".
En este modelo, detenga los medios para identificar un problema de proceso y una oportunidad para la mejora continua, arranque significa idear un experimento para abordar ese problema, y continuar significa validar que el experimento fue un éxito y debe incorporarse en el proceso en el proceso. Esta es la base del desarrollo de software ágil.
Siempre estar enviando
Otro principal crítico, pero a menudo pasado por alto, el principal de Scrum es que siempre debe estar en condiciones de enviar a la producción en un momento de aviso. Muchos equipos pasan por alto esto simplemente sin presionar a la producción al final de cada sprint, y agrupar varios sprints en grandes lanzamientos. Esto está mal por varias razones.
Para estar en un estado listo para enviar, varias cosas deben estar en su lugar:
Cuanto más complejidad introduzca, cuanto más grandes sus lanzamientos, y más monolítica, su arquitectura, más difícil y que consuma mucho tiempo será empujar rápidamente los cambios. Esto resulta no solo en el aumento de la sobrecarga para la implementación, sino que también rompe los bucles de retroalimentación crítica. Al no poder ingresar rápidamente y recopilar comentarios, es probable que invierte demasiado en la solución incorrecta y aumente la cantidad de retrabajo y deuda técnica más adelante. El principio de envío siempre debe estar tejido en la tela de su arquitectura y proceso de desarrollo.
Celebracion
Uno de los mayores fallos de los equipos de scrum de línea de ensamblaje es que convierten los sprints en maratones que nunca terminan. El ciclo interminable de Sprint después de Sprint en un esfuerzo por maximizar la productividad puede ser aplastante al alma. En exitosos equipos de scrum, toman todas las oportunidades de celebrar sus éxitos, defienden los éxitos de sus clientes, recompensan a los que fueron más allá, y brindan una perspectiva sobre cuánto ha mejorado el equipo con el tiempo. Esto puede ser una ceremonia elaborada en ocasiones especiales, o tan simple como un equipo de almuerzo o una hora feliz después de cada sprint. Es fundamental no pasar por alto este período de descanso y aprecio, ya que proporciona la pasión y la energía que se necesitarán para el próximo Sprint.
Conclusión
Sostenga un espejo, busque profundamente dentro de su propio corazón y reconozca cuál de estos equipos se identifica con más. Comparta este artículo con su equipo y discútalo en su próxima retrospectiva. Identifique todas las formas en que sigue los primeros principios, y todas las formas en que se suscribe al dogma. No tenga miedo, el primer paso para la mejora continua es admitir que tiene un problema.
¡RECIÉN LANZADO! ¡Obtenga su kit de herramientas de desarrollo de productos gratis!
He reunido un paquete completo para ayudar a los empresarios, los fundadores de inicio y los CEOs, aprenden a crear productos y empresas de tecnología. La primera pieza, que estoy regalando de forma gratuita, es un kit de herramientas de desarrollo de productos personalizables. Incluye todas las plantillas que uso con mis clientes reales para ayudarles a obtener de la idea de la ejecución. ¡CONSIGUELO AQUI!