lunes, 11 de noviembre de 2013

Resumen de la charla "Agilismo e Innovación" de Masa K. Maeda

El pasado mes de octubre tuve la oportunidad de escuchar a Masa K. Maeda en dos ocasiones. La primera en el Webinar Agile PMBOK para socios del Capítulo de Madrid del Project Management Institute y la segunda, la charla presencial Agilismo e Innovación organizaba por Tetuan Valley Space.


jueves, 17 de octubre de 2013

Repitamos juntos: No bañaré en oro mis proyectos.

"Bañar en oro" los proyectos es una importante fuente de problemas y sin embargo dicha práctica se viene repitiendo y repitiendo como piedra en la que caemos continuamente. Está en nuestra naturaleza, lo de caer varias veces en la misma piedra, por tanto tal vez sea conveniente repetirlo como un mantra todas las mañanas.

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

lunes, 16 de septiembre de 2013

KANBAN: Cuaderno de Bitácora tras 9 meses de viaje

Cuando leí “From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department” de David J. Anderson y Dragos Dumitriu sobre la aplicación de Kanban en un equipo de mantenimiento de software encontré una gran analogía con las características de un grupo de desarrollo en mi último cliente. En ese momento decidí (después de profundizar en el método) utilizar esta aproximación para la dirección de dicho equipo.



lunes, 26 de agosto de 2013

Estimación Relativa por un niño de 9 años

La estimación relativa nos permite valorar el esfuerzo que nos supondrá llevar a cabo un determinado trabajo utilizando de unidad de medida otro trabajo que nos resulte familiar. En lugar de utilizar las métricas de horas, días u hombre/mes, cuando llevamos a cabo una estimación relativa utilizamos un valor que aproxime el tamaño de dicho trabajo. Existen diferentes formas de definir este valor: puede ser numérico (conocido como Puntos) o utilizando el tamaño de las tallas de camisetas (conocido como "T-Shirt Sizing"). En general nos resulta más sencillo clasificar las tareas comparándolas con otras que ya hemos realizado en lugar de estimar el número de horas o jornadas (no digamos cuando saltamos a la dimensión hombre/mes).

Este verano he podido comprobar su facilidad de aplicación en un entorno muy diferente al desarrollo del software con mi hijo de 9 años. Os resumo la experiencia:

lunes, 22 de julio de 2013

La "vieja" práctica de inspección de código ¿sigue manteniendo el tipo?

Todos hemos escuchado/leído las bondades de esta práctica y la mejora substancial en la calidad y mantenibilidad de nuestro código...entonces...¿por qué es tan poco utilizada? Tal vez yo he tenido muy mala suerte... pero pocas veces la he visto claramente integrada en un proceso de desarrollo.

Las inspecciones de código tienen como principal objetivo mejorar la estructura del código fuente, no descubrir bugs (de hecho inspeccionamos los fuentes no los vemos en ejecución) por lo que el hecho de incorporar una fase de revisión en el proceso de desarrollo no implica que puedas evitar la fase de testing. Tal vez este sea uno de los motivos por lo que no es tan utilizada: los tiempos de desarrollo se alargan... no podemos dedicar ese tiempo extra en nuestros proyectos... la calidad es cara y no podemos pormitírnosla (el cliente no la pide, no la paga,... no la tiene), además ya vamos tarde... como para encima dedicarnos a revisar código.... Hasta que alguien plantea una solución intermedia ¿Y que tal si hacemos un manual de estilo y lo sigue todo el mundo? Y ahí acaba todo, en las 100 o 200 hojas de manual de estilo que nadie suele leer.

¿Te suena la escena?

miércoles, 17 de julio de 2013

Kanban: Las 8 metas "realistas" que puedes alcanzar

Antes de afrontar un proyecto o llevar a cabo un cambio importante en cualquier ámbito de nuestra vida es importante plantearnos por qué nos interesa afrontarlo, qué esperamos conseguir, personal o profesionalmente, tras realizar el cambio.

Este mismo razonamiento debes realizar si estás planteándote cambiar la forma de trabajo de tu departamento de desarrollo para adoptar alguna práctica ágil. Definir qué pretendes obtener en su aplicación es de vital importancia puesto que una u otra práctica tienen "prescripciones" diferentes y por tanto te llevarán a distintas metas.

En este post repasaremos las metas que David J. Anderson en [1] "promete" que podemos alcanzar a través de la aplicación del método Kanban a nuestro proceso de desarrollo de software. Mi opinión personal, después de su aplicación en equipos de desarrollo, es que sí son metas realistas. Probablemente ninguna de estas metas debieran ser fuerzas motrices de tu cambio, pero estarás de acuerdo conmigo que no te hará ningún daño alcanzarlas.

lunes, 8 de abril de 2013

¿Quieres ser más productivo?... recuerda afilar la sierra (I)

En tiempos de "vacas gordas" las organizaciones tienden a sobredimensionarse. Los ingresos van como un tiro y la cuenta de resultados no se ve demasiado afectada por los gastos... necesitamos capacidad productiva que nos permita obtener más ingresos aunque esta capacidad productiva resulte cara o ineficiente...da igual, los ingresos están garantizados, los márgenes son grandes, las comisiones jugosas, todo el mundo está contento... ¿por qué preocuparse? En España ocurrió de forma exagerada en el sector de la construcción por lo que gran parte de una generación abandonó las aulas para incorporarse a un mercado laboral que ofrecía sueldos significativamente superiores que a titulados universitarios... El sector IT, por supuesto, también se subió al carro... había un tiempo en que "recién licenciado + 1 año de experiencia en el lenguaje X" era una pieza cotizada en el mercado laboral... y si me apuras... lo de "recién licenciado" era opcional...

El sueño se acabó, primero en nuestro sector cuando "descubrimos" (con el pinchazo de las punto-com) que la nueva economía no tenía nuevas reglas... que no existía fórmula secreta para evitar los ciclos económicos y que la cuenta de resultados tarde o temprano debe abandonar el rojo. Posteriormente se acabó el sueño para todos... de nuevo al "descubrir" que no existe ninguna regla económica que obligue al precio de la vivienda a crecer eternamente (tesis defendidas por reconocidas publicaciones de color salmón) e incluso pueden bajar.

Ahora los ingresos son moderados (por decir algo...), las tarifas se tiran por los suelos hasta el punto que en ocasiones da la sensación de que se ganan proyectos por el mero hecho de tener a la gente ocupada... En este contexto (ciñéndonos de nuevo a nuestro sector IT) parece tener mayor sentido lo que comentábamos en  ¿Restricciones en el demanda TI, de costes, de presupuesto? Tal vez te interese el pensamiento Lean. El término Lean Software Development  se acuñó en 1992,  ufff... en aquella época España estaba a punto de iniciar su "milagro español" como para preocuparnos de eficiencias, mejoras continuas y eliminación de desperdicios...¿verdad? Lo nuestro era el "dame más madera"...

Sin embargo, ahora resulta imprescindible preocuparnos de estos temas porque debemos mejorar nuestra productividad y de ahí que me viene a la memoria el libro de Stephen Covey, Los 7 hábitos de la gente altamente efectiva [1] que descubrí años atrás gracias a un proceso más que recomendable de Coaching. Los hábitos descritos por Covey son interesantes para cualquier situación pero vienen al pelo en épocas en que necesitamos que tanto nosotros individualmente como los equipos y organizaciones de los que formamos parte seamos los más productivos posibles.

Covey realiza la siguiente clasificación de los 7 hábitos:

PARTE PRIVADA
  • Primer hábito: Se proactivo
  • Segundo hábito: Empieza con un fin en mente
  • Tercer hábito: Establece primero lo primero
PARTE PÚBLICA
  • Cuarto hábito: Piensa en ganar/ganar
  • Quinto hábito: Procura primero comprender y después ser comprendido
  • Sexto hábito: La sinergia
RENOVACIÓN
  • Séptimo hábito: Afila la sierra.
Aunque sea empezar la casa por el tejado únicamente me centraré en el último porque es el que hace posible al resto y además es más que suficiente (creo) para que puedas intuir qué hay detrás y si te interesa o no profundizar en el tema. Covey nos introduce el séptimo hábito a través la parábola del leñador y de ahí coge su nombre. Un visitante inesperado en medio del bosque se encuentra con un leñador:

