Nuevo en Scrum, sugerencia para crear Product Backlog
1,192 views
Skip to first unread message
COREVA
Feb 27, 2014, 2:02:14 PM2/27/14
to agile...@googlegroups.com
Hola a todos, soy nuevo en Scrum y como es mi primera experiencia quiero saber si voy por buen camino.
El proyecto en el que participaré tiene unos 17 requerimientos, entre reportes, CRUDs, consultas, etc. Ya los tenemos identificados, el tema es que aquí en la empresa se maneja únicamente RUP y es lo que conocemos. Por ello las dudas al adaptarnos a Scrum. De momento la idea es hacer un plan de trabajo en MsProject donde en lugar de resolver tiempos para cada Caso de Uso como hacíamos en RUP, ahora dividiremos el plan en Sprints.
Ahora, ahí viene mi primer duda: ¿En el Product Backlog deben ir únicamente los requerimientos de forma global, y estos se asocian a una historia de usuario? ¿En los Sprint Backlogs divido cada requerimiento en tareas que puedan caber en un sprint? Si es así, ¿Cómo ligo el sprint backlog y sus tareas con el product backlog? Esto por la visibilidad que pienso debe tener el Product Owner al mirar el Product Backlog para conocer el avance del proyecto (digo, también podría ver el plan de trabajo, ¿no?).
Pongo un ejemplo para hacerme entender: Uno de los "requerimientos" es un CRUD (create, update, delete) de datos. Los sprints los hemos pensado de una semana, por el tiempo corto que tenemos para desarrollar el producto. Siendo así, se me hace simple poner en el backlog:
Requerimiento 1: CRUD de datos para soporte de mapeos de información.
Pero siendo que eso es grande de desarrollar, esto no cabe en un sprint. Según lo que revisé de la documentación de scrum, este requerimiento debería ser "partido" en tareas más pequeñas, de tal forma que puedan entrar en los Sprints. ¿Es correcto?
Entonces, propongo esto:
Sprint 1: Insertar datos de mapeo de información (Req 1)
Sprint 2: Modificar datos de mapeo de información (Req 1), Borrar datos de Mapeo (Req 1).
¿Esto es correcto? ¿En el Product Backlog queda el requerimiento genérico y en los sprints las tareas desmenuzadas para completar ese requerimiento? ¿En el Product Backlog debo indicar (aunque sólo sea una anotación en el requerimiento) las tareas que componen ese requerimiento?
Por otro lado hay cosas adicionales como por ejemplo hacer modelo de datos, DAOs o instalar ambiente de desarrollo que obligatoriamente debo colocar en el Sprint 1. ¿Eso acaso tiene relación con algún requerimiento o debo crear un nuevo requerimiento para esas tareas? ¿Cómo se acostumbra manejarlas?
Mi idea es colocar el detalle de lo que involucra cada Sprint en el plan de trabajo. Obviamente sé que los Backlog son susceptibles a cambios, pero se requiere el plan para estimaciones de costos, tiempos y es que es es un proyecto con una duración definida ya de antemano y que necesita conocerse el costo total para saber cuanto pedir por la construcción del sistema.
Agradezco sus sugerencias.
El proyecto en el que participaré tiene unos 17 requerimientos, entre reportes, CRUDs, consultas, etc. Ya los tenemos identificados, el tema es que aquí en la empresa se maneja únicamente RUP y es lo que conocemos. Por ello las dudas al adaptarnos a Scrum. De momento la idea es hacer un plan de trabajo en MsProject donde en lugar de resolver tiempos para cada Caso de Uso como hacíamos en RUP, ahora dividiremos el plan en Sprints.
Ahora, ahí viene mi primer duda: ¿En el Product Backlog deben ir únicamente los requerimientos de forma global, y estos se asocian a una historia de usuario? ¿En los Sprint Backlogs divido cada requerimiento en tareas que puedan caber en un sprint? Si es así, ¿Cómo ligo el sprint backlog y sus tareas con el product backlog? Esto por la visibilidad que pienso debe tener el Product Owner al mirar el Product Backlog para conocer el avance del proyecto (digo, también podría ver el plan de trabajo, ¿no?).
Pongo un ejemplo para hacerme entender: Uno de los "requerimientos" es un CRUD (create, update, delete) de datos. Los sprints los hemos pensado de una semana, por el tiempo corto que tenemos para desarrollar el producto. Siendo así, se me hace simple poner en el backlog:
Requerimiento 1: CRUD de datos para soporte de mapeos de información.
Pero siendo que eso es grande de desarrollar, esto no cabe en un sprint. Según lo que revisé de la documentación de scrum, este requerimiento debería ser "partido" en tareas más pequeñas, de tal forma que puedan entrar en los Sprints. ¿Es correcto?
Entonces, propongo esto:
Sprint 1: Insertar datos de mapeo de información (Req 1)
Sprint 2: Modificar datos de mapeo de información (Req 1), Borrar datos de Mapeo (Req 1).
¿Esto es correcto? ¿En el Product Backlog queda el requerimiento genérico y en los sprints las tareas desmenuzadas para completar ese requerimiento? ¿En el Product Backlog debo indicar (aunque sólo sea una anotación en el requerimiento) las tareas que componen ese requerimiento?
Por otro lado hay cosas adicionales como por ejemplo hacer modelo de datos, DAOs o instalar ambiente de desarrollo que obligatoriamente debo colocar en el Sprint 1. ¿Eso acaso tiene relación con algún requerimiento o debo crear un nuevo requerimiento para esas tareas? ¿Cómo se acostumbra manejarlas?
Mi idea es colocar el detalle de lo que involucra cada Sprint en el plan de trabajo. Obviamente sé que los Backlog son susceptibles a cambios, pero se requiere el plan para estimaciones de costos, tiempos y es que es es un proyecto con una duración definida ya de antemano y que necesita conocerse el costo total para saber cuanto pedir por la construcción del sistema.
Agradezco sus sugerencias.
Alfredo Casado
Feb 27, 2014, 2:33:37 PM2/27/14
to agile...@googlegroups.com
Tienes un poco de lio, en primer lugar acostumbrate a usar el lenguaje de scrum y olvidate de eso de "requerimientos" y olvida también de las "tareas", al menos de lo que tu estas definiendo como tareas que en scrum son otra cosa, en scrum tenemos:
- El centro de todo, la historia de usuario, una HU es algo que añade algún valor al producto para el usuario.
- Tareas, en ocasiones las HU se dividen en tareas, con objetivo de poder estimar mejor, pero nada más, un sprint esta compuesto de un conjunto de HU (a mi no me gusta dividir en tareas por ejemplo).
- Epicas, conjunto de historias relacionadas de algún modo, simplemente se suelen anotar en el backlog a que epica pertenece cada historia, esto también es opcional.
Por tu forma de definir las "tareas" me da la sensación de que estas pensando en tareas más desde el punto de vista de organización técnica que desde el punto de vista de historias de usuario, me explico, pensando en tu CRUD, no tiene sentido hacer en el primer sprint todas las inserciones y en el segundo modificaciones y borrados, lo que tiene sentido es tener historias de usuario del tipo:
- crud de clientes.
- crud de proveedores
- crud de...
De esta forma cada historia agrega valor, no sirve para mucho insertar registros si no se pueden modificar o borrar, y será preferible llegar al ultimo día de proyecto diciendo: "no hemos terminado, pero tenemos terminadas las partes de clientes, proveedores y ..., aunque nos falta el CRUD de forlayos..", que decir "podemos insertar y modificar pero no se puede borrar registro". En el primer caso tienes un sistema usable en un X%, en el segundo caso tienes un sistema que se puede usar el 0%. (puedes insertar X pero si te equivocas no se puede borrar... mala suerte!).
Es decir, se trata de avanzar en pequeños pasos en los que cada uno añade valor al proyecto, no lo enfoques dividir un desarrollo gordo en etapas, enfocalo como si cualquier día se pudiera cancelar el proyecto y aún así tuvieras un producto usable, estas es de las cosas más importantes del cambio a agile.
Sobre lo de los DAO's y los entornos, estas cosas jamas deben ir en un backlog, un backlog son historias de usuario, y ningún usuario quiere que le des unos DAO's o que le cuentes que tienes un build con maven y jenkins, esto no son historias de usuario. Y por supuesto tampoco necesitas una tarea para definir todos tus DAO's, en cada historia de usuario crearas el código y los artefactos (tablas por ejemplo) que necesites para cumplir con esa necesidad del usuario, esto de ponerse a hacer un modelo de datos de todo el proyecto y definir "la capa de DAO's" no es precisamente muy ági, si quereís cambiar a agile necesitais este cambio de mentalidad lo primero. Y hombre yo como cliente espero que tengas tus herramientas a punto y tus entornos preparados ¿no pretenderas cobrarme por esto no?
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para ver este debate en la Web, visita https://groups.google.com/d/msgid/agile-spain/5344f351-ab92-4380-98c8-b63c66ae5134%40googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
COREVA
Feb 27, 2014, 5:30:32 PM2/27/14
to agile...@googlegroups.com
Gracias por tu respuesta. Te pregunto: Por ejemplo si tengo la historia de CRUD de clientes y un sprint no es suficiente para terminarlo ¿Cómo lo muestras en tu plan?
¿Lo divides en varios Sprints?
El término "tarea" lo saqué del libro "Scrum y XP desde las trincheras" y de "Kanban vs Scrum" en español, pensé que era la forma adecuada de nombrar a una actividad. Lo que yo leí es que si una historia es muy larga la divido en varias "tareas" que reparto en varios Sprints. Claro, es sencillo leerlo pero aplicarlo es otra cosa. De hecho mi intención es obtener más información, no pretender que ya sé hacer las cosas. De allí que pregunto por como ha sido su experiencia.
Respecto a los temas de arquitectura y diseño de la solución, entiendo que se debe hacer algo en cada sprint (en el Sprint Backlog debería aparecer algo al respecto, ¿no?), pero ¿no vale la pena tener antes un diseño global aunque fuera básico? ¿No es riesgoso ponerse a trabajar sin haber definido esas cuestiones técnicas? No digo que deban ser historias de usuario o tareas en el Backlog, más bien pregunto cómo deberían trabajarse.
Por el tema de costos y si cobrar o no al cliente por instalar herramientas, aquí sí lo acostumbramos detallar en el plan de trabajo al estilo RUP, es un tiempo finalmente, que aunque sean sólo unas horas, suma horas al proyecto. Pero quizás nos estamos desviando y ese tema lo vé el área comercial de la empresa y la PMO (el como justificar el plan de trabajo).
¿Lo divides en varios Sprints?
El término "tarea" lo saqué del libro "Scrum y XP desde las trincheras" y de "Kanban vs Scrum" en español, pensé que era la forma adecuada de nombrar a una actividad. Lo que yo leí es que si una historia es muy larga la divido en varias "tareas" que reparto en varios Sprints. Claro, es sencillo leerlo pero aplicarlo es otra cosa. De hecho mi intención es obtener más información, no pretender que ya sé hacer las cosas. De allí que pregunto por como ha sido su experiencia.
Respecto a los temas de arquitectura y diseño de la solución, entiendo que se debe hacer algo en cada sprint (en el Sprint Backlog debería aparecer algo al respecto, ¿no?), pero ¿no vale la pena tener antes un diseño global aunque fuera básico? ¿No es riesgoso ponerse a trabajar sin haber definido esas cuestiones técnicas? No digo que deban ser historias de usuario o tareas en el Backlog, más bien pregunto cómo deberían trabajarse.
Por el tema de costos y si cobrar o no al cliente por instalar herramientas, aquí sí lo acostumbramos detallar en el plan de trabajo al estilo RUP, es un tiempo finalmente, que aunque sean sólo unas horas, suma horas al proyecto. Pero quizás nos estamos desviando y ese tema lo vé el área comercial de la empresa y la PMO (el como justificar el plan de trabajo).
Ismael Olea
Feb 27, 2014, 6:18:00 PM2/27/14
to agile...@googlegroups.com
2014-02-27 23:30 GMT+01:00 COREVA <oresi...@gmail.com>:
Gracias por tu respuesta. Te pregunto: Por ejemplo si tengo la historia de CRUD de clientes y un sprint no es suficiente para terminarlo ¿Cómo lo muestras en tu plan?
¿Lo divides en varios Sprints?
sí: intentas identificar incrementos de producto con algún grado de completitud, si no puede acabarse una funcionalidad completa yo la descompondría en clases/bibliotecas o equivalente que de tiempo a quedar concluido durante el sprint.
Respecto a los temas de arquitectura y diseño de la solución, entiendo que se debe hacer algo en cada sprint (en el Sprint Backlog debería aparecer algo al respecto, ¿no?), pero ¿no vale la pena tener antes un diseño global aunque fuera básico?
lo bueno de scrum es que, al menos en mi interpretación, no aplica exclusivamente a la codificación del software sino a todo el ciclo de vida del proyecto: las labores de análisis deben quedar encajadas en la carga de trabajo de los sprints. si en un proyecto que empieza desde cero y partiendo con que ya tengo una pila de producto aparentemente completa me parece obvio que el equipo organizará el trabajo preciso de análisis y diseño, y el trabajo del equipo se organiza por sprints.
supongo que en la práctica depende de qué recursos tiene disponible el equipo y con ellos organizar el trabajo de una forma u otra. nadie serio se va a poner a picar código desde cero
¿No es riesgoso ponerse a trabajar sin haber definido esas cuestiones técnicas? No digo que deban ser historias de usuario o tareas en el Backlog, más bien pregunto cómo deberían trabajarse.
en el backlog mantienes las historias desde el punto de vista del «negocio» del cliente
en el sprint las tareas del equipo de ingeniería y desarrollo
las reuniones de preparación del sprint y demo son las conversaciones en las que se casan las prioridades del negocio con las exigencias de la ingeniería en función de los recursos disponibles. en esas conversaciones se negocia la carga de trabajo con realimentación mutua.
entre esas exigencias de ingeniería encuentro obvio que están todas las cuestiones de arquitectura y diseño, por supuesto. y también encuentro obvio que en los primeros sprints de un proyecto mediano/grande la mayoría de los productos no sean software.
Por el tema de costos y si cobrar o no al cliente por instalar herramientas, aquí sí lo acostumbramos detallar en el plan de trabajo al estilo RUP, es un tiempo finalmente, que aunque sean sólo unas horas, suma horas al proyecto. Pero quizás nos estamos desviando y ese tema lo vé el área comercial de la empresa y la PMO (el como justificar el plan de trabajo).
sobre instalar herramientas, hombre, depende, lo suyo es que ya conozcas las que vas a usar: entre otras cosas al equipo le sirve para hacer mejor las estimaciones. si estamos hablando de tareas relativamente rutinarias (levantar un sistema CI propio para el proyecto, o un laboratorio de pruebas específico para el mismo o cualquier otra cosa del estilo) entonces yo la veo que forma parte 100% de la actividad del proyecto y que debe recogerse dentro del sprint
generalizando: en el sprint se organiza toda la carga de trabajo del equipo relativa al proyecto, y yo interpreto que eso incluye todas las labores de las cuales el equipo es genuinamente responsable por activa o por pasiva. vamos: como que si para acabar el proyecto hay que pintar una pared y cantar la Marsellesa, esas son tareas que entran dentro del sprint.
Ismael Olea
http://olea.org/diario
Alfredo Casado
Feb 27, 2014, 6:57:19 PM2/27/14
to agile...@googlegroups.com
Por ejemplo si tengo la historia de CRUD de clientes y un sprint no es suficiente para terminarlo ¿Cómo lo muestras en tu plan?, ¿Lo divides en varios Sprints?
No, si una historia no te cabe en un sprint es porque es demasiado larga, las historias deben tratar de definirse de forma que siendo lo más pequeñas posibles añadan valor al producto. Si una historia no cabe en un sprint es indicativo de que no estas dividiendo bien en historias cortas, o que tus sprints son demasiado cortos que también puede ser, posiblemente una semana sea excesivo si estas empezando con scrum. Pero el final de un sprint se entregan historias terminadas, si las historias terminadas no agregan nada al producto (una librería, una "capa" de DAO's o similares) entonces es equivalente a no tener nada terminado. Esto hablando en general, si se trata de un crud de una tabla y tardas más de media hora tus problemas son otros, probablemente no usar las herramientas adecuadas, y si no se trata de un crud y tienen "algo más" entonces es más que probable que pueda dividirse en historias más pequeñas que aporten valor al negocio.
¿no vale la pena tener antes un diseño global aunque fuera básico?
En absoluto, no al menos si quieres hacer agilismo, en cada historia haces el diseño/arquitectura necesario para esa historia, ni más ni menos.
¿No es riesgoso ponerse a trabajar sin haber definido esas cuestiones técnicas?
El agilismo considera que el riesgo es definir diseños y arquitecturas en las etapas tempranas del proyecto que es cuando menos información se tiene. La idea es que tu arquitectura y diseño vaya emergiendo en función de las necesidades que se plantean en cada historia de usuario. Todas las practicas técnicas del agilismo TDD, CI, propiedad colectiva, pair programming contribuyen y posibilitan esta idea de diseño, si no las hacéis es bastante difícil conseguir este objetivo, por supuesto es recomiendo hacerlas ante el riesgo de acabar en un nuevo caso de flacid scrum.
Ismael:
"encuentro obvio que en los primeros sprints de un proyecto mediano/grande la mayoría de los productos no sean software."
Pues no es nada obvio, el manifiesto agil dice en uno de sus principios: Working software is the primary measure of progress.
En ocasiones puede haber otros productos como documentación para el usuario final u otros, pero siempre entregables para el usuario/cliente final. Si te refieres a productos internos como documentación, UML's, diseños de BD etc,etc, estas cosas en scrum no se pueden considerar productos y no suponen ningún avance en el proyecto, en términos lean se podrían decir que son desperdicio (waste)
Me da la sensación vais más en la dirección de enmascarar un proceso tipico waterfall o RUP detrás de scrum, esto no es agilismo, es otra cosa, si os habéis planteado el cambio supongo que será para resolver problemas que tenéis actualmente, si lo único que hacéis es lo mismo pero con post-its y "sprints" os vais a quedar igual que al principio, el cambio al agilismo es fundamentalmente un cambio de mentalidad y no tanto de procedimientos o procesos.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para ver este debate en la Web, visita https://groups.google.com/d/msgid/agile-spain/CAARR2rZKEagQtx7r53kSy%2BKY3%3DL%2BMaCp1a3FpnBBbmZX_iY1DA%40mail.gmail.com.
Ismael Olea
Mar 3, 2014, 4:37:37 AM3/3/14
to agile...@googlegroups.com
2014-02-28 0:57 GMT+01:00 Alfredo Casado <casado....@gmail.com>:
"encuentro obvio que en los primeros sprints de un proyecto mediano/grande la mayoría de los productos no sean software."Pues no es nada obvio, el manifiesto agil dice en uno de sus principios: Working software is the primary measure of progress.En ocasiones puede haber otros productos como documentación para el usuario final u otros, pero siempre entregables para el usuario/cliente final. Si te refieres a productos internos como documentación, UML's, diseños de BD etc,etc, estas cosas en scrum no se pueden considerar productos y no suponen ningún avance en el proyecto, en términos lean se podrían decir que son desperdicio (waste)
En este caso hago mía la máxima de que «la calidad no es negociable». Si la clase de artefactos de los que hablamos son necesarios para garantizar el mínimo de calidad que el equipo se autoexige desde mi punto de vista no sólo pueden sino que deben entrar en la carga de trabajo de sprints.
También hay voces que claman por la importancia de la documentación interna. Yo estoy de acuerdo si forman parte del sistema de calidad del equipo. Y como con todo lo importante es asegurarse continuamente que no se le dedica más tiempo del mínimo imprescindible.
Sí que estoy de acuerdo en evitar a toda costa el sobrediseño, que puede ser un hábito adquirido en las prácticas de cascada, que puede padecer un proyecto en cascada y gracias a tener ordenada la pila del producto podemos acotar las restricciones e imponer límites que asociamos a fechas de entrega.
Reply all
Reply to author
Forward
0 new messages