Theba Gomez

Embajadora de los Guilds en Open Source Weekends &

Desarrollo de personas, equipos y organizaciones con Design Thinking, coaching, creatividad y metodologías ágiles.

Diseño de proyectos de CX y Transformación Cultural.

Instructor @Fictizia

#FutureJuniorDeveloper

Ulises Gascón

Desarrollador Full Stack y orgulloso co-organizor de la comunidad Open Source Weekends (OSW)

Colaborador activo en la Comunidad Open Source

Trabaja como freelance, además de ser profesor en Fictizia.

¿Cómo hemos evolucionado?

Sociedad

Economía

Religión

Evolución > > nuevas formas de agruparse para trabajar

Visión del mundo

Conciencia Predominante

10.000 ac - actualidad

Ejércitos conquistadores, proto imperios

Sociedad/Organizaciones impulsivas/rojas

Impulsivo / Rojo (10.000 a.c./...)

Organizaciones rojas:

• Cohesión gracias a ejercicios de PODER
• Líder: atemoriza, compra lealtad
• Sin jerarquía formal ni puestos de trabajo
• No escalables - pérdida de poder e influencia
• Baja estrategia, alta reactividad

4.000 ac - actualidad

Iglesia Católica, ejército, Gobiernos...

Sociedad/Org.

Conformista/Ámbar

Conformista/Ámbar (4.000 a.c./...)

Organizaciones ámbar:

• Busca el control con jerarquías, burocracia, organigramas
• Más estrategia, L/P, escalabilidad con procesos
• Sucesión ordenada, mundo predecible (no acepta el cambio)
• "Se piensa en la cima, se ejecuta en la base"
• Medidas disciplinarias no cumpliendo las normas

S. XIX ac - actualidad

(Casi) Todas las empresas, Bolsa(s)...

Soc./Org. Naranja/Logro

Logro / Naranja (Ilustración /...)

Organizaciones naranja:

• El cambio es una oportunidad; innovación |predicción y control | meritocracia
• Impulsadas por procesos y proyectos
• Jerarquías con cierta flexibilidad: equipos de proyecto...
• Gestión por objetivos; acceso a la información +horiz.
• Órdenes en cascada
• Motivación: éxito material (se inventa premios)

S. XIX - actualidad

(Algunas) empresas, ONGs, activismo comunitario...

Soc./Org. Verde/Pluralista

Pluralista / Verde (s.XIX /...)

Organizaciones verdes:

• Rompen con jerarquías y estructuras
• Decisiones de forma igualitaria
• Empoderamiento y descentralización: decisiones horizontales y basadas en el propósito
• (primordial) Cultura impulsada por valores y propósito
• Perspectiva de múltiples grupos de interés
• Negocio = responsabilidad social y medioambiental

Evolutivo/TEAL

Organizaciones TEAL:

• Cuanto más compleja es la visión del mundo y la cognición, con mayor eficacia podemos enfrentarnos a los problemas.​
• Relación con el poder: la confianza reemplaza al miedo
• Plenitud y comunidad

• Apoyarán el anhelo de la gente a ser ell@s mism@s en el trabajo y de estar involucrados en relaciones enriquecedoras

¿Cómo hemos evolucionado?

Tipos de líderes 

Modelo Cynefin

Ordenados/

predecibles

Sin predictabilidad

Categorizar

Analizar

Experimentar

Actuar

Cultura!

Predecible

Explotación

• Obvio
• Rígido
• Plano
• Control

• Complicado
• Rígido
• Jerarquía
• Competitivo

Incremental

S/T Perf.

Descubrimiento

L/T Develop.

• Creativo
• Horizontal
• Redes
• Complejo

Exploración

• Libre
• Comunidad
• Colaborativo
• Caótico

Impredecible

Imprescindible lectura!!

La era no Agile

Waterfall

Waterfall - Claves

