Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Valor del negocio. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Valor del negocio. Mostrar todas las entradas

viernes, septiembre 11, 2015

Gerencia de Proyectos Iterativos: de cómo el software se puede construir por incrementos

Divide et impera: ‘divide y vencerás’. Frase atribuida a Julio César.
FreeDigitalPhoto.Net
Los proyectos de construcción de software deben responder con prontitud a los cambios frecuentes e inesperados tanto en los requisitos del negocio como en la tecnología de implementación. Es habitual que en estos proyectos haya una gran incertidumbre en cuanto al alcance, a la fecha de entrega y al presupuesto requerido, lo que conlleva un alto número de riesgos que obstaculizan la consecución de los objetivos propuestos.
Por ejemplo, es un grave error con consecuencias atroces, asumir que los usuarios –generalmente personas de mandos medios y altos– son capaces de suministrar al equipo del proyecto información oportuna y precisa de todos los requisitos para un sistema de software. Además, uno de los problemas principales de la construcción de software tradicional recae en el hecho de que quienes han estado involucrados en ello hasta la fecha no están dispuestos a reconocer que esta actividad es, la mayoría de las veces, un asunto de planeación ocupacional y organizacional.
Corresponde precisamente al gerente del proyecto lidiar con todos estos factores que entorpecen la evolución normal de un proyecto de software. Es el gerente del proyecto quien sabe que los procedimientos tradicionales seguidos tienen un conjunto de riesgos tácitos “indetectables” dada la propia naturaleza del ciclo de vida de los proyectos. Los proyectos iterativos propician la detección temprana de los riesgos y facilitan su manejo anticipado por parte de los responsables. Pero ¿qué es realmente un proyecto iterativo? Para entenderlo, veamos lo fundamental.
¿Qué es una Iteración?
Una iteración es un mini-proyecto con una salida bien definida: una versión incrementada, estable, probada e integrada del producto de software, con su documentación asociada.
Esta definición lleva implícito un concepto muy importante: la versión o porción de software que se produce en una iteración tiene tales cualidades que se podría no solo mostrar al usuario sino poner en producción. De hecho, en fases avanzadas del proyecto, esto ocurre con regularidad; es decir, en un proyecto iterativo es posible tener versiones del software funcionando antes de terminar el proyecto.
Características de las Iteraciones
Ahora bien, como cualquier proyecto (de software), una iteración pasa por todas las etapas de un proyecto tradicional: inicio, planeación, ejecución y control, y cierre. En el caso particular de los proyectos de software, durante la etapa de ejecución y control de una iteración encontramos el ciclo tradicional del software: modelado de requisitos, análisis y diseño, implementación, pruebas, integración y, opcionalmente, despliegue, aunque una iteración no necesariamente cubre todas las etapas.
Pero la verdadera esencia de las iteraciones radica en otros aspectos que buscan disminuir la incertidumbre en los proyectos, aumentar el desempeño, mitigar los riesgos, sobre todo reducir los riesgos técnicos en las primeras iteraciones, y recibir retroalimentación continua y efectiva de los usuarios. El primero de estos aspectos es la duración de las iteraciones: de unos pocos días hasta unas pocas semanas es lo más eficaz, aunque también depende del tamaño del equipo y de la duración total estimada del proyecto.
Figura 1: esquema de una iteración típica. Cada iteración es un mini-proyecto con todo lo que ello implica.
Excepto quizás en proyectos grandes con más de 40 o 50 personas, la idea es no tener iteraciones de varios meses, ya que en ese tiempo puede ocurrir lo que sucede en los proyectos ejecutados en cascada: hay poca o ninguna mitigación de riesgos técnicos, puesto que no hay entregas “visibles” para los usuarios, recibimos poca retroalimentación de ellos y así no medimos eficientemente el progreso del proyecto, o no podemos reaccionar a tiempo ante una mala decisión técnica que conduzca a un retraso en el proyecto.
Duración de las iteraciones
Número de personas
Duración
2 a 15
2 a 4 semanas
15 a 30
4 a 6 semanas
30 a 50
6 a 8 semanas
Fuente: Bittner, K. Spence, I. Managing Iterative software Development Projects. Addison Wesley Professional. Junio 27, 2006.
Otro aspecto importante es que la duración de las iteraciones no tiene que ser la misma, pero la desviación debe ser pequeña. La idea es no tener iteraciones de dos semanas y otras de seis o más. Scrum, una metodología ágil ampliamente usada hoy día, por ejemplo, promulga iteraciones de 30 días, llamadas Sprint, con equipos de menos de 10 personas. Y ya que menciono Scrum, me parece importante aclarar que no todos los proyectos iterativos son ágiles, pero todos los proyectos ágiles son iterativos; la iteración es una propiedad intrínseca de las metodologías ágiles de construcción de software.
Gestión iterativa de proyectos
Otra de las características principales de este tipo de proyectos es que en las primeras iteraciones se construye la porción de producto que es significativa para la arquitectura del software. El gerente del proyecto se apoya en el arquitecto y en los ingenieros de requisitos para tomar la decisión de cuántas iteraciones “arquitectónicas” tendrá el proyecto, normalmente de 1 a 3, y qué funcionalidad será implementada, de tal manera que al final de esta fase (llamada de Elaboración, de Planeación o de Arquitectura, según la metodología que se use), no solo existe un documento de arquitectura o de diseño de alto nivel, sino que hay software funcionando cuyo propósito es demostrar que esa es la arquitectura correcta para el producto.
Figura 2: Perfil de los riesgos durante la gestión iterativa de proyectos. Los riesgos técnicos disminuyen en las primeras iteraciones. Contrario a lo que sucedía con el método en cascada, donde los riesgos disminuían al final del proyecto, durante las pruebas en el mejor de los casos.
La gestión iterativa de proyectos puede tomar muchas formas, dependiendo de las metas del proyecto: el desarrollo iterativo de prototipos puede ayudar a evolucionar una interfaz de usuario. El desarrollo ágil es una forma de involucrar muy de cerca un usuario en un proceso que podría repetirse diariamente. Entre tanto, el desarrollo incremental permite al equipo del proyecto a producir incrementos semanales o en cortos períodos de tiempo, mientras que un modelo en espiral puede ayudar al equipo a confrontar y a mitigar los riesgos de un producto en evolución.
En estos casos es el gerente del proyecto quien toma la decisión de la estrategia a seguir, teniendo en cuenta el valor de distintas variables: tamaño del proyecto, tamaño del equipo, experiencia del equipo y de los usuarios, criticidad y complejidad del proyecto, los riesgos técnicos y administrativos, el grado de volatilidad detectada de los requisitos y las herramientas de apoyo disponibles.
Foto de FreeDigitalPhoto.Net
La gestión iterativa ayuda a superar las barreras de especificación y de comunicación entre los usuarios y el equipo de trabajo con el único objetivo de alcanzar la más alta satisfacción de los primeros. El factor clave es precisamente que las personas del negocio entiendan los requisitos y retroalimenten a las personas de tecnología. En este apartado, el papel del gerente es de mediador, por lo que debería incluir elementos de comunicación efectiva, como la tolerancia –cuando no se confunde con la pasividad–, la imparcialidad y la empatía, para construir confianza y disciplina entre unos y otros.
Corresponde al Gerente del Proyecto integrar el equipo de trabajo con todos los involucrados tanto internos como externos y la gestión iterativa posibilita una integración paso a paso. Para lograrlo, el gerente del proyecto debe tener en cuenta algo que está fuera de su control: una infraestructura cambiante y un proceso de negocio inestable. También se debe vincular la estructura del proyecto (iterativo) con el éxito del proyecto, de esta forma, no habrá espacio para la ruina del proyecto.
Esto se logra mediante la motivación interna del equipo de trabajo, el desarrollo de competencias blandas (negociación, técnicas de comunicación –escrita, verbal y no verbal–, manejo eficaz del tiempo, creatividad, trabajo en equipo, entre otras) y la “implantación no invasiva de chips de alta efectividad”, como la proactividad y la sinergia.
Ahora bien, puede haber muchas desviaciones de un plan de proyecto de desarrollo de software. En estos casos, el gerente de proyecto decide cómo manejarlas, puesto que cada retraso requiere de una acción de su parte. Sin embargo, las opciones del gerente son muchas veces limitadas y una de las estrategias que puede seguir es esta de la agenda iterativa. Esto permite corregir o ajustar los planes de trabajo a medida que se desvían de las medidas iniciales.
Por ejemplo, si una iteración toma más tiempo del programado debido a un problema técnico que el equipo del proyecto tardó en responder o a la toma de una decisión por parte del usuario, el gerente puede reprogramar las iteraciones subsiguientes de tal forma que el plan original global del proyecto no se vea afectado.

En cualquier caso, todas las formas de gestión iterativa proporcionan una manera de:
  • Integrar y validar la evolución del producto continuamente
  • Demostrar progreso en cortos períodos de tiempo
  • Alertar pronto al equipo del proyecto de los problemas suscitados
  • Entregar funcionalidad de manera temprana
  • Incorporar sistemáticamente el re-trabajo inevitable que ocurre en el desarrollo de software

En resumen, la gestión Iterativa de proyectos facilita procedimientos para el desarrollo exitoso de aplicaciones y minimizan tanto los riesgos como los costos, combinando técnicas de administración bien estructuradas de métodos en cascada con técnicas de validación temprana del modelo evolutivo. Este proceso es más adaptable a situaciones diversas en proyectos de software y da al gerente la flexibilidad necesaria para acomodarse a un rango dinámico de alternativas técnicas.

Información
Este artículo fue publicado originalmente por la Revista de la Asociación Española de Profesionales en Dirección de Proyectos, en marzo de 2012. Para acceder al artículo original, pueden hacer clic aquí.

domingo, mayo 31, 2015

De Scrum Master bueno a Scrum Master grandioso

Somos lo que hacemos repetidamente. La excelencia, por tanto, no es un acto, sino un hábito.
-Aristóteles
Así que ya eres o te consideras un(a) buen Scrum Master. Bien. Pero algo que aprendí en los últimos años es que siempre hay una acción de mejora, un camino que tomar que nos hará mejores. Qué tal si en vez de quedarnos allí, en ese claustro de “bueno”, damos un paso más allá, quizás más arriesgado, para convertirnos cada día no solo en mejores profesionales sino en personas sobresalientes, grandiosas. Trataré de explicar mi punto en los siguientes apartados:

Aprender del pasado

Quien olvida la historia, la suya y la de su entorno, está condenado a repetirla. Así que revisar una corta lista de cosas que han ido mal en el pasado y analizar con el equipo cómo podrían manejarse si se presentan nuevamente es una forma excelente de evitar esos mismos problemas. Las retrospectivas siempre son bienvenidas, no solo al final de cada iteración o hito del proyecto, sino siempre que se necesiten, como un instrumento de mejora continua.

