la empresa y el equipo de desarrollo 4. Interacción con negocio 5. Principios y prácticas “internas” del equipo 6. Hall of shame 7. Conclusiones y recursos recomendados 8. Debate grupal
1986) OOPSLA 1995: presented by Jeff Sutherland and Ken Schwaber The Scrum guide (November 2017): • It’s a FRAMEWORK (not a methodology, not a method) • Only mentions “software” as one of several contexts (“for developing, delivering, and sustaining complex products”) • Values, team, events, artifacts, DoD. • Push system Best book ever about Scrum: “The people’s Scrum” (Tobias Mayer)
Backlog Items” (PBI) ◦ Origen de las US: eXtreme Programming!!! (1998) • “Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;”. E.g. QA, architect, tech lead, etc. • Sí se mencionan las estimaciones, pero ningún método concreto (no “story points”) • No dice que solo se pueda/deba entregar/desplegar al final del sprint...
(DSDM) Alistair Cockburn (Crystal) Ward Cunningham (XP) Martin Fowler (XP) James Grenning (XP) Jim Highsmith (ASD) Andrew Hunt (PP) Ron Jeffries (XP) Jon Kern (FDD) Brian Marick Robert C. Martin (XP*) Steve Mellor Ken Schwaber (Scrum) Jeff Sutherland (Scrum) Dave Thomas (PP) https://twitter.com/eferro
actually did all the XP practices. But Ken Schwaber convinced him to leave the engineering practices out of Scrum, to keep the model simple and let the teams take responsibility for the tech practices themselves. Perhaps this helped spread Scrum faster, but the downside is that a lot of teams suffer because they lack the technical practices that enable sustainable agile development.” “Scrum and XP from the Trenches” Henrik Kniberg https://twitter.com/eferro
engineering practices. It is difficult to scale XP teams without Scrum and Scrum solves the management interface issues for XP. Be careful about doing pieces of anything and calling it Agile.” “Deep Agile course” Ron Jeffries and Sutherland https://twitter.com/eferro
love to reach, but with the constant pressures to produce software quickly, they cannot actually implement it. ... This book shows readers how to use SCRUM, an Agile software development process, to quickly and seamlessly implement XP in their shop-while still producing actual software.” “Agile Software Development with Scrum” Ken Schwaber and Mike Beedle https://twitter.com/eferro
few projects recently. It works out like this: • They want to use an agile process, and pick Scrum • They adopt the Scrum practices, and maybe even the principles • After a while progress is slow because the code base is a mess” “Flaccid Scrum” Martin Fowler
años de antigüedad (sector de Telecomunicaciones) • Desarrollo de producto • Empresa con EBITDA muy positivo • ~ 20-25 personas en toda la empresa (ahora ~ 35 personas) • Equipo de desarrollo: 6-8 personas (ahora ~ 11 personas) • “ENORME” base de código (33 µservicios, 80 clientes, ~2.500 contenedores en Prod)
más seguros ◦ Peer review: Someone else can take a look to it and detect problems • Para mejorar la calidad del código (e.g. design solution) • Para compartir y extender el conocimiento • Para tener control sobre lo que otras personas hacen: ◦ Modo “seguro” de aceptar contribuciones de otras personas/equipos
flow ◦ You are NOT doing Continuous Integration, let alone Continuous Delivery/Deployment ◦ You better wait for that PR to be merged before creating a new one… or fight with Git • It’s too late: ◦ Someone already worked several hours (days?) on it. Waste. • You don’t have the context of the person for every decision made • Review hundreds of lines and tenth of files… are you kidding? • Merge race...
Mean it when saying “Continuous Integration”. • It's not about PR vs TBD... • ...but about PR vs TDD + Pair programming + TBD + parallel changes +.. • If you don't trust your code enough… then you know where to focus • Still branching: ◦ Spike, too much uncertainty: ▪ Done 3-4 times in 2 years ▪ After the spike, start from scratch with the new knowledge in master • I forgot git complexity: only needed pull and push commands :-)
diferentes zonas horarias ◦ No es posible hacer pair programming • En casos excepcionales en que alguien trabajó solo (mejor hacer code review en local, no en PR)
the business/customer... • Technical excellence AS IF YOU MEAN IT: e.g. TDD, SOLID, clean code… • Pair/mob programming by default • Trunk-based development by default (plu TDD, feature toggle, etc.) • Continuous Delivery/Deployment • Kanban: pull system with continuous flow
and synchronizing ◦ No silos ◦ It really pays off in the long term • Radical transparency • LONG TERM VISION: probably you need to slow down temporarily… to keep a good long term sustainable pace (without suffering)
islomar
ivargrimstad
sakuraidayo
rkaga
nealle
nrslib
kenn
logica0419
kotaro666
danielsogl
fast_doctor
shota_tech
syossan27
productmarketing
keavy
csswizardry
sferik
mraible
marktimemedia
tammyeverts
honnibal
samlambert
caitiem20
jnunemaker
sachag
