Perfil de un Scrum master (antes: Pequeña película de animación para difundir las metodologías ágiles)

654 views
Skip to first unread message

Israel Alcázar

unread,
Jul 22, 2010, 8:16:22 AM7/22/10
to agile...@googlegroups.com, foro-...@yahoogroups.com
Pedro, este tema que introduces me parece muy interesante. Las funciones que según Scrum debe tener un SM podrían ser:

- Velar por el proceso (lista de requisitos priorizada, facilitador en las reuniones, enseñar al equipo a autogestionarse).
- Eliminar impedimentos que puedan ir apareciendo para que el equipo consiga los objetivos de cada iteracción.
- Proteger y aislar al equipo de interrupciones
- Asegurar la calidad 

Tenéis mejor explicado todo esto en Proyectos Agiles [1]. 

Bien a mi todo esto me parece muy bien, creo que son objetivos claros para que Scrum llegue a buen puerto. Ahora pensemos en cualquier empresa que quiera implantar Scrum. Si es una empresa muy grande, podrá permitirse tener perfiles exclusivamente que realicen la labor de SM, que hagan training, coaching y guíen al equipo alejándolo del lado oscuro de la fuerza. Ahora bien, si la empresa es mas pequeña, y los perfiles de la gente tiene que ser mas versátiles, creo que un perfil puramente SM no termine de encajar y se entienda como un perfil un  mixto con una carga técnica importante.

Esta es la filosofía que seguimos un poco en mi empresa, donde realmente el SM hace labores de lo que se puede llamar Team Leader, es decir, realiza las labores de SM, pero además es un referente técnico a la hora de resolver dudas y eliminar impedimentos (que muchas veces son meramente técnicos). 

Puede ser un debate interesante.


Saludos,



El 22 de julio de 2010 13:39, PEDRO BALLESTEROS HERRANZ <pm...@tid.es> escribió:

Pues a mi lo que me parece extraño de la película es que el que parece el scrum master (o igual es el scrum coach) diga que además les ayuda sobre la tecnología a utilizar, y que venga uno, le pregunte que como hacer eso y que el scrum master le diga que con hibérnate. Yo pensaba que el que trabaja exclusivamente en el rol de scrum master (es decir, no está también haciendo rol de desarrollador) no debía meterse en temas de tecnología. Que los temas de tecnología debían resolverse mediante la potenciación de la comunicación entre miembros del grupo, de ahí que lo ideal sea que todos estén ubicados en la misma sala. Es decir, ¿el scrum master es también un referente tecnológico? Yo he oído por ahí que no, y que además no debería serlo.

 

Saludos,

                Pedro

 

De: agile...@googlegroups.com [mailto:agile...@googlegroups.comEn nombre de Alejandro Pérez García
Enviado el: jueves, 22 de julio de 2010 11:00
Para: agile...@googlegroups.com
CC: foro-...@yahoogroups.com
Asunto: [agile-spain] Pequeña película de animación para difundir las metodologías ágiles

 

Hola a todos.

 

En Autentia hemos hecho una pequeña película de animación, con un toque de humor, para ayudar a difundir las metodologías ágiles.

 

 

A ver que os parece   ;)

 

 

 

Saludos


--

Alejandro Pérez García

Socio fundador de Autentia y www.adictosaltrabajo.com

(Formación, Consultoría, Desarrollo de sistemas transaccionales)

Tel.: 655 99 11 75

 

Autentia Real Business Solutions S.L.

       "Soporte a Desarrollo"

 

 

 

Este mensaje, y en su caso cualquier fichero anexo al mismo, puede contener información confidencial y/o privilegiada, siendo para uso exclusivo del destinatario. Si Vd. no es el destinatario o lo ha recibido por error, por favor, informe inmediatamente al emisor y destrúyalo. Está estrictamente prohibido por la legislación vigente realizar sin autorización cualquier copia, revelación o distribución del contenido de este mensaje sin la autorización expresa del remitente. Las opiniones expresadas en este correo son las de su autor y no son, necesariamente, compartidas por Autentia Real Business Solutions S.L.

 

