Quién puede ser Product Owner o Scrum Master?

Al momento de adoptar la metodología ágil Scrum en una organización que está acostumbrada a trabajar usando el enfoque en cascada para sus proyectos de Desarrollo de Software, nos encontramos con ciertas preguntas de cara a los roles que generalmente existen en la gestión en cascada y cuáles son los mejores candidatos para ocupar los nuevos roles que propone Scrum.

Los roles que generalmente encontramos en la gestión en cascada o “Plan Driven” son el Product Manager, Business Analyst, Project Manager, Software Developer, DataBase Admin, Tester, UI Designer, Functional Director, etc. En Scrum solo son tres, el Product Owner, el Scrum Master y el Development Team.  Como decidimos quien va a ocupar que rol de Product Owner? Y quien puede ser el Scrum Master?  Hablemos un poco de eso.

En Scrum, el rol de Product Owner es el que se encarga de administrar el repositorio de requerimientos (el Product Backlog), priorizar los elementos de este repositorio basado en el valor que tienen para el negocio, agregar detalles a dichos elementos y además debe estar disponible para que el equipo de desarrollo pueda aclarar sus dudas y obtener respuesta a las posibles preguntas relacionadas con el trabajo que estarán haciendo.  Estas responsabilidades del Product Owner pueden ser cubiertas por varios de los roles que existen en la gestión tradicional o en cascada, sin embargo, hay que tomar en cuenta algunos elementos importantes antes de decidir quien será el que ocupara este rol de Product Owner.   Dentro de los elementos a tomar en cuenta están:

• El candidato (o candidata) debe tener un buen conocimiento (yo diría que un perfecto dominio) del negocio, del producto que se espera construir o del servicio que va a crear.
• Debe tener alto nivel de credibilidad en la organización, esto para que sus decisiones sean respetadas.
• Debe ser un buen comunicador, es decir, debe saber transmitir una idea de manera clara (generalmente lo tendrá que hacer usando el lenguaje del negocio).

Todo aquel que cumpla con estos tres elementos es un candidato a ser Product Owner.  No es casualidad que generalmente las personas que pertenecen al área de negocios, áreas de gestión de productos, gestión de proyectos, áreas de mercadeo, operaciones, etc., son los que generalmente son seleccionados para cubrir este rol, esto es así debido a que esas personas conocen bien el producto o el negocio (a veces no saben exactamente lo que quieren pero tienen bien claro cual es la necesidad que se desea cubrir), gozan de alta credibilidad en la organización por sus hazañas pasadas en esas posiciones y como trabajan generalmente con muchas personas a su alrededor (o bajo su cargo) tienden a ser buenos comunicadores.

Por otro lado tenemos al Scrum Master, este rol debe tener un excelente dominio y conocimiento de la metodología Scrum y debe saber moverse dentro de la empresa, es decir, debe conocer los procesos, procedimientos, políticas de la empresa, la cultura organizacional e incluso es deseable que conozca algunos “atajos” para solucionar situaciones (conoce exactamente quien puede resolver un problema en particular cuando se presenta).  Esta persona debería de poder entender el lenguaje que use el Product Owner, me refiero al lenguaje del negocio y también debe poder comunicarse sin inconvenientes usando el lenguaje del equipo de desarrollo (siendo este el último el equipo de personas que creara el producto, servicio o resultado esperado), con esto del lenguaje me refiero a palabras y jergas propias del producto que se esta construyendo, si es de software debería poder entender una conversación técnica, si es un producto basado en maderas preciosa debería poder entender la terminología usada por los constructores de artículos en madera o ebanistas.  Debe tener capacidades de facilitador, poder solucionar conflictos (que seguro va a tener algunos que solucionar, tanto a lo interno del equipo de desarrollo como entre el Product Owner, el equipo, los stakeholders y demás involucrados).  

Los candidatos a Scrum Master son generalmente personas que salen del equipo de desarrollo, que presentan buenas capacidades de comunicación, solucionan conflictos, cuentan con alto nivel de empatía, conocen la empresa y saben como moverse dentro de ella.  También un Project Manager puede ser un buen Scrum Master, siempre y cuando cumpla con los elementos que ya hemos citado (si tiene un conocimiento básico o moderado sobre el producto o servicio a construir y las técnicas y herramientas que usara el equipo de desarrollo para crear dicho producto o servicio seria excelente).

Aunque esto que les describo en esta ocasión aplica para la generalidad de los proyectos que son llevados con Scrum, recuerden que existen escenarios puntuales donde el caso particular del Product Owner puede necesitar características especiales, este es el caso de múltiples equipos de Scrum que desarrollan componentes de un producto mayor, en ese caso los Product Owners requieren de un conocimiento “técnico” importante para poder pasar los requerimientos (historias de usuario) de manera que cumplan con los requisitos de la integración que en un momento futuro habrá que realizar, pero esa es otra historia :P.

Bueno eso es todo en cuanto los quien puede ocupar los roles de Product Owner y Scrum Master en Scrum, espero verlos pronto por acá en otro post de Agile Zone.

About zero (0) story points

The Fibonacci series was slightly modified for agile planning purposes. This modification includes adding the values 0 and 0.5 and rounding up the values that exceed 13 (20, 40 and 100). The question is: can we assign zero story points to an issue? Is this correct? Does this have any impact in velocity measurements or indicators or any other charts or reports?

We assign zero story points to an issue that requires the least effort of the team to be completed. Issues that take a few hours to be resolved and accepted, or issues that only need to be verified by a team member in order to be considered as “solved”. Those issues don’t have impact in a velocity report or velocity chart of the team, for that reason we need to be careful to assign zero story points to an issue. Imagine a sprint with 30 issues in it (bugs, improvements, spikes and stories) and 15 of them with zero story points, that situation changes the measurement of velocity of the team because if we put the 15 issues together in a bag, we can assign 3 or 5 story points to that bag, but we don’t see these story points in any place.

You can handle this situation with multiple approaches. The first approach is take one issue with zero story point for each team member or less. If you have 7 team members, you can take into the sprint up to 7 issues with zero story points and no more. The second approach is to create a new issue with multiples things to do (various issues interrelated with zero story points each one) and assign 0.5, 1 or 2 story points to that new issue.

In conclusion, you can assign zero story point to an issue under specific conditions (the issue take the least effort of the team to be completed), but be careful including those issues in a single sprint can impact your velocity measurement.

La serie Fibonacci fue ligeramente modificada para ser usada en la planeación ágil, específicamente en el Planning Poker. Esta modificación incluye los valores cero (0) y 0.5 y redondea algunos valores superiores al 13 (20, 40 y 100). La pregunta aquí es: puedo asignar cero (0) story points a un issue (error, historia de usuario, mejora, spike, etc.)? Esto estaría correcto? Tendría esto algún impacto en la medición de la velocidad, en los indicadores de velocidad o gráficas y reportes relacionados?, hablemos de eso.

Asignamos cero (0) story points a un Issue que requiere el mínimo esfuerzo del equipo para ser completado. Issues que toman solo algunas horas para ser resueltos y aceptados, o issues que solo necesitan ser verificados por algún miembro del equipo para ser considerado como “resuelto” o “terminado”. Esos issues que pesan cero (0) no tienen impacto en los reportes de velocidad o graficas de medición de velocidad del equipo, por esa razón tenemos que tener mucho cuidado al asignar cero (0) story points a un issue. Imagine que usted tiene 30 issues en un sprint (errores, mejoras, spikes e historias de usuario) y que 15 de esos issues pesan cero (0) story points, esto puede cambiar la velocidad de su equipo de manera interesante. Imagine que usted pueda colocar esos 15 issues todos en una bolsa y darle un peso a dicha bolsa, esto seguro pesaría unos 3 o 5 story points, sin embargo, usted nunca va a ver esos story points en ningún lugar si los deja sueltos.

Se puede manejar esta situación de varias maneras. La primera es tomando como máximo un issue que pesa cero (0) por cada miembro del equipo dentro de un mismo sprint. Si usted tiene 7 miembros en su equipo, solo podrá tomar 7 issues con peso cero (0) en un mismo sprint y no más. Otra forma es agrupar los issues relacionados y que pesan cero (0) y crear un nuevo issue que los incluya a todos y a este nuevo issue si darle un peso, que podría ser 0.5, 1 o 2 story points.

En conclusión, usted puede asignar cero (0) story points a un issue bajo ciertas condiciones muy específicas (el issue tomaría el mínimo esfuerzo del equipo para ser completado), pero tenga mucho cuidado con incluir varios de estos issues en un mismo sprint ya que esto puede impactar su medición de la velocidad del equipo.

Hablemos de Metodologías Ágiles

Usamos el enfoque de gestión ágil de proyectos para abordar proyectos que el enfoque “tradicional” o “en cascada” no puede resolver de manera óptima y eficiente. Generalmente son proyectos con poca o ninguna definición de procesos, con poco detalle del producto resultante del proyecto, con alta posibilidad de cambios en los procesos y el producto, con procesos complejos, etc.   Sin embargo, existen varias formas de gestionar los proyectos de manera ágil y por esta razón fue que en el 2001 se firmó el manifiesto ágil, en respuesta a los diversos y múltiples mecanismos y formas que emergieron para dar respuesta a los proyectos que se deben gestionar con el enfoque ágil.  Desde antes de la firma del manifiesto existían un conjunto de Métodos Ágiles para abordar proyectos con las características citadas hace un momento.  De eso hablaremos en esta ocasión, de las metodologías ágiles de gestión de proyectos.

Que es una Metodología?

Según algunos autores, una metodología es un conjunto de procesos y prácticas usados en una forma específica para lograr obtener un resultado.  El diccionario de la real academia española lo define como un conjunto de métodos que se siguen  en una investigación científica o en una exposición doctrinal.  Todo lo descrito es correcto, sin embargo, prefiero definir metodología como una mezcla interesante de roles, herramientas, técnicas, procesos, prácticas y actividades que se conjugan y actúan sobre un modelo organizacional específico.

Que son las Metodologías Ágiles ?

La gestión tradicional de proyectos se enfoca mayormente en mejores prácticas y cuando hablamos de Ágil recurrimos a las metodologías ágiles.  La diferencia entre ambos enfoques es que las mejores prácticas son una sugerencia de cómo hacer las cosas producto de la extensa experiencia y buenos resultados obtenidos usando esas prácticas, las metodologías sugieren una forma en particular de hacer las cosas donde si dejan algo fuera el resultado no será el esperado, es decir, debe hacerse lo indicado por la metodología como requerido (no es una sugerencia, es que hay que hacerlo así).  Obviamente veremos más adelante que se pueden hacer ajustes a las metodologías ágiles para adaptarlas a las situaciones y contextos de nuestra empresa, pero siguen siendo una metodología.

Las Metodologías Ágiles tienen la peculiaridad de que el tiempo y los recursos (personas, materiales y equipos) son fijos, invariables, es decir, no cambian.  En cambio el conjunto de características y especificaciones del producto o servicio que se desea construir es totalmente flexible, ajustable, cambiante.

Las Metodologías Ágiles surgieron antes incluso de la firma del Manifiesto Ágil, algunas sufrieron algunos cambios posterior a ese momento, otras surgen después de la firma del referido manifiesto y otras continúan siendo exactamente igual que hace 13 años.  Dentro de la Metodologías Ágiles de renombre podemos citar las siguientes:

• Scrum
• eXtreme Programming (XP)
• Crystal Family
• Lean Software Development
• Agile Unified Process (AUP)
• Feature Drive Development (FDD)
• Test Drive Development (TDD)
• Dynamic Systems Development Method (DSDM)
• Kanban

Desde hace más de diez años diferentes organizaciones miden el uso de estas metodologías por los diferentes equipos de desarrollo de productos que trabajan con el enfoque ágil.  Un estudio realizado por la empresa Version One en el 2014 (8va encuesta anual sobre el uso de metodologías ágiles) arrojo el siguiente resultado:

Esto nos indica que Scrum es la metodología ágil más usada  (por mucho) dentro de los equipos de proyectos que trabajan con ágil, seguido por el híbrido de Scrum + eXtreme Programming.

Más adelante hablaremos de cada uno de estos métodos ágiles en detalle.  Hasta la próxima.

Actividades sobre Gestión de Proyectos en República Dominicana – Noviembre 2014

En República Dominicana hemos estado en un proceso de descubrimiento escalonado de la importancia de aplicar la Gestión Profesional de Proyectos en las organizaciones.  Dicho descubrimiento ha tenido lugar en la última década aunque desde siempre hemos gestionado proyectos de diversos tipos y tamaños.  Producto de este descubrimiento, hemos conformado algunas organizaciones profesionales destinadas a organizar, agrupar y apoyar a los profesionales y organizaciones en cuanto a la Gestión Profesional de Proyectos.  Hoy vamos a hablar sobre las organizaciones de profesionales existentes en República Dominicana en cuestión de Project Management y sobre un conjunto de eventos que dichas organizaciones tienen pautados para el mes de Noviembre de este año (2014).

Project Management Institute – Dominican Republic Chapter

El capítulo PMI de República Dominicana es una organización de profesionales destinada a apoyar las actividades relacionadas con Gestión de Proyectos en República Dominicana, apoyar los profesionales del área y difundir las mejores prácticas del PMI.  Ahora bien, quien mejor que ellos mismos para explicarnos que son y cómo se formaron, aquí les dejo la transcripción de la sección “Quienes Somos” de su sitio web (www.pmird.org.do):

"El Project Management Institute® (PMI®), es una asociación profesional sin fines de lucro, fundada en 1969, cuyo objetivo principal es el de promover la práctica y profesión de administración de proyectos alrededor del mundo de un modo consciente y proactivo. El PMI® cuenta con más de quinientos mil miembros activos en 185 países alrededor del mundo.

El Capítulo PMI República Dominicana es una entidad constituida con el propósito de difundir los estándares de la Dirección de Proyectos y agrupar a profesionales de esta disciplina de diversas áreas e industrias en nuestro país.

El 30 de julio de 2010 se realizó el primer encuentro de profesionales voluntarios decididos a unir esfuerzos para desarrollar esta iniciativa que ayude a mejorar la dirección de proyectos en nuestras empresas y nuestro país, así como las competencias de nuestros profesionales.

Después de varias sesiones de trabajo constante y en equipo lograron formalizar el Plan de Negocios y con esto concretizar la Asociación PMI Capítulo República Dominicana constituida formalmente con todas las especificaciones de las leyes dominicanas y requisitos del PMI en Estados Unidos, dirigida por una Junta Directiva conformada por miembros fundadores y voluntarios."

Cabe destacar que el PMI contaba para el 2013 con 439,689 miembros activos (según su informe anual de ese año) y un total de certificaciones activas ascendiente a 628,363.  Obviamente hoy en día estos números han crecido, de eso hablaremos en otro momento.

El Capítulo PMI de República Dominicana se mantiene constantemente realizando actividades de integración, charlas, reuniones, etc. con el objetivo de que los profesionales relacionados con la Gestión Profesional de Proyectos de República Dominicana se conozcan y hagan el respectivo “networking”.  Ahora en noviembre 2014 están organizando la cuarta entrega de su congreso internacional de gestión de proyectos el cual detallo a continuación:

Nombre del Evento: IV Congreso Internacional de Gestión de Proyectos

Lugar: Hotel Bávaro Palace Deluxe, Punta Cana

Fecha: del 13 al 15 de Noviembre

Más información: www.congresoproyectosrd.com

Esta es la cuarta entrega del conocido y ya famoso congreso internacional de gestión de proyectos que organiza el capítulo de República Dominicana del Project Management Institute.  Serán 3 días completos donde solo se respirara el aire de Project Management.  Los expositores que propone el congreso son personalidades con alto nivel de credibilidad y experiencia en sus respectivas áreas de conocimientos, habrá varios extranjeros (Argentina, Estados Unidos, Ecuador, Perú y México) y también contaremos con representación de expositores dominicanos.

Algo que me llama mucho la atención de este IV congreso internacional de gestión de proyectos son las calificaciones de algunos de los principales expositores (personas muy calificadas y con muchos conocimientos), en especial la señora María Matarelli.  Hago referencia a la señora Matarelli debido a que ella será expositora principal del evento y la misma cuenta con las principales certificaciones en materia de gestión ágil de proyectos:

• PMP (Project Management Professional del PMI).
• PMI-ACP (PMI Agile Certified Practitioner).
• CSM (Certified Scrum Master).
• CSPO (Certified Scrum Product Owner).
• CSP (Certified Scrum Professional).
• CST (Certified Scrum Trainer).

Obviamente posee otras certificaciones de relevancia, sin embargo es de notar que la mayoría de sus calificaciones apuntan a la gestión ágil de proyectos.  El hecho de que ella sea la principal expositora del IV Congreso Internacional de Gestión de Proyectos y a la vez sea una eminencia en cuanto a la Gestión Ágil de Proyectos nos deja muy claro que cada vez más y más equipos, organizaciones y grupos están adoptando Ágil como el modo de llevar a cabo sus proyectos en un mundo que va tan veloz y requiere que nos adaptemos rápidamente a su cambios. 

Asociación Dominicana de Gestión de Proyectos (ADGP), adscrita al International Project Management Association (IPMA).

La International Project Management Association (IPMA) fue fundada en 1965 bajo el nombre de “International Management System Association (IMSA)” por un conjunto de “managers”, luego en 1979 fue nombrada International Project Management Association (IPMA), la cual es una federación internacional de más de 50 sociedades nacionales de gestión de proyectos distribuidas en África, Asia, Europa y las Américas.  Contaba en el 2012 con poco más de 120,000 miembros.

La ADGP es una asociación profesional de gestión de proyectos adscrita al IPMA, aunque son independientes en cuanto a sus operaciones, se manejan bajo los lineamientos del IPMA y son estos últimos los que hasta cierto punto “apadrinan” la ADGP.  Surgió en el año 2013 como parte del proyecto de ampliación de LATNET (Red de Asociaciones Latinoamericanas de IPMA) y apoyada en un conjunto de profesionales que en ese momento (2013) cursaban el Master in Project Management de la universidad UQO de Canadá.

En el mes de noviembre cuentan con varias propuestas relacionadas con la Gestión Profesional de Proyectos.

Nombre del Evento: Taller Internacional de Dirección de Proyectos para Jóvenes.

Lugar: Universidad INTEC, Salón Julio Ravelo de la Fuente.

Fecha: 4 de Noviembre 2014

Más información: http://www.adgp-ipma.do/.

Este taller pretende motivar a los profesionales más jóvenes y estudiantes universitarios a que se involucren en la rama profesional de la Gestión de Proyectos.  Cuenta con exponentes de renombre en materia de Gestión de Proyectos como el dr. Jesus Martinez Almela (de España) y el Ing. José Reyes (de Panamá), ambos excelentes profesionales de la Gestión de Proyectos y muy experimentados (el Ing. José Reyes es Project Manager en el proyecto de las Esclusas de la ampliación del canal de Panamá). 

Nombre del Evento: Primer foro regional de energía.

Lugar: Universidad INTEC, Salón Julio Ravelo de la Fuente.

Fecha: 5 de Noviembre 2014

Más información: http://www.adgp-ipma.do/.

Este es el primer Foro Regional de Energía que se realizará en la República Dominicana.  Contará con expositores de Panamá, México, España y República Dominicana.  Aunque este evento es muy orientado al tema energético, los expositores son profesionales que también tienen formación en Gestión de Proyectos y estará auspiciado por la ADGP y el IPMA.

Un poco de historia de "Ágil"

Como hemos podido ver en post anteriores (Que es Ágil), la gestión ágil de proyectos intenta resolver los problemas de gestión que el enfoque “Tradicional” o “En Cascada” no puede.  La gestión ágil de proyectos esta enfocada básicamente en proyectos con alto nivel de incertidumbre, con mediano o alto nivel de complejidad, con procesos desconocidos o que deberán ser adaptados durante se este ejecutando el proyecto, características del producto, servicio o resultado que podrían variar basado en los resultados obtenidos por el proyecto a mediano plazo, con necesidad de retroalimentación temprana y con alta frecuencia para la toma de decisiones y que necesitan flexibilidad en el alcance, tiempo y/o costos.  Ahora bien, estos proyectos no existen desde hace 6 meses, estos tipos de proyectos tienen muchos años existiendo, entonces, quien fue el primero que pensó en esto de “Ágil”?, fue el concepto inicial de esa persona o personas el mismo que tenemos ahora?, ha evolucionado con el tiempo?, desde cuando esta este tema de “Ágil” en el mundo de la gestión de proyectos?.  Hablemos un poco de eso.

Todo este tema de “Ágil” y su funcionamiento esta basado en el uso de pequeños ciclos de trabajo, de los cuales se hacen varios (varios ciclos), estos ciclos van acumulando un resultado que crece con cada uno de ellos, este modelo es llamado “Desarrollo en Espiral”.  El Desarrollo en Espiral fue definido por primera vez en 1986 en un articulo publicado por el sr. Barry Boehm (un señor que le gustaba hacer muchas cosas interesantes por sus años de juventud y que posee un Master y un PhD en Matemáticas, para los que les gusta estudiar matemáticas a niveles de Master).   Sin embargo, la NASA uso el “Desarrollo Iterativo e Incremental” en su proyecto Mercury a principios de los 60s según un artículo publicado por el sr. Victor R. Basili (“Iteractive and Incremental Development: A Brief History”).  En ese mismo articulo se menciona que IBM estuvo usando estas técnicas a principios de 1957.  Es decir, este asunto lo usan desde hace un tiempo, imagínese… 1957  0_o.

Mientras estas personas de la NASA e IBM estaban tratando de gestionar sus proyectos y crear sus productos usando un enfoque distinto al “Tradicional”, el Project Management Institute (PMI) es formado en Estados Unidos en el 1969, es formado también el International Project Management Association (IPMA) en Europa para eso del 1965 (aunque ese nombre lo oficializaron realmente en el 1979, del 1965 al 1979 tenían otro nombre), en 1953 inician en Toyota con el uso de las pizarras de Kanban, que no es mas que un sistema de tarjetas postradas en columnas (regularmente en una pizarra) para controlar el trabajo en proceso, trabajo pendiente, trabajo terminado, y otros estados.  Todo esto de Kanban surgió como un subsistema de JIT (Just in Time) y lo mencionamos porque se usa bastante en el enfoque “Ágil”.

Paralelo a todo lo que he mencionado, la industria de software estaba en asenso y como ya les había mencionado, estos proyectos de desarrollo de software cumplen con la gran mayoría de las características que una gestión “En Cascada” no podía resolver, estos señores que producían software tenían un serio problema en las manos y necesitaban resolverlo.  Y Como dijo Platón “La necesidad es  la madre de la invención”, comenzaron a surgir un conjunto de “Frameworks”, Metodologías, Mejores Prácticas, Guías, Artículos, etc. que indicaban como los diferentes grupos de ingenieros de diferentes industrias intentaban resolver la situación.  En 1986 se usa por primera vez el término “Scrum” haciendo alusión a un “Framework” para la gestión de proyectos de software.  Esto fue en un artículo de Harvard Business Review publicado por un conjunto de ingenieros que usaron ese novedoso “Framework” en empresas como Canon, Honda, NEC, 3M, Xerox, HP, etc.

Ya para mediados de los 90s existían varias opciones para poder enfrentar los proyectos que la gestión “En Cascada” no podía solucionar, Scrum se populariza, eXtreme Programming y TDD (Test Driven Development) que son otras formas de desarrollar productos de software atendiendo a las características que mencionamos al principio de este post y que inician a finales de los 90s (gracias a un señor llamado Kent Beck).

A esos del 2000 ya teníamos un conjunto importante de “Frameworks” y metodologías que “resolvían” el tema del desarrollo de software (que eran los mas afectados por la naturaleza de sus proyectos) y que habían surgido en la década de los 90s,  pero todos estaban hasta cierto punto dispersos.  Entonces, en el año 2001, específicamente entre el 11 y el 13 de Febrero de ese año, en el Lodge at Snowbird resort de Utah, 17 personas se reunieron a hablar un poco sobre el tema.  Estas personas representaban los principales “Frameworks Agiles” hasta ese momento y producto de esa reunión se formo la Alianza Ágil compuesta por todos ellos y también surgió la pieza principal que rige hoy en día el Desarrollo Ágil, nos referimos a el Manifiesto Ágil, el cual fue firmado por todos los presentes.

El Manifiesto Ágil que surgió de esa reunión con los 17 principales representantes de los diferentes movimientos “ágiles” hasta ese momento, cuenta con cuatro valores y 12 principios y aquí esta lo que dice:

"Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda."

Lo firmaron los siguientes personajes:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherlan and Dave Thomas.

Los 12 Principios del Manifiesto Ágil son los siguientes:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Todo lo anterior es historia, sin embargo, hoy en día siguen vigente todos estos principios y valores y cada día son mas los equipos de desarrollo de software que usan los “Frameworks”, metodologías y mejores practicas que fueron impulsadas a través de este manifiesto y por estos autores.

No obstante, no solo los proyectos de software tienen problemas en cuanto a su gestión que el enfoque “En Cascada” no puede resolver y según hemos visto, el manifiesto ágil aunque puede usarse para el desarrollo de productos, esta enfocado al desarrollo de productos de software.  Atendiendo a esta problemática, en el 2005, un grupo de los autores del manifiesto ágil junto a otro pequeño grupo de personas, redactaron lo que le llamaron “PM Declaration of Interdependence” o DOI que cuenta a su vez con seis principios que son mas específicos de la gestión de proyectos ágiles en general (no específicos de la gestión de proyectos de software).  Los seis principios son los siguientes (en ingles):

1. We increase return on investment by making continuous flow of value our focus.
2. We deliver reliable results by engaging customers in frequent interactions and shared ownership.
3. We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
4. We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
5. We boost performance through group accountability for results and shared responsibility for team effectiveness.
6. We improve effectiveness and reliability through situationally specific strategies, processes and practices.

Los firmantes del DOI son los siguientes:

David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.

Bueno, hemos hablado bastante de historia, aunque se que somos gente de acción, también se que la historia debemos conocerla.  A continuación les dejo algunos enlaces de interés relacionados con este tema.  Hasta la próxima.

Enlaces:

Alianza  Ágil (http://www.agilealliance.org)

Manifiesto Ágil (http://agilemanifesto.org)

Declaración de Interdependencia (http://pmdoi.org)