Agenda 1. Disclaimers 2. ¿Qué es “agile”? 3. Contexto de 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
Scrum (¿1986?) “The New New Product development game” (Hirokata Takeuchi, 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)
Algunas aclaraciones sobre Scrum ● No “User stories”, but “Product 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...
19 Kent Beck (XP) Mike Beedle (Scrum) Arie van Bennekum (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
20 “I learned from Jeff Sutherland that the first Scrum 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
21 “You don’t see high performing Scrum teams without XP 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
22 “eXtreme Programming is an ideal many software shops would 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
23 “There's a mess I've heard about with quite a 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
¿Qué es “agile” para mí? 1. People first a. Antimatter principle (Bob Marshall): “Attend to folk’s needs” 2. Gestión del riesgo a. “Inspect and adapt”... so fast as possible.
Contexto de la empresa (2015-2017) ● Fundada en 2002, 17 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)
¿Cómo se decide en qué se trabaja? Cultura del Patinete en la empresa http://blog.crisp.se/wp-content/uploads/2014/10/Screen-Shot-2014-10-07-at-08.20.00.png Simplicidad Feedback
Sin estimaciones en general ¿Cómo se decide en qué se trabaja? http://6.fotos.web.sapo.io/i/o2806a3ac/18197719_O8Ukt.jpeg Confianza Comunicación Simplicidad Transparencia
Mínimo para varios clientes ¿Cómo se decide en qué se trabaja? https://i0.wp.com/autismodiario.org/wp-content/uploads/2014/06/positivo-negativo.jpg?resize=300%2C199&ssl=1 Simplicidad Valentía
https://soniccrewldn.files.wordpress.com/2014/03/friends-putting-their-hands-together-in-a-sign-of-unity-and-teamwork1.jpg Cómo lo hacemos nosotros (y por qué)
¿Por qué se trabaja con Pull Requests? ● Para sentirnos 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
Problemas con las Pull Requests ● It completely breaks the 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...
Trunk-based development for the win!! ● Pushing to Master. Yep. 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 :-)
¿Cuándo pueden tener sentido las PR? ● Equipos distribuidos en 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)
More key points (I) ● KISS / MVP: think about 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
More key points (II) ● Investing lots of time communicating 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)
Recursos ● https://martinfowler.com/articles/agile-aus-2018.html ● https://jeronimopalacios.com/kanban/ ● https://benjiweber.co.uk/blog/2015/04/17/modern-extreme-programming/ ● http://manifesto.softwarecraftsmanship.org/ ● The speed vs quality fallacy discussion ● 7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development (JBrains)
Y algunos blogs interesantes... http://www.eferro.net/ http://blog.jmbeas.es http://jeronimopalacios.com/ https://ronjeffries.com/ https://www.mountaingoatsoftware.com/blog
islomar
microcms
mackee
mikobaaaaa0920
manfredsteyer
haman29
hcrane
uhooi
masumitsu
dosukoi_android
lemolatoon
maroon1st
blackbracken
lara
smashingmag
philnash
garrettdimon
afnizarnur
bermonpainter
chriscoyier
holman
phodgson
myddelton
keavy
lauravandoore