Scrum Experiencia Personal

Resumen

Scrum es un marco de trabajo ágil para la realizar proyectos complejos. Originalmente se formalizó para proyectos de desarrollo de software, pero funciona bien para cualquier tarea complicada, es un enfoque innovador para conseguir alcanzar a terminar el trabajo correcto, en tiempo y forma. Las posibilidades son infinitas. El marco de Scrum es engañosamente simple. “Scrum toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80” (Palacio, Juan, 2008, p. 87). Scrum surge de la necesidad de una metodología ágil; Kniberg (2007) señala que su ejecución correcta se está convirtiendo en un factor cada vez más importante para los equipos que buscan inversión de capital. Así tal como se lee, se busca inversión del capital de los clientes en el desarrollo de su software y si los equipos no conocen su velocidad de desarrollo, el cliente no puede crear una calendarización con fechas verídicas para el lanzamiento de su producto y sin ellas la compañía podría fracasar y los inversores perder su dinero.

Introducción

A lo largo del semestre he visto varios temas que han llamado mi atención, personalmente los que más me han gustado y sido útiles son los que hablan de herramientas actuales y muy modernas para desarrollar sistemas y aplicaciones dirigidos a móviles y web. Sin embargo, en la experiencia profesional en la que me he estado desenvolviendo es la parte de planeación y gestión de proyectos de desarrollo de software e ingeniería de procesos (algo apartado de la programación). Tuve la oportunidad de concentrarme en un equipo de trabajo como ‘Tester de sistemas’ en la que nos regíamos bajo la metodología de Scrum y es por ello que he decidido hablar del tema. Fue de los que más abarcamos en el semestre entre prácticas, ejemplos, tareas y herramientas administrativas.

En el desarrollo, operación y mantenimiento del software es un requisito indispensable la aplicación de diferentes enfoques cuantificables, sistemáticos y disciplinados para el éxito en cualquier proyecto que se esté realizando en colaboración con los ingenieros de software; donde no se debe olvidar que el propósito es la producción eficaz y eficiente de un producto software que reúna los requisitos solicitados por el cliente.

En éste documento les iré exponiendo lo teórico que aprendí en el semestre con los ejemplos de lo práctico que ya he trabajado y que no había podido fundamentar, si usted comenzará a desenvolverse en equipos de desarrollo de software, puede que le resulte interesante saber desde el enfoque de alguien que no llevaba la teoría y se fue directo a la práctica, el cómo se trabaja con Scrum.

SCRUM, mi experiencia personal

Buscando ahondar en el tema de Scrum, me di a la tarea de preguntar opiniones y en base a lo vivido laboralmente de dos años a la fecha, hacerme de un propio criterio de ésta metodología para hacer pilares más firmes a la hora de emplearla con algún grupo de trabajo y apoyar con mis conocimientos y experiencias.

Petróleos Mexicanos subcontrata a empresas para la realización de diferentes proyectos, tanto administrativos como de campo. Entre esas subcontrataciones se encuentra la empresa Impulsora Río Grande, que tiene cede en Reynosa Tamaulipas y una pequeña oficina aquí en Villahermosa. Ingresé como Tester de sistemas, para un proyecto nuevo de tableros de control de pozos para la zona sureste del país. El representante de Río Grande, el M. Carlos Alva nos asignó como líder de proyecto al M. Adolfo Carranza, quedando yo directamente bajo su contratación. Recién llegada, desconocía la aplicación de la metodología. Sólo había escuchado de teóricamente de ella en la universidad, y en la residencia profesional había estado desarrollando aplicaciones web bajo metodologías de enfoques tradicionalistas (modelo en cascada, prototipado, incremental y/o en espiral).

Comenzaba siempre en inicio de semana con una reunión de al menos media hora (lunes, 9 am), lo cual en ese momento yo desconocía que era un Sprint Review. El M. Adolfo juntaba a todo el equipo (programadores, analistas, testers y managers de bases de datos), asignaba nuevas tareas, checaba las tareas pendientes, asignaba a pruebas las terminadas y daba por hechas las ya probadas que no generaran errores. El resto de la semana sólo había reuniones de 15 minutos (Diary Scrum) para sincronizar actividades y crear el plan del día con vista al día siguiente, las reuniones diarias son muy importantes porque permiten retroalimentar y ver opinión de los demás. Como yo ingresé con el proyecto ya comenzado, no estuve enterada de los resultados de las reuniones de planificación en las cuales se estableció qué se conseguiría y cómo se conseguiría; obvio con previas reuniones con los clientes para checar el sistema ya obsoleto, obtener los requerimientos nuevos y analizar las posibles mejoras del sistema anterior, así mismo cómo conjugar dos sistemas anteriores en uno sólo.

Para mi beneficio, pude ver la utilización del “kanban” (task-board) sin saber que así se le podía llamar a ese curioso pizarrón de corcho que tenían colgado en la pared, dividido en 4 columnas y siempre a la vista de todos, con las tareas pendientes por realizar, las que se estaban haciendo, las que se estaban probando y las que se consideraban como hechas o terminadas. Además la analista de sistemas era la encarga de separar los requisitos del cliente en pequeñas tareas (Pila del Producto, con número de identificación, nombre de la tarea, nivel de importancia y estimación inicial) que nuestro líder de proyecto “subastaba” entre todos los programadores en donde éstos ofrecían “tiempos” y al que menos tiempo se llevase programándolo, a ése se le asignaba esa tarea. Simpáticamente, cuando todos los programadores diferían mucho en tiempos, se hacía un cálculo de sumatoria y promedio de ese tiempo y se apostaba asignársele al programador que tuviera más fuerza en ese tipo de tarea (graficación con componentes de Microsoft,

...