agile, Stakeholders, teams, Training

Roles y estructuras que funcionan • Guía para la gestión de proyectos para niñas


La administración de proyectos Agile es una forma de administrar el trabajo que brinda beneficios iterativos e incrementales.

Es diferente a la administración de proyectos predictivos, donde sabe lo que está creando y está planeando cómo llegar allí, porque cuando trabaja con Agile Métodos, te adaptas a medida que avanzas. No siempre está seguro del destino, y es por eso que los métodos Agile como Scrum, Scrumban y Kanban son excelentes para entregar proyectos con gran incertidumbre o donde la especificación exacta del producto todavía se está elaborando a medida que avanza.

Los métodos Agile necesitan Equipos ágiles: equipos que piensan de manera diferente y trabajan de manera que apoyen la entrega receptiva. Una mentalidad ágil y un conjunto de valores compartidos, principios y herramientas a menudo ágiles ayudan a los equipos ágiles a tener éxito.

¿Entonces por qué son diferentes? En este artículo veremos qué conforma un equipo Agile y los roles que encontrará dentro de él, junto con las estructuras de equipo que puede configurar para ayudar a que su equipo Agile sea un éxito.

¿Qué es un equipo Agile? ?

Un equipo Agile es un grupo multifuncional de personas que es autónomo hasta el punto de que las personas del grupo pueden entregar el producto (o la siguiente iteración del mismo) sin necesidad de recurrir a habilidades fuera del grupo

Es casi más fácil pensar en equipos ágiles en virtud de lo que no son. Los equipos ágiles no son simplemente un equipo de proyecto formado por diferentes personas de diferentes áreas del negocio.

Los equipos ágiles no son recursos de desarrollador únicamente. Tampoco son un equipo matricial.

Los equipos ágiles son grupos dedicados de personas que (si quieres que hagan su mejor trabajo) no se mueven entre productos o equipos solo porque existe una demanda en un área diferente del Negocio esta semana. Por lo tanto, se convierten en un grupo de colegas muy unidos y de confianza, que encuentran un ritmo de trabajo para las entregas.

Son un "equipo completo". No necesitan a nadie ni a nada más para hacer las cosas. Esto es particularmente importante cuando se trata de la toma de decisiones. Las personas que necesitan tomar las decisiones son parte del equipo. Agile trabaja para los proyectos de hoy.

Agile Team Roles

Como un equipo de desarrollo Agile tiene que ser "todo", es importante tener los roles correctos en el grupo. Los roles de equipo Agile más comunes son:

Líder del equipo. Si está utilizando el método ágil Scrum, este rol será Scrum Master. El punto de la función es facilitar el equipo. El Scrum Master (o líder del equipo) es responsable de encontrar recursos para el equipo y garantizar que los miembros del equipo estén protegidos de la política de la oficina y demás, permitiéndoles seguir adelante y hacer un gran trabajo. Agile Alliance define el rol de esta manera:

El scrum master es el rol del equipo responsable de garantizar que el equipo tenga valores y principios ágiles y siga los procesos y prácticas que el equipo acordó que usarían.

Propietario del producto. Considero que este rol está más alineado con un patrocinador de proyecto en un proyecto no ágil. Son la persona que representa los intereses del cliente / parte interesada, literalmente, la persona que posee el producto que el equipo ágil está cambiando o creando.

Miembro del equipo. En un proyecto de desarrollo ágil, este rol normalmente sería alguien en un rol de desarrollo de software o programación. Sin embargo, como Agile se separa de TI, podría significar que cualquier persona que tenga algo valioso que aportar al equipo que ayude a completar los entregables

Tester. Como el trabajo de Agile todavía se lleva a cabo en el dominio de TI, las pruebas de software siguen siendo una parte importante de los equipos de Agile. Incluso en equipos que no son de software, es posible que desee a alguien que pueda actuar como probador. A medida que los proyectos Agile se entregan de manera incremental, las pruebas son realmente importantes. Debe hacer una prueba de regresión de lo que ya ha entregado para garantizar que su última iteración no rompa algo por error, por ejemplo. ¡Es un rol muy responsable!

