Archive for the ‘Informática e Internet’ Category

h1

Suites de Gestion de Procesos de Negocio de Codigo Abierto: el caso Mexicano

03/28/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

[Se ha estimado] que el proceso de negocio como servicio (BPaaS) y el mercado de BPM en la nube crecerán en valor desde USD 1 mil millones en 2013 hasta 7,120 millones de dólares en 2018.

The next evolution of BPM. Lance Harris. (Business Technology News and Information, 2013).

Hace algunas semanas nuestro country head me encargó encontrar los BPMS (Business Process Management SuitesSuites de Gestión de Procesos de Negocio) de mayor uso en México, y si entre éstos existe una opción basada en código abierto lo suficientemente competitiva como para incluirla dentro de nuestra oferta de servicios. Los resultados se obtuvieron en su mayoría a partir de información encontrada libremente en la web, por lo que me es posible compartir una buena parte de éstos:

Esta investigación presenta las opciones más utilizadas para el software de código abierto con respecto a Business Process Management Suites (BPMS) en México. Los resultados se presentan tomando en cuenta que el software BPMS es poco utilizado en México y el resto de América Latina. El conjunto de opciones mostradas a continuación está pensado principalmente con la finalidad de fomentar la evaluación de opciones de código abierto durante la generación de nuestras propuestas de solución y servicios. Se entiende que el mercado de software, especialmente la rama de código abierto, es un entorno de desarrollo muy dinámico y las opciones que figuran en este documento pueden quedar obsoletas rápidamente. Aun así, esta lista tiene como objetivo ser de utilidad para los clientes potenciales que consideren el código abierto como una opción, y para ayudar a darle mayor credibilidad y seguridad a nuestras propuestas.

Contexto

Típicamente, los beneficios del software de código abierto incluyen precios más bajos de adquisición, bajos o nulos costes de licencia, interoperabilidad, así como integración y personalización fácil de implementar; menos barreras para la reutilización, conformidad con los estándares abiertos de tecnología y datos que dan autonomía sobre su propia información. Finalmente, proporciona la posibilidad de no tener que “casarse” con un proveedor determinado.

El código abierto es poco o en absoluto utilizado en las organizaciones mexicanas de gran tamaño. Los integradores de sistemas y fabricantes no consideran al software de código abierto para sus soluciones de TI. Esto se puede demostrar en el Cuadrante Mágico de Gartner para BPMS (2010):

pic: Magic Quadrant for Business Management Suites (Oct 2010)

Cuadrante Mágico de Gartner para suites de gestión de procesos de negocio (Octubre 2010). (Fuente: avoka.com)

De entre 27 opciones diferentes, sólo una (Intalio) es de código abierto. Éste cae dentro del grupo de visionarios.

Hay importantes obstáculos al código abierto en México. Algunos de ellos incluyen una falta de una orientación clara para su adquisición, resistencia por parte de los proveedores, preocupaciones sobre las obligaciones de licenciamiento y – desde que el TLCAN comenzó su existencia hace más de 20 años – el tema de las patentes, malos entendidos acerca del proceso de acreditación de seguridad y mitos alrededor de la calidad y el soporte técnico del código abierto.

Cómo interpretar este documento

Este documento presenta el software de código abierto para ser considerado en nuevas soluciones BPM que cumplan con los requerimientos del negocio, o como sustitutos de software propietario ya existente. Se ofrecen varias opciones sobre la base de las implementaciones ya liberadas en el mercado mexicano hasta marzo de 2014. Este conjunto de opciones se puede utilizar para:

• Informar durante el diseño de nuevas soluciones de TI.

• Sugerir oportunidades de TI de servicios o soluciones nuevas.

• Retar propuestas de solución que no utilicen las tecnologías de código abierto.

El criterio general para que un software de código abierto sea listado entre las opciones sugeridas es que debe existir una oportunidad real para su uso. Un uso significativo y probado es un factor clave, en el que “probado” puede significar:

• Uso a gran escala, volumen o en escenarios de alto rendimiento.

• Uso en funciones críticas, tales como salud o seguridad.

• Historial de uso, de preferencia durante muchos años.

Uso de los BPMS

La mayoría de los proveedores de BPMS proporcionan análisis de procesos, diseño y herramientas de modelado de flujos de trabajo dentro de sus suites.
Por otro lado, la mayoría de las organizaciones optan por invertir en BPMS porque necesitan apoyo para un programa de mejora continua de procesos, el apoyo a un proyecto de transformación de negocios, y/o el middleware necesario para implementar una arquitectura orientada a servicios (SOA). Las organizaciones también pueden buscar adoptar un BPMS para guiar el proceso de implementación de una solución de procesos específica.

Las soluciones BPM han sido adoptadas principalmente por los organismos financieros, donde la visibilidad y la adherencia a las regulaciones de cumplimiento son una parte integral de este sector (por ejemplo, la ley Sarbanes-Oxley). BPM también se ha aplicado en las organizaciones de servicios donde la productividad y la eficacia del personal desempeñan un papel clave en el rendimiento del proceso. La mayoría de las organizaciones deciden adoptar BPM porque prevén que los cambios en sus procesos se producen con frecuencia. Sin embargo, muchas organizaciones también están comenzando a ver más allá de BPM como un simple documentación y rastreo de procesos, considerándolo como una oportunidad para transformar su negocio, mejorar los procesos y reducir costos.

Adopción de los BPMS

La mayoría de las herramientas y software de BPM utilizados hoy en día son productos comerciales caros. El mercado está siendo liderado por IBM (Lombardi) y Oracle (Oracle BPM 11g), acaparando más de la mitad de la cuota de mercado. Sólo un pequeño porcentaje (aproximadamente 15%) de las empresas en México han adoptado una solución de código abierto para BPMS. Estos están dirigidos por Intalio y jBPM de JBoss. Otros jugadores incluyen BonitaSoft, ProcessMaker y Activiti, que representan una pequeña fracción de la cuota de mercado. Estos tres son adoptados en su mayoría por organizaciones pequeñas y medianas (PYMEs).

BPMS Clientes
IBM Afore Banamex, CaixaBank, Financiera Independencia, GNP Seguros, AXA Seguros, Coca-Cola, Redpack, Telcel
Oracle AXA Financials, Banamex Gpo. Financiero, Bimbo, Comex, Nextel, Movistar, Cablemas, Televisa, Casas GEO
Intalio Sky, Santander, Samsung de México, Costco, Sears de México, DHL
JBoss jBPM BBVA, Toyota, Grupo Posadas
BonitaSoft DirecTV, Xerox (gestión de documentos)
ProcessMaker Banregio, Mexbrit, Lenovo LatAm
Activiti CONACyT (Gobierno Mexicano)

Principales clientes de las suites BPM más utilizadas en México. Los clientes fueron obtenidos de las páginas web de cada proveedor.

Por qué código abierto y cuáles son los retos para su adopción

