Categoría: Project Management

El sabor de la buena UX

Los programas de TV de moda van cambiando año tras año. Reality shows, concursos de talento de canto, de baile, de salto en trampolín (sigh!). Ahora estan de moda los concursos de cocina como Master Chef, Top Chef y otros…

Tengo que admitir que a estos últimos sí estoy algo enganchado porque me siento identificado con los concursantes en los momentos en los que los jueces van a probar el plato, lo miran, lo prueban y lo juzgan. Todo lo aprendido por el cocinero antes de esa elaboración junto con la suerte y pericia en el momento de la elaboración se plasman en el plato.

Sé que es la enésima analogía del desarrollo de software, pero me vais a permitir usarla. Voy a analizar las tres partes de un software bien desarrollado.

La receta es la historia de usuario.
Cuando se define la historia de usuario es cuando el cocinero piensa qué va a cocinar. Puede ser lomo de atún, muslos de pollo a la pimienta o pastel de boniato con cintas de chocolate. El cocinero piensa qué es lo que le va a gustar al cliente y pasa a su ejecución. Igualmente un equipo de trabajo se enfrenta con una historia de usuario. La definición de esa historia indica cómo va a dar valor al cliente.

La presentación del plato es la estética del software
Tanto cuando se presenta un plato como cuando el cliente va a usar el software, el producto tiene que entrar por los ojos. En cocina es muy importante aspectos el corte de los ingredientes, su color, cómo están alineados en el plato,… . En software igualmente hay que prestar atención a las fuentes que se usan, los bordes, los colores, los iconos,… Todo tiene que tener un aspecto cuidado.

Y para terminar…
El sabor es la Experiencia de Usuario, la UX
Aqui es donde el cocinero y el equipo de software más se la juegan. En cocina un plato puede estar bien planificado y con una cuidadisima estética pero pueden pasar cosas como una textura de un ingrediente que no es la que te habías imaginado, como algo que cruje y no debería, una combinación de sabores que no encajan,… Cuando el usuario usa la característica desarrollada pueden sucederle cosas muy parecidas: información que falta y hace que no sepa usarla, tener que hacer muchos clicks, tener que ir abriendo y cerrando interfaces, tener elementos de interfaz muy pequeños o muy grandes,…

Me faltan dos páginas para terminar el libro de Lean UX (mi mente ya no procesaba letra escrita). En breve hablaré un poco cómo se trabajan esos dos aspectos, la estética y la experiencia de usuario. En un equipo Ágil se trabajan de forma completamente distinta y en momentos distintos. Lo veremos.

25/02/2014
Algo llamado «Declaración de Interdependencia»

De nuevo en el libro de David J Anderson, descubrí algo llamado «Declaration of Interdependence» DOI. En español, Declaración de Interdependencia. Esto fue una redefinición del manifiesto Agil pero centrado solamente en la gestión de proyectos. Sus autores forman la creme de la creme en gestión de proyectos ágiles con nombres como el propio David J Anderson, Alistar Cockburn o Mike Cohn.

Sus puntos son:

Incrementamos el retorno de la inversión (ROI) centrándonos en un flujo contínuo de valor.
Habla de dar valor al cliente de forma más continua posible. Mejor iteraciones de 2 semanas que de 3. Mejor aportaciones diarias que cada 2 semanas. Lo que necesita de forma más rápida posible desde el momento que lo necesita.

Entregamos resultados fiables haciendo participes a los clientes en interacciones frecuentes y compartiendo la propiedad.
El cliente debe formar parte activa del resultado. Cuando más participe en la definición de producto y en su revisión frecuente mejor adaptado estará a sus necesidades.

Esperamos lo inesperado y lo gestionamos mediante iteraciones, anticipación y adaptación.
El mundo es caotico por naturaleza. Lo que es cierto por la mañana deja de serlo por la tarde. Los procedimientos de trabajo tiene que ser flexibles y con ciclos cortos para poder seguir dando valor en estas condiciones.

