Comenzando con Scrum

50 views
Skip to first unread message

Micho Gar

unread,
Jun 24, 2009, 5:50:48 AM6/24/09
to agile...@googlegroups.com
Hola a todos,

estamos comenzando en mi empresa a utilizar Scrum. Me imagino que como todas tenemos unas particularidades que pensamos nos hacen diferentes, pero que al final seran iguales. Somos una consultoria, trabajamos a la vez en varios proyectos, las personas ocupan diferentes equipos para diferentes proyectos, y actualmente vivimos de la producción heroica, con lo que ello significa para los equipos.

El afán de organización ha surgido de los mismos equipos, por lo que podriamos decir se trata de un proceso de abajo para arriba, nuestros directivos están de acuerdo, pero no se como se actuará a la hora de tratar con el cliente, veremos.

Estamos siguiendo algo de literatura (Flexibilidad con Scrum, Scrum desde las Trincheras...), y teniamos pensado ir echandole un vistazo a Xplanner, os iremos contando.

Genial la charla de Angel Medinilla sobre contratos Ágiles que hico la gente de Autentia, es un crack!!, y muy buena iniciativa, repetiré.

Cualquier consejo será bienvenido.

Saludos a todos y gracias.

--
# michogar
# Analista Programador SIG
# GNU/Linux Counter 462666

Una visión personal:
http://michogar.blogspot.com

El día a día:
http://twitter.com/michogar


Rodrigo Corral González

unread,
Jun 24, 2009, 6:12:55 AM6/24/09
to agile...@googlegroups.com
Hola Micho:
 
La situación de partida en la que te encuentras es la más compleja que se da. En empresas como la tuya, la gran dificultad pasa por encontrar que es un equipo para vosotros, en primer lugar, y en segundo lugar definir cuantos product backlogs vais a manejar.
 
Para hacer esto, no hay una receta universal. Depende mucho de la cultura y organización actual de la empresa. Pero es la clave. Pensad que ahora solo existen individuos y tenéis que para de esa situación a una en la que el trabajo de reparta entre equipos, no entre individuos. Es es la gran dificultad.
 
El principal problema que tenéis ahora es el tiempo que se os va en cambios de contexto. Probablemente estéis en la típica situación de prioridades difusas, de entender a los fuegos, al cliente que más grita... el antídoto para eso es Scrum y su modelo de equipos. Por ahí empezaría yo.
 
Esa definición de equipos se puede hace atendiendo a numerosos factores y es particular de cada caso, muchas veces no resulta evidente, pero es vital hacerlo bien. Podemos particionar los equipos por numerosos criterios: tecnología, cliente al que se dedican, proyecto (la más evidente)... Lo vital, en mi opinión, es que esas particiones sean verdaderas particiones, que no existan individuos que están en n equipos a la vez.
 
Yo suelo analizar las particiones que me salen según las leyes de las particiones de Roger S. Sessions, y da buen resultado:
 
1ª Ley: Las particiones deben ser verdaderas particiones.
2ª Ley: Las particiones deben ser adecuadas al problema.
3ª Ley: El número de subconjuntos en una partición debe ser adecuado.
4ª Ley: El tamaño de las particiones debe ser aproximadamente igual.
5ª Ley: Las interacciones entre subconjuntos deben ser mínimas y bien definidas.
 
Si lográis hacer bien eso, habréis dado un gran paso. Luego, a la hora de determinar el número de backlogs, el enfoque más simple es un equipo, un backlog, un product owner. Anque no siempre es posible, es el enfoque más simple y el que siempre se debe perseguir.
 
El enfoque más simplista de Scrum persigue un proyecto, un backlog, un equipo. Pero esto no siempre es posible en consultoras donde lo que hay son muchos proyectos pequeños que gestionar como un todo más que algunos proyectos grandes que respondan al modelo simple de Scrum.
 
!Un saludo¡

Rodrigo Corral González

Software Architect


C\ Sebastián Elcano 32 , - Madrid (Spain)

Email: rco...@plainconcepts.com Mobile: +34 (686) 754 328 Blog: http://geeks.ms/blogs/rcorral/

Note: The information contained in this message may be confidential information subject to the terms and conditions of a confidentiality agreement between Plain Concepts and you or your employer. You are not permitted to disclose or publish confidential information. In addition, if you have received this message in error (i) please notify us immediately by return message, and (ii) any use or distribution of this information is prohibited.

P Please consider the environment before printing this email.

Disclaimer added by CodeTwo Exchange Rules
www.codetwo.com


From: agile...@googlegroups.com [agile...@googlegroups.com] On Behalf Of Micho Gar [mich...@gmail.com]
Sent: Wednesday, June 24, 2009 11:50
To: agile...@googlegroups.com
Subject: [agile-spain] Comenzando con Scrum

Xavier Quesada Allue

unread,
Jun 24, 2009, 6:30:58 AM6/24/09
to agile...@googlegroups.com
Excelente respuesta, Rodrigo. +1

2009/6/24 Rodrigo Corral González <rco...@plainconcepts.com>



--
Xavier Quesada Allue
Visual Management Blog
http://www.xqa.com.ar/visualmanagement

elmenda...@gmail.com

