Matriz de competencias para equipos ágiles

Actualmente me he propuesto introducir esta práctica de Management 3.0 dentro del equipo con el que estoy actualmente trabajando debido a algunos problemas de ausencias de ciertas habilidades dentro del equipo debido a dependencias de equipos externos al del producto que gestionan y cuentan con los perfiles con dichas habilidades como servicios corporativos (ya se no es lo mejor para tener equipos ágiles multidisciplinares pero es lo que hay y “hay que comerrr…” como diría un amigo).

Después de leer y documentarme con toda la información existente sobre el tema, he llegado a definir una propuesta de esta dinámica para cubrir varios objetivos y obtener ciertos resultados y que os voy a compartir.

competence-levels.png

Objetivo

 

  • Identificar las competencias necesarias para el producto en varias dimensiones:
    • Habilidades técnicas
    • Conocimientos funcionales y procesos
    • Habilidades blandas
  • Identificar el grado de conocimiento del equipo en dichas competencias.
  • Identificar gaps de conocimiento para contar con un equipo multidisciplinar y autosuficiente y acciones para cubrir dicho gap como equipo.
  • Identificar puntos de mejora personales y acciones de mejora individual en cuanto a formación (Perfiles T).
  • Identificar en qué somos buenos como equipo y en qué debemos mejorar como equipo y personalmente para elaborar un plan de acción.

 

Matriz de competencias

 

  • Se trata de una matriz donde en horizontal se identifican las competencias por tipos y en vertical los miembros del equipo.
  • Por cada competencia hay que describir la competencia e identificar la capacidad necesaria por cada nivel en el producto y las acciones como equipo a tomar si no se dispusiera de los mínimos dentro del equipo.
  • Por cada miembro hay que identificar el nivel para cada una de las habilidades y las acciones personales (si se quisiera como plan de formación personal) para mejorar en algunas de ellas y conseguir un perfil T.
    • Los niveles van a ser:
      • 0 – Sin conocimientos (no disponible) – Cruz roja (X)
      • 1 – Conocimiento básico (novato) – Punto rojo (o)
      • 2 – Puede abordarlo pero con ayuda (aprendiz) – Punto azul (o)
      • 3 – Puede abordarlo de forma independiente (avanzado) – Punto Verde (o)
      • 4 – Conocimiento excelente, puede enseñar a otros (experto) – Punto Negro (o)

 

Dinámica para su creación y seguimiento

 

  • Identificamos las competencias necesarias para el producto en sus 3 dimensiones: Habilidades técnicas, Habilidades funcionales y procesos, Habilidades blandas
  • Describir las competencias mínimamente para ser comprensible su necesidad y acordar por cada una de estas competencias cuál es el la capacidad mínima que se debe de tener en el ítem evaluado enumerando la cantidad de Expertos, Avanzados y Aprendices por cada uno de ellos.
  • A continuación de manera grupal, se comienza a llenar las columnas de la Matriz con los nombres de los correspondientes integrantes del equipo y debatiendo de manera abierta en qué nivel de competencia consideran que se encuentra cada uno respecto a una habilidad específica.
  • Encontrar maneras de desarrollar las habilidades que faltan identificando acciones de equipo para adquirirlas, por ejemplo, capacitación para …, programación en pares … , charla técnica sobre …,  mentores con experiencia que enseñan al equipo en … etc.
  • Priorizar las acciones y planificar ejecutándose conforme a prioridad durante los siguientes sprints o iteraciones.
  • En sesiones posteriores identificar, si la persona quiere, acciones de coaching/mentoring sobre su mejora personal para convertirse en un perfil T o multidisciplinar (como agile coach o scrum master).
  • Finalmente y posterior a esta sesión se debe de hacer un seguimiento continuo de las acciones. Colocar la lista de habilidades requeridas visible en el lugar de trabajo. Inspeccionar si las acciones se cumplen en cada sprint y la capacidad es mejorada según sea necesario y adaptar las acciones conforme al resultado si fuera necesario.

 

Ejemplo de matriz

 

 

Resultados esperados

 

  • Aumenta la confianza en sí mismo de los miembros del equipo.
  • Se descubren las habilidades ocultas de los miembros del equipo.
  • Crea transparencia y muestra cómo el desarrollo de habilidades es necesario para mejorar el equipo y generar un buen producto.

 

 

Ya os contaré como avanza la dinámica conforme vayamos inspeccionando los resultados y adaptando la dinámica si fuera necesario 🙂

 

Fuente:
Management 3.0 Practice Competency Matrix

 

Anuncios
Categorías:agile, dinámicas

Reuniones Efectivas

“Una reunión es una agrupación de dos o más personas convocadas con el propósito de lograr un objetivo común a través de la interacción”

14565350736_0c1456e0f8_z

Las reuniones de equipo son significativas e inevitables. Aseguran que los proyectos del equipo vayan en fecha y estén en buen camino, y que todos estén en sintonía. Las reuniones del equipo dejan claro que todos están trabajando para lograr el mismo objetivo.

Si bien algunas reuniones no son necesarias y tenemos que trabajar en el timeboxing de otros, reunirse con nuestros compañeros de equipo y compartir pensamientos, ideas, opiniones y soluciones es un ejercicio importante.

Las estadísticas muestran que, en general, las personas terminan perdiendo aproximadamente 31 horas cada mes en reuniones improductivas. Incluso a nivel gerencial, los gerentes intermedios pierden hasta el 35% de su tiempo y los altos directivos desperdician hasta el 50% de los suyos en reuniones, sintiéndose como un desperdicio absoluto.

En ocasiones, da la sensación que muchas reuniones buscan control. Un control de tareas y resultados. Pero, o son excesivamente frecuentes o a lo mejor no es la mejor forma. En muchas ocasiones un buen gestor de proyectos/tareas puede evitar tanta reunión. Conseguiremos información instantánea sobre el estado de proyectos y tareas. Así quizá, podamos reducir el número de reuniones. Y hacer más seguimiento que control.

 

Problemas actuales

Problemas actuales detectados en una organización:

  • Muchas reuniones innecesarias.
  • Reuniones de control.
  • Muchos participantes.
  • Se empieza y termina tarde.
  • Convocan y Asisten muchas personas.
  • Sin objetivo claro.
  • Muy largas.
  • Sin conclusiones y acciones posteriores.
  • Sin responsables de acciones y plan de ejecución.

¿Cómo dejas de tener reuniones inútiles?
Aprovechemos las reuniones para lo que son. Un momento y espacio para conseguir un fin concreto por un conjunto de personas. Sobre todo es un trabajo en equipo que no podríamos hacer de forma tan eficaz de otro modo.

¿Cómo se diseñan reuniones memorables ?
La gestión del tiempo y la organización del trabajo debe ser una cultura de empresa. Se necesitan hábitos compartidos por todos para evitar estrés innecesario.
Vamos a ver a continuación una seria de buenas prácticas y consejos para conseguirlo.

 

