EL MANIFIESTO GIL

El Manifiesto gil comienza enumerando los principales valores del desarrollo gil. Segn el Manifiesto se valora: Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un a decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental. La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito. Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta. Los valores anteriores inspiran los doce principios del manifiesto. Son caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros principios son generales y resumen gran parte del espritu gil. El resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo.

Los principios son:

1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. 2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. 3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. 4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. 6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. 7. El software que funciona es la medida principal de progreso. 8. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante. 9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. 12. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento.

MARCO DE TRABAJO SCRUM

2

El marco de trabajo Scrum consiste en los Equipos Scrum y en sus roles, eventos, artefactos y reglas asociadas. Cada componente dentro del marco de trabajo sirve a un propsito especfico y es esencial para el xito de Scrum y para su uso. Las estrategias especficas para usar el marco de trabajo Scrum son diversas, y estn descritas en otros lugares. Las reglas de Scrum vinculan a los eventos, roles y artefactos, rigiendo las relaciones e interacciones entre ellos. Las reglas de Scrum son descritas en el contenido del presente documento.

ROLES EN SCRUM
En Scrum existen tres roles: Dueo de Product, Equipo y ScrumMaster. Todos ellos forman lo que se conoce como el Equipo Scrum. Dueo de Producto: es responsable de maximizar el retorno de inversin (ROI) a base de identificar las funcionalidades de producto, trasladarlas a una lista priorizada, decidir cules deberan estar al principio de la lista para el siguiente Sprint, y repriorizar y refinar continuamente dicha lista. El Dueo de Producto es responsable a nivel ganancias y prdidas del producto, asumiendo que se trata de un producto comercial. En el caso de aplicaciones internas, el Dueo de Producto no es responsable del ROI en el mismo sentido que en un producto comercial (que generara ingresos), pero aun sera responsable de maximizar el ROI en el sentido de escoger en cada Sprint los elementos que ms valor aportan. En la prctica, valor es un trmino muy difuso, y la priorizacin puede verse influenciada por el deseo de satisfacer a los clientes clave, la alineacin con los objetivos estratgicos, atacar riesgos, mejorar y otros factores. En algunos casos el Dueo de Producto y el cliente son la misma persona; esto es frecuente en el caso de desarrollos internos. En otros, el cliente pueden ser millones de personas con necesidades muy variadas, en cuyo caso en muchas organizaciones el rol del Poduct Owner es similar al de Product Manager (Director de Producto) o Product Marketing Manager (Director de Marketing de Producto). Sin embargo, el rol del Dueo de Producto es algo distinto del Product Manager tradicional, ya que interacta de forma activa y regular con el Equipo, prioriza trabajando con todos

los stakeholders y revisa los resultados de cada Sprint, en lugar de delegar las decisiones de desarrollo a un Jefe de Proyecto. Es importante hacer notar que, en Scrum, hay una y slo una persona que sirve como Dueo de Producto y ejerce la autoridad final como tal, y l o ella es responsable del valor del trabajo realizado, aunque dicha persona no tiene por qu trabajar sola. Equipo: (tambin llamado Equipo de Desarrollo) construye lo que el Dueo de Producto indica: por ejemplo, una aplicacin o un sitio Web. El Equipo en Scrum es cross-funcional engloba toda la experiencia y conocimiento necesarios para desarrollar un producto potencialmente entregable en cada Sprint y es autoorganizado (auto-gestionado), con un amplio margen de autonoma y

responsabilidad. El Equipo decide cuntos elementos (del conjunto que ofrece el Dueo de Producto) va a desarrollar durante el Sprint y cul es la mejor manera de lograr dicho objetivo. Cada miembro del Equipo es simplemente un miembro de equipo. Ntese que no hay ttulos fijos especializados en un grupo que adopta Scrum: no hay analistas de negocio, administradores de bases de datos, arquitectos, lderes de equipo, diseadores / especialistas en UX, programadores... Los miembros del Equipo trabajan juntos durante cada Sprint de cualquier manera que sea apropiada para lograr el objetivo que se han marcado ellos mismos. Dado que solo hay miembros de equipo, el Equipo no es slo cross-funcional, sino que adems muestra aprendizaje mltiple: cada persona indudablemente tendr ciertas fortalezas, pero tambin continuar aprendiendo otras especialidades. Cada persona tendr habilidades principales, secundarias e incluso terciarias, y se espera de ellos que vayan a por el trabajo: que emprendan tareas con las que se sienten menos familiarizados con el objetivo de ayudar a completar un elemento. Por ejemplo, una persona cuya habilidad principal es el diseo de interaccin de usuario (UX) podra tener habilidades secundarias en automatizacin de pruebas; una persona con habilidad principal en redaccin tcnica podra tambin ayudar con el anlisis y la programacin.

El Equipo Scrum tiene siete ms/menos dos personas, y en el caso del Software el Equipo podra incluir a personas con habilidades en anlisis, desarrollo, pruebas, diseo de interfaz, diseo de bases de datos, arquitectura, documentacin y dems. El Equipo desarrolla el producto y proporciona ideas al Dueo de Producto sobre cmo hacer que el producto sea un xito. En Scrum, los Equipos son ms productivos y efectivos si todos los miembros estn dedicados al 100% a trabajar en un producto durante el Sprint. El Equipo evita la multi-tarea sobre varios productos o proyectos para evitar el gran coste que tienen la prdida de concentracin y el cambio de contexto (context switching). Los Equipos estables se asocian con mayor productividad, por lo que hay que evitar cambiar miembros del Equipo. Las reas de producto con muchas personas se organizan mediante mltiples Equipos, cada uno de ellos concentrados en diferentes funcionalidades del producto y con alta coordinacin de sus esfuerzos. Dado que cada equipo realiza todo el trabajo necesario para una funcionalidad desde la perspectiva del cliente (planificacin, anlisis, desarrollo y pruebas), los Equipos se denominan tambin feature teams (equipos de funcionalidad). ScrumMaster: ayuda al rea de producto a aprender y aplicar Scrum para obtener valor de negocio. El ScrumMaster hace todo lo que est en su mano para ayudar al Equipo, al Dueo de Producto y a la organizacin a tener xito. El ScrumMaster no es el jefe de los miembros del Equipo, como tampoco es un jefe de proyecto, lder de equipo o representante del equipo. En su lugar, el ScrumMaster sirve al Equipo; ayuda a eliminar impedimentos, protege al Equipo de interferencias externas y les ayuda a adoptar prcticas de desarrollo modernas. El o ella forma, entrena y gua al Dueo de Producto, al Equipo y al resto de la organizacin en el uso correcto de Scrum. El ScrumMaster es un coach y un formador. El ScrumMaster se asegura de que todo el mundo (incluidos el Dueo de Producto y los gerentes) comprenden los principios y las prcticas de Scrum, y ayudan a guiar a la organizacin a travs de los habitualmente difciles cambios que son necesarios para lograr el xito en el desarrollo gil. Como Scrum hace visibles mltiples impedimentos y amenazas a la efectividad del Equipo y del Dueo de Producto, es importante contar con un ScrumMaster comprometido trabajando de 5

forma enrgica en ayudar a resolverlos: si no, ser difcil que el Equipo o el Dueo de Producto tengan xito. El de ScrumMaster debera ser un rol dedicado al 100%, aunque un equipo pequeo podra tener un miembro del equipo ejerciendo dicho Rol (y con una menor carga de trabajo regular en dicho caso). Los mejores ScrumMasters surgen de todo tipo de experiencias y disciplinas: Ingeniera, Diseo, Pruebas, Direccin de Producto, Gestin de Proyectos o Gestin de la Calidad. El ScrumMaster y el Dueo de Producto no pueden ser la misma persona, ya que su enfoque es muy diferente y combinar ambos roles normalmente conduce a confusin y conflictos. Uno de los desafortunados resultados de combinar ambos roles es un Dueo de Producto haciendo micro- gestin, lo cul es justo lo opuesto al equipo auto-gestionado que requiere Scrum. Al contrario de los gerentes tradicionales, el ScrumMaster no le dice a la gente lo que tiene que hacer o asigna tareas facilitan el proceso dando soporte al Equipo mientras que este se organiza y se gestiona por su cuenta. Si el ScrumMaster se encontraba anteriormente en una posicin de gerencia sobre el equipo, tendr que realizar un cambio profundo en su forma de pensar y estilo de interaccin con el Equipo para tener xito con Scrum. Nota: no existe ningn tipo de rol de jefe de proyecto en Scrum. Esto se debe a que no es necesario en absoluto: las responsabilidades tradicionales del jefe de proyecto han sido divididas y reasignadas entre los tres roles de Scrum, sobre todo entre el Equipo y el Dueo de Producto ms que en el ScrumMaster. La prctica de Scrum con jefes de proyecto aadidos demuestra un desconocimiento fundamental de Scrum, y tpicamente desemboca en conflictos de responsabilidad, confusin respecto a la autoridad y resultados por debajo de lo esperado. A veces, un (ex) jefe de proyecto puede tomar el rol de ScrumMaster, pero el xito de esta iniciativa depende fuertemente de la persona y de hasta qu punto comprende bien las diferencias fundamentales entre ambos puestos, tanto en las responsabilidades del da a da como en el set mental necesario para tener xito. Una buena forma de comprender el rol de ScrumMaster a conciencia y comenzar 6

a desarrollar las habilidades clave necesarias para dicho xito son los cursos de Certified ScrumMasterde la Scrum Alliance. Adems de estos tres roles, hay otros stakeholders que contribuyen al xito del producto, incluyendo los gerentes, clientes y usuarios finales. Algunos

stakeholders como por ejemplo los gerentes funcionales (como un director de ingeniera) pueden descubrir que su puesto, aunque sigue aportando valor, cambia al adoptar Scrum: Apoyan al Equipo a base de respetar las reglas y el espritu de Scrum. Ayudan a eliminar impedimentos que identifican el Equipo o el Dueo de Producto. Hacen que la experiencia y el conocimiento estn disponibles En Scrum, estas personas sustituyen el tiempo que antes empleaban como nieras (asignando tareas, pidiendo informes de progreso y otras formas de microgestin) por tiempo como gur o sirviente del Equipo (mentorizacin, coaching, ayudar a eliminar obstculos o resolver problemas, proporcionar feedback constructivo y guiar el desarrollo de habilidades de los miembros de Equipo). En este cambio, los gerentes pueden tener que cambiar su estilo de gestin; por ejemplo, mediante el uso de preguntas socrticas para ayudar al equipo a descubrir la solucin a un problema por si mismos en lugar de simplemente decidiendo una solucin y asignndosela al equipo.