jueves, 7 de diciembre de 2017

Modelo Spotify: Guild (Comunidad) o comunidades de prácticas

Las comunidades de prácticas


Aunque la traducción que se suele hacer de Guild es gremio, prefiero llamarlo "Comunidad". En el modelo Spotify, un Guild es una "comunidad" de interés, orgánica y de amplio alcance. Aunque las comunidades son útiles y pueden usarse al margen del esquema Spotify. 
Una comunidad es una organización de personas que quieren compartir conocimientos, buenas prácticas, herramientas, códigos, iniciativas e ideas, generar capacitaciones, organizar code katas/hackathons, organizar eventos en pos de la misión, ayudar en la construcción de estándares comunes y acuerdos organizacionales. Serían como las "comunidades de práctica" o los grupos de aprendizaje, no necesariamente están en el mismo área de competencia pero mantienen intereses comunes. Una comunidad normalmente no pertenece a una tribu en particular, sino que recorre toda la organización. Y se reúnen exporádicamente o periódicamente, con cierta regularidad, sin ser un equipo fijo ni una estructura formal de la organización. La vida o disolución de una comunidad depende de la participación, cohesión y motivación de sus miembros.


Líder de la comunidad 


Es aconsejable que la comunidad tenga al menos un líder que sea responsable (pueden ser más de uno). Esto hace que sea más fácil seguir el progreso hacia la misión de la comunidad. El líder no es un cargo formal, sino un rol. Tanto la participación, como líder o como miembro, es voluntaria. Hay que tener en cuenta que el líder de comunidad debe ser un líder servicial, quien sostiene la misión y la visión de las respectivas competencias de la comunidad y quien facilita su funcionamiento. También es deseable que el líder sea alguien proactivo y/o un agente de cambio, ya que la comunidad funciona también como mecanismo de mejora continua para hacer aportes de mejora a la organización, generar ideas o liderar alguna innovación. Las principales funciones de un líder de comunidad son:

  • Convocar a las personas. 
  • Agendar las citas y reservar salas.
  • Permitir y promover que personas de diferentes equipos se reúnan de manera fluida y colaboren en un propósito compartido. 
  • Facilitar y/o moderar las reuniones. 
  • Encargarse de alguna administración mínima (seguimiento de temas). 
  • Coordinar a las personas o miembros para que se realicen las reuniones. 
  • Asegurarse que la comunidad tenga una misión clara y visible para todos. 
  • Asegurarse y promover que sea valiosa para los miembros y la organización. 
  • Facilitar puentes o medios de comunicación. 
  • Fomentar y usar prácticas ágiles (como uso de backlog, kanban boards, retrospectivas, etc.).
  • Delegar y generar trabajo en equipo. No debe ser un cuello de botella ni un acaparador. Debe fomentar el trabajo distribuido, colaborativo y formar otros líderes. Debe lograr que la comunidad pueda llegar a funcionar y existir sin él.
  • Germinar una comunidad si ve la necesidad en la organización.

Germinar una Comunidad


Para hacer nacer una comunidad se necesita crear un ambiente abierto y acogedor. No intente estructurarlos o hacerlos excesivamente formales; en principio, deberían ser entidades autónomas, orgánicas, que prácticamente carecen de jerarquía. Una de las mejores cosas acerca de la vida de las comunidades es que serán evaluadas por su comunidad de ingenieros o colegas, por lo que, tan pronto como una deje de cumplir una función, se vuelva redundante o no necesaria, naturalmente se desvanecerá. O también puede ser absorbida por otra comunidad. Es aconsejable que al momento de formación se defina un propósito y/o misión y se de a conocer al resto, invitando a los integrantes de la organización a participar de forma abierta. Preferentemente es bueno comenzar con alguna lista de temas de interés priorizada, acuerdos de trabajo y herramientas colaborativas a usar.

Ejemplos 


Las comunidades pueden ser por capas tecnológicas de desarrollo o especialidad como: Backend Guild, Frontend Guild, QA Guild, UX Guild, DevOps Guild, Iteration Manager Guild (Team Facilitator), Product Owner Guild, Agile Management Guild, etcétera. También por lenguajes: Javascript Guild, Java Guild, etcétera. Por tecnología o prácticas: Continuous Integration, Machine Learning, etc.

Ejemplo de una declaración de comunidad:

Comunidad de Scrum Masters (o Iteration Managers o semejante): 


  • Propósito: Reunir a Facilitadores de Equipos, Iteration Managers y Scrum Masters para capacitarnos y desarrollar mejor el perfil profesional a través de la discusión y el intercambio de conocimientos. Alternamos entre talleres en los que pasamos la hora aprendiendo una habilidad, dinámica o técnica, reuniones regulares donde presentamos lo que hemos estado haciendo y discutimos ideas (sobre métricas, buenas prácticas, calidad, procesos, agilidad, estándares, etc.) para mejorar nuestros procesos de trabajo y empujar la transformación ágil.
  • Mission: Empoderar a los IM para ser agentes de cambio y mejorar nuestra organización y trabajo de los equipos.
  • Objetivos: Compartir conocimiento, prácticas e ideas. Generar iniciativas de mejoras. Unificar criterios y generar acuerdos. Influir en el cambio cultural de la organización hacia una cultura ágil.
  • Métricas: Tener una presentación al menos una vez al mes. Generar al menos una iniciativa mensual. Celebramos algun logro de la comunidad mensualmente.
  • Agenda: Nos reunimos en la sala desiganad de 16:00 a 17:00 cada martes.
  • Herramientas: usamos Trello (Jira, Google Drive, etc.) para administrar nuestro backlog de temas e iniciativas.
  • Dinámica: Generalmente se puede usar un formato de Lean Coffee.




















Publicado por en No hay comentarios:
Etiquetas: ,

viernes, 23 de junio de 2017

Movimiento Ágil: los 4 aspectos claves de la agilidad empresarial



Hoy en día, 'Agile' y la agilidad en general se transformó en un movimiento más allá de Ingeniería de Software y área de producción. En este sentido, el Manifiesto Ágil (textualmente) ya ha quedado algo obsoleto, pero no así su esencia, su corazón. El núcleo esencial ágil se sintetiza en cuatro aspectos claves que pueden aplicarse y guiar las prácticas de cualquier disciplina o proyecto de componente intelectual en cualquier organización empresarial o Sistema Social Empresarial. En el siguiente video esquematizo estas cuatro claves que considero conforma el espíritu del movimiento.

(video del año 2017)




Tengo que recalcar que no inventé nada nuevo. Esto es simplemente la síntesis (que cualquiera puede hacer) del Manifiesto Ágil y la literatura al respecto que fluye en el movimiento ágil. No obstante hace poco rescaté un fragmento de video de Ángel Medinilla, en un meetup de Agilidad y escala, donde sintetiza la agilidad en estos cuatro aspectos claves con los que estoy totalmente de acuerdo y que me alegra que haya alguien que profese lo mismo. Siempre consideré que el movimiento ágil, tanto en la industria de software como en cualquier ámbito empresarial, se resume a estos cuatro aspectos esenciales. El manifiesto ágil está orientado solo al desarrollo de software y por esa razón considero que está algo obsoleto, por lo que algunos intentan brindar alguna otra fórmula valorativa alternativa, como "Modern Agile" o "Heart of Agile", sin embargo pienso que esas ideas no engloban realmente la esencia ágil, no guardan el verdadero espíritu ágil. Y viendo a Ángel encontré, por fin, a alguien que resume tan bien la agilidad y que está en sintonía con algo que hace años vengo fomentando, y es que: estos cuatro aspectos valorativos pueden emplearse en cualquier sistema social empresarial y es lo que constituye el corazón del movimiento ágil.

A continuación comparto el video:



Referencias:

  1. Manifiesto por el Desarrollo Ágil de Software: http://agilemanifesto.org/iso/es/manifesto.html
  2. Ángel Medinilla, meetup agilidad a escala: Conversatorio con Ángel Medinilla sobre Agilidad a escala, incluyendo experiencias reales de los asistentes y perspectivas sobre los marcos de trabajo más conocidos (SAFe, LeSS, Nexus...).





Publicado por en No hay comentarios:
Etiquetas: ,

domingo, 7 de mayo de 2017

Valores ágiles: Mandala Ágil

En estos días (primera semana de Mayo 2017) asistí al Agile Open Camp de Chile 2017. Es un evento diferente, con energía, buena onda y muchas conversaciones interesantes. Fue un espacio para compartir y generar semillas para nuevas ideas.

En algunas charlas interesantes sobre la vigencia del “Manifiesto Ágil” y sus posibles actualizaciones con generalizaciones y simplificaciones, surgieron debates sobre “Modern Agile”, “Heart of Agile” (de Alistair Cockburn) y como se podría mejorar la forma de presentar el Manifiesto Ágil. A mi no me convencía la propuesta de “Modern Agile”, con el agregado que hace de la seguridad como requisito (“Make Safety a Prerequisite”) ni tampoco me cerraba la simplificación propuesta con el “Heart of Agile” con dos incisos muy relacionados como la reflexión y la mejora continua, pero mostrados separados. En consecuencia pensé en hacer una síntesis.

La idea es que la agilidad se ha vuelto excesivamente decorada y el manifiesto, hasta cierto punto, tiene muchos incisos (4 valores y 12 principios) como para ser aprendido fácilmente. Además fue concebido para el desarrollo de software, específicamente, y no para cualquier organización.

