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.

Arquitectura - ¿Que es y que hace el arquitecto'

Que es la arquitectura de software y cual es el papel del arquitecto?

He escuchado muchas veces frases como “Debes tener en cuenta que la arquitectura se hace al inicio, después simplemente desarrollamos”, “Eso fue una decisión de arquitectura y debe respetarse” o “Esperemos a que el arquitecto tenga tiempo para que tomemos una decisión y continuemos el desarrollo”. La verdad no estoy de acuerdo en absoluto con ninguna de ellas porque en mi opinión:

• La arquitectura no incluye solo el diseño de unos componentes en UML y la aplicación de 4+1 vistas o cualquier otra estrategia de documentación. Esta va mucho más allá e incluye, el análisis y entendimiento de la necesidad, el diseño arquitectónico de los componentes y sus relaciones satisfaciendo cada uno de los drivers arquitectónicos y la asesoría y direccionamiento en el desarrollo. En torno a este planteamiento no tiene sentido decir que se hizo un correcto diseño pero que el desarrollo no satisface los drivers arquitectónicos. Era responsabilidad del arquitecto brindar el acompañamiento y la asesoría al equipo de desarrollo para que se realizara la implementación adecuadamente dentro del contexto.

• Las decisiones de arquitectura no son palabra de Dios, de hecho es imposible en el inicio del proyecto tener todo el alcance claro y tomar decisiones completamente acertadas en torno a esto. La arquitectura es un plan más de aquellos que hacemos en el proyecto y como todo plan debe ser flexible y adaptarse  a las necesidades de este, no al contrario. De hecho en la medida de lo posible las decisiones deben tomarse en conjunto con el equipo, el Arquitecto debería actuar más como un asesor que orienta a las personas en torno al logro de un mejor diseño que satisfaga todos los drivers arquitectónicos. Esto es muy utópico porque normalmente la arquitectura se realiza cuando el equipo aún no está conformado o se hacen compromisos de diseño en etapa comercial, pero al menos debemos garantizar que ésta recibe la adecuada retroalimentación por parte del equipo previo a la implementación y que este se sienta conforme. Después de todo quien construye se debe sentir cómodo con las herramientas que usa y la arquitectura es una herramienta más. No una imposición.

• El arquitecto no debe ser el punto central de toma de decisiones de diseño (Al menos no de todas) porque lo más probable es que se convierta en un cuello de botella y frene muchos temas de implementación. Incluso lo más probable es que el equipo pueda tomar mejores decisiones porque tienen el conocimiento en detalle de la necesidad. Con esto no quiero decir que todos tomen decisiones que podrían incluso ir en contravía, me refiero al hecho de que las decisiones sean concertadas por todo el equipo y no solo por el arquitecto. Esto no quita la necesidad de que el arquitecto preste el servicio de revisiones a las decisiones ya tomadas o participe como un miembro más en el equipo que tomará la decisión.

En conclusión el arquitecto de software no realiza una serie de actividades, simplemente cumple un único objetivo “Garantizar que el software sea implementado de forma tal que satisfaga todos los Drivers arquitectónicos, lo que a su vez se traducirá en satisfacción de las necesidades del cliente”. 

Si esto no se logra podríamos considerar que la arquitectura fue todo un fracaso aún cuando haya sido muy bien definida en el papel. ¡El papel puede con todo!

Gerencia - Lo mínimo mas valioso va primero

Lo mínimo mas valioso va primero

¿Cuantas iniciativas acaban en la papelera porque nos damos cuenta del gran alcance y esfuerzo que se requiere para llevarlas a cabo, o peor aún cuantas dimensionamos muy pequeñas pero en el camino se convirtieron en bestias indomables?, ¿Cuántos grandes productos salieron con la totalidad de las características implementadas en su versión inicial? Probablemente ninguno.

Cuando ingresamos en la vasta selva de la innovación y la investigación, o incluso en el trabajo rutinario, queremos hacerlo todo, damos grandes mordiscos que luego evidenciamos, no podremos masticar.

Hace algún tiempo tuve la fortuna de asistir a un curso de SCRUM y uno de los conceptos de sentido común más evidentes e impactantes en mi concepto fue el MMP (Minimal marketable Product). Aún siendo un concepto de sentido común es impresionante ver como en la práctica se hace muy complejo de lograr. Probablemente sea por nuestra ambición, o tal vez aplicamos a la definición de locura de Albert Einstein: “Locura es pretender lograr resultados diferentes haciendo lo mismo”. ¿Por qué no aprendemos de los errores del pasado y tomamos las buenas experiencias de otras industrias?

El MMP plantea que debemos hacer primero aquello que entrega más valor y de esta manera ofrecer al usuario final un producto que satisfaga algunas necesidades aún cuando sean mínimas. De esta manera se logra retorno de la inversión rápidamente, se satisface al usuario, obtenemos retroalimentación, y el equipo se siente motivado porque puede ver el resultado de su trabajo, lo cual no ocurre cuando llevamos años trabajando en la construcción de un producto y no vemos nada, tal vez veamos el avance en un cronograma pero eso es solo una gran mentira y no motiva.

El concepto de MMP se puede aplicar a cualquier contexto y actividad, de hecho lo hice durante el proyecto de reparación de un apartamento. No disponíamos de mucho tiempo y solo podíamos ocuparnos de esto los fines de semana. Durante tres periodos trabajamos incansablemente para hacer los ajustes necesarios pero con tan mala suerte, “Si así puede llamarse”, que no veíamos el avance. 

Decidimos parar para analizar la situación y nos dimos cuenta que en efecto habíamos avanzado mucho pero habíamos reparado las áreas menos deterioradas de modo que en conjunto el apartamento aún se veía en muy mal estado.

Es impresionante ver como la ley de pareto aplica en la mayoría de los contextos de la vida diaria y esta no fue la excepción. En realidad solo una pequeña parte del apartamento estaba fuertemente averiada, de modo que decidimos enfocarnos en esto. 
Acordamos que no nos quedaríamos puliendo en exceso cada reparación que hiciésemos, que nuestro objetivo sería dejar el inmueble aceptable para ser arrendado, de esta manera podríamos iniciar el proceso de consecución de prospectos de arrendatario y en paralelo podríamos refinar lo que consideráramos necesario.

En 1 fin de semana dejamos el apartamento listo para arrendar y en un periodo de 8 días ya teníamos arrendatario. 

De seguir como íbamos probablemente aún tendríamos cosas pendientes por hacer y la verdad es que siempre van a existir pendientes. En vez de eso ya entregamos algo a nuestro cliente (El arrendatario) y con el tiempo con seguridad seguiremos haciendo ajustes menores hasta acercarnos al ideal de perfección que queremos.

Se que el caso de ejemplo no es siquiera comparable con los proyectos a los que nos enfrentamos en la vida diario. Pero. ¿No les ha pasado algo similar?.