Implementación del método ágil Scrum en una empresa de desarrollo de software uruguaya

Transcripción

1 Implementación del método ágil Scrum en una empresa de desarrollo de software uruguaya Lic. Nadim Curi Lic. Gonzalo Lema Lic. Martín Mari Lic. Fernando Rizzo ABSTRACT The present work raises to study how the Scrum agile method can be implemented in a uruguayan development of software company, which at the moment does not count on any process for the accomplishment of its work. Keywords: Scrum, agile methods, GeneXus RESUMEN El presente trabajo plantea estudiar como la metodología ágil de Scrum puede ser implementada en una empresa de desarrollo de software uruguaya, que actualmente no cuenta con ningun proceso formalizado para la realización de su trabajo. Palabras claves: Scrum, métodos ágiles, GeneXus

2 1 INTRODUCCIÓN Scrum es un método ágil usado para controlar y administrar el desarrollo de software siguiendo prácticas iterativas e incrementales. [3] Esta metodología define también un conjunto de roles que se deben asignar antes de comenzar el proyecto, estos roles son: Product Owner: Establece las prioridades en el producto, de modo que las funcionalidades más importantes se realicen primero. Scrum Master: Gestiona el proceso, debe asegurar las buenas prácticas del proceso y remover las trabas que aparecen en el camino. Team: Entre 5 y 10 personas, los cuales desempeñan distintas funciones (programadores, analistas, QA, diseñadores, etc.). Algunos miembros del equipo son conocidos como cerdos porque están comprometidos con una meta, los que están involucrados pero no comprometidos se los conoce como gallinas. Cada etapa del ciclo de desarrollo se hace corresponder con una serie de Sprints o iteraciones, de aproximadamente 30 días cada uno. El producto es diseñado, desarrollado y probado dentro de los Sprints, y no hay un proceso definido dentro del mismo. Al final de cada Sprint, se produce un ejecutable para demostrar que se cumplieron los objetivos planteados para el mismo, y para mostrarle al cliente el progreso llevado a cabo. Diariamente se realiza una reunión (Daily Sprint Meeting) de 15 a 30 minutos donde el equipo comparte del estado del Sprint, pero no se resuelven problemas. En estas se cita al Scrum Master, el cual pregunta a cada miembro del equipo: Qué ha hecho desde el último Scrum Meeting? Qué le ha impedido el trabajo? Qué piensa hacer desde ahora y hasta el próximo Scrum Meeting? A estas reuniones son invitados tanto cerdos (Product Owner, Team y ScrumMaster) como gallinas, pero sólo los cerdos pueden hablar. Luego de finalizado el sprint se realiza un reunión de revisión (Sprint Review Meeting) en la cual las partes interesadas (clientes, gerentes, Product Owner y otros ingenieros) evalúan el progreso y reevalúan los requerimientos técnicos y de negocio; el trabajo se reestablece y el equipo entra en un nuevo Sprint. A su vez existe una lista de todo el trabajo que se debe completar en el proyecto, denominada Product backlog, la cual es mantenida y priorizada únicamente por el Product Owner. Es un documento dinámico puesto que cambia a medida que el producto evoluciona con los sucesivos Sprints. También existe una lista de todas la tareas que se deben completar durante el Sprint (Sprint backlog), para cumplir con los objetivos planteados al inicio del mismo. Por último, existe una reunión para planificar el Sprint (Sprint Planning Meeting). La duración estimada de esta etapa es de 8 horas y a ella asisten el Scrum Master, Product Owner, y el Scrum Team. Adicionalmente se pueden invitar otras partes como los clientes para que puedan aportar información útil por ejemplo con respecto al dominio del negocio. Se divide en dos segmentos de 4 horas cada uno, la primera es para seleccionar el Product Backlog y la segunda es para preparar el Sprint Backlog. 1

