jorge, me ha encantado la idea de continuous development y quiero abrir un thread paralelo para no hacer ruido en el otro post.
Mi pregunta es ¿cómo encajar el rol de PO y Scrum Master en la propuesta? ¿Harían falta o el trabajo que llevaría no es suficiente para que su rol fuera full-time?
Yo veo dos similes posibles con otras profesiones: La pareja de bomberos que saben lo que tienen que hacer y sólo necesitan ser guiados a grosso modo? O como un maestro y un aprendiz al estilo craftmanship apprentice.
Ahora ya has abierto la caja de pandora y te toca intentar cerrarla :)
> ya que abres la caja de los truenos ;) mi opción con dos personas sería > continuous development: comunicación diaria, sentados cerca, retrospectiva > continua, planificación continua, entrega continua...
> scrum con menos de 4 me parece forzadillo y sobraría pizza :)
> 2012/2/14 Israel Alcázar <israelalca...@gmail.com>
>> Hola,
>> Nosotros hacemos Scrum con un equipo de 2 personas, un product owner y un >> scrum master / coach y no tenemos mayor problema por ser pocos. No entiendo >> muy bien que el número de personas afecte a scrum.
>> Saludos
>> Enviado desde mi dispositivo móvil >> El 14/02/2012 17:23, "Antonio de la Torre" <adelatorref...@gmail.com> >> escribió:
>> Hola:
>>> Creo que para empezar a ver útil Scrum, debería ser equipos entre 5 y >>> 7, porque si no, 3 se verá mucha burocracia: ScrumMaster, tablones, >>> scrum diario, etc. >>> Aunque todavía sería muy útil otras cosas como: Backlog, PO, Retros
>>> Según mi opinión, siempre compensa :-)
>>> Pero si Scrum como marco no se quiere asumir, siempre se pueden poner >>> en práctica muchas más prácticas ágiles
>>> El día 14 de febrero de 2012 16:00, Juanma Gómez >>> <juanmagom...@gmail.com> escribió: >>> > Hola!
>>> > Me imagino que la pregunta abarca un poco más de amplitud, ya que no >>> sólo >>> > cuenta el equipo de desarrollo como tal. Además, en el equipo del que >>> formo >>> > parte somos 3 y, de verdad, no tenemos mayor problema. Qué duda cabe >>> que con >>> > más gente seguramente podríamos desarrollar técnicas que ahora mismo >>> son muy >>> > costosas para nosotros.
>>> > Creo que lo mejor que puedes hacer es contratar a un Agile Coach y que >>> > valore cuánto fácil o difícil va a ser implementar métodos ágiles en tu >>> > empresa, ya que sin conocer bien vuestro tamaño y funcionamiento, todo >>> lo >>> > que podamos decir por aquí va a carecer de sentido...
>>> > Juanma Gómez.
>>> > El 14 de febrero de 2012 15:36, David Roncancio < >>> david.roncan...@gmail.com> >>> > escribió:
>>> >> Hola, yo he probado SCRUM con equipos muy pequeños 3, y empieza a >>> ponerse >>> >> feo el asunto por que a pesar de que alguno de los miembros haga por >>> varios >>> >> roles no se van a ver los mismos resultados, lo que se aconseja >>> generalmente >>> >> son equipos de 7+ o - 2 personas, es decir que lo mínimo para que te >>> buenos >>> >> resultados son 5 personas
>>> >> Cordialmente,
>>> >> David Roncancio >>> >> (+57) 3014311354
>>> >> On Tue, Feb 14, 2012 at 9:32 AM, jagutierrezm <jagutierr...@gmail.com
>>> >> wrote:
>>> >>> Saludos, en la empresa donde trabajo tienen la idea que para >>> >>> implementar SCRUM se necesita un equipo muy grande para poder >>> >>> implementar SCRUM. >>> >>> En su experiencia, ¿Cual es la cantidad mínima y la cantidad optima >>> >>> para implementar SCRUM? Tomando en cuenta que una misma persona puede >>> >>> cumplir varios roles
>>> >>> -- >>> >>> 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.
>>> >> -- >>> >> 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.
>>> > -- >>> > 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.
>>> -- >>> 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.
>>> -- >> 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.
> -- > 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.
el po para mí es imprescindible en el formato que sea: po, po proxy, responsable funcional, juan pérez... para dos dev no veo necesario un sm, para tres te lo puedes pensar
para mí, el símil sería un grupo de jazz, pero cada equipo y contexto es un ejemplo en sí mismo, digo yo
2012/2/14 Adrian Perreau de Pinninck <aperr...@gmail.com>
> jorge, me ha encantado la idea de continuous development y quiero abrir un > thread paralelo para no hacer ruido en el otro post.
> Mi pregunta es ¿cómo encajar el rol de PO y Scrum Master en la propuesta? > ¿Harían falta o el trabajo que llevaría no es suficiente para que su rol > fuera full-time?
> Yo veo dos similes posibles con otras profesiones: > La pareja de bomberos que saben lo que tienen que hacer y sólo necesitan > ser guiados a grosso modo? > O como un maestro y un aprendiz al estilo craftmanship apprentice.
> Ahora ya has abierto la caja de pandora y te toca intentar cerrarla :)
>> ya que abres la caja de los truenos ;) mi opción con dos personas sería >> continuous development: comunicación diaria, sentados cerca, retrospectiva >> continua, planificación continua, entrega continua...
>> scrum con menos de 4 me parece forzadillo y sobraría pizza :)
>> 2012/2/14 Israel Alcázar <israelalca...@gmail.com>
>>> Hola,
>>> Nosotros hacemos Scrum con un equipo de 2 personas, un product owner y >>> un scrum master / coach y no tenemos mayor problema por ser pocos. No >>> entiendo muy bien que el número de personas afecte a scrum.
>>> Saludos
>>> Enviado desde mi dispositivo móvil >>> El 14/02/2012 17:23, "Antonio de la Torre" <adelatorref...@gmail.com> >>> escribió:
>>> Hola:
>>>> Creo que para empezar a ver útil Scrum, debería ser equipos entre 5 y >>>> 7, porque si no, 3 se verá mucha burocracia: ScrumMaster, tablones, >>>> scrum diario, etc. >>>> Aunque todavía sería muy útil otras cosas como: Backlog, PO, Retros
>>>> Según mi opinión, siempre compensa :-)
>>>> Pero si Scrum como marco no se quiere asumir, siempre se pueden poner >>>> en práctica muchas más prácticas ágiles
>>>> El día 14 de febrero de 2012 16:00, Juanma Gómez >>>> <juanmagom...@gmail.com> escribió: >>>> > Hola!
>>>> > Me imagino que la pregunta abarca un poco más de amplitud, ya que no >>>> sólo >>>> > cuenta el equipo de desarrollo como tal. Además, en el equipo del que >>>> formo >>>> > parte somos 3 y, de verdad, no tenemos mayor problema. Qué duda cabe >>>> que con >>>> > más gente seguramente podríamos desarrollar técnicas que ahora mismo >>>> son muy >>>> > costosas para nosotros.
>>>> > Creo que lo mejor que puedes hacer es contratar a un Agile Coach y que >>>> > valore cuánto fácil o difícil va a ser implementar métodos ágiles en >>>> tu >>>> > empresa, ya que sin conocer bien vuestro tamaño y funcionamiento, >>>> todo lo >>>> > que podamos decir por aquí va a carecer de sentido...
>>>> > Juanma Gómez.
>>>> > El 14 de febrero de 2012 15:36, David Roncancio < >>>> david.roncan...@gmail.com> >>>> > escribió:
>>>> >> Hola, yo he probado SCRUM con equipos muy pequeños 3, y empieza a >>>> ponerse >>>> >> feo el asunto por que a pesar de que alguno de los miembros haga por >>>> varios >>>> >> roles no se van a ver los mismos resultados, lo que se aconseja >>>> generalmente >>>> >> son equipos de 7+ o - 2 personas, es decir que lo mínimo para que te >>>> buenos >>>> >> resultados son 5 personas
>>>> >> Cordialmente,
>>>> >> David Roncancio >>>> >> (+57) 3014311354
>>>> >> On Tue, Feb 14, 2012 at 9:32 AM, jagutierrezm < >>>> jagutierr...@gmail.com> >>>> >> wrote:
>>>> >>> Saludos, en la empresa donde trabajo tienen la idea que para >>>> >>> implementar SCRUM se necesita un equipo muy grande para poder >>>> >>> implementar SCRUM. >>>> >>> En su experiencia, ¿Cual es la cantidad mínima y la cantidad optima >>>> >>> para implementar SCRUM? Tomando en cuenta que una misma persona >>>> puede >>>> >>> cumplir varios roles
>>>> >>> -- >>>> >>> 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.
>>>> >> -- >>>> >> 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.
>>>> > -- >>>> > 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.
>>>> -- >>>> 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.
>>>> -- >>> 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.
>> -- >> 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.
> -- > 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.
Creo el concepto de desarrollo continuo es el reto para la organizacion interna de cualquier equipo. Otra cosa es que sea alcanzable, sea por la composicion del equipo, el desarrollo en cuestion o el tamano del equipo.
Desde luego me parece que no hace falta un SM. Por un lado, no es Scrum, por otro lado, un equipo asi no necesita un agente de cambio como tal.
Desde la perspectiva de cliente puede ser demasiado agil, aunque tengas un PO espabilado (si creo que necesitas un PO), dado que entregas continuas requieren mas implicacion, lo que no siempre es posible.
Lo del Jazz me gusta, aunque suelen ser varios solistas que tocan un tema y uno suele hacer un solo y los demas acompanan. Por otro lado, si hacen una buena composicion pregunta-respuesta ya se parece bastante a un equipo de alto rendimiento.
Un saludo,
Harald
Adrian: la mesa redonda esta manana ha sido bastante interesante.
Am 14/02/2012 um 21:59 schrieb jorge <jorge.b...@gmail.com>:
> el po para mí es imprescindible en el formato que sea: po, po proxy, responsable funcional, juan pérez... > para dos dev no veo necesario un sm, para tres te lo puedes pensar
> para mí, el símil sería un grupo de jazz, pero cada equipo y contexto es un ejemplo en sí mismo, digo yo
> 2012/2/14 Adrian Perreau de Pinninck <aperr...@gmail.com> > jorge, me ha encantado la idea de continuous development y quiero abrir un thread paralelo para no hacer ruido en el otro post.
> Mi pregunta es ¿cómo encajar el rol de PO y Scrum Master en la propuesta? > ¿Harían falta o el trabajo que llevaría no es suficiente para que su rol fuera full-time?
> Yo veo dos similes posibles con otras profesiones: > La pareja de bomberos que saben lo que tienen que hacer y sólo necesitan ser guiados a grosso modo? > O como un maestro y un aprendiz al estilo craftmanship apprentice.
> Ahora ya has abierto la caja de pandora y te toca intentar cerrarla :)
> 2012/2/14 jorge <jorge.b...@gmail.com> > por poder...
> ya que abres la caja de los truenos ;) mi opción con dos personas sería continuous development: comunicación diaria, sentados cerca, retrospectiva continua, planificación continua, entrega continua...
> scrum con menos de 4 me parece forzadillo y sobraría pizza :)
> 2012/2/14 Israel Alcázar <israelalca...@gmail.com> > Hola,
> Nosotros hacemos Scrum con un equipo de 2 personas, un product owner y un scrum master / coach y no tenemos mayor problema por ser pocos. No entiendo muy bien que el número de personas afecte a scrum.
> Saludos
> Enviado desde mi dispositivo móvil
> El 14/02/2012 17:23, "Antonio de la Torre" <adelatorref...@gmail.com> escribió:
> Hola:
> Creo que para empezar a ver útil Scrum, debería ser equipos entre 5 y > 7, porque si no, 3 se verá mucha burocracia: ScrumMaster, tablones, > scrum diario, etc. > Aunque todavía sería muy útil otras cosas como: Backlog, PO, Retros
> Según mi opinión, siempre compensa :-)
> Pero si Scrum como marco no se quiere asumir, siempre se pueden poner > en práctica muchas más prácticas ágiles
> El día 14 de febrero de 2012 16:00, Juanma Gómez > <juanmagom...@gmail.com> escribió: > > Hola!
> > Me imagino que la pregunta abarca un poco más de amplitud, ya que no sólo > > cuenta el equipo de desarrollo como tal. Además, en el equipo del que formo > > parte somos 3 y, de verdad, no tenemos mayor problema. Qué duda cabe que con > > más gente seguramente podríamos desarrollar técnicas que ahora mismo son muy > > costosas para nosotros.
> > Creo que lo mejor que puedes hacer es contratar a un Agile Coach y que > > valore cuánto fácil o difícil va a ser implementar métodos ágiles en tu > > empresa, ya que sin conocer bien vuestro tamaño y funcionamiento, todo lo > > que podamos decir por aquí va a carecer de sentido...
> > Juanma Gómez.
> > El 14 de febrero de 2012 15:36, David Roncancio <david.roncan...@gmail.com> > > escribió:
> >> Hola, yo he probado SCRUM con equipos muy pequeños 3, y empieza a ponerse > >> feo el asunto por que a pesar de que alguno de los miembros haga por varios > >> roles no se van a ver los mismos resultados, lo que se aconseja generalmente > >> son equipos de 7+ o - 2 personas, es decir que lo mínimo para que te buenos > >> resultados son 5 personas
> >> Cordialmente,
> >> David Roncancio > >> (+57) 3014311354
> >> On Tue, Feb 14, 2012 at 9:32 AM, jagutierrezm <jagutierr...@gmail.com> > >> wrote:
> >>> Saludos, en la empresa donde trabajo tienen la idea que para > >>> implementar SCRUM se necesita un equipo muy grande para poder > >>> implementar SCRUM. > >>> En su experiencia, ¿Cual es la cantidad mínima y la cantidad optima > >>> para implementar SCRUM? Tomando en cuenta que una misma persona puede > >>> cumplir varios roles
> >>> -- > >>> 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.
> >> -- > >> 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.
> > -- > > 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.
> -- > 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.
> -- > 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.
> -- > 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.
> -- > 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.
> -- > 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.
> Creo el concepto de desarrollo continuo es el reto para la organizacion > interna de cualquier equipo. Otra cosa es que sea alcanzable, sea por la > composicion del equipo, el desarrollo en cuestion o el tamano del equipo.
> Desde luego me parece que no hace falta un SM. Por un lado, no es Scrum, > por otro lado, un equipo asi no necesita un agente de cambio como tal.
> Desde la perspectiva de cliente puede ser demasiado agil, aunque tengas un > PO espabilado (si creo que necesitas un PO), dado que entregas continuas > requieren mas implicacion, lo que no siempre es posible.
> Lo del Jazz me gusta, aunque suelen ser varios solistas que tocan un tema > y uno suele hacer un solo y los demas acompanan. Por otro lado, si hacen > una buena composicion pregunta-respuesta ya se parece bastante a un equipo > de alto rendimiento.
> Un saludo,
> Harald
> Adrian: la mesa redonda esta manana ha sido bastante interesante.
> Am 14/02/2012 um 21:59 schrieb jorge <jorge.b...@gmail.com>:
> escoge lo que quieras del menú ;)
> el po para mí es imprescindible en el formato que sea: po, po proxy, > responsable funcional, juan pérez... > para dos dev no veo necesario un sm, para tres te lo puedes pensar
> para mí, el símil sería un grupo de jazz, pero cada equipo y contexto es > un ejemplo en sí mismo, digo yo
> 2012/2/14 Adrian Perreau de Pinninck <aperr...@gmail.com>
>> jorge, me ha encantado la idea de continuous development y quiero abrir >> un thread paralelo para no hacer ruido en el otro post.
>> Mi pregunta es ¿cómo encajar el rol de PO y Scrum Master en la propuesta? >> ¿Harían falta o el trabajo que llevaría no es suficiente para que su rol >> fuera full-time?
>> Yo veo dos similes posibles con otras profesiones: >> La pareja de bomberos que saben lo que tienen que hacer y sólo necesitan >> ser guiados a grosso modo? >> O como un maestro y un aprendiz al estilo craftmanship apprentice.
>> Ahora ya has abierto la caja de pandora y te toca intentar cerrarla :)
>>> ya que abres la caja de los truenos ;) mi opción con dos personas sería >>> continuous development: comunicación diaria, sentados cerca, retrospectiva >>> continua, planificación continua, entrega continua...
>>> scrum con menos de 4 me parece forzadillo y sobraría pizza :)
>>> 2012/2/14 Israel Alcázar <israelalca...@gmail.com>
>>>> Hola,
>>>> Nosotros hacemos Scrum con un equipo de 2 personas, un product owner y >>>> un scrum master / coach y no tenemos mayor problema por ser pocos. No >>>> entiendo muy bien que el número de personas afecte a scrum.
>>>> Saludos
>>>> Enviado desde mi dispositivo móvil >>>> El 14/02/2012 17:23, "Antonio de la Torre" <adelatorref...@gmail.com> >>>> escribió:
>>>> Hola:
>>>>> Creo que para empezar a ver útil Scrum, debería ser equipos entre 5 y >>>>> 7, porque si no, 3 se verá mucha burocracia: ScrumMaster, tablones, >>>>> scrum diario, etc. >>>>> Aunque todavía sería muy útil otras cosas como: Backlog, PO, Retros
>>>>> Según mi opinión, siempre compensa :-)
>>>>> Pero si Scrum como marco no se quiere asumir, siempre se pueden poner >>>>> en práctica muchas más prácticas ágiles
>>>>> El día 14 de febrero de 2012 16:00, Juanma Gómez >>>>> <juanmagom...@gmail.com> escribió: >>>>> > Hola!
>>>>> > Me imagino que la pregunta abarca un poco más de amplitud, ya que no >>>>> sólo >>>>> > cuenta el equipo de desarrollo como tal. Además, en el equipo del >>>>> que formo >>>>> > parte somos 3 y, de verdad, no tenemos mayor problema. Qué duda cabe >>>>> que con >>>>> > más gente seguramente podríamos desarrollar técnicas que ahora mismo >>>>> son muy >>>>> > costosas para nosotros.
>>>>> > Creo que lo mejor que puedes hacer es contratar a un Agile Coach y >>>>> que >>>>> > valore cuánto fácil o difícil va a ser implementar métodos ágiles en >>>>> tu >>>>> > empresa, ya que sin conocer bien vuestro tamaño y funcionamiento, >>>>> todo lo >>>>> > que podamos decir por aquí va a carecer de sentido...
>>>>> > Juanma Gómez.
>>>>> > El 14 de febrero de 2012 15:36, David Roncancio < >>>>> david.roncan...@gmail.com> >>>>> > escribió:
>>>>> >> Hola, yo he probado SCRUM con equipos muy pequeños 3, y empieza a >>>>> ponerse >>>>> >> feo el asunto por que a pesar de que alguno de los miembros haga >>>>> por varios >>>>> >> roles no se van a ver los mismos resultados, lo que se aconseja >>>>> generalmente >>>>> >> son equipos de 7+ o - 2 personas, es decir que lo mínimo para que >>>>> te buenos >>>>> >> resultados son 5 personas
>>>>> >> Cordialmente,
>>>>> >> David Roncancio >>>>> >> (+57) 3014311354
>>>>> >> On Tue, Feb 14, 2012 at 9:32 AM, jagutierrezm < >>>>> jagutierr...@gmail.com> >>>>> >> wrote:
>>>>> >>> Saludos, en la empresa donde trabajo tienen la idea que para >>>>> >>> implementar SCRUM se necesita un equipo muy grande para poder >>>>> >>> implementar SCRUM. >>>>> >>> En su experiencia, ¿Cual es la cantidad mínima y la cantidad optima >>>>> >>> para implementar SCRUM? Tomando en cuenta que una misma persona >>>>> puede >>>>> >>> cumplir varios roles
>>>>> >>> -- >>>>> >>> 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.
>>>>> >> -- >>>>> >> 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.
>>>>> > -- >>>>> > 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.
>>>>> -- >>>>> 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.
>>>>> -- >>>> 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.
>>> -- >>> 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.
>> -- >> 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.
> -- > 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.
> -- > 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
Perdonadme que discrepe con vosotros. Si bien es cierto que un rol de SM como tal quizás no hiciera falta (al fin y al cabo si no se hace Scrum para que un SM) si que creo que podría ser necesaria la labor de un Coach. Al fin y al cabo que un equipo sea de alto rendimiento o no o que se sigan buenas prácticas, etc no depende del número de personas que formen el equipo sino de lo motivadas, disciplinadas e involucradas que esten. Por tanto, podría ser necesaria esta figura de Coach que oriente/aconseje/ayude al equipo (y al P.O) a mejorar y motivarles.
Tengo pendiente escribir un post hablando de todo esto...algo así como "Los equipos auto organizados no existen" (promete polémica advierto).
Adrian, voy buscando las cámaras y al "Super" para hacer un Development Big Brother? :D.
Saludos,
El 14 de febrero de 2012 23:40, Adrian Perreau de Pinninck < aperr...@gmail.com> escribió:
>> Creo el concepto de desarrollo continuo es el reto para la organizacion >> interna de cualquier equipo. Otra cosa es que sea alcanzable, sea por la >> composicion del equipo, el desarrollo en cuestion o el tamano del equipo.
>> Desde luego me parece que no hace falta un SM. Por un lado, no es Scrum, >> por otro lado, un equipo asi no necesita un agente de cambio como tal.
>> Desde la perspectiva de cliente puede ser demasiado agil, aunque tengas >> un PO espabilado (si creo que necesitas un PO), dado que entregas continuas >> requieren mas implicacion, lo que no siempre es posible.
>> Lo del Jazz me gusta, aunque suelen ser varios solistas que tocan un tema >> y uno suele hacer un solo y los demas acompanan. Por otro lado, si hacen >> una buena composicion pregunta-respuesta ya se parece bastante a un equipo >> de alto rendimiento.
>> Un saludo,
>> Harald
>> Adrian: la mesa redonda esta manana ha sido bastante interesante.
>> Am 14/02/2012 um 21:59 schrieb jorge <jorge.b...@gmail.com>:
>> escoge lo que quieras del menú ;)
>> el po para mí es imprescindible en el formato que sea: po, po proxy, >> responsable funcional, juan pérez... >> para dos dev no veo necesario un sm, para tres te lo puedes pensar
>> para mí, el símil sería un grupo de jazz, pero cada equipo y contexto es >> un ejemplo en sí mismo, digo yo
>> 2012/2/14 Adrian Perreau de Pinninck <aperr...@gmail.com>
>>> jorge, me ha encantado la idea de continuous development y quiero abrir >>> un thread paralelo para no hacer ruido en el otro post.
>>> Mi pregunta es ¿cómo encajar el rol de PO y Scrum Master en la propuesta? >>> ¿Harían falta o el trabajo que llevaría no es suficiente para que su rol >>> fuera full-time?
>>> Yo veo dos similes posibles con otras profesiones: >>> La pareja de bomberos que saben lo que tienen que hacer y sólo necesitan >>> ser guiados a grosso modo? >>> O como un maestro y un aprendiz al estilo craftmanship apprentice.
>>> Ahora ya has abierto la caja de pandora y te toca intentar cerrarla :)
>>>> ya que abres la caja de los truenos ;) mi opción con dos personas sería >>>> continuous development: comunicación diaria, sentados cerca, retrospectiva >>>> continua, planificación continua, entrega continua...
>>>> scrum con menos de 4 me parece forzadillo y sobraría pizza :)
>>>> 2012/2/14 Israel Alcázar <israelalca...@gmail.com>
>>>>> Hola,
>>>>> Nosotros hacemos Scrum con un equipo de 2 personas, un product owner y >>>>> un scrum master / coach y no tenemos mayor problema por ser pocos. No >>>>> entiendo muy bien que el número de personas afecte a scrum.
>>>>> Saludos
>>>>> Enviado desde mi dispositivo móvil >>>>> El 14/02/2012 17:23, "Antonio de la Torre" <adelatorref...@gmail.com> >>>>> escribió:
>>>>> Hola:
>>>>>> Creo que para empezar a ver útil Scrum, debería ser equipos entre 5 y >>>>>> 7, porque si no, 3 se verá mucha burocracia: ScrumMaster, tablones, >>>>>> scrum diario, etc. >>>>>> Aunque todavía sería muy útil otras cosas como: Backlog, PO, Retros
>>>>>> Según mi opinión, siempre compensa :-)
>>>>>> Pero si Scrum como marco no se quiere asumir, siempre se pueden poner >>>>>> en práctica muchas más prácticas ágiles
>>>>>> El día 14 de febrero de 2012 16:00, Juanma Gómez >>>>>> <juanmagom...@gmail.com> escribió: >>>>>> > Hola!
>>>>>> > Me imagino que la pregunta abarca un poco más de amplitud, ya que >>>>>> no sólo >>>>>> > cuenta el equipo de desarrollo como tal. Además, en el equipo del >>>>>> que formo >>>>>> > parte somos 3 y, de verdad, no tenemos mayor problema. Qué duda >>>>>> cabe que con >>>>>> > más gente seguramente podríamos desarrollar técnicas que ahora >>>>>> mismo son muy >>>>>> > costosas para nosotros.
>>>>>> > Creo que lo mejor que puedes hacer es contratar a un Agile Coach y >>>>>> que >>>>>> > valore cuánto fácil o difícil va a ser implementar métodos ágiles >>>>>> en tu >>>>>> > empresa, ya que sin conocer bien vuestro tamaño y funcionamiento, >>>>>> todo lo >>>>>> > que podamos decir por aquí va a carecer de sentido...
>>>>>> > Juanma Gómez.
>>>>>> > El 14 de febrero de 2012 15:36, David Roncancio < >>>>>> david.roncan...@gmail.com> >>>>>> > escribió:
>>>>>> >> Hola, yo he probado SCRUM con equipos muy pequeños 3, y empieza a >>>>>> ponerse >>>>>> >> feo el asunto por que a pesar de que alguno de los miembros haga >>>>>> por varios >>>>>> >> roles no se van a ver los mismos resultados, lo que se aconseja >>>>>> generalmente >>>>>> >> son equipos de 7+ o - 2 personas, es decir que lo mínimo para que >>>>>> te buenos >>>>>> >> resultados son 5 personas
>>>>>> >> Cordialmente,
>>>>>> >> David Roncancio >>>>>> >> (+57) 3014311354
>>>>>> >> On Tue, Feb 14, 2012 at 9:32 AM, jagutierrezm < >>>>>> jagutierr...@gmail.com> >>>>>> >> wrote:
>>>>>> >>> Saludos, en la empresa donde trabajo tienen la idea que para >>>>>> >>> implementar SCRUM se necesita un equipo muy grande para poder >>>>>> >>> implementar SCRUM. >>>>>> >>> En su experiencia, ¿Cual es la cantidad mínima y la cantidad >>>>>> optima >>>>>> >>> para implementar SCRUM? Tomando en cuenta que una misma persona >>>>>> puede >>>>>> >>> cumplir varios roles
>>>>>> >>> -- >>>>>> >>> 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.
>>>>>> >> -- >>>>>> >> 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.
>>>>>> > -- >>>>>> > 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.
>>>>>> -- >>>>>> 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.
>>>>>> -- >>>>> 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.
>>>> -- >>>> 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.
Jajaja. A ver si cuando coincidamos intercambiamos impresiones sobre cómo nos va a con los equipos pequeños distribuidos. Espero tu artículo. Te doy toda la razón en que la motivación es difícil de mantener.
Saludos.
PD. Lanzo idea para mejorar la reputación de IT. Hacer un reality show en la MTV en una empresa estilo Atlassian (wink, wink)
2012/2/14 Israel Alcázar <israelalca...@gmail.com>
> Perdonadme que discrepe con vosotros. Si bien es cierto que un rol de SM > como tal quizás no hiciera falta (al fin y al cabo si no se hace Scrum para > que un SM) si que creo que podría ser necesaria la labor de un Coach. Al > fin y al cabo que un equipo sea de alto rendimiento o no o que se sigan > buenas prácticas, etc no depende del número de personas que formen el > equipo sino de lo motivadas, disciplinadas e involucradas que esten. Por > tanto, podría ser necesaria esta figura de Coach que oriente/aconseje/ayude > al equipo (y al P.O) a mejorar y motivarles.
> Tengo pendiente escribir un post hablando de todo esto...algo así como > "Los equipos auto organizados no existen" (promete polémica advierto).
> Adrian, voy buscando las cámaras y al "Super" para hacer un Development > Big Brother? :D.
> Saludos,
> El 14 de febrero de 2012 23:40, Adrian Perreau de Pinninck < > aperr...@gmail.com> escribió:
> Gracias Harald, no sabía que andabas por ahí. ¿Cómo que no me has saludado?
>> En cuanto a lo del SM yo también creo que su rol no debería ser >> necesario. Sería interesante observar a un equipo así. Israel, ¿te atreves?
>>> Creo el concepto de desarrollo continuo es el reto para la organizacion >>> interna de cualquier equipo. Otra cosa es que sea alcanzable, sea por la >>> composicion del equipo, el desarrollo en cuestion o el tamano del equipo.
>>> Desde luego me parece que no hace falta un SM. Por un lado, no es Scrum, >>> por otro lado, un equipo asi no necesita un agente de cambio como tal.
>>> Desde la perspectiva de cliente puede ser demasiado agil, aunque tengas >>> un PO espabilado (si creo que necesitas un PO), dado que entregas continuas >>> requieren mas implicacion, lo que no siempre es posible.
>>> Lo del Jazz me gusta, aunque suelen ser varios solistas que tocan un >>> tema y uno suele hacer un solo y los demas acompanan. Por otro lado, si >>> hacen una buena composicion pregunta-respuesta ya se parece bastante a un >>> equipo de alto rendimiento.
>>> Un saludo,
>>> Harald
>>> Adrian: la mesa redonda esta manana ha sido bastante interesante.
>>> Am 14/02/2012 um 21:59 schrieb jorge <jorge.b...@gmail.com>:
>>> escoge lo que quieras del menú ;)
>>> el po para mí es imprescindible en el formato que sea: po, po proxy, >>> responsable funcional, juan pérez... >>> para dos dev no veo necesario un sm, para tres te lo puedes pensar
>>> para mí, el símil sería un grupo de jazz, pero cada equipo y contexto es >>> un ejemplo en sí mismo, digo yo
>>> 2012/2/14 Adrian Perreau de Pinninck <aperr...@gmail.com>
>>>> jorge, me ha encantado la idea de continuous development y quiero abrir >>>> un thread paralelo para no hacer ruido en el otro post.
>>>> Mi pregunta es ¿cómo encajar el rol de PO y Scrum Master en la >>>> propuesta? >>>> ¿Harían falta o el trabajo que llevaría no es suficiente para que su >>>> rol fuera full-time?
>>>> Yo veo dos similes posibles con otras profesiones: >>>> La pareja de bomberos que saben lo que tienen que hacer y sólo >>>> necesitan ser guiados a grosso modo? >>>> O como un maestro y un aprendiz al estilo craftmanship apprentice.
>>>> Ahora ya has abierto la caja de pandora y te toca intentar cerrarla :)
>>>>> ya que abres la caja de los truenos ;) mi opción con dos personas >>>>> sería continuous development: comunicación diaria, sentados cerca, >>>>> retrospectiva continua, planificación continua, entrega continua...
>>>>> scrum con menos de 4 me parece forzadillo y sobraría pizza :)
>>>>> 2012/2/14 Israel Alcázar <israelalca...@gmail.com>
>>>>>> Hola,
>>>>>> Nosotros hacemos Scrum con un equipo de 2 personas, un product owner >>>>>> y un scrum master / coach y no tenemos mayor problema por ser pocos. No >>>>>> entiendo muy bien que el número de personas afecte a scrum.
>>>>>> Saludos
>>>>>> Enviado desde mi dispositivo móvil >>>>>> El 14/02/2012 17:23, "Antonio de la Torre" <adelatorref...@gmail.com> >>>>>> escribió:
>>>>>> Hola:
>>>>>>> Creo que para empezar a ver útil Scrum, debería ser equipos entre 5 y >>>>>>> 7, porque si no, 3 se verá mucha burocracia: ScrumMaster, tablones, >>>>>>> scrum diario, etc. >>>>>>> Aunque todavía sería muy útil otras cosas como: Backlog, PO, Retros
>>>>>>> Según mi opinión, siempre compensa :-)
>>>>>>> Pero si Scrum como marco no se quiere asumir, siempre se pueden poner >>>>>>> en práctica muchas más prácticas ágiles
>>>>>>> El día 14 de febrero de 2012 16:00, Juanma Gómez >>>>>>> <juanmagom...@gmail.com> escribió: >>>>>>> > Hola!
>>>>>>> > Me imagino que la pregunta abarca un poco más de amplitud, ya que >>>>>>> no sólo >>>>>>> > cuenta el equipo de desarrollo como tal. Además, en el equipo del >>>>>>> que formo >>>>>>> > parte somos 3 y, de verdad, no tenemos mayor problema. Qué duda >>>>>>> cabe que con >>>>>>> > más gente seguramente podríamos desarrollar técnicas que ahora >>>>>>> mismo son muy >>>>>>> > costosas para nosotros.
>>>>>>> > Creo que lo mejor que puedes hacer es contratar a un Agile Coach y >>>>>>> que >>>>>>> > valore cuánto fácil o difícil va a ser implementar métodos ágiles >>>>>>> en tu >>>>>>> > empresa, ya que sin conocer bien vuestro tamaño y funcionamiento, >>>>>>> todo lo >>>>>>> > que podamos decir por aquí va a carecer de sentido...
>>>>>>> > Juanma Gómez.
>>>>>>> > El 14 de febrero de 2012 15:36, David Roncancio < >>>>>>> david.roncan...@gmail.com> >>>>>>> > escribió:
>>>>>>> >> Hola, yo he probado SCRUM con equipos muy pequeños 3, y empieza a >>>>>>> ponerse >>>>>>> >> feo el asunto por que a pesar de que alguno de los miembros haga >>>>>>> por varios >>>>>>> >> roles no se van a ver los mismos resultados, lo que se aconseja >>>>>>> generalmente >>>>>>> >> son equipos de 7+ o - 2 personas, es decir que lo mínimo para que >>>>>>> te buenos >>>>>>> >> resultados son 5 personas
>>>>>>> >> Cordialmente,
>>>>>>> >> David Roncancio >>>>>>> >> (+57) 3014311354
>>>>>>> >> On Tue, Feb 14, 2012 at 9:32 AM, jagutierrezm < >>>>>>> jagutierr...@gmail.com> >>>>>>> >> wrote:
>>>>>>> >>> Saludos, en la empresa donde trabajo tienen la idea que para >>>>>>> >>> implementar SCRUM se necesita un equipo muy grande para poder >>>>>>> >>> implementar SCRUM. >>>>>>> >>> En su experiencia, ¿Cual es la cantidad mínima y la cantidad >>>>>>> optima >>>>>>> >>> para implementar SCRUM? Tomando en cuenta que una misma persona >>>>>>> puede >>>>>>> >>> cumplir varios roles
>>>>>>> >>> -- >>>>>>> >>> 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.
>>>>>>> >> -- >>>>>>> >> 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.
>>>>>>> > -- >>>>>>> > 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.
>>>>>>> -- >>>>>>> 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.
>>>>>>> -- >>>>>> 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
El papel de facilitador, coach, integrador con otros
departamentos,... lo veo necesario de forma continua. . Respecto al
PO veo más un enfoque Lean en el que hay idealmente una historia en
curso y una historia analizada en la cola. Pero esto sólo es posible
si el PO está muy,muy disponible. Si no lo está tanto se puede
aumentar el numero de historias listas a modo de buffer. Así si el PO
está se analizan con él unas historias y cuando no esté no se tiene
que quedar la gente parada por tener las historias claras.
Asumo que desarrollo continuo es lo que algunos llaman *application lifecycle management* (ALM) y nosotros llamamos el dia a dia (en yaencontre desarrollamos software propietario exclusivamente).
A nosotros, SCRUM nos esta dando "problemas" como metodologia para el ciclo de vida del desarrollo del software. Con un producto "maduro", es rara la vez que el PO tiene listo un Sprint completo de tres semanas con Vision y objetivo claro. Las necesidades son de mayor orientación a cambios y el PB lo componen pequeñas historias de usuario o tareas técnicas no relacionadas entre si, si las intentamos juntar para tener la magnitud de un sprint, tenemos lo que llamamos sprint "surtido cuetara". Ademas lo normal es que en el transcurso del sprint se cambien prioridades y se modifique el Sprint Backlog. Esto solo crea tensión y desmotiva al equipo.
Con un enfoque evolutivo de desarrollo o cambios incrementales lo que si nos ha funcionado es KANBAN con algunas ceremonias de Scrum (daily meeting, Demos, Retros...).
Y desde luego estoy de acuerdo con Jorge, el PO tiene que tener un enfoque Lean, cada Daily meeting se analiza las tareas en curso, y si la capacidad del equipo lo permite se empiezan tareas nuevas, el PO ha de estar disponible y la comunicación ha de ser constante, el PO ha de priorizar constantemente, así como el principios como *Team Empowerment **el equipo necesita saber Qué ha de construir y el equipo decide Cómo. *
*
*
*La figura del PO como dice jbaez es imprescindible, ademas un PO (o Product Manager con conocimientos y habilidades) ya existe en la empresa.*
*Sobre la figura de SM, Israel ha dado en el clavo, a mi me ha pasado. En *
términos* agiles, un ecosistema sin SM muere**. Se tiende a volver a la tecnica ASM (A Salto de Mata, que *decía* Carlos el otro dia). Puede ser un SM compartido, un coach, lider, *héroe* o integrador, como quieras, pero tiene mucho que hacer (incentivar la innovación de procesos, limitar el trabajo en curso, ayudar al PO con el PB,...) *
*
*
*Israel, tienes razón, tu articulo va a hacer "pupita" ;)*
*
*
*
*
*Miquel A. Mora*
*
*
*
*
Siempre es interesante conocer casos reales. En vuestro caso quien en vuestra organizacion empuja vuestros cambios metodologicos? Esta persona tiene apoyo de la direccion?
Un saludo,
Harald
Am 18/02/2012 um 11:13 schrieb "Miquel A. Mora" <m.yaencon...@gmail.com>:
> Asumo que desarrollo continuo es lo que algunos llaman application lifecycle management (ALM) y nosotros llamamos el dia a dia (en yaencontre desarrollamos software propietario exclusivamente).
> A nosotros, SCRUM nos esta dando "problemas" como metodologia para el ciclo de vida del desarrollo del software. Con un producto "maduro", es rara la vez que el PO tiene listo un Sprint completo de tres semanas con Vision y objetivo claro. Las necesidades son de mayor orientación a cambios y el PB lo componen pequeñas historias de usuario o tareas técnicas no relacionadas entre si, si las intentamos juntar para tener la magnitud de un sprint, tenemos lo que llamamos sprint "surtido cuetara". Ademas lo normal es que en el transcurso del sprint se cambien prioridades y se modifique el Sprint Backlog. Esto solo crea tensión y desmotiva al equipo.
> Con un enfoque evolutivo de desarrollo o cambios incrementales lo que si nos ha funcionado es KANBAN con algunas ceremonias de Scrum (daily meeting, Demos, Retros...).
> Y desde luego estoy de acuerdo con Jorge, el PO tiene que tener un enfoque Lean, cada Daily meeting se analiza las tareas en curso, y si la capacidad del equipo lo permite se empiezan tareas nuevas, el PO ha de estar disponible y la comunicación ha de ser constante, el PO ha de priorizar constantemente, así como el principios como Team Empowerment el equipo necesita saber Qué ha de construir y el equipo decide Cómo.
> La figura del PO como dice jbaez es imprescindible, ademas un PO (o Product Manager con conocimientos y habilidades) ya existe en la empresa. > Sobre la figura de SM, Israel ha dado en el clavo, a mi me ha pasado. En términos agiles, un ecosistema sin SM muere. Se tiende a volver a la tecnica ASM (A Salto de Mata, que decía Carlos el otro dia). Puede ser un SM compartido, un coach, lider, héroe o integrador, como quieras, pero tiene mucho que hacer (incentivar la innovación de procesos, limitar el trabajo en curso, ayudar al PO con el PB,...)
> Israel, tienes razón, tu articulo va a hacer "pupita" ;)
> Miquel A. Mora
> -- > Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google. > Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/OUZxOjj6H-IJ. > 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.
El 18 de febrero de 2012 10:41, Harringer <harrin...@gmail.com> escribió:
> Buenas,
> Siempre es interesante conocer casos reales. En vuestro caso quien en > vuestra organizacion empuja vuestros cambios metodologicos? Esta persona > tiene apoyo de la direccion?
> Un saludo,
> Harald
Buena pregunta Harald.
Segun mi cristal, lo que cuenta Miguel, tiene varios problemas de agilismo basico. Por ejemplo, noto un gran problema a la hora de lograr el equilibrio de poderes. Veo que hay areas que son totalmente dominantes de otras, y de esa forma nunca van a poder aproximarse al agilismo. Y seguramente esto esta relacionado con su dificultad para aplicar scrum.
Lo que si veo es que tienen bastante bien definidos los roles, y les dan importancia... este seria un caso donde se atiende la "tecnica" pero no la "filosofia".
La migración al agilismo consta de cambios de habitos. Y eso es equivalentemente tan dificil como dejar de fumar. Por ello el agilismo es facil de explicar, pero dificil de implementar.
Lamentablemente muchas empresas conservan estructuras piramidales, y mientras sigan teniendo en la cúspide a los fumadores, todo el humo seguira inundando la piramide y llegara a los clientes...
Estoy de acuerdo con Daniel y la importancia del cambio de paradigma que implica abrazar los principios agiles y entender el espíritu Scrum (nos costo un par de años antes que en 2010 Alan Cyment nos lo hizo ver en un CSM). Ademas tenemos apoyo absoluto de gerencia (de la cual yo formo parte ;) por la excelente mejora que scrum y los principios agiles han aportado comparandolos a las metodologias predictivas-waterfall que aplicábamos (sufríamos) hasta hace tres años.
Y desde luego, no creo que nadie pueda discutir que, como dice Daniel, la filosofia control & commander, estructuras piramidales o organizaciones excesivamente matriciales son la primera causa de los fails en implementaciones agiles.
Pero la experiencia que quiero explicar, y quizas solo es nuestro caso () es que en tres equipos de desarrollo interno con Scrum,con tres proyectos y tres PO diferentes, nos pasa que cuando el producto es maduro (llevamos más de 10 años con el proyecto principal), la prioridad de negocio (que marca la prioridad del PB) se basa en gran medida en un mantenimiento evolutivo, en mejoras de procesos o modelos y en optimización de sistemas, basados por ejemplo en UX, persuabilidad, y factores de conversion que implican mucho conocimiento empirico, con sus pruebas-error etc. Solo en contadas ocasiones entran desarrollos de un mes o más duración.
Por eso comento en este hilo que en casos como el nuestro, *el continuos deployment*, el mantenimiento evolutivo en entornos *basados en la mejora u optimización de procesos subyacentes, Scrum puede no ser la mejor opción,*que quizas debamos hacer una adaptación basada en el contexto. Quizas en este escenario se necesite algo más orientado a tareas pequeñas e independientes con gran orientación a la reducción de *throughput* y entregas más a menudo, en vez de un desarrollo iterativo.
Por ejemplo tenemos un cuarto equipo (procesos de negocio aplicados a CRM y ERP) con Kanban y el resultado es totalmente diferente.
Es diferente crear un nuevo proyecto o sistema, o en una fase de crecimiento o innovación, aqui es donde Scrum funciona de manera espectacular, iteraciones, comunicación, retrospectivas, visualización de trabajo en curso,... Nuestra empresa no se plantea Agile, se plantea como aplicarlo para cada contexto.
Si exponer el caso sirve para aprender de los errores, ya me doy por satisfecho. Al fin y al cabo no es eso ser agil ?
> Estoy de acuerdo con Daniel y la importancia del cambio de paradigma que > implica abrazar los principios agiles y entender el espíritu Scrum (nos > costo un par de años antes que en 2010 Alan Cyment nos lo hizo ver en un > CSM). Ademas tenemos apoyo absoluto de gerencia (de la cual yo formo parte > ;) por la excelente mejora que scrum y los principios agiles han aportado > comparandolos a las metodologias predictivas-waterfall > que aplicábamos (sufríamos) hasta hace tres años.
> Y desde luego, no creo que nadie pueda discutir que, como dice Daniel, la > filosofia control & commander, estructuras piramidales o organizaciones > excesivamente matriciales son la primera causa de los fails en > implementaciones agiles.
> Pero la experiencia que quiero explicar, y quizas solo es nuestro caso () > es que en tres equipos de desarrollo interno con Scrum,con tres proyectos y > tres PO diferentes, nos pasa que cuando el producto es maduro (llevamos más > de 10 años con el proyecto principal), la prioridad de negocio (que marca > la prioridad del PB) se basa en gran medida en un mantenimiento evolutivo, > en mejoras de procesos o modelos y en optimización de sistemas, basados por > ejemplo en UX, persuabilidad, y factores de conversion que implican mucho > conocimiento empirico, con sus pruebas-error etc. Solo en contadas > ocasiones entran desarrollos de un mes o más duración.
> Por eso comento en este hilo que en casos como el nuestro, *el continuos > deployment*, el mantenimiento evolutivo en entornos *basados en la mejora > u optimización de procesos subyacentes, Scrum puede no ser la mejor opción, > * que quizas debamos hacer una adaptación basada en el contexto. Quizas > en este escenario se necesite algo más orientado a tareas pequeñas e > independientes con gran orientación a la reducción de *throughput* y > entregas más a menudo, en vez de un desarrollo iterativo. > Por ejemplo tenemos un cuarto equipo (procesos de negocio aplicados a CRM > y ERP) con Kanban y el resultado es totalmente diferente.
> Es diferente crear un nuevo proyecto o sistema, o en una fase de > crecimiento o innovación, aqui es donde Scrum funciona de > manera espectacular, iteraciones, comunicación, > retrospectivas, visualización de trabajo en curso,... Nuestra empresa no se > plantea Agile, se plantea como aplicarlo para cada contexto.
> Si exponer el caso sirve para aprender de los errores, ya me doy por > satisfecho. Al fin y al cabo no es eso ser agil ?
Hola Miguel, tu experiencia y opinion son muy valiosos para mi y por eso participo...
Perdon por la pregunta pero hay algo que no entiendo... si tienes un PO, un SM, daily meetings, backlog, retrospectivas... porque dices que "no aplicas scrum"? ¿es porque no tienes el time-box?
De ser asi... ¿que impedimento o dificultad te trae el time-box?
Desde ya que la teoria indica que para el mantenimiento de sistemas es mejor kanban que scrum... pero es importante buscarle la vuelta a tu experiencia para entenderla.
Entre scrum y kanban la principal diferencia es el time-box o ausencia de el.
Claro Daniel, es por que participas tú y el resto y que aportais tanto valor y haceis el esfuerzo desinteresado de compartir conocimiento.
No digo que no apliquemos Scrum, lo hacemos, pero (quizas) lo hacemos por sistema. Se ha demostrado mejor que el desarrollo predictivo y se aplica. Expongo mi caso, ya que no estoy seguro que Scrum sea la mejor opción para continuous deployment (en contextos concretos). Pero como es simplemente una opinión, me gusta exponerla aqui y ademas en este hilo que Adrian ha abierto porque me gustaría aprovechar vuestro conocimiento porque no estoy seguro y me gustaría leer vuestras opiniones.
Por aportar mi granito de arena, comentaré que mi experiencia personal
incorporando principios ágiles en un entorno de software de producción
industrial es prácticamente identica a la de Miquel.
En esencia, despliegue continuo de software a medida.
Nos está costando más la adopción de TDD que los sprints y
retrospectivas semanales.
On 18 feb, 19:18, "Miquel A. Mora" <m.yaencon...@gmail.com> wrote:
> Claro Daniel, es por que participas tú y el resto y que aportais tanto
> valor y haceis el esfuerzo desinteresado de compartir conocimiento.
> No digo que no apliquemos Scrum, lo hacemos, pero (quizas) lo hacemos por
> sistema. Se ha demostrado mejor que el desarrollo predictivo y se aplica.
> Expongo mi caso, ya que no estoy seguro que Scrum sea la mejor opción para
> continuous deployment (en contextos concretos). Pero como es simplemente
> una opinión, me gusta exponerla aqui y ademas en este hilo que Adrian ha
> abierto porque me gustaría aprovechar vuestro conocimiento porque no estoy
> seguro y me gustaría leer vuestras opiniones.
El 18 de febrero de 2012 16:11, Fermin <fermin.s...@gmail.com> escribió:
> Por aportar mi granito de arena, comentaré que mi experiencia personal > incorporando principios ágiles en un entorno de software de producción > industrial es prácticamente identica a la de Miquel. > En esencia, despliegue continuo de software a medida.
> Nos está costando más la adopción de TDD que los sprints y > retrospectivas semanales.
Interesante! Hace cuanto que estan con TDD? con que tecnologias? (java, ruby, python, c++)
Probablemente no entiendo de todo vuestra situacion. Entiendo que sabeis scrum y kanban. Me parece que estamos masco menos de acuerdo para scrum es mejor para gestionar proyectos y kanban mejor para gestionar incidencias y cambios.
El tema de deploy / desarrollo continuo o integracion continua, emo, no es un tema de gestion del trabajo en primer lugar, sino mas bien de gestion del software que producimos.
Es decir, puedes hacer integracion continua independientemente de scrum / kanban o cualquier metodologia.
Probablemente la cuestion es el alcance buscado para el deploy continuo en vuestro caso.
Un saludo,
Harald
Am 18/02/2012 um 19:18 schrieb "Miquel A. Mora" <m.yaencon...@gmail.com>:
> Claro Daniel, es por que participas tú y el resto y que aportais tanto valor y haceis el esfuerzo desinteresado de compartir conocimiento.
> No digo que no apliquemos Scrum, lo hacemos, pero (quizas) lo hacemos por sistema. Se ha demostrado mejor que el desarrollo predictivo y se aplica. Expongo mi caso, ya que no estoy seguro que Scrum sea la mejor opción para continuous deployment (en contextos concretos). Pero como es simplemente una opinión, me gusta exponerla aqui y ademas en este hilo que Adrian ha abierto porque me gustaría aprovechar vuestro conocimiento porque no estoy seguro y me gustaría leer vuestras opiniones.
> Gracias.
> Miquel A. Mora > -- > Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google. > Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/_bwlbVdxNhsJ. > 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.
> Probablemente no entiendo de todo vuestra situacion. Entiendo que sabeis > scrum y kanban. Me parece que estamos masco menos de acuerdo para scrum es > mejor para gestionar proyectos y kanban mejor para gestionar incidencias y > cambios.
> El tema de deploy / desarrollo continuo > o integracion continua, emo, no es un tema de gestion del trabajo en > primer lugar, sino mas bien de gestion del software que producimos.
> Es decir, puedes hacer integracion continua independientemente de scrum / > kanban o cualquier metodologia.
> Probablemente la cuestion es el alcance buscado para el deploy continuo en > vuestro caso.
> Un saludo,
> Harald
Uhh! perdon veo que realmente estaba perdido... Continuous Deployment es lo mismo que Integracion Continua?
Perdon si la pregunta es muy tonta... es para verificar...
> Probablemente no entiendo de todo vuestra situacion. Entiendo que sabeis > scrum y kanban. Me parece que estamos masco menos de acuerdo para scrum es > mejor para gestionar proyectos y kanban mejor para gestionar incidencias y > cambios.
> El tema de deploy / desarrollo continuo > o integracion continua, emo, no es un tema de gestion del trabajo en > primer lugar, sino mas bien de gestion del software que producimos.
> Es decir, puedes hacer integracion continua independientemente de scrum / > kanban o cualquier metodologia.
> Probablemente la cuestion es el alcance buscado para el deploy continuo en > vuestro caso.
> Un saludo,
> Harald
Uhh! perdon veo que realmente estaba perdido... Continuous Deployment es lo mismo que Integracion Continua?
Perdon si la pregunta es muy tonta... es para verificar...
-- 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.
Cierto, creo que no hemos definido la terminología. ¿que diferencia hay entre integración continua y deploy continuo?
Por Integración Continua entiendo el despliegue en uno o varios entornos y ejecucación automatica de unas pruebas a partir de que un programador sube una versión finalizada en un sistema de control de versiones. Hay herramientas como CruiseControl y Hudson que se han comentado aquí que dan un soporte a esto. No se si es la definición exacta, pero va en esta linea.
"One key goal of continuous deployment is to reduce the risk of releasing software. Counter-intuitively, increased throughput and increased production stability are not a zero-sum game, and effective continuous deployment actually reduces the risk of any individual release. In the course of teaching continuous delivery and talking to people who implement it, I’ve come to see that “doing it right” can be reduced to four principles:
- Low-risk releases are incremental. - Decouple deployment and release. - Focus on reducing batch size. - Optimize for resilience."
Si fuera esta la definición, opino que sigue siendo bastante parecido a Integración Continua haciendo hincapie en conseguir que el output del proceso de Integración Continua se despliegue directamente en un entorno productivo.
> El 19/02/2012, a las 00:25, Daniel Ceillan <codigodan...@gmail.com> > escribió:
> El 18 de febrero de 2012 19:07, Harringer <harrin...@gmail.com> escribió:
>> Hola Miguel,
>> Probablemente no entiendo de todo vuestra situacion. Entiendo que sabeis >> scrum y kanban. Me parece que estamos masco menos de acuerdo para scrum es >> mejor para gestionar proyectos y kanban mejor para gestionar incidencias y >> cambios.
>> El tema de deploy / desarrollo continuo >> o integracion continua, emo, no es un tema de gestion del trabajo en >> primer lugar, sino mas bien de gestion del software que producimos.
>> Es decir, puedes hacer integracion continua independientemente de scrum / >> kanban o cualquier metodologia.
>> Probablemente la cuestion es el alcance buscado para el deploy continuo >> en vuestro caso.
>> Un saludo,
>> Harald
> Uhh! perdon veo que realmente estaba perdido... Continuous Deployment es > lo mismo que Integracion Continua?
> Perdon si la pregunta es muy tonta... es para verificar...
> -- > 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.
> -- > 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.
Continuos delivery (por cierto, el libro es IMHO imprescindible) es mucho, pero mucho, más que integración continua.
La integración continua es un proceso que sólo involucra al equipo de desarrollo, cualquier equipo puede poner en práctica esta técnica de forma relativamente facil, basta con tener un build automatizado y test automáticos. El continuos delivery llevado a su maxima expresión involucra muchos más elementos:
- integración total entre sistemas y desarrollo (devOps). No recuerdo donde leí que el agilismo se podía ver como una continua eliminación de barreras, con la integración del cliente en los equipos (xp o scrum) cae una barrera, con la integración de QA en el equipo cae otra barrera, la integración entre sistemas y desarrollo es otra barrera más a eliminar.
- requiere gestionar las versiones del producto completo, es decir, el producto no es sólo el binario que se genera después de compilar ( o el empaquetado o lo que sea dependiente de la tecnología) incluye también el entorno donde se va desplegar el producto con todas sus características y configuraciones. (herramientas como chef ayudan a esto, la virtualización y los entornos de cloud también tienen mucho que ver con que esto empiece a ser cada vez más viable)
- requiere una automatización de pruebas total, eliminando cualquier fase de test manual, cada commit se convierte en una nueva versión en producción..
- requiere automatización de pruebas también a nivel de pruebas de requisitos no funcionales, pruebas de rendimiento, seguridad etc,etc. Incluso con vueltas atras a versiones anteriores si no se supera algún limite. Por ejemplo recuerdo una empresa que decían hacer más de 50 despliegues diarios, tenian el sistema montado de modo que cada versión se desplegaba en la mitad de sus servidores y si superaba ciertas pruebas de rendimiento se montaba sobre los restantes y en caso de no superarlas se descartaba esa versión, todo sin intervención manual alguna (casi na).
- requiere un nivel de responsabilidad brutal en cada desarrollador, cada commit es una subida a producción.
Continuos delivery implica sobre todo reducir al minimo la cadena de valor, desde que alguien tiene una idea hasta que el usuario puede disfrutar de esa característica en el producto final, llevado a su máxima expresión supone que el usuario puede disponer de esa característica minutos después de que un desarrollador haga "commit" de esa feature.
A mi me parece casi como el "santo grial" del desarrollo, yo al menos estoy muy lejos de conseguirlo, pero es sin duda una buena meta a perseguir.
El 19 de febrero de 2012 02:07, Harald Messemer <harrin...@gmail.com>escribió:
> Cierto, creo que no hemos definido la terminología. ¿que diferencia hay > entre integración continua y deploy continuo?
> Por Integración Continua entiendo el despliegue en uno o varios entornos y > ejecucación automatica de unas pruebas a partir de que un programador sube > una versión finalizada en un sistema de control de versiones. Hay > herramientas como CruiseControl y Hudson que se han comentado aquí que dan > un soporte a esto. No se si es la definición exacta, pero va en esta linea.
> "One key goal of continuous deployment is to reduce the risk of releasing > software. Counter-intuitively, increased throughput and increased > production stability are not a zero-sum game, and effective continuous > deployment actually reduces the risk of any individual release. In the > course of teaching continuous delivery and talking to people who implement > it, I’ve come to see that “doing it right” can be reduced to four > principles:
> - Low-risk releases are incremental. > - Decouple deployment and release. > - Focus on reducing batch size. > - Optimize for resilience."
> Si fuera esta la definición, opino que sigue siendo bastante parecido a > Integración Continua haciendo hincapie en conseguir que el output del > proceso de Integración Continua se despliegue directamente en un entorno > productivo.
>> El 19/02/2012, a las 00:25, Daniel Ceillan <codigodan...@gmail.com> >> escribió:
>> El 18 de febrero de 2012 19:07, Harringer <harrin...@gmail.com> escribió:
>>> Hola Miguel,
>>> Probablemente no entiendo de todo vuestra situacion. Entiendo que sabeis >>> scrum y kanban. Me parece que estamos masco menos de acuerdo para scrum es >>> mejor para gestionar proyectos y kanban mejor para gestionar incidencias y >>> cambios.
>>> El tema de deploy / desarrollo continuo >>> o integracion continua, emo, no es un tema de gestion del trabajo en >>> primer lugar, sino mas bien de gestion del software que producimos.
>>> Es decir, puedes hacer integracion continua independientemente de scrum >>> / kanban o cualquier metodologia.
>>> Probablemente la cuestion es el alcance buscado para el deploy continuo >>> en vuestro caso.
>>> Un saludo,
>>> Harald
>> Uhh! perdon veo que realmente estaba perdido... Continuous Deployment >> es lo mismo que Integracion Continua?
>> Perdon si la pregunta es muy tonta... es para verificar...
>> -- >> 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.
>> -- >> 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.
> -- > 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.
> Continuos delivery (por cierto, el libro es IMHO imprescindible) es mucho, > pero mucho, más que integración continua.
> La integración continua es un proceso que sólo involucra al equipo de > desarrollo, cualquier equipo puede poner en práctica esta técnica de forma > relativamente facil, basta con tener un build automatizado y > test automáticos. El continuos delivery llevado a su maxima expresión > involucra muchos más elementos:
> - integración total entre sistemas y desarrollo (devOps). No recuerdo > donde leí que el agilismo se podía ver como una continua eliminación de > barreras, con la integración del cliente en los equipos (xp o scrum) cae > una barrera, con la integración de QA en el equipo cae otra barrera, la > integración entre sistemas y desarrollo es otra barrera más a eliminar.
> - requiere gestionar las versiones del producto completo, es decir, el > producto no es sólo el binario que se genera después de compilar ( o el > empaquetado o lo que sea dependiente de la tecnología) incluye también el > entorno donde se va desplegar el producto con todas sus características y > configuraciones. (herramientas como chef ayudan a esto, la virtualización y > los entornos de cloud también tienen mucho que ver con que esto empiece a > ser cada vez más viable)
> - requiere una automatización de pruebas total, eliminando cualquier fase > de test manual, cada commit se convierte en una nueva versión en > producción..
> - requiere automatización de pruebas también a nivel de pruebas de > requisitos no funcionales, pruebas de rendimiento, seguridad etc,etc. > Incluso con vueltas atras a versiones anteriores si no se supera algún > limite. Por ejemplo recuerdo una empresa que decían hacer más de 50 > despliegues diarios, tenian el sistema montado de modo que cada versión se > desplegaba en la mitad de sus servidores y si superaba ciertas pruebas de > rendimiento se montaba sobre los restantes y en caso de no superarlas se > descartaba esa versión, todo sin intervención manual alguna (casi na).
> - requiere un nivel de responsabilidad brutal en cada desarrollador, cada > commit es una subida a producción.
> Continuos delivery implica sobre todo reducir al minimo la cadena de > valor, desde que alguien tiene una idea hasta que el usuario puede > disfrutar de esa característica en el producto final, llevado a su máxima > expresión supone que el usuario puede disponer de esa característica > minutos después de que un desarrollador haga "commit" de esa feature.
> A mi me parece casi como el "santo grial" del desarrollo, yo al menos > estoy muy lejos de conseguirlo, pero es sin duda una buena meta a > perseguir.
> El 19 de febrero de 2012 02:07, Harald Messemer <harrin...@gmail.com>escribió:
> Cierto, creo que no hemos definido la terminología. ¿que diferencia hay >> entre integración continua y deploy continuo?
>> Por Integración Continua entiendo el despliegue en uno o varios entornos >> y ejecucación automatica de unas pruebas a partir de que un programador >> sube una versión finalizada en un sistema de control de versiones. Hay >> herramientas como CruiseControl y Hudson que se han comentado aquí que dan >> un soporte a esto. No se si es la definición exacta, pero va en esta linea.
>> "One key goal of continuous deployment is to reduce the risk of releasing >> software. Counter-intuitively, increased throughput and increased >> production stability are not a zero-sum game, and effective continuous >> deployment actually reduces the risk of any individual release. In the >> course of teaching continuous delivery and talking to people who implement >> it, I’ve come to see that “doing it right” can be reduced to four >> principles:
>> - Low-risk releases are incremental. >> - Decouple deployment and release. >> - Focus on reducing batch size. >> - Optimize for resilience."
>> Si fuera esta la definición, opino que sigue siendo bastante parecido a >> Integración Continua haciendo hincapie en conseguir que el output del >> proceso de Integración Continua se despliegue directamente en un entorno >> productivo.
>>> El 19/02/2012, a las 00:25, Daniel Ceillan <codigodan...@gmail.com> >>> escribió:
>>> El 18 de febrero de 2012 19:07, Harringer <harrin...@gmail.com>escribió:
>>>> Hola Miguel,
>>>> Probablemente no entiendo de todo vuestra situacion. Entiendo que >>>> sabeis scrum y kanban. Me parece que estamos masco menos de acuerdo para >>>> scrum es mejor para gestionar proyectos y kanban mejor para gestionar >>>> incidencias y cambios.
>>>> El tema de deploy / desarrollo continuo >>>> o integracion continua, emo, no es un tema de gestion del trabajo en >>>> primer lugar, sino mas bien de gestion del software que producimos.
>>>> Es decir, puedes hacer integracion continua independientemente de scrum >>>> / kanban o cualquier metodologia.
>>>> Probablemente la cuestion es el alcance buscado para el deploy continuo >>>> en vuestro caso.
>>>> Un saludo,
>>>> Harald
>>> Uhh! perdon veo que realmente estaba perdido... Continuous Deployment >>> es lo mismo que Integracion Continua?
>>> Perdon si la pregunta es muy tonta... es para verificar...
Queda claro ahora... este modelo se deberia aplicar en aquellos proyectos donde necesitamos el soft en produccion lo antes posible. El unico drama es que requiere un equipazo detras...
Muchas Gracias a Tod@s,
A Adrian x abrir el hilo y al resto x sacarle todo este jugo al tema...
Me habéis dado + n 20 mails q mucho tiempo leyendo y preguntándome dudas.
Como decís, trabajar bien en un entorno d Integración Continua requiere Equipos d Alto Rendimiento, pero trabajar bien en entornos d Entrega Continua requiere Ecosistemas y Organizaciones d Alto Rendimiento.
En cualquier caso, después d aclarar conceptos, veo q tanto Integración y Entrega Continuas no dependen tanto del tipo d trabajo ni d Scrum vs Kanban, sino d la capacidad y necesidad d ese despliegue constante.
Gracias a Tod@s,
(control de versiones, compilación continua, integración continua, despliegue continuo) #lol
El 19/02/2012, a las 03:05, Alfredo Casado <casado.alfr...@gmail.com> escribió:
Continuos delivery (por cierto, el libro es IMHO imprescindible) es mucho, pero mucho, más que integración continua.
La integración continua es un proceso que sólo involucra al equipo de desarrollo, cualquier equipo puede poner en práctica esta técnica de forma relativamente facil, basta con tener un build automatizado y test automáticos. El continuos delivery llevado a su maxima expresión involucra muchos más elementos:
- integración total entre sistemas y desarrollo (devOps). No recuerdo donde leí que el agilismo se podía ver como una continua eliminación de barreras, con la integración del cliente en los equipos (xp o scrum) cae una barrera, con la integración de QA en el equipo cae otra barrera, la integración entre sistemas y desarrollo es otra barrera más a eliminar.
- requiere gestionar las versiones del producto completo, es decir, el producto no es sólo el binario que se genera después de compilar ( o el empaquetado o lo que sea dependiente de la tecnología) incluye también el entorno donde se va desplegar el producto con todas sus características y configuraciones. (herramientas como chef ayudan a esto, la virtualización y los entornos de cloud también tienen mucho que ver con que esto empiece a ser cada vez más viable)
- requiere una automatización de pruebas total, eliminando cualquier fase de test manual, cada commit se convierte en una nueva versión en producción..
- requiere automatización de pruebas también a nivel de pruebas de requisitos no funcionales, pruebas de rendimiento, seguridad etc,etc. Incluso con vueltas atras a versiones anteriores si no se supera algún limite. Por ejemplo recuerdo una empresa que decían hacer más de 50 despliegues diarios, tenian el sistema montado de modo que cada versión se desplegaba en la mitad de sus servidores y si superaba ciertas pruebas de rendimiento se montaba sobre los restantes y en caso de no superarlas se descartaba esa versión, todo sin intervención manual alguna (casi na).
- requiere un nivel de responsabilidad brutal en cada desarrollador, cada commit es una subida a producción.
Continuos delivery implica sobre todo reducir al minimo la cadena de valor, desde que alguien tiene una idea hasta que el usuario puede disfrutar de esa característica en el producto final, llevado a su máxima expresión supone que el usuario puede disponer de esa característica minutos después de que un desarrollador haga "commit" de esa feature.
A mi me parece casi como el "santo grial" del desarrollo, yo al menos estoy muy lejos de conseguirlo, pero es sin duda una buena meta a perseguir.
El 19 de febrero de 2012 02:07, Harald Messemer <harrin...@gmail.com>escribió:
> Cierto, creo que no hemos definido la terminología. ¿que diferencia hay > entre integración continua y deploy continuo?
> Por Integración Continua entiendo el despliegue en uno o varios entornos y > ejecucación automatica de unas pruebas a partir de que un programador sube > una versión finalizada en un sistema de control de versiones. Hay > herramientas como CruiseControl y Hudson que se han comentado aquí que dan > un soporte a esto. No se si es la definición exacta, pero va en esta linea.
> "One key goal of continuous deployment is to reduce the risk of releasing > software. Counter-intuitively, increased throughput and increased > production stability are not a zero-sum game, and effective continuous > deployment actually reduces the risk of any individual release. In the > course of teaching continuous delivery and talking to people who implement > it, I’ve come to see that “doing it right” can be reduced to four > principles:
> - Low-risk releases are incremental. > - Decouple deployment and release. > - Focus on reducing batch size. > - Optimize for resilience."
> Si fuera esta la definición, opino que sigue siendo bastante parecido a > Integración Continua haciendo hincapie en conseguir que el output del > proceso de Integración Continua se despliegue directamente en un entorno > productivo.
>> El 19/02/2012, a las 00:25, Daniel Ceillan <codigodan...@gmail.com> >> escribió:
>> El 18 de febrero de 2012 19:07, Harringer <harrin...@gmail.com> escribió:
>>> Hola Miguel,
>>> Probablemente no entiendo de todo vuestra situacion. Entiendo que sabeis >>> scrum y kanban. Me parece que estamos masco menos de acuerdo para scrum es >>> mejor para gestionar proyectos y kanban mejor para gestionar incidencias y >>> cambios.
>>> El tema de deploy / desarrollo continuo >>> o integracion continua, emo, no es un tema de gestion del trabajo en >>> primer lugar, sino mas bien de gestion del software que producimos.
>>> Es decir, puedes hacer integracion continua independientemente de scrum >>> / kanban o cualquier metodologia.
>>> Probablemente la cuestion es el alcance buscado para el deploy continuo >>> en vuestro caso.
>>> Un saludo,
>>> Harald
>> Uhh! perdon veo que realmente estaba perdido... Continuous Deployment >> es lo mismo que Integracion Continua?
>> Perdon si la pregunta es muy tonta... es para verificar...
>> -- >> 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.
>> -- >> 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.
> -- > 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.
-- 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.
Conceptualmente un "continous delivery" (ojo: ya tenemos otro termino nuevo. Antes hablabamos de "continous deploy") promete mucho, pero a la vez es muy exigente en terminos de proceso, personas y tecnologias de soporte.
Es un poco como con el Model-driven-development, otro concepto fuerte que ha dado buenas resultados a empresas del tamano de Nokia, pero que en entornos con poco grado de repetibilidad, poca estandarizacion y poca heterogenidad de deploy no ha tenido mucho exito, dado el esfuerzo upfront no tiene compensacion.
Vamos, mi duda es: continous deploy es para todos los proyectos o es para casos especificos?
Un saludo,
Harald
Am 19/02/2012 um 10:35 schrieb jorge baez <jorge.b...@gmail.com>:
> El 19/02/2012, a las 03:05, Alfredo Casado <casado.alfr...@gmail.com> escribió:
>> Continuos delivery (por cierto, el libro es IMHO imprescindible) es mucho, pero mucho, más que integración continua.
>> La integración continua es un proceso que sólo involucra al equipo de desarrollo, cualquier equipo puede poner en práctica esta técnica de forma relativamente facil, basta con tener un build automatizado y test automáticos. El continuos delivery llevado a su maxima expresión involucra muchos más elementos:
>> - integración total entre sistemas y desarrollo (devOps). No recuerdo donde leí que el agilismo se podía ver como una continua eliminación de barreras, con la integración del cliente en los equipos (xp o scrum) cae una barrera, con la integración de QA en el equipo cae otra barrera, la integración entre sistemas y desarrollo es otra barrera más a eliminar.
>> - requiere gestionar las versiones del producto completo, es decir, el producto no es sólo el binario que se genera después de compilar ( o el empaquetado o lo que sea dependiente de la tecnología) incluye también el entorno donde se va desplegar el producto con todas sus características y configuraciones. (herramientas como chef ayudan a esto, la virtualización y los entornos de cloud también tienen mucho que ver con que esto empiece a ser cada vez más viable)
>> - requiere una automatización de pruebas total, eliminando cualquier fase de test manual, cada commit se convierte en una nueva versión en producción..
>> - requiere automatización de pruebas también a nivel de pruebas de requisitos no funcionales, pruebas de rendimiento, seguridad etc,etc. Incluso con vueltas atras a versiones anteriores si no se supera algún limite. Por ejemplo recuerdo una empresa que decían hacer más de 50 despliegues diarios, tenian el sistema montado de modo que cada versión se desplegaba en la mitad de sus servidores y si superaba ciertas pruebas de rendimiento se montaba sobre los restantes y en caso de no superarlas se descartaba esa versión, todo sin intervención manual alguna (casi na).
>> - requiere un nivel de responsabilidad brutal en cada desarrollador, cada commit es una subida a producción.
>> Continuos delivery implica sobre todo reducir al minimo la cadena de valor, desde que alguien tiene una idea hasta que el usuario puede disfrutar de esa característica en el producto final, llevado a su máxima expresión supone que el usuario puede disponer de esa característica minutos después de que un desarrollador haga "commit" de esa feature.
>> A mi me parece casi como el "santo grial" del desarrollo, yo al menos estoy muy lejos de conseguirlo, pero es sin duda una buena meta a perseguir.
>> El 19 de febrero de 2012 02:07, Harald Messemer <harrin...@gmail.com> escribió: >> Cierto, creo que no hemos definido la terminología. ¿que diferencia hay entre integración continua y deploy continuo?
>> Por Integración Continua entiendo el despliegue en uno o varios entornos y ejecucación automatica de unas pruebas a partir de que un programador sube una versión finalizada en un sistema de control de versiones. Hay herramientas como CruiseControl y Hudson que se han comentado aquí que dan un soporte a esto. No se si es la definición exacta, pero va en esta linea.
>> "One key goal of continuous deployment is to reduce the risk of releasing software. Counter-intuitively, increased throughput and increased production stability are not a zero-sum game, and effective continuous deployment actually reduces the risk of any individual release. In the course of teaching continuous delivery and talking to people who implement it, I’ve come to see that “doing it right” can be reduced to four principles: >> Low-risk releases are incremental. >> Decouple deployment and release. >> Focus on reducing batch size. >> Optimize for resilience." >> Si fuera esta la definición, opino que sigue siendo bastante parecido a Integración Continua haciendo hincapie en conseguir que el output del proceso de Integración Continua se despliegue directamente en un entorno productivo.
>> Un saludo, >> Harald
>> 2012/2/19 jorge baez <jorge.b...@gmail.com> >> no, no es lo mismo
>> El 19/02/2012, a las 00:25, Daniel Ceillan <codigodan...@gmail.com> escribió:
>>> El 18 de febrero de 2012 19:07, Harringer <harrin...@gmail.com> escribió: >>> Hola Miguel,
>>> Probablemente no entiendo de todo vuestra situacion. Entiendo que sabeis scrum y kanban. Me parece que estamos masco menos de acuerdo para scrum es mejor para gestionar proyectos y kanban mejor para gestionar incidencias y cambios.
>>> El tema de deploy / desarrollo continuo >>> o integracion continua, emo, no es un tema de gestion del trabajo en primer lugar, sino mas bien de gestion del software que producimos.
>>> Es decir, puedes hacer integracion continua independientemente de scrum / kanban o cualquier metodologia.
>>> Probablemente la cuestion es el alcance buscado para el deploy continuo en vuestro caso.
>>> Un saludo,
>>> Harald
>>> Uhh! perdon veo que realmente estaba perdido... Continuous Deployment es lo mismo que Integracion Continua?
>>> Perdon si la pregunta es muy tonta... es para verificar...
>>> -- >>> 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.
>> -- >> 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.
>> -- >> 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.
>> -- >> 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. > -- > 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.
igual en lugar de deploy tenía q haber puesto delivery ;)
El 19/02/2012, a las 10:57, Harringer <harrin...@gmail.com> escribió:
Buen hilo, aunque no tiraria la toalla aun.
Conceptualmente un "continous delivery" (ojo: ya tenemos otro termino nuevo. Antes hablabamos de "continous deploy") promete mucho, pero a la vez es muy exigente en terminos de proceso, personas y tecnologias de soporte.
Es un poco como con el Model-driven-development, otro concepto fuerte que ha dado buenas resultados a empresas del tamano de Nokia, pero que en entornos con poco grado de repetibilidad, poca estandarizacion y poca heterogenidad de deploy no ha tenido mucho exito, dado el esfuerzo upfront no tiene compensacion.
Vamos, mi duda es: continous deploy es para todos los proyectos o es para casos especificos?
Un saludo,
Harald
Am 19/02/2012 um 10:35 schrieb jorge baez <jorge.b...@gmail.com>:
+1
es el siguiente paso... peo el escalón es alto
(control de versiones, compilación continua, integración continua, despliegue continuo) #lol
El 19/02/2012, a las 03:05, Alfredo Casado <casado.alfr...@gmail.com> escribió:
Continuos delivery (por cierto, el libro es IMHO imprescindible) es mucho, pero mucho, más que integración continua.
La integración continua es un proceso que sólo involucra al equipo de desarrollo, cualquier equipo puede poner en práctica esta técnica de forma relativamente facil, basta con tener un build automatizado y test automáticos. El continuos delivery llevado a su maxima expresión involucra muchos más elementos:
- integración total entre sistemas y desarrollo (devOps). No recuerdo donde leí que el agilismo se podía ver como una continua eliminación de barreras, con la integración del cliente en los equipos (xp o scrum) cae una barrera, con la integración de QA en el equipo cae otra barrera, la integración entre sistemas y desarrollo es otra barrera más a eliminar.
- requiere gestionar las versiones del producto completo, es decir, el producto no es sólo el binario que se genera después de compilar ( o el empaquetado o lo que sea dependiente de la tecnología) incluye también el entorno donde se va desplegar el producto con todas sus características y configuraciones. (herramientas como chef ayudan a esto, la virtualización y los entornos de cloud también tienen mucho que ver con que esto empiece a ser cada vez más viable)
- requiere una automatización de pruebas total, eliminando cualquier fase de test manual, cada commit se convierte en una nueva versión en producción..
- requiere automatización de pruebas también a nivel de pruebas de requisitos no funcionales, pruebas de rendimiento, seguridad etc,etc. Incluso con vueltas atras a versiones anteriores si no se supera algún limite. Por ejemplo recuerdo una empresa que decían hacer más de 50 despliegues diarios, tenian el sistema montado de modo que cada versión se desplegaba en la mitad de sus servidores y si superaba ciertas pruebas de rendimiento se montaba sobre los restantes y en caso de no superarlas se descartaba esa versión, todo sin intervención manual alguna (casi na).
- requiere un nivel de responsabilidad brutal en cada desarrollador, cada commit es una subida a producción.
Continuos delivery implica sobre todo reducir al minimo la cadena de valor, desde que alguien tiene una idea hasta que el usuario puede disfrutar de esa característica en el producto final, llevado a su máxima expresión supone que el usuario puede disponer de esa característica minutos después de que un desarrollador haga "commit" de esa feature.
A mi me parece casi como el "santo grial" del desarrollo, yo al menos estoy muy lejos de conseguirlo, pero es sin duda una buena meta a perseguir.
El 19 de febrero de 2012 02:07, Harald Messemer <harrin...@gmail.com>escribió:
> Cierto, creo que no hemos definido la terminología. ¿que diferencia hay > entre integración continua y deploy continuo?
> Por Integración Continua entiendo el despliegue en uno o varios entornos y > ejecucación automatica de unas pruebas a partir de que un programador sube > una versión finalizada en un sistema de control de versiones. Hay > herramientas como CruiseControl y Hudson que se han comentado aquí que dan > un soporte a esto. No se si es la definición exacta, pero va en esta linea.
> "One key goal of continuous deployment is to reduce the risk of releasing > software. Counter-intuitively, increased throughput and increased > production stability are not a zero-sum game, and effective continuous > deployment actually reduces the risk of any individual release. In the > course of teaching continuous delivery and talking to people who implement > it, I’ve come to see that “doing it right” can be reduced to four > principles:
> - Low-risk releases are incremental. > - Decouple deployment and release. > - Focus on reducing batch size. > - Optimize for resilience."
> Si fuera esta la definición, opino que sigue siendo bastante parecido a > Integración Continua haciendo hincapie en conseguir que el output del > proceso de Integración Continua se despliegue directamente en un entorno > productivo.
>> El 19/02/2012, a las 00:25, Daniel Ceillan <codigodan...@gmail.com> >> escribió:
>> El 18 de febrero de 2012 19:07, Harringer <harrin...@gmail.com> escribió:
>>> Hola Miguel,
>>> Probablemente no entiendo de todo vuestra situacion. Entiendo que sabeis >>> scrum y kanban. Me parece que estamos masco menos de acuerdo para scrum es >>> mejor para gestionar proyectos y kanban mejor para gestionar incidencias y >>> cambios.
>>> El tema de deploy / desarrollo continuo >>> o integracion continua, emo, no es un tema de gestion del trabajo en >>> primer lugar, sino mas bien de gestion del software que producimos.
>>> Es decir, puedes hacer integracion continua independientemente de scrum >>> / kanban o cualquier metodologia.
>>> Probablemente la cuestion es el alcance buscado para el deploy continuo >>> en vuestro caso.
>>> Un saludo,
>>> Harald
>> Uhh! perdon veo que realmente estaba perdido... Continuous Deployment >> es lo mismo que Integracion Continua?
>> Perdon si la pregunta es muy tonta... es para verificar...
>> -- >> 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.
>> -- >> 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.
> -- > 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.
-- 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.
-- 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.
-- 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.
