Posts Tagged ‘gestion de proyectos’

h1

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

04/29/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

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

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

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

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

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

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

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

Pic: Wright Brothers' Prototype Designs


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

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

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

(Fuente: NASA)

Mejores Prácticas

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

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

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

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

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

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

Fases de implementación

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

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

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

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

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

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

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

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

Recomendaciones adicionales

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

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

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

Conclusiones

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

h1

¿Qué es la estrategia TI Bimodal (Bimodal IT) y cómo podemos implementarla?

01/08/2016

Wizdoc [Icon By Buuf]  Tips & Tricks.

No importa qué tan lento vayas, siempre y cuando no te detengas.

Confucio (551 – 479 AC). Profesor, editor, político y filósofo chino.

Hace un par de semanas tuvimos una reunión con cliente relacionada a su estrategia TI y cómo piensa crecer durante el próximo año fiscal. Durante la junta salieron a relucir algunas palabras clave como innovación o implementación ágil. Sin embargo, la frase que nos dio la respuesta a lo que realmente está buscando, se resume en dos palabras: estrategia bimodal. ¿De qué se trata? ¿Por qué algunos la están considerando como la nueva panacea que asegurará la competitividad de las organizaciones TI? ¿Y cuáles son los riesgos encontrados durante su adopción?

Durante el Simposio/ITxpo llevado a cabo por la firma de consultoría e investigación de mercado Gartner en Octubre de 2014, el vicepresidente senior y jefe global de investigación, Peter Sondergaard, señaló que mientras los CIOs no sean capaces de transformar sus departamentos TI de manera que sean más ágiles y competitivos, podrán convertir sus organizaciones mediante un modelo TI Bimodal; de hecho, según Gartner, para el 2017, el 75% de las organizaciones de TI tendrá una capacidad bimodal. Este modelo se describe como “La práctica de gestionar dos modos distintos y coherentes de ejecución de TI, uno centrado en la estabilidad y el otro en la agilidad. El Modo 1 es tradicional y secuencial, haciendo hincapié en la seguridad y precisión. El Modo 2 es exploratorio y no lineal, con énfasis en la agilidad y rapidez.” Así, la organización tendrá dos maneras de llevar a cabo sus iniciativas TI:

Modo 1

• Involucra a proyectos relacionados con el mantenimiento de los sistemas centrales (core systems) – usualmente las bases de datos y sistemas legados.
• Se centra en proporcionar estabilidad y eficiencia, respetando los ciclos de desarrollo más tradicionales, como cascada.

Modo 2

• Involucra a los proyectos que ofrecen innovación y agilidad para el negocio.
• El foco está en la respuesta rápida, mientras trabaja en liberaciones frecuentes (básicamente, desarrollo ágil de software).

No tan rápido

Sin embargo, el problema que intenta atacar Gartner no es nuevo (agilidad vs. estabilidad); por el contrario, si no se lleva a cabo de manera adecuada, el modelo bimodal puede degenerar en una lucha de poder entre las dos áreas, ya que es indispensable una colaboración transparente entre ambas con el afán de agregar valor de negocio. Las consecuencias, descritas en la revista CIO Insight, se enumeran a continuación:

• La primera y de mayor impacto sería la creación de silos artificiales para productos, procesos y personas. Esta es la dirección opuesta a toda tendencia organizacional saludable de TI desde que el término “síndrome del silo funcional” fue acuñado por Phil Ensor en 1988. TI Bimodal en silos significa lanzarse al ruedo precipitadamente, ignorando numerosos estudios publicados durante los últimos cuatro decenios.

• Estancamiento del Modo 1: El enfoque bimodal propone aplicar una curita sobre la herida que representan las plataformas tradicionales, pero no hace nada por detener la hemorragia. Este modelo institucionaliza el estancamiento, al desalentar la innovación en plataformas legadas bajo el pretexto de que “si no está roto, no lo arregles”.

• Rigidez del Modo 2: En palabras de Gartner, “el Modo 2 requiere un enfoque riguroso y disciplinado”, así que el modelo bimodal prescribe un flujo de proceso definido, previsible y lógico en torno a lo que en esencia, es un proceso impredecible para la experimentación y el descubrimiento. Algo así como “Pintura por números para la obra de Jackson Pollock.”

