Pues a mi lo que me parece extraño de la película es que el que parece el scrum master (o igual es el scrum coach) diga que además les ayuda sobre la tecnología a utilizar, y que venga uno, le pregunte que como hacer eso y que el scrum master le diga que con hibérnate. Yo pensaba que el que trabaja exclusivamente en el rol de scrum master (es decir, no está también haciendo rol de desarrollador) no debía meterse en temas de tecnología. Que los temas de tecnología debían resolverse mediante la potenciación de la comunicación entre miembros del grupo, de ahí que lo ideal sea que todos estén ubicados en la misma sala. Es decir, ¿el scrum master es también un referente tecnológico? Yo he oído por ahí que no, y que además no debería serlo.
Saludos,
Pedro
De: agile...@googlegroups.com [mailto:agile...@googlegroups.com] En nombre de Alejandro Pérez García
Enviado el: jueves, 22 de julio de 2010 11:00
Para: agile...@googlegroups.com
CC: foro-...@yahoogroups.com
Asunto: [agile-spain] Pequeña película de animación para difundir las metodologías ágiles
Hola a todos.
En Autentia hemos hecho una pequeña película de animación, con un toque de humor, para ayudar a difundir las metodologías ágiles.
A ver que os parece ;)
Saludos
--Alejandro Pérez García
Socio fundador de Autentia y www.adictosaltrabajo.com
(Formación, Consultoría, Desarrollo de sistemas transaccionales)
Tel.: 655 99 11 75
Autentia Real Business Solutions S.L.
"Soporte a Desarrollo"
Este mensaje, y en su caso cualquier fichero anexo al mismo, puede contener información confidencial y/o privilegiada, siendo para uso exclusivo del destinatario. Si Vd. no es el destinatario o lo ha recibido por error, por favor, informe inmediatamente al emisor y destrúyalo. Está estrictamente prohibido por la legislación vigente realizar sin autorización cualquier copia, revelación o distribución del contenido de este mensaje sin la autorización expresa del remitente. Las opiniones expresadas en este correo son las de su autor y no son, necesariamente, compartidas por Autentia Real Business Solutions S.L.
This e-mail, and in the case of any file annexed to it, may contain confidential and/or privileged information, and it is exclusively for the use of the addresses of the message. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden by current legislation. The points of view expressed in this e-mail are solely those of the author and may not necessarily be from, or supported by, Autentia Real Business Solutions S.L.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
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.
Bueno, que el código tiene que ser mantenible, no?
he visto herramientas que hacen lo que deben, pero para añadir una nueva funcionalidad, 3 meses
en vez de 2 semanas, la calidad se va, se va!!
Por poner un ejemplo, he visto herramientas perder reputación por querer sacar algo en el mercado en una fecha,
y hacer todo deprisa, y no poder hacer pruebas, y bang bang bang! Fallos y fallos. Bueno, esto lo sabremos todos.
Pues eso, la calidad de los procesos aumenta la calidad del producto final.2010/7/23 Jose Luis Soria <jlso...@gmail.com>
Puff, parece que hay discrepancias.
Sinceramente, aunque haya roles, yo creo que el equipo, si es un buen equipo, tendrá que hacer todo lo que sepa y esté a su alcance. No? Yo he leído algún artículo que dice que el Product Owner tiene que hacer pruebas si no tiene nada que hacer, con lo cual contribuye. Si además tiene experiencia, pues prouqe no gestionar pruebas.
El SM, pues puede hasta tirar algunas líneas de código, y si tiene tiempo y no tiene otra cosa que hacer mejor (quizá difícil)
pues hasta hacer pruebas. ( Así lo veo yo, que el equipo, tiene que ser más equipo )
Yo creo, que hablar de responsabilidades, dentro de un super equipo Scrum, mmmmmm, no sé, significa que hay que apuntar con el dedo si algo sale mal?
Bueno, qué pensáis?2010/7/23 Xavier Quesada Allue <xav...@xqa.com.ar>
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.