unread,
Jun 24, 2009, 1:27:49 PM6/24/09
to agile-spain
Nivelazo de respuesta si señor. Mi caso es exactamente el mismo, y
desde la perspectiva de personas que, aunque tienen buena voluntad,
no sabemos nada de scrum...hemos pedido ayuda a profesionales!!

On 24 jun, 12:12, Rodrigo Corral González <rcor...@plainconcepts.com>
wrote:
> Hola Micho:
>
> La situación de partida en la que te encuentras es la más compleja que se da. En empresas como la tuya, la gran dificultad pasa por encontrar que es un equipo para vosotros, en primer lugar, y en segundo lugar definir cuantos product backlogs vais a manejar.
>
> Para hacer esto, no hay una receta universal. Depende mucho de la cultura y organización actual de la empresa. Pero es la clave. Pensad que ahora solo existen individuos y tenéis que para de esa situación a una en la que el trabajo de reparta entre equipos, no entre individuos. Es es la gran dificultad.
>
> El principal problema que tenéis ahora es el tiempo que se os va en cambios de contexto. Probablemente estéis en la típica situación de prioridades difusas, de entender a los fuegos, al cliente que más grita... el antídoto para eso es Scrum y su modelo de equipos. Por ahí empezaría yo.
>
> Esa definición de equipos se puede hace atendiendo a numerosos factores y es particular de cada caso, muchas veces no resulta evidente, pero es vital hacerlo bien. Podemos particionar los equipos por numerosos criterios: tecnología, cliente al que se dedican, proyecto (la más evidente)... Lo vital, en mi opinión, es que esas particiones sean verdaderas particiones, que no existan individuos que están en n equipos a la vez.
>
> Yo suelo analizar las particiones que me salen según las leyes de las particiones de Roger S. Sessions, y da buen resultado:
>
> 1ª Ley: Las particiones deben ser verdaderas particiones.
> 2ª Ley: Las particiones deben ser adecuadas al problema.
> 3ª Ley: El número de subconjuntos en una partición debe ser adecuado.
> 4ª Ley: El tamaño de las particiones debe ser aproximadamente igual.
> 5ª Ley: Las interacciones entre subconjuntos deben ser mínimas y bien definidas.
>
> Si lográis hacer bien eso, habréis dado un gran paso. Luego, a la hora de determinar el número de backlogs, el enfoque más simple es un equipo, un backlog, un product owner. Anque no siempre es posible, es el enfoque más simple y el que siempre se debe perseguir.
>
> El enfoque más simplista de Scrum persigue un proyecto, un backlog, un equipo. Pero esto no siempre es posible en consultoras donde lo que hay son muchos proyectos pequeños que gestionar como un todo más que algunos proyectos grandes que respondan al modelo simple de Scrum.
>
> !Un saludo¡
>
> Rodrigo Corral González
>
> Software Architect
>
> C\ Sebastián Elcano 32 , - Madrid (Spain)
>
> Email: rcor...@plainconcepts.com <mailto:rcor...@plainconcepts.com> Mobile: +34 (686) 754 328 Blog:http://geeks.ms/blogs/rcorral/
> ________________________________
>
> Note: The information contained in this message may be confidential information subject to the terms and conditions of a confidentiality agreement between Plain Concepts and you or your employer. You are not permitted to disclose or publish confidential information. In addition, if you have received this message in error (i) please notify us immediately by return message, and (ii) any use or distribution of this information is prohibited.
>
> P Please consider the environment before printing this email.
>
> Disclaimer added by CodeTwo Exchange Ruleswww.codetwo.com<http://www.codetwo.com>
>
> ________________________________
> From: agile...@googlegroups.com [agile...@googlegroups.com] On Behalf Of Micho Gar [micho...@gmail.com]

Joserra

unread,
Jun 24, 2009, 4:59:17 PM6/24/09
to agile-spain
Ciertamente las recomendaciones de Rodrigo son acertadas. Nosotros
empezamos hace un año en la misma situación, y sin duda que el primer
problema es el de los equipos fijos. Así que suerte!

On Jun 24, 7:27 pm, "elmendalere...@gmail.com"

José Manuel Beas

unread,
Jun 24, 2009, 5:35:10 PM6/24/09
to agile...@googlegroups.com
Me interesa mucho esto que decís de los equipos, pero no entiendo muy bien lo que explica Rodrigo. :-(

Quiero decir, entiendo que lo ideal es que los equipos sean lo más estancos posibles (aunque no estoy seguro de porqué, intuyo que es porque así se evitan interrupciones y tiempos muertos en un equipo esperando al "recurso compartido"), pero la tozuda realidad es que los "recursos compartidos" EXISTEN.

Mi duda va en este sentido. ¿Qué hacemos si tenemos "recursos compartidos"? Se me ocurre que sean "exclusivos" de un equipo durante un sprint y de otro equipo en el sprint siguiente, p.ej. pero intuyo que esto no es la solución, sobre todo si hablamos de desarrollos iterativos e incrementales (el especialista será necesario en casi todos los sprints).

Si no se entiende bien mi pregunta no dudéis en recriminarmelo. :-)

Un saludo,
Jose Manuel Beas

http://www.agile-spain.com
http://jmbeas.blogspot.com



