Proyectos - Los 20 mandamientos del profesional humano, feliz y productivo

1. Buscarás ser exitoso a nivel profesional y personal. Equilibrarás ambos mundos y encontrarás la forma de integrarlos en una sola vida.
2. No buscarás dinero o poder como el fin ultimo de tu profesión. Te preguntarás antes de hacer algo ¿Como mejorará esto la calidad de vida de otro ser humano?
3. Lo mas importante serán las personas y JAMÁS pasarás por encima de ellas.
4. Ganarás sin que el otro pierda.
5. Defenderás tu integridad y la de tu equipo por encima de los intereses empresariales, económicos o de poder.
6. Pondrás las técnicas y las teorías a tu servicio. Las adaptarás y moldearás a la necesidad y realidad actual.
7. Comprenderás que los problemas técnicos se solucionan con estudio, pero los problemas de actitud solo se solucionan con actitud.
8. Te orientarás al logro de metas. No a la realización de actividades
9. Confiarás en el equipo de personas con quien trabajas
10. Velarás por descansar todos los días. 
11. No trabajarás mas para lograr más. Te enfocarás mas para lograr mas.
12. Realizarás solo una actividad al tiempo y te enfocarás en algo diferente cuando la hayas terminado completamente.
13. Amarás la calidad por encima de todas las cosas (Laborales)
14. Trabajarás con personas no con recursos (los recursos se consumen y las personas se desarollan y son irreemplazables).
15. Disfrutarás plenamente cada cosa que hagas. No esperarás a lograr algo para sentirte afortunado y feliz y velarás porque el circulo de personas que te rodean sean conscientes de lo mismo.
16. Serás consciente de tu naturaleza humana e imperfecta y por lo tanto asumirás tus errores y los errores de quienes te rodean como una oportunidad de mejora.
17. Serás consciente que el poder del grupo es infinitamente mayor al poder del individuo y pondrás los objetivos del equipo por encima de las ambiciones personales.
18. No siempre tendrás la razón
19. Comprenderás que el conocimiento no te pertenece y por lo tanto enseñarás a todo aquel que lo necesite sin temor a verte desplazado.
20. Te reconocerás un ser humano incompleto y buscarás la ayuda de los demás cuando tu conocimiento sea limitado.

Proyectos - Scrum Master. El verdadero impedimiento.

El rol del Scrum master en la metodología SCRUM es radicalmente diferente a los cargos que tradicionalmente vemos en las empresas. Sus objetivos son principalmente asegurar que la metodología se cumpla, remover impedimentos que afectan la productividad de las personas, aumentar paulatina y progresivamente la velocidad del equipo y sobre todo VELAR PORQUE LAS PERSONAS SE SIENTAN BIEN.

¿Pero que pasa cuando este rol es asumido por alguien que se encuentra sumergido en el tradicional rol de director de proyectos?

La experiencia me ha demostrado que si alguien quiere ser Scrum Master primero debe desaprender todo aquello que haya vivido como director y para poder hacerlo debe asegurar que sus superiores están alineados con esto. Mas aún. Debe asegurar que la empresa lo vea como Scrum Master y le permita actuar como tal. Es muy complicado lograr cumplir con las responsabilidades del rol cuando los jefes simplemente ejercen presión y exigen resultados haciendo caso omiso a lo que piensa el equipo.

Incluso dentro del mundo de la tradicional gerencia de proyectos existen varias clases de personas:

• Aquellos que les gusta dar ordenes, pensar y decidir que es lo que debe hacerse.
• Aquellos que le dan la libertad a sus colaboradores para que decidan como van a cumplir con una meta.
• Aquellos a los que simplemente les interesa cumplir una meta e inspirar a los demás con el ejemplo, mas allá de las ordenes y la demostración de superioridad y poder.

De estos tipos de personas las que mas fácilmente se adaptarían a este nuevo rol son las dos ultimas, pero la primera es absolutamente perjudicial si se está trabajando con un grupo de profesionales que tienen el conocimiento y la capacidad de asumir retos y sacarlos adelante. Quien se encuentra en esta posición es un absoluto y gran autócrata o en otras palabras un absoluto y gran pendejo si cree que esta actitud le permitirá obtener mejores resultados de las personas con quienes trabaja. 

El poder es bastante seductor y quien se encuentra en esta posición no duda un solo instante en hacer gala de el y opacar a los individuos con quienes trabaja con el fin de verse siempre como aquel super héroe que salva la situación. No se da cuenta que el precio es demasiado alto. Todos los regímenes autocráticos tarde o temprano caen cuando las personas comprenden que tienen un poder mas allá de lo imaginable y que pueden lograr grandes y mejores cosas por si mismas trabajando en equipo.

A continuación una serie de elementos que me han hecho la vida imposible en los proyectos SCRUM de los que he participado. 

• Tiempo: El valor ganado no avanza de forma directamente proporcional al esfuerzo invertido. Un Scrum Master que todos los días cuestione el trabajo realizado por el equipo y simplemente critique el hecho de que el Burn down chart no baja a diario, es un gran dolor de cabeza.

• Interferir con el equipo: No confiar en el grupo de personas con quienes se labora y todo el tiempo cuestionar la forma de trabajo y las decisiones tomadas.

• Decidir lo que debe hacerse: Con la excusa de que conocen mejor la empresa o el negocio todo el tiempo interfieren y asignan el trabajo de las personas, sin darle la oportunidad al equipo de actuar por si mismo.

¿Como podría un niño no depender de su padre, si este no lo deja caerse, tropezarse y tomar sus propias decisiones?. La excusa siempre es el tiempo. "Si no les digo que hacer ustedes tardarán mas tiempo en descubrirlo y no le podremos entregar valor al negocio". La verdad es que: "Siempre existirá excusas."

• Culpar: Siempre es mas fácil culpar a los demás de nuestra incapacidad. No se puede pretender que el equipo logre grandes cosas si no se le da una gran autonomía. 

• No es suficiente lo que se logra: Pocas cosas tan desmotivantes como terminar las historias de usuario comprometidas para un Sprint y que el Scrum master diga. "La velocidad realmente no fue tanta porque considero que le asignaron demasiados puntos a ciertas historias de usuario que eran muy simples".

• No velar por que la metodología se cumpla: Esta es una labor propia del rol. Si él mismo incentiva a no seguirla con el fin de entregar a como dé lugar, tenemos grandes problemas

• No seguir ciertas practicas porque no hay tiempo: No permitir usar practicas como TDD, pair programming o pomodoros porque implican tiempo adicional y se debe entregar rápidamente al usuario. ¿Será que cuando estallen los problemas el producción, el tiempo invertido en pruebas unitarias no se justifica?.

