Principios del manifiesto ágil (Principio 1)

05/19/2010

Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.

Este principio es la base de los desarrollos iterativos y es lo que lo diferencia de los métodos tradicionales.

La idea es cambiar el concepto de planificar todo antes de empezar a entregar software funcionando al cliente por una idea de pensar que es lo que necesita mi cliente ahora y empezar a solucionar problemas lo antes posible.

Por software de valor se refiere a algo que resuelva un requerimiento del cliente (que aporte valor al sistema)

Por entrega temprana se refiere a hacer entregas más rapido de lo que se haría con una metodología tradicional en cascada

Y por continua se refiere a iteraciones de duración fija. Al principio del proyecto se debe acordar con el cliente, una duración fija de iteración y si se establece cada 3 semanas, entonces debe asumirse el compromiso de entregar software de valor cada 3 semanas.

Anuncios

Cuando se empiece a usar IPv6 habrá que cambiarlo, pero por ahora es válido y divertido

05/19/2010

Aprovecho el buen comic que sacaron hoy los muchachos de xkcd.com para hacer una referencia a su página.

Yo ya los tengo en mi lector de rss y cada tanto me encuentro con algo gracioso.


Manifiesto ágil

05/19/2010

Hoy quiero compartir el manifiesto por el desarrollo ágil de software, es bastante interesante y esta bueno para analizar lo que propone esta gente:

Manifiesto por el Desarrollo Ágil de Software

Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.

Como dice al final, se valoran más lo de la izquierda, no quiere decir que los de la derecha no sean importantes.

Yo creo que vale la pena mirar bien todos los renglones y prestar atencion a las 2 partes de cada oración. Se puede mantener un buen grupo de trabajo, con individuos capacitados y que interactuen bien entre ellos y a su vez proveer de procesos y herramientas que mejoren el trabajo de ellos.

En cuanto al Software funcionando, este es el objetivo de todo el proyecto, por supuesto que es más importante que la documentación. Pero no hay que agarrarse de esta frase para no hacer nada de documentación, hay documentación importante que ayuda a mejorar el funcionamiento del software, esta es la documentación que vale la pena. Lo que no hay que hacer es perder tiempo en documentación para encajonar y que nadie la vuelva a ver.

En cuanto al punto del cliente, es más un aspecto psicológico. No tiene sentido estarse peleando con el cliente, por si pidió o no pidió algo. Como profesionales lo que más nos sirve es que nuestro soft se use. Y para eso hay que hacer lo que pida el cliente. Colaborando con el cliente vamos a lograr que este colabore con nosotros y vamos a lograr software de mejor calidad.

Lo de la respuesta ante el cambio tiene mucho que ver con todo lo anterior. Planificar es importante, lo que no hay que hacer es planificar para demasiado adelante, y pretender que no cambie nada. Si se acepta el cambio como algo natural, cuando cambia algo se está más dispuesto a trabajar en esa mejora y no se lo toma como algo negativo. Además… es lo que nos da de comer, así que bienvenidos las cosas raras y los cambios, jaja.



Pivotal Tracker, una herramienta para tener en cuenta

05/18/2010

Hola

Hoy estuve investigando un poco esta herramienta gratuita para gestión de proyectos siguiendo la metodología de Scrum.

La verdad que es bastante simple, gratis y permite hacer un seguimiento bastante bueno de un proyecto. Además permite realizar estimaciones usando la escala de Fibonacci con lo que puedo aplicar el método de estimación que aprendí el sabado pasado 😀

Por ahora lo que hice fue ir agregando las stories de mi proyecto de nutrición y la verdad que la herramienta parece bastante sencilla de usar y da un pantallazo general del estado del proyecto. Lo que no pude encontrar todavía es para poner la cantidad de horas reales trabajadas, como para hacer un cálculo de los tiempos posterior, por lo que vi hasta ahora, permite poner una fecha y propone automaticamente la fecha del momento, como para ir trabajando en tiempo real y hacer un commit de las tareas realizadas o de las que se está trabajando.

Les dejo una imagen del dashboard.

Preview del dashboard del Pivotal Tracker

Dashboard de mi proyecto de nutrición

Se ve bastante lindo.


A empezar!

05/17/2010

Este es el primer post, para empezar a probar un poco esto.


Agile Open Rosario

05/17/2010

El pasado sábado estuve en el Agile Open acá en Rosario.

El formato del evento fue Open Space y al principio no tenía muchas expectativas ya que no sabía con que me iba a encontrar. Pero la verdad es que valió la pena invertir tiempo de mi sábado en este evento.

Conocí mucha gente interesada en el desarrollo de software, algunos ya utilizando metodologías ágiles y muchos otros como yo que fuimos a escuchar y a ver cómo y en que se puede implementar estas metodologías.

Me llevo muchas cosas interesantes de este evento y muchas cosas para investigar y que voy a estar publicando mi experiencia más adelante en este blog, probando algunas de las herramientas que me recomendaron.

Vale la pena destacar una de las sesiones que dictó Nico Paez en la que mediante un workshop mostró una técnica de estimación de tiempos bastante interesante, clasificando stories del backlog y luego asignandoles una estimación de tiempo a los grupos de stories. Prometo que la voy a probar en el proyecto de nutrición que estoy trabajando actualmente y voy a comentar mi experiencia ya que hasta ahora la estimación por puntos de función estuvo bastante lejos de ser buena y ahora estimando más o menos a ojo no nos está yendo mal, pero estaría bueno tener un método más formal para medir un poco mejor.