Posts Tagged ‘desarrollo’

h1

El Javapocalipsis o cómo nos estamos quedando sin Java EE

07/15/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

No se trata de bits, bytes y protocolos, sino de beneficios, pérdidas y márgenes.

Louis Gerstner, Jr. (n. 1942). Empresario estadounidense, mejor conocido por su rol como director general de IBM entre 1993 y 2002.

Una tendencia aparentemente irreversible, es la lenta pero inexorable muerte de Java Enterprise Edition (Java EE). No me refiero al lenguaje de programación Java (también conocido como Java Standard Edition o Java SE), el cual está teniendo un enorme impulso gracias a su facilidad de aprendizaje e implementación, sino a todas aquellas tecnologías/librerías basadas en Java, que en su momento eran consideradas el non plus ultra para desarrollar aplicaciones multi-capa y empresariales: Servlets, Java Server Pages (JSP), Enterprise Java Beans (EJB), Java Persistence Architecture (JPA), así como Java Server Faces (JSF).

Cómo llegamos hasta aquí

En 1999, Sun Microsystems publicó Java EE, con la finalidad de desarrollar aplicaciones “de nivel empresarial”, que en su forma más simple, son aplicaciones web con alta disponibilidad, escalabilidad y mantenibilidad. Así, dicha versión de Java incluía los EJBs, Servlets y JSPs; tecnologías bastante complejas que requerían de al menos un día para mostrar el proverbial “Hola Mundo”. Debido a esta dificultad de implementación, la comunidad open-source respondió casi de inmediato, desarrollando y liberando en el año 2000 ciertos frameworks como Struts e iBATIS, los que disminuían enormemente el tiempo para terminar un delivery. Eventualmente, surgieron algunos frameworks más ligeros y ergonómicos que el propio Java EE, como Hibernate y Spring, los que forzarían a Sun adoptar su filosofía, en la sexta versión de Java EE, liberada en 2009.

Sin embargo, a raíz de la adquisición de Sun por Oracle, completada en 2010, la empresa dirigida por Larry Ellison ha dejado de apostar a esta plataforma, relegándola poco a poco al olvido. ¿La razón? Que Oracle es un conocido mercenario en la industria, y Java EE no está generando los suficientes ingresos como para asegurarle un presupuesto. Lo peor de todo es la poca transparencia y falta de un pronunciamiento claro al respecto, lo que está poniendo nerviosos a programadores, integradores y clientes por igual. Y no es para menos, pues considerando el historial de Oracle con los desarrollos open-source, existen muchas razones para preocuparse por el bienestar de esta plataforma; especialmente desde que Oracle perdió una batalla legal contra Google en Mayo pasado por el uso de Java en Android, la que ha desembocado en la demora de Java SE 9, cuya fecha de liberación se moverá hasta 2017, y la paralización de cualquier trabajo relacionado a Java EE.

Pic: Is Java dead?


Si bien la plataforma Java EE se encuentra en franca decadencia, el lenguaje de programación Java es parte de una era dorada empujada principalmente, por el explosivo crecimiento de los smartphones y tablets:

• Los applets de Java ya son cosa del pasado debido a que inicialmente apareció Flash; en última instancia, fueron liquidados por HTML5.

• La popularidad de Java en desktop siempre ha sido relativamente baja, debido sobre todo a otras opciones como C++ y Python. Sin embargo, definitivamente no está acabada y todavía se mantiene en evolución constante.

• Muchas empresas tienen enormes cantidades de código escrito en Java. Y si algo hemos aprendido de lenguajes legados como COBOL, es que frecuentemente, se niegan a morir – aunque ya no representaría una ventaja curricular conocerlo, a menos que seamos especialistas en alguna de sus tecnologías, como digamos, EJB 2.1.

• Java es el principal lenguaje de programación de los dispositivos Android, que son muy populares: en Otoño de 2015 existían alrededor de 1,400 millones de dispositivos activos alrededor del mundo.

En resumen, Java no va a desaparecer, incluso si Oracle se lo propusiera.


(Fuente de la imagen: ExtremeTech.com)


La cuestión es que al detener el soporte a Java EE, Oracle está poniendo en riesgo 15 años de desarrollo aplicativo y literalmente, millones de empleos alrededor del mundo. Hoy en día, ya hay competidores de Oracle que estarían dispuestos a tomar el relevo para continuar con el proyecto, como IBM y RedHat, quienes ciertamente tienen los recursos para soportar la plataforma, además de tener la capacidad de agregarle funcionalidad de acuerdo al actual entorno tecnológico, como los microservicios. Claro que Oracle siendo Oracle, puede comportarse como el siniestro Guasón de The Dark Knight (2008): esta compañía preferiría convertirse en un agente del caos, antes de permitir que las joyas de la corona caigan en manos de la competencia. Esto podría desestabilizar la industria, ya que daría lugar a una situación extrema en la que decenas de proveedores de TI, que dirigidos por Google, IBM y RedHat, se unan para generar su propia versión de Java EE, dejando a Oracle fuera de la jugada.

¿Qué pasará?

Lamentablemente, Oracle no ha sabido cómo capitalizar la ventaja competitiva que tiene al haber adquirido Java EE. Por el contrario, se puso un balazo en el pie, eliminando o echando a perder algunas de sus mejores adquisiciones, como WebLogic, GlassFish, OpenOffice ó Hudson. Y es que este siempre ha sido el modus operandi de Oracle: en vez de tomar un producto para hacerlo el líder de su respectivo nicho de mercado, se la ha pasado coleccionando buenos desarrollos, para poco a poco, retirarles el financiamiento. Eventualmente, los deja morir o los “tira a la basura”, al donarlos a la comunidad open-source cuando ya no representan un riesgo para su negocio central.

Si Ellison y su equipo tiene un mínimo de visión, en algún punto se darán cuenta que su verdadero negocio central son las bases de datos; no los servidores de aplicaciones y por supuesto, tampoco Java EE. En ese momento, darán las gracias y dirán adiós, permitiendo que el Java Community Process tome las riendas de la plataforma, dejando que algunos de sus miembros más fuertes se hagan cargo de su evolución. Sin embargo, si Oracle no hace absolutamente nada, tan sólo se necesitan un par de años más para que la entropía se haga tan evidente, que nadie querrá adoptar su funcionalidad, convirtiéndola en tan sólo algunas librerías de uso común en los productos de Oracle. Esto de hecho, ya está pasando en la actualidad: algunos de los clientes con los que he trabajado, están reemplazando sus servidores de aplicaciones empresariales (RedHat JBoss o IBM WebSphere) por simples Tomcats con Spring debido a que “Nos han pedido diversificar nuestro stack tecnológico, porque nuestra dependencia [en Java EE] se ha vuelto potencialmente peligrosa.” Siendo así las cosas, ya no habrá nada que hacer, dando el paso libre para otras tecnologías como MEAN (MongoDB + Express.js + AngularJS + Node.js”).

En fin, el único consuelo de tontos en este caso, es que Oracle se está disparando en el pie una y otra vez, repetidamente. Entonces, después de haber generado suficiente antagonismo con socios y clientes por igual, tal vez finalmente sangre lo suficiente como para que muera y sea comprada por alguien que sí tiene la visión necesaria para llevar esta plataforma hacia el futuro.

h1

Cómo hacer Pruebas de Concepto (POC): un enfoque formal

04/29/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

El verdadero viaje del descubrimiento no consiste en buscar nuevos paisajes, sino en tener nuevos ojos.

Marcel Proust (1871 – 1922). Novelista, ensayista y crítico francés.

Supongamos que nuestro equipo ha estado trabajando durante varias semanas / iteraciones / sprints y todo se ve bastante bien. Sin embargo, el cliente nos pide desarrollar un tipo de requerimiento que nunca hemos hecho anteriormente o del que no estamos seguros cómo implementarlo. ¿Qué hacer cuando el equipo debe enfrentarse a una cuestión técnica o funcional desconocida?

Con frecuencia, los proyectos TI se desenvuelven en un ambiente caótico, para el que es necesario resolver una serie de requerimientos funcionales a través de soluciones tecnológicas que conllevan un cierto riesgo durante su implementación. Para minimizar este riesgo, es necesario llevar a cabo lo que comúnmente conocemos como prueba de concepto (Proof of Concept – POC) o spike – este último, surgido del desarrollo de software ágil. Esta actividad consiste en la construcción de una maqueta o demo con la finalidad de evaluar la factibilidad de un requerimiento funcional vagamente especificado, el desarrollo de un componente de software, la adquisición de un producto, o una combinación de todos ellos. En resumen, cada vez que encontremos requerimientos que posean demasiada complejidad técnica o un fuerte grado de incertidumbre, es necesaria una POC para determinar su factibilidad e impacto. Sin embargo, es necesario recordar que todo requerimiento posee un cierto grado de incertidumbre y riesgo, por lo que las pruebas de concepto deben ser una excepción, no la regla: para los riesgos e incertidumbres “menores”, el equipo debe descubrir la solución mediante el debate, la colaboración, la experimentación y la negociación. Una POC o spike por el contrario, debe reservarse para problemas importantes y complicados de responder. Por ello:

• La prueba debe evaluarse de acuerdo a objetivos claramente definidos entre todos los stakeholders, incluyendo mínimamente, qué medir (funcionalidad de negocio, funcionalidad TI, funcionalidad de sistemas), cómo medirlo (costo, facilidad de uso, escalabilidad) y cómo se realizará la evaluación (a través de un scorecard, escenarios de uso).

• Asimismo, debe tener un tiempo definido (timebox), para hacer el suficiente trabajo como para obtener el valor requerido.

• Finalmente, la prueba debe ser parte integral de la estrategia de implementación del proyecto, habiendo sido debidamente planeada y documentada, incluyendo el tiempo y esfuerzo necesarios para su análisis, diseño e implementación.

Pic: Wright Brothers' Prototype Designs


Cuando Wilbur y Orville Wright perfeccionaron su aeroplano, decidieron probar sus teorías antes de sujetarse a sí mismos sobre el ala de una máquina voladora. Usando modelos a escala en túneles de viento, hicieron pruebas sobre la factibilidad del vuelo tripulado.

Iniciando en 1900, éste fue su primer prototipo, que básicamente era un papalote o cometa. Con él, probaron la idea de deformar la parte superior del ala para controlar el balanceo de la aeronave. Entonces construyeron un planeador en 1901. Este avión volaba como una cometa, pero también podía desempeñarse como un planeador pilotado. Los hermanos Wright ganaron experiencia de vuelo con este avión, descubriendo a la vez varios problemas que tuvieron que superar más tarde, como mayor resistencia al aire y la tendencia a voltearse en pleno vuelo. Después vino el aeroplano de 1902, que fue el primer avión en el mundo que podía ser controlado sobre sus tres ejes (transversal, horizontal y longitudinal). Finalmente, en 1903 construyeron su Wright Flyer: una aeronave pilotada que podía despegar y volar por sus propios medios.

Así, sucesivas pruebas de concepto cumplieron su propósito, dando a los hermanos Wright los datos necesarios para validar que sus objetivos e ideas tenían suficiente mérito como para continuar. Se demostró que la teoría podría funcionar en conjunto con otros factores integrales, como la experiencia necesaria para controlar un avión, materiales de construcción y requerimientos climatológicos.

(Fuente: NASA)

Mejores Prácticas

Una prueba de concepto no debe ejecutarse de manera aislada del resto de la organización TI; ésta debe contar con el apoyo de las áreas relacionadas a su implementación, tales como los usuarios de negocio, proveedores, infraestructura y soporte técnico. Esto porque cualquier retraso durante la ejecución puede volverse crítico. Adicionalmente, es buena idea seguir las siguientes mejores prácticas:

• Limitar el alcance. La solución debe evaluarse contra escenarios representativos; no todos los escenarios de uso. En caso de estar evaluando la adopción de un producto, debemos indicar al cliente de que ésta correrá en las plataformas estándar y usadas por clientes existentes. Asimismo, es muy importante no añadir alcance adicional a la POC, a menos que éste sea obligatorio para el éxito de ésta, y haya sido acordado por todos los stakeholders, incluyéndonos a nosotros.

• Planear con anticipación. A menudo, esta será la primera vez que varias organizaciones, incluyendo terceros, estarán trabajando juntos. Es indispensable asegurar que todos puedan comprometerse a los plazos definidos por la POC. También es importante alinear las reuniones de avance antes de tiempo. Los usuarios usualmente tienen sus actividades del día a día, y los cierres trimestrales o anuales pueden comprometer su disponibilidad para revisión o apoyo.

• Ejecutar la prueba de manera aislada al resto del ambiente productivo. A menos que la integración sea crítica, la conectividad con otros sistemas debe ser simulada. Esto porque casi siempre, obtener los permisos necesarios para integrar la maqueta a otros sistemas informáticos se convierte en todo un reto.

• Mantener a los stakeholders informados con regularidad sobre el progreso de la prueba. Cuando llega el momento de selección y/o evaluación, todos los interesados deben estar alineados a los resultados. Esta alineación es crítica para obtener la aprobación por parte de la dirección TI. El concepto clave aquí es “sin sorpresas”.

• Reuniones diarias de seguimiento. La prueba se llevará a cabo en un lapso de 2 a 8 semanas, por lo que un retraso de uno o dos días puede poner la fecha de entrega en riesgo. Una llamada o reunión de carácter informal al final de cada día asegurará que los retrasos, riesgos y problemas sean abordados y resueltos de forma rápida, minimizando el impacto sobre el resultado final.

Fases de implementación

Una POC consiste generalmente de seis fases que pueden variar en tiempo y esfuerzo de acuerdo a la complejidad, alcance y objetivos de la solución:

Fase
Descripción
Pre-Planificación
Prerrequisitos de la prueba.
Kick-off / Formación
Instalación de software, planificación detallada de la prueba de concepto y diseño de alto nivel de la solución.
Implementación
Diseño e implementación de la solución, en conjunto con retroalimentación del usuario y capacitación en los productos comerciales.
Pruebas / Capacitación a usuario
Verificación de que los escenarios de evaluación y todos los componentes están integrados correctamente. Creación de datos para la evaluación. Los usuarios son capacitados en la solución.
Evaluación
Los usuarios y la organización TI llevan a cabo la evaluación y retroalimentación de la POC.
Conclusión
Crear una presentación de resultados, incluyendo una recomendación.
Fases de ejecución de una prueba de concepto.

La fase de pre-planificación asegura que la prueba esté configurada de forma correcta, y que las dependencias hayan sido identificadas adecuadamente para que no haya retrasos durante su ejecución. Si ésta es la primera vez que se realiza un ejercicio de esta clase, es recomendable iniciar la fase de pre-planificación con al menos un mes de anticipación al kick-off. Si ya se han realizado dos o tres pruebas de concepto, la pre-planificación puede comenzar dos semanas antes del kick-off formal.

Por otro lado, el kick-off es una combinación de inicio formal de la prueba de concepto, así como el período durante el que ésta será planeada a detalle, mientras los compromisos por parte del equipo y proveedores son acordados, para llevar a cabo los escenarios de ejecución: instalación y configuración del o los productos, revisión de requerimientos, planeación y governance, diseño detallado, revisión funcional y arquitectónica, modelo de datos y posiblemente, hitos dentro de la construcción de la POC.

