Cualquier discusión sobre los procesos de desarrollo de software se basa en algunos enfoques clásicos de cómo crear software moderno. Debemos establecer alguna cadencia para entregar productos con la frecuencia esperada teniendo en cuenta las necesidades del mercado. Una longitud de iteración debe reflejar la velocidad necesaria de adaptación a los cambios de backlog del producto. Los equipos deben prepararse para cada iteración y preparar los elementos de backlog. Parece que el enfoque de gestión de prioridades es absolutamente intuitivo y no tiene que tener un profundo entendimiento en la estandarización para usarlo en su desarrollo de software. Sin embargo, establecer cualquier proceso significa declaración de principios generales para cada miembro del equipo. Y aquí están las complicaciones: ¿cómo explicar a cualquier miembro del equipo qué significa algún dígito o palabra junto a una tarea o un error del producto? Siempre es posible inventar tu propio sistema de prioridades, pero esto lleva a la necesidad de explicar los principios de tu sistema para cada nuevo miembro del equipo. Si el proyecto es grande y tienes muchos nuevos compañeros de trabajo, bueno, eso es un problema. Por lo tanto, es más fácil usar algunos estándares o enfoques internacionales probados por el tiempo. En este artículo me gustaría discutir el uso del método MoSCoW para la priorización en el desarrollo de productos como la forma más común de racionalizar el trabajo durante las iteraciones, que proporcionan resultados rápidos y mensurables. Como ilustración, voy a proporcionar un ejemplo del método de priorización personalizado y los problemas que he enfrentado con este enfoque.Entonces vamos a sumergirnos en la descomposición del método MoSCoW para considerar cada prioridad con ejemplos vivos. Un artículo puede ser útil para los gerentes de producto o cualquier persona que persiga el proceso de desarrollo de productos que funciona bien. Disfrutar con el enfoque personalizado en cuanto a la prioridad del artículo Hace mucho tiempo, en un equipo de productos, tratábamos de resolver un problema con las prioridades de los artículos en nuestros ciclos de desarrollo. El proceso en sí era muy inmaduro: los plazos de implementación a menudo se violaban, el equipo tenía que trabajar horas extras, y los lanzamientos de productos eran de calidad insatisfactoria. En ese momento usamos las prioridades numéricas 1-2-3-4 y no ayudaron en absoluto. Luego decidimos simplificar la comunicación entre los miembros del equipo e introducimos una prioridad adicional “5”. Esta prioridad se convertiría en la prioridad más alta, más importante que “1”, y significaría “showstopper” - el billete o elemento que debería implementarse ASAP, a pesar de cualquier otra tarea en el backlog de iteración. Por supuesto, esta decisión generó docenas de preguntas: Why is “5” more important than “1”? Because historically we had myriad priority “1” items, and “0” was used for the tasks that had to be prioritised later. Changing the meaning of “0” means a thoughtful review of the entire backlog, implementation of some migration, and nobody wanted to do it. How does it happen that we have so many priority “1” tasks in the iteration that we have to introduce an additional priority? And what is the purpose of 2-3-4? These are the most important questions that show the process immaturity, because team members had no idea what the difference was between 2-3-4. All these tasks were just “optional”. How do we explain these illogical rules to new team members? These rules were impossible to explain, and this improvement didn’t help to make things right. Por supuesto, un método de priorización no era el problema general en este proceso.Hubo problemas fundamentales en el enfoque sobre la planificación, la gestión de riesgos y la propia estrategia.Pero si tienes muchos desafíos en tu mesa, inventar tu propia metodología obscura no parece ser la mejor decisión. Introducción al enfoque “MoSCoW” Algunas normas están estrictamente codificadas en los RFC de las mejores prácticas internacionales de organismos como el IETF o el IEEE, mientras que otras se han convertido en normas en su propio derecho.La que me gustaría introducir cae en la segunda categoría.La metodología MoSCoW no es el único enfoque para la priorización de tareas, sino uno de los métodos más eficientes y universales para comenzar a hacer las cosas bien. El enfoque fue propuesto por Dai Clegg en el libro “ El nombre “MoSCoW” no tiene conexión con la capital norteña y fue creado como un acrónimo de categorías de priorización: Los ojos tienen, Tiene que tener, El Ulla tiene, Estas categorías pueden estar asociadas con prioridades numéricas 1-2-3-4 y ayudar a determinar de forma inequívoca la secuencia de tareas o elementos en la iteración del desarrollo del producto. El objetivo claro de cada categoría hace que este método sea una joya, y durante este artículo, me gustaría cubrir cada prioridad con ejemplos en el desarrollo ágil. Método de caso Fast-Track: un enfoque RAD M S Co W En primer lugar, es necesario establecer un escenario de ejemplo para el uso del enfoque. Supongamos que somos miembros de un equipo de producto que está desarrollando un producto B2B. En este producto, nuestros clientes pueden almacenar y intercambiar archivos para sus proyectos. Para mantenerlo sencillo, nuestro equipo añadirá algunas características básicas, como “Invitación de Usuario” - la funcionalidad de agregar a un nuevo participante a un proyecto. Nos prometimos a nuestros clientes que implementaríamos esta característica a una fecha determinada; tenemos un compromiso. Ahora, el equipo tiene que planificar la próxima iteración para lanzar la nueva versión del producto antes del plazo para mantener la reputación de la empresa. En este ejemplo, no segmentaremos a los miembros del equipo por especialidad (Dev, DevOps, QA), y imaginaremos a nuestro equipo como un equipo Scrum universal canónico. El escenario de invitación de usuario ha preparado requisitos técnicos, UX/UI. La función ya se había descompuesto en elementos significativos que tienen sentido, y todos estos elementos fueron estimados. Es hora de usar un enfoque de priorización, y sin más preocupación, vamos a categorizar estos elementos. Hay que tenerlo - 1 La prioridad de Must Have “1” se utiliza para tareas, características, elementos de backlog de productos, historias de usuarios o errores que deben incluirse en la próxima iteración de desarrollo. Por ejemplo, durante la planificación nos dimos cuenta de que algunas tareas deben desarrollarse a través de acuerdos con clientes o son críticas para el negocio por alguna otra razón. La idea principal es que estos elementos son cruciales y no negociables. El equipo tiene que estimarlos, asumir riesgos y planearlos. Si la estimación es más que el tiempo disponible, los artículos deben descomponerse hasta que se pueda crear el Producto de Valor Mínimo (MVP) durante la iteración. Basándose en el ejemplo de una nueva característica del producto, supongamos que queremos implementar una característica de “invitar a un nuevo usuario a un proyecto”.La categoría “Must Have” refleja tareas MVP y crea funcionalidad básica.El resultado de la iteración debe proporcionar un escenario significativo y tareas adecuadas para la prioridad “1”: Implement the <Invite user> button in the project users list. Develop basic functions of the “Invite user” pop-up. Send a notification to the new user with authentication instructions. Debería haber - 2 La segunda categoría está cerca del “Must Have”.Pero es algo que podríamos aplazar o entregar más tarde. Si tenemos un acuerdo con el cliente sobre las invitaciones de usuario, las funciones MVP se liberarán como opciones obligatorias en la prioridad “1”. Sin embargo, siempre hay muchas mejoras que son necesarias para implementar, pero pueden omitirse en el alcance declarado. Durante la fase de desarrollo, el equipo podría enfrentarse a algunos riesgos con las tareas “Must Have”, y las funciones de segunda prioridad deben posponerse porque no forman parte del MVP. Por ejemplo, en la función “Invitación de Usuario”, el producto debe ayudar a incorporar a nuevos usuarios. En la prioridad “Debería tener”, el equipo desarrollará el escenario crítico de creación e invitación. Pero también es importante enviar feedback al administrador invitante que un nuevo usuario se haya conectado con éxito. Es posible utilizar la función sin este feedback, pero con esta notificación, el producto definitivamente es mejor y el administrador sabrá que todo está bien. Así se establece la segunda prioridad - estamos mejorando el proceso principal, algo importante para el negocio, teniendo en cuenta solo que esta característica es adicional. Un error de producto "Debería tener" es algo que rompe el escenario, pero hay algún problema razonable, disponible para un usuario ordinario y no técnico.Es mejor siempre corregir estos errores durante la iteración, pero podrían ser negociados cerca del plazo, porque todavía es posible liberarlos con ellos. Puede ser - 3 Esta categoría se trata de mejoras o defectos visuales menores que hacen una diferencia en general y podrían mejorar la sensación general del producto, pero no son críticos en este momento o profundamente opcionales para el escenario. Sería bueno desarrollar estas cosas, solo si se mitigan los riesgos de las prioridades "Debería tener" o "Debería tener". Durante la planificación, el equipo del producto debe pensar en los elementos "Puede tener" como este: la primera prioridad debe hacerse. Debemos aplicar el máximo esfuerzo para entregar la segunda prioridad. Si todo va bien, esperamos desarrollar los terceros elementos prioritarios, pero si hemos fracasado, no debería afectar al negocio. En el caso de la función "invitación de usuario", la tercera prioridad es algunas mejoras adicionales en el formulario de invitación de usuario. Como tercera característica de prioridad, el administrador podría configurar notificaciones automáticas si un usuario no se ha conectado durante los próximos tres días. El administrador del proyecto podría enviar este recordatorio manualmente si notan la ausencia de una segunda notificación de prioridad, pero sería un buen toque implementar recordatorios automáticos inicialmente. Sin esta mejora, el producto funciona bien y cumple con los términos del contrato, lo que lo hace "Puede tener". Una prioridad "Puede tener" como un bug de producto es algo acerca de características raras o errores visuales que se reproducen en algunos entornos inusuales. Estos errores podrían ser corregidos si no tenemos errores no completados o errores de producto de otras categorías. Los errores de tercera prioridad podrían ser trasladados a la próxima iteración sin largas negociaciones, porque no están bloqueando el lanzamiento del producto. Por ejemplo, la mayoría de nuestra base de clientes utiliza navegadores web en un motor específico y tenemos un defecto insignificante en un motor no popular. Sería genial corregir este error, pero si todo el mundo está ocupado con tareas más importantes, no hay problema de tener este problema en el lanzamiento. No se puede - 4 Una categoría útil que muestra los elementos que definitivamente no se liberarán durante la iteración. Sin embargo, es importante tenerlos si queda alguna capacidad. El equipo de producto podría planificar las tareas de iteración y segmento y los errores como primera, segunda y tercera prioridad. Y sucede que las tareas son más fáciles de lo planeado. Los desarrolladores tendrán tiempo adicional que podría usarse para la cuarta prioridad. Estos elementos siempre se desarrollan en ramas y nunca están destinados a fusionarse en la iteración actual, pero esto hace que las cosas sean más fáciles para la próxima iteración. ¿Qué tipo de tareas son adecuadas como un backlog "no tienen"? En primer lugar, hay tareas de deuda técnica. Las más importantes podrían ser la prioridad "Debería tener" o "Debería tener", pero las mejoras regulares de código para el mantenimiento de la base de código son un gran ejemplo de la cuarta prioridad. Los desarrolladores tienen la oportunidad de mejorar el código después de las tareas cruciales para el negocio y usar estas mejoras en las próximas iteraciones. Si algunos cambios están rompiendo y requieren una ejecución de QA no típica, hacer mejoras antes de nuevas iteraciones también proporciona una oportunidad para el cuidado oportuno. También, es útil agregar como la prioridad “No tener” algunos elementos que van a ser la primera prioridad “Deberá tener” en la próxima iteración. Sabemos que después de la invitación de usuario básica, debemos integrar configuraciones de permiso de usuario detalladas en este escenario, para simplificar el flujo del administrador. Esta característica será el MVP de la próxima iteración. Si tenemos alguna capacidad, es bueno comenzar a desarrollarlo como cuarta prioridad; que disminuirá los riesgos en el futuro. Durante la planificación de la próxima iteración, la prioridad de este elemento será actualizada a la “Deberá tener”. Es mejor no tener errores de producto de la cuarta prioridad, porque esta categoría muestra que el error no será corregido durante la iteración y sólo creará un desorden adicional en el panel de retroceso. Sin embargo, la prioridad podría usarse para los errores que requieren cambios arquitectónicos que son peligrosos para la iteración actual y su prueba debe ser planificada en la siguiente. Utilizar el enfoque prioritario En el comienzo de este artículo he hecho un ejemplo del enfoque de prioridad personalizado con cuatro categorías, que nadie comprendió y el equipo tiene que introducir la quinta prioridad para las tareas más importantes. Estas reglas también sirven como un punto de referencia para el equipo y ayudan a mostrar los problemas en el enfoque de planificación del equipo. Por ejemplo, si el equipo no puede desarrollar todos los elementos planificados de la primera prioridad “Debería tener”, por no hablar de otras prioridades, muestra profundos problemas en el proceso: Los requisitos de características no eran tan buenos y claros. Hubo un error en la descomposición. El equipo de alguna manera subestimó la complejidad de las tareas. Alguien decidió cambiar la idea durante la iteración. El equipo tiene que proporcionar retrospectiva y averiguar la fuente del problema y encontrar la solución para corregir el proceso de desarrollo roto. Al mismo tiempo, la realización estable de la tercera y cuarta prioridades tampoco es tan buena. Significa que somos buenos en la estimación y la gestión de riesgos, pero también demuestra que el equipo está bastante relajado o subcargado. Tal vez podríamos planificar artículos adicionales de las prioridades “Debería tener” o “Debería tener”. Los inconvenientes del enfoque En el ejemplo anterior, las tareas se clasificaron por prioridad para una iteración particular, pero eso no significa prioridad global según el negocio de la empresa. Las tareas que están etiquetadas como "Puede tener" en la iteración actual podrían convertirse en "Debe tener" en la siguiente, y estos cambios requieren tiempo adicional durante cada sesión de planificación para el gerente de iteración. Además, el enfoque todavía tiene un problema con la secuencia de tareas en una categoría. Si la iteración tiene pocos elementos “Must Have”, ¿cuál de ellos debe desarrollarse primero? Esta secuencia todavía debe ser discutida a través de la planificación de la iteración y coordinada a través de software específico. No hay bala de plata para todo el proceso de desarrollo, pero el uso de enfoques como MoSCoW ayuda a racionalizar los procesos básicos. Conclusión Hay muchos métodos y enfoques para la priorización. Sin embargo, creo que el enfoque MoSCoW es uno de los más fáciles de empezar con mejoras generales al proceso de desarrollo de software. Este enfoque es más adecuado para los productos del mercado B2B y el desarrollo de productos con tareas y visión claramente formuladas. Es necesario tener un plan para sucesivas iteraciones para utilizar este enfoque correctamente. En un entorno caótico y de rápido cambio, este enfoque puede fallar y crear tantas tareas de alta prioridad, lo que afectará a la predictibilidad del lanzamiento. El mismo problema puede aparecer sin procesos de planificación y estimación adecuados. Pero sin embargo, usar este enfoque ayudará a identificar todos estos problemas lo antes posible y lanzar una iniciativa para simplificar y hacer que el desarrollo del producto funcione bien.
