Archivo de la etiqueta: Agile

Preguntas que tal vez te hagas de los Coderetreats

Apuntaros esta fecha todos los desarrolladores: Sábado 14 de Diciembre del 2013. Ese día se celebra en distintas ciudades de todo el mundo el Día Global del Coderetreat.

“¿Y qué es esta frikada?” Esta frikada es una oportunidad única de aprender a mejorar la calidad personal del desarrollo de software.

“Pero yo ya programo mucho en el trabajo”. Sí, pero cuando se trabaja la atención está en acabar lo antes posible. Normalmente se programa del modo que se cree más rápido sin intentar buscar nuevas maneras de hacerlo. Haciendo un kata, como el del Juego de la Vida que es el que se suele hacer ese día, te puedes permitir el lujo de hacerlo de esa forma que has leído u oídopero que nunca te habías atrevido a probar. El objetivo NO es terminar el kata. De hecho, a los 45 minutos tienes que borrar el código que has hecho.

“¿Queeee?, ¿Borrar lo que he hecho?” Cierto. Cada 45 minutos vas a enfrentarte al problema desde distintos ángulos y con determinadas restricciones que van cambiando.

“¿Y crees entonces que aprenderé algo?” Ciertamente. Mejorarás estas habilidades:

TDD: +4 Todas las sesiones se realizan haciendo primero los tests y después la solución.
Código limpio: +3 El foco constante está en trabajar con ese código ideal que nunca te has atrevido a escribir por falta de tiempo
Programación en parejas: +3 Todas las sesiones son en pareja mediante el método de PingPong. Uno escribe el test y hace que falla, el otro lo desarrolla,lo pasa a verde y escribe el test para el otro miembro.
Otros lenguajes: 30% de probabildades En cada sesión podrás trabajar con otros que usan otros lenguajes de programación como su segunda lengua madre
Carisma: +2 Trabajar codo con codo con gente con la que nunca has trabajado servirá para mejorar tus habilidades sociales en el trabajo.

“¿Dónde me puedo apuntar a uno?” En España se están haciendo en varios lugares. Aquí tienes una lista

Alicante http://tinyurl.com/on39bq4
Barcelona http://agile-barcelona.org
Caceres http://tinyurl.com/p52qq3d
Madrid http://tinyurl.com/p884qtw
Ourense http://tinyurl.com/on72tsj
Valencia http://tinyurl.com/q3yyj5d
Zaragoza http://tinyurl.com/pa7xp6r

Para buscar en otros lugares del mundo puedes buscarlo aquí: http://coderetreat.org/events

Date prisa. Normalmente las plazas son limitadas.

Si te pica el gusanillo aquí puedes ver más información de los amigos de Agile Madrid. madridcoderetreat.wordpress.com

Si tienes una empresa o conoces alguna que esté dispuesta a patrocinar algo de estas sesiones. Todos los participantes estarán muy agradecidos de que por ejemplo traiga la comida del día o de algun regalo o alguna licencia de software. Animará mucho el día y todos los asistentes tendrán en muy buena imagen la empresa. Contacta con el organizador de la sesión y preguntale qué necesita si estas interesado.

Enfermería, Desarrollo de Software y Servant Leadership

La ingeniería informática es una profesión joven. Algunos nos orgullecemos de haber empezado hace 25 años con los MSXs y su BASIC. Otros empezaron su profesión con las tarjetas perforadas y sin poder preguntar en aquel entonces a nadie cualquier problema técnico que pudieran encontrar (Oh! Bendito Stackoverflow!)

La medicina, por el contrario,  es una de las profesiones técnicas más antiguas. Desde los antiguos chamanes, pasando por el árabe Avicena (Ali Ibn Cina) a las modernas clínicas y hospitales.  Florence Nightingale, a finales del siglo 19 hizo un gran avance en la medicina separando responsabilidades y posibilitando que enfermeras, entrenadas por ella misma, liberaran a los saturados médicos en las curas sencillas de la Guerra de Crimea mejorando su recuperación. Desde ese momento, mucho ha llovido en en el mundo de la enfermería y han adquirido muchos, diversos y muy importantes roles.

