La Integración continua: Netscape, la NASA, XP y dos mayordomos

En el artículo “La Integración Continua reduce el riesgo en proyectos software” comentábamos un poco el contenido del artículo de Martin Fowler que sacó en el 2005 sobre este mismo tema. En este artículo Fowler explicaba que la CI tenía un beneficio directo en los proyectos software reduciendo el riesgo, y  tuvo el efecto  añadido de  ayudar a que se difundiera con aún más fuerza.  Haciendo un guiño nostálgico a un anuncio del 2001 que decía “Si no sabes programar no sabes informática”, hoy en día “si no practicas la integración continua, no desarrollas software”. Volviéndome a ponerme nostálgico, ya lo decían en un anuncio de los 80: “la informática es mucho más que unas palabras”. Porque desarrollar software es mucho más que sentarse durante horas a escribir líneas de código.

programador3

Los que conozcan Extreme programming me dirán, “integración continua es una de las prácticas de XP”. Sí que lo es, es una de las 12 prácticas de XP, pero ¿cómo fue su evolución? y ¿a quién se le ocurrió por primera vez que debían hacerse integraciones automáticas lo más a menudo posible para reducir el riesgo en los proyectos? ¿Un día se levantó Kent Beck de la cama y dijo: “¡¡¡Eureka!!!”? y uno de los doce mandamientos será: integración continua. Nada más lejos de la realidad.

Os Dez Mandamentos 1

La CI fue propuesta y nombrada por primera vez en 1991 por Grady Booch en su método (Método Booch). En este caso Booch no hablaba en ningún caso de integrar varias veces al día. Grady Booch es conocido por desarrollar UML junto con James Rumbaugh. En 1991/94 desarrolló el método Booch. Se trataba de una técnica usada en ingeniería software para el diseño de objetos (predecesor de UML y RUP). Este método hablaba de uso de objetos, métricas, QA, patrones de diseño, formalismo, madurez de procesos y una notación robusta. Habla de sacar releases de arquitectura hasta llegar al sistema final (evolutivos)…si, es el precursor de RUP también, evidentemente.

image-83472-full

En los años 90 del siglo XX se producían dos temas importantes para el surgimiento de la integración continua. Uno fue que contrataron a Kent Beck (uno de los creadores de XP) en Chrysler con el objetivo de llevar un proyecto (El C3) de gestión de nominas, en el cual los requisitos eran un gran problema (¡¡¡no me lo esperaba!!!…). Parece ser que el sistema legacy de nóminas era bastante infumable (más de lo habitual supongo), se trataban de varias aplicaciones, cada uno de su padre y de su madre, que hacían lo mismo en algunos casos pero de forma diferente y donde los requisitos, como no, brillaban por su ausencia. El primer año que sacaron la primera release fue muy duro. Tan duro,  que  cliente, punto de contacto de Chrysler con el proyecto, tuvo que pedir la baja por estrés.

liberar-estress

Por otro lado, mientras se cocía la historia de Chrysler y XP, ocurre una historia paralela. Los ingenieros de calidad de Netscape, tuvieron una gran ocurrencia. Estos llegaron a la conclusión de que sería bueno poder realizar construcciones del código automáticamente de forma periódica. Tenían bastantes problemas con CVS (que acaba de surgir en los 90), ya que cada vez que iban a sacar una release, el código no compilaba correctamente: “en mi máquina funciona” decían los desarrolladores.

fz1t19.jpg

Se pusieron manos a la obra y crearon una herramienta muy sencilla llamada Tinderbox que les permitía realizar una construcción diaria de su software de forma que sabían en el mismo día si había habido un problema con la construcción del mismo (la build). En poco menos de un año, se dieron cuenta que bajando la cadencia de los builds, eran capaces de saber cuál había sido el problema de integración que había roto la build (a menos tiempo, menos commits realizados y más fácil detectar el problema de fallo). Progresivamente bajaron la cadencia hasta  realizar builds automáticos cada hora. Cuando en 1998 el código de Netscape es liberado, también es difundida su forma de trabajo a la comunidad de open-source. De esta manera la construcción frecuente de tu código de forma automática pronto se convirtió en una buena práctica en el mundillo del desarrollo software.

best-practices.jpg

