Escrito por Martin Fowler
Traducido por Jesús Pérez
Revisado por Carmen Vidal

De vez en cuando la gente se pregunta si una especialidad particular puede ser usada de forma incremental: " No se puede hacer (seguridad | diseño de interfaz de usuario| bases de datos | internacionalización | *) con un proyecto ágil porque este aspecto tiene que ser desarrollado realizando un gran diseño inicial".

Cuando se me hace una pregunta como esta, me encuentro perdido porque desconozco esa especialidad. El diseño de aplicaciones es algo de lo que pienso que puedo hablar, pero no sobre diseño seguridad - y mi interrogador bien puede ser un reconocido experto en este campo.

A pesar de mis limitaciones reconocidas en el campo del que se habla, no voy a decir que sólo se puede usar diseño planificado en ese área. Lo que puedo decir es que realmente no sabemos si se puede hacer el diseño incremental en aquella área. He visto bastantes casos en los que la gente ha dicho " no se puede usar el diseño incremental para x " sólo para averiguar que se puede. El diseño de aplicación es de una forma, el diseño de bases de datos es de otra. De esto modo, hasta que la gente pruebe el diseño incremental de un modo serio, no estoy dispuesto a excluirlo.

Parte de la dificultad de evaluar esta pregunta está en que es demasiado fácil hacer el diseño incremental mal. Si se hace el diseño incremental de un forma incontrolada, con alta probabilidad se termina con un lío de diseño - para hacer el trabajo de diseño incremental se necesita algo que haga el diseño convergir al orden. En el articulo "Está el Diseño Muerto" me referí a éstas como prácticas de habilitación. Para el diseño de software, las pruebas, integración continua y refactorizar son las prácticas clave que permiten que el diseño del software converja y evitar la entropía del software. Cuando hablamos de algo más, como el diseño de UI, la cuestión encontrar cuáles son las prácticas de habilitación. Pueden ser similares o inspiradas por las del diseño de software, o pueden ser diferentes. En el diseño de base de datos, por ejemplo, la migración de datos incremental es una práctica de habilitación clave. Hasta que se encuentre un buen conjunto de prácticas de habilitación, el diseño incremental es algo frágil.

Traducido por Carmen Vidal Gil (Agile-Spain).

No se pueden meter diez libras de mierda en una bolsa de cinco libras
     --Alguien que lo ha intentado

  Cuando Kent y yo escribimos “Planning Extremme Programming”, incluimos esta cita para ayudar a obtener la esencia de lo que trata la planificación. Uno de los grandes problemas con el desarrollo de software es que la gente no sabe lo que se puede hacer realmente en un tiempo finito. Con demasiada frecuencia vemos mucha funcionalidad aparcada en una bolsa sin comprender dónde encajará. Uno de las cosas que me gustó mucho acerca de la estrategia de planificación de Kent fue un mecanismo sencillo de tratar esto.

  El principio es realmente muy sencillo. Divide el tiempo de proyecto en iteraciones. Divide el problema solicitado en funcionalidades (o “historias”, como se llaman en XP). Estima cuánto trabajo se necesita para cada funcionalidad. Estima cuánto trabajo se completa en cada iteración, y no ponga más funcionalidades en cada iteración de las que quepan. La planificación de la siguiente versión en XP trata de decidir qué funcionalidades van en cada iteración.

En todo proyecto de desarrollo ocurre una o más veces: se compromete la finalización de un conjunto de funcionalidades o entregables para una determinada fecha pero no es posible cumplir con el compromiso. ¿Qué puede hacerse en ese caso? En un reciente y breve artículo Ron Jeffries explica el punto de vista de Extreme Programming al respecto. La solución según él consiste en Maximizar cada iteración

En un artículo algo más extenso de unos días antes Jeffries nos explica con más detalle cómo conseguir cumplir las fechas.

Microsoft ha publicado un kit de gestión de proyectos Scrum para sus herramienta Microsoft Office Project Professional 2003 y Project Standard 2003.
El kit incluye una plantilla de Project para gestionar el backlog de producto y el de iteración, así como el código fuente para generar un componente COM que permite exportar los datos del proyecto a Excel pudiendo generar así gráficos burn-down y diagramas de flujo acumulado.

En el número de otoño de la revista electrónica gratuita "Methods & Tools" se recoge un artículo de Rachel Davies titulado "Agile Requirements" sobre gestión de requisitos en proyectos gestionados mediante metodologías ágiles.
En el artículo se pone el ejemplo de la metodología Extreme Programming y el uso de historias para gestionar los requisitos.

La propia autora cita tanto en el artículo como en su blog el artículo "Essential XP: Card, Conversation, Confirmation" de Ron Jeffries para explicar las tres partes en las que se divide una historia en Extreme Programming.