• Sobre-simplificación de procesos: Las nuevas aplicaciones se acuñarán en torno a uno de dos modos y serán siempre encerradas en un modus operandi que sin duda resultará ser inadecuado a largo plazo. TI Bimodal cierra las puertas a las aplicaciones legadas del Modo 1 para evolucionar a las ofertas ágiles del Modo 2; por el contrario se endurecerán las condiciones para que un prototipo ágil del Modo 2 pueda convertirse en una oferta de servicio más estable de acuerdo al Modo 1.

¿Cómo implementarla?

Aunque TI Bimodal suena bastante razonable sobre el papel, en la práctica los principales retos a sortear incluyen la priorización de los proyectos, la distribución de recursos entre ambos modos, integración o intercepción de proyectos (ya que por ejemplo, una aplicación móvil no es nada sin un back-end estable que la soporte) y cómo mantener a la organización, proveedores y socios de negocios apegados a esta visión. En pocas palabras, para alcanzar la meta planteada, es fundamental definir un gobierno TI o governance adecuado. Aunque la definición completa de un gobierno TI no es el objetivo de este post, baste decir que éste debe incluir los siguientes puntos:

• La alineación entre la estrategia de la organización y las TI.

• Obtención de valor que las TI generan para la organización.

• Mecanismos que permitan mediciones apropiadas para poder valorar las TI en su conjunto y poder tomar decisiones respecto a su gobierno.

• Gestión del riesgo que en un momento dado pueda afectar e impactar negativamente en las actividades y procesos de la organización.

• Gestión de los recursos TI y la utilización óptima de los mismos.

El gobierno TI debe facilitar un modelo transparente en el que todos los interesados tengan visibilidad sobre el día a día de las operaciones y el avance del programa estratégico. Asimismo, el modelo debe proveer una comunicación y priorización claras, que ayuden en la detección y resolución de problemas más rápidamente. Por ello, el proceso de gobierno debe abordar los siguientes tres niveles de revisión:

1. Estratégico: Cuando a un nivel de dirección ejecutiva, los diferentes grupos de interés puedan mantener y hacer crecer la relación (evitando caer en luchas de poder), resolviendo asuntos importantes, manteniendo la dirección establecida y aprobando los cambios estratégicos y el plan para el futuro.

2. Táctico: Donde a través de reuniones periódicas de los grupos de interés, éstos son capaces de asegurar que se está avanzando de acuerdo a los objetivos generales del programa.

3. Operacional: Cuando todos son capaces de trabajar sobre una base del día a día para ofrecer los servicios y entregables TI, respondiendo a peticiones, problemas y consultas, en línea con los objetivos del programa.

Pic: Bimodal IT Governance Example


Para que TI Bimodal – o cualquier otra estrategia de TI – tenga éxito, la visión tiene que ser compartida por todos los niveles de la organización: la alta dirección, proveedores, socios de negocio, gerentes de proyecto y equipos de trabajo por igual. Además, el éxito se mide no sólo por la entrega de valor a la organización de TI, sino por el valor del negocio; es decir, que la estrategia TI beneficia al negocio de una manera cuantificable. El éxito del programa, por lo tanto, debe ser comunicada a todos los niveles de la organización.

Parafraseando a George Orwell, aunque los tres niveles de revisión son igualmente importantes, algunos son más iguales que otros: el nivel estratégico tiene como principal responsabilidad mantener alienada la estrategia con los objetivos de negocio, monitoreando el desempeño de las demás áreas y detectando y resolviendo cualquier riesgo de alto nivel que se llegue a presentar; por otro lado, el nivel operativo lleva a cabo los proyectos individuales, reportando su progreso y asegurándose que las métricas impuestas por los otros dos niveles se cumplan. Sin embargo, el nivel que es crucial durante la implementación es el nivel táctico (la Oficina de Gestión de Proyectos o PMO, así como el Centro de Excelencia o CoE) ya que tiene por principal responsabilidad:

• Generar estándares y procesos, así como seleccionar las herramientas y tecnologías que usará el resto de la organización.

• Revisar el rendimiento y apego a normas de desempeño acordados para todos los grupos.

• Desarrollar el programa de implementación de la estrategia.

• Llevar a cabo el presupuesto, planeación y asignación de recursos.

• Asegurarse de que todas las políticas, planes, normas, etc. permean a los equipos de la organización.

• Resolver problemas tácticos escalados con el Comité de Gobierno estratégico (Steering Committee) y

• Escalar problemas al Comité de Gobierno cuando sea apropiado (por ejemplo, asuntos contractuales).

Algunos tips durante la adopción de este modelo