Un ejemplo claro de su importante labor es la de las auxiliares en las consultas médicas. Las ves entrando y saliendo de las consultas, recibiendo llamadas, llamando a pacientes,… Tengo la suerte de estar casado con una de ellas y desde hace poco me he dado cuenta de la similitud de lo que hace con mi trabajo como director de desarrollo. Paso a citar algunas de las cosas que hacen:

  • Preparan todo el material y documentación para que los médicos puedan hacer más productivo el tiempo que pasan con el paciente
  • Bloquean las interrupciones (comerciales, llamadas, preguntas,..) para que se puedan centrar en el paciente hasta que termina la consulta
  • Gestionar prioridades. Dan respuesta personales a los pacientes citándolos según la urgencia de sus problemas.
  • Reducir el Lead Time (Tiempo de Entrega). Citan a los pacientes para analíticas, pruebas de anestesia, cirugía,.. de tal modo que el paciente pase el menor tiempo posible desde que empieza el proceso hasta que termina y sea más rápido y menos traumático.

Esa función en los equipos de desarrollo la tienen los Scrum Masters/Team Leaders/Directores de Desarrollo/Whatever…. Ambos nos ocupamos en que nuestro  equipo (médicos o desarrolladores) sean lo más productivos posible con su tiempo. Los papeles y herramientas de trabajo más importantes tienen que estar en estado READY para que puedan trabajar sin interrupciones y sin que tengan que ocupar su tiempo en algo que puede hacer otra persona. Ambos podemos hacer que la productividad de un equipo aumente o disminuya drásticamente según lo bien o mal que lo hagamos. En gestión de proyectos Ágiles lo llamamos Servant Leadership como si fuera un concepto nuevo pero es algo que lo llevan haciendo hace tiempo las auxiliares, sin tanto bombo y platillo y conceptos en inglés.

La próxima vez que este esperando a entrar al medico fíjate en ellas, las auxiliares o enfermeras, quizá aprendas algo de cómo mejorar la productividad de tu equipo de desarrollo.

Planificación estratégica Ágil mediante Releases

Definición de Release

Scrum y Agile en general trabajan con timeboxes. Estos timeboxes permiten trabajar al equipo o empresa aun ritmo constante entregando software iterativamente y siendo muy fiable en las fechas de entrega. Los Sprints se suelen hacer de menos de un mes y este tiempo es suficiente para el departamento de desarrollo en analizar, desarrollar y probar el software a entregar. Sin embargo, cuando estamos hablando del trabajo asociado con este software hecho por toda la compañía, el periodo de Sprint queda muy pequeño y se hace necesario hablar de peridos más largos llamados. En VSN estos timeboxes más largos que el sprint los llamamos Releases. Estos Releases los componemos de cuatro Sprints para así hacer cuatro al año.

Ventajas del Release

Un Release permite una definición estratégica del software más allá de lo que se puede preveer para un sprint. Se pueden definir uno o dos Objetivos de alto nivel y en base a estos se definirán los Epics e historias de usuario más importantes. Esta definición estratégica permite un trabajo sincronizado de todos los departamentos de una empresa. Los comerciales saben cómo enfocar sus ventas, los de Marketing pueden preparar la web y la información comercial, los de Operaciones pueden decidir con qué configuración de hardware funciona mejor,…

Definición de epics que constituyen el release por parte del Product Owner

Antes de comenzar el periodo del Release propiamente dicho, el product Owner debe decidir qué objetivo u objetivos tendrá el release y a partir de estos definirá una serie de Epics o historias priorizadas. También puede haber caracerísticas que no encajen con los objetivos pero que sean igualmente importantes para su trabajo con el resto.