Manual de buenas prácticas

Para ser un profesional exitoso, que significa productivo, es necesario que saber cómo diseñar reuniones memorables.

A continuación vamos a ver una serie de buenas prácticas y consejos para organizar reuniones memorables:

 

1. Deja de invitar. Vende tu reunión!

Asegurarse de que los asistentes realizan un trabajo significativo durante la reunión puede ser uno de los objetivos más impactantes que se pueda lograr como convocante.
Debe aprender a comunicar el valor de la reunión para que la gente quiera asistir y todos puedan participar.
¡Si no puede convencer a sus compañeros de trabajo de asistir a su reunión, es tu problema, no el de ellos!

Consejo: Un tema por reunión
Las reuniones no deben ser rutinarias. Solo tienen sentido cuando el tema en cuestión es necesario, desafiante o emocional, y sería mejor abordarla dirigida para obtener las inquietudes y preguntas de sus compañeros de trabajo.

Consejo: Tener una agenda.
Si bien esto puede parecer información innecesaria, sin una agenda predeterminada, las reuniones pueden convertirse rápidamente en una pérdida de tiempo.
Desde conversaciones que pasan del tema a la discusión de temas con la menor prioridad, una reunión mal administrada puede hacer más daño que bien.
Un buen método es incluir  la agenda con un resumen de los detalles de la reunión y compartirlos con los asistentes de antemano. Esto mantiene el rumbo de las discusiones de la reunión de manera productiva.
Crear una agenda también le permite asignar a cada asistente una parte de la misma, ayudando a los asistentes a sentirse útiles y enfocados.

 

2. Las cocinas son mejores que las salas.

Los asistentes desean algo diferente, algo que no hayan visto antes.
A menudo debe iterar en el modo de reunirse y tomar medidas para aumentar la colaboración y energizar a su equipo.

Consejo: Reuniones en línea.
Aunque las reuniones cara a cara son efectivas, viajar entre sucursales o plantas de un mismo edificio, o tener que desplazarte si estas teletrabajando  puede desperdiciar tiempo y recursos.
Si bien puede considerar la opción de conferencia telefónica, también tiene que saber que el 65% de las personas realizan otro trabajo regularmente durante una conferencia telefónica.
Esto, a su vez, causa pérdida de enfoque y pérdida de tiempo.
En lugar de las conferencias telefónicas, puede ser útil participar en videoconferencias, lo que permite a los empleados encontrarse cara a cara sin estar en el mismo lugar.
Una aplicación de gestión de reuniones tiene la capacidad de simplificar múltiples procesos, desde la gestión de asistentes y proveedores hasta la decisión de calendarios. También puede proporcionar videoconferencias multipartitas y compartir contenido.
Las aplicaciones de gestión de reuniones pueden ser la solución para casi todos los problemas de productividad de las reuniones y la necesidad de salas.

 

3. Romper el hielo.

Comienza una reunión con un “rompehielos”. Aumenta la energía en la reunión, involucra a todos, y como subproducto, también lo ayuda a obtener más información acerca de sus compañeros de trabajo.

FAVI, durante muchos años, tuvo la práctica de comenzar cada reunión con todos los participantes compartiendo una breve historia de alguien a quien recientemente habían agradecido o felicitado. La práctica tuvo un efecto hermoso en las reuniones: creó un ambiente de posibilidad, gratitud, celebración y confianza en la bondad y el talento de otras personas. Centrarse en los demás y sus logros también puede ayudar a las personas a desviar su atención de los objetivos egocéntricos con los que podrían haber venido (“Necesito sacar a X de la reunión”) y re-conectarse con las necesidades más amplias de la organización.
–Frederic Laloux, Reinventing Organizations

4. Energiza a tus equipos con juegos.

Puedes usar juegos de escenificación o competiciones que desafíen a las personas mental o físicamente, haz descansos o si la energía disminuye durante una reunión larga.
Los juegos implican actividad física ligera que genera energía y positivismo.

 

5. Hacer reuniones visuales.

Las reuniones visuales no solo son más divertidas que las reuniones normales, también son más interactivas y productivas.
Los participantes de las reuniones visuales están más comprometidos y preparados para la acción.

Consejo: Una imagen vale mas que mil palabras. Los visuales son una parte integral de cada reunión.
No solo hable de los asuntos usando texto en diapositivas o folletos en papel. Haga uso de gráficos, imágenes e incluso vídeos para analizar el progreso.

 

6. Fomentar el choque de ideas.

Con demasiada frecuencia, las personas luchan por el consenso que deja un terreno fértil sin cultivar. En una buena reunión, la gente se entusiasma argumentando sus puntos.
Un verdadero líder no es un buscador de consenso sino un moldeador de consenso.
–Martin Luther King

Consejo: Sesiones de Brainstorming.
Si bien es bueno tener las discusiones resumidas, también puede ser efectivo dejar un espacio de tiempo abierto en sus reuniones para una lluvia de ideas.
Las personas tienen habilidades únicas, procesos de pensamiento y talentos, y esto les da a los miembros de su equipo la oportunidad de sentirse escuchados.
Las sesiones de lluvia de ideas pueden ayudar a las personas a compartir ideas basadas en sus habilidades únicas, lo que puede aportar información valiosa a la empresa y conducir a la búsqueda de soluciones poco probables.

 

7. Tome decisiones rápidamente, incluso si son imperfectas.

Obtener tracción en una sola cosa es mucho más útil que tocar en muchas cosas sin impulso hacia adelante en ninguna.

Consejo: Que la reunión sea lo más breve posible. Las reuniones largas pueden cansar y distraer a los asistentes.
Según la investigación, el lapso de tiempo para prestar atención es de entre 10 y 18 minutos. Por esta razón, es posible que desee mantener las reuniones, en promedio, de 15 minutos o menos.
Las reuniones cortas ayudan a enfocarse solo en los problemas sin dar a las personas el lujo de tiempo para dejar de lado.
Las reuniones más cortas son más productivas que las más grandes. Las reuniones no son para vender sus acciones. Deben compartir el valor y decidir acciones juntos.

 

8. Promover la transparencia

Es importante dejar alguna documentación de la reunión con información relevante, conclusiones, decisiones y acciones a tomar posteriores y comparte con todos los convocados para su seguimiento posterior. Puede ser un correo, un documento de acta, o una nota en alguna comunidad de conocimiento.

Bridgewater Associates, el fondo de cobertura más grande del mundo con 145 mil millones de dólares en activos, adopta un enfoque de este tipo: cada reunión se registra y se pone a disposición de todos los empleados. El fundador de Bridgewater, Ray Dalio, explica: “Mi principio más importante es que llegar a la verdad … es esencial para mejorar. Llegamos a la verdad a través de una transparencia radical y dejando de lado nuestras barreras del ego para explorar nuestros errores y nuestras debilidades personales para que podamos mejorar.
–Laszlo Bock, Work Rules!