La gran ventaja de Bimodal es que la organización ya debería poseer un área de operaciones/desarrollo relativamente madura trabajando en Modo 1; esta madurez es precisamente la que asegura una implementación ordenada y estable, pero impide que iniciativas “para ayer” se concreten eficazmente. Por lo tanto, el proceso de adopción debe enfocarse a la creación del Modo 2 y cómo sus equipos deben interactuar y coordinarse eficientemente con los equipos del Modo 1. Por lo tanto, una adopción debe considerar entre otros, los siguientes puntos dentro del programa de implementación de estrategia:

• Una evaluación de la capacidad (readiness assessment) para convertir un segmento de la organización al Modo 2 de operación. Esto permitirá saber qué equipos y proyectos pueden generar el mayor valor de negocio en el menor tiempo posible. Por ejemplo, los proyectos más apropiados para llevarse a cabo en el Modo 2 son aquellos que poseen 1) fechas de entrega muy agresivas, 2) un alto grado de complejidad, y 3) un alto grado de innovación.

• Identificar uno o varios coaches versados en el Modo 2 de operación – Scrum, Lean, Kanban, V-Model, etcétera – que puedan resolver las dudas durante la implementación. Éstos por supuesto, deben ir de la mano con el Centro de Excelencia para definir los procesos, herramientas y entregables de gestión y desarrollo ágil que adoptará la organización.

• En caso de que los equipos del Modo 2 se hayan integrado con el personal original de la organización, es indispensable enfocarse en el cambio cultural. Si bien las prácticas y herramientas ágiles son importantes, establecer una mentalidad ágil es indispensable. Esto implica creer firmemente en el empowerment, liderazgo subordinado o equipos multidisciplinarios. El beneficio es que aseguramos una mentalidad de colaboración y urgencia para satisfacer las cambiantes demandas del negocio.

• Para el momento en que se inicie el delivery de equipos en el Modo 2, ya se debe haber seleccionado una herramienta de planeación (por ejemplo, JIRA o VersionOne), se debe haber proporcionado el entrenamiento adecuado a los equipos y se deben haber definido las métricas mínimas para que de manera periódica, pueda existir una rendición de cuentas al Comité de Gobierno.

• Finalmente, una vez que se han dado los primeros pilotos de adopción del Modo 2 y se ha establecido la manera en que ambos tipos de equipo estarán colaborando, es indispensable generar un proceso de mejora continua para perfeccionar la integración de todos los interesados. Para este momento, iniciar la estandarización – por ejemplo, certificar los proyectos corriendo en Modo 1 en CMMi-5 y los proyectos ejecutados en Modo 2 en CMMi-3 – ya es posible.

Conclusiones

La estrategia Bimodal NO es la bala de plata. Es tan sólo un paso intermedio hacia la introducción de prácticas como DevOps. A final de cuentas, lo que cualquier organización debe buscar, es la convergencia para actualizar sus procesos e infraestructura a la realidad del mercado. Hace algún tiempo, el analista independiente Jason Bloomberg dio su propio punto de vista al respecto de lo que él llamó una “receta para el desastre” de Gartner, añadiendo su propia recomendación: … para que la transformación digital tenga éxito, debe ser de extremo a extremo – con los clientes en un extremo y los sistemas legados del otro. TI tradicional, por supuesto, sigue siendo responsable de los sistemas legados.

Así, el enfoque debe ser el de empresas exitosas como Apple, Amazon o Google:

• ¿Cómo podemos deleitar a los clientes con nuevos productos y un mejor servicio?

• ¿Cómo se puede mejorar continuamente nuestro negocio con pequeños incrementos?

• ¿Cómo podemos optimizar la cadena de valor?

• ¿Cómo nos aseguramos de que el negocio impulsa el cambio y no el departamento de TI o marketing?

La clave reside en contestar estas preguntas honestamente y trabajar en ello… o formar parte del registro fósil de empresas fallidas, junto a anti-ejemplos tales como Eastman Kodak, PanAm y Compaq.

h1

Adrenaline Junkies and Template Zombies

08/28/2015

Wizbook [Icon By Buuf]  Libros.

No existen los fracasos – sólo experiencias y tus reacciones a éstas.

Tom Gunnar Krause (1934 – 2013), cantante bajo-barítono y maestro de canto finlandés.