XP lleva las mejores prácticas a niveles extremos. Por ejemplo la práctica de hacer test antes de desarrollar fue usada por la NASA en el programa Mercury Space por primera vez para tarjetas perforadas en 1960. XP la llevo al extremo con TDD. Aunque Kent beck no se considera a sí mismo el creador de Test Driven Development, fue el que implemento SUnit, un framework de tests unitarios para Smalltalk que fueron las bases de la familia xUnit (conjunto de frameworks basados en sus premisas como nUnit, phpUnit, junit, MsUnit, etc). Este framework se pensó para realizar TDD basándose en ideas de Gerard Weinberg y Leeds, Herbert D. en su libro (Computer Programming Fundamentals – 1960). Sí, he de afirmar que es curioso que en la portada original Weingberg no aparezca. Pero eso es otra historia.

51+GmuMoPYL._SX331_BO1,204,203,200_

Otra de las prácticas que se lleva al extremo es la integración continua. Kent Beck tomó la idea de Booch, las nuevas buenas prácticas de los build automáticos con las ideas de los servidores de builds automáticos emergentes y la inclusión del framework de test automáticos que había creado para dar forma a una de las prácticas de XP: Si aquellos tipos de Netscape podrían hacer construcciones del código cada hora, ¿por qué no íbamos a poder hacerlos en cada commit y además pasar automáticamente baterías de test automáticamente con sUnit? En 1999 Kent beck publica el primer libro sobre XP donde incluye el concepto como una de sus 12 prácticas.

circles.jpg

La integración continua ha ido evolucionando a medida de que han ido apareciendo nuevas tecnologías y herramientas. Si tenemos que pensar en cual fue la primera herramienta construida para este propósito, podemos pensar que fue Cruise Control que surgió en el 2001 como servidor de builds extensible. Esta herramienta estaba pensada para realizar builds automáticos usando Ant o Maven. Funcionaba (y funciona) a través de plugins que extendían su funcionalidad. Se trata de una herramienta gratuita y open-source.  Existe una herramienta para .NET similar denominada Cruisecontrol.NET que aparece en el 2003 con su versión 0.3.1 pero no es hasta 2005 que aparece la primera versión 1.0 estable. Es decir, que la integración continua basada en herramientas específicas (no el concepto como tal), tampoco es tan lejano. Fue cuando se estrenó “Batman begins”.

Batman-Begins-batman-555782_1024_768.jpg

Hudson es otra herramienta de integración continua escrita en Java que se ejecuta en un Apache Tomcat o en el servidor de aplicaciones GlassFish. Trabaja con CVS, Svn, Git y clearcase, y puede ejecutar Apache Ant y Maven así como procesos Windows. Hudson surgió en 2008 y se convirtió en una alternativa a Cruise control y otros servidores de builds de código abierto.  El desarrollador principal de Hudson fue Kohsuke Kawaguchi que actualmente es empleado de Sun Microsystems. Si dejas a un montón de desarrolladores software el código de una herramienta como esta, pasa lo que pasa: crean una comunidad y la llevan “hasta el infinito y más allá”.

kohsuke.jpg

Cuando más adelante Oracle compró Sun, este declaró que quería registrar el nombre de Hudson y desarrollar una versión comercial. Esto enfadó mucho a la comunidad de desarrollo de Hudson, la cual decidió, junto con Kawaguchi hacer un fork del código de Hudson y llamarlo Jenkins en 2011 (ambos son nombres típicos de mayordomos). Al final Oracle se da por vencido y en 2012 dona Hudson a la fundación Eclipse. En 2013 llevan muchos commits de Jenkins a Hudson. Lo que decía yo… “hasta el infinito y más allá”.

jenkins vs Hudson java

El caso es que los conceptos han cambiado poco desde final del siglo XX, ya que siguen siendo prácticamente los mismos. Si han aparecido nuevos, es porque han aparecido herramientas que ahora lo permiten y anteriormente no, o no con la misma facilidad. De la integración continúa se pasa a la entrega continua y de ahí al despliegue automático en producción. Hoy en día existen muchas herramientas y plugins desarrollados que están trayendo nuevos conceptos y capacidades de automatización, o quizá ya no tan nuevos en el momento de publicación de este post. Algunas organizaciones, hoy en día, son lo suficientemente maduras para automatizar tanto el desarrollo software y las pruebas, que con cada commit despliegan directamente en los servidores de producción  con seguridad (pocas son) (continuous deployment). Pero eso amigos, eso, es otra historia.

continuos deployment vs delivery.jpg

PDFicono EXTENDIDO

REFERENCIAS:

[1] Continuous Integration – Martin Fowler
[2] Continuous delivery  – Martin Fowler
[3] Extreme Programing Explanined:Embrace change – Kent Beck

Anuncios

Motivación al estilo Rocky Balboa en los equipos: Motivación intrínseca

Tuve mi primer ordenador cuando tenía 16 años. La fuerte motivación que me llevo a reclamar intensamente durante de 5 años un cacharro de esos, no provenía del deseo de jugar a esos modernos juegos en VGA 320×200 a pesar del temor de mis padres a que me esos jueguecitos me sorbieran el cerebro. Esta fuerte sensación que se convirtió en una cruzada, comenzó la primera vez vi un ordenador y quedé fascinado por como mi vecino tecleaba comandos para que esa máquina hiciera cosas: básicamente cargar el juego de Game Over en cinta en Amstrad CPC con monitor verde. Quedé fascinado por el proceso de cargar el juego y no por el juego en sí.  Cuando me puse a jugar me mataron a la primera y cómo había que esperar un buen rato para cargar otra partida perdí el interés por jugar.

CPCverde

 Y es que aquello que me llevó a más de 5 años de insistencia para conseguir uno de esos cacharros no fue el hecho de poder tenerlo y jugar, sino el hecho de que quería dominar esa máquina para poder hacer yo mis propios juegos. Tanto insistí en esos años que no me compraron un CPC sino un fantástico 386 con tarjeta VGA y un ratón (sin coprocesador matemático). Tardé una semana en desmontarlo para ver que había dentro y 2 días en decidir si volver a la tienda para ver si me lo podían volver a montar. Fui bastantes veces, yo era un chaval muy pesado, y al final me hice amigo del dueño que resultaba que sabía programar.

pc-roto

Mis primeros ficheros batch fueron usando un ejecutable que él había creado en pascal para poner colorcitos a los caracteres y pintar el fondo de pantalla. Lo hacía por el simple hecho de poder hacerlo, porque realmente a nadie le importaban mis jueguecitos y tampoco nadie me pagaba por ello: ni falta que hacía. Por lo que creo que mi motivación provenía del hecho de simplemente poder hacer aquello que me gustaba. Supongo que es lo que denominan motivación intrínseca y desgraciadamente es algo que padezco desde muy joven: No sé cómo ni cuándo la pillé pero según me han dicho tengo que vivir con ello de por vida. Yo creo que todo empezó con ese CPC y esa adicción de niño por esas películas de Rocky Balboa. Pienso que todo el mundo quiere vivir esa sensación de logro  con esa tremenda música de fondo. Os recomiendo echarle un vistazo aquí antes de continuar: mano de santo.

rockybalboa

En la motivación intrínseca, la persona realiza una actividad por simple placer de realizarla sin que alguien le proporcione ningún incentivo externo. Por otro lado la motivación externa es algo que aparece cuando lo que atrae a la persona no es la acción que realiza si no lo que se recibe a cambio de lo que estás haciendo. Cuando hacemos cosas por motivación intrínseca es muy probable que tengamos estados de flow y una vez terminada la tarea experimentemos un estado que es mezcla de cansancio y satisfacción personal. Sin embargo, cuando hacemos tareas que realmente no nos apetece hacer donde nuestra única motivación es un salario a final de mes o lo que vamos a obtener tras el resultado, nuestros niveles de concentración bajan. Cuando terminas te sientes bien, pero no por haberlo hecho sino por haberte quitado el muerto de encima, por lo que te sientes normalmente cansado y deseoso de no tener que volver a hacerlo nunca más. De hecho, en el momento que aceptamos hacer la tarea, la recompensa nos parece interesante, pero cuando hay que hacerlo todos los días al final… ni siquiera eso motiva.

motivacion_intrinseca_extrinseca