• Solo se trabaja en un etapa a la vez
• A más avanza el proyecto más complejo es la modificación de los requisitos
• Método muy criticado por la industria y círculos académicos
• Muy extendido por el mundo

Waterfall - Criterios

Lo bueno

• Fácil implementación en los equipos
• La base es la documentación
• Definir antes de diseñar, diseñar antes que programar

Lo malo

• Pocos proyectos siguen un desarrollo lineal
• Es un proceso lento y demasiado secuencial
• Si necesitamos un rediseño... los costes de cambiar son muy altos

Agile y sus cosas!

Cultura Ágil y otras cosas

No hay nada intrínsecamente “mejor” en el hecho de estar en un nivel más alto de desarrollo, así como un adolescente no es “mejor” que un niño pequeño. Sin embargo, un adolescente puede hacer más cosas porque puede pensar de manera más sofisticada que un niño pequeño. Cualquier nivel de desarrollo está bien; la pregunta es si ese nivel encaja bien con el trabajo al que nos enfrentamos.

                                                                                  NICK PETRIE

Origen Agile 

Entornos inciertos, no predecibles, con necesidades cambiantes...requieren mayor flexibilidad de toma de decisiones

Reacción a la falta de soluciones a problemas históricos de desarrollo de proyectos

Agilidad =

APREDER MÁS Y MÁS RÁPIDO

FLEXIBILIDAD

ADAPTACIÓN

SIMPLICIDAD

...nueva forma de pensar y actuar!

...nueva forma de pensar y actuar!

¿Quieres compartir qué significa para tí tener "una nueva forma de pensar y actuar"?

Enfoque Agile 

...nueva forma de pensar y actuar!

Recursos

Fechas

Requisitos (implementar la funcionalidad +valiosa para usuarios)

Fijado

Estimado

¿¿Y cómo se consigue??

• ​Colaboración + comunicación constante
• Trabajo por iteraciones e incrementos
• Equipos auto-organizados
• Experimentar a pequeña y múltiple escala
• Despejar incertidumbre (p.ej. prototipos)
• Orientación a ayudar 

• APREDER MÁS Y MÁS RÁPIDO

• FLEXIBILIDAD

• ADAPTACIÓN

• SIMPLICIDAD

Agilidad =

...y con mil soluciones de gestión

Lean 

StartUp

DSDM

...y qué sucede con su adopción?

Enfoque 

táctico

No Buy-in

No venimos

"de serie"

Intereses

personales

Resistencia

al 

cambio

Desconoci-miento

práctica

Liderazgos

anticuados

...y tí, ¿por qué te gusta Agile?

Integración

sencilla

miembros

Pequeñas 

victorias

Soluciones

rápidas

Cliente y 

equipo

unidos

Entregas

aseguradas

Aprendizaje

sobre la 

marcha

....

El manifiesto

Estamos descubriendo formas mejores de desarrollar
software, tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:

... y sus 12 principios (framework)

Predicción vs Adaptación

Predicción:

• Cascada
• Control
• Condiciones cerradas
• Pésima gestión de cambios

Adaptación:

• Aprendizaje incremental, iteraciones!
• Estimaciones 
• Óptima gestión de cambios

Enfoque ágil de personas

Peopleware >> (vs Hardware vs Software) "El éxito de los proyectos lo determinan las personas. 

"Implementar las best practices del desarrollo del software Open Source en organizaciones de enfoque privativo << Inner Source

Equipos ágiles >> multi-funcionalidad, auto-organización + creatividad + motivación + habilidades personales + comunicación 

Holocracia >> "Sistema organizativo horizontal con equipos auto-organizados y adaptativos.

"Nuevas prácticas de liderazgo << Management 3.0.

Colaboración - Comunicación - Meritocracia - Auto-organización...

Horizontalidad - Host or servant leadership - Toma de decisiones descentralizada

Múltiples roles (adaptativos) - estructuras de círculos -  proceso de gobierno - acción e innovación

Adaptación al cambio

Visión compartida y

trasversal

Aprendizaje

iterativo

Equipos auto-organizados

Enfoque (cultura)

horizontal

Espacios para la reflexión, mejora y comunicación

Conocimiento producto y usuarios

Aporte de valor al usuario

Foco en la Calidad

Scrum y sus cosas!

Métodos ágiles y prácticas

Scrum, ¿me lo puedes resumir?

Scrum y Kanban sirven como procesos de gestión; en el caso de desarrollo de software, hay que seguir unas buenas prácticas de programación, como las que ofrece XP

Scrum propone un marco de trabajo basado (fundamentalmente) en que los equipos se auto gestionen y en iteraciones o Sprints

Scrum es el método ágil más aplicado y con más elementos aplicables. 

Scrum, ¿me lo puedes resumir?

Principios:

• Inspección y Adaptación: iteraciones, análisis, mejoras!
• Auto-organización y colaboración: responsabilidad y compromiso!
• Priorización de los requisitos
• Mantener el ritmo de desarrollo. Optimización, predictabilidad, estimación, fechas clave!
• Iteraciones: planificación, análisis, creación y comprobación de entregas

Scrum: flujo de trabajo resumido

Scrum: flujo de trabajo resumido

Product Owner (rol)

• Responsable desde el punto de vista del negocio.

• Intermediario entre equipo y Stakeholders

• Gestiona el Product Backlog

Sprint 0 (viabilidad?)

• Recursos y marco temporal (fechas entrega, releases...)
• Herramientas, procesos...
• Hªs de usuario: priorización y criterios de cumplimiento
• Entregable: P. Backlog

Product Backlog

• Define el amplio trabajo del proyecto con detalle
• Temas, épicas e historias de usuario y prioriza 
• Criterios que definan ya cumplido

Scrum: flujo de trabajo resumido

Sprint Planning Meeting, Scrum Master y Equipo

Scrum Master (rol)

• Facilitador del trabajo
• Responsable del proceso
• Aplica las mejores prácticas y mejorar el trabajo en equipo
• Identifica puntos de mejora y ayuda a resolver conflictos

Equipo (auto org.) (rol)

• Ejecutan el trabajo

• Responsables técnicos

• Preocupados por mejoras de Calidad y Productividad

Sprint Planning Meeting

• Estimación requisitos P.B.

• Alcance Sprint

• Historias de usuarios > tareas!

• Entregable: Sprint Backlog!

Scrum: flujo de trabajo resumido

Sprint Backlog

• Definición del trabajo a desarrollar
• Viene del S. Planning en base al P.B. y sus prioridades
• Responsabilidad del equipo y SM
• Incluye las tareas en lenguaje técnico (subdiv. de las historias de usuario) realizables por 1 persona entre medio y 3 días
• Impediment Backlog: la pila de impedimentos

Scrum: flujo de trabajo resumido

Duración Sprints y Burndown Chart

Burndown Chart

• Evolución del trabajo durante el Sprint
• Herramienta visual evolutiva

• X=Horas; Y=días (calendario)

Duración Sprints

• Entre 2 y 4 semanas
• Fechas y tareas fijas

Scrum: flujo de trabajo resumido

Daily Meetings, Review y Retrospectiva

Daily Meeting (SM facilita)

• Sincronización diaria trabajo durante el Sprint (fin, comienzo, impedimentos...)
• Reuniones ágiles - 10/15mins

• Busca mejorar la comunicación

Sprint Review

• Revisión resultados Sprint - EL QUÉ
• Resultados visibles; criterios de aceptación
• PO determina la realización

Retrospectiva (+++)

• Revisión de CÓMO hacemos las cosas
• Foco en la mejora del proceso

• Rev. evolución, objetivos, dificultades, mejoras, soluciones..

Scrum: Backlogs 

Scrum: Velocidad y estimaciones

Eventos para revisión y reflexión

