Transcripciones
1. Cómo formar el equipo ágil de la introducción de un equipo ágil: Hola, soy Teresa Bennett, y esta es la segunda parte de la serie de formación de cursos Agile para analistas de negocios. Y esta parte de la serie, vamos a mirar a formar el equipo Agile. Son cuatro los temas que cubriremos en este entrenamiento. El primero son las unidades del equipo. Vamos a hablar de la unidad de negocio y de la unidad de desarrollo, y qué áreas de la organización caen en cada una de esas unidades. Cuando estamos hablando de nuestro equipo y juntando a la gente que va a ser parte de ese equipo Agile. Entonces vamos a ver los roles de los miembros del equipo y ver qué roles son desempeñados por la gente en esas dos unidades. Después pasaremos a las mejores prácticas para el equipo. ¿ Qué es lo que necesitamos hacer consistentemente para asegurar que nuestro equipo tenga éxito? Por cada sprint y cada proyecto que completamos. Después hablaremos de tu equipo, tu rol en tu equipo Agile, y qué cambios de mentalidad podrías necesitar para hacer un pedido para tener éxito en un equipo Agile. Y qué significa flexibilidad para ti cuando estás trabajando en un entorno ágil. Entonces únete a mí en el siguiente video y empecemos.
2. Unidades del equipo ágil: Dos unidades forman el equipo Agile. En primer lugar, tenemos la unidad frente al cliente, que también se puede pensar como la unidad de negocio. Las personas que forman ese equipo son, primer lugar, el cliente, que es el patrocinador del proyecto. También tienes el equipo de marketing, que es el equipo de marketing de tu empresa o la empresa para la que está el producto. Si su empresa es una firma de consultoría y ha sido traída para asistir en un proyecto en otra organización de lo que sería el equipo de marketing de esa organización. El gerente de producto es la persona que gestiona las operaciones del producto. Y también forman parte de la unidad orientada al cliente. Y entonces por supuesto tenemos a los ejecutivos que yo consideraría
como cualquiera a nivel de director o superior. También tenemos el CMMI, que son expertos en materia. Esas son las personas que trabajan con AND OR apoyan el producto. Entonces son los que realmente están trabajando con él día tras día y realmente conocen todas las tuercas y pernos del producto. Entonces, ¿pueden contestar tus preguntas sobre cómo haces esto? ¿ Qué pasa si un cliente lo pide? ¿ Cómo atraviesan este proceso? Deberían poder responder a ese tipo de preguntas. También contamos con grupos de interés como parte de la unidad orientada al cliente. Esas son personas o grupos que tienen algo que
ganar o perder con el resultado de tu proyecto. El motivo por el que estoy mencionando algo que perder aquí es
pensarlo en términos de cuando estás haciendo una actualización a un proceso, veces
hay cosas que se eliminan del proceso ya que estamos haciendo las cosas más eficientes. Y eso puede dar pasos que un grupo particular de personas estaba haciendo o sacar un proceso en conjunto que están haciendo grupo. Por lo que un titular de una participación que está perdiendo algo podría ser un grupo que ya no va a tener realizar una función porque los cambios que
se están haciendo están haciendo las cosas más eficientes y esa función ya no es necesaria. Y entonces por supuesto, podría haber otras personas involucradas dependiendo de cuál sea el proyecto. Por lo que podría necesitar considerar a los reps de servicio al cliente, personal de
ventas, tal vez recepcionistas. Si, por ejemplo, el software es tal vez un sistema de reservas hoteleras. Por lo que tendría trabajadores de recepción, cualquiera de ese tipo de personas que podría tener
que pensar que podría incluirse ya sea suave u otro grupo de personas que pudiera necesitar involucrarse en el proyecto y luego otros gestores de productos y partes interesadas. Entonces, ¿quién más podría estar involucrado además de los stakeholders que ya has pensado? ¿ Hay otras personas que puedan verse afectadas? Ahora echemos un vistazo a quién está incluido en la unidad de desarrollo. Tenemos, por supuesto a los desarrolladores, ¿verdad? Esas son las personas que están codificando. Están desarrollando la aplicación. Están haciendo cambios en el software real, el analista de negocios. Por lo que esta es la persona que
detalla las historias durante las sesiones de aseo con la unidad de negocio. Entonces si eres el analista de negocios, entonces. Aquí es donde la mayor parte de su trabajo se va a hacer en el equipo Agile. Qa también está involucrada en la unidad de desarrollo. Por lo que el equipo de control de calidad son las personas que están haciendo pruebas de software, pruebas de
procedimientos, pruebas de flujo de procesos, cualquier otra cosa
que no sean las pruebas unitarias, que normalmente lo hacen los desarrolladores porque están probando sus propios código antes de que lo estén volteando. Por lo que las pruebas unitarias no están incluidas en QA, eso es parte de la función del desarrollador. Pero cualquier otra prueba que esté sucediendo se
incluye típicamente en la barbilla de comida de QA y luego en el gerente del proyecto. El encargado del proyecto puede estar separado del Scrum Master. O el encargado del proyecto también puede ser discriminante. O he visto esto de ambas maneras en diferentes organizaciones en las que he trabajado. Por lo que solo depende de cómo se configure su organización y cómo
estén definiendo roles y responsabilidades dentro de su organización. Por lo que puede tener un rol combinado donde el gerente del proyecto y el maestro scrum o la misma persona, o fueron ellos son roles separados realizados por dos individuos diferentes. A continuación, tenemos a los escritores técnicos y o formación de escritores manuales. Se encargan de crear documentación técnica y documentación de capacitación. La documentación de capacitación podrá ser realizada por la unidad cliente. Por lo que se puede asignar a alguien de la unidad de negocio para que haga la redacción del manual de capacitación. De nuevo, solo depende de cómo se configure
la organización en la empresa en la que estás trabajando. Por lo que he trabajado en organizaciones donde no han tenido un escritor de manual de capacitación dedicado. Por lo que el equipo técnico que hizo la redacción técnica también creó los materiales de capacitación. Y también he trabajado en organizaciones donde la unidad de negocio, derecha, la unidad frente al cliente tenía un equipo de capacitación y es alguien para escribir los materiales de capacitación. Por lo que sólo depende de cómo estén configurados. Si sí tienen una persona para crear los materiales de capacitación como parte de la unidad orientada al cliente, entonces serían incluidos en esa área en lugar de en la unidad de desarrollo. Entonces tenemos a nuestra UX y diseñamos gente creativa. Por lo que son las personas que están definiendo el aspecto y la sensación de la aplicación y la experiencia del usuario. Entonces tenemos a las personas de arquitectura que también están incluidas en la unidad de desarrollo porque estamos hablando de arquitectura de sistemas, arquitectura de bases de datos. Se trata más de la arquitectura técnica que de cualquier cosa que esté relacionada con los negocios. Y entonces tenemos otro tipo de otra categoría, ¿no? Por lo que cualquier otro personal de TI o I S que sea necesario para el éxito del proyecto. Y de nuevo, eso depende de cómo se configure su organización y para qué sirve ese proyecto en particular en cuanto a qué otras unidades podrían estar involucradas en ese proyecto en particular.
3. Papel de equipo: A continuación, echemos un vistazo a los roles de equipo. Entonces vamos a hablar de quién es el responsable qué en ambas unidades de las que acabamos de hablar, la unidad orientada al cliente y la unidad de desarrollo. Cada una de esas personas tiene ciertas responsabilidades dentro del equipo. Por lo que para la unidad frente al cliente, son los responsables de la visión del producto y la hoja de ruta. También son responsables de gestionar el Retraso de Productos, que es el alcance, pero piénsalo como el alcance del proyecto. ¿ Qué estamos haciendo por este proyecto? Se espera que estén preparados con detalles en el momento adecuado. Entonces en cualquier momento que el equipo del proyecto necesite detalles específicos
relacionados con cualquier cosa para las funciones empresariales del proyecto. Necesitan estar preparados para poder responder esas preguntas. Necesitan establecer expectativas claras de aceptación, lo que significa que necesitan asegurarse de que todo el equipo entienda para qué
es su expectativa cuando dirán que lo que se ha desarrollado y construido cumple con sus expectativas. Por lo que necesitan decirnos de frente cuáles
son esas expectativas para que estemos construyendo para cumplir con esas expectativas. Que la esperanza es para cuando lleguemos al punto en que les estamos devolviendo un producto. Están diciendo que sí, así es como esperaba que fuera. Y por supuesto, están muy involucrados en la comunicación en todo el equipo con no sólo definir y ayudar al equipo a entender qué es lo que quieren, sino también en comunicar cualquier cambio y su retroalimentación a lo que se está creando y construyendo para ellos. la unidad de desarrollo se le encarga estimar, lo que significa que necesitan tener un buen mango en estimar el tiempo
que les va a llevar para completar todo lo que está dentro del alcance del proyecto. Ellos son los responsables de planear y comprometerse por la iteración. Por lo que una iteración también se conoce como un sprint en el mundo Ágil. Y un Sprints son típicamente dos semanas, tal vez tres semanas. He visto a algunas organizaciones hacer sprints de cuatro semanas. No obstante, advierto en contra de esos porque empiezas a moverte a más de una mentalidad de cascada cuando te metes en un sprint que dura cuatro semanas o incluso más que eso. Entonces el mejor marco de tiempo para un sprint es de dos semanas o tres semanas, hombre. Y durante ese sprint, o lo que podría conocerse como iteración, la expectativa es que la unidad de desarrollo sea capaz de planear lo que van a hacer durante esa iteración y comprometerse con eso, luego salir de la otro extremo de la misma con esas cosas terminadas. Obviamente, van a necesitar ejecutar la iteración, ¿no? Entonces después de haber planeado y comprometido con lo que van a hacer, entonces necesitan poder ejecutar en eso y completar las tareas que hay que hacer. Y después de
eso, ahí es donde entra la demo que mencioné antes cuando hablaba de la unidad de negocio. Por lo que el equipo de desarrollo va a hacer una demo al final que para sprint para mostrar lo que se completó durante ese lapso de tiempo. Y si la comunicación ha sucedido bien, y todos han tenido el mismo entendimiento que lo que están viendo en la demo debería ser lo que esperaban ver. Y por lo tanto, deberían decir, sí, acepto esto porque se construyó de la manera que esperábamos que fuera. Y por supuesto, se espera que brinden una comunicación
clara durante cada uno de los sprints a través de la finalización del proyecto.
4. Mejores prácticas y tu equipo: Ahora hablemos de las mejores prácticas de equipo. Queremos comenzar como equipo y terminar como equipo. A lo que nos referimos con eso es cuando inicias por primera vez un proyecto para que todos estén muy entusiasmados con ello. Pólvora como sí, vamos a hacer esto donde a bordo con esto, no
queremos meternos en un ciclo donde nos entusiasman las cosas. Y luego nos metemos en una iteración y empezamos a trabajar a través de ella y surgen problemas. Y para cuando terminamos esa iteración en ese lapso de dos semanas o tres semanas. Y llegamos al final,
Todo el mundo está señalando con los dedos y diciendo, bueno, no hicimos esto porque esto no estaba claro. Y no logramos hacer esto porque esta persona no hizo esto. Queremos comenzar como equipo y terminar como equipo. Y lo que eso significa es que durante todo ese periodo de dos a tres semanas, estamos trabajando juntos, colaborando juntos. Estamos planteando temas que surgen y los estamos resolviendo juntos para que completemos ese sprint. Siempre juntos como equipo y no estamos astillando. Y que sucedan esas cosas que pueden romper esto y causar la mala voluntad durante un equipo. Por lo que la comunicación es clave ahí durante todo
el proceso para que el equipo se mantenga cohesivo y trabaje en conjunto. Y parte de eso es el número dos, que es comunicación abierta y honesta. Si te falta algo, si estás teniendo una barricada que te está impidiendo hacer algo. Tenemos que poder hablar de esas cosas y llegar a soluciones a esas cosas. El número tres se inspecciona y se adapta. Entonces lo que significa esta mejor práctica es que siempre estamos mirando lo que estamos haciendo, pensando en cómo podemos hacerlo mejor, y luego adaptándonos y haciendo esos cambios avanzando. Lo que nos lleva al número cuatro, que es la mejora incremental en producto y proceso. Para que podamos mejorar el producto, es
decir, lo que estamos entregando, siempre
tenemos que estar mejorando también nuestros procesos. Por lo que durante esa comunicación abierta y honesta y la inspección y adaptación, queremos mejorar nuestros procesos para que estemos mejorando el producto que estamos entregando a su equipo de trabajo. Entonces hablemos de tus expectativas. ¿ Qué expectativas tienes cuando estás trabajando en un equipo Agile? Qué cambios y mentalidad necesitan hacerse cuando se está pasando de una cascada a un enfoque ágil. Una de las cosas para mí, probablemente lo más grande para mí fue entender y estar bien con el hecho de que no voy a saber todo a la vez. Por lo que cuando estás trabajando con, en un entorno de cascada, estás completando todos los requisitos. Por lo que puede estar trabajando en la fase de análisis de un proyecto. Cuatro. Ciertamente por semanas a la vez, a veces meses a la vez, dependiendo de lo grande que sea el proyecto. Y para cuando llegues al final de la fase de análisis, ya
conoces ese producto dentro. Llevas tanto tiempo trabajando en ello que ahora te has convertido en un CMMI para el producto. Y con Agile, no vas a estar ahí al final de una iteración, al final de un sprint, ¿verdad? Todo lo que vas a estar realmente cómodo con y saber son los requisitos, es
decir, las historias que se completaron y trabajaron durante ese sprint. Por lo que estás construyendo tus conocimientos al mismo tiempo, el equipo de desarrollo está construyendo sus conocimientos. Y ese fue probablemente el cambio más grande que tuve que hacer en mi mentalidad fue estar acuerdo con el hecho de que no
iba a saber todo lo que iba a estar aprendiendo en el camino, junto con todos los demás. Otra cosa con la que tienes que estar cómodo es la flexibilidad. Entonces saltando donde te necesitan. Una de las cosas que realmente funciona bien en un ambiente ágil que no tenemos mucha
oportunidad de hacer en un entorno de cascada es saltar y ayudar en otras áreas. Porque en un entorno de cascada estás tan enfocado en todo se haga en un solo conjunto de tiempo. Tu terminando todos los requisitos, lo estás haciendo, toda tu documentación. Por lo que estás teniendo todas tus sesiones de requisitos. Estás creando todos tus requisitos. Estás creando todos tus flujos de proceso. Estás creando todos tus diagramas de flujo de datos, cualquier tipo de documentación que tengas que hacerlo casos de uso, sea lo que sea, estás haciendo todo el asunto. Entonces estás muy enfocado en todo eso. De qué se tiene que hacer en ese mundo. Y tienes anteojeras puestas porque tienes que hacerlo, para poder superar todo eso. No obstante, en un mundo ágil, tienes un poco más de flexibilidad porque solo
estás enfocado en cierto trozo de trabajo a la vez. Y eso te deja con la capacidad de tipo de abrir los ojos y poder ver qué está pasando a tu alrededor y en qué está enfocado el resto del equipo y escuchar qué retos están teniendo y tal vez entender como si estuvieran teniendo una barricada o un reto con esta cosa. A pesar de que eso no forma parte de mis tareas diarias, sé cómo ayudar con esto. Yo puedo ayudarlos a superar este bloqueo carretero. Y tú puedes hablar y decir, sabes qué, yo puedo ayudarte con eso. Por lo que ser flexible y tomar eso en consideración y tomar esos pasos para especie de saltar y ayudar a tus compañeros de equipo es otra cosa con la que
estás aprendiendo a hacer y poniéndote cómodo en un mundo ágil. Tu proyecto para esta clase es documentar qué expectativas tienes para trabajar en un proyecto Agile y qué turnos y mentalidad crees que necesitarías hacer personalmente si te desplazaras de un entorno de cascada a un ágil o si eres nuevo en Agile y no has trabajado previamente en Waterfall. Por lo que no necesariamente tienes que hacer un turno. Después enumera tres cosas que sientes que son necesarias para una mentalidad exitosa, para un ambiente de trabajo ágil.
Teresa Bennett, Business Analysis Expert
