Hace un tiempo ya venimos con un proyecto de Nutrición y ahora que estoy con un poco más de tiempo libre le voy a dedicar a la página para darnos a conocer un poco más. Aunque en cualquier momento llega más laburo y le voy a tener que meter un corte a la web y dejarla para cuando haya más tiempo.

El dominio lo tengo registrado hace más de un año ya, así que proximamente se alojará en www.eigen.com.ar

Les dejo un printscreen para que vayan viendo. Le falta muuuucho igual.

EigenWeb en desarrollo

Ejemplo: Hover Zoom en funcionamiento

https://chrome.google.com/extensions/detail/nonjdcjchghhkdoolnlbekcfllmednbl

Ahorra bastante tiempo en Facebook sobre todo, permitiendo ver las fotos en un tamaño aceptable, sin tener que entrar en el link de la foto. Es bastante complicado de explicar, hasta que no lo usé, no entendía bien como trabajaba, así que a descargar y probar, no tarda mas de 5 segs,  así que no hay excusa.

Desgraciadamente me cansé de Facebook y decidí cerrar mi cuenta ayer, así que seguiré usando esta extensión para la wikipedia, o hasta que me arrepienta y reactive la cuenta, jaja.

http://samples.msdn.microsoft.com/ietestcenter/

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.

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

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.

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.

Dashboard de mi proyecto de nutrición

Se ve bastante lindo.

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.