Algunas preguntas que me resonaban en esos días fueron… ¿Qué podemos enfatizar para volver al corazón de la agilidad y reinterpretar al manifiesto ágil rescatando lo esencial? ¿Cómo mostrar el corazón de la agilidad de una forma didáctica y simple? 

Respondiendo a estas preguntas, pienso que es bueno tener un mandala, como un escudo, que resuma algunos conceptos claves de la agilidad, sin perder nada del manifiesto. Cuando terminaba el evento “Agile Open Camp” hice un borrador de lo que para mí podría ser un buen mandala (con forma escudo) que muestra cuatro conceptos clave, que cohesionan a los 4 valores y 12 principio. El dibujo que hice (con sharpie en hoja A4) es el siguiente:


Los conceptos clave son:
  1. Collaboration
  2. Delivery (Value Flow)
  3. Adaptation
  4. Improvement

Estos conceptos contemplan a los valores y principios ágiles como comento a continuación:
  1. Factor humano (Colaboración): este concepto abarca a la priorización de "individuos e interacciones sobre procesos y herramientas" y a la "colaboración con el cliente sobre negociación contractual". Ambos valores son necesarios para lograr la colaboración. También sostiene al principio que dice que "los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.". Además para lograr mejorar la colaboración, y con ella un equipo de alto desempeño de trabajo sostenibe, es necesario lograr individuos motivados. La colaboración se da en procesos de autoorganización. Y finalmente para promover la colaboración se prioriza y fomenta la conversación cara a cara y el fortalecimiento de las relaciones humanas dentro de la organización.
  2. Flujo de valor (Entrega): esta es una idea pragmática de operatibilidad. Abarca a "Software funcionando sobre documentación extensiva" donde se amplía a producto funcionando como foco principal por sobre documentación excesiva (de esta manera no se limita a solo software). Se tiene como prioridad satisfacer a nuestros clientes mediante la entrega temprana y continua de un servicio o producto con valor. Las entregas de valor deben ser frecuentes, con preferencia al periodo de tiempo más corto posible. Que las cosas funciones, nuestros productos y servicios, es la medida principal de éxito y progreso.
  3. Adaptación: este abarca a la "Respuesta ante el cambio sobre seguir un plan". Los procesos Ágiles promueven el desarrollo sostenible mediante ciclos de retroalimentación y auto-regulación para manejar el cambio de requisitos y el entorno cambiante. Se busca la adaptabilidad en un proceso sostenible con procesos de auto-ajustar el comportamiento según el contexto cambiante y el continuo feedback del cliente y usuario.
  4. Mejora continua: este concepto incluye la búsqueda de la excelencia, mediante la mejora contínua con etapas de reflexión y acción. También incluye a la simplicidad, como parte de la búsqueda de excelencia, además de que es parte de la ciencia y de la ingeniería.

Pienso que esta síntesis es una buena herramienta visual y conceptual para enseñar agilidad. Recordar estas cuatro ideas se hace muy simple, más si mantenemos visible el mandala en nuestro lugar de trabajo.

El equipo de participantes del AOC...

Referencias:




Publicado por en No hay comentarios:
Etiquetas: ,

jueves, 13 de abril de 2017

Scrumban en DevOps



¿Qué metodología ágil podemos usar en operaciones para que funcione con Equipos de desarrollo Scrum? Pues, podemo usar Scrumban.

Scrumban se trata de una metodología mixta y flexible entre Scrum y Kanban. Combina las la flexibilidad de Kanban y las características básicas de Scrum. Por un lado, se toma de Kanban lo de mantener un trabajo continuo, exponer el flujo de trabajo, el tablero de trabajo persistente, auto-asignaciones de tareas solamente por el sistema del tomar y jalar (pull), limitar el trabajo en curso y buscar optimizar el flujo teniendo en cuenta la métrica “cycle time”. Por otro, se agrega de Scrum la ceremonia de planning (principalmente bajo demanda), la retrospectiva como reunión de mejora contínua (Kaizen), el trabajo en ciclos o iteraciones sin ser limitativo o restrictivo de trabajo y la priorización, que se recomienda hacer en cada planificación. Dentro de la flexibilidad que brinda, hace optativo el usar otras partes o prácticas de Scrum. Bajo esta metodología no es necesario estimar, puede ser algo optativo, ya que no se necesita calcular el trabajo que entra en una iteración porque el trabajo es continuo. Aunque sí se pueden estimar tiempos de entrega y/o tamaños de paquetes de trabajo. Por otro lado, al ser el trabajo contínuo y no tener un compromiso formal de trabajo comprometido en una iteración, los cambios y re-priorizaciones pueden hacerse en cualquier momento. También es muy flexible el tipo de roles de los miembros del equipo debido a que no prescribe roles específicos ni es necesaria la multidisciplinariedad que recomienda Scrum. Además, como se mencionó antes y al igual que en Kanban, el tablero permanece persistente, mientras que sólo cambian las tareas y sus prioridades. A diferencia de Scrum que el tablero de sprint se renueva en cada iteración. Relacionado a la planificación, en Scrumban se planifica focalizados en los releases y no es obligadamente necesario hacerse en la planning de cada iteración; pues, la planificación se puede realizar solo bajo demanda. 

Ámbito de aplicación


 Este método se muy útil principalmente para procesos de ritmo rápido, para startups, proyectos que requieren fabricación de productos constante, equipos y proyectos con ambientes muy dinámicos y cambiantes, equipos de solución de problemas de contingencias en producción, equipos de mantenimiento, soporte o desarrollo de infraestructura. También es útil para integrar (coordinar y sincronizar) otros equipos de soporte a los equipos Scrum, por ejemplo bajo el marco DevOps. En estos casos, los equipos soporte pueden usar Scrumban y los de desarrollo Scrum.


Valores y principios


Los principios principales de Scrumban son: mostrar el flujo de trabajo, cuidarlo y mejorarlo. Aunque para seguir el marco Ágil de trabajo con mindset DevOps se puede usar el manifiesto ágil disciplinado (Ver the Disciplined Agile Manifesto) o tener en cuenta los aspectos principales del manifiesto ágil. También se pueden incluir los valores de Scrum y/o principios Lean. Esto es bastante flexible y depende de cada equipo.

Integración Development con Operaciones


Las transformaciones en la organización clásica de TI a menudo son difíciles; Inicialmente, un pequeño equipo o conjunto de equipos multifuncionales haciendo Scrum, compuesto por desarrolladores y por otro lado equipos de especialistas en operaciones. Para integrarlos bajo el marco ágil no se suele usar Scrum en operaciones, complejiza la coordinación entre Dev y Ops. A lo que sí recurrimos es a Lean, Kanban o Scrumban. Mientras los equipos “Dev Scrum” cubren la demanda de necesidades de negocio de la organización (desarrollando y desplegando), los equipos “Ops Scrumban” cubren la demanda de los equipos Dev para soporte del continuous Delivery, infraestructura u otras dependencias técnicas. Por ejemplo, grupos como Infraestructura o Soporte, gestionan un flujo continuo de solicitudes de los usuarios Devs o de clientes internos de la organización. Estos equipos encuentran difícil calzar su trabajo dentro de iteraciones Sprint de tiempo fijo, con cierta rigidez, cuando su trabajo tiene dependencias que pueden no ser satisfechas dentro de una iteración definida o sus clientes no pueden esperar al final de una iteración para recibir una corrección de software.
 

Roles

Kanban no prescribe roles como títulos pero se sugieren los siguientes [D. A.]:
  1. Service Request Manager o Product Owner: es el encargado de la priorización del backlog y entender las necesidades del cliente. Si el cliente es interno a la organización como el sector de producción, el PO se encarga de tratarlos como stakeholder y ser el único punto de entrada para los requerimientos que hace la organización al equipo.
  2. Service Delivery Manager o Flow Master: es un facilitador (equivalente a un Scrum Master en Scrum). Se encarga de facilitar las ceremonias, el flujo de trabajo y propiciar la mejora continua.

Flujo de trabajo y tablero kanban


Estos equipos pueden usar tableros kanban para exponer sus flujos de trabajo. Estos tableros no necesariamente tienen alta cohesión a un objetivo como si se suele hacer en Scrum. Aunque, sí deben tener objetivos para el trabajo en curso. Estos tableros están más orientados a entrega de soluciones out-come en releases, en vez de tiempo fijos. Deben permitir flexibilidad para adaptarse a la demanda de Dev y de la organización.
(Nota: lo ideal es que en la columna in progress se coloquen los estado del flujo de trabajo)

Métrica


 En Scrumban se usan las métricas de Kanban para medir el valor, proceso y flujo relacionados con el propósito. En este sentido, el rendimiento (Throughput) es el más relevante y se mide a través de indicadores de tiempos de duración promedio de actividades o trabajo sobre elementos. También se usa el Cycle Time, que es el tiempo período requerido para completar un ciclo de trabajo u operación desde que se inició; O para completar una función o tarea desde el principio del trabajo hasta el final (El tiempo total que transcurre desde el momento en que el trabajo se inicia en una tarea hasta su finalización). También se usan herramientas de monitoreo como "Histograma de Lead Time", o de cycle time, y el "Cumulative Flow Diagram" (CFD). El CDF o diagrama de flujo acumulados muestra el total de elementos que están en curso, así como el tiempo que tarda en completarse. La estimación promedio del tiempo de ciclo de avance muestra cuánto tiempo, en promedio, se tarda en completar un elemento. También se puede usar un indicador de eficiencia de flujo: Flow efficiency = [work time / (work time + wait time)] × 100%.

