Primera pregunta, como definir un backlog, cuando no hay trabajo?
16 views
Skip to first unread message
Stuardo -StR- Rodríguez
Jun 16, 2009, 4:26:32 PM6/16/09
to comunidad-s...@googlegroups.com
Mi primera pregunta es el porqué llegué al desespere. He trabajado en un par de empresas, donde el flujo y cantidad de trabajo nos permitía hacer backlogs de 1 o 2 semanas (mas que eso no, pues desarrollo web es mucho mas cambiante). Actualmente trabajo en una empresa enfocada 100% al eCommerce. Esto va bastante pegado al marketing.
Mi problema es que no hay suficiente trabajo para hacer un backlog de 1 semana. No se saben que tareas se tengan para mas de 2 días, y es muy común que nuestro daily scrum se cambie a la mitad del día porque hay algo que urge lanzarlo hoy. Este es mi pan de todos los días ahora y siento que el problema me está ganando.
¿Qué hacer en estos casos?
Muchas gracias por sus comentarios
Mi problema es que no hay suficiente trabajo para hacer un backlog de 1 semana. No se saben que tareas se tengan para mas de 2 días, y es muy común que nuestro daily scrum se cambie a la mitad del día porque hay algo que urge lanzarlo hoy. Este es mi pan de todos los días ahora y siento que el problema me está ganando.
¿Qué hacer en estos casos?
Muchas gracias por sus comentarios
Sergio Acosta
Jun 16, 2009, 4:43:19 PM6/16/09
to comunidad-s...@googlegroups.com
Le voy a pensar a ver si puedo hacer un comentario mas atinado más
tarde =), pero en principio la situación que comentas me suena mucho a
que es un contexto de reacción rápida mas como de soporte a producción
y funcionalidad muy puntual y no tanto un producto completo. Estoy en
lo cierto?
Por que si es así, me suena mucho a un entorno como para Kanban:
Es una técnica muy similar a Scrum, pero mas orientado a la
priorización ágil de backlog items día con día y no hay un backlog
comprometido para un plazo fijo. Precisamente el objetivo es que
tengas la forma de reaccionar a requerimientos muy cambiantes y
urgentes y de los cuales tal vez no tienes visibilidad varias semanas
antes como para hacer una planeación de un sprint.
Esta es una presentación de intro a Kanban para desarrollo de software:
http://www.infoq.com/presentations/kanban-for-software
La presentación está un poco pesada (aburrida) pero está interesante.
Y aqui hay un par de links de intro al tema:
Kanban Applied to Software Development: from Agile to Lean
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
Kanban in Software Development
http://www.targetprocess.com/blog/2008/09/kanban-in-software-development.html
Si crees que la situación de tu empresa actual se prestaría a
implementar algo asi? O de plano no aplica?
saludos,
sergio
tarde =), pero en principio la situación que comentas me suena mucho a
que es un contexto de reacción rápida mas como de soporte a producción
y funcionalidad muy puntual y no tanto un producto completo. Estoy en
lo cierto?
Por que si es así, me suena mucho a un entorno como para Kanban:
Es una técnica muy similar a Scrum, pero mas orientado a la
priorización ágil de backlog items día con día y no hay un backlog
comprometido para un plazo fijo. Precisamente el objetivo es que
tengas la forma de reaccionar a requerimientos muy cambiantes y
urgentes y de los cuales tal vez no tienes visibilidad varias semanas
antes como para hacer una planeación de un sprint.
Esta es una presentación de intro a Kanban para desarrollo de software:
http://www.infoq.com/presentations/kanban-for-software
La presentación está un poco pesada (aburrida) pero está interesante.
Y aqui hay un par de links de intro al tema:
Kanban Applied to Software Development: from Agile to Lean
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
Kanban in Software Development
http://www.targetprocess.com/blog/2008/09/kanban-in-software-development.html
Si crees que la situación de tu empresa actual se prestaría a
implementar algo asi? O de plano no aplica?
saludos,
sergio
David Arturo Cruz Salinas
Jun 16, 2009, 4:46:12 PM6/16/09
to comunidad-s...@googlegroups.com
En mi opinión, no todo lo que es Scrum aplica en tu caso. Sobre todo porque un sprint para ustedes sería como de 2 días, y en esa brecha de tiempo tan corta gastarías más esfuerzo en medir tiempos y hacer retrospectivas y planeaciones de lo que ganarías.
Sin embargo me parece que puedes rescatar algunas de las cosas de la filosofía Scrum. Los daily scrum meetings creo que sí convienen si son breves, y en mi opinión, en esa misma reunión metería una retrospectiva muy rápida, para ir mejorando el proceso.
Y dado el tiempo tan corto entre solicitudes, intentaría reunirme con el product owner al menos una vez a la semana para ir corrigiendo el rumbo si se están dando mal las prioridades.
En el caso de las estimaciones de tiempo, al ser cosas muy breves, es más fácil calcular, por lo que no creo que valga la pena que participe todo el equipo con un poker planning o algo así, tal vez la persona asignada sea suficiente para estimar, a menos que el equipo opine muy diferente, pero eso se platicaría en cada daily scrum meeting.
Qué te parece?
Stuardo -StR- Rodríguez
Jun 17, 2009, 6:58:16 PM6/17/09
to comunidad-s...@googlegroups.com
2009/6/16 Sergio Acosta <sergio...@gmail.com>
Esta es una presentación de intro a Kanban para desarrollo de software:
http://www.infoq.com/presentations/kanban-for-software
Luego de ver el video, tomé una idea vaga, y estoy deborando todo artículo que encuentro sobre Kanban, pero tengo varias dudas. Dicen que ellos no manejan iteraciones, que cualquier día se van acomodando prioridades y mas cosas entran en cola, según la capacidad definida permita. Pero finalmente dice que todo se hace release cada 2 semanas (los miércoles cada 2 semanas).. osea que finalmente si tienen releases planeados y "sprints".. lo que no tienen es backlog.
Entiendo bien?
David Arturo Cruz Salinas
Jun 17, 2009, 7:23:30 PM6/17/09
to comunidad-s...@googlegroups.com
Me parece que también el asunto es que, ya sea kanban o scrum, no definen reglas específicas. Dan algunas ideas de cómo se puede implementar y se basan más en principios. Sin embargo a uno le toca tomar lo que le conviene de cada idea para crear el proceso más acercado a lo que se necesita en cada caso. Los tiempos de release sobre todo, tiene mucho que ver con tu product owner.
En tu caso podrías hacer una mezcla de ideas:
- Para que el proceso no sea complejo
- Para que puedas generar alguna planeación aunque sea diaria
- Para que puedas tener alguna retroalimentación del trabajo del equipo y del proceso para poder mejorarlos
- Para que puedas medir la efectividad del equipo en cada entrega y detectar fallas.
Saludos!
Jorge Vargas Garcia
Jun 17, 2009, 10:54:46 PM6/17/09
to comunidad-s...@googlegroups.com
Hola,
--
Jorge (edivargas) Vargas Garcia
Java Consultant - SJCP
SUN Java Champion - java-champions.dev.java.net
JavaUP - www.javaup.org
Comunidad Java Mexico - www.comunidadjava.org
SUN Educacion - www.suneducacion.com
Mobile (52) 55 3334 9115
Twitter/Gtalk/Yahoo/hi5: edivargas
skype: edivargasjvg
Facebook: ediv...@gmail.com
MSN: ediv...@hotmail.com
No al contrario ambos tienen product backlog y priorizaciones, la diferencia es que en el kanban no se genera el proceso de preplaneacion, planeacion, review y sprint que al final consume tiempo del equipo y se necesita para proyectos mas amplios y que acomode iteraciones.
La idea de meter todos los requierimientos al kanban es que tienes el product back log a la vista, con sus pirizaciones y ejecutas las tareas. El tener release es que cosas que has terminado sean sacadas a produccion en iteraciones definidas, pero si el proyecto que comentas es pequeño, tu puedes definir iteraciones muy pequeñas, por ejemplo los martes y viernes, entonces sacas cosas esos dias.
No olvides que igual requieres de actividades de integracion o pruebas no funcionales que evitaria iteraciones tan pequeñas y las de una semana quedan mejor.
--
Jorge (edivargas) Vargas Garcia
Java Consultant - SJCP
SUN Java Champion - java-champions.dev.java.net
JavaUP - www.javaup.org
Comunidad Java Mexico - www.comunidadjava.org
SUN Educacion - www.suneducacion.com
Mobile (52) 55 3334 9115
Twitter/Gtalk/Yahoo/hi5: edivargas
skype: edivargasjvg
Facebook: ediv...@gmail.com
MSN: ediv...@hotmail.com
Carlos Ortega
Jun 19, 2009, 3:57:35 PM6/19/09
to comunidad-s...@googlegroups.com
Stuardo....
Aquí algunos comentarios....
Es importante definir la diferencia entre la operaciones cotidianas (daily
activities) y lo que son proyectos.
En alguna ocasión un cliente con el que estuve, tuvo ese problema, y se
trato de definir conjuntamente (entre los líderes/responsables de diferentes
áreas) que se debe considerar como un proyecto, ellos decidieron que
cualquier esfuerzo que de manera inicial y "al vuelo" tomara mas de 80hrs
sería considerado como un "proyecto".
La razón obedecía mas a negocio, ya que el 70 u 80 por ciento de sus
actividades tomaban de pocas horas a algunos días y cuando mas eran
realizadas por 2 o 3 personas, pero en muchos casos 1 sola persona era
responsable de hacer las tareas.
Después decidieron que deberían de tener 2 o 3 "perfiles" por tipos de
proyectos, esto es, no todos los proyectos recibirían el mismo tratamiento,
el más sofisticado de los perfiles requería no solo de mayor planeación,
sino también de alojamiento de recursos (humanos y materiales) y tiempos por
otras áreas y una mayor visibilidad hacia las áreas usuarias y por supuesto
las áreas de sistemas.
Por supuesto quizás muchos se pregunten porque 80 hrs, parece arbitrario
considerar solo esa condición para declarar a "algo" como proyecto.
En realidad si lo fue.
Pero sirvió.
En esa ocasión la idea era comenzar con algo, es decir probarlo, y si no
resultaba, se podía descartar después.
Por otra parte era tanta la presión de llevar algo de control en sus
actividades que incluso el hecho de pensar y analizar lo que se podía o no,
tomar como discriminantes para considerar lo que era un proyecto era en si
una actividad que pocas veces podían tomarse el lujo de llevar a cabo, por
eso mismo a pesar de que fue poco el tiempo de análisis todos trataron y se
esforzaron para que esa medida fuera su primer discriminante base.
Es decir, como quizás escuchaste en la reunión que se tuvo, muchas ocasiones
no hay una única y absoluta respuesta, variara de equipo a equipo y de
organización a organización, sin embargo lo importante es la propuesta y que
se empiecen a realizar las actividades para comprobar o refutar la validez
de sus propias iniciativas.
Espero que esto te pueda servir de ayuda.
Saludos
Carlos
-----Mensaje original-----
De: comunidad-s...@googlegroups.com
[mailto:comunidad-s...@googlegroups.com] En nombre de Sergio Acosta
Enviado el: Martes, 16 de Junio de 2009 03:43 p.m.
Para: comunidad-s...@googlegroups.com
Asunto: Re: Primera pregunta, como definir un backlog, cuando no hay
trabajo?
Aquí algunos comentarios....
Es importante definir la diferencia entre la operaciones cotidianas (daily
activities) y lo que son proyectos.
En alguna ocasión un cliente con el que estuve, tuvo ese problema, y se
trato de definir conjuntamente (entre los líderes/responsables de diferentes
áreas) que se debe considerar como un proyecto, ellos decidieron que
cualquier esfuerzo que de manera inicial y "al vuelo" tomara mas de 80hrs
sería considerado como un "proyecto".
La razón obedecía mas a negocio, ya que el 70 u 80 por ciento de sus
actividades tomaban de pocas horas a algunos días y cuando mas eran
realizadas por 2 o 3 personas, pero en muchos casos 1 sola persona era
responsable de hacer las tareas.
Después decidieron que deberían de tener 2 o 3 "perfiles" por tipos de
proyectos, esto es, no todos los proyectos recibirían el mismo tratamiento,
el más sofisticado de los perfiles requería no solo de mayor planeación,
sino también de alojamiento de recursos (humanos y materiales) y tiempos por
otras áreas y una mayor visibilidad hacia las áreas usuarias y por supuesto
las áreas de sistemas.
Por supuesto quizás muchos se pregunten porque 80 hrs, parece arbitrario
considerar solo esa condición para declarar a "algo" como proyecto.
En realidad si lo fue.
Pero sirvió.
En esa ocasión la idea era comenzar con algo, es decir probarlo, y si no
resultaba, se podía descartar después.
Por otra parte era tanta la presión de llevar algo de control en sus
actividades que incluso el hecho de pensar y analizar lo que se podía o no,
tomar como discriminantes para considerar lo que era un proyecto era en si
una actividad que pocas veces podían tomarse el lujo de llevar a cabo, por
eso mismo a pesar de que fue poco el tiempo de análisis todos trataron y se
esforzaron para que esa medida fuera su primer discriminante base.
Es decir, como quizás escuchaste en la reunión que se tuvo, muchas ocasiones
no hay una única y absoluta respuesta, variara de equipo a equipo y de
organización a organización, sin embargo lo importante es la propuesta y que
se empiecen a realizar las actividades para comprobar o refutar la validez
de sus propias iniciativas.
Espero que esto te pueda servir de ayuda.
Saludos
Carlos
-----Mensaje original-----
De: comunidad-s...@googlegroups.com
[mailto:comunidad-s...@googlegroups.com] En nombre de Sergio Acosta
Enviado el: Martes, 16 de Junio de 2009 03:43 p.m.
Para: comunidad-s...@googlegroups.com
Asunto: Re: Primera pregunta, como definir un backlog, cuando no hay
trabajo?
Reply all
Reply to author
Forward
0 new messages