La implementación incluye no sólo la codificación o configuración de la solución, sino también reuniones de seguimiento. Los stakeholders deben ser informados acerca de entregables en tiempo y forma, y qué problemas y riesgos tienen que ser abordados. Esta es también una oportunidad para dar la primera respuesta oficial al o los proveedores acerca de sus fortalezas y debilidades percibidas, dándoles la posibilidad de ajustar su desempeño. Estas reuniones también ayudarán a reducir las desconexiones y posibles fallas de comunicación dentro del equipo.

La fase de pruebas se enfoca en las pruebas funcionales básicas de la solución, que frecuentemente incluyen la capacitación de los usuarios que estarán participando en la prueba de concepto. Es importante establecer las sesiones de capacitación y evaluación antes del inicio de la ejecución, para asegurar la disponibilidad de los stakeholders.

La fase de evaluación es aquella en la que los usuarios y el departamento IT recorren la solución y aplican los criterios para su selección. Se asume que, tanto la funcionalidad de la solución así como los escenarios implementados, serán utilizados para determinar el resultado final de la solución propuesta (aceptación y adopción, o rechazo y búsqueda de nuevas opciones).

Finalmente, la conclusión incluye los entregables de la POC (requerimientos, escenarios, scorecard, evaluación), así como las recomendaciones planteadas, que pueden incluir requerimientos presupuestarios, plan de capacitación, aprovisionamiento de personal y definición y/o cambio en requerimientos para los que se implementó esta prueba. En la siguiente liga se encuentra un ejemplo de dichos entregables.

Recomendaciones adicionales

Nótese que una prueba de concepto puede también formar parte del set de herramientas del desarrollo ágil, pero bajo el entendido que su duración será de un sólo sprint o iteración (2 a 4 semanas). Cuando la solución no pueda implementarse dentro de este periodo de tiempo, primero es necesario desmenuzar el requerimiento (comúnmente denominado como “historia épica”), para posteriormente desarrollar una o varias pruebas de concepto dentro de los límites de tiempo establecidos por el sprint.

También, es importante recordar que una prueba de concepto no nos dice si lo que vamos a hacer es la mejor opción; ésta solamente nos dice si la manera en que abordamos el problema es factible: las POCs tienden a ser muy específicas y concretas; dejando fuera muchas áreas críticas que pueden requerir validación también. Por ejemplo, si estamos evaluando una herramienta de reporteo, una prueba de concepto puede estar enfocada en la generación de algún tipo particular de informe, pero su implementación puede ignorar otra funcionalidad, como la integración de la herramienta con otras aplicaciones, o qué tan personalizables son los reportes generados.

Finalmente, es necesario tomar en cuenta que el diseño de una buena prueba de concepto requeriría una comprensión completa del dominio, ya que es importante identificar por adelantado las diferentes áreas de riesgo, para que éstas sean validadas; en la mayoría de las situaciones esto es imposible, por lo que es muy probable que después de la adopción de alguna solución, el equipo (o peor aún, el cliente) descubra deficiencias en la solución adoptada. Por ello, es necesario sensibilizar al cliente sobre las limitaciones de una prueba de esta naturaleza.

Conclusiones

En el sentido más general, una POC es un prototipo que representa las capacidades o posibilidades técnicas y funcionales de un producto final. Es un modelo a escala que intenta probar que una teoría se puede transformar en una realidad, pero ni nosotros ni el cliente deberíamos esperar a tener la funcionalidad completa. Si bien una prueba de concepto puede ser útil y a veces indispensable, ésta rara vez debe ser vista como la única manera de seleccionar el producto final propuesto: ésta tiene limitaciones y sólo puede proporcionar información que debe ser considerada en combinación con otros factores; así, el propósito principal de la prueba de concepto consiste en proveer certidumbre al respecto de los aspectos básicos de rendimiento y características de un entregable.

h1

¿Qué es la Internet de las Cosas (IoT)?

07/10/2015

Wizdoc [Icon By Buuf]  Tips & Tricks.

La mejor manera de predecir el futuro es creándolo.

Abraham Lincoln (1809 – 1865), decimosexto presidente de los Estados Unidos.

La Internet de las Cosas no es un concepto nuevo. Éste se basa en dos tecnologías que han existido por casi 50 años: la Internet y la comunicación máquina a máquina (Machine to MachineM2M). Lo que realmente ha cambiado las reglas del juego, es cómo estas dos tecnologías se han combinado para crear un paradigma que podría revolucionar al mundo. A continuación mencionamos por qué.

Corría el año de 1959, cuando el Departamento de Defensa de los Estados Unidos encargó a la Universidad de California en Los Ángeles (UCLA), una red de telecomunicaciones que pudiera ser utilizada de manera confiable y segura por todas sus instancias de gobierno, funcionando incluso ante una eventual guerra nuclear. Dicha red, finalmente implementada en 1969, basada en los protocolos TCP/IP y denominada como ARPANET, pasaría a ser parte del dominio público algunas décadas más tarde, extendiendo sus nodos hasta cada rincón del planeta. Ahora la conocemos como Internet, y cerca del 42.4% (2015) de la población mundial está conectada a ella de alguna u otra forma.

Por otro lado, en 1969 el inventor griego Theodore G. Paraskevakos ya había logrado crear un dispositivo que pudiese identificar el número telefónico desde el cual le estaban llamando. Hoy por hoy, esto es conocido como el identificador de llamada entrante o Caller ID, y es ahora considerado como la primera instancia de comunicación máquina a máquina. Con el pasar del tiempo, esta disciplina fue evolucionando hasta adquirir su actual modelo de operación: M2M comprende un dispositivo, tal como un sensor o medidor, que captura un evento (como la temperatura, el nivel de inventario, etc.) que se retransmite a través de una red a un programa de software o aplicación, traduciendo el evento capturado en información significativa. Por ejemplo, artículos que necesitan ser reabastecidos.

Usando este tipo de investigación, en 1982 varios estudiantes de la Universidad Carnegie Mellon conectaron una máquina expendedora de refrescos modificada a la ARPANET, convirtiéndose en el primer dispositivo o appliance en ser conectado a Internet del mundo. La máquina expendedora podía reportar su inventario, así como si las bebidas recién cargadas estaban frías.

Aunque ambas tecnologías ya estaban lo suficientemente maduras para 1987 – año en que las primeras aplicaciones comerciales de M2M basadas en RFID salían a la luz – no fue sino hasta el año de 1999, que el emprendedor británico Kevin Ashton acuñó el término “La Internet de las Cosas” (Internet of Things – IoT): “un sistema en el que la Internet está conectada al mundo físico a través de sensores ubicuos”. Con la aparición de la Web 2.0, la computación en la nube y Big Data, se ha extendido este concepto hasta incluir mucho más que teledetección. En términos simples, IoT predice que una vez que todos los dispositivos se encuentren conectados a Internet, existirán aplicaciones que les permitirán conectarse con los demás objetos a su alrededor, así como otros sistemas y aplicaciones en la nube. Cuando todos ellos actúen al unísono, conformarán una “inteligencia ambiental“. Por ejemplo, podríamos ver un sistema muy complejo, tal como un vuelo internacional, reportando los valores de todos los componentes mecánicos de la aeronave, la lista de pasajeros, inventario de carga e información de ruta, incluyendo aeropuertos de origen y destino, para combinarlos de una manera que optimice costos e incremente la seguridad del vuelo:

La nueva flota de aviones Virgin creará 500 gigabytes de datos en cada vuelo. Así que un vuelo redondo generará 1 Terabyte de información. El director TI para Virgin, David Bulman, espera una explosión de información. Los datos no sólo se generan a partir de fuentes digitales, sino también de ‘entidades’ físicas, como empleados, clientes, aviones y carga. En una entrevista para Computerworld Reino Unido, Bulman citó: “Los últimos aviones que estamos recibiendo, los Boeing 787, están increíblemente conectados. Literalmente, cada pieza de este avión tiene una conexión a Internet: desde los motores, los flaps, hasta el tren de aterrizaje. Si hay un problema con uno de los motores, lo sabremos antes de que aterrice, para asegurarnos de que tenemos las refacciones en el destino. Se está llegando al punto en el que cada parte del avión nos está diciendo lo que está haciendo conforme el vuelo ocurre. Este nivel de percepción operativa implicará la generación de grandes cantidades de datos por cada aeronave.”

