Lima Agile Day 2010 – Test Driven Development
2010-04-19 | Categories: Blog, Geek | Tags: agile, presentations
El fin de semana tuve la oportunidad de volver a participar en Lima Agile Day, en esta oportunidad compartimos experiencias con Heitor Roriz y Marco Mafra ambos de Scrum Amazonia. ¿Qué puedo contar? bueno que fue una buena experiencia y como siempre contentos porque hemos aportado con un grano más de arena para difundir las metodologías y técnicas ágiles en el Perú.
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.
¡¡¡Gracias al equipo organizador lo hicieron muy bien!!!
2009-10-04 | Categories: Articles, Productivity | Tags: agile, mind, mind map
¿Qué son los mapas mentales?
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.
2009-04-26 | Categories: Blog, Geek | Tags: agile, presentations
La semana pasada se llevo a cabo Lima Agile Day 2009. Estuvo increíble! …. Se llevo de una manera muy organizada gracias al esfuerzo de todos los miembros de la comunidad y el público terminó motivado, sentí que se logró despertar mas aún el interés por metodologías como Scrum, XP y otras.
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.
A closer look inside PMBOK by an agile practitioner
2008-04-18 | Categories: Articles, Management | Tags: agile
I agree with every point of the Agile Manifesto and with almost all the agile practices. I believe that following an agile software development process is the right way to address most of the problems that we see in several projects nowadays.
So, why do I decide to take a PMI© Certification course?,.. well, I wanted to know more about PMI©, learn from it, modify it, adapt it to agile practices and write about everything I disagree/agree with. I just want challenge myself!
The course was divided in sections, one for each PMBOK© chapter. So I can read each chapter before class and prepare questions or topics for discussion in class. Yeah, that will be fun!
Well, as part of the Certification course my group has to develop all the documentation for a software development project reusing some templates that we received in the first day of class. This week, we had the first preliminary presentation of Project Charter and Preliminary Project Scope Statement documents. While I was looking the Preliminary Project Scope Statement template, I had a doubt about project phases because the template assumes sequential project phases and my partners defined them as: analisys, desing, implementatión, testing. OMG that’s waterfall!!!
I asked about how can I show clearly that I’m following an iterative process in the Preliminary Project Scope Statement but I didn’t receive a clear answer. Someone told me that PMBOK© assumes that project phases are sequential. Argggg!,… waterfall!!!
At night, taking a closer look in Chapter 2 – Section 2.1.2 – 3rd Paragraph, I found that PMBOK© uses as example an information technology project with iterative project life cycle!. In conclusion, PMBOK© assumes that most of the projects have sequential phases but there are exceptions like information technology projects using an iterative life cycle.
So it could be interesting to develop a template for Preliminary Project Scope Statements that assumes parallel and sequential phases and a mix of them.
Crunch Time: Mala practica en gestion de proyectos
2008-04-18 | Categories: Articles, Management | Tags: agile
Si no saben que es Crunch Time pueden revisen este post. Crunch Time es una de las malas practicas más generalizadas en la gestión de proyectos informáticos y consiste en exigir a los miembros del equipo a trabajar mas horas y a trabajar fines de semanas o feriados.
¿Por qué llegan la mayoría de proyectos al Crunch Time? Hay diferentes razones y entre ellas podría mencionar:
- Mala definición del alcance del proyecto: Si al definir el alcance del proyecto solo intervienen los vendedores, el cliente y el jefe de proyecto entonces todo saldrá mal. Los vendedores solo quieren vender y tienen de bajar tiempos, recursos con el fin de vender aun así sepan lo que pasará. Los clientes muchas veces no saben lo que quieren o quieren algo que es imposible realizar con el tiempo y dinero que pueden invertir. Los jefes de proyecto por lo normal tampoco saben de tecnologías y no piden un juicio experto (consultan al arquitecto de software)
- Mala estimación de tiempos: Tiene que ver mucho con lo anterior. El cliente quiere que todo sea rápido. El vendedor promete un tiempo para convencer al cliente sin consultar si es viable. El jefe de proyecto trata de cumplir con lo imposible porque ya todo esta bajo contrato, etc.
- Mala estimación de cantidad de recursos: A menos recursos más ganancia (vendedor), menos costo (cliente). El jefe de proyecto tendrá que exigir más y más al equipo.
- Over-engineering: Hacer más de lo que necesita el cliente, un ejemplo clásico es tratar de hacer un sistema extremadamente flexible. Al final el cliente nunca necesitará aprovechar esa extrema flexibilidad y peor aún esa flexibilidad no funciona correctamente.
¿Que resultado obtendremos con esto?
- Un equipo desmotivado y por ende un mal producto
- Un cliente enojado debido a que el tiempo, costo y calidad del producto no es el esperado
- Los miembros del equipo van renunciando, esto lleva a que en el siguiente proyecto se cometan los mismos errores
Y al parecer nadie aprende de estos errores, nadie trata de cambiar:
- Enseñar a los vendedores sobre tecnologías y que siempre consulten al arquitecto de software
- El arquitecto de software debe lo suficientemente fuerte para poder decir las cosas como son y no callar
- Presentar al cliente opciones factibles/reales para solucionar sus necesidades. Si quiere menos costo o tiempo disminuir las funcionalidades para mantener la calidad del producto. De que le sirve al cliente un producto que se entrego a tiempo y con los costos exactos y no es de buena calidad. Tarde o temprano el producto será más y más costoso para el cliente.
- El jefe de proyecto debe negociar y no tratar de cumplir por cumplir
- Documentar las experiencias adquiridas sean buenas o malas para tomarlas en cuenta en los siguientes proyectos
Y mi recomendación final: Digan NO al Crunch Time!!!! o cobren mucho mucho mucho mas!!!! 
Dedicado a mis amigos que en estos
momentos están en Cruch Time.
Importancia de definir un ambiente de base de datos
2006-12-30 | Categories: Articles, Technology | Tags: agile, database
Es importante definir un ambiente adecuado y políticas claras para un proyecto de desarrollo de software. En este artículo quiero concentrarme en la base de datos, que cumple sin lugar a dudas un rol de vital importancia en los sistemas actuales.
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.