Un Scrum master de estas características cumple un solo papel dentro de un proyecto. SER EL ÚNICO Y GRAN IMPEDIMENTO. Un impedimento que debe ser removido si se quieren lograr grandes cosas.

La labor del Scrum master no es simple ni todos estamos capacitados para serlo. Primero debemos vencer al mayor enemigo si queremos tener las cualidades necesarias. Nosotros mismos. 

Proyectos - Un inicio ágil bastante lento.

Un inicio ágil bastante lento

Un cambio de metodología va mucho mas allá del conocimiento de la misma pues conlleva a asumir una filosofía que no todos estamos dispuestos a seguir. Las metodologías ágiles parten de planteamientos bastante admirables, y dado su poco nivel de prescripción, iniciarse en ellas sin la ayuda de un experto con experiencia puede ser bastante complejo.

A continuación una serie de dificultades que nos encontramos tratando de iniciar un proyecto con SCRUM:

• Falta de alineación: Suena a frase de cajón pero esta es la principal dificultad al iniciar cualquier proyecto. ¿Que es lo que quiere lograr el negocio?, ¿El producto owner está alineado 100% con lo que quiere lograr y las prioridades definidas son un reflejo de tal alineación?

• Incapacidad para priorizar: El negocio siempre quiere tenerlo todo. La consecuencia es que termina teniendo nada.

• Falta de herramientas: Pareciera ser un ítem bastante trivial pero la metodología plantea el uso de muchos elementos (Post-its, marcadores, tablero, tarjetas de estimación de poker, tarjetas de escritura de historias de usuario, entre otros) que en ausencia de ellos entorpecen el proceso. 

• Visión del proyecto: Todos los miembros del equipo deben tener la misma visión del objetivo que debe lograrse. Pida a varios miembros del equipo que explique las metas que deben alcanzarse y le beneficio que se entregará al completar el proyecto. Muchos probablemente no conocen estos datos.

• Demasiado tiempo en el arranque: Quedarse mucho tiempo definiendo planes, herramientas, haciendo consensos o cualquier otra cantidad de cosas, puede ser contraproducente. ¡JAMAS ESTAREMOS LISTOS PARA ARRANCAR!, de modo que es mejor dedicar un tiempo corto y limitado a esta labor y ajustar todo los que sea necesario en los primeros sprints. Lo importante es que se maneje la expectativa y no se esperen grandes resultados pues el equipo apenas se estará organizando.

• Orientación a generar valor al negocio: En todo proyecto de desarollo lo común es que se realicen actividades orientadas a generar la base de desarollo que permitirá construir la funcionalidad requerida por el negocio. En SCRUM es vital que en cada iteración se entregue valor aún cuando sea mínimo y encontrar este equilibrio no es fácil. ¿Como decirle al usuario que en 8 días no pudimos hacer nada porque configurar la aplicación fue muy complejo o porque no alcanzamos a definir el plan de GCS?. Esto es inaceptable.

• Justificar la tecnología de implementación: Algunas veces el tiempo y el costo de implementación pueden variar considerablemente por la inclusión de una nueva tecnología. Justificar el ¿Por que? al negocio es una labor compleja si no se explica en sus términos. De hecho siempre se debe buscar el beneficio de esta ante el usuario, ya sea de cara a una mejoría en la aplicación o en temas de proyecto como tiempo o costo, en el mediano o largo plazo.

• Expectativa: Muchas veces el negocio espera mucho mas de lo que le podemos ofrecer con el tiempo y el presupuesto disponible. Alinear expectativas es importante al inicio de modo tal que no se lleven una gran desilusión. Esto suele ser una labor ardua.

• Pretender hacer planes al inicio: Los planes deben estar el servicio del equipo por lo tanto este es quien los diseña de acuerdo a sus necesidades. Muchas veces se pretende definir formas de trabajo (TDD, ATDD, DDD, BDD, etc) pero es la realidad del proyecto la que determinará la mejor combinación. Es importante sentar una base común al inicio. Por ejemplo, el plan de gestión de la configuración podría diseñarse previo al desarollo pero esto no impide que cambie durante el proyecto.

• Intermediación: Para solucionar un problema se pasa por varios intermediarios hasta llegar al responsable. Esto dilata demasiado el tiempo de resolución del problema.

• Impedir la autogestión del equipo: El rol del scrum master no se asume plenamente y se ve viciado por elementos de las metodologías tradicionales de gestión de proyectos, rayando en algunas ocasiones con el seguimiento, control y la interferencia en la toma de decisiones.

• Falta de foco: Es muy común que cada miembro del equipo se concentre en una historia de usuario y al final queden varias empezadas. Sobre todo al inicio cuando el equipo no conoce su velocidad es preciso enfocarse solo en ciertos items de modo que se garantice la entrega de algo aún cuando sea poco. Solo los items completos que dan valor al negocio generan avance.

• No tener en cuenta a los stakes holders: Dada la velocidad con la cual se generan entregables en SCRUM, es muy importante que todas las áreas que intervienen de manera directa o indirecta en el ciclo de vida del producto hasta que llega a producción, se tengan en cuenta. Si requerimos permisos en la estación de trabajo, configuraciones en los servidores previo al paso entre ambientes, configuraciones de bases de datos,  o cualquier otro tema que dependa de otros, debe identificarse a quien acudir y tenerlos en cuenta desde el inicio. Si cualquiera de ellos no ofrece la ayuda adecuada en el momento justo, probablemente no generemos valor en muchos sprints.

De todos los aspectos mencionados el mas impactante es el ultimo. Los stake holders afectan de una manera impresionante todo el proceso. Durante el primer sprint del proyecto objeto de análisis no se entregó absolutamente nada por lo siguiente:

• Una de las estaciones de trabajo tenía problemas y la dependencia con soporte tecnológico impedía avanzar en este frente
• No se tenía acceso como administrador a la estación de trabajo por lo que no era posible instalar el software requerido para iniciar labores.
• Se requerían accesos servidores y aplicaciones existentes dentro de la compañía cuyos responsables tenían un acuerdo de servicio demasiado amplio para un proyecto SCRUM.

Los errores cometidos nos son muy diferentes a los que se presentan en proyectos gestionados de forma tradicional. La diferencia radical es que bajo esta metodología se falla rápidamente. Muchos de estos problemas los aprende a manejar el equipo en el tiempo conforme adquiere autonomía y el apoyo de los stakes holders. Esto se evidenció después del primer sprint en el cual se pudo generar valor. 

Solo un poco pero se generó valor¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡.

Estimación - El bello arte de estimar el software

El bello arte de estimar el software

