archivo

Archivo de la etiqueta: James Grenning

Planning Poker, descrita inicialmente por James Grenning en 2002, es una técnica de estimación de esfuerzo de tareas concretas o historias de usuario utilizada con frecuencia en metodologías ágiles.

Es una técnica de estimación en la que participan los diferentes integrantes de un equipo de proyecto (o al menos una parte lo suficientemente representativa del mismo) y tratan de alcanzar un consenso sobre el tiempo que requiere la realización de la tarea.

La ventaja principal de este tipo de técnicas es que en el error o en el acierto cada cual ha expresado su opinión y es parte de ella, lo cual es un antídoto para la desmotivación provocada por predicciones imposibles en aquellos casos donde se imponen unas planificaciones realizadas por una persona o un grupo reducido de ellas que en la mayoría de los casos no han tenido en cuenta la opinión de los perfiles que van a ejecutar el trabajo.

El nombre de la técnica viene dado por la utilización de un mazo de cartas por cada una de las personas que participan en el proceso de estimación. La numeración elegida para las cartas y que representa una unidad de esfuerzo (o de tiempo) puede variar en función del equipo de trabajo, de la organización que decide estimar sus proyectos de esta forma, etc…

Son frecuentes los siguientes juegos de cartas:

– Uno que contenga la secuencia de Fibonacci: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. ¿Por qué la utilización de este tipo de secuencias u otras similares? Tiene como objeto representar la incertidumbre de realizar estimaciones sobre hitos de larga duración o que requieren un gran esfuerzo (se puede apreciar que conforme la secuencia va creciendo hay mayores diferencias entre los números, esto suele derivar a que cuanta mayor incertidumbre exista sobre un determinado desarrollo la estimación elegida será bastante más conservadora).

– Una que contenga la secuencia: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 y opcionalmente el el símbolo ? que significa no estoy seguro o una taza de café que significa, necesito un descanso.

– Una que utilice un juego de cartas estándar con la secuencia: As, 2, 3, 5, 8 y Rey. El Rey significa que la tarea resulta complicada de estimar.

El procedimiento de estimación tiene una dinámica sencilla:

– Un moderador que coordina la sesión y que no participa en la valoración.

– El jefe de proyectos que ayuda al moderador y toma nota de los acuerdos y aspectos más interesantes que surjan en la reunión.

– Para cada historia de usuario o tarea que se evalua, se elige al desarrollador que tenga un mayor conocimiento de la misma para realizar una breve exposición.

– A continuación el resto de participantes en el proceso de valoración pueden realizar consultas con el objeto de aclarar aquellas dudas que les puedan surgir. En todo este proceso no se debe adelantar las ideas que tiene cada uno con respecto a la estimación de esfuerzo de la tarea, de esta manera se pretende impedir que opiniones de unos influyan sobre las de otros.

– El jefe de proyectos va anotando lo más significativo del diálogo que se produce.

– Una vez finalizada esta primera ronda se procede a la estimación del esfuerzo por parte de cada uno de los participantes. Para ello, eligen una carta de su baraja, la ponen boca abajo y una vez hecho esto por parte de todos, se procede simultáneamente a ponerlas boca arriba.

– Aquellas personas que hayan realizado las estimaciones más altas y las más bajas, procederán a dar una explicación de por qué han realizado esa elección, una vez hecho esto se iniciará otra ronda de diálogo.

– Una vez finalizada esta fase, se procede de nuevo a realizar una estimación y así sucesivamente hasta que se alcance una solución de consenso.

– Si no se alcanza un acuerdo, se puede dejar la evaluación de la tarea para otra ocasión, intentar negociar un consenso por parte del moderador u ofrecer un mayor peso a la opinión de la persona responsable de realizar la tarea o de que la tarea se ejecute correctamente en tiempo y forma.

– Con el propósito de evitar que cada estimación se prolongue excesivamente se suele utilizar un reloj que delimita el tiempo dedicado a cada uno. Una vez finalizado el tiempo, se podrán tomar decisiones como las indicadas en el párrafo anterior.

Estudios realizados han llegado a la conclusión que esta técnica produce estimaciones menos optimistas que otras y que además suelen resultar bastante precisas.

Una vez analizados los principios y valores del manifiesto ágil, en este artículo se va a realizar un breve perfil de sus diecisiete participantes, con el objetivo de que se pueda apreciar que todo el equipo de personas que participaron eran profesionales de reconocido prestigio y que en su trayectoria profesional tenían experiencia e incluso habían publicado artículos y libros sobre la aplicación de estrategias que posteriormente a alto nivel se plasmaron en el manifiesto ágil.

– Kent Beck: Americano. Creador de la metodología de programación extrema y de la metodología de desarrollo guiado por las pruebas (TDD: Test-driven Development). Coautor de JUnit. Promotor de la reunión que dio lugar a la creación de manifiesto ágil para el desarrollo de software.

– Mike Beedle: Americano. Ha sido uno de los pioneros en la aplicación de Scrum (desde 1995) en proyectos de desarrollo de software en diferentes organizaciones y tipos de sistemas (en cuanto al proceso o procesos de negocio que tratan de informatizar).

– Arie van Bennekum: Holandés. Jefe de proyectos y consultor especializado en la metodología DSDM (método de desarrollo de sistemas dinámicos), representó al DSDM Consortium en la reunión.

– Alistair Cockburn: Americano. Creador de la familia de metodologías Crystal. Contribuyó a la expansión de la utilización de los casos de uso con la definición que hizo de los mismos en el libro “Escribir casos de uso efectivos” publicado en el año 2000, propiciando la generalización de su uso para describir el comportamiento de los requisitos software y de los procesos de negocio (a más alto nivel). La creación del concepto de caso de uso es bastante anterior, del año 1986 y fue realizada por el sueco Ivar Jacobson

– Ward Cunningham: Americano. Howard G. Cunningham fue el creador de la primera solución Wiki (WikiWikiWeb) y se considera un pionero tanto en la aplicación de programación extrema como en la utilización de patrones de diseño.

– Martin Fowler: Americano. Especialista en procesos de refactorización de software, programación orientada a objetos, UML y programación extrema. Hizo popular el uso del término “inyección de dependencias”.

– James Grenning: Americano. Especialista en sistemas empotrados. Fue uno de los pioneros en desarrollo de proyectos bajo la metodología de programación extrema. Experto en TDD (Test-driven Development). Ha sido el creador de la técnica de estimación Planning Poker.

– Jim Highsmith: Americano. James A. Highsmith III. Ingeniero de software experimentado que ha participado en proyectos de desarrollo de software en muchos países del mundo. En el año 1999 publicó el libro “Adaptative Software Development” donde puso de manifiesto la naturaleza adaptativa de los proyectos de desarrollo de software. Se ha especializado en la consultoría de proyectos que se realizan en entornos inestables y con una complejidad creciente.

– Andrew Hunt: Americano. Desarrollador de software con gran experiencia. Publicó junto a Dave Thomas en el año 1999 el libro “The Pragmatic Programmer”, en el que realizó una definición de lo que consideraban un programador práctico o pragmático:

– Early adopter.
– Curioso.
– Pensador crítico.
– Realista.
– Aprendiz de todo, maestro de nada.

Fue uno de los introductores en occidente de la programación en Ruby, mediante la publicación en el año 2000 del libro “Programming Ruby: A Pragmatic Programmer’s Guide”.

– Ron Jeffries: Considerado junto a Kent Beck y Ward Cunningham como uno de los creadores de la programación extrema. Participó junto a Beck en el proyecto de 1996 en Chrysler que dio lugar a este concepto.

– Brian Marick: Americano. Especialista en realización de tareas de testing. En el año 1995 publicó uno de sus libros más conocidos: “The Craft of Software Testing: Subsystem Testing Including Object-based and Object-oriented Testing”. Experto en Ruby.

– Robert C. Martin: Americano. Robert Cecil Martin (Uncle Bob). Dedicado a tareas de desarrollo de software desde 1970. Especialista en programación orientada a objetos sobre todo en el área de patrones de diseño.