Ponderacion de los epics por parte del equipo

El primer día del Release el equipo de desarrollo se reune para hacer una ponderácion de los epics e historias. Se puede usar el Planning Poker pero se puede usar cualquier sistema de estimación ágil. En VSN, usamos el siguiente método: Se preparan en columnas ponderadas con la serie de Fiabonnacci y bajo ellas distintos epics que se hayan ajustado a estos tamaños. Se hace una definición de cada característica a desarrollar, se escribe el titulo en una tarjeta y por turno rodado cada miembro pone la tarjeta junto a la que más se parece en tamaño. Explica sus argumentos para esa ponderación  para que el resto las entienda. Cada miembro cuando llega su turno puede ponderar una caracteristica nueva o modificar una ponderación anterior. Cuando todas se hayan leido todos los epics deben tener su tamaño relativo.

Encajamiento en Sprints

Una vez ponderadas los nuevos desarrollos hay que encajarlos en Sprints. Esto lo puede hacer el equipo en conjunto. Se recomienda poner en los primeros sprints las historias o epics más grandes y complejos. Estas historias que tienen un interfaz importante nuevo o que requieren investigación. De este modo, si algo de lo desarrollado en estos primeros sprints no se corresponde con lo esperado o hay que cambiar de tecnología, existen sprints antes del fin de Release para ajustar los problemas encontrados. En los Sprints finales se harán las historias pequeñas y que no ponen en riesgo el objetivo estratégico. Es importante conocer la disponibilidad de los desarrolladores (vacaciones en medio) y el nivel de historias o puntos que normalmente se usan para corrección de bugs o desarrollos urgentes. A partir de esta disponibilidad del equipo y la parte de cada sprint que se puede usar para Release se hace este encajamiento.

Feedback y reajuste de sprints siguientes

En cada final de Sprint se hace una demo de lo desarrollado al resto de la empresa y se muestra la lista de historias resueltas y las que no han podido resolverse. Con el resultado de lo desarrollado y teniendo en cuenta el trabajo pendiente para el release se puede reajustar el encajamiento de los sprints sucesivos. Es muy útil tener una forma de visualizar los bloques trabajo  que se retrasan para el sprint siguiente y los que se prevee que no entrarán finalmente en el release.

Retrospectiva Fin de Release

En el último día del Release es muy recomendable hacer una retrospectiva que incluya a todos los departamentos implicados en el Release. En este se pueden mejorar el modo en el que se ha hecho las entregas y la comunicación interdepartamental para mejorar y no cometer los mismos errores.

No estimes, rompe el trabajo pendiente

Estimar el trabajo pendiente es algo que se considera necesario para poder planificar el tiempo y los recursos de cara al futuro. Si trabajas con Scrum seguramente al principio del Sprint planificarás con tu equipo los puntos de historia que vais a meter en el sprint y también quizá las horas de las tareas. Gracias a esta planificación podemos tener “mas o menos” un sprint con una cantidad de trabajo controlada y una posible planificación de más a largo plazo en un release plan.

Si embargo, el trabajo de estimación realmente no es un trabajo que aporte valor al producto final. El que estimes con una precisión del 100% o del 20% no hará que el cliente obtenga más o menos valor y seguro que no pagará más por ello. Según la propuesta Lean debemos intentar reducir o eliminar aquellas tareas que no aporten valor al cliente y esta tiene pinta de ello. Entonces… ¿intentamos trabajar sin planificación del sprint o del producto sólo por esto?

Por otro lado, siempre se recomienda trabajar con historias lo más pequeñas posibles. La teoría de colas indica que con un tamaño de paquete de trabajo menor conseguimos una velocidad más constante que con tamaños muy dispersos. Además, desarrollando historias pequeñas, acortamos el tiempo de feedback y esto conlleva una reducción de errores. Muy bonito pero … ¿Cómo nos puede ayudar el tener historias pequeñas con el problema de la planificación?