Pocos proyectos tan difíciles de estimar como los proyectos de software. ¿Por que?. Porque contrario a lo que muchos creen, la construcción del software es un arte y por lo tanto no puede concebirse una fabrica que automatice su construcción. La construcción de un producto de software es un reflejo directo del conocimiento de quien construye. Dos personas pueden llegar a un mismo resultado con diseños totalmente diferentes con el agravante de que ambos pueden considerarse buenos diseños en contextos diferentes. Entonces. ¿Como ser certeros en las estimaciones que entregamos?.

la respuesta es muy simple. NO SE PUEDE SER CERTERO. Es absolutamente imposible. Es mas, las certeza va en contra de la definición de estimación "Aprecio y valor que se da y en que se tasa y considera algo. RAE". Máximo podríamos llegar a un valor aproximado que permita calcular la fecha de finalización del proyecto. Pero mas allá no tiene sentido. ¿Y como lograr esa aproximación?

Lo mas importante a la hora de estimar radica en entender lo que debemos lograr y que debemos hacer para lograrlo. 

A continuación describo una serie de actividades que suelo realizar cada vez que debo estimar. No son nada del otro mundo, incluso pueden verse como tareas derivadas de la aplicación del sentido común (El menos común de los sentidos).

El proceso se puede dividir en 4 fases.:Entender la necesidad, entender como vamos a satisfacer la necesidad, identificar las actividades que se requiere ejecutar para lograr el objetivo y estimar cuanto tiempo tardaremos para lograrlo.

ENTENDER QUE ES LO QUE SE NECESITA

• Entender el contexto de la necesidad: Se sugiere leer toda la documentación sin preocuparse por conocer cada aspecto de forma detallada, el contexto es suficiente para orientar la forma como se solucionarán las inquietudes.

• Break: Dependiendo del tamaño y cantidad de in formación que deba revisar para entender el contexto, es preferible se tome un descanso y preferiblemente cambie de actividad. Esto le permitirá cuando retome el tema tener la mente mucho mas despejada.

• Estructurar los objetivos, necesidades y requerimientos: La documentación que recibimos normalmente viene dispersa o agrupada por diferentes temas que no tienen sentido para nosotros. Ordenarla y estructurarla será la base para entender en detalle lo que nos solicitan.

Figura 1. Objetivos, necesidades, y requerimientos estructurados

Es importante durante la estructuración, escribir todas las inquietudes que tengamos sobre la definición, de modo que podamos reunirnos con el experto para aclararlas.

Durante esta actividad podríamos empezar a identificar ciertas tareas que deben realizarse y que servirán como insumo a la estimación. Aunque el siguiente paso será precisamente el de identificarlas, se puede hacer a lo largo del ejercicio de modo que no sean olvidadas.

• Reunión con el usuario: Es importante tener una reunión con la persona que tiene la necesidad que estamos analizando. Se sugiere que el experto empiece contando una visión global de lo que requiere y las razones por las que lo solicita. Esto permitirá aclarar mas el contexto. Luego se puede entrar en el detalle y empezar a discutir puntualmente las inquietudes descubiertas en el paso anterior.

ENTENDER COMO VAMOS A LOGRAR LO QUE NOS SOLICITAN.

• Realizar un diseño conceptual: Es imposible estimar si no tenemos una idea medianamente clara de como vamos a lograr lo que nos están pidiendo. El éxito de este paso depende de la experiencia que tengamos solucionando problemáticas o necesidades similares. Si nos piden construir una carretera, probablemente un zootecnista no sea la persona mas adecuada para hacer un diseño de la forma como se va a construir. En el mundo del software es muy conveniente cubrir este paso con un diseño de arquitectura, teniendo en cuenta los drivers arquitectónicos (Restricciones técnicas, de negocio, atributos de calidad, necesidades funcionales) que estén disponibles al momento de su realización. El nivel de detalle que se logre dependerá del grado de incertidumbre y del nivel de riesgo que se está dispuesto a asumir.

Diseño

IDENTIFICAR QUE ACTIVIDADES DEBEMOS EJECUTAR PARA HACERLO POSIBLE.

• Construir el WBS o EDT (Work Break Down Structure o Estructura de Desglose de Trabajo): Se puede tomar como insumo el artefacto descrito en la figura 1. La idea es que sea estructurado de manera realista teniendo en cuenta la información entregada por el usuario en la reunión. 

El objetivo de realizar el WBS es principalmente identificar las actividades que deben realizarse para completar el producto, por esta razón es importante equilibrar el nivel de detalle al que se quiere llegar y esto depende de dos aspectos principalmente: El nivel de confianza que se requiere de la estimación y el tiempo disponible para realizarla. 

Si realizamos un desglose muy detallado, es posible que logremos un nivel de confianza mayor (Aunque esto hará que se extienda mucho el tiempo de planeación y aún así lo mas probable es que se realicen asunciones que en el transcurso del proyecto se desvirtúen e invaliden la estimación.), pero también es posible que sobre estimemos (Podríamos desglosar actividades muy pequeñas que realmente requieren menos tiempo del planteado). 

Si realizamos un desglose de muy alto nivel lo mas probable es que subestimemos (Podríamos perder de vista actividades importantes que harán que el esfuerzo requerido sea mayor).

Siempre es importante tener en cuenta el grado de incertidumbre con el que se debe convivir en el momento de la estimación (Conforme avanza el tiempo esta se va reduciendo hasta llegar a 0 en el momento de la entrega del producto). Este será el factor que nos permitirá determinar que tanto esfuerzo invertir en el desglose. A mayor grado de incertidumbre, menor debe ser el esfuerzo invertido.

Figura 2. Cono de la incertidumbre

• Retroalimentar el WBS con lecciones aprendidas: Es importante revisar algún repositorio en el que se encuentren tareas que son repetitivas en todos los proyectos tales como planeación, aseguramiento de la calidad, arquitectura de software, gestión del proyecto (Reuniones de seguimiento, gestión de riesgos, gestión de la calidad, control, cierre), despliegues, pruebas o actividades que hace el cliente en cada entrega y que puedan afectar la fecha de finalización del proyecto. Todo esto con el fin de no perderles de vista y tener en cuenta el esfuerzo que requieren en la estimación. Este repositorio debería actualizarse constantemente cada vez que se cierren los proyectos con el fin de aprender de experiencias previas.

ESTIMAR CUANTO TIEMPO TARDAREMOS PARA LOGRARLO.

Solo resta colocar un número. Esta es la tarea mas sencilla de todas ¿Por que?. Porque cualquier número que se coloque será solo una percepción aún si viene de un repositorio de datos históricos, o si lo estimó mas grande sabio del planeta. Una percepción que jamás será acertada.

