Documente Academic
Documente Profesional
Documente Cultură
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)
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
Consultores
Personal de gerencia media y tcnica del rea de TI.
Modalidad de evaluacin
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
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).
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.
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.
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.
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.
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.
[1]El trmino metodologa es utilizado de manera coloquial, siendo rigurosos las metodologas son ms
bien marcos de trabajo o frameworks.
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.
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
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.
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.
% de disponibilidad para el
proyecto
100 %
40 %
20 %
20 %
40 %
10 %
60 %
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.
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.
tiempo
-15%
+100%
-10%
+50%
-5%
+25%
Tiempo ideal
0%
+10%
-30%
+20%
-50%
+30%
-65%
Not practical
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.
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
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.
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.
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
[1]Cockburn, A. (2002). Agile software development. Boston, MA, USA. Addison-Wesley Longman
Publishing Co., Inc.
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
Valuable
(valiosa)
Estimable
(estimable)
Small
(pequea)
[1] Wake, B. (2003). INVEST in good stories, and SMART tasks. Disponible
en:http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
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.
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
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).
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.
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:
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:
[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:
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.
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 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
[1] Sutherland, J. (2001). Agile can scale: Inventing and reinventing scrum in five companies.14(12)
Beneficios de Scrum
Para ayudarte a la hora de implantar Scrum y la agilidad en tu empresa, te dejo un mapa de ideas clave
que debes tener en cuenta.
Mapa mental de buenas prcticas y claves a la hora de implantar Scrum y agilidad
La implantacin de las metodologas giles, y, por lo tanto, de los principios giles, aporta una serie de
beneficios como el aumento de la transparencia a lo largo de la gestin del proyecto, la mejora de la
comunicacin y la autogestin del equipo de desarrollo. As mismo, existen otras ventajas que se obtienen
al utilizar Scrum.
Entregas parciales (time to market). El cliente puede utilizar las primeras funcionalidades de
la aplicacin software que se est construyendo antes de que est finalizada por completo. Por
tanto, el cliente puede empezar antes a recuperar su inversin. Por ejemplo, puede utilizar un
producto al que slo le faltan caractersticas poco relevantes, puede introducir en el mercado un
producto antes que su competidor, puede hacer frente a nuevas peticiones de clientes, etc.
Flexibilidad y adaptacin respecto a las necesidades del cliente. De manera regular el Product
Owner redirige el proyecto en funcin de sus nuevas prioridades, de los cambios en el mercado,
de los requisitos completados que le permiten entender mejor el producto, de la velocidad real de
desarrollo, etc. Al final de cada iteracin el Product Owner puede aprovechar la parte de producto
completada hasta ese momento para hacer pruebas de concepto con usuarios o consumidores y
tomar decisiones en funcin del resultado obtenido.
Animacin de despedida
https://www.youtube.com/watch?v=43IZRmJeMwI
Gua Scrum
Mapa mental de buenas prcticas y claves a la hora de implantar Scrum y agilidad
Scrum para Dummies (1/2). Las ideas de Scrum en 2 post de 5 min.
Test Leccin 4
Seleccione la opcin correcta sobre Scrum:
Se adapta de forma temprana a los cambios de requisitos.
Est especialmente indicado para proyectos sin cambio en los requisitos.
No se tiene en cuenta el valor aportado al cliente.
Elegir la afirmacin correcta:
No pueden existir dependencias entre historias de usuario.
Para mejorar la creatividad del equipo es necesario evitar la realizacin de estimaciones.
El valor lo da el Product Owner.
El Scrum Master es el jefe de equipo y todos los dems miembros han de rendirle cuentas.
Verdadero.
Falso.
...lo cual dificulta la gestin y evolucin del proyecto. Las prcticas giles no escapan a este problema y
de hecho, por estar asociadas a requisitos cambiantes el desafo es mayor.
La mayora de los errores que se producen con ms frecuencia en los proyectos software estn
relacionados con aspectos de estimacin. Entre estos errores se pueden destacar:
Expectativas no realistas: muchas veces las tareas sobre las que se ha estimado son ambiguas.
Posteriormente el equipo seguramente se llega a un consenso comn pero el cliente puede
mantener otra expectativa. Y presionar para obtener el resultado que l cree es el correcto.
Confundir estimaciones con objetivos: al estimar tenemos que tener en cuenta nuestra
capacidad actual real y el histrico de productividad de la empresa. Es decir, si queremos
terminar en 3 meses (un objetivo) puede que lo consigamos o no sabiendo que contamos con 2
programadores y que el 20% del tiempo estamos respondiendo incidencias de otros proyectos.
Omisin de estimar tareas necesarias: las pruebas, la documentacin, las tareas relacionadas
con la gestin de configuracin o la calidad puede que no se planifiquen. Pero muchas veces
consumen tiempo.
Seleccionar una historia de las ms pequeas y asignarle 1 punto historia. Esta historia de
usuario con 1 punto historia har de unidad, y al resto se le asignarn puntos historia en funcin
de su complejidad respecto a sta.
Seleccionar una historia de tamao medio y asignarle un nmero en la mitad del rango de
puntos historia a utilizar. Normalmente, se usan rangos de puntos historia entre 1-10. Segn
esto, buscaramos una historia de tamao medio y le asignaramos cinco puntos historia. Cada
historia adicional se calcula comparndola con la primera historia.
Planning Poker
Una vez elegidas las funcionalidades a realizarse en un Sprint, de acuerdo con lo priorizado por el
cliente, es necesario realizar una estimacin ms detallada, utilizando por ejemplo, la tcnica de
Planning Poker.
El Planning Poker es una tcnica que se utiliza para asignar los puntos historia a las historias de
usuario. Esta tcnica recibe el nombre de Planning Poker ya que cada una de las personas implicadas en
el proceso de estimacin toma un mazo de cartas que suelen estar numeradas con alguna de las secuencias
que vimos antes (por ejemplo la de Fibonacci).
La tcnica de Planning Poker est basada en el consenso y es utilizada para estimar el esfuerzo o el
tamao relativo de las tareas de desarrollo de software. Est muy arraigado en las tcnicas giles por su
sencillez, facilidad y bajo coste. No es una prctica de Scrum pero se suele utilizar con esta metodologa
gil.
Los pasos a seguir en el Planning Poker son los siguientes:
1. Se presentan las historias de usuario a estimar uno por uno haciendo una descripcin de los mismos.
Y se procede a discutir aquellos detalles ms relevantes o que no hayan quedado claros. Suele darse un
tiempo mximo de discusin para mejorar la productividad.
2. Tras este perodo de discusin cada una de las personas implicadas en el proceso de estimacin toma
un mazo de cartas (que estn numeradas segn la serie de Fibonacci, como objetivo de reflejar la
incertidumbre inherente en la estimacin). De ah escoge la carta que representa su estimacin del
trabajo que implica implementar el requisito que se est discutiendo. Las estimaciones son privadas.
3. Las unidades utilizadas pueden ser variadas y deben estar definidas previamente. Pueden ser das
reales, das ideales o puntos de la historia. Como consenso se denominan puntos de poker. La diferencia
entre das ideales y reales est en la cantidad de horas a tener en cuenta. En los proyectos en los que se
suceden muchas interrupciones es conveniente estimar en das reales (o incluso en horas).
4. Finalmente se publican todas las estimaciones, es decir, cada integrante del equipo muestra a la vez
la carta seleccionada (esto es as para evitar que las estimaciones de unos modifiquen las de otros). Si
existe una gran dispersin entre las estimaciones (unos dicen 2, otros 21) se vuelve al discutir el requisito
y se vuelve a realizar el proceso de estimacin.
5. Generalmente la dispersin en las estimaciones es sntoma de que la informacin que manejan parte
de los involucrados en el proceso de estimacin no es completa o exacta. La segunda ronda de discusin
permite aclarar aquellos puntos poco claros, diferencias de criterio y desvelar informacin que pueda no
ser obvia sobre el requisito. En la siguiente ronda de estimacin la dispersin de las estimaciones ser
mucho menor y se podr llegar fcilmente a un consenso.
Usando Planning Poker es fcil estimar las historias de usuario de una manera gil y rpida
combinando la analoga y el juicio experto a un entorno grupal democrtico. Nos lleva a
estimaciones respaldadas por todos los involucrados y basadas en consensos.
Planning Poker II
A continuacin plantearemos un ejemplo ms complejo de estimacin con Planning Poker.
Supongamos que en la prxima iteracin debemos implementar 3 historias de usuario. Nuestro equipo
est formado por 4 desarrolladores: D1, D2, D3 y D4. La unidad que usaremos sern los Puntos Poker.
Se presenta el siguiente histrico de estimaciones:
Importante: Este modo dinmico de estimacin hace participar a todos los asistentes,reduce el
tiempo de estimacin de una funcionalidad, y lo ms importante, se consigue alcanzar una
convergencia en la estimacin de las historias de usuario.
Peligros al estimar
Al realizar estimaciones teniendo en cuenta jornadas de trabajo es necesario recordar lo siguiente: los das
son "ideales". stos son aquellos en los que se cumplen las horas de trabajo definidas sin interrupciones,
interferencias o distracciones de ningn tipo.
Entre un 25% y 35% del tiempo se invertirn en otras actividades (imprevistos, llamadas, correo,
etc.). Asimismo es bueno recordar que el trabajo se expande hasta ocupar todo el tiempo del que se
dispona para su realizacin.
Estos dos aspectos significan que si realizamos una estimacin por arriba (es decir que indicamos 3 das
a una tarea que se realiza en 2 das) por lo general los equipos van a utilizar todo el tiempo del que
disponen. Y si estimamos por debajo (decimos 3 das reales para una tarea de 3 das ideales) tendremos
retrasos.
La velocidad
La velocidad es la cantidad de trabajo que un equipo puede hacer en una iteracin. En el inicio de la
iteracin el equipo estima el trabajo que ser medido tomando un sistema de referencia de puntos,
llamados puntos de sistema. stos sern arbitrarios, y pueden tomar numerosas unidades: historias de
usuario, tareas tcnicas, etc.
http://youtu.be/X66vfjW0yWI
realizado nuestro equipo en las iteraciones de un proyecto. En el eje vertical se encuentra la cantidad de
puntos historia desarrollados. En el eje horizontal se indican los proyectos realizados.
Antes del inicio de una estimacin: para que el equipo conozca su capacidad
Despus de realizar la estimacin: para que se controle que tan bien o mal se ha realizado la
estimacin.
Importante: Hemos dicho que las estimaciones suelen ser optimistas. Por lo tanto, una vez se van
afianzando las tcnicas de estimacin la estimacin por debajo disminuye.
De esta manera, como puede verse en el grfico, al inicio del proyecto las estimaciones suelen ser
dispersas e imprecisas. Sin embargo, segn avanza el proyecto, a travs del histrico, la introduccin
de nuevas prcticas de estimacin y la experiencia conseguida en las mismas se tiende a una mejora en
las estimaciones futuras.
En cualquier caso, no olvides que cuando hablamos de velocidad hacemos referencia a una media. Si
necesitas hacer estudios ms profundos sobre la velocidad de un equipo, o comparar ms fielmente a
dos equipos segn su velocidad, etc., deberas acompaar la velocidad media de otros valores, por
ejemplo, la desviacin tpica.
La frecuencia con la que hay que mostrar el software a los usuarios. Normalmente, el
software se puede mostrar al final de una iteracin (demos de prototipos), por lo que a mayor
frecuencia requerida para mostrar demos y avance, menor debiera ser la duracin de la iteracin.
En lnea con el anterior, debiramos pensar con qu frecuencia hay que medir, o mostrar, el
progreso del proyecto. En teora slo al final de una iteracin podemos medir con precisin la
cantidad de trabajo que realmente ha sido completado.
La frecuencia con la que se pueden reajustar objetivos del proyecto. No debiramos hacer
cambios de objetivo, funcionalidad, o alcance, una vez que ha comenzado una iteracin. Los
ajustes y cambios deben esperar hasta el momento en que una iteracin termina. Por ello, si se
requiere mayor ratio de cambio de alcance, menor debiera ser la duracin de la iteracin. Por lo
tanto, el tiempo que se puede aguantar sin cambios de prioridad es un factor determinante a la
hora de fijar la temporalidad de una iteracin.
Con todo, por ejemplo, si tenemos cuatro meses de proyecto, y nuestras iteraciones son de un mes de
duracin, tendremos tres momentos (al final de la iteracin 1, 2 y 3) para tomar feedback, medir
progreso y re-ajustar prioridades.
Otra consideracin clave es el tiempo que tarda una idea (un requisito funcional, una historia de
usuario) en transformarse en software. Por ejemplo, consideremos de nuevo iteraciones de cuatro
semanas. Suponiendo que una nueva idea aparece en el medio de una iteracin, esa idea solo puede
introducirse en la prxima versin, que comenzar en dos semanas. Dos semanas que quedan de la
iteracin en que aparece el nuevo requisito, ms cuatro de la siguiente, hacen que la nueva idea est
implementada en 6 semanas, y si 6 semanas es mucho para nuestro negocio... habr que considerar
iteraciones menores.
Una ltima consideracin. No olvides que a menor tiempo de iteracin mayor nivel y sofisticacin
debe tener el equipo de desarrollo, por lo que la madurez, compenetracin, experiencia, cualidades
tcnicas, etc., juegan un papel importante.
A iteraciones ms cortas, hars ms entregas, con mayor frecuencia, y menor ser la desviacin
respecto a lo que el usuario espera.
Test Leccin 5
Entre los errores clsicos del desarrollo software que provocan un mayor impacto y que estn
relacionados con aspectos de estimacin se encuentran:
Omisin de estimar tareas necesarias y falta de implicacin.
Expectativas no realistas y calendario demasiado optimista.
Verdadero o Falso: Las tcnicas de estimacin sustituyen al juicio experto.
Falso, lo complementa.
Verdadero.
A quin pertenece la funcin de asignar valor a las historias de usuario?
Equipo de desarrollo.
Product Owner.
Jefe de proyecto.
A priori, qu historias de usuario sern las que primero se tengan en cuenta para llevarlas al
Sprint Backlog?
Las que aporten menos valor para el cliente y adems se necesite mucho tiempo para llevarlas a
cabo
Las historias de usuario que menos tiempo necesitemos para llevarlas a cabo, porque as
podremos implementar ms tareas en una misma iteracin.
Las que aporten mayor valor para el cliente.
Seleccione la opcin INCORRECTA:
Antes de publicar la estimacin se puede compartir con otros compaeros con el fin de no
desviarse.
El planning poker es una manera fcil de estimar las historias de usuario de una forma
democrtica, gil y rpida.
Los puntos de poker son unidades ficticias definidas previamente. Pueden ser das de duracin,
das ideales o puntos de historia.
Qu puede generar la falta de compromiso con la estimacin?
Estimacin por debajo.
Estimacin por arriba
Buena estimacin
Cunto tiempo debera durar una iteracin?
1 semana
1 mes
Lo que se suele encontrar es que las iteraciones de los proyectos duran entre una semana y un
mes, pero esto depende del tipo de proyecto y del equipo
Lean Startup
Relacionado con esto, Eric Ries en su libro The Lean Startup, propone utilizar Lean, en vez de para
desarrollar software (tema que se explicar en las siguientes secciones), para crear empresas y negocios.
La metodologa que propone Eric Ries se basa en enfocar la creacin de la empresa en la mxima y ms
frecuente interaccin con los posibles clientes. Es decir, que en vez de hacer un gran plan de negocio y
terminar un producto mucho tiempo despus (algo as como un ciclo de vida en cascada), con el riesgo de
haber invertido mucho en algo que no vale para nada, cntrate en sacar rpidamente pequeos prototipos
del negocio, aunque no estn totalmente terminados, y valdalos con usuarios reales (iterativo,
incremental gil.
El libro se centra en que el conocimiento vlido es aquel que obtenemos probando cosas en la realidad,es
el que realmente nos ayuda a tomar decisiones. Esfuerzo que no nos sirva para aprender e ir ajustndose a
las necesidades de los futuros clientes es un gasto intil.
La propuesta del Lean Startup es aplicar un ciclo de construir medir aprender, iterar constantemente
para ir ajustando y aprendiendo. Cada iteracin o bucle debe terminar con un MVP (Minimum Viable
Product), un producto mnimo, y que recuerda tanto al prototipado de un ciclo de vida iterativo gil. Todo
orientado a aprender rpidamente el qu quiere el cliente con el mnimo desperdicio (o esfuerzo en cosas
que no van a servir).
Para saber ms sobre el Lean Startup te dejo este vdeo:
https://www.youtube.com/watch?v=fEvKo90qBns
que escribieran el libro que ha inspirado las ideas del Lean aplicado al desarrollo software (Lean Software
Development).
Una paradoja ms: aunque la filosofa gil rechaza que el proceso de desarrollo software sea un proceso
de fabricacin industrial tradicional (como el que sucede al construir un coche o una casa)los agilitistas
han tenido una gran influencia y adopcin de los mtodos de fabricacin de Toyota.
Hoy agilidad y lean han llegado casi a ser sinnimos. Los principios giles son compatibles con los
principios lean. Sin embargo, los principios lean son de mayor alcance, aplican a la hora de seleccionar
prcticas de desarrollo apropiadas a otras situaciones, ms all del desarrollo software, y ms all de los
entornos en los que la agilidad funciona bien.
A continuacin te enumero las principales diferencias entre agilidad y lean:
1 El lean software development se ve al desarrollo software como un paso dentro de un flujo
global, un paso dentro de un todo. Lean no slo trata el desarrollo, trata hasta la puesta, y xito,
en el mercado del producto.
2 En lean no hay product owner o roles de cliente, tpicos del desarrollo gil.
3 En lean existen figuras cercanas a jefes de proyecto o product managers. En el lean
software development los equipos estn dirigidos por alguien que ocupa el rol de ingeniero jefe
(como se llamaba en Toyota), el gerente de programas o program manager (Microsoft), o
product champion (3M).
4 Otra diferencia entre agilidad y lean es que en lean no hay un rol que priorice el trabajo del
equipo de desarrollo, como suele suceder en las metodologas giles. Los mtodos giles suelen
proponer al cliente o representante del cliente (product owner) que priorice el trabajo del equipo
software.
5 Muchas veces respecto a las metodologas giles existen interrogantes sobre cmo hacer
frente al diseo. Las iteraciones hacen complejo este punto. Dado que el desarrollo lean
establece una serie de principios que exigen tratar al producto como un todo, un ciclo de
vida completo, enfoque multifuncional, ponen ms nfasis en cmo organizar una combinacin
de diseo, desarrollo, implementacin y la validacin.
Desperdicios de Lean I
El Lean, y el Lean Software Development (como ya vimos), se centra en la eliminacin continua de
desperdicios, los desperdicios del lean software son todo aquello que no aporta valor y que ocurre tanto
en todo proyecto.
Aunque el Lean se ha aplicado histricamente a la industria, ha sido en los ltimos aos cuando se ha
adaptado al software, donde las cosas no son exactamente iguales (recuerda aquello de que fabricar
software no es lo mismo que fabricar coches o casas). Y en esta seccin vamos a ver los desperdicios del
lean software, desperdicios reales de da a da de un proyecto software.
Ya veris que los desperdicios del lean software pueden aplicar a tu da a da, a cualquier cosa que
hagas en tu vida, desde estudiar para un examen, a mantener un blog, a mejorar tu vida social.
Hay 7 tpicos desperdicios del lean software (segn los clasificaron Mary and Tom Poppendieck en el
mejor libro que hay sobre el tema):
Aquella documentacin que tardamos meses en elaborar pero que qued sin codificar (esto me recuerda a
mis tiempos haciendo diseos UML al detalle y que luego al chocar con la realidad no los seguamos).
Los requisitos, y las historias de usuario obsoletas.
Ese cdigo en el PC de un desarrollador durante mucho tiempo, tanto que integrarlo ya es complicadsimo
es un desperdicio. O esas ramas de cdigo en la herramienta de control de versiones que viven durante
meses antes de mergearse con la lnea principal, desperdicio.
O el cdigo no probado: sin pruebas, no hay manera de saber que el cdigo funciona (ni con pruebas
tenemos seguridad, pues imagnate sin ellas).
Aquello que creemos que el cliente va a necesitar pero que cliente no ha pedido. Cuando un comercial,
cliente, etc., insiste en incluir cosas en el producto,que al final no se usan tenemos un enorme
desperdicio. La funcionalidad que ha quedado obsoleta es un desperdicio.
Y no olvidis que las caractersticas introducidas slo para probar la ltima moda y esa tecnologa
moderna acaban siendo un desperdicio.
Cuntas veces has resuelto un problema y no has implantado inmediatamente la solucin? Cuntas
veces has tenido que redescubrir semanas despus la misma solucin? Desperdicio de tiempo, otro de los
desperdicios del lean software.
Por otro lado, muchas veces no preguntamos, ni hacemos caso a expertos, y trabajamos en solitario. Cada
minuto que pasamos redescubriendo cosas que rpidamente nos podran haber contado es tiempo
perdido.
Y tambin est el cdigo mal escrito o indocumentado que conduce a una incalculable cantidad de
reaprendizaje, desperdiciando tiempo.
Por ltimo, otro clsico y repetido desperdicio: desarrolladores que estn constantemente siendo
reasignados a funciones diferentes, dejando sin terminar su trabajo actual.
Desperdicios de Lean II
Desperdicios del lean software 4: De mano en mano
Documentos de anlisis de requisitos, que luego pasan a las manos de un diseador. El diseador
elabora un diseo y entonces pasa a manos de los programadores. O lo que viene a ser el ciclo de vida
en cascada. Por desgracia, poco conocimiento puede transmitirse SOLO con documentos y
diagramas, por lo que mucho papel acaba siendo un desperdicio.
Desperdicios del lean software 5: Las pausas
Empezar a trabajar en el desarrollo de un proyecto mucho tiempo despus del contacto inicial con el
cliente. Esperar a que el equipo est disponible para empezar a trabajar. Esas largas fases de
documentacin de requisitos (esto tambin me recuerda a mis tiempos haciendo diseos UML al
detalle) que tratan de especificar de forma exhaustiva todos los aspectos de un proyecto.
Y no slo eso, la revisin o aprobacin de procesos que actan como puertas entre fases y que requieren
de un individuo apenas disponible.
Desperdicios del lean software 6: Cambio de Tarea
El coste de cambiar de tarea durante el desarrollo de software ha sido un problema de siempre.Tom
DeMarco y Timothy Lister ya lo trataban en su libro Peopleware (muy recomendable, por cierto).
Desgraciadamente, concentrarse es extremadamente difcil. De esto hay mucho escrito, pero se dice que
necesitamos por lo menos quince minutos para concentrarnos en algo. Y durante esos quince minutos,
estar concentrndose. Una vez concentrado, cualquier interrupcin nos obliga a empezar de nuevo, lo
que cuesta otros quince minutos de tiempo improductivo. Cuatro interrupciones cuestan una hora de
productividad. Treinta y dos interrupciones un da.
Desperdicios del lean software 7: Defectos
Por ltimo, quizs uno de los ms obvios: los defectos. Todo aquello que no se hace bien, es un
desperdicio, no aporta valor, y consume tiempo a la hora de repararlo.
Kanban
Kanban es una palabra japonesa que significa tarjetas visuales (kan significa visual, y ban tarjeta).
Esta tcnica se cre en Toyota, y se utiliza para controlar el avance del trabajo, en el contexto de
una lnea de produccin. Actualmente est siendo aplicado en la gestin de proyectos software.
https://www.youtube.com/watch?v=uGKHBHzG0jM
A su vez hay una regla 0 o inicial: el trabajo que se gestione estar dividido en bloques o tareas
pequeas. Como ejemplos de bloques o tems a gestionar tenemos: los requisitos, las historias de
usuario, una funcionalidad a ser desarrollada, etc.
Nota: una de las publicaciones ms interesantes al respecto es el libro: Kanban and Scrum - making the
most of both de Henrik Kniberg, Mattias Skarin.
Todo ello ayudar en la gestin del desarrollo ya que, entre otras cosas, mostrar los cuellos de
botella, colas, variabilidad y prdidas de eficiencia. Esto lo veremos ms adelante.
El primer paso que debemos hacer es dividir las historias de usuario en tareas de un tiempo
homogneo:
Para formar el Sprint Backlog y simplificar el problema, supondremos que las historias de usuario son
indivisibles. Adems las tareas a implementar en cada historia de usuario tienen que guardar el orden
establecido.
sto es: si se quiere implementar el requisito 3, ha de realizarse 3.1 y 3.2 en la misma iteracin, y en
ese orden.
En el Sprint Backlog lo tenemos que cumplimentar con 4 tareas para este Sprint. Aqu se ve
claramente que Kanban limita el WIP por estado en flujo de trabajo (columna del tablero);
en cambio Scrum limita el flujo de trabajo por iteracin, al indicar en el Sprint Backlog
cuntas tareas se pueden realizar en esa iteracin (recordemos que una vez comenzada una
iteracin en Scrum, no debera modificarse el Sprint Backlog).
Ahora bien, tenemos que seleccionar las tareas que, para estas historias de usuario, maximizan el valor
dado por el cliente (suponiendo que las historias de usuario son indivisibles).
Para el primer Sprint, las historias de usuario que maximizan el valor percibido por el cliente son 1, 3 y
4. Por lo que nuestro muro inicial quedara as:
De esta manera podemos ver que es fcil estimar en Kanban. Son tareas ms o menos homogneas en
tiempo. Por lo que, realizando unos pequeos clculos podemos determinar nuestro tiempo estimado.
En este caso, como el WIP de estado del flujo "En progreso" es 2, el tiempo mximo vendr
determinado por el promedio de tiempo de todas las tareas dividido 2 (ver frmula).
Por tanto:
3 das (de la tarea 1) + 2 das (de la tarea 3.1) + 3 das (de la tarea 3.2) + 3 das (de la tarea 4)
2 (WIP "En progreso")
El resultado de esta operacin es aproximadamente 6 das. Por lo tanto, para terminar las historias de
usuario, el equipo tardar aproximadamente 6 das.
Asimismo, existen otros tiempos incluidos dentro del lead time. El cycle time, que es el tiempo que pasa
desde que se empieza a trabajar con el tem hasta que pasa a un estado finalizado. Es decir es el tiempo
que se ha estado trabajando sobre la historia de usuario, tarea, etc. Como se ve en la figura, se intentar
hacer ambos tiempos similares mediante la evolucin de los lmites y de la misma pizarra Kanban.
Limitar el WIP- asignando lmites concretos. Determinando cuntos elementos pueden estar
en progreso en cada estado del flujo de trabajo. A esto se aade otra idea tan razonable como
que para empezar con una nueva tarea alguna otra tarea previa debe haber finalizado.
En ese caso tenemos un cuello de botella en la etapa de pruebas por lo que los equipos de desarrollo
pueden ayudar. De hecho podan haberlo hecho antes, en el caso de que algn integrante del equipo
quedar ocioso. Por lo tanto, si el equipo o el desarrollador no tiene posibilidad de continuar
trabajando debe buscar el cuello de botella en las siguientes etapas.
Durante la utilizacin de Kanban los lmites del trabajo en progreso (WIP) irn evolucionando.
Para ello es indispensable tener en cuenta los sntomas de lmites errneos para converger a los
valores ptimos:
La esencia de los lmites WIP de un KANBAN es enfocar al equipo en finalizar cosas ms que
en comenzar cosas.
El flujo de trabajo es el siguiente: llega una peticin de parche y el jefe de proyecto la selecciona
envindola a la columna de "peticiones seleccionadas". En el siguiente paso el equipo de desarrollo
elegir el siguiente parche a desarrollar. Una vez el parche se encuentre desarrollado quedar a la
espera de ser elegido para realizar la actividad de pruebas. Por lo tanto, entre la la etapa de
desarrollo y prueba puede existir un tiempo de espera.
Por eso es necesario dividir la columna de desarrollo y la columna de pruebas en dos partes, una para el
trabajo que se est realizando (columnas de estado) y otra para el trabajo ya realizado (columnas
de espera).
Lo ms importante aqu es que el lmite WIP es de la suma de ambas columnas. Es decir que si la
columna "desarrollo" tiene un lmite WIP de 4 no se podr empezar nuevas tareas de desarrollo aunque
tenga los 4 tems en la sub-columna "hechos". Esto es para evitar los cuellos de botella.
Recomendacin: empezar de menos a ms en cantidad de columnas. Como hemos visto se puede
complicar facilmente.
Scrum y Kanban making the most of both, Henrik Kniberg y Mattias Skarin
Qu es el mtodo Kanban para la gestin de proyectos?
Kanban vs. Scrum by Henrik Kniberg & Mattias Skarin
Test Leccin 6
Kanban permite tomar prcticas de otras tcnicas giles como SCRUM?
S, siempre y cuando se mantenga el WIP. Al ser adaptable y tener solo tres reglas siempre puede
tomar las medidas que le convengan con el fin de ser ms eficientes.
No, dejara de ser Kanban.
Si tengo un WIP de 3 en la fase "En progreso" y tengo 2 historias de usuario Puedo traer ms
historias de usuario de la fase "Pendiente"?
No, tengo que esperar a que todas las historias de usuario en las que actualmente estoy trabajando
pasen a la fase de "Terminado".
S, puedo trabajar con 3 historias de usuario ms. El WIP es de 3.
S, puedo trabajar con 1 historia de usuario ms.
Seleccione la opcin correcta:
Si al inicio del proyecto establecemos un WIP de 2, ese WIP no puede cambiar hasta que no
finalice el proyecto.
Lo ideal sera que el lead time y el cycle time llegaran a ser similares
El tamao de las historias de usuario es indiferente.
Suponiendo que estamos aplicando las tcnicas giles propias de Kanban, podremos aadir
historias de usuario (user stories) al Sprint Backlog?
Si
No
Agilidad y Lean son conceptos idnticos?
No, son trminos incompatibles
No, aunque los principios giles y Lean son compatibles.
S, porque muchos creadores de las metodologas giles estuvieron influenciados por principios
Lean.