Finnegan, Matthew. (2015). “Boeing 787s to create half a terabyte of data per flight, says Virgin Atlantic“. computerworlduk.com.

Todo dispositivo que tenga un sensor estará conectado a Internet, incluyendo los autos, los refrigeradores, las luces en nuestro hogar, e incluso elementos insospechados, tales como nuestros libros, la ropa de cama o las plantas ornamentales:

  • Transporte: Vehículos y sus partes, así como los dispositivos de navegación y rastreo, combinados para resultar en vehículos autónomos como el Google driverless car, rutas de distribución más eficientes, diagnóstico ante fallas mecánicas o “estacionamiento inteligente” (ver abajo), sin la necesidad de dobles filas o esperar a ver qué cajón de estacionamiento se desocupa.
  • Ciudades: Sistemas urbanos, incluyendo redes de energía, agua y drenaje; luces de tráfico y monitoreo de contaminantes. El uso de sistemas inteligentes permitiría una mejor planeación urbana, reducción de contaminantes o mapeo y respuesta rápida ante emergencias. Imaginemos un centro de monitoreo basado en los videojuegos SimCity o Cities:Skylines para darnos una idea de las posibilidades de esta plataforma.
  • Edificios inteligentes: Sistemas de ventilación, cámaras de vigilancia, red eléctrica e integridad estructural que permitan una mejor administración de los recursos del edificio – tales como luz y agua potable – así como incremento en su seguridad.
  • Hogar: Calefacción, detectores de humo, cerraduras, termostatos, artículos para el hogar (televisores, refrigeradores, estufas, lavavajillas, lavadoras) y robots de limpieza trabajando como una sola unidad: para una brillante, aunque algo deprimente representación del funcionamiento de una casa automatizada, basta leer la historia corta Vendrán lluvias suaves (1950), del aclamado escritor estadounidense Ray Bradbury.
  • Salud: Monitores del ritmo cardiaco, implantes, sensores de glucosa, administración de medicamentos. El cuidado de la salud es una de las áreas en las que más información se traduce en una mayor posibilidad de salvar vidas, mediante la prevención, seguimiento y tratamiento de enfermedades.
  • Wearables: Relojes, cámaras, pulseras, lentes, ropa, detectores de movimiento. Un ejemplo salido de la industria del entretenimiento: el MagicBand permite acceder a cualquier atracción encontrada en los parques temáticos de Disney, reemplazando prácticamente cualquier transacción dentro de sus instalaciones, tales como reservaciones y compras, mejorando la experiencia de los huéspedes.

IoT es un paradigma revolucionario porque las tecnologías involucradas (interfaces, dispositivos, redes, sensores, información y software) permiten no sólo detección y reporteo, sino que también es responsable de ejecutar acciones en base a las aportaciones de varios dispositivos, trabajando en conjunto:

Pic: IoT Innovations: Connected Car ~ SAP @ informationisbeautiful.net

Ejemplo de un auto conectado a IoT: estacionamiento inteligente. Si en vez de estar buscando por un lugar de estacionamiento – ¡algunas veces, por hasta 30 minutos! – posteriormente buscar el parquímetro y pagar con cambio, pudiésemos hacer todo esto de forma automática y con la mínima intervención humana posible, el tráfico en las grandes ciudades disminuiría considerablemente, mejorando nuestra productividad y calidad de vida.

(Dar click en imagen o aquí para ver en tamaño original)

(Fuente: informationisbeautiful.net)

A mediados del 2015, existen alrededor de 7 mil millones de dispositivos conectados a Internet; se estima que para el 2020, entre 25 y 30 mil millones de dispositivos estarán conectados, resultando en un fuerte impacto en una gran variedad de sectores económicos: la manufactura, la agricultura y los servicios que formen parte de IoT tendrán un valor de mercado de aproximadamente USD 1.7 billones para el 2020 ($ 1,700,000,000,000), equivalentes a un poco menos del producto interno bruto de Canadá de hoy en día.

Aspectos ingenieriles de IoT

Aunque una descripción detallada de los protocolos y frameworks existentes de IoT está fuera del alcance de este post, vale la pena mencionar que el paradigma ya no sólo se trata de gestionar conexiones TCP/IP: es necesario proporcionar seguridad, confiabilidad, redundancia y por supuesto, interoperabilidad. Primero lo primero: ¿cuál es la arquitectura de IoT? Para que se puedan considerar “conectados”, los dispositivos deben poder comunicarse entre sí (Device to Device – D2D). Luego, los datos capturados por el dispositivo deben ser recogidos y enviados a la infraestructura IT, compuesta principalmente por servidores (Device to Server – D2S). Esa infraestructura tiene que compartir los datos del dispositivo entre los servidores que la componen (Servier to Server – S2S), para posteriormente proporcionar información de regreso a los dispositivos, a los programas de análisis, o los dispositivos móviles que forman parte de la arquitectura. A grandes razgos, toda la plataforma puede verse así:

Pic: Framework of the IoT support system. ~ ZTE

Concepto de sistema de soporte o arquitectura de IoT: [Éste] consta de cuatro capas: la capa de detección, la capa de transporte de red, la capa de operación y gestión, y la capa de aplicación. La capa de detección consiste de una red inalámbrica de sensores (Wireless Sensor Network – WSN), lectores de RFID y terminales M2M. La capa de transporte de red contiene varias subredes (GSM, CDMA, 3G y de línea fija) ofrecidas por los operadores para la transferencia de información entre la capa de detección y la capa de aplicación. La capa de operación y gestión incluye la plataforma de apoyo a la operación, así como el ambiente en el que reside el Sistema de Apoyo a la Operación de Negocios (Business Operation Support System – BOSS). Al hacer uso de protocolos estándar, la plataforma de apoyo a la operación puede tener acceso a las terminales y aplicaciones, proporcionando funcionalidad como autenticación, facturación, gestión de servicios y aceptación del servicio, de modo que los operadores pueden gestionar aplicaciones de IoT de manera unificada. La capa de aplicación contiene un número de aplicaciones industriales que llaman a diferentes funcionalidades de los servicios a través de la plataforma de soporte de operaciones, con el fin de satisfacer las necesidades de servicio.

(Dar click en imagen o aquí para ver en tamaño original)

(Fuente de imagen y pie de página: zte.com.cn)

Por otro lado, los protocolos que controlan cómo un dispositivo transmite y recibe datos pueden ser un componente crítico a la hora de gestionar el resto de sus recursos. Sin entrar en demasiado detalle, los protocolos que forman parte de IoT se describen a continuación:

  • MQTT (Message Queue Telemetry Transport): Usado para recolectar la información capturada por el dispositivo y comunicarla a la infraestructura IT (D2S).
  • XMPP (eXtensible Messaging and Presence Protocol): Utilizado para conectar los dispositivos a las personas; basado en XML es un tipo especial de D2S ya que a final de cuentas, se conecta a los servidores.
  • DDS (Data Distribution Service): Un bus de datos utilizado para integrar dispositivos entre sí (D2D).
  • AMQP (Advanced Message Queuing Protocol): Un sistema de encolado utilizado para conectar servidores entre sí (S2S).

Retos