2009/6/24 Joserra <jrr...@gmail.com>

Martin Perez

unread,
Jun 25, 2009, 2:30:58 AM6/25/09
to agile...@googlegroups.com
En mi última empresa sí que teníamos individuos compartidos.

En nuestro caso:

- Quienquiera que estuviese compartido acudía a ambos sprints a no ser que sus tareas ya estuviesen terminadas.
- Normalmente la división no era 50/50 si no que se necesitaba a esa persona para unas tareas muy concretas. Así que solía ser más 90/10 o 80/20
- Las tareas del individuo compartido son muy concretas y están muy delimitadas. A todos los efectos se podrían hacer en otro Sprint pero simplemente se compartía la persona para que ésta no perdiese contexto de lo que está pasando en su otro Sprint.

Nunca tuvimos ningún problema especial con este planteamiento. De hecho era común que si un Sprint resultaba muy ligero, que se moviera alguna gente a algún otro equipo durante unos días para echar una mano.

Saludos,
Martín

2009/6/24 José Manuel Beas <jose....@gmail.com>



--
Martín Pérez

Founder,
http://www.jobsket.com

German DZ

unread,
Jun 25, 2009, 3:06:16 AM6/25/09
to agile...@googlegroups.com
Respecto a las personas compartidas, no digamos recursos, ya que el hardware es un recurso y eso en gral no se comparte, las herramientas tampoco, y sobre todo porque las PERSONAS son más importantes que los RECURSOS (lo leí por algún lado!). :)

Un par de reglas que puedo resumir luego de algunos años de experiencia:

- Compartir perfiles Jr (desde el punto de vista de la falta de autogestión) no es buena idea, ya que es mucha presión para la persona y mucho riesgo para el equipo
- Compartir perfiles Sr es muy valioso para el equipo, porque le aporta confianza el saber que cuenta con el apoyo de un especialista para ayudarlos a cumplir sus objetivos de iteración.
- Compartir Staff (diseñadores gráficos, admins de sistemas, testers), es válido, pero no se recomienda colocarlos en el camino crítico (si se acepta el término) de las tareas y de todos modos es preferible que su participación sea con un compromiso por cantidad de tiempo de dedicación diaria/semanal y que el líder del equipo haga un acompañamiento para asegurar que no hay impedimentos. Estos perfiles no tendrán un 100% de compromiso y sentido de pertenencia a un equipo, sobre todo si en el otro equipo las cosas funcionan mejor, no afectará al proyecto bueno por salvar el que está con inconvenientes.



2009/6/25 Martin Perez <mpe...@gmail.com>

Micho Gar

unread,
Jun 25, 2009, 3:24:32 AM6/25/09
to agile...@googlegroups.com
Muchas gracias a todos por las respuestas. En principio creo que generar equipos estancos de momento nos va a ser complicado, estamos demasiado imbricados, pero si creemos también que seria necesario. Hemos planteado de momento definir los proyectos y utilizar estos como unidad, aunque los equipos se intercambien. Creemos que tiene que ser algo así como estar en sprints diferentes, lo que no sabemos si será muy factible.

Otra duda que nos surge, es el tema del teletrabajo. No llevo mucho en la lista, y no se si se ha discutido antes. Por lo que he leido, se habla de la necesidad de la presencia en el equipo para desarrollar con SCRUM, pero nosotros, bueno, personalmente yo, creo que la opción del teletrabajo tiene que ser viable en nuestras empresas en los tiempos que corren.

Saludos, gracias y espero no ser muy pesado.

Daniel Alonso

unread,
Jun 25, 2009, 3:25:31 AM6/25/09
to agile...@googlegroups.com
Mis impresiones :)

Dejando a un lado la discusion sobre un buen Product owner y centrandonos en el equipo, considero muy importante la estabilidad en los equipos, comprobando que la presencia en dos equipos puede llevar (puede) a la no implicación en ninguno de ellos en el mismo grado que el resto del los que están en él.

