Toma de requisitos e historias de usuario

Tomás Casquero Sierra

unread,

Mar 3, 2011, 4:39:45 AM3/3/11

to agile...@googlegroups.com

Hola

Juan Carlos, sin animo de polemizar Agustin dice:

"Tendrá que definir historias de usuario (que representan los
requisitos, ya sean funcionales o no funcionales)"

Creo que deja claro que habla de historias de usuario y no vanaliza sobre Agile.

2011/3/3 Juan Carlos Quijano Abad <juancarl...@gmail.com>

Juan Carlos Quijano Abad

unread,

Mar 3, 2011, 5:30:37 AM3/3/11

to agile...@googlegroups.com

Buenas,

Ups, perdon. Creo que he sido demasiado tajante. No quería molestar a nadie. Y menos a Agustín, que tiene todo mi respeto. Y al que doy como ejemplo del cambio positivo en la docencia universitaria.

Me refería esencialmente a:

"(huele mucho a metodología convencional donde historia de usuario = caso de uso y esto NO ES ÁGIL)"

A mi parecer, la aseveración no se fundamenta en el manifiesto agile, ya que el no describe las prácticas técnicas o de gestión. Señala prioridades y no descarta el uso de casos de uso o de tomas de requisitos, mientras no sean un impedimento para la creación de valor.

Una vez más, disculpame Agustín, si he sido brusco o molesto. No era mi intención.

--

Un saludo

Juan Quijano

Signature powered by WiseStamp

Dougals Orlando Castro Barreto

unread,

Mar 3, 2011, 9:57:56 AM3/3/11

to agile...@googlegroups.com, Juan Carlos Quijano Abad

Muy bien, requisitos o historias; requerimientos o "El problema", el motivo que nos hará trabajar.

Hablamos de semántica y afortunadamente comprendemos aunque nos separa en algunos casos el océano y la cultura entre otras cosa.

Excelente.

Dougals Castro
سلام عليكم
+5804166188295
Telf.Trab. 0212.274-47-84
Caracas - Venezuela
dougals...@hotmail.com
dca...@seniat.gob.ve

Chat

Google Talk: dougals.castro

MSN: dougals.castro

Contact Me

--- @ WiseStamp Signature. Get it now

Contactame

Chat

dougals.castro

Javier Gómez

unread,

Mar 3, 2011, 11:31:56 AM3/3/11

to agile...@googlegroups.com

A este respecto, acabo de volver de una reunión donde, después de explicar un poco como funcionan los métodos ágiles, me han preguntado si al finalizar un proyecto de este tipo se podría realizar una iteración que como único objetivo tuviera crear los documentos funcional y técnico tradicionales correspondientes, incluso los relacionados con CMMI.

Por lo visto, les surge esta necesidad debido a que puede llegar el caso en que revendan el producto y su cliente final se la exija. ¿Que opináis? ¿que documentación creeis que habría que generar y cuando?.

Saludos

Juan Carlos Quijano Abad

unread,

Mar 3, 2011, 12:13:25 PM3/3/11

to agile...@googlegroups.com

Buenas,

Si necesitas la documentación CMMI, yo te recomendaría entonces llevar las tareas de documentación como indica el ciclo CMMI. Aunque sea una tarea reiterativa en los diferentes sprint.

Lo que pasa es que hay documentación CMMI que solo tiene sentido al inicio del proyecto como el Anális del esquema de datos, o la mayoría del Analisis funcional o el Análisis de arquitectura de sistemas o los riesgos.

También puedes, eso lo he tenido que hacer alguna vez, llevar los tiempos y documentación de CMMI pero abordar la fase de desarrollo con una métodología Agile.

La idea del sprint final para documentar es una buena solución pero la documentación no tendrá el sentido, ni el objetico para lo que se hace. Si no, tal y como dices, sería para cumplir un requisito del cliente.

--

Un saludo

Juan Quijano

Signature powered by WiseStamp

Dougals Orlando Castro Barreto

unread,

Mar 3, 2011, 12:36:05 PM3/3/11

to agile...@googlegroups.com, Juan Carlos Quijano Abad

Podría aplicarse ReIngenieria ? para tener todo el diseño util para futuras modificaciones o nuevas implementaciones al sistema.

Manuales de Usuario ? DAS ?

Dougals Castro
سلام عليكم
+5804166188295
Telf.Trab. 0212.274-47-84
Caracas - Venezuela
dougals...@hotmail.com
dca...@seniat.gob.ve

Chat

Google Talk: dougals.castro

MSN: dougals.castro

Contact Me

--- @ WiseStamp Signature. Get it now

Contactame

Chat

dougals.castro

Alfredo Casado

unread,

Mar 3, 2011, 3:19:56 PM3/3/11

to agile...@googlegroups.com