Un buen Scrum Master hace esto, pero un gran Scrum Master proporciona además ejemplos vivos de lo que pasó, cuenta la historia completa. Recordemos que contando historias es como sobreviven las culturas y en ágil todo es acerca de la cultura. Mediante ejemplos, les decimos a las personas lo que esperamos de una manera diáfana. Si además los ejemplos son lo suficientemente buenos, estaremos proporcionando ideas valiosas sobre cómo los integrantes del equipo pueden lograr la meta final. No solo les estaríamos dando un contexto personal sino también profesional de algo que quizás no logren entender de otra forma.

Más allá de la ‘Definición de Terminado’

Un buen Scrum Master posibilita que el equipo en pleno tenga una Definición de Terminado (DoD); un gran Scrum Master se asegura de que la planificación conduzca a un plan claro y que el equipo en pleno tenga igualmente objetivos claros y alcanzables que vayan más allá de la DoD y que, si es necesario, existan objetivos intermedios que ayuden a lograr al objetivo final. Algunas metas pueden ser extensas en el alcance, pero deben describirse con simplicidad y de tal forma que comprometan al equipo y a la organización.

Los desafíos y el futuro


Un buen Scrum Master ayuda a preparar el entorno en el que su equipo creará productos con una excelente trama en su interior y que generen resonancia en los usuarios y soporta la implementación de Scrum en la organización. Un gran Scrum Master, además, prepara no solo al equipo sino a la organización para enfrentar los retos que llegarán: 
  • dominar las tecnologías emergentes, pero también los enfoques y los cambios de paradigma que harán de los miembros del equipo personas más innovadoras, más proactivas y que entiendan mejor la filosofía ágil;
  • compartir más para aumentar tanto la velocidad como la calidad de las decisiones -es  un asunto de mayor y mejor conocimiento;
  • licenciar a todo el equipo y a todos en la organización para que se sientan empoderados y lideren el cambio y a crear valor continuamente; y
  • anticiparse a las necesidades de los clientes, a identificar y resolver los problemas más rápido y a ir más adelante que la competencia.

Personas sobre Scrum Masters

Un buen Scrum Master sabe y promueve que el trabajo es importante, siembra la semilla en el equipo para que lleve un ritmo sostenido durante todo el proyecto a lo largo y ancho de toda la organización; un gran Scrum Master sabe y promueve que la vida es más importante que cualquier otra cosa, reafirma en el equipo que lo más importante son las personas, los desafíos personales e inspira a todos a que mantengan esas prioridades por encima de cualquier otro reto profesional, sin que se pierda de vista el compromiso, la responsabilidad y el foco de los miembros del equipo en los objetivos definidos.

Otros 10 consejos extraordinarios para ser un mejor líder

En su artículo “10 Awesome Tips for Being a Better Leader” (10 consejos extraordinarios para ser un mejor líder), Carly Okyle, asistente editorial de Enterpreneur, enumera estas sugerencias para ser un gran líder. Pienso que todo Scrum Master debería celebrarlas como parte de su rutina diaria si quiere llegar a ser realmente grandioso. De hecho, ya he mencionado algunas de estas indicaciones de una u otra forma en los párrafos precedentes:
  1. Lidera mediante el ejemplo
  2. Algo de humildad siempre cae bien
  3. Practica la comunicación efectivamente
  4. Promulga y cerciórate de que las reuniones sean productivas
  5. Conoce bien tus limitaciones
  6. Encuentra un mentor, siempre hay alguien que puede enseñarte algo
  7. Sé emocionalmente consciente
  8. Ten cuidado con y evita los errores comunes en el liderazgo, por ejemplo, pensar que tienes que tomar todas las decisiones o no tener presente que lo más importante puede suceder cuando no estás presente
  9. Aprender del pasado, sobre todo de los errores del pasado
  10. Nunca dejes de mejorar, los grandes líderes y, de hecho, las grandes personas, están aprendiendo constantemente y tratando de superarse a sí mismas.


Adenda

Un  buen Scrum Master dispone de los instrumentos y recursos necesarios para remover impedimentos en el proyecto; un gran Scrum Master se prepara y prepara a su equipo para lidiar con la complejidad, la incertidumbre y los cambios inherentes no solo a los proyectos de TI, sino a la industria en general.

Finalmente, recuerda que un buen Scrum Master triunfa con el equipo, un gran Scrum Master hace que las personas en el equipo sean más exitosas que él/ella.

¿Y tú, qué estás haciendo por pasar de ser un buen Scrum Master a un Scrum Master absolutamente grandioso? Házmelo saber en el foro.

------------------------------------------------------------------------
Más sobre Scrum Master en:

viernes, abril 17, 2015

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas
Este viernes 17 de abril, presenté en el Regional Scrum Gathering 2015, en Quito, mi disertación sobre Ágil y enfoques tradicionales. Mi asunto principal es que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización, como erróneamente pregonan muchos. Los líderes de los procesos actuales pueden y deben trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos tipo CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada alejado de lo que se está hablando en el  #RSGECU2015.

Hacia el final quise poner mi propio manifiesto, el ‘Ágil es algo que eres…’, se trata de la persona, no de las cosas ni de los procesos. Ya lo he dicho en otras oportunidades, ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

¿Quieres saber más?

Pueden descargar la nueva versión de la presentación haciendo clic aquí o en esta dirección: http://goo.gl/leJ5N8.


No olviden escribirme con sus inquietudes o sugerencias a lucho.salazar@gmail.com o en el foro del blog.

jueves, marzo 05, 2015

De historias de usuario, culturas y del arte de narrar historias

“Yo no sé muchas cosas, en verdad,

Digo tan solo lo que he visto.
Y he visto que la cuna del hombre
la mecen con cuentos,
que los gritos de angustia del hombre
los ahogan con cuentos,
que el llanto del hombre
lo taponan con cuentos.
Y que el miedo del hombre
ha inventado todos los cuentos…
Yo sé muy pocas cosas, es verdad,
pero me han dormido con todos los cuentos
y sé todos los cuentos ...”
[León Felipe, Aguaviva.]

La vida es una alegoría, los seres humanos no solo estamos configurados como cuerpos biológicos abastecidos de estímulos y pulsiones, pues nacemos en un entorno social y por tanto nos relacionamos, desde lo más esencial –lo familiar, hasta lo más universal, con nuestros semejantes. Pero además poseemos una visión personal para interpretar nuestra cotidianidad, tenemos ideales y pensamientos, emociones y aversiones que nos hacen actuar  de formas particulares al interpretar nuestra realidad.

En todo esto, la narración de historias juega un papel muy importante  en la construcción de conocimiento. La narrativa es una forma de caracterizar los fenómenos de la experiencia humana. Dice Ivar Jacobson en su libro Casos de Uso 2.0 que “la narración de historias permite a las culturas sobrevivir y progresar; es el camino más simple y más efectivo para pasar el conocimiento de una persona a otra. Es la mejor manera de comunicar lo que un sistema debe hacer y hacer que todo el mundo trabaje en el sistema sobre los mismos objetivos.” [1]

Las historias (de usuario) establecen una manera de organizar y comunicar experiencias. Las personas usan instintivamente la narración de historias para organizar un cúmulo de ideas que consideran disperso; además, gracias a ellas pueden organizar lo que saben acerca de su trabajo y de cómo lo hacen. Al narrar historias, las personas nos invitan de una forma u otra  a investigar sus pensamientos, sus sentimientos y sus intenciones. Finalmente, como oyentes y más tarde como lectores de las historias de usuario, adherimos a los acontecimientos, como una exploración de la experiencia de los usuarios, entendiéndolas mejor y de la forma más completa posible, pero sobre todo, comprendiendo su valor real.

Quienes transitamos a diario por el vasto universo del diseño y construcción de productos de software sabemos que es importante enfocarnos en el valor que estos prestarán a sus dueños, los usuarios, y a otros interesados. El mismo Jacobson dice que “solo se genera valor si el sistema se usa realmente; así, es mejor enfocarse en cómo se usará el sistema que en las largas listas de funciones o características que ofrecerá.” [2] Y agrega más adelante: “es fácil capturar y validar la completitud de las historias y estas, a su vez, facilitan filtrar las formas potenciales de usar el sistema que ofrezcan poco o ningún valor real a los usuarios. Este foco constante en el valor permite asegurar que cada entrega del sistema sea tan pequeña como sea posible, a la vez que tenga valor real para los usuarios del sistema y para los interesados que financian el desarrollo.” [3]

Cuenta las historias, no las escribas

En su libro “Fifty Quick Ideas to Improve your User Stories”, Gojko Adzic & David Evans [4], compilan una serie de conceptos sobre cómo mejorar nuestras historias de usuario o, mejor aun, sobre cómo mejorar el desempeño del equipo ágil usando la técnica de las historias de usuario. Me interesó mucho la primera de esas ideas, muy acorde a mi interés actual sobre las historias y la supervivencia de las culturas. Esta idea es precisamente la del título de esta sección: cuenta historias, no las escribas.

Uno de los errores más comunes de las personas que empiezan a usar prácticas ágiles es creer que las historias de usuario son requisitos livianos. Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante, el Equipo de Desarrollo y el Dueño de Producto, pero definitivamente no son requisitos. Este malentendido conduce a situaciones en que las historias sean recolectadas en herramientas de gestión de actividades, con muchos detalles escritos o proporcionados por representantes del negocio.

Nada más alejado de una buena práctica. Las historias de usuario implican un modelo totalmente diferente, Gojko y David lo llaman “requisitos por colaboración”, un modelo donde la transferencia de conocimiento vía documentos “pesados” se reemplaza por involucramiento y colaboración, al mejor estilo del Manifiesto Ágil. Ya sabemos que la conversación cara a cara es la forma más efectiva de comunicar información y que una buena discusión entre los interesados y el equipo ágil lleva a mejores preguntas/respuestas, opciones e ideas del producto. Cuando los requisitos se escriben, aun si los llamamos historias de usuario, estas discusiones nunca suceden y las mejores ideas se pierden para siempre. Tengo algo de experiencia en esto, pasé dos décadas escribiendo requisitos de software, todo tipo de requisitos, todo tipo de productos de software.

La recomendación es simple, avanzan Adzic y Evans en su libro: intenta contar historias o que te cuenten historias, en vez de escribirlas. Usa tarjetas físicas o un sistema de tiquetes electrónicos, pero solo como recordatorios de esa conversación que tendrás más adelante. No gastes mucho tiempo tratando de descifrar los detalles de las historias con anticipación. Compromete a los interesados del negocio e involucra a los miembros del equipo en una discusión, busca distintas perspectivas de la historia y explora opciones. Esta es la forma de acceder a los beneficios reales de trabajar con historias de usuario.

Beneficios clave de contar historias

Las discusiones permiten a los representantes del negocio, no solo explicar lo que quieren, sino también asegurarse de que los miembros del equipo entiendan esto correctamente. Uno de los mayores problemas en los modelos tradicionales son los malos entendidos entre los distintos roles en el equipo y entre los interesados, entre quienes existen niveles heterogéneos de conocimiento acerca de las necesidades de cada uno, complemento además del ya típico fenómeno del “teléfono roto” [5]. Es un hecho, explicar una historia cara a cara evita caer en vacíos de conocimiento sobre la historia.

El segundo beneficio, apuntan Adzic & Evans, es el análisis más rápido. Cuando el equipo completo se involucra en una discusión, los vacíos funcionales, las inconsistencias y los requisitos no claros se descubren más rápidamente que cuando una sola persona (léase Analista del Negocio o similar), escribe los detalles.

Pero el beneficio más importante de la comunicación cara a cara, comparada con el paso de información vía documentos, es que la primera produce mejores soluciones, mejores productos. Para ser capaz de construir buenas soluciones, las personas necesitan conocer los planes y las oportunidades del negocio, entender el dominio del problema, tener un conocimiento profundo de las restricciones técnicas estar al tanto de las nuevas tecnologías que potencialmente les puedan servir. Involucrar a un grupo de personas en el análisis desde diferentes perspectivas ayuda al equipo a beneficiarse del conocimiento compartido.

Como lograrlo

La excusa más común para llenarnos de documentación es la insistencia del negocio en la aprobación formal, las regulaciones legales o gubernamentales o las dependencias con terceros. Si es necesario “firmar” las historias hazlo a medida que las discutes. Es más, si el alcance final debe ser aprobado por varios interesados en el negocio, involúcralos en las reuniones de Refinamiento, días antes de la reunión de planificación del Sprint donde se van a construir las historias. En cualquier caso, el Dueño de Producto juega un papel muy importante en la consecución de tales aprobaciones. Es una de sus responsabilidades directas.

Como siempre, ensaya distintos acercamientos y en cada retrospectiva analiza como le fue a tu equipo. Como dice el refrán, la experiencia no se improvisa. Hasta allí el tema, recomiendo amplísimamente los libros que usé como referencia

Referencias

[1] [2] [3] Ivar Jacobson et all. Use Case 2.0. Ivar Jacobson International. 2011. Traducción de Luis Antonio Salazar y Carlos Mario Zapata.

[4] Gojko Adzic & David Evans, Fifty Quick Ideas to Improve your User Stories, © 2013 – 2014 Nueri Consulting LLP

[5] Conocido también en algunas culturas o regiones como el fenómeno o el juego del “teléfono descompuesto”

Para saber más de historias de usuario puedes leer mi serie de artículos en este mismo Gazafatonario:

http://goo.gl/iJvj7
http://goo.gl/NZv4vj
http://goo.gl/e1DSVh
http://goo.gl/eGHQQU

martes, diciembre 16, 2014

Antipatrones Scrum: definición de la estructura


Sobre ScrumButs, seres humanos y otros menesteres terrenales de lo Ágil

El cambio es difícil, aceptar el cambio es aún más difícil, pero cambiar una cultura organizacional, arraigada en la estructura de las organizaciones y en el ADN de las personas, es quizás la tarea más compleja que un ser humano, o un grupo de personas, pueden emprender. Pero los cambios son necesarios y con estos vienen los sinsabores de la toma de decisiones erróneas, las que, en el caso de los métodos de desarrollo de software, son el equivalente de errores en la adopción de prácticas y métodos nuevos para la organización.

Durante la transición al enfoque ágil de construcción de software, muchas veces las organizaciones y las personas encargadas del cambio en las organizaciones deciden no seguir la línea descrita por las guías, los expertos o las prácticas documentadas por la industria, y se apartan de ello simplemente para adecuar su “nueva” forma de trabajo a las antiguas costumbres, a lo que es conocido y que costó tanto (tiempo, dinero, personas, recursos) implementar y que de alguna manera ha funcionado en la organización.

El término ScrumBut (ScrumPero) se usa para referirnos a los cambios a Scrum que se hacen para ocultar disfunciones y problemas que un Scrum no modificado revela a la luz del contexto donde suceden los hechos. Un ejemplo típico, de algunos presentados en [1], es: “Usamos Scrum, pero no podemos construir una pieza de funcionalidad en un mes, así que nuestros Sprints tardan 6 semanas” (o más). En este ejemplo, El ScrumBut es el uso de sprints de 6 semanas debido a la inhabilidad de la organización para dividir los requisitos en historias de usuario (o cualquier otra pieza que se use para representar funcionalidad del software) lo suficientemente pequeñas y simples.

El término (ScrumBut) implica que el cambio al método Scrum se debió a problemas en la organización, en vez de a problemas con el propio método Scrum. Pero ojo, no todos los cambios al método Scrum se consideran ScrumButs. Se considera aceptable cambiar las prácticas de Scrum si los cambios se basan en una necesidad real y en un entendimiento profundo de los mecanismos que hacen que Scrum funcione. Este último asunto es lo que constituirá la parte de “Excepción” del antipatrón.

Personas y sus interacciones sobre el mismísimo proceso Scrum y las herramientas que proporciona

Estamos de acuerdo en que Ágil es más acerca de las personas y sus interacciones, la comunicación cara a cara y la cultura, que acerca de los procesos, las prácticas y las herramientas, aunque nunca debemos cansarnos de repetir esto. Sí, las prácticas de Scrum son importantes y nos proporcionan guías inteligentes que nos ayudan a mejorar nuestra productividad y la calidad de lo que hacemos, pero son los principios – la parte difícil – los que hacen que Ágil sea sostenible en el largo plazo y los que nos permiten maximizar los beneficios que el método nos ofrece.

Así que cuando decimos que una mala práctica, un ScrumBut, es este de los sprints demasiado extensos, no vamos a arremeter contra la práctica en sí, lo que nos interesa es ir a los principios ágiles, esos del mismísimo Manifiesto Ágil y mirar que podemos hacer. ¡Eureka! Hay un principio que dice: “Entregamos software funcional frecuentemente…” [2], esto es lo que nos interesa. La entrega de productos, de alto valor para el cliente/usuario, priorizado por este, es lo que nos va a permitir obtener una mejor y más objetiva retroalimentación del estado de las cosas, nos hablará del grado de satisfacción del usuario, de su felicidad y de la calidad de ese producto.