Por otro lado, la distribución de perfiles Sr y perfiles Jr. considero que debe estar muy claramente distribuida, de manera que los Jr vayan evolucionando y puedan compartir la responsabilidad con los Sr, aparte de que puedan los Jr sentir claramente la multipropiedad del código (esto ultimo tambien se puede llegar a perder en el caso de personas ,yo odio llamar a las personas "recursos", no estables en un equipo y con una alta dedicación.

Claro que esto es la idealidad....


German DZ escribió:

Vicenç Garcia

unread,
Jun 25, 2009, 3:34:45 AM6/25/09
to agile...@googlegroups.com
Hola Micho,

acabo de pasar dos meses trabajando en un proyecto en Argentina, así que he hecho algo parecido a teletrabajo, o por lo menos a trabajo no presencial con el resto del grupo.

Separaria los problemas que nos hemos encontrado en dos partes: puramente metodológicos y problemas técnicos ( o de buenas prácticas de programación, vamos ).

En la parte de los metodológicos nosotros lo que hemos hecho ( ya que nuestro TFS no tiene salida a Internet ) es mantener una hoja de cálculo de google docs compartida entre los miembros del equipo que hacia de product backlog, donde se ponian las histórias de usuario priorizadas y se iba actualizando el estado de las tareas. Cabe decir que hemos hecho más Kanban que no Scrum, pero la idea és más o menos la misma. Las daily meetings los haciamos mayoritariamente por mail, aunque acabamos por hacerlos por telefono pq nos aclarábamos mucho más. Esta parte fué bastante bien y estoy bastante orgulloso de cómo lo hicimos ahún con los problemas que dá la diferencia horaria.

La parte que tubimos más problemas fué con el código. El hecho de tener el código tanto en barcelona como en buenos aires en el mismo estado al final del dia fué complicado ya que tanto yo cómo desde barcelona se iban tocando cosas. Al final nos pasábamos por mail los cambios que habíamos hecho y los dos equipos los incorporaban. Con un poco de esfuerzo y dedicación la cosa acaba saliendo pero he de reconocer que fué lo que llevamos peor. Por suerte no perdimos nada de código ni nos pasó ninguna desgracia.

Espero que te haya servido de algo.

Saludos,

2009/6/25 Micho Gar <mich...@gmail.com>



--
Vicenç García
http://devnettips.blogspot.com

German DZ

unread,
Jun 25, 2009, 3:42:35 AM6/25/09
to agile...@googlegroups.com
Sin querer confundir o incrementar el nivel de duda ¿por qué SCRUM y no Kanban? Si no puedes tener los equipos estancos, estimo que tampoco les será fácil tener iteraciones largas debido a urgencias.

Empezar con Kanban, aprovechar el tiempo para ir aprendiendo sobre el tiempo de respuesta, organizar el SCM, tener buenos Builds, etc. una vez que eso esté estabilizado, tratar de comprometer a un equipo con un proyecto a realizarlo en forma de SCRUM.



2009/6/25 Micho Gar <mich...@gmail.com>

Xavier Quesada Allue

unread,
Jun 25, 2009, 4:09:14 AM6/25/09
to agile...@googlegroups.com
German,

Que significaría (para vos) empezar con kanban, exactamente? Cuáles serían los primeros pasos que tomarías?

Saludos,
Xavier

2009/6/25 German DZ <ge...@ndz.com.ar>

German DZ

unread,
Jun 25, 2009, 4:27:21 AM6/25/09
to agile...@googlegroups.com
Los primeros pasos respecto a Kanban serían:

- Identificar Tareas
- Estimar
- Priorizar
- Medir velocidad
- Ejercitar el ritmo de tomar una tarea, resolverla, verificarla y declararla Done!
- Mantener la pizarra en buena salud (que refleje la realidad) [Aquí XQA es el experto]

Todos esos pasos son igual de necesarios en Scrum, pero si no pueden armar equipos dedicados y tener iteraciones fijas con claridad va a ser difícil llevar Scrum.

Al mismo tiempo, ir ajustando los procesos de Build, teniendo buenas verificaciones, agregar Unit Test donde valga la pena, etc.

No es muy ortodoxo mi planteo, pero soy más de la idea de pasitos de bebé antes que grandes movimientos revolucionarios. Si se gana confianza y esa gimnasia hace que luego todo lo mencionado arriba sea algo natural será más fácil incorporar otros conceptos que se basan en éstos.

Parece muy simplista o poco desafiante mi planteo? Ultimamente veo que comenzar con el agilismo resulta en una cantidad enorme de cosas nuevas para un equipo y me parece que eso no es muy bueno. Casi que la cantidad de cosas que se le piden a un equipo que quiere hacer Scrum es igual a las que se piden para hacer RUP! ¿exagero o estoy subestimando a la gente?


2009/6/25 Xavier Quesada Allue <xav...@xqa.com.ar>

Juan Fernández

unread,
Jun 25, 2009, 4:32:06 AM6/25/09
to agile...@googlegroups.com
Hola Germán

¿Existe algún tipo de documentación sobre Kanban que me puedas recomendar? Estoy intentando que en mi empresa se acabe implantando Scrum, pero quizás veo mejor utilizar una metodología que nos permita hacer la transición de forma más pausada, y por lo que veo, estos pasos me vienen como anillo al dedo.

Actualmente somos cuatro desarrolladores y tenemos que llevar y mantener por lo menos 20 proyectos, o sea, que imagínate el caos que tenemos montado.

Gracias !


2009/6/25 German DZ <ge...@ndz.com.ar>

Xavier Quesada Allue

unread,
Jun 25, 2009, 4:35:11 AM6/25/09
to agile...@googlegroups.com
Me parece perfecto lo que plantéas. Mi pregunta iba orientada a ayudarte a ayudar. Decir "te conviene empezar con kanban" probablemente ayude poco al lector, en cambio este checklist es mucho más concreto y útil.

Despues podemos entrar en discusión si esto es lo que en kanbandev llaman "kanban" o no... pero esa es otra historia (y una muy aburrida, por cierto).

En lo personal, yo creo que siempre es posible identificar un Product Owner. Quien define las tareas? De donde vienen? Surgen por generación espontánea? Creo que siempre es recomendable empezar por identificar un PO (o crear un Proxy PO de no existir uno) y definir un backlog que no es más que los primeros 3 pasos que citás.

Rodrigo Corral González

unread,
Jun 25, 2009, 5:02:02 AM6/25/09
to agile...@googlegroups.com
Hola José Manuel:
 
Efectivamente el problema de compartir gente es que la gente compartida siempre va a tener cambios de contexto. Los cambios de contexto se comen el tiempo productivo de la gente sin 'quemar backlog' es puro desperdicio y es inevitable. En mi experiencia solo si la gente sabe en que equipo esta se evita esta situación y la gente se mantiene enfocada en los objetivos del sprint establecidos para el equipo en cuestión.
 
En mi opinión compartir personas entre equipos es una situación a evitar. En situaciones en las que esto parece inevitable por ejemplo diseñadores, especialista en base de datos, gente de experiencia de usuario etc... lo que suelo hacer es crear un equipo con estos y que manejen un backlog propio, aunque siempre intento que los equipos estén balanceados y que no dependan de 'expertos' externos al equipo. Inevitablemente este backlog tiene intersecciones con los backlog del los equipos, y esto es algo que se gestiona día a día. Funciona razonablemente bien y evito en síndrome de crisis de identidad (¿a que equipo quiero más a papa o a mama? ;) que se da cuando alguien esté en dos equipo y sobre todo evito también el que haya gente que tenga que acudir a varios Daily Scrum. Ir a varios daily es como ir a uno de más de 15 minutos. Que la gente vaya a más de un daily y a mi me parece una forma sutil de saltarse las reglas de Scrum. También creo que  la crisis de identidad se da si andas moviendo gente entre equipos de un sprint a otro... si los equipos no son estables, es imposible que mejoren como equipo y que se den las sinergias e identidad propias de un equipo (si queréis profundizar en esto, Peopleware es la mejor referencia sobre el tema).
 
Te todas formas, insisto, no hay reglas claras, más allá de no saltarse las de Scrum y usar el sentido común (en su versión Scrum de visibilidad, inspección y adaptación).
 
¡Un saludo!
 

Rodrigo Corral González

Software Architect


C\ Sebastián Elcano 32 , - Madrid (Spain)


Note: The information contained in this message may be confidential information subject to the terms and conditions of a confidentiality agreement between Plain Concepts and you or your employer. You are not permitted to disclose or publish confidential information. In addition, if you have received this message in error (i) please notify us immediately by return message, and (ii) any use or distribution of this information is prohibited.

P Please consider the environment before printing this email.

Disclaimer added by CodeTwo Exchange Rules
www.codetwo.com


From: agile...@googlegroups.com [agile...@googlegroups.com] On Behalf Of José Manuel Beas [jose....@gmail.com]
Sent: Wednesday, June 24, 2009 23:35
To: agile...@googlegroups.com
Subject: [agile-spain] Re: Comenzando con Scrum

German DZ

unread,
Jun 25, 2009, 5:05:41 AM6/25/09
to agile...@googlegroups.com
Gracias, siempre ayudan las revisiones y mejoras. No me animé a explicar mucho más justamente por lo que decía de no confundir, pero si ayuda a otros, excelente.

De acuerdo, no creo que sea kanban con todas las letras y si es aburrido, con Scrum es similar. Pero es una licencia que podemos tomarnos para poder tener un comienzo simple y luego que sea incremental.

Lo del PO, sin dudas es importantísimo y en en gral un proxy puede ser más viable. Alguien que asuma responsabilidad y de respuestas en forma unificada. Esto es deformación personal mía, que siempre creo que existe alguien así. Y si, lograr el backlog es un objetivo importantísimo, pero veo mucha tendencia a la documentitis del backlog más que al ejercicio de pensar sobre su contenido y los pasos para hacerlo.

Off-topic/privado: Seguís por Bélgica? Vas a estar por Madrid en algún momento? nos vimos en el Open de Buenos Aires y estaría buenísimo que estés en algún Agile Madrid.

Jorge Uriarte Aretxaga

unread,
Jun 25, 2009, 5:19:35 AM6/25/09
to agile...@googlegroups.com
Dando la razon a Rodrigo, me gustaria hacer una reflexion sobre este
(habitual) debate sobre la dedicacion exclusiva o no, y sobre otros
"impedimentos" a la aplicacion de Scrum/Agile.

Lo mismo que promulgamos tener una vision de hacia donde va el
proyecto, tanto funcional como arquitectonicamente, pero evitamos
intentar cerrar la definicion demasiado pronto (ni funcional ni
tecnicamente), igual tenemos que plantearnos adopciones y mejoras
metodologicas.
Veamos el camino general, veamos hacia donde queremos llegar, y no
crucemos puentes que probablemente no sean tales cuando lleguemos, o
hayan cambiado de lugar.

El uso de recursos compartidos no suele ser el principal problema,
aunque sea habitual. El trabajo simultaneo en varios proyectos si lo
es, aunque casi siempre tenemos una asignacion *principal* (a ESTE
equipo PERTENEZCO ahora), y otras *en mantenimiento*. En ese caso, yo
opto por reservar una pequeña cuota de dedicacion por parte de los
miembros del equipo a sus tareas de mantenimiento, asumiendo que su
velocidad teorica plena en el Scrum se reduce.
Si en un momento dado surge un fuego que exige mas dedicacion, se
gestiona, igual que se gestionan las enfermedades, las rotaciones, los
fallos de especificacion, los fallos de implementacion (a veces
fallamos!), etc...

Intentar tener la receta final de la adopcion agil pre-escrita va
contra los propios principios ;) (a la hoguera! a la hoguera!)


