Ing. Angel Rosendo Condori Coaquira 1. DINMICAS UTILIZADAS EN METODOLOGAS AGILES Y ARQUITECTURA 1.1. PRESENTARSE 1.1.1.

Objetivo: Conocer a los participantes y poder establecer una comunicacin fluida con todos. 1.1.2.Desarrollo Se reparte Stikers a los participantes para que puedan anotar su nombre y pegarlo a la altura de su pecho. Pedirle a cada participante que saque un dulce de una bolsa, los dulces deben ser de colores y cada dulce tiene una diferente pregunta: Por. Ejemplo Que le gusta de su carrera?, Qu espera del curso?, etc. Dialogar un con los participantes sobre las respuestas. 1.1.3.Conclusiones Es importante conocer y nombrar a los participantes por sus nombres, a nadie le gusta que le digan Tu, Ud, etc. La dinmica facilita conocer sus nombres y evita estar preguntando a cada momento por sus nombres. 1.2. BRAINSTORMING 1.2.1.Objetivo: Conocer los inters y necesidades de los participantes 1.2.2.Desarrollo: Repartir fichas 3 aproximadamente por participante (Se le pude dar mas fichas segn pida el participantes), Pedir llenar las fichas con preguntas relacionadas con el curso, o lo que le gustara aprender en el curso. Luego recoger las fichas y ponerlas en el piso, y pedir a todos los participantes leer y priorizar las fichas poniendo estrellitas a las fichas, si al alguien se le ocurre alguna pregunta mas las puede agregar an, tambin los participantes pueden dialogar la importancia de ciertos temas. Finalmente se ordena las fichas por prioridad, se pega en la pizarra (sobre un papelote) para conocer las preguntas, estas se convierten en el PRODUCT BACKLOG (Lista de actividades). 1.2.3.Conclusiones: El uso de esta dinmica trata de conocer las necesidades de los participantes y que es lo que a ellos les parece de mayor valor a tratar, asi se puede desarrollar el curso con una mejor perspectiva. Tambin se puede usar esta dinmica para solucionar problemas, usando retrospectivas, preguntando que les gusto y que no les gusto. 1.3. MANIFIESTO GIL
Manifiesto por el Desarrollo gil de Software Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A travs de este trabajo hemos Aprendido a valorar: 1.- Individuos e interacciones sobre procesos y herramientas 2.- Software funcionando sobre documentacin extensiva 3.- Colaboracin con el cliente sobre negociacin contractual 4.- Respuesta ante el cambio sobre seguir un plan Esto es, aunque valoramos los elementos de la derecha, Valoramos ms los de la izquierda.

Ing. Angel Rosendo Condori Coaquira 1.3.1.Conclusiones: Es importante conocer el manifiesto gil, que no quita importancia a la documentacin o a los procesos y herramientas, pero esta da mayor importancia a la persona y la colaboracin con esta para as desarrollar un sistema de acuerdo a las expectativas del cliente. 1.4. RETROSPECTIVA 1.4.1.Objetivo: Conocer experiencias previas que los participantes tuvieron sobre un determinado tema. 1.4.2.Desarrollo: Repartir fichas donde los participantes puedan anotar los problemas en desarrollo de software Formar grupos de 5 y ubicar cada problema en el manifiesto gil. Cada grupo leer en voz alta uno de sus problemas y esta es analizada y discutida por todos los participantes. 1.4.3.Conclusiones: El ser humano aprende mejor por medio de Historias Es importante enfocarse mas en la planificacin que en el plan en si. Romper los momentos de tensin en forma inesperada. Los problemas de desarrollo software son muy similares a los que ocurren en otros lugares, el problema principal reside en los cambios que el cliente puede hacer que hacen que se cambie alcance, tiempo y presupuesto. 1.5. CANDY QUESTION 1.5.1.Objetivo: Determinar como se tiente el usuario en ese momento. 1.5.2.Desarrollo: Los participantes toman dulces, escogiendo de entre 3 colores, Amarillo, Rojo Preguntar de a cuerdo al color: Amarillo: Qu pasa por su cabeza?, Qu necesitas de esta clase?, Qu es lo que esperas de la clase? Motivar a los participantes a ser espontneos. 1.5.3.Conclusiones: Romper el hielo, que muchas veces existe al iniciar un trabajo o una sesin, esta dinmica permite conocer como estn los participantes y asi poder tomar decisiones, y determinar como llevar la sesin o trabajo. 1.6. WARMAP 1.6.1.Objetivo: Conocer un poco como se siente el usuario 1.6.2.Desarrollo: Formar grupos de 5 participantes Entregar varios globos a cada grupo En cada grupo un participante hace el rol de cliente, y es quien infla los globos, guiado alrededor por el resto del grupo. Luego hacer lo mismo pero esta vez con los ojos vendados Luego separar el grupo a cierta distancia unos 3 metros el grupo gua al cliente a inflar los globos.

