Archive for the ‘Informática e Internet’ Category

h1

Una adopción ágil: retos y soluciones

14 febrero, 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

10 enero, 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

29 noviembre, 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

27 septiembre, 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)

14 julio, 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)

5 julio, 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

23 mayo, 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.

Seguir

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

Únete a otros 39 seguidores