_
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte



2009/6/25 Rodrigo Corral González <rco...@plainconcepts.com>:

MONICA IZQUIERDO BRIONES

unread,
Jun 25, 2009, 5:21:04 AM6/25/09
to agile...@googlegroups.com

Estoy totalmente de acuerdo con Rodrigo.  Tener la gente dedicada a tiempo parcial en un proyecto casi nunca funciona y desde mi punto de vista hace difícil que esa persona se comprometa  al 100% con el objetivo de cada uno de los sprints en los que trabaja.

 

Estoy también de acuerdo en que hay determinados recursos, en nuestro caso principalmente diseñadores y gente de experiencia de usuario que no siempre es posible que estén al 100% en un proyecto.  En nuestro caso porque no siempre hay tareas dentro de un sprint como para que esas personas dediquen el 100% de su tiempo, y la verdad es que gestionar eso no es sencillo.  Rodrigo, cuando hablas de un product backlog independiente, ¿qué quieres decir exactamente?  ¿Los ítems de ese product backlog son una recopilación de todas las tareas que esos equipos tienen en los distintos sprints?, ¿cómo se gestionan estos equipos? Veo complicado que puedan trabajar por sprints también, porque los sprints en los que estén involucrados tendrán distintas fechas de inicio y fin, y al no estar sincronizados, no veo muy claro como gestionan su PB.

 