This e-mail, and in the case of any file annexed to it, may contain confidential and/or privileged information, and it is exclusively for the use of the addresses of the message. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden by current legislation. The points of view expressed in this e-mail are solely those of the author and may not necessarily be from, or supported by, Autentia Real Business Solutions S.L.

 

 

 

-- 
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.

-- 
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.


PEDRO BALLESTEROS HERRANZ

unread,
Jul 22, 2010, 11:34:28 AM7/22/10
to agile...@googlegroups.com, foro-...@yahoogroups.com

Yo lo vería desde el punto de vista de que se trata de roles, y por tanto una persona del equipo puede asumir el rol de SM y también el rol de desarrollador (Team Member?), si puede combinar ambas cosas y si descuenta de su tiempo disponible en los sprint lo que le lleva ser SM.

 

En mi empresa si hay grupos que tienen una persona dedicada a ser exclusivamente SM de uno o varios proyectos, pero hay otros que deben compaginar tareas, depende de cada proyecto concreto. Si es un proyecto con pocos recursos no se pueden permitir el lujo de tener alguien que solo haga de SM. Aunque la tendencia es a que haya SM dedicados en exclusiva.

 

Algunos miembros con rol de desarrollador (tanto si es SM como si no) podrían tener además la etiqueta de Referente Tecnológico y por tanto tener más peso o mas criterio a la hora de decir que tecnología se usa en cada caso.

 

Lo que pasa es que una vez alguien me comentó que lo ideal sería que el SM no asumirá rol de desarrollador y menos aun de referente tecnológico ya que se corre el riesgo de que al final acabe ejerciendo de tradicional Jefe de Proyecto, y trate de imponer por la fuerza en la estrategia tecnológica sin atender a la opinión del resto de los miembros, es decir, que acabe convirtiéndose en una figura de Jefe y no haya un verdadero trabajo colaborativo basado en la comunicación permanente. La verdad es que entre unos compañeros de trabajo una vez surgió la polémica sobre esto.

 

Pero supongo que si todos saben en qué consiste scrum esto se puede evitar y a nadie se le sube el poder a la cabeza.

 

De todas formas cuando se trata de enseñar o formar en scrum creo que habría que atender a las ideas originales antes de saltarse las “reglas” para adaptarlo a las necesidades concretas. El video a mi me parece que transmite que el rol (y recalco rol) de SM, por defecto es un referente o jefe tecnológico.

Xavier Quesada Allue

unread,
Jul 22, 2010, 5:04:22 PM7/22/10
to agile-spain, foro-agiles
Una aclaración: asegurar la calidad no es funcion del ScrumMaster. Es responsabilidad del equipo, y en forma indirecta del PO (en el sentido de que es quien acepta o rechaza las entregas).

Saludos,
Xavier

2010/7/22 Israel Alcázar <israel...@gmail.com>



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

xavier.albaladejo

unread,
Jul 22, 2010, 5:28:43 PM7/22/10
to agile-spain
Hola,

Al hilo del comentario de XQ, me gustaría conocer vuestra opinión
sobre lo siguiente:

Aceptando que la responsabilidad de lo que se entrega es del equipo
(todos son responsables de lo que se consigue o no delante del Product
Owner), y dado que el guardián del proceso es el Scrum Master, ¿quien
es la primera persona que debería darse cuenta de que la "definición
de hecho" no se está cumpliendo y que se están "escondiendo cosas
debajo de la alfombra"?

Salud,

---
Xavier Albaladejo
www.proyectosagiles.org


On 22 jul, 23:04, Xavier Quesada Allue <xav...@xqa.com.ar> wrote:
> Una aclaración: asegurar la calidad no es funcion del ScrumMaster. Es
> responsabilidad del equipo, y en forma indirecta del PO (en el sentido de
> que es quien acepta o rechaza las entregas).
>
> Saludos,
> Xavier
>
> 2010/7/22 Israel Alcázar <israelalca...@gmail.com>
> > israelalca...@gmail.com
> >http://www.farmerdev.com
> >http://www.twitter.com/ialcazar
>
> > El 22 de julio de 2010 13:39, PEDRO BALLESTEROS HERRANZ <p...@tid.es>
> >  escribió:
>
> >> Pues a mi lo que me parece extraño de la película es que el que parece el
> >> scrum master (o igual es el scrum coach) diga que además les ayuda sobre la
> >> tecnología a utilizar, y que venga uno, le pregunte que como hacer eso y que
> >> el scrum master le diga que con hibérnate. Yo pensaba que el que trabaja
> >> exclusivamente en el rol de scrum master (es decir, no está también haciendo
> >> rol de desarrollador) no debía meterse en temas de tecnología. Que los temas
> >> de tecnología debían resolverse mediante la potenciación de la comunicación
> >> entre miembros del grupo, de ahí que lo ideal sea que todos estén ubicados
> >> en la misma sala. Es decir, ¿el scrum master es también un referente
> >> tecnológico? Yo he oído por ahí que no, y que además no debería serlo.
>
> >> Saludos,
>
> >>                 Pedro
>
> >> *De:* agile...@googlegroups.com [mailto:agile...@googlegroups.com]
> >> *En nombre de *Alejandro Pérez García
> >> *Enviado el:* jueves, 22 de julio de 2010 11:00
> >> *Para:* agile...@googlegroups.com
> >> *CC:* foro-agi...@yahoogroups.com
> >> *Asunto:* [agile-spain] Pequeña película de animación para difundir las
> >> metodologías ágiles
>
> >> Hola a todos.
>
> >> En Autentia hemos hecho una pequeña película de animación, con un toque de
> >> humor, para ayudar a difundir las metodologías ágiles.
>
> >>http://www.adictosaltrabajo.com/detalle-noticia.php?noticia=254
>
> >> A ver que os parece   ;)
>
> >> Saludos
>
> >> --
>
> >> Alejandro Pérez García
>
> >> Socio fundador de Autentia ywww.adictosaltrabajo.com
>
> >> (Formación, Consultoría, Desarrollo de sistemas transaccionales)
>
> >> mailto:alejandr...@autentia.com <alejandr...@autentia.com>
> >> agile-spain...@googlegroups.com<agile-spain%2Bunsubscribe@googlegr­oups.com>
> >> Para tener acceso a más opciones, visita el grupo en
> >>http://groups.google.com/group/agile-spain?hl=es.
>
> >> --
> >> 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<agile-spain%2Bunsubscribe@googlegr­oups.com>
> >> Para tener acceso a más opciones, visita el grupo en
> >>http://groups.google.com/group/agile-spain?hl=es.
>
> >  --
> > 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<agile-spain%2Bunsubscribe@googlegr­oups.com>
> > Para tener acceso a más opciones, visita el grupo en
> >http://groups.google.com/group/agile-spain?hl=es.
>
> --
> Xavier Quesada Allue
> Certified Scrum Coach
> Visual Management Blog:http://www.xqa.com.ar/visualmanagement- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

Gustavo Cebrian Garcia

unread,
Jul 22, 2010, 8:26:35 PM7/22/10
to agile...@googlegroups.com
Xavier,

En mi opinión, en la práctica. tiene que ser el tester el primero que se de cuenta.

Bien, el tester, es parte del grupo, y aunque tengamos equipos multidisciplinares, si tenemos testers
en los grupos scrum ( he leido artículos y visto presentaciones que lo afirman así, y yo trabajaba así )


Otra cosa, mmmmmmmmmmmm, Eso de que la calidad no es responsabilidad de Scrum Master, mmmmm,
Si, la responsabilidad es del equipo, pero en esto discrepa mucho la gente.

1-Unos dicen que el Scrum Master sólo guía, y no se mete en calidad, ni en el resultado.
2-Otros, que el Scrum Master, debe hacer todo lo que pueda. Está claro que depende de la persona.
3-Hasta he oido que si el Scrum master enseña todos los procesos y cuando el equipo va bien, este se puede retirar.

Claro está, que depende del caso, pero, al final, el resultado que se tiene depende de las personas, y en mi opinión
si que puede ser bueno de que el Scrum Master, como digo yo, "baje" hasta la calidad, todo lo más que pueda.
Es más, para mi, un buen SM lo debería de hacer. Obviamente, no puede estar revisando todas las líneas de código...

Qué pensáis?

2010/7/22 xavier.albaladejo <xavi.al...@gmail.com>

Gustavo Cebrian Garcia

unread,
Jul 22, 2010, 8:32:49 PM7/22/10
to agile...@googlegroups.com, foro-...@yahoogroups.com
Exactamente Pedro, una cosa es hablar de roles, y otro de personas, y una persona, puede desarrollar varios roles,
y apliquemos la lógica, un SM no puede decir, "No, yo soy SM!!!" y debe intentar ayudar lo más que pueda con su experiencia. También, siendo realista, una persona, SM como tal, a la larga, se irá alejando poco a poco de las tecnologías, por lo menos de ser un super techy! Hasta podría decir que un buen SM no debe de ser techy a la larga, ya que o bien son tecnologías antiguas las que se utilizan en su empresa, o ese techy no tiene vida y sigue leyendo y programando en vez de educarse en gestión. ( Es mi opinión )

2010/7/22 PEDRO BALLESTEROS HERRANZ <pm...@tid.es>

Jose Luis Soria

unread,
Jul 23, 2010, 2:53:01 PM7/23/10
to agile-spain
Yo estoy con XQ, la calidad no es responsabilidad del ScrumMaster.
Para mí la mejor definición de calidad (de cara al negocio, no hablo
de calidad del código o similares) es que el software haga lo que se
supone que tiene que hacer. Y esto se refleja en los criterios de
aceptación de las historias de usuario, lo aprueba el Product Owner y
se corrobora con el resto de interesados.

En cuanto a quién es el primero que se daría cuenta de que no se llega
a la definición de hecho y que se esconden cosas debajo de la
alfombra, en mi opinión es el mismo equipo. En un equipo que funcione
bien como tal, esto tiene que salir en el trabajo diario, en el daily
scrum, etc.

Un saludo!!!



On 23 jul, 02:32, Gustavo Cebrian Garcia <g.cebrian.gar...@gmail.com>
wrote:
> Exactamente Pedro, una cosa es hablar de roles, y otro de personas, y una
> persona, puede desarrollar varios roles,
> y apliquemos la lógica, un SM no puede decir, "No, yo soy SM!!!" y debe
> intentar ayudar lo más que pueda con su experiencia. También, siendo
> realista, una persona, SM como tal, a la larga, se irá alejando poco a poco
> de las tecnologías, por lo menos de ser un super techy! Hasta podría decir
> que un buen SM no debe de ser techy a la larga, ya que o bien son
> tecnologías antiguas las que se utilizan en su empresa, o ese techy no tiene
> vida y sigue leyendo y programando en vez de educarse en gestión. ( Es mi
> opinión )
>
> 2010/7/22 PEDRO BALLESTEROS HERRANZ <p...@tid.es>
> > nombre de *Israel Alcázar
> > *Enviado el:* jueves, 22 de julio de 2010 14:16
> > *Para:* agile...@googlegroups.com; foro-agi...@yahoogroups.com
> > *Asunto:* [agile-spain] Perfil de un Scrum master (antes: Pequeña película
> > israelalca...@gmail.com
> >http://www.farmerdev.com
> >http://www.twitter.com/ialcazar
>
> > El 22 de julio de 2010 13:39, PEDRO BALLESTEROS HERRANZ <p...@tid.es
> > > escribió:
>
> > Pues a mi lo que me parece extraño de la película es que el que parece el
> > scrum master (o igual es el scrum coach) diga que además les ayuda sobre la
> > tecnología a utilizar, y que venga uno, le pregunte que como hacer eso y que
> > el scrum master le diga que con hibérnate. Yo pensaba que el que trabaja
> > exclusivamente en el rol de scrum master (es decir, no está también haciendo
> > rol de desarrollador) no debía meterse en temas de tecnología. Que los temas
> > de tecnología debían resolverse mediante la potenciación de la comunicación
> > entre miembros del grupo, de ahí que lo ideal sea que todos estén ubicados
> > en la misma sala. Es decir, ¿el scrum master es también un referente
> > tecnológico? Yo he oído por ahí que no, y que además no debería serlo.
>
> > Saludos,
>
> >                 Pedro
>
> > *De:* agile...@googlegroups.com [mailto:agile...@googlegroups.com] *En
> > nombre de *Alejandro Pérez García
> > *Enviado el:* jueves, 22 de julio de 2010 11:00
> > *Asunto:* [agile-spain] Pequeña película de animación para difundir las
> > metodologías ágiles
>
> > Hola a todos.
>
> > En Autentia hemos hecho una pequeña película de animación, con un toque de
> > humor, para ayudar a difundir las metodologías ágiles.
>
> >http://www.adictosaltrabajo.com/detalle-noticia.php?noticia=254
>
> > A ver que os parece   ;)
>
> > Saludos
>
> > --
>
> > Alejandro Pérez García
>
> > Socio fundador de Autentia ywww.adictosaltrabajo.com
>
> > (Formación, Consultoría, Desarrollo de sistemas transaccionales)
>
> > mailto:alejandr...@autentia.com <alejandr...@autentia.com>
> > agile-spain...@googlegroups.com<agile-spain%2Bunsubscribe@googlegr oups.com>
> > Para tener acceso a más opciones, visita el grupo en
> >http://groups.google.com/group/agile-spain?hl=es.
>
> > --
> > 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<agile-spain%2Bunsubscribe@googlegr oups.com>
> > Para tener acceso a más opciones, visita el grupo en
> >http://groups.google.com/group/agile-spain?hl=es.
>
> > --
> > 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<agile-spain%2Bunsubscribe@googlegr oups.com>
> > Para tener acceso a más opciones, visita el grupo en
> >http://groups.google.com/group/agile-spain?hl=es.
>
> > --
> > 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<agile-spain%2Bunsubscribe@googlegr oups.com>

Xavier Quesada Allue

unread,
Jul 23, 2010, 3:19:02 PM7/23/10
to agile-spain
Se han mencionado tres tipos de "calidad"

1) Calidad externa
2) Calidad interna (mantenibilidad)
3) Calidad del proceso

La calidad externa yo diría que es responsabilidad, en ultima instancia, del Product Owner, ya que es observable. Pero el equipo tiene una obligación básica de desarrollar software de calidad, o sea el Product Owner no debe convertirse en el Tester/QA del equipo.

La calidad interna es indiscutiblemente responsabilidad del equipo, ya que no es observable (en el corto plazo) por el Product Owner. El ScrumMaster debe velar por que el equipo sea consciente de cual es el estado actual de la calidad interna del producto, y si es baja, tiene que guiar al equipo para que reaccione ante el problema.

O sea, en castellano: si el equipo está haciendo un desastre, es responsabilidad del ScrumMaster que el equipo reaccione y empiece a refactorizar y agregar tests. Pero esto no es lo mismo que decir que el ScrumMaster es responsable de la calidad final (interna o externa) del producto. El SM puede estar haciendo un buen trabajo y la calidad seguir siendo baja. Si el equipo y la gerencia no colaboran, el SM no puede hacer milagros.

Finalmente, la calidad del proceso es indiscutiblemente responsabilidad del ScrumMaster.

Saludos,
X

2010/7/23 Gustavo Cebrian Garcia <g.cebria...@gmail.com>
Bueno, que el código tiene que ser mantenible, no?

he visto herramientas que hacen lo que deben, pero para añadir una nueva funcionalidad, 3 meses
en vez de 2 semanas, la calidad se va, se va!!

Por poner un ejemplo, he visto herramientas perder reputación por querer sacar algo en el mercado en una fecha,
y hacer todo deprisa, y no poder hacer pruebas, y bang bang bang! Fallos y fallos. Bueno, esto lo sabremos todos.

Pues eso, la calidad de los procesos aumenta la calidad del producto final.

2010/7/23 Jose Luis Soria <jlso...@gmail.com>



--

Xavier Quesada Allue

unread,
Jul 23, 2010, 8:13:38 PM7/23/10
to agile-spain
A ver, que quede claro: nadie está diciendo que el PO no PUEDA testear, o el SM codear, etc, en ciertos contextos y situaciones. No confundir PUEDA con DEBA. Que pueda testear no significa que deba testear. Si es un buen equipo y el PO quiere testear para ayudar a ir mas rapido, bienvenido sea. Pero el equipo no deberia depender de ello. Si el equipo depende del PO para garantizar la calidad, está usandolo para tapar la causa raíz de que no saben (o no quieren) construir algo de calidad por si mismos.

Respecto al ultimo comentario, estamos hablando de la definicion de roles y responsabilidades del framework de Scrum. Esto no tiene nada que ver con apuntar dedos, tiene que ver con entender qué es y que no es Scrum. Por ejemplo, un equipo que depende del PO para testear probablemente no esta haciendo Scrum correctamente.

Saludos,
Xavier

2010/7/23 Gustavo Cebrian Garcia <g.cebria...@gmail.com>
Puff, parece que hay discrepancias.

Sinceramente, aunque haya roles, yo creo que el equipo, si es un buen equipo, tendrá que hacer todo lo que sepa y esté a su alcance. No? Yo he leído algún artículo que dice que el Product Owner tiene que hacer pruebas si no tiene nada que hacer, con lo cual contribuye. Si además tiene experiencia, pues prouqe no gestionar pruebas.
El SM, pues puede hasta tirar algunas líneas de código, y si tiene tiempo y no tiene otra cosa que hacer mejor (quizá difícil)
pues hasta hacer pruebas. ( Así lo veo yo, que el equipo, tiene que ser más equipo )

Yo creo, que hablar de responsabilidades, dentro de un super equipo Scrum, mmmmmm, no sé, significa que hay que apuntar con el dedo si algo sale mal?

Bueno, qué pensáis?

2010/7/23 Xavier Quesada Allue <xav...@xqa.com.ar>

Gustavo Cebrian Garcia

unread,
Jul 23, 2010, 8:34:01 PM7/23/10
to agile...@googlegroups.com
Si, entiendo que para medir la velocidad del equipo, claro, no puede meter al PO en el equipo, no?

Es un buen argumento para decir que tienes razón. Se mide la velocidad del equipo, sin el PO, no?

Gustavo.

2010/7/24 Xavier Quesada Allue <xav...@xqa.com.ar>

harr...@gmail.com

unread,
Jul 25, 2010, 6:04:59 AM7/25/10
to Liste Agile Spain
No estoy seguro si hace falta anadir mucho, pero creo que habria que destacar que la "receta" de Scrum esta en eliminar "cuellos de botella" a traves de un proceso que distribuye el trabajo entre los stakeholders "cerdo", en vez de depositar toda la confianza en algun "guru".

En consecuencia, el resultado (y la calidad) no dependen de un individuo, sino de la capacidad del equipo de organizarse.

Alli radica, por lo menos para mi, la fuerza de SCRUM, sacar maximo provecho del potencial del grupo y dejando surgir los resultados como consecuencia de este esfuerzo colectivo, pero guido por un proceso.

Saludos,
Harald
Enviado desde mi BlackBerry® de Vodafone

xavier.albaladejo

unread,
Jul 25, 2010, 11:22:04 AM7/25/10
to agile-spain
Como resumen, creo que podríamos decir que el equipo es el responsable
de proporcionar un producto de calidad, no se puede escudar en etapas
posteriores de verificación de calidad o en las pruebas de aceptación
del Product Owner para no garantizar la calidad del producto que ha
construido.

Dicho esto, se puede profundizar en base a la terminología de la
ISO9126 de calidad de producto en ingeniería del software:
- La calidad en uso (satisfacción del usuario, efectividad,
productividad, seguridad) es un aspecto a verificar por el Product
Owner que, además de ser representante de los usuarios finales,
también debe asegurar que el producto cumpla con las necesidades del
negocio y estratégicas de los stakeholders del proyecto.
- La calidad externa (funcionalidad, usabilidad, eficiencia,
mantenibilidad, fiabilidad, portabilidad) en algunos aspectos es más
difícil de verificar por el Product Owner.
- La calidad interna no es verificable directamente por el Product
Owner.

Como dice Xavier Quesada, “[allí donde la calidad externa e interna no
es observable] el equipo tiene una obligación básica de desarrollar
software de calidad, o sea el Product Owner no debe convertirse en el
Tester/QA del equipo”.

Si es necesario, el Product Owner se puede servir de diversos
mecanismos como ayuda a verificar la calidad externa e interna del
producto, por ejemplo, una auditoría. En el caso de desarrollo de
software, una auditoría del código, patrones arquitectónicos
utilizados, trazabilidad entre requisitos (historias de usuario),
casos de prueba (criterios de aceptación) y otros entregables, etc.

El Scrum Master se encarga de facilitar que se entregue un producto
con calidad. Al ser el responsable de la calidad en el proceso, el
Scrum Master guía al Product Owner y al equipo para conseguir que:
- El Product Owner (re)priorice en función del valor aportado al
negocio (y el coste de implementación).
- El equipo cumpla con la “definición de hecho” que ha consensuado
con el cliente.
- El Product Owner revise el producto al final de cada iteración.
- El equipo tome consciencia del producto que se está entregando (si
cumple con las expectativas del Product Owner, si es está degradando
la calidad externa e interna y se está introduciendo “deuda técnica”
que dificulte su crecimiento sostenido) y guiarlo para que reaccione
si hay problemas (como menciona Xavier Quesada).

Salud,

---
Xavier Albaladejo
www.proyectosagiles.org

On 24 jul, 02:13, Xavier Quesada Allue <xav...@xqa.com.ar> wrote:
>  A ver, que quede claro: nadie está diciendo que el PO no PUEDA testear, o
> el SM codear, etc, en ciertos contextos y situaciones. No confundir PUEDA
> con DEBA. Que pueda testear no significa que deba testear. Si es un buen
> equipo y el PO quiere testear para ayudar a ir mas rapido, bienvenido sea.
> Pero el equipo no deberia depender de ello. Si el equipo depende del PO para
> garantizar la calidad, está usandolo para tapar la causa raíz de que no
> saben (o no quieren) construir algo de calidad por si mismos.
>
> Respecto al ultimo comentario, estamos hablando de la definicion de roles y
> responsabilidades del framework de Scrum. Esto no tiene nada que ver con
> apuntar dedos, tiene que ver con entender qué es y que no es Scrum. Por
> ejemplo, un equipo que depende del PO para testear probablemente no esta
> haciendo Scrum correctamente.
>
> Saludos,
> Xavier
>
> 2010/7/23 Gustavo Cebrian Garcia <g.cebrian.gar...@gmail.com>
> >> 2010/7/23 Gustavo Cebrian Garcia <g.cebrian.gar...@gmail.com>
>
> >>> Bueno, que el código tiene que ser mantenible, no?
>
> >>> he visto herramientas que hacen lo que deben, pero para añadir una nueva
> >>> funcionalidad, 3 meses
> >>> en vez de 2 semanas, la calidad se va, se va!!
>
> >>> Por poner un ejemplo, he visto herramientas perder reputación por querer
> >>> sacar algo en el mercado en una fecha,
> >>> y hacer todo deprisa, y no poder hacer pruebas, y bang bang bang! Fallos
> >>> y fallos. Bueno, esto lo sabremos todos.
>
> >>> Pues eso, la calidad de los procesos aumenta la calidad del producto
> >>> final.
>
> >>> 2010/7/23 Jose Luis Soria <jlsor...@gmail.com>
> ...
>
> leer más »

IvanFont

unread,
Jul 25, 2010, 6:12:11 PM7/25/10
to agile-spain
Hola a todos,

estoy totalmente de acuerdo en que la "calidad interna" a nivel de
código debe de ser responsabilidad del equipo de desarrollo y por lo
tanto del SM. Pero también de la seguridad y del rendimiento del
desarrollo. Por otro lado, la calidad del "uso" ( usabilidad y
funcionalidad) son exclusivas del PO.

saludos
Ivan

On 25 jul, 17:22, "xavier.albaladejo" <xavi.albalad...@gmail.com>
wrote:
> ...
>
> leer más »

Xavier Quesada Allue

unread,
Jul 25, 2010, 6:22:07 PM7/25/10
to agile-spain
Buen resumen. No sabia de esa "categorizacion de calidades" de la ISO, ni habia escuchado hablar de 'calidad de uso'. Una perspectiva interesante sobre el tema.

Saludos,
X

2010/7/25 xavier.albaladejo <xavi.al...@gmail.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.

Reply all
Reply to author
Forward
0 new messages