¿El desarrollo agil motiva a no preocuparse del futuro? vía @jchyip

Este problema lo he visto muchas veces
¿que opinan Uds. de este artículo de Jason Yip?

Agile encourages developers not to think about the future?

Yo creo que es más importante Unit Tests y Fail Fast,

YAGNI y STTCPW son más bien parte de Fail Fast.

Quizás debería explayarme un poco.

Kanban tiene la idea de que para ir más rápido, WIP = 1. Al menos cada desarrollador debe tener WIP = 1, de esa manera te peudes concentrar en una tarea.

Mi experiencia ha sido: dale todo el tiempo del mundo al programador, que estime como quiera: 1 hora, 1 día, 1 mes, 1 año. A eso agrégale un “riesgo” que es un multiplicador que singifica “el máximo tiempo que se puede demorar”, entre 1 y 10. Si fueras un jefe ¿qué mirarías? La respuesta es estimación * riesgo > 2 días => divide la tarea en tareas componentes que resuelven conceptualmente el problema. Supongamos que originalmente eran 2 semanas de trabajo estimado. La subdivisión la hace el programador sólo, y estima cada tarea. El resultado invariablemente son 4 tareas de 30 minutos c/u y una tarea que 1.5 semanas.

Entonces tomas la tarea de 1.5 semanas y se la asignas a otro desarrollador para que la estime. Invariablemente él va a estimar menso tiempo, por ejemplo 4 días. Le pides lo mismo, divide, 3 tareas de 1 hora y una tarea 2 días.

Se logró al subidivisón en tareas de menos de 2 días.

Ahora la gente se concentra en una sóla tarea de menos de 2 días.

Debemos notar que el trabajo original de 2 semanas quedó reducido a un total de 2 horas para un desarrollador y 2 dias y 3 horas para otro, de modo que todo estará hecho en menos de 3 días.

¿Qué tiene que ver esto con despreocuparse del futuro?

  1. Si todo está escrto con unit tests, lo que ya está hecho no me preocupa.
  2. Si tengo una sola tarea asignada y estimada por mí, entonces no tengo nada de qué preocuparme excepto esta tarea. Y mi peor estimación son 2 días a lo más, es casi imposible fallar.
  3. Si encuentro algo dificl, le asigno más tiempo o le pongo más riesgo, eso automáticamente hace que entre el scrum master en acción y me pida dividir la tarea. Lo puedo hacer yo directamente ya que el scrum master siempre la divide y pide la colaboración de otros en los temas que considero difíciles.

¿Entonces qué podría fallar?

Que estemos construyendo el producto incorrecto. Eso se resuelve con Fail Fast.

¿Porque YAGNI y STTCPW son parte de Fail Fast?

Porque puede que me de cuenta que lo que estoy proponiendo sea un mal diseño, pero es la manera más rápida de salir al mercado y probar si es el producto correcto… y por producto correcto me refiero a uno que “entusiasma” al cliente o usuario. Basta con una cáscara que parezca que hace algo,si eso motiva al ciiente, estamos “listos”…

Eso es mucho más importante que escribir el código correcto, escribir el producto correcto.

YAGNI y STTCPW deben ser tomados con cuidado. La idea de que sean tan simples es que sean fácilmente reemplazables por diseños más elaborados. Cuando parto mi proyecto no hay código escrito, de modo que no hay dependencias. Si escribo mucho código para lograr YAGNI, está mal. Si luego tengo muchas partes que modificar para cambiar mi YAGNI por YAGNI2 que es un poco más elaborado, está mal (a menos que sea un refactoring automático).

Se debe tender a los patrones de diseño, no necesariamente a los 23 patrones de diseño GoF, sino a la idea fundamental detrás de los patrones de diseño GoF que es que el programa sea más dinámico, que tome más decisiones en tiempo de ejecución que en tiempo de compilación. En otras palabras, se debe intentar llegar a los “feature toggles”: queremos agregar una funcionalidad o quitarla, vamos a un página de configuración y activamos o desactivamos la funcionalidad, no es necesario bajar el sistema, ni recompilar, ni escribir código (ya está escrito o es un plugin que se comunica através de una API bien definida), las dependecias están correctamente especificadas y son manejadas por el mismo software.

Esto suena a ANTi-YAGNI, pero pensemos en un sistema con 100 funcionalidades o 200, el problema no es construir más funcionalidades, sino administrar las que ya existen, porque una nueva funcionalidad sólo es compleja cuando impacta funcionalidades ya existentes, por ejemplo, de modo que son esas funcionalidades existentes las que deben ser “administradas” (agregar preguntas en la UI en ciertos puntos, agregar procedimientos en determinados lugares ya existentes,etc.). Luego agrego una funcionalidad más, ¿la quiere el cliente? Fail fast es la respuesta. ¿me desordena lo que ya existe? Los unit tests son la respuesta. ¿Me doy cuenta tardíamente que esa funcionalidad no la queremos? Feature toggles me soluciona el problema.

1 me gusta