Damos rienda suelta a la creatividad y la innovación reconociendo que los individuos son la fuente última de valor, y creando un entorno en el que puedan diferenciarse.
Los desarrolladores son los que crean. Cárgalos de stress en un entorno de trabajo restringido y obtendrás resultados mediocres. Déjalos que disfruten con lo que hacen y dales los medios oportunos y crearán grandezas.

Disparamos el rendimiento mediante la responsabilidad común sobre los resultados y sobre la propia efectividad del equipo.
No hay equipo más eficiente que aquel que está motivado y se le dan las herramientas para que ellos mismos hagan su trabajo más rápido y con mejor calidad.

Mejoramos la efectividad y la fiabilidad mediante estrategias, procesos y prácticas especificas para cada situación.
Existen muchas metodologías pero no hay una sola que funcione para todos los entornos. Hay que probar, medir y adaptar hasta encontrar el sistema que mejor funcione (mientras funcione).

Estos son los 6 puntos que habla la DOI. Puntos para reflexionar e interiorizar poco a poco. Puntos muy importante para quien quiere agilizar el desarrollo de software pero… David tiene razón.¡ Qué pena de nombre !.

21/02/2014
Programa sinvergüenza!

Cuando uno empieza la carrera de Ingeniería en Informática, nos dicen que estudiamos la carrera para ser jefes de proyecto, no programadores. ¡Tonterías!

Cierto es que la vida de programador es difícil, dura y aburrida cuando uno termina la carrera. Salen bugs por doquier, se escribe un código horrible y se pasan horas y horas haciendo que todo «medio funcione». La cosa cambia cuando se empieza a controlar el Código Limpio, a usar bien los tests unitarios y usar herramientas como la integración contínua. En ese momento se empieza a disfrutar programando como nunca, creando nuevas características con nuevas tecnologías prácticamente sin errores y en un ambiente de trabajo distendido que te permite ir a casa a una hora razonable.

En ese momento tu papel tiene que cambiar y te toca llevar un equipo.

Cuando se lleva un equipo de trabajo la mayoría de gente piensa que ya no debe programar, que te tienes que centrar en quitar bloqueos al equipo y proveer del mayor valor posible al cliente a tiempo. ¡ Qué pena!, ¿no?

En el libro «Lessons in Agile Managment: On the Road to Kanban«, David J Anderson habla que un jefe de equipo no tiene por qué dejar de programar. De hecho la mejor manera de inculcar las buenas prácticas es mediante el ejemplo. Yo tengo que aportar una cosa más. Tambien puede programar si el objetivo de ese software es evitarles interrupciones y/o mejorar su productividad. Un jefe de equipo puede practicar sus artes haciendo esa herramienta que viene perfecta a los de operaciones para obtener información de qué hacer sin tener que llamar a desarrollo, o esa herramienta para gestionar las dependencias de los proyectos. Esto tambien es gestionar.

20/02/2014
Nuestro humilde Coderetreat

El pasado sábado 14 de Diciembre celebramos en Alicante nuestro primer Coderetreat. Si quieres detalles de qué es un Coderetreat aquí los tienes.

Gracias a Santiago Melía conseguimos un aula muy buena en la Universidad de Alicante y fue el pistoletazo de salida para empezar a prepararlo. Creé el evento en la web del Coderetreat y en Eventbrite para que la gente se pudiera apuntar de manera sencilla. Sabía que debía conseguir que algún patrocinador que pagara el almuerzo o la comida del día y poder traer la comida a la propia aula. Para ello contacté con empresas locales de papelería, componentes informáticos, bancos, el ayuntamiento, la diputación… «Rien de rien». Lo único que conseguí fue alguna respuesta diciendo «No vamos a patrocinar nada pero suerte en el evento».

Angel Armenta se propuso prepararse el papel de facilitador. Así yo podría estar en las conexiones con otras ciudades del mundo, actualizando el estado de nuestras sesiones, poniendo la publicidad y estar atento al evento. Los días pasaban y pocos apuntados iban apareciendo. Llégó la fecha del 14 de Diciembre con sólo 6 inscritos. Sin embargo, tras hacer cancelado un par de eventos por ser poca gente y haberme arrepentido despues, tiré millas hacia delante con el evento.

