Criterio de demarcación de una Story
¿Qué es una Story y qué no? ¿Cuál es el criterio de demarcación?
¿Qué es una Story?
Según
el concepto general de metodología Ágil, la Story se define como una
"promesa de una conversación " o una "descripción de una
característica" [UNTREF 2014] [Dan North 2015]. Según esta perspectiva, representa una "funcionalidad de aplicación" para un usuario y que brinda un beneficio (ROL + FUNCIONALIDAD + BENEFICIO):
COMO <ROL> QUIERO <FUNCIONALIDAD> PARA QUE <BENEFICIO>
No es exactamemte un requerimiento pero puede considerarse como el título de un requerimiento como recordatorio de algo relevante a conversar con el usuario (o cliente). En consecuencia lo relevante es su evolución como conversación [UNTREF 2014].
La Story describe lo que el usuario quiere hacer desde la perspectiva de una interacción con un proceso de negocio, describe el objetivo del usuario en términos de necesidad de obtener algo que se hace en el negocio [Bellware Scott 2014].
Según Dan North y en el marco de Behavior-Driven Development (BDD), una Story es más un requerimiento, pues tiene que ser una descripción de un requisito y su beneficio para el negocio, y un conjunto de criterios con los que todos estamos de acuerdo de qué es o lo que se hace, "lo que el cliente necesita" [Dan North 2015].
Para Scrum existen items de Backlog de producto PBI que se los suele denominar como Story. El Product Backlog incluye incisos o Stories que aportan valor al cliente y que suelen ser descripción de requisitos funcionales. Aunque también puede incluir entradas para exploración de características, necesidades del cliente u opciones técnicas, requerimientos no funcionales, el trabajo necesario para lanzar el producto, y otros incisos, así como la configuración del entorno o arreglar defectos [Scrum-Institute , 2015]. O sea que puede proporcionar valor en forma indirecta mediante el aumento de la calidad o la reducción de los incidentes en el largo plazo [Scrum-Institute , 2015].
El criterio de demarcación aceptado en metodología ágil en general es el criterio INVEST que consta de seis características a cumplir:
1- Independiente: debe ser atómica.
2- Negociable: debe ser conversable y en consecuencia negociable (es viva).
3- Valueble: debe generar un valor al usuario o cliente. Una Story sin una declaración de la motivación del usuario a menudo se piensa que es no accionable; es decir, la historia no se puede estimar o implementar fácilmente [Bellware Scott 2014].
4- Estimable: se debe poder estimar.
5- Pequeña: debe ser lo suficientemente pequeña para entrar en un sprint o iteración.
6- Probable: debe poder ser testeable.
[UNTREF 2014][Agile Alliance 2015] (Bill Wake's)
COMO <ROL> QUIERO <FUNCIONALIDAD> PARA QUE <BENEFICIO>
No es exactamemte un requerimiento pero puede considerarse como el título de un requerimiento como recordatorio de algo relevante a conversar con el usuario (o cliente). En consecuencia lo relevante es su evolución como conversación [UNTREF 2014].
La Story describe lo que el usuario quiere hacer desde la perspectiva de una interacción con un proceso de negocio, describe el objetivo del usuario en términos de necesidad de obtener algo que se hace en el negocio [Bellware Scott 2014].
Según Dan North y en el marco de Behavior-Driven Development (BDD), una Story es más un requerimiento, pues tiene que ser una descripción de un requisito y su beneficio para el negocio, y un conjunto de criterios con los que todos estamos de acuerdo de qué es o lo que se hace, "lo que el cliente necesita" [Dan North 2015].
Story para Scrum
Para Scrum existen items de Backlog de producto PBI que se los suele denominar como Story. El Product Backlog incluye incisos o Stories que aportan valor al cliente y que suelen ser descripción de requisitos funcionales. Aunque también puede incluir entradas para exploración de características, necesidades del cliente u opciones técnicas, requerimientos no funcionales, el trabajo necesario para lanzar el producto, y otros incisos, así como la configuración del entorno o arreglar defectos [Scrum-Institute , 2015]. O sea que puede proporcionar valor en forma indirecta mediante el aumento de la calidad o la reducción de los incidentes en el largo plazo [Scrum-Institute , 2015].
¿Cuál es el criterio de demarcación?
El criterio de demarcación aceptado en metodología ágil en general es el criterio INVEST que consta de seis características a cumplir:
1- Independiente: debe ser atómica.
2- Negociable: debe ser conversable y en consecuencia negociable (es viva).
3- Valueble: debe generar un valor al usuario o cliente. Una Story sin una declaración de la motivación del usuario a menudo se piensa que es no accionable; es decir, la historia no se puede estimar o implementar fácilmente [Bellware Scott 2014].
4- Estimable: se debe poder estimar.
5- Pequeña: debe ser lo suficientemente pequeña para entrar en un sprint o iteración.
6- Probable: debe poder ser testeable.
[UNTREF 2014][Agile Alliance 2015] (Bill Wake's)
¿Qué NO es una Story?
Si no cumple con el criterio INVEST es bastante probable que no sea una Story. Por ejemplo una tarea puramente técnica (que le interesa solo al desarrollador), un refactoring técnico o un Spike no cumplen con INVEST y en su generalidad no son Story. Veamos:
No es una Story ya que es una tarea de investigación y/o experimentación en formato time-boxing por lo que no cumple con ser testeable ni estimable (no cumple con dos criterios).
Es una tarea técnica que no es valuable o su valoración es a futuro o en relación a un atributo de calidad que puede no estar directamente solicitado por el cliente o no impacta en beneficio inmediato para el cliente, ya que podría estar resolviendo una deuda técnica. Esto no quiere decir que no pueda haber una "story de refactoring" que puede proporcionar valor en forma indirecta mediante el "aumento de la calidad o la reducción de los incidentes en el largo plazo".
“Cada historia tiene que ser valorado por los usuarios. Pero eso sería un error." [Mike Cohn 2004] Pues en realidad, una historia de usuario describe la funcionalidad que será valiosa para un usuario o comprador de un sistema o software [Mike Cohn 2004]. Hay historias que especifican aspectos técnicos que no son valiosos para el usuario sino mas bien para el cliente o comprador (la valoración es transitiva y no directa). Historias técnicas pueden ser valorados por los compradores que contemplan la compra del producto, pero no serían valorados por los usuarios reales. Pero esto no es lo que podemos llamar una "Technical Story" sino que es una Story con aspectos técnicos que tiene valor para el cliente. Para Scott Ambler en Agile Modeling, una Story es una definición de muy alto nivel de un requerimiento que puede ser funcional o no, por ejemplo de un requerimiento técnico [Scott Ambler 2015], por ejemplo: "como usuario quiero que las transcripciones estén disponibles en línea a través de un navegador estándar lo que me permite acceder desde cualquier lugar" [Scott Ambler 2015].
Cuando se habla de "Technical Story" se referencia a aquella historia técnica que sólo es valorada por los desarrolladores. Estas historias son las que se quieren evitar y considerar como Technical Story que podría ser una tarea técnica o una historia mejor redactada. Este tipo de historias se centran en la tecnología y las ventajas para los programadores. Es muy posible que las ideas detrás de estas historias sean buenas, pero en cambio deben ser escritas para que los beneficios a los clientes o usuarios sean evidentes. Esto permitirá que el cliente priorizar inteligentemente estas historias en el calendario de desarrollo [Mike Cohn 2004].
Para la Agile Alliance una Story no se corresponden en general a un "componente técnico" o de la "interfaz de usuario", pues a pesar de que a veces puede ser un atajo útil hablar de por ejemplo "la historia de diálogo de búsqueda", pantallas, cuadros de diálogo y botones, no son historias de usuario [Agile Alliance 2015].
Spike:
No es una Story ya que es una tarea de investigación y/o experimentación en formato time-boxing por lo que no cumple con ser testeable ni estimable (no cumple con dos criterios).
Refactoring Task:
Es una tarea técnica que no es valuable o su valoración es a futuro o en relación a un atributo de calidad que puede no estar directamente solicitado por el cliente o no impacta en beneficio inmediato para el cliente, ya que podría estar resolviendo una deuda técnica. Esto no quiere decir que no pueda haber una "story de refactoring" que puede proporcionar valor en forma indirecta mediante el "aumento de la calidad o la reducción de los incidentes en el largo plazo".
Technical Story:
“Cada historia tiene que ser valorado por los usuarios. Pero eso sería un error." [Mike Cohn 2004] Pues en realidad, una historia de usuario describe la funcionalidad que será valiosa para un usuario o comprador de un sistema o software [Mike Cohn 2004]. Hay historias que especifican aspectos técnicos que no son valiosos para el usuario sino mas bien para el cliente o comprador (la valoración es transitiva y no directa). Historias técnicas pueden ser valorados por los compradores que contemplan la compra del producto, pero no serían valorados por los usuarios reales. Pero esto no es lo que podemos llamar una "Technical Story" sino que es una Story con aspectos técnicos que tiene valor para el cliente. Para Scott Ambler en Agile Modeling, una Story es una definición de muy alto nivel de un requerimiento que puede ser funcional o no, por ejemplo de un requerimiento técnico [Scott Ambler 2015], por ejemplo: "como usuario quiero que las transcripciones estén disponibles en línea a través de un navegador estándar lo que me permite acceder desde cualquier lugar" [Scott Ambler 2015].
Cuando se habla de "Technical Story" se referencia a aquella historia técnica que sólo es valorada por los desarrolladores. Estas historias son las que se quieren evitar y considerar como Technical Story que podría ser una tarea técnica o una historia mejor redactada. Este tipo de historias se centran en la tecnología y las ventajas para los programadores. Es muy posible que las ideas detrás de estas historias sean buenas, pero en cambio deben ser escritas para que los beneficios a los clientes o usuarios sean evidentes. Esto permitirá que el cliente priorizar inteligentemente estas historias en el calendario de desarrollo [Mike Cohn 2004].
Para la Agile Alliance una Story no se corresponden en general a un "componente técnico" o de la "interfaz de usuario", pues a pesar de que a veces puede ser un atajo útil hablar de por ejemplo "la historia de diálogo de búsqueda", pantallas, cuadros de diálogo y botones, no son historias de usuario [Agile Alliance 2015].
Referencias:
[Mike Cohn 2004]
User Stories Applied For Agile Software Development. Mike Cohn, 2004.
[Dan North 2015]
WHAT’S IN A STORY? Dan North, 2015.
[UNTREF 2014]
Construcción de software: una mirada ágil. Nicolás Paez, Diego Fontdevila, Pablo Suárez, Carlos Fontela, Marcio Degiovannini, Alejandro Molina. Universidad Nacional de Tres de Febrero (UNTREF), 2014.
BehaviorDriven Development. By Bellware Scott. Code Magazine, by EPS Software Corp. 1993 2014. All rights reserved. (www.codemag.com/article/0805061)
[Scott Ambler 2015]
User Stories: An Agile Introduction. Scott Ambler and Associates, Agile Modeling, 2015. URL: http://www.agilemodeling.com/artifacts/userStory.htm
[Agile Alliance 2015]
Agile Alliance, User Stories. URL: http://guide.agilealliance.org/guide/user-stories.html
[Scrum-Institute
, 2015]
Scrum
revealed: the only book can simply learn scrum! International Scrum
Institute (scrum-institute.org) o ISI.
No hay comentarios:
Publicar un comentario