No todo es miel sobre hojuelas. IoT enfrenta grandes retos, los cuales determinarán durante los próximos años si ésta se convertirá en una exitosa estrategia de crecimiento tecnológico global o una rama relativamente importante de M2M, aunque sólo dirigida a nichos de mercado específicos:

  • Falta de estándares: La falta de estándares abiertos es un problema a nivel institucional dentro de IoT. Por ejemplo, el Internet Engineering Task Force (IETF) incorpora las aportaciones de múltiples interesados, incluyendo una combinación de responsables de políticas, capitanes de industria e ingenieros para formular el marco de desarrollo futuro para Internet. No existe tal organización para IoT, a pesar de que la tecnología toma prestados tanto el hardware como las prácticas de desarrollo de la Internet. La consolidación y competencia futuras podrían degenerar en otra guerra de estándares, como las ya famosas VHS vs. Betamax, o iOS vs. Android.
  • Privacidad y seguridad: En el ejemplo del automóvil conectado a IoT de más arriba, es necesario contar con diferentes proveedores de servicios trabajando al mismo tiempo para alcanzar un fin común: en este caso, encontrar y pagar por un cajón de estacionamiento. Es necesario enviar por la red información privada; mínimamente las placas del automóvil, así como la cuenta de la que se sustraerá el pago por el espacio. En caso de presentarse una falla de seguridad – un posible hackeo o robo de información personal – ¿Quién habría sido el responsable de salvaguardar esta información?
  • Complejidad de diseño y pruebas: Debido a que IoT implica interacciones entre una gran variedad de sensores, es muy complicado realizar el diseño correcto y pruebas correspondientes de una nueva aplicación, lo que limita el ingreso a sólo las compañías que pueden pagar por extensas pruebas y depuración. ¿Cuál fue el costo de conceptualizar, diseñar, implementar y depurar el sistema de MagicBands mencionado más arriba? La no-tan-despreciable cantidad de 1,000 millones de dólares – una inversión considerable incluso para Disney, pues representa 8% de sus ingresos brutos anuales.

Conclusiones

La Internet de las cosas se está convirtiendo en un tema de conversación cada vez más importante, tanto en el lugar de trabajo como fuera de él. Es un concepto que no sólo tiene el potencial de afectar la forma en que trabajamos, hacemos negocios o vivimos; ésta puede mejorar exponencialmente nuestra eficiencia, así como reducir desperdicios de tiempo, dinero y recursos. Sin embargo, así como IoT puede abrir muchas posibilidades, también ésta debe solventar muchos retos. Por ejemplo, la seguridad es uno de los obstáculos más importantes que han detenido la implementación generalizada de este paradigma: Con miles de millones de dispositivos conectados e interactuando conjuntamente, ¿qué debería hacerse para mantener segura la información personal? Después de todo, existe la posibilidad de que alguien llegue a hackear nuestro refrigerador, obteniendo acceso a toda nuestra red. Y si en la actualidad las empresas de todo el mundo están sujetas a constantes ataques a su seguridad – muchas veces, gestionados por gobiernos de naciones rivales – ¿cómo podemos asegurar nuestra privacidad e intercambio de datos seguro? Justo hace un par de días, hackers todavía sin identificar fueron capaces de colarse en una batería alemana de misiles tierra-aire…

Sin importar qué camino llegue a tomar la Internet de las cosas, es innegable que eventualmente tendrá un profundo impacto en nuestras vidas, de la misma forma en que los dispositivos móviles lo hicieron hace algunos años, o la TV y las computadoras lo hicieron con nuestros padres y abuelos desde hace algunas décadas.

h1

Automatización de pruebas: una introducción

12/19/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

“f u cn rd ths, u cn gt a gd jb n sftwr tstng.”

El año se está terminando, y en México el puente Guadalupe-Reyes prácticamente significa el cierre de este 2014. Sin embargo, en vez de decir “estamos hechos; nos vemos en 2015”, todavía salen detalles aquí y allá en el trabajo que nos impiden relajarnos completamente: somos víctimas de una importante rotación de personal así como fechas de liberación, seguidas de un freeze. Aunque algunos recursos dejen la empresa, ciertos entregables deben estar terminados durante el transcurso de las próximas dos semanas.

Nuestro Coco es el proceso de pruebas, que para algunos proyectos debe llevarse a cabo de forma enteramente manual, lo que ha resultado en una ardua labor por parte de los testers y hasta de los mismos desarrolladores. Sin embargo, de momento no hay mucho que podamos hacer para cambiar esta situación, pues el ambiente sobre el que estamos trabajando es enteramente del cliente, y ya que aquél cerró su ciclo fiscal hace poco menos de un mes, ya no dispone del presupuesto necesario para adquirir una suite de pruebas automatizadas que permitan aligerar la carga de trabajo, al menos en lo que resta del año.

Aplicando un poco de pensamiento crítico, ¿acaso las pruebas automatizadas son tan buenas como dicen? ¿No será más práctico emplear a un ejército de testers que adquirir una herramienta? ¡Yo tenía la idea de que con JUnit y TDD es más que suficiente! ¿Qué consideraciones deberemos tomar si nos decidimos por el camino de la automatización? Es así como presento una pequeña introducción a la automatización de pruebas y algunos consejos para no dejarnos engañar por herramientas que se autodescriben como el non plus ultra, apoyando a tomar una decisión racional con respecto a una actividad que de forma ideal debería tomar el 20-25% del tiempo total necesario para generar un entregable técnico.

Algunas ideas erróneas sobre el automated testing

Primero que nada, es necesario aclarar ciertas falacias que han plagado la industria por años, gracias a elaborados trucos de marketing. En el excelente artículo Test Automation Snake Oil (con un título equivalente a “El fraude de la automatización de pruebas”) el autor e ingeniero de software James Bach describe algunos “supuestos peligrosos” que nos pueden llevar al desastre:

  • Las pruebas consisten en una secuencia de acciones. Una manera más útil de pensar en las pruebas es como una secuencia de interacciones entremezclada con evaluaciones; algunas son predecibles y objetivas, mientras otras son complejas, ambiguas y volátiles.
  • Una prueba significa repetir las mismas acciones una y otra vez. La variabilidad es una de las grandes ventajas de las pruebas manuales.
  • Podemos automatizar acciones de prueba. Probablemente la parte más difícil de la automatización es interpretar los resultados de la prueba, separando anomalías inofensivas de problemas graves. Un ejemplo clásico es el error de división del Intel Pentium.
  • Una prueba automatizada es más rápida ya que no necesita ninguna intervención humana. Todas las suites de pruebas automatizadas requieren de intervención humana, aunque sólo sea para diagnosticar los resultados y corregir pruebas erróneas.
  • La automatización reduce el error humano. Sí, se reducen algunos errores. Aquellos que los seres humanos hacen cuando se les pide llevar a cabo una larga lista de actividades mentales y táctiles aburridas. Pero otros errores se amplifican.
  • Podemos cuantificar los costos y beneficios de las pruebas automatizadas vs. manuales. La realidad es que las pruebas manuales y las pruebas automatizadas son dos procesos diferentes, en lugar de dos maneras diferentes para ejecutar el mismo proceso.
  • La automatización conducirá a un “importante ahorro en costos laborales”. Los costos de desarrollo de la automatización, de operación de las pruebas automatizadas, del mantenimiento de la automatización conforme el producto cambia y de cualquier otra tarea que es requerida por la automatización, deben sopesarse contra los costos de diseño, configuración e implementación de pruebas manuales. Usualmente la automatización resulta ser más costosa.
  • La automatización no dañará el proyecto de prueba. Ciertamente, es peligroso automatizar algo que no entendemos. Si no tenemos una clara estrategia de pruebas antes de la introducción de la automatización, el resultado será una gran masa de código de prueba que nadie entiende completamente.

Siendo así las cosas, la automatización se define como una técnica que facilita las labores repetitivas, liberando a los testers de actividades tediosas para permitirles concentrarse en lo que verdaderamente importa: la funcionalidad de negocio que el usuario espera.

Automatizando