Ing. Angel Rosendo Condori Coaquira 1.6.3.Conclusiones: Conocer y sentir lo que el cliente muchas veces siente cuando se desarrolla un sistema es importante, y esta dinmica nos demuestra que tener el cliente cerca y bien comunicado ayuda mucho al xito del proyecto. El globo representa la inversin que el cliente hace en el proyecto, si el globo se revienta el proyecto esta fracasando, por lo tanto el cliente pierde confianza y esta es cada vez mas difcil de recuperarla. 1.7. 2 VERDADES 1 MENTIRA 1.7.1.Objetivo: Romper el hielo y unir el equipo formando un ambiente de confianza 1.7.2.Desarrollo: A todos los participantes uno por uno pedirles que digan 2 verdades y una mentira. Luego poner a todo los participantes en circulo y pedirles que extiendan sus manos con los 5 dedos extendidos. Cada participante debe mencionar algo que le gustara hacer pero que todava no logro hacer. Los dems participantes escuchan y si ellos hicieron eso doblan un dedo. La dinmica termina cuando alguien dobla los 10 dedos. 1.7.3.Conclusiones: En un equipo de trabajo generalmente nos encontramos y nos vemos unos a otros todos los das, y a veces se siente un ambiente aptico y sin motivaciones. Esta dinmica muestra que aun hay muchas cosas que no conocemos de nuestros amigos y personas que trabajan con nosotros. Esta dinmica tambin permite encontrar similitudes entre las personas para asi formar lazos de amistad. 1.8. CAMINATA TONTA (silly walking) 1.8.1.Objetivo: Mostrar que es necesario estar atentos frente a los cambios 1.8.2.Desarrollo: Todos los participantes caminan solos realizando movimientos graciosos Luego en parejas coordinan rpidamente una caminata graciosa Luego de tres y asi sucesivamente 1.8.3.Conclusiones: Es necesario estar atentos a los cambios y saber adecuarse a estos, tambin es importante entender a las personas con las cuales trabajamos, no siempre todo el equipo tiene la misma idea de algo y es necesario tomar acuerdos rpidamente. 1.9. ORIGAMI EN PAREJA 1.9.1.Objetivo: Mostrar y analizar la comunicacin dentro de un equipo 1.9.2.Desarrollo: Formar equipos de 2 personas, luego ubicarlos en uno de los tres grupos de comunicacin: 1. Sentados uno al lado del otro 2. Sentados frente a frente 3. Sentados de espaldas

Ing. Angel Rosendo Condori Coaquira Luego repartir una hoja que indica los pasos a seguir para relizar un Origami, a uno y a otro una hoja en blanco para que pueda realizar el Origami guiado por el que tiene la gua. Se les concede unos 5 minutos para que puedan armar el origami siempre guiados por la persona con la gua. 1.9.3.Conclusiones: La comunicacin tiene que ser fluida y es mejor si es directa, no es recomendable usar correos o documentos que muchas veces como se demuestra en al dinmica hace mucho mas complejo el trabajo y muchas veces no se entiende el mensaje es si, lo que hace que el proyecto se retrase o simplemente no se haciendo lo que el cliente espera. 1.10. REQUERIMIENTOS 1.10.1. Objetivo: Determinar que los requerimientos son fundamentales para el desarrollo 1.10.2. Desarrollo: Formar grupos de 5 o 6 participantes, luego repartir globos y pegapegas. Pedir a los grupos realizar caras con los globos y pegapegas, en un tiempo de duracin de 3 minutos. Luego como si fuera una segunda iteracin, se le pide que los ojos sean cuadrados, la Nairz en forma de triangulo y la boca rectngulo. 1.10.3. Conclusiones: Con los primeros requerimientos que se tenan que solo eran caras, y se desconoca las caractersticas de esta cada grupo hizo la cara como le pareca mejor, pero al llegar a la segunda iteracin nos dimos cuenta que no era lo que el cliente quera, porque esta deba tener ciertas caractersticas que no se tomaron en cuenta. Esta dinmica muestra que muchas veces nosotros como desarrolladores pensamos lo mejor para el cliente, pero que al final resulta que no es lo que el cliente esperaba, por lo tanto es muy importante la fase de requerimientos y mejor aun si esta se vuelve a realizar en cada iteracin. 1.11. MR. HAPPY FACE

