agile-spain.com - Requisitos y planificación

Planning Pocker

Fri, 27 Jul 2007 09:01:36 +0000

A la hora de hacer una estimación, se debe tener en cuenta lo siguiente:

1. Las estimaciones son estimaciones, es decir, aunque le dediques mucho tiempo, no llegaremos a una precisión del 100%
2. Las estimaciones se deciden colaborativamente, incluyendo a quienes harán la tarea ( esto último es muy importante)
3. Se deben realizar como la combinación de:
- Opinión del experto
- Analogía: comparar con otras tareas ya estimadas
- Disgregación: separar una tarea en varias

Dentro de las metodologías ágiles, una de las propuestas para estimar es jugar al Planning Pocker, que combinas las técnicas anteriores.

Reglas y errores típicos en la gestión de requisitos

Sat, 18 Feb 2006 18:59:33 +0000

Brad Appleton ha juntado y expandido dos de sus recientes entradas en su blog para escribir el artículo The Unchangeable Rules of Software Change donde describe con gran claridad su visión de cómo es y cómo debería ser la gestión de requisitos.

Este artículo se basa en su experiencia práctica de consultor en varios equipos donde ha visto cómo unos no tenían metodología ninguna, otros intentaban definir todo a priori guiados por metodologías pesadas y otros no hacían análisis de requisitos ninguno pensando que así aplicaban un método ágil. O lo que es peor, el mismo equipo iba dando tumbos de un extremo a otro.

En resumen, los errores típicos que Brad destaca entre tumbo y tumbo son:

No disponer de ningún mecanismo de control de cambio
Evitar cambios de alcance durante el proyecto
Parálisis del proyecto debido a un excesivo tiempo recogiendo requisitos
No hacer captura de requisitos de ningún tipo
No realizar planificación de las iteraciones (tras pasarse a un método supuestamente ágil)
Demasiada planificación de las iteraciones

Para curarse estos errores Brad plantea sus cuatro reglas básicas de la gestión de requisitos, pero os dejo que lo leais en el propio artículo.

¿Qué tienen de malo los diagramas de Gantt?

Mon, 13 Feb 2006 14:55:51 +0000

En una entrada en su blog titulada Why GANTT Charts Were Banned in the First Scrum, Jeff Sutherland nos explica su opinión sobre los diagramas de Gantt. En ella defiende porqué los dejó fuera de SCRUM, aunque reconoce que pueden ser útiles para mostrarlos a gente externa (pero sólo en esos casos).

Ventajas e inconvenientes de iteraciones cortas

Thu, 26 Jan 2006 20:28:05 +0000

Hoy he leído dos entradas de blogs que me han parecido muy esclarecedoras en relación a preguntas que me han venido a la cabeza más de una vez ¿cómo de largas deben ser las iteraciones de un proyecto? ¿qué ventajas tiene hacerlas más largas o más cortas?

El primero de ellos es The Pros and Cons of Short Iterations de Mishkin Berteig y el segundo Planning with the Horizon of Predictability leído en el blog Agile in Action.

La idea sobre la que construyen es la del horizonte de predictabilidad, es decir cuanto tiempo que puedes predecir en el proyecto antes de que surjan interrupciones, cambios en requisitos, cambios de prioridades, etc. Este horizonte es diferente en cada proyecto y quizá incluso en cada momento y el tamaño de las iteraciones debe adaptarse correspondientemente para que funcionen correctamente.

ExtendiendoElIncrementalismo

Thu, 08 Dec 2005 14:56:57 +0000

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.

BolsaDeCincoLibras

Fri, 11 Nov 2005 20:34:32 +0000

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.

¿Qué hacemos si no vamos a cumplir la planificación?

Wed, 02 Nov 2005 08:26:15 +0000

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.

Kit de Scrum para MS Project 2003

Mon, 24 Oct 2005 13:49:19 +0000

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.

Gestión de requisitos ágil

Mon, 24 Oct 2005 13:50:58 +0000

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.