Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anteriorRevisión previa
Próxima revisión
Revisión previa
marcodetrabajoim [2020/03/09 16:49] scantormarcodetrabajoim [2024/03/05 15:41] (actual) – editor externo 127.0.0.1
Línea 67: Línea 67:
  
 {{:recomendacion_sprint_de_2_semanas.png|}} {{:recomendacion_sprint_de_2_semanas.png|}}
 +
 +===== Escalamiento de Scrum =====
 +
 +Utilizando el marco de trabajo SCRUM es posible gestionar un equipo de 3-9 personas trabajando sobre un producto/negocio determinado. Cuando es necesario disponer de una mayor capacidad productiva lo cual implica que existen múltiples equipos trabajando sobre un mismo producto/negocio y todo este trabajo debe producir un incremento integrado, utilizamos dos formas de escalar SCRUM según el contexto de la organización, cantidad de personas, locaciones de trabajo, etc., que se analizan previamente y permiten adoptar la mejor opción para cada caso:
 +
 +  * **Primera forma:** Utilizando marco de trabajo Nexus y Nexus + ([[https://www.scrum.org/resources/online-nexus-guide]]), lo cual nos permite:
 +    * **Nexus:** Gestionar hasta 9 equipos de 3-9 colaboradores.
 +    * **Nexus +:** Gestionar hasta 9 equipos Nexus donde cada uno de ellos tiene hasta 9 equipos de 3-9 colaboradores.
 +
 +{{:nexus_framework_scrumorg.png|}}
 +
 +  * **Segunda forma**: SQUADS o Marco de Trabajo de Spotify, si bien no es un marco de trabajo establecido por SCRUM.ORG, es un marco de trabajo ágil producto de la adaptación de varios fundamentos ágiles a una corporación que requiere grandes cantidades de equipos, personas y recursos colaborando en un único producto/negocio. Adoptamos esta forma de escalar SCRUM debido a que se ha transformado en un estándar de la industria y se basa en el principio de autonomía de los equipos.
 +
 +{{:squads_spotify.png|}}
 +
 +===== KPIs =====
 +
 +A continuación, describimos los KPIs utilizados para evaluar el performance del equipo y el progreso del producto o servicio en desarrollo.
 +
 +  * **Burn Down Chart:** Lo utilizamos para medir el trabajo pendiente en un sprint o del producto.
 +  * **Burn Up Chart:** Lo utilizamos para medir el trabajo completado del sprint o del producto.
 +
 +{{:burndown_y_burnup_charts.png|}}
 +
 +  * **Velocity:** Medición de los “story point” comprometidos versus los terminados según la definición de Done (DoD). De esta forma es posible medir el performance del sprint y del equipo, además permite proyectar el esfuerzo y/o rendimiento. Una diferencia considerable entre puntos desarrollados vs completados puede denotar:
 +    * Deuda técnica.
 +    * Problemas de planificación.
 +
 +{{:velocity_chart.png|}}
 +
 +  * **Incrementos de Funcionalidad y Despliegues a Producción:**
 +    * **Aprobación de Sprints:** Permite medir el nivel de aceptación de los sprints en los eventos de revisión.
 +    * **Despliegues a Producción:** Permite medir si se mantiene una conducta de despliegue continuo ya que la única forma de validar si los incrementos de funcionalidad son realmente de valor, es por medio del mercado y tal retroalimentación solo es posible desplegando a producción.
 +
 +----
 +Todos los nombres de producto y marcas comerciales como Scrum.org(tm) y Spotify(r) así como las imágenes son propiedad de sus respectivos dueños, que son de ninguna manera asociada o afiliada con In Motion. Los nombres de productos son utilizados con el único fin de dar a conocer el marco de trabajo ágil con el que In Motion gestiona sus implementaciones de proyectos. El uso de estos nombres no implica ninguna cooperación o respaldo.
 +----