Estudiante: Diego Barrientos Jaldn

Manejo gil de un Proyecto con Scrum

Scrum ha sido creado para sacar productos de problemas complejos y est basado en la teora de control de procesos industriales, utilizando mecanismos como la auto-organizacin. Scrum ayuda a controlar el proyecto de desarrollo de software, lo que no significa que las cosas en proyecto vayan a salir tal cual se esperaban, sino que va a guiar el trabajo para que se vuelva lo ms valioso posible. Scrum sostiene todas sus prcticas en un esqueleto de proceso iterativo incremental. Una iteracin da como resultado un incremento. El esqueleto funciona de esta manera: al principio de la iteracin el equipo revisa que es lo que hay que hacer, seleccionan lo que creen que se puede convertir en un incremento de funcionalidad al final del mini-proceso (que ser presentada a los clientes para hacer una inspeccin) y finalmente se deja que el equipo haga su mejor esfuerzo durante la iteracin. El corazn de Scrum descansa en la iteracin. El equipo analiza los requerimientos, considera la tecnologa disponible y evala sus propias habilidades y capacidades, despus determinan cmo van a construir la funcionalidad, modificando el enfoque y encontrndose en el camino con sorpresas, dificultades y nuevas complejidades. El equipo tiene que darse cuenta qu es lo que se necesita hacer y encontrar la mejor manera de hacerlo.

Los Roles de Scrum Slo hay tres roles en Scrum: el Product Owner, el Scrum Master, y el Equipo. Todas las responsabilidades del manejo del proyecto se dividen en esos tres roles: El Product Owner es el responsable de representar el inters de cualquiera que quiera invertir en el proyecto. sta persona es la que consigue la financiacin inicial y posterior del proyecto, creando los requerimientos iniciales generales, el retorno de la inversin (ROI) y los planes de lanzamiento. La lista de requerimientos iniciales se llama Product Backlog, el Product Owner es el responsable de que las funcionalidades ms valiosas para el cliente y las menos complejas sean hechas primero. El Equipo es responsable de la funcionalidad del desarrollo. Los Equipos se manejan y organizan a s mismos, son responsables del cmo el Product Backlog se va a volver en un incremento de funcionalidad dentro de una iteracin y tambin de manejar su trabajo para realizar aquello. Todos los miembros del Equipo son colectivamente responsables para que la iteracin sea un xito y as mismo todo el proyecto. El Scrum Master es el responsable del proceso Scrum, de ensear Scrum a todos los involucrados en el proyecto y de asegurarse de que se sigan las reglas y prcticas de Scrum. Las personas que asumirn esos roles son aquellas que estn comprometidas con el proyecto. Tambin puede haber personas que estn interesadas, pero que no estn comprometidas. Scrum hace una distincin entre estos dos grupos: las personas comprometidas sern aquellas que tendrn la autoridad necesaria para llevar el proyecto al xito: las que no estn comprometidas no podrn interferir innecesariamente.

Flujo de Scrum El proyecto Scrum inicia con una visin del sistema a desarrollar, que tal vez sea vaga en un inicio, pero conforme el proyecto avance se har clara. El Product Owner formular un plan que incluye un Product Backlog, que es una lista de los requerimientos funcionales y no funcionales que, cuando se vuelvan en una funcionalidad, darn una idea ms clara de la visin del sistema. El Product Backlog est priorizado de tal manera que las funcionalidades ms valiosas son las se harn primero y est dividido en lanzamientos propuestos. El Product Backlog es slo un punto de partida: las prioridades, los lanzamientos, el contenido generalmente cambian cuando el proyecto empieza, como es de esperarse. Los cambios en el Product Backlog reflejan cambios en los requerimientos del negocio y cun rpido el Equipo puede transformar el Product Backlog en funcionalidad. Todo el trabajo se hace en Sprints. Cada Sprint es una iteracin de 30 das consecutivos, y es iniciado con una reunin de planificacin de Sprint, donde el Equipo y el Product Owner colaboran juntos para ver qu se va a hacer en el siguiente Sprint. El Product Owner, escogiendo el requerimiento con ms prioridad del Product Backlog, indicar que es lo que se desea y el Equipo indicar cunto de la funcionalidad ser entregada en el Sprint. El tiempo mximo de de una reunin de planificacin de Sprint es de ocho horas: lo que se quiere es trabajar, no pensar mucho acerca del trabajo. La reunin de planificacin de Sprint se divide en dos partes. En la primera parte, el Product Owner muestra al Equipo el requerimiento del Product Backlog con mayor prioridad, el Equipo hace preguntas y antes de que finalicen las cuatro primeras horas, el Equipo indica cunto del requerimiento podr desarrollar y se compromete a hacerlo de la mejor manera posible. Las siguientes cuatro horas el Equipo debe hacer un plan tentativo del Sprint y las tareas que componen este plan son colocadas en un Sprint Backlog, donde las tareas sern aumentadas a medida que el Sprint avance. El Sprint da inicio.