—¿Qué está usted haciendo?
—¿No lo ve? Estoy cortando este árbol.
—¡Se le ve exhausto! ¿Cuánto tiempo hace que trabaja?
—Más de cinco horas, y estoy molido. Esto no es sencillo.
—¿Por qué no hace una pausa durante unos minutos y afila la sierra? Estoy seguro de que cortaría mucho más rápido.
—No tengo tiempo para afilar la sierra. Estoy demasiado ocupado aserrando.

Si sustituimos al leñador por España, al visitante por Alemania y recordamos nuestra filosofía de "más madera" durante el "milagro español"...creo que la parábola resume perfectamente nuestra situación. Lo malo es que, hasta el momento, las propuestas desde los diferentes gobiernos que nos intentan sacar de esta situación es básicamente la bajada de salarios y de beneficios sociales, con lo que se supone ganaremos la ansiada mejora de productividad... pero me temo que de afilar la sierra se habla poco. Curioso porque otros países como Estados Unidos o Inglaterra están considerando necesario incluir la tecnología y la programación como materia básica en las escuelas... hasta Obama hizo mención de ello en su último Discurso de la Nación.

Como no tenemos demasiada capacidad de decisión en esos niveles al menos intentemos desde el nuestro hacer todo lo posible por afilar la sierra. Tal vez tus decisiones sólo te afecten a ti (esta será tu mejor inversión) o a tu departamento o a tu empresa...pero la suma de cada pequeña mejora es lo que hace cambios importantes.

Detrás de afilar la sierra está por supuesto la formación, pero hay mucho más, como la administración eficiente de nuestro tiempo, aunque va más allá que el hecho de utilizar este o aquel método de planificación que aunque es necesario se queda muy en la superficie. Afilar la sierra te va a resultará más costoso que aplicar un método de gestión personal del tiempo,... de hecho considera que ya has trabajado en los seis principios anteriores y se enfoca en trabajar sobre las cuatro dimensiones de nuestra naturaleza: la física, la espiritual, la mental y la social/emocional. En el próximo post comentaremos cómo de relacionadas están estas cuatro dimensiones y qué hay detrás de cada una de ellas.


Referencias:
Stephen R. Covey, (2005). Los 7 Hábitos de la Gente Altamente Efectiva: La Revolucion Etica en la Vida Cotidiana y en la Empresa, Ediciones Paidos Ibérica.

martes, 2 de abril de 2013

KANBAN, el origen: The Goal (Theory of Constraint)

¿Por qué podría interesarle a un ingeniero de software leer una "novela" sobre organización industrial? Bueno, si estás interesado en la aplicación del método Kanban en el proceso de desarrollo de software es muy posible que te interese leer The Goal: A Process of Ongoing Improvement  (Theory of Constraint) de E. Goldratt [1] puesto que fue la Teoría de Restricciones la que llevó a David J. Anderson a aplicar una primera aproximación de Kanban en un equipo de desarrollo en Microsoft. De hecho, en From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department no encontrarás ninguna referencia a Kanban puesto que se trata de la aplicación de Theory of Constraints (TOC). Después de esta publicación, Donald Reinertsen hizo ver a Anderson que su adaptación de TOC se ajustaba al método Kanban por lo que Anderson continuó utilizando Kanban en lugar de TOC, entre otras razones porque es un método asociado a la filosofía Lean (más de moda en estos momento). En cualquier caso, ambos métodos tienen muchos puntos de unión y una visión común: la mejora continua o Kaizen (que lo llaman los japoneses).

Alguna razón para "invertir" el tiempo en su lectura:
  • El libro fue editado en 1984 por lo que está a punto de cumplir 30 años. Si pasado tanto tiempo continúa editándose y se ha aplicado en empresas de la talla de General Motors o Microsoft... algo debe tener.
  • Trata muy diversos e interesantes temas como las competencias de un buen gestor, la influencia de la presión profesional en la vida personal , las relaciones laborales, gestión del cambio, innovación, el método Socrático... y por supuesto mucho de Teoría de Restricciones... Hmmm, de software lo único que menciona es su incapacidad para localizar los cuellos de botella...
  • Si tienes algún interés profesional o vocacional en la formación o divulgación de conocimiento The Goal  es todo un ejemplo de didáctica. Es capaz de introducirte, por ejemplo, en la relación que tienen los eventos dependientes y las fluctuaciones estadísticas en el rendimiento de una planta industrial, de tal forma que te acaba por resultar hasta interesante. La combinación del método Socrático con el formato novela es la clave para conseguir que aquellos que no estamos interesados en la reorganización industrial nos resulte interesante el libro y encontremos nuevas formas de aplicación de sus principios...es una buena forma de transferir conocimientos y de hecho me recuerda por un lado los Cibercuentos de @jgarzas, (este es un ejemplo), y el prólogo que escribe @jmbeas en Deseño Ágil con TDD de Carlos Blé. Es curioso que la gente que probablemente tiene más que decir es capaz de simplificarlo de forma que todo el mundo lo entienda.
Ahora bien, como el tiempo es escaso y los recursos de lectura prácticamente ilimitados te diría que yo no leería el libro:
  • Si lo que te interesa es conocer por encima qué hay detrás de alguna palabra de moda como Lean o Kanban. Para eso te aconsejo "googlear" un poco. Existen suficientes recursos Online en castellano como para hacerte una idea. 
  • Si quieres profundizar un poco más y te estás planteando si esta u otra práctica puede resultarte interesante...te aconsejo que te hagas con un ejemplar de Gestión Ágil de Proyectos Software [2]. Aquí encontrarás toda esta información procesada y ordenada. Es un buen punto de partida si tu equipo/departamento necesita un cambio pero todavía no estás seguro del camino a seguir. 
  • Si te estás planteando la aplicación de Kanban al desarrollo de software te aconsejo que primero leas [3] y [4] y luego, si te interesa, profundices en The Goal. 
  • Si nada de lo anterior te interesa deja aquí este post (es algo extenso) y salta a otra lectura que seguro las encontrarás más interesantes...

