¿Es necesario el componente técnico en un Scrum Master?
599 views
Skip to first unread message
Sonia Bravo
Apr 2, 2012, 3:38:59 PM4/2/12
to agile-spain
Hola a tod@s,
He 'rastreado' los diferentes topics y no llego a encontrar la
respuesta que busco así que prefiero plantearla directamente aunque
más de un@ considere que ya ha sido contestada en los diversos debates
abiertos (por tanto, pido perdón si creéis que mi pregunta está harto
contestada anteriormente).
Soy informática y trabajé en consultoría como analista/programadora
Java durante 5 años. Tras esos 5 años, pasé al lado 'cliente' hace 6
años y dejé de programar para pasar a labores de JP aunque considero
que en mi caso se trata más de supervisión (con mi consiguiente
frustración. No preguntéis: forma de trabajar en empresa pública que
subcontrata todo).
Mi motivación siempre ha estado más orientada a la gestión de equipos
fomentando el trabajo en equipo, la comunicación y la motivación de
los integrantes.
Aparte, durante estos 6 últimos años he visto cómo los proyectos
fracasaban estrepitosamente uno tras otro siguiendo la famosa
metodología en cascada.
Hace un tiempo que descubrí las metodologías ágiles (con más detalle,
Scrum) y ha sido como volver a nacer. Estoy tan evangelizada que me he
dado cuenta de que es la forma de trabajo que yo busco y con la que
realmente comulgo (aunque seguramente esto suponga dejar la
confortable estabilidad de mi puesto actual).
Sí, me gustaría ejercer de Scrum Master pero me surge una gran duda,
¿es necesaria la componente técnica en un Scrum Master?
He leído muchísimo sobre las labores de un Scrum Master pero tengo la
gran duda de si es necesario que ejerza también como referente
tecnológico/técnico, que sea un experto técnicamente hablando. Si es
así, dado mi desfase/oxidación de los últimos años y mi poca
motivación en convertime en una experta tecnológica, no tiene sentido
el orientar mi carrera hacia este punto por no tener las cualidades,
motivaciones y aptitudes que debe tener un Scrum Master.
Como entenderéis, dado que estoy replanteándome mi carrera
profesional, vuestras respuestas (como expertos que os considero)
resultan muy importantes para mí, por lo que también me gustaría que
cualquier respuesta venga argumentada para así entenderlo mejor.
Y ahí va la segunda pregunta del millón... Supongamos que no es
necesario el componente técnico/tecnológico de un Scrum Master...
¿Realmente existen empresas que buscan Scrum Master que 'no hagan de
todo'? Esto es, un Scrum Master que sea un facilitador y no además una
persona que sea consultor senior y experto tecnológico (de nuevo, el
componente técnico).
Por saber si tengo un 'lugar' en este mundo de las TI.
Gracias de antemano a todos y perdón por el discurso.
Saludos,
Sonia
He 'rastreado' los diferentes topics y no llego a encontrar la
respuesta que busco así que prefiero plantearla directamente aunque
más de un@ considere que ya ha sido contestada en los diversos debates
abiertos (por tanto, pido perdón si creéis que mi pregunta está harto
contestada anteriormente).
Soy informática y trabajé en consultoría como analista/programadora
Java durante 5 años. Tras esos 5 años, pasé al lado 'cliente' hace 6
años y dejé de programar para pasar a labores de JP aunque considero
que en mi caso se trata más de supervisión (con mi consiguiente
frustración. No preguntéis: forma de trabajar en empresa pública que
subcontrata todo).
Mi motivación siempre ha estado más orientada a la gestión de equipos
fomentando el trabajo en equipo, la comunicación y la motivación de
los integrantes.
Aparte, durante estos 6 últimos años he visto cómo los proyectos
fracasaban estrepitosamente uno tras otro siguiendo la famosa
metodología en cascada.
Hace un tiempo que descubrí las metodologías ágiles (con más detalle,
Scrum) y ha sido como volver a nacer. Estoy tan evangelizada que me he
dado cuenta de que es la forma de trabajo que yo busco y con la que
realmente comulgo (aunque seguramente esto suponga dejar la
confortable estabilidad de mi puesto actual).
Sí, me gustaría ejercer de Scrum Master pero me surge una gran duda,
¿es necesaria la componente técnica en un Scrum Master?
He leído muchísimo sobre las labores de un Scrum Master pero tengo la
gran duda de si es necesario que ejerza también como referente
tecnológico/técnico, que sea un experto técnicamente hablando. Si es
así, dado mi desfase/oxidación de los últimos años y mi poca
motivación en convertime en una experta tecnológica, no tiene sentido
el orientar mi carrera hacia este punto por no tener las cualidades,
motivaciones y aptitudes que debe tener un Scrum Master.
Como entenderéis, dado que estoy replanteándome mi carrera
profesional, vuestras respuestas (como expertos que os considero)
resultan muy importantes para mí, por lo que también me gustaría que
cualquier respuesta venga argumentada para así entenderlo mejor.
Y ahí va la segunda pregunta del millón... Supongamos que no es
necesario el componente técnico/tecnológico de un Scrum Master...
¿Realmente existen empresas que buscan Scrum Master que 'no hagan de
todo'? Esto es, un Scrum Master que sea un facilitador y no además una
persona que sea consultor senior y experto tecnológico (de nuevo, el
componente técnico).
Por saber si tengo un 'lugar' en este mundo de las TI.
Gracias de antemano a todos y perdón por el discurso.
Saludos,
Sonia
Daniel Ceillan
Apr 2, 2012, 3:58:39 PM4/2/12
to agile...@googlegroups.com
El 2 de abril de 2012 16:38, Sonia Bravo <sonia...@gmail.com> escribió:
Hola a tod@s,
He 'rastreado' los diferentes topics y no llego a encontrar la
respuesta que busco así que prefiero plantearla directamente aunque
más de un@ considere que ya ha sido contestada en los diversos debates
abiertos (por tanto, pido perdón si creéis que mi pregunta está harto
contestada anteriormente).
Soy informática y trabajé en consultoría como analista/programadora
Java durante 5 años. Tras esos 5 años, pasé al lado 'cliente' hace 6
años y dejé de programar para pasar a labores de JP aunque considero
que en mi caso se trata más de supervisión (con mi consiguiente
frustración. No preguntéis: forma de trabajar en empresa pública que
subcontrata todo).
Mi motivación siempre ha estado más orientada a la gestión de equipos
fomentando el trabajo en equipo, la comunicación y la motivación de
los integrantes.
Hola Sonia, te comparto mi punto de vista.
La labor de Scrum Master en si no requiere conocimiento tecnico de la labor de programador, pero si constituye una fuerte ventaja conocer o tener idea de los procesos que estan pasando debajo.
Siendo la principal mision del SM la motivacion del equipo (segun entiendo yo) no seria requerido que conozca los pormenores tecnicos. Sin embargo si considero que para ser SM, alguien debe haber programado algun tiempo o haber sufrido bastante el management Fordista, porque esa es justamente una forma de conocer el punto de vista del programador o desarrollador.
Definitivamente el SM no es un Lider tecnico. Es un experto de Scrum, con habilidades de coach. Por mi parte lo veo mas como un Docente, que como un Tecnico.
Aparte, durante estos 6 últimos años he visto cómo los proyectos
fracasaban estrepitosamente uno tras otro siguiendo la famosa
metodología en cascada.
Hace un tiempo que descubrí las metodologías ágiles (con más detalle,
Scrum) y ha sido como volver a nacer. Estoy tan evangelizada que me he
dado cuenta de que es la forma de trabajo que yo busco y con la que
realmente comulgo (aunque seguramente esto suponga dejar la
confortable estabilidad de mi puesto actual).
Sí, me gustaría ejercer de Scrum Master pero me surge una gran duda,
¿es necesaria la componente técnica en un Scrum Master?
He leído muchísimo sobre las labores de un Scrum Master pero tengo la
gran duda de si es necesario que ejerza también como referente
tecnológico/técnico, que sea un experto técnicamente hablando. Si es
así, dado mi desfase/oxidación de los últimos años y mi poca
motivación en convertime en una experta tecnológica, no tiene sentido
el orientar mi carrera hacia este punto por no tener las cualidades,
motivaciones y aptitudes que debe tener un Scrum Master.
Genial! felicitaciones.
Como entenderéis, dado que estoy replanteándome mi carrera
profesional, vuestras respuestas (como expertos que os considero)
resultan muy importantes para mí, por lo que también me gustaría que
cualquier respuesta venga argumentada para así entenderlo mejor.
Mira yo por mi parte, soy apasionado del codigo y el desarrollo, pero estoy enfocándome mas hacia ser PO. Yo te recomendaria que no solo evalues el rol de SM sino tambien el de PO.
Y ahí va la segunda pregunta del millón... Supongamos que no es
necesario el componente técnico/tecnológico de un Scrum Master...
¿Realmente existen empresas que buscan Scrum Master que 'no hagan de
todo'? Esto es, un Scrum Master que sea un facilitador y no además una
persona que sea consultor senior y experto tecnológico (de nuevo, el
componente técnico).
Por saber si tengo un 'lugar' en este mundo de las TI.
Hay muchas empresas que dicen ser agiles, pero no lo son. Hay formas de darte cuenta si una empresa tiene filosofia agil y ponerlos a prueba. Suponiendo que manifiestan usar agiles, les puedes hacer preguntas como
¿Cuando no llegan a terminar un sprint como lo solucionan?
¿como realizan estimaciones?
¿hacen retrospectivas? ¿como?
¿como es o funciona la estructura jerarquica?
Gracias de antemano a todos y perdón por el discurso.
Saludos,
Sonia
Saludos y perdon por el mio.
Daniel Ceillan
Blog: www.agile-patterns.com
Mario Nunes
Apr 2, 2012, 3:58:54 PM4/2/12
to agile...@googlegroups.com
Hola Sonia,
Te voy a responder bajo mi humilde experiencia y punto de vista. El ScM no tiene que ser "el lider" tecnológico del equipo, pero si forma parte del equipo de desarrollo. Esto implicitamente te empuja a volver al lado tecnológico. No obstante también tienes el perfil de Product Owner que no es tan tecnológico y que colabora estrechamente con un ScM para crear equipo y proyectos.
El ScM no sustituye al "analista" de un equipo de programadores, es uno más, pero fomenta la creación de equipo y trabaja para ello. No se desliga de las responsabilidades de los proyectos como ejecutor. El ScM es el facilitador, coach de equipo.
Bienvenida al mundo ágil, una vez que entras ya es dificil salir ^_^
Salu2.
--
Mario Nunes
http://twitter.com/mariotux
http://pensandoenred.com
Te voy a responder bajo mi humilde experiencia y punto de vista. El ScM no tiene que ser "el lider" tecnológico del equipo, pero si forma parte del equipo de desarrollo. Esto implicitamente te empuja a volver al lado tecnológico. No obstante también tienes el perfil de Product Owner que no es tan tecnológico y que colabora estrechamente con un ScM para crear equipo y proyectos.
El ScM no sustituye al "analista" de un equipo de programadores, es uno más, pero fomenta la creación de equipo y trabaja para ello. No se desliga de las responsabilidades de los proyectos como ejecutor. El ScM es el facilitador, coach de equipo.
Bienvenida al mundo ágil, una vez que entras ya es dificil salir ^_^
Salu2.
--
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.
--
Mario Nunes
http://twitter.com/mariotux
http://pensandoenred.com
Sonia Bravo
Apr 2, 2012, 4:07:35 PM4/2/12
to agile-spain
Perdón para nada!!!!
Al contrario, gracias por tu punto de vista que me es de gran ayuda.
Totalmente de acuerdo con que ahora hay empresas que se apuntan al
agilismo sin 'sentirlo y creer' en ello realmente. Eso supone otro
fracaso. Tanto para la empresa que al final demostrará que no cree en
ello como la frustración de aquellos que sí creen y tras poner su
empeño, esfuerzo e ilusión en llevarlo adelante se encuentran con
muros de piedra.
On 2 abr, 21:58, Daniel Ceillan <codigodan...@gmail.com> wrote:
Al contrario, gracias por tu punto de vista que me es de gran ayuda.
Totalmente de acuerdo con que ahora hay empresas que se apuntan al
agilismo sin 'sentirlo y creer' en ello realmente. Eso supone otro
fracaso. Tanto para la empresa que al final demostrará que no cree en
ello como la frustración de aquellos que sí creen y tras poner su
empeño, esfuerzo e ilusión en llevarlo adelante se encuentran con
muros de piedra.
On 2 abr, 21:58, Daniel Ceillan <codigodan...@gmail.com> wrote:
Sonia Bravo
Apr 2, 2012, 4:10:25 PM4/2/12
to agile-spain
Cierto, ya no puedo salir (ni quiero)! :-)
Yo tenía la idea (tal vez equivocada) de que el PO lo 'colocaría' el
cliente (obviamente, como no tenga alma ágil, mal vamos).
¿Realmente uno puede 'orientarse' a ser PO?
Debe ser que todo lo que escucho consiste en cómo ser un buen ScM y no
un buen PO (otro papel fundamental para que un proyecto tenga éxito,
obviamente).
Gracias!
On 2 abr, 21:58, Mario Nunes <ma...@pensandoenred.com> wrote:
> Hola Sonia,
>
> Te voy a responder bajo mi humilde experiencia y punto de vista. El ScM no
> tiene que ser "el lider" tecnológico del equipo, pero si forma parte del
> equipo de desarrollo. Esto implicitamente te empuja a volver al lado
> tecnológico. No obstante también tienes el perfil de Product Owner que no
> es tan tecnológico y que colabora estrechamente con un ScM para crear
> equipo y proyectos.
>
> El ScM no sustituye al "analista" de un equipo de programadores, es uno
> más, pero fomenta la creación de equipo y trabaja para ello. No se desliga
> de las responsabilidades de los proyectos como ejecutor. El ScM es el
> facilitador, coach de equipo.
>
> Bienvenida al mundo ágil, una vez que entras ya es dificil salir ^_^
>
> Salu2.
>
Yo tenía la idea (tal vez equivocada) de que el PO lo 'colocaría' el
cliente (obviamente, como no tenga alma ágil, mal vamos).
¿Realmente uno puede 'orientarse' a ser PO?
Debe ser que todo lo que escucho consiste en cómo ser un buen ScM y no
un buen PO (otro papel fundamental para que un proyecto tenga éxito,
obviamente).
Gracias!
On 2 abr, 21:58, Mario Nunes <ma...@pensandoenred.com> wrote:
> Hola Sonia,
>
> Te voy a responder bajo mi humilde experiencia y punto de vista. El ScM no
> tiene que ser "el lider" tecnológico del equipo, pero si forma parte del
> equipo de desarrollo. Esto implicitamente te empuja a volver al lado
> tecnológico. No obstante también tienes el perfil de Product Owner que no
> es tan tecnológico y que colabora estrechamente con un ScM para crear
> equipo y proyectos.
>
> El ScM no sustituye al "analista" de un equipo de programadores, es uno
> más, pero fomenta la creación de equipo y trabaja para ello. No se desliga
> de las responsabilidades de los proyectos como ejecutor. El ScM es el
> facilitador, coach de equipo.
>
> Bienvenida al mundo ágil, una vez que entras ya es dificil salir ^_^
>
> Salu2.
>
Adrian Perreau de Pinninck
Apr 2, 2012, 4:18:23 PM4/2/12
to agile...@googlegroups.com
Hola Sonia,
Paso una imagen sacada del libro de Lyssa Adkins "Coaching Agile Teams" donde muestra los diferentes caminos para llegar a Agile Coach. Parece que el tuyo será el de la derecha del todo. Lo que encuentro más difícil de tu caso será encontrar el primer equipo donde empezar a practicar. Será complicado que una empresa buscando un Scrum Master contrate a alguien sin experiencia para el puesto. Quizás deberías buscar la forma de empezar a aplicar conocimientos en tu empresa actual. Una posibilidad es empezar como product owner y buscarte un proveedor que ya sea ágil.
Muchos ánimos,
--
Paso una imagen sacada del libro de Lyssa Adkins "Coaching Agile Teams" donde muestra los diferentes caminos para llegar a Agile Coach. Parece que el tuyo será el de la derecha del todo. Lo que encuentro más difícil de tu caso será encontrar el primer equipo donde empezar a practicar. Será complicado que una empresa buscando un Scrum Master contrate a alguien sin experiencia para el puesto. Quizás deberías buscar la forma de empezar a aplicar conocimientos en tu empresa actual. Una posibilidad es empezar como product owner y buscarte un proveedor que ya sea ágil.
Muchos ánimos,
2012/4/2 Sonia Bravo <sonia...@gmail.com>
--
Adrián Perreau de Pinninck Bas, Ph.D
LinkedIn: http://es.linkedin.com/in/eidrien
Twitter: @eidrien
Juanma Gómez
Apr 2, 2012, 4:19:57 PM4/2/12
to agile...@googlegroups.com
Buenas!
Sonia, como te han comentado, el SM debe velar porque se cumplan los objetivos del equipo. Debe orientar (de ahí su faceta de coach), debe tratar de eliminar los impedimentos que puedan ir surgiendo, los posibles conflictos en el PO y los Stakeholders, etc. Algo muy importante que en numerosas ocasiones a un equipo sin un buen SM se le puede pasar es sacar el máximo partido a las retrospectivas. Algo también importante es que, muchas veces, las retros se convierten en algo rutinario y que deja de terner sentido para el equipo. Es en estas situaciones en las que el SM cobra más importancia para evitar que el equipo pierda el foco de la mejora continua.
Por otro lado, creo que también juega un papel muy importante como "pegamento" entre todos los roles del proyecto.
¿Es necesario estar a la última en tecnología? Yo diría que no, que es más importante saber "gestionar" a las personas y servir de lubricante en todas las fases del proceso ágil.
Un saludo para todos! :D
--
Juanma Gómez.Sonia Bravo
Apr 2, 2012, 4:38:24 PM4/2/12
to agile-spain
La imagen es realmente clarificadora! Resume muy bien los diferentes
itinerarios.
Lo que comentas es justamente algo que me preocupa: quién va a querer
contratar un SM sin experiencia :-(
Tu solución intermedia es la que veo más factible... Ahora toca
'evangelizar' a mi empresa. Ni imagináis la ardua tarea que es ésa
(aunque no desisto)...
Si finalmente veo que es imposible aplicar las metodologías ágiles en
mi empresa, buscaré mi lugar en otro lado.
Gracias!
On 2 abr, 22:18, Adrian Perreau de Pinninck <aperr...@gmail.com>
wrote:
> Screen shot 2012-04-02 at 22.12.43.png
> 127 KVerDescargar
itinerarios.
Lo que comentas es justamente algo que me preocupa: quién va a querer
contratar un SM sin experiencia :-(
Tu solución intermedia es la que veo más factible... Ahora toca
'evangelizar' a mi empresa. Ni imagináis la ardua tarea que es ésa
(aunque no desisto)...
Si finalmente veo que es imposible aplicar las metodologías ágiles en
mi empresa, buscaré mi lugar en otro lado.
Gracias!
On 2 abr, 22:18, Adrian Perreau de Pinninck <aperr...@gmail.com>
wrote:
> Hola Sonia,
>
> Paso una imagen sacada del libro de Lyssa Adkins "Coaching Agile Teams"
> donde muestra los diferentes caminos para llegar a Agile Coach. Parece que
> el tuyo será el de la derecha del todo. Lo que encuentro más difícil de tu
> caso será encontrar el primer equipo donde empezar a practicar. Será
> complicado que una empresa buscando un Scrum Master contrate a alguien sin
> experiencia para el puesto. Quizás deberías buscar la forma de empezar a
> aplicar conocimientos en tu empresa actual. Una posibilidad es empezar como
> product owner y buscarte un proveedor que ya sea ágil.
>
> Muchos ánimos,
>
> 2012/4/2 Sonia Bravo <sonia.br...@gmail.com>
>
> Paso una imagen sacada del libro de Lyssa Adkins "Coaching Agile Teams"
> donde muestra los diferentes caminos para llegar a Agile Coach. Parece que
> el tuyo será el de la derecha del todo. Lo que encuentro más difícil de tu
> caso será encontrar el primer equipo donde empezar a practicar. Será
> complicado que una empresa buscando un Scrum Master contrate a alguien sin
> experiencia para el puesto. Quizás deberías buscar la forma de empezar a
> aplicar conocimientos en tu empresa actual. Una posibilidad es empezar como
> product owner y buscarte un proveedor que ya sea ágil.
>
> Muchos ánimos,
>
> 127 KVerDescargar
Sonia Bravo
Apr 2, 2012, 4:42:11 PM4/2/12
to agile-spain
Gracias Juanma. Esa visión que das es la que yo tenía en mente y en la
que me motiva dirigir mi carrera profesional.
Creo que el SM debe velar y trabajar para que su equipo realmente crea
en Scrum y sea consciente de sus beneficios... Porque si no, el equipo
sólo lo hará 'porque lo dice éste que dice que es el SM'.
Lo que me sorprende y no logro entender es que aún haya personas (y lo
digo por propia experiencia, que lo veo día a día) que sea tan reacia
a las metodologías ágiles y en particular, Scrum.
On 2 abr, 22:19, Juanma Gómez <juanmagom...@gmail.com> wrote:
> Buenas!
>
> Sonia, como te han comentado, el SM debe velar porque se cumplan los
> objetivos del equipo. Debe orientar (de ahí su faceta de coach), debe
> tratar de eliminar los impedimentos que puedan ir surgiendo, los posibles
> conflictos en el PO y los Stakeholders, etc. Algo muy importante que en
> numerosas ocasiones a un equipo sin un buen SM se le puede pasar es sacar
> el máximo partido a las retrospectivas. Algo también importante es que,
> muchas veces, las retros se convierten en algo rutinario y que deja de
> terner sentido para el equipo. Es en estas situaciones en las que el SM
> cobra más importancia para evitar que el equipo pierda el foco de la mejora
> continua.
>
> Por otro lado, creo que también juega un papel muy importante como
> "pegamento" entre todos los roles del proyecto.
>
> ¿Es necesario estar a la última en tecnología? Yo diría que no, que es más
> importante saber "gestionar" a las personas y servir de lubricante en todas
> las fases del proceso ágil.
>
> Un saludo para todos! :D
> --
> Juanma Gómez.
> @JuanmaGomeR -http://es.linkedin.com/pub/juan-manuel-g%C3%B3mez-ramos/43/813/4a2-http://juanmagomez.wordpress.com
que me motiva dirigir mi carrera profesional.
Creo que el SM debe velar y trabajar para que su equipo realmente crea
en Scrum y sea consciente de sus beneficios... Porque si no, el equipo
sólo lo hará 'porque lo dice éste que dice que es el SM'.
Lo que me sorprende y no logro entender es que aún haya personas (y lo
digo por propia experiencia, que lo veo día a día) que sea tan reacia
a las metodologías ágiles y en particular, Scrum.
On 2 abr, 22:19, Juanma Gómez <juanmagom...@gmail.com> wrote:
> Buenas!
>
> Sonia, como te han comentado, el SM debe velar porque se cumplan los
> objetivos del equipo. Debe orientar (de ahí su faceta de coach), debe
> tratar de eliminar los impedimentos que puedan ir surgiendo, los posibles
> conflictos en el PO y los Stakeholders, etc. Algo muy importante que en
> numerosas ocasiones a un equipo sin un buen SM se le puede pasar es sacar
> el máximo partido a las retrospectivas. Algo también importante es que,
> muchas veces, las retros se convierten en algo rutinario y que deja de
> terner sentido para el equipo. Es en estas situaciones en las que el SM
> cobra más importancia para evitar que el equipo pierda el foco de la mejora
> continua.
>
> Por otro lado, creo que también juega un papel muy importante como
> "pegamento" entre todos los roles del proyecto.
>
> ¿Es necesario estar a la última en tecnología? Yo diría que no, que es más
> importante saber "gestionar" a las personas y servir de lubricante en todas
> las fases del proceso ágil.
>
> Un saludo para todos! :D
> --
> Juanma Gómez.
Juanma Gómez
Apr 2, 2012, 4:51:22 PM4/2/12
to agile...@googlegroups.com
El escepticismo frente a lo desconocido es algo normal en el ser humano. Creo que la importancia de las metodologías ágiles se descubre cuando uno las vive en sus propias carnes.
En la empresa en la que trabajo llevamos algo más de un año implantando Scrum. No es un camino fácil, y es normal que la gente no se sienta cómoda frente a los cambios que supone (cambia todo), y haya quien, como me pasó a mí en su momento, no se crea que esto de verdad funciona, y muy bien.
Ahí es donde entra en juego la labor de un buen coach que sea capaz de dirigir la transición. Al principio la mayoría de los que se suban al tren lo harán "porque lo dice el coach o el scrum master", pero tiempo después lo harán porque verán los beneficios que les trae tanto a nivel de equipo como a nivel individual.
Lo que te recomendaría, si tienes idea de implantarlo en tu empresa, es que busques dinámicas que ejemplifiquen cuál es nuestro día a día o, si pudieras, que intentaras organizar una jornada de formación sobre Scrum. Contar con una formación inicial es muy importante para que la gente entienda un poco cuál es el alcance del planteamiento ágil.
--
Juanma Gómez.Mario Nunes
Apr 2, 2012, 6:44:19 PM4/2/12
to agile...@googlegroups.com
No con todos los clientes se puede trabajar de forma ágil. A veces hace falta un perfíl que obtenga esa visión de negocio para resolver las necesidades al cliente. Aunque lo ideal es que el rol de PO lo pueda hacer el própio cliente, no siempre se puede conseguir. Es un restyling del JP :-) con visión ágil. La gestión del alcance del proyecto es su responsabilidad, aunque lo que se haga en las iteraciones sea responsabilidad del equipo (donde incluyo al PO, pero el no decide que es lo que se hace en la iteración, lo hace todo el equipo).
Un buen PO, es aquel que gestiona con eficiencia el alcance de proyecto. Aquél que valora la autogestión del equipo al que pertenece. El que consigue junto con el ScM, tener un equipo de alto rendimiento.
Es el perfíl camaleónico en áreas de negocio de clientes para trasladar esa necesidad al equipo. Aunque lo que estoy describiendo es "proxy manager" no sólo es lo que hace un buen PO. Como un miembro más de un equipo se encarga de trabajar en y para el equipo. Escalando dentro de la organización todos aquellos impedimentos que el ScM no tiene a su alcance. También gestiona los datos económicos del proyecto y el tiempo, no sólo el alcance... vamos... un sin fin de cosas ^_^
Los buenos PO escasean, no todos los JP que han "digi-evolucionado" a PO, son capaces de adaptarse al cambio.
Ser ágil, no es sólo una cuestión de seguir las normas metodológicas, es un cambio de filosofía en la actitud profesional y personal.
Salu2.
--
Un buen PO, es aquel que gestiona con eficiencia el alcance de proyecto. Aquél que valora la autogestión del equipo al que pertenece. El que consigue junto con el ScM, tener un equipo de alto rendimiento.
Es el perfíl camaleónico en áreas de negocio de clientes para trasladar esa necesidad al equipo. Aunque lo que estoy describiendo es "proxy manager" no sólo es lo que hace un buen PO. Como un miembro más de un equipo se encarga de trabajar en y para el equipo. Escalando dentro de la organización todos aquellos impedimentos que el ScM no tiene a su alcance. También gestiona los datos económicos del proyecto y el tiempo, no sólo el alcance... vamos... un sin fin de cosas ^_^
Los buenos PO escasean, no todos los JP que han "digi-evolucionado" a PO, son capaces de adaptarse al cambio.
Ser ágil, no es sólo una cuestión de seguir las normas metodológicas, es un cambio de filosofía en la actitud profesional y personal.
Salu2.
El 2 de abril de 2012 22:10, Sonia Bravo <sonia...@gmail.com> escribió:
--
Alfredo Casado
Apr 2, 2012, 8:46:56 PM4/2/12
to agile...@googlegroups.com
Yo empezaría por algo de perogrullo, cuanto más sepas de desarrollo de software más podrás ayudar como parte de un equipo que desarrolla software (sea como SM o como lo que sea). En mi opinión hay dos tipos perfiles fundamentales en todo proyecto software, el que conoce el negocio (define el problema a resolver) y el que conoce como resolverlo (define la solución). Soy bastante exceptico respecto a cualquier perfil que no se encuadre en alguna de estas dos clasificaciones con claridad. Si ni eres conocedor del problema a resolver ni eres experto en la solución a aplicar... sinceramente... ¿eres realmente necesario?. Me vais a permitir que por lo menos dude de la necesidad de estos roles de "facilitadores" puros, quizas en algunos contextos y en organizaciones complejas puedan ser utiles, pero como poco, yo me lo plantearía muy mucho antes de pagar un sueldo a alguien con este rol.
Yo soy SM y se podría decir que lider tecnico de facto, personalmente veo muchas dificultades en hacer un buen papel como scrum master si no puedo guiar a mi equipo también en el aspecto técnico, por ejemplo:
- ¿Que hago cuando no se termine un sprint bien por acumulación de bugs a ultima hora?, ¿como les enseño a escribir pruebas unitarias si no se hacerlo yo?. Les puedo mandar a un curso (otro gasto), o traer a un experto (otro nuevo gasto).
- ¿Que hago cuando surjan impedimentos técnicos?, cosas del tipo. "no estamos gestionando la politica de branch/mergues", "la integración continua se rompe continuamente", "he dejado de hacer pruebas porque me lleva demasiado tiempo escribirlas".
- ¿Como ganarse el respeto de un equipo de desarrolladores si no hablas su mismo idioma?
En mi opinión alguien que quiera hacer que un equipo sea verdaderamente agil y funcione (y no digo ser SM, agil > scrum) tiene que ser alguien que comprenda en profundidad tanto la parte técnica como la parte de gestión agil de un proyecto. En caso contrario necesitaras dos roles, el del SM facilitador y el del lider técnico agil, sinceramente, a mi me parece un lujo bastante caro cuando hay mucha gente capacitada para hacer las dos cosas.
Daniel Ceillan
Apr 2, 2012, 10:17:06 PM4/2/12
to agile...@googlegroups.com
El 2 de abril de 2012 21:46, Alfredo Casado <casado....@gmail.com> escribió:
Yo empezaría por algo de perogrullo, cuanto más sepas de desarrollo de software más podrás ayudar como parte de un equipo que desarrolla software (sea como SM o como lo que sea). En mi opinión hay dos tipos perfiles fundamentales en todo proyecto software, el que conoce el negocio (define el problema a resolver) y el que conoce como resolverlo (define la solución). Soy bastante exceptico respecto a cualquier perfil que no se encuadre en alguna de estas dos clasificaciones con claridad. Si ni eres conocedor del problema a resolver ni eres experto en la solución a aplicar... sinceramente... ¿eres realmente necesario?. Me vais a permitir que por lo menos dude de la necesidad de estos roles de "facilitadores" puros, quizas en algunos contextos y en organizaciones complejas puedan ser utiles, pero como poco, yo me lo plantearía muy mucho antes de pagar un sueldo a alguien con este rol.Yo soy SM y se podría decir que lider tecnico de facto, personalmente veo muchas dificultades en hacer un buen papel como scrum master si no puedo guiar a mi equipo también en el aspecto técnico, por ejemplo:- ¿Que hago cuando no se termine un sprint bien por acumulación de bugs a ultima hora?, ¿como les enseño a escribir pruebas unitarias si no se hacerlo yo?. Les puedo mandar a un curso (otro gasto), o traer a un experto (otro nuevo gasto).- ¿Que hago cuando surjan impedimentos técnicos?, cosas del tipo. "no estamos gestionando la politica de branch/mergues", "la integración continua se rompe continuamente", "he dejado de hacer pruebas porque me lleva demasiado tiempo escribirlas".- ¿Como ganarse el respeto de un equipo de desarrolladores si no hablas su mismo idioma?En mi opinión alguien que quiera hacer que un equipo sea verdaderamente agil y funcione (y no digo ser SM, agil > scrum) tiene que ser alguien que comprenda en profundidad tanto la parte técnica como la parte de gestión agil de un proyecto. En caso contrario necesitaras dos roles, el del SM facilitador y el del lider técnico agil, sinceramente, a mi me parece un lujo bastante caro cuando hay mucha gente capacitada para hacer las dos cosas.
Pero creo que estamos clasificando lobos grises. Y un poco de ejemplo no nos vendria nada mal, para por lo menos definir de que estamos hablando... :)
Sobre tecnicas de codeo, svn, git, integracion continua, TDD, BDD, FDD, XP, uml, y un largo etcetera si... es el conjunto de conocimientos requeribles para un SM.
Ser "experto Java", dominar la Inteligencia Artificial, dominio profundo de algoritmia, amplios conocimientos de matematicas, o de arquitectura de software, estos son diferentes de aquellos. Estos serian mas los conocimientos requeribles a un "lider tecnico". El SM seria un "lider agil".
Por supuesto que si tienes algun bocho que domina lo tecnico y lo agil es un excelente recurso. Pero no se hasta cuando se pueden llevar de la mano... ser coach agil requiere inteligencia social. Y en general, los expertos en matematicas e inteligencia artificial, no son gente sociable. Existen excepciones, pero en general no lo son.
Un buen SM es capaz de detectar, por ejemplo, la desmotivacion. Y a su vez es capaz de generar el ambiente motivante. Con conocimientos de psicologia, por dar otro ejemplo... me imagino que algun "super tecnico" cuando una pieza no funciona, te dira: "tirala y pon una nueva". Tendra logicas del tipo, "si algo no anda, hazlo andar"
No debemos olvidarnos de que nada de esto son "reglas". Justamente si lo consideramos reglas, es porque quizas tengamos una arquitectura mental de "lider tecnico", y por eso es que a muchisimos desarrolladores les cuesta migrar al agilismo.
Una variable muy clave es el tamaño y complejidad del proyecto. Si el proyecto es muy pequeño, el SM puede ser uno de los developers. Pero si el proyecto es muy complejo y grande, el SM no debera codear, y no debera ser ni tu mejor developer, ni tu lider tecnico. Porque seria un gran desperdicio, ademas de que es dificil que un "gran developer" se pueda convertir en "gran SM".
Otra cosa mas. Si bien podemos considerar al SM, idealmente, como un "líder natural", segun lo veo yo, no es un tipo de "jefe". Esto principalmente que la sola presencia de un jefe desmotiva. Y un largo etcetera...
Siendo el SM junto con el PO la conjuncion entre el mundo tecnico y el de los negocios, no creo que sean gastos innecesarios, y si creo que deben conocer ambos mundos para poder conectarlos.
Todo lo anterior es una vision personal en base a mi experiencia y conocimiento.
Saludos!
Daniel Marquez Medina
Apr 3, 2012, 2:44:37 AM4/3/12
to agile...@googlegroups.com
Buenas,
desde mi humilde visión, creo que debes centrarte en ser un buen SM aprendiendo sus liturgias, artefactos etc., más viendo que puedes tener inexperiencia. Si tienes que ayudar al equipo técnicamente... pues como diría alguno que anda por aquí... "que le den al equipo, es su problema!!! " :)
Siendo puristas, el SM vela por el proceso no por el equipo, aunque siendo practicos y mundanos (y yo soy de estos), tendrás que hacer mucho coaching y ayudarlos técnicamente todo lo posible, al igual que al PO, tendrás que enseñarlo. Eso sí, ya no depende de tí, dependerá que el equipo que tengas sea más maduro o inmaduro técnicamente, etc.
Mi consejo, si puede llamarse así, sería que te machacaras a ser un SM muy bueno, y que luego cuando tengas un equipo, ya te amoldes a su situación y necesidades, igual que con el PO, aunque por mi experiencia (que es relativamente poca), tienes mucho por hacer (aprender, leer, etc.)
Espero haberte ayudado, si necesitas referencias de lecturas, documentación, etc. ya sabes donde pedirlo.
Saludos,
PD: comentar que estoy de acuerdo con casi todas las respuestas dichas, al final el conocimiento busca la excelencia y contra más tengas mejor para todos.
Sonia Bravo
Apr 3, 2012, 3:41:25 AM4/3/12
to agile-spain
Muchas gracias por tu visión y aporte sobre el PO.
Creo que me he centrado tanto en el SM (tal vez porque es lo que más
me motiva) que he perdido un poco de vista al PO, cuando su labor es
tan esencial como la del SM y la del equipo en culminar con éxito un
proyecto.
Profundizaré más también en el mundo del PO.
On 3 abr, 00:44, Mario Nunes <ma...@pensandoenred.com> wrote:
> No con todos los clientes se puede trabajar de forma ágil. A veces hace
> falta un perfíl que obtenga esa visión de negocio para resolver las
> necesidades al cliente. Aunque lo ideal es que el rol de PO lo pueda hacer
> el própio cliente, no siempre se puede conseguir. Es un restyling del JP
> :-) con visión ágil. La gestión del alcance del proyecto es su
> responsabilidad, aunque lo que se haga en las iteraciones sea
> responsabilidad del equipo (donde incluyo al PO, pero el no decide que es
> lo que se hace en la iteración, lo hace todo el equipo).
>
> Un buen PO, es aquel que gestiona con eficiencia el alcance de proyecto.
> Aquél que valora la autogestión del equipo al que pertenece. El que
> consigue junto con el ScM, tener un equipo de alto rendimiento.
>
> Es el perfíl camaleónico en áreas de negocio de clientes para trasladar esa
> necesidad al equipo. Aunque lo que estoy describiendo es "proxy manager" no
> sólo es lo que hace un buen PO. Como un miembro más de un equipo se encarga
> de trabajar en y para el equipo. Escalando dentro de la organización todos
> aquellos impedimentos que el ScM no tiene a su alcance. También gestiona
> los datos económicos del proyecto y el tiempo, no sólo el alcance...
> vamos... un sin fin de cosas ^_^
>
> Los buenos PO escasean, no todos los JP que han "digi-evolucionado" a PO,
> son capaces de adaptarse al cambio.
>
> Ser ágil, no es sólo una cuestión de seguir las normas metodológicas, es un
> cambio de filosofía en la actitud profesional y personal.
>
> Salu2.
>
Creo que me he centrado tanto en el SM (tal vez porque es lo que más
me motiva) que he perdido un poco de vista al PO, cuando su labor es
tan esencial como la del SM y la del equipo en culminar con éxito un
proyecto.
Profundizaré más también en el mundo del PO.
On 3 abr, 00:44, Mario Nunes <ma...@pensandoenred.com> wrote:
> No con todos los clientes se puede trabajar de forma ágil. A veces hace
> falta un perfíl que obtenga esa visión de negocio para resolver las
> necesidades al cliente. Aunque lo ideal es que el rol de PO lo pueda hacer
> el própio cliente, no siempre se puede conseguir. Es un restyling del JP
> :-) con visión ágil. La gestión del alcance del proyecto es su
> responsabilidad, aunque lo que se haga en las iteraciones sea
> responsabilidad del equipo (donde incluyo al PO, pero el no decide que es
> lo que se hace en la iteración, lo hace todo el equipo).
>
> Un buen PO, es aquel que gestiona con eficiencia el alcance de proyecto.
> Aquél que valora la autogestión del equipo al que pertenece. El que
> consigue junto con el ScM, tener un equipo de alto rendimiento.
>
> Es el perfíl camaleónico en áreas de negocio de clientes para trasladar esa
> necesidad al equipo. Aunque lo que estoy describiendo es "proxy manager" no
> sólo es lo que hace un buen PO. Como un miembro más de un equipo se encarga
> de trabajar en y para el equipo. Escalando dentro de la organización todos
> aquellos impedimentos que el ScM no tiene a su alcance. También gestiona
> los datos económicos del proyecto y el tiempo, no sólo el alcance...
> vamos... un sin fin de cosas ^_^
>
> Los buenos PO escasean, no todos los JP que han "digi-evolucionado" a PO,
> son capaces de adaptarse al cambio.
>
> Ser ágil, no es sólo una cuestión de seguir las normas metodológicas, es un
> cambio de filosofía en la actitud profesional y personal.
>
> Salu2.
>
Eduardo Ferro
Apr 3, 2012, 3:52:40 AM4/3/12
to agile...@googlegroups.com
Buenas
--
Hasta Otra
http://www.eferro.net
http://twitter.com/#!/eferro (@eferro)
http://www.linkedin.com/in/eferro
Muchas gracias por tu visión y aporte sobre el PO.
Creo que me he centrado tanto en el SM (tal vez porque es lo que más
me motiva) que he perdido un poco de vista al PO, cuando su labor es
tan esencial como la del SM y la del equipo en culminar con éxito un
proyecto.
Profundizaré más también en el mundo del PO.
Quizás como introducción al mundo del PO, te pueda venir bien el libro: "Agile Product Management with Scrum: Creating Products That Customers Love"
Se lee muy fácil y se centra totalmente en el rol del PO como pieza fundamental para la creación de productos exitosos...
Hace nada he terminado el libro y la verdad es que me ha gustado bastante y creo que puede ser una lectura recomendable ahora que estás con esas inquietudes.
saludos
Hasta Otra
http://www.eferro.net
http://twitter.com/#!/eferro (@eferro)
http://www.linkedin.com/in/eferro
Sonia Bravo
Apr 3, 2012, 4:00:09 AM4/3/12
to agile-spain
Muchas gracias, Alfredo!
Estoy de acuerdo contigo en que cuanto más sepas de desarrollo (en
general, cuanto más sepas del entorno en el que te mueves...
Desarrollo software, financiero, industrial...), más puedes aportar y
ayudar al equipo.
Por eso desconfío de JP's/managers que he visto que no han tenido
experiencia real en desarrollo software (que no se han 'pegado'
programando). Es difícil que puedan entender muchos de los problemas
que le trasladará su equipo. De ahí que valore mi experiencia como
desfase por haber dejado de programar estos últimos años y alejarme de
la tecnología) no me hace un líder técnico al que mi equipo pueda
acudir.
Entiendo su idioma (cuando algún desarrollador me ha hablado en
términos más técnicos que no entiendo, derivados principalmente del
uso de una tecnología que yo no he manejado, busco información para
entender realmente de qué me está hablando y así poder entender el
problema, siempre contando con que la base técnica la tengo, dado mi
pasado, para poder investigar), pero si el equipo tiene un problema
técnico que no sepa resolver, difícilmente podré ayudarles.
Aunque también considero que si un equipo de desarrolladores
multidisciplinares se topa con un problema que entre todos no saben
resolver (pues aquí es fundamental las metodologías ágiles... La
comunicación... El trabajo en equipo... La visibilidad y la
transparencia... El Daily Scrum donde poner problemas en común...), me
daría un poco de miedo que la solución mágica la tenga que dar el SM.
Creo que el SM es quien ha de inculcar y velar por el uso de un buen
ecosistema para el desarrollo software, la integración continua, la
necesidad de las pruebas unitarias, etc...
No sé, tal vez mi duda está en que quieran ver en mí a una gurú del
desarrollo software y experta en tecnología, porque no lo soy.
Estuve en el Codemotion y si algo tengo claro es que este mundo cambia
y se mueve con una velocidad bárbara (por suerte). Y siento que 'no
estoy al día' de todas las tecnologías que ahora despuntan. Puedo leer
sobre ellas (soy informática y he desarrollado durante años. No es
algo que me sea ajeno) pero no seré una experta. Y como digo, no me
motiva especialmente ser una experta técnica en ninguna tecnología.
No sé si me explico.
Pero aunque no lo pareza, entiendo tu punto de vista Alfredo. Y apoyo
prácticamente todo lo que comentas :-)
Estoy de acuerdo contigo en que cuanto más sepas de desarrollo (en
general, cuanto más sepas del entorno en el que te mueves...
Desarrollo software, financiero, industrial...), más puedes aportar y
ayudar al equipo.
Por eso desconfío de JP's/managers que he visto que no han tenido
experiencia real en desarrollo software (que no se han 'pegado'
programando). Es difícil que puedan entender muchos de los problemas
que le trasladará su equipo. De ahí que valore mi experiencia como
analista/programadora Java durante 5 años.
Pero recononozco que mi experiencia como programadora (debido al
desfase por haber dejado de programar estos últimos años y alejarme de
la tecnología) no me hace un líder técnico al que mi equipo pueda
acudir.
Entiendo su idioma (cuando algún desarrollador me ha hablado en
términos más técnicos que no entiendo, derivados principalmente del
uso de una tecnología que yo no he manejado, busco información para
entender realmente de qué me está hablando y así poder entender el
problema, siempre contando con que la base técnica la tengo, dado mi
pasado, para poder investigar), pero si el equipo tiene un problema
técnico que no sepa resolver, difícilmente podré ayudarles.
Aunque también considero que si un equipo de desarrolladores
multidisciplinares se topa con un problema que entre todos no saben
resolver (pues aquí es fundamental las metodologías ágiles... La
comunicación... El trabajo en equipo... La visibilidad y la
transparencia... El Daily Scrum donde poner problemas en común...), me
daría un poco de miedo que la solución mágica la tenga que dar el SM.
Creo que el SM es quien ha de inculcar y velar por el uso de un buen
ecosistema para el desarrollo software, la integración continua, la
necesidad de las pruebas unitarias, etc...
No sé, tal vez mi duda está en que quieran ver en mí a una gurú del
desarrollo software y experta en tecnología, porque no lo soy.
Estuve en el Codemotion y si algo tengo claro es que este mundo cambia
y se mueve con una velocidad bárbara (por suerte). Y siento que 'no
estoy al día' de todas las tecnologías que ahora despuntan. Puedo leer
sobre ellas (soy informática y he desarrollado durante años. No es
algo que me sea ajeno) pero no seré una experta. Y como digo, no me
motiva especialmente ser una experta técnica en ninguna tecnología.
No sé si me explico.
Pero aunque no lo pareza, entiendo tu punto de vista Alfredo. Y apoyo
prácticamente todo lo que comentas :-)
German DZ
Apr 3, 2012, 4:06:26 AM4/3/12
to agile...@googlegroups.com
Respecto a los especialistas, los SM y esa variantes, hay un ensayo muy bueno de Scott Ambler al respecto que ayuda a entender que características son las que tienen valor y en que contexto.
Saludos
2012/4/3 Sonia Bravo <sonia...@gmail.com>
Sonia Bravo
Apr 3, 2012, 4:15:22 AM4/3/12
to agile-spain
Daniel, totalmente de acuerdo contigo. Te aseguro que en muchos
desarrolladores que he conocido, la parte 'social' brillaba por su
ausencia. Muchos eran excelentes técnicos a los que respetaba y
admiraba por su buen hacer. Pero en lo social había carencias y eso
también impacta en el equipo.
Ahí es donde me gusta trabajar y donde quiero aportar valor.
Aparte, como bien dices, quiero empaparme de verdad en técnicas de
codificación, SVN, integración continua, TDD, BDD, FDD, XP,
UML... Muchas las conozco ya y otras sólo de oídas. Así que quiero
aprender más.
Como se suele decir "hay faena pa' donde mires", así que paso a
paso... Hay tanto!!!
Gracias!
PD: Mi experiencia como desarrolladora estuvo ligada durante mucho
tiempo al mundo de la Inteligencia Artificial y ha sido una de las
etapas más interesantes en mi vida profesional :-)
On 3 abr, 04:17, Daniel Ceillan <codigodan...@gmail.com> wrote:
desarrolladores que he conocido, la parte 'social' brillaba por su
ausencia. Muchos eran excelentes técnicos a los que respetaba y
admiraba por su buen hacer. Pero en lo social había carencias y eso
también impacta en el equipo.
Ahí es donde me gusta trabajar y donde quiero aportar valor.
Aparte, como bien dices, quiero empaparme de verdad en técnicas de
codificación, SVN, integración continua, TDD, BDD, FDD, XP,
UML... Muchas las conozco ya y otras sólo de oídas. Así que quiero
aprender más.
Como se suele decir "hay faena pa' donde mires", así que paso a
paso... Hay tanto!!!
Gracias!
PD: Mi experiencia como desarrolladora estuvo ligada durante mucho
tiempo al mundo de la Inteligencia Artificial y ha sido una de las
etapas más interesantes en mi vida profesional :-)
On 3 abr, 04:17, Daniel Ceillan <codigodan...@gmail.com> wrote:
Sonia Bravo
Apr 3, 2012, 4:19:51 AM4/3/12
to agile-spain
De acuerdo contigo, Daniel (como dices, yo también estoy de acuerdo
con todo el mundo, porque creo que todos tienen razón desde su
experiencia y visión).
Apuntas algo muy importante: ser práctico y mundano. Teoría hay mucha
que es lo que no hago más que leer. Luego está el mundo real, el
cliente real, el equipo real, los problemas reales... Y habrá que dar
soluciones reales y ágiles puesto que no todo está en los libros.
Gracias, claro que has sido de ayuda! Y no descarto el solicitar más
referencias de lectura y documentación (ya tengo unos cuantos libros
pendientes de lectura que me han recomendado).
con todo el mundo, porque creo que todos tienen razón desde su
experiencia y visión).
Apuntas algo muy importante: ser práctico y mundano. Teoría hay mucha
que es lo que no hago más que leer. Luego está el mundo real, el
cliente real, el equipo real, los problemas reales... Y habrá que dar
soluciones reales y ágiles puesto que no todo está en los libros.
Gracias, claro que has sido de ayuda! Y no descarto el solicitar más
referencias de lectura y documentación (ya tengo unos cuantos libros
pendientes de lectura que me han recomendado).
Sonia Bravo
Apr 3, 2012, 4:21:30 AM4/3/12
to agile-spain
Justamente este fin de semana me han hablado de este libro! :-)
Otro libro que apunto a la lista... Me interesa mucho por tener una
visión más profunda del PO.
Gracias!
On 3 abr, 09:52, Eduardo Ferro <eduardo.ferro.ald...@gmail.com> wrote:
> Buenas
>
> 2012/4/3 Sonia Bravo <sonia.br...@gmail.com>
Otro libro que apunto a la lista... Me interesa mucho por tener una
visión más profunda del PO.
Gracias!
On 3 abr, 09:52, Eduardo Ferro <eduardo.ferro.ald...@gmail.com> wrote:
> Buenas
>
> 2012/4/3 Sonia Bravo <sonia.br...@gmail.com>
Sonia Bravo
Apr 3, 2012, 4:24:27 AM4/3/12
to agile-spain
Qué bueno! Voy a leerlo con detalle...
Gracias!!!
On 3 abr, 10:06, German DZ <g...@ndz.com.ar> wrote:
> Respecto a los especialistas, los SM y esa variantes, hay un ensayo muy
> bueno de Scott Ambler al respecto que ayuda a entender que características
> son las que tienen valor y en que contexto.
>
> http://www.agilemodeling.com/essays/generalizingSpecialists.htm
>
> Saludos
>
> 2012/4/3 Sonia Bravo <sonia.br...@gmail.com>> Muchas gracias, Alfredo!
Gracias!!!
On 3 abr, 10:06, German DZ <g...@ndz.com.ar> wrote:
> Respecto a los especialistas, los SM y esa variantes, hay un ensayo muy
> bueno de Scott Ambler al respecto que ayuda a entender que características
> son las que tienen valor y en que contexto.
>
> http://www.agilemodeling.com/essays/generalizingSpecialists.htm
>
> Saludos
>
Reply all
Reply to author
Forward
0 new messages