Antes de cualquier otra consideración, el principal motivo de adopción de una solución de código abierto u open source consiste en los costos de licenciamiento y servicios profesionales necesarios para su implementación. Los productos comerciales se encuentran en el orden de USD 250,000 por implementación, generalmente a través de pagos por adelantado. Por el contrario, las herramientas BPM de código abierto están atrayendo más atención en el mercado debido a los posibles ahorros en costos y términos de licenciamiento más flexibles. Los usuarios también pueden ampliar las prestaciones de los productos y su escalabilidad sin costes adicionales. En caso de que la solución requiera una personalización específica o corrección de bugs, es posible buscar la ayuda de un tercero o de la comunidad open source, en lugar de esperar los lentos tiempos de respuesta de los proveedores comerciales.

Los principales retos a los que se enfrenta cualquier adopción BPMS se enumeran a continuación:

• Fuerte dependencia de operadores que realizan sus tareas de forma manual, sin automatización ni flexibilidad para satisfacer las cambiantes necesidades del negocio.

• Falta de procesos y prácticas bien documentadas.

• Escasa colaboración en equipo; todo se hace a través de correo electrónico y llamadas telefónicas. Los documentos son almacenados en formato físico (hard-copy).

• Los proveedores actuales se centran en el departamento IT para proveer las necesidades de BPM de la organización; en realidad, BPM debería ser responsabilidad del área de negocios.

• Muchas organizaciones están centradas en datos (data-centric) en lugar de estar centradas en el proceso (process-centric).

• A menos que el cumplimiento normativo o de continuidad del negocio sean un factor, muchas organizaciones siguen un crecimiento orgánico, dejando la gestión de procesos en un segundo plano.

• Falta de confianza en BPM. Muchas organizaciones esperan resultados verificables en menos de 6 meses desde la adopción de BPM.

Principales Suites BPM Open Source

Intalio

Intalio es una plataforma de procesos de negocio de código abierto construido alrededor del modelador BPMN STP de Eclipse y el motor Apache ODE BPEL 2.0, ambos originalmente aportados por Intalio. La versión Enterprise proporciona los componentes necesarios para el diseño, la implementación y la gestión de varios procesos de negocio, tales como:

• BRE (Business Rules Engine – Motor de reglas de negocio).

• BAM (Business Activity Monitoring – Monitoreo de Actividades de Negocio).

• Portal.

• ESB (Enterprise Service Bus – Bus de Servicios Empresarial).

• ECM (Enterprise Content Management – Gestión de Contenidos Empresarial).

Intalio está disponible en varias ediciones, pero la versión relevante para este documento es la edición de comunidad libre (free community edition) de Intalio. Ésta se compone de dos módulos: Intalio Designer e Intalio Server. Intalio Designer permite el modelado de los procesos para ser eventualmente desplegados en el Intalio Server. Intalio Designer permite que modelos BPMN se conviertan en procesos BPEL ejecutables. De acuerdo a la filosofía de Intalio, el área de negocio podría generar, editar y ejecutar los procesos, sin requerir de un desarrollador técnico para traducir la visión de negocio en código.

JBoss jBPM

jBPM es una plataforma de código abierto para diferentes lenguajes de procesos ejecutables que van desde la gestión de procesos empresariales (BPM) hasta el flujo de trabajo para la orquestación de servicios. jBPM admite tres lenguajes de proceso diferentes. Cada uno de ellos está dirigido a una función y entorno específico:

• jPDL (lenguaje de definición de proceso propio de JBoss).

• BPMN 2.0

• Pageflow

jBPM genera todos estos lenguajes de proceso de forma nativa en la parte superior de la Máquina Virtual de Procesos (Process Virtual Machine – PVM). Así mismo, jBPM es independiente de las bases de datos, servidores y es integrable en otras aplicaciones (embeddable). Finalmente, esta suite es altamente personalizable – desde el punto de vista de los desarrolladores.

jBPM es modular. Funciona con el middleware empresarial de JBoss o cualquier otra plataforma de middleware que cumpla con la especificación Java EE. Está disponible a través de suscripciones que incluyen software certificado, soporte por industria, actualizaciones y parches, documentación y política de mantenimiento de varios años. El modelador es una aplicación Java estándar y no necesita un servidor de aplicaciones; las empresas que estén interesadas en jBPM pueden utilizarlo sin añadir más complejidad. Los formularios que pertenecen a los procesos modelados pueden implementarse como aplicaciones web o aplicaciones de escritorio (standalone) en Java.

Bonita Open Solution

Bonita BPM es un gestor de procesos de negocio de código abierto y suite de modelado de flujos de trabajo, creado en el 2001. El proyecto se inició en el Instituto Nacional de Investigación en Informática y Automática (Francia), para luego incubarse por varios años en el interior de la empresa informática francesa Groupe Bull. Desde 2009, el desarrollo y soporte de Bonita es realizado por Bonitasoft, una empresa creada específicamente para esta actividad.

Bonita consta de tres módulos principales:

• Bonita Studio: permite al usuario modificar gráficamente los procesos de negocio siguiendo el estándar BPMN. El usuario también puede conectar los procesos a otras piezas del sistema de información (tales como mensajería, planificación de recursos empresariales, administración de contenido empresarial y bases de datos) con el fin de generar una aplicación de negocio autónoma, accesible como un formulario web. Bonita Studio también permite al usuario diseñar gráficamente las formas que se mostrarán al usuario final con el fin de interactuar con el proceso. Por otra parte, el modelador permite al usuario empezar a trabajar con procesos diseñados con otros estándares y tecnologías como XPDL o jBPM. Se basa en Eclipse.

• Bonita BPM Engine: El motor de BPM es una API Java que permite al programador interactuar mediante programación de los procesos. Se basa en Hibernate.

• Bonita Portal: es un portal que permite a cada usuario final administrar en una interfaz parecida a webmail todas las tareas en las que él o ella está involucrada. El portal también permite que el propietario de un proceso pueda administrar y obtener informes sobre los procesos. Se basa en GWT.

ProcessMaker

ProcessMaker está diseñado estrictamente para las pequeñas y medianas empresas (PYMEs). Al igual que Intalio, ProcessMaker tiene la filosofía de que los usuarios de negocios y expertos en procesos que no tienen experiencia en programación puedan diseñar y ejecutar flujos de trabajo, así como automatizar los procesos de todos los sistemas. ProcessMaker tiene varios módulos con los que el usuario puede crear mapas de flujo de trabajo, formas de diseño personalizadas, extracción de datos de desde fuentes externas y otras características para generar y optimizar las operaciones de gestión del flujo de trabajo y de negocios:

• Diseñador de Mapa de Procesos

• Dynaform Builder (formularios personalizados para los procesos de la organización)

• Output Document Builder (diseñador de documentos de salida de proceso) / Gestión Documental

• Motor de reglas de negocio

• IDE para construcción de web services

• Gestión de usuarios

• Bandeja de entrada de casos

ProcessMaker posee una biblioteca en línea que proporciona plantillas de proceso que el usuario puede descargar y editar. La curva de aprendizaje también se puede reducir ya que el desarrollo puede basarse desde una plantilla ya construida y probada. Algunas plantillas de muestra incluyen:

• Solicitud de tarjeta de crédito

• Proceso de informe de gastos