3 2 LA EMPRESA ARTech es una empresa líder en herramientas de desarrollo de software basadas en gestión automática del conocimiento. [4] Desde 1984, ARTech ha desarrollado importantes y originales actividades de investigación en el área de las bases de datos relacionales, desarrollo de aplicaciones, CASE (Computer Aided Software Engineering) e inteligencia artificial. Estas actividades han requerido muchas horas de dedicación, y han producido una exclusiva tecnología que es el núcleo de GeneXus. Más de clientes en el mundo utilizan GeneXus para crear e integrar aplicaciones de misión crítica que fácilmente se adaptan a los implacables cambios del negocio. La tecnología GeneXus permite que los clientes usen el know-how exclusivo de su negocio en las plataformas tecnológicas líderes del mercado. ARTech fue fundada en 1988 y tiene su base en Montevideo, Uruguay. Además, cuenta con oficinas en Estados Unidos, México y Brasil, y una red de distribuidores en el mundo. 3 ANÁLISIS DE LA METODOLOGÍA Por qué un proceso? El desarrollo del software es una tarea compleja. El proceso del desarrollo del software es enteramente intelectual, y todos sus productos intermedios son representaciones marginales de los pensamientos implicados. Los materiales que utilizamos para crear el producto final son extremadamente volátiles: requerimientos del usuario para un producto que los mismos aún no conocen, y la interacción de los organismos más complejos del planeta con nuestro producto: las personas. [2] Es por esto que es necesario implementar una metodología que sirva para organizar y sustentar el proceso de desarrollo de software. Al tratarse de una actividad muy cambiante, una metodología ágil como Scrum puede brindar la flexibilidad adecuada de forma de adaptarse dinámicamente a las necesidades de los usuarios. Por qué Scrum? Si bien hasta este momento no se contaba con una metodología de trabajo en la empresa en cuestión, mediante un estudio de investigación se percibe que Scrum presenta grandes similitudes con la estructura y metodología diaria de trabajo en la empresa. Otra razón por la que este método resulta atractivo, es que está orientado a equipos de desarrollo pequeños como es el caso. Por qué ahora? Porque actualmente existe un nuevo emprendimiento en la empresa: se está comenzando un nuevo proyecto en el cual estará involucrada gran parte del equipo de desarrollo y en el que se deberá trabajar con ciclos relativamente cortos. Este proyecto es GeneXus Rocha, y es una nueva versión del producto que comercializa la empresa hoy en día. Descripción de la metodología aplicada a la empresa La lista de funcionalidades para implementar en GeneXus Rocha estará enmarcada en el Product backlog, con una breve descripción de cada una y sin incurrir en gran nivel de detalle. Estas incluirán una estimación de tiempo aproximada para su implementación, no para comprometerse con dicho tiempo sino para poder comparar el esfuerzo que implicará el desarrollo de las distintas funcionalidades. 2

4 Hasta el momento, esta lista de funcionalidades era bastante informal y no se encontraba registrada formalmente en un único lugar, sino que además parte de la misma existía en la mente de los desarrolladores únicamente. Además de la lista anterior, actualmente se cuenta con una lista de funcionalidades (también informal) a para ser desarrollaras en determinado momento. Esta lista puede presentar cierta analogía con el Sprint backlog, pero deberá ser formalizada en el mismo. Al final de cada día cada desarrollador actualizará la información del Sprint Backlog con las tareas que realizó, y la cantidad de horas necesarias para cumplir con el resto de las tareas asignadas. Definición de roles Product Owner: En este caso será la misma empresa que desarrolla el producto, ya que es ella quién decide las funcionalidades que deberán ser implementadas y que aportarán valor al mismo. Por lo tanto, la alta gerencia conjuntamente con gerentes de mando medio conformarán esta parte. Team: El equipo de desarrollo estará conformado por diez desarrolladores en este caso, y otro conjunto de personas que también tendrán influencia en la construcción del producto (stakeholders): Un encargado de asegurar la calidad del producto (QA) Dos encargados de probar el producto (Testers) Un administrador de sistemas (System Administrador) Es importante destacar que los miembros de este equipo deberán dedicarse full-time, salvo excepciones. Scrum Master: Tarea que inicialmente será llevada a cabo conjuntamente por dos personas, ya que se decide que las tareas a desempeñar no requieren una dedicación full-time. No es una posición de liderazgo, sino de organización y gestión del proyecto. El Scrum Master debe encargarse de que la metodología sea aplicada correctamente, junto con sus valores y reglas. Adicionalmente, podrá servir de soporte al Team y ayudarlo en caso de que se encuentre bloqueado con un problema, es decir, será quién realice todas las actividades necesarias para que ese impedimento desaparezca. Sprint Tendrá una duración de dos semanas inicialmente, aunque lo deseable es llegar progresivamente a una duración de un mes. Durante el mismo el Team se auto-organiza el trabajo a realizar y no podrá ser interrumpido por personas externas al mismo, comprometiéndose de esta forma a realizar el trabajo propuesto en ese Sprint. El producto será diseñado, codificado y probado durante el Sprint, quedando ese conjunto de funcionalidades terminadas. Al final del mismo se realizará una demostración al Product Owner con el trabajo realizado, pero sin embargo no se entregará un ejecutable. Una diferencia que existe con la forma de trabajo hoy en día, es que actualmente no se tiene certeza de cuando un conjunto de funcionalidades están terminadas, ya sea por ejemplo nunca son completamente probadas por el equipo de desarrollo. 3