Cada da el Equipo se junta en una reunin de quince minutos llamada Scrum Diario, donde cada miembro del grupo responde a las siguientes preguntas: Qu hiciste desde el ltimo Scrum Diario? Qu planeas hacer desde ahora hasta el prximo Scrum Diario? Qu impedimentos encontraste conociendo tus compromisos con el Sprint y el proyecto? El propsito de estas reuniones es de sincronizar diariamente el trabajo de todos los miembros y de planificar reuniones necesarias para que el Equipo avance en el proyecto. Al finalizar el Sprint, se da lugar a una revisin del Sprint, que es una reunin de cuatro horas donde el Equipo muestra al Product Owner o a los clientes lo que se hizo durante el Sprint. Esto se da para que entre todos colaboren y se decida qu es lo que se va a hacer luego. Despus de esta revisin y una vez vistas las prioridades para la prxima reunin, el Scrum Master debe hacer una retrospectiva sobre lo que se ha hecho, con el objetivo de mejorar lo realizado y hacer ms disfrutable el prximo Sprint. Colaboracin del Cliente y del Equipo Antes las computadoras no eran tan poderosas, tampoco lo usuarios eran muchos, si un cliente peda el desarrollo de una aplicacin, sta se poda hacer con unos cuantos desarrolladores. Se le peda al cliente una descripcin de lo que necesitaba, se iba a programar y se le preguntaba: es esto lo que usted quera? y listo. Pero ahora todo es ms complejo: la tecnologa ha mejorado y los clientes son varios, ya no solo unos pocos. Ahora tiene que haber una comunicacin con todos los clientes para dar con los requerimientos. Comunicacin que no debe ser hecha en base a documentacin porque es inadecuada. Mientras ms se sigue la ingeniera de software ms se agranda la brecha entre desarrolladores y clientes, esto ocurra por ejemplo con el uso de procesos en cascada: se empezaba con los requerimientos, se pasaba al diseo, se escriba el cdigo, se hacan pruebas y recin se mostraba. Y se hacan juntas con los clientes y se les mostraban

los requerimientos y los modelos, luego se les preguntaba si eso era lo que queran y si decan s, se les tena que advertir que un cambio despus les iba a resultar costoso, lo que quedaba firmado en un contrato. Este modo de realizar las cosas no era para nada colaborativo, todo estaba sujeto a contratos. En cambio lo que se propone con Scrum es colaborar entre todos para obtener el mejor producto posible: los Sprints son cortos para que los clientes no pierdan inters, devuelven funcionalidades y el cliente puede redirigir el proyecto al inicio de cada Sprint para optimizar el valor del producto que desea. Al trmino de cada Sprint, los clientes ven la nueva funcionalidad; los anlisis, los modelos, requerimientos se usan en el desarrollo pero nunca se muestran a los clientes. Si los clientes son escpticos con Scrum, lo que debe hacer el Scrum Master es la rpida entrega de resultados que los clientes puedan usar en su organizacin.