(Weekly)

(Weekly)

Reviews

(nuevo)

P.B.

(nuevo)

Planning +

Sprint B.

Sprint

Planning

Retros

pectiva

Sprint B.

Planning

Reviews

Retros.

Scrum: valores que adoptaremos

• Mejora continua: identificar continuamente el área de mejora
• Calidad: nunca sacrificar antes que plazos y costes
• Time-boxing: aprovechar el tiempo en reuniones (p.ej.)
• Responsabilidad compartida siempre. Sin ella, no hay auto gestión
• Multidisciplinar: equipo autónomo para todas las tareas del proyecto
• Flexibilidad ya que los requisitos pueden cambiar
• Ritmo adecuado, que favorece la previsión, estimación, MOTIVACIÓN...
• Compromiso, confianza y autonomía hacia el proyecto
• Simplicidad que facilita el proceso presente y futuro
• Respeto; Scrum se centra en las personas y sus relaciones
• Valentía para tomar decisiones con autonomía
• Foco: es importante trabajar para mantenerlo!
• Predictabilidad: con el objetivo de valorar la cantidad de trabajo fácil
• Personas: Scrum trata de favorecer su comunicación y lograr relaciones fluidas

Scrum: valores que adoptaremos

• Revisión del trabajo para favorecer la calidad del mismo
• Colaboración, imprescindible para el trabajo en equipo
• Contar con el cliente: se integra en el trabajo del equipo
• Iteraciones o ciclos cortos para resolver problemas rápidamente
• Priorización: qué es realmente importante y asignar relevancia
• Trabajo en equipo: uno de los valores supremos!
• Generosidad
• Comunicación
• Capacidad y disposición a aprender

Kanban: la herramienta visual

• Se fundamenta en principios Lean
• Se centra en eliminar desperdicio

Priorización de items

Criterios

de actuación

Eliminación

cuellos de 

botella 

• Identificar cuello de botella
• Investigar restricción
• Subordinar todo lo demás
• Eliminar restricción
• Volver al paso inicial

Kanban: la herramienta visual

• Visualiza todo el flujo de trabajo
• Estado de cada item
• 1ª columna - Backlog Producto
• Dividir el trabajo en items pequeños
• Limitar el nº de items (WiP)
• Tiempo para completar el ciclo

Kanban con GitHub

XP y sus cosas!

Historia XP

• Gestación años 80 + nuevas incorporaciones (TDD)
• Novedad: aplicar prácticas de forma simultánea y con re-alimentación
• Ciclo:
  • Planificación
  • Análisis
  • Diseño
  • Desarrollo
  • Pruebas
  • Despliegue 
• Iteraciones semanales

Despliegue frecuente + generación de funcionalidad completa por iteración

Ciclo de vida

XP 

• Obj. principal: desarrollar software con menos defectos, más barato y de forma más productiva
• Método adaptativo
• Desarrollo de código que permite fácilmente añadir nuevas funcionalidades
• Trabaja con pequeñas iteraciones > feedback frecuente!
• Forma incremental
• Pruebas como base de la construcción: rápidas, frecuentes y automatizadas
• Detención de fallos rápidamente

La aplicación de XP depende más de las personas implicadas que del tipo de proyecto

Scrum y XP 

Combinamos ambos frameworks para que el resultado sea óptimo

Scrum - framework de gestión organizativa equipo y proyecto

XP - framework para mejorar las prácticas de programación y desarrollo

Valores comunes:

• Revisión del trabajo
• Colaboración, respeto, valentía 
• Implicación directa del cliente
• Simplicidad
• Iteraciones/ciclos cortos
• Priorización

Lean y sus cosas!

Lean: de la fabricación a la programación

• Fabricar sólo lo necesario

• Cero defectos 

• Eliminar el desperdicio

Lean: de la fabricación a la programación

Mejora continua:

Uno de los elementos + importantes del manifiesto ágil. 