Cuando tenemos historias más pequeñas conseguimos una homogeneización de los tamaños de las mismas. Esto es, hay poca diferencia entre la historia más grande y más pequeña que metemos dentro del sprint. Con un tamaño más o menos constante y una capacidad de desarrollo fija obtenemos una capacidad basada en historias por sprint. Según trabajamos así, Sprint tras sprint vemos que obtenemos un número más o menos constante de historias.  La misma precisión es la misma que se obtiene cuando estimamos por puntos. Esta cantidad fija de historias nos permite planificar el sprint y, si además rompemos mediante análisis las historias que componen el producto más allá del sprint, planificaremos los tiempos de entrega de producto.

Cuando el desarrollador se pregunta “¿Qué voy a hacer hoy?”

Esta pregunta se pueden hacer muchos desarrolladores todos los días cuando entran al trabajo. Hay mucho trabajo por completar pero.. ¿qué es lo más eficiente que se puede hacer?

Cuando se intenta tener un sistema Agile/Lean es muy importante que el flujo de trabajo sea llevado mediante sistema PULL. Para conseguir esto las tareas deben atraerse hacia las ultimas fases del desarrollo. También hay que intentar reducir la cantidad de Trabajo en Curso (Work In Progress,WIP) por lo que antes de empezar nuevas características hay que intentar completar antes las que estan en curso.

Para conseguir todo esto, y con el apoyo de un tablero kanban fisico o virtual, los desarrolladores pueden decidir qué hacer en base a estas preguntas.

1.- ¿TENGO ALGUN TEST FALLIDO QUE DEBO ARREGLAR?  –> ARREGLARLO

Muchas veces los tests fallidos se acumulan y sólo se arreglan al final de sprint. Esto provoca que haya una acumulación de desarrollos y tests que pueden hacer que el deadline o fin de sprint se retrase. Debería ser la prioridad principal el completar los desarrollos ya hechos arreglando esos fallos que se han encontrado antes de otra cosa.

2.- ¿EL NUMERO DE TESTS PENDIENTES HA ALCANZADO SU MAXIMO? –> PASAR UN TEST

En VSN, el equipo de desarrollo ha definido cómo número máximo de historias esperando el test a 3. Si en el daily stand-up se ve que ha alcanzado ese número, se reparten 2 tests entre los desarrolladores para aliviar esa saturación. Naturalmente, ningún desarrollador testea lo que él mismo ha desarrollado, sino lo que ha hecho otro.

3.- ¿TENGO ALGUN DESARROLLO EN CURSO? –> CONTINUAR CON EL DESARROLLO

Naturalmente, una buenísima manera de avanzar es seguir con la historia y las tareas que había en curso.

4.- ¿PUEDO AYUDAR A TERMINAR ALGUNA HISTORIA EN CURSO? –> AYUDAR CON ESA HISTORIA

Si hay desarrolladores a los que se puede ayudar hay que hacerlo llegado este punto. Puede ser mediante el pair-programming, puede ser haciendo alguna tarea que se puede paralelizar, puede ser invesigando algo en Internet que necesite. Lo que se pueda hacer para ayudar a terminar antes con las historias que ya están en desarrollo.

5.- EMPEZAR HISTORIA LISTA EN ORDEN DE PRIORIDAD

Si a las anteriores preguntas se ha respondido NO pues no hay mayor problema. Se elige una historia por empezar siguiendo el orden de prioridad  establecido y a desarrollarla

La parte impredecible de una estimación

¿Cuanto vas a tardar en terminar esta tarea? Esta pregunta puede resultar muy fácil de responder y hacer una respuesta con una precisión absoluta, o tambien puede resultar muy dificil y dar una respuesta que nada tenga que ver con lo que al final se termina tardando.

¿De qué depende?