No quiero decir que la motivación extrínseca sea mala, de hecho si tienes que hacer un montón de tareas tediosas y banales lo mejor que puedes hacer es hacer una checklist y recompensarte a ti mismo con algo si consigues checkear cada uno de los puntos. El caso es que para trabajos creativos no funciona y lo que deberíamos buscar tanto en nosotros mismos como en nuestros equipos es la motivación intrínseca. El motivo por el cual tendemos a usar la motivación extrínseca es un tema cultural.  La motivación extrínseca en el trabajo proviene de la visión de liderazgo que se tenía en la época industrial que se basaba en que los obreros iban a hacer lo mínimo imprescindible, no les importaba la calidad y no sabían cuál era la mejor manera de hacer las cosas. Por ese motivo había expertos que debían dividir el trabajo en tareas más pequeñas y decidir cuál es la mejor forma de hacer las cosas. En consecuencia había que pagar más a los empleados para que sigan el “modo experto”. Esta cultura lleva sin duda a uno de los antipatrones de la motivación: el liderazgo autocrático.

cadenamontaje

No sé si os acordáis algunos de esa enciclopedia digital que sacó Microsoft en los 90: Microsoft Encarta. Se trato de un proyecto ambicioso de Microsoft que surge en los 80 al detectar la necesidad de un motor de búsqueda en hipertexto, con hiperenlaces, con contenidos multimedia, mapas, en inglés, alemán, francés, español, neerlandés, italiano, portugués y japonés. Recuerdo haberla tenido en varios CDs, tenía más de 64000 artículos. En 2009, todos sus contenidos fueron cerrados y el proyecto fue un autentico fracaso. Encarta había sido barrida por un proyecto iniciado en el 2000 de open source donde la gente no recibía nada a cambio de alimentar con contenido a esta enciclopedia…bueno sí: satisfacción personal. En 2008 había escritos 9790407 artículos en creo que 264 idiomas según sus últimas estadísticas. Estamos hablando de Wikipedia y de la fuerza de la motivación intrínseca en el ser humano.

Wikipedia-logo

La motivación intrínseca ha sido estudiada por psicólogos desde 1972, sin embargo no hay una teoría unificada magistral para explicar su origen o los elementos de esta motivación. La mayoría de las teorías se basan en la teoría de la atribución de Weiner. Haciendo un resumen rápido, Weiner explica cómo las personas perciben un fracaso o un logro, y esta percepción la realizan en función de una búsqueda de cuál fue la causa raíz. En función de cómo las personas interpretan subjetivamente la situación tendrán mejor o peor percepción de sus posibilidades en el futuro y eso hará que decaiga o aumente su motivación. Otras teorías sobre la motivación son:

  • La pirámide de Maslow. Se trata de una jerarquía de necesidades humanas donde se defiende que conforme se satisfacen las necesidades más básicas (parte inferior de la pirámide), los seres humanos desarrollan necesidades y deseos más elevados (parte superior de la pirámide).

400px-Pirámide_de_Maslow

  • Teoría de los dos factores. Se trata de una teoría formulada para explicar el comportamiento de las personas en situaciones de trabajo. Hay dos factores, la satisfacción y la insatisfacción. Se realiza esta separación para explicar que la insatisfacción del individuo se produce por la ausencia de factores de higiene: sueldo, política empresa, supervisión, seguridad laboral, etc. La satisfacción se produce gracias al reconocimiento, independencia laboral, promoción y logros.
  • Teoría X y Teoría Y. Se tratan de dos teorías contrapuestas definidas en la década de los 60 por Douglas McGregor. Se describen dos visiones distintas del trabajo y las formas de dirección. Teoría X donde el trabajador es pesimista, estático y con aversión innata al trabajo, y la teoría Y donde se considera al trabajador como el activo más importante de la empresa: optimista y flexible.
  • Efecto Pigmalión. Está más relacionado con la pedagogía, donde se describe que la creencia de una persona puede influir en el rendimiento de otra.
  • Teorías de Clayton Alderfer. Se trata de una revisión de la pirámide de Maslow donde se agrupan las necesidades humanas en: Existencia (necesidades fisiológicas y de seguridad), Relación (necesidades de interacción con otras personas) y crecimiento (desarrollo interno de la persona y autorealización).
  • Teoría de la esperanza. Explica por qué las personas eligen un comportamiento sobre otro. También explica como toman decisiones para lograr un fin.
  • Teoría de la equidad laboral. Afirma que un individuo tendrá en cuenta que recibió lo suficiente si percibe que la proporción de sus aportaciones a la empresa es equivalente a lo que aporta el resto de individuos. Además aquello que recibe a cambio lo debe percibir que sería aceptable para un colega que él considere que tiene más experiencia que él.

