Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI

Leccin 0

Hola!

Quiero darte la bienvenida a "Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI".

Me presento, soy Javier Garzs, y soy el coordinador del curso.

Mi primer proyecto gil... fue en 2001. Incluso an guardo las diapositivas que usamos para arrancar

aquel proyecto

eXtreme Programming y los mtodos giles (2001) from Javier Garzs

Brevemente, soy Mentor gil, Scrum Mster, experto en gestin de proyectos y equipos. Hasta la fecha,

he trabajado para ms de 80 empresas (como INDITEX, TELEFNICA, SIEMENS, INDRA, AENOR,

BBVA, etc.). Aqu te dejo mi CV completo.

En lo que refiere a formacin, soy postdoctorado e investigador invitado en la Universidad Carnegie

Mellon (Pittsburgh, EE.UU), donde trabaj en Agilidad y Scrum, Doctor (Ph.D.) (cum laude por

unanimidad) e Ingeniero Superior en Informtica (premio extraordinario) por la UCLM.

He sido programador, jefe de proyecto, consultor, director de informtica, CIO, diseador, he pasado por

casi todas las dedicaciones del desarrollo software. Llevo ms de 17 aos en el mundo profesional IT.

Ahora, profe de la Rey Juan Carlos y colaboro con 233 grados de TI, en todo lo relacionado con agilidad.

Desde 2006 escribo un blog sobre tecnologa, ya con ms de 1100 post: javiergarzas.com

Recomendamos:

Participar activamente, debatiendo, compartiendo ideas y realizando los talleres.

Investigar sobre los temas tratados y debatir en grupo cada leccin.

Compartir sugerencias y dudas tanto en el foro general como en los foros de debate especficos.

Incorporarse al grupo de usuarios de Agilidad y Calidad en el Software y los Sistemas de

Informacin para mantener el contacto entre los asistentes tras la finalizacin del curso.

Y si ests en Madrid, tambin puedes mantener el contacto presencialmente en estos temas unindote a

las reuniones mensuales, gratuitas y desinteresadas, que organizamos desde el grupo de

Meetup Liderazgo tcnico - Peopleware - Management 3.0.

Tambin puedes darte de alta a nuestra newsletter en la que peridicamente enviamos noticias y

novedades en el mundo de la gestin de proyectos, agilidad, gestin de equipos, etc.

Aqu comienza la historia....