En el área de TI en general y el desarrollo de software en particular, es poco frecuente encontrar un “hombre orquesta” que pueda llevar por sí mismo proyectos complejos o de alta criticidad. Hoy por hoy, la industria requiere de equipos de trabajo compuestos por personal de diferentes áreas – gerentes, programadores, DBA’s, especialistas en dominio de negocio – quienes deben colaborar de manera efectiva para alcanzar los objetivos propuestos por la organización o proyecto. Sin embargo, aunque la literatura se enfoca a las habilidades individuales y cómo debe gestionarse el proyecto, muy pocos autores se han enfocado al tema de la cultura organizacional y cómo ésta puede entorpecer o apoyar al cumplimiento de estos objetivos.

Es así como “Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior” por Tom de Marco et al. nos presenta un compendio de 86 patrones de comportamiento – buenos, malos y el ocasional wtf – encontrados en nuestros proyectos y organizaciones. Es un libro dirigido a los practicantes del team leadership o project management, y aunque no es demasiado formal, las narrativas de cada uno de estos patrones nos permiten identificar si vamos por el buen camino, o si estamos cayendo en esas dinámicas de grupo en las que el resultado no será nada agradable. Los autores no se toman a sí mismos demasiado en serio, por lo que muchos que ya tenemos varios años en este negocio, recordaremos con una sonrisa aquellas “tragedias griegas” que hemos experimentado a lo largo de nuestra carrera. A continuación incluyo algunos de los patrones más valiosos que encontré en este ejemplar:

2. Rattle yer Dags: El equipo exhibe un sentido palpable de urgencia para determinar quién debe hacer qué para cuándo, y un deseo de llevar a cabo todas las acciones necesarias inmediatamente.

8. Contacto visual: La organización tiende a co-localizar al personal del proyecto cuando el trabajo es urgente y complejo.

31. Ritmo: El equipo establece un ritmo de trabajo mediante entregas en intervalos regulares.

33. Noche de Póker: Los empleados de toda la organización se reúnen para realizar actividades que no están vinculadas a sus funciones de trabajo.

56. Toda la atención: La participación de tiempo completo en un solo proyecto mejora el rendimiento individual.

66. Seelenverwandtschaft: La organización permite que un equipo particular deje fuera incluso las reglas más fundamentales de su proceso de desarrollo.

75. La puerta del refrigerador: De manera rutinaria, los miembros del equipo exponen los frutos de su trabajo para que los demás los vean.

78. Razones para el cambio: Se abren ventanas de oportunidad para cambios de alcance específicos durante todo el proyecto, usualmente alineados con los límites de iteraciones de desarrollo.

Es interesante ver cómo sin realmente proponérselo, los autores nos muestran que buena parte de los patrones positivos encontrados en el libro pertenecen a la filosofía ágil: si bien éstos son nombrados de diferente manera (por ejemplo, la “puerta del refrigerador” es mejor conocida como “radiadores de información” en el ámbito ágil), todos estos patrones permiten mejorar la productividad del equipo, mientras al mismo tiempo, facilitan elementos clave de la gestión de proyectos, como la comunicación, la propiedad compartida sobre los entregables y un mejor control del alcance del proyecto.

Por otro lado, el problema que tengo con el libro es que éste sólo describe la dinámica resultante, sin dar mayores explicaciones. Esto es especialmente aparente en los patrones negativos: aunque son muy jocosos – o mejor dicho, tragicómicos – la realidad es que una vez que nuestros proyectos tienden a permanecer en el lado negativo de las cosas, el lector tendrá que depender de su propia experiencia y habilidades para modificar el entorno de trabajo y prosperar, o mantenerse en un curso directo al desastre. Por ejemplo, uno de los capítulos que demuestra este punto es la “jerga de proyecto” o project-speak: palabras y frases que suenan inofensivas a primera vista, pero que disfrazan ideas nefastas:

CUANDO ELLOS DICEN: REALMENTE QUIEREN DECIR:
El calendario es agresivo. Estamos fritos.
Vamos a compensar la metedura de pata en las próximas iteraciones. Seguimos estando fritos.
Él es el hombre clave. Él está frito.
resumen ejecutivo versión de tira cómica
alto nivel que no es de verdad
acumulación rápida de personal (rapid staff buildup) si una mujer puede tener un bebé en 9 meses, trayendo 9 mujeres a bordo tendremos un bebé en un mes, ¿cierto?
Gerente de Proyectos Especiales gestiona su propio escritorio
Venimos del corporativo y estamos aquí para ayudar. (No necesita mayor explicación)
El trabajo continúa. No tenemos ni idea.
El tiempo lo dirá. No tenemos ni idea, y lo admitimos.
Esta ha sido una experiencia de aprendizaje. Realmente jodimos esto.
Una vez dicho esto… Todo lo que he dicho anteriormente eran tonterías.
código completo no probado
Estás facultado. (empowered) Te toca cargar con la culpa de esto.
fruta madura (low-hanging fruit) Algo que incluso [insertar nombre] no puede estropear.
Pongamos esto atrás y sigamos adelante. (significa lo mismo que cuando un político lo dice)
Ahora, toma mi consejo. Te supero en rango.
El código se ha vuelto inmantenible. Yo lo hubiera diseñado de otra manera.
Todavía estamos a 30,000 pies. Está en mi escritorio, sin tocar.
Bradley aquí es nuestro comodín. Bradley aquí es el idiota del proyecto.
Mantente en la misma página. Hazlo a mi manera.
mejor práctica inventado por las personas que no trabajan aquí y por lo tanto infinitamente superior a todo lo que hacemos
Apalanca las competencias básicas (core competencies). No hagas la parte difícil.
Hazlo fuera de línea. Haz que desaparezca.
Tienes un nuevo enfoque. Eres un imbécil.
Las pruebas han resultado ser un cuello de botella importante. Se mantienen encontrando errores.
liberación limitada liberación sin funcionalidad
Déjame clarificar lo que necesito ¡Vienen nuevos requerimientos!
Estamos considerando nuestras opciones. la única que tenemos.
Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. Tom DeMarco, et al. (Dorset House, 2008).


Y… eso es todo con respecto a este tema: puede ser divertido conocer el significado real de aquellas frases usadas recurrentemente por el jefe o el cliente, pero ojeando a través del libro, es imposible encontrar cómo contrarrestar este lenguaje complicado y casi sin sentido (tip: es necesario demostrar honestidad y transparencia durante nuestras interacciones con otros, porque debemos entender que la deshonestidad crea incomodidad y duda entre aquellos con quienes estamos negociando; sin confianza o respeto mutuo sólo estamos postergando lo invetiable: una dolorosa ruptura). Por ello, Adrenaline Junkies debería considerarse como una serie de situaciones y anécdotas personales – historias de guerra si así lo queremos ver – pero de ninguna manera puede ser valorado como un libro con soluciones puntuales a una mala cultura corporativa afectando nuestros proyectos. Todo puede resumirse en “oh, sí; he pasado por esto antes”, pero jamás exclamaremos “Ahh, es por eso que este proyecto terminó en desastre…”

Así que, para aquellos que están iniciando sus carreras como gerentes o líderes de proyecto, será necesario buscar en otras publicaciones la razón de su falta de sueño y qué herramientas se requieren para coger al toro por los cuernos. Para los que ya tienen experiencia, es un buen retrato de lo que hemos tenido que soportar, y puede usarse como referencia para recordarnos cómo detectar aquellos olores que apestan nuestro proyecto, antes de que se conviertan en una historia de horror.

h1

De propuestas comerciales y tiempo con el jefe

08/29/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

Una medida del liderazgo es el calibre de la gente que decide seguirte.

— Dennis A. Peer, autor y consultor organizacional Estadounidense.

Estas últimas cuatro semanas han sido una completa locura. En la empresa donde laboro armamos una propuesta por alrededor de 150 personas y un tiempo de unos 5 años de engagement que incluye gente de México, India y Reino Unido. Es un proyecto multimillonario, que por obvias razones captó la atención de global management, quienes han estado revisando con lupa cada una de las cifras planteadas en la propuesta, incluyendo staffing, presupuesto, planes de proyecto y todo lo demás. Con decir que el detalle requirió de montos presupuestarios y costos mensuales por persona, a lo largo de esos cinco años. Al final de un esfuerzo inmenso logramos reunir el equivalente a un directorio telefónico con todo el detalle esperado por el cliente; el próximo miércoles nos estaremos desplazando a sus instalaciones para realizar nuestro oral presentation; desde el día de ayer ya se está haciendo el trámite de los vuelos para aquellos que vendrán desde offshore.

Ahora bien, últimamente he pasado mucho tiempo colaborando con el equipo extendido para la redacción de este documento: gente comercial, del área de delivery y hasta personal de recursos humanos, especialistas en finanzas y gerentes de transformación organizacional; tanto así que durante las últimas semanas he interactuado con mi delivery manager más tiempo de lo que había hecho durante los seis meses previos. Esto nos lleva a la siguiente interrogante: ¿cuál es el monto ideal de tiempo que nosotros deberíamos pasar con el jefe?