En equipos más grandes o productos especializados, también puede tener:

  • Expertos en la materia en áreas técnicas o de dominio. Puede que no estén con el equipo todo el tiempo. En su lugar, pueden pasar según sea necesario para apoyar al arquitecto central
  • Arquitecto. La función del arquitecto de sistemas es garantizar que la solución sea adecuada para su propósito y que se ajuste al resto de la arquitectura empresarial.

Y al contrario de lo que podría haber escuchado, puede tener a alguien en un rol de gestión de proyectos en un equipo ágil .

Agile Team Structures

Aquí hay 5 estructuras de equipo ágil que podrías usar al armar tus propios equipos.

1. Equipo Agilista General

Como era de esperar del nombre, en un equipo Agile generalista, cualquiera puede realizar cualquier tarea en cualquier momento.

Esta estructura de equipo funciona de manera más efectiva en un proyecto bien entendido y con personas que son buenos en diversos roles.

Sin embargo, tienes que encontrar a las personas adecuadas para hacer que esto funcione: personas dedicadas y apasionadas que pueden ayudar a cualquier cosa. Además, necesita un proyecto que pueda hacer frente sin una experiencia muy específica en la materia. No todos los integrantes del equipo pueden ser expertos en impuestos o analistas especializados en protección de datos.

Si su equipo ágil es pequeño, el proyecto no requiere demasiada experiencia especializada en ningún dominio (que usted no necesita). tener en el equipo) y tienes personas apasionadas, entonces este puede ser un gran equipo motivado y motivado.

Prueba esta estructura de equipo en equipos pequeños ya que es difícil de escalar.

2. Specialist Agile Team

En un equipo de especialistas, todos los miembros del equipo tienen un conjunto de habilidades diferente. Esto le brinda software, pruebas y análisis de datos de alta calidad, porque las personas que realizan esas funciones tienen experiencia en esas áreas.

Sin embargo, puede que le resulte difícil trabajar con esta estructura porque no hay previsibilidad. A menudo terminas con recursos esperando para su próxima tarea.

Catherine Powell, directora de Abakas, una empresa con sede en Boston, que habló en la conferencia de desarrollo de software Øredev en Suecia, dijo que los equipos de especialistas no alcanzan su objetivo de Sprint en el 70% de sprints. "Si puede evitar este nivel de especialidad, evítelo", aconsejó.

Los equipos de especialistas trabajan más eficazmente con equipos de mayor tamaño, más hacia las 20 personas que terminan en el espectro en lugar de 5 o 6 personas.

puede minimizar el tiempo de inactividad para los miembros del equipo entrenándolos en forma cruzada. Entonces, con suerte, puede suavizar sus tiempos menos ocupados y pueden ayudar a que el proyecto siga avanzando.

3. Transición del equipo ágil

Todos tienen que comenzar en algún lugar. Cuando un equipo está haciendo la transición a un método ágil como Scrum, puede configurar su equipo para que apoye esa transición.

Moverse a cualquier nueva forma de trabajar es una curva de aprendizaje. Tienes que ayudar al equipo a adoptar nuevas formas de trabajar.

Puedes administrar la carga de trabajo de un equipo de transición, por ejemplo, ejecutando sprints por disciplina. Así que tu prueba se convierte en un sprint. No es Agile puro, pero es una forma de ayudar a los equipos más acostumbrados a las metodologías de cascada / predicción a familiarizarse con el lenguaje, las prácticas y las ceremonias de Agile.

Sin embargo, a largo plazo, toda esta estructura y este enfoque se aplican a los sprints. extender los plazos de entrega.

4. Equipo paralelo de Agile

En este equipo, todos cambian de trabajo por carrera. Todos escriben código, luego todos se mueven para probarlo. Esta configuración es buena para el entrenamiento cruzado, pero tiene ciclos de lanzamiento de carrera cruzada.

Si suena difícil de manejar, entonces es porque puede ser! Hay formas más fáciles de configurar su equipo, pero si tiene razones para hacerlo de esta manera (por ejemplo, su equipo Agile experimentado necesita un nuevo desafío, o si hay una razón en particular para trabajar con un cliente de esta manera). Todos los medios le dan una oportunidad.

5. Subgrupo de productos ágiles

En una organización grande, bien puede encontrar esta estructura de equipos ágiles. Es donde el equipo Agile es en realidad una unidad autónoma de un equipo más grande. Su equipo tendrá la responsabilidad de un área específica de trabajo, pero el producto en general se compone de varias subáreas. Todos los equipos ágiles trabajan juntos, cada uno en un área en particular, para contribuir con una visión más amplia.

También encontrará que el trabajo se entrega entre los equipos a lo largo del tiempo. Su equipo termina algo y ese producto (o subproducto) pasa al siguiente equipo. Esto funciona bien cuando se usa un método como Scrum en toda la organización. Por ejemplo, el producto está diseñado por un equipo y se lo entrega a otro equipo para que realice la implementación y la instalación.

Este es un modelo de equipo a nivel organizativo y, por lo tanto, funcionaría de manera eficaz en las empresas acostumbradas a hacer las cosas de manera ágil. 19659002] Sin embargo, también puede funcionar cuando el equipo Agile es un sub-equipo de un equipo de proyecto no tan ágil. He sabido que los programas predictivos se están ejecutando con subgrupos de Agile que realizan el desarrollo de software, mientras que la estructura general del programa se administró con una metodología de cascada. ¡Parece desordenado, pero funcionó!

Reto # 1 de Agile Project Management: No se siente bien

Si no sientes que tu equipo Agile realmente está trabajando de la mejor manera posible, es posible que tu El equipo del proyecto Agile no encaja en una de esas 5 estructuras. Y eso podría estar perfectamente bien. Sin embargo, para ver el beneficio de ser ágil, definitivamente es útil contar con equipos de proyectos que se autogestionen y que tengan muchas de las características que he descrito anteriormente.

Cuantas menos dependencias externas tienen los miembros del equipo en el resto de el negocio (u otros equipos) es más fácil para ellos operar independientemente y hacer su trabajo de la manera más ágil que saben.

La falta de cultura ágil es la razón principal por la que los equipos ágiles no se sienten tan ágiles. Si su metodología ágil no parece estar funcionando, quizás sea hora de echar un vistazo a la estructura de su equipo.

Desafío de gestión de proyectos ágil n.º 2: tamaño del equipo

El segundo desafío podría ser que su equipo ágil es del tamaño incorrecto.

Cuando tu equipo crece demasiado (es decir, más de 20), es útil dividir al equipo y tener varios equipos trabajando. Deberá dividir los entregables para que cada equipo tenga algo discreto para trabajar. Esto se logra fácilmente con las historias de usuario y la preparación del trabajo acumulado.

Una de las responsabilidades de los líderes del equipo es coordinar con otros líderes del equipo, asegurándose de que todo el producto esté unido.

Su estructura de equipo ágil

En última instancia , como líder de un equipo Agile o Scrum Master, depende de usted establecer la estructura para su equipo Agile que funcione mejor. Todas las estructuras y roles anteriores son generales, y ágil es un enfoque adaptativo. Así que adaptarlo. Haga que funcione para su organización y su proyecto.

Escuche al equipo, lo que necesitan y cómo puede entregarlo. Aproveche su experiencia. Y sigue cambiando las cosas hasta que encuentres una manera de hacer que tu equipo ágil trabaje para todos en él.

Pin para leer más tarde:

 Estructuras del equipo Agile



Source link

You Might Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>