Como veis, si leemos todas, posiblemente tengamos más dudas que antes de haberlas leído y tengamos que consultar con un experto o psicólogo que nos dé un poco de luz. Y es que hay mucha discrepancia sobre el tema.

miauuu

Una explicación que me gusta mucho es la que Daniel Pink proporciona en su libro Drive. En este libro nos explica entre otras cosas que los incentivos no funcionan en entornos creativos. Los incentivos funcionan en trabajos a destajo: cuanto más haces, más ganas. Lo que comenta en el libro no es algo nuevo, de hecho muchos de los conceptos provienen de las teorías que os he comentado antes. Él dice que sin lugar a duda el ser humano está motivado dentro de un entorno laboral cuando los siguientes factores están cubiertos:

  • Factor de higiene en el trabajo. La persona necesita tener sus necesidades cubiertas y trabajar en un entorno en el que se sienta a gusto realizando su labor: sueldo digno, no ruidos, no interrupciones, etc. Si nos damos cuenta tiene mucho que ver con la teoría de los dos factores y con la pirámide de Maslow en la que si el ser humano tiene cubiertas sus necesidades básicas, entonces tenderá a cubrir otras de un nivel superior.

satisfaccion

  • Autonomía. Uno de los factores que nos motiva al acometer una tarea es determinar la forma en la que haremos que nuestro trabajo sea más efectivo. La mayoría de las personas son más productivas cuando pueden administrar su tiempo y lugar de trabajo. La autonomía debe desarrollarse, tanto la individual como la del propio equipo. No hay nada que más desmotive que alguien te diga cada paso que debes seguir para hacer tu trabajo. Necesitamos un objetivo y la libertad para poder decidir cómo llegar hasta él. El truco de un líder está no en decidir cómo deben hacerlo si no establecer el contexto adecuado y reglas adecuadas para que ellos puedan llegar a su objetivo con la suficiente autonomía.

tiempo_manage

  • Maestría. Una persona logra su satisfacción personal a medida que logra llegar a dominar un campo de trabajo. Este dominio sólo se logra cuando se desarrollan los talentos naturales de la persona. Así que lo que estamos hablando es de desarrollo profesional y personal. Esto está muy relacionado con el concepto de flow de Mihaly Csikszentmihalyi donde explica como la persona logra la satisfacción personal en la medida que logra llegar a dominar un área laboral. Por eso es tan importante que el equipo y los individuos tenga retos nuevos que les sirvan para alcanzar esa maestría en lo que hacen.

Joda

  • Propósito. Aun teniendo autonomía y logrando la maestría en el trabajo, es necesario un propósito, es decir, saber que lo que hacemos tiene un valor que va más allá de nosotros mismos.

propósito

La motivación en los equipos es uno de los factores que se deben cuidar. Olvidarse de este factor o pensar que “los trabajadores deben venir motivados de casa” es una actitud que al final sólo nos lleva a tener empleados “calentando el asiento esperando que toque la campana para irse a casa”. Sin embargo, tal y como hemos visto en el artículo, la motivación intrínseca en nuestro equipos tiene dos responsables: por un lado el individuo con su actitud que “debe venir predispuesto de casa” y por otro lado la organización que debe proporcionar el ambiente adecuado para que esa motivación emerja. Un líder que tiene en su contra un descuido de los factores de higiene por parte de la empresa, aún puede potenciar la maestría, el propósito y sobre todo siempre seguir la primera regla de la motivación: no desmotivar. Os dejo un ejemplo significativo donde podemos identificar que lo que mueve a Google es sin duda personas altamente motivadas.

Trabajar en Google – Parte 1

Trabajar en Google – Parte 2

PDFicono EXTENDIDO

REFERENCIAS:

[1] _Drive – Daniel Pink
[2]  Fluir (Flow). Una psicología de la felicidad – Mihaly Csikszentmihalyi
[3] Motivación – Wikipedia