Mejora continua


 En Scrumban se busca tener ciclos de mejora continua y que se pueden implementar mediante reuniones frecuentes de retrospectiva como en Scrum. El foco principal, en la mejora continua, es mejorar el flujo de trabajo prestando atención a los cuellos de botella y a la optimización del flujo de trabajo. Para ello también se buscan resolver impedimentos del flujo y solución de causas raíces.



Referencias:





Publicado por en No hay comentarios:
Etiquetas:

miércoles, 29 de marzo de 2017

System Thinking: Facilitación gráfica sistémica

Facilitación gráfica sistémica


En nuestro pensar conversan constantemente el zorro racional y el colibrí emocional. Y, tal vez, para compensar tanta planificación y frivolidad racional, el agilismo trajo el pensamiento y facilitación visual a la mesa de la ingeniería de software. Pienso que encontrar el equilibrio entre estos dos mundos es inmensamente fructífero en el desarrollo de software. Si nos quedamos entrampados en el pensamiento visual y sus herramientas, como post-its y colores nos podemos perder en el holismo y con él en el desorden. Y no salir de la baldosa de la racionalidad ingenieril nos puede hacer ciegos de la creatividad y cortos en la innovación. El arte es encontrar el camino del medio.


Bajo el marco de la agilidad se emplean las facilitaciones gráficas para traducir conceptos complejos y ayudar a razonar o analizar problemas complejos en un lenguaje visual de palabras e imágenes. Esta estrategia puede ser una manera muy eficaz de resumir y comunicar ideas, permitir a los participantes ver e interiorizar el panorama general de una discusión o presentación y facilitar el análisis de la realidad y de sistemas. Pero considero que las dinámicas divertidas y coloridas no debería reemplazar a la ingeniería ni los post-its reemplazar el modelado de sistemas.

Facilitar gráficamente no debería ser graficar por graficar. Cuando dibujamos, lo que hacemos es modelar. Hacemos una representación simplificada de un sistema en algún punto particular en el tiempo o el espacio destinado a promover la comprensión del sistema real (Bellinger 2004); por tal motivo, hay que tener en cuenta que modelar de una forma acertada, para comprender el sistema real, requiere usar herramientas apropiadas. Sino podríamos llegar a modelar ideas que no se condicen con la realidad, perder tiempo, llegar a problemas que no son causa raíz y/o llegar a soluciones que no lo son y que hasta pueden llegar a ser problemas futuros.

Diagramación y notación


La facilitación gráfica no nos sirve de nada en ingeniería de software (más que como entretención, embellecimiento o apoyo de una conversación) si no usamos “herramientas conceptuales de diagramado” con estándares de notación, “conceptos de sistemas” y herramientas 'ingenieriles'. No es necesario usar lenguaje técnico ni usar los diagramas en forma estricta, se pueden adornar y enriquecer gracias al uso de la creatividad. Pero, a mi criterio, no se debería perder de vista que debemos mantener cierta concordancia con la realidad y el profesionalismo que la disciplina requiere.

