El documento compara las experiencias obtenidas con las metodologías Scrum y PMI. Scrum promueve el trabajo en equipo a través de reuniones diarias y retrospectivas que mejoran la comunicación y detección temprana de problemas. PMI es más burocrática y los cambios tardan más en implementarse. La conclusión es que Scrum es más adecuada para proyectos ágiles con ciclos cortos que no aburren al equipo.

1. La idea de esta slice es mostrar las experiencias obtenidas con las metodologias SCRUM y PMI.
Actualmente sacamos mucho provecho de las reuniones diarias de 20 minutos para tener visibilidad de cada
miembro del equipo que Scrum propone. Esto genera confianza y motivación ante el avance que se hace
diariamente. Hay que admitir que a veces no se tienen ganas de hacerlas ya que debemos ir a una sala
desconcentrandos de nuestro trabajo. Le hacemos algunas pequeñas adapaciones a las temáticas de las
reuniones pero en lineas generales se respeta el formato original. Otro punto fuerte es la retroespectiva
que se hace al final del sprint para analizar exitos, fracasos y lecciones aprendidas. Soy fan de esto por
que permite analizar que se hizo bien o mal para mejorar. En nuestro caso, el ScrumMaster se mantiene
alejado de los problemas puntuales de coding enfocandose en lo burocrático lo cual es bueno ya que a la
mayoria del equipo no le interesa para nada estos asuntos.
Con respecto a mi experiencia usando la metodologia PMI es que es super burocrática en el ámbito de la
consultoría donde todo es para ayer y hay muchos de pasos a realizar propuestos por PMI que se realizan
o no con muy mala predisposición. Debo decir que daba mayor visibilidad del trabajo que haciamos frente
a los clientes / jefes. Por otro lado, aplicabamos solo lo necesario para nuestros casos ya que eran
proyectos de corta duración y no tenia sentido todo lo propuesto.
Como conclusión por la experiencia obtenida con ambas, opto por SCRUM ya que te da más tiempo para
reparar errores y poder trabajar en varias perspectivas del proyecto al mismo tiempo ( analisis, desarrollo,
interfaces ) en ciclos cortos no aburriendo ni desmoralizando al equipo ante proyectos que muchas veces
no son bien recibidos por el equipo.
VS

2. En el Teatro Cervantes estoy usando metodologías ágiles para el desarrollo de sistemas. Área
recientemente creada y con muy poca gente (1 programador, 1 arquitecto-programador). Actualmente
estamos desarrollando un software de gestión de bienes de consumo para el área de suministros. Luego
de 7 meses estamos en la fase final. Creo que los dos principales factores que han ayudado mucho en el
proceso son las reuniones periódicas (semanales o quincenales) y estar abiertos al cambio siempre
(no se negocia, se hace). Esto ha permitido que el producto se vaya puliendo constantemente y al
transitar juntos ese camino los programadores y los usuarios se sientan cómodos durante todo el
proyecto.
Considero que esta forma de trabajo es ideal en el contexto del Teatro, ya que es un pequeño Organismo
del Estado Nacional, donde los factores costo, y a veces tiempo pueden no ser preponderantes, y poder
hacer que el alcance sea el más apropiado para las áreas usuarias es el mejor resultado que se pueda
obtener.
Además la rigidez y burocracia de los mecanismos de compra harían que los procesos de desarrollo sean
muy complicados si tuviéramos que tercerizar.
Creo que para proyectos de desarrollo puntuales para áreas específicas las metodologías ágiles son las
más apropiadas. Mientras que si tuviera que realizar un desarrollo o implementar un software transversal
a todo el Organismo usaría herramientas de PMI.

