Metodologías Ágiles para el Desarrollo de Software

Para logar una mejor comprensión sobre las nuevas tendencias de desarrollo de software, es preciso contar con un amplio catálogo de información; pero este tipo de material sólo se consigue en inglés. Excelente decisión de mostrarnos las nuevas técnicas de desarrollo ágil en nuestro idioma. De hecho, yo poseo un único libro que habla de esto mismo, y en español. Espero que puedan ampliar toda esta diversidad, y en espera de más información.

Espero que sigan aportando mas sobre las metodologias agiles.

Muchas gracias por estos manuales.

Excelente manual, espero que sigan avanzando con su publicación. Muchas gracias

Los felicito por su grab trabajo y su empeño... yo me pregunto ¿es posible q una sola persona ejecute un proyecto usando una metodologia agil? Hago esta pregunta porque a mi me tocara hacerlo el año q viene. Algunos consejos??

Hola Gustavo! Excelente pregunta la que haces ya que muchos programadores tienen la misma duda.

En principio, las metodologías de gestión de proyectos, están basadas en EQUIPOS. No obstante, muchas de sus pautas organizativas así como prácticas técnicas propuestas por metodologías como eXtreme Programming (de las que hablaremos en próximos capítulos), pueden ser implementadas por un desarrollador independiente.

Por ejemplo, la participación constante y permanente del cliente propia del agilismo; la organización por Sprints de Scrum; y prácticas técnicas como el TDD de eXtreme Programming.

Lógicamente te encontrarás con varias desventajas:

- Difícilmente un solo programador pueda entregar software 100% funcional en un sprint de 2 semanas. Así que tal vez, puedas proponer Sprints de 4 semanas (no más de eso y no menos de 3 semanas)

- Si te encargas de otros aspectos externos a la programación (ejemplo: diseño de interfaces, documentación, etc.) te será imposible solapar estas etapas del desarrollo (esto también repercutirá en el tiempo que te demore un Sprint). Para estos casos, siempre sugiero priorizar etapas. Por ejemplo, si tu fuerte es la programación, pues procura que en los primeros Sprints, la parte inherente a la programación sea la prioridad. Puedes proveer un diseño que permita transformar la información de manera humanamente legible, pero puedes postergar el diseño completo de las GUI para un Sprint exclusivo.

- No tendrás quien se encargue de solucionar impedimentos que surjan, así que esto, dependerá de tu propia habilidad para negociar. Lo mejor que puedes hacer, es dejar en claro a tu cliente que solo debe haber UNA persona autorizada a sugerir cambios o mejoras. Y para esto, nada mejor que utilizar las reuniones de revisión de Scrum. De esa forma, trabajarás tranquilo durante todo el Sprint, y los cambios que surjan (de funcionalidad, requerimientos o mejoras), podrán hacerse en la revisión, y planificarse para otro Sprint (según considere el cliente)

Los felicito por tan excelente trabajo, estoy visitando continuamente desarrolloweb y como estoy leyendo los manuales, empezare con este. Si es posible que publiquen algunos libros que refuercen el tema.

Saludos. Nos vemos dentro de los articulos ;)