(https://www.youtube.com/watch?v=pNsMZJLHQTE)

Objetivos del curso

Los objetivos del curso son que el alumno conozca la gestin gil de proyectos tecnolgicos para

gestionar con xito el da a da de los proyectos.

Prcticas y tecnologas que aborda el curso:

SCRUM, HISTORIAS DE USUARIO, GESTIN DE EQUIPOS, PEOPLEWARE, PRODUCT

OWNER, ESTIMACIN GIL, PUNTOS HISTORIA, PRODUCT BACKLOG, CICLOS DE VIDA

GILES, LEAN, KANBAN, etc.

Desglose de objetivos

Conocer las bases de las metodologas giles y su diferencia con las metodologas tradicionales.

Conocer las prcticas giles propias de Scrum, sus particularidades e importancia actual de dicha

metodologa gil en el sector.

Conocer las claves ms importantes en la gestin de equipos.

Conocer LEAN Y Kanban.

Presentar cules son los mtodos de estimacin ms eficientes en el rea de las metodologas

giles. Veremos cmo funciona el Planning Poker Y LOS PUNTOS HISTORIA

Otros aspectos relacionados, como la relacin de las metodologas giles, como Scrum, con

modelos de procesos como CMMI o ISO/IEC 15504.

Dirigido a

Estudiantes de carreras tecnolgicas.

Desarrolladores.

Quienes quieran aplicar la agilidad a otros contextos

Profesionales de informtica en general

Directivos, Jefes de proyecto, responsables de calidad

Consultores

Personal de gerencia media y tcnica del rea de TI.

Modalidad de evaluacin

El curso est compuesto de 6 lecciones de contenido audiovisual, textual y presentaciones.

No est previsto restringir los horarios de acceso por lo que el estudiante podr acceder a las

lecciones a partir del momento en que se habiliten y hasta la finalizacin del curso.

Al finalizar cada leccin, el usuario obtendr una nota con su calificacin despus de

realizar el test correspondiente, siendo todos estos obligatorios. Esa nota no tendr ningn

valor sobre la calificacin final del curso. Solo se utilizar para que el estudiante conozca cmo

ha realizado esa leccin. Cada test podr realizarse una nica vez, y es obligatoria su realizacin

para pasar al siguiente mdulo.

Las lecciones han de realizarse en orden secuencial, es decir, para acceder a una leccin es

necesario haber completado la leccin anterior.

Para obtener el certificado que indica que se ha superado el curso, es necesario obtener una

calificacin del 50% en el examen final. Este examen estar disponible para su realizacin tras

la publicacin de todas las lecciones del curso.

Utiliza el "Foro" para cualquier tipo de duda que te surja sobre el curso o su contenido. En este

foro sers respondido por otros alumnos o por los profesores del curso.

Normas de los foros

Para que la participacin en los foros del curso sea satisfactoria para todos los alumnos, se deben seguir

las reglas que se detallan a continuacin.

Debe mantener una conducta apropiada con el resto de miembros.

Escriba en la seccin o foro adecuado (foro general o foro especfico de lecciones).

Trate temas que estn relacionados con la temtica del curso.

No publique contenido indebido o censurable.

No incluya anuncios con fines comerciales o publicitarios.

No publique contenido que infrinja cualquiera de los derechos legales de terceros, como pueden

ser derechos de propiedad intelectual.

El foro podr ser abierto algunos das antes del comienzo del curso, y ser cerrado al finalizar el

mismo (aunque el examen final del curso continue abierto), por lo que si deseas realizar

comentarios en el foro podrs hacerlo hasta el ltimo da del curso.

En caso de incumplimiento de alguna de las reglas especificadas, los administradores y/o moderadores

podrn tomar las acciones que consideren oportunas.

Fuentes, referencias y agradecimientos

Agradecer a los compaer@s de la Academia online de 233 Grados de TI por sus comentarios,

sugerencias y materiales cedidos gratuitamente.

Una gran parte del material del curso est sacado de las fuentes detalladas a continuacin. Por lo que si en

algn momento necesitas ms material para ampliar el contenido del curso, puedes encontrarlo en:

Libro: Cmo sobrevivir... A la planificacin de un proyecto gil, Javier Garzs

Libro: Gestin de Proyectos gil...y las experiencias de ms de 12 aos de proyectos giles

Y de la seccin de agilidad del blog de javiergarzas.com:

Agilidad

Mi agradecimiento a aquellos con los que he compartido proyectos profesionales, a los asistentes a los

diferentes webinars, seminarios y conferencias que hemos organizado sobre diferentes aspectos de la

calidad software y proyectos giles, por habernos transmitido en qu temas debera incidir el curso,

destacando a los lectores del blog www.javiergarzas.com , y sus comentarios de incalculable valor para

motivar este curso.

Quera destacar especialmente la labor de revisin, maquetado, sugerencias y los comentarios realizados

por:

- Ana Mara del Carmen Garca Oterino

- David Garca Fernndez

- M ngeles Morales Muoz

- Noem Navarro Snchez

Leccin 1: Construir software no es como construir coches o casas

La predictibilidad, ciclo de vida en cascada o desarrollo tradicional

En su nacimiento, la gestin de proyectos software intent imitar la gestin de proyectos de otras

disciplinas, como la arquitectura, las industria o la ingeniera civil, hasta el punto de heredar y adaptar al

mundo del software muchos de sus roles (p.e. arquitectos software) y tipos de organizaciones (p.e.

fbricas de software).

Hoy en da una de las prcticas ms discutidas y polmicas de las que se han querido heredar desde otras

disciplinas es la llamada predictibilidad, tambin conocida como gestin de proyectos dirigida por la

planificacin, desarrollo tradicional o incluso tambin conocida como desarrollo pesado.

"Vdeo resumen de qu es la Agilidad"

https://www.youtube.com/watch?v=oShXAC26rcs

La predictibilidad se basa en dividir un proyecto en fases, por ejemplo, de manera simplificada,

requisitos, diseo y construccin, y que cada una de estas fases no comience hasta que termine con

xito la anterior.

Se le llama predictibilidad porque cada fase intenta predecir lo que pasar en la siguiente; por

ejemplo, la fase de diseo intenta predecir qu pasar en la programacin, y esos diseos intentarn ser

muy precisos y detallados, para ser cumplidos sin variacin por los programadores.

Adems, en este tipo de gestin, cada una de estas fases se realiza una nica vez (no hay dos fases de

requisitos). Y las fases estn claramente diferenciadas (en teora, est claro cundo termina el diseo y

comienza la programacin), hasta el punto de tener profesionales claramente diferenciados y

especializados en cada una de ellas: analistas de requisitos, arquitectos de diseo software,

programadores, personas para pruebas, etc.

Normalmente cada fase concluye con un entregable documental que sirve de entrada a la siguiente

fase, la especificacin de requisitos software es la entrada al diseo, el documento de diseo la

entrada a la construccin, etc.

"Conferencia (15 min.) sobre las bases de la agilidad y sus diferencias con las disciplinas tradicionales"

https://www.youtube.com/watch?v=L9qlrgKWqfI&list=PL-bVpgNOlmip9lfzxpdW2sDeigRkarNgk

La gestin de proyectos predictiva es tpica en disciplinas como la arquitectura. Y desde sus orgenes, la

ingeniera del software intent perseverantemente emular a las ingenieras clsicas. Tener una fase de

diseo muy claramente separada de la programacin (hasta el punto de intentar tener una organizacin

cliente que detalle los diseos y otra organizacin, normalmente llamada fbrica de software, que los

implemente). Que la programacin no comenzase hasta que terminase el diseo. Que el diseo concluya

con unos planos precisos que guen totalmente la construccin. Que una vez que se hace un diseo ste no

se modifique; de hecho, notaciones como UML (Unified Modeling Language es un lenguaje grfico para

visualizar, especificar, construir y documentar un sistema) se concibieron para construir los planos

detallados del software.

Al anterior tipo de gestin de proyectos predictiva, en el mundo del software se le conoce como ciclo

de vida en cascada (ver Figura 1).

Figura 1. Ejemplo de ciclo de vida predictivo o en cascada

LECTURAS PARA AMPLIAR EL TEMA:

Diagramas Gantt cmo arma de destruccin masiva de proyectos. Maneras de usar un Gantt para matar un

proyecto

gil vs. Tradicional

Construir software no es como construir coches o casas

En software, la experiencia nos dice que es muy difcil especificar los requisitos en una nica y

primera fase. Por la complejidad de muchas de las reglas de negocio que automatizamos cuando

construimos software, es muy difcil saber qu software se quiere hasta que se trabaja en su

implementacin y se ven las primeras versiones o prototipos [1].

Tambin es muy difcil documentar de una nica vez, a la primera, antes de la codificacin,un diseo

que especifique de manera realista y sin variacin todas las cuestiones a implementar en la programacin.

Las ingenieras clsicas o la arquitectura necesitan seguir este tipo de ciclos de vida en cascada o

predictivos porque precisan mucho de un diseo previo a la construccin, exhaustivo e inamovible:

disponer de los planos del arquitecto siempre antes de empezar el edificio. Nadie se imagina que una vez

realizados los cimientos de un edificio se vuelva a redisear el plano y se cambie lo ya construido.

Adems, los planos para construir son precisos y pocas veces varan, ya que la mayora de los diseos

de las ingenieras clsicas, arquitecturas, etc., pueden hacer un mayor uso de las matemticas o la fsica.

En software no es as. Y aunque se pretenda emular ese modo de fabricacin, en software no funciona

bien, y debemos tener muy claro que es casi imposible cerrar un diseo a la primera para pasarlo a

programacin sin tener que modificarlo posteriormente.

Evolucin fabricacin software

Por lo general, realizar un cambio en el producto final que construyen las ingenieras clsicas o la

arquitectura es muy costoso. Cambiar, por ejemplo, la posicin de una columna en un edificio o realizar

modificaciones a la estructura de un puente ya construido tiene un alto coste. Y de ah que la arquitectura

o las ingenieras clsicas pretendan lograr a toda costa diseos o planos de un alto nivel de detalle, para

que una vez que comience la fase de construccin no tengan que ser modificados. Adems,

normalmente, en la arquitectura o en las ingenieras clsicas los costes de construir son muy

elevados en comparacin con los de disear. El coste del equipo de diseadores es sustancialmente

inferior al de la realizacin de la obra, del puente, edificio, etc.

La anterior relacin de costes no se comporta igual en el caso del software. Por un lado, el software,

por su naturaleza (y si se construye mnimamente bien), es ms fcil de modificar. Cambiar lneas de

cdigo tiene menos impacto que cambiar los pilares de un edificio ya construido. De ah que existan

numerosas propuestas que recomiendan construir rpido una versin software y modificarla

evolutivamente (la tcnica de la refactorizacin trabaja sobre esta idea). En software no existe esa

divisin tan clara entre los costes del diseo y los de la construccin.

Tambin en las ingenieras clsicas o la arquitectura los roles y especializacin necesaria en cada

fase son diferentes. Los planos o diseos los realizan arquitectos que no suelen participar en la fase de

construccin. La construccin tiene poco componente intelectual y mucho manual, al contrario que

el diseo. Y todo apoya a que existan dos actividades claramente diferenciadas: el diseo y la

construccin.

En nuestro caso, el producto final, el software, tiene diferencias muy sustanciales con estos productos

fsicos. Estas diferencias hacen que el proceso de construccin sea diferente. Durante muchos aos,

quizs por la juventud de la ingeniera del software, se han obviado estas diferencias, e incluso se han

intentado encontrar metodologas que imitasen y replicasen los procesos de construccin tradicional al

software. Ejemplo de ello son las primeras versiones y usos de lenguajes de diseo como UML, o

metodologas como RUP [2] o Mtrica v3 [3].

Sin embargo en muchas ocasiones, estos intentos de emular la construccin de software a productos

fsicos han creado importantes problemas y algunos de los mayores errores a la hora de gestionar

proyectos software.

Diferenciar el cmo se construye software del cmo se construyen los productos fsicos es uno de los

pilares de las metodologas giles (M. Fowler, 2005) [4]. De hecho es un tema del que se ha escrito

mucho .Y tambin se ha debatido bastante, desde hace muchos aos, con posturas a favor y en contra.

Y es que en software,es frecuente que diseo y construccin muchas veces se solapen, y por ello se

recomiende construir por iteraciones, por partes, y el uso de prototipos incrementales.

[1] En este caso se utiliza la palabra prototipo como sinnimo de un producto software con

caractersticas que pueden ser utilizadas por el cliente

[2] RUP, por sus siglas en ingls que significan RationalUnifiedProcess es un proceso de desarrollo de

software utilizado junto con UML y que constituye una metodologa para el anlisis, diseo,

implementacin y documentacin de proyectos software orientados a objetos.

[3] Mtrica v3 es una metodologa de planificacin, desarrollo y mantenimiento de sistemas de

informacin, mayormente promovida y utilizada en el mbito de las administraciones pblicas.

[4] Fowler, M. (2005). The new methology.

Frente a la prediccin adaptacin, o el ciclo de vida iterativo e incremental

Es curioso ver como el concepto ciclo de vida, una de las piezas ms fundamentales, y trascendentales,

de la gestin de un proyecto software produce tanta confusin.

En parte, tampoco es de extraar, debido a que no existe una nica terminologa al respecto, existen

muchas definiciones, conceptos confusos, etc. Por eso vamos a aclarar los principales tipos de ciclos de

vida que hay:

Cascada

Las fases del ciclo de vida (requisitos, anlisis, diseo, etc.) se realizan (en teora) de manera lineal,

una nica vez, y el inicio de una fase no comienza hasta que termina la fase anterior.

Su naturaleza es lineal, tpica de la construccin de productos fsicos y su principal problema viene de

que no deja claro cmo responder cuando el resultado de una fase no es el esperado.

El ciclo de vida ms criticado en los ltimos aos. En muchos proyectos su implantacin ha sido un

fracaso, mientras que hay otros proyectos que trabajan perfectamente de esta manera.

El ciclo de vida incremental

Cada iteracin (una iteracin es un periodo de tiempo, no confundir con el ciclo de vida iterativo, que

veremos luego, siendo este punto confuso, por las definiciones) contiene las fases del cascada estndar,

pero cada iteracin trabaja sobre un subconjunto de funcionalidad. La entrega total del proyecto se

divide en subsistemas priorizados.

Desarrollar por partes el producto software, para despus integrarlas a medida que se completan.

Un ejemplo de un desarrollo puramente incremental puede ser la agregacin de mdulos en diferentes

fases. El agregar cada vez ms funcionalidad al sistema.

El ciclo de vida iterativo

En cada ciclo, iteracin, se revisa y mejora el producto. Un ejemplo de desarrollo iterativo es aquel

basado en refactorizaciones, en el que cada ciclo mejora ms la calidad del producto.

Es importante sealar que este ciclo no implica aadir funcionalidades en el producto, pero si la

revisin y la mejora.

Iterativo e incremental

Incremental = aadir, iterativo = retrabajo

Se va liberando partes del producto (prototipos) peridicamente, en cada iteracin, y cada nueva

versin, normalmente, aumenta la funcionalidad y mejora en calidad respecto a la anterior. Aqu

hay un post con ms informacin.

Adems, el ciclo de vida iterativo e incremental es una de las bases de un proyecto gil, ms

concretamente, con iteraciones cortas en tiempo, de pocas semanas, normalmente un mes y raramente

ms de dos

http://www.youtube.com/watch?v=EwmI5NDKLBo&feature=youtu.be

El ciclo de vida iterativo e incremental es una de las buenas prcticas de ingeniera del software ms

antiguas, su primer uso en el software se data en los 50 (pincha aqu, te dejo este post donde hablamos del

tema).

Sobre estos dos ciclos de vida te dejo un artculo de Cockburn especialmente aclaratorio.

Ciclo de vida gil

Sera un ciclo de vida iterativo e incremental, con iteraciones cortas (semanas) y sin que dentro de

cada iteracin tenga porqu haber fases lineales (tipo cascada). A partir de la anterior, matizaciones,

adaptaciones, etc., hay por cada metodologa gil que existe.

Quiz el caso ms popular es el de Scrum. Hace ya sus aos, en el 85, y en la primera presentacin oficial

de Scrum, Ken Schwaber, uno de sus creadores, hablaba sobre el ciclo de vida de Scrum, y sus diferencias

con los anteriores ciclos de vida

Segn comenta Ken Schwaber, el ciclo de vida en Cascada y el Espiral cierran el contexto y la entrega

al inicio de un proyecto. La principal diferencia entre cascada, espiral e iterativo y los ciclos de vida

giles, concretamente en Scrum, es que estos ltimos asumen que el anlisis, diseo, etc., de cada

iteracin o Sprint son impredecibles. Los Sprints, o iteraciones cortas, no son (o a priori no tienen

porqu) lineales y son flexibles.

Pero, como comentaba, cada metodologa de las llamadas giles, FDD, Crystal, DSDM, XP, etc.,

matizar su ciclo de vida.

CURIOSIDADES: El ciclo de vida iterativo e incremental es incluso ms antiguo

que el cascada!

Con la creciente popularidad de los mtodos giles en muchas ocasiones se cree que el ciclo de vida

iterativo e incremental es una prctica moderna, nueva frente al antiguo ciclo de vida en cascada, pero su

aplicacin data de mitad de los aos 50, y desde entonces ha sido ampliamente usado y se ha escrito

mucho sobre l (C. Larman & V. Basili, 2003) [1].

En 1950 la construccin del avin cohete X-15 supuso un hito en la aplicacin del ciclo de vida iterativo

e incremental, hasta el punto de que dicho ciclo de vida fue una de las principales contribuciones al xito

del proyecto

Link al texto completo. Veterano ciclo de vida iterativo e incremental (J. Garzs, 2010).

[1] Larman, C. & Basili, V. (2003). Iterative and incremental Development: A brief History. Computer

36(6), 47-56

El proyecto gil

https://www.youtube.com/watch?v=MOucV2m56rA

Comentaba Ambler [1], que un proyecto gil se podra definir como una manera de enfocar el

desarrollo software mediante un ciclo iterativo e incremental, con equipos que trabajan de manera

altamente colaborativa y autoorganizados. Es decir, un proyecto gil es un desarrollo iterativo ms la

segunda gran caracterstica implicada directamente por la iteracin extrema: equipos colaborativos y

autoorganizados.

A diferencia de ciclos de vida iterativos e incrementales ms relajados, en un proyecto gil cada

iteracin no es una mini cascada. Esto no es as, porque el objetivo de acortar al mximo las

iteraciones (normalmente entre 1 y 4 semanas) lo hace casi imposible. Cuanto menor es el tiempo de

iteracin ms se solapan las tareas. Hasta el punto que implicar que de manera no secuencial, muchas

veces solapada, y repetitivamente, durante una iteracin se est casi a la vez diseando, programando y

probando.

Lo anterior implicar mxima colaboracin e interaccin de los miembros del equipo.

Implicar equipos multidisciplinares, es decir, que no hay roles que slo diseen o programen todos

pueden disear y programar. E implica auto-organizacin, es decir, que en la mayora de los proyectos

giles no hay, por ejemplo, un nico jefe de proyecto responsable de asignar tareas.

Un proyecto gil lleva la iteracin al extremo:

1. Se busca dividir las tareas del proyecto software en incrementos de una corta duracin

(segn la metodologa gil, tpicamente entre 1 y 4 semanas).

2. Cada iteracin suele concluir con un prototipo operativo. Al final de cada incremento se

obtiene un producto entregable que es revisado junto con el cliente, posibilitando la aparicin

de nuevos requisitos o la perfeccin de los existentes, reduciendo riesgos globales y permitiendo

la adaptacin rpida a los cambios.

Normalmente un proceso gil se basa en un ciclo de vida iterativo e incremental pero no todo

proceso iterativo e incremental es un proceso gil. Adems, estn la colaboracin y los equipos

autoorganizados, entonces, qu caracteriza un proyecto gil? en el siguiente captulo veremos que

derivado de todo lo anterior se debe cumplir adems otros valores y principios.

[1] Ambler, S. (2008). Acceleration: An agile productivity measure. Disponible en:

https://www.ibm.com/developerworks/mydeveloperworks/blogs/a

mbler/entry/metric_acceleration?lang=en

El Manifiesto gil

El 12 de febrero de 2001,17 destacados y reconocidos profesionales de la ingeniera del software

escriban en Utah el Manifiesto gil. Entre ellos estaban los creadores de algunas de las metodologas

[1] giles ms conocidas en la actualidad: XP, Scrum, DSDM, Crystal, etc. Su objetivo fue establecer

los valores y principios que permitiran a los equipos desarrollar software rpidamente y

respondiendo a los cambios que puedan surgir a lo largo del proyecto.

Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales,

caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las

actividades desarrolladas.

De esta forma se establecieron cuatro valores giles:

Valorar a los individuos y las interacciones del equipo de desarrollo sobre el proceso y las

herramientas. Se tendrn en cuenta las buenas prcticas de desarrollo y gestin de los

participantes del proyecto (siempre dentro del marco de la metodologa elegida). Esto facilita el

trabajo en equipo y disminuir los impedimentos para que realicen su trabajo. Asimismo

compromete al equipo de desarrollo y a los individuos que lo componen.

Desarrollar software que funciona ms que conseguir una documentacin exhaustiva. No es

necesario producir documentos a menos que sean necesarios de forma inmediata para tomar una

decisin importante. Los documentos deben ser cortos y centrarse en lo fundamental. La

variacin de la cantidad y tipo de documentacin puede ser ampliada dependiendo el tipo de

cliente o de proyecto. El hecho de decir que la documentacin es el cdigo fuente y seguir esa

idea sin flexibilidad puede originar un caos. El problema no es la documentacin sino su utilidad.

La colaboracin con el cliente ms que la negociacin de un contrato. Es necesaria una

interaccin constante entre el cliente y el equipo de desarrollo. De esta colaboracin depende el

xito del proyecto. Este es uno de los puntos ms complicados de llevar a cabo, debido a que

muchas veces el cliente no est disponible. En ese caso desde dentro de la empresa existir una

persona que represente al cliente, haciendo de interlocutor y participando en las reuniones del

equipo.

Responder a los cambios ms que seguir estrictamente un plan. Pasamos de la anticipacin y

la planificacin estricta sin poder volver hacia atrs a la adaptacin. La flexibilidad no es total,

pero existen muchos puntos (todos ellos controlados) donde se pueden adaptar las actividades.

LO QUE NO DICE

Ausencia total de documentacin.

Ausencia total de planificacin: planificar y ser flexible es diferente a improvisar.

El cliente debe hacer todo el trabajo y ser el Jefe de Proyecto.

El equipo puede modificar la metodologa sin justificacin.

LEE LAS ENTREVISTAS QUE HICIMOS A LOS FIRMANTES DEL

MANIFIESTO GIL:

Entrevista a Alistar Cockburn

Entrevista a Robert C. Martin

Entrevista a Jeff Sutherland

[1]El trmino metodologa es utilizado de manera coloquial, siendo rigurosos las metodologas son ms

bien marcos de trabajo o frameworks.

Los Principios giles

De estos cuatro valores surgen los doce principios del manifiesto. Estos principios son caractersticas

que diferencian un proceso gil de uno tradicional. Los principios son los siguientes:

1. La prioridad es satisfacer al cliente mediante entregas tempranas y continuas de software que le

aporten 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 fundamental 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.

Comparativa resumen de agilidad vs tradicional

A modo de resumen, esta son las principales diferencias entre las metodologas giles y tradicionales:

https://www.youtube.com/watch?v=gnam324znBk

Para saber ms: Desarrollo gil o tradicional: Existe el punto intermedio?

Unin los modelos de procesos y metodologas giles

En ocasiones existe la percepcin de que es incompatible unir modelos como CMMI o ISO/IEC 15504

ISO/IEC 12207 con metodologas giles. Sin embargo, esta concepcin no es correcta, ya que los

modelos y las metodologas se encuentran en distintos niveles de abstraccin.

https://www.youtube.com/watch?v=Ukx3sGGTENY

Los modelos de procesos establecen qu es lo que espera encontrarse en los procesos, pero son las

metodologas las que indicarn cmo deben realizarse. Es por esto que el uso de modelos de procesos y

metodologas giles no debe considerarse un aspecto contradictorio sino complementario.

Can Scrum help to improve the project management process? A study of the relationships between Scrum

and Project Management process areas of CMMI-DEV 1.3.

Si quieres saber ms sobre CMMI

Gua Prctica de Supervivencia en una Auditora CMMI

Enlaces y lecturas recomendadas

Gestin gil de Proyectos Software.

Video muy interesante y dinmico de la reunin en el Dcimo Aniversario del Manifiesto gil

Una metodologa por cada proyecto

Manifiesto gil

Procesos software

Test Leccin 1

El software se construye siguiendo los mismos pasos que si construyramos una casa.

Verdadero

Falso

Si seguimos un ciclo de vida en cascada, podemos cambiar los requisitos en cualquier momento.

Verdadera

Falso

El ciclo de vida iterativo e incremental es una de las bases de un proyecto gil.

Verdadero

Falso

El ciclo de vida en cascada...

Nunca hay que usarlo en un proyecto software.

Siempre hay que usarlo en un proyecto software.

Lo usaremos dependiendo del producto software a desarrollar.

Un proyecto giles es ...

Un desarrollo iterativo

Un desarrollo en cascada con equipos autoorganizados y colaborativos

Una manera de enfocar el desarrollo software mediante un ciclo iterativo e incremental, con

equipos que trabajan de manera altamente colaborativa y autoorganizados

Ninguna de las anteriores

En un proyecto gil cada iteracin concluye...

Con un prototipo operativo

Con un prototipo no operativo

No se entrega ningn prototipo.

Ninguna de las anteriores.

Leccin 2: Peopleware

Gestin de equipos

En esta leccin se tratarn los puntos ms importantes que debemos tener en cuenta a la hora de gestionar

los equipos software en general y giles en particular. A continuacin os dejo un vdeo resumen de dichos

puntos, y una conferencia que di en Valencia con las diapositivas que utilic.

https://www.youtube.com/watch?v=o90o6Oassec&feature=youtu.be

https://www.youtube.com/watch?v=CyqQry7wrS8

Peopleware: y como no gestionar un equipo de desarrollo software from Javier Garzs

Este tema es muy importante y est muy estudiado, pero a la vez es poco conocido; la pieza fundamental

del xito de una empresa de base tecnolgica son las personas.

Comenzamos enumerando 5 caractersticas de los equipos de alto rendimiento (entendiendo por

rendimiento productividad, minimizar el desperdicio de tiempo, hacer el mximo con las personas

necesarias, evitar sobrecostes...):

1. Buscar a los miembros ms adecuados y retenerlos: es esencial el talento, hay que buscar la persona

ms adecuada para el tipo de tecnologa y proyecto que se est desarrollando, y una vez que se tiene a la

persona idnea conseguir retenerla.

2. Trabajar en un entorno de productividad, sin interrupciones: los entornos fsicos tienen un

impacto altsimo en la productividad. Uno de los principales impactos vienen de las interrupciones, como

solucin encontramos la tcnica pomodoro (tcnica de gestin personal) que dice que trabajas en

intervalos de 25 minutos dedicados exclusivamente a una tarea sin que haya cambio de contexto ni

interrupciones y luego 5 minutos de descanso.

3. Conocer el impacto de la NO calidad: si un software est mal hecho, la mantenibilidad baja, y

conlleva a que la productividad baje (como una mala solucin a ello meten ms gente a trabajar, esto hace

que vaya peor; una buena solucin es refactorizar) y como consecuencia se disparan los costes. La calidad

afecta mucho a la productividad.

4. Equipos pequeos: el tamao de los equipos es una de las claves ms importantes en la gestin de

equipos. Aadir gente a un proyecto retrasado hace que te retrase ms.

5. Equipos multifuncionales (sin hroes ni apagafuegos): un buen equipo no tiene apaga fuegos. Un

equipo multifuncional es un equipo en el que hay un equilibrio entre sus miembros, es decir, cada uno

tiene su tarea, pero en momentos especficos puede realizar otras.

LECTURAS PARA AMPLIAR EL TEMA:

Gestin de proyectos gily las experiencias de ms de 12 aos de proyectos giles.

Trabajar en ms de un proyecto a la vez genera prdida de tiempo y disminuye la

productividad

El libro Quality Software Management Volume 1. Systems Thinking escrito por Gerald M. Weinberg

en 1992, fue famoso principalmente por un estudio en el que explicaba el desperdicio de tiempo que

supona tener a las personas trabajando en varios proyectos a la vez. Concretamente, Weinberg lo

sintetizaba en la siguiente tabla:

Nmero de proyectos

simultneos

% de disponibilidad para el

proyecto

Prdida debido al cambio de

contexto

1 100 % 0 %

2 40 % 20 %

3 20 % 40 %

4 10 % 60 %

5 5 % 75 %

Tabla 1. Disponibilidad y prdida de tiempo en funcin del nmero de proyectos a la vez en el que se

trabaje.

Como se puede observar en la Tabla 1, a mayor nmero de proyectos trabajando simultneamente, la

disponibilidad para cada proyecto va disminuyendo, y la prdida de tiempo en aumento, debido al

cambio de tareas, de estar trabajando en un proyecto a pasar los pensamientos a otro. A esto se le

llama cambio de contexto, el tiempo perdido entre que cambias de una tarea a otra y te concentras en

ella. Este efecto es muy similar a las interrupciones (que se ver ms adelante).

Lo ideal es abrir y cerrar tareas, no tener muchas abiertas.

Interrumpir a quin programa, o al que realiza cualquier actividad intelectual, hace

que su productividad caiga

En trabajos intelectuales, como programar, escribir artculos, post, disear, etc., las interrupciones son

un mal que afecta enormemente a la productividad, a continuacin se explican las causas y qu medios

se pueden utilizar para que esto no suceda.

Parnin y Rugaber hicieron un estudio sobre las interrupciones en el ao 2010, siendo su conclusin ms

destacada la siguiente:

Lo normal es que a un programador le lleve de 10 a 15 minutos volver al estado de concentracin

previo al haber sido interrumpido.

La interrupcin pueden ser externa, por ejemplo, que venga alguien y te interrumpe, llamadas al

mvil, etc. O puede ser interna, leer el correo, el twitter, etc., lo que tambin es conocido como

procrastinacin.

Dos consejos son:

Para luchar contra interrupciones internas. Utilizar la tcnica pomodoro, que es bsicamente

dedicar intervalos de 25 minutos, llamados pomodoros, a una nica tarea, sin distraccin o

dedicacin a otra tarea durante la duracin del pomodoro (ni mvil, ni correo, ni twitter, etc.).

Para luchar contra interrupciones externas. Aslate, en la medida de lo posible, maanas, horas o

das, a entornos sin interrupciones.

Debemos ser conscientes del problema que esto supone, es decir, de que las interrupciones hacen que

nuestra productividad caiga, nuestro trabajo efectivo al final del da, y seguidamente poner medios para

luchar contra ellas.

Los equipos con mucha gente son menos productivos

Hay quien piensa que en un equipo, cuanta ms gente haya mejor. Esto no es as, es uno de los errores

ms frecuentes en gestin de proyectos software.

Cuando el tamao del equipo crece ms all de un nmero de personas el tiempo de proyecto no

se reduce.

Lawrence Putnam, elabor en 2003 una investigacin cuyos resultados fueron que cuando el tamao del

equipo creca ms all de un nmero de personas, el esfuerzo aumentaba y el tiempo de proyecto no se

reduca.

Imagen 1. Putnam, 2003.

Cuando el tamao del equipo incrementaba de 1 a 7 personas, el tiempo se acortaba y el esfuerzo

incrementaba. Pero cuando pasaba de 7 personas, tanto el esfuerzo como el tiempo incrementaban. Esto

ocurre a causa de:

- La coordinacin que requieren los equipos grandes es mayor.

- Hay un incremento en las rutas de comunicacin.

Para lograr la mxima eficiencia, los equipos deberan ser de 5 a 9 personas.

Para ms informacin consultar aqu.

Hay un lmite en el que no puedes recortar ms el tiempo de un proyecto aadiendo

ms gente

A la hora de planificar un proyecto, muchos responsables de proyecto ven razonable pensar que si

aaden ms gente al proyecto, el proyecto se terminar antes, y podrn encajarlo en esas complicadas

fechas.

Lo primero que hay que tener en cuenta es que hay una temporalidad llamada imposible, por mucha

gente que aadas al proyecto no podrs reducir su tiempo ms all de un tope.

Muchos investigadores han estudiado los efectos de comprimir el calendario de proyecto, todos

concluyen en que acortar el tiempo de proyecto por debajo del tiempo ideal incrementa el esfuerzo de

manera no lineal. Es decir, que si el tiempo ideal es 12 meses y 7 desarrolladores, no vas a poder

recortar el proyecto a 7 meses con 12 desarrolladores vas a necesitar muchos ms.

La siguiente tabla es popular en el mundo de la gestin de proyectos software, elaborada por Putnam,

que muestra, despus de estudiar un gran nmero de proyectos, cmo segn la reduccin el tiempo se

incrementa el esfuerzo.

Compresin/Expansin del

tiempo

Incremento/Reduccin del esfuerzo

-15% +100%

-10% +50%

-5% +25%

Tiempo ideal 0%

+10% -30%

+20% -50%

+30% -65%

More than +30% Not practical

Tabla 1. Putnam and Myers 1992

Una de las razones de este efecto viene del desperdicio de esfuerzo que aparece por aumentar el nmero

de miembros del equipo, que como veamos en el anterior apartado, es un desperdicio mucho mayor, se

dispara, si el equipo se incrementa en ms de 7 personas.

Despus de tanta investigacin sobre el tema, existe el consenso de que reducir ms de un 25% el

tiempo ideales imposible.

Quemar y saturar de trabajo al equipo no se traduce en mayores resultados

Tom DeMarco en Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency escrito en

2001, insiste en eso de que un equipo est muy ocupado y sobresaturado no da lugar a una mayor

efectividad y beneficios.

En la actualidad, hay empresas que sobrecargan a sus trabajadores, con el objetivo de terminar antes, o

ms tareas en menos tiempo, no teniendo as en cuenta el carcter humano y emocional de los equipos.

Tom DeMarco propone que debera haber ms slack, lo que se traduce en libertad para la gente de

la empresa, tener un margen de actuacin, ya que es prcticamente imposible que una persona invierta

todo su tiempo laboral en realizar cosas productivas, si una persona est agotada es probable que no

pueda hacer nada ms, bloqueando ideas creativas las cuales son necesarias para el desarrollo de la

empresa.

Que en una empresa haya slack permite a los empleados ser ms productivos e innovar.

Ya que Qu es lo ms determinante para el xito o fracaso de un proyecto? Las personas.

Aadir gente a un proyecto retrasado hace que se retrase an ms

Brooks fue director del desarrollo del famoso OS/360 de IBM, y a raz de sus experiencias, xitos y

fracasos escribi The Mythical Man-Month: Essays in Software Engineering, libro al que deben su

mayor fama, aunque no suficiente, frases como:

Aadir recursos humanos a un proyecto con retraso provocar un retraso mayor.

En un proyecto la figura del arquitecto software es esencial.

Medir el progreso de un proyecto en funcin del tiempo que lleva desarrollndose es un error

Cmo puede un proyecto acumular un retraso de un ao? acumulando retrasos da a da.

La principal causa de los problemas en el desarrollo software est en la planificacin y distribucin de

recursos, la idea de que horas y recursos humanos son intercambiables lleva a que si un proyecto est

retrasado la solucin sea agregar ms mano de obra. Pero el factor humano y las horas no se pueden

conmutar como en una multiplicacin: el tiempo extra que se aade por cada persona va a parar a

reuniones, planes, e-mails, negociaciones, discusiones, revisiones, coordinacin de reuniones, actas,

explicaciones, formacin, etc. Y por otro lado existen tareas que simplemente no se pueden dividir y

deben ser realizadas por la misma persona.

Brooks compara el desarrollo software con las arenas movedizas que durante la prehistoria engullan

animales gigantes que cuanto ms luchaban por escapar ms rpido se hundan. La nica salida de este

pozo de arenas movedizas es aplicar un proceso de ingeniera consciente y mtodos probados en la

gestin de proyectos.

Para ms informacin consultar aqu.

Programar con msica hace que seas menos productivo

En los aos 60, se realizaron experimentos sobre los efectos de programar mientras se escucha msica

en la Universidad de Cornell (EEUU). Lo vamos a explicar para razonar por qu escuchar msica hace

que seas menos productivo.

Los investigadores de la Universidad, hicieron dos grupos con estudiantes de informtica, uno grupo

con aquellos estudiantes a los que les gustaba estudiar con msica y otro con aquellos a los que no.

A los participantes se les entreg un problema de programacin en Fortran para trabajar en l con

ciertas especificaciones, y prcticamente realizaron el ejercicio con la misma velocidad y precisin. La

parte del cerebro que se requiere para la aritmtica y la lgica no se ve influenciada por escuchar

msica, pero hay parte del centro que s.

La especificacin requera una transformacin de nmeros y el resultado final de las operaciones era

que cada nmero de salida era igual a su nmero de entrada. La mayora de los estudiantes que se dieron

cuenta de ello, pertenecan al grupo de la habitacin en silencio.

Es el lado derecho del cerebro el que procesa la msica, los trabajos intelectuales, de concentracin, no

slo necesitan el lado izquierdo del cerebro, sino tambin requieren de lgica e ingenio, que se procesan

en el derecho.

Si escuchas msica, puedes perder la oportunidad del salto creativo, ya que influye en la

reduccin de la creatividad, y este efecto es acumulativo.

Es un tipo de interrupcin como hemos hablado de ello anteriormente.

Puedes leer ms en Peopleware de DeMarco y Lister.

La organizacin de la sala y las mesas de un equipo de desarrollo software influye

en la productividad

Cul es la mejor manera de organizar la sala y las mesas de un equipo de desarrollo software.

Este apartado tiene relacin con el apartado interrumpir a quien programa o quien realiza cualquier

actividad intelectual, hace que su productividad caiga ya que hay oficinas que no separan las salas de

recreo de los lugares de concentracin, por lo tanto la persona que est concentrada es interrumpida por

sus compaeros que estn de descanso y esto hace que esa persona pierda mucho tiempo.

La cuestin es que en la oficina en la que un grupo de desarrolladores (o cualquier grupo de

profesionales que realicen tareas que requieran concentracin) trabaje debiera ayudar a eso, a evitar las

interrupciones y la falta de concentracin, y eso es lo que vamos a ver en este apartado.

Uno de los aspectos fundamentales para un buen entorno de trabajo es que no haya ruido. Por tanto,

elementos como puertas, aislantes de ruido, algn mecanismo para evitar las interrupciones entre los

propios compaeros, se hacen indispensables.

Respecto al puesto de trabajo las recomendaciones son las que se describen a continuacin.

Un espacio iluminado con luz natural y con ventanas, tambin incrementa la productividad. Por otra

parte, es primordial que la gente est cmoda, con espacio suficiente para trabajar.

Est la opcin de poner las mesas sin ningn elemento de separacin entre las mismas, y da ms

sensacin de amplitud, pero eso solo se recomienda a aquellos cuya cultura de empresa es consciente

del impacto de las interrupciones y saben gestionarlas.

Ms all de la opcin anterior, est la tpica prctica de usar cubculos. Facilita la comunicacin cara a

cara, no hay puertas, es ms rpido llegar a los sitios o a las mesas de otros compaeros, etc.

La siguiente opcin, es que cada persona tenga un despacho que disminuye radicalmente las

interrupciones, pero la desventaja es el sentimiento de soledad.

En cualquiera de los anteriores es necesario complementar estos entornos con salas de reuniones para

actividades que requieran trabajo en equipo, evitando molestar al resto del equipo. Y espacio para

relajarse (con sofs, etc).

Una buena prctica es que cuando alguien quiere algo de otro se lo escribe por chat, en vez de gritrselo

y hacer que el resto de la gente gire la cabeza y empiece a opinar sin necesidad. Tambin, al pedirnos

las cosas por chat, el que responde no tiene por qu contestar inmediatamente, interrumpiendo aquello

en lo que estaba.

Test Leccin 2

1- En qu consiste la tcnica Pomodoro?

a. Es una tcnica utilizada para evitar las interrupciones externas.

b. Hacer descansos frecuentes.

c. Dedicar intervalos cortos de tiempo a una nica tarea sin distraccin.

d. Ponerse msica para aislarse de un entorno ruidoso de trabajo.

2- Qu causa que la productividad disminuya cuando trabajas en ms de un proyecto a la vez?

a. Cambio de contexto.

b. Tcnica Pomodoro.

c. Un entorno que evite las interrupciones.

d. Ninguna de las anteriores.

3. Qu ocurre cuando se reduce el tiempo del proyecto muy por debajo del tiempo ideal?

a. Aumenta el esfuerzo de manera lineal.

b. No aumenta el esfuerzo.

c. Aumenta el esfuerzo de manera no lineal.

d. Ninguna de las anteriores.

4- Segn Putnam, Cul es el rango ptimo del tamao del equipo? (ya que superado ese nmero

no se reduce significativa y proporcionalmente el tiempo y el esfuerzo)

a. A partir de 3-5 personas.

b. A partir de 5-7 personas.

c. A partir de 7-9 personas.

d. Ms de 10 personas.

5- Si a un proyecto con retraso le aadimos personas (de manera no estructurada), seguiremos

teniendo problemas respecto al tiempo?

a. No ya que las horas y los recursos humanos son intercambiables.

b. No, ya que si aadimos el doble de personas recortaremos el tiempo a la mitad.

c. S, ya que aparecen prdidas de tiempo debidas al aumento de la comunicacin, la

coordinacin, la formacin.

d. Todas las anteriores son correctas.

6- Afecta escuchar msica en la actividad de programar?

a. S, afecta en la creatividad pudiendo perder la oportunidad de un salto creativo.

b. No, no afecta.

c. S, afecta a la parte del cerebro que se requiere para la lgica y la aritmtica.

d. Ninguna de las anteriores.

7- Qu es el slack?

a. Saturar al equipo de trabajo para pretender que sea ms productivo.

b. Dar libertad al equipo, tener un margen de actuacin.

c. Ninguna de las anteriores.

d. Es una tcnica de estimacin.

Leccin 3: El Product Owner y las historias de usuario

El product owner (o propietario del producto) es aquella persona con una visin muy clara del

producto que se quiere desarrollar, que es capaz de transmitir esa visin al equipo de desarrollo y,

adems, est altamente disponible para transmitirla.

https://www.youtube.com/watch?v=NqMNMb36P80

La figura del product owner es clave en un proyecto gil, en su planificacin y seguimiento. Es una

figura que cuando no realiza correctamente su funcin el proyecto tiene un serio riesgo, y problema,

llegando incluso a dejar de ser gil, o incluso dejando de ser proyecto.

Desgraciadamente, es frecuente encontrar implantaciones errneas alrededor de este rol. En unas

ocasiones sus tareas se minimizan, en otras suelen pasarse por alto muchas de sus importantes

responsabilidades, etc.

La mayora de las ocasiones, el negocio, los usuarios, etc., van proporcionando una cantidad de ideas a

implementar, que se van convirtiendo en historias de usuario, muy superiores en nmero. La funcin del

product owner es vital, debe ser quien decida qu historias de usuario entran en el product backlog,

cules no, y adems la prioridad de las historias del product backlog.

Para saber ms...

Claves para implantar el rol de Product Owner, uno de los roles clave en un desarrollo gil (1/2)

Claves para implantar el rol de Product Owner, uno de los roles clave en un desarrollo gil (2/2)

7 responsabilidades vitales de un product owner

Video viernes: Esto es lo que hace un Producto Owner, explicado en 15 min. y de manera

divertida

Historias de usuario

En las metodologas giles la descripcin de las necesidades se realiza a partir de las historias de usuario

(user story) que son, principalmente, lo que el cliente o el usuario quiere que se implemente; es decir,

son una descripcin breve, de una funcionalidad software tal y como la percibe el usuario (M. Cohn,

2004) [1].

https://www.youtube.com/watch?v=-mbAXwB1q2M

El concepto de historia de usuario tiene sus races en la metodologa eXtremeProgramming o

programacin extrema. Esta metodologa fue creada por Kent Beck y descrita por primera vez en 1999 en

su libro eXtreme Programming Explained. No obstante, las historias de usuario se adaptan de manera

apropiada a la mayora de las metodologas giles, teniendo por ejemplo, un papel muy importante en la

metodologa Scrum.

[1] Cohn, M. (2004). User stories applied: For agile software development Addison-Wesley

Qu informacin contiene una historia de usuario

Aunque dependiendo del proyecto se podra incluir cualquier otro campo que proporcionase informacin

til, en este apartado se describen aquellos campos que se consideran ms necesarios para describir de

manera adecuada una historia de usuario. Estos campos se pueden observar en la siguiente figura:

Figura 4. Historia de usuario

De esta manera, una historia de usuario est compuesta por los siguientes elementos:

ID: identificador de la historia de usuario.

Ttulo: ttulo descriptivo de la historia de usuario.

Descripcin: descripcin sintetizada de la historia de usuario. Si bien el estilo puede ser libre, la

historia de usuario debe responder a tres preguntas: Quin se beneficia? Qu se quiere? y Cul

es el beneficio? Cohn (M. Cohn, 2004) [1] recomienda seguir el siguiente patrn: Como [rol del

usuario], quiero [objetivo], para poder [beneficio]. Con este patrn se garantiza que la

funcionalidad se captura a un alto nivel y que se est describiendo de una manera no demasiado

extensa.

Estimacin: estimacin del tiempo de implementacin de la historia de usuario en unidades de

desarrollo, conocidas como puntos de historia (estas unidades representarn el tiempo terico de

desarrollo/persona que se estipule al comienzo del proyecto).

Valor: valor (normalmente numrico) que aporta la historia de usuario al cliente o usuario. El

objetivo del equipo es maximizar el valor y la satisfaccin percibida por el cliente o usuario en

cada iteracin. Este campo determinar junto con el tiempo, el orden con el que las historias de

usuario van a ser implementadas.

Dependencias: una historia de usuario no debera ser dependiente de otra historia, pero en

ocasiones es necesario mantener la relacin. En este campo se indicaran los identificadores de

otras historias de las que depende.

Pruebas de aceptacin: pruebas consensuadas entre el cliente o usuario y el equipo que el

cdigo debe superar para dar como finalizada la implementacin de la historia de usuario. Este

campo tambin se suele denominar criterios o condiciones de aceptacin".

Cohn en (M. Cohn, 2004) [1] comenta que si bien las historias de usuario son lo suficientemente

flexibles como para describir la funcionalidad de la mayora de los sistemas, no son apropiadas

para todo. Si por cualquier razn, se necesita expresar alguna necesidad de una manera diferente a

una historia de usuario, recomienda que se haga. Por ejemplo, las interfaces de usuario se suelen

describir en documentos con muchos pantallazos. Al igual puede ocurrir con documentos especificaciones

de seguridad, normativas, etc.

No obstante, lo que s es importante con esta documentacin adicional es mantener la trazabilidad

con las historias de usuario. Por ejemplo, a travs de hojas de clculo donde se lleve el control de a qu

historia pertenece cada documento adicional, o especificando el identificador de la historia en algn

apartado del documento, etc.

[1] Cohn, M. (2004). User stories applied: For agile software development Addison-Wesley

Malas interpretaciones del concepto de historia de usuario I

Las historias de usuario equivalen a requisitos funcionales?

Popularmente se asocia el concepto de historia de usuario con el de la especificacin de un requisito

funcional. De hecho, muchas veces se habla de que a la hora de especificar una necesidad del cliente o

del usuario, las metodologas giles usan la historia de usuario y las tradicionales, el requisito funcional.

Sin embargo, detrs del concepto de historia de usuario hay muchos aspectos que lo diferencian de

lo que es una especificacin de un requisito, diferencias que muchas veces son poco conocidas y que

llevan a muchos equipos a dudas y confusiones.

Una historia de usuario describe funcionalidad que ser til para el usuario y/o cliente de un

sistema software. Y aunque normalmente las historias de usuario asociadas a las metodologas giles,

suelen escribirse en psit o tarjetas, son mucho ms que eso. Como se ha comentado anteriormente, una

historia no es slo una descripcin de una funcionalidad, sino tambin es de vital importancia la

conversacin que conllevan.

Las historias de usuario, frente a mostrar el cmo, slo dicen el qu. Es decir, muestran

funcionalidad que ser desarrollada, pero no cmo se desarrollar. De ah que aspectos como que el

software se escribir en Java no deben estar contenidos en una historia de usuario.

De esta manera, equiparar las historias de usuario con las especificaciones de requisitos no es

demasiado correcto ya que por definicin, las historias de usuario no deben tener el nivel de detalle que

suele tener la especificacin de un requisito

Una historia de usuario debera ser pequea, memorizable, y que pudiera ser desarrollada por un

par de programadores en una semana. Debido a su brevedad, es imposible que una historia de usuario

contenga toda la informacin necesaria para desarrollarla, en tan reducido espacio no se pueden describir

aspectos del diseo, de las pruebas, normativas, convenciones de codificacin a seguir, etc.

Para resolver el anterior problema hay que entender que el objetivo de las historias de usuario es, entre

otros, lograr la interaccin entre el equipo y el cliente o el usuario por encima de documentar

(manifiesto gil, ver leccin 1) por lo que no se deben sobrecargar de informacin. Sin embargo, la

realidad de los proyectos y de los negocios es otra y hace que la teora se deba ajustar a la prctica, por lo

que se pueden dar varias soluciones para reflejar toda esa informacin que en un primer momento parece

que no cuadra en las historias de usuario:

Relajar la agilidad usando los tradicionales requisitos en ciclos de vida gil.

Usar casos de uso en vez de historias de usuario.

Utilizar tcnicas de trazabilidad para relacionar las historias de usuario con otros documentos: de

diseo, normativas, etc.

[1]Cockburn, A. (2002). Agile software development. Boston, MA, USA. Addison-Wesley Longman

Publishing Co., Inc.

Malas interpretaciones del concepto de historia de usuario II

Las historias de usuario equivalen a casos de uso?

Otro concepto que suele crear confusin sobre las historias de usuario son los casos de uso. Aunque

hay quien ha logrado incluir casos de uso en su proceso gil, no quiere decir que las historias de usuario

sean equivalentes a los casos de uso. Realmente, como comenta Cockburn (A. Cockburn, 2002) [1], las

historias de usuario estn ms cerca de la captura de requisitos (aquella fase que sirve para extraer las

necesidades del usuario).

Bsicamente, si decamos que una historia de usuario es el qu quiere el usuario, el caso de uso es

un cmo lo quiere.

Generalmente, cuando un proyecto comience a seguir una metodologa gil, se deberan olvidar

completamente los casos de uso y el equipo debera centrarse en la realizacin de historias de usuario.

Segn Cockburn(A. Cockburn, 2008) [2], esto puede producir los siguientes problemas:

Las historias de usuario no proporcionan a los diseadores un contexto desde el que trabajar.

Pueden no tener claro cul es el objetivo en cada momento. Cundo le surgira al cliente o

usuario esta necesidad?

Las historias de usuario no proporcionan al equipo de trabajo ningn sentido de completitud. Se

puede dar el caso que el nmero de historias de usuario no deje de aumentar, lo que puede

provocar desmotivacin en el equipo. Realmente, cmo de grande es el proyecto?

Las historias de usuario no son un buen mecanismo para evaluar la dificultad del trabajo que est

an por llegar.

Por tanto, si en un proyecto ocurre alguno de estos problemas se puede barajar la posibilidad (relajando la

agilidad) de complementar las necesidades descritas en las historias de usuario con casos de uso donde

quede reflejado el comportamiento necesario para cumplir dichas necesidades.

En el caso de que se usen las historias de usuario y los casos de uso de manera complementaria, una

historia de usuario suele dar lugar a la especificacin de varios casos de uso.

[1]Cockburn, A. (2002). Agile software development. Boston, MA, USA. Addison-Wesley Longman

Publishing Co., Inc.

[2]Cockburn, A. (2008). Why I still use use cases. Disponible

en:http://alistair.cockburn.us/Why+I+still+use+use+cases

Creando buenas historias de usuario

Para asegurar la calidad de una historia de usuario, Bill Wake describi en 2003 un mtodo llamado

INVEST (Wake, 2003) [1]. El mtodo se usa para comprobar la calidad de una historia de usuario

revisando que cumpla las caractersticas descritas en la Tabla 1. Descripcin del INVEST.

Independient

(independiente)

Es importante que cada historia de usuario pueda ser planificada e

implementada en cualquier orden. Para ello deberan ser totalmente

independientes (lo cual facilita el trabajo posterior del equipo). Las

dependencias entre historias de usuario pueden reducirse

combinndolas en una o dividindolas de manera diferente.

Negotiable

(negociable) Una historia de usuario es una descripcin corta de una necesidad

que no incluye detalles. Las historias deben ser negociables ya que

sus detalles sern acordados por el cliente/usuario y el equipo

durante la fase de conversacin. Por tanto, se debe evitar una historia de usuario con demasiados detalles porque limitara la

conversacin acerca de la misma.

Valuable

(valiosa) Una historia de usuario tiene que ser valiosa para el cliente o el

usuario. Una manera de hacer una historia valiosa para el cliente o

el usuario es que la escriba l mismo.

Estimable

(estimable) Una buena historia de usuario debe ser estimada con la precisin

suficiente para ayudar al cliente o usuario a priorizar y planificar su

implementacin. La estimacin generalmente ser realizada por el

equipo de trabajo y est directamente relacionada con el tamao de

la historia de usuario (una historia de usuario de gran tamao es

ms difcil de estimar) y con el conocimiento del equipo de la

necesidad expresada (en el caso de falta de conocimiento, sern

necesarias ms fases de conversacin acerca de la misma).

Small

(pequea) Las historias de usuario deberan englobar como mucho unas pocas

semanas/persona de trabajo. Incluso hay equipos que las restringen

a das/persona. Una descripcin corta ayuda a disminuir el tamao

de una historia de usuario, facilitando su estimacin.

Testable

(comprobable) La historia de usuario debera ser capaz de ser probada (fase

confirmacin de la historia de usuario). Si el cliente o usuario no sabe como probar la historia de usuario significa que no es del todo

clara o que no es valiosa. Si el equipo no puede probar una historia

de usuario nunca sabr si la ha terminado o no.

Tabla 1. Descripcin del mtodo INVEST

[1] Wake, B. (2003). INVEST in good stories, and SMART tasks. Disponible

en:http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Asignar valor a una historia de usuario

Como se comentaba en la introduccin del tema, los tems del Product backlog, deben estar priorizados,

es decir, deben tener asignados un valor. Dicho valor es asignado por el Product Owner, y pondera

bsicamente las siguientes variables:

Beneficios de implementar una funcionalidad

Prdida o coste que demande posponer la implementacin de una funcionalidad

Riesgos de implementarla

Coherencia con los intereses del negocio

Valor diferencial con respecto a productos de la competencia

Uno de los aspectos ms importantes aqu es que la definicin de "valor" para cada cliente puede variar.

Por lo tanto es muy recomendable incluir algn tipo de escala cualitativa.

Una manera rpida de empezar a asignar valor a las historias es dividirlas en 3 grupos, segn sean

imperativas, importantes o prescindibles. Dentro de cada grupo nos resultar ms fcil realizar una

ordenacin relativa por valor numrico y despus asignarlo. Todo ello servir para que en cada iteracin

entreguemos el producto al cliente maximizando su valor.

Existen otro tipo de ponderaciones, por ejemplo la tcnica MoSCoW. Esta tcnica fue definida por

primera vez en el libro Case Method Fast-Track: A RAD Approach, en el ao 2004. Su fin es obtener el

entendimiento comn entre cliente y el equipo del proyecto sobre la importancia de cada requisito o

historia de usuario. La clasificacin es la siguiente:

M - MUST. Se debe tener la funcionalidad. En caso de que no exista la solucin a construir fallar.

S - SHOULD Se debera tener la funcionalidad. La funcionalidad es importante pero la solucin no

fallar si no existe.

C - COULD Sera conveniente tener esta funcionalidad. Es en realidad un deseo.

W - WON'T No est en los planes tener esta funcionalidad en este momento. Posteriormente puede pasar

a alguno de los estados anteriores.

Lecturas y enlaces recomendados

Cohn, M. (2004). User stories applied: For agile software development Addison-Wesley

Ejemplos y buenas prcticas de descomponer historias de usuario en tareas (1/2)

Ejemplos y buenas prcticas de descomponer historias de usuario en tareas (2/2)

Test Leccin 3

Las funciones del product owner son ...

Tener una visin muy clara del producto que se quiere realizar, poder transmitirlo al grupo de

desarrollo y gestionar la comunicacin entre equipos y el orden en el que se desarrollarn las

tareas.

Ser el Jefe de Proyecto.

No son prioritarias sus funciones, es un elemento opcional en un proyecto gil.

Qu es una historia de usuario?

Un post-it que se utiliza para escribir la especificacin de requisitos.

Una descripcin breve, de una funcionalidad software tal y como la percibe el usuario

Una descripcin de todo lo que tiene que hacer el software

Ninguna de las anteriores

Una historia de usuario es equivalente a ...

Casos de uso

Requisitos

Todas las anteriores

Ninguna de las anteriores

Una historia de usuario nos dice ...

El "qu" ser desarrollado no el "cmo" se desarrollar

El "cmo" se desarrollar una funcionalidad, no el "qu" se desarrollar

Ninguna de las anteriores

Todas las anteriores

Para asegurar la calidad de una historia de usuario, es necesario que stas tengan una descripcin

pormenorizada.

Verdadero

Falso

El tamao de una historia de usuario es ...

Grande, puede durar todo el tiempo que se quiera, incluso meses o aos.

Pequea, incluso hay equipos que las restringen a das/personas.

Ninguna de las anteriores.

Taller de historias de usuario

Explicacin de la tarea

Para terminar de entender los conceptos, y crear buenas historias de usuario, os vamos a proponer un

ejercicio colaborativo, un taller de historias de usuario como tarea P2P, el resultado del ejercicio es

elaborar un product backlog con 10 historias de usuario.

Una tarea con evaluacin entre pares (P2P) consiste en crear un documento donde incluyas la resolucin

al ejercicio que te pedimos, entregarla en la plataforma y evaluar las tareas que han hecho varios de tus

compaeros. no se considera completada la tarea si no evalas al nmero de compaeros que te pida la

plataforma, no basta con entregar tu tarea, hay que evaluar a los dems.

En este caso, tenis que crear 10 historias de usuario para el juego del Space Invaders.

Para refrescaros un poco la memoria con respecto a este juego, Space Invaders es el tpico juego de matar

marcianos, en dos dimensiones.El jugador controla un can que puede moverse a la derecha o izquierda

y disparar. El objetivo del juego es ir destruyendo los extraterrestres invasores disparando con el can,

que van acercndose a la tierra cada vez ms rpidamente a medida que el jugador va destruyendo a los

enemigos. Este ciclo se puede repetir en forma indefinida. Si los invasores llegan al can controlado por

el jugador, el juego termina.

http://www.youtube.com/watch?v=437Ld_rKM2s

Cada cierto tiempo aparece en la pantalla, por encima de los extraterrestres, un platillo volador que se

mueve aleatoriamente de derecha a izquierda o de izquierda a derecha. Si el jugador le dispara y destruye,

suma una serie de puntos aleatorios. Adems hay una fila de 4 escudos de proteccin, justo delante del

jugador, para protegerlo de los disparos aliengenas. Estos escudos son destruidos gradualmente por los

disparos de los invasores o del propio can del jugador.

Nos vamos a poner en la situacin de que empezamos de cero a crear el juego a da de hoy (no vamos a

evolucionar el space invaders existente, vamos a crear uno nuevo de cero).

Cmo entrego el ejercicio?

Paso 1 Ejercicio resuelto.Deberis incluir las 10 historias de usuario en un archivo, y adjuntarlo ms

abajo, en la seccin de Entrega tu tarea. Recomendamos que el archivo sea preferentemente en formato

pdf (para que luego tus compaeros puedan abrirlo sin problemas). En la caja de texto, puedes copiar el

mismo texto que hayas escrito en el archivo, escribir cualquier comentario, o simplemente poner un ".".

Este comentario lo leer la persona que te evale.

Paso 2 Evaluar a tus compaeros. Despus de entregar tu tarea, la pgina pasar a la fase 2 ("2.

Valora a tus compaeros"), donde te mostrar una lista de varios ejercicios de tus compaeros, y tendrs

que evaluarlos. La evaluacin consiste en leer lo que tu compaero ha escrito, y escribir una valoracin en

la caja de texto. Al contrario que cuando envas la tareas, al evaluar no es obligatorio adjuntar ningn

archivo (tienes la opcin, pero solo es una opcin y mejor si los comentarios los haces SOLO en el cuadro

de texto).

Por poneros un ejemplo, estos seran algunos de los aspectos que podras evaluar:

1. Ha incluido 10 historias de usuario?

2. Las historias de usuario siguen el formato apropiado? (p.e Como [jugador] quiero)

3. Cada historia de usuario incluye los elementos necesarios? (p.e. Estimacin, valor, ttulo,

descripcin-Ver seccin de Qu informacin contiene una historia de usuario-)

4. Est priorizada la lista de historias de usuario? Recuerda que un product backlog debera estar

priorizado (puedes ayudarte del mtodo MoSCoW)

5. Se contempla cmo validar cada historia de usuario (condiciones de satisfaccin o aceptacin)

por parte del product owner una vez completada?

6. Se cumple el mtodo INVEST?

7. Tienen demasiado texto las historias?

8. Son demasiado genricas? Recuerda que una historia debera poderse desarrollar en un Sprint o

iteracin (para este ejercicio supondremos iteraciones de 30 das y un equipo de 5 personas)

No obstante, esta parte est abierta a cualquier valoracin o recomendacin que se te pudiera ocurrir. Ten

en cuenta que este es un ejercicio abierto para que podis aprender y mejorar unos de otros J.

Paso 3 Ver las evaluaciones que han hecho tus compaeros sobre tu ejercicio. Cuando valores a

todos los compaeros, la pgina pasar a la fase 3 y te mostrar cmo han valorado tu trabajo. Es posible

que todava no te haya valorado nadie, pero puedes acceder de nuevo cuando quieras para ver las

valoraciones.

Paso 4 Fin de la tarea.Si has valorado todos los trabajos pedidos, debera aparecerte la tarea como

completada, con un "tick" verde.

ATENCIN! Es importante que hagas la valoracin de tus compaeros cuando tengas tiempo y ests

preparada/o. La asignacin de trabajos cambia CADA vez que accedes a la pgina de la tarea P2P. Es

decir, si descargas los trabajos a valorar y ests ausente de la plataforma ms de DOS HORAS, se cerrar

tu sesin. Cuando vuelvas, e introduzcas de nuevo tu usuario y contrasea, la plataforma te ofrecer

TRABAJOS DIFERENTES a los que tenas al principio; si ya los has ledo y valorado, no te habr

servido de nada porque tendrs que valorar otros diferentes para completar la actividad. Del mismo modo,

si sales de la pgina para consultar un video, por ejemplo, al volver te habr cambiado las tareas. Esto es

debido al algoritmo establecido por el equipo de MiriadaX (y no podemos cambiarlo). Si necesitas

consultar otras secciones mientras valoras, hazlo desde otra pestaa o ventana de tu navegador.

Si eres de los primeros en subir tareas, la plataforma no podr asignarte tareas de otras personas para

valorar. Vuelve uno o dos das despus y ya podrs completar esta fase.

Leccin 4: Scrum

https://www.youtube.com/watch?v=KA9A9eRXhLo

Scrum es una metodologa gil que proporciona un marco para la gestin de proyectos. Podramos decir

que hoy en da es la metodologa gil ms popular, y, de hecho, se ha utilizado para desarrollar productos

software desde principios de la dcada de los 90.

El conjunto de buenas prcticas de Scrum se aplica esencialmente a la gestin de proyectos.

Por otro lado, aunque normalmente hablamos de la metodologa Scrum, lo correcto sera decir el

framework Scrum, porque realmente es un conjunto de buenas prcticas que necesita su adaptacin en

cada organizacin, o, incluso, a cada equipo. [1].

https://www.youtube.com/watch?v=GGVrxFlfbZA

Como se indica en la Scrum Guide [1] , existen tres pilares en los que se basa:

Transparencia: todos los aspectos del proceso que afectan al resultado son visibles para todos

aquellos que administran dicho resultado. Por ejemplo, se utilizan pizarras y otros mecanismos o

tcnicas colaborativas para mejorar la comunicacin.

Inspeccin: se debe controlar con la frecuencia suficiente los diversos aspectos del proceso para

que puedan detectarse variaciones inaceptables en el mismo.

Revisin: el producto debe estar dentro de los lmites aceptables. En caso de desviacin se

proceder a una adaptacin del proceso y el material procesado.

Puedes ver una entrevista que realic a Sthuerland aqu.

[1] Schwaber, K., & Sutherland, J. (2013). Scrum guide. Disponible en:https://www.scrum.org/Scrum-

Guides

El equipo en Scrum

Uno de los aspectos ms importantes en cualquier proyecto, y tambin en los proyectos giles, es el

establecimiento del equipo. Los roles y responsabilidades deben ser claros y conocidos por todos los

integrantes del mismo.

Infografas de los roles de Scrum:

Infografa del Product Owner

Infografa del Scrum Master

Cada equipo Scrum tiene tres roles:

Scrum Master: es el responsable de asegurar que el equipo Scrum siga las prcticas de Scrum.

Sus principales funciones son:

Ayuda a que el equipo Scrum y la organizacin adopten Scrum.

Liderar el equipo Scrum, buscando la mejora en la productividad y calidad de los

entregables.

Ayudar a la autogestin del equipo.

Gestiona e intenta resolver los impedimentos con los que el equipo se encuentra para

cumplir con las tareas del proyecto.

Propietario del Producto (ProductOwner): es la persona responsable de gestionar las

necesidades que sern satisfechas por el proyecto y asegurar el valor del trabajo que el equipo

lleva a cabo. Su aportacin al equipo se basa en:

Recolectar las necesidades o historias de usuario.

Gestionar y ordenar las necesidades (representadas por las historias de usuario,descritas

en la leccin 2 ).

Aceptar el producto software al finalizar cada iteracin.

Maximizar el retorno de inversin del proyecto.

Equipo de desarrollo: El equipo est formado por los desarrolladores, que convertirn las

necesidades del ProductOwner en un conjunto de nuevas funcionalidades, modificaciones o

incrementos del producto software final. El equipo de desarrollo tiene caractersticas especiales:

Auto-gestionado: el mismo equipo supervisa su trabajo. En Scrum se potenciarn las

reuniones del equipo (aqu tienes un post sobre ese tema), aumentando la comunicacin.

No existe el rol clsico de jefe de proyecto. El Scrum Master tiene otras

responsabilidades vistas en el apartado anterior.

Multifuncional: no existen compartimientos estancos o especialistas, cada integrante del

equipo puede encargarse de tareas de programacin, pruebas, despliegue, etc. Asimismo

las personas pueden tener capacidades diferentes o conocimientos ms profundos en

diferentes reas. Lo importante es que cualquier integrante del equipo sea capaz de

realizar cualquier funcin.

No distribuidos: es conveniente que el equipo se encuentre en el mismo lugar fsico.

Esto facilita la comunicacin y la autogestin que nace del mismo equipo.No obstante se

ha conseguido realizar proyectos Scrum con equipos distribuidos gracias a herramientas

de trabajo colaborativo (Hossain et al., 2009) [1].

Tamao ptimo: un equipo de desarrollo Scrum (sin tener en cuenta al Product Owner y

al Scrum Master) estara compuesto por al menos tres personas. Con menos de tres

personas al interaccin decae y con ella la productividad del equipo. Como lmite

superior, con ms de nueve personas la interaccin hace que la autogestin sea muy

difcil de alcanzar.

[1] Hossain, E., Babar, M. A., & Hye-young Paik. (2009). Using scrum in global software development:

A systematic literature review. Artculo presentado en Fourth IEEE International Conference on Global

Software Engineering, 2009. pp. 175

El Product Backlog

https://www.youtube.com/watch?v=OEurlA_3xq0

La pila de producto o Product Backlog (utilizaremos las palabras en ingls al ser la forma ms utilizada

en los proyectos) en Scrum es uno de los elementos fundamentales. A partir del Product Backlog se

logra tener una nica visin durante todo el proyecto. Y, por lo tanto, los fallos en el Product Backlog

repercutirn profundamente en el proyecto.

El Product Backlog consiste en un listado de historias del usuario que se incorporarn al producto

software a partir de incrementos sucesivos. Es decir, sera similar a un listado de requisitos de usuario

y representa lo que el cliente espera. Una de las principales diferencias respecto de un proceso

tradicional es la evolucin continua del Product Backlog, buscando aumentar el valor del producto

software desde el punto de vista del negocio.

Para ello, este listado estar ordenado. Aunque no existe un criterio preestablecido en Scrum para

ordenar las historias de usuario, el ms aceptado es partir del valor que aporta al negocio la

implementacin de la historia de usuario. El responsable de ordenar el Product Backlog es el

Product Owner, aunque tambin puede ser ayudado o recibir asesoramiento de otros roles como, por

ejemplo, el Scrum Master y el equipo de desarrollo.

Tal y como se describe en (Pichler, 2010) [1] un Product Backlog cuenta, esencialmente, con cuatro

cualidades: debe estar detallado de manera adecuada, estimado, emergente y priorizado:

Detallado adecuadamente: el grado de detalle depender de la prioridad. Las historias de

usuario que tengan una mayor prioridad se describen con ms detalle. De esta manera las

siguientes funcionalidades a ser implementadas se encuentran descritas correctamente y son

viables. Como consecuencia de esto, las necesidades se descubren, se descomponen, y

perfeccionan a lo largo de todo el proyecto.

Estimado: las estimaciones a menudo se expresan en das ideales o en trminos abstractos. Saber

el tamao de los elementos del Product Backlog ayuda a darle prioridad y a planificar los

siguientes pasos. Una de las tcnicas que se pueden emplear para estimar las historias de usuario

es el Planning Poker, que veremos en la Leccin 4.

https://www.youtube.com/watch?v=6aeTlbOeVmI

Emergente: las necesidades se van desarrollando y sus contenidos cambian con frecuencia. Los

nuevos elementos se descubren y se agregan a la lista teniendo en cuenta los comentarios de los

clientes y usuarios. As mismo, otros elementos podrn ser modificados o eliminados.

Priorizado: los elementos del Product Backlog se priorizan. Los elementos ms importantes y de

mayor prioridad aparecen en la parte superior de la lista. Puede no ser necesario priorizar todos

los elementos en un primer momento, sin embargo s es conveniente identificar los 15-20

elementos ms prioritarios.

Puedes leer ms sobre el product backlog aqu.

[1] Pichler, R. (2010). Agile product management with scrum: Creating products that customers love

Addison-Wesley Professional.

El Sprint

Como hemos visto anteriormente, una de las bases de los proyectos giles es el desarrollo mediante las

iteraciones incrementales. En Scrum a cada iteracin se le denomina Sprint. Scrum recomienda

iteraciones cortas, por lo que cada Sprint durar entre 1 y 4 semanas. Y como resultado se crear un

producto software potencialmente entregable, un prototipo operativo. Las caractersticas que van a

implementarse en el Sprint provienen del Product Backlog.

El equipo de desarrollo selecciona las historias de usuario que se van a desarrollar en el Sprint

conformando la pila de Sprint (Sprint Backlog). La definicin de cmo descomponer, analizar o

desarrollar este Sprint Backlog queda a criterio del equipo de desarrollo.

https://www.youtube.com/watch?v=paZkbQwZpCY

Importante: Aunque todos los Sprints dan como resultado un incremento del producto software, no todos

implican un paso a produccin. Es responsabilidad del ProductOwner y los clientes decidir el momento en

el que los incrementos son puestos en produccin.

Una posibilidad para realizar la puesta en produccin es con los denominados "Sprints de Release". Estos

Sprints contendrn, en general, tareas solamente relacionadas con el despliegue, instalacin y puesta en

produccin del sistema. Es decir, no existen tareas donde se agreguen nueva funcionalidad.

http://www.youtube.com/watch?v=sfWfHPsHm6o&feature=youtu.be

Adems, el equipo de desarrollo deber estimar el esfuerzo que nos llevarn las tareas del Sprint Backlog

(un mtodo de estimacin muy usado en Scrum y que veremos ms adelante es el Planning Poker,

descrito en la leccin 4 ).

Importante: En Scrum el Sprint Backlog indica solamente lo que el equipo realizar durante la iteracin.

El ProductBacklog, por el contrario, es una lista de caractersticas que el ProductOwner quiere que se

realicen en futuros Sprints.

El Product Owner puede visualizar, pero no puede modificar el Sprint Backlog. En cambio, puede

modificar el ProductBacklog cuantas veces quiera con la nica restriccin de que los cambios tendrn

efecto una vez finalizado el Sprint.

Para mejorar la gestin de las historias de usuario y las tareas de cada Sprint usualmente se utilizan

pizarras u otros mecanismos que brinden informacin inmediata al equipo. En el siguiente video puedes

ver un ejemplo de lo que podra ser un tablero Scrum en un proyecto real.

Impresionante, tablero Scrum en pizarra que actualiza automticamente un Jira. Pdeselo a los Reyes

Reuniones

Las reuniones son un pilar importante dentro de Scrum. Se realizan a lo largo de todo el Sprint como

muestra la Figura 4, representadas en los cuadros con color gris. Se definen diversos tipos de reuniones:

Reunin de planificacin del Sprint (Sprint Planning Meeting): se lleva a cabo al principio de

cada Sprint, definiendo en ella que se va a realizar en ese Sprint. Esta reunin da lugar al Sprint

Backlog. En esta reunin participan todos los roles. El Product Owner presenta el conjunto de

historias de usuario en el ProductBacklog y el equipo de desarrollo selecciona las historias de

usuario sobre las que se trabajar. La duracin de la reunin no debe ser mayor de 8 horas y como

resultado de la misma el equipo de desarrollo hace una previsin del trabajo que ser completada

durante el Sprint.

https://www.youtube.com/watch?v=QQcKjsk9_gg

Reunin diaria (Daily Scrum): es una reunin diaria de no ms de 15 minutos en la que

participan el equipo de desarrollo y el Scrum Master. En esta reunin cada miembro del equipo

presenta lo que hizo el da anterior, lo que va a hacer hoy y los impedimentos que se ha

encontrado.

https://www.youtube.com/watch?v=pfQeF4OGOdU

Reunin de revisin del Sprint (Sprint Review Meeting): se realiza al final del Sprint.

Participan el equipo de desarrollo, el Scrum Master y el Product Owner. Durante la misma se

indica qu ha podido completarse y qu no, presentando el trabajo realizado al Product Owner.

Por su parte el Product Owner (y dems interesados) verifican el incremento del producto y

obtienen informacin necesaria para actualizar el Product Backlog con nuevas historias de

usuario. No debe durar ms de 4 horas.

Retrospectiva del Sprint (Sprint Retrospective): tambin al final del Sprint (aunque puede que

no se realice al final de todos los Sprints), sirve para que los integrantes del equipo Scrum y el

Scrum Master den sus impresiones sobre el Sprint que acaba de terminar. Se utiliza para la

mejora del proceso y normalmente se trabaja con dos columnas, con los aspectos positivos y

negativos del Sprint. Esta reunin no debera durar ms de 4 horas.

https://www.youtube.com/watch?v=WwHZwBWIvM8

Medir el progreso del proyecto

En el caso de las prcticas giles y en particular de Scrum uno de los mecanismos ms utilizados es el

grfico BurnDown [1].

Este grfico representa el trabajo que queda por hacer en un Sprint en funcin del tiempo y compara

el progreso real del Sprint con su planificacin inicial, facilitando las labores de seguimiento del

mismo.

https://www.youtube.com/watch?v=IU1-ZLk5fQQ

[1] Sutherland, J. (2001). Agile can scale: Inventing and reinventing scrum in five companies.14(12)

Acordar una buena definicin de "done"

Por lo general, la gente que empieza a implantar agilidad, o los que lo han intentado pero no con mucho

xito, suelen tener en comn el pasar por alto un grupo de aspectos que son de los ms importantes: los

que definen las relaciones y compromisos entre los diferentes roles que participan en el desarrollo

software.

Todo el mundo es consciente y se preocupa por establecer iteraciones, Sprint, prototipos, historias de

usuario, etc. Pero hay otros aspectos en un proyecto gil igualmente importantes, como son los de

compromiso, por ejemplo, que todo el mundo tenga claros los roles y responsabilidades de todo el mundo,

que al comenzar un Sprint el product owner deje clara la