Testeando de a pares

Un par de testers, trabajando juntos, a menudo pueden hacerlo tan bien o mejor que un "cazador" de defectos experto. El trabajo de a pares puede ser estable (es decir, dos personas regularmente trabajando juntas) o mucho más fluído, como en XP (Extreme Programming) para desarrollo. En ese caso, el tester que es resposable de un área dada buscará compañeros de testing temporales quienes tengan experiencia útil o conocimiento para abordar alguna parte de dicha área.

Leer más...

Primeros pasos con la programación en parejas

La programación de a pares es una de las prácticas más ricas y dificiles de Extreme Programming, la que a mi entender genera el mayor cambio de mentalidad en el equipo. Hay muchas guías en Internet con consejos para aplicar esta práctica, y hoy me encontré con un artículo al respecto breve y útil. En Primeros pasos en pair programming, Wilbur Suero nos comparte 6 recomendaciones concretas para aplicar al momento de empezar a usar esta técnica. ¡Muy recomendable!

7 mitos del desarrollo Ágil

Alberto Gutierrez lleva varios años trabajando con Ágil, y llegó a la conclusión que hay varios principios dando vueltas que son sólo palabrerío que apuntan a convencer a la gerencia, y que en realidad no ayudan al desarrollo de la aplicación.

Leer más...

No escribo pruebas unitarias porque... (manual de excusas)

Siendo alguien que vive los beneficios de hacer TDD, creo profundamente en el desarrollo guiado por pruebas. Esta práctica agrega un nuevo nivel de calidad y madurez al desarrollo de software, y sin embargo todavía no es la técnica más usada en los proyectos de software. Cuando hay que elegir entre características, tiempo y calidad, siempre sufre la calidad. No queremos agregar tiempo extra para hacer pruebas, y tampoco queremos comprometer las características que vamos a entregar. Si no se pusieron como objetivo hacer TDD al iniciar el proeycto, es dificil hacerlo después.

Leer más...

Prácticas para mejorar la calidad del código

Hay muchísimas prácticas que podemos adoptar para mejorar la calidad de nuestro código. ¿Por dónde empezar? ¿Existe una lista única y completa? En este artículo veremos un pequeño listado de buenas prácticas, que nos pueden ayudar a comenzar ese largo camino que implica trabajar con más profesionalismo, mejorando los productos que desarrollamos.

Leer más...

¿Sos inteligente o tonto?

¿Cuál es la diferencia entre ser inteligente o ser tonto? Creo que podría resumirse en dos cosas: qué tan lejos en el futuro podés pensar, y qué tan rápido podés generar este pensamiento. Cuando alguien juega ajedrez, o poker, sus habilidades están determinadas por cuántas movidas puede pensar por adelantado. Cuánta historia pueden recordar, y así planificar el siguiente movimiento.

En el desarrollo de software, ¿qué tan lejos podés mirar? ¿Estás usando prácticas destructivas porque estás muy ocupado "terminando el trabajo"? ¿Estás ignorando buenas prácticas que podrían ahorrarte tiempo?

Leer más...

Las tres C de la arquitectura

En nuestro trabajo con clientes a menudo tenemos discusiones sobre la función de la arquitectura y el rol de los arquitectos. Estas discusiones ocurren porque la arquitectura no contribuye de forma visible a los objetivos organizacionales, y por lo tanto se la percibe como una molestia para los proyectos. Muchas discusiones se origina por la falta de entendimiento sobre el rol y el lugar de los arquitectos dentro de la organización. Hemos definido tres objetivos de la función de la arquitectura en organizaciones de TI: Las Tres C de la Arquitectura. Estas son: Conexión, Cohesión y Cambiabilidad. Al tomar estos conceptos como principios básicos de la arquitectura logramos enfocarnos en qué hacer y cómo posicionar a la arquitectura dentro de la organización.

Leer más...

Integración Continua para mantener el proyecto en rumbo

Hoy en día tenemos muchas herramientas que dicen limpiar de forma mágica nuestro código. Mueven, modifican, emprolijan y mágicamente resuelven todos nuestros problemas. Lamentablemente, como la mayoría ya sabe, escribir buen código lleva trabajo. No existen herramientas mágicas que puedan salvarnos (y no importa lo que nos digan los vendedores), pero si hay una herramienta que funciona muy bien para ayudarnos a mantenernos en forma.

Leer más...

Lista de comprobación para hacer TDD

El Desarrollo Guiado por Pruebas (o TDD) se suele describir como un ciclo de rojo-verde-refactor, que se repite continuamente, para ir agregando nuevas características o arreglar bugs. La siguiente lista de comprobación que comparte Giorgio Sironi contiene un grupo de preguntas que deberíamos hacernos a nosotros mismos mientras avanzamos por las fases de TDD, para no olvidarnos de la esencia de esta técnica.

Leer más...

Estándares de código... ¿para qué?

aplicacion-xmlComo desarrolladores, nuestro entregable es el código fuente, es lo que producimos, y por lo tanto debemos hacer que se vea bien. Pero, ¿qué significa "bien"? ¿Cómo debería verse? Podríamos armar debates interminables sobre el tema, y los resultados nos desilusionarían. No existe algo como el Mejor Estilo De Codificación.

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