Historias técnicas ¿Donde?


(Claudio Mardones) #1

Estimados,

Antes que todo felicitarlos por la comunidad.

Me encuentro creando un pequeño proyecto, aplicando los principios agile utilizando como herramienta Jira Agile.
Tengo bien definida mis historias de usuario (lo que el cliente desea y le aporta valor), pero tengo además una pila de tareas técticas que desarrollar dentro del equipo, por ejemplo levantar ambientes de integración continua, definición de la arquitectura de software, entre otras.

No he encontrado referencias claras de como incluir dichas tareas tecnicas, si es conveniente agregarlas como historias de usuario u de otra forma.

Cualquier ayuda se agradecerá. :slight_smile:


(Mario Lucero) #2

Claudio

Las historias no son solo Funcionales o de Negocio también existen las historias técnicas las cuales el equipo que es el que mas sabe de eso tiene que en el Sprint Planning colocarlas y ver como pueden ser incluidos dentro del Sprint o los subsiguientes dependiendo del resto de Historias a realizar.
Es una negociación con el PO para ver cuantas Historias Técnicas incluir.

Saludos

Mario


(David Lay) #3

Yo quiero complementar y al mismo tiempo dar una alternativa

Generalmente se hace una iteración 0 en donde se levantan los requerimientos técnicos de ambiente y se hacen los kickoff correspondientes. En esta iteración siempre trato de finalizar la mayoría de las historias técnicas que aparezcan.

Para el cliente e incluso para el PO es complicado entender el valor de una historia técnica, especialmente contrarestándolo con el gran valor que ofrecen las historias funcionales. Para esto hay que ofrecer especial detalle en explicar el “porque” y cual es el valor dentro de la historia. También es importante desarrollar las pruebas de aceptación para estas historias

La alternativa, es que he encontrado que varios de estos requerimientos se pueden colocar como parte de las pruebas de aceptación para historias iniciales, especialmente cuando son pequeños o más enfocados en una feature en particular. Por ejemplo, para hacer un ambiente de pruebas para un login de integración con active directory, se puede poner como prueba de aceptación del login:

  • “se ha podido reproducir en un ambiente local que la integración es correcta”

o algo de ese estilo.

El objetivo no es ocultar estas tareas al cliente/PO sino efectivamente que se entienda cual es el contexto y el impacto de estas tareas técnicas dentro de las funcionalidades.


(Silvana Ortega Sierra) #4

Hola Claudio,

Esos son los denominados ‘Requerimientos No Funcionales’ y son igual de
importantes que los requerimientos funcionales, por lo tanto también es
necesario creales su propia historia de usuario (llamadas Historia Técnica
en este caso), porque son cosas que aportan al desarrollo del proyecto y
como dice Mario, con el PO pueden definir su inclusión y el spring de
trabajo de las mismas.

Saludos,

Sincerely,


(Jose Manuel Caracci) #5

Tengo entendido que las “historias” se crearon con la intención de que existiera una conversación entre alguien que quiere algo y el equipo que lo desarrolla.

Nada más… es solo una tarjeta con una promesa de que ocurrirá esa conversación. (lejos de ser un requerimiento o un elemento trabajable o a desarrollar)

Desde mi punto de vista lo mejor y más simple es meter todo en el saco del backlog y ni siquiera ponerle nombre (o si quieres llámalos items del backlog)

Saludos!

José Manuel


(Carlos Peix) #6

En mi opinión, las historias de usuario deben contener un incremento funcional desde el punto de vista del usuario, no técnico.

En Scrum en particular, las historias de usuario no son el único elemento del backlog, podría haber otros, de ahí que la comunidad prefiere utilizar el nombre de “backlog item”.

En cualquier caso, creo que es peligroso para todos utilizar el recurso de las “historias técnicas”, es una salida fácil a la necesidad de slicing y de fragmentación de las unidades de trabajo.

Otro riesgo, alto en mi opnión, tiene que ver con el concepto YAGNI (no vas a necesitarlo) y BDUF (gran diseño al comienzo).

Por qué no construir el ambiente al tiempo que se desarrolla la primera historia? (y solo construir lo que necesitamos para esa historia). Obviamente es necesario estimar un esfuerzo mayor para esas primeras, también puede ser necesario un slice mas fino.

En ese sentido, tampoco me gusta el sprint 0, me parece una licencia para desarrollar la gran arquitectura, ambientes, etc.

Por ejemplo, por qué crear una servidor de bases de datos en el ambiente si las primeras historias no usarán la base de datos? Para que crear mas ambientes de los que voy a necesitar en el futuro cercano?

Entonces, los ítem de backlog que no son historias, deberían ser pocos y, definitivamente, no deberían ser materia de negociación con el PO (si el PO lo ve innecesario, entonces tenemos que hablar de eso).

Un saludo


(Felipe Martin) #7

Hola Claudio,

Creo que no existe “la” opción correcta, sino aquella que funciona mejor para el equipo y facilita la entrega de valor para el cliente.

He trabajado con requerimientos no funcionales como Historias de Usuario y también añadirla como tareas técnicas (en Jira pueden coexistir estos elementos). Te sugiero conversarlo con el equipo, ver lo que les hace más sentido y probar con eso. Puede ser que no sea necesaria una mayor descripción de una tarea o de un necesidad técnica, y baste con el nombre.

Si en un tiempo se dan cuenta que hubiera sido mejor de otra manera, o se puede mejorar lo que ya han decidido, háganlo.

El Kanban y las Historias siguen siendo herramientas, que están por detrás de los procesos y todos ellos por detrás de las personas. Experimenten y aprendan de su experiencia.

Saludos!