Llegó el día. Como no conseguimos patrocinador yo compré unas empanadillas y dulces para comer allí y Ángel se encargaba de las bebidas y el café. Puse los carteles para indicar bien cómo se llegaba al aula (no sea que alguien se fuera a perder). Cuando llegó la hora de comenzar nos encontramos 4 personas en el aula: Angel, dos inscritos y yo.

Total, que tanto Ángel como yo hicimos parejas con ellos y dejé aparcado el tema de conexiones globales y hangouts. Como dicen los mismos organizadores, lo más importante es la gente que hay dentro. Fueron unas sesiones muy interesantes. Abordamos el juego de la vida desde todos los puntos de vista posibles: la vida y muerte de la celula, cómo contar sus vecinos, qué criterio se elige para que sobreviva o no. Al medio día nos fuimos a comer a un restaurante y cerramos las sesiones de tarde con un Randori compartiendo la pantalla con un proyectos y resolviendo entre todos una vez más el juego.

Resultado: A la vista está. Esperamos repetir el próximo año.

19/12/2013

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.

23/11/2013

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.
07/11/2013
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.

17/01/2013
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.

02/08/2012
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

05/06/2012
Feature Toggle. La opción más ventajosa para conseguir la Entrega Continua

En el Manifiesto Agil el primer principio dice así:

Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software

«Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software útil»

Uno de los enfoques más importantes es poder dar al cliente software funcionando para que lo pruebe y nos aporte el feedback que permite hacer la aplicación cada vez más valioso para el cliente. Además, en la parte técnica, hacer entregas más frecuentes reduce el riesgo de cada una de ellas.

En el desarrollo tradicional. Las tareas de desarrollo y test se van acortando según se acerca el deadline. Durante todo el tiempo no se puede hacer release porque siempre hay desarrollos sin completar por uno u otro desarrollador. Cuando todo el testing ha terminado y todos los bugs y desarrollos se han cerrado es el momento de hacer el release de la aplicación.

Usando Scrum esto mejora algo:

Reduciendo el tiempo de entrega y haciendolo más frecuente podemos ajustarnos más a los deadlines pactados con los clientes. Durante el sprint el código se considera no releaseable ya que solamente cuando se termina éste, todos los desarrollos se han cerrados y estan libres de bugs conocidos.

Aunque Scrum es un gran avance respecto al desarrollo tradicional, se puede ir más alla y poder ofrecer actualizaciones de manera continua y temprana. Hay varias formas de conseguir esto:

Forma 1: Desarrollar historia por historia

Todos los desarrolladores trabajan en la misma historia y se hace release cuando se termina. Esta es la manera más dura de conseguirlo. Hace falta gran madurez en el equipo pero también reduce el tiempo de desarrollo de cada historia. Durante el tiempo de desarrollo el código se considera sucio ( no releaseable) pero estos intervalos son cortos.

Pero claro, quizá tu eres uno de los que dice. No todo se puede paralelizar, 9 embarazadas no dan a luz un niño cada mes.

Sin embargo, en cuestión de desarrollo se puede paralelizar mucho las historias. Hay back-office y fron-end. Hay clases de store, de vista, de controlador, hay que desarrollar los tests, hay que preparar los scripts de bases de datos. Todos estos son tareas que algunas se pueden realizar en paralelo por varios desarrolladores. Necesita organización y planificación previa del equipo y coordinación durante el desarrollo. Así es como lo veo yo:

Forma 2: Feature branching.

El auge de los nuevos sistemas distribuidos de control de código (DVCS) como Git, Mercurial o Plastic SCM tambien tienen características que permiten hacer branches a menudo. Esto es usado para hacer un branch por historia a desarrollar o feature branching. Una vez completada esa historia se incorpora a las ramas principales que sea necesaria para hacer el deploy.

Esto es un ejemplo de branches usando un sistema de feature branches y varias ramas de integración. Hay partidarios de los features branches pero yo me inclino más por la opinión de estos dos conocidos personajes.