• Solicitud de zonificación de distrito

Activiti

Activiti es una plataforma BPM de código abierto para un entorno basado en Java. Originalmente desarrollada por Alfresco, su código fuente se distribuye bajo la licencia Apache. Dentro de la plataforma Activiti BPM se encuentran los siguientes componentes:

• Modelado: Activiti Modeler, Designer y Kickstart

• Ejecución: Activiti Engine

• Gestión: Activiti Explorer, REST.

Activiti es soportada y desarrollada por varias empresas como SpringSource, Atos Origin, Signavio, Camunda y otros. Así mismo, la plataforma se puede integrar a mule, un popular ESB de código abierto, para la entrega de soluciones basadas en SOA. Su modelador soporta BPMN y jPDL; posee extensiones que permiten la integración con el middleware de JBoss.

Benchmark entre los diferentes BPMS

Finalmente, se presenta un comparativo de los diferentes BPMS, incluyendo los productos de IBM y Oracle:

BPMS Tipo Interfaz de Usuario Notación Workflows Binding
IBM Lombardi Workflow, Process Designer, ESB, ECM, Portal Todos BPMN BPEL J2EE, WSDL/WS
Oracle BPM 11g Workflow, Process Designer, ESB, ECM, Portal Todos BPMN BPEL J2EE, WSDL/WS
Intalio Workflow, Process Designer, ESB, ECM, Portal, BRE Web 2.0 BPMN WS-BPEL J2EE
JBoss jBPM Workflow, Process Designer Todos jPDL, BPMN, Pageflow BPEL WSDL/WS
BonitaSoft Workflow, Process Designer, Portal Java BPMN XPDL, BPEL J2EE
ProcessMaker Workflow, Process Designer, ECM Todos BPMN BPEL J2EE
Activiti Workflow, Process Designer Todos BPMN BPEL REST

Comparativo con las características de los BPMS más usados en México.

Análisis y recomendaciones

Para clientes pequeños con un gasto menor a USD 100,000 anuales dedicados a BPM, es recomendable adquirir un producto de código abierto. Dependiendo del requerimiento del cliente, puede utilizarse alguna de las opciones mostradas en el documento; sin embargo si el cliente tiene esperado un fuerte crecimiento en la demanda de su solución BPM, las mejores opciones son jBPM o Intalio, ya que ambos productos permiten conexión con plataformas de alta escalabilidad, incluyendo middleware y bases de datos comerciales. En el caso de jBPM, este producto permite utilizar la vasta gama de productos ofrecidos por Red Hat, mientras Intalio permite al cliente utilizar la Community Edition hasta que haya alcanzado la masa crítica necesaria para adquirir sus licencias. Basándose en una comparación a juicio de experto entre ambos productos, NO existe una clara ventaja competitiva de alguno sobre otro, por lo que dependiendo de las características del cliente variará el criterio de selección del BPMS a implementar.

h1

Una adopción ágil: retos y soluciones

02/14/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

Primero, tienes que aprender las reglas del juego. Luego, tienes que jugar mejor que nadie.

Albert Einstein (1879 – 1955). Físico judeo-alemán, nacionalizado suizo y posteriormente, estadounidense.

Desde hace poco menos de un año hemos venido trabajando con varias células de desarrollo ágil para un cliente que en aquél entonces era relativamente inexperto en esta metodología. Algunas de estas células han sido todo un éxito, compuestas por gente altamente calificada que trabaja como uña y mugre con el Product Owner (PO) perteneciente al cliente, mientras lanzan funcionalidad a producción como si fueran una fábrica de juguetes china. Otras células menos afortunadas han tenido que afrontar duros retos, incluyendo gente sin la suficiente experiencia para implementar el stack tecnológico y grado de colaboración necesarios para lidiar con proyectos y clientes complicados.

Pues bien, a partir de enero de este año, el cliente nos solicitó integrar Extreme Programming (XP) como parte de la implementación ágil, sin dejar de lado Scrum como framework de gestión de proyectos. Esto requirió un poco de flexibilidad entre ambas partes para incluir una serie de nuevos controles, tales como:

• Programación por pares, donde el trabajo es desempeñado por dos desarrolladores en vez de hacerlo de forma individual.

• El refactoring y la integración continua han tomado un rol mucho más importante durante el ciclo de desarrollo.

• Ahora existe una “propiedad colectiva del código”, en la que cualquiera puede modificar el código de otro, siempre que éste cambio sea respaldado por las mandatorias pruebas unitarias así como una correcta integración continua, evitando los así denominados cowboy coders: programadores muy buenos, pero que siempre dejan detrás de ellos un revoltijo inmantenible de código.

• La planeación ahora debe tomar en cuenta spikes de XP, los que en realidad son experimentos, análisis técnicos o pruebas de concepto que incluyen una revisión formal por parte del cliente.

• Anteriormente, la definición de “terminado” significaba tener algo listo para la demo. Ahora, ésta ha cambiado a “cuando el cliente lo haya probado satisfactoriamente”. Esto significa que durante el Sprint, el cliente realiza pruebas sobre los entregables, previo a la sesión de demostración.

• El análisis y diseño arquitectónico deben hacer uso de “metáforas”, o historias muy sencillas que explican cómo funciona el sistema. Esto se debe a que para el análisis, debemos interactuar con “embajadores” que oficialmente fungen como enlace entre las áreas de negocio y TI. Por ello la necesidad de explicarles cómo funcionan las cosas en términos “que hasta un niño pueda entender”.

Estos puntos han derivado en que el equipo tenga que reforzar la disciplina, pues si no tenemos cuidado, podemos terminar con una dinámica de grupo totalmente anárquica, en la que cada quien hace lo que quiere. Esto es más aparente si tomamos en cuenta que ahora todos trabajan en pares y pueden “tocar” cualquier parte del código. Por otro lado, el beneficio principal y la razón por la que el cliente ha considerado hacer este cambio, es que ya somos lo suficientemente maduros como para evolucionar el proceso hasta la fase de innovación:

pic: Enterprise agility adoption roadmap

Roadmap de adopción ágil. Generalmente, todo inicia con una fase de experimentación a través de un proyecto piloto con sólo un equipo de trabajo (Pasos 1 y 2). Posteriormente, corremos una fase de lanzamiento, donde varios equipos ágiles trabajan en paralelo sobre un mismo programa (Pasos 3 y 4). Después, ejecutamos un rollout general, donde establecemos ágil a nivel portafolio (Paso 4). Finalmente, viene la fase de innovación (Paso 5), en la que se implementan prácticas como colaboración remota y configuración de un ALM comercial. (Fuente de la imagen: appslog.com)

Lo que debe quedar muy claro, es que antes de llegar a esta fase, debimos haber alcanzado el punto en el que el cliente confía en nosotros lo suficiente como para sólo indicarnos cuál es el valor de negocio de la funcionalidad a entregar, dejando a nuestro criterio todo lo demás. Es decir, el momento en el que se le ha cedido el control y mando al equipo.

Los principales retos durante la adopción

