Ofertas y Contratos en Scrum Aspectos que se deben considerar para ofertar y contratar proyectos de entrega incremental. José Vázquez Sánchez 2013 José Vázquez Sánchez
Twitea sobre el libro! Por favor ayuda a José Vázquez Sánchez hablando sobre el libro en Twitter! El tweet sugerido para este libro es: I just bought Ofertas y Contratos en Scrum in http://www.leanpub.com. The first book written by @PepeVazquezS El hashtag sugerido para este libro es #OfertasyContratosScrum. Descubre lo que otra gente está diciendo sobre el libro haciendo click en este enlace para buscar el hashtag en Twitter: https://twitter.com/search/#ofertasycontratosscrum
Índice general 1 PREFACIO.......................................... 2 2 INTRODUCCIÓN..................................... 4
ÍNDICE GENERAL 1 Agradecimientos. A mi mujer y a mis hijos por soportar mis largas horas delante del ordenador escribiendo este libro. A Fernando, Carlos y Vicente por ayudarme a realizar una revisión completa del libro antes de su publicacion. A todos los que dentro de la comunidad Ágil me han enseñado cosas que me han permitido escribir este libro: Ana,Diego,Carlos,Angel,Masa,Guillermo,Juanma y muchos otros más. Gracias.
1 PREFACIO. El modelo Ágil de desarrollo goza cada vez de más amplia aceptación en la industria de la Ingeniería de Software. El número de empresas que están emprendiendo el camino de la adopción del modelo ágil va creciendo y no se trata solo de pequeñas empresas,también en grandes corporaciones se observan implementaciones del modelo. Animadas por los beneficios que se anuncian del uso de dichas prácticas y por los datos de porcentajes de éxito de los proyectos en los que se aplican,las empresas que aún no hayan adoptado este modelo para el desarrollo de software deberían valorar seriamente el empleo del modelo Ágil en sus proyectos de desarrollo. Bien se enfoque el proyecto a la construcción de un producto comercial, al desarrollo de un servicio a clientes como parte de una aplicación existente o a una nueva aplicación para atender necesidades de usuarios internos, un modelo Agil de desarrollo aporta mejoras significativas en los proyectos. No podemos sin embargo considerar Ágil como la panacea que solucionará todos los problemas habituales de los proyectos. Su aplicación requiere un cambio de mentalidad, formación adecuada y sobre todo grandes dosis de disciplina para su aplicación. No todos los proyectos son adecuados para aplicarlo, dependerá del nivel de complejidad e incertidumbre del proyecto. Asi, en los proyectos en los que existe un alto nivel de predecibilidad y el equipo posee de un gran conocimiento sobre el alcance que se pretende desarrollar, quizás no sea una opción a considerar y un modelo tradicional sea de aplicación. No obstante los pilares de transparencia, inspección y adaptación, junto con el enfoque en la mejora continua que forman parte de los fundamentos Agiles, aportan unas ventajas a los proyectos que se deben considerar al decidir el enfoque que vayamos a seguir. Este libro, no pretende ser un tratado exhaustivo de la teoría, dinámicas y disciplinas de los modelos ágiles, ni un manual legal sobre como deben escribirse las claúsulas de los contratos en proyectos Ágiles. Su objetivo es aportar claridad a los procesos previos al inicio de los trabajos de construcción del Software por parte de los equipos : el proceso de licitación u oferta comercial para un proyecto y el proceso de elaboración del contrato que regule la relación entre las partes. En un entorno dirigido por políticas rigurosas de reducción de costes por parte de las organizaciones y con una enorme competencia en los mercados, tanto los responsables de la selección y contratación de proveedores por parte de la empresa, como los responsables comerciales o gerentes de cuenta por parte de las empresas proveedoras, deben hacer grandes esfuerzos. Los unos por conseguir la mayor reducción posible de costes, los otros por conseguir nuevos clientes o mantener los actuales. Un entorno complicado, máxime en momentos de recesión en los que la supervivencia está en el ADN de todos los actores implicados. Si le preguntamos a un responsable de compras o a la persona que debe aceptar una oferta comercial para un nuevo desarrollo, su opinión sobre la posibilidad de contratar un proyecto en el que el alcance no se define completamente al inicio, lo primero que pensará es que estamos locos. Sencillamente, no será viable. Su mentalidad está anclada en la manera en que tradicionalmente se contratan los proyectos : precio cerrado por un alcance vagamente definido y con un plazo estipulado de antemano, poniendo en competencia a varios proveedores para conseguir la mejor oferta económica por lo que se supone, que ha sido definido y especificado por los responsables de 2
PREFACIO. 3 negocio. La realidad en cuanto a la definición es bastante distinta : los requisitos estan vagamente definidos al inicio del proyecto y irán descubriéndose a lo largo del tiempo a medida que se van concretando las necesidades. Por otro lado, si le preguntamos a un gerente de cuenta o comercial de una empresa proveedora de servicios IT sobre la opinión que le merece un proyecto a precio cerrado en el que el alcance es variable, igualmente pensará que estamos locos y que será un proyecto económicamente no rentable ya que el cliente podrá pedir cambios continuamente y tendremos que aceptarlos ampliando el esfuerzo necesario de los equipos y por tanto incurriendo en sobrecostes. Por tanto, una de las principales barreras que se plantean por ambas partes para adoptar un enfoque ágil, es la adecuación de los procesos de oferta comercial y del proceso de contratación a las dinámicas propias de Agile. Esto requiere un cambio cultural de las organizaciones y un cambio en el modelo mental de aquellos que ofertan y de aquellos que contratan los proyectos para adaptar sus procesos a la naturaleza propia de Agile. Esto ni mucho menos es fácil, supone un montón de retos y de desafíos. Es complicado romper las barreras y procedimientos actuales, pero no es imposible. Debemos basarnos en relaciones de confianza entre todos los actores involucrados y los gestores deben cambiar sus principios de gestión para enfocarse en modelos que tengan como principal prioridad la aportación de valor a los clientes finales y un cambio de paradigma sobre como liderar equipos, eliminar las burocracias excesivas que reducen la agilidad, crear equipos motivados y comprometidos, desarrollar a las personas y sus competencias enfocados en favorecer la innovación y en una entrega de valor rápida sin pérdida de foco sobre los objetivos principales. En este libro,además de explicar cual es la esencia del modelo Ágil a través de los 4 valores de su manifiesto y sus 12 principios, se aportan ideas y consejos para tratar de evitar las barreras y las preocupaciones que pueden tener los responsables de la elaboración y presentación de las propuestas comerciales y los responsables de la aceptación y redacción de los contratos para trabajar en un ambiente Ágil. Aprovechando la naturaleza del desarrollo iterativo que proponen los métodos ágiles en general y Scrum en particular, se pueden articular relaciones de confianza y de beneficio para ambos que conduzcan a aumentar las posibilidades de éxito de nuestros proyectos. Si no existe el conocimiento de la esencia y las características intrínsecas de los modelos Agiles, es muy normal que tanto a los profesionales de las Tecnologías de la Información como a los responsables de compras y a los abogados, les surjan dudas respecto a cómo pueden los contratos que actualmente se celebran entre cliente y proveedor de TI, -habitualmente proyectos a precio cerrado-, adaptarse a este modelo de trabajo. En los capítulos dedicados a Contratos ágiles, el libro enumera los aspectos más importantes que se deben tener en cuenta a la hora de redactar el contrato entre las partes para contemplar los aspectos esenciales del modelo Ágil y poder trasladar sus ventajas al modelo contractual.
2 INTRODUCCIÓN Para poder entender el modelo de contratación Agile, previamente es necesario que tanto los encargados de elaborar las ofertas comerciales, como los departamentos jurídicos o personas del mundo legal encargadas de la redacción del contrato, estén familiarizadas con los principios Ágiles. Estos principios,por la naturaleza incremental del ciclo de entrega Ágil y por el enfoque adaptativo y progresivo en cuanto a la definición de los requerimientos, deben ser entendidos por el departamento de TI o responsables del contrato para que puedan asi elaborar y redactar un documento que refleje estas características. Por otra parte, las personas responsables de la elaboración de las ofertas deben saber que existen una serie de técnicas que se pueden emplear para definir el alcance del proyecto en un ambiente ágil, con cuya aplicación podrán aportar un gran valor al cliente y conseguir una amplia visión de las necesidades sin tener de emplear grandes esfuerzos en la recogida de los requerimientos. El marco de trabajo Ágil más extendido a nivel mundial es Scrum. Scrum es un marco de trabajo para el desarrollo de Software, en el cual el desarrollo se lleva a cabo de manera incremental y se entrega valor al cliente con software que funciona en periodos de entrega frecuentes, estableciendo de antemano cual será la frecuencia de entrega. Más allá de esta pequeña definición y de los siguientes párrafos sobre los pilares de Scrum, no es el objetivo del libro explicar este marco de trabajo, los roles, artefactos o dinámicas de equipo aunque a lo largo del mismo, al hacer referencia a estos conceptos se definen brevemente algunos de ellos al pie de página. SCRUM Scrum es un modelo Agil que se basa en tres pilares fundamentales : Transparencia, Inspección y Adaptación. 4
INTRODUCCIÓN 5 Los tres pilares de Scrum Estos tres pilares, gobiernan el ciclo del desarrollo de Software con los objetivos de : Dar visibilidad a los intervinientes o involucrados sobre el estado del proyecto y conseguir una definición de criterios de aceptación compartida ( Definition of Done - DoD) Revisar de manera colaborativa el progreso del proyecto y hacer emerger de manera temprana las desviaciones o las diferencias respecto a los objetivos definidos. Ajustar el proceso para evitar problemas o desviaciones mediante procesos de mejora continua. Estos tres pilares,conducen todos los aspectos del proyecto de desarrollo. Se emplean además una serie de artefactos y liturgias que deben ser comprendidas por los responsables de elaborar las ofertas de proyectos asi como por los abogados, para poder elaborar de manera efectiva los contratos entre las dos partes afectadas. A los efectos de este documento, los abogados y partes interesadas deberán conocer los roles, la terminología y las dinámicas que siguen los equipos para poder entender las diferencias entre este modelo de trabajo y los modelos tradicionales, pues de ello depende que se puedan reflejar en las ofertas comerciales y en el clausulado de los contratos las cuestiones básicas que gobiernen el modelo de relación.
INTRODUCCIÓN 6 Roles en Scrum Es un aspecto importante el conocimiento de los roles para poder definir las responsabilidades de cada uno de ellos dentro de la oferta y del contrato. En Scrum, solamente hay tres roles cada uno con sus responsabilidades bien definidas, las cuales se describen brevemente a continuación. Estos tres roles, son : Product Owner : o dueño de producto, que es el representante del negocio dentro del proyecto. Es el responsable de la definición y refinado de los requisitos y de priorizar su valor al equipo. Ha de colaborar y participar diariamente en el proyecto para definir aquello que el equipo debe construir dentro de cada una de las iteraciones. Al ser un rol nuevo que aglutina muchas responsabilidades y del cual depende en gran parte el éxito del proyecto, su elección es clave y además es un rol complicado. Su papel y su participación en el proyecto deben quedar perfectamente definidas dentro del modelo contractual. Scrum Master : es el rol que ha de velar por el cumplimiento del proceso.tiene que asegurar que las dinámicas,reuniones y artefactos Scrum se hacen de manera correcta. Ha de garantizar el ritmo del equipo y ayudar a resolver los impedimentos que se pudieran plantear. También es un rol nuevo, y de cara al contrato aunque pudieran aparecer referencias al rol en los apartados que describan el modelo de trabajo, no es tan importante como la correcta definición de las responsabilidades del Product Owner. Equipo : el equipo, formado por todos aquellos que han de desarrollar el Software, son la parte técnica del proyecto, pero toman un protagonismo fundamental : en completa colaboración con el Product Owner y ayudados siempre por el Scrum Master deben ser responsables de trasladar el valor de negocio a software que funciona. Multidisciplinares, responsables, autoorganizados, con foco en la innovación, flexibles y con espíritu de mejora continua son algunas de las características que definen a los equipos Scrum. Se ha escrito mucho sobre la ausencia del rol del Project Manager dentro de los roles de Scrum, pero para resumirlo podríamos decir que necesita reinventarse, pero no desaparecer. El modelo Command-and-Control en el cual el Project Manager asigna y distribuye las tareas al equipo según un plan detallado al inicio del proyecto, cambia con el modelo ágil. Sus funciones seguirán siendo muchas y de mucha importancia para el proyecto. En algunos casos se asocia al Project Manager con es rol de Scrum Master, otras veces, en situaciones en las que el cliente final no puede participar de manera activa en el proyecto tanto como sería deseable, se asocia este rol al del Product Owner (actuando como proxy del cliente). Sea cual sea el rol al que se asocia la figura de Project Manager, hay ciertas cuestiones clave de un proyecto que deben tener una persona encargada y por tanto responsable de ellas. Ayudar a resolver las dependencias que el equipo no sea capaz de resolver por si mismo. Coordinar con otros equipos involucrados las actividades dependientes para cada entrega. Mantener alineados los objetivos y expectativas de todos los involucrados en el proyecto. Anticiparse a posibles problemas por medio de la observación del entorno que le rodea. Encargarse del seguimiento y control de los presupuestos asignados al proyecto. Realizar informes periódicos sobre el estado del proyecto para la Gerencia. Vigilar que se entrega valor al cliente y que el producto tiene la calidad requerida.
INTRODUCCIÓN 7 Prestar asesoramiento al equipo en dificultades técnicas que se pudieran presentar. Intervenir en la resolución de problemas y conflictos. Y cuando actua como Proxy del cliente entonces estas funciones se ven aumentadas con la responsabilidad de la definición, refinado, priorización y aceptación de las funcionalidades de negocio del producto o servicio que el equipo tiene que desarrollar. La oferta y el contrato, deben dejar claro como se articulan las funciones y responsabilidades de los participantes en el proyecto, entre otras cosas, porque como más adelante veremos algunas cláusulas de algunos modelos de contrato están condicionadas a dichos roles y a su participación en el proyecto. LOS REQUISITOS Otro aspecto clave muy importante, para empezar a plantear una oferta o un modelo de contrato,es que las partes interesadas deben tener claro que en el marco de trabajo Scrum en particular y en los modelos ágiles en general, los requisitos o alcance del proyecto emergen a lo largo del tiempo y van siendo desgranados a lo largo de todo el proyecto en incrementos de funcionalidad que producen entregables demostrables en intervalos de tiempo prefijados de antemano, denominados Sprints. Los requisitos son identificados de manera progresiva por parte del cliente,junto a la prioridad de cada uno en base a criterios de valor o importancia para el negocio. En siguientes capítulos veremos como aplicar técnicas para la definición del alcance que sirvan como base para la preparación de la oferta y para la determinación del objeto del contrato. En contraposición con los modelos tradicionales de contratación en los que el cliente no ve resultados hasta las etapas finales del proyecto, Scrum, produce entregables de valor al cliente de manera frecuente. En el siguiente capítulo se explican las razones por las que la adopción de un enfoque ágil para el desarrollo de software es un modelo que las organizaciones han de considerar para mejorar la eficiencia de los desarrollos y conseguir traer al mercado los productos y servicios que demandan los clientes, con la rapidez y flexibilidad que imponen las actuales condiciones de los mercados.