A continuación comparto un conjunto de “herramientas conceptuales de diagramado” que todo facilitador gráfico y sistémico podría emplear:


  1. ADL: es un lenguaje de descripción de arquitectura (Architecture Description Language) como lenguaje informático para crear una descripción de una arquitectura de software. Algunas ADL que se han desarrollado son: Acme (desarrollada por CMU), AADL (estandarizada por SAE), C2 (desarrollada por UCI), SBC-ADL (desarrollada por National Sun Yat-Sen University), Darwin (desarrollada por Imperial College Londres) y Wright (desarrollado por CMU).
  2. BD: El diagrama de bloques (Block Diagram) es la representación del funcionamiento interno de un sistema, que se hace mediante bloques y sus relaciones, y que, además, definen la organización de todo el proceso interno, sus entradas y sus salidas.
  3. BPMN: Business Process Modeling Notation. Modelo y Notación de Procesos de Negocio, es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow). Se usan en análisis de negocio y análisis de procesos.
  4. CD: Conceptual Diagram, Concept Map or Concept Draw.
  5. CLD: Causal Loop Diagram. Un diagrama de bucle causal (CLD) es un diagrama causal que ayuda a visualizar cómo las diferentes variables en un sistema están causalmente interrelacionadas. El diagrama consta de un conjunto de palabras, flechas y signo de acusación (acusación directa o inversa). Se usan en dinámica de sistemas.
  6. ER: Entity Relationship Diagram con Entity Relational Model. Diagramar entidades y relaciones para modelar bases de datos en software o entidades en un dominio de datos (Big Data, etc.).
  7. EER: Enhanced entity–relationship model. Diagramar entidades y relaciones.
  8. ERD: Diagrama de entidades de bases de datos (Entity Relationship Diagram (ERD)).
  9. FBD: Functional Block Diagram.
  10. FC: Flow Charts (for control flow).
  11. DFD: Data Flow Diagram.
  12. DDD diagrams: Domain Driven Design.
  13. MMD: Map Mind Diagram.
  14. SBD: Signals Block Diagram.
  15. SC: Structure Chart.
  16. SFD: Stock and Flow Diagrams.
  17. SSADM: Structured Systems Analysis and Design Method.
  18. SIPOC: Supplier-Input-Process-Otputs-Customer. Sirve para modelar sistemas en una perspectiva de Proveedores (Suppliers), Entradas (Inputs), Procesos (Process), Salidas (Outputs) y Clientes (Customers). Usado en análisis de procesos y sistemas.
  19. UML: es un lenguaje de modelado (Unified Modeling Language) visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas de software complejos, tanto en estructura (diagramas de componentes, estructura compuesta, implementación, de objetos, de paquetes) como en comportamiento (diagramas de actividades, comunicación, de secuencia, máquina de estado y de casos de uso). Puede servir para modelar algunos sistemas no software también.
  20. C4 Model (for Software Architecture): El modelo C4 es una técnica de notación gráfica ajustada para modelar la arquitectura de los sistemas de software donde se modelan: context, containers, components y el code. Se basa en una descomposición estructural de un sistema en contenedores y componentes y se basa en técnicas de modelado existentes, como el lenguaje de modelado unificado (UML) o los diagramas de relación de entidad (ERD) para la descomposición más detallada de los bloques de construcción arquitectónicos.
  21. VSM: Value Stream Mapping o mapeo de flujo de material  información. Usado en análisis de procesos y sistemas.
  22. ASME: Diagramas de procesos Norma ASME.
  23. Cursograma: diagrama de ingeniería industrial.
  24. IDEF0: Método de Modelado Funcional IDEF0, diseñado para modelar las decisiones, acciones y actividades de una organización o sistema. Se deriva del lenguaje de modelado gráfico establecido Structured Analysis and Design Technique (SADT) desarrollado por Douglas T.Ross y SofTech, Inc.
  25. Organizadores Gráficos:
    1. VENN: Diagrama de Venn.
    2. Organigrama.
    3. Telaraña.
    4. Mapas conceptuales libres.


¿Qué profesionales suelen necesitar diagramar?


En general la facilitación la puede hacer cualquier persona o profesional que necesita facilitar el entendimiento de un dominio de realidad o analizar sistemas, procesos, comportamientos y estructuras. Por eso son los Agile Coaches o trainers quienes suelen facilitar gráficamente.
Aunque, generalmente, son los Arquitectos de Software (Arquitectos de Soluciones, Arquitectos de Infraestructura y Arquitectos de Big Data), los Modeladores de Datos, los Analistas de Negocio, los Analista Funcionales, Analistas de Procesos y Analistas de Sistemas, quienes profesionalmente se ven en la necesidad de modelar y diagramar.
Espero que te haya servido este post para incursionar en alguna manera de diagramar y facilitar gráficamente lo que deses.


Referencias:



Publicado por en No hay comentarios:
Etiquetas: ,

jueves, 2 de marzo de 2017

Lean: Lean Systems Engineering

Lean para Ingeniería de Sistemas


El MIT llevó a cabo estudios de Toyota Production System, que produjo un enfoque llamado "Sistema de Producción Lean" (Lean Production System, Krafcik 1988; Womack et al. 1990). El desarrollo posterior de "Lean thinking" y el trabajo relacionado en el MIT llevó a la Fuerza Aérea a patrocinar el Lean Aerospace Initiative (Murman 2003, Womack-Jones 2003). Simultáneamente, se utilizaron ideas Lean para reforzar los aspectos de escalabilidad y confiabilidad de los métodos ágiles para el software (Poppendieck 2003; Larman-Vodde 2009) y con el enfoque de Kanban se orientó al manejo de flujo y se ha aplicado con éxito al desarrollo de software (Anderson 2010) desde entonces.

Principios


Considero que Lean a influenciado a ingeniería de sistemas como el pensamiento sistémico ha influenciado a Lean. Para la ingeniería de sistemas, la fuente actual de Lean es “Lean Systems Engineering” y sus principios que son los siguientes:

1. Valor: Guíe el proyecto mediante la determinación de las propuestas de valor de los clientes y otros stakeholders. Mantenlos involucrados y gestiona cambios en sus proposiciones de valor.
2. Organice el flujo de valor: especifique los requisitos del proyecto, la
exploración de espacios comerciales entre las propuestas de valor, evaluación de costos y evaluación de madurez tecnológica, resultando en un plan de proyecto completo y un conjunto de requisitos. Pienso que en ámbitos ágiles esto se debe traducir a realizar un RELEASE PLAN.
3. Flujo: Centre la atención cuidadosa a las actividades de la ruta crítica del proyecto (cuellos de botella) para evitar costosas paradas de trabajo, Incluyendo la coordinación con proveedores externos.
4. Jale (Pull): Tire de las tareas siguientes que se realizarán en función de las necesidades y dependencias priorizadas. Si la necesidad de la tarea no puede ser encontrada, rechace como desecho.
5. Perfección: Aplique la mejora continua del proceso para acercarse a la perfección. Maneje los defectos tempranamente y busque y corrija las causas raíces de los problemas en lugar de sus síntomas.
6. Respeto por las personas: Distribuya la responsabilidad, la autoridad y la rendición de cuentas a todo el personal. Nutrir un ambiente de aprendizaje. Tenga a las personas como los activos más valiosos de la organización (Oppenheim 2011);


Referencias: 
  • Guide to the Systems Engineering Body of Knowledge (SEBoK), 2016. URL: http://sebokwiki.org
  • Murman, E. 2003. Lean Systems Engineering I, II, Lecture Notes, MIT Course 16.885J, Fall. Cambridge, MA, USA: MIT.
  • Oppenheim, B. 2011. Lean for Systems Engineering. Hoboken, NJ: Wiley.
  • Poppendieck, M. and T. Poppendieck. 2003. Lean Software Development: An Agile Toolkit for Software Development Managers. New York, NY, USA: Addison Wesley.
     



Publicado por en No hay comentarios:
Etiquetas:

lunes, 13 de febrero de 2017

Agile: Gamification - Dinámicas De Grupo


A vece, cuando las organizaciones adoptan agilidad y se comienza con dinámicas de trabajo, postits, sharpies, flipchart, dibujos, etcétera, pareciera que volvemos al kindergarten; pero esto tiene sus razones. Y las razones derivan de Game Thinking con Gamification.

Gamification



Gamification (Game Thinking), es el uso de elementos de diseño de juegos, pensamiento y mecánicas de juego para implicar a las personas en alguna actividad con un objetivo [1]. La gamification es bastante usada en entornos ágíles (Agile Game) para ayudar a los cambios culturales, cohesionar equipos y buscar el trabajo colaborativo. En este contexto se refiere al uso de la mecánicas de juegos y recompensas en un entorno de desarrollo de software ágil para aumentar el compromiso del equipo y conducir los comportamientos deseados. También se usa para lograr una cultura creativa e innovadora en la organización. Toda Organización Inteligente necesita mecanismos de creatividad para conducir hacia la innovación y la gamification y las "Dinámicas De Grupo" ayudan a eso.


Dinámicas De Grupo


Parte de la Gamification son las "Dinámicas De Grupo" (Group Dynamics) o "Dinámicas Didácticas Activas" que consisten en dinámicas donde un facilitador propone juegos con determinadas reglas para cumplir un objetivo. En estas dinámicas no necesariamente deben haber ganadores o reconpensas, pero sí se persigue un espacio de juego que funcine como enseñanza práctica y didáctica o consecucion de un objetivo de equipo mediante herramientas visuales (Visual Thinking), creativas (Creative Thinking) o de diseño (Design Thinking).
Una dinámica de grupo tiene como entrada un game con un objetivo, reglas e instrucciones. Un facilitador ayuda a que la dinámica se lleve a cabo, con las personas integrante, cumpliendo el objetivo. Además las dinámicas, por lo general, tienen una estructura compuesta por una etapa inicial de divergencia de ideas (open), una segunda etapa de exploración de ideas (executing) y una etapa de cierre donde se converge en alguna conclusión o resultado según el objetivo del game (close) [2]. Todo el proceso debe cumplirse en un time-box estipulado y para que sea efectiva se debe llegar al resultado esperado (según el objetivo del game).


Cartera de dinámicas


Un facilitador creativo debería contar con una cartera de dinámicas que puede traer a la mano cuando necesite alguna. Algunos lugares donde podemos encontrar dinámicas son:

Conclusión


Hay que recordar que las organizaciones Software Factory que quieren ser inteligentes y apostar a la innovación y al trabajo creativo pueden recurrir al “Game Thinking”, pues más del 50 por ciento de las organizaciones que tienen procesos de innovación los jugarán [1], pero nunca se debe olvidar que no hay que dejar de hacer Ingeniería de Software.


Referencias:
  1. [1] Article: Agile Gamification, Boosting team performance and software development practices using game elements, Davi Gabriel da Silva, ScrumAlliance, 20 August 2014.
  2. [2] Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers. Dave Gray, Sunni Brown, and James Macanufo. O'Reilly, 2010.
Publicado por en No hay comentarios:
Etiquetas:

domingo, 5 de febrero de 2017

Kanban: Las tres reglas básicas del Método Kanban