Martin Fowler y Jezz Humble afirman que el uso de feature branches va en contra de la Integración Continua, necesaria para tener feedback de integración temprano y realizar los merges con las ramas principales menos dolorosos. Además es necesario una gran bateria de tests automaticos para evitar bugs ya que es necesario testear la funcionalidad varias veces. Primero en la rama en la que se desarrolló, después en cada una de las ramas en la que se integra. Si es necesario el tests manual esto puede ser muy doloroso. Sólo recomiendan el Feature Branching en equipos muy muy maduros.

Forma 3: Feature Toggle.

Esto se basa en poder desarrollar las funcionalidades, teniendolas integradas junto con el resto del código pero que no afecte al producto si se tiene que hacer release a mitad de desarrollo. El truco está en desactivar el link o el acceso a la nueva funcionalidad hasta que esté completamente desarrollado y testeado.

Esta tercera forma, aparte de permitir hacer release a cada momento teniendo el código integrado también tiene una serie de ventajas extra.

Ventaja 1. Canary Releasing.

Este concepto proviene del sistema utilizado en las minas para detectar fugas de gases. Ponían jaulas con canarios a lo largo de los tuneles y estos, al ser más delicados que las personas, morían rapidamente en caso de fuga de gas letal. Efectivamente es una tecnica un poco triste por perjudicar a los canarios pero hay que contrastarlo con las vidas humanas que salvavan.

Moviendonos al terreno del software (donde hay menos gases involucrados), el Canary releasing significa poder ir activando funcionalidades por zonas. Primero las activaríamos en sistemas internos, después en sistemas de clientes con confianza y si todo funciona correcto al final se activaría en clientes críticos. Si en alguna de estas zonas da problemas, dejaríamos de avanzar antes de resolver el problema

Ventaja extra 2. Marcha atrás rápida.

Alguna vez habeis programado una actualización a un cliente, se le ha dicho que con esta nueva versión va a tener los bugs encontrados arreglados y además la nueva funcionalidad. Ejecutas el instalador, actualizas el sistema y la nueva funcionalidad no va ni para atrás y los usuarios se empiezan a quejar. La opción normal es 1.- Gritar, 2.- Desinstalar la última versión instalada,3,. Deshacer manualmente los cambios que hubiera hecho el instalador que no hace al desinstalar,.4.- Instalar la versión anterior. 5,. Volver a gritar.

Mediante el Feature Toggle nos permitiría poder simplemente desactivar la nueva funcionalidad sin tener que desinstalar. En cuanto la tuvieramos arreglada y el sistema actualizado, solamente se vuelve a activar. Bastante menos doloroso.

Ventaja extra 3: Customización del producto.

A todos nos ha llegado las estadisticas de que los usuarios sólo utilizan una pequeña parte de la funcionalidad. Con el resto ocurre dos cosas: 1. Les molesta que esté o 2,. Nos molesta que lo toquen. La opción más sencilla es desactivar la funcionalidad que no van a necesitar haciendole el interfaz más sencillo y evitando posibles problemas.

Implementación propuesta.

En VSN vamos a tener una tabla por producto. En esta tabla habrá una entrada por característica candidata a ser activable o desactivable por el feature toggle.

En entorno de desarrollo y test se le pondrá a todas las filas la columna ACTIVE a true así aparecerá todo para probar. Sin embargo, en el SQL de release sólo estarán activas las funcionalidades completadas y que formen parte del producto por defecto. De este modo aprovechamos todas las ventajas de este sistema. Le hemos añadido una columna leible por humanos porque todo esto seguramente acabe en un panel de activación y desactivación para un futuro «Gate Keeper» guardian de las características.

Actualización 7/6/2012: Nosotros instalamos de momento sólo sistemas llave en mano. Es decir, instalamos en cada cliente una máquina con el server. En cada server hay una base de datos y en esa base de datos se puede activar o desactivar sus features. Así sí que se permite activar y desactivar por Canary Release. Si el sistema está en la nube falta añadir a la tabla una columna referente a el area del cliente (definida por tí) , region geografica y sacar su region por geoip,.. o algún otro tipo de agrupar los clientes.

04/05/2012