Tanto la adopción ágil en general, como la implementación de XP en particular, han implicado muchísimos retos que sobre todo, tienen que ver con el lado humano. Ciertamente, desde hacía tiempo ya habíamos cubierto el tema del ciclo de desarrollo o SDLC y la calidad de los entregables; por lo que ahora debíamos lidiar con temas como “… ¿por qué debo sentarme con este tío a programar?” El cambio de algunos paradigmas, incluso entre gente “ágil”, no es cosa sencilla. A continuación, enumero los mayores retos que llegamos a enfrentar y cómo los hemos mitigado:

• El primero, y más importante de todos: ágil no significa que terminaremos un proyecto en menos tiempo. Este es un concepto erróneo que muchos usan como argumento de venta. La realidad es que el mayor beneficio de ágil, desde el punto de vista de negocio, son las liberaciones tempranas: ¿Para qué esperar seis meses a tener todo terminado, si desde el primer mes ya existe un entregable “listo para liberar a producción” que puede indicarnos si el proyecto está destinado al éxito o al fracaso? Obviamente, tendremos que esperar otros cinco meses para tener todo al 100%, pero desde el primer mes tendremos algo tangible y generando un ingreso, o podemos darnos cuenta que el caso de negocio era erróneo, teniendo la posibilidad de “tirar del enchufe” cuando apenas se ha gastado una pequeña fracción del presupuesto.

• Interdependencias entre equipos y proyectos. Aunque Scrum hace énfasis en que no existan interdependencias entre equipos, la realidad es que esto es el pan nuestro de cada día. Por ejemplo, un equipo en Java desarrolla web services que serán consumidos por una aplicación en .net desarrollada por otro equipo. En este caso, podemos echar mano de un perfil que no viene descrito en el framework original, conocido como Technical Owner (TO), que está al mismo nivel del Scrum of Scrum Masters. El TO es el responsable de la arquitectura de un programa o portafolio, definiendo interfaces y dependencias. Así mismo, debe apoyar en la definición del plan de liberación o release plan, evitando al máximo que nos pisemos los callos unos con otros, trazando una ruta crítica que tomará precedencia sobre cualquier otro ítem de los product backlogs para cada equipo involucrado:

pic: Scrum in an interdependent environment

El equipo 1 (rojo) hace Sprints de dos semanas y liberaciones cada mes; el equipo 2 (azul) ejecuta Sprints de cuatro semanas y libera cada dos meses. Sabiendo que el equipo 2 debe implementar ciertos componentes para que el equipo 1 pueda integrarlos, el Technical Owner debe apoyar a los Product Owners de ambos equipos para definir la ruta crítica y acordar quién hará qué y cuándo debe tenerlo listo. (Fuente de la imagen: cardinalsolutions.com)

Así, el TO apoyará en la generación de las especificaciones necesarias para que los equipos utilicen “mock ups” mientras tienen lista su parte. Finalmente, los POs deben considerar un Sprint o parte de éste dedicado a la integración, pruebas y refactoring entre ambos equipos.

• Dificultades para asegurar la calidad y generar los entregables de acuerdo a CMMi-L3. Desde un principio contamos con un miembro del equipo que podía fungir como “especialista técnico” (su puesto oficial es Tech Lead o TL, pero NO es el líder del equipo; tampoco tiene el rol de Scrum Master). Dicha persona colabora de forma muy estrecha con el TO para implementar adecuadamente la arquitectura definida por aquél, así como reforzar una correcta ejecución de desarrollo guiado por pruebas (TDD) e integración continua. En resumen: un TL no puede confiar en un software que no tenga un set de pruebas cuantificables que puedan ejecutarse con sólo pulsar un botón. Por otro lado, contamos con un par de Business Analysts (BA) encargados de verificar una correcta transferencia de conocimiento entre el cliente y el resto del equipo. Ya que esta transferencia está muy relacionada a la documentación requerida por CMMi, ellos son también los encargados de apoyar en esta tarea, liberando a los desarrolladores de cargas innecesarias.

• Scrum distribuido. Esta modalidad del proceso es una historia aparte, pero baste decir que en un par de células, algunos miembros del equipo pertenecen a offshore. Es decir, por un lado tenemos al Scrum Master, el tech lead, un desarrollador y un analista de negocio trabajando hombro con hombro con el cliente, mientras el resto del equipo – el tester, tres desarrolladores y otro business analyst – colabora desde literalmente, el otro lado del mundo. Desde un punto de vista táctico, el principal reto es la comunicación, confianza y respeto mutuo, así como diferencias culturales. En cuanto a estrategia de negocios, este modelo rebaja muchísimo los costos, pero también refleja una pequeña pero perceptible disminución en la productividad – en nuestra experiencia, a menos que todo el equipo este co-locado o ya se hayan resuelto diferencias culturales, los tiempos de ejecución se incrementarán hasta en un 25% debido precisamente, al overhead de comunicación.

Conclusiones

Cualquier adopción ágil y su correspondiente implementación tendrán retos a enfrentar, principalmente en las áreas de interdependencia entre equipos, manejo de recursos remotos y alineación del cliente. Sin embargo, si obtenemos el patrocinio sincero de high management – o como en nuestro caso, es una directiva que viene del cuartel general y debe adoptarse por todas sus subsidiarias alrededor del mundo – nuestros problemas serán mucho menores, limitándose a temas de madurez y alineación de procesos.

¿Dónde nos encontramos parados después de todo este ejercicio? Bastante bien, ya que después de diez meses, hemos trabajado de forma casi ininterrumpida, e incluso tenemos la oportunidad de expandir nuestras operaciones a otras unidades de negocio. Si todo sale bien, en un par de meses estaremos haciendo un copy + paste del proceso de adopción e implementación, aunque en esta ocasión, tendremos que enfrentar un área en la que personalmente no me siento tan fuerte: e-commerce.

h1

A qué dedica su tiempo un desarrollador

01/10/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

Los requerimientos cognitivos para la programación (ingeniería de software) son mucho más parecidos a los necesarios para componer música o pintar un cuadro, que aquellos para construir un puente o instalar una alcantarilla. La falsa idea de que los “geeks” somos aburridos, poco creativos y torpes implicaría que Mozart, Beethoven y Daft Punk también lo son.

Entonces, ¿por qué insistimos en medir el desarrollo de software como si fuera una ciencia de la ingeniería?

Hace un par de meses publiqué un post referente a las herramientas y tecnologías más usadas en el lenguaje de programación Java. Adicionalmente a la frecuencia con la que se emplean estas tecnologías, el estudio original también contiene un apartado relacionado a la productividad del personal IT. Específicamente, a qué dedica su tiempo un desarrollador. Los resultados son reveladores:

Actividad Descripción Tiempo Porcentaje
Generación de código Programando, codificando, desarrollando hacks 15 Hrs. 37.5%
Resolviendo problemas Debugueo, perfilamiento, tuning de desempeño 5 Hrs. 12.5%
Comunicación Juntas, chats, correos, teleconferencias 5 Hrs. 12.5%
Overhead técnico Compilando, desplegando, instalando hardware y software 4 Hrs. 10%
Estrategia Arquitectura, diseño, refactoring 4 Hrs. 10%
Ocio Twitter, Facebook, YouTube 3 Hrs. 7.5%
QA Generación de pruebas, revisiones de código 2 Hrs. 5%
Bomberazos Caídas de sistema, problemas de desempeño 2 Hrs. 5%

