Equipo con perfiles radicalmente diferenciados

[Carlos :: Runroom ::]

Hola de nuevo!

Nada, como me han gustado tanto vuestras respuestas en el hilo de las estimaciones, me gustaría plantearos un problema que me ronda por la cabeza desde hace unos meses.

Resulta que, como algunos ya habréis leído de forma más extensa en el post de mi blog donde escribo sobre "Scrumban multiproyecto y multiperfil" (disculpad el autolink), mi equipo se compone de 3 perfiles radicalmente diferenciados:

- 7 Programadores

- 2 Diseñadores gráficos

- 2 Marketeros/Contenidos

La cosa es que hasta ahora, las reuniones de planificación de sprint las hacemos con todo el equipo presente en todo momento.

Digo "hasta ahora" porque tenemos la sensación de que a veces para algunos de ellos es un engorro y una pérdida de tiempo asistir a las estimaciones de los demás, porque no se enteran de nada. La intención de hacer que todo el mundo estuviera presente era intentar cohesionar al equipo y que todo el mundo conociese el trabajo del resto, pero creemos que esto ya se consigue con las Demos de producto, retrospectivas y los Daily Scrum, de modo que hemos pensado que sería buena idea citar a la gente por perfil: primero estiman los programadores "sus" historias, luego los diseñadores las suyas, y por último contenidos... y si hay historias compartidas, que también las hay a veces, pues todos juntos. Pero nos encontramos que la mayor parte del tiempo, durante las estimaciones de los programadores se habla de cosas incomprensibles para un perfil no-técnico.

Ya se que esto huele un pelín a waterfall, y que en teoría las Historias de Usuario deberían ser unidades potencialmente entregables y que por tanto cada una de ellas debería tener tareas de diseño + tareas de programación + tareas de contenidos, pero la realidad de nuestro estudio está sujeta a los timings de cada proyecto, en muchas ocasiones impuestos por el cliente.

Nuestros sprints son actualmente de dos semanas. Hay sprints donde la carga de trabajo es sobretodo maquetación CSS, otros donde sobretodo hay "desarrollo", otros diseño... y eso representa otro gran problema: Nuestra Vavg de Scrum son 25 puntos. Es decir, en un sprint ideal, nuestro equipo debería poder hacer 25 Puntos de Historia, pero qué pasa si de esos 25 puntos resulta que 18 son puntos de diseño gráfico? En este sprint nos ha pasado algo parecido y la conclusión a la que hemos llegado es que debemos tener 3 Velocidades Medias: Vavg de Programación, Vavg de Diseño y Vavg de Contenidos...

Porque si no, si nos limitamos a seleccionar los 25 primeros puntos del backlog, el equipo queda totalmente descompensado en cuanto a carga de trabajo.

Mi olfato me dice que esto no es todo lo ágil que debería, pero no se nos ocurre una solución mejor.

Qué pensáis? Xavi Gost, tienes permiso para insultarme!!!  LOL

c

--

Carlos Iglesias

Runroom

Milà i Fontanals

14·26, 2º 3ª

08012 Barcelona

t 934 590 445

f 932 082 962

www.runroom.com

“En cumplimiento de la Ley Orgánica de Protección de Datos de Carácter Personal (LOPD) le informamos de que sus datos de contacto son incorporados en ficheros titularidad de Runroom Producción Multimedia, S.L. que responden a la finalidad de servir de directorio de contactos, el envío de informaciones relacionadas con nuestra actividad, así como facilitar la gestión administrativa y comercial desarrollada por la empresa. El titular de los datos autoriza de forma específica que sus datos puedan ser accedidos por las siguientes empresas de hosting sitas en EE.UU.: DreamHost WebHosting (PMB # 257, 417 Associated Rd., Brea, CA 92821), y Google Inc. (1600 Amphitheatre Parkway, Mountain View, CA 94043).

Para ejercitar los derechos de acceso, rectificación, cancelación y oposición previstos en la ley puede dirigirse mediante comunicación escrita a Runroom, Ref. Protección de datos, C/ Milà i Fontanals, 14-16, 2º 3ª, 08012 Barcelona.”

[Juan Carlos Quijano Abad]

Buenas,

 

No te puedo hablar de primera mano porque no he tenido aún no he tenido la experiencia. Lo que puedo compartir es mi situación habitual.

 

Somos un "core" de desarrolladores y tenemos orbitando servicios de diseño gráfico y de sistemas. Si bien estos perfiles no son parte del equipo ya que no están en ninguna de las reuniones scrum, si lo són ya que los tenemos informados y con acceso a la aplicación en todo momento.

 

Así cuando le pedimos cosas, no le suena a cuento chino y pueden tener un concepto, vago eso sí, del contexto por el que se le solicitan los servicios.

 

Sobre la sensación de inutilidad, creo que es un impedimento que vas a tener que corregir. Se supone que todo el mundo es parte del equipo, por lo cual esas reuniones le deben interesar a todos. Si bien las estimaciones de desarrollo las liderará el equipo de desarrollo y las de diseño gráfico los diseñadores. No le vendrá mal a nadie y a todos le beneficie aunque se escape de vez en cuando algún bostezo.

 

A las retrospectivas si que es obligadísimo que todos vayan y aporten. Pero seguro que esto tu también lo piensas.

 

Hay un artículo de Rodrigo muy bueno de una empresa que tenía tres lineas en en sprint backlog, me recordó mucho tu situación ;)

--

Un saludo

Juan Quijano

 

Blog de .Net y Gestión de proyectos

Blog de opinión social

Blog de World of Warcraft

Blog de Tiro con Arco

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

[Enrique Amodeo]

Hola, efectivamente no es todo lo ágil que podría ser, lo ideal es que
el equipo fuera multidisciplinar y que todos supieran de todo. Ahora
bien, la realidad indica que una persona que sabe de programación no
suele poder aprender diseño gráfico y viceversa. Al tener
especialistas la cosa tiene que ser un poco waterfall, ya que a veces
unos no pueden empezar hasta que tengan el trabajo de otro. Salvo por
algunas personas muy especiales, esto no es posible. Sin embargo no
hay que ser teórico y podemos llegar a un termino medio.

En principio puedes seguir entregando y planificando historias de
usuario, para ello puedes dividir el sprint planning en tres fases. En
la primera haces la descomposición en tareas, con todo el equipo
junto. En la segunda separas a cada equipo de especialistas y les
haces estimar sus tareas, así no perderán el tiempo ni se aburrirán
estimando tareas que no entienden. Finalmente sumas cada tarea para
saber el tamaño total de la historia. El resto es igual que antes,
sobre todo si no hay mucha interdependencia entre los equipos y puedes
trabajar más o menos en paralelo. Si tienes mucha interdependencia
entonces puede ser más problemático

Otra opción, sobre todo si no puedes paralelizar tareas de diseño,
marketing y programación, es olvidarte de Scrum y pasar a hacer un
Kanban puro con historias de usuario. Cada grupo de especialistas
tiene sus propias columnas, y las historias van fluyendo de una
columna a la siguiente. Las historias pasan de un equipo a otro si
pasan de una columna de un equipo a otra columna de otro equipo. Por
cada columna necesitas una definición precisa de hecho (definition of
done), especialmente en las columnas donde el trabajo se pasa a otro
equipo. Después es cuestión de ir probando a ajustar el WIP máximo,
con prueba y error, y a ver si varias columnas pueden compartir WIP,
para minimizar el tiempo de entrega. Ej. de columnas: Para hacer ->
Diseño gráfico -> Aceptación Diseño -> Programación -> Aceptación
Programación -> Hecho

Estoy suponiendo que el diseño tiene que completarse antes de empezar
a programar. Puedes experimentar a ver si realmente puedes tener algún
tipo de paralelismo.

El usar Kanban no excluye que tengas una demo cada dos semanas, hagas
un daily meeting o cada dos semanas una retrospectiva.
Nunca pierdas de vista los siguiente:
a) Equipo autoorganizado. Si una forma de organizarte no funciona,
busca soluciones con tu equipo (pero no sin él)
b) Básate en prueba y error. No te olvides de las retrospectivas para
buscar soluciones a problemas y mejoras.
c) Feedback del cliente. Por ello no debes olvidar hacer demos cada
dos semanas, o mejor aun, cada vez que una historia esté completa. Es
imprescindible que entregues historias y no "tareas" o "artefactos",
sino el cliente no podrá valorarlo.
El que te termine saliendo un waterfall da más o menos igual, sobre
todo si el trabajo se va sacando de forma eficaz.
Salud !
2011/1/31 Carlos :: Runroom :: <car...@runroom.com>:

[Alberto Peña]

¡Buenas!

Un par de preguntas ¿Cuando el sprint es más de diseño gráfico que hacen los programadores? ¿Os habéis planteado pair programming interdisciplinar (programador-diseñador, maquetador-programador, contenidos-diseñador?

Ahora mi opinión :P Si las historias no dependen entre sí entonces tienes 3 equipos. Si no son independientes (y me imagino que no lo serán) realmente solo necesitas la velocidad más baja de las tres. Es decir, si los programadores son capaces de "terminar" 7 cosas, los diseñadores acaban 2 y los de contenidos 4, la velocidad del equipo es 2 (si las historias están relacionadas) Esto lo puedes salvar haciendo que "los equipos" trabajen en historias no relacionadas cuando les sobre tiempo, pero guiar un producto/proyecto por eso en lugar de por prioridad me parece un error.

Sinceramente, no tengo ni idea (ni experiencia) de decirte como arreglarlo, pero sí que me parece que algo huele mal (aunque a ti te pasa lo mismo, por eso el post :D ). En fin, que creo que no te ayudo mucho. Lo siento :S

Un saludo

2011/1/31 Carlos :: Runroom :: <car...@runroom.com>

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--
Alberto Peña Abril

http://twitter.com/plagelao
http://plagelao.blogspot.com/

[José Manuel Beas]

Hola,

Pues justamente vengo de una reunión donde hemos estado tratando de averiguar en qué consiste una funcionalidad (para poderla planificar) y, casualmente, nuestro equipo es multidisciplinar: unos cuantos de host y otros cuantos de java. :-)

Y aunque ha sido una reunión carísima (10 personas casi 3 horas) al menos ha servido para:

a) particionar la funcionalidad en algo más parecido a historias de usuario, que nos permiten terminarlas en menos de una semana y en las que participan indistintamente gente de host y de java, a veces incluso en tareas compartidas (aún muy pocas para mi gusto)

b) que todo el equipo comparta una visión común de lo que hay que hacer, de cuáles son las dudas, de cuáles son las suposiciones y de cuál es el propósito de lo que luego hará

En resumen, que lo malo son los "especialistas" pero no los perfiles especializados. Los primeros son imprescindibles y provocan cuellos de botella y otras disfunciones. Los segundos son la vida misma: no podemos saber de todo. Lo que tenemos que hacer es un esfuerzo ¿extra? para diseccionar nuestras historias de usuario y no dividirlas por "sectores productivos" ni tecnologías sino por valor aportado, por definición de hecho: ¿cómo se comprueba esta funcionalidad entregada?

Un cordial saludo,

José Manuel Beas

[German DZ]

Sin entrar mucho en el tema especialistas vs generalistas; lo que seguro que no es bueno es aislarse. Si tienes(*1) una iteración donde los que saben más de diseño tienen más trabajo que los que saben más de programar; si estos últimos no tienen nada mejor que hacer sería muy enriquecedor que se pongan al lado de los que harán el diseño. El feedback temprano se agradecerá.

Un tema muy importante para los equipos es que esté muy claro cual es el "pipeline" de producción. Tener claro los ritmos, a quien pedirle cosas, a quien ayudar en cada momento, todo para lograr el ritmo sostenible y evitar un "es que no lo supimos hasta el último día".

PD: Yo soy horrible diseñando, pero desde el 2000 que comencé a trabajar con muchos diseñadores, aprendí mucho de ellos. Si bien no puedo ejecutar sus trabajos, sí los entiendo y eso me ayuda a comunicarme mejor.

(*1) JMB: con un poco de esfuerzo logro escribir "tienes" y no "tenés", pero para el plural de la 2da persona se me complica más, y realmente a veces me siento ridículo (e ignorante, porque muchos verbos no los se conjugar correctamente).

2011/1/31 José Manuel Beas <jose....@gmail.com>

[jcesarperez]

Parece que tienes:

* varios proyectos y un solo equipo
* equipo no multidisciplinar

¿Y por qué dices que no es nada ágil? No estoy de acuerdo. Al menos
tal y como lo cuentas, trabajas con iteraciones, seleccionais
historias en base a su valor, hacéis demos, hacéis reuniones juntos,
hacéis equipo y estáis en pleno proceso de mejora contínua! Ya
quisieran muchos...

Yo no me obsesionaría con hacer Scrum al 100%. Coge lo que más os
sirva o lo que mejor os funcione y experimenta con algunos cambios.
Yo seguiría con algo más parecido a Scrum que Kanban por eso que dices
de los timings de los proyectos. Las iteraciones cortas y las demos
ayudan a estar muy centrados, llevar un ritmo saludable y tener los
objetivos muy presentes. Por lo que comentas parece además que os
funciona relativamente bien.

¿Qué cambios puedes hacer a Scrum?
Yo probaría con no obsesionarme con llenar el sprint de la forma más
eficiente posible. Llénalo con historias de sobra y que no te importe
hacer sprints incompletos. Las historias incompletas las mueves al
siguiente spring y punto. ¿Qué drama hay en eso?
También puedes poner una duración máxima para realizar la estimación
de una historia. No es nada bueno obsesionarse con las estimaciones.
De hecho si lo he entendido bien, el proyecto ya está vendido, por lo
que la estimación sólo la hacéis para saber cuantas historias meter en
un sprint. ¿Qué importa que te sobren 2 historias que 6? ¿Tan
importante es la métrica de velocidad?
Y como tu mismo dices, puedes probar a hacer reuniones distintas para
cada perfil. Que eso no es nada Scrum. Sí, ok, ¿pero si os funciona
que tiene de malo?

En definitiva, experimenta. Que no lo digo yo, lo dice el propio
Henrik Kniberg :-)

Saludos,
Julio.