Saludos!

 

 

 

 

Rodrigo Corral González

unread,
Jun 25, 2009, 5:30:17 AM6/25/09
to agile...@googlegroups.com
Vicenç con lo fácil es que poner el TFS en 'modo WLAN' y accederlo desde cualquier parte del mundo...!!!!
Seguro que la burocracia de sistemas/IT es la que lo hizo imposible...
 
Con lo que mola acceder a toda la información de tu proyecto (fuentes, informes, información de gestión) desde el otro lado del charco... :)
 

Rodrigo Corral González

Software Architect


C\ Sebastián Elcano 32 , - Madrid (Spain)


Note: The information contained in this message may be confidential information subject to the terms and conditions of a confidentiality agreement between Plain Concepts and you or your employer. You are not permitted to disclose or publish confidential information. In addition, if you have received this message in error (i) please notify us immediately by return message, and (ii) any use or distribution of this information is prohibited.

P Please consider the environment before printing this email.

Disclaimer added by CodeTwo Exchange Rules
www.codetwo.com


From: agile...@googlegroups.com [agile...@googlegroups.com] On Behalf Of Vicenç Garcia [vincen...@gmail.com]
Sent: Thursday, June 25, 2009 09:34

To: agile...@googlegroups.com
Subject: [agile-spain] Re: Comenzando con Scrum

Jorge Uriarte Aretxaga

unread,
Jun 25, 2009, 5:40:20 AM6/25/09
to agile...@googlegroups.com
> Rodrigo, cuando hablas de un product backlog independiente, ¿qué quieres
> decir exactamente? ¿Los ítems de ese product backlog son una recopilación
> de todas las tareas que esos equipos tienen en los distintos sprints?, ¿cómo
> se gestionan estos equipos? Veo complicado que puedan trabajar por sprints
> también, porque los sprints en los que estén involucrados tendrán distintas
> fechas de inicio y fin, y al no estar sincronizados, no veo muy claro como
> gestionan su PB.
>

Para un staff compartido... un Kanban aplica mejor por "alisar" el
concepto de sprint... ahí tambien existe un backlog, lo que pasa es
que existen menos restricciones temporales a su modificación.

Si el tiempo medio de salida de las actividades del staff es
predecible, los equipos que funcionan en base a sprint pueden calcular
si el servicio solicitado se les dará en plazo o no.

> Rodrigo, cuando hablas de un product backlog independiente, ¿qué quieres

Rodrigo Corral González

unread,
Jun 25, 2009, 5:43:12 AM6/25/09
to agile...@googlegroups.com
Cierto. Para equipos de tipo 'diseñadores', el concepto de Sprint se relaja, y es dificil hacer un Sprint Review. Esos equipos tienden a funcionar con un Scrum bastante 'kanbanizado'. Básicamente tienen un PB con PBI mucho más atómicos y con un esquema FIFO más que con un PO que prioriza explicitamente (aunque también hay PO, su labor es más simple).

Un saludo.



Disclaimer added by CodeTwo Exchange Rules
http://www.codetwo.com________________________________________
From: agile...@googlegroups.com [agile...@googlegroups.com] On Behalf Of Jorge Uriarte Aretxaga [jorge....@gailen.es]
Sent: Thursday, June 25, 2009 11:40
To: agile...@googlegroups.com
Subject: [agile-spain] Re: Comenzando con Scrum

David

unread,
Jun 30, 2009, 6:18:13 AM6/30/09
to agile...@googlegroups.com
Hola a todos.