Desglose de actividades desempeñadas durante una semana de trabajo de 40 Hrs. (Fuente: zeroturnaround.com)

De acuerdo al reporte – que incluye a desarrolladores, arquitectos, sysadmins y QAs – el personal IT sólo pasa 26 horas a la semana (65% del total, o tan sólo 5.2 horas efectivas al día) desempeñando su función principal: generando código, resolviendo problemas, realizando tareas de estrategia y QA; el resto del tiempo lo dedica a actividades menos productivas como juntas, bomberazos y cierto grado de ocio.

Por otro lado, si estos parámetros son resultado de una encuesta global, es inevitable darse cuenta que el personal Latinoamericano es aún menos productivo, ya que nuestra cultura incluye distracciones como ir a la tienda de la esquina por unas papas o pasar por el café de las 4:00 al Starbucks local. Esto nos proporciona una buena idea de la productividad real de un desarrollador en nuestros países, ya que ésta puede disminuir a tan sólo 3-4 horas efectivas al día. Como resultado, muchas empresas de la región extienden sus horarios a 45 horas o más a la semana, agotando aún más a los recursos y a largo plazo, impactando su productividad.

Las causas organizacionales de una baja productividad

¿Por qué cuidar la productividad del personal IT? La respuesta es simple: dinero. El factor más importante en el desarrollo de software son los desarrolladores, mientras que el ambiente de trabajo tiene un profundo impacto en la productividad y calidad, como veremos más adelante. Por ello, es necesario hacer ajustes en ambos para maximizar el retorno de inversión: un desarrollador es un empleado caro con un mejor salario que el del promedio de otros trabajadores de oficina. Considerando los tiempos de desarrollo, tiene sentido mejorar su eficiencia y productividad, pues una mala calidad y fechas de liberación erradas terminan en marchas forzadas, cacerías de brujas y ultimadamente, un mayor costo para la organización.

Ahora bien, ¿qué puede hacer la empresa para incrementar nuestra productividad? Muchos jefes creen que bloqueando internet mejorará el desempeño de sus empleados. Sin embargo, esto no puede estar más alejado de la realidad: de acuerdo a varios estudios, al navegar por la red obtenemos el descanso y relajación necesarios para mejorar nuestro estado de ánimo, incrementando nuestra productividad. Por supuesto, sitios pornográficos o con material ofensivo deben ser filtrados, pero una empresa sin acceso a Stack Overflow sólo significa que top management no tiene idea de lo que está haciendo.

En realidad, existen otras maneras de destruir la productividad de la gente IT que pueden clasificarse en básicamente cinco categorías:

1. Las manzanas podridas. En esta categoría tenemos programadores con pésima actitud, hombres orquesta con egos más grandes que la deuda externa y narcisistas que insisten en achacar a otros los errores de su propio código. En algunos casos, es posible corregir el rumbo al delimitar responsabilidades, tener una estrategia de capacitación y una intervención real de recursos humanos que ayude a retenerlos y resolver temas de comportamiento. Aunque, más a menudo de lo que se cree, la mejor opción es deshacerse de las manzanas podridas antes de que echen a perder el resto del barril.

2. Overhead administrativo. Juntas de avance maratónicas, parálisis por inboxes saturados, así como los procesos mismos para medir el desempeño – reportes de actividades, reportes de horas, procesos de control al estilo RUP – dañan más a la productividad de lo que Facebook o Twitter jamás podrán lograr. Aunque la respuesta a este problema yace en la cultura organizacional (tradicional vs. ágil, esclavos de la metodología vs. interpretación pragmática), es una buena idea generar una retrospectiva o análisis FODA para darnos cuenta dónde estamos fallando, ya que la perfección se alcanza, no cuando no hay nada más que añadir, sino cuando ya no queda nada más que quitar.

3. Mala administración. Dos de los peores infractores son aquellos gerentes que no tienen ni idea de TI y cuya única aportación es reenviar correos, o esos managers que recientemente fueron desarrolladores, perdiéndose constantemente en los detalles en vez de tener una visión general del proyecto. En este caso vale la pena ayudar al manager a mejorar sus habilidades, ya sea mediante coaching, revisión por pares o cursos gerenciales. En un peor escenario, habrá que dejarlo “buscar nuevas oportunidades”, pero sólo si hemos buscado ayudarlo sin resultado alguno o ya es un tema de actitud – recordemos que hay estudios demostrando una importante cantidad de sociópatas en las posiciones de medio y alto nivel gerencial.

4. Ambiente de trabajo y dinámica de grupo. Si el ambiente no es propicio para la concentración requerida o el equipo de trabajo no tiene afinidad cultural (programadores vs. testers), se perderá mucho tiempo debido a interrupciones o falta de comunicación. En las metodologías ágiles esto se resuelve al dejar a todo el equipo aislado del resto de la organización, por ejemplo, en una sala de juntas. De la misma manera, los integrantes deben sentirse a gusto con sus demás compañeros al encontrar un tema de interés mutuo, el cual debería ser en la mayoría de los casos, la satisfacción del cliente.

5. Problemas técnicos. La deuda técnica, demasiados requerimientos de documentación o uso de software con pobre documentación, desarrollos que tengan que ver con sistemas legados o por el contrario, implementaciones con tecnologías inmaduras, implican cuantiosas pérdidas de tiempo en investigación, pruebas de concepto, lectura de más y más manuales así como re trabajo constante. Entre otras opciones, es necesario considerar el tiempo dedicado a estas actividades e incluirlo en el plan de proyecto. Así mismo, debemos asegurarnos que las incidencias sean resueltas tan pronto como vayan apareciendo, para evitar que la entropía se haga presente.

Con todo y todo, hasta este punto estamos asumiendo que el ambiente laboral no es tóxico o extremadamente burocrático, o que el personal vive lo suficientemente cerca del trabajo como para no llegar exhausto después de un recorrido de hasta dos horas. Pero, si buscamos quitarle cargas innecesarias a los empleados, estaremos dando un paso en la dirección correcta: hay pocas cosas que podamos hacer para incrementar la motivación y productividad de un desarrollador, pero sí que podemos hacer mucho para destruirla.

Nosotros también somos parte del problema

Así es: los sistemólogos tampoco somos el cuchillo más filoso de la cocina, pues tenemos malos hábitos que impactan nuestra propia productividad, incluyendo:

• Multitasking. La mayoría intentamos llevar a cabo varias tareas al mismo tiempo, como generar un entregable mientras checamos el correo y nos reímos ante la última actualización del 9GAG: ¿por qué creen que las configuraciones multi-monitor y el ALT + TAB se han vuelto tan populares? Multitasking es de hecho, una actividad que incrementa exponencialmente el tiempo necesario para terminar las tareas que podríamos realizar de forma secuencial, y aun así, insistimos con ello: ¿quién no ha visto ese video donde un tipo va caminando por la calle mientras textea con su móvil, sin darse cuenta que tiene enfrente a un oso? Una solución ante un problema tan común es simplemente, trabajar desconectado. Aplicar 25 minutos de furioso trabajo sin interrupciones para después relajarse por 5 minutos y caminar un poco, leer correos o checar el WhatsApp. Esto es de hecho, una recomendable técnica de administración del tiempo con serias bases en la neuropsicología.

• Cómo atacamos tareas “aburridas”. Hay actividades que NO son precisamente del agrado de nadie, como la documentación, reportes de horas o rastreo de incidencias. La mayoría de las personas se quedan estancadas realizando estas tareas, tomando más de lo que deberían. Una buena opción es darnos cuenta en qué momento del día somos más productivos y en qué momento “volamos en piloto automático”. Por ejemplo, si somos del tipo matutino, debemos dejar por la mañana todas las actividades que requieran concentración, dejando para la tarde – usualmente después de la hora de la comida – las tareas más bien repetitivas que requieren poco “cerebro”. Si aun así nos cuesta trabajo, podemos escuchar música que nos ponga en el modo correcto: la instrumental es la más recomendada por los expertos; el ritmo de nuestra selección define qué tan energéticos o relajados nos sentiremos (por ejemplo: dance vs. chill-out).

• Que hacemos – o dejamos de hacer – con las interrupciones. Si no es posible mudarse a una sala de juntas, podemos adquirir unos audífonos anti ruido. Existe una menor probabilidad de ser interrumpidos por ruidos medioambientales y automáticamente estamos dando una señal de “no molestar”. Si es factible negociar un horario flexible, es conveniente trabajar algunas horas extra el lunes y martes, que son los días en que usualmente tenemos más energía y mejor actitud, compensándolas saliendo un poco más temprano el resto de la semana. Por ejemplo, trabajar 12-14 horas el lunes puede significar sólo trabajar hasta el mediodía del viernes.

• Juntas. Si hay algo que atormenta a la mayoría son las juntas innecesarias. Es necesario evitarlas a toda costa, aunque tarde o temprano tendremos que asistir a una. De acuerdo a los especialistas, debemos buscar calendarizarlas a las primeras horas de la mañana, cuando la mayoría tiene más energía. Sin embargo, se supone que el martes a las 3:00 PM (justo después de la comida) es cuando casi todos tenemos un pico máximo de atención. Si el objetivo es llegar a un acuerdo rápido o se trata de reuniones de alto nivel, al tenerla poco antes de la hora de salida lograremos el efecto deseado, ya que a nadie le gusta quedarse después de las 6.

Es un hecho corroborado por varios estudios, que los mejores programadores son hasta 28 veces más eficientes que los peores programadores. Esto se debe entre otras cosas, a que toman ownership del proyecto, generan más código con menos incidencias, escriben estructuras mantenibles y hacen más con menos. Por ello, vale la pena leerse valiosos ejemplares como Beautiful Code o The Pragmatic Programmer y luego poner todo en práctica: en el mercado laboral actual, un “programador promedio” gana alrededor de US$23,800 anuales, mientras un superstar alcanza los US$30,200. Esto significa una diferencia de más del 26%.

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

Conservando la lealtad de los empleados: dos puntos de vista

09/27/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

La administración consiste en hacer las cosas bien; el liderazgo consiste en hacer lo correcto.

Peter Drucker (1909 – 2005), consultor, educador y autor austriaco.

¿Qué es lo que la mayoría de nosotros espera de su trabajo? ¿Qué requerimos para prosperar y crecer en el mismo? ¿Qué necesitamos para “ponernos la camiseta” y dar nuestro máximo esfuerzo? Algunos responderán sueldos altos y prestaciones; otros se irán por el tema del ambiente laboral y los que ya lo han experimentado, tal vez mencionen home office y flexibilidad de horario. Sin embargo, resulta que nada de esto es cierto: dos de las empresas globales con más prestaciones, apapachos y número de iniciativas de calidad de vida hacia sus trabajadores, tienen índices de rotación enormes, con una permanencia promedio de apenas un año. No, no se tratan de Walmart y sus historias de horror; tampoco de Samsung, con capataces que imponen castigos corporales a sus empleados. Estas empresas son ni más ni menos, que Google y Amazon.

Así es: una de las grandes realidades de la vida moderna, es que sin importar las prestaciones, ingresos o ambiente laboral, la verdadera satisfacción de nuestro trabajo depende de un sólo factor: nuestro jefe. Si es una persona con dotes de liderazgo que nos trata como seres humanos, nos informa adecuadamente qué es lo que espera de nosotros y nos proporciona una retroalimentación de forma positiva y continua, seremos trabajadores felices, incluso si el sueldo no es del todo competitivo, la naturaleza del puesto es estresante o las jornadas laborales llegan a ser excesivamente largas. Esto puede ser algo inesperado para algunos de nosotros, pero si nos ponemos a pensar, nos daremos cuenta que es verdad: habitualmente cuando cambiamos de trabajo de manera voluntaria, se debe a que estamos abandonando al jefe, no a la empresa. Recuerdo una entrada en este mismo blog, donde describía que la interacción entre las personas siempre debe basarse en humildad, respeto y confianza, pues al faltar alguno de estos valores, tarde o temprano tendremos un conflicto que desembocará en una ruptura.

Qué hacer como empleado

En algunas ocasiones me he topado con jefes que no están preparados para serlo. Ya sea porque los lanzaron al ruedo sin entender plenamente sus funciones, o son acting – sí, aquello de sigues ganando el sueldo de supervisor, pero trabaja como ‘acting manager’ por cierto tiempo y si eres bueno, te damos el puesto. Lo malo es que con regularidad, ni siquiera se dan cuenta de que se están metiendo en un batidillo, y a menos que exista retroalimentación por parte de sus subalternos, no podrán identificar dónde se encuentran las áreas de oportunidad. Una buena forma de arreglar esto es hablar con ellos para corregir el rumbo. Pareciera que esto es de sentido común, pero muchas veces, el ego se interpone en el camino – el típico “que se joda” – sin darnos cuenta que en última instancia, al tener un supervisor ya somos parte de un equipo de trabajo; si él falla, nosotros fallamos también. Algunos expertos en la materia nos recomiendan ciertas acciones a tomar en caso de que nuestro manager no tome la iniciativa:

• Qué espera de nosotros. Aunque muchos damos por hecho cuál es nuestra función, a menudo los jefes esperan algo muy diferente de lo que nosotros creemos. Por ello vale la pena dejar en claro las expectativas de ambos.

• Mayor comunicación. Pedir una retroalimentación periódica independientemente de si creemos que vamos bien o no, permitirá a ambas partes identificar sus respectivas áreas de oportunidad. La clave aquí es la humildad: el diálogo debe darse no para acorralarlo o ponerlo en evidencia, sino para darle a entender que estamos ahí para apoyarlo.