Acción pro activa para experimentar e identificar nuevas mejoras sin miedo a equivocarse, sin culpables.

Es una mentalidad 

Lean Software Developement

• Reducir drásticamente el tiempo de entrega de un producto 

• Reducir su precio 

• Reducir nº de bugs - mejora calidad

Lean Software Developement

 Principios: 

• Trabajo a medias
• Funcionalidades/código innecesarias
• Burocracia excesiva 
• Defectos 
• Esperas y pérdida de foco

• Feedback, comunicación
• Iteraciones cortas
• Sincronización  

Lean Software Developement

 Principios: 

• Contar con + información
• Aprender/investigar antes de decidir
• Mantener opciones abiertas
• Análisis de opciones y alternativas
• Valoración de impacto y consecuencias

• Entrega y feedback rápido!
• Pull system, tª colas, tareas fragmentadas...

Lean Software Developement

 Principios: 

• Responsabilidad
• Toma de decisiones
• Foco: aprendizaje y autonomía
• Participación e influencia en el proyecto

• Integridad percibida -usuario/necesidad/mercado
• Integridad conceptual - cómo se ha construido (refactorización, testing)

Lean Software Developement

 Principios: 

• Visión global del producto 
• Optimización de todo el conjunto
• Org. por objetivos o proyectos (vs org. funcional)
• Mayor sentido de control, propiedad, responsabilidad

Claves

Nuevo Entorno

Básicos

• Repositorio
• Tracking
• Commits
• Sincronizar cambios
• Ramas
• Fork
• Clonación
• Pull-request
• Gestión de merges
• Gestión de permisos

Configuración

Workflow

Workflow Simplificado

Merges

Merges

Manual merge

Fast-forward (automatizado)

No hay conflicto alguno

Branches (Ramas)

Branches (Acción)

Tools

Más...

Recursos

Github

Github Guide: Managing Projects

Muchas herramientas

• Markdown
• Readme.md
• Issues
• Pull Request
• Labels
• Millestones
• Projects
• ...

Básicos

• Es una red social

• Markdown

• Socializacion

• Colaborar

• Compartir

• Gist

• Issues

• Pages

• Wikis

API

• https://api.github.com/users/{user}

• https://api.github.com/users/{user}/orgs

• https://api.github.com/users/{user}/events​

• https://api.github.com/users/{user}/repos

• https://api.github.com/repos/{user}/{repo}

• Documentación

• Git Awards

Recursos

• Github Help
• Github Videos
• Guide: Hello World
• Guide: Understanding the GitHub Flow
• Guide: Getting your project on GitHub
• Guide: Getting Started with GitHub Pages
• Guide: Be Social
• Guide: Forking Projects
• Guide: Mastering Issues
• Guide: Making Your Code Citable
• Guide: Documenting your projects on GitHub
• Guide: Mastering Markdown

Proyectos reales

• electron/electron: Build cross platform desktop apps with JavaScript, HTML, and CSS
• tensorflow/tensorflow: Computation using data flow graphs for scalable machine learning 
• tastejs/todomvc: Helping you select an MV* framework - Todo apps for React.js, Ember.js, Angular, and many more
• serverless/serverless: Serverless Framework – Build web, mobile and IoT applications with serverless architectures using AWS Lambda, Azure Functions, Google CloudFunctions & more!
• nodejs/node: Node.js JavaScript runtime
• atom/atom: The hackable text editor
• twbs/bootstrap: The most popular HTML, CSS, and JavaScript framework for developing responsive, mobile first projects on the web.

Un changelog

¡Ejemplo de Nodejs!

Equipos auto-organizados

Los roles de Scrum son funcionales,

no jerárquicos!!

Carácter + ísticas ;) 

