0
BUENAS PRÁCTICAS Cómo implantarlas en proyectos tecnológicos...          y no morir en el intento        Ricard Clau (@ric...
RICARD CLAU      Backend Tech Lead @ SocialPointHe pasado por Emagister, Ulabox y Privalia              A veces doy charla...
VAMOS A HABLAR DE...• Nuestra   realidad como desarrolladores• Nuestra   relación con “negocio”• Buenas     prácticas (qué...
CONCEPTOS SUELTOS• Tolerancia    al sufrimiento. ¿Es infinita?• Deuda    técnica. Hay que pagarla o sufrirla• Time   to mar...
ESCENARIOS HOSTILES• Consultoras      y empresas de servicios en general• Proyectos   freelance muy ajustados de presupues...
DESARROLLADORES• Nos   sentimos superhéroes• Sed   insaciable de conocimiento• Trabajamos   con lo que nos gusta• Nos   gu...
NEGOCIO• Nos    piden “cosas”• Responsables   de conseguir pasta• No     les entendemos bien• Nos    ven como una “commodi...
NO SOMOS PERFECTOS• Estaríamos   siempre refactorizando• Introducimos   bugs... demasiados• No   sabemos vender nuestras i...
ELLOS TAMPOCO• Features   que se tiran a la basura• Time   to market, baja calidad• No aceptan estimaciones largas de tiem...
PROBLEMASDESARROLLO DICE          NEGOCIO CONTESTANo se saben explicar     No entienden necesidadesTonterietas de negocio ...
NO ES UNA GUERRA  Estamos todos en el mismo barco       Confianza bidireccional
BUENAS PRÁCTICAS“Conjunto coherente de acciones que han rendido buen o excelente   servicio en un determinado contexto y q...
¿POR QUÉ USARLAS?• Nos      ayudan a trabajar mejor• Es   divertido y genera entusiasmo• Es   nuestra responsabilidad prom...
¿POR QUÉ NO SE HACE?• Desconocimiento• Jefes   sin conocimientos técnicos• Complicado   de explicar el retorno• Entornos  ...
EJEMPLOS RÁPIDOS• Metodologías    AGILE• Comunicación         continua y clara• Retrospectivas        y mejora continua• R...
¿POR DÓNDE EMPIEZO?• Busca   apoyos, los necesitarás• Identifica   cosas que molestan y atácalas• Itera, reinventa, cuestio...
AGILEEs MUCHO más que una pared llena de post-its
AGILE VA DE...• Transparencia     y confianza• El   product owner prioriza negocio• El   equipo de desarrollo estima• El   ...
LA COSA NO FLUYE SI...• Hay   tareas unplanned siempre   interrumpe continuamente al• Se equipo de desarrollo• Negocio    ...
¿POR QUÉ NO SE HACE?• Miedo   a perder flexibilidad y decisión de timings• Es   un marco abierto, no hay manual• Malas   ex...
INTRODUCCIÓN GRADUAL• Dailys   y retrospectivas• Listado     de tareas a largo plazo• Tablón      bien visible• Generar   ...
GENTE DE NEGOCIO    ¿Qué parte os toca?
COMUNICACIÓN• Habla    con el equipo de desarrollo a menudo• Cuando   algo es importante para negocio, explica por qué•Y  ...
NO DEBERÍAS...• Vernos    como un mal necesario• Ningunearnos    en la estrategia• No   permitir el desarrollo del equipo•...
DESARROLLADORES   Tenéis mucho que decir y hacer
SI ESTÁS AL PRINCIPIO• Intenta   elegir tecnologías probadas en marcos similares• No    te la juegues probando cosas sólo ...
PROYECTOS MADUROS• Cuesta      mucho cambiar las cosas, pero se puede• Intenta   introducir algo de Agile• Intenta   adopt...
UTILIZA FRAMEWORKS   No haces nada tan diferente al resto...   Ni tu inteligencia supera a la colectiva
EL DÍA A DÍA• Deja   que cada uno use el IDE / SO que quiera• Coding    Standards. POR FAVOR• Control    de versiones mode...
PERFORMANCE• Minimiza   las requests• Cachea     todo lo que puedas• Usa   colas donde puedas• Lasmicrooptimizaciones no v...
EXTREME PROGRAMMING• Simplicidad, comunicación, retroalimentación, coraje   y respeto• Pequeñas     mejoras, continuas. En...
EXTREME PROGRAMMINGVale, es una utopía, pero hay cosas que podemos hacer...
TESTING• Tener   pocos tests es mucho mejor que no tener nada• Se   puede introducir gradualmente• Lo   más visual es el t...
¿POR QUÉ NO TESTEAMOS?• Desconocimiento• Prisas    de negocio (no vale como excusa!)• Es   difícil de explicar en seminari...
NO SÉ CÓMO EMPEZAR• Empieza    haciendo macros con Selenium IDE        instalar Selenium en local, haz una pequeña demo• I...
INTEGRACIÓN CONTINUA    Hay que intentar acercarse a ello
COMPLEMENTAN LOS TESTS• Métricas• Monitorización       de servidores• Análisis   de Logs• Debugging• Profiling
CONCLUSIONES• “Negocio”     no es nuestro enemigo• Depende     de nosotros hacer las cosas bien• Se   puede mejorar cada d...
MUCHÍSIMAS GRACIAS   ¡Preguntad lo que queráis, no os cortéis!        Ricard Clau (@ricardclau)        ricard.clau@gmail.com
CUMPLEAÑOS FELIZ   Y que cumplas muchos más...
Betabeers Barcelona - Buenas prácticas
Upcoming SlideShare
Loading in...5
×

Betabeers Barcelona - Buenas prácticas

1,206

Published on

Charla sobre cómo implantar buenas prácticas en los proyectos tecnológicos y no morir en el intento. Realizada el 25 de Enero de 2013 en Betabeers Barcelona.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,206
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Betabeers Barcelona - Buenas prácticas"

  1. 1. BUENAS PRÁCTICAS Cómo implantarlas en proyectos tecnológicos... y no morir en el intento Ricard Clau (@ricardclau) Betabeers BCN 25-Enero-2013
  2. 2. RICARD CLAU Backend Tech Lead @ SocialPointHe pasado por Emagister, Ulabox y Privalia A veces doy charlasY de vez en cuando me aceptan PR en Github
  3. 3. VAMOS A HABLAR DE...• Nuestra realidad como desarrolladores• Nuestra relación con “negocio”• Buenas prácticas (qué son y por dónde empezamos)• Algunas herramientas y truquillos• Todo lo que queráis preguntar
  4. 4. CONCEPTOS SUELTOS• Tolerancia al sufrimiento. ¿Es infinita?• Deuda técnica. Hay que pagarla o sufrirla• Time to market. La preocupación de negocio• Resistencia al cambio. Es humano• Acción continua• #rigor. Siempre prevalece y acaba venciendo
  5. 5. ESCENARIOS HOSTILES• Consultoras y empresas de servicios en general• Proyectos freelance muy ajustados de presupuesto• Equipos con gente acomodada y resistente al cambio• Equipos de sistemas perezosos• Área de negocio con poco background técnico
  6. 6. DESARROLLADORES• Nos sentimos superhéroes• Sed insaciable de conocimiento• Trabajamos con lo que nos gusta• Nos gusta rodearnos de los mejores• Es algo más que un trabajo
  7. 7. NEGOCIO• Nos piden “cosas”• Responsables de conseguir pasta• No les entendemos bien• Nos ven como una “commodity”• Bajo conocimiento tecnológico
  8. 8. NO SOMOS PERFECTOS• Estaríamos siempre refactorizando• Introducimos bugs... demasiados• No sabemos vender nuestras ideas• Nos cuesta comunicarnos• Perdemos de vista que lo que importa es lo que da pasta
  9. 9. ELLOS TAMPOCO• Features que se tiran a la basura• Time to market, baja calidad• No aceptan estimaciones largas de tiempo relegan temas técnicos hasta• Se que es demasiado tarde
  10. 10. PROBLEMASDESARROLLO DICE NEGOCIO CONTESTANo se saben explicar No entienden necesidadesTonterietas de negocio Feature monetizadoraNo tienen ni idea No conocen negocioMetodologías ágiles Rigidez operativaGente de master Frikis
  11. 11. NO ES UNA GUERRA Estamos todos en el mismo barco Confianza bidireccional
  12. 12. BUENAS PRÁCTICAS“Conjunto coherente de acciones que han rendido buen o excelente servicio en un determinado contexto y que se espera que, en contextos similares, rindan similares resultados.”
  13. 13. ¿POR QUÉ USARLAS?• Nos ayudan a trabajar mejor• Es divertido y genera entusiasmo• Es nuestra responsabilidad promoverlas• .... y seguirlas• Se puede aplicar gradualmente• Desarrollo de mayor calidad
  14. 14. ¿POR QUÉ NO SE HACE?• Desconocimiento• Jefes sin conocimientos técnicos• Complicado de explicar el retorno• Entornos viciados• Resistencia al cambio
  15. 15. EJEMPLOS RÁPIDOS• Metodologías AGILE• Comunicación continua y clara• Retrospectivas y mejora continua• Revisiones de procesos y código• Integración continua, Testing, ...• El equipo ha de ser una piña!
  16. 16. ¿POR DÓNDE EMPIEZO?• Busca apoyos, los necesitarás• Identifica cosas que molestan y atácalas• Itera, reinventa, cuestiona, siempre!• Pequeñas demostraciones tienen impacto• Si no te ves capaz, contrata a alguien que de el empujón
  17. 17. AGILEEs MUCHO más que una pared llena de post-its
  18. 18. AGILE VA DE...• Transparencia y confianza• El product owner prioriza negocio• El equipo de desarrollo estima• El scrum master negocia• Status diario para bloqueos• Retrospectiva a fin de sprint
  19. 19. LA COSA NO FLUYE SI...• Hay tareas unplanned siempre interrumpe continuamente al• Se equipo de desarrollo• Negocio impone tiempos• Los dailys se eternizan• Las retrospectivas no arreglan nada
  20. 20. ¿POR QUÉ NO SE HACE?• Miedo a perder flexibilidad y decisión de timings• Es un marco abierto, no hay manual• Malas experiencias por mal uso de las metodologías• Es muy difícil cambiar un entorno viciado• Requiere que gran parte de la empresa lo siga
  21. 21. INTRODUCCIÓN GRADUAL• Dailys y retrospectivas• Listado de tareas a largo plazo• Tablón bien visible• Generar y transmitir confianza SIEMPRE por qué tardamos• Explicar X días en hacer “esa tontería”
  22. 22. GENTE DE NEGOCIO ¿Qué parte os toca?
  23. 23. COMUNICACIÓN• Habla con el equipo de desarrollo a menudo• Cuando algo es importante para negocio, explica por qué•Y cuando algo no lo es, no presiones innecesariamente• Reconóceles los méritos cuando han hecho las cosas bien• Tú les has fichado, confía en ellos y aprovecha su talento
  24. 24. NO DEBERÍAS...• Vernos como un mal necesario• Ningunearnos en la estrategia• No permitir el desarrollo del equipo• Temer que si nos formamos nos iremos a la competencia @empresaurioTIC• Fichar a lo loco, en plan cárnica
  25. 25. DESARROLLADORES Tenéis mucho que decir y hacer
  26. 26. SI ESTÁS AL PRINCIPIO• Intenta elegir tecnologías probadas en marcos similares• No te la juegues probando cosas sólo porque son “cool”• No confíes en productos mágicos...• Ni en consultores de dudosa reputación• Usa herramientas open-source• No hagas falsas promesas a los que se embarcan contigo
  27. 27. PROYECTOS MADUROS• Cuesta mucho cambiar las cosas, pero se puede• Intenta introducir algo de Agile• Intenta adoptar técnicas de Extreme Programming• Los refactors son sanos y necesarios• El testing es muy conveniente, aunque sea funcional• Monitoriza cuantas más cosas mejor
  28. 28. UTILIZA FRAMEWORKS No haces nada tan diferente al resto... Ni tu inteligencia supera a la colectiva
  29. 29. EL DÍA A DÍA• Deja que cada uno use el IDE / SO que quiera• Coding Standards. POR FAVOR• Control de versiones moderno (nada anterior a SVN)• Es necesario documentar, tanto código como procesos• Usa algún issue tracker para gestión de bugs y features• Entorno de QA lo más parecido a producción posible
  30. 30. PERFORMANCE• Minimiza las requests• Cachea todo lo que puedas• Usa colas donde puedas• Lasmicrooptimizaciones no valen para nada• Afina settings de servidor
  31. 31. EXTREME PROGRAMMING• Simplicidad, comunicación, retroalimentación, coraje y respeto• Pequeñas mejoras, continuas. Entregas frecuentes• Programación en parejas• Pruebas unitarias continuas• El refactor es bueno• Propiedad del código compartida
  32. 32. EXTREME PROGRAMMINGVale, es una utopía, pero hay cosas que podemos hacer...
  33. 33. TESTING• Tener pocos tests es mucho mejor que no tener nada• Se puede introducir gradualmente• Lo más visual es el testing funcional (Selenium / Sahi)• Empieza por lo más crítico (login, pagos, operativa diaria)• Hasta el código más oscuro puede ser testeado!
  34. 34. ¿POR QUÉ NO TESTEAMOS?• Desconocimiento• Prisas de negocio (no vale como excusa!)• Es difícil de explicar en seminarios, charlas, libros, etc...• Testear proyectos terminados es una tarea titánica• Esdifícil justificar las horas invertidas... hasta que previenen catástrofes o bajan los bugs
  35. 35. NO SÉ CÓMO EMPEZAR• Empieza haciendo macros con Selenium IDE instalar Selenium en local, haz una pequeña demo• Intenta y enséñasela a tus jefes• Si trabajas con User Stories, considera BDD• No te frustres si no entiendes qué es un Mock, un Stub, ... en cosas que tengan valor, no te obsesiones con• Céntrate la cobertura 100%
  36. 36. INTEGRACIÓN CONTINUA Hay que intentar acercarse a ello
  37. 37. COMPLEMENTAN LOS TESTS• Métricas• Monitorización de servidores• Análisis de Logs• Debugging• Profiling
  38. 38. CONCLUSIONES• “Negocio” no es nuestro enemigo• Depende de nosotros hacer las cosas bien• Se puede mejorar cada día un poquito• Hay muchas herramientas para facilitar las cosas• Un mundo mejor es posible! :)•Y si aún así no nos dejan... hay muchos sitios donde ir!
  39. 39. MUCHÍSIMAS GRACIAS ¡Preguntad lo que queráis, no os cortéis! Ricard Clau (@ricardclau) ricard.clau@gmail.com
  40. 40. CUMPLEAÑOS FELIZ Y que cumplas muchos más...
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×