Coincido plenamente en que los equipos deben estar cohesionados y siempre que se pueda así debe de ser, ya que de lo contrario aparecen sentimientos como los que habéis comentado -no pertenencia, sobrecarga de trabajo, indiferencia, etc.-. Además un equipo conformado cumple mejor los objetivos, y la figura de al menos un especialista es fundamental en los equipos de ingeniería, siempre y cuando el especialista no sirva como bombero apaga fuegos, si no para marcar la velocidad del equipo.

Ahora bien, me parece intuir algún error de apreciación a la hora de componer los equipos en un entorno ágil, ya que se trata a los diseñadores como "activos itinerantes". Si la velocidad del equipo viene dada por las estimaciones de las tareas asignadas en sucesivos sprints, no puedo planificar de antemano que un diseñador va a estar asignado un 20% del tiempo, pues entonces hablamos de un entorno predictivo y no ágil.

Las mismas cualidades que propongo a un programador debo propornérselas a un diseñador. Hablamos de equipos multidisciplinares y es común cometer el error de equiparar a un equipo de desarrollo software con un equipo puramente de ingeniería informática, pero son nuevos tiempos.

Si un desarrollador para formar parte de un proyecto debe conocer un lenguaje, patrones de diseño, buenas prácticas de codificación, pruebas de código y un montón de skills más, también a los diseñadores hay que "obligarles" (no me gusta como suena, mejor recomendarles) que además de técnicas de diseño, colores y pantones, sepan diseñar pruebas de usuario, realicen prototipos, aprendan y utilicen técnicas y reglas de usabilidad y accesibilidad, así como patrones de diseño y de código también.

Si hablamos de Scrum como técnica de gestión de desarrollos iterativos e incrementales, podemos añadir modelos iterativos e incrementales basados en prototipos como prototipo desechable, prototipo por incrementos o prototipo evolutivo (Dix et al, 1997). Asi como modelos de ingeniería basados en usabilidad (D. Mayhew, 1999).

Modelos donde se planifica como tareas el diseño conceptual y el físico, así como las pruebas de aceptación del interfaz de usuario (no de la correcta funcionalidad), por lo que los diseñadores en este caso (la verdad es que es válido para cualquier perfil, no sólo los diseñadores, frontend, integradores, etc.) juegan un papel dentro del equipo, se involucran y cumplen una de las directivas del manifiesto ágil: Valorar la colaboración con el cliente, y al estar basado en prototipos se cumple otra: Valorar la respuesta al cambio.

Por tanto la implicación de cualquier tipo de perfil fuera de "puramente desarrollador" es del 100% durante todo el proyecto.

En cuanto al teletrabajo:

El concepto de teletrabajo tiene implicaciones legales y empresariales, ya que el trabajador no puede pagar por trabajar (es ilegal), eso implica que los gastos de conexión, ordenador y derivados deben correr a cargo de la empresa (aquí no hablamos de freelancing).

Las consideraciones empresariales son que el primer cambio de mentalidad debe ocurrir a nivel directivo, si no el teletrabajo no funciona.

Segundo que es necesario una muy buena planificación de antemano y un control exhaustivo del éxito de lo que el teletrabajador debe conseguir, eso implica trabajo y seguimiento también por el jefe, directivo o mando.

Tercero: no todos los perfiles son aptos para teletrabajo, como se puede desprender del informe del ministerio[1].

A nivel personal exige fuerza de voluntad, planificación, constancia y concentración para eliminar interferencias exteriores. (lo más duro es luchar con tu mujer, suegra, madre, hermanos o hijos, a veces incluso los vecinos).

De todo esto se desprende que es necesario disponer de las herramientas adecuadas para poder gestionar teletrabajadores con éxito (y dependerá también del tipo de proyecto):

Lo más sencillo puede ser email, chat y teléfono.

A pasar a un entorno con un sistema gestor de contenidos y planificador de tareas, con videoconferencia gestionado en una extranet.

En un entorno de desarrollo, es vital disponer de herramientas como foros de discusión, wikis, planificadores online y herramientas SCM, algo más elaborado que una hoja excel y correo electrónico ya que en largas iteraciones es muy subceptible a errores.

Me ha quedado un poco largo, pero espero que sirva.

Saludos.
David


[1]http://www.map.es/iniciativas/mejora_de_la_administracion_general_del_estado/funcion_publica/concilia/medidas/teletrabajo/document_es/Manual_Teletrabajo.pdf

Manuel Angel Rubio Jiménez

unread,
Jul 4, 2009, 12:23:48 PM7/4/09
to agile...@googlegroups.com
Hola José Manuel,

en principio, perdón por responder tan tarde :-P

El 24/06/2009, a las 23:35, José Manuel Beas escribió:
> Mi duda va en este sentido. ¿Qué hacemos si tenemos "recursos
> compartidos"? Se me ocurre que sean "exclusivos" de un equipo
> durante un sprint y de otro equipo en el sprint siguiente, p.ej.
> pero intuyo que esto no es la solución, sobre todo si hablamos de
> desarrollos iterativos e incrementales (el especialista será
> necesario en casi todos los sprints).

Yo en mis proyectos solo tengo un maquetador web, con lo que el tema
de las interfaces son a través de mi RECURSO COMPARTIDO.

En este caso, lo que he hecho, es considerar la interfaz web como un
proyecto aparte y, en cada sprint se hace desarrollo del proyecto que
se requiera o que corra prisa, mientras por detrás se va trabajando
en mejorar lo que se pueda del sistema interno.

También destacar que mi terreno es el desarrollo de elementos de
telecomunicaciones, con lo que la interfaz es un 50% de cada
proyecto, y muchas veces menos.

Un saludo.
Manuel Rubio.

Luis Pabón

unread,
Jul 8, 2009, 4:21:05 PM7/8/09
to agile-spain
Un pequeño apunte más en cuanto a la ciencia del particionado que
introducía Rodrigo:

En industrias y sectores donde los proyectos son complejos y de gran
envergadura, se suele usar una técnica de ingeniería basada en lo que
se denomina la "Matriz de Estructura de Diseño" (en inglés: Design
Structure Matrix, o DSM), para establecer particiones lo más
desacopladas que sea posible, evitar bucles de dependencias y, en
general, simplificar la organización.

Que se use en esos ámbitos no quiere decir que el método no sea útil y
fácil de usar también en entornos más modestos. Se puede aplicar a
distintos problemas tales como la organización de equipos, la
resolución de problemas, la optimización de procesos o la arquitectura
de componentes de un sistema.

De hecho, respecto a este último aspecto, es posible que algunos ya lo
hayáis estado aplicando al usar las herramientas de particionado
estructural del código (en paquetes) que proporcionan algunas
herramientas de programación y análisis como IntelliJ IDEA, Lattix
LDM, Structure 101 o Dtangler.

Si os interesa el tema, os recomiendo que os paséis por www.dsmweb.org
y echéis un vistazo a la información y las herramientas allí
disponibles.

Saludos

--
Luis Pabón





On 24 jun, 12:12, Rodrigo Corral González <rcor...@plainconcepts.com>
wrote:
> Hola Micho:
>
> La situación de partida en la que te encuentras es la más compleja que se da. En empresas como la tuya, la gran dificultad pasa por encontrar que es un equipo para vosotros, en primer lugar, y en segundo lugar definir cuantos product backlogs vais a manejar.
>
> Para hacer esto, no hay una receta universal. Depende mucho de la cultura y organización actual de la empresa. Pero es la clave. Pensad que ahora solo existen individuos y tenéis que para de esa situación a una en la que el trabajo de reparta entre equipos, no entre individuos. Es es la gran dificultad.
>
> El principal problema que tenéis ahora es el tiempo que se os va en cambios de contexto. Probablemente estéis en la típica situación de prioridades difusas, de entender a los fuegos, al cliente que más grita... el antídoto para eso es Scrum y su modelo de equipos. Por ahí empezaría yo.
>
> Esa definición de equipos se puede hace atendiendo a numerosos factores y es particular de cada caso, muchas veces no resulta evidente, pero es vital hacerlo bien. Podemos particionar los equipos por numerosos criterios: tecnología, cliente al que se dedican, proyecto (la más evidente)... Lo vital, en mi opinión, es que esas particiones sean verdaderas particiones, que no existan individuos que están en n equipos a la vez.
>
> Yo suelo analizar las particiones que me salen según las leyes de las particiones de Roger S. Sessions, y da buen resultado:
>
> 1ª Ley: Las particiones deben ser verdaderas particiones.
> 2ª Ley: Las particiones deben ser adecuadas al problema.
> 3ª Ley: El número de subconjuntos en una partición debe ser adecuado.
> 4ª Ley: El tamaño de las particiones debe ser aproximadamente igual.
> 5ª Ley: Las interacciones entre subconjuntos deben ser mínimas y bien definidas.
>
> Si lográis hacer bien eso, habréis dado un gran paso. Luego, a la hora de determinar el número de backlogs, el enfoque más simple es un equipo, un backlog, un product owner. Anque no siempre es posible, es el enfoque más simple y el que siempre se debe perseguir.
>
> El enfoque más simplista de Scrum persigue un proyecto, un backlog, un equipo. Pero esto no siempre es posible en consultoras donde lo que hay son muchos proyectos pequeños que gestionar como un todo más que algunos proyectos grandes que respondan al modelo simple de Scrum.
>
> !Un saludo¡
>
> Rodrigo Corral González
>
> Software Architect
>
> C\ Sebastián Elcano 32 , - Madrid (Spain)
>
> Email: rcor...@plainconcepts.com <mailto:rcor...@plainconcepts.com> Mobile: +34 (686) 754 328 Blog:http://geeks.ms/blogs/rcorral/
> ________________________________
>
> Note: The information contained in this message may be confidential information subject to the terms and conditions of a confidentiality agreement between Plain Concepts and you or your employer. You are not permitted to disclose or publish confidential information. In addition, if you have received this message in error (i) please notify us immediately by return message, and (ii) any use or distribution of this information is prohibited.
>
> P Please consider the environment before printing this email.
>
> Disclaimer added by CodeTwo Exchange Ruleswww.codetwo.com<http://www.codetwo.com>
>
> ________________________________
> From: agile...@googlegroups.com [agile...@googlegroups.com] On Behalf Of Micho Gar [micho...@gmail.com]
Reply all
Reply to author
Forward
0 new messages