Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Las reglas que hay que romper para que tu equipo de desarrollo sea el más RÁPIDO

228 Aufrufe

Veröffentlicht am

Slides de la charla de Codemotion 2017: https://2017.codemotion.es/agenda.html#5693168230072320/5105557983723520

Video: https://www.youtube.com/watch?v=VnrynReafSg

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

Las reglas que hay que romper para que tu equipo de desarrollo sea el más RÁPIDO

  1. 1. Las reglas que hay que romper para que tu equipo de desarrollo sea el más RÁPIDO o cómo se gana el sueldo un CTO* *si, es Comic Sans MS@javierabadia 2017
  2. 2. CORRIENDO, TE CANSAS SOLO NECESITAS UNAS ZAPATILLAS. PUNTO. LAS DEL DECATHLÓN ESTÁN BIEN AUNQUE TE COMPRES LAS ZAPATILLAS DE 180€ TE VAS A CANSAR IGUAL PARA HIDRATARSE, LO MEJOR ES EL AGUA LOS GRANDES ATLETAS CORREN MUCHO, PORQUE ENTRENAN MUCHO PARA PREPARAR UN MARATÓN, HAY QUE SALIR A CORRER. Y TE VAS A CANSAR
  3. 3. ¿qué es velocidad?
  4. 4. velocidad hackathón a machetazos por la selva
  5. 5. velocidad ‘banco’ autopista de 6 carriles, con barandillas, farolas y gasolineras
  6. 6. velocidad ’startup’ hacer un camino practicable por la selva, a ver a dónde llegamos, mientras todavía tenemos víveres
  7. 7. microservicios! 💩 ¡soy un monolito! 💩 💩💩💩 💩 ¡y nosotros los microservicios! ¡y nosotros los microservicios! ¡y nosotros los microservicios!
  8. 8. saber hacia donde vamos ¿cómo podemos ir más rápido? I
  9. 9. movimiento != avance * esta es Courier New
  10. 10. ¿tienes un Product Manager?
  11. 11. road-map
  12. 12. agilidad o agilismo
  13. 13. agilismo o agilidad scrum master
  14. 14. hacer solo lo necesario ¿cómo podemos ir más rápido? II
  15. 15. el efecto “ballesta” meta-trabajo = trabajo que no es trabajo
  16. 16. capas de abstracción credit: http://www.defprogramming.com/quotes-by/roberto-waltman/
  17. 17. guías de estilo y reglas para la organización del código
  18. 18. DRY - código reusable
  19. 19. DRY - código reusable • no a la primera • no a la segunda • tal vez a la tercera
  20. 20. DRY - código reusable • no a la primera • no a la segunda • tal vez a la tercera • copy & paste de código = bueno • pero SI: single-concern, loose coupling • DRY: cada decisión en un solo sitio
  21. 21. deuda técnica
  22. 22. principios de la deuda técnica • es necesaria y sana si se hace a sabiendas • demasiada te puede hundir • no ponerse en modo hackathón • el que la hace, la paga
  23. 23. testing Xtesting automático
  24. 24. testing automático • ¿100% de cobertura? • ¿qué tipo de errores se cazan con unit-testing? • ¿tiene sentido hacer test automáticos para validar el HTML?
  25. 25. testing “a secas” • es necesario PROBAR • antes de cada despliegue • es necesario VALIDAR • muy probablemente no es necesario ni efectivo AUTOMATIZAR los TEST • mini-post-portems: cada vez que falle algo, preguntarse: ¿cómo podríamos haberlo evitado? (que sea ‘realizable’)
  26. 26. optimización abstracción reusabilidad automatización USUARIO
  27. 27. time-suckers ¿cómo podemos ir más rápido? III
  28. 28. prepararte para los accidentes en lugar de evitarlos (pista: no se puede)
  29. 29. time-suckers • diferencias entre entornos • en mi máquina funciona • “ensalada de settings” • administración de servidores • disco lleno en el peor momento • seguridad • dependencias
  30. 30. más time-suckers • integraciones fallidas • merges con ansiedad • despliegues fallidos • errores manuales = no automático • se rompe algo al cambiar el esquema de bbdd • (no usáis migraciones?) • se rompe algo al cambiar las dependencias • la Puesta en Producción vs la puesta en producción
  31. 31. time-suckers de otro tipo • información no compartida • debates filosóficos interminables
  32. 32. coordinación ¿cómo podemos ir más rápido? IV
  33. 33. transparencia información compartida ¿todos saben lo que están haciendo los demás miembros de su equipo? ¿todos saben por qué hacen lo que están haciendo?
  34. 34. no vale con saberse los comandos y no es necesario sabérselos
  35. 35. entendiendo git • repo • colección de commits (identificados por su SHA1) • commit • cada commit sabe quien es su padre • un commit es un delta NO una foto • rama • rama = una etiqueta que apunta a un commit • un commit puede tener dos (o más) hijos • merge • crear un nuevo commit con dos (o más) padres • combinar los cambios que vienen de 2 ramas https://marklodato.github.io/visual-git-guide/index-en.html
  36. 36. usando git • las ramas • usar muchas ramas (son gratis) • de vida corta • sin miedo a los merges • los commits • prohibido “git add .” • ‘manufacturar’ los commits • recomendable • pull requests • code review • oh shit git https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
  37. 37. feature-switches • ¿por que? • ¿como?
  38. 38. getting things DONE ¿cómo podemos ir más rápido? V
  39. 39. soltar lastre lo antes posible
  40. 40. debugging y validación en pre-producción el modo “ship”
  41. 41. hitos
  42. 42. el equipo ¿cómo podemos ir más rápido? VI
  43. 43. programador analista programador analista
  44. 44. cerebro en modo ON
  45. 45. nadie tiene las respuestas es TU trabajo encontrarlas
  46. 46. nadie es Dios las buenas ideas, son buenas independientemente de donde vengan Proyecto Aristótles
  47. 47. tomar decisiones por consenso
  48. 48. tenemos que ser valientes no perfectos los errores individuales ocurren el equipo debe mejorar continuamente para que no tengan consecuencias
  49. 49. motivación identificarse con los objetivos gestión adulta
  50. 50. compartir conocimiento innovación
  51. 51. work/family balance somos desarrolladores, no bomberos
  52. 52. I II III IV V VI el equipo getting things done coordinación time-suckers hacer solo lo necesario saber hacia dónde vamos
  53. 53. y sobre todo…
  54. 54. Comic Sans MS

×