[agile-spain] Contínuous Deployment

[Adrian Perreau de Pinninck]

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...@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 <israel...@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" <adelato...@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

http://www.extremeprogramming.org/

Saludos

El día 14 de febrero de 2012 16:00, Juanma Gómez
<juanma...@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.r...@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 <jaguti...@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...@googlegroups.com.
>>> Para anular tu suscripción a este grupo, envía un correo electrónico a
>>> agile-spain...@googlegroups.com
>>> Para tener acceso a más opciones, visita el grupo en
>>> http://groups.google.com/group/agile-spain?hl=es.
>>>
>>
>> --
>> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
>> Grupos de Google.
>> Para publicar una entrada en este grupo, envía un correo electrónico a
>> agile...@googlegroups.com.
>> Para anular tu suscripción a este grupo, envía un correo electrónico a
>> agile-spain...@googlegroups.com
>> Para tener acceso a más opciones, visita el grupo en
>> http://groups.google.com/group/agile-spain?hl=es.
>
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
> Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a
> agile...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a
> agile-spain...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en
> http://groups.google.com/group/agile-spain?hl=es.

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--

Adrián Perreau de Pinninck Bas, Ph.D

LinkedIn: http://es.linkedin.com/in/eidrien 

Blog: eidrienontech.blogspot.com

Twitter: @eidrien

[jorge]

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 <aper...@gmail.com>

[Harringer]

Opino, aunque no me llamen :-)

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.

[Adrian Perreau de Pinninck]

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?

Saludos,

2012/2/14 Harringer <harr...@gmail.com>

[Israel Alcázar]

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,

Israel Alcázar Rodríguez
israel...@gmail.com
http://www.farmerdev.com

http://www.mavencharts.com
http://www.twitter.com/ialcazar

[Adrian Perreau de Pinninck]

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 <israel...@gmail.com>

[Jorge Muria]

Hola

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.

Un saludo

[Miquel A. Mora]

Comento mi caso por si aporta en el hilo

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

[Harringer]

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

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

[Daniel Ceillan]

El 18 de febrero de 2012 10:41, Harringer <harr...@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...

Saludos!

--
Daniel Ceillan

Blog: www.agile-patterns.com

[Miquel A. Mora]

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 ?

[Daniel Ceillan]

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.

[Miquel A. Mora]

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

[Fermin]

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.

[Daniel Ceillan]

El 18 de febrero de 2012 16:11, Fermin <fermi...@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++)

[Harringer]

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

--

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.

[Daniel Ceillan]

El 18 de febrero de 2012 19:07, Harringer <harr...@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...

[jorge baez]

no, no es lo mismo

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.

[Harald Messemer]

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.

De http://continuousdelivery.com/ extraigo sobre Despliegue Continuo:

"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...@gmail.com>

[Alfredo Casado]

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.   

[Daniel Ceillan]

Gracias por la excelente explicacion! 

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

Abrazo!

[Cramtirolf]

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,

A10,
Cramtirolf

[jorge baez]

+1

es el siguiente paso... peo el escalón es alto

(control de versiones, compilación continua, integración continua, despliegue continuo) #lol

[Harringer]

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

[jorge baez]

igual en lugar de deploy tenía q haber puesto delivery ;)

[Miquel A. Mora]

+ 1 muy interesante el hilo, increíble ver como "fluye" la comunicación, se ha hablado de forma interantisima 

• Dedicación SM / PO en entorno de Continuos Deployment (desarrollo continuo)
  
• Experiencias en Gestión de proyectos de Desarrollo continuo (Application lifecycle management)
  
• TDD en despliegue continuo de software a medida
  
• Gestionar proyectos / gestionar incidencias con scrum y kanban
  
• Integración Continua en un entorno productivo
  
• Continuos delivery (como el "santo grial" del desarrollo)
  

Muchas gracias a todos. A seguir siguiendo que esto promete ;)

[Daniel Ceillan]

+1

Gran hilo!

Aporto mis respuestas a las preguntas que plantearon. Solo es mi punto de vista...

+ Scrum o Kanban.

Kanban sirve cuando necesitas entregar soluciones y no puedes o no debes esperar 2 o 3 semanas. Es muy bueno para solucion de bugs, creacion de documentos de consultoria, equipos pequeños o proyectos muy pequeños.

Lo malo de Kanban es que se pierde el time-box, o caja de tiempo. Es ese limite de tiempo en el cual no dejaras nada a medio hacer, pararas la produccion para ejercer mejora continua (retrospectivas) y corregiras el cristal de estimacion asi como la velocidad del equipo para mantener una velocidad feliz.

Scrum sigue siendo la reina de agiles. Si bien no es para todos los proyectos, equipos o clientes, si lo es para el 80% de ellos. Su exito esta archidemostrado y no solo en ambientes de desarrollo de software. Se aplica Scrum a equipos de marketing, a la gestion de empresas, a equipos creativos, y un sin fin de actividades humanas. Yo lo he aplicado a educacion por ejemplo.

Tambien es muy bueno Scrum para procesos indefinidos. Cuando no sabemos lo que va a llevar. El timebox te pone un limite a la aproximacion, y eso evita que dediques mas tiempo del necesario a un proceso.

+ Continuous Deployment

Es una tecnica fascinante, altamente productiva y competitiva, pero de alto riesgo. Obviamente no es para todos los proyectos. Pero no le veo mucha conexion con lo agil, ya que no veo metodos de proteccion del equipo. El mismo queda muy expuesto y bajo un nivel de alta presion orientada a la entrega. Se pierde el proceso de QA. Por lo menos yo no lo veo para mis proyectos.

Como dijeron ahi, "no intenten en casa esto es para profesionales". Es algo peligroso y requiere altos equipos. Esos equipos que terminan algo y esta perfecto.

+ TDD

Hay muchos detractores del TDD, pero hay que decir siempre lo mismo. Nada es para Todo.

No podras ni deberas aplicar TDD a todos tus proyectos, ni a todos los procesos de un determinado proyecto. Y al iniciarte, no deberas pretender dominar la tecnica de la noche a la mañana. Usualmente toma 1 o 2 meses acomodarse a ella...

Para los que se inician son muy buenos los CodingDojos.

Es dificil al principio hacer babysteps, y armar los tests ya que algunas partes del sistema son dificiles de testear sobre todo si trabajas con Java.

TDD ES la solucion al desarrollo complejo. Si tienes un componente de software que debe tener comportamientos complejos dependiendo del estado de muchas variables del entorno... la solucion es TDD.

Tambien facilita la incersion de nuevos miembros al equipo, hace que la linea de progreso y avance en el proyecto sea mas recta. Por ende mas facil de avanzar. Esto es porque los desarrolladores se pueden enfocar en salvar el test actual, y se despreocupan del resto del sistema. De todas maneras si sus cambios rompen otra parte, los tests le avisaran...

Listo eso es todo...

Saludetes!