9. Busca mejorar

El resultado de una gran reunión no es la reunión en sí misma. Es lo que sucede después de esa reunión:

  • ¿Qué aprendimos?
  • ¿Qué fue valioso?
  • ¿Qué vamos a hacer?
  • ¿Cómo evaluaremos el éxito de nuestros próximos pasos?

Debe asegurarse de que los asistentes recuerden para que están allí, recuerden lo sucedido y recuerden cuáles son sus tareas y responsabilidades.

 

Conclusión:

Las reuniones efectivas no ocurren por accidente, suceden por diseño.
–Catherine Mattiske, Making Meetings Work, 2010

Tenemos que comenzar a desarrollar buenas prácticas de reuniones, tanto si somos convocantes como si somos asistentes.
Para que todos lo tengamos en cuenta, las resumimos en los siguientes checklist.

 

Checklist para convocante de reuniones

Previo a la reunión:

  • ¿es necesaria la reunión? –> Asegúrate de ser necesaria la reunión o si hay alternativa.
  • ¿qué tipo de reunión necesito? –> presencial, audio conferencia o vídeo conferencia
  • Redacta convocatoria: ¡Vende tu reunión! –> Convocatoria con explicación de objetivo y agenda, NO solo asunto!
  • Localiza a los asistentes necesarios y asigna agenda –> NO convocados para estar informados;  asignar puntos de agenda a asistentes sobre todo si la reunión es larga y no es necesaria la presencia de todos todo el tiempo.
  • Convoca con tiempo –> entre 1 día y una semana si es no planificada, más si es planificada.
  • Prepara la reunión –> tipo (presencial, audio, vídeo), sala, materiales, contenidos, formato, tiempo, etc.

En la reunión:

  • Se puntual y prepara escenario –> Llega a tiempo y ten todo lo necesario preparado en el escenario.
  • Facilita y modera la sesión –> Rompe el hielo, presenta objetivo y agenda, modera, facilita la sesión, …
  • Dirige la sesión –> Asegura la participación de todos y el seguimiento de la agenda.
  • Asegura la toma de decisiones –> Debe de asegurar que el objetivo de la reunión y la agenda concluye con una toma de decisiones y conclusiones

Posterior a la reunión:

  • Comparte la información de la sesión –> Redacta documento de la reunión con información relevante, conclusiones, decisiones y acciones a tomar posteriores y comparte con todos los convocados para su seguimiento posterior.
  • Realiza las acciones asignadas –> Es importante que no se quede en solo intenciones y se convierta en acciones de valor posteriores a la sesión.
  • Revisa las acciones realizadas –> La única forma de evaluar el resultado de una reunión es con acciones concluidas.

Checklist para asistente a reuniones

Previo a la reunión:

  • Aceptar/Rechazar convocatoria cuanto antes –> Si se necesaria mas información para ello solicita al convocante.
  • Redirige al asistente necesario –> Si no eres el asistente adecuado o puedes delegar en alguien de tu equipo redirige la convocatoria hacia la persona adecuada y comunica en cambio.
  • Si cambias de decisión notifica con tiempo –> Si se tiene algún impedimento para asistir comunica al solicitante, puede que sea necesaria tu presencia. Es buena práctica tener las agendas corporativas actualizadas para ver nuestra disponibilidad.
  • Prepara la reunión –> Prepárate el tema o temas asignados en agenda.

En la reunión:

  • Se puntual –> Llega a tiempo y lleva todo lo necesario para la reunión preparado.
  • Escucha y participa activamente en la sesión –> Recuerda que estás en una sesión de trabajo, no perdiendo el tiempo en una reunión. Evita la multitarea y las interrupciones durante la sesión.
  • Fomenta un buen clima de trabajo en la sesión –> Se respetuoso en los debates y opiniones con tus compañeros.
  • Anota las conclusiones y toma de decisiones –> No esperes al acta de reunión por parte de otro de los compañeros, toma tus propias notas.

Posterior a la reunión:

  • Revisa la información de la sesión –> Revisa documento de la reunión con información relevante, conclusiones, decisiones y acciones a tomar posteriores y aporta tu punto de vista si no estuvieras de acuerdo con la información proporcionada.
  • Realiza las acciones asignadas –> Es importante que no se quede en solo intenciones y se convierta en acciones de valor posteriores a la sesión.
  • Comunica las acciones realizadas –> La única forma de evaluar el resultado de una reunión es con acciones concluidas.

Checklist recordatorio para las salas

  • Se puntual: entra a la sala a la hora y libera la sala a la hora
  • ¿Vienes preparado para la reunión?
  • Dirige y participa activamente en la reunión
  • Se respetuoso y correcto con tus compañeros
  • ¿Has tomado conclusiones y acciones de la reunión?
  • Reporta problemas con la sala si los hubiera
  • Deja todo como estaba

Referencias

https://management30.com/modules/better-meetings/

https://dzone.com/articles/5-tips-for-more-effective-team-meetings?edition=371199&utm_source=Weekly%20Digest&utm_medium=email&utm_campaign=Weekly%20Digest%202018-04-04

 

Categorías:Varios Etiquetas: , ,

In praise of SWARMing

Dan North & Associates

Most of my work these days is helping organisations figure out how to be more effective, in terms of how quickly they can identify and respond to the needs of their external and internal customers, and how well their response meets those needs. This tends to be easy enough in the small; the challenges appear as we try to scale these techniques to the hundreds, thousands or tens of thousands of people.

It is into this space that a new generation of software methods have emerged. SAFe, LeSS, DAD and others claim to help enterprises “scale agile,” whatever that means. A generous interpretation is that people who have a track record helping organisations on this journey have managed to codify their knowledge into a set of blueprints, guidelines, frameworks and methods so you don’t have to. Another take is that execs in organisations above a certain size like to buy…

Ver la entrada original 4.106 palabras más

Categorías:Uncategorized

Scrum Master – Definición y Funciones

En los últimos meses y por varias situaciones laborales diferentes se me han planteado las preguntas de ¿qué es un Scrum Master? y ¿a qué se dedica un Scrum Master?

Para intentar dar respuesta a esta pregunta comencé a buscar información acerca del tema por toda la web, quedándome con un resumen obtenido a partir de diferentes publicaciones realizadas y que he considerado, desde mi punto de vista, vienen a dar respuesta a estas preguntas y el cual comparto en este artículo.

 

Índice

  • Definición de Scrum Master
    • Definición según la guía oficial de Scrum
    • Definición resumida de Scrum Master
  • Funciones de Scrum Master
    • El Scrum Master como líder de cambio (o agente de cambio)
    • ¿Qué es un agente de cambio?
    • ¿Qué está haciendo realmente Scrum Master durante el día?
    • Lista de Tareas de un Scrum Master
    • Lista de verificación de tareas de un Scrum Master

 

