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).
> 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-spain@googlegroups.com [mailto:agile-spain@googlegroups.com] *En > nombre de *Alejandro Pérez García > *Enviado el:* jueves, 22 de julio de 2010 11:00 > *Para:* agile-spain@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.
> 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-spain@googlegroups.com. > Para anular tu suscripción a este grupo, envía un correo electrónico a > agile-spain+unsubscribe@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-spain@googlegroups.com. > Para anular tu suscripción a este grupo, envía un correo electrónico a > agile-spain+unsubscribe@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.
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.
Saludos, Pedro
De: agile-spain@googlegroups.com [mailto:agile-spain@googlegroups.com] En nombre de Israel Alcázar Enviado el: jueves, 22 de julio de 2010 14:16 Para: agile-spain@googlegroups.com; foro-agi...@yahoogroups.com Asunto: [agile-spain] Perfil de un Scrum master (antes: Pequeña película de animación para difundir las metodologías ágiles)
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).
El 22 de julio de 2010 13:39, PEDRO BALLESTEROS HERRANZ <p...@tid.es<mailto: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-spain@googlegroups.com<mailto:agile-spain@googlegroups.com> [mailto:agile-spain@googlegroups.com<mailto:agile-spain@googlegroups.com>] En nombre de Alejandro Pérez García Enviado el: jueves, 22 de julio de 2010 11:00 Para: agile-spain@googlegroups.com<mailto:agile-spain@googlegroups.com> CC: foro-agi...@yahoogroups.com<mailto: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.
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-spain@googlegroups.com<mailto:agile-spain@googlegroups.com>. Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com<mailto:agile-spain%2Bunsubscribe@g ooglegroups.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-spain@googlegroups.com<mailto:agile-spain@googlegroups.com>. Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com<mailto:agile-spain%2Bunsubscribe@g ooglegroups.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-spain@googlegroups.com. Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
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>
> 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).
> 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-spain@googlegroups.com [mailto:agile-spain@googlegroups.com] >> *En nombre de *Alejandro Pérez García >> *Enviado el:* jueves, 22 de julio de 2010 11:00 >> *Para:* agile-spain@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.
>> 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-spain@googlegroups.com. >> Para anular tu suscripción a este grupo, envía un correo electrónico a >> agile-spain+unsubscribe@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-spain@googlegroups.com. >> Para anular tu suscripción a este grupo, envía un correo electrónico a >> agile-spain+unsubscribe@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-spain@googlegroups.com. > Para anular tu suscripción a este grupo, envía un correo electrónico a > agile-spain+unsubscribe@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.
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"?
> 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>
> > 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).
> > 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-spain@googlegroups.com [mailto:agile-spain@googlegroups.com]
> >> *En nombre de *Alejandro Pérez García
> >> *Enviado el:* jueves, 22 de julio de 2010 11:00
> >> *Para:* agile-spain@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.
> >> 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-spain@googlegroups.com.
> >> Para anular tu suscripción a este grupo, envía un correo electrónico a
> >> agile-spain+unsubscribe@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-spain@googlegroups.com.
> >> Para anular tu suscripción a este grupo, envía un correo electrónico a
> >> agile-spain+unsubscribe@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-spain@googlegroups.com.
> > Para anular tu suscripción a este grupo, envía un correo electrónico a
> > agile-spain+unsubscribe@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.
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...
> 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"?
> 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>
> > > 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).
> > > 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-spain@googlegroups.com [mailto: > agile-spain@googlegroups.com] > > >> *En nombre de *Alejandro Pérez García > > >> *Enviado el:* jueves, 22 de julio de 2010 11:00 > > >> *Para:* agile-spain@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.
> > >> 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-spain@googlegroups.com. > > >> Para anular tu suscripción a este grupo, envía un correo electrónico a > > >> agile-spain+unsubscribe@googlegroups.com<agile-spain%2Bunsubscribe@googlegr oups.com> > <agile-spain%2Bunsubscribe@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-spain@googlegroups.com. > > >> Para anular tu suscripción a este grupo, envía un correo electrónico a > > >> agile-spain+unsubscribe@googlegroups.com<agile-spain%2Bunsubscribe@googlegr oups.com> > <agile-spain%2Bunsubscribe@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-spain@googlegroups.com. > > > Para anular tu suscripción a este grupo, envía un correo electrónico a > > > agile-spain+unsubscribe@googlegroups.com<agile-spain%2Bunsubscribe@googlegr oups.com> > <agile-spain%2Bunsubscribe@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-spain@googlegroups.com. > Para anular tu suscripción a este grupo, envía un correo electrónico a > agile-spain+unsubscribe@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.
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 )
> 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.
> Saludos,
> Pedro
> *De:* agile-spain@googlegroups.com [mailto:agile-spain@googlegroups.com] *En > nombre de *Israel Alcázar > *Enviado el:* jueves, 22 de julio de 2010 14:16 > *Para:* agile-spain@googlegroups.com; foro-agi...@yahoogroups.com > *Asunto:* [agile-spain] Perfil de un Scrum master (antes: Pequeña película > de animación para difundir las metodologías ágiles)
> 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).
> 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-spain@googlegroups.com [mailto:agile-spain@googlegroups.com] *En > nombre de *Alejandro Pérez García > *Enviado el:* jueves, 22 de julio de 2010 11:00 > *Para:* agile-spain@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.
> 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-spain@googlegroups.com. > Para anular tu suscripción a este grupo, envía un correo electrónico a > agile-spain+unsubscribe@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-spain@googlegroups.com. > Para anular tu suscripción a este grupo, envía un correo electrónico a > agile-spain+unsubscribe@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-spain@googlegroups.com. > Para anular tu suscripción a este grupo, envía un correo electrónico a > agile-spain+unsubscribe@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-spain@googlegroups.com. > Para anular tu suscripción a este grupo, envía un correo electrónico a > agile-spain+unsubscribe@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.
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>
> > 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.
> > Saludos,
> > Pedro
> > *De:* agile-spain@googlegroups.com [mailto:agile-spain@googlegroups.com] *En
> > nombre de *Israel Alcázar
> > *Enviado el:* jueves, 22 de julio de 2010 14:16
> > *Para:* agile-spain@googlegroups.com; foro-agi...@yahoogroups.com
> > *Asunto:* [agile-spain] Perfil de un Scrum master (antes: Pequeña película
> > de animación para difundir las metodologías ágiles)
> > 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).
> > 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-spain@googlegroups.com [mailto:agile-spain@googlegroups.com] *En
> > nombre de *Alejandro Pérez García
> > *Enviado el:* jueves, 22 de julio de 2010 11:00
> > *Para:* agile-spain@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.
> > 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-spain@googlegroups.com.
> > Para anular tu suscripción a este grupo, envía un correo electrónico a
> > agile-spain+unsubscribe@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-spain@googlegroups.com.
> > Para anular tu suscripción a este grupo, envía un correo electrónico a
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.
> 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.
> 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>
>> > > 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.
>> > > Saludos,
>> > > Pedro
>> > > *De:* agile-spain@googlegroups.com [mailto: >> agile-spain@googlegroups.com] *En >> > > nombre de *Israel Alcázar >> > > *Enviado el:* jueves, 22 de julio de 2010 14:16 >> > > *Para:* agile-spain@googlegroups.com; foro-agi...@yahoogroups.com >> > > *Asunto:* [agile-spain] Perfil de un Scrum master (antes: Pequeña >> película >> > > de animación para difundir las metodologías ágiles)
>> > > 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).
>> > > 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-spain@googlegroups.com [mailto: >> agile-spain@googlegroups.com] *En >> > > nombre de *Alejandro Pérez García >> > > *Enviado el:* jueves, 22 de julio de 2010 11:00 >> > > *Para:* agile-spain@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.
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.
> 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?
>> 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.
>>> 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>
>>> 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>
>>>> > > 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.
>>>> > > Saludos,
>>>> > > Pedro
>>>> > > *De:* agile-spain@googlegroups.com [mailto: >>>> agile-spain@googlegroups.com] *En >>>> > > nombre de *Israel Alcázar >>>> > > *Enviado el:* jueves, 22 de julio de 2010 14:16 >>>> > > *Para:* agile-spain@googlegroups.com; foro-agi...@yahoogroups.com >>>> > > *Asunto:* [agile-spain] Perfil de un Scrum master (antes: Pequeña >>>> película >>>> > > de animación para difundir las metodologías ágiles)
>>>> > > 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).
> 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.
>> 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?
>>> 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.
>>>> 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>
>>>> 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>
>>>>> > > 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.
>>>>> > > Saludos,
>>>>> > > Pedro
>>>>> > > *De:* agile-spain@googlegroups.com [mailto: >>>>> agile-spain@googlegroups.com] *En >>>>> > > nombre de *Israel Alcázar >>>>> > > *Enviado el:* jueves, 22 de julio de 2010 14:16 >>>>> > > *Para:* agile-spain@googlegroups.com; foro-agi...@yahoogroups.com >>>>> > > *Asunto:* [agile-spain] Perfil de un Scrum master (antes: Pequeña >>>>> película >>>>> > > de animación para difundir las metodologías ágiles)
>>>>> > > 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
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
-----Original Message-----
From: Jose Luis Soria <jlsor...@gmail.com>
Sender: agile-spain@googlegroups.com
Date: Fri, 23 Jul 2010 11:53:01 To: agile-spain<agile-spain@googlegroups.com>
Reply-To: agile-spain@googlegroups.com
Subject: [agile-spain] Re: Perfil de un Scrum master (antes: Pequeña película de animación para difundir las metodolog
ías ágiles)
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>
> > 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.
> > Saludos,
> > Pedro
> > *De:* agile-spain@googlegroups.com [mailto:agile-spain@googlegroups.com] *En
> > nombre de *Israel Alcázar
> > *Enviado el:* jueves, 22 de julio de 2010 14:16
> > *Para:* agile-spain@googlegroups.com; foro-agi...@yahoogroups.com
> > *Asunto:* [agile-spain] Perfil de un Scrum master (antes: Pequeña película
> > de animación para difundir las metodologías ágiles)
> > 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).
> > 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-spain@googlegroups.com [mailto:agile-spain@googlegroups.com] *En
> > nombre de *Alejandro Pérez García
> > *Enviado el:* jueves, 22 de julio de 2010 11:00
> > *Para:* agile-spain@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.
> > 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
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).
> 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.
> > 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?
> >> 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.
> >>> 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>
> >>> 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>
> >>>> > > 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
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:
> 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).
> 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.
> > > 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?
> > >> 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.
> > >>> 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>
> > >>> 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>
> > >>>> > > 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.
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.
> 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).
> 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.
> > > 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?
> > >> 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.
> > >>> 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>
> > >>> 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>
> > >>>> > > 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.