5 Daily Sprint Meeting Se deberán realizar reuniones en forma diaria, de forma tal de que todos los integrantes del equipo sepan en donde están parados. La reunión deberá realizarse a la misma hora, con una duración aproximada de 15 minutos. Como se mencionó anteriormente el objetivo de estas reuniones no es la resolución de problemas, sino que se pretende mejorar la comunicación entre los miembros del equipo. La importancia que se le dará a estas reuniones, se refleja en el hecho de que no podrán ser sustituidas por correos electrónicos o por otra modalidad para comunicarse. Se busca que se genere cierta presión entre los integrantes del equipo para el cumplimiento de las tareas, dado que todos saben que han hecho todos y que tienen para hacer en el corto plazo. Asimismo, el tener una reunión diaria permite que todos tengan una imagen de la situación actual, y evita tener que realizar otras reuniones innecesarias. Los cerdos que concurrirán a dichas reuniones serán los 10 desarrolladores, el Gerente de Desarrollo (representando al Product Owner) y el Scrum Master, mientras que eventualmente podrán invitarse personas de otras áreas (por ej. Soporte) como gallinas. Restricciones Se debe crear una lista completa con todas las restricciones encontradas por el equipo durante el Sprint. Sprint Review Meeting El propósito de esta reunión es que el equipo presente un balance de las metas alcanzadas durante el Sprint. La preparación de esta presentación, que tendrá formato de demo, es de aproximadamente dos horas. Además de los miembros del Team y el Scrum Master, participarán gerentes de la alta dirección, y cualquier otro interesado de la empresa. Release Sprints En algunos casos es recomendable durante los Sprints regulares que el producto ya empiece a ser usado por los usuarios. Los usuarios beta o similares podrán usarlo inmediatamente luego del sprint. Durante el Release Sprint, el equipo prepara el producto para que sea liberado. Si bien esta no es una parte obligatoria de la metodología de Scrum, resulta bastante recomendable. Beneficios percibidos Dentro de los beneficios que se considera se alcanzarán al implementar esta metodología, encontramos [5]: Rentabilidad: Scrum define un conjunto de valores, principios y prácticas referente a como modelar y documentar de forma eficaz y rápida. Creando así sólo los modelos y documentos que son necesarios, reduciendo de esta forma los costos asociados al proyecto. Reducción del tiempo: Debido principalmente a la gran comunicación y colaboración que ocurre durante el ciclo de vida del proyecto, la información crítica se pone a disposición de la gente adecuada, y se reducen al mínimo los errores y los esfuerzos desperdiciados, lo que significa en una gran reducción en el tiempo total del proyecto. Aumento de calidad: Se desarrollan productos de mayor calidad debido principalmente a la reducción del ciclo de vida de los desarrollos y la liberación continua de ejecutables. De esta forma, los problemas del producto que se repiten pueden ser identificados y ser resueltos en vez de pasar al siguiente requerimiento. Conformidad del cliente: Hay un mayor control del ciclo de vida del producto, esto mediante las reuniones diarias y de revisión del Sprint, la entrega de ejecutables al finalizar el Sprint, etc. 4

6 4 CONCLUSIONES El proceso Scrum plantea beneficios importantes dadas las características y la forma de organización de la empresa. La elección de este proceso para el nuevo proyecto (GeneXus Rocha) que la empresa está encarando, se puede sintentizar en los siguientes puntos: Presenta importantes similitudes con la estructura y metodología diaria de trabajo en la empresa. Está que está orientado a equipos de desarrollo pequeños como es el caso. Se buscan formalizar ciertas tareas o documentos que actualmente se realizan de forma más informal. Se pretende aprovechar el inicio de un nuevo proyecto para adaptar un proceso ágil que mejore la organización y comunicación del equipo de trabajo. Sin embargo, aplicar la metodología con rigor desde un comienzo resulta difícil debido a que implica un cambio en la cultura empresarial, y en la forma en que se venía trabajando hasta este momento. El principal objetivo de aplicar una metodología de trabajo será mejorar la estimación de los tiempos de desarrollo y la calidad del producto obtenido. Es importante tener en cuenta de que Scrum es un método ágil que puede ser aplicado en cualquier actividad que implique una Gestión de Proyecto, y no solamente para la actividad en el desarrollo de software. 5

7 REFERENCIAS [1] Ken Schwaber: Agile Project Management with Scrum, Microsoft Press, 2004 [2] Clinton Keith: Agile Methodology in Game Development: Year 3, Game Developers Conference, [3] Control Chaos [4] GeneXus [5] Agile PLM 6