Pic: The Office's Michael Scott

“Soy amigo de todo el mundo en esta oficina. Todos somos los mejores amigos. Me encanta todo el mundo aquí. Pero a veces tus mejores amigos empiezan a llegar tarde al trabajo y empiezan a tener citas con el dentista que no son citas con el dentista, y es cuando es bueno hacerles saber que puedes darles una paliza.” (Fuente: tvcomedies.about.com)

Muchos responderán: “lo menos posible”. En realidad, de acuerdo a un estudio generado por la firma de consultoría Leadership IQ, nuestra inspiración, compromiso, innovación y motivación mejoran substancialmente si pasamos alrededor de seis horas a la semana interactuando con nuestro supervisor inmediato, incrementando en 29%, 30%, 16% y 15% sus valores, respectivamente. En el caso de los ejecutivos y gerentes medios, una relación aún más cercana con los jefes se vuelve crítica, pues es necesario pasar entre ocho y diez horas de colaboración cercana para alcanzar estos valores máximos de productividad. Por el contrario, si pasamos demasiado tiempo con él, nuestro desempeño empieza a decaer, ya que los niveles de inspiración y motivación se mantienen sin cambios o declinan después de este tiempo ideal. Así, el tiempo considerado como óptimo que debemos pasar con nuestro manager debe abarcar entre una y dos horas al día.

Claro que, esto se debe en parte al tiempo extra que pasamos con el mandamás: esa cantidad de interacción (de hasta el 25% del día de trabajo) permite conocernos uno al otro de una forma más íntima: qué nos motiva, cuáles son nuestras expectativas o qué pensamos realmente de la organización. En fin, conocer mejor al ser humano enfrente de nosotros, mejorando nuestra dinámica de grupo. Y esto porque en un post anterior ya había comentado que a la hora de motivar a los empleados es necesario demostrar un interés sincero por ellos: el jefe no debe ver a sus subordinados como “recursos humanos”, sino como colaboradores sin los cuales él está frito, mientras los empleados deben ver al jefe no como un capataz desalmado que no los comprende, sino como una persona que depende de su buen desempeño para alcanzar los objetivos que le han sido impuestos.

Sabiendo que nosotros deberíamos pasar alrededor de seis a diez horas a la semana con nuestro líder, ¿cuánto tiempo realmente lo pasamos trabajando juntos? De acuerdo al mismo estudio, que abarcó a cerca de 30,000 profesionistas, resulta que 48% de ellos pasa tres horas o menos interactuando con sus respectivos jefes. Y lo más extraño del asunto, es que de acuerdo a los entrevistados, hasta para aquellos que sentían que no se valoraba su trabajo, existía una fuerte relación entre el tiempo que pasaban juntos y estos sentimientos de inspiración y motivación. En pocas palabras, sin importar si creemos que nuestro jefe es un chambón o un cascarrabias, es indispensable pasar un mínimo de seis horas a la semana interactuando en conjunto – de preferencia cara a cara – para mejorar nuestro sentido de pertenencia y lealtad hacia la compañía. De manera inversa, si somos líderes, gerentes o directores, tenemos que evitar distanciarnos de nuestra gente; por el contrario, si queremos que ellos respondan como queremos, debemos ir directamente a las trincheras e involucrarnos en los quehaceres del día a día, sin dejarnos consumir por las tentaciones del micromanagement. Si los subordinados ven que estamos interesados en el éxito de nuestros proyectos y no tenemos miedo de subirnos las mangas y “mancharnos de lodo” de vez en cuando, ellos nos seguirán sin dudarlo. Todo esto porque la diferencia entre chicotear y guiar es lo que distingue a los verdaderos líderes de los “jefes”.

h1

¿Cuál es el rol de un Scrum Master en un proyecto ágil?

07/04/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

Caminar sobre el agua y desarrollar software a partir de una especificación son fáciles… si ambos están congelados.

— Edward V. Berard, ingeniero de software y autor estadounidense.