Los testers son percibidos con frecuencia como los cuellos de botella durante la entrega de productos de software. Así, se les exige probar más y más código en cada vez menos tiempo. Por otro lado, conforme diferentes versiones de un código son liberadas, la nueva funcionalidad debe probarse en conjunto con las características previamente existentes, por lo que el ciclo de pruebas tiende a volverse cada vez más lento. Hoy por hoy, ya existen herramientas que permiten reducir los tiempos de prueba mediante una interfaz gráfica de usuario, mientras otras herramientas facilitan la ejecución de pruebas de desempeño – que anteriormente tenían que implementarse mediante un ejército de testers simulando los usuarios de una aplicación.

En un intento de hacer más con menos, no hay más remedio que usar estas herramientas en los proyectos. La automatización de pruebas consiste en el uso de herramientas de software especializadas que permiten controlar la ejecución de pruebas, comparación de resultados reales contra resultados previstos, creación de las condiciones previas para la ejecución de pruebas, así como otras funciones de control y presentación de reportes. Comúnmente, la automatización de pruebas busca automatizar procesos manuales y repetitivos ya existentes que siguen una metodología de pruebas formal. La mayoría de las herramientas de prueba pueden ayudar a automatizar tareas como la instalación del producto, creación de datos de prueba e interacción con la interfaz de usuario; el objetivo principal consiste en simplificar las pruebas de regresión: es decir, se genera un repositorio de casos de prueba detallados que son repetibles y que se ejecutan en su conjunto cada vez que haya un cambio en la aplicación. Esto se hace para asegurar que ningún cambio traiga consecuencias imprevistas. Es importante recalcar que la automatización de pruebas es algo caro y debe considerársele como un complemento – no un reemplazo – de las pruebas manuales. Sólo a largo plazo o en productos de software con ciclos de mantenimiento muy extensos puede llegar a ser más rentable que trabajar con grupos de testers dedicados.

Pros y Contras

No todo es miel sobre hojuelas, sin embargo. Previo a adoptar una herramienta de automatización de pruebas es necesario tomar en consideración que el verdadero costo de la automatización se mide por el número de pruebas manuales que no estamos ejecutando y por lo tanto, el número de incidencias o bugs que estamos dejando pasar. Eventualmente, la decisión entre automatizar o seguir procesos manuales deberá llevarse a cabo contestando las siguientes preguntas: ¿Si automatizo esta prueba, qué pruebas manuales puedo perder? ¿Cuántos errores de usuario pueden escaparse al no ejecutar dichas pruebas? ¿Cuál será su severidad? De acuerdo al ingeniero de pruebas y autor Brian Marick:

Una prueba está diseñada para un propósito determinado: revisar si algunos aspectos de una o más características funcionan. Cuando una prueba automatizada detecta incidencias, deberías asumir que encontrarás errores que parecen no tener nada que ver con el propósito original de la prueba. Gran parte del valor de una prueba automatizada radica en lo bien que se puede hacer eso.

Marick, Brian. (1998). “When Should a Test Be Automated?” uml.org.cn.

En caso de decidirse por la automatización, deben incluirse medidas para investigar si la incorporación de dicha herramienta será beneficiosa para el proyecto, teniendo en cuenta los requisitos de prueba, ambiente de pruebas disponible, personal capacitado, entorno de usuario, plataforma del proyecto, así como las características de la aplicación a ser validada. También es importante realizar las estimaciones y modificación correspondiente al plan de proyecto para garantizar el tiempo mínimo indispensable para la instalación de la herramienta, así como la jerarquía de requerimientos; es necesario realizar pruebas de concepto (Proof of Concept – PoC) con las potenciales herramientas y utilerías de prueba, validando la compatibilidad con el ambiente aplicativo y buscando soluciones alternativas a problemas de incompatibilidad que surjan durante esta PoC. En términos generales, algunos de los pros y contras de adoptar herramientas de automatización de pruebas serían los siguientes:

Pros:

  • Si es necesario ejecutar una serie de pruebas en múltiples ocasiones, para un gran número de usuarios.
  • Código que cambia con frecuencia, buscando detectar regresiones en el momento oportuno.
  • Ejecutar pruebas durante los escenarios principales para detectar regresiones de forma periódica. Por ejemplo: en un build nocturno o nightly build.
  • Matriz de pruebas de grandes dimensiones, como un producto destinado a diferentes idiomas en plataformas y sistemas operativos diversos.
  • Ejecución en paralelo sobre diferentes máquinas – mientras que las pruebas manuales tendrían que ejecutarse secuencialmente.

Contras:

  • La automatización es demasiado costosa (tiempo y/o presupuesto). Escribir los casos de prueba y configurar la herramienta siempre es más costoso al principio que correr las pruebas de forma manual.
  • No se pueden automatizar referencias visuales. Por ejemplo, si la herramienta no permite detectar el tipo de letra o color, será necesaria una prueba manual.
  • No se pueden automatizar pruebas al azar, por lo que es imposible detectar verdaderos errores de usuario.
  • Ambientes complejos donde una herramienta no sea suficiente para probar la aplicación en su conjunto. Por ejemplo, aplicaciones multiplataforma.

Conclusiones

La automatización puede ofrecer grandes beneficios, siempre y cuando recordemos que “testing” no sólo significa probar lo mismo una y otra vez hasta el cansancio: éste implica evaluar los resultados de acuerdo a diferentes entradas y concentrarse en aquellas incidencias que restan valor agregado al cliente. Luego, tenemos que ser muy cuidadosos con el tipo de herramienta que utilizaremos, pues ninguna de las herramientas encontradas en el mercado actual hará el trabajo por nosotros. Finalmente, es importante tener una clara idea de qué tareas puede simplificar y la utilicemos como un complemento de las pruebas manuales, ya que:

Un tonto con una herramienta sigue siendo un tonto.

Grady Booch (n. 1955), ingeniero de software estadounidense, co-autor del Lenguaje Unificado de Modelado (UML).

h1

Las herramientas y tecnologías más usadas en Java

11/29/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

El aprendiz evita todo uso de clases en Java. El profesional, acepta las clases de Java. El maestro sabe qué clases aprovechar y cuáles evitar.

— Michael Fogus, programador y escritor Estadounidense. Autor del libro The Joy of Clojure.

Regularmente, un proyecto desarrollado en el lenguaje de programación Java incluye librerías de terceros. Esto ocurre porque en estricta teoría, los APIs del core del lenguaje poseen toda la funcionalidad que necesitamos, mientras que en realidad, generar este middleware por nuestra cuenta requiere demasiado esfuerzo, por lo que podemos minimizar esta tarea con la ayuda de librerías que nos permiten enfocarnos en lo que realmente importa: la lógica de negocio. Así, desde las tareas tan pedestres como los logs, hasta las más esotéricas como el procesamiento de lenguaje natural, tenemos a nuestra disposición un sinfín de herramientas y frameworks generados por otros desarrolladores que nos permitirán resolver el problema en cuestión sin necesidad de reinventar la rueda. Por otro lado, con el explosivo crecimiento de Java y las plataformas que la componen, incluyendo desktop, web y móvil, existen literalmente cientos de librerías para una misma función que pueden generarnos ansiedad por indecisión, porque debemos elegir entre frameworks “de moda” – los que pueden impresionar a los clientes, cerrando un trato – y aquellas herramientas que ya son consideradas maduras y por lo tanto, “aburridas”. Esto es razonable, ya que el éxito o fracaso de un proyecto desde el punto de vista técnico se debe en gran medida al uso de tecnologías inmaduras o aquellas que tienen una pronunciada curva de aprendizaje.

Así entonces, hace algún tiempo se publicaron dos análisis que describen las herramientas y frameworks más utilizados por la comunidad Java. El primero fue generado por el staff de Takipi, un startup que ha basado su estudio en las estadísticas que arrojaron más de 10,000 proyectos de Java hosteados en GitHub. El segundo fue desarrollado por ZeroTurnaround, otra compañía que realizó su análisis a través de encuestas publicadas en el reconocido sitio The Server Side. Los resultados se muestran a continuación:

Pic: Tools & Tech - 1 of 2
Pic: Tools & Tech - 2 of 2

Herramientas y tecnologías más comunes en la comunidad Java. En la gráfica se muestra el porcentaje de proyectos en los que los desarrolladores han utilizado una tecnología específica, de acuerdo a su categoría.

A partir de estos números, obtenemos algunos hallazgos interesantes:

• En este momento, la versión de Java más usada es la 6, publicada en Diciembre de 2006. Puesto que la versión 5 tiene poco más de 9 años de existencia (Septiembre 2004) y la versión 7 apenas tiene un par de años de haber sido liberada (Julio 2011), estos porcentajes proporcionan el tiempo aproximado para que una versión de Java se generalice: 3 años y 4 meses.

• Debido a su tremenda potencia, relativa facilidad de aprendizaje y extensa documentación, Eclipse, Maven, Ant, Jenkins/Hudson, Subversion, SLF4J, Spring, Hibernate y JUnit se han vuelto los estándares de facto en la industria, al grado en que no existen implementaciones de Java que no usen alguno de estos frameworks y herramientas.

• Adicionalmente, Spring MVC y Java Server Faces se han convertido en los frameworks de mayor uso para cualquier implementación web. Apache Struts sigue apareciendo entre los primeros lugares, aunque no está claro cuál de las dos versiones es la más popular. Lamentablemente, otros frameworks como Wicket o Tapestry – que personalmente me parecen mucho más accesibles que JSF o Struts – se han quedado rezagados.

• En cuanto a los servidores de aplicaciones, vale la pena mencionar cómo Tomcat está presente en casi cualquier despliegue web, mientras JBoss es el “servidor empresarial” con mayor uso por la comunidad. Por otro lado, vemos cómo los millones de dólares que respaldan a los servidores de aplicaciones comerciales no han servido de mucho para incrementar su participación. Sin embargo, esto es sólo relativo, ya que con frecuencia, Tomcat y Jetty son utilizados para ambientes de desarrollo, mientras el servidor en el que se deja la producción termina siendo un Websphere o un Weblogic.

• Finalmente, de acuerdo a las estadísticas, el desarrollo orientado a pruebas está cambiando la manera de hacer los proyectos, con casi uno de cada tres utilizando JUnit: Ahora, las pruebas unitarias ya son prácticamente un requerimiento que nosotros como desarrolladores debemos conocer y saber cómo llevar a cabo.

Conclusiones

Los resultados pueden no ser sorprendentes, pero son un buen punto de referencia para saber hacia dónde se está dirigiendo Java, mientras que para los desarrolladores novatos éstos pueden servir como guía para conocer qué frameworks y herramientas deben dominar si quieren ser competitivos en el ambiente laboral presente. Adicionalmente, podemos darnos cuenta que con muy marcadas excepciones, el desarrollo en Java depende casi exclusivamente de iniciativas open source, lo que ciertamente democratiza esta disciplina, evitando que un sólo jugador sea el que defina el futuro de la especialidad, tal como aquella otra tecnología que opera bajo el (poco ético) lema de “adoptar, extender y extinguir“.

h1

Implementando Scrum: un caso de la vida real (Parte 1)

07/05/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

El éxito no es definitivo; el fracaso no es fatal: lo que cuenta es el coraje para continuar.

Winston Churchill (1874-1965), político y estadista británico.

Ahora que ya tenemos un par de meses implementando Scrum con un cliente relativamente inexperto en esta metodología, nos hemos llevado un par de chascos que seguramente pueden ocurrir en cualquier implementación donde no exista una definición concreta de expectativas, cuáles son sus procesos y artefactos, o aquellos que ejecutan el desarrollo no cuentan con los skills necesarios.

Pero empecemos por el principio: de entre cinco células ágiles, un equipo de desarrollo en Java “falló espectacularmente” de acuerdo al cliente. Esto provocó alerta entre nuestro “high management”, ya que el incidente puso en duda nuestra capacidad para trabajar con Scrum así como para generar los entregables de alta calidad que nos fueron solicitados. Aunque al principio esto se achacó a falta de conocimiento en los procesos ágiles, elaboramos un RCA en el que encontramos la verdadera causa del problema:

• Primero, el cliente se acercó a nuestra empresa solicitando células de desarrollo ágil. Inicialmente, pidió dos de “altísima urgencia”, advirtiéndonos que si no se conformaban e iniciaban los trabajos inmediatamente, encomendaría el proyecto a alguien más. Esto claramente fue para presionarnos, pues hasta la fecha, NO existe otro proveedor que esté ofreciendo este tipo de servicio a nuestro cliente.

• Luego, lo que el cliente solicitó fueron “células en Java y .Net”. Ni más ni menos. El requerimiento no incluyó un conjunto de tecnologías o perfiles específicos, ni en qué tipo de proyecto se estaría trabajando. Esto, aunado a la presión por iniciar de inmediato, significó que nuestra área de reclutamiento se limitó a buscar candidatos genéricos: “Hola, soy de la empresa X. ¿Sabes Java o .Net? ¿Sí? Te espero mañana para firma de contrato.” En el equipo .Net tuvimos muchísima suerte de contar con un desarrollador que ya conocía el tipo de arquitectura a implementar (Model-View-View-Model). En el equipo Java no tuvimos tanta suerte, pues el proyecto no sólo consistía en conocer el core del lenguaje, sino también en dominar una variada multitud de frameworks, herramientas y tecnologías como Spring, Hibernate, Websphere, JPA, JAX-WS o JSF.

Toy Stories: Noel (Texas, USA) ~ Gabriele Galimberti


Stack Tecnológico del equipo original. Como puede apreciarse en la tabla, las habilidades prácticas de las personas tendían a medio o bajo – sólo 16% de la experiencia podía ser considerada como “alta”. Sin un liderazgo técnico adecuado, el equipo estaba condenado desde un principio. (Dar click en imagen o aquí para ver a mayor escala)

• Dos semanas después de iniciado el delivery nos dimos cuenta que los skills requeridos eran muy especializados, ya que el proyecto se trata de implementar un SOA con todo y web services, flujos de trabajo, validaciones de negocio y colaboración constante con otros proveedores. Es decir, aparte de no contar con las habilidades necesarias para realizar su tarea, la gente tampoco tenía el “colmillo” para defenderse ante los demás proveedores o el mismo cliente, pues a la primera oportunidad, culparon de cualquier retraso a nuestro equipo.

• Después de otro par de semanas, tuvimos que cambiar de líder técnico y Scrum Master. ¿La razón? No supieron hacer “click” con el responsable del lado del cliente o Product Owner (PO), quien además de ser una persona bastante difícil de tratar, también tiene altos skills técnicos y funcionales – el típico “YO lo haría en dos horas. ¿Por qué TÚ vas a tardar un día en hacerlo?” Esto acentuó los problemas con el equipo, quienes presenciaban constantes discusiones a nivel técnico y administrativo con este personaje, además que se desmoralizaron al ver cómo sus líderes dejaban el proyecto con las piernas por delante.

• En la iteración tres ocurrió el desastre. Teniendo que entregar cuatro web services, el líder técnico cometió el error de “entrar al ruedo”, programando uno de éstos, pero desatendiendo el avance de los desarrolladores. Por otro lado, el Scrum Master no tomó suficiente ownership del equipo, pues cuando preguntaba “¿Cómo vas?” todos respondían “Bien”, sin que éste indagara más al respecto. Lo triste del asunto es que en realidad no iban nada bien – de hecho, algunos jamás probaron su código. Este exceso de confianza hacia los desarrolladores significó el principio del fin, ya que como cereza del pastel, nuestro tester jamás hizo las pruebas correspondientes sobre el código “terminado”.

• Durante la demostración al final del Sprint, todo reventó en nuestras manos: algunos desarrolladores sólo probaron en sus laptops; otros jamás probaron en absoluto. Sin embargo, nadie probó en el ambiente del cliente, así que durante la revisión de la demo, nada funcionó. El cliente, enfurecido, nos dijo que a partir de ese momento, su propia gente desarrollaría estos web services. Por lo pronto, esta célula estaba cancelada.

Y es así como hemos estado la última semana y media tratando de “salvar el honor”, pues aunque sabemos que el cliente ya está desarrollando los componentes por su cuenta, nosotros tenemos que entregar algo funcional para solicitar el pago por estas semanas de trabajo. A raíz de este incidente, hemos podido generar un plan de acción con el afán de que esto no se vuelva a repetir en el resto de las células, incluyendo controles para asegurar la efectividad de todos nosotros:

• Desde un inicio, contar con los recursos adecuados. Ahora, en las células nuevas, primero se presenta un líder técnico que “mide las aguas” para obtener el stack tecnológico y los perfiles requeridos. Posteriormente, dicho líder debe estar presente durante el proceso de reclutamiento, ya que la mejor manera de asegurar un buen recurso es contestando afirmativamente la pregunta: “si esta persona va a estar bajo mi responsabilidad, ¿me conviene traerlo a bordo?”

• Por otro lado, es necesario mejorar el liderazgo, pues no se ha dado una comunicación efectiva entre en líder técnico y el Scrum Master, además de que ha faltado ownership por parte de ambos. Básicamente, evitar la práctica de estarse pasando el mono.

• El cliente tiene un conocimiento muy bajo en metodologías ágiles. Es decir, ellos sólo recibieron el curso de dos días para convertirse en Scrum Master. Por ello, es necesario crear un par de workshops: el primero dirigido hacia los POs para que conozcan cuál es la verdadera función de un Product Owner y cuáles son las expectativas y entregables que deben estar manejando con el resto del equipo; el segundo debe estar dirigido hacia los ejecutivos del cliente (gerentes y directores) para que se den cuenta que ágil no es la “bala de plata”, al mismo tiempo que mostramos cuáles son las métricas con las que nos deberían estar midiendo, pues algunos entregables que nos están solicitando como “reportes de horas” y “cartas de aceptación” son algunos esquemas de control que se contraponen a la ideología de ágil.

• Finalmente, darnos cuenta que este problema no se debió a falta de conocimiento en ágil, sino a temas más pedestres como poco ownership, un líder técnico que quiso ser héroe, exceso de confianza entre el Scrum Master, el líder y el equipo así como poca experiencia por parte del equipo, puntualmente en el proceso de desarrollo de software (SDLC), y sus disciplinas más importantes, como integración continua, refactoring y pruebas de concepto. De hecho, el cliente mismo mencionó que el problema no era Scrum, sino los skills, actitud y experiencia de la gente. Después de todo, código entregado sin haber sido probado es un tema preocupante que no tiene que ver con conocimiento en (o la falta de) Scrum. Por ello estamos reforzando el proceso SDLC a través de dos expertos, uno en Java y uno en .Net, quienes asegurarán el correcto seguimiento de las prácticas de desarrollo ágil a través de las herramientas y procesos más adecuados.

De momento, sólo hemos visto un pequeño ejemplo de lo que puede pasar durante una implementación de ágil en un ambiente inmaduro. En el próximo post veremos que Scrum “de la vida real” no sólo consiste en leer los papeles de Ken Schwaber y esperar lo mejor: la realidad es que es necesario contar con el apoyo de una buena gestión de proyectos, un governance bien estructurado y hasta que no estemos seguros que el proceso está siendo seguido por todos los involucrados, deben existir algunos puntos de control para asegurar que todo marcha sobre ruedas.

h1

Los comentarios más chuscos encontrados en el código fuente

05/23/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

Los programas deben escribirse para que la gente los lea, y sólo incidentalmente para que las máquinas los ejecuten.

Hal Abelson (n. 1947), profesor y codirector estadounidense del Instituto Tecnológico de Massachusetts (MIT), cofundador de Creative Commons.

Hace algún tiempo, en el sitio técnico Stack Overflow apareció un hilo de discusión que decía: ¿Cuál es el mejor comentario en el código fuente que has encontrado? Aunque sale por completo de los temas que normalmente tratan en dicho sitio, la pregunta tuvo una respuesta de tal magnitud, que uno de los administradores tuvo que bloquear el hilo para evitar que éste dejara a sus servidores fuera de combate. Honestamente, en la actualidad se le conserva más por el enorme tráfico que origina, que por las “razones históricas” que justifican su permanencia entre preguntas más valiosas, aunque menos populares. Sin embargo, recomiendo mucho leer este hilo de discusión, porque nos permite entrar en la psique de aquellos valerosos programadores que cayeron en el cumplimiento del deber:

// if i ever see this again i’m going to start bringing guns to work

Traducción: Si veo esto de nuevo voy a empezar a traer armas al trabajo.

/**
For the brave souls who get this far: You are the chosen ones,
the valiant knights of programming who toil away, without rest,
fixing our most awful code. To you, true saviors, kings of men,
I say this: never gonna give you up, never gonna let you down,
never gonna run around and desert you. Never gonna make you cry,
never gonna say goodbye. Never gonna tell a lie and hurt you.
*/

Traducción: Para las almas valientes que han llegado hasta aquí: Ustedes son los elegidos, los caballeros valerosos de la programación que trabajan duro, sin descanso, corrigiendo nuestro terrible código. A ustedes, verdaderos salvadores, reyes de los hombres, les digo esto: (letra de la canción Never Gonna Give You Up de Rick Astley; efectivamente aplicándole al lector un Rickroll).

// I dedicate all this code, all my work, to my wife, Darlene, who will
// have to support me and our three children and the dog once it gets
// released into the public.

Traducción: Dedico todo este código, todo mi trabajo, a mi esposa Darlene, quien tendrá que mantenernos a mí, a nuestros tres hijos y al perro una vez que esto sea liberado al público.

try {
  …
} catch (Exception e) {
  //silent as a ninja
}

Traducción: Silencioso como un ninja.

// Dear maintainer:
//
// Once you are done trying to ‘optimize’ this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 16

Traducción: Querido encargado (de mantenimiento): Cuando hayas terminado de intentar “optimizar” esta rutina y te hayas dado cuenta del terrible error que esto significa, por favor incrementa el siguiente contador como aviso al tipo que venga después de ti: total_horas_desperdiciadas = 16

// I will give you two of my seventy-two virgins if you can fix this.

Traducción: Te daré dos de mis setenta y dos vírgenes si logras arreglar esto.

//Dear future me. Please forgive me.
//I can’t even begin to express how sorry I am.

Traducción: Querido yo del futuro. Por favor perdóname. Ni siquiera puedo empezar a expresar cuánto lo siento.

// If you’re reading this, that means you have been put in charge of my previous project.
// I am so, so sorry for you. God speed.

Traducción: Si estás leyendo esto, significa que te han puesto a cargo de mi anterior proyecto. Lo siento mucho por ti. Buena suerte.

/**
* If you don’t understand this code, you should be flipping burgers instead.
*/

Traducción: Si no entiendes este código, deberías estar volteando hamburguesas en su lugar.

try {
  …
}
catch (SQLException ex) {
  // Basically, without saying too much, you’re screwed. Royally and totally.
}
catch(Exception ex)
{
  //If you thought you were screwed before, boy have I news for you!!!
}

Traducción 1: Básicamente, sin decir mucho, estas jodido. Real y totalmente.

Traducción 2: Si antes pensabas que estabas jodido, oh muchacho, tengo noticias para ti!!!

Dependiendo de la situación en la que nos encontremos, estas joyas de comicidad ingenieril pueden hacernos recordar esos duros momentos en que la noche era larga y el café, barato.