Y esta entrega de software debemos hacerla desde el inicio del proyecto y manera frecuente, ¿cómo nos suena ‘cada 2 semanas’? De esta forma, si nos equivocamos, lo hacemos rápido, en 2 semanas, y barato, mucho más económico que si hubiésemos invertido meses de trabajo y muchas personas en esa porción del producto y del proyecto. Si nos equivocamos, todavía hay tiempo para reaccionar, decidir sobre acciones que nos hagan volver al “camino correcto”, que mejoren el estado de salud del producto/proyecto y de todos los interesados en el mismo.

Estudio a fondo de un Antipatrón: la estructura y el contenido

Todo este preámbulo, necesario por demás, para llegar al meollo del asunto. Vamos a intentar definir una primera versión de Antipatrón con el ejemplo que hemos venido mencionando a lo largo de este estudio. Es precisamente lo que me interesa porque en todo este recorrido de consulta sobre el tema he encontrado que la gran mayoría de los autores sobre mencionan el antipatrón, el scrumbut o la práctica dañina, algunos dan un paso más y mencionan una o dos recomendaciones de como curar la enfermedad. Pero en general, todos se quedan en el camino, no van más allá de mencionar una lista de prácticas incorrectas. Ahora que recuerdo, eso mismo hice yo en el primer artículo (acercamiento) de esta serie sobre antipatrones Scrum [3].

Pero muchas veces ayuda conocer el porqué del por qué, el problema detrás del problema, la causa raíz y con ello en la superficie, es un poco más liviano encontrar el camino de salida. Así que vamos al fondo de las cosas. Hagamos un acercamiento más detallado a un antipatrón, mejor dicho, entremos al núcleo de una mala práctica común.

Nombre del Antipatrón: ‘Sprint demasiado extenso’

Recomendación de Scrum: Realizar sprints de 2 semanas (o menos). Más específicamente, para equipos de menos de 5 personas, sprints de 2 semanas están bien: si el equipo es de 5 personas o más, es posible hacer sprints de menos de 2 semanas. En definitiva, los sprints no deberían tardar más de 3 a 4 semanas. Este último lapso, quizás solo para equipos pequeños de 3 personas.

Contexto: Experimentación temprana con Scrum, legado Cascada de ciclos de producción extensos, clientes/usuarios reacios a participar en intervalos cortos.
Esta situación es bastante común cuando el equipo venía trabajando con Cascada o con RUP o WaterRUP o similares. También, cuando el equipo intenta hacer/entregar muchas funcionalidades o funcionalidades muy grandes o complejas, o cuando el equipo es muy pequeño (1 o 2 personas) y para entregar Valor extienden los sprints

Solución (este es el antipatrón): Establecer sprints de 4 semanas o aún más largos.

Consecuencias: en vez de un trabajo más extensos para los sprints, las tareas planeadas tienden a no finalizarse al final del sprint, posiblemente porque las primeras semanas no son usadas los suficientemente eficientes y se establecen tareas muy largas en los sprints. Disminuyendo consecuentemente el compromiso del equipo a entregar elementos al final del sprint. El ciclo de retroalimentación llega a ser tan extenso que parte del trabajo podría no llegar a necesitarse más.

La productividad no es la misma al inicio del sprint (normalmente más baja), que al final del mismo. Algo similar ocurre con el “paso sostenido” que debería mantener el equipo durante todo el proyecto: en este caso, al principio del sprint, los miembros del equipo inician con el ritmo que quisieran tener durante todo el sprint y, por extensión, durante todo el proyecto; sin embargo, hacia la segunda parte del sprint y sobre todo hacia el final del mismo, el equipo regularmente trabaja más de la cuenta, tratando de alcanzar el objetivo del sprint. Lamentablemente, muchas veces es demasiado tarde.

Excepciones: Si el equipo de desarrollo debe sincronizarse con trabajo externo que tiene un ritmo más lento (por ejemplo, desarrollo de hardware), sprints más prolongados podrían justificarse. En este caso, se debe prestar especial atención a la Definición de Preparado”. [4]

Hasta allí esta versión. ¡Funciona para mí!

Terminemos con una sugerencia

Ya he dicho en otras ocasiones que debemos empezar con “Scrum al Natural”, Scrum orgánico si se quiere. Cuando sea hora de hacer alguna adaptación, motivada por el hábitat organizacional, debemos evaluar estos cambios a las prácticas Scrum en su contexto, con el fin de separar los cambios dañinos de los necesarios o benéficos requeridos por ese hábitat organizacional y evitar así una crisis mayúscula en el mediano o en el largo plazo.
Ágiles, nos vemos en la Red.

Referencias

[1] Un breve artículo: ‘ScrumButs and Modifying Scrum’, lo encuentran en

[2] http://www.agilemanifesto.org/iso/es/principles.html.
El principio completo dice:
“Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.”
¡Nunca está de más darse una pasadita por el Manifiesto Ágil!

El primer artículo de esta serie sobre Antipatrones Ágiles/Scrum, donde hago una introducción al asunto que nos ocupa. La dirección completa es:

[4] Un artículo sobre este asunto de la Definición de Preparado fue publicado hace poco por el amigo y colega Johnny Ordoñez, se los recomiendo ampliamente:
‘La Definición de “Ready” es tan importante como la Definición de “Done”’

jueves, noviembre 27, 2014