1.11.1. Objetivo: Conocer la metodologa KAMBAN para la gestin de cambios 1.11.2. Desarrollo: Se forman grupos de 5 participantes Se muestran 4 diferentes rostros todos hechos usando tringulos, cuadrados y rectngulos como los siguientes:

Ing. Angel Rosendo Condori Coaquira El moderador escribe en una hoja la cantidad de demanda de las caras, sin que nadie le vea, y se pide a los participantes crear caras con como los ya mostrados en la cantidad que ellos vean por conveniente. Finalmente comprar lo producido con lo que el mercado necesitaba y sacar las perdidas que tuvimos por fabricar ciertas caras en exceso y tambin por no fabricar otras que el mercado necesitaba. 1.11.3. Conclusiones: En desarrollo de software si se ponen muchas personas a corregir errores se pierde dinero, por lo tanto es necesario usar las personas justas para un proyecto. En los casos en que los requerimientos cambien bruscamente que provoquen parar el proyecto se tiene que optimizar las metodologas, para esto se utiliza KAMBAN, que usando la misma dinmica con la diferencia, de que ahora cada perticipante se especializa en una sola area y se utilizan colas. Como en el ejemplo siguiente.

De esta manera podemos rpidamente producir solo lo que el mercado necesita y todo justo a tiempo. KAMBAN permite optimizar la produccin, y en ingeneria de software se puede aplicar a los requerimientos cambiantes, estar preparados todo el equipo para afrontarlos. 1.12. SOBRE LOS USUARIOS Todos los usuarios son diferentes Los usuarios necesitan tener confianza Los usuarios se sienten mas seguros con el equipo de desarrollo cerca El usuario pierde confianza cuando algn proyecto anterior fracazo, por eso es difcil que vuelva a confiar fcilmente. La comunicacin es muy importante MULTITASKING (Multitareas)

1.13.

1.13.1. Objetivo: Mostrar como funciona el procesamiento multirarea 1.13.2. Desarrollo: Repartir hojas a todos los participantes, estos deben tener un lapicero y una mesa. Dividir las hojas en 3 sectores en forma vertical Luego se empieza el trabajo escribiendo en el sector 1 letras A-Z En el sector 2 Nmeros.

Ing. Angel Rosendo Condori Coaquira En el sector 3 Nmeros Romanos, la forma de procesamiento tiene que ser de la siguiente forma: se escribe la letra A, luego 1 y finalmente I en romanos, luego se pasa a la siguiente lnea. El tiempo es cronometrado dndoles unos 2 minutos. Luego se les entra una hoja mas y se les piden que escriban lo mismo, pero esta vez primero solo letras, luego nmeros y finalmente los nmeros romanos. 1.13.3. Conclusiones: Como seres humanos a veces queremos resolver todos los problemas a la vez, con lo cual solo logramos confundirnos mas y finalmente demorar mucho mas en solucionar los problemas. Resolver las tareas de 1 en 1, es mas eficiente que todas a la vez. 1.14. ESTIMACIONES

1.14.1. Objetivo: Conocer formas de estimacin de costos 1.14.2. Desarrollo: Formar grupos de 5 participantes. En una mesa poner un gran cantidad de globos desinflados en forma de montn. Pedir a los participantes a aproximar la cantidad de estos. Luego sacar un promedio de todas las aproximaciones realizadas 1.14.3. Conclusiones: Las estimaciones mas reales se realizan en grupo, cada miembro del equipo debe dar una aproximacin de los costos, al sacar el promedio este generalmente tiende a cercarse al real. La estimacin de una personal generalmente dista de la realidad Tambin se puede repetir la dinmica pero ahora con los globos inflados que resulta mas fcil la estimacin porque ya se cuenta con informacin histrica, ya que estos se usaron para dinmicas anteriores. 1.15. EN BUSCA DE SU AMADA