• Explicar nuestras capacidades. Muchos jefes no tienen idea de qué skills poseen los miembros de su equipo; esto ocurre sobre todo en organizaciones donde el manager tiene muchas personas bajo su cargo. Siempre es sano recordarle al jefe – y recordarnos a nosotros mismos – que él no está ahí porque sepa más que nosotros, sino porque puede coordinar profesionales que saben hacer su trabajo.

• Consistencia. ¿A cuántos no nos ha pasado aquella situación en la que el jefe solicita un trabajo con urgencia, obligándonos a salir tarde por entregarlo antes de la fecha límite, para que después de algunos días nos salga con que ‘ehh… ni siquiera lo he revisado’? Este tipo de inconsistencias se convierten en “una raya más al tigre”, y de ahí, en resentimiento y la eventual separación. La mejor opción es hablarlo de inmediato, solicitando compromiso y respeto de su parte.

Y qué hacer como manager

Ahh… pero el que debería buscar la lealtad del empleado debería ser el jefe, pues la razón de ser de un manager es básicamente la de coordinar personas y retener buenos trabajadores; de nueva cuenta, humildad, respeto y confianza deben ser los valores que debemos mostrar hacia nuestros subordinados. En este caso, existen algunos tips que nos pueden ayudar a mejorar la experiencia de nuestra gente y mejorar la eficiencia general del equipo de trabajo:

• Escuchar atentamente lo que nos dicen. Es necesario hacer preguntas, mantener contacto visual, sonreír; nada de checar el celular, el reloj o el monitor de la laptop. Debemos mostrar a nuestra gente que estamos realmente interesados en lo que tienen que decir, pues debemos hacerlos sentir que son alguien importante en nuestro equipo de trabajo.

• Comunicación. Evitando revelar información clasificada o entregarnos a la juntitis crónica, es muy importante que nuestros equipos estén informados sobre el estatus general del proyecto, área e incluso de la compañía. Esta política inclusiva de all hands meetings tiene sus beneficios; especialmente el sentido de pertenencia y de que somos un equipo, tanto en las buenas como en las malas.

• No hacerse el importante. Uno de los rasgos característicos de algunas personas es lo fantoches que pueden llegar a ser; este comportamiento es especialmente notable en la cultura Latina, donde existen muchos jefes que todavía aplican la de quién es el macho con sus subordinados. Esto puede servirnos cuando tengamos reuniones entre iguales o participemos en una negociación con un cliente, para hacerles saber que somos parte del club. Pero cuando se trata de nuestra gente, tenemos que reflejar la convicción de que “mi confianza es tal que NO es necesario apantallarte con mis posesiones materiales, viajes o grados académicos”.

• No discutir las fallas de otros. ¿A quién no le gusta un poco de chisme de vez en cuando? Después de todo, es un buen tema de conversación que hace amena cualquier plática. Sin embargo, perdemos enormemente el respeto de los demás si ventilamos los trapitos de alguien en público. Y esto también incluye las evaluaciones: los elogios y reconocimientos siempre son en público; los reproches y críticas, en privado.

En resumidas cuentas, para conservar la lealtad de nuestros empleados, como managers debemos demostrarles que sinceramente nos preocupamos por ellos y que los consideramos no sólo como recursos, sino como colaboradores sin los cuales nosotros no podríamos llegar a ningún lado. Como elocuentemente describió un gerente en una plática dada por Jeff Haden, consultor y columnista de la revista electrónica Inc.com:

… Sí, nosotros estamos a cargo y sí, hablamos acerca de objetivos, metas y visiones, pero a nuestros empleados no les importa nada de eso. Podemos comunicarnos y conectarnos con ellos todo lo que queramos, pero nadie nos escucha realmente. Sólo sonríen y asienten con la cabeza; luego vuelven a hacer sus trabajos de la misma manera que siempre lo han hecho.

Nuestros empleados en realidad no se preocupan por lo que queremos que hagan, hasta que se dan cuenta de lo mucho que nos preocupamos por ellos. Cuando los empleados saben – realmente saben – que te preocupas por ellos, es entonces cuando ellos se preocupan por ti. Y cuando saben que te importan, te escucharán… y harán lo que sea por ti.

h1

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

07/14/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

La suerte no es un factor. La esperanza no es una estrategia. El miedo no es una opción.

James Cameron (n. 1954), director, guionista, productor de cine y explorador marino canadiense.

En el post pasado mostré un ejemplo de la vida real, con algunos de los tropiezos con los que podemos toparnos durante una implementación de Scrum. En resumidas cuentas, el usuario es nuevo en el paradigma ágil y por la premura de cerrar el contrato, a nosotros nos falló conseguir al personal adecuado, así como capacitarlos correctamente en las mejores prácticas de desarrollo ágil. Sin embargo, esto sólo es la punta del iceberg, ya que durante las siguientes iteraciones y para los demás equipos, tendremos que incluir una serie de medidas de control para asegurar la efectividad y eficiencia del proceso, así como de la calidad de los entregables.

Uno de los requerimientos más importantes para el cliente es una elevada productividad por cada Sprint, así que nos decidimos por un esquema de “trabajo especializado en paralelo”:

Tiempo (día) Planeación Análisis Diseño y Codificación Pruebas Despliegue
Planeación del Sprint
1 Recolectar reqs. del backlog        
2 Transf. de conocimiento de analistas hacia resto del equipo

Atomización de reqs. en tareas

Reunión de Sprint planning

     
3        
Ejecución del Sprint
4 – 13   Análisis para crear/insertar nuevos reqs. en backlog (siguiente Sprint) Diseño Ágil

Codificación

Pruebas Unitarias

Pruebas Funcionales

 
Cierre del Sprint
14         Reunión de Sprint review
15 Retro.        

Ciclo de “especialización en paralelo” con Scrum. Nótese cómo mientras una parte del equipo se enfoca a desarrollar los entregables del Sprint actual, otra parte (dos analistas) se dedica a realizar el análisis de requerimientos del siguiente Sprint.

Este modelo de tres semanas con análisis en T+1 es posible ya que cada célula incluye dos analistas de sistemas. Ciertamente esto contradice el paradigma ágil, ya que en teoría, todos los integrantes del equipo deben ser milusos o como dicen nuestros vecinos del norte, jack of all trades. Sin embargo, la misma figura literaria también dice: jack of all trades, master of none o lo que es lo mismo: quien mucho abarca, poco aprieta. Es decir, en algunas ocasiones es recomendable tener gente especializada en la célula que nos ayude a maximizar la eficiencia del equipo, pues por citar un ejemplo, un desarrollador promedio puede conocer PL/SQL y obtener buenos resultados, pero un DBA experimentado, “creará magia”.

Cabe recalcar que este esquema resultó exitoso en cuatro células pero falló catastróficamente en una de ellas. La manera más objetiva de demostrarlo es a través de números fríos: mientras la célula más productiva ha generado 819 story points durante las últimas 13 semanas, la peor ha generado tan sólo 130 que aun así, están siendo impugnados por el cliente. Esta falta de productividad fue achacada inicialmente a una falta de seguimiento en el proceso Scrum, sin embargo en términos generales, dicho proceso fue seguido al pie de la letra; el problema derivó en no implementar correctamente la construcción de los entregables. Este proceso, separado de Scrum, es conocido como el ciclo de vida de desarrollo de software (Software Development Life Cycle o SDLC).

