Capítulo 5. Las topologías fundamentales.

Capítulo 5. Las topologías fundamentales.

Parte II. Topologías de equipo útiles para el flujo

Lucha de la entrega sostenible de software

Leer más

Topologías fundamentales

Leer más

Equipo alineado a un flujo de valor

Características de los equipos alineados a un flujo de valor

Leer más

Propósito de otros equipos es...

Leer más

Comportamiento de un equipo habilitador

Leer más

Filosofía Lean alineada con la Eficiencia de Flujo

Leer más

Caso ejemplo: Amazon

Leer más

La misión de un equipo habilitador

Leer más

La misión de un equipo de plataforma

Leer más

Equipos Habilitadores

Características de los equipos Habilitadores

Comportamiento de un equipo habilitador

Leer más

Leer más

Equipo de sub sistema complejo

Comportamiento de equipos de subsistemas complejos

Características de los equipos de sub sistemas complejos

Leer más

Leer más

Equipo de Plataforma

Características de los equipos de plataforma

Comportamiento de un equipo de plataforma

Leer más

Leer más

Los equipos de plataforma pueden tomar una forma fractal

Leer más

Evitar crear silos

Leer más

Una plataforma a la medida (A Just Big Enough Platform)

Leer más

Administrar la plataforma como un producto

Leer más

Gestión de incidentes

Leer más

Ejercicio 5

Pasos:

1. Conectar. Compartir organigramas de equipo de tecnología.
2. Conceptos.
3. Presentar organigrama actual
4. Hacer nuevo diseño utilizando topologías fundamentales
5. Comparte con tus compañeros
6. Regístralo en tu LOG de Aprendizaje.
7. Descubrimientos
8. Preguntas
9. Preocupaciones
10. Recursos

Tema. Topologías fundamentales Outcomes:

• Organización actual
• Organización con Team Topologies

Duración: 60 minutos (dos rondas)

1. Tratar la plataforma como un sistema de producción en vivo, donde los downtimes son planeados y administrados.
2. Donde se utilizan técnicas de administración de productos y servicios.
1. Horas de operación
2. SLAS para gestión de incidentes
3. Gestión de downtimes (MTTR).
4. Los principales clientes de la plataforma son los equipos de producto.
5. La plataforma necesita un roadmap influenciado por las necesidades de los usuarios (los equipos de desarrollo - User Personas).

• Fuerte colaboración con equipos alineados a un flujo de valor
• Un equipo de plataforma descansa sobre técnicas de prototipado rápido, para un rápido feedback.
• Fuerte foco en la usabilidad y confiabilidad de sus servicios y aptitud para el propósito.
• Consume otros servicios de plataforma.
• Entiende que la adopción de un servicio de plataforma tiene una curva de aprendizaje.

• Comprender las necesidades de los equipos alineados a un flujo de valor
• Establecer checkpoints y acordar cuando se requiere colaboración
• Estar delante de la curva de conocimiento para probar nuevos enfoques
• Son mensajeros de buenas y malas nuevas
• Actúan como un proxy para servicios externos o internos
• Actúan como guardianes del conocimiento (curators)

• Mejora continua de su expertise​
• Formado de especialistas en un dominio técnico o de producto
• ​ Ayudan a cerrar brechas de capacidades ​
• Tiene ancho de banda para investigar, hacer experimentos y hacer sugerencias informadas sobre prácticas, herramientas, frameworks y ecosistemas acerca de las aplicaciones del stack.​
• Colaborativos por naturaleza, ellos ayudan a entender los problemas de los equipos. ​
• Jutta Eckstein los llama Equipos Técnicos de Consultores”​
• Ayudan a los equipos enfocados al flujo a enfocarse en el problema, no en la solución.​
• No debe haber dependencia de un equipo habilitador.
• ​ La transmisión de conocimiento entre un equipo habilitador y uno alineado a la corriente puede ser temporal o de largo plazo.

Los equipos de plataforma en compañías muy grandes pueden conformarse de todos los otros tipos de topología fundamentales: alineados a la corriente, habilitadores, de subsistema complicado y de plataforma. Así es una plataforma para otra plataforma. Esto crea un efecto anidado o de fractalDentro del equipo de plataforma hay varios equipos de plataformas subyacentes que lidian con la red, los ambientes, las métricas, etc. y que colaboran a su vez para proveer el servicio a otros equipos de plataforma.

• Son responsables de construir y mantener sistemas que dependen de conocimiento altamente especializado.
• Reducen la carga cognitiva de equipos alineados a la corriente trabajando en sistemas que incluyen subsistemas complicados.
• Ejemplo de ello: video processing codecs, modelos matemáticos, algoritmos de conciliación en tiempo real..

En 2002 Jeff Bezos adoptó los equipos altamente independientes mediante un memo:

• Cada equipo es responsable por operar su propio servicio. Cada servicio puede ser uno o más características de Amazon o AWS.
• Cada servicio provee un API para uso interno y externo, los equipos NO interfieren en hacer supuesto de arquitectura para tecnología de otros equipos.

• Provee estándares, templates, apis, y buenas prácticas privadas para que los desarrolladores puedan usarlas para innovar rápida y efectivamente.
• Reducen la complejidad de todos los sistemas subyacentes mientras exponen funcionalidad para ser utilizada por equipos
• Está construida para los desarrolladores (buena UX / DEVEx).
• Puede ser solo una Wiki (Plataforma Mínima Viable)
• Una plataforma más grande requiere un equipo más robusto.
• Requiere una fuerte administración del producto para ser lo justamente necesario.

• Una plataforma digital es la base para el autoservicio de APIs, herramientas, servicios, conocimiento y soporte y está organizado como un producto interno atractivo.
• Los equipos alineados al flujo de la cadena de valor fácilmente consumen y adoptan los servicios de plataforma que son confiables, usables y aptos para el propósito.
• El valor aportado por un equipo de plataforma puede ser medido en función del valor que proveen a otros equipos.
• Una plataforma puede proveer distintos niveles de servicio.

• Flujo estable
• Ajustes rápidos basados en retroalimentación
• Experimentos rápidosIdealmente sin cambiar de manos (no hand-offs)
• Tiempo y espacio para realizar labores de calidad (slack - holgura)
• Contacto regular con los otros tipos de equipo
• Los miembros pueden alcanzar autonomía, maestría y propósito (Daniel Pink).

• Flujo continuo requiere claridad de propósito y responsabilidad
• Un equipo alineado el flujo o un solo un flujo de trabajo
• Un servicio o producto
• Un conjunto de features
• El journey de un usuario
• Una persona
• El equipo está empoderado para construir y entregar valor
• Rápido
• De manera segura
• De manera independiente
• Sin requerir pasar a otro equipo parte del proyecto

Cuando existe un incidente en producción, los equipos de soporte generalmente tratan de resolverlo solo dentro del stream. Si el problema se encuentra dentro del stream, no hay necesidad de involucrar a alguien más. Si es necesario, otros equipos estarán alineados con equipos que participan en el problema para diagnosticar. Si los incidentes afectan a muchos equipos un enjambre dinámico o un escuadrón de incidentes de especialistas en soporte se forman de varios equipos de soporte para hacer triage del problema y restaurar el servicio tan rápidamente como sea posible.

• Las organizaciones tradicionales se agrupan por expertise funcional como:
• Aseguramiento de la Calidad
• Administración de Bases de Datos
• Experiencia de Usuario
• Arquitectura
• Procesamiento de Datos (ETL)esto crea silos que limitan el flujo de valor.
• En su lugar los stream aligned teams funcionan de mejor manera.