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

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.

Individuos e interacciones VS Procesos y herramientas

Software funcionando VS Documentació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.

Colaboración del cliente VS Nogociación contractual

Respuesta al cambio VS Seguir 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.

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 PMPROBLEMA: 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