¿Cuáles son las mejores prácticas para la gestión de productos Agile / SCRUM?

Scrum como metodología es simple y sus métodos son repetibles, pero su práctica disciplinada y diaria no es necesariamente tan fácil. Uno de nuestros objetivos principales aquí en el Camino Escalable (una red de más de 4000 desarrolladores y diseñadores independientes) es usar Scrum como una metodología verdaderamente relevante para conducir proyectos hasta su finalización y para satisfacer a los clientes.

Antes de sumergirse en las mejores prácticas de Scrum, es útil recordar por qué se utiliza Scrum. Scrum facilita la comunicación creando bucles de retroalimentación. Queremos que los desarrolladores se mantengan sincronizados entre sí y queremos que el cliente se mantenga en contacto con el equipo de desarrollo. También queremos crear ciclos de desarrollo en los que el cliente pueda ver resultados tangibles y dar su opinión con anticipación. No hay nada como trabajar en una fecha límite durante meses solo para descubrir que el cliente estaba anticipando un resultado diferente. Los métodos de Scrum están diseñados para ayudar a eliminar las brechas en la comprensión del equipo de desarrollo de lo que quiere un cliente.

veamos algunos consejos específicos que lo ayudarán a usted y a su equipo a utilizar eficazmente los métodos Scrum con éxito:

1. ACLARAR, ACLARAR, ACLARAR

Estás en una reunión y la conversación va y viene. Todos los demás dicen “Genial, tiene sentido para mí”. El problema es que no tiene sentido para ti, pero no quieres ser “ese tipo”, ¿verdad? Bueno, no te avergüences y no te dejes engañar pensando que tiene sentido para todos los demás. La claridad es el trabajo de todos y obtener claridad más tarde suele ser más costoso. Una vez que tenga claridad, documente la decisión .

2. UTILICE LAS HERRAMIENTAS CORRECTAS

Todos tienen su bolsa de trucos, sus herramientas de referencia. A muchos de nuestro equipo les gusta la combinación de JIRA Agile combinada con Stash, pero hay muchas otras herramientas excelentes que lo ayudarán a hacer lo mismo. Si es posible, encuentre algo que le permita visualizar el estado de un sprint como un tablero Kanban. Las herramientas para las revisiones de código también son muy importantes. Si es demasiado difícil de hacer, no sucederá. El software adecuado no tiene que costar una fortuna, pero puede marcar una gran diferencia en el éxito de un proyecto.

yo. Use JIRA, Podio y alternativas para la revisión de código

ii) Usa Git para el desarrollo y la colaboración remota

iii) Utilice Slack para la comunicación y las integraciones (la integración de JIRA con Slack ha facilitado todas nuestras vidas)

iv. Use GoToMeeting / Google Hangouts, aparezca. En para la comunicación remota

3. ESCRIBE BUENAS HISTORIAS

No asuma que todos recordarán cada objetivo y fijarán cada característica discutida en una reunión. Después de hablar sobre una función, es fácil alejarse y olvidar los detalles sobre la decisión que se tomó. Puede parecer obvio, pero generalmente no se hace bien. Esto vuelve al consejo # 1 , la falta de claridad es uno de los mayores problemas que puede tener. Así que escribe buenas historias y mantenlas actualizadas.

4. TIMEBOX TUS SPRINTS

Cuando decides la duración de un sprint para tu equipo, es mejor cumplir con la duración acordada (1 a 4 semanas como máximo). No solo estire la longitud de todas formas. Si son dos semanas, no extiendas el sprint a tres semanas porque una determinada característica necesita salir. El sprint es tu cadencia, tu sección de ritmo. Ayuda a mantener el impulso. Un sprint también conlleva cierto grado de carga mental. Ahora, si estás empezando a tartamudear porque crees que me estoy perdiendo un punto muy importante sobre lanzamientos y plazos, quédate conmigo, ahí es donde entra mi próximo consejo.

5. DESACUPAR LA IDEA DE UN SPRINT Y UNA LIBERACIÓN

¿Es un sprint lo mismo que un lanzamiento? Es fácil pensar en ellos como lo mismo, pero ¿con qué frecuencia liberas un hotfix a mitad del sprint? ¿O qué pasa con la implementación continua? Ciertamente puede desplegar más de una vez en un sprint. Realmente se reduce al control de calidad, y si planea hacer lanzamientos rápidos, probablemente necesitará invertir en la automatización de su prueba.

