BUENAS PRÁCTICASCómo implantarlas en proyectos tecnológicos...

y no morir en el intento

Ricard Clau (@ricardclau)Betabeers BCN 25-Enero-2013

RICARD CLAUBackend Tech Lead @ SocialPoint

He pasado por Emagister, Ulabox y PrivaliaA veces doy charlas

Y de vez en cuando me aceptan PR en Github

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

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

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

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

NEGOCIO

•Nos piden “cosas”

• Responsables de conseguir pasta

•No les entendemos bien

•Nos ven como una “commodity”

• Bajo conocimiento tecnológico

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

ELLOS TAMPOCO

• Features que se tiran a la basura

•Time to market, baja calidad

•No aceptan estimaciones largas de tiempo

• Se relegan temas técnicos hasta que es demasiado tarde

PROBLEMAS

DESARROLLO DICE

No se saben explicar

Tonterietas de negocio

No tienen ni idea

Metodologías ágiles

Gente de master

NEGOCIO CONTESTA

No entienden necesidades

Feature monetizadora

No conocen negocio

Rigidez operativa

Frikis

NO ES UNA GUERRAEstamos 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 que se espera que, en contextos similares, rindan similares resultados.”

¿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

¿POR QUÉ NO SE HACE?

•Desconocimiento

• Jefes sin conocimientos técnicos

• Complicado de explicar el retorno

• Entornos viciados

•Resistencia al cambio

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!

¿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

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 scrum master negocia

• Status diario para bloqueos

•Retrospectiva a fin de sprint

LA COSA NO FLUYE SI...

• Hay tareas unplanned siempre

• Se interrumpe continuamente al equipo de desarrollo

•Negocio impone tiempos

• Los dailys se eternizan

• Las retrospectivas no arreglan nada

¿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

INTRODUCCIÓN GRADUAL

•Dailys y retrospectivas

• Listado de tareas a largo plazo

•Tablón bien visible

• Generar y transmitir confianza

• Explicar SIEMPRE por qué tardamos X días en hacer “esa tontería”

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 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

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

• Fichar a lo loco, en plan cárnica@empresaurioTIC

DESARROLLADORESTené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 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

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

UTILIZA FRAMEWORKSNo 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 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

PERFORMANCE

•Minimiza las requests

•Cachea todo lo que puedas

• Usa colas donde puedas

• Las microoptimizaciones no valen para nada

•Afina settings de servidor

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

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 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!

¿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

• Es difícil justificar las horas invertidas... hasta que previenen catástrofes o bajan los bugs

NO SÉ CÓMO EMPEZAR

• Empieza haciendo macros con Selenium IDE

• Intenta instalar Selenium en local, haz una pequeña demo 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, ...

• Céntrate en cosas que tengan valor, no te obsesiones con la cobertura 100%

INTEGRACIÓN CONTINUAHay 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í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!

MUCHÍSIMAS GRACIAS

¡Preguntad lo que queráis, no os cortéis!

Ricard Clau (@ricardclau)ricard.clau@gmail.com

CUMPLEAÑOS FELIZY que cumplas muchos más...