El desarrollo de software se compone de dos procesos

Cualquier proyecto de desarrollo de software está compuesto por dos familias de procesos fuertemente ligados que atacan aspectos muy diferentes del proyecto:

• El proceso de gestión de proyectos, que de acuerdo al Project Management Body of Knowledge (PMBOK), se compone por diez áreas de conocimiento: integración, alcance, tiempo, costos, calidad, recursos humanos, comunicación, riesgo, adquisición y stakeholders.

• El proceso de desarrollo de software o SDLC, enfocado a la entrega del producto y conformado por las disciplinas ya conocidas por todos: análisis de requerimientos, diseño, construcción, pruebas, despliegue, mantenimiento y gestión de la configuración.

El problema es que los neófitos en el paradigma ágil creen que cualquier metodología define ambos procesos, algo que es tan FALSO como que el PMBOK nos indique cómo implementar un plan de pruebas. Scrum está enfocado al proceso de gestión de proyectos, dejando que el equipo decida cómo implementar a nivel operativo sus desarrollos; por el contrario, metodologías como Extreme Programming (XP) se enfocan de lleno a la ingeniería de software y por ende, a la entrega y calidad del producto. Es así como una de las metodologías híbridas más utilizadas en la industria es la mancuerna Scrum/XP, ya que ésta permite una combinación ganadora:

↑ Prácticas de gestión de proyectos Gestión de Costos Gestión de adquisiciones Gestión del tiempo

Sprint

*40 Hrs./Semana

Gestión de RRHH

Scrum master

*Propiedad colectiva del código

*Cliente on-site

*Coach, no PM

  Alcance y reqs.

Product Owner

Product Backlog

*Juego de planeación

*Cliente on-site

*Historias

Gestión de la comunicación

Scrum diario

Reunión de Sprint planning

Reunión de Sprint review

*Cliente on-site

*Historias

Gestión de la integración

Sprint

Reunión de Sprint planning

Sprint backlog

*Juego de planeación

*Liberaciones cortas

Gestión del riesgo

Reunión de Sprint planning

Reunión de Sprint review

Scrum diario

*Juego de planeación

*Liberaciones cortas

*Programación orientada a pruebas

*Cliente on-site

↓ Prácticas de desarrollo de software Diseño de software

*Metáforas

*Diseño simple

Construcción de software

*Programación por pares

*Refactoring

*Propiedad colectiva del código

*Estándares de codificación

Gestión de la configuración

Build diario

*Integración continua

Gestión de la calidad

Reunión de Sprint review

*Programación orientada a pruebas

*Refactoring

*Cliente on-site

*Estándares de codificación


Combinación de metodologías de gestión de proyectos y desarrollo de software. En este caso, Scrum y Extreme Programming. Nota: las prácticas con (*) pertenecen a XP. (Fuente: just-another-blog-for-kicks @ blogspot.com)

Esta combinación incluye controles entre las disciplinas de gestión de proyectos y desarrollo de software, dejando fuera sólo la gestión de adquisición y costos, que podrían ser llevadas a cabo de forma adecuada por una Oficina de Proyectos o PMO. Como opinión personal, este ejercicio debería ayudarnos a entender que Scrum por sí solo no resolverá nuestros problemas, ya que no hay soluciones técnicas para problemas de gestión, pero puede haber soluciones administradas para problemas técnicos. Por ello la necesidad de complementarlo con mejores prácticas de otras metodologías o frameworks enfocados al nivel operativo.

Asegurando que todos hacen lo que dicen que hacen

Es así como hemos decidido verificar el seguimiento de estas prácticas a través de un checklist aplicado por un experto en la materia (Subject Matter Expert o SME) en colaboración con el resto del equipo, incluyendo el líder técnico (TL), los analistas (BA), los desarrolladores (DEV), el tester (TE) y el Scrum master (SCM):

Fase Punto de revisión Responsable Evidencia Resultado
Análisis Documentación elaborada por analistas está completada al 100% y están de acuerdo al objetivo de las historias de usuario seleccionadas para el presente Sprint. BA/TL Documento
Análisis La documentación aprobada está publicada, distribuida y disponible para todos los miembros del equipo. BA/ TL/ SCM TFS/ Sharepoint
Diseño Modelo de persistencia y modelo conceptual cumplen con alguno de los tres enfoques ORM: esquema primero, modelo primero, código primero. TL TFS/RSA
Diseño La arquitectura ya ha sido definida y comprendida por todo el equipo: cliente-servidor, N-capas, SOA. TL TFS/RSA
Construcción Los estándares de código han sido aplicados a todo artefacto de software construido de acuerdo a la filosofía de codificación adoptada. TL TFS/RSA
Construcción El ambiente de desarrollo está correctamente instalado y configurado en las instalaciones del cliente y si aplica, en las laptops de los desarrolladores. TL Ambiente verificado
Pruebas Unit tests para cada artefacto de software. TE/DEV Artefactos de software
Pruebas Matriz de pruebas actualizada con todos los casos y escenarios de prueba. TE Documento
Despliegue Obtener la documentación con los procedimientos de instalación y configuración de los entregables de software en los ambientes de QA, PERF y PROD TL Documento
Despliegue Verificar que existan procedimientos de gestión de cambios para los ambientes de QA, PERF y PROD. TL Documento

Lista de verificación para mejores prácticas del SDLC ágil.

Este es sólo un ejemplo, ya que dependiendo de la madurez del equipo o empresa que está implementando el proyecto, la lista puede tener más de 150 controles. De momento, nosotros no requerimos tantos (sólo 50-60 dependiendo de la tecnología usada), pero nuestra área de SQA ya nos adelantó la noticia que dentro de 6-8 meses certificaremos la cuenta en CMMI-5. Por ello, muy probablemente, acabaremos con una lista muy extensa, comprobada no sólo por nuestros SMEs, sino también por SQAs calificados o los appraisers que otorgan la certificación CMMI.

Conclusiones

El SDLC es el proceso que empleamos para desarrollar nuestros entregables. Y sin importar la metodología que ocupemos, si nuestro SDLC es inmaduro o deficiente, estamos en serios problemas. Sin embargo, NO existe un proceso único que pueda ser implementado por todos; incluso, debería ser lo suficientemente flexible como para cambiarlo de acuerdo a las necesidades de negocio o conforme va creciendo el alcance de nuestro proyecto. La situación es que siempre es necesario tener un proceso formal y comprendido por todos los involucrados, que pueda seguirse de forma sustentable. La alternativa es trabajar de forma desorganizada, o confiar ciegamente en que el equipo sabe lo que hace. Así que, nuestra mejor opción al adoptar ágil, consiste en adherirse al proceso de gestión, definir un SDLC formal, y hasta que estemos seguros que ambos procesos sean llevados a cabo de forma natural y repetible, es necesario introducir medidas de control para asegurarnos que todo funciona correctamente.

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.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 38 seguidores