Enlace al informe completo: ANÁLISIS EXTREMO – Emparejamiento para analistas de negocios
ANÁLISIS EXTREMO – Emparejamiento para analistas de negocios
La programación de pares ha sido utilizada por los desarrolladores de software en la mayoría de las compañías de software progresivas para ayudar a producir productos de calidad y garantizar que el contexto se comparta entre los equipos. Para los no iniciados, la programación tradicional de pares (en resumen) es una práctica en la que 2 programadores trabajan en el desarrollo de una funcionalidad de software en conjunto.
Esta práctica ayuda a mejorar la calidad del código, ya que tiene 2 pares de ojos y cerebros tratando de resolver el problema y cuando una persona escribe el código, la otra lo revisa continuamente, eliminando así la necesidad de tener sesiones de revisión de código separadas. Además, si el par ha funcionado eficientemente, cualquier error en el diseño se ha detectado por adelantado, eliminando así cualquier desperdicio causado por defectos que se habrían descubierto en una etapa posterior. Este concepto se ha aplicado principalmente al trabajo de los desarrolladores de software y otros roles aún no lo han adaptado del todo.
¿Porque es esto importante? – Los analistas de negocios (en general) están acostumbrados a trabajar en una capacidad individual ya que la mayoría de los equipos tienen un solo BA, y muchos analistas encuentran difícil trabajar con otros analistas de una manera amigable. Supongo que, dado que hay una escasez de oportunidades para trabajar con otros, las habilidades para trabajar con otros tienen la oportunidad de florecer.
- ¿Cómo inicio mi propio estudio de diseño gráfico?
- Dinámica de fluidos: ¿Hay alguna forma de diseñar un contenedor para influir en el flujo de aire dentro o controlar los puntos donde se ejerce más la fuerza de presión, empujando efectivamente el flujo de aire en una dirección uniforme?
- ¿Cómo funciona el rompecabezas chino / la tetera Cadogan?
- ¿Qué haría para ayudar a su aspirante a hijo que está considerando una carrera en arquitectura?
- ¿Cuáles son las mejores herramientas en línea para probar diseños visuales para un sitio web o interfaz?
“Los analistas de negocios, los analistas de experiencia de usuario (UX), los gerentes de proyectos y (en menor grado) los analistas de calidad están acostumbrados a trabajar solos, y es posible que necesiten averiguar cómo lidiar con situaciones en las que ellos también necesitan colaborar entre la comunidad, y entregar “.
Mi función principal es la de Analista de negocios, y quería compartir mis experiencias sobre los proyectos que ejecuté en ThoughtWorks, donde pude vincularme con los otros BA con cierto nivel de éxito. Este artículo es mi intento de no solo compartir algunas de esas lecciones y experiencias, sino que también generará debates / debates saludables.
Los basicos
Antes de entrar en detalles sobre cómo emparejarse como analistas de negocios, primero necesitamos tener algunos conceptos básicos correctos.
Cualquier relación de trabajo exitosa debe tener estos elementos en el núcleo, la ausencia de estos hará que cualquier intento de emparejamiento sea inútil.
- Compromiso de trabajo de las personas en cuestión.
- Respeto mutuo
- Igual reparto de tareas y responsabilidades.
- Aproveche las fortalezas de cada uno y trabaje alrededor de los bordes ásperos.
- Voluntad de recibir comentarios unos de otros y trabajar para mejorar
- Ayudándose mutuamente a través de los tiempos libres personales asumiendo temporalmente la responsabilidad de las tareas
- Capacidad para compartir risas y trabajar en situaciones estresantes.
- Higiene personal, ya que la expectativa es que ambos se sienten razonablemente cerca uno del otro, la higiene personal será un factor importante. 😛
Prácticas de emparejamiento
Cuando miramos el análisis de negocios en un proyecto ágil, las siguientes tareas generalmente tendrían que llevarse a cabo en el día a día. Espero vincular las prácticas que utilizamos y defender mi caso de “ANÁLISIS EXTREMO”.
Registros diarios: el día generalmente comienza con un stand-up donde participa todo el equipo y, posteriormente, los programadores, analistas de calidad y analistas de negocios se registran para sus tareas. Es importante que los BA se reúnan y enumeren las tareas que tienen la intención de elegir durante el transcurso del día y se registren para ellos en función de una distribución equitativa.
Esta actividad es importante ya que puede haber múltiples cosas (además del detalle de la historia) que deben abordarse durante el día, como responder a los correos electrónicos enviados por el cliente, aumentar los bloqueadores, revisar las historias analizadas, etc. Y estas tareas deben ser identificadas y respondidas a como un equipo.
Herramientas / prácticas: cuando los BA se ubican conjuntamente, tiene sentido sentarse uno al lado del otro y enumerar las tareas en un cuaderno o notas adhesivas y eliminarlas a medida que se realizan. Sin embargo, cuando los BA están trabajando en diferentes zonas horarias (o geografías), además de una recuperación diaria de 15-30 minutos, las inscripciones se pueden administrar a través de un administrador de listas de tareas liviano como Trello. Es basado en la web, de uso gratuito y simple como el infierno.
Detalle de la historia: esta es la tarea más importante que los BA emprenden y emparejar aquí puede ayudar a establecer una dirección mutuamente acordada que el BA que detalla la historia puede tomar.
Herramientas / Prácticas: La herramienta que se usa aquí es la más efectiva, es decir, las conversaciones. El BA que ha tomado la propiedad de una función explicará brevemente el enfoque que él / ella planea tomar y solicitará aportes de los otros BA. Esto asegura que el contexto se comparta y también ayuda a construir una mejor historia por adelantado (falla rápidamente).
Revisión de la historia (interna): en la programación extrema, los programadores utilizan la revisión por pares para garantizar que se sigan las prácticas de codificación. Teniendo en cuenta los mismos principios, los analistas de negocios deben hacer que sus historias sean revisadas por otro par de ojos solo para asegurarse de que todas las bases estén cubiertas.
Herramientas / Prácticas: Asegurarse de que todas las historias (especialmente las complejas) sean revisadas por pares al menos por un Analista de Negocios para capturar cualquier omisión / error obvio.
Revisión de la historia (con el cliente): las historias deben ser aprobadas por los clientes antes de que los programadores puedan recogerlas y estas reuniones se pueden gestionar mejor si trabaja en equipo. Si los BA han seguido los pasos anteriores, recibirán un mensaje uniforme y presentarán una voz unificada al cliente.
Herramientas / Prácticas: Tener funciones iniciales , donde, como equipo, presenta el esquema del requisito y recibe aportes del cliente.
Planificación de iteraciones : las historias que deben seleccionarse en las próximas iteraciones deben planificarse y comunicarse al cliente. Es importante que esta actividad tenga en cuenta las dependencias y prioridades asociadas con las historias y características.
Herramientas / Prácticas: Gire la responsabilidad de crear el plan de iteración entre los BA y luego revise el plan que se ha establecido como un equipo. Nuevamente, esto ayuda a obtener aportes de un grupo más grande y, en ausencia de uno de los BA, los otros pueden hacerse cargo de la reunión de planificación de iteración con el equipo y / o el cliente.