Comentarios en: SCRUM para un equipo en MÚLTIPLES proyectos http://www.programania.net/desarrollo-agil/scrum-para-un-equipo-en-multiples-proyectos/ Ingeniería del Software Tue, 09 Mar 2010 17:10:04 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Por: Luis Artola http://www.programania.net/desarrollo-agil/scrum-para-un-equipo-en-multiples-proyectos/comment-page-1/#comment-12813 Luis Artola Wed, 21 Jan 2009 10:32:46 +0000 http://www.programania.net/?p=395#comment-12813 Hola Emilio, para nada llegas tarde! Lo que comentas de los "guardianes" o "responsables" me parece básico. Siempre tiene que haber una sola voz, y más si es cara al cliente... ;-) me apunto tu blog! Hola Emilio,

para nada llegas tarde! Lo que comentas de los “guardianes” o “responsables” me parece básico. Siempre tiene que haber una sola voz, y más si es cara al cliente… ;-)

me apunto tu blog!

]]> Por: Emilio Bravo http://www.programania.net/desarrollo-agil/scrum-para-un-equipo-en-multiples-proyectos/comment-page-1/#comment-12800 Emilio Bravo Tue, 20 Jan 2009 10:15:43 +0000 http://www.programania.net/?p=395#comment-12800 Hola, espero no llegar muy tarde :-D. Nosotros usamos la misma técnica que ha comentado Miguel. Tenemos un backlog para cada proyecto y es en la pila del Sprint donde vamos metiendo lo que cabe de cada proyecto. Para la gestión de los proyectos usamos Jira acompañado del correspondiente tablón. Para la comunicación con la gerencia(comerciales)seria conveniente poner un "guardian" que fuera el único canal de comunicación con el equipo, de esta manera tenemos controladas las posibles interrupciones. Saludos. Hola, espero no llegar muy tarde :-D .
Nosotros usamos la misma técnica que ha comentado Miguel. Tenemos un backlog para cada proyecto y es en la pila del Sprint donde vamos metiendo lo que cabe de cada proyecto.
Para la gestión de los proyectos usamos Jira acompañado del correspondiente tablón.
Para la comunicación con la gerencia(comerciales)seria conveniente poner un “guardian” que fuera el único canal de comunicación con el equipo, de esta manera tenemos controladas las posibles interrupciones.

Saludos.

]]> Por: Miguel http://www.programania.net/desarrollo-agil/scrum-para-un-equipo-en-multiples-proyectos/comment-page-1/#comment-12753 Miguel Sat, 10 Jan 2009 17:53:35 +0000 http://www.programania.net/?p=395#comment-12753 Luis, los tecnicos suelen formar equipos de generalmente 2, que normalmente llevan varios proyectos juntos, así se suelen cubrir unos a otros, y en general se ayudan en varias cosas. Por supuesto los equipos rotan, pero se hace caoticamente, ya que cuando un miembro del equipo se queda libre, puede compartir proyecto con otro compañero. Juan comenta 2 cosas interesantes. 1.- Compartir con los comerciales el respeto por los sprints. A veces es duro ya que tienes que pelearlo, pero se van dando cuenta que aunque a veces les demos tortas, se les proporciona una seguridad de fechas y calidad que antes no tenian, y despues de un tiempo son ellos los que te obligan a llevar la metodologia. 2.-Fundamental la coordinacion para descomposicion, estimacion y final de sprint. Mucho cuidado con acumular sprints para una persona, ya que no podra llegar a todos. Saludos! Luis, los tecnicos suelen formar equipos de generalmente 2, que normalmente llevan varios proyectos juntos, así se suelen cubrir unos a otros, y en general se ayudan en varias cosas.
Por supuesto los equipos rotan, pero se hace caoticamente, ya que cuando un miembro del equipo se queda libre, puede compartir proyecto con otro compañero.