Definición de Scrum Master

Definición según la guía oficial de Scrum

(fuente http://www.scrumguides.org/scrum-guide.html)

El Scrum Master es responsable de promover y apoyar Scrum como se define en la Guía de Scrum.

Los Scrum Masters hacen esto ayudando a todos a entender la teoría, prácticas, reglas y valores de Scrum.

El Scrum Master es un líder que está al servicio del Equipo Scrum. Ayuda tanto a los Stakeholders como al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser útiles y cuáles no. Y ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.

 

El Scrum Master da servicio al Dueño de Producto de varias formas, incluyendo:

  • Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el equipo Scrum de la mejor manera posible;
  • Encontrar técnicas para gestionar la Lista de Producto de manera efectiva;
  • Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y concisos;
  • Entender la planificación del producto en un entorno empírico;
  • Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de Producto para maximizar el valor;
  • Entender y practicar la agilidad;
  • Facilitar los eventos de Scrum según se requiera o necesite.

 

El Scrum Master da servicio al Equipo de Desarrollo de varias formas, incluyendo:

  • Guiar al Equipo de Desarrollo para que sea autoorganizado y multifuncional;
  • Ayudar al Equipo de Desarrollo a crear productos de alto valor;
  • Eliminar impedimentos para el progreso del Equipo de Desarrollo;
  • Facilitar los eventos de Scrum según se requiera o necesite; y,
  • Guiar al Equipo de Desarrollo en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo.

 

El Scrum Master da servicio a la Organización de varias formas, incluyendo:

  • Liderar y guiar a la organización en la adopción de Scrum;
  • Planificar las implementaciones de Scrum en la organización;
  • Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto;
  • Motivar cambios que incrementen la productividad del Equipo Scrum; y,
  • Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización.

 

Definición resumida de Scrum Master

(fuente https://cristinaramosvega.com/los-roles-scrum/)

En modo resumido podemos decir que el Scrum Master es el maestro del modelo Scrum. Entendiendo maestro como una persona capaz de enseñar a aplicar el modelo con habilidad y destreza. Es decir, con maestría.

Así pues, el Scrum Master:

  • Es el garante del Modelo Scrum.
  • Es un líder “influyente” al servicio del Equipo Scrum y de la Organización.
  • Tiene conocimiento y experiencia en el marco de trabajo y en el modelo organizativo Scrum.
  • Sirve al Product Owner, ayudándole a entender:
    • La planificación del producto en un entorno empírico
    • El mantenimiento de una Lista de Producto clara y priorizada
  • Sirve al Equipo Técnico, enseñándole:
    • A ser un equipo auto-organizado y multifuncional
    • A eliminar impedimentos para su progreso
  • Sirve a la Organización, liderando la adopción de Scrum:
    • Planificando su implementación
    • Motivando cambios que incrementen la productividad del Equipo Scrum
  • Es el máximo responsable de asegurar que el modelo es entendido y aplicado.

El Scrum Master se caracteriza por su humildad y su generosidad.

 

Funciones de un Scrum Master

El Scrum Master como líder de cambio (o agente de cambio) 

(fuente https://www.scrum.org/resources/blog/scrum-master-change-leader)

 

Esta es una de las posturas que se describe en el documento “Las 8 posturas de un Scrum Master“.

Las 8 funciones comúnmente malentendidas de un Scrum Master

La función de Scrum Master a menudo se entiende mal y se considera como alguien que actúa como …

  • Policía de Scrum. Rigurosamente siguiendo las reglas de Scrum sin ninguna empatía por la situación actual y el contexto del equipo. Si no estás actuando de acuerdo con la Guía de Scrum, lo estás haciendo mal.
  • Héroe. Es un pájaro. Es un avión. ¡Es el Súper Scrum Master! Resolver todos tus impedimentos incluso antes de que fuera realmente un impedimento. El héroe es adicto a la adrenalina de resolver “problemas”. No se trata del equipo, se trata de aumentar su condición de héroe.
  • Escriba. Tomando notas durante cada evento de Scrum. Anotando todo el plan de sprints, plan diario, discusiones de refinamiento y compromisos retrospectivos.
  • Secretario. Planificando todos los eventos de Scrum en la agenda de todos. Responsable de mantener el horario de los equipos con días festivos y días libres actualizados.
  • Cafetero.  No hay nada de malo en conseguir café para los miembros de su equipo. Eso es incluso muy colegial?? de compañerismo. Pero si tu objetivo principal durante el día es proporcionar café al equipo … entonces te estás perdiendo el objetivo de ser un Scrum Master.
  • Director.  Todas las mañanas, el equipo proporciona una actualización de estado al presidente del Scrum diario. Esto ofrece al Scrum Master la información necesaria para escribir el informe de estado diario a sus superiores.
  • El administrador (herramientas).  Si necesita un cambio en JIRA o cualquier otra herramienta: el Scrum Master es su amigo. Él conoce todos los flujos de trabajo de memoria.
  • El jefe del equipo. El llamado “líder sirviente”, pero en realidad solo es el jefe del equipo. El jefe que contrata y despide. El jefe que decide si alguien merece un aumento salarial.

Si cumples con el rol del Scrum Master de acuerdo con las 8 posturas malentendidas, es probable que termines con un Scrum Team con …

  • Bajo nivel de autoorganización. Depende del Scrum Master solucionar todos los problemas (potenciales), dividir el trabajo entre los miembros del equipo y determinar la composición del equipo “ideal” …
  • Un equipo que no posee el proceso. El equipo solo usa Scrum porque tú, como Scrum Master, eres tan entusiasta al respecto. Probablemente, el Daily Scrum solo ocurrirá cuando el Scrum Master esté presente …
  • Zombie-Scrum. A primera vista, parece ser Scrum normal. Pero le falta el corazón que late. Los equipos de Scrum realizan todos los eventos de Scrum, pero un incremento potencial liberable, rara vez es el resultado de un Sprint. Los equipos de Zombie Scrum tienen una definición muy poco ambiciosa de lo que significa ‘hecho’ y ningún impulso para extenderlo. Se ven a sí mismos como un engranaje en la rueda, incapaces y no dispuestos a cambiar nada y tener un impacto real: ¡solo estoy aquí para codificar! Los equipos de Zombie Scrum no muestran respuesta a un Sprint fallido o exitoso y tampoco tienen ninguna intención de mejorar su situación. En realidad, a nadie le importa este equipo. Las partes interesadas han olvidado la existencia de este equipo hace mucho tiempo.

Las 8 posturas reales de un Scrum Master

Es mejor cumplir el rol de Scrum Master siendo un …

  • Eliminador de impedimentos. Resolver problemas de bloqueo para el progreso del equipo, teniendo en cuenta las capacidades de auto organización del equipo de desarrollo.
  • Facilitador. Al establecer el escenario y proporcionar límites claros en los que el equipo puede colaborar. Facilitando los eventos de Scrum, asegurando que lograrán el resultado deseado. Aún más importante: facilita la transparencia necesaria para que pueda realizarse una verdadera inspección y adaptación.
  • Entrenador. Que entrena a la persona con un enfoque en la mentalidad y el comportamiento, el equipo en mejora continua y la organización en una verdadera colaboración con el equipo de Scrum.
  • El docente. Debe asegurarse de que Scrum y otros métodos relevantes sean comprendidos y ejecutados.
  • Líder sirviente.  Cuyo enfoque está en las necesidades de los miembros del equipo y aquellos a quienes sirven (el cliente), con el objetivo de lograr resultados en línea con los valores, principios y objetivos comerciales de la organización.
  • Gerente. Responsable de la gestión de impedimentos, la eliminación de residuos, la gestión del proceso, la gestión de la salud del equipo, la gestión de los límites de la auto organización y la gestión de la cultura.
  • Agente del Cambio. Para habilitar una cultura en la que los equipos de Scrum puedan florecer.
  • Mentor.  Que transfiere conocimiento y experiencia ágiles al equipo.

¿Qué es un agente de cambio?

(fuente https://www.scrum.org/resources/blog/scrum-master-change-agent)

Algunas buenas definiciones sobre un agente de cambio son:

  • “Una persona que ayuda a una organización a transformarse centrándose en la eficacia, la mejora y el desarrollo de la organización”.
  • “Las personas que actúan como catalizadores del cambio”.

Dentro del contexto de Scrum, el rol del Scrum Master se describe como un agente de cambio como:

  • “Un buen Scrum Master ayuda a un equipo de Scrum a sobrevivir en la cultura de una organización. Un gran Scrum Master ayuda a cambiar la cultura para que los equipos de Scrum puedan prosperar”

Para describir las características de una cultura de Scrum hay que referirse al manifiesto Agile. Una cultura amigable con Scrum es un entorno que:

  • Valora el éxito del equipo sobre el éxito individual
  • Estimula los miembros del equipo para mantener a sí mismos y a los demás responsables
  • Promueve la mejora continua y la experimentación
  • Aprecia a todos por sus talentos y habilidades únicos
  • Valores de comportamiento sobre logros
  • Pone al cliente en el centro de sus operaciones
  • Considera que el acto de planificar es más útil que el plan real
  • Admite una composición estable del equipo durante un período más prolongado para aumentar el rendimiento
  • Invita e inspira a los miembros del equipo a sacar el máximo provecho de ellos mismos.
  • Prospera con la autodisciplina donde se otorga confianza y propiedad a las personas
  • Ayuda a las personas a tener éxito brindando apoyo, confianza y orientación
  • Reemplaza la documentación temporal e integral con comunicación cara a cara
  • Valores de productos en lugar de proyectos
  • Proporciona valor comercial a través de equipos pequeños, ubicados conjuntamente, multifuncionales y auto organizados

Para habilitar una cultura en la que los equipos de Scrum puedan florecer, el Scrum Master debe actuar como un agente de cambio. El Scrum Master ayuda a crear un entorno que permite que el espíritu de Scrum prospere. La Guía de Scrum define esta parte del rol de Scrum Master como servir a la organización.

Como agente de cambio, los verdaderos grandes Scrum Masters se harán visibles. Saben cómo cambiar el statu quo y ayudar a crear un entorno más adecuado. Saben cuándo ser disruptivo y cuándo tener cuidado. Ellos entienden que los cambios organizacionales pueden tomar un período de tiempo más largo. Sin embargo, su disposición a cambiar actúa como una catálisis para impulsar a la organización. La fuerza de Scrum está haciendo que los cuellos de botella y los problemas sean visibles, los grandes Scrum Masters crean apoyo dentro de la organización para resolver verdaderamente estas disfunciones.

¿Qué está haciendo realmente un Scrum Master durante el día?

(fuente https://www.scrum.org/resources/blog/day-life-scrum-master)

La respuesta más obvia se puede encontrar en la propia Guía de Scrum. Ofrece una descripción clara de los servicios que Scrum Master proporciona al equipo de desarrollo, al propietario del producto y a la organización. Algunos ejemplos de estos servicios son entrenar al Equipo de Desarrollo en la auto organización y la funcionalidad cruzada, ayuda al Product Owner a encontrar técnicas para una gestión efectiva del Product Backlog y apoya a la organización en su adopción de Scrum.

Un Scrum Master por la propia definición:

  • Pone foco en la creación de equipos exitosos con fuertes habilidades en auto organización y funcionalidad cruzada y un impulso para la mejora continua.
  • Apoya a los Propietarios de Producto en la visualización del progreso, la creación de una Cartera de Producto transparente y la maximización del valor del producto.
  • Ayuda a las organizaciones a hacer que Scrum tenga éxito al apoyar a la administración en los procesos, procedimientos, cultura y comportamiento cambiantes.
  • Asegura que el espíritu de Scrum es realmente entendido, debido a su fuerte enfoque en los principios de Agile y los valores de Scrum.

Características de un gran Scrum Master (no son todas las tareas tangibles, pero dan una idea de qué esperar de un Scrum Master):

  • Asegura que todo el equipo soporte el proceso de Scrum elegido.
  • Maneja los impedimentos que exceden las capacidades de auto organización del equipo y les impide alcanzar el Objetivo del Sprint.
  • Reconoce el conflicto saludable del equipo y promueve el desacuerdo constructivo.
  • Está preparado para ser lo suficientemente disruptivo como para hacer cumplir un cambio dentro de la organización.
  • Entiende el poder de una auto organización.
  • Entiende el valor de un ritmo constante de sprint y hace todo lo posible para crearlo y mantenerlo.
  • Sabe cómo escuchar de verdad y se siente cómodo con el silencio.
  • Entiende la fuerza del coaching y ha aprendido a utilizar algunas preguntas poderosas.
  • Enseña al propietario del producto cómo maximizar el retorno de la inversión y cumplir los objetivos.
  • Es competente con otros frameworks como XP, Kanban y Lean.

La parte más importante es que un Scrum Master siempre debe evitar tener una agenda completa. Un Scrum Master inteligente tiene mucho espacio libre en su agenda. Cuanto más, mejor.

Como planificación diaria, un Scrum Master podría considerar preguntas como:

  • ¿Cómo está mi Dueño de Producto?
    • ¿El Backlog del producto está en forma?
    • ¿Cómo está manejando a los stakeholders?
    • ¿Qué pasa con la entrega de valor comercial y retorno de la inversión?
  • ¿Cómo está el Equipo de Desarrollo?
    • ¿Están trabajando juntos?
    • ¿Hay conflicto en el equipo? ¿Lo resuelven?
    • ¿El equipo toma decisiones?
  • ¿Cómo están nuestras prácticas de ingeniería?
    • ¿El equipo los está cuidando y mejorando?
    • ¿Cómo está la automatización de pruebas?
    • ¿El equipo está expandiendo su Definición de Listo?
  • ¿Cómo está mi organización?
    • ¿Hay coordinación entre equipos?
    • ¿Qué impedimentos organizacionales hay en el camino?
    • ¿Qué pasa con las prácticas de recursos humanos?

Un día en la vida de un Scrum Master:

  • Comience el día con una mente abierta y curiosa
  • Una buena primera pregunta para considerar es ” ¿Cómo puedo mejorar la vida del equipo de Scrum al facilitar la creatividad y el empoderamiento?”
  • Recuerde: ¡su agenda es tan buena como vacía esté! Excepto por el Daily Scrum y algunos otros eventos de Scrum.
  • Asiste al Daily Scrum como observador. Escucha lo que se dice y lo que no se dice.
  • Considera algunas de las preguntas que se han mencionado anteriormente.
  • En base a sus observaciones, determina sus próximos pasos. Esto puede ser coaching, consultoría, enseñanza, facilitación, mentoring, administración, resolución de problemas, navegación de conflictos o … simplemente sentarse con el equipo, escuchar y observar al equipo.
  • ¡Hacer “nada” es una actividad perfecta para un Scrum Master! El mayor escollo para un Scrum Master es estar demasiado ocupado y no darse cuenta de lo que realmente está pasando.

Lista de Tareas de un Scrum Master

(fuente http://agiletrail.com/2011/11/14/42-tasks-for-a-scrum-masters-job/)

Frecuentemente al adoptar scrum en una organización surgen preguntas como las siguientes:

  • ¿Por qué las funciones de Scrum Master y Project Manager deben ser ocupadas por personas diferentes?
  • ¿Un scrum master para un equipo de 10 será un puesto de tiempo completo o un programador puede ocupar este puesto si está altamente capacitado en scrum?

Detrás de esas preguntas está la suposición de que el Scrum Master no es un rol a tiempo completo. Los que hacen esas preguntas conjeturan que se ahorra dinero al fusionar dos roles o al asignar el deber de los dos roles a una sola persona.

De los tres roles en Scrum, todos parecen comprender de inmediato que ser miembro del equipo es un trabajo de tiempo completo, porque desarrolla software todo el día, y que ser propietario de un producto es un trabajo de tiempo completo, porque desarrolla el producto todo el día, pero parece mucho más allá de la imaginación lo que podría ser el trabajo de un Scrum Master y por qué sería un trabajo de tiempo completo también.

El Scrum Master es un puesto de tiempo completo para una persona en un equipo de Scrum. A continuación, se enumera una lista de cosas que son parte de un trabajo de Scrum Master a tiempo completo:

  • Reuniones
    • Facilitando reuniones para el equipo. Esto incluye:
      • preparando
      • moderación
      • Postprocesamiento
    • Celebración de retrospectivas. Las retrospectivas son reuniones especiales.
  • Dinámica de equipo
    • Coaching a miembros del equipo (p. Ej., Entrenamientos uno a uno).
    • Mediando en conflictos.
    • Ayudando al equipo a tomar decisiones.
    • Fomentando la auto organización del equipo.
    • Mediando el conflicto general de objetivos entre el equipo de desarrollo (alta calidad técnica) y el propietario del producto (más características).
  • Aprendizaje
    • Continuar aprendiendo sobre todo Agile (por ejemplo, visitar grupos de usuarios, asistir a conferencias, leer libros, escribir blogs, etc.).
    • Consultoría a los miembros del equipo con respecto a Agile.
    • Ayudando al equipo a crear radiadores de información.
    • Dar feedback al equipo.
    • Alentar el uso de prácticas de ingeniería ágiles dentro del equipo de desarrollo (por ejemplo, BDD, TDD, software craftmanship, entrega continua, etc.).
    • Retos de Equipo con innovaciones de gestión Agile (p. Ej. FedEx-Days).
    • Interactuando constantemente con otros Scrum Master en la organización (por ejemplo, a través de la comunidad de práctica).
    • Haciendo Gemba Walks.
  • Producto
    • Ayudando a escribir o dividir historias de usuarios.
    • Ayudando a escribir o adaptar visiones de productos.
    • Ayudando a ordenar items del backlog del producto.
    • Ayudando con la planificación de release.
    • Estar familiarizado con el trabajo del equipo (es decir, el producto).
  • Big Picture
    • Reunir a las personas que deberían hablar entre ellos.
    • Mantenerse en contacto con todos los stakeholders regularmente.
    • Ayudando al equipo a informar a la gerencia.
    • Ayudando a fomentar la comunidad Ágil dentro de la organización.
    • Organizar eventos de intercambio como Open Spaces o World Cafés para el equipo, los stakeholders y la organización.
    • Compartir ideas en toda la empresa (microblogging , blogs, conferencias internas, etc.).
    • Ser una persona de contacto para todos en el equipo y los stakeholders con respecto a Agile.
    • Dar oportunidades de aprendizaje a las personas de la organización (por ejemplo, charlas o talleres) y dejarles aprender conceptos ágiles como, por ejemplo, la deuda técnica.
  • Cambio
    • Ayudando al equipo a deshacerse de los impedimentos.
    • Sugerir nuevas métricas para el equipo como catalizadores para el cambio.
  • Espejo
    • Reflejando los valores de Agile y Scrum para el equipo.
    • Recordando al equipo sus acuerdos (por ejemplo, políticas).
    • Ayudando al equipo a mejorar continuamente su proceso.
    • Reflejando problemas para el equipo a través de la observación desde fuera del equipo.
    • Hacer preguntas abiertas.
    • Verificando todos los modelos que usa el equipo (por ejemplo, Sprint backlog, métricas, etc.) y mostrarles las diferencias entre el modelo y el mundo real.
  • Psicología
    • Visualizar el futuro (cómo quiere el equipo que funcione el trabajo, el próximo mes, el próximo año, …)
    • Crear y articular un objetivo común (también conocido como un propósito común) para el equipo (que puede cambiar o cambiar de vez en cuando)
    • Resaltar los valores y el espíritu del equipo
    • Ayudar a todos dentro y fuera del equipo a comprender el papel de la mentalidad en el rendimiento del equipo
    • Ayudar al equipo a mejorar sus habilidades sociales, especialmente conversaciones constructivas
  • Diverso
    • Ayudar al equipo a mantener el enfoque (por ejemplo, actuando como un amortiguador entre las distracciones externas y el equipo).
    • Ayudando al equipo a mantener sus herramientas de Scrum (Story Board, Action Board, gráficos, backlogs, etc.).
    • Ayudar al equipo y al propietario del producto a encontrar un:
      • definición de hecho
      • definición de listo
    • Mantener al equipo unido: proteger al equipo como una unidad cohesiva (por ejemplo, de otras partes del negocio que quieren atracar furtivamente personas, o el tiempo de las personas), incluso desde la disolución completa (también conocido como derribo).

Lista de verificación de tareas de un Scrum Master

(fuente http://blogs.collab.net/agile/a-scrummasters-checklist)

A continuación, se enumeran algunas de las tareas que habitualmente ignora un Scrum Masters:

  1. ¿Cómo está mi Dueño de Producto? ¿Mejoras la efectividad del Propietario del Producto ayudándole a mantener el Product Backlog y la release plan? (Tenga en cuenta que solo el propietario del producto puede priorizar el backlog).
  • ¿Está el Product Backlog priorizado?
  • ¿Están todos los requisitos y deseos de todos los stakeholders para el producto capturados en el product backlog? Recuerde que el backlog es emergente.
  • ¿Es el product backlog de un tamaño manejable? Para mantener una cantidad manejable de elementos, mantenga solo las cosas más granulares hacia la parte superior, con épicas generales en la parte inferior. Es contraproducente sobre analizar demasiado más allá de la parte superior del product backlog. Sus requisitos cambiarán en una conversación continua entre el producto en desarrollo y los stakeholders / clientes.
  • ¿Se podrían expresar mejor los requisitos (especialmente los que se encuentran en la parte superior del product backlog) como historias de usuario INVEST (independientes, negociables, valiosas, estimables, pequeñas y comprobables)?
  • ¿Has informado al propietario de tu producto sobre la deuda técnica y cómo evitarla? Una buena idea puede ser agregar test automáticos y refactorización a la “definición de hecho” para cada ítem del backlog.
  • ¿El product backlog es un radiador de información altamente visible para todas las partes interesadas?
  • Si está utilizando una herramienta automatizada para la administración del backlog, ¿todos saben cómo usarla fácilmente? Las herramientas de administración automatizadas introducen el peligro de convertirse en refrigeradores de información sin radiación activa del Scrum Master.
  • ¿Puedes ayudar a irradiar mostrando a todos las impresiones?
  • ¿Puedes ayudar a irradiar creando grandes gráficos visibles?
  • ¿Ha ayudado al Propietario de Producto a organizar los items del backlog en las versiones apropiadas (o quemador frontal, quemador back, refrigerador)?
  • ¿Todos los stakeholders (incluido el equipo) saben si la release plan aún coincide con la realidad, en función de la velocidad actual (puntos de historia por Sprint)?
  • ¿Ajustó el propietario del producto la release plan después de la última reunión de revisión de Sprint? Hay pocos Propietarios de Producto que replanifican el lanzamiento después de cada Sprint, por lo general posponiendo el trabajo para futuras versiones a medida que se descubre un trabajo más importante. Puede intentar mostrarle a todos los graficos de burndown y release después de que los items hayan sido reconocidos como “hechos” durante cada Sprint Review Meeting. Esto permite el descubrimiento temprano del alcance/cambio de planificación.
  1. ¿Cómo está mi equipo?
  • ¿Los miembros del equipo gastan parte de su tiempo en el estado del flujo? Algunas características de este estado (del flujo):
    • Objetivos claros (las expectativas y las reglas son discernibles y los objetivos son alcanzables y se alinean de manera apropiada con el conjunto de habilidades del equipo).
    • Concentrarse y enfocarse, un alto grado de concentración en un campo de atención limitado.
    • Una pérdida de la sensación de autoconciencia, la fusión de la acción y la conciencia.
    • Sentido del tiempo distorsionado: la experiencia subjetiva del tiempo se ve alterada.
    • Comentarios directos e inmediatos (los éxitos y fracasos en el curso de la actividad son evidentes, de modo que el comportamiento se puede ajustar según sea necesario).
    • Balance entre nivel de habilidad y desafío (la actividad no es ni muy fácil ni muy difícil).
    • Un sentido de control personal sobre la situación o actividad.
    • La actividad es intrínsecamente gratificante, por lo que hay una acción sin esfuerzo.
  • ¿Los miembros del equipo parecen simpatizarse, divertirse juntos y celebrar el éxito mutuo?
  • ¿Los miembros del equipo se responsabilizan recíprocamente de los estándares y se desafían unos a otros para crecer?
  • ¿Hay problemas/oportunidades que el equipo no está discutiendo porque son demasiado incómodos? Ver Conversaciones Cruciales: Herramientas para hablar cuando hay mucho en juego. O considere trabajar con un facilitador profesional que pueda hacer que las conversaciones incómodas sean más cómodas.
  • ¿Has probado una variedad de formatos y ubicaciones para las Retrospectivas? Vea Retrospectivas ágiles: Haciendo buenos equipos (Esther Derby / Diana Larsen) para algunas ideas.
  • ¿El equipo se ha enfocado en los criterios de aceptación? Tal vez debería llevar a cabo un chequeo de Sprint a mediados para volver a revisar los criterios de aceptación de los elementos del sprint backlog.
  • ¿La lista de tareas de Sprint refleja lo que el equipo realmente está haciendo?
  • ¿Las estimaciones de tareas de su equipo y/o su tablero están actualizadas?
  • ¿Son visibles para el equipo los artefactos de autogestión del equipo (tablero de tareas, Sprint Burndown Chart, etc.), y son convenientes para el uso por el equipo?
  • ¿Están estos artefactos adecuadamente protegidos de microgestores?
  • ¿Los miembros del equipo se ofrecen como voluntarios para las tareas?
  • ¿Los ítems de amortización de deuda técnica (que reducen la velocidad de su equipo) se han incluido en el backlog y se han comunicado al propietario del producto?
  • ¿Los miembros del equipo dejan sus títulos de trabajo en la puerta de la sala de trabajo?
  • ¿Todo el equipo se considera colectivamente responsable de las pruebas, la documentación del usuario, etc.?
  • ¿La gerencia mide el equipo solo por el éxito colectivo?
  1. ¿Cómo están nuestras prácticas de ingeniería?
  • ¿Su sistema en desarrollo tiene un botón “pulsar para probar” para que cualquier persona (del mismo equipo o equipo diferente) pueda detectar convenientemente cuándo lo han roto? Normalmente, esto se logra mediante el marco xUnit (JUnit, etc.).
  • ¿Tiene un equilibrio adecuado entre las pruebas automáticas del sistema de extremo a extremo (también conocidas como “pruebas funcionales”) y las pruebas unitarias automatizadas?
  • ¿El equipo está escribiendo pruebas del sistema “funcional” y pruebas unitarias en el mismo idioma que el sistema que están desarrollando (en lugar de utilizar lenguajes de scripting exclusivos o herramientas de captura de reproducción que solo un subconjunto del equipo sabe cómo mantener)? Es posible con JUnit… BDD, TDD, etc.
  • ¿Ha descubierto su equipo el área gris útil entre las pruebas del sistema y las pruebas unitarias?
  • ¿Un servidor de integración continua hace sonar automáticamente una alarma dentro de una hora (o minutos) de que alguien ha causado un fallo de regresión? (“Las versiones diarias son para los débiles”. Kent Beck)
  • ¿Se acumulan todos los resultados de las pruebas en el servidor de integración continua?
  • ¿Los miembros del equipo han descubierto los beneficios del diseño continuo y la refactorización constante como una alternativa al “Big Up Front Design”? La refactorización tiene una definición estricta: cambiar la estructura interna de un sistema sin cambiar su comportamiento externo. La refactorización debe realizarse varias veces por hora, siempre que haya código duplicado, lógica condicional compleja (visible por indentado excesivo o métodos largos), identificadores mal nombrados, acoplamiento excesivo entre objetos, etc. La refactorización con confianza solo es posible con la cobertura de pruebas automatizadas. Los agujeros en la cobertura de prueba y la refactorización diferida son cánceres denominados deuda técnica.
  • ¿Su “definición de hecho” (criterios de aceptación) para cada ítem funcional del backlog incluye una cobertura completa y una refactorización? Es poco probable que generes productos potencialmente enviados cada Sprint sin aprender las prácticas de eXtreme Programing (como lo describen Kent Beck, Ron Jeffries, etc.).
  • ¿Los miembros del equipo hacen pair programming la mayor parte del tiempo? La programación de pares aumenta drásticamente el mantenimiento del código y reduce las tasas de errores, pero desafía los límites de las personas y, a veces, parece tomar más tiempo (si ponemos la cantidad sobre la calidad). En lugar de obligar a las personas a hacer esto, lidere con el ejemplo iniciando días de trabajo emparejados con los miembros del equipo. Algunos de ellos comenzarán a preferir trabajar de esta manera.
  1. ¿Cómo está la organización?
  • ¿Se genera la cantidad apropiada de comunicación entre equipos?
  • ¿Los Scrum Master se reúnen entre ellos, trabajando en la lista de impedimentos organizacionales?
  • Cuando corresponde, ¿están los impedimentos organizacionales pegados a la pared de la oficina del director de desarrollo? ¿Se puede cuantificar el costo económico, perdida de time to market, perder calidad o perder oportunidades de clientes? (Pero recuerde el descubrimiento de Ken Schwaber: “Un Scrum Master muerto es un Scrum Master inútil”).
  • ¿Es tu organización una de las pocas con trayectorias profesionales compatibles con los objetivos colectivos de tus equipos? Responda “no” si hay un incentivo profesional para realizar trabajos de programación o arquitectura a expensas de las pruebas, la automatización de pruebas o la documentación del usuario.
  • ¿Su organización ha sido reconocida por la prensa comercial u otras fuentes independientes como uno de los mejores lugares para trabajar o como un líder en su industria?
  • ¿Estás ayudando a crear una organización de aprendizaje?

 

Conclusión:

Una vez recopilada y analizada toda esta información tengo claro que quiero desarrollar mi carrera profesional como Scrum Master y que aun teniendo todo el conocimiento y formación que he absorbido en estos pocos años que llevo dedicado a ello parcialmente, me quedan muchos años de práctica dedicándome al 100% para considerarme a futuro un buen Scrum Master y practicante Agile en general!

 

Categorías:Uncategorized Etiquetas: , ,

Mejoras documentación de ontologías

Blog de Sofia2 IoT Platform

 doc-ontologias-03
Se incluyen en la plataforma una serie de mejoras de cara a la documentación de nuestro modelo de dominio basado en ontologías.
La primera de ellas consiste en poder incluir una descripción a los atributos de una ontología en la pantalla de creación/edición de la misma y cuyo contenido quede incluido en el propio esquema JSON de ésta.
doc-ontologias-01doc-ontologias-02doc-ontologias-03doc-ontologias-04doc-ontologias-05
Se ha incluido en la pantalla de consulta de las ontologías una vista de documentación para mostrar solamente la información documental de una ontología en un formato más amigable que un json-schema y con posibilidad de exportar como pdf documental.
doc-ontologias-06doc-ontologias-07doc-ontologias-08doc-ontologias-09
En posteriores versiones se evolucionará la funcionalidad de creación de ontologías mediante modelado UML para poder modelar todas las entidades de un proyecto Sofia2 o Space en un único diagrama y poder representar relaciones lógicas entre ellas a nivel de espacio, generando las ontologías a partir de dicho modelo y de forma inversa poder obtener…

Ver la entrada original 47 palabras más

Categorías:Uncategorized

Funcionalidad de Export/Import Configuración y Datos en Plataforma Sofia2 (Parte II)

Blog de Sofia2 IoT Platform

exp-ip-edit

En esta segunda parte del post (ver Parte I), nos vamos a centrar en la funcionalidad de exportación e importación de datos de ontologías.

Exportar Datos de Ontologias

La exportación de datos de ontologías se puede hacer de todas las ontologías del usuario y sobre las que tiene permisos.

exp-ip-101

Previo a la exportación de ontologías, podemos ver una estadística del contenido de las mismas, para ello seleccionamos de la lista aquellas que queremos mostrar y pulsamos en el botón “Mostrar estadísticas”.

Se nos muestra la información de tamaño, número de registros disponibles y limite de registros exportables permitido para cada ontología y un check para seleccionar aquellas a exportar.

exp-ip-102

Una vez seleccionado el tipo de exportación que queremos realizar pulsamos el botón Exportar para generar los ficheros de exportación a descargar, uno por ontología seleccionada.

exp-ip-103

Los ficheros se generarán mediante un proceso asíncrono en segundo plano y estarán disponibles en la lista inferior de descargas una…

Ver la entrada original 402 palabras más

Categorías:Uncategorized

Funcionalidad de Export/Import Configuración y Datos en Plataforma Sofia2 (Parte I)

Blog de Sofia2 IoT Platform

Mediante esta funcionalidad se pretende disponer de un mecanismo para la importación y exportación de datos de configuración (proyectos, ontologias, scripts, etc …) y de datos de negocio (instancias de ontologias) relacionados con un usuario desde una instancia de plataforma a otro, por ejemplo desde una instancia de desarrollo a una instancia de preproducción o producción.

Para acceder a la funcionalidad se debe de hacer con usuario con rol Colaborador mediante la opción de menú disponible en Herramientas > Exportar/Importar elementos

exp-ip-001

La ventana de Export/Import contiene 2 pestaña:

  • Elementos configuración:  Funcionalidad para Exportar/Importar elementos de configuración (BDC de Plataforma)
  • Datos ontología: Funcionalidad Exportar / Importar Datos o instancias de Ontologias (BDTR de Plataforma)

exp-ip-002

En una primera parte de este post nos centraremos en la funcionalidad de exportación e importación de elementos de configuración.

Exportar Elementos de Configuración

La exportación de elementos de configuración se puede hacer de todos los elementos de…

Ver la entrada original 553 palabras más

Categorías:Uncategorized