Desde hace tiempo, he venido predicando y evangelizando acerca de las metodologías ágiles; especialmente Scrum y Extreme Programming. Ahora bien, muchos de los neófitos suelen ser muy cautelosos y hasta escépticos en cuanto a los beneficios que éstas pueden aportar. Una de las preguntas más comunes que he escuchado, consiste en qué rol debe tomar un Scrum Master (SCM) como parte del proyecto ágil; la gran mayoría cree que el SCM es un “administrador de proyectos” o “líder técnico”, quien debe asumir la responsabilidad sobre el proyecto y los integrantes del equipo, dirigiendo las tareas o asignando responsabilidades durante de la ejecución del mismo. Nada más alejado de la verdad, ya que el SCM es el guardián del proceso… y no mucho más. De hecho, si el equipo de trabajo ya cuenta con el conocimiento necesario para llevar a cabo las ceremonias y generar los artefactos de manera adecuada, en cada ciclo o iteración de desarrollo es posible que el rol de Scrum Master sea tomado por algún miembro del equipo diferente en cada ocasión; no necesariamente el responsable técnico o el más senior del grupo. Debido a esto, presento a continuación las tareas desempeñadas por un SCM como parte de un proyecto, basándome en mi propia experiencia durante estos últimos años:

Se coordina con el Product Owner (PO). Un Scrum Master debe trabajar en conjunto con el PO para facilitar las actividades requeridas y cumplir con el release. Estas actividades incluyen aportar activamente durante la priorización del backlog, rastrear actualizaciones relacionadas al sprint actual, alzar la mano cuando se detecte algún riesgo, o trabajar con el PO para seleccionar los elementos a implementar durante el siguiente sprint.

Se convierte en el enlace entre el equipo de trabajo y el Product Owner. En muchas ocasiones, el PO es una persona con un background de negocios, por lo que hablarle en bits y bytes puede convertirse en todo un reto; esto es especialmente crítico, ya que para que Scrum sea exitoso, es necesaria una interacción constante entre el Product Owner y los desarrolladores. Por ello es importante que el Scrum Master mantenga a todos en sintonía, ya sea mediante sesiones grupales para aclaración de dudas o reuniones “uno a uno” donde el Scrum Master participa como moderador. De acuerdo a mi experiencia, el equipo usualmente pregunta poco durante la sesión de planeación del sprint, dejando casi todas las dudas para sesiones de preguntas y respuestas posteriores. Entonces, es recomendable calendarizar este tipo de reuniones una vez que inicie el análisis de historias de usuario, incluso a manera de reverse knowledge transfer, en el que el desarrollador le explica al PO, en sus propias palabras, qué es lo que entendió de la historia de usuario a implementar. Así mismo, para evitar que una sesión de este tipo se convierta en una reunión maratónica, es una buena idea acordar un tiempo fijo o timebox. El SCM debe entonces evitar que la reunión se desvíe del tema principal y todos los involucrados vayan directo al grano.

Facilita la demostración del sprint y la retrospectiva. El SCM es usualmente el indicado para calendarizar y facilitar la revisión al final del sprint, en la que los miembros del equipo muestran a los stakeholders el trabajo terminado. Ya que seguramente los participantes harán preguntas y proporcionarán retroalimentación al equipo, el Scrum Master puede actuar como escriba o moderador. Para las retrospectivas, un SCM experimentado puede ayudar a que los participantes “se aflojen”, para que las preguntas ¿Qué salió bien? ¿Qué salió mal? ¿Cómo podemos mejorar para la próxima en base a nuestras lecciones aprendidas? Puedan contestarse de forma honesta y ordenada, ayudando a que el equipo se concentre en cómo mejorar, en vez de designar culpables. Para proyectos pequeños o medianos en los que existan de uno a tres equipos de desarrollo, la revisión al final del sprint así como la retrospectiva pueden realizarse de manera combinada mediante videoconferencia; cuando el staffing del proyecto sobrepase más de 30 participantes, es mucho más cómodo que el equipo líder (Scrum de Scrum Masters, Arquitecto Líder, Product Owner de Product Owners) sea la única voz de cara a los stakeholders; dejando a cada equipo hacer sus propias retrospectivas.

Protege al equipo del Product Owner. El Scrum Master debe impedir a como dé lugar que el objetivo del sprint cambie una vez que ha iniciado. Si el SCM se da cuenta que el PO está cambiando los objetivos a mitad del sprint, su labor deberá ser la de negociar con el Product Owner cómo intercambiar historias de usuario equivalentes en esfuerzo de acuerdo a la prioridad de entrega, dejando las historias removidas de vuelta en el product backlog para su posterior implementación. Esto no es ideal, pero es bastante más sano que cancelar el sprint completo. Por otro lado, si esta re-priorización se vuelve la norma, es aconsejable adoptar un modelo de Scrumban, en el que se acuerda con el PO limitar el monto de trabajo por fase (por hacer, en ejecución, terminado), permitiendo intercambiar las tareas o entregables en cualquier momento. También es recomendable aclarar con el Product Owner que este intercambio de tareas tiene un costo: el “cambio de contexto” o tiempo mínimo necesario para cambiar de la tarea A a la tarea B, puede incrementar hasta en 24% el tiempo del proyecto si se le usa de manera constante.

