View
41
Download
10
Category
Preview:
DESCRIPTION
Apuntes de Agilidad y Lean
Citation preview
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
Recommended