Es muy recomendable en este punto diferenciar estos tres términos: Tamaño, Esfuerzo, Tiempo. 

El tamaño como su nombre lo indica pretende dimensionar que tan grande es el software que vamos a construir. Se puede dar en las siguientes medidas: Function points, Story points, o cualquier otra unidad que quiera utilizar. Lo realmente importante es que el valor obtenido tenga algún significado para usted. 

El esfuerzo dependerá de quien ejecute las tareas. Una persona puede tardar 4 Horas realizando un CRUD a una tabla de una base de datos, mientras que otra menos experimentada tardará 8 Horas. El esfuerzo es la cantidad de horas que una persona invierte para completar una unidad de tamaño. SCRUM por ejemplo traslada el esfuerzo al Sprint. ¿Cuantos puntos de historia podemos completar en este Sprint?, las metodologías tradicionales asignan el esfuerzo a la tarea misma.

Los valores de tamaño y esfuerzo podrían ser obtenidos a través de ciertas técnicas:: Function points, Planning poker, Deal and Slide, Mark II function points, analogía, Wideband delphi, entre otras. Ninguna ofrecerá un valor mas acertado que la otra pues al final en cualquier caso se terminará usando Juicio Experto dado que los valores que reciben como insumo estas técnicas serán subjetivos.

Otra alternativa es utilizar datos históricos pero esto tampoco le dará mas precisión a la estimación. Es mas. Una simple suma puede ser mas efectiva que la aplicación de una gran formula matemática muy compleja. En cualquier caso seguirá siendo una estimación.

El tiempo dependerá de otros factores como los días festivos, las vacaciones, la cantidad de personas involucradas en la realización de una tarea, etc. En estos casos es útil utilizar técnicas como la ruta crítica, o Gantt para tomar en consideración estos factores.

Recomendaciones:

• No utilizar la unidad de medida Horas en todos los casos. A mayor incertidumbre mayor debe ser la unidad de tiempo utilizada. Por ejemplo. En etapa comercial la unidad mínima de medida deben ser meses, semanas o días  A medida que reduce la incertidumbre puede reducir la unidad de media usada pero mínimo debe darse en Horas. Los minutos o medias Horas dan una falsa sensación de precisión. Si una funcionalidad es tan pequeña que no se demora al menos una hora, entonces agrúpela con otras tareas que pueden realizarse en esa unidad de tiempo.

• Utilice la analogía: Es muy útil siempre comparar actividades que se han llevado a cabo de forma similar en otros proyectos para comparar la estimación. Esto permitirá identificar trabajo adicional o ciertos riesgos para los cuales debe realizarse reservas de gestión. Por ejemplo. Si se está estimando la integración con un sistema externo y previamente otros proyectos lo hicieron, revise que pasó y cuanto tardaron realmente.

Conclusión: Es mejor ser fiel al Décimo primer mandamiento "No estimarás"

La documentación no documentada

La documentación no documentada

Desde el inicio de los tiempos el conocimiento de la humanidad se ha transferido por medio de documentos a través de varias generaciones, sin esta información no tendríamos memoria histórica y al morir el experto, el conocimiento dejaría de existir con el.

Documentar es una de las actividades que los profesionales menos queremos y mucho menos valoramos. De hecho este trabajo siempre se deja para el final de todo proyecto y finalmente se realiza con el fin de dar cumplimiento a las clausulas del contrato y no para dar valor a quienes harán uso del conocimiento que generamos.

A continuación un resumen de las causas mas comunes por las cuales considero que la documentación generada en muchos casos no da valor:

• Falta de contexto: Normalmente quien documenta asume que sus lectores tendrán el mismo conocimiento sobre las características, beneficios, fortalezas, debilidades y condiciones de uso de su producto. Esto hace que sea muy complicado entender los diseños e instrucciones que se entregan.

• Asumir pre-condiciones de funcionamiento: Todo producto normalmente tiene unas pre-condiciones que deben satisfacerse de modo que este pueda funcionar adecuadamente. En el caso del software tales pre-condiciones serían las librerías de software usadas, contenedores, servidores de aplicaciones, sistemas operativos, IDE o cualquiera otra. ¿Acaso un vehículo puede funcionar sin gasolina?. Parece obvio, pero para un desconocedor no lo es.

• Asumir expertos: Está íntimamente relacionado con las dos anteriores pero me parece tan importante que quiero recalcarlo. Es mejor asumir que quien leerá la documentación es un completo desconocedor del producto. 

• Orientación a diferentes públicos: No todos los lectores tendrán los mismos intereses, de modo que debe ofrecerse mecanismos a través de los cuales la información pueda ser accedida rápidamente para cada tipo de público. Es muy importante en este caso tener un indice y referencias a diferentes partes del documento de modo que no sea necesario leer toda una sección para encontrar lo que se requiere.

• Fuentes de información adicional: Nada mas triste que tener dudas y no saber a quien o donde acudir, podría ser una persona, un sitio de internet o cualquier otra fuente de datos.

• Documentación de políticas y lineamientos: Normalmente durante el proceso de construcción se realizan acuerdos que terminan siendo políticas (Se debe cumplir en todo los casos) y lineamientos (Recomendaciones para operar de forma adecuada). Conocerlos es muy importante y ayudan a entender la razón por la que se tomaron ciertas decisiones.

• Lo mejor son los ejemplos: Un ejemplo vale mas que mil palabras. Preferiblemente el ejemplo debe tener imágenes e instrucciones paso a paso de como realizar las tareas mas criticas tales como configuración del producto y en el caso puntual del software, construcción de funcionalidades complejas.

• Limitar la carreta: La introducción, justificación y cualquier otra información que no genera valor directo debe limitarse. Se debe documentar solo aquello que realmente será de utilidad.

• Información articulada: De nada sirven un conjunto de conceptos y definiciones si no están articulados dentro de un contexto. La mejor forma de articularlos es a través de un ejemplo.

• Glosario: Cualquier concepto propio del dominio debe documentarse claramente de modo que quien lea sepa de que le están hablando.

• Actualización: De nada sirve un documento desactualizado, con seguridad nadie lo volverá a leer. Esto va íntimamente relacionado con limitar la carreta. Mientras menor cantidad de información debamos modificar cada vez, mayor será la probabilidad de que lo hagamos

• Detalles: Si el conocimiento que queremos plasmar es muy cambiante no tiene mucho sentido desgastarnos en documentar el detalle (Porque tendremos que ajustar la documentación muchas veces). En estos casos es preferible plasmar un conocimiento de alto nivel que será complementado mediante conversación entre el experto y el que lo requiere.

• Conversación: Nada podrá reemplazar la interacción entre individuos, de modo que aún cuando esté muy bien documentado siempre será mejor conversar y discutir las dudas que con seguridad después de leer un documento serán bastantes.