Estas son algunas de las reflexiones que te puedo dejar de su lectura:
  • La importancia de las métricas. El libro continuamente refleja la necesidad de tomar medidas a lo largo de toda la cadena productiva, tanto en tiempos de procesado como en calidad del producto; hay que tener en cuenta que sin una referencia clara de "donde estamos" en muy difícil decidir si aplicando determinadas medidas mejoramos. Las métricas no les gusta a nadie (tampoco en el entorno industrial) pero son imprescindibles. En el mundo del software me temo que acostumbramos a situarnos en uno de los extremos: Un gran número de proyectos no mide ni el rendimiento del proceso ni la calidad del producto, pero cuando nos planteamos la necesidad de las métricas, dado que tenemos una gran facilidad para generar/manejar datos (es lo nuestro, claro) nos solemos pasar de largo y empezamos a medir a discreción. Si actualmente no utilizas ninguna métrica, deberías plantear unas pocas interesantes (en Kanban las básicas son LeadTime y CycleTime)... el ratio de errores, el acoplamiento de clases, la complejidad ciclomática, la profundidad de herencia, las adecuación a normas de programación, están muy bien, pero deberías introducirlas poco a poco...y sobre todo después de plantearte por qué tiene importancia determinada métrica en el contexto de un proyecto concreto.
  • Debe de existir más de una docena de referencias al sentido común en el libro, para acabar concluyendo que "el sentido común no es tan común"... Y lo cierto es que The Goal basa la mayor parte de su plan de mejora en tomar decisiones de "sentido común" a simple vista nada excepcionales. Por otra parte, como finalmente acabó recalcando Anderson en [3] no se necesita de mentes prodigiosas ni de disponer de los mejores técnicos del mundo (que no digo yo que esté mal...en cualquier caso no te costará encontrarlos, el 80% de la gente se considera más inteligente que la media...), sino que la mayor parte de las mejoras introducidas es fruto de aplicar medidas de sentido común que habitualmente no se aprecian porque chocan con la cultura preestablecida, por lo que al sentido común yo añadiría valentía para cambiar la forma habitual de hacer las cosas.
  • Respecto a la innovación y el rechazo al cambio muestra la dificultad que presentan determinadas organizaciones para introducir un cambio de pensamiento incluso en situaciones críticas como la descrita en The Goal. La novela trata este rechazo al cambio dejando patente que es capaz incluso de llevar a la quiebra a una empresa. De hecho, el "no tener nada que perder" es lo que en este caso finalmente impulsó el cambio. Si hubiera existido alguna posibilidad de salvar la situación con las normas preestablecidas probablemente no se habrían tomado las medidas que mejoraron el rendimiento de la planta de producción que finalmente salvó el resto de la división. Esta idea es el eje central de El Dilema de los Innovadores [5] donde puedes encontrar documentados casos concretos de agentes dominantes de un mercado que acaban desapareciendo ante su incapacidad de adaptación a determinadas innovaciones. Se detallan dos casos en sectores muy diferentes: las maquinarias de perforación con la aparición de los cilindros hidráulicos en sustitución de las poleas y las empresas tecnológicas de fabricación de dispositivos de almacenamiento (discos duros) con su necesidad continua de duplicación de capacidad. 
  • En la cadena de producción la reducción del tamaño de los lotes repercute en una reducción del inventario en los buffers intermedios, disminuyendo, por tanto, el tiempo perdido en estos buffers a la espera de capacidad productiva, lo que deriva en una condensación del LeadTime (tiempo transcurrido desde la aceptación del pedido hasta la entrega). Lo anterior tiene un punto débil: implica "perder" más tiempo en configuración de la maquinaria... pero si estas máquinas no son cuellos de botella del proceso, el rendimiento global no se ve penalizado.  Ufff, complicado analizarlo en un párrafo... pero resumiendo mucho, la idea es que cuanto menores sean nuestros trabajos (tareas de desarrollo) menos tiempos de ingeniería (obviamente) y de espera a que alguien pueda hacerse cargo de ellos, por lo que el tiempo de ciclo disminuye.
    En líneas generales los trabajos en nuestros procesos de desarrollo consumen tiempo en:
    • Actividades de ingeniería (análisis, diseño, construcción,...).
    • Configuración del entorno.
    • Tiempo de espera para iniciar el trabajo en una determinada actividad de ingeniería.
    • Tiempo en espera de otras partes (en el caso de trabajos más grandes: temas o epopeyas).

    Si los trabajos son muy grandes desperdiciaremos tiempo principalmente en los dos últimos puntos. 
    El problema es que disminuyendo el tamaño aumentamos el tiempo de configuración (puesto que tendremos que preparar el entorno más veces). En el mundo industrial este tiempo se pierde configurando la maquinaria para que comience a trabajar con una pieza concreta pero en desarrollo de software se pierde en, por ejemplo, configuración del entorno y escenarios de pruebas... de aquí la  necesidad de automatización de las pruebas y del proceso de despliegue.
  • Otro tema interesante es el tiempo "ocioso". The Goal muestra la dificultad de hacer entender a la dirección que el hecho de parar una maquinaria (y sus operarios) en intervalos concretos sea rentable a la empresa. El "sentido común" decía que para amortizarlas, esta máquinas debían trabajar al 100% de su capacidad. En realidad esto generaba inventario innecesario en los buffers intermedios ¿recuerdas el efecto en el tiempo de ciclo? Goldratt concluye que tener a maquinaria y personal parados bajo determinadas circunstancias resulta rentable...
    Hmmm, un poco duro de aplicar al mundo del software, ¿verdad? Pues bien, te recomiendo el artículo Scaling Agile @ Spotify donde explican cómo gestionan ellos estos "tiempos ociosos". Te lo resumo: todo el mundo dispone de un 10% de su tiempo para dedicarse a actividades que consideran interesantes pero no directamente asociadas a compromisos de sus proyectos. Generalmente suelen agrupar ese 10% y cada dos semanas disponen de un "hack day" (algo así como un "día de escaqueo en el trabajo"). Se podría argumentar que estos "hack days" no tienen el mismo objetivo que en The Goal, de hecho en la planta industrial pretendían eliminar inventario intermedio mientras que en Spotify buscan generar innovación, pero en ambos entornos resulta rentable que los recursos no trabajen siempre al 100%. La aproximación de Anderson (y la mía personal) es aprovechar los tiempos de bloqueos producidos por los WIP del tablero Kanban para generar estos espacios de innovación, de esta forma no existe tanta tensión cuando una persona del equipo no puede coger ningún trabajo puesto que puede dedicar ese tiempo a asuntos de interés general no asociados a proyectos concretos. Reconozco que me sigue gustando más la idea de los "hack day" pero... no todos trabajamos en Spotify...
Aquí lo dejo, pero ten en cuenta que está todo muy destilado, si te resulta interesante en The Goal encontrarás otros asuntos que por extensión no he querido tratar como el concepto de contabilidad de costes, la definición de trabajo finalizado, la inercia del proceso de mejora, la aplicación de TOC a actividades "no materiales" como la gestión, el flujo continuo y regular,...

Referencias:
[1] Goldratt, E. y Cox, J. (2012). THE GOAL: A Process of Ongoing Improvement (Third Revised Edition), North River Pr.
[2] Garzás, J., Salamanca, J.A., e Irrazábal, E. (2012). Gestión Ágil de Proyectos Software, Kybele Consulting.
[3] Anderson, David J., y Dumitriu, D. (2005). From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department. Proceedings of the TOC-ICO World Conference, Barcelona.
[4] Anderson, David J. (2010) Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press.
[5] Christensen, C.M. (2000). El Dilema de los innovadores, Granica.


jueves, 7 de marzo de 2013

Continuous Delivery (II): Sus promesas

Como ya comentamos en Continuous Delivery: ¿Por qué te puede interesar? la meta que se pretende  alcanzar es la implantación de un mecanismo altamente automatizado que nos permita desplegar en los diferentes entornos (desarrollo, pruebas y producción) "presionando un botón".