6. BEBE EL KOOL-AID

Escribir software es un desafío. Es especialmente difícil cuando los desarrolladores y las partes interesadas de la compañía tienen ideas completamente diferentes sobre cómo debería hacerse. Scrum es una herramienta que funciona mejor cuando todos aceptan comprar el proceso y beben el Kool-aid juntos. Una forma que puede ser útil para obtener la aceptación es que las personas en varios puestos de la empresa tomen la capacitación Scrum. Puede parecer un gasto costoso, pero en realidad es bastante razonable y más rentable que crear software que nadie quiere.

Incluso con las mejores metodologías, las mejores herramientas y las mejores personas, su éxito como profesional de Scrum no es una garantía. Las personas correctas y la idea correcta no siempre y automáticamente se traducen en éxito. Crear productos exitosos es una combinación de gran talento, cultura correcta y líneas claras de comunicación. A menudo es más arte que ciencia. Las personas a menudo tratarán de cambiar la metodología porque no está funcionando, pero a veces el problema es mayor con el negocio y sus procesos. Esos procesos pueden ser rotos y disfuncionales. Ha habido casos en los que el CEO no quería que los desarrolladores tuvieran mucho que decir sobre las cosas que perjudicaban su trabajo y, como resultado, creaba estrés y productos de calidad inferior. Dejó al equipo profundamente frustrado con un mal gusto, una mala experiencia y, en última instancia, un producto fallido.

Al comprometerse y configurar su próximo proyecto de desarrollo, asegúrese de haber abordado los problemas que podrían afectar ese proyecto desde una perspectiva comercial. Arregle sus procesos comerciales para permitir que Scrum funcione. El éxito es un régimen compartido y un sistema de valores.

En Scrum Product Management, debe centrarse en las funciones principales de ser el propietario del producto:

  • Descubra y grabe historias para la cartera de pedidos.
  • Priorice las historias en la cartera de productos, la cartera de publicaciones y la cartera de iteraciones.
  • Determinar fechas de lanzamiento y fechas de iteración.
  • Desarrolla detalles de la historia y ayuda al equipo a comprender esos detalles.
  • Ayuda QA para desarrollar pruebas de aceptación.
  • Interactúe con el Cliente para asegurarse de que el producto satisfaga las necesidades del cliente.

Como seguimiento, también recomendaría leer el ‘Manifiesto para el desarrollo ágil de software’. Esto proporcionará una buena base para el desarrollo de software ágil.

http://www.agilemanifesto.org/

También es posible que desee leer ‘Mejores prácticas para SCRUM’ de Mike Cohn del software Mountain Goat:

http: //www.mountaingoatsoftware… .

Mike ha sido un participante activo en proyectos Scrum desde 1995 y tiene una tonelada de fantásticos recursos ágiles en su sitio web.

El núcleo de Agile son las pequeñas iteraciones, el trabajo constante para revisar y validar su trabajo y mejorar sus procesos en cada punto de control.

Esto se aplica muy fácilmente a la gestión de productos, especialmente en su configuración específica de gestión y mejora de la acumulación de productos.

1. Trabaje en iteraciones pequeñas: identifique las historias actuales de alta prioridad en su cartera de pedidos, elabúrelas y luego identifique el próximo conjunto de historias de alta prioridad.

2. Revise y valide: cada dos semanas más o menos, mire su priorización y revísela con clientes REALES. Asegúrese de estar escuchando lo que NO están diciendo, y use tanto el contenido hablado como el no hablado para revisar las prioridades en la cartera de pedidos que ya tiene. Si algo que no fue elaborado se mueve hacia arriba, elabórelo más completamente.

3. Mejore su proceso: cada dos semanas (o sea cual sea su plan de iteración), pregúntese a usted mismo y a sus equipos: “¿Qué es lo que estamos haciendo bien?”, “¿Qué es lo que podemos mejorar” y “Qué debería dejamos de hacerlo AHORA MISMO, lo que está causando problemas “.

La aplicación de los principios generales de Agile a las prácticas de gestión de productos no es tan desalentador como muchas personas … de hecho, es una necesidad si el equipo de desarrollo con el que está trabajando está utilizando las prácticas Agile / SCRUM.