Arquitectura - ¿Un paquidérmico SEI caminando ágil?

¿Un paquidérmico SEI caminando ágil?

Las metodologías ágiles son sin duda alguna el tema de moda en la industria del desarollo de software y por ende son un buen negocio que muchas empresas no quieren desaprovechar. Las planteamientos de estos marcos de trabajo son radicalmente diferentes a lo que plantea RUP, y van en contra de lo robusto y excesivamente analítico (Parálisis del análisis en algunos casos) que plantea el SEI. 

En el siguiente articulo: "Integrating SoftwareArchitecture-Centric Methods into Extreme Programming (XP)", se muestra la posición de este instituto en torno a las metodologías ágiles y como involucrarlas dentro del contexto de un proyecto de este tipo. Aunque se podría ver mas como un documento comercial cuyo único es objetivo vender, lo considero un buen referente para incluir sus buenas practicas en este tipo de proyectos. Es un poco viejo pero QAW, ADD, ATAM, CBAM y ARID siguen estando vigentes y pueden ser una gran ayuda que equilibre el radical extremo al que llega ágil. El diseño emergente.

Este post se basa en las recomendaciones del documento para la inclusión de las practicas del SEI dentro del contexto XP y la experiencia de la aplicación de tres de estas en un proyecto SCRUM (QAW, ADD, ATAM).

QAW

SCRUM parte de una alta colaboración entre el negocio y el proveedor tecnológico cambiando los largos documentos de especificación por la automatización de las pruebas de aceptación (ATDD) y otras practicas como TDD tomadas de XP. Al inicio solo se identifican las necesidades a un nivel muy alto y son documentadas como historias de usuario. Estas historias deben contener criterios de aceptación y ser discutidas entre el equipo y el cliente con el fin de obtener toda la información necesaria para entregar valor. El problema con este enfoque es que se centra en las necesidades funcionales del software y quedan un poco relegados los atributos de calidad que aunque en la mayoría de los casos no son expresados por el negocio, determinan la buena o mala percepción de este en torno al software. De hecho los atributos de calidad rara vez se encuentran aislados de lo funcional ("El usuario puede retirar un limite diario de $300.000 de una cuenta con los fondos suficientes en menos de 10 segundos") pero identificarlos es en muchas ocasiones complejo.

Aquí es donde QAW genera valor. En el proceso de identificación a través de la generación de escenarios de negocio que permiten discutir las diferentes situaciones a las cuales el software será sometido y por ende permitirá identificar aquellos puntos mas sensibles (Desempeño, Modificabilidad, Disponibilidad, etc) que deben ser considerados. Los escenarios generados durante el QAW podrían convertirse en historias de usuarios o Tech stories e incluso podrán ser automatizados con ATDD convirtiéndose de esta manera en criterios de aceptación.

En SCRUM se plantea la realización de una Iteración 0 en la cual no se genere valor directo al negocio pero que permitirá construir la base de desarollo con la cual se implementarán las funcionalidades, esta base podría incluir entre otras cosas la definición arquitectónica que recibirá como uno de sus insumos los atributos de calidad. 

El ejercicio podría realizarse en unas cuantas horas o máximo un día  Su objetivo es identificar un conjunto de atributos de calidad que serán clave para la definición arquitectónica pero que serán refinados según las necesidades del equipo junto con el cliente en sprints posteriores.

Este proceso promueve uno de los principios ágiles   "Interacción entre personas sobre procesos y herramientas", solo que su foco está centrado en algo no funcional que de igual manera entregará valor al negocio.

ADD

Con los drivers arquitectónicos claros (Atributos de calidad, restricciones técnicas, restricciones de negocio y necesidades funcionales), se puede realizar un diseño arquitectónico de alto nivel (En la Iteración 0) que será construido en conjunto por todos los miembros del equipo. En este punto ADD se convierte en una muy buena herramienta que permitirá definir una propuesta de arquitectura de referencia que satisfaga los drivers identificados.

El objetivo de la arquitectura en este punto es generar una visión general y compartida de los objetivos que deben lograrse y alinear los esfuerzos de todo el equipo en torno a esto por lo tanto el diseño planteado con seguridad variará en el tiempo.

ATAM

La evaluación arquitectónica probablemente se vea en ágil como una propuesta inútil dado que previo a la implementación se basará solo en conjeturas que no necesariamente van a materializarse en el código desarollado. A mi me parece importante principalmente al interior de grandes organizaciones donde el éxito de un proyecto depende de la visión de múltiples áreas de tecnología (Operaciones, Infraestructura tecnológica, Seguridad, etc) donde realizar una evaluación permitirá obtener la visión de muchas de ellas involucrandolas desde el inicio y verificando como cumplir con sus expectativas en torno al sistema. 

Es obvio que estas mismas áreas debieron estar en el QAW porque de los contrario sus escenarios no estarían planteados y por ende no serian contemplados en el diseño arquitectónico.

Sería ideal que los artefactos generados durante las tres actividades planteadas estuvieran visibles para todo el equipo durante la ejecución del proyecto, con el fin de que se pueda retroalimentar constantemente y todos tengan la misma visibilidad.

Arquitectura - ¿Afectada por la tecnología?

¿La arquitectura se ve afectada por la tecnología de implementación?

"Lo mas importante es satisfacer al negocio por encima de la tecnología pero esto depende del entendimiento de la tecnología que se pretende poner al servicio del negocio.".

El rol de arquitecto de software ha cobrado mucha fuerza en los últimos años y al día de hoy no podría encontrar una frase que lo defina unívocamente. De hecho con el tiempo se ha desvirtuado poco a poco hasta convertirse en un simple punto mas de toma de decisiones burocráticas alejadas de la realidad y difíciles de implementar. He aquí el nacimiento del Ivory Tower Architect.

Es difícil no dejarse contaminar con el ambiente y por esto les comparto mi experiencia como Ivory Tower Architect en un proyecto de la vida real. Afortunadamente evidenciamos el gran error a tiempo y por eso no fue tan costoso.

Mi experiencia en desarollo de software se sustentaba solo en aplicaciones WEB, JAVA y JEE.

El reto ahora era diferente. Necesitábamos construir una aplicación que sería ejecutada en el computador de escritorio de cada persona. Adicional a esto se requería un nivel gráfico muy alto porque uno de los objetivos era generar una muy buena experiencia al usuario.

Mi responsabilidad inicialmente era realizar una investigación sobre las tecnologías existentes en el mercado y que nos pudiesen apoyar en la realización de este trabajo. Pasé por muchas herramientas RIA: Silverligth de Microsoft, Java Fx de Oracle, y Flex de Adobe. Después de discutir las ventajas y desventajas de cada una de ellas la seleccionada fue Flex.