En el anterior post describimos unas situaciones por las que nos podría interesar su implantación, ya que al no ser algo trivial, es aconsejable asegurarse de estar realmente interesado. Si reconoces con demasiada facilidad dichas situaciones y estás interesado en seguir adelante en este post se describen las ventajas que los autores "prometen":

  • Disponer de un proceso de despliegue repetible, fiable y predecible. A demás de evitar las situaciones de las que hemos hablado anteriormente permitirá acortar el tiempo de ciclo de desarrollo acelerando la puesta a disposición de los usuarios nueva funcionalidad y la resolución de incidencias. Esto tiene mucho que ver con el principio de entregar con rapidez de Lean Software Development del que ya hablamos en ¿Restricciones en el demanda TI, de costes, de presupuesto? Tal vez te interese el pensamiento Lean.
    En cuanto a la característica "repetible", se puede llegar a pensar que no es tan difícil de conseguir siendo lo suficientemente metódicos pero lo cierto es que cuando los problemas y la fecha límite nos presionan es muy común saltarse los procedimientos y los manuales...de modo que después de 3 días de parches y cambios el sistema funciona...pero ¿somos realmente capaces de reproducirlo en el orden que corresponda y eliminando los pasos que no son necesarios?
  • Fortalecer los equipos. El proceso de despliegue propuesto por CD tiene una característica importante y que igualmente enlaza con el pensamiento Lean: es un sistema Pull. Esto se traduce en que debe funcionar como un autoservicio, el desarrollador, tester o técnico de operaciones "tirará" de   la versión específica del sistema que necesita. El hecho de que se intente depurar un error (equipo desarrollo) sobre un código desfasado, se pruebe una versión (equipo de pruebas) que no corresponde o se pierdan dos horas desplegando un sistema (equipo de operaciones) con una documentación de puesta en producción desfasada conduce, generalmente, a problemas entre los diferentes equipos que participan en todo el proceso.
  • Reducir errores. Desde el momento de captura de requisitos hasta la puesta en producción existen un gran numero de posibilidades de introducción de errores. CD se centra en la reducción de los errores producidos específicamente en producción como consecuencia de una gestión de la configuración deficiente: una versión específica de nuestro sistemas implican un código fuente determinado, asociado con una versión específica de la base de datos, URLs concretas para el acceso a servicios Web, etc. Controlando todos y cada uno de estos elementos bajo una gestión de la configuración adecuada se reducirán considerablemente (ojo no digo "se eliminarán por completo"... desconfía de quien lo prometa) los problemas "inesperados" en producción. 
  • Minimizar el estrés. Si has participado en un proyecto software tendrás muy presente que según se acerca la fecha de la entrega el estrés aumenta de forma considerable (posiblemente las horas extras también). Es el momento de la adrenalina..., de los héroes locales... y de saltarse los protocolos (con los correspondientes visados de la jerarquía superior, por supuesto) y no es de extrañar que en operaciones llegue la orden de abrir la base de datos e introducir manualmente los valores de configuración que algún desarrollador va indicando sobre la marcha...porque el sistema ha de arrancar sí o sí... En desarrollo llegan "visados" similares siendo necesario tocar código que ha de subir a producción en minutos...por lo que, obviamente, se saltan todos los procedimientos de calidad establecidos.
    Este tipo de órdenes pueden estar justificadas y seguirán realizándose si el coste de no ejecutarlas lo justifica...vivimos en el mundo real...¿alguien piensa que el CTO de una tienda Online no firmaría visados para arreglar un problema en la plataforma de pago (único punto de entrada de ingresos)? pero ¿tendríamos el mismo estrés si nuestro despliegue se hubiese preparado desde el Día 1 para que pudiera realizarse "presionando un botón"? Con toda probabilidad los datos que el técnico de sistemas se ve obligado a introducir "a ciegas" formarían parte de un script listo y preparado para su ejecución (de hecho no sería la primera vez que se lanzara).
  • La práctica lleva a la perfección. No es cuestión de definir la mejor y más sofisticada técnica para esta  u otra tecnología (para eso ya están, de nuevo, los héroes locales)... es más simple que eso puesto que el efecto de desplegar continuamente el sistema acabará creando, por si solo, un procedimiento detallado (¡y probado!). Si esto lo hacemos desde el primer día del proyecto cuando tengamos que desplegar el día D habremos verificado dicho procedimiento decenas de veces.


Ahora bien, para poder automatizar el proceso de despliegue necesitarás dos pilares básicos, por lo que si no dispones de ellos es imprescindible que inicies tu camino aquí:

Gestión de la Configuración
En muchas ocasiones se confunde este término con el "control de código fuente" pero en realidad la gestión de la configuración va más allá, en [1] se define como el proceso por el cual todos los artefactos relevantes para nuestro proyecto y sus relaciones son almacenados, recuperados, identificados inequívocamente y modificados.

El enfoque de CD es mantener bajo la gestión de la configuración absolutamente todos los elementos que serán necesarios para el despliegue, esto implica por supuesto al código fuente pero también a la configuración de la base de datos, la configuración mínima que requieren las aplicaciones para funcionar así como la diferente configuración de entorno (sistemas operativos, servidores de aplicaciones, etc.).

Una buena estrategia de Gestión de la Configuración es básica para cualquier proyecto software, por lo que si no dispones de ella, es recomendable que estés o no interesado en CD lo incluyas en tu lista de "temas urgentes" a realizar.

Integración Continua
Para poder automatizar los despliegues es necesario asegurar que en todo momento disponemos de una versión estable de nuestro código, asegurándonos de que compila y pasa un conjunto de pruebas que garantizan (dentro de lo razonable) su correcto funcionamiento. La mejor forma de conseguir esto es mediante la práctica de Integración Continua. Al igual que ocurre con la Gestión de la Configuración muchas veces interpretada como sinónimo de "control de código fuente" la Integración Continua se suele asociar con la compilación remota, aunque en realidad tiene mayores implicaciones que disponer de dicha infraestructura como ya comentamos en "Practicando" la Integración Continua (IC).


Referencias
[1] Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Jez Humble y David Farley

martes, 26 de febrero de 2013

Continuous Delivery: ¿Por qué te puede interesar?

Empecemos definiendo qué es Continuous Delivery (CD): Consiste básicamente en la implantación de un proceso repetible y confiable para la liberación de software evitando, en la medida de lo posible, la intervención humana. Los autores de Continuous Delivery [1] aconsejan que la única intervención por nuestra parte para la liberación de una nueva versión sea la de pulsar el botón de despliegue para lo que será necesario disponer en todo momento de una versión de software estable listo para la entrega.


Este objetivo es realmente ambicioso y como te puedes imaginar su puesta en marcha requiere un esfuerzo importante por lo que deberías hacerte algunas preguntas antes de planteártelo. Para ayudarte en esta  decisión te recomiendo que leas las siguientes situaciones, si te resultan demasiado familiares te puede compensar hacerte con el libro y profundizar en sus ideas.

Situaciones derivadas de un proceso de despliegue manual

En muchas organizaciones la gestión de la configuración del entorno de producción se lleva a cabo directamente por equipos de operaciones. De esta forma cuando se requiere cambiar la cadena de conexión a una base de datos, el acceso con certificado o el uso del canal seguro para una aplicación se lleva a cabo manualmente en los servidores de producción. Este hecho puede provocar las siguientes situaciones:
  • Para desplegar un sistema es necesaria la edición de elaborados manuales de instalación que describen secuencialmente los pasos que deberá realizar el equipo de operaciones.
  • El proceso de despliegue finalmente no sigue el plan establecido, en diferentes momentos es necesario  improvisar y no se sigue el manual. 
  • Se hace necesario establecer una conexión telefónica permanente entre desarrollo y operaciones durante el proceso de despliegue. En ocasiones se requiere desplazar algún miembro del equipo de desarrollo a las instalaciones del equipo de operaciones.
  • Se hace necesaria la realización de pruebas manuales en entorno de producción para asegurarnos que la aplicación se ejecuta correctamente y que interacciona de forma adecuada con sistemas externos.
  • Falla un despliegue en producción aun después de haberse desplegado perfectamente en entorno de pre-producción.
  • Los nodos de un cluster tienen diferentes versiones de sistemas operativos, componentes de terceros o parches, lo que deriva en que la aplicación se comporta de diferente forma dependiendo del nodo que atiende la petición.
  • El equipo de operaciones requiere más tiempo del estimado inicialmente para preparar el entorno requerido por una versión específica de nuestro software.
  • No es posible retroceder a una versión anterior de un sistema después de un determinado pase que implica bases de datos, servidores de aplicaciones, parches de sistemas operativos, etc.
  • La configuración de los sistemas se llevan a cabo manualmente a través de herramientas de administración proporcionadas por los propios Sistemas Operativos, SGBD, servidores de aplicaciones, etc.
Situaciones derivadas de desplegar en entorno real justo cuando finalizamos el desarrollo

Esto suele ser muy común y no deja de ser un problema puesto que existe un enorme número de riesgos asociados a la arquitectura técnica (¡pueden exigir tocar código!) que se descubrirán cuando el equipo de desarrollo da por finalizado su trabajo. Obviamente cuanto más tardemos en "conocer" el entorno de producción mayores y más peligrosos se harán estos riesgos, de esto ya hablamos en un post anterior por lo que argumentábamos que el día 1 era el mejor momento para el despliegue. A continuación se describen alguna de las situaciones que nos podemos encontrar
  • La primera vez que el equipo de operaciones se "enfrenta" al nuevo software es el día D. Generalmente las organizaciones siguen una política común que minimiza este impacto pero siempre existe un motivo para que en desarrollo nos veamos obligados a realizar un proyecto que se sale de la norma provocando que el equipo de operaciones no se encuentre tan "cómodo" con el despliegue. 
  • El entorno de pre-producción (lo más parecido que tendremos a producción) no está disponible hasta que nos encontramos demasiado cerca de la fecha límite.
  • Derivado de lo anterior, las pruebas se han realizado sobre el entorno de desarrollo y la pre-producción no se comporta igual ante determinadas funcionalidades.
  • Hay poca, o ninguna, colaboración entre el equipo de desarrollo y el de operaciones. 
  • En proyectos de larga duración, en los que están implicados equipos de la propia organización y desarrollos subcontratados con proveedores externos es habitual que el despliegue sea el momento de revisar los documentos contractuales. Si el contrato se redactó a nuestro favor y el proveedor debe hacerse cargo de, por ejemplo, un cambio de plataforma, estamos de media enhorabuena... porque seguramente esto ocurra, de nuevo, pisando la fecha límite.