3. Individuos e interacciones VS Procesos y herramientas
Software funcionando VSDocumentación comprensiva
*Comparativa basada en el
manifiesto ágil
•
Prioridad al equipo: donde trabajo,
equipo estable de 2 años.
•
Sprints: siempre sale algo nuevo por
sprint y cerrás el anterior.
•
Prioridad a la metodología: donde trabaje,
alta rotación.
•
Desarrollos largos: abrurrimiento y poca
creatividad, siempre venían a retocar
cosas de 1 mes atrás.
•
Delivery continuo de software desde el
primer minuto.
•
Integración de toda la aplicación y
visibilidad completa del trabajo
generado.
•
Mucha documentación al comienzo para
el PM, tiempos muertos para el
desarrollador. No se leyeron nunca.
•
Se dependen de documentos para el
desarrollo que no siempre están bien y
claros, muchas veces había que llamar o
enviar mails.

4. Colaboración del cliente VS Nogociación contractual
Respuesta al cambio VSSeguir un plan
*Comparativa basada en el
manifiesto ágil
•
Se le consulta continuamente al PO, que
es parte del equipo además.
•
Canjeamos tareas frente a cambios en 20
minutos de daily meeting.
•
El cliente no era parte del equipo por lo
que era un trato distinto.
•
Cada cambio, si bien aceptado, llevaba días
de reacomodo.
•
Plannings por sprint, lo que permite, si
hay cambios y se cae una historia, tomarla
el próximo sprint.
•
Cambios durante el sprint son tomados
como deseables por el equipo.
•
Plan altamente estructurado, ya de por sí en
un archivo project.
•
Había preocupación a largo plazo. La meta
estaba muy lejos.

5. Scrum
PMI
Percepción de las personas de las
metodologías
ROL: Scrum Master
PROBLEMA: imposibilidad al
implementar las reuniones diarias por
flexibilidad de horarios en el equipo.
SOLUCION: Mayor presencia como
facilitador e intercalar técnicas de XP
para distibuir el conocimiento.
CONCLUSION:
Pude apreciar que con está metodología
la curva de aprendizaje de los nuevos
integrantes es más rápida que en
metodologías PMI.
El trabajo en equipo es más visible y la
detección de desvíos se realiza de
manera más temprana.
ROL: Programador, Analista y PM
PROBLEMA: La comunicación. Al no
establecer un diccionario común entre los
participantes hizo que algunos proyectos
tengan una tasa de bugs importante.
El aplicar la metodología de forma
secuencial llevo en todos los casos a que el
project solo se consulte para buscar
culpables o calcular cuan desviados ya nos
encontramos.
CONCLUSION:
Por falta de madurez no se llego a utilizar
correctamente las herramientas para
implementar la metodología y por lo tanto
no se generó un biblioteca de lecciones
aprendidas.
Propuesta de las metodologás
En ambos casos se promueve:

Participación

Integración

Calidad

Versatilidad

Reutilización

Madurez

6. Scrum
PMI
Percepción de las personas de las
metodologías
ROL: Scrum Master
PROBLEMA: imposibilidad al
implementar las reuniones diarias por
flexibilidad de horarios en el equipo.
SOLUCION: Mayor presencia como
facilitador e intercalar técnicas de XP
para distibuir el conocimiento.
CONCLUSION:
Pude apreciar que con está metodología
la curva de aprendizaje de los nuevos
integrantes es más rápida que en
metodologías PMI.
El trabajo en equipo es más visible y la
detección de desvíos se realiza de
manera más temprana.
ROL: Programador, Analista y PM
PROBLEMA: La comunicación. Al no
establecer un diccionario común entre los
participantes hizo que algunos proyectos
tengan una tasa de bugs importante.
El aplicar la metodología de forma
secuencial llevo en todos los casos a que el
project solo se consulte para buscar
culpables o calcular cuan desviados ya nos
encontramos.
CONCLUSION:
Por falta de madurez no se llego a utilizar
correctamente las herramientas para
implementar la metodología y por lo tanto
no se generó un biblioteca de lecciones
aprendidas.
Propuesta de las metodologás
En ambos casos se promueve:

Participación

Integración

Calidad

Versatilidad

Reutilización

Madurez