Programación en parejas vs Revisiones de código

La Programación en parejas y las Revisiones de código son prácticas que aumentan la calidad del software, así como promover la difusión del conocimiento. Si bien los debates Ágil vs Lean, Scrum vs XP, vi vs Emacs andan a baja velocidad, los desarrolladores son conocidos por discutir los méritos de la programación en parejas versus las revisiones de código.

Theodore-Nguyen Cao describió las revisores de código como gallinas, y los programadores en parejas como cerdos.

La historia de la gallina y del cerdo es generalmente discutida en el círculo de la agilidad. Al hacer un desayuno con bacon y huevos, la gallina está involucrada pero el cerdo está comprometido.

Leer más...

NetBeans es el gran ganador de Developer.com 2009

netbeansTodos los años la gente de Developer.com lleva a cabo la votación de los mejores productos y tecnologías del año. Los finalistas se anunciaron en noviembre pasado, cuando comenzó la votación abierta. Hoy ya se conocen los ganadores del Producto del Año de Developer.com 2009.

En esta edición no sólo se recibieron más votos que en los últimos dos años, sino que hubo una clara victoria entre el primer y segundo puesto de cada categoría. Esta vez no hubo "segundos cercanos". El ganador de cada categoría lo hizo con un margen respetable.

El proyecto NetBeans fue el gran ganador, llevándose el primer lugar en 5 de las 12 categorías.

Leer más...

Planificación efectiva de un sprint

tildeAl comienzo de cada sprint, el equipo de Scrum y el Dueño del Producto negocian el alcance del sprint. Tienen una cantidad limitada de tiempo para discutir y acordar el backlog del sprint. El Dueño del Producto quiere que la funcionalidad se implemente adecuadamente e invertir el dinero de forma inteligente. El equipo quiere un acuerdo que pueda cumplir. ¡Y todos quieren que la reunión termine a tiempo!

A continuación veremos una agenda propuesta para que las planificaciones del sprint sean exitosas.

Leer más...

Si querés algo simple, olvidate de lo Ágil

Luiz Rocha escribe con razón acerca de los peligros de confundir ágil con un conjunto de métodos que deben seguirse para que el "proceso" funcione. Es algo natural de las organizaciones -que por extensión son personas- procurar un punto de equilibrio entre las necesidades discordantes y éste es uno de los más propicios para trasformar la filosofía Ágil en una metodología que difiere poco de la tradicional cascada.

Además, hay una gran tentación de pensar en Ágil como lo opuesto de Cascada y convertir esto en una excusa para no tener ningún proceso o método coherente de desarrollo. Es muy común encontrar empresas inmersas en la desorganización que describen sus procesos como ágiles.

Leer más...

Una guía Ágil para el desarrollo Lean, parte 3

mapa con brujulaEn el primer artículo de esta serie vimos los siete principios Lean y sus bases fundacionales esenciales. Durante la segunda parte analizamos cada principio Lean y mostramos algunas prácticas Ágiles que los implementan. En esta tercera y última parte refleccionaremos sobre la práctica de Justo-A-Tiempo (JIT) y sobre el uso de Lean en general.

Leer más...

¿SOA está muerto?

ripAnne Thomas Manes escribió un obituario para SOA, con el argumento de que:

SOA encontró su fallecimiento el 1 de enero de 2009, cuando fue eliminado por el impacto de la recesión económica. SOA es sobrevivido por su descendencia: mashups, BPM, SaaS, Cloud Computing y de cualquier otro enfoque de arquitectura que se basa en "servicios".

Ella continúa:

Leer más...

Lidiando con "Rotten Apple" de su equipo

En los últimos días ha habido un debate muy activo en el grupo de Scrum Development do Yahoo Groups sobre qué hacer cuando una persona de su equipo está teniendo "bajo desempeño". En el hilo de más de 130 respuestas, Rotten Apple in Scrum Team, el debate fue desde consejos hasta la cuestión principal, hablando de la moral del equipo y quien la gestiona, hasta el clásico debate de la medición de
los individuos, para distinguir si un equipo es realmente un "equipo" y más.

Marko Majkic comenzó el debate describiendo a un miembro de su equipo que parece tener problemas de "bajo desempeño" y pedió consejos sobre cómo hacer frente a eso (cita derivada del post original y de una respuesta posterior):

Leer más...

Una guía Ágil para el desarrollo Lean, parte 1

mapa con brujulaLa cosa más valiosa que puede gastar un hombre es el tiempo - Theophrastus (372 AC - 287 AC)

Lean es el nombre del método que usa Toyota para producir y desarrollar automóviles. Como desarrolladores de software no hacemos ninguna de esas dos cosas, así que ¿por qué nos debería interesar? La razón es simple: los principios básicos del método de Toyota son principios que en la realidad aplican en cualquier lugar. No son panaceas: los principios son universales, aunque puedan variar las prácticas específicas.

En esta primera parte de la guía vamos a ver los siente principios principios y las bases del pensamiento Lean.

Leer más...

La ley de Moore es muy lenta

Los avances en "cloud computing", clustering y para fines generales de computación con utilidades de GPU's sugieren que el poder de cálculo por cada dólar se puede aumentar significativamente más rápido de lo que la Ley de Moore predice.

La primera semana completa de enero es siempre un momento emocionante en la industria informática. El Consumer Electronics Show y MacWorld traen anuncios de nuevos productos, empresas informáticas que no están orientadas a los pequeños consumidores también tienden a hacer nuevos anuncios, con el fin de no estar fuera de los medios de comunicación. Esta semana, varios anuncios sugieren que un modelo más distribuido de  "cloud computing" orientará la arquitectura de los grandes sistemas, aumentando rápidamente la potencia de cálculo para el usuario, incluso más que la Ley de Moore sugiere.

Leer más...

Ejecutando ágil despues de renuncias

Adrian Carr escribió acerca de la adaptación de la implementación de Scrum de su equipo después de renuncias. Originalmente, el equipo era un grupo de cuatro desarrolladores, un tester, un Dueño del Producto y el Scrum Master. Después de los recortes, el equipo se redujo a cuatro miembros con Adrian como Scrum Master en medio plazo y ningún Dueño de Producto dedicado. La unidad de negocio tuvo el mismo problema de personal que el grupo de desarrollo y, por tanto, fue capaz de proporcionar sólo un "punto de contacto senior que entiende el negocio y está autorizado a tomar decisiones sobre el proyecto." Así que la pregunta que se hizo él fue: ¿Qué partes de Scrum se deberían mantener? El primer intento de Adrian incluyó:

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