Las reglas que hay que romper para que tu equipo de desarrollo sea el más RÁPIDO
•Télécharger en tant que PPTX, PDF•
1 j'aime•416 vues
El documento proporciona consejos para que un equipo de desarrollo sea más rápido, enfocándose en seis áreas clave: 1) enfocarse solo en lo necesario, 2) establecer claramente la dirección, 3) mejorar la coordinación entre el equipo, 4) identificar y reducir las cosas que roban tiempo, 5) asegurar que las cosas se hagan de manera efectiva, y 6) formar un equipo comprometido. El documento enfatiza la importancia de la transparencia, automatización, toma de decisiones por consenso,
Recommandé
Recommandé
Contenu connexe
Similaire à Las reglas que hay que romper para que tu equipo de desarrollo sea el más RÁPIDO
Similaire à Las reglas que hay que romper para que tu equipo de desarrollo sea el más RÁPIDO (20)
Plus de Javier Abadía
Plus de Javier Abadía (12)
Dernier
Dernier (6)
Las reglas que hay que romper para que tu equipo de desarrollo sea el más RÁPIDO
- 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
- 4. 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
- 7. velocidad hackathón a machetazos por la selva
- 8. velocidad ‘banco’ autopista de 6 carriles, con barandillas, farolas y gasolineras
- 9. velocidad ’startup’ hacer un camino practicable por la selva, a ver a dónde llegamos, mientras todavía tenemos víveres
- 10. microservicios! 💩 ¡soy un monolito! 💩 💩💩💩 💩 ¡y nosotros los microservicios! ¡y nosotros los microservicios! ¡y nosotros los microservicios!
- 11. saber hacia donde vamos ¿cómo podemos ir más rápido? I
- 12. movimiento != avance * esta es Courier New
- 13. ¿tienes un Product Manager?
- 14. road-map
- 17. hacer solo lo necesario ¿cómo podemos ir más rápido? II
- 18. el efecto “ballesta” meta-trabajo = trabajo que no es trabajo
- 19. capas de abstracción credit: http://www.defprogramming.com/quotes-by/roberto-waltman/
- 20. guías de estilo y reglas para la organización del código
- 22. DRY - código reusable
- 23. DRY - código reusable • no a la primera • no a la segunda • tal vez a la tercera
- 24. 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
- 25. deuda técnica
- 26. 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
- 28. 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?
- 29. 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’)
- 32. time-suckers ¿cómo podemos ir más rápido? III
- 34. prepararte para los accidentes en lugar de evitarlos (pista: no se puede)
- 35. 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
- 36. 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
- 37. time-suckers de otro tipo • información no compartida • debates filosóficos interminables
- 38. coordinación ¿cómo podemos ir más rápido? IV
- 39. 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?
- 41. no vale con saberse los comandos y no es necesario sabérselos
- 42. 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
- 43. 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
- 44. feature-switches • ¿por que? • ¿como?
- 45. getting things DONE ¿cómo podemos ir más rápido? V
- 46. soltar lastre lo antes posible
- 47. debugging y validación en pre-producción el modo “ship”
- 48. hitos
- 49. el equipo ¿cómo podemos ir más rápido? VI
- 52. nadie tiene las respuestas es TU trabajo encontrarlas
- 53. nadie es Dios las buenas ideas, son buenas independientemente de donde vengan Proyecto Aristótles
- 54. tomar decisiones por consenso
- 55. tenemos que ser valientes no perfectos los errores individuales ocurren el equipo debe mejorar continuamente para que no tengan consecuencias
- 56. motivación identificarse con los objetivos gestión adulta
- 58. work/family balance somos desarrolladores, no bomberos
- 59. I II III IV V VI el equipo getting things done coordinación time-suckers hacer solo lo necesario saber hacia dónde vamos
- 61. y sobre todo…
- 62. Comic Sans MS
Notes de l'éditeur
- [12:20] 40 min para crear un producto
- ¿cuántos de aquí sois responsables de un equipo de desarrollo? Bueno, pues vosotros ya habéis pasado por el momento "Frodo"... y el resto, algún día os tocará... ¿Qué es el momento "Frodo"? Pues llega alguien, te da un anillo y te dice... hala majete, ves allí el monte del destino? Pues tienes que llegar allí y destruirlo.
- Así que con un poco de suerte te buscas un equipo de confianza (o te lo asignan) y te pones a pensar cual es la mejor forma de cumplir tu misión. ¿Qué hago? ¿Busco un mapa? ¿Busco ayuda? ¿Empiezo a andar?... ¿Qué haría Frodo?...
- nos han encomendado una misión y queremos hacerlo bien para ser más cool, buscamos en inglés
- nos han encomendado una misión y queremos hacerlo bien para ser más cool, buscamos en inglés
- internet es como el quiosco, que hay de todo. me dedico al mundo de la moda, me fijo más en las revistas del sector... y siempre hablan de lo mismo... qué se va a llevar el mes que viene, cómo hacer dieta y que hay que hacer para estar mas sexy.
- Si nos salimos del sector y vamos a las revistas de running... también acaban hablando de lo mismo, de cómo hacer dieta.
- También hay portadas con chicos… hablan de lo mismo.
- las revistas de running... también acaban hablando de lo mismo, de cómo hacer dieta. pero… os imagináis que tuvieran estos titulares? … ¿Qué pondrían el segundo mes? La realidad no es glamourosa, y por eso nadie hace revistas ni artículos ni tweets Pues de eso va esta charla... de los consejos que se escuchan por ahí para desarrollar software y que en mi opinión no ayudan a ir más deprisa, y de las cosas que nadie dice, porque no son glamurosas o nos da vergüenza reconocer porque nos han convencido, y encima nos sentimos culpables
- Si resumieramos lo que vemos en internet sobre el desarrollo de software en una portada de revista, sería algo así. … ¿y no hablamos de hacer dieta? si, es esto de los microservicios!! Muchas buenas prácticas "de salón" pero que muchas veces están escritas por blogueros profesionales y gente que se dedica a escribir tutoriales... pero que han escrito menos código de producción que el director de desarrollo de una consultora Y ¿qué pasa con el código de producción? QUE ES FEO. Que nadie tuitea sobre el "if" horrible que ha tenido que poner en una función para controlar un error que aparecía a los usuarios los martes por la tarde, porque no tiene glamour.
- ¿por qué es importante?
- velocidad hackatón calidad hackathón si quieres ir rápido ve solo, si quieres llegar lejos, ve con toda la tribu
- con recursos suficientes y siguiendo todos los manuales y cumpliendo todas las normas de seguridad. buena forma = tienes los recursos suficientes y sabes con exactitud por donde tienes que pasar y a dónde tienes que llegar
- En los proyectos interesantes, no sabemos a dónde tenemos que llegar ni por dónde tenemos que pasar... Nadie ha ido antes. Llegar ántes de que se acaben los recursos. Dia a día de startups y proyectos que no son startups. Nosotros en StyleSage llevamos 2 años y medio en este modo: eramos 4 y ahora somos 19. ¿y como lo hemos conseguido?
- Microservicios! ¡¡¡NI DE COÑA!!! No echarnos más trabajo encima. A la larga puede ser la solución óptima. Al principio ni de coña. necesitas devops Entonces... hacemos un monolito infumable? no, monolito si, porque es lo más simple, pero no infumable: bien organizado, bien separado código muy cohesivo y con poco acoplamiento para que las partes diferenciadas que vayan emergiendo se puedan ir separando. nos evitamos la carga de trabajo de DevOps inicial y nos preparamos el terreno para trocearlo cuando sea necesario
- [12:28] entonces, en serio lo primero es saber a donde quieres ir
- por que si no, confundimos movimento con avance... trabajamos mucho, nunca llegamos a nada. avance = aportar valor a nuestro usuario a través de nuestro producto. un mes a refactorizar una aplicación = nos hemos movido mucho pero no hemos avanzado nada.
- dice hacia donde vamos pero dice lo que NO hay que hacer. se pasa el día apuntando buenas ideas y diciendo que no
- su trabajo es hacer un road-map: documento de word en project, como las empresas grandes en trello, como las startups hipsters con post-its , como las empresas ágiles
- hablando de agilidad, lo fundamental es meter al usuario en el bucle, es la única forma de saber si el movimiento es avance ENTREGAR la funcionalidad lo antes posible y VALIDAR que lo que hemos hecho es lo que realmente hacía falta.
- agilismo = se centra en toda la ceremonia de los post-its, los sprints, los scrum masters... y se olvida de que al final de cada sprint hay que pasar por el usuario! ¿cuantos proyectos hacen sprints sin entregar nada? te crees que estás siendo muy ágil y solo te estás engañando a ti mismo
- [12:29] solo podemos ir rápido si vamos en la dirección correcta. Pero aun así… por el camino nos vamos a encontrar miles de distracciones que nos pueden hacer ir más lentos
- es lo que yo llamo el 'meta-trabajo', son tareas que nos inventamos nosotros mismos bajo la excusa de las buenas prácticas de ingeniería y que en el fondo no aportan valor al usuario a través del producto el efecto ‘ballesta’ por ‘miguel angel ballesta’ los desarrolladores somos expertos en cambiar la definición de nuestro trabajo para hacerlo más molón: ballesta, nueva vista, generador de código para crear vistas: 30 min -> 3 días y además no ha creado la vista muy preocupante: foco del usuario a la ingeniería: cambiamos el trabajo de aportar valor al usuario a través del producto a hacer un generador de código síntoma = product manager y CTO no están haciendo bien su trabajo, no están insertando en el cerebro de los desarrolladores la alergia a las pamplinas. Los desarrolladores son 'caballos de carreras', y tienen que correr. Si no les pones objetivos claros, se ponen a correr en la dirección equivocada. Cuando alguien no sabe qué hacer, hace lo que sabe... programar. Y nos movemos mucho y avanzamos poco.
- otro ejemplo de esto son las capas de abstracción: capa genérica para acceder a base de datos para poder cambiar el gestor cuando queramos, un sistema de plugins, y así cualquier cosa que queramos hacer la podemos hacer con un plugin, un editor de layouts... y es la versión moderna del código espagetthi que es el código lasaña, con demasiadas capas de abstracción... Roberto Waltman auténticos astronautas de la abstracción que se niegan a resolver problemas concretos... siempre buscan la generalización, la abstracción... ya llegará el momento de abstraer problemas, pero todavía no si alguien propone alguna de estas cosas, dadle una colleja y que se quede mirando al roadmap
- todos tenemos preferencias: un profesional se tiene que adaptar tenemos distintos estilos de código - los respetamos - 1 cambio de 1 línea no tiene que generar un diff de 200 te aguantas trabajo del CTO sobre la estructura del código... siempre hay alguien que quiere definirla antes de empezar... lo malo es que demasiadas reglas, limitan la velocidad esperar a ver por donde crece, y definir a posteriori una estructura
- tu pintas los caminos, y luego la realidad te demuestra por dónde pasa la gente espera a ver por dónde te crece el código y define la estructura a posteriori… las reglas prematuras te limitan la velocidad
- Todos hemos leido DRY - Don't Repeat Yourself, y nos han inculcado que hay que evitar duplicidades a toda cosa así que cuando estamos desarrollando y tenemos la sensación de que este código se va a necesitar en más sitios, aparece “ballesta” y te dice hazlo reusable
- el código reusable es muy difícil de escribir bien, ¿qué es genérico y qué es específico de cada caso? a la primera no, no merece la pena a la segunda vez, ya ha pasado el tiempo y lo que necesitas ahora no es exactamente lo que tienes. Peligro de romper algo. a la tercera, no es que vaya a ser más fácil, pero hay justificación para dedicar el tiempo y esfuerzo necesarios para hacer el código bien y probar exhaustivamente los 3 sitios donde lo usas
- así que mientras tanto, el copy & paste es buenísimo... lo importante es que el código que escribamos esté bien organizado con single-concern y loose coupling, para que cuando llegue el momento de refactorizarlo (si es que llega) la operación sea sencilla. Y marcar el código duplicado con referencias cruzadas. ¿Y que hay del DRY? en realidad es otra cosa… lo que me dice es que cada decisión debe reflejarse en un solo sitio del código
- esto del copy&paste es un ejemplo de Deuda Técnica
- es sana ¿tenéis hipoteca? mientras sea manejable no ponerse en modo hackathón, no es sostenible no puede ser que unos hagan ñapas y otros vengan detrás limpando la mierda... eso no es deuda técnica, eso es 'machismo' de código
- sobre la documentación... hay que documentarlo todo, no hay que documentar nada...
- yo creo que lo que no está escrito, se olvida, pero por otro lado, no hay que escribir las cosas más de una vez el peor documento es el que no lee nadie el peor documento es el que cuando alguien lo lee está desactualizado mantener las cosas juntas, con referencias lo de la documentación automática es otro ejemplo perfecto del efecto “ballesta”
- los desarrolladores tenemos un autocorrector en el cerebro, que cuando oimos la palabra testing, inmediatamente le añadimos automático después… no nos cabe en la cabeza que las aplicaciones se pueden probar de otra forma… ¡probándolas!
- tiene sentido: si, pero acotado, y es una solución parcial al problema de la calidad ¿cuántas aplicaciones han fallado en producción y tenían 100% de cobertura y todos los tests pasando en verde? ¡porque siempre falla otra cosa! ¿qué tipo de errores se cazan con unit-testing? ¿tiene sentido hacer test automáticos para validar el HTML? TDD: mola como filosofía, pero no para front-end
- es necesario PROBAR antes de cada despliegue es necesario VALIDAR no es necesario AUTOMATIZAR los TEST: puede ser cómodo, divertido, útil… pero no es necesario con cada cagada, pensar qué test te hubiera evitado cometerla cada vez que falle algo, preguntarse: ¿cómo podríamos haberlo evitado? (que sea ‘realizable’)
- sin tests, puedes sobrevivir durante un tiempo… como estos 3 lumbreras
- todas estas cosas tienen en común: redefinen el trabajo es hacer algo para nosotros en lugar de hacer algo para el usuario MUY peligroso
- [12:39] sabemos a donde vamos no nos distraemos con pamplinas y aún así, hay semanas en las que se tuerce todo y nos vamos a casa con la lista de tareas sin tocar: se nos ha caido el servidor, se nos ha llenado el disco duro, nos ha fallado una integración y nos hemos pasado dos/tres días limpiando la mierda…
- y eso pasa porque a veces nos afanamos en resolver los síntomas, en lugar de atajar las causas de raíz de los time-suckers si detectáis alguno de estos problemas, no tenéis nada más prioritario que resolverlo: es como atarse los cordones por ejemplo
- aun así, movidas vas a tener, si no querías movidas, no haberte dedicado a la informática prepárate para que no sean catastróficas: backups, servidores virtuales, repositorios… lo de siempre
- ser estrictos con que los entornos sean lo más parecidos posibles pro/pre/dev resolverlos solo cuando sean time-suckers, no ponernos a containerizar en docker solo porque es divertido… a lo mejor la solución es contratar un devops
- aquí la solución es mejorar el proceso de integración y despliegue contínuo… cada vez más… viene ballesta y dice “un jenkins” no es necesario un jenkins… es necesario automatizar el despliegue (un simple script de bash) usar migraciones gestionar las dependencias hacer despliegues frecuentes
- transparencia respeto mutuo y autoridad del CTO
- [12:43] supongamos que sabemos a donde vamos que no nos dejamos distraer con las “buenas prácticas” y que hemos tapado los agujeros del barco ¿qué más nos podría ralentizar?
- nada mas triste que dos personas arreglando lo mismo sin saberlo o alguien resolviendo algo que no tiene sentido, por no saber de donde viene
- código documentos todo…
- integrar código que está a medias lastre = código no integrado simplifica muchísimas cosas y la puesta en producción es facilísima
- [12:47] acabar terminar finalizar completar dar carpetazo cerrar
- lastre = código que no está en producción = trabajo que no ha aportado ningún valor
- desarrollas una feature super urgente en 2 semanas y se pasa otras dos semanas en “pre-producción” hasta que alguien da el OK definitivo NEGARSE a resolver ”issues” con cuentagotas nada iguala a un google spreadsheet compartido
- son sagrados se negocian con negocio: si fijas el alcance yo pongo la fecha si pones la fecha, yo decido el alcance acostumbrar a negocio a que siempre cumplimos con las fechas relación de confianza
- [12:50]
- ¿cuántos hay que tener de cada? NINGUNO todos tienen que ser desarrolladores y todos tienen que tener al usuario presente todos los días
- todos tienen que venir a trabajar con el cerebro de pensar activado ownership, authority, empowerment nadie ‘aprueba’ la especificación, nadie va a revisar tu trabajo… tú eres el responsable de hacerlo bien (anécdota de HP) ojo, que las ”code reviews” son otra cosa
- nadie tiene las respuestas, ni la verdad absoluta PIENSA dale toda la información a tu equipo para que puedan pensar
- todos deben contribuir todos deben opinar todos deben tener toda la información para contribuir positivamente
- es obligación del CTO tomar las decisiones y hacerse responsable
- los errores individuales ocurren el equipo debe mejorar para que no tengan consecuencias
- yo te digo a dónde hay que llegar es cosa tuya buscar la mejor manera de llegar no hay nada que motive más a un desarrollador que sentirse productivo trabajar en un equipo así motiva los desarrolladores son caballos de carreras si corren están contentos
- charlas internas rienda suelta caballos de carreras útil, enfocado, con objetivos tangibles déjale a ballesta que juegue, pero con algo útil
- rienda suelta caballos de carreras útil, enfocado, con objetivos tangibles
- trabajar menos horas nos hace ir más rápido
- [12:55] esta diapo para acabar, no mola no son reglas, ni un decálogo somos personas
- para ir rápido las cosas importantes no son las que tienen que ver con el código son las que tienen que ver con el usuario (para saber hacia donde vamos, qué hacer y qué no hacer) y las que tienen que ver con el equipo (para, que si sabemos a donde vamos, vayamos todos juntos y bien coordinados)