En este post quería comentar didácticamente las bases del método Kanban. Pues el mismo, es un sistema de trabajo, con una mirada sistémica orientada al proceso de trabajo con el fin de optimizarlo. A "Kanban básico" se lo puede entender por sus tres tres reglas principales:
  1. Mostrar el proceso,
  2. Limitar el trabajo en curso; y
  3. Optimizar el flujo.

Para “mostrar el proceso” de trabajo y sus ítems se suele usar un tablero físico o herramienta digital equivalente con tarjetas representando los ítems de trabajo.

Para “limitar el trabajo en curso” se busca acordar entre los involucrados límites sobre la cantidad de ítems de trabajo que pueden encararse a la vez. A este volumen de trabajo en curso se lo llama WIP (Work in Progress).

Y para “optimizar el flujo” se monitorea y sigue el avance de los ítems de trabajo en el flujo del proceso, para determinar si el progreso sigue un ritmo regular, estable y óptimo. Para ello se usan métricas tales como el Cycle time (Ct), Lead time (Lt) y el Throughput.

Métricas

Las métricas de Kanban provienen de teoría de colas y son las siguientes:

El Cycle time (Ct) es el tiempo de ciclo cuando el trabajo real comienza hasta cuándo está listo para entregarse (tiempo que sucede entre el inicio y el final del proceso, para un ítem de trabajo dado sin los tiemos de cola o espera). El Cycle time es más una medida mecánica de la capacidad del proceso de trabajo del sistema.

El Lead time (Lt) es el tiempo total de espera del demandante o tiempo total de procesamiento de todo el sistema en que una tarea o ítem es introducido en el sistema hasta que el trabajo está completado y es entregado. El Lead time comienza cuando es hecha la petición y termina cuando se entrega el trabajo listo. Ver el siguiente gráfico ejemplo:

El Touch Time (Tt) es la métrica que registra el tiempo en el cual un ítem de trabajo fue realmente trabajado (o "tocado") por el equipo (cuantos días hábiles pasó este ítem en columnas de "trabajo en curso", en oposición con columnas de cola / buffer y estado bloqueado o sin trabajo del equipo sobre el mismo).

La relación entre estas tres métricas es: Tt <= Ct <= Lt

Por otro lado, el Throughput es el rendimiento del sistema de trabajo, como capacidad de producción, que consta de el número medio de unidades procesadas en un tiempo determinado.  O sea que, representa la cantidad de ítems que un equipo puede terminar en un periodo dado, por ejemplo 4 ítems por semana.

Finalmente y complementariamente, para optimizar el flujo, se pueden utilizar diferentes herramientas de análisis como el CFD. El CFD o Diagrama de Flujo Acumulado, es una herramienta que permite evidenciar cuellos de botella mostrando el flujo de trabajo en el sistem según períodos de tiempo. Esta herramienta es muy utilizada en Kanban.

Resumen


En fin, esto es Kanban y lo bajé a un gráfico auto-explicativo.


Quería recordar que Kanban puro es una alternativa a la agilidad o una técnica a sumar en un marco ágil, pero no es ágil por definición. De los cuatro valores del manifiesto ágil, el único que se puede argumentar que si sigue Kanban por naturaleza es el de responder al cambio frente a seguir un plan.

Kanban en Ingeniería de Software


Hay que aclarar que en Ingeniería de Software se usa el "Método Kanban" definido por David Anderson. El mismo agrega tres prácticas más a las básicas anteriores: 
  • Dirigir y gestionar el flujo.
  • Hacer las Políticas (reglas y directrices de su trabajo) de Proceso Explícitas.
  • Utilizar modelos para reconocer oportunidades de mejora.

Además fundamenta el método Kanban en cuatro principios:
  1. Comience con lo que hace ahora.
  2. Se acuerda perseguir el cambio incremental y evolutivo.
  3. Respetar el proceso actual, los roles, las responsabilidades y los cargos.
  4. Liderazgo en todos los niveles.
Y, además, propone los roles de Product Owner y Flow Master (facilitador).



Referencias: 
  • Kanban In Action, by Marcus Hammarberg, Joakim Sunden, Publisher: Manning Publications.
  • Kanban: Successful Evolutionary Change for your Technology Business, by David J. Anderson, Publisher: Blue Hole Press.
  • Blog: Kanban - Definition of Lead Time and Cycle Time.
  • The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen.
  • Kanban, an alternative path to agility by David Anderson.
  • Kanban… ¿realmente es ágil?
  • Anderson, David (septiembre de 2003). Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall. ISBN 0-13-142460-2.
  • Anderson, David (abril de 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press. ISBN 0-9845214-0-2.
    http://web.archive.org/web/http://www.djaa.com/principles-kanban-method 
  • David Anderson "The principles of the Kanban method" December 10, 2010
  • Anderson, David (septiembre de 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press. ISBN 978-0-9845214-0-1.
     


Publicado por en No hay comentarios:
Etiquetas:
Suscribirse a: Entradas (Atom)