¿Te suena alguna de las anteriores situaciones? Aunque la lista está recopilada de Continuous Delivery [1] personalmente he de reconocer que las he sufrido un su gran mayoría y que podría ampliarla fácilmente.

Reducir estas situaciones es, desde mi punto de vista, suficiente motivo para afrontar el esfuerzo que requiere la implantación de CD, claro que el grado de automatización sugerida puede y debe variar dependiendo de la naturaleza de los sistemas que estemos desarrollando.

Existen dos motivos que a nosotros nos condujeron a CD:
  1. Nos resultaba demasiado familiar las situaciones descritas anteriormente. 
  2. Desde una perspectiva ágil cuanto menor sea la duración de la iteración mayor necesidad tendrás de automatización en el proceso de despliegue. En nuestro caso, el hecho de utilizar un tablero Kanban en el equipo de desarrollo nos ha generado la necesidad de aumentar la sofisticación del proceso de despliegue debido al flujo continuo promovido por dicho método
En próximos post resumiré las bases mínimas sobre las que se apoya CD, los beneficios esperados así como nuestras experiencias al implementarlo.


Referencias
[1] Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Jez Humble y David Farley
[2] http://www.continuousdelivery.com/


jueves, 21 de febrero de 2013

¿Restricciones en el demanda TI, de costes, de presupuesto? Tal vez te interese el pensamiento Lean

Lean Software Development es la adaptación al mundo del software del Sistema de Producción de Toyota (TPS) principal culpable de que Toyota pasara a ser el mayor fabricante mundial de automóviles e igualmente el motivo por el que todos asociamos a la marca con la Calidad.

Si ya has leído otras fuentes sobre Lean aquí no vas a encontrar nada nuevo, espero que este sea el primero de una serie de post desde nuestra experiencia y pretende dar una breve introducción de sus principios.

Lean Software Develompent no es una metodología, ni método, ni proceso de desarrollo sino que se trata de una serie de principios que debes adaptar a tu propio proceso con el objetivo final de mejorarlo. Por otro lado existen diferentes escuelas de pensamiento sobre Lean que se centran en aspectos distintos, para unos, por ejemplo, lo importante es la reducción del desperdicio (waste) mientras que otros se centran más en el flujo de trabajo. En este post nos centraremos en resumir los principios descritos por Mary y Tom Poppendeick.

PRIMER PRINCIPIO: Eliminar el desperdicio

Definición de desperdicio desde la perspectiva Lean: Todo lo que no aporta valor al usuario. Esto implica tener muy claro qué es valor... monográfico para un futuro post...

En fabricación uno de los mayores desperdicios es el inventario puesto que se debe almacenar, asegurar, mover, se desfasa… en este caso (y sin que sirva de precedente) la propiedad de intangibilidad del software juega a nuestro favor, pero me temo que existe un equivalente: el trabajo parcialmente hecho.

Kanban, por ejemplo, en su fase inicial aconseja la generación de estos almacenes (buffers) como mal menor para mejorar la cadencia del flujo de trabajo, pero una vez conseguido esto, potencia descubrir los cuellos de botella, solucionarlos y minimizar su uso. De hecho, el objetivo final es eliminarlos por completo al igual que hicieron en Toyota apoyándose en el Just In Time (JIT).

Otro de los grandes desperdicios de nuestra industria es la funcionalidad extra que no requería el usuario y finalmente no se utiliza. Sobre esto ya dejé una referencia sobre un grupo de trabajo recientemente creado en Cómo construir el producto que "realmente" esperan.

SEGUNDO PRINCIPIO: Desarrollar con Calidad

Este principio aconseja construir con calidad y descubrir los errores en ciclos tempranos: test unitarios, test de integración, test de sistemas… automatizados.

Evitar mantener vivos los errores apuntados en el sistema de seguimiento de tareas. Obviamente es importante identificar y realizar el seguimiento de los errores, pero en el enfoque Lean un error detiene la cadena de producción para solucionarlo. Un error apuntado en el sistema de seguimiento de tareas es trabajo parcialmente hecho... lo que va en contra del primer principio.

TERCER PRINCIPIO: Crear conocimiento
El proceso de desarrollo del software se acerca al desarrollo de productos (segunda derivada del TPS) y ambos tienen en común que son procesos basados en el conocimiento. Lean aconseja amplificar este conocimiento desde dos dimensiones:
  • Es importante aprender sobre el producto en sí. En esto nos ayuda el desarrollo iterativo potenciando una alta realimentación. 
  • Igualmente importante es aprender sobre el propio proceso. Lean asigna la responsabilidad de la mejora del proceso al equipo de trabajo (quien mejor conoce la forma de trabajar es quien hace el trabajo), justificando la dedicación de parte del tiempo productivo en la mejora del proceso. 

CUARTO PRINCIPIO: Aplazar las decisiones


Posponer las decisiones irreversibles hasta el último momento responsable, esto es, justo antes de que la decisión sea demasiado tarde.

También muy relacionado con el desarrollo de producto lo que facilita su aplicación al software. Si Toyota lo aplica al diseño de coches… en el software no debería ser más complejo. No implica no tomar decisiones, sino identificar aquellas que son irreversibles o costosamente reversibles y tomar la decisión la más tarde posible.

Por otra parte se potencia diseñar los sistemas lo suficientemente flexibles. Pero ojo, no todos las partes de nuestros sistemas necesitan el mismo grado de flexibilidad… no olvidemos que la flexibilidad no es gratis por lo que se debe aplicar este principio con sentido común y en muchos casos basándonos en la experiencia.

QUINTO PRINCIPIO: Entregar con rapidez

Los requisitos cambian, por lo que necesitamos desarrollar el software tan rápido como nos sea posible para que los usuarios/clientes no tengan tiempo a cambiarlos.

Bien, de acuerdo… aún así los requisitos cambian… pero si entregamos el producto lo antes posible y obtenemos una rápida realimentación (tercer principio) estaremos en una mejor situación para que los cambios se corrijan sobre el diseño actual en lugar de sobre el código escrito dentro de unos meses: eliminamos desperdicio (primer principio).

SEXTO PRINCIPIO: Respetar a las personas

En el aspecto de personal TPS se centra en los siguientes aspectos:
  • Liderazgo emprendedor. Una organización que respeta a sus personas desarrolla buenos líderes y se asegura de que los equipos tienen el tipo de liderazgo que fomenta el compromiso motivando a su gente en crear productos de calidad. 
  • Personal técnico experto. Una organización Lean debe desarrollar y nutrir experiencia técnica en el área/tecnología en que trabaja. Se me vienen a la cabeza diferentes empresas por lo bien o mal que aplican este principio con su personal...
  • Responsabilidad en la planificación y el control. En lugar de decirle a la gente qué tiene que hacer y cómo ha de hacerlo se promueve la auto-organización que permita la consecución de unos razonables objetivos. Potenciar la flexibilidad necesaria para que la gente solucione por sí mismos los problemas…lo fácil es decirlo, verdad? A nosotros nos ha llevado 6 meses de esfuerzo apoyados en el uso de Kanban que personalmente creo que es un facilitador estupendo para este y otros principios Lean.
SÉPTIMO PRINCIPIO: Optimizar el conjunto

Cuando se piensa en la optimización desde una perspectiva Lean se piensa en la optimización del conjunto de la cadena de valor, traspasando la fronteras internas por las que dicha cadena atraviesa.

Probablemente este principio, junto con el anterior, sean los de más difícil aplicación sin el apoyo de la alta dirección. Hay que tener en cuenta que Lean sobrepasa los límites de un equipo de desarrollo por lo que determinados principios serán de difícil aplicación sin el adecuado compromiso de la jerarquía superior...

Y hasta aquí una primera explicación muy, muy resumida de los siete principios de Lean Software Development. No existe una guía de aplicación de los principios, pero en las referencias citadas abajo encontrarás una serie de prácticas y consejos que puedes utilizar para incorporarlos a tu propio proceso.

Reflexión

Personalmente creo que en momentos como el actual te puede llegar a interesar el pensamiento Lean porque, probablemente, tu organización, departamento IT o empresa esté sufriendo las restricciones de la severa crisis que atravesamos y todo lo anteriormente expuesto fue diseñado en una situación igualmente de enormes restricciones. Ten en cuenta que TPS se crea en Japón, en plana posguerra y en una empresa que no disponía de los recursos de las grandes compañías automovilísticas del momento (americanas).

Por otra parte, la demanda japonesa era significativamente menor a la que disfrutaban los colosos americanos, por lo que, la única forma de sobrevivir en esa situación era reinventar las reglas del juego y la forma de hacer las cosas. Aunque a Toyota le fue bien con la aplicación de estos principios no fue hasta la crisis del 74, debido a una importante contracción de la demanda mundial, que otras empresas (principalmente japonesas) empezaran a replicar el modelo, de nuevo bajo fuertes restricciones.

De ahí el título del post ¿Restricciones en la demanda TI, de costes, de presupuesto? Tal vez te interese el pensamiento Lean. En mi caso este ha sido el motivo principal que me ha llevado a optimizar y mejorar la forma que tenemos de hacer las cosas, años atrás no existían estas restricciones sino que la situación era la contraria, recordemos que la demanda era tan grande que nuestro problema era encontrar profesionales en el mercado que nos permitieran seguir produciendo... Con la situación a la inversa (mantener la producción aun perdiendo personal) he acabado profundizando y guiando a mi equipo de desarrollo a través de Lean y Kanban (de nuestras experiencias con Kanban escribiré en breve).

Referencias

Mary y Tom Poppendieck, Lean Software Development - An Agile Toolkit, Addison Wesely, 2003.
Mary y Tom Poppendieck, Implementing Lean Software Development, Addison Wesely, 2006.



viernes, 15 de febrero de 2013

Cómo construir el producto que "realmente" esperan


El lunes de esta misma semana (11 de febrero) se juntaron en Londres, invitadas por Gojko Adzic (Impact Mapping), un grupo de personas que son ponentes y escritores habituales en temas relacionados con la concepción del producto. Esta idea se trata en diferentes técnicas como Impact Mapping, Lean Startup, Feature Injection, etc.

Yo di con ello porque actualmente, entre otras cuestiones, estoy adentrándome en temas de Lean y centrándome en uno de los principales problemas (desperdicios) que tenemos en nuestros proyectos: implementar funcionalidad que no interesan a nadie. Lean Sturtup se centra en estos asuntos pero no es fácilmente adoptable en todas las situaciones (no todos vivimos en un mundo con miles/millones de usuarios) de ahí que sigo buscando lo que más se adapte a la mía y, de momento, me detuve en Impact Mapping.

El enfoque Ágil se centra mucho en la entrega del producto, por lo que equipos ágiles perfectamente organizados y con alto rendimiento pueden estar cumpliendo a la perfección los objetivos de su sprint (si trabajan con Scrum, por ejemplo) pero estar desviándose totalmente del objetivo final: lo que realmente quieren los clientes/usuarios... iteración tras iteración entregan su versión incrementando funcionalidad y con la velocidad acordada...pero ¿realmente esto aporta valor? Si no es así, ni una ejecución de libro de un sprint te salvará de haber perdido las últimas 4 semanas...

En fin, volvamos al motivo principal de este post, lo interesante de este encuentro es el intento de todas estas personas por encontrar unos puntos comunes en las diferentes técnicas que las permitirá evolucionar de la mano. Hay quien lo empieza a comparar con el Manifiesto Ágil (imagino que por lo resumido y el número de puntos), otros dicen que sirve para explicar y acercar el Manifiesto a la gestión de las organizaciones,  todavía le están buscando nombre... Este es el resultado de tan "sesuda" reunión.

Great results happen when:

  1. People know why they are doing their work
  2. Organizations focus on outcomes and impacts rather than features
  3. Teams decide what to do next based on immediate and direct feedback from the use of their work
  4. Everyone cares




Creo que yo no aportaría mucho siguiendo hablando de ello, por lo que si te interesan estos temas puedes empezar por el blog de Gojko The February Revolution que explica los 4 puntos con suficiente detalle y si continúas interesado visita con frecuencia la comunidad de Google+ creada para compartir y evolucionar estas ideas: FebMeeting.


miércoles, 13 de febrero de 2013

"Practicando" la Integración Continua (IC)

Después de invertir un tiempo considerable en su configuración disponemos de máquinas de Build que son capaces de compilar el código de nuestros proyectos, tenemos definiciones de compilación en diferentes formatos (integración continua, programadas, incrementales) y hemos adoptado la buena práctica de únicamente desplegar en producción las carpetas de despliegue generadas por estas máquinas.

lunes, 11 de febrero de 2013

Día 1: El mejor momento para el despliegue

Las puestas en producción suelen ser complicadas, incluso si hemos superado los innumerables problemas durante el desarrollo del producto, hemos corregido a tiempo los errores detectados en las pruebas y disponemos de una versión estable para el despliegue, en ocasiones nos encontramos superando la fecha de entrega en varias semanas por la necesidad de "afinar el sistema" al entorno de producción.

Puede parecer demasiado prematuro (e irreal) pero lo cierto es que no encontraremos en la vida de un proyecto mejor momento para su puesta en producción que su primer día de vida. Bien, tal vez tengamos que acotar lo que entendemos por "primer día" puesto que desde el momento de la concepción del sistema hasta que se escribe la primera línea de código pueden pasar varios días, tal vez semanas o incluso meses...

Durante las puestas en producción nos encontramos con una serie de problemas difíciles de predecir y reproducir, por lo que suele ser complicado aprender y replicarlo en el siguiente proyecto: debemos desplegar por sorpresa en servidores de 64 bits, la versión del Componente X de producción no coincide exactamente con la de Preproducción/Desarrollo, no alcanzamos desde los servidores de producción determinado Servicio Web, no está habilitada la IP de los nuevos servidores para el envío de correos, no se ejecutó el script con los permisos sobre determinados objetos de la base de datos... en resumen, la casuística tiende a infinito...

Cuanto más se retrasa la puesta en producción de nuestro sistema más funcionalidad incorpora, más lógica de negocio, mayor necesidad de configuración y de integración con otros sistemas... en definitiva, más riesgo a manejar. De ahí la afirmación que el primer día es el mejor momento para el despliegue.

Dependiendo del entorno, tecnología u organización el "primer día" puede traducirse como "la primera semana" o "el primer mes" pero lo cierto es que siempre habrá un único momento del proyecto en el que el despliegue es sencillo, pasado ese momento la complejidad va en aumento.

En nuestros proyectos intentamos evitar este problema cambiando el orden natural del despliegue, en lugar de desplegar al finalizar proyecto o en la primera iteración entregable, desplegamos un ¡Hola Mundo! tan pronto como nos es posible. Con esto no me refiero a las 3 líneas de código que escribimos al iniciarnos en un nuevo lenguaje de programación. En realidad nuestro ¡Hola Mundo! debe hacer algo más: 
  • "Nos saluda" desde el Log. Lo cual no es decir poco; esto implica que hemos definido la estrategia de tratamiento de Logs, tenemos acceso de escritura donde quiera que se registre y el equipo de desarrollo dispone de accesos de lectura para verificar que el "recién nacido" respira.
  • Establece conexión con los orígenes de datos que utilizará (SGBD, WebServices, ...) y nos informa positiva o negativamente a través del Log.
  • Disponemos de, al menos, una prueba unitaria y una prueba de sistema. En realidad buscamos asegurarnos que existen los proyectos de pruebas asociados y se lanzan junto con la compilación. Las pruebas en este momento no nos preocupan demasiado, con un AssertTrue(true) tendremos el efecto deseado: 100% de las pruebas ejecutadas y funcionando.
  • Nuestra máquina de Build dispone de una definición de compilación que obtiene nuestro (escaso) código, ejecuta las pruebas (obviamente pasan) y nos proporciona la carpeta de despliegue.

