Mis presentaciones suelen tener poco contenido y muchas imágenes así que lo más practico es compartir el mapa mental con el cual arme la conferencia.

Abner Ballardo Xmind Account

¡¡¡Gracias al equipo organizador lo hicieron muy bien!!!

Es una técnica que busca potenciar la forma de trabajo que tiene nuestro cerebro, a través del uso de palabras o imágenes relacionadas entre si con lineas. Estos diagramas son más fáciles de recordar que lineas de texto, es más puede incluso estimular nuestro cerebro a encontrar otros conceptos y relacionarlos con los que ya se tienen.

Los mapas mentales son diagramas que se usan para organizar, generar ideas y capturar información; podemos usarlos para estudiar, resolver problemas, tomar decisiones, escribir artículos y mucho más.

¿Cómo es un mapa mental?

Es simple, primero comenzamos con una idea central:

Luego vamos agregando agregando palabras/conceptos relacionados. Es importante el uso de colores.

Una imagen vale mas que mil palabras así que podemos agregar imágenes que ayuden.

Pueden ayudar otras relaciones entre los conceptos que ya tenemos e incluso podemos trazar líneas en blanco para motivar nuestro cerebro a buscar más conceptos.

¿En que podemos usar mapa mentales?

Prácticamente en todo, por ejemplo :

• Para tomar notas: En clases o en una reunión es importante capturar de manera rápida los conceptos claves.
• Lluvia de ideas: En grupo o de manera individual es importante capturar todas las ideas que vengan y motivar que nuestro cerebro busque la mayor cantidad de conceptos relacionados con el tema central.
• Toma de decisiones: Primero hacer una lluvia de ideas y luego organizarlas para que podamos tomar una decisión.
• Presentaciones: Una manera simple y rápida de armar una presentación que sea fácil de captar por el público.
• Productividad: Capturar tareas, organizarlas, priorizarlas, etc. Por ejemplo es un buen complemento para la técnica de Getting Things Done.

En próximos artículos tocaré con mayor detalle de cada una de las aplicaciones de los mapas mentales.

¿Qué necesitamos?

No necesitamos mas que lapiz/lapicero y papel para comenzar con los mapas mentales, aquí algunas ideas:

• Una hoja en blanco (sin lineas) y lápices de colores: Es lo ideal usar colores pero cuando es necesario incluso podemos usar una servilleta y un lápiz negro.
• Moleskine: Podemos usar este legendario cuaderno y lápices o lapiceros de colores.

En el mundo virtual tenemos muchos programas disponibles, entre ellos les recomiendo:

• Freemind: Simple, ligero y multi-plataforma.

• Xmind: Es un producto completo y que uso para casi todo en mi día a día.

Es fácil de aprender

Todo el tiempo que llevo usando esta técnica he encontrado que solo es necesario explicar los conceptos básicos de mapas mentales, luego cada uno por si solo puede usarlo y encontrar el potencial de esta técnica, descubrir nuevos usos, etc. Ejemplo de esto es como se difundió el uso de mapas mentales en las comunidades de Agile Perú y Spring Perú así como en mi centro de trabajo.

Los animo usar esta técnica que es simple pero muy potente, en estos enlaces pueden encontrar otros ejemplos de mapas mentales:

• Xmind Share
• Modlost’s Xmind Share Page

Me hubiera gustado hablar de Extreme Programming a fondo pero dado que el objetivo de la conferencia era brindar una introducción a metodologías ágiles, decidí que era mas beneficioso compartir algunos tips para aplicar técnica ágiles. Las dividí para desarrolladores, jefes de proyecto y usuarios finales,… y tuvo una buena acogida

Me enfoqué en compartir mi visión: “Desarrollar software es un arte”, el software es complejo, muy variable y tiene muchas formas de implementarlo. Por ello, la combinación elegante de diseño, código, nomenclatura tiene algo arte y belleza.

Este es el mapa mental de la conferencia:

Seleccionando “Outline” podrán acceder a los URL’s dentro del mapa mental.

La comunicación entre los miembros de un proyecto es muy importante y si no es buena o no se realiza en el momento adecuado traerá consigo una serie de inconvenientes. Por ejemplo: Si un programador se entera tardíamente de alguna modificación de la estructura de la base de datos, esto traerá: incomodidad, bugs y demoras. Por ello, es necesario establecer políticas sobre como y quien debe informar a los interesados de algún cambio en la base de datos. Si no existen políticas claras, documentadas y que estén bien comprendidas todo sera un gran desorden.

Otros problemas tienen que ver con el ambiente de base de datos y suceden con mucha frecuencia. Algunos ejemplos pueden ser resumidos con estos comentarios:

• No puedo probar mi código/funcionalidad porque hay data incoherente en la base de datos
• No se porque la aplicación se cayo cuando la llevamos a producción
• ¡No puedo seguir!, la base de datos esta lenta. Y alguien responde: es que Juan Peréz esta probando un proceso pesado
• La aplicación esta muy lenta en producción. Hay que ver la manera de mejorar el tiempo de respuesta pero primero llena la base de datos de prueba con mas registros
• ¿Alguien apagó la PC donde esta la base de datos?

La propuesta que más me agrada para definir el ambiente de base de datos, es la de Scott W. Amber. El lo denomina database sandboxes:

Cada programador cuenta con una base de datos propia (development sandbox) donde puede realizar todo lo que desee, de preferencia esta base de datos debe estar en su propia PC. Por otro lado se debe tener una base de datos para integración (project integration sandbox), donde los programadores puedan realizar pruebas de integración.

El proyecto necesitará una base de datos especial (demo sandbox)) para mostrar a sus stakeholders un demo de la aplicación o para realizar pruebas de aceptación. Finalmente, se debe tener una base de datos (pre-production Test/QA sandbox) para realizar pruebas (QA) y para probar la aplicación con data similar a la que procesará/usará en producción.

Una vez establecido este ambiente y luego que el equipo ha asimilado la forma de trabajo, sería muy interesante (y un reto también) intentar aplicar las propuestas de Evolutionary/Agile Database Development.