Work. 4: Scrum y Cultura de equipos en proyectos Open Source
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
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.
Apúntate para ser Guilder! guilds.osweekends.com
Nuevo portal para Guilders! guilds.osweekends.com
Presentaciones de los Guilders durante el Hackaton!! - '15 mins - temática libre - ¿¿quién quiere practicar??
GitHub for Education como Sponsor!
Pronto, pronto...
Recursos (en inglés)
Student developers packs
y pegatinas!!
Ponentes
Visibilidad de los Guilds
Otros programas de GitHub
Entornos inciertos, no predecibles, con necesidades cambiantes...requieren mayor flexibilidad de toma de decisiones
Agilidad = adaptación y resiliencia
...nueva forma de pensar y actuar!
...nueva forma de pensar y actuar!
...nueva forma de pensar y actuar!
Recursos
Fechas
Requisitos (implementar la funcionalidad +valiosa para usuarios)
Fijado
Estimado
Lean
StartUp
DSDM
Enfoque
táctico
No Buy-in
No venimos
"de serie"
Intereses
personales
Resistencia
al
cambio
Desconoci-miento
práctica
Liderazgos
anticuados
Integración
sencilla
miembros
Pequeñas
victorias
Soluciones
rápidas
Cliente y
equipo
unidos
Entregas
aseguradas
Aprendizaje
sobre la
marcha
....
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:
🔝 Más importante | 👔 Menos importante |
---|---|
Individuos e interacciones | Procesos y herramientas |
Software funcionando | Documentación exhaustiva |
Colaboración con el cliente | Negociación contractual |
Respuesta ante el cambio | Seguir un plan estricto |
Satisfacción cliente: entregas frecuentes | Medida de progreso: software funcionando |
---|---|
Requisitos cambiantes |
Agilismo=desarrollo sostenible |
Entrega software funcional: períodos 2 sem.-2 meses | Excelencia técnica y buen diseño es agilidad! |
Colaboración negocio-desarrollo | Simplifica! Es esencial |
Entorno motivador y apoyo al equipo | Son necesarios equipos auto-organizados! |
Comunicación abierta, cara a cara | Revisiones y reflexiones frecuentes, ajustes a tiempo! |
... y sus 12 principios (framework)
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.
Principios:
Product Owner (rol)
Responsable desde el punto de vista del negocio.
Intermediario entre equipo y Stakeholders
Gestiona el Product Backlog
Sprint 0 (viabilidad?)
Product Backlog
Sprint Planning Meeting, Scrum Master y Equipo
Scrum Master (rol)
Equipo (auto org.) (rol)
Ejecutan el trabajo
Responsables técnicos
Preocupados por mejoras de Calidad y Productividad
Sprint Planning Meeting
Alcance Sprint
Historias de usuarios > tareas!
Entregable: Sprint Backlog!
Sprint Backlog
Duración Sprints y Burndown Chart
Burndown Chart
X=Horas; Y=días (calendario)
Duración Sprints
Daily Meetings, Review y Retrospectiva
Daily Meeting (SM facilita)
Busca mejorar la comunicación
Sprint Review
Retrospectiva (+++)
Rev. evolución, objetivos, dificultades, mejoras, soluciones..
Lo que usaremos:
El proceso que adaptamos:
Los Roles que adaptamos:
Y a aprender y pasárselo bien!!!
Objetivos:
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.
Objetivos:
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.
Objetivos:
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.
EL readme.md es el punto de contacto de nuestro proyecto con el mundo. No solo con los participantes del proyecto, también con reutilizador@s y potenciales usuari@s
Componentes:
El contriuting.md es el F.A.Q para contribuir a nuestro proyecto con el mundo. Desde aquí gestionamos todo tipo de posibles interacciones
Escenarios planteados:
EL code of conduct.md son las normas y estándares que rigen nuestro proyectos y determinan que clase de aportaciones o acciones de terceros serán rechazadas y perseguidas
Este Código de Conducta es una adaptación del Contributor Covenant, versión 1.4
Contamos con una plantilla automática para notificar bugs.
Datos pedidos:
Un milestone agrupa los issues de un Sprint y establece un deadline que será siempre 1 día antes del próximo OSW
Por Slack:
Explórate. Aprende.
Escucha al mundo.
Y vuelve a aprender.