JUnit 4.6 publicado

JUnitYa está disponible JUnit 4.6, la nueva versión del framework de pruebas para Java basado en XUnit. Esta nueva versión incluye arreglos de bugs y una nueva arquitectura que permite reordenar y paralelizar tests y tests suites.

Entre las novedades más importantes se destaca el nuevo Core experimental, llamado MaxCore. MaxCore recuerda los resultados de las corriedas de tests anteriores, para luego poder ejecutar nuevos tests en otro órden. MaxCore prefiere a los tests nuevos por sobre los viejos, a los rápidos por sobre los lentos, y a los tests que fallaron recientemente por sobre los que hace mucho vienen fallando.

¿Que significa calidad de software?

¿Qué siginifica Calidad en Desarrollo de Software? Tal como se utiliza hoy en día, Mike Bria dice: "Calidad" se refiere a "ausencia de defectos" en lugar de "presencia de valor".

Y sugiere:

"Calidad" debe ser utilizado como una medida de utilidad funcional/evidente para nuestro consumidor, y NO como medida de defectos. En realidad, se debería suponer que los defectos están usualmente ausentes. Esto debería estar implícito en lo que significa ser un profesional.
Así que: Aquí, propongo que nosotros, como profesionales del software y hombres de negocio dejemos de utilizar la palabra "calidad" como significado de "medida de defectos;.

Leer más...

Medición y seguimiento ágil

Además de otras actividades, dirijo a algunos equipos de desarrollo. Por eso, la gobernabilidad es un tema que me es muy querido. Es decir, ¿cómo saber si mis equipos están mejorando?. Y ya que creemos en el modelo ágil, como saber si mis equipos están siendo ágiles.

Una crítica habitual - y pertinente de alguna manera - que se hace a XP y Scrum es la falta de un sistema de gobierno. Es decir, como definir un mecanismo para dirigir a los equipos a trabajar con desarrollo ágil. Hablo sólo de XP y Scrum, porque yo no sé si las otras metodologías ágiles tienen mecanismos de gobierno.

Leer más...

Contratos para los proyectos Ágiles, parte 2

ContratoTanto el cliente como el proveedor de software al inicio de un proyecto de desarrollo de software saben que hay demasiado en juego para trabajar sólo con un acuerdo verbal. Un contrato es en realidad un conjunto de reglas escritas de juego. Las reglas correctas incrementan la probabilidad de éxito para ambas partes. Las reglas incorrectas hacen que la cooperación sea dificil y entorpecen el progreso. ¿Cuáles son los tipos de contratos que existen, y cuál es el mejor enfoque para un proyecto ágil? 

Leer más...

Trabajar muchas horas no es bueno para vos ni para tu equipo

RelojLamentablemente, este simple tema de asegurar que nadie trabaje muchas horas por día (más de 10 ó 12) en un equipo a veces no sucede. Cuando un equipo está atrasado con respecto a la planificación, la primera cosa con la que un líder novato (o no hábil) es presionar para que su equipo haga muchas horas de trabajo. En una organización de desarrollo, si un líder hace ésto alguna vez es inmediatamente puesto en la lista negra por la gente que lo rodea.

Leer más...

Contratos para los proyectos Ágiles, parte 1

ContratoAunque el Manifiesto Ágil valora más a la colaboración con el cliente que al contrato, los contratos son necesarios cuando se trabaja con proveedores externos. Un contrato en realidad es un conjunto de reglas que delimitan el área de juego. Usar las reglas correctas aumenta las probabilidades del éxito para ambas partes. Usar las reglas incorrectas van a dificultar y entorpecer el progreso. Entonces, ¿cuáles son las reglas de juego disponibles, y cuál es el mejor contrato para un proyecto ágil?

En esta primera parte del artículo de Agile Manifesto, vamos a analizar el propósito y contenido de los contratos, y algunos criterios para evaluar a los contratos ágiles. En el siguiente artículo vamos a ver distintas alternativas para contratos ágiles, examinando sus fortalezas y debilidades.

Leer más...

Kanban vs. Scrum

KanbanEn nuestro equipo de desarrollo llevamos algo más de un año trabajando con Scrum.  Y ahora, para los pedidos de cambio, arreglos de bugs, mantenimiento de aplicaciones productivas y todo aquello que no llega a una iteración de Scrum, estamos abordando el uso de Kanban.

Nos viene bien una comparación de ambas herramientas metodológicas. Nos basamos en una guia práctica Kanban vs. Scrum, de Henrik Kniberg.

Leer más...

Reutilización de código (lo que todo jefe quiere)

En un reciente debate en la lista de Extreme Programming  en Yahoo Groups se exploró el conflicto aparente entre desarrollar software reutilizable y la práctica de XP de no escribir el código hasta que se necesite.

Ron Jeffries y otras personas compartieron sus ideas acerca de los costos y beneficios de la reutilización de código, y cómo y cuándo ponerlo en práctica en un entorno ágil.

Leer más...

Podcast sobre los principios de la agilidad

PodcastLa gente de JavaHispano publicó el Podcast: Principios de Agilidad, dedicado al desarrollo ágil, en donde entrevistan a tres miembros de Agile-Spain. En la entrevista participarán Jose Manuel Beas autor del blog Se hace camino al andar..., Xavier Quesada autor del Blog de Visual Management y Xavi Albaladejo autor del portal http://www.proyectosagiles.org una base de conocimientos de Scrum.

Leer más...

Toma de decisiones: la resolución

Signo de preguntaEn los artículos anteriores vimos que tomar decisiones sin intención es muy perjudical para los equipos, y para solucionar esto planteamos utilizar el Protocolo de Decisión, una práctica para tomar decisiones basándose en el consenso unánime. Pero las personas son libres para votar y defender sus ideales, por lo cual es posible que no logre generarse el consenso unánime buscado en una primera instancia.

En este artículo final de la serie exploraremos el Protocolo de Resolución, una práctica que se puede utilizar en distintos escenarios cuando las pesonas no pueden llegar a un acuerdo unánime sobre algún tema. La idea será olvidar todos los rencores y diferencias, y sólo centrarnos exclusivamente en lo que haría cambiar de parecer a los disidentes.

Leer más...

Toma de decisiones: la decisión

Signo de preguntaComo vimos en el artículo anterior, la toma de decisiones sin intención genera caos y perjudica a los equipos que desarrollan software, impiendo que puedan crear el mejor producto posible. Las técnicas habituales para tomar decisiones, tanto por mayoría o autocráticas, presentan importantes problemas. El Protocolo de Decisión brinda una estructura para que los equipos puedan ejercer su facultad cognitiva, que genera responsabilidad por las decisiones tomadas.

En este artículo exploraremos el Protocolo de Decisión, que utiliza un proceso confiable y orientado al consenso para que un equipo tome decisiones. Esta práctica busca tomar decisiones por unanimidad en el equipo... Esperen, esperen, ¿creen que es imposible lograr la unanimidad absoluta en un equipo? Los invito primero a leer este artículo, sin preconceptos.

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