Juan comenta 2 cosas interesantes. 1.- Compartir con los comerciales el respeto por los sprints. A veces es duro ya que tienes que pelearlo, pero se van dando cuenta que aunque a veces les demos tortas, se les proporciona una seguridad de fechas y calidad que antes no tenian, y despues de un tiempo son ellos los que te obligan a llevar la metodologia.

2.-Fundamental la coordinacion para descomposicion, estimacion y final de sprint. Mucho cuidado con acumular sprints para una persona, ya que no podra llegar a todos.

Saludos!

]]> Por: Luis Artola http://www.programania.net/desarrollo-agil/scrum-para-un-equipo-en-multiples-proyectos/comment-page-1/#comment-12642 Luis Artola Wed, 31 Dec 2008 08:04:23 +0000 http://www.programania.net/?p=395#comment-12642 Hola Juan, encantado de verte por aquí! :-D Entiendo que los consejos que das van en la dirección de homogeneizar todos los proyectos lo máximo posible de tal manera que el cambio entre ellos suponga el menor tedio para el desarrollador. Como dices, no es fácil, pero creo que vale la pena ingeniárselas para intentarlo :-D Hola Juan,

encantado de verte por aquí! :-D

Entiendo que los consejos que das van en la dirección de homogeneizar todos los proyectos lo máximo posible de tal manera que el cambio entre ellos suponga el menor tedio para el desarrollador. Como dices, no es fácil, pero creo que vale la pena ingeniárselas para intentarlo :-D

]]> Por: Juan http://www.programania.net/desarrollo-agil/scrum-para-un-equipo-en-multiples-proyectos/comment-page-1/#comment-12639 Juan Tue, 30 Dec 2008 20:57:11 +0000 http://www.programania.net/?p=395#comment-12639 Hola! Qué charla tan interesante. Siento no haberla visto antes. Tenéis mucha razón: la verdad es que, en la mayoría de las empresas de por aquí, lo de equipos de 5 ó 6 personas dedicadas a un proyecto es muy raro (o desconocido). Aquí es más normal, dedicar una persona a cada proyecto, y que haga lo que pueda, y además se le interrumpe para que "switchee en multi-tarea" si surge alguna tarea de mantenimiento con otro proyecto que también hizo, o que él conoce. Ahora no me puedo quejar (o no mucho), pero en los 5 años que llevé el departamento de otra empresa (50-60 programadores)... los proyectos más grandes nunca tuvieron más de 3 personas (aunque eran operaciones comerciales de facturación más que respetable, pero ese es otro tema), y el "switcheo" y las emergencias eran la norma. No se si os puede servir, porque cada empresa tiene sus cosas, pero apuntaría: compartir con el resto (comercial, gerencia...) la necesidad de respetar iteraciones y no interrumpirlas. Una plataforma técnica homogénea usada en todos los proeyctos (motor de integración continua, control de código y plataforma de pre-producción para dejar los incrementos "terminados" y que se puedan validar al final de cada iteración). Coordinación de sprints por grupos de 4 a 6 personas (estén en 3, 4 o 6 proyectos, pero NO una persona en varios): pero tratando igualmente las historias que se van a hacer, su descomposición y estimación al inicio, porque todas las aportaciones de unos a otros, sugerencias de enfoque de cada historia... se comparten igual en equipo. Quizá pueda ser un criterio para agrupar estos equipos, el que tengan el mismo comercial, para que sea el mismo propietario de producto en el sprint y pueda decidir qué historias de sus cuentas de proyectos va a tener. Esto obliga a que los proyectos de cada grupo vayan a hacer un sprint de igual duración.... Desde luego, no es fácil. Un saludo, y lo mejor para 2009!. Hola!
Qué charla tan interesante.
Siento no haberla visto antes.
Tenéis mucha razón: la verdad es que, en la mayoría de las empresas de por aquí, lo de equipos de 5 ó 6 personas dedicadas a un proyecto es muy raro (o desconocido).
Aquí es más normal, dedicar una persona a cada proyecto, y que haga lo que pueda, y además se le interrumpe para que “switchee en multi-tarea” si surge alguna tarea de mantenimiento con otro proyecto que también hizo, o que él conoce.

