Otras Metodologias ( PMI,Prince2,IPMA,Metrica3) y su convivencia o no con la agilidad.
Jonathan Vila Lopez
-----------------------------------------------
Slitzweitz !!!!!!
Algo que ya ha salido: métrica vs scrum en administración pública. No me interesa para nada, pero seguro que a otros sí.*lo contrario de ágil no es tradicional*, que seguro que nos suena2010/2/18 José Manuel Beas <jose....@gmail.com>2010/2/18 jorge <jorge...@gmail.com>¿Podrías concretar un poco más? ¿Poner ejemplos quizás?Yo creo que ese déficit, si existe, no pertenece al ámbito del grupo. :)
Vale, yo había entendido que Juan sólo se refería al grupo (teniendo en cuenta el título del hilo).
Como mucho, lo enfocaría con comparaciones, benchmark, temas que se puedan aplicar (cortar y pegar)...
Un saludo,
JMB
--
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.
Abel Muiño Vizcaino
Mi duda es sencilla.......... Por que ?Que os ha hecho plantearos otras opciones y descartar estas ?No les habeis visto utilidad ( porque ? ) ? etc......No creeis que sean compatibles con la agilidad ? porque ?
Jorge Uriarte Aretxaga
> Que os ha hecho plantearos otras opciones y descartar estas ?
> No les habeis visto utilidad ( porque ? ) ? etc......
> No creeis que sean compatibles con la agilidad ? porque ?
>
¿Alguien habló el otro día de "encontrar tu propio camino"?
Quizás es porque yo soy por naturaleza escéptico, y un "culo
inquieto", pero creo que nuestra obligación en la vida es cambiar,
evolucionar, aprender, equivocarnos y levantarnos.
Es esencial asumir que cada poco tiempo tenemos que desprendernos de
nuestras creencias y quedarnos otra vez "en pelotas en bajo la
lluvia".
En mi camino, el problema no ha sido casi nunca metodológico sino de
adopción. Las metodologías a menudo supuran sentido comun y
practicidad, mientras que las implementaciones las fosilizan y las
hacen
En el 97 pasé por la epifanía de formación en CMM (todavía no tenía la
"I"!!!), que me exorcizó de las barbaridades que sufría nuestro sector
"en el nombre de la ISO" y se centraba en areas de proceso y mejoras
tangibles en la productividad. Al de unos años estaba totalmente
decepcionado con el rumbo que había tomado el tema.
PMBOK (y otros como SWEBOK, más criticados y probablemente con mucha
razón :) ) son lecturas que alimentan el espíritu, siempre que uno no
tenga tendencia al fanatismo y sea crítico.
En mi caso me quedé de nuevo "en pelotas bajo la lluvia" al dejar una
de esas multinacionales y meterme en una startup en la época de las
puntocom. De repente todo el conglomerado burocrático había
desaparecido... gracias a dios... pero tambien había perdido los
objetivos detrás de ese conglomerado, mejorar la calidad y la
eficiencia de los desarrollos, garantizar el mantenimiento, documentar
*lo necesario* para garantizar que las rotaciones no afectarían a la
evolución de los sistemas, que los desarrollos se probaran *lo
suficiente*, ... y tuve la suerte de que hubiera dinero suficiente
(qué tiempos!) para atacar y experimentar con mejoras de proceso.
Y RUP, que empezaba a tener su nombre... parecía lógico pero
tremendamente inadecuado a nuestros ritmos productivos... (y asistí a
unas charlas de Ivar Jacobson que me hicieron dudar de todo... de
nuevo...)
Y tuve la suerte de que apareciera un lunático y me dijera: "embrace
the change!" "YAGNI". Y al principio no quería creerle... pero jodé,
me convenció... y de ahí a FDD, y a los libros de Coad... gente que
había peleado dentro de estructuras tradicionales, y que había
demostrado que había formas de conseguir eficiencia y retorno...
Perdón, respondo a tus preguntas:
- Yo no las descarto. Pero creo que no hay metodología "out of the
box" que se adapte a lo heterogeneo de nuestras organizaciones, al
menos hoy en día.
- Son útiles, utilísimas, para iluminar, establecer espacios de
nombres, proponer soluciones, y pueden funcionar siempre y cuando se
apliquen con cabeza y corazón (y esto aplica a todo, tambien a las
"ágiles", pero claro, las ágiles son menos costosas de implantar, con
lo que su porcentaje de éxito relativo es mayor)
- Son, casi siempre, compatibles con esa abstracción que llamamos "la
agilidad", o mejor, los principios ágiles pueden vivir en el marco de
una metodología "tradicional" (perdón!), siempre y cuando esa misma
metodología sea fiel a sus principios de revisión y mejora continua, y
que la organización sea lo suficientemente flexible como para
modificar los marcos metodológicos cuando no son eficientes, lo que
por otra parte debería ser una obligación de las organizaciones...
No creo que haya balas de plata, no creo en libros sagrados, no creo
en verdades reveladas ni en castigos divinos. Creo en mi trabajo, creo
en mi capacidad para reconocer mis errores y aprender de ellos, y creo
en mi capacidad para ayudar a otros en el camino :)
_
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte
Xavi Gost
Lo que quiero decir es que no hago una eleccion por contraposicion a
otras metodologias, cuando encontre XP (el librito de Beck por
accidente, reseñado en un Wired) y lo lei, me hablaba a mi, conseguia
verbalizar cosas que estaban en mi cabeza, que me decia mi
experiencia, que iban con mi personalidad y el entorno en el que
estaba trabajando asi que la adopte.
En cualquier caso , dudo que sea necesario un cuerpo teorico acerca de
metodologias para poder discutir, opinar y crear sobre agile...
Personalmente yo carezco de formacion especifica y espero que se me note.
Xavi Gost
harr...@gmail.com
-PM-BOK no es una metodologia, sino una coleccion de conocimiento
-PMI es el gestor del PM-BOK
-SCRUM es una metodologia, pero de gestion
-Metrica-3 es una metologia de un sector para proyectos de TI cubriendo la gestion y la construccion
-el "Agile Manifest" no es un codigo de conducta o de unas pautas genericas
-RUP es una metodologia para desarrollar software, pero no cubre la gestion de forma explicita
-CMMI es un metodo para evaluar el grado de madurez de una organizacion que produce software
Podriamos seguir asi, pero creo que ya se ve a donde quiero llegar. Por lo menos los puntos arriba mencionados son perfectamente combinables y complementarias.
Recomiendo antes de comparar y argumentar desgranar algo lo que se quiere comparar. Ejemplo: podriamos comparar scrum con chrystal clear.
Un saludo,
Harald
Enviado desde mi BlackBerry® de Vodafone
Jonathan Vila Lopez
Carlos Díez-Gil Romero
Legnita
Jonathan:
Las metodologías a las que nos referimos como tradicionales tales como
el PMBoK (Project Management Body of Knowlegde) del PMI (Project
Management Intitute) están haciendo una aproximación hacia las
metodologías ágiles que podemos ver en la creación de una comunidad de
ágil dentro del PMI: http://agile.community.pmi.org/Pages/Default.aspx
en la que más de 300 miembros del PMI participamos. Esto es sin duda
un reconocimiento de las bondades de las metodologías ágiles y una
aceptación de que son compatibles con estas metodologías o marcos
metodológicos. Aspectos como las reuniones diarias, el desarrollo
incremental, la planificación del sprint y su revisión, la figura del
product owner, etc. etc en absoluto son incompatibles con el PMBoK o
PRINCE2 (Projects in Controlled Environments) de la OGC del Reino
Unido.
Para mí la revolución de SCRUM u otras metodologías ágiles proviene
del contexto, del entorno que crean al poner juntas y en orden una
serie de prácticas que estimulan la colaboración y el compromiso de
todos los participantes y, como dijo Xavi Albaladejo en Agile Spain
2009, consiguen sacar lo mejor de todos nosotros. La antipatía que
producen las metodologías "tradiciones" en parte de la comunidad ágil,
no creo que provenga de los procesos, organización o prácticas que
proponen, que por otro lado son muy desconocidas, sino por los
contextos de trabajo que crean y que son conocidos y sufridos por
muchos.
No soy dogmático ni defensor ni enemigo de ninguna metodología. Sí lo
soy de aquellos que se aferran a la "teoría española"
http://legnita.wordpress.com/2006/08/08/la-teoria-espanola/ y
distornionan el PMBoK, PRINCE2, RUM o incluso SCRUM y ponen por
delante de las personas los procesos, objetivos...
Cada proyecto es distinto a todos los demás y requiere enfoques
distintos. Conocer diversas metodologías nos permite poder seleccionar
los más apropiado de ellas para cada proyecto. Por este motivo no
deberíamos despreciar ninguna, bueno quizás sí Métrica 3 por su falta
de evolución que la ha convertido en casi pieza de museo, porque
hacerlo significa perder oportunidades para hacer los proyectos mejor.
Saludos,
Angel
pd: por si no me he conseguido explicar bien con eso del contexto
recomiendo leer The tipping point.
Francisco Hueso
Me estoy iniciando en la Gestión de Proyectos y casualmente encontre
este grupo, en el que creo me podeis orientar bastante. He de decir
que mi fin no son los métodos ágiles, pero espero que me puedan
ayudar.
En principio quiero hacerme una idea general de los métodos o modelos
de Gestión que existen, algo esquemático, donde pueda conocer con lo
que se trabaja actualmente (tanto predictivo como ágil). Desconozco si
existe algun libro que trate de esto o si ustedes mismos me los podeis
indicar.
Un saludo y muchas gracias.
Fracisco Hueso.
Jonathan Vila Lopez
Si quieres te puedo pasar un resumen del PMBOK (PMI) que hice para pasar el examen...... tal vez eso te de una pequeña idea de lo que va..... Te adelanto que no es una metodologia sino unas recomendaciones de buenas practicas y no es concreta del desarrollo de software......es una de las mas "famosas" aunque existen otras ( IPMA, Prince2... )
Saludos.
-----------------------------------------------
Slitzweitz !!!!!!
Francisco Hueso
En realidad lo que me gustaría conocer son esas otras que existen,
como IPMA, Prince2, etc. Quiero decir, aquellos "metodos" de gestión
de proyectos que son utilizados hoy día, de forma general, a pesar de
que no sean los mejores.
Saludos.
On 13 abr, 09:53, Jonathan Vila Lopez <jonathan.v...@gmail.com> wrote:
> Hola Francisco......
>
> Si quieres te puedo pasar un resumen del PMBOK (PMI) que hice para pasar el
> examen...... tal vez eso te de una pequeña idea de lo que va..... Te
> adelanto que no es una metodologia sino unas recomendaciones de buenas
> practicas y no es concreta del desarrollo de software......es una de las mas
> "famosas" aunque existen otras ( IPMA, Prince2... )
>
> Saludos.
> -----------------------------------------------
> Slitzweitz !!!!!!
>
> 2010/4/13 Francisco Hueso <franhu...@gmail.com>
> > agile-spain...@googlegroups.com<agile-spain%2Bunsu...@googlegroups.com>
Legnita
El 9 de junio daré una conferencia de 30 minutos sobre PRINCE2, PMBOK
y quizás algo de SCRUM. Los detalles todavía no los tengo decididos,
pero hablaré, como he hecho en otras ocasiones, de que no son
excluyentes sino complementarias.
La asistencia es gratuita https://docs.google.com/viewer?url=http://www.qrpmmi.es/sp/_news/Forum_Madrid10.pdf
Pido disculpas si esto se puede interpretar como publicidad.
Saludos,
Ángel
David Palomar
La clave sobre elegir o descartar una metodología creo sinceramente
que es el desconocimiento como primer factor y como segundo el negocio
al que va dedicado.
Pese a lo comentado en otro hilo de este mismo foro, el negocio y el
marco de trabajo al que va destinado la creación del software es muy
importante, como los equipos, roles y herramientas y no sólo las
prácticas de desarrollo.
Todas las metodologías disponen de una parte orientada a conseguir la
calidad y aquí es donde aparecen las distintas técnicas en mejor o
peor medida para conseguirlo. Afirmar que si no se realiza una
determinada práctica en concreto no se está haciendo una metodología
real es una visión muy pobre de los sitemas de desarrollo.
La metodología o marco de trabajo a elegir dependerá entonces del
factor negocio, por ejemplo métrica es una metodología demasiado
rígida y grande para poder aplicarla a procesos rápidos debido a la
gran cantidad de información que hay que generar, por lo tanto no
tendría sentido aplicarla a un desarrollo de un portla web de un par
de meses, pero sí es apta para grandes empresas que disponen de muchos
activos que gestionar y donde no puede perderse nada de información, y
aquí es donde entran en juego marcos de gestión y calidad total como
ITIL.
A decir verdad, no conozco ninguna empresa que implante una
metodología estrictamente al 100%, ni de desarrollo, ni de gestión,
todas son adaptadas a las circunstancias del negocio particular. La
mayoría de los marcos de trabajo no especifican cuáles son las
técnicas a aplicar debajo de las recomendaciones que proponen, y aquí
es donde las prácticas ágiles pueden entrar a cubrir ese nicho, además
de revolucionar el panorama de desarrollo (y gestión ) del software
eliminando muchas barreras propiciadas por esas metologías
"monstruosas", aunque cada vez más flexibles y personalizables y como
dice Angel con acercamientos a las prácticas ágiles.
Afirmar que si no se realizan todas las técnicas ágiles no se hace
agilismo, es lo mismo que afirmar que si no se cumplen todos procesos
y documentaciones de métrica o RUP no se está haciendo metodología, la
bondad de la flexibilidad es dependiente del negocio en cuestión.
Creo que incorporar prácticas técnicas ágiles en estas metodologías es
bueno y posible y mejorará la experiencia del desarrollo, así como
incorporar prácticas de gestión ágiles siempre que la metodología lo
permita también redundará en beneficio, todo dependerá de los
estándares a cumplir, y del ámbito del negocio elegido.
Hay proyectos en los que se han incluido prácticas ágiles con CMMI por
ejemplo y han mostrado su éxito, ya que ser ágil implica personas
frente a procesos, tampoco estaría mal conocer qué es lo que han
perdido por el camino y poner en una balanza si merece o no la pena.
Saludos