Durante nuestro "primer día de proyecto" hacemos las tareas que solíamos realizar en los últimos días: solicitar un código de identificación para nuestro sistema en producción, darlo de alta en la CMDB corporativa, escribir los manuales de instalación... La ventaja es que a partir de ese momento (la primera semana del proyecto) somos capaces de asegurar que nuestro sistema se ejecuta correctamente en el entorno de producción. Vale, al usuario le aporta poco o nada, de hecho se trata de una producción oculta...pero a nosotros nos aporta una información de gran valor.

Obviamente para desplegar un ¡Hola Mundo! no es necesario automatizar las pruebas ni utilizar máquinas de compilación remota. En nuestro caso lo hacemos así porque es la configuración por defecto de nuestros proyectos y garantiza que cualquier incremento de código no rompa la build ni deje test sin funcionar, obviamente se deben desarrollar más allá del AssertTrue(true). Lo que realmente nos interesa es verificar que el nuevo sistema "se levanta" correctamente en producción, conecta con los sistemas con los que se  deberá integrar y nos informa positivamente al respecto. No hacemos nada que no haríamos unos meses después (no desperdiciamos tiempo ni recursos) y anticipándonos convertimos en problemas reales los riesgos futuros y al despejarlos en un instante tan prematuro el tiempo corre a nuestro favor.

Día 2 del proyecto: el mejor momento para desplegar la versión 0.2 

Bueno, si lo dicho anteriormente puede llegar a encajar (al menos en un porcentaje aceptable de proyectos)  ¿Por qué no repetirlo al día siguiente? Y por "día siguiente" queremos decir tan pronto como sea posible... 

La idea es que si ya dispongo de una versión operativa en producción, no debo esperar hasta la entrega final para volver a realizar el despliegue. Si todos los días despliego mi nueva funcionalidad, todos los días validaré que el procedimiento de despliegue funciona y el "día D" pasará de ser "los 4 días D" a un despliegue rutinario... nosotros nos estamos aproximando a esta idea a partir del enfoque explicado por Jez Humble y David Farley en Continuous Devivery (CD).

Ahora bien, si para desplegar nuestro ¡Hola Mundo! no teníamos muchas restricciones, en esta nueva fase sí que necesitaremos un buen control de código fuente y una práctica "real" de integración continua. El enfoque que sigue CD es automatizar al máximo el proceso de despliegue (el objetivo final es que la única intervención humana sea pulsar el botón) por lo que igualmente necesitaremos  máquinas de compilación remotas.

El esfuerzo de implantar Continuous Delivery (CD) va mucho más allá que la buena práctica de desplegar y validar nuestro sistema tan pronto como sea posible explicada gráficamente con nuestro ¡Hola Mundo! El objetivo que perseguimos es que diariamente se valide nuestro proceso de puesta en producción, lo cual no implica que todo los días deba liberar una versión, sino que disponemos de un procedimiento que funciona y nos ofrece las garantías necesarias para poder asumir un despliegue inmediato si tuviera la necesidad de hacerlo de urgencia.

Esto son palabras mayores y el esfuerzo no es trivial, actualmente estimo que llevaremos andado una buena parte del camino...en próximos post iremos explicando en más detalle los entresijos de CD y cómo, poco a poco, lo vamos afrontando nosotros. 










lunes, 4 de febrero de 2013

TDD - Test Driven Development


TDD es una técnica propuesta en 2002 por Kent Beck (firmante del Manifiesto Ágil y autor de la metodología Extreme Programming) y altamente extendida desde entonces. Desarrollar atendiendo a esta técnica implica asumir que el código fuente incluye las pruebas unitarias, de tal forma que, no se puede considerar terminado un método/módulo si no existen las correspondientes pruebas que lo validan.

El algoritmo de esta técnica es bastante sencillo aunque el impacto en la forma de programar es muy alto por lo que para el programador es difícil interiorizar el proceso cuando se comienza a aplicar la técnica. El algoritmo consta de 3 partes:

1. Implementar la Prueba Unitaria que deberá cumplir el software que tenemos que construir. Si somos capaces de ejecutar la prueba (es muy posible que no llegue ni a compilar) la prueba no pasará.

2. Implementar el código mínimo necesario de negocio que hace que la prueba pase. Es importante destacar que el algoritmo propone que no busquemos el código óptimo en este momento (para eso está el último paso), únicamente nos interesa que la prueba pase (de ahí el nombre del método…el desarrollo lo dirigen las pruebas, nuestra meta principal es conseguir que las pruebas pasen, obviamente es crítico elegir bien el conjunto de pruebas necesarias para llegar a implementar el método/módulo/sistema que marcan las especificaciones).

3. Refactorizar el código escrito en el punto 2. La técnica de refactorización forma parte de la metodología Extreme Programming y se puede definir como alterar la estructura interna de un determinado código fuente sin alterar su comportamiento externo. Esta técnica obligatoriamente requiere para su aplicación de un robusto conjunto de pruebas automáticas que nos garantice que los pequeños cambios incorporados en el código no alteran su comportamiento. Las refactorizaciones se deben realizar siempre en pequeños y atómicos cambios.

La refactorización es un tema suficientemente extenso como para tratarlo por separado pero aplicado en un contexto de TDD nos deberemos centrar sobre todo en la robustez del código y en evitar el código duplicado generado en el paso 2. Cada pequeño cambio en el código implica que se vuelven a ejecutar las pruebas unitarias para verificar que no hemos “estropeado” nada con la refactorización.

Atendiendo a las interfaces gráficas de las herramientas de automatización de las pruebas unitarias se suele resumir el algoritmo de TDD con 3 palabras:

1. Rojo
2. Verde
3. Refactorizar


Rojo cuando se escribe la prueba se ejecuta por primera vez, obviamente no pasa y la interfaz la marca en rojo (en realidad lo que suele ocurrir es que rompemos la compilación...ni tan siquiera conseguimos el rojo). Verde cuando se escribe el código fuente que implementa el objeto de la prueba. Refactorizar…cuando mejoramos el código. Ojo, ese habitual olvidarse de este último paso, consiguiendo lo contrario de lo que pretende la técnica: un código de peor calidad.

Como se ha comentado anteriormente lo difícil de la prueba es ponerla en marcha, cambiar la forma de programar. M. Poppendieck asocia TDD al segundo principio de Lean Software Development: Build Quality-In, por su parte Henrik Kniberg comenta que sería lo último a lo que renunciaría en un equipo de desarrollo, M. Cohn le atribuye a una mejora significativa de la productividad de los equipos de desarrollo. Obviamente, las referencias (y sus promesas) son suficientemente solventes como para plantearnos el esfuerzo, pero hay que reconocer que nuestro primer acercamiento a TDD ha sido ciertamente "durillo". Probablemente por falta de experiencia en pruebas unitarias (+ mocks). Aunque no descartamos seguir profundizando e intentando su puesta en marcha, he de reconocer que la hemos postergado un poco en favor de otras prácticas más "ligeras" sobre las que podamos obtener un mayor ratio coste/beneficio.



Referencias utilizadas:
Diseño Ágil con TDD, Carlos Blé y colaboradores.

lunes, 28 de enero de 2013

Métricas de código en Visual Studio


Visual Studio incorpora “de serie” unas métricas que código que nos ofrece una mayor visibilidad sobre la calidad del código que se está desarrollando. El análisis del código de un determinado proyecto/solución se puede hacer a demanda desde el menú Analizar – Calcular métricas de código para el proyecto/solución o haciendo clic con el botón derecho del ratón sobre el proyecto concreto (explorador de soluciones).

El resultado del análisis se mostrará en la ventana “Resultados de métricas del código”.


El analizador nos muestra 5 métricas por método:

·         Índice de Mantenibilidad: Utiliza un algoritmo para, atendiendo al resto de las métricas, ofrecer un valor comprendido entre 0-100. Cuanto más cercano a 100 más mantenible es el software. El analizador muestra una codificación por colores:
o    Verde [20, 100] à mantenimiento bueno.
o    Amarillo entre [10, 19] à mantenimiento moderado.
o    Rojo [0, 9] à mantenimiento pobre.