• Son la nueva era de los equipos - orgs. Pluralistas/ Verdes y Teal
• Son el paradigma de la agilidad
• Horizontalidad
• Comparten propósito y motivación
• Aprenden de ell@s mism@s y por ell@s mism@s
• Se auto-organizan/planifican/desarrollan/crecen juntos
• Acuerdan cómo funcionar (procesos, herramientas, planificación...)
• Se conocen, se ayudan, colaboran!
• Son multi-funcionales

Equipo auto-organizado

• Ejecutan y entregan el trabajo

• Responsabilidad final sobre el trabajo y su éxito

• Asumen cualquier actividad de desarrollo

• Preocupados por mejoras de calidad y productividad

• Auto-asignación de tareas

• Mejora continua

• Diversificado (cross-funcional)
• Motivación
• Compromiso
• Responsabilidad
• Toma de decisiones 
• Valentía, colaboración...
• Autonomía y auto-organización (no jerarquías)
• Estable y dedicado 
• Anticipación

Equipos motivados

• Ponen su creatividad a funcionar para buscar alternativas comunes (Def. problema - encuentran soluc. - construyen!)
• Las planifican visualmente para encontrar mejor las soluciones
• Tod@s l@s miembros comparten su punto de vista
• Buena escucha y comunicación!
• Valoran las alternativas sin caer en un análisis aburrido
• Cada miembro del equipo se conoce bien: quién es, qué se le da bien, qué dificultades tiene, cómo integrarle en el grupo...
• La mejor decisión > tiene que ver con el propósito común (ver la peli XD) o con el fin de mejorar la vida del usuario (en los Guilds ;))

Motivación - ¿Cómo trabajarla?

IMPORTANCIA > mi aportación tiene impacto en la creación de algo mayor

IDENTIDAD > formo parte de un proyecto que sé a dónde se dirige y cuál es el resultado, y la mejora de la vida de las personas

AUTONOMÍA > como equipo tenemos autonomía para tomar decisiones sobre el proyecto, experimentar, crear...

HABILIDADES VISIBLES > aporto con mis mejores habilidades, con mis fortalezas, y si no lo son, yo decido si las aprendo o desestimo

FEEDBACK > recibo y doy feedback adecuado y que haga crecer

(adaptación) Modelo Hackman&Oldham

Management 3.0.

Management 3.0.

Imprescindible para una óptima gestión y adaptación al cambio

Management 3.0.

Evolución de los paradigmas de gestión para facilitar la creación de nuevos sistemas, entornos, organizaciones, implementación de metodologías/frameworks...

Evolución

• Supervisión
• Control horarios
• Competitividad individual 

• (aún) Organización funcional
• Grandes jerarquías
• (aún) No grandes cambios

• Visión orientada a personas y equipos
• Estructura orientada
• Servant/host leader

Tablero de delegación

Equipos y Líderes - Ej. Spotify

Spotify Engineering Culture

Modelo Kniberg

Open Source

Por qué Open Source

• Motivación real con y hacia el proyecto (su misión) 
• Mejor calidad de código y software
• Incorpora las prácticas más modernas de desarrollo
• Open Source is the future! (eso lo sabemos tod@s! :))
• Mantainers: los líderes de la industria?
• Tus repos y commits: la mejor entrevista técnica 
• El software salva vidas; y si es eficiente, muchas más!
• A mí lo que me gusta es generar ideas!
• El corazón del Open Source tiene pilares morales fundamentales
• Software: úsalo, estudialo, modificalo, re-distribuyelo, comparte tus modificaciones!
• Obligación de dar: la Regla de Oro!
• El aprendizaje de la próxima generación
• ...Why Open Source by Ben Balter
• ... Open Source (Almost) everything 

Dificultades

• Caos generalizado a la hora de saber qué se hace y qué necesidad se resuelve
• Proyectos cuyo cliente final es desconocido o no existe
• Falta de compromiso por parte de los contributors
• Dificultades para adquirir voluntari@s
• Ecosistema altamente volatil y muy mediatizado
• Tiempo dedicado por los miembros varia enormemente
• Bajo o nulo presupuesto sin patrocinadores
• Dificultad para mantener las contribuciones y organizar el código
• Problemas para difundir lo que se hace y como se hace
• Barrera de entrada proporcional al tamaño del proyecto
• Dificultades para no-iniciados