Antipatrones Scrum: primer acercamiento


“Scrum es como el ajedrez. O lo juegas como lo dictan sus reglas, o no lo juegas. Scrum y el ajedrez no fallan ni aciertan. O los juegas, o no.” Ken Schwaber [1]
Presentación, o de la relación que tiene Bruce Lee con un arquitecto de apellido Alexander, una banda de los cuatro, Chuck Norris y Kent Beck

Las llaman ‘malas prácticas’, a mí me gusta llamarlas ‘prácticas fuera de contexto’; en el entorno ágil, algunos incluso hablan con humor de ‘Scrum Norris’, refiriéndose a aquel actor de Hollywood, Chuck Norris, quien apareciera por primera vez en 1972 en una película del legendario Bruce Lee, La Furia del Dragón, y que se hiciera popular por allá en los años 80 con películas de acción como Ojo por Ojo, Perdidos en Acción y Fuerza Delta y donde, a pesar de la incesante acción, no sufría ni un rasguño, ni siquiera se espelucaba. Los más técnicos y aventajados penetran la barrera científica y las llaman ‘Antipatrones’. Pero para usar este último término, primero definamos qué es un patrón, en nuestro contexto.

Quizás todos recordamos los súperarchipopulares ‘patrones de diseño’ [2] de los también súperarchifamosos ‘banda de los cuatro’ (Gang of Four), compuesta por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, quienes a su vez basaron su investigación en el trabajo de un Arquitecto (no de software), Christopher Alexander, quien por allá a finales de los 70, dio origen al tema como un concepto arquitectónico. Lo curioso de este asunto es que no fueron Gamma y su banda quienes primero tomaron ese concepto de Alexander: fueron los mismísimos Kent Beck y Ward Cunningham quienes en 1987 comenzaron a experimentar con la idea de aplicar patrones a la programación de computadores y presentaron sus resultados en el OOPSLA de ese año.

Toda esta historia, que siempre me ha parecido fascinante, porque es en la que se basarán los antropólogos de la TI en el futuro para descubrir al resto del universo de donde proviene la inteligencia artificial: las máquinas que piensan, los robots que hablan mejor que los humanos y los computadores ópticos, toda esta historia, simplemente para entender que un ‘patrón’ es una solución reusable a un problema común y recurrente dentro de un contexto. Pero ojo, un patrón no es una solución terminada, en cambio, es una descripción de cómo solucionar un problema.

Finalmente, hay patrones de Análisis (Fowler), patrones de diseño (Gamma et all), patrones de programación (Beck), patrones de pruebas (Binder), etcétera. Por supuesto, están los patrones en los métodos y en las prácticas y en los procesos. Pero de todo esto hablaremos en otra oportunidad. Lo que me ocupa esta vez son precisamente los Antipatrones Ágiles, en general, y los de Scrum, en particular.

Antipatrones Scrum: una primerísima aproximación pragmática

Un Antipatrón es, entonces, la antítesis de una solución a un problema recurrente. En el caso de los métodos y prácticas (ágiles), son actividades, procedimientos o rutinas, usos o hábitos, que personas dentro de una organización o entorno adquieren o ejecutan, con la idea de que son la forma ‘correcta’ de hacer las cosas. Estas malas prácticas se dan por múltiples razones. Aquí algunas de las respuestas más frecuentes que escucho en mi trasegar ágil:
  • Siempre lo hemos hecho así
  • Nuestras condiciones son únicas, entonces debemos hacerlo de esta manera (¡la madre de todas las entelequias!)
  • Hay temor al cambio (la más natural de todas estas especulaciones, el miedo es algo inherente al ser humano. Es quizás este miedo el que infunde los demás motivos expuestos aquí. No en vano León Felipe dice: “el miedo del hombre…ha inventado todos los cuentos.” [3])
  • La teoría, lo que dicen los libros y los manuales (léase Guías) no nos aplica
  • Tenemos regulaciones que nos impiden hacerlo de otra forma
  • No hemos tenido entrenamiento ni acompañamiento (de expertos en la materia)
Quizás esta última sea la razón cardinal de que las organizaciones se desvíen de las prácticas propuestas en Scrum por distintos motivos y de que las implementaciones prácticas de Scrum rara vez sigan los ideales de los libros de texto y mucho menos de sus autores. Es probable que algunos de esos porqués estén bien respaldados y sean sensatos, como lo hemos abordado en algunos ambientes, sin embargo, la gran mayoría de las veces las organizaciones no alcanzan a distinguir netamente las secuelas que se derivan de tomar esas desviaciones y se sienten tentadas a ajustar, a ‘acomodar’ Scrum y otras prácticas ágiles para ellas.

He estado allí: muy tarde se dan cuenta estas organizaciones que han caído en un sinfín de malas prácticas o en unos hábitos inadecuados para las personas, para los equipos y para la organización misma. Los resultados infaustos empiezan a aparecer cuando tratamos de ir un poco más allá: ‘bueno, ya que hacemos Scrum, agreguemos TDD y refactoring’ o ‘ya que hemos gestionado dos o tres proyectos con Scrum, llevemos esto a nivel corporativo’. Personas quemadas, clientes/usuarios que no ven la diferencia con métodos anteriores (léase Cascada, WaterRUP, etc.) o modelos de calidad como CMMI, COBIT, PMI y familiares.

