#03 Feature by feature

Software economics book resources

Sorry for the mess! This version is just a first draft ;-)

Términos a googlear

feedback, iterativo, scrum, kanban, XP, Toc, Lean, Lean Startup, cost of delay, carrying cost, wip, flow, bottleneck, 100% utilization, mvp, agile, user story, continuous delivery, impact mapping, user story mapping, elephant carpaccio, emergent design, evolutionary architecture,

Notes

Speed in software development

Disclaimer: he escrito un resumen a mi bola de un superartículo que he leído http://www.targetprocess.com/articles/speed-in-software-development.html

Sprint, Marathon and intervals

  • Extreme Sprint: no dormir, cafeina a tope. Puedes aguantar un mes empezando a hacer daño a tu salud. Más, si la sacrificas completamente.

  • Moderate Sprint: 8-10 horas diarias. Siempre se anda tarde. Trabajo aburrido. Se puede aguantar años, la productividad va disminuyendo pero nadie se da cuenta.

  • Marathon: 6-8 horas diarias. Tiempo para deporte, familia y amigos. Tiempo para pensar en profundidad en los problemas. Rara vez ocurre, normalmente los managers quieren más y lo intentan conseguir de maneras estúpidas como empujar tareas, “somos héroes”  y sobretrabajo.

  • Intervalos: mezcla de marathon and “fast pace sprint”.

Fast pace sprint: nada de reuniones sobre el futuro, formaciones, actividades de recursos humanos, etc… sólo entregar, probar y documentar código.

Software Speed Model

Verde: aumenta la velocidad. Rojo, la disminuye. Amarillo: existen límites.Flecha verde: aumenta el efecto. Fecha roja: disminuye el efecto.

Skill and Experience

Aumentar las habilidades de los desarrolladores disminuye la complejidad del sistema. La posibilidad de contratar gente ya formada es limitada. La posibilidad de contratar gente y hacerla crecer no. Contrata a gente a la que le guste aprender nuevas cosas. Ayuda a la gente a aprender. Opciones:

  • compra libros

  • envia a conferencias

  • monta una conferencia

  • da tiempo para aprender nuevas cosas (80-20, learning fridays, etc…)

  • proyectos personales, coursera, leer artículos

Trabajar un 20% menos a la semana implica bajar la velocidad. ¿Importa? En modo marathon no. En modo sprint sí. Hay que ver cuando te lo puedes permitir.

Ayuda a la gente a entender mejor el dominio

Evitar que el desarrollador implemente cosas ciegamente sin entederlas. Ayuda a evitar re-work. Ayuda a detectar con mayor rapidez malas soluciones.

Experiencia

No es lo mismo gente con años de experiencia que gente experta en algo (con la habilidad para algo). La clave de la velocidad es la habilidad (skill). Si tienes mucha experiencia en habilidades irrelevantes, no sirve. De todas formas, un developer con 20 años de experiencia, normalmente resolverá las cosas más rápidametne que uno de 5.

System complexity

La complejidad es inherente al software. Tenemos que intentar construir sistemas simples, pero no el más simple. La gente con habilidad hace las cosas menos complejas. La complejidad ralentiza mucho el software.

Deuda técnica

La deuda técnica es una decisión deliberada de no entregar la mejor solución a cambio de entregarlo más rápido. Mal código y malas soluciones no es deuda técnica. La deuda técnica no es siempre mala. Está bien si sabes que, por ir más rápido, luego tienes que pagar y con intereses. Lo malo es cuando la gente obvia el pago, y la deuda aumenta hasta que la situación es insostenible. Si los managers nos aprietan, es nuestra responsabilidad decirles que se está sacrificando por llegar a la fecha límite. La deuda técnica se paga mediante refactoring o reescritura. Llegados a cierto punto, la organización puede estar pagando más por la deuda técnica que por el propio desarrollo.

Refactoring

Refactorizar es imposible sin una buena batería de pruebas automatizadas. ¿Por qué no refactorizamos todo el tiempo? Porque refactorizar es una actividad que no añade valor de negocio. El cliente no recibe nada a cambio. Lo hacemos para reducir la deuda técnica y la complejidad del sistema y porque sabemos a ciencia cierta que no podemos crear un sistema suficientemente bueno al primer intento.

Pruebas automáticas lentas o inestables

La complejidad del sistema hace que las pruebas puedan llegar a ser demasiado lentas. En parte se puede solucionar con la ejecución paralela de las mismas. Es mucho peor cuando tienes pruebas que fallan de manera intermitente. A veces se puede llegar a perder una enorme cantidad de tiempo en intentar encontrar por qué sucede…

Cowboy Coding

A muchos desarrolladores no les gustan los procesos. Les gusta programar libremente saltándoselos. Esto puede estar bien si trabajas solo o en un equipo pequeño. En un desarrollo con más de 20 desarrolladores tiene que haber un proceso bien definido. Y disciplina. Extreme Programming es, por ejemplo, una metodología que exige un montón de disciplina y energía, pero que entrega al final un trabajo de calidad.

Turboboost en el corto plazo

A veces uno puede meter el turbo para llegar a una cita importante sacrificando la calidad. Mientras luego se sepa que hay que pagar la deuda técnica generada.

Fechas límite (deadline)

Las fechas límite nunca tienen que ver con una arquitectura limpia o refactorizar. Tienen que ver con funcionalidad. Nos meten presión y nos hacen programar peor y aumentar la complejidad del sistema. Así de claro. Mezclar fechas límite con una actitud épica es todavía peor. Usar fechas límite a veces puede ser necesarias pero no pueden ser la manera normal de desarrollar.

Desarrollo iterativo y fechas límite

El desarrollo por sprints es desarrollar a base de fechas límite. Y, como consecuencia, puede tener los mismos efectos contraproducentes comentados anteriormente. Al ser sprints pequeños, los efectos también serán pequeños. El desarrollo por sprints puede estar bien, pero no hay que perder de vista el efecto de las fechas límite.

Sobretrabajar

La manera más simple de aumentar la cantidad de funcionalidad entregada es sobretrabajar. A veces no hay otro remedio. Pero intentar solucionar los problemas sobretrabajando hace que cuando el problema termina de explotar, las consecuencias sean peores todavía. Artículo interesante sobre sobretrabajar.

Pasión

La pasión es buena. La gente apasionada se preocupa por su trabajo más. Pero no todo lo que reluce es oro. La gente apasionada tiene problemas para encontrar un equilibrio entre trabajo y vida personal. Puede quemarse antes y acabar deprimida.

Trabajo concentrado y enfocado

El trabajo enfocado y sin interrupciones es clave para que un programador entregue un buen código. Es difícil sino mantener en el cerebro abstracciones de gran tamaño. Repaso a las cosas que influyen en el trabajo concentrado.

Equipos inestables/ Rotación de personal

Tuckman define cuatro estados de un equipo: forming, storming, norming, performing. La auténtica productividad del equipo se produce en la fase de performing. Si se rota a las personas, los equipos vuelven a pasar una y otra vez por las fases de forming, storming y norming. Es difícil desarrollar buenas relaciones si rotas a las personas todo el rato. Puede estar bien reformar equipos que no estén siendo muy productivos. Pero se tarda meses en saberlo porque se puede pasar mucho tiempo en la fase de storming.

Open Space

Si tienes equipos estables es importante que cada equipo de, por ejemplo, seis personas esté en un espacio abierto. Pero si toda la empresa está en un mismo espacio abierto hay demasiado ruido. Lo ideal es tener salas “tamaño equipo”.

IM/Skype/Notifications

Las notificaciones destruyen tu concentración. Y si no le pones atención, se embeben en tu flujo diario. Aunque tengas pocas, pueden destruir la productividad de tu día. Si estás programando, ciérralo todo. Estos canales de comunicación son muy útiles, pero al mismo tiempo muy peligrosos. Y es muy difícil resolver el problema a nivel sistémico.

Multi-tasking

Aunque sea muy fácil decirlo y muy difícil hacerlo, hay que intentar hacer una tarea cada vez y poner toda la concentración en ella, evitando las ineficiencias de los cambios de contexto. La técnica del pomodoro puede ayudar.

Rehacer

Obviamente reduce la velocidad en desarrollar software el tener que rehacer cosas. No podemos evitarlo completamente, pero sí reducirlo al máximo. Ocurre por tres motivos principalmente:

Errores (bugs)

Es imposible evitar tener alguno. Pero es importante encontrarlos rápidamente. El ciclo de feedback tiene que ser rápido y tiene que haber colaboración entre el que desarrolla y el que prueba. Encontrar errores en producción es todavía peor, sobre todo a nivel de comunicación (desarrollador, probador, cliente, usuario…)

Requisitos vagos

Suponen intentar adivinar lo que se quiere hacer. Sin saberlo realmente. A veces porque el Dueño de producto no está disponible. A veces porque es muy difícil especificar por adelantado los detalles.

  • Transición de UX a desarrollo: en el camino se pierde información. O se repiten discusiones ya aclaradas previamente. Formas de mejorar esto:

    • Los desarrolladores participan en la UX desde el principio

    • Antes de implementar una funcionalidad se hace una reunión 'previa con todo el mundo para tener una misma visión 'compartida.

    • escribir buenas especificaciones (imposible!)

<!-- -->

  • Especificaciones:

Fallo de demanda (Do the right things)

Los errores son malos pero… ¿qué pasa con las funcionalidades que nadie usa? Todo el tiempo de pensarlas, desarrollarlas y probarlas no sirve para nada. ¿Cómo evitarlo?

  • Canales de comunicación: que los usuarios tengan una manera sencilla de dar feedback.

  • Estadísticas: úsalas para saber si una funcionalidad es popular o no.

  • Ranking de funcionalidades: crea un modelo lineal simple y úsalo para crear un ranking de funcionalidades. Por ejemplo, basándote en uso, votos de usuarios, tamaño, dificultad, frecuencia de uso…

  • UX feedback: prototipos, sketches, a/b testing…

Más gente / Más equipos de desarrollo

Las organizaciones pequeñas tienen mayor “velocidad por unidad” mientras las organizaciones grandes tienen mayor “velocidad global” (pero les cuesta económicamente lo suyo conseguirla). Más gente significa más coordinación, más reuniones, más desperdicio.

Contratar

Contratar a nueva gente puede aumentar la velocidad de la organización a largo plazo. A corto, se pierde tiempo en: entrevistar gente para contratarla, mentorizar a los nuevos para transmitirles conocimiento, etc. Y, además, el propio contratado tardará tiempo en ser totalmente productivo. Si quieres ir rápido a corto plazo, contratando a más gente irás más lento.

Coordinación

Cuanta más jerarquía más desperdicio en coordinación y reuniones. Las organización en redes, de manera plana y con equipos autónomos y multifuncionales ayuda a reducir la coordinación. Nota: la estructura de las organizaciones se transmite a la estructura del software. Una jerarquía flexible tiende a crear software flexible. Sería interesante estudiar cómo son las estructuras de IBM o Atlassian y ver cómo se transmite a su software.

Desperdicio y tareas que no añaden valor

Reuniones

La mayoría de las reuniones apestan. Hay que intentar reducirlas al mínimo. Las organizaciones pequeñas pueden vivir sin reuniones. A partir de cierto tamaño, hacen falta. Existen un montón de libros sobre cómo mejorar las reuniones y… ¿sabes qué? Funcionan. Todas las reuniones deberían tener: facilitación, agenda, gente preparada y resultados.

Para generar algo nuevo, tienes que pasar tiempo pensando.

Deporte en el trabajo

El deporte en el trabajo está estupendamente. Las soluciones creativas no vienen de estar sin levantarse del asiento ocho horas. Está bien levantarse, charlar y hacer algo de ping-pong.

Aprender en el trabajo

Las organizaciones contratan a gente con capacidad para aprender y potencial, pero inexplicablemente no les dan tiempo para hacerlo. El efecto de dejar tiempo de aprendizaje en el trabajo (side-projects, hackatones, libros, conferencias…) no se puede ver a corto plazo. Además, no existe un modelo para cuantificarlo a nivel económico.

Equilibrio entre trabajo y vida personal

Si trabajas más y más duro, acabarás haciéndolo más y más tontamente. Cuando tienes un problema importante es difícil no pensar en él en el trabajo, en casa, en la ducha,… pero eso no puede ser una constante. Un buen manager intentará que los desarrolladores tengan hobbies y aficiones y dediquen tiempo a ello.

Resumiendo

Creo que el estrés está bien en momentos puntuales. La velocidad/productividad en el desarrollo de software es un problema a abordar desde múltiples puntos de vista. Es MUY difícil y no puede reducirse a decir “hay que trabajar más rápido” y centrarse en dejar de hacer cosas y tomar atajos.

Links

Images

Books

Personas alrededor de el incremento

Descubrimiento iterativo

Lean/Scrum/Kanban/XP: desde las trincheras

Mentalidad Lean

Devops