Ahora no me puedo quejar (o no mucho), pero en los 5 años que llevé el departamento de otra empresa (50-60 programadores)… los proyectos más grandes nunca tuvieron más de 3 personas (aunque eran operaciones comerciales de facturación más que respetable, pero ese es otro tema), y el “switcheo” y las emergencias eran la norma.

No se si os puede servir, porque cada empresa tiene sus cosas, pero apuntaría: compartir con el resto (comercial, gerencia…) la necesidad de respetar iteraciones y no interrumpirlas. Una plataforma técnica homogénea usada en todos los proeyctos (motor de integración continua, control de código y plataforma de pre-producción para dejar los incrementos “terminados” y que se puedan validar al final de cada iteración). Coordinación de sprints por grupos de 4 a 6 personas (estén en 3, 4 o 6 proyectos, pero NO una persona en varios): pero tratando igualmente las historias que se van a hacer, su descomposición y estimación al inicio, porque todas las aportaciones de unos a otros, sugerencias de enfoque de cada historia… se comparten igual en equipo. Quizá pueda ser un criterio para agrupar estos equipos, el que tengan el mismo comercial, para que sea el mismo propietario de producto en el sprint y pueda decidir qué historias de sus cuentas de proyectos va a tener. Esto obliga a que los proyectos de cada grupo vayan a hacer un sprint de igual duración….

Desde luego, no es fácil.

Un saludo, y lo mejor para 2009!.

]]> Por: Luis Artola http://www.programania.net/desarrollo-agil/scrum-para-un-equipo-en-multiples-proyectos/comment-page-1/#comment-12417 Luis Artola Mon, 15 Dec 2008 08:01:38 +0000 http://www.programania.net/?p=395#comment-12417 Muy interesante Miguel. Un backlog para cada proyecto, pero un sólo backlog de sprint (sin olvidar documentación y pruebas). Supongo que cada uno debe adaptarlo a la realidad de su empresa (35 proyectos en un sólo backlog podría ser un poco infernal si.. :-D) Vuestros 15 técnicos: ¿forman un sólo equipo? ¿los tenéis divididos por equipos que son siempre iguales o rotan? Me parece otra cuestión interesante... Muy interesante Miguel. Un backlog para cada proyecto, pero un sólo backlog de sprint (sin olvidar documentación y pruebas).

Supongo que cada uno debe adaptarlo a la realidad de su empresa (35 proyectos en un sólo backlog podría ser un poco infernal si.. :-D )
Vuestros 15 técnicos: ¿forman un sólo equipo? ¿los tenéis divididos por equipos que son siempre iguales o rotan? Me parece otra cuestión interesante…

]]> Por: Miguel http://www.programania.net/desarrollo-agil/scrum-para-un-equipo-en-multiples-proyectos/comment-page-1/#comment-12409 Miguel Sun, 14 Dec 2008 18:57:35 +0000 http://www.programania.net/?p=395#comment-12409 En mi empresa tenemos exactamente el mismo tipo de situacion, unos 15 tecnicos para 35 proyectos. Llevamos un excel para cada uno de los proyectos con el backlog. Para planificarlo se ponen todas las tareas y segun los recursos se indica un dia de finalización. Cada semana (no cada dia como scrum) se repasa y se ve si se sigue (es ciertamente complicado cuando cada persona tiene minimo 2 proyectos). La fecha de cada sprint es fija, con lo que si a alguna tarea no se llega se saca del sprint y se mete en el siguiente. Es importante añadir las tareas de pruebas y documentación, que siempre se olvidan. El tema de hacer un backlog de diferentes proyectos no lo vemos escalable. Lo que hacemos es otro excel y agregar los sprint de cada proyecto, asi se pueden asigar prioridades entre proyectos facilmente. Saludos! En mi empresa tenemos exactamente el mismo tipo de situacion, unos 15 tecnicos para 35 proyectos. Llevamos un excel para cada uno de los proyectos con el backlog.
Para planificarlo se ponen todas las tareas y segun los recursos se indica un dia de finalización. Cada semana (no cada dia como scrum) se repasa y se ve si se sigue (es ciertamente complicado cuando cada persona tiene minimo 2 proyectos). La fecha de cada sprint es fija, con lo que si a alguna tarea no se llega se saca del sprint y se mete en el siguiente. Es importante añadir las tareas de pruebas y documentación, que siempre se olvidan.

El tema de hacer un backlog de diferentes proyectos no lo vemos escalable. Lo que hacemos es otro excel y agregar los sprint de cada proyecto, asi se pueden asigar prioridades entre proyectos facilmente.

Saludos!

]]> Por: Joserra http://www.programania.net/desarrollo-agil/scrum-para-un-equipo-en-multiples-proyectos/comment-page-1/#comment-12382 Joserra Fri, 12 Dec 2008 12:44:40 +0000 http://www.programania.net/?p=395#comment-12382 Yo soy un fan de JIRA :) así que no me hagas mucho caso. En realidad intentamos llevarlo de manera visible todo en la pizarra, con los míticos post-it. JIRA es el refuerzo para que no se pierda nada, controlar las horas de manera sencilla, mantener comentarios y trazabilidad. Yo soy un fan de JIRA :) así que no me hagas mucho caso.
En realidad intentamos llevarlo de manera visible todo en la pizarra, con los míticos post-it. JIRA es el refuerzo para que no se pierda nada, controlar las horas de manera sencilla, mantener comentarios y trazabilidad.

]]> Por: Luis Artola http://www.programania.net/desarrollo-agil/scrum-para-un-equipo-en-multiples-proyectos/comment-page-1/#comment-12380 Luis Artola Fri, 12 Dec 2008 11:14:07 +0000 http://www.programania.net/?p=395#comment-12380 "la duración de las iteraciones no depende del proyecto" --> touchez. Ahí me has dado... ¡muy bien lo tengo mucho más claro! oye,¿y qué herramienta utilizar para gestionar los backlogs? A mí el excel no me ha funcionado muy bien. Y eso que mucha gente lo usa. Utilizo un wiki sencillito. Tengo entendido que utilizáis Jira, verdad? qué tal la experiencia? “la duración de las iteraciones no depende del proyecto” –> touchez. Ahí me has dado… ¡muy bien lo tengo mucho más claro!

oye,¿y qué herramienta utilizar para gestionar los backlogs? A mí el excel no me ha funcionado muy bien. Y eso que mucha gente lo usa. Utilizo un wiki sencillito. Tengo entendido que utilizáis Jira, verdad? qué tal la experiencia?

]]> Por: Joserra http://www.programania.net/desarrollo-agil/scrum-para-un-equipo-en-multiples-proyectos/comment-page-1/#comment-12379 Joserra Fri, 12 Dec 2008 10:53:11 +0000 http://www.programania.net/?p=395#comment-12379 Jeje, he estado desconectado un día por problemas personales y ya me echan de menos... :D El product backlog, ciertamente se convertiría en un multi-product-backlog. Te da la visión de las prioridades entre proyectos, que es muy interesante, por que solo cabe un camello por la puerta. El sprint lo planificas igual que antes, solo que puede haber historias de usuario o tareas de más de un proyecto. La duración de las iteraciones no depende del proyecto!!! no podrías estar involucrado en iteraciones diferentes al mismo tiempo. Cada iteración haces lo que peudas según la prioridad de los proyectos. Jeje, he estado desconectado un día por problemas personales y ya me echan de menos… :D
El product backlog, ciertamente se convertiría en un multi-product-backlog. Te da la visión de las prioridades entre proyectos, que es muy interesante, por que solo cabe un camello por la puerta.
El sprint lo planificas igual que antes, solo que puede haber historias de usuario o tareas de más de un proyecto. La duración de las iteraciones no depende del proyecto!!! no podrías estar involucrado en iteraciones diferentes al mismo tiempo. Cada iteración haces lo que peudas según la prioridad de los proyectos.

]]>