Ahora bien, es cierto que en un lapso de tiempo relativamente breve, desde el ascenso de los arquetipos, poéticos por demás, del Manifiesto Ágil, muchas organizaciones se han afiliado a alguna forma de trabajo ágil. Pero lo que realmente está sucediendo cuando alguien dice “somos ágiles”, es “estamos usando algunas prácticas o ideas de Scrum y de otros métodos o prácticas ágiles”, algo que se conoce ordinariamente como ScrumBut (en español, ScrumPero –algo así como: ‘sí, usamos Scrum pero…’, donde este ‘pero’, quiere decir muchas veces: no tenemos Dueño de Producto, o no hacemos reuniones diarias, o el Scrum Master es el mismo Arquitecto de software o el gerente del proyecto, o no tenemos ‘definición de terminado’, entre muchas otras cosas y, con frecuencia, un compuesto de varias de estas).

Primera lista no exhaustiva, incompleta, de antipatrones Scrum

Hasta aquí la perorata, a manera de introducción. Lo que sigue es una lista de esas prácticas fuera de contexto, o antipatrones.
  1. “Nuestro Scrum Diario tarda 30 minutos o más, hablamos mucho de todo”, emparentado con “no hacemos Reunión Diaria porque no le vemos sentido”. Ya sé, tus tareas tardan 20, 30 o más horas y cada día que se reúnen, tus actividades siguen “en progreso”. Por eso no tiene sentido reunirse cada día.
  2. “Hablamos con el Dueño de Producto cada 2 o 3 semanas, durante la reunión de planificación”
  3. “Nuestro Sprint 0 es de nunca acabar, estamos detallando todos los requisitos”, también conocido como el ‘contraataque de la Cascada’
  4. “No sabemos donde está el Backlog del Producto”, o del ‘extraño caso del backlog de producto misterioso’
  5. “No tenemos definición de terminado”, familiar de “nuestro ‘trabajo en progreso’ es ilimitado”
  6. “No hacemos retrospectiva porque todo funciona muy bien con Scrum” o “nuestras retrospectivas son una oda a la autolaceración”. Me sé muchas otras con nuestra reunión favorita de regresión y análisis. Una, a propósito de Scrum Norris: ‘Cuck Norris no necesita Revisiones ni Retrospectivas. No hay espacio para el mejoramiento en los procesos de Chuck Norris’.
  7. “Nuestros Scrum Masters están en piloto automático”. A estos los ascendieron en esta década a zombis. ¡Estamos llenos de Scrum Masters zombis! Necesitamos un proyecto ‘Alice’ que acabe con esa disfunción.
  8. “Sí, hacemos sprints de 2 semanas, pero no entregamos valor al negocio”. Estos son los del enfoque iterativo e insustancial. El producto resultante es una colcha de retazos
  9. “Nuestros equipos son elásticos: sus miembros entran a y salen del equipo en cualquier momento del sprint y en cualquier sprint”
  10. “En la organización cambiamos el modelo de gestión del PMI por Scrum, pero el resto del proceso lo dejamos tal cual estamos certificados CMMI”
Suplemento
  1. “Nuestros Scrum Masters están asignados a 4, 9 y hasta 17 proyectos simultáneamente”, mejor conocido el Pulpo Ágil
  2. Nuestros clientes aceptan que usemos Scrum pero los proyectos son tiempo fijo-costo fijo-alcance fijo y el cronograma lo debemos entregar el primer día”
Por ahora solo la lista, pero mi análisis irá mucho más allá. Cuál es el contexto donde típicamente ocurre la mala práctica, cuál es la recomendación de Scrum/Ágil para cada eliminar el antipatrón de la faz de la tierra (bueno, al menos, del entorno donde se presenta), cuáles son las consecuencias de insistir en el mal-uso de la práctica, cuál es la solución (al menos, parcial) y, quién sabe, quizás alguna que otra excepción en la que el uso del antipatrón se justifique. ¿Es esto último posible? Yo no lo sé de cierto, lo supongo.

Colofón

Finalmente, quiero referirme a la frase inicial que usé para abrir este primer incremento sobre el tema: tiene razón Schwaber al hacer la analogía de Scrum con el Ajedrez. Las reglas de este juego son pocas y bastante simples, sin embargo, las estrategias existentes para jugarlo son diversas. Y hay un momento en el juego de la ‘Torre’ y el ‘Alfil’, llamado el ‘juego medio’ por los estudiosos, que se parece mucho a cuando los equipos de construcción de software juegan al diseño y a la programación usando las maniobras de Scrum: es cuando se requiere de creatividad, innovación, anticipación; es cuando precisamente nos damos cuenta que el desarrollo de software, como el Ajedrez, es jugado por personas, no por procesos ni herramientas.

Volveré con más antipatrones… ¡pronto! Mientras tanto, cuéntame cuáles malas prácticas o antítesis de excelencia, te has encontrado al ingresar a este apasionante pero complejo universo del desarrollo de software con métodos y prácticas ágiles.

Referencias

[1] Blog de Ken Schwaber: abril 7 de 2011:
https://kenschwaber.wordpress.com/2011/04/07/scrum-fails/

[2] Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2.

[3] Felipe Camino Galicia de la Rosa, conocido como León Felipe (Tábara, Zamora, 11 de abril de 1884 - Ciudad de México, 18 de septiembre de 1968), fue un poeta español. Este es su poema “Sé todos los cuentos”:
Yo no sé muchas cosas, es verdad.
Digo tan sólo lo que he visto.
Y he visto:
que la cuna del hombre la mecen con cuentos…
Que los gritos de angustia del hombre los ahogan con cuentos…
Que el llanto del hombre lo taponan con cuentos…
Que los huesos del hombre los entierran con cuentos…
Y que el miedo del hombre…
ha inventado todos los cuentos.
Yo sé muy pocas cosas, es verdad.
Pero me han dormido con todos los cuentos…
Y sé todos los cuentos.