– Steve Mellor: Americano. Especialista en sistemas empotrados, programación orientada a objetos y MDA (Model Driven Architecture). Creador junto a Sally Shlaer del método Shlaer-Mellor que es uno de los métodos de análisis y diseño orientado a objetos que surgió a finales de la década de los ochenta como respuesta a las principales problemáticas que presentaba el análisis y diseño estructurado, entre las cuales destacaban la complejidad de los diseños estructurados y la dificultad de mantener tanto su documentación de análisis como de diseño.

– Jon Kern: Americano. Inició su carrera profesional en sistemas empotrados en el área militar. Considerado como uno de los pioneros en la aplicación de la programación orientada a objetos. Especialista en programación Java y en MDA.

– Ken Schwaber y Jeff Sutherland: Americanos. Creadores de la metodología Scrum.

– Dave Thomas: Inglés. Autor junto a Andrew Hunt del libro “The Pragmatic Programmer”. También junto al mismo autor se considera uno de los introductores de Ruby en occidente.

Soy un converso, quizá por eso mi postura es más radical. Estoy cansado de participar en desarrollos con metodologías clásicas que no terminan de tener éxito (no tener éxito no es lo mismo que fracasar, aunque bastante de ellos sí que se podrían considerar un fracaso), podría ser algo que solo me pasara a mi, pero no es así, sucede con frecuencia y seguro que todos nosotros conocemos o hemos vivido proyectos con estos resultados.

La crisis del software sigue existiendo y existirá mientras no cambien muchas cosas. Los que nos dedicamos a esto tenemos muchos esquemas mentales que cambiar, son años haciendo los desarrollos de una determinada manera y también de formación centrada exclusivamente en metodologías clásicas.

El éxito o el fracaso de un proyecto no es exclusivo de las metodologías, pero sí predisponen a obtener unos resultados u otros.

Los proyectos de desarrollo de software tienen una naturaleza cambiante, es complicado acertar en todo: obtener los requisitos del usuario, la mecánica de comunicación entre usuario y sistema, la interfaz, etc… y lo es porque ni los usuarios tienen claro lo que quieren hasta que ven funcionalidades implementadas y también porque no siempre se interpreta adecuadamente por parte de los analistas o técnicos del proyecto las necesidades de los usuarios.

Metodologías de carácter eminentemente predictivo como las clásicas no son acordes con la naturaleza del desarrollo de software, habrá excepciones porque no existen llaves maestras que sirvan para todo.

Las metodologías ágiles, son adaptativas, son iterativas, incrementales. Sin embargo por encima de ellas está la propia filosofía del desarrollo ágil, realmente es la esencia, una vez entendida es mucho más trascendente que cualquier forma de llevarla a cabo.

Teniendo claro qué significa ser ágil, hasta su aplicación en metodologías clásicas las hace más flexibles.

En el año 2001 se reunieron en Salt Lake City diecisiete prestigiosos expertos en gestión de proyectos, ingeniería y desarrollo de software. La convocatoria la realizó Kent Beck, padre de la programación extrema.

En la reunión analizaron las problemáticas existentes en el desarrollo de software y en la necesidad de cambiar la forma en que se enfocaban y hacían los proyectos de desarrollo de software, lo cual dio lugar a unas conclusiones, recogidas en el manifiesto ágil.

En mi opinión, se trata de un manifiesto a favor del desarrollo de software, en su defensa, en la defensa de los que nos dedicamos a esta profesión ya que la mejor forma de dignificarnos es conseguir que la mayor parte de nuestros proyectos tengan éxito. Hay que romper con lo que no funciona, si el desarrollo de software es de una manera, actuar de otra es ir contra natura.

Los firmantes del manifiesto fueron las siguientes personas: 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 Sutherland y Dave Thomas.

El contenido del manifiesto es el siguiente, primero pongo el original en inglés y a continuación su traducción:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

– Individuals and interactions over processes and tools.
– Working software over comprehensive documentation.
– Customer collaboration over contract negotiation.
– Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.”

“Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

– A los individuos y su interacción, por encima de los procesos y las herramientas.
– El software que funciona, por encima de la documentación exhaustiva.
– La colaboración con el cliente, por encima de la negociación contractual.
– La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.”

En el próximo artículo sobre esta materia comenzaré a exponer mi punto de vista sobre cada principio de los que componen el manifiesto.