Agilismo y

Open Source

¿Con que nos quedamos?

Nuestra deconstrucción

El proceso que adaptamos:

• NO somos Scrum ni nada estrictos
• Somos Agile a nuestro modo :-D
• Un weekly review es mejor que un daily
• Sprints de un mes, que coinciden con OSW
• Demo time en comunidad con presentación y debate con usuari@s
• Sprints y Backlogs

Fast implementation

¿Cómo organizarnos?

1.  Fases del proyecto al estilo OSWeekends

2.  Elementos de un proyecto

3.  Mecánicas de trabajo

Fase: Sprint 0 (Zero Code)

Objetivos:

• Analizar una Idea/Necesidad/petición...
• Pensar una solución/producto tecnológico
• Definir las funcionalidades con perspectiva técnica (backlog técnico de producto)
• Entregamos un Readme.md, backlog.md y pitch del proyecto

Esta primera fase es la que nos ayuda a definir qué es lo que necesitamos para empezar a trabajar en el proyecto.

El objetivo principal es asentar la bases del producto y resolver las cuestiones técnicas generales, dejando todo documentado en el proceso.

Fase: Sprint 1 (Fast MVP)

Objetivos:

• Actualizar documentación (readme, backlog, etc..)
• Crear un Milestone (deadline)
• Generar y resolver los Issues del sprint con detalles, asignados y etiquetados
• Pedir Feedback (Demo day, presentación, etc...)

Esta segunda fase es la que nos ayuda a validar que lo que estamos haciendo tiene sentido y que estamos resolviendo un problema real con nuestr@s usuari@s.

El objetivo principal es crear una versión mínima viable del producto, que probablemente pivote o sea descartada posteriormente.

Fase: Sprint n+1 (template)

Objetivos:

• Procesar feedback (feature request + bugs)
• Listar y resolver bugs
• Actualizar documentación (readme, backlog, etc..)
• Crear un Milestone (deadline)
• Generar y resolver los issues del sprint con detalles, asignados y etiquetados
• Pedir Feedback (Demo day, presentación, etc...)

Esta plantilla de trabajo se extenderá a los próximos sprints que hagamos.

El objetivo principal es añadir nuevas funcionalidades en nuestro producto y resolver bugs, por supuesto presentando resultados en cada iteracción.

Elemento: Readme.md

Template actual

Elemento: CONTRIBUTING.md

Template actual

Elemento: Issues

Contamos con una plantilla automática para notificar bugs.

Template actual

Elemento: Milestone

Un milestone agrupa los issues de un Sprint y establece un deadline que será siempre 1 día antes del próximo OSW

Mecánicas: Markdown

Github Guides: Mastering Markdown

Mecánicas: Git Flow

Mecánicas: Projects (kanban)

Recomendaciones 

A nivel de negocio: 

• Foco principal: el cliente
• Producto/servicio: mejora continua
• Nuevas métricas
• Gestión del cambio
  • Apoyos!!!
  • Comunicación
  • Seguimiento
  • Fases de adopción
• Herramientas técnicas (programas, Cloud...)
• Procesos
• Estructura organizativa

CULTURA!!

Recomendaciones 

A nivel de metodologías: 

• Análisis de la mejor metodología
• Nuevos perfiles (Agile coach, Product Owner, Scrum Master, equipo multifuncional (12p.max)...) 
• Formación y consultoría
• Adopción y retrospectivas (follow-up)
• Confianza de todos los stakeholders
• Adaptación del espacio de trabajo
• Cliente cercano
• Aplicación real de las prácticas de trabajo!!
• Resiliencia y confianza

CULTURA!!