Después de analizar varios de nuestros proyectos hemos observado que en ninguno de los casos se muestra un valor amarillo o rojo, por lo que, o bien todos nuestros proyectos tienen una calidad extraordinaria (con el código heredado y las prisas en el desarrollo de determinados proyectos no me lo creo) o bien tendremos que afinar el umbral a partir del cual consideramos necesario inspeccionar/mejorar el código. Inicialmente nos planteamos mantener este valor por encima de 50 y se irá ajustando según vayamos ganando experiencia con la métrica.

·         Complejidad ciclomática: representa la complejidad estructural de una porción de código. Se calcula sumando las instrucciones condicionales, los bucles, las salidas (return extras) de los métodos y las cláusulas AND y OR dentro de los condicionales. A mayor valor de esta métrica peor mantenibilidad.

McConnell en CODE COMPLETE argumenta que está generalmente aceptado para lenguajes como java o C# que esta métrica sea menor que 10 aunque en determinados entornos se han obtenido buenos resultados con un umbral de 15. Nos planteamos no ser demasiado estrictos con esta métrica. Hemos encontrado, por ejemplo, funciones de conversión de cantidades numéricas a letras que requieren de un gran número de estructuras condicionales y aunque la complejidad ciclomática de esta función sea elevada su alta cohesión no parece aconsejar su división en varias funciones para mejorar la complejidad.

·         Profundidad de Herencia: Cuanto más profunda es la jerarquía de la herencia de las clases involucradas en un determinado método, más complicado es entender el código. Diferentes estudios indican que a partir de un nivel de jerarquía de 4 la mayor parte de los programadores tenemos problemas para entender el código.

·         Acoplamiento de clases: mide las relaciones que el método en análisis tiene con otras clases a través de parámetros, variables locales, tipos de valores devueltos, llamadas a métodos, implementaciones de interfaces, etc. Un acoplamiento muy elevado indica que el diseño presenta o presentará futuros problemas de mantenibilidad. Debido a que esta métrica está muy asociada al tiempo de diseño es importante tenerla “bajo control” en momentos tempranos del proyecto puesto que su resolución futura puede ser bastante más complicada que, por ejemplo, la complejidad ciclomática que podemos solucionar extrayendo un método nuevo.

·         Líneas de código: número de líneas de código de un método sin contar espacios ni comentarios. Si el número de líneas de código es demasiado elevado, esto indica que el método está intentando hacer demasiadas cosas, síntoma de baja cohesión y de difícil mantenibilidad. Hay mucha discrepancia en cuanto al número adecuado de líneas de código, pero en lenguajes tipo java o C# un umbral generalmente aceptado son las 50 líneas.

En cualquier caso, una buena práctica extendida es intentar que un método se visualice por completo en la pantalla sin necesidad de utilizar la barra de desplazamientos, esto facilita el seguimiento en tiempo de depuración y una buena estructuración en tiempos de construcción.

Dependiendo del tipo de proyectos, arquitecturas utilizadas y tiempo de vida del proyecto los umbrales podrán variar, nosotros después de una breve inspección de varios proyectos que actualmente se encuentran en fase de mantenimiento hemos definido la siguiente tabla, como punto de partida para posteriormente adaptarlos:

Índice de Mantenibilidad
Complejidad Ciclomática
Profundidad de herencia
Acoplamiento de clases
Líneas de código
>50
<10
<4
<7
<25

lunes, 21 de enero de 2013

Planning Poker: Un método de estimación ágil de software


Planning Poker® es una técnica de estimación de software puesta en marcha por primera vez por James W. Grenning en un equipo de desarrollo Ágil utilizando XP en 2002.

Los resultados positivos del Planning Poker se derivan de la combinación del uso de opinión experta (quien normalmente realiza la tarea la estima), analogía (puesto que un gran número de historias tienen similitud con el trabajo desarrollado previamente por el equipo) y división del esfuerzo de estimación (en historias de un tamaño adecuado para evitar que la desviación sea elevada).

En las sesiones de Planning Poker debe jugar todo el equipo de desarrollo y aunque determinadas historias no afecten por igual a todos los integrantes del equipo será necesaria la participación activa de todos. El otro role necesario es el moderador que será el encargado de que los participantes lleguen al consenso (en equipos ágiles el moderador suele ser el Product Owner, aunque si no disponemos de esta figura bastará con que el moderador conozca suficientemente las historias que deben estimarse).

El juego es fácil:

El moderador coge una historia y la explica al equipo.

Los integrantes del equipo hacen las preguntas necesarias para aclarar los aspectos que no entendieron de la historia.

Cuando todo el equipo parece entender la historia se inicia la primera ronda, cada integrante estima el esfuerzo y simultáneamente sueltan una tarjeta sobre la mesa. En el hecho de hacerlo simultáneamente es probablemente donde reside la potencia de este método, evitando que la opinión de la persona que pueda tener más experiencia con la tecnología o sistema que estamos tratando “contamine”  la decisión del resto.

Si existe una diferencia significativa entre la estimación mayor y menos, las personas que realizaran estas estimaciones iniciarán el debate explicando por qué han dado esa estimación. Ante diferencias muy grandes nos solemos encontrar con funcionalidad “escondida” que determinadas personas han incluido en su estimación (de ahí que se eleve) o una sobre-estimación del esfuerzo de la persona que estimó por debajo. Si es necesario, el mediador (y el resto del equipo) participarán activamente para aclarar la situación.

De nuevo se vuelve a estimar y todo el equipo vuelve a sacar una carta. Generalmente se suele llegar a un consenso en la segunda ronda, si no es así, se volverá a intentar (rara vez supera la tercera ronda). El objetivo es alcanzar un mínimo de consenso, no que todos saquen la misma carta. 


Además de la estimación en sí, la ventaja de realizar Planning Poker es que se descubren características ocultas al poner en común las historias e incluso puede darse el caso de tener que posponer la estimación de una determinada historia por falta de información concreta. Esto nos lleva a un refinamiento de los requisitos antes de iniciar el desarrollo de los mismos. Es muy posible que se gane tiempo si llegamos a esta conclusión en una sesión de Planning Poker y justo al finalizar la sesión la persona responsable se encarga de aclarar con el usuario  la funcionalidad necesaria.

¿Qué se necesita para "jugar"?

·         Un equipo de desarrollo.
·         Un moderador (puede ser un miembro más del equipo, aunque al ejercer de moderador no podrá jugar).
·         Tantas barajas de Planning Poker como miembros del equipo.
·         Varias historias de usuario para estimar.

En cuanto a las barajas difieren un poco de las tradicionales y suelen tener esta pinta (la del ejemplo está obtenida de la Web de la Consultora sueca Crisp)




Obviamente no tiene nada que ver con una baraja de Poker normal. El número de cartas se reduce para acelerar la estimación y la distribución particular de los números (serie de Fibonacci alterada) intenta provocar una mayor sensación de incertidumbre al estimar historias grandes… de 20 pasa a 40 y de ahí a 100... Lo que se pretende con esto es dejar patente que en estimaciones de historias de esos tamaños la incertidumbre y por tanto la probabilidad de error es muy alta, por lo que si no te sirve una estimación a dedo alzado será preferible dividir la historia y estimarla por separado.

Si algún miembro del equipo saca la taza del café es para pedir un descanso, la ? se utiliza para indicar que con la información disponible no se tienen ni idea del esfuerzo a realizar y el 0 indica que el esfuerzo es mínimo…prácticamente despreciable. En la baraja estándar también está el símbolo de infinito, para reflejar una historia de extensión fuera de alcance (con los recursos actuales).

Existen aplicaciones móviles que te permiten jugar a Planning Poker, pero me temo que la potencia está en el método, en este caso la tecnología no nos ayudará a realizar mejores estimaciones.

Otras fuentes:

Si te interesa el tema puedes encontrar más información en AgileEstimation and Planning, Addison Wesley, 2005,  M. Cohn.

También puedes ver un video explicativo de planning poker en YouTube de 4 minutos (inglés).





Planning Poker® es una marca registrada por Mountain Goat Software, LLC.