Decidimos entonces realizar una prueba de concepto de modo que pudiésemos determinar que tantas facilidades ofrecía la plataforma en torno a incrementar la velocidad de programación. Las conclusiones fueron bastante positivas de modo que finalmente esta fue la opción seleccionada para el proyecto.

Acto seguido se realizó el diseño de la arquitectura. Decidimos tener un híbrido: JEE para la Back End y Flex para el Front End. El mecanismo de integración sería a través de servicios web. El diseño para el Front End fue el siguiente:

Diseño inicial de la aplicación FLEX.

La idea era que las pantallas estuvieran en el componente "forms", los cuales accederían a los servicios de datos a través de las interfaces definidas en el componente "datarepositories" (Estos actuarían de forma similar a como lo hacen los Delegate en JEE), cualquier evento que se ejecutara en el formulario se realizaría a través de una acción definida dentro del componente "actions", las validaciones en pantalla se realizarían a través de "validations" y en caso de que se requiriera consultar información para completarla, se debería usar un data repository.

Hasta aquí todo perfecto. Una arquitectura que aparentemente satisface las necesidades y en teoría fácil de implementar.

Tiempo después llegó el desarollo de la primera funcionalidad. Como asumimos que los data repository nos abstraerían de los servicios de datos decidimos Mockearlos y trabajar sin la implementación de estos. El desarrollo en el Front end se completó e inició la construcción de los servicios de datos y la integración.

No contamos con que la ejecución de los servicios web en Flex se realiza de forma asíncrona. Esto significa que desde los componentes "actions", "forms" o "validations", no podríamos obtener una respuesta haciendo el llamado a un método de un data repository puesto que la arquitectura de esta tecnología plantea que la respuesta se reciba en un método a través de callBack.

En este punto fue necesario re diseñar y cambiar la implementación de todo lo construido en el Front End. Ahora tenemos el siguiente diseño. 

Nuevo diseño de aplicación FLEX

Los formularios realizan el llamado directo a los servicios y reciben el callback con la respuesta. Si se requieren validaciones que usen servicios de datos entonces primero se llama al servicio y luego se ejecuta la validación (En el callback).

La alternativa inicial de diseño fue radicalmente diferente. De hecho durante varias horas intentamos implementar tal y como se había definido al inicio pero la especificación de Flex lo hacía imposible, en todos los foros muchas personas preguntaban cosas similares y la respuesta siempre era la misma. Flex es asíncrono en la ejecución de servicios de datos y no hay nada que hacer.

Siempre he defendido mi posición en torno a que la tecnología es lo menos importante en el diseño de una arquitectura. Hoy replanteo esta afirmación de la siguiente manera: 

"Lo mas importante es satisfacer al negocio por encima de la tecnología pero esto depende del entendimiento de la tecnología que se pretende poner al servicio del negocio.".

Ahora valoro mucho uno de los principios que plantean las metodologías ágiles: "Los mejores diseños salen de equipos auto dirigidos". 

Y un concejo: Si no sabe mejor reserve su opinión, investigue, implemente, aprenda y luego hable.

Gerencia - La increíble y triste historia del cándido don pendejo y su director desalmado

La increíble y triste historia del cándido don pendejo y su director desalmado

Don pendejo estaba realizando un trabajo cuando sopló el viento de su desgracia.

A la oficina entró el director con una mueca de sonrisa. Don pendejo sabía que pronto le comunicarían las conclusiones de la reunión con el cliente. Y de hecho fue así. La conversación  comenzó con un saludo cordial, mas cordial que lo acostumbrado y un repentino interés por la vida personal y familiar del próximo sacrificado. Después de un rato la conversación empezó a adquirir su verdadero tono y se volcó en torno a lo laboral. Don pendejo simplemente escuchaba el discurso que ya muchas veces le habían echado. Sabía que de igual manera le tocaría trabajar de mas y cancelar aquel paseo familiar que había planeado desde hace varios días. Su hijo se sentiría decepcionado pero era mas importante asegurar su continuidad en el trabajo así fuese llevando una vida miserable, que levantarse y buscar alternativas diferentes que le permitieran vivir una vida plena.

Su director continuó la conversación ...Es por esto que debemos entregar un mes antes de lo acordado. Yo traté de evitarlo pero ya sabes como es el cliente. Si no hacemos las concesiones que ellos solicitan simplemente buscarán a otro que si lo haga... bla, bla, bla.

Tal y como lo previó don pendejo, ese fin de semana se esforzó por hacer todo lo que tenía pendiente para intentar cumplir con la imposición. El domingo en la tarde terminaron todo lo que tenían que hacer pero ya no había tiempo para asegurar la calidad y lo peor es que don pendejo tampoco tuvo tiempo para hacer las pruebas suficientes que le dieran la tranquilidad de que el trabajo realizado cumple con las especificaciones del cliente.

Su director simplemente dice. Entreguemos para que reduzcamos la ansiedad del cliente. En los próximos días realizamos las pruebas que sean necesarias y entregamos una nueva versión.

El viento de la desgracia sopló nuevamente pero ahora con un hedor bastante desagradable. El cliente está furioso y quiere una versión de calidad inmediatamente, pues lo que se le entregó no le sirve para nada. Esto fue lo que le transmitieron al director en la reunión de seguimiento y por supuesto el se lo debe transmitir a don pendejo. La conversación inicial se debe dar nuevamente. A la oficina entró el director con una mueca de sonrisa...

El circulo vicioso continúa y el Director furioso por lo que hizo don pendejo lo presiona para que haga las cosas bien hechas. ¿Como es posible que un profesional con la experiencia de don pendejo entrega tal bazofia?. El ambiente laboral poco a poco se degrada y don pendejo cada vez se siente mas estresado y decepcionado. 

Al final sufre un paro cardíaco y muere.

Todos dan sus condolencias y el proyecto debe ser detenido hasta que encuentren un nuevo pendejo que se le mida al ritmo.

Mientras tanto don pendejo va al cielo y San pedro no lo deja entrar ¡POR PENDEJO!.

Conclusiones

• ¿La culpa es del director?, Sí, ¿La culpa es de don pendejo?, Sí. 

Un buen director debe tener las habilidades suficientes para negociar. En una negociación las partes tienen percepciones diferentes del valor y es responsabilidad del director mostrar el valor que tienen las actividades propuestas para contribuir a la elaboración de un producto final de calidad. Negociar será mucho mas fácil cuando ambas partes tienen la misma percepción del valor generado. pero se trata de negociar, no de bajarse los pantalones y hacer lo que el otro diga por miedo. 

Es responsabilidad de quien va a realizar el trabajo asegurarse que las condiciones están dadas para iniciar labores. No se puede llevar una vida buena y una mala en paralelo, la vida es una sola y siempre debemos velar por disfrutar de nuestro trabajo. Si el director no lo ve, entonces debemos tener la fortaleza suficiente para mostrarle su equivocación y exigir todas las herramientas necesarias para construir un producto de calidad.

• Del afán solo queda el cansancio. No hacer lo necesario cuando es necesario solo traerá dolores de cabeza mas adelante. En desarollo de software esto se conoce como deuda técnica y como todas las deudas tarde o temprano tendrán que pagarse con el agravante de que mientras mas tarde se haga mas intereses tendremos que saldar.

• La culpa al final siempre será de quien construye el producto. Es nuestra reputación como profesionales la que que está en juego. Tomemos en serio nuestra profesión y demosle valor a esos 5 años de universidad.

Gerencia - La calidad no es negociable

La calidad no es negociable

La calidad hace parte de esas cosas que simplemente percibimos pero que difícilmente sabemos definir. Podríamos decir que un producto es de calidad cuando satisface nuestras necesidades en el momento justo. No existen puntos medios. La calidad va mas allá de lo tangible y como en las relaciones humanas la primera impresión es la que cuenta. Nunca hay una segunda oportunidad para entregar un producto de calidad.

En el ámbito de la gerencia de proyectos existe una ley muy conocida llamada la Triple restricción. Esta plantea que todo proyecto gira en torno a tres variables: El alcance, el tiempo y el costo. Un cambio en cualquiera de ellas afectará a las otras dos y afectará también a la calidad. Calidad es entregar un producto con el alcance definido, en el tiempo acordado y con el presupuesto pactado. De cara al consumidor esto siempre va a ser percibido de tal manera independientemente de nuestra excusas o justificaciones para no hacerlo.

• ¿Acaso creen que quien compra un producto se sentirá feliz ante la promesa de un conjunto de funcionalidades que no se le entregaron en su totalidad?
• ¿Acaso creen que quien acuerda un precio de compra se sentirá satisfecho si le cobramos mas de lo pactado al inicio?
• ¿Acaso creen que el consumidor se sentirá tranquilo cuando le incumplimos la promesa de entrega del producto?

Un cambio en cualquiera de las variables debe ser previamente acordado y negociado con el consumidor. Un producto de mala calidad genera desconfianza y por lo tanto deserción.  Nadie querrá usarlo. Se trata tan solo de sentido común.

La calidad es el punto en el cual se ve finalmente reflejado el trabajo de todo un equipo. Evidentemente entregar un producto de calidad no es responsabilidad de una sola persona

Y si la calidad es tan importante entonces ¿por que la negociamos?

Cuando un proyecto tiene limitaciones de presupuesto o de tiempo una de las frases mas comunes es: "¿Por que no reducimos el tiempo de pruebas?". Las consecuencias se harán esperar pero llegarán tarde o temprano.

Los productos de software aumentan su complejidad proporcionalmente al doble de su alcance y por lo tanto corregir un problema al inicio será mucho menos costoso que hacerlo en una etapa avanzada del proyecto.

La calidad nunca debe ser negociable, esta siempre deberá permanecer implícita en cualquier actividad que realicemos y aunque su aseguramiento dependa del área de SQA, es responsabilidad de todos velar porque se dé.

Tengamos imaginación. Existen otras formas de optimizar el costo y el tiempo del proyecto (Pruebas automatizadas, automatización de procesos manuales y repetitivos, buenas practicas de diseño y desarrollo de software). He visto a muchos proyectos fracasar o terminar finalmente con un overhead impresionante debido a la falta de calidad en la entrega del producto. ¡Aprendamos de nuestros errores!.

Patrones - Plenamente justificables al negocio

Patrones de diseño: plenamente justificables al negocio

Sin duda alguna un diseño de software que no toma como base los años de experiencias previas condensadas en los catálogos de patrones de diseño, tiene menos probabilidad de ser exitoso respecto a uno que si lo haga.

Los patrones de diseño son bastante simples una vez se entienden los beneficios que se derivan de su uso. Personalmente pienso que la literatura ha hecho un gran trabajo documentandolos, mostrando la forma como se diseñan o la forma como se implementan, pero muy pocos se han esforzado por mostrar su valor evidente ante el negocio.

Independiente de su origen (GOF, JEE, GRASP, etc), pienso que todos ellos caben perfectamente dentro de dos categorías:

• Aquellos cuya aplicación es percibida directamente por el usuario final.
• Aquellos cuya aplicación es percibida por el negocio en el tiempo (Corto, Mediano o Largo plazo).

Estas dos categorías son las mismas que planteé hace algún tiempo para los atributos de calidad. ¿Por que?, pues porque de no ser así, ¿como justificar su aplicación?. Lo mas importante no es el patrón en si mismo, lo realmente importante es la razón por la cual este debe aplicarse y su justificación se deriva principalmente de todos los drivers arquitectónicos (Necesidades funcionales, Atributos de calidad, Restricciones técnicas y restricciones de negocio). Si no se puede justificar entonces no está bien diseñado.

Ejemplo práctico.

A partir de las reuniones de entendimiento de la necesidad con el cliente queda claro que se requiere una página web que permita realizar pagos a través de tarjeta débito o crédito. Aunque esto está definido, todavía no se ha seleccionado el proveedor a través del cual se realizarán las transacciones. Se tienen tres opcionados y el desarollo debe iniciar inmediatamente.

Una patrón Strategy en combinación con un patrón Adapter serían una buena combinación para solucionar este reto de diseño ¿Por que?.

El negocio requiere iniciar el desarollo inmediatamente pero se tiene un riesgo importante. El proveedor de transacciones de pago no se ha seleccionado. Siguiendo el principio de diseño Open/Close necesitamos entonces diseñar un mecanismo que permita realizar todo el desarollo de la página web de modo que en el momento en el que se decida un proveedor, se pueda realizar la integración sin modificar el código fuente ya escrito. El patrón Adapter tendrá sentido desde el punto de vista de separación de responsabilidades facilitando la lectura del código fuente escrito. Todo esto se traduce finalmente en un incremento del atributo de calidad "flexibilidad", lo que a su vez entregará los siguientes beneficios para el negocio:

• Se podrá iniciar el desarollo inmediatamente tal y como lo desean (Restricción de negocio)
• La integración con el proveedor de transacciones de pago no modificará el código construido hasta ese momento, lo cual reducirá el riesgo de daños a la implementación existente, que a su vez se traducirá en menor tiempo invertido por el área de testing en realización de pruebas de regresión.
• La separación de responsabilidades reducirá el tiempo de mantenimiento, al tenerse componentes altamente cohesivos.

Todo está estrechamente relacionado. En el ejemplo se ve como un atributo de calidad que podríamos pensar le interesa solo al equipo de desarollo, finalmente si es muy relevante para el negocio expresado en sus términos (Alcance , Tiempo, Costo o Calidad).

Trabajo colaborativo - 7x5

7X5

Generar ideas no es una tarea fácil porque depende de la imaginación, una soft skill que no se puede manipular racionalmente cuando se quiera. La inspiración simplemente llega. 

La mejor forma de obtener ideas es a través de una lluvia de ellas. El poder del grupo es indudablemente mayor al poder del individuo, pero ¿Como ponernos de acuerdo para priorizar esas ideas?, o ¿como seleccionar la mas adecuada?.

A continuación comparto un ejercicio a través del cual se podrán generar ideas y priorizarlas de forma ágil, rápida y divertida.

Formato del ejercicio

Roles

No existen roles definidos para el ejercicio. Se sugiere hacer este ejercicio con un grupo mínimo de 5 personas.

Instrucciones

• Se entrega a cada persona una hoja y un marcador.

• Cada persona debe escribir una idea.

• Se forman parejas de personas.

• Una vez todas las personas hayan escrito sus ideas, las personas deben empezar a caminar por el lugar en el que se encuentren reunidos e intercambiar los papeles en los que se escribieron las ideas, entre sí.

• Una vez intercambiados, se deben armar parejas nuevamente de forma arbitraria (No se deben reunir las mismas personas en cada pareja).

• Una vez conformada la pareja, discuten las ideas escritas en el papel. Cada pareja tiene 7 puntos los cuales debe distribuir entre las dos ideas. Ejemplo: Si la idea 1 es la que mas les gusta, entonces asignan a esta 7 puntos y 0 puntos a la otra idea, o podrían asignar 5 puntos y 2 puntos o cualquier distribución de números, lo importante es que la suma de puntos entre las dos ideas no sea superior a 7.

• Una vez asignados los puntos, se intercambian nuevamente los papeles con otras personas y se conforman nuevas parejas en las cuales deberás discutir y asignar nuevamente los puntos a cada idea. Esto debe hacerse 5 veces.

Al finalizar las rondas se seleccionan los papeles que tengan mayor cantidad de puntos asignados. De esta forma ya tenemos un conjunto de ideas y su priorización.

Experiencia personal al participar del ejercicio

• Este ejercicio fomenta la interacción entre las personas y esto siempre va a ser divertido.

• La actividad saca a las personas por un momento de su rutina diaria lo cual disminuye la presión del trabajo y por consiguiente hace que las ideas fluyan mas fácilmente.

• La priorización se realiza rápidamente. Obviamente es mas fácil decidirse cual de dos ideas es mejor, que hacer una interminable jornada de priorización de 30 o 40 ideas.

• Escuchar a las personas siempre es la mejor opción y a través de ejercicios como este, se fomenta tal practica.

Trabajo colaborativo - Spect writter

Spec writter

La transferencia de conocimiento a través del papel es fría, aburrida y poco emotiva. La comunicación va mucho más allá de la transmisión del mensaje e incluye los gestos, expresiones y cualquier cantidad de aspectos no verbales que se perciben cuando interactuamos entre personas. 

Efectividad del medio de comunicación

Cada vez que sea más impersonal la comunicación, menor cantidad de información se transmite y mayor es la probabilidad de mal interpretar el mensaje. 

El objetivo de este ejercicio es evidenciar como la interacción y comunicación directa entre personas mejora el entendimiento de la información recibida.

Formato del ejercicio

Roles

Grupo de especificación: Grupo de personas que da las instrucciones al grupo de implementación para que realicen lo que necesitan.

Grupo de implementación: Grupo de personas que intenta implementar lo que el grupo inicial les solicitó.

Moderador: Encargado de entregar las instrucciones y velar porque las reglas del ejercicio se cumplan.

Parte 1	Parte 2
Instrucciones
Se conforman equipos de 4 personas cada uno.	El grupo se reúne y se invierten los papeles, quienes hacían parte del grupo de especificación, ahora hacen parte del grupo de implementación y viceversa.
Cada equipo se debe dividir a su vez en dos grupos. Un grupo de especificación y un grupo de implementación.	Se entrega un dibujo diferente al grupo de especificación.
Los grupos de implementación deben salir del salón.	Esta vez los dos grupos permanecen reunidos durante todo el proceso
Se le entrega al grupo de especificación una hoja con un dibujo. Su objetivo es escribir en un papel las características del dibujo de modo que el grupo de implementación pueda replicarlo. Reglas: No está permitido escribir medidas absolutas, solo pueden existir medidas relativas (Ejemplo. Media página) Solo está permitido escribir texto. Se dispone de 10 minutos para realizar la especificación.	Se definen iteraciones cortas de especificación e implementación. Regla: Cada iteración tendrá una duración de 5 minutos (2,5 para especificación y 2,5 para implementación. Se definen en total 4 iteraciones.
Una vez se haya escrito la especificación sale el grupo de especificación y entra el grupo de implementación.	Inicia el grupo de especificación informando al grupo de implementación lo que observa en el dibujo durante los primeros 2,5 minutos. Regla:  Durante la etapa de especificación no se puede trabajar en el dibujo. El grupo de implementación puede realizar preguntas Solo está permitido al equipo de especificación dar medidas relativas.
A partir del texto escrito, el grupo de implementación debe tratar de realizar el dibujo. Reglas: Se dispone de 10 minutos para realizar la implementación.	Al finalizar los 2,5 minutos de especificación el grupo de implementación empieza a dibujar. Reglas:  No es posible realizar preguntas durante la fase de implementación. Al finalizar cada iteración el dibujo debe estar completo.
Una vez completado el dibujo entra el grupo de especificación y revisa lo que se implementó.	Se repiten los dos pasos anteriores hasta completar las 4 iteraciones. Después de una iteración, el grupo de especificación puede retroalimentar el dibujo realizado en la iteración anterior.
Experiencia personal al participar del ejercicio
La gran mayoría de los dibujos elaborados en la etapa de implementación no se parecían al dibujo con base en el cual el grupo de especificación escribió la necesidad.	Es mucho más agradable conversar con las personas, sobre leer un documento de texto.
Leer y escribir la especificación era una labor aburrida y repetitiva.	La revisión constante del grupo de especificación hacía que la implementación se mejorara a través de las iteraciones.
	Los dibujos realizados en la parte 2 estaban mucho más acorde a la especificación respecto a los realizados en la parte 1.