Representa al equipo en el Scrum de Scrums (SoS). Sólo stakeholders de alto nivel participan en esta reunión. Si el equipo tiene múltiples reuniones internas, típicamente cada SCM representará a su equipo en un SoS. El Scrum Master puede ir acompañado durante esta reunión, ya que cualquier miembro del equipo puede proporcionar estas actualizaciones. Sin embargo, el SCM es quien debería saber lo que está pasando con su equipo en todo momento, y debería estar al tanto de cualquier plan de acción que pretenda llevarse a cabo. Durante el SoS es bastante común que se discutan cuestiones de diseño técnico así como reglas de negocio e impedimentos que afecten al proyecto en su conjunto, tales como problemas de infraestructura y regulatorios. Los participantes idealmente deberán ser Scrum Masters, Product Owners, arquitectos, gerentes de proyecto, etcétera.

Facilita los daily standups. El scrum diario es una reunión en la que los miembros del equipo proporcionan actualizaciones sobre su trabajo, comentando qué hicieron ayer, que piensan hacer hoy y qué obstáculos se encuentran en su camino. El SCM debe asegurarse que los standups tengan una duración definida y que la conversación fluya correctamente – es decir, evitar concentrarse en los detalles o permanecer demasiado tiempo hablando acerca de un tema particular. Si es necesario, el Scrum Master puede tomar nota y calendarizar sesiones adicionales para tratar temas puntuales.

Ayuda a remover impedimentos que bloqueen el trabajo del equipo. Esta es de hecho, la tarea más importante que debe desempeñar el Scrum Master. Si el equipo se enfrenta a un reto que impida entregar el trabajo acordado, el SCM debe entender de qué se trata y cómo resolverlo, coordinándose con otros stakeholders para “despejar el camino”. Si el problema está “fuera de su jurisdicción”, es indispensable que el Scrum Master escale el problema lo más pronto posible.

Se convierte en un coach ágil. En caso de que algún miembro del equipo no conozca del todo el proceso ágil, es responsabilidad del Scrum Master que todos aprendan y sigan las prácticas de la metodología correctamente.

Tiene que hacer cumplir la definición de Terminado. El SCM debe asegurarse que el equipo se adhiere a la “Definición de Terminado”; es decir, una lista previamente negociada y aceptada entre los integrantes del equipo, en la que se define bajo qué criterios el trabajo es considerado como finalizado. Por ejemplo, (1) debe cumplir con los criterios de aceptación definidos en la historia de usuario, (2) las pruebas unitarias, de integración y de aceptación deben haber sido terminadas, (3) deben existir cero defectos de severidad alta y (4) la revisión de código por algún colega debe haberse completado.

Facilita la sesión de planeación. La sesión de planeación es aquella en la que el equipo decide el objetivo del sprint y cuáles elementos del Product Backlog serán seleccionados para implementarse durante la presente iteración. Usualmente durante los primeros sprints, el Scrum Master es quien definirá o reforzará las reglas del Planning Poker usado para dimensionar las historias de usuario en términos de puntos de historia (por ejemplo: la serie de Fibonacci o “puntos perro“).

Conclusiones

Aunque la mayoría de las actividades que desempeña un SCM han sido cubiertas en este post, pueden presentarse muchas más actividades que dependen de la naturaleza del proyecto. Por ejemplo, en un equipo de desarrollo, el SCM era un excelente arquitecto en Java, por lo que además de sus funciones como Scrum Master, colaboró con el líder técnico del equipo para definir una arquitectura que fuese fácil de implementar y mantener. Por otro lado, en un caso que me tocó personalmente, en el que desempeñando la labor de Scrum de Scrum Masters, también tenía que fungir como Program Manager, llevando el tracking de varios equipos y proyectos operando simultáneamente, comunicando el avance y problemas a la alta dirección mediante presentaciones especialmente hechas para este fin – así es, de esas con portafolios, semáforos y “tiburones” listos para desayunarse al presentador si ellos ven algo que no les gusta.

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%.