1.15.1. Objetivo: Vivenciar la forma de planificacin 1.15.2. Desarrollo: Formar grupos de 5 participantes y repartir papelotes. Pedir a cada grupo realizar un plan de viaje en busca de tu amada, que se encuentra en otra ciudad distante. Luego pedir pegar el plan la pared, e indicar que los participantes que los planes cambiaron, nuestra amada ya no se encuentra en dicha ciudad, sino que esta se cambio de ciudad. Con hojas plegables realizar los cambios necesarios a nuestro plan. Y luego de esto vuelve a surgir un cambio no roban el dinero de viaje, se realizan nuevos cambios en el plan. 1.15.3. Conclusiones: No es conveniente realizar un plan muy detallado ya que al surgir cambios, es muy complicado ajustar el plan. En cada iteracin Scrum, revisar el plan y realizar los cambios necesarios.

Ing. Angel Rosendo Condori Coaquira 1.16. QUE ES LO QUE ESTOY PENSANDO? 1.16.1. Objetivo: Analizar el proceso de anlisis de sistemas 1.16.2. Desarrollo: Formar equipos de 5, un miembro del equipo hace el rol de usuario, este solo escribe verbos, sobre lo que el necesita. Los analistas deben tratar de entender lo que se esta pidiendo, y el equipo lo debe construir utilizando globos largos. Luego al usuario de le muestra una imagen, y este de la misma forma debe indicar a equipo con verbos las caractersticas de esta. El analista debe dibujar lo que el usuario le pide. Se realizan iteraciones hasta mejorar el diseo.. Las iteraciones consisten en que el usuario vuelva a ver la imagen y vuelva a dar nuevas instrucciones. 1.16.3. Conclusiones: Es necesario tomar bien los requerimientos para mejorar el desarrollo, y asi evitar retrasos, y cambios en la planificacin. 1.17. SCRUM 1.17.1. Objetivo: Conocer y aplicar en forma practica la metodologa de desarrollo de SCRUM 1.17.2. Desarrollo: Formar equipos de 5 personas Se pide al equipo realizar un listado de los lugares tursticos, comida, actividades de Puno. Esta de debe hacer en un papelote, y se debe priorizar 15 de estos tems. Los 15 Items seleccionados se convierten en el PRODUCT BACKLOG, en un papelote se crea el CHARPER ACTIVITY que consiste en dividir el papelote en 3 sectores, el primero es TODO, y se ponen todas las actividades que se van hacer en ese SPRINT. El segundo en DOING, aca se pasan las actividades que ya se estn realizando con los nombres de las personas que lo estn realizando. El tercer sector es DONE, donde se apilan todas la actividades ya terminadas.

Ing. Angel Rosendo Condori Coaquira Luego en otro papelote se dibuja el BURNDOWN, que muestra el avance, en funcin a las tareas terminadas y los Sprint. Y Finalamente en otro papelote se dibuja la satisfaccin, como han evolucionado anmicamente se BIEN o MAL, cada participante traza una lnea que indica como se ha sentido a lo largo de todo el proyecto. 1.17.3. Conclusiones: La metodologa Scrum, con estas practicas nos permite llevar un mejor control del desarrollo del software y mantener al equipo motivado. Las actividades que se estn desarrollando son visibles para todos y si alguien falto, viendo la pizarra rpidamente se puede ubicar como esta el avance del proyecto y que tareas aun faltan realizar.

1.18. GO!! 1.18.1. Objetivo: Entender que para dominar algo es necesario tener un previo entrenamiento 1.18.2. Desarrollo: Formar un circulo con todos los participantes de pie, luego uno de ellos dice GO!! Y seala a otro participante, este debe tomar la posicin del que sealo y el otro se va a la del anterior (Intercambio de posiciones). Pero antes de salir de su posicin este debe decir GO! Y sealar, se produce como un efecto de cascada. 1.18.3. Conclusiones: Aprender y dominar las metodologas agiles lleva su tiempo 1.19. AMIGOS Y ENEMIGOS 1.19.1. Objetivo: Entender que para dominar algo es necesario tener un previo entrenamiento 1.19.2. Desarrollo: Formar un circulo con todos los participantes de pie, luego uno de ellos dice GO!! Y seala a otro participante, este debe tomar la posicin del que sealo y el otro se va a la del anterior (Intercambio de posiciones). Pero antes de salir de su posicin este debe decir GO! Y sealar, se produce como un efecto de cascada. 1.19.3. Conclusiones: Aprender y dominar las metodologas agiles lleva su tiempo