10 formas de mejorar la Planificación de Poker

Cartas de pokerQuienes promueven el uso de la Planificación de Poker comprenden varios de los motivos de su éxito. Hay muy buenas razones por lo cuales la mayoría de los coach ágiles la utilizan y enseñan a sus equipos.

Los 3 motivos más importantes para del éxito de la Planificación de Poker son:

  1. Fomenta la colaboración a través de todo el equipo.
  2. Crea estimaciones por consenso en vez de tener a un único individuo que estime.
  3. Expone problemas de manera temprana, a través de discusiones sobre cada historia de usuario.

Leer más...

La duración ideal de una iteración

ReglaCon la popularidad de las metodologías ágiles para el desarrollo de software también aumento la popularidad del desarrollo iterativo, tanto en equipos ágiles como en los tradicionales. Una consideración clave en los procesos iterativos es definir qué tan larga deben ser las iteraciones. Las recomendaciones varian, desde 1 semana para equipos de Extreme Programming hasta 1 mes para equipos con Scrum. Algunos equipos también usan iteraciones más largas todavía, aunque la mayoría utiliza iteraciones de entre 1 semana y 1 mes.

Leer más...

Calidad de software con BDD y ATDD

En un artículo anterior sobre la calidad interna y externa del software plantee la importancia de la testeabilidad para la calidad de un sistema. Reforzando el mensaje: cuando se aumenta la testeabilidad del software, mejoras directamente  tu arquitectura y tu diseño. Desarrollar sin pruebas unitarias automatizadas y sin pruebas de aceptación es simplemente, construir código legado desde el momento cero!

Leer más...

Contratos de precio fijo: El gran dilema

Tengo una conferencia bien conocida sobre contratación y estimaciones de proyectos de software. Trata bastante el tema y se muestra cómo no sólo existen contratos de precio fijo para comprar proyectos.

Sin embargo, en Brasil, la gran mayoría de los proyectos desarrollados por terceros proveedores siguen siendo contratados con la modalidad de precios fijos. Muchos agilistas sólo critican el contrato, sin mostrar salidas cuando no hay otra alternativa y el cliente todavía requiere de contratos a precio fijo. Por supuesto que el ideal sería firmar un contrato de alcance variable o deslizante y siempre debe ser intentado y negociado. Pero todavía tenemos muchas empresas que seguirán comprando en la forma de precio cerrado.

Leer más...

Lean, Kanban y Ágil

Los días 6 y 7 de Mayo de este año 2009 en Miami (Florida, EE.UU.) tendrá lugar la Conferencia de Kanban y Lean 2009, lo que será el primer evento internacional sobre el sistema Kanban y Lean aplicada al desarrollo de software.

El sistema Kanban de TPS (Sistema de Producción Toyota) es una de las herramientas del pensamiento Lean que nos permite gestionar de manera ajustada al ciclo de producción y evolución de productos. Recientemente, esta filosofía ha ido ganando mucha sinergia con el desarrollo de software, principalmente por la propagación de metodologías ágiles, que en cierto modo, es un excelente punto de partida para la practica de conceptos inherentes al Pensamiento Lean. 

Leer más...

Lean y ágil: ¿matrimonio o contradicción?

Sí, estoy tratando de provocarlo deliberadamente. Y sí, de una forma mucho más específica, creo que la última mitad de la pregunta es la verdad.

Eso puede ser sorprendente, ya que LeanAgile parece haberse convertido en una palabra en el mundo del desarrollo de software. Así que tal vez, algunas advertencias no vienen mal.

Conozco a Mary y Tom Poppendieck por más de una década. Fuimos amigos y colegas en el grupo más grande de usuarios en el mundo - en Minneapolis. Tom fue mi alumno en la Universidad de St. Thomas.  Tom fue uno de los revisores técnicos de mi libro sobre objetos. 

Leer más...

Estimando en puntos de historia

Cinta de medirPuede resultar algo dificil lograr que los equipos estimen utilizando Puntos de Historia. Cuando se explica el sistema de Puntos de Historia muchos no logran captar el concepto. Al estimar se suele pensar en días u horas, lo que complica más el cambio a una medida que parece tan oscura e ilógica. 

Pero una vez que se comienza a utilizar los puntos de historia, solamente lleva un par de sprints hasta que el equipo entiende la magia detrás de esta fabulosa práctica. ¿Qué hace que estimar por puntos de historia sea tan importante… y tan bueno?

Leer más...

Haciendo hablar al burndown de Scrum

FuegoEs común que algunos equipos, durante la retrospectiva, tengan problemas en seguir y recordar los impedimentos que tuvieron y el contexto dentro del cual ocurrieron. Una forma de salvar esta situación es crear eventos clave e impedimentos diarios en el mismo gráfico de burndown. Este gráfico ya tiene una escala de tiempo, así que ¿por qué no aprovecharla?.

En este artículo veremos dos variantes para que el gráfico de Burndown nos muestre más información útil.

Leer más...

La cura para la estimación de tareas: ¡no hacerlo más!

CalculadoraA veces veo algunos equipos obsesionados con la planificación del sprint, especialemente con la estimación de las tareas. Quiero decir, realmente obsesionados. ¿Dos días de planificación para un sprint de dos semanas? Aunque no lo crean, ocurre. Incluso aunque se quejan de pasar mucho tiempo en las reuniones de Scrum, insisten y discuten los detalles de la estimación de cada tarea. Por suerte, para aquellos equipos que quieran aprovechar su experiencia en Scrum y en las planificaciones, eliminar la estimación de tareas es una opción.

Leer más...

Por favor, ¡escriban tests!

Creo que pasó la hora que los desarrolladores maduren un poco en cuanto a la necesidad de probar TODA y CUALQUIER aplicación que sea escrita, independientemente de su tamaño. Creo que ya pasó hace mucho la fase en la cual la arrogancia era suficiente para creer que su aplicación funcionaría sin tests (después de todo, ¡usted es el mejor programador del mundo!).

Leer más...

¿Estimar o no estimar?

Este es un asunto un poco controvertido en la comunidad, tenemos defensores de los 2 abordajes, los libros de Ken Schawber y Mike Cohn, vemos la recomendación de estimar las tareas en horas, pero ya hace algún tiempo la idea de abrir mas las estimaciones de tareas está creciendo y ganando fans y yo soy uno de ellos en particular. Lo que suele ocurrir es que la planificación del sprint puede ser largo y cansador cuando el equipo tiene que estimar cada una de las tareas que considera son necesarias para desarrollar los temas del backlog, que normalmente se ve son interminables discusiones de si una tarea va a llevar 4 o 6 horas, cuando esta información no es realmente importante a la hora de entregar un elemento rápido.

Leer más...

Seguinos en Facebook.

Publicá tus artículos.

Publicar Convertite en redactor para Dos Ideas y compartí tus conocimientos a una comunidad que sigue creciendo!
Quiero publicar

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