Por lo visto, les surge esta necesidad debido a que puede llegar el caso en que revendan el producto y su cliente final se la exija. ¿Que opináis? ¿que documentación creeis que habría que generar y cuando?.

Como dicen en Lean, decidamos en el ultimo momento responsable, si "puede llegar el caso" es de esperar que también "puede no llegar el caso" por tanto si no llega el caso y dedicamos X tiempo a generar esa documentación habrá sido tiempo perdido que podríamos haber dedicado a añadir más valor al producto. En general cualquier cosa que se haga "por si acaso" es la misma definición de YAGNI.

Y si al final "llega el caso" y le vendes el producto a un cliente que exige cierta documentación, según yo lo veo tienes dos opciones:

- Explicarle que con los métodos ágiles que has usado has generado algo mucho mejor que toda esa pila de documentos técnicos, tienes especificaciones ejecutables y un código de calidad que es la mejor documentación de tu sistema. No olvidemos que la documentación sirve para poder evolucionar un sistema, explicale a tu cliente que tu producto, gracias a que a que has usado técnicas agiles, es mucho más facil de evolucionar que un proyecto clásico con código spaghetti y una pila de documentos, generalmente, inservibles.

- A pesar de tus esfuerzos el cliente quiere sus documentos y tu sigues queriendo vender tu producto a ese cliente (que habría que pensarselo dos veces...), pues entonces y sólo entonces le haces los documentos que te pida.

Patricio Letelier

unread,

Mar 3, 2011, 4:42:22 PM3/3/11

to agile...@googlegroups.com

Hola,

Me gustaría dar mi opinión con respecto de algunos conceptos mencionados en esta discusión:

1. Las Historias de Usuario (HU) y los Casos de Uso (CU) son ambos artefactos para especificar requisitos. Ciertamente puede encontrarse un punto en el cual una especificación hecha mediante un CU podría ser equivalente a otra hecha como HU, es una cuestión de granuralidad (tamaño), los CU (en el contexto metodológico "usual" que se les asume) no tienen la presión por ser un trabajo acotado a alrededor de una semana de trabajo (tamaño orientativo para una HU) y normalmente se refieren sólo a requisitos funcionales. Así, en cuanto a tamaño, un CU equivaldría a un conjunto de HU, o a esas llamadas HU épicas, aquellas que deben particionarse en HU "normales".

2. Estoy "muy" de acuerdo con que la agilidad no está reñida (necesariamente) con los artefactos que utilices para desarollar software, llevando como premisa el minimalismo respecto de todas las especificaciones adicionales al código en sí mismo, y exigiendo "rentabilidad" a cualquier esfuerzo invertido en dichas especificaciones. Si sólo se trata de cumplir con una cláusula de documentación en el acuerdo con el cliente, podríamos en extremo esperar a que el producto esté listo para su entrega y en ese momento hacer "reingeniería" para generar unas especificaciones. Sin embargo, entre ese extremo y el contrario (invertir mucho esfuerzo desde el comienzo del proyecto en generación y actualizacion de especificaciones), siempre puede buscarse un punto de equilibrio y sensatez.

3. CMMI es un estandar de referencia para la evaluación y mejora de procesos de desarrollo de software, NO es una metodología, no establece los elementos básicos: roles, artefactos ni actividades específicas (sólo de carácter general), tampoco establece herramientas (ni plantillas :-) ). Por otra parte, aunque sí que pueden considerarse metodologías, ni Scrum ni XP son muy precisas respecto a dichos elementos, pero esto no incomoda demasiado debido al minimalismo antes mencionado. Al referirse a documentación de metodologías de carácter tradicional o no ágil, podría usarse como referencia lo establecido por las metodologías RUP o Métrica (pero no CMMI).

Un saludo,

Patricio Letelier

www.tuneupprocess.com

Patricio Letelier

www.tuneupprocess.com

Harald Messemer

unread,

Mar 3, 2011, 7:22:21 PM3/3/11

to agile...@googlegroups.com

Me parece que lo he mencionado en algún momento: International Requirements Engineering Board (IREB, http://www.certified-re.de/en/mission.html). Ya vemos que hay diferentes maneras de llegar a la meta, pero creo que hay algo en común que consiste en poner el usuario y sus requerimientos en el centro de atención en un proyecto.

Un saludo,
Harald

2011/3/3 Patricio Letelier <lete...@dsic.upv.es>

Juan Carlos Quijano Abad

unread,

Mar 4, 2011, 3:54:42 AM3/4/11

to agile...@googlegroups.com

Buenas,

Patricio, tienes toda la razón. Cuando hablo de CMMI es una simplificación absurda y erronea. Tal y como dices CMMI es un guía de madurez, no una métodología. Si acaso lo hago para simplificar CMMI = Métodología "Pesada".

Es como cuando hablamos de Kanban como métodología cuando en realidad es meramente una herramienta visual.

Muchas gracias por la puntualización.

--

Un saludo

Juan Quijano