Kent Beck, el padre de Extreme Programming y de varias herramientas de xUnit, nos cuenta sobre las tendencias en el mundo del software y la sinergía entre el negocio y el desarrollo ágil. La razón por la cual Ágil es cada vez más popular es porque responde a las necesidades del negocio a medida que evoluciona.
En la era en donde nos estamos enfocando a Web 2.0 (palabra que muchos hablan y no tantos comprenden), está cambiando radicalmente la forma en la que se crean sistemas. Actualmente, estamos viendo que los equipos tienden a entregar software como servicios, no como productos. Esta realidad lleva a cambios fundamentales en los modelos de negocio de las organizaciones.
Con el advenimiento de lo ágil como moda desde hace unos años, y sabiendo que casi ninguno de nosotros querría trabajar en Jurassic Park, todos los que de alguna u otra manera estamos al tanto de lo que pasa afuera de nuestro trabajo, en eso que muchos llaman ‘mundo’ y otros ‘internet’, podemos decir que a nosotros los desarrolladores nos dan muchas ganas de saber y entender que es esto de ágil, que es Scrum, XP, TDD, PP y como puede beneficiar nuestro trabajo diario este conjunto de siglas, sobre todo si de quitar burocracia se trata, que es una de los temas que mas nos molesta a nosotros.
La Programación en pareja es una de las prácticas más debatidas de Extreme Programming. Históricamente, la programación solía ser una actividad solitaria que requería de una alta concentración e incluso aislamiento total. Los mejores programadores saben como alcanzar un estado mental conocido como Fluir o Zona, en el cual la mente es capaz de enfocarse en el código y tomar decisiones sumamente creativas y eficientes.
Las metodologías ágiles no ofrecen un nuevo enfoque nuevo para la gestión de riesgos de un proyecto, ni brindan brindan nada nuevo sobre el tema. ¿Sorprendido? Según el PMBOK, la creación de un plan de mitigiación de riesgos incluye identificar los riegos, realizar un análisis cualitativo y cuantitativo, planificar la respuesta al riesgo, monitorear y controlar los riesgos. Y todo esto lo hacemos en Ágil.
Si ya fuiste programador por algún tiempo, probablemente ya tuviste que codificar más lentamente debido al código feo y mal hecho. El grado de lentitud varía y a menudo es significativo. Los equipos que se mueven rápidamente en el inicio del proyecto se pueden encontrar marchando a pasos de tortuga algunos meses más tarde. Es aquella situación en la que cualquier cambio, por mas trivial que sea, rompe otras partes del código y se hace con miedo de los efectos que genera.
Acabo de terminar de leer el recién publicado libro The Art of Lean Software Development: A Practical and Incremental Approach de Curt Hibbs, Steve Jewett, Mike Sullivan. En el capítulo 2, los autores hacen la gran pregunta: si está claro (a través de diversos estudios y casos reales) que el desarrollo tradicional y cascada frecuentemente falla y que el desarrollo Ágil y Lean aumenta las posibilidades de éxito, ¿qué es lo que les impide a las personas y organizaciones hacer el cambio?
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):
¿Por qué es divertido programar? ¿Qué recompensa esperan obtener quienes programan? Frederick Brooks, autor del clásico The mythical man-month, reflexiona sobre el arte de la programación, las cosas positivas que generan la pasión por esta actividad, y también los contratiempos y problemas inherentes que surgen casi de forma inevitable.
Todas las metodologías ágiles hablan del "desarrollo iterativo" de software. Sin embargo, muchas veces se lo confunde con un desarrollo por incrementos, que es algo bien distinto.
En su charla Embrace Uncertainty (video en inglés), Jeff Patton nos explica con un ejemplo claro la diferencia entre estos dos enfoques.
Veamos a continuación la diferencia fundamental entre el desarrollo de software incremental y el iterativo.
Cuando realmente nos importa lo que hacemos, entonces también nos importa hacerlo mejor. Esto involucra reflexionar sobre cómo hacen las cosas, y probar nuevas técnicas para ver si nos permiten mejorar. Aunque otras personas nos recomienden técnicas, la única forma de saber si funcionan con uno es probarlas y ver si mejoran nuestro rendimiento.
Nuevo logo, nuevo buscador, nueva portada, podcast mensual... ¡y muchas novedades más!
"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