Ágil para un Project Manager tradicional

saltar obstaculosLos Project Managers (PM) tradicionales suelen mirar a las metodologias agiles como algo raro, distinto y, por lo tanto, las encaran con desconfianza. Y es que, realmente, son un enfoque completamente distinto al sugerido por las metodologias tradicionales (o "pesadas", como se les dice desde en el mundo ágil). Sin embargo, es posible encontrar algunos puntos de encuentro, un área común desde donde poder comenzar un dialogo, y empezar a caminar un recorrido distinto para la gestión de proyectos.

Este artículo intenta encontrar ese punto en comun y acompañar a los PM hacia un primer vistazo a una alternativa cada vez más utilizada en todo el mundo para la gestión de proyectos de sistemas.

Leer más...

Tecnología, sí pero no

Me desespero un poco. Personas y organizaciones quieren tecnología. Ha llegado la hora de la web 2.0. Todos quieren llegar cuanto antes a la tierra prometida. Vengan cursos y más cursos.

Y no, no y no. No es la forma. Más de una y de uno van a sufrir. Porque querer usar las herramientas de la web social sin soltar lastre va a conducir a que muchas organizaciones lo pasen mal. Sobre todo directivos y gente de sistemas. Se van a rebelar. Esto es un arma que la carga el diablo.

Leer más...

Juegos de pruebas

Sin lugar a dudas, una de las formas más originales de probar un producto, y que he tenido la oportunidad de experimentar este año, es la de jugar con él. Sí, jugar, habéis leido bien. Intentaré explicar el concepto en los siguientes párrafos.

Cuando un producto está llegando a su fecha de lanzamiento empieza el periodo estresante de pruebas exhaustivas. Normalmente, el producto se cerrará en cuando a código fuente y a partir de ahí entrará en proceso de integración y pruebas por parte del equipo de tests. Una vez que termine este período, podremos lanzar nuestra tan esperada versión. Obviamente, nos interesa que cuando el producto llegue a manos del cliente, éste se encuentre impecable y totalmente libre del más mínimo error, problema de rendimiento, agujero de memoria, o cualquier otro efecto indeseable.

Leer más...

Integración Contínua o vergüenza pública

Hace un tiempo leí que una de las medidas que Mike Clark promovía en el libro Pragmatic Project Automation es la de mostrar el resultado de las diferentes build de la manera más visible que se pueda.

El objetivo de la medida está claro, saber lo más pronto posible cuando y por qué se ha producido un evento que ha roto el proceso de build de la aplicación.

Leer más...

Queme sus gráficos Burn-down

En muchos artículos sobre scrum, el grafico tradicional burn-down todavía se representa como el método preferido para mostrar los progresos en un sprint o proyecto. Sin embargo, desde la introducción de graficos burn-down, varias han sido las mejoras sugeridas por los principales autores y expertos. Estoy de acuerdo con cada uno de ellos, y mi sugerencia para ustedes es intentar ver estas ideas, y cambiar la forma en que grafican por completo!

Leer más...

Exponé en 20 diapositivas y sentate de una vez

proyector de diapositivas¿Quién no asisitó alguna vez a alguna presentación que parecería interminable? El tiempo se estira hasta romper cualquier límite físico, el orador divaga sobre cuanto tema crea dominar, y las horas van pasando y pasando. A veces el presentador parece quedar tildado en una diapositiva, hablando y hablando sin parar, exprimiendo los conceptos al máximo (mientras, el público empieza a rogar, silenciosamente, que termine de una buena vez esa bendita diapositiva, con la secreta esperanza de que además sea la última y se de por terminada la tortura charla).

Evidentemente, hay formas mejores de dar una presentación. Una de estas maneras es utilizar el concepto de Pecha-Kucha.

Leer más...

Como hacer y/o comprar software de calidad

En la gran mayoría de los proyectos de software necesarios para desarrolladores internos (del departamento de TI) o externos (de consultoría y fábricas de software), podemos notar que los principales puntos de medición del funcionamiento son los plazos de entrega y costo. Como Robert Austin nos muestra perfectamente, en su libro "La medición y la gestión del rendimiento en las Organizaciones", la medición de un sistema complejo a través de unos pocos parámetros (métricas) hace que sea disfuncional y genera el efecto contrario a los fines previstos.

Leer más...

Cómo usar Kanban en el desarrollo de software

kanjiUn kanban (en kanji 看板 donde kan (看) significa "visual", y ban (板) significa "tarjeta" o "tablero") es un concepto de producción justo-a-tiempo.

El kanban es una tarjeta física que se utiliza en el Sistema de Producción de Toyota (TPS - Toyota Production System) para soportar un control productivo descentralizado por demanda. Actualmente en el desarrollo ágil de software se visualizan los proyectos mediante la publicación de tarjetas con tareas en una pared, lo cual se conoce como "software kanban" o "tareas kanban".

Pero exactamente, ¿qué es kanban? ¿Cómo se puede utilizar en el contexto del desarrollo de software?.

Leer más...

Antes de construir software, debemos construir personas!

Con este artículo pretendo ayudar a aclarar la importancia del ScrumMaster, cuál es su papel en una organización de desarrollo de software que debe ser aprendido y como deben ser las características de liderazgo.

Resolvi escribir este artículo basado en dos fuentes de inspiración: La primera es el enorme número de libros que describen en detalle el sistema de producción Toyota (o Lean Production), su filosofía y cultura (libros son: El Toyota Way, The Toyota Way Fieldbook, Toyota Toyota talento y cultura). La segunda inspiración se basaba en los debates que tuvieron lugar en las listas en el desarrollo ágil, con respecto a si el ScrumMaster es necesario y si el ScrumMaster es solo una función.

Leer más...

Programación en parejas

Se tiene que programar por parejas si se sigue un proceso ágil.
Esto es completamente falso. 'Ágil' es un término muy amplio definido sólo en términos de valores y principios, el más notablemente en el Manifiesto para el Desarrollo de Software Ágil. El manifiesto no menciona el programar por parejas y la mayoría de los métodos ágiles no lo incluyen en su aproximación.
Ya que programar por parejas es una práctica de XP, ha tenido mucha influencia en la comunidad ágil. Por consiguiente a menudo es mencionado como una práctica ágil – tomando como práctica algo que es comúnmente usado por la gente en proyectos ágiles. Pero esto es una observación, no una prescripción..

Leer más...

El quinto valor ágil

manifiestoEn marzo de 2001 diecisiete críticos de los modelos de mejora del desarrollo de software basados en procesos se reunieron para tratar sobre técnicas y procesos para desarrollar software. En la reunión se acuñó el término “Métodos Ágiles” para definir a los métodos que estaban surgiendo como alternativa a las metodologías formales (CMMI, SPICE) a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo.

Los integrantes de la reunión resumieron los principios sobre los que se basan los métodos alternativos en cuatro postulados, lo que ha quedado denominado como Manifiesto Ágil.

Leer más...

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw