Conoce a tu enemigo, conoce su espada

[Vicenç Garcia]

Hola buenas,

andaba troleando un poco hoy a Jose Manuel Beas (desde el cariño y el respeto, claro está) porqué el pobre hombre andaba viendo videos de ITIL y de COBIT (reconozco que es la primera vez que oigo hablar de COBIT).

El tema es que Jose me ha dicho que hay que conocer al enemigo y mi pregunta es: son estas metodologias o procesos ( o como queráis llamarlo ) enemigos del agilismo?

Entiendo el punto de Jose en que afirma que lo que proponen estas metodologias está alejado de los principios ágiles y que si alguien entra a hacer una transformación en una empresa que lo ha aplicado (o lo sigue haciendo) tendrá mucho trabajo.

Mi punto viene más en la palabra enemigo, que evoca a confrontación. Hay que luchar contra otras metodologias para ver quien es mejor? Tenemos que diferenciarnos simplemente porque somos un poco mejores que otra metodología o por que realmente aportamos valor? Nuestro mensaje tiene que ser que somos un poco más guais que ITIL?

Se que la pregunta es chorra y que me diréis que no, que esto es la leche por si solo, pero le he prometido a Jose que postearía por aquí y, a parte, veo que esto se va animando ultimamente y hay que mantener el impulso.

Un abrazo,.

--

Vicenç García

http://vgaltes.com

http://geeks.ms/blogs/devnettips
http://www.linkedin.com/in/vgaltes
http://www.twitter.com/vgaltes

ᐧ

[Rubén Pila]

Supongo el conoce a tu enemigo viene de Sun Tzu y el arte de la guerra. Independientemente de mi anterior frase, gran error de enfoque a mi entender. Ninguna metodología está por encima de las demás, ni tampoco hay que forzar para que el agilismo sea la solución a todo problema/empresa. En definitiva no es EL enfoque, es uno más.

Sin acritud. Sólo una opinión.

Saludos

- Pila -

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CALdEnKrOXLK9wWCf7%3Drt8R%3DV1MJ0qs90Ca%3DNrXG2Vq7pe_6b3A%40mail.gmail.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Harringer]

En mi opinión la, mejor metodología es la que a uno le da buenos resultados.

La, comparación entre Agile y ITIL/CeBIT tiene poco sentido, dado que Agile describe un como hacer las cosas para conseguir, mientras que las otras dos describen que cosas valen la pena de conseguir. Nadie discutirá la utilidad de tener un Serviceleistungen que funciona, ni medir si se consigue un objetivo.

Saludos,
Harald

Saludos, Harald Messemer Enzyme Advising Group 672456096

--

[Gabriel Osorio]

Hola,

Creo entender el punto porque me hice una pregunta similar.

Cuando recién empecé a frecuentar a la comunidad ágil me gustaron los coding dojos (orientados en general a pruebas unitarias) y las conferencias sobre scrum y contratación ágil. Una de las cosas en las que se insistía en todos ellos era que el fundamento del agilismo es la calidad del artesano. Pero, excepto por TDD, el agilismo no daba mayores detalles sobre aseguramiento de la calidad.

Me di cuenta que aunque seguía buenas prácticas y había leído usado RUP y patrones de software, no conocía un marco de calidad formal tipo ISO9000. Así que busqué y, por azar, tuve la oportunidad de estudiar PSP (personal software process) directamente con socios de Carnegie Mellon y me certifiqué. Es decir, fui directamente a los elementos del lado derecho del manifiesto (¿antimanifiesto?) ágil. La razón: cualquier marco de calidad es mejor que ninguno; así sea el monstruo que nos pinta el agilismo.

Mi conclusión respecto a PSP: Se pueden notar las buenas intenciones y da buen contexto y herramientas de aseguramiento de la calidad, tanto, que debiera enseñarse en las universidades. Pero, el método que se plantea para usarlas busca convertir a los humanos en máquinas a las que se le pueden revisar los medidores (imagínense a los programadores en un galpón o barraca como pollos y un capataz que pasa revisando los medidores puestos en sus espaldas sin apenas cruzar palabra.)

Respondiendo la pregunta: no solo hay que conocer al enemigo, hay que saber como piensa, a qué sabe y cuales son sus valores, objetivos y hasta a qué escuela asistió. Hay que saberlo porque eso nutre y fundamenta lo que en pocas palabras el agilismo promueve.

Y anticipando una pregunta que tal vez nadie haga, gran parte de PSP (o parecidos) puede evolucionar para ser empleado en equipos ágiles sin perder los elementos de la izquierda del manifiesto. Lo imagino como un software tipo ayudante personal (un socio con mucha memoria), en lugar de un capataz tirano y quisquilloso.

(Nota: me certifiqué como scrum product owner después y no se parece en nada a lo de PSP.)

Saludos!

Gabriel

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/1423248308130.0b161ec2%40Nodemailer.

[José Manuel Beas]

Hola a todos,

El lema "Conoce a tu enemigo, conoce su espada" es atribuido al artesano de la espada Miyamoto Musashi y no a Sun Tzu, el autor del conocido "El Arte de la Guerra". Esta frase se refiere a la importancia estratégica de conocer en detalle las cosas que están lejos y de alejarnos de las cosas que están cerca. De esta manera es más difícil que nos distraigamos por "movimientos insignificantes de la espada de nuestro enemigo". Seguramente la confusión viene de esta otra cita de "El Arte de la Guerra":

Por tanto os digo: Conoce a tu enemigo y conócete a ti mismo; en cien batallas, nunca saldrás derrotado. Si eres ignorante de tu enemigo pero te conoces a ti mismo, tus oportunidades de ganar o perder son las mismas. Si eres ignorante de tu enemigo y de ti mismo, puedes estar seguro de ser derrotado en cada batalla.

Saliendo de la metáfora bélica y de las espadas, mi conversación con Vicenç estaba relacionada con mi interés por conocer los problemas que otros tratan de resolver desde paradigmas muy diferentes al agilismo. De esta manera estoy preparado para responder a un cliente cuando me plantea un reto del tipo "yo esto ahora lo resuelvo con la metodología XYZ, ¿cómo resuelve esto el agilismo?".

No se trata, por tanto, de ver a otras metodologías como "enemigos" ni al agilismo como "la metodología que os liberará". Afortunadamente, este discurso ha sido superado hace tiempo. Lo que sí es cierto, es que el "mindset" en el que se basan métodos como ITIL choca muchísimo con el "mindset agilista". El primero busca el control desde los procesos mientras que el segundo lo consigue desde la confianza en las personas. Lógicamente, ninguno de los dos se puede aplicar en todos los contextos. Un equipo de novatos en un entorno propenso a castigar el error no debería hacer Agile.

Lo dejo ahí porque sé que así seguiremos el debate. Je, je... ^_^

Un cordial saludo,

Jose Manuel Beas

http://jmbeas.es

[Pedro Gustavo Torres]

Hi couldn't agree more with Beas. :)

If we don't know what else is out there how can we say that Agile is different/better than other tools?

Knowing the "enemy" is a must have in order to give proper advise and understand the context.

Saludos,
Pedro

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a agile...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAD8mR90q3yg9B0ZpQthWtGekpABRKTv9krFnR9QMZeOWaZPU6g%40mail.gmail.com.

[Julio César Pérez Arques]

Aunque uses otras palabras, tu mensaje parece el mismo que dices que está superado: Agile es lo más, todo lo anterior está equivocado. Sé Agile, sé cool, o ya que estamos sé water que es aún más guay y fluido.

Creo que pretender sustituir ITIL por Agile es un error importante de concepto. Si vas con ese enfoque a un cliente que de verdad conoce y aprecia ITIL, dudo que se sienta muy interesado en contratar tus servicios. Puede que te vaya mucho mejor pretendiendo optimizar los procesos usando Agile, que se han definido con ITIL. Pero antes harás bien en estudiar ITIL.

"Un equipo de novatos en un entorno propenso a castigar el error no debería hacer Agile."

Luego esta frase me ha matado. En Agile no hay espacio para los novatos, no hay errores? ITIL castiga? Mucho prejuicio, no?

[Carlos Peix]

2015-02-09 4:32 GMT-03:00 Julio César Pérez Arques <julio.cesar....@gmail.com>:

Aunque uses otras palabras, tu mensaje parece el mismo que dices que está superado: Agile es lo más, todo lo anterior está equivocado. Sé Agile, sé cool, o ya que estamos sé water que es aún más guay y fluido.

Creo que pretender sustituir ITIL por Agile es un error importante de concepto. Si vas con ese enfoque a un cliente que de verdad conoce y aprecia ITIL, dudo que se sienta muy interesado en contratar tus servicios. Puede que te vaya mucho mejor pretendiendo optimizar los procesos usando Agile, que se han definido con ITIL. Pero antes harás bien en estudiar ITIL.

No que tenía en la cabeza JMB, pero a veces uso el recurso de extremar posiciones "durante los debates" lo cual me permite expresarme mejor con un lenguaje menos preciso. Aquí vale sumar la historia del quien habla para comprender de donde viene.

 

"Un equipo de novatos en un entorno propenso a castigar el error no debería hacer Agile."
Luego esta frase me ha matado. En Agile no hay espacio para los novatos, no hay errores? ITIL castiga? Mucho prejuicio, no?

Yo interpreté justo lo opuesto. JMB no habla contra los novatos, mucho menos con agilismo y novatos. Lo que yo entiendo es que el sugiere es que un entorno que castiga el error (no habló de ITIL en esa frase) no es adecuado puesto que, en muchas ocasiones, sobre todo cuando somos novatos, llegamos al error cuando probamos nuevos caminos o nuevas maneras de hacer las cosas, buscando la mejora.

Un saludo!

 

El jueves, 5 de febrero de 2015, 22:54:50 (UTC+1), Vicenç García escribió:

Hola buenas,

andaba troleando un poco hoy a Jose Manuel Beas (desde el cariño y el respeto, claro está) porqué el pobre hombre andaba viendo videos de ITIL y de COBIT (reconozco que es la primera vez que oigo hablar de COBIT).

El tema es que Jose me ha dicho que hay que conocer al enemigo y mi pregunta es: son estas metodologias o procesos ( o como queráis llamarlo ) enemigos del agilismo?

Entiendo el punto de Jose en que afirma que lo que proponen estas metodologias está alejado de los principios ágiles y que si alguien entra a hacer una transformación en una empresa que lo ha aplicado (o lo sigue haciendo) tendrá mucho trabajo.

Mi punto viene más en la palabra enemigo, que evoca a confrontación. Hay que luchar contra otras metodologias para ver quien es mejor? Tenemos que diferenciarnos simplemente porque somos un poco mejores que otra metodología o por que realmente aportamos valor? Nuestro mensaje tiene que ser que somos un poco más guais que ITIL?

Se que la pregunta es chorra y que me diréis que no, que esto es la leche por si solo, pero le he prometido a Jose que postearía por aquí y, a parte, veo que esto se va animando ultimamente y hay que mantener el impulso.

Un abrazo,.

--

Vicenç García

http://vgaltes.com

http://geeks.ms/blogs/devnettips
http://www.linkedin.com/in/vgaltes
http://www.twitter.com/vgaltes

ᐧ

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a agile...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/e2a3aa4e-3206-47a6-94b0-1915fd9e726b%40googlegroups.com.

[José Manuel Beas]

Hola,

Julio César, lástima, no me expliqué bien. Nada más lejos de mi intención atacar ITIL. Lo que no me gusta es el mindset con el cuál éste se aplica. Podría citar otros frameworks, incluso ágiles, que se introducen en las organizaciones manteniendo la jerarquía y los procesos como presunta garantía de éxito. Por tanto, no es el framework el que castiga sino el mindset. [Por favor, ¿alguien tiene una buena traducción para mindset? ^_^]

No digo que Agile sea cool. Lo que digo es que yo prefiero trabajar en un entorno donde se da preferencia a la colaboración entre personas y no a procesos y jerarquías. Y lo prefiero desde un punto de vista personal y desde un punto de vista de negocio. Puedo argumentar que las compañías ágiles son más productivas, adaptables al cambio y, en el medio-largo plazo, más competitivas que sus rivales. Luego, cada uno que haga lo que le plazca. :)

Por otro lado, me gano la vida llevando estos cambios a organizaciones donde la cultura existente no siempre es la más adecuada para empezar con "todo el libro" y hay que decidir por dónde empezar. De ahí lo que Carlos ha entendido tan bien. No debemos poner a la gente en su zona de fracaso, sobre todo si no entienden bien qué beneficio les van a reportar los cambios que les pedimos. Entender las necesidades que tienen cubiertas mediante otras soluciones no ágiles también es importante para un consultor que pretende ayudar a una organización a cambiar profundamente. Por ejemplo, habéis pensado en qué ocurre en el siguiente escenario:

Una organización, en razón de su negocio, debe tener auditados todos sus cambios en el código y la infraestructura que lo soporta. Para cada cambio tienen unos procesos de supervisión y autorización que provocan enormes cuellos de botella. Ahora llegan estos agilistas que dicen que todo va en Historias de Usuario y que los responsables son los equipos, de manera colegiada. Por cierto, los equipos están formados por profesionales de diferentes empresas y algunos son muy, muy novatos. ¿Creéis que debemos quitar esos procesos de supervisión y autorización antes que nada? Son el mayor cuello de botella de la organización con diferencia. ;-)

Para aplicar un pensamiento sistémico a una organización compleja es necesario enriquecer nuestra caja de herramientas e incorporar el mayor número posible de puntos de vista o caeremos en simplificaciones que podrían dañar a nuestros clientes.

Perdón por el ladrillazo. :D

Un cordial saludo,
JMB

[Helder De Oliveira]

mindset {

   trad.: mentalidad

   sin.: peculiaridad, característica, pensamiento, parecer, concepción, ánimo

}

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a agile...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAD8mR90ZFi2wQPecq8DQT1Zh%2B93KXvOMrMUhBwicenu1Td4fmg%40mail.gmail.com.

[José Manuel Beas]

Helder.abrazo(self);