En tareas como las que solemos hacer los desarrolladores de software, el resultado de nuestro trabajo no es solamente el código generado sino tambien se genera conocimiento para el propio desarrollador. Para identificar qué parte del tiempo se ha utilizado para generar la funcionalidad y qué parte del tiempo se ha utilizado para generar el conocimiento sólo hay que hacerse una pregunta:

¿Qué tardarías ahora si tuvieras que repetir la misma tarea?

Ese tiempo que responderías corresponde con el tiempo usado en la generación del producto y el resto fue el usado en la generación de conocimiento.

KnowledgeGeneration

En entornos en los que el lenguaje de programación es muy conocido y el tipo de producto final se ha hecho muchas veces, hay poca generación de conocimiento y el tiempo que se tarda se puede predecir facilmente.

LowLearning

Sin embargo en entornos de innovación continua muchas veces el tiempo de generación de conocimiento es la mayor parte.

HighLearning

Realizando pair-programming se reduce el tiempo impredecible ya que la en la tarea sólo se genera el conocimiento que no tiene ninguno de los dos componentes de la pareja.

PairProgramming

Este tiempo de duración desconocida puede llevar al traste cualquier deadline. En proyectos tradicionales waterfall puede provocar que no se llegue a tiempo y en proyectos Scrum provocan que los sprints se solapen, estando varios días del siguiente sprint terminando tareas retrasadas. Una manera de minimizar su impacto es reducir la cantidad de  trabajo en curso, reduciendo el tamaño de las historias y focalizando a todo el equipo en la consecución de la misma en lugar de tener muchas historias abiertas.

Scrumban, de moda pero quizá no necesario

Nota: El Scrumban del que hablo no tiene nada que ver con el que acuña David J Anderson

Hace poco escribí un tweet en el que decía que el Scrumban no era necesario. Los 140 caracteres del tweeter no dan espacio para una explicación de esto pero voy a intentarlo aquí.

Scrumban, al menos el que conozco yo, se basa en dos paneles. Un panel con las historias de usuario del sprint, características y bugs a desarrollar provenientes del product owner, y un panel kanban con el resto de tareas que no tienen que ver con las historias de usuario previstas. Normalmente son problemas a resolver de soporte de algún cliente o relativas a otros departamentos de la empresa.

En el panel kanban se establecen 3 prioridades relativas a las tareas del panel Scrum.

  • Una prioridad llamada ASAP, en lo que se hacen tareas cuando el trabajo pendiente en el panel Scrum sea menor del ideal que tocaría para ese día.
  • Una prioridad llamada PRIO en se cogen tareas cuando se ha terminado en las que se está trabajando en ese momento.
  • También una prioridad FIRE en la que cuando se añade una tarea hay que hacerla de modo inminente dejando el trabajo a mitad. Naturalmente en la retrospectiva se analiza por qué ha ocurrido una tarea FIRE y se intenta evitar que ocurra en el futuro.

Yo veo un problema grave en el hecho que sean dos paneles con la misma función y añade gestión extra que quizá no sea necesaria. Además tener dos sitios donde mirar el trabajo es más complejo que tener uno solo en el que esté todo el trabajo que se está realizando.

Cuenta con que el Product Owner es el que pone las tareas al kanban y requiere que las prioridades sean muy claras. Tambien es una herramienta para que el equipo justifique ante el PO el haber hecho más o menos puntos de producto.  Yo nunca he entendido esta necesidad de justificación ya que todos deberíamos tener los mismos objetivos, que es dar valor a los clientes.

Yo entiendo tres prioridades que encajan en un solo panel.

  • La prioridad FIRE es que no hace falta ponerla en ningún panel, se le dice a la persona o personas involucradas que se ponen a ello inmediatamente.
  • La prioridad “lo tendrá a final de este sprint” en el que es posible que salga alguna historia que ya estuviera en el  sprint para que quepa la nueva.
  • La prioridad, “lo estudiaremos para el siguiente sprint” en el que se encajará como una historia más para el siguiente sprint dejando inalterable el actual.