Guía Práctica Nivel Inicial

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Guía Práctica Nivel Inicial"

Transcripción

1 Guía Práctica Nivel Inicial

2 Tabla de Contenidos Nota del Autor... 3 Qué es la metodología Ágil o Agile?... 4 Qué es Scrum?... 8 Un ejemplo práctico en SCRUM:... 9 Todo bien, pero Qué es Scrum? Empirismo Los Pilares de Scrum Compromiso Concentración Franqueza Respeto: Coraje El Equipo Scrum El Dueño de Producto El Equipo de Desarrollo El Scrum Máster Lista de Producto en Scrum (Product Backlog) Los requerimientos del cliente Qué contiene una Lista de Producto? Cómo le ayudamos al Dueño del Producto a elaborar la Lista de Producto? Lista de Tareas de Sprint (Sprint Backlog)... 27

3 Refinamiento de la Lista de Producto El Sprint o la Iteración en Scrum Planificación del Sprint La Meta del Sprint El Scrum Diario Daily Scrum Retrospectivas en Scrum Revisión del Sprint Sprint Review Típica Agenda: Reunión de Revisión KANBAN... 48

4 Nota del Autor Muchas gracias por ser parte del Proyecto de Cadena Crítica. Este es la primer guía, de las tres que están en carpeta sobre el tema Agile & Scrum. Aquí vas a encontrar las definiciones formales pero también muchos consejos prácticos aprendidos de años trabajando en este tipo de proyectos. Espero que te resulte entretenido. Si no has descubierto esta guía a través de te invito a que te acerques y descargues todo el material que te parezca interesante. Atentamente Carlos Diaz Calvi

5 Qué es la metodología Ágil o Agile? Dicen que el resultado de un proyecto está íntimamente ligado con la calidad de las relaciones entre los miembros del equipo. Quizás lleven razón. Lo cierto es que en los proyectos que existen equipos en los que da gusto trabajar, y otros en que no vemos la hora de volver a casa, o que se termine de otra vez. Si eso afectó la calidad de mi trabajo, no lo sé. Pero ciertamente no tenía más ganas de estar allí. Otras veces son factores externos los que hacen el proyecto insufrible. En particular proyectos largos, donde el objetivo se pierde, y más que avanzar estamos día tras

6 día luchando con estructuras muy fijas, etapas, documentación, plazos tallados en piedra que fueron poco realistas desde su concepción; a veces meses antes. De ahí que surgió una nueva forma de trabajar; de esto ya casi quince años: La metodología Ágil. Aunque algunos también la llaman XP (Extreme Programming), o Programación Extrema, entre otros nombres. Básicamente la palabra Ágil, es usada para englobar una estrategia de desarrollo de Software que tiene como premisas la estrecha colaboración de los equipos, los ciclos de desarrollo y el compromiso del equipo como un todo. Sigue los lineamientos de las proposiciones escritas en el Manifiesto Ágil: 1. Los Individuos e interacciones por sobre los Procesos y Herramientas 2. El Software Funcionando por sobre la Documentación Extensiva 3. La Colaboración con el Cliente por sobre la Negociación Contractual 4. La Respuesta Ante El Cambio por sobre el Seguir un Plan El Manifiesto Ágil da más importancia a los ítems de la izquierda que a los de la derecha, pero ambos siguen siendo necesarios.

7 Y hace énfasis en los siguientes principios Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. El software funcionando es la medida principal de progreso.

8 Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. Scrum es uno de los métodos Ágiles que se desarrollaron tras el manifiesto.

9 Qué es Scrum? Confieso que hasta hace muy poco yo pensaba que era una de esas formas de trabajo, medio bohemia y "a lo que salga, que podía ser utilizada solo en empresas pequeñas, con proyectos poco importantes. Pero en realidad Qué es Scrum? Todos los proyectos que venía haciendo yo en consultoría, por más de quince años, fueron solo en Cascada, y no solo eso: Cascadas muy pero muy elaboradas, como la de la Compañía de Energía, que tenía su propio manual de metodologías tipo PMP para la entrega de proyectos.; eso sobre el Manual que ya llevaba yo de mi propia empresa de como entregar proyectos en cascada según nosotros. PERO al final - ESTABA EQUIVOCADO AL PENSAR ASÍ.

10 Tuve oportunidad de hacer cursos de SCRUM, tanto como DESARROLLADOR como también de SCRUM MASTER (el que facilita y lleva a término cada una de las iteraciones); el Jefe de Proyectos de la forma de trabajo SCRUM. Luego tuve la suerte de trabajar dentro de un proyecto ágil por un par de iteraciones. Y al final tuve que ir con una pala a enterrar todos mis preconceptos y malas ideas sobre el tema. Es un marco de trabajo magnifico. Un ejemplo práctico en SCRUM: Para que lo entendamos con claridad. Una vez que tenemos el objetivo que nos da el cliente (una página web, una serie de componentes, lo que sea), debemos sentarnos a preparar el proyecto Scrum, conseguir el equipo adecuado, y dividir el

11 trabajo que nos pide el Dueño del Producto (Product Owner, o PO) normalmente el cliente -, trozándolo en tareas más pequeñas en una Lista de Producto (Product Backlog). Todo el equipo hace un ejercicio de estimación de esfuerzo para cada una de esas tareas, al menos las iniciales. Se decide cuantos Sprints (o Iteraciones) haremos, de acuerdo al tiempo de proyecto, y por ende cuantas Entregas (Releases, a producción). Por ej.: Un proyecto de 8 semanas, con Sprints de dos semanas y dos releases, una a la 4 (cuarta) y otra a la 8 (octava) semana. Entonces cada lunes que comienza un sprint de dos semanas, se reúne el equipo y elige que tareas de la Lista de Productos va a realizar durante esas dos semanas, en esa iteración. Las tareas se reparten intentando cubrir las prioridades dadas por el Dueño del Producto, pero no hace falta tomar la #1. Entonces de una lista de 100 tareas totales, elegimos 10, por ejemplo, de distinta complejidad. La estimación del esfuerzo que hicimos antes nos permite intuir que podemos hacer entre todos los del equipo unas 2 tareas complejas, 4 de mediana complejidad, y 4 simples. Entonces cada uno trabaja en esas tareas con el objetivo de terminarlas bien, de darlas por Terminada, testeada, integrada, potencialmente entregable al usuario final (sino no se considera terminada por más que casi casi ya este). Hay reuniones muy cortas todos los días llamada el Scrum Diario (el Daily Scrum), y cada miembro del equipo tiene la oportunidad de contar lo que hizo el día anterior, lo que espera hacer hoy, y que obstáculos le preocupan. Es tarea del Scrum Máster el quitar esos obstáculos del camino (llamados también impedimentos); luego se encarga de promover el dialogo, facilitar el trabajo.. y por ultimo no menos importante ocuparse de escudar/proteger el equipo de cualquier interacción con el mundo

12 exterior, el cliente, o nuevos requerimientos, hasta que las dos semanas se terminen. Al final del Sprint, o Iteración, (al final de la segunda semana) se presenta lo Terminado y solo lo terminado, nada a medias al Dueño del Producto, que da sus impresiones; se realiza luego otra reunión de Retrospección para hablar todos con honestidad y decir que se hizo mal (estimaciones por ejemplo), y como mejorar esas cosas. Las lecciones aprendidas. Y por ejemplo, decidir que la próxima iteración tomaremos mas o menos trabajo respecto al esfuerzo que hemos calculado. Esto define lo que es la Velocidad del equipo (podríamos llamar productividad). Entonces cuando empiece el próximo Sprint, el lunes siguiente, el ejercicio se vuelve a repetir, la toma de tareas pendientes, la re-estimación de esas tareas basándose en lo que hemos aprendido, y a trabajar nuevamente.

13 Todo bien, pero Qué es Scrum? Empecemos por el principio, pero no voy a hacer historia, tranquilos. Todos conocemos de la metodología en Cascada (o Waterfall) para la entrega y desarrollo de proyectos, esa que va paso a paso, desde la toma de requerimientos, control, ejecución, test, y producción, básicamente. Pues lo que tiene de efectiva, lo tiene de aburrida. Y tienda a matar lisa y llanamente a la creatividad. De ahí que grandes empresas se hayan planteado utilizar metodologías más dinámicas, agiles y entre ellas, la más usada es esta, llamada SCRUM. Al ser un marco, no una metodología que hay que seguir a rajatablas, SCRUM puede ser adaptado a las necesidades del proyecto, es flexible, y tiene en la mira permanentemente el tema de la mejoría incremental del producto que se pretende entregar. Entonces, en vez de tener que esperar hasta la Etapa de Producción (o Mantenimiento), dentro de varios meses, lo que SCRUM promueve es que al final de cada iteración (o Sprint) haya una serie de componentes que el dueño del producto pueda presentar a los usuarios; esto es en una, dos o tres semanas, y entonces volver a repetir el proceso y entregar algo mejorado luego, y así sucesivamente. Empirismo Es la palabra clave que describe de que se trata SCRUM. Que en realidad significa que conoceremos mejor aquello que experimentamos, por tanto iremos

14 mejorando nuestra calidad, cantidad, capacidades, y muchos otros parámetros tras cada iteración del proyecto. Y entonces se apoya en tres pilares que hay que tener siempre en cuenta: TRANSPARENCIA, INSPECCION y ADAPTACION Transparencia: Que todos los interesados, el equipo, el dueño del producto (el cliente); todos sepan cómo está la situación en cualquier momento dado. Que las reglas sean claras, por ejemplo la de los criterios que usaremos para dar por Terminado un trabajo. Tiene que haber sido testeado? Tiene que haber sido revisado por un colega? etc. Todo muy claro, si es posible, impreso y a vista de todos en la oficina. Inspección: Que tenemos que controlar, revisar, permanentemente como estamos ejecutando los procesos y utilizando los artefactos que nos provee la técnica SCRUM. No tan frecuente como para que lleve mucho tiempo, pero lo suficientemente efectiva como para que cada nueva iteración (o Sprint) notemos una mejora. Adaptación: Como resultado de la Inspección, quizás tengamos que cambiar, y eso es muy bueno. Cuanto antes lo hagamos, mejor.

15 Los Pilares de Scrum Lo primero que me viene a la cabeza cuando pienso en los Pilares de Scrum es precisamente una imagen de una batalla de caballeros honorables. El rival, en este caso, sería la sobre-planificación. Para trabajar en un proyecto Scrum tenemos que entender cuáles son los pilares de los proyectos Scrum. Y estos son: Compromiso, Concentración, Franqueza, Respeto y Coraje... lo necesario para ir a cualquier batalla. Es importante que entendamos porqué son fundamentales: Compromiso

16 Que el equipo tenga un deber con la calidad; con la colaboración y el deseo de aprender e intentar ser cada día mejores, más eficientes en su trabajo. Que no sea una obligación pero un acuerdo ser profesionales, auto-organizarse, y el compromiso de entregar un software funcional, ni más ni menos. Sentirse atados a la definición de trabajo Terminado, y qué es lo que significa para el resto del equipo. Jurarse entregar un producto de valor al cliente; y finalmente, el compromiso a tener autocritica, mirar como grupo hacia adentro y sacar las mejores conclusiones y lecciones para el próximo ciclo. Concentración: Y foco en lo que sabemos, en nuestras capacidades. También en lo más importante. Y principalmente en aquellas cosas simples que agregan valor a nuestro trabajo. Desmontar el bosque, árbol a árbol. Franqueza: Ser transparentes ésta es una palabra clave en Scrum -. Ser sinceros en el estado actual de nuestro trabajo. Y ser abiertos a dar una mano al compañero que puede necesitarla. Dar opiniones leales, y aceptar valoraciones de nuestro trabajo por parte de otros miembros del equipo. Respeto: Estar siempre consciente que todos somos distintos. Y en organizaciones globales, especialmente, el hecho que los miembros del equipo pueden provenir de culturas

17 distintas. Y, en particular, respetar la experiencia y forma de pensar del otro; sus derechos y sus responsabilidades. Coraje: Mostrar audacia por ejemplo en no hacer una tarea que no aporta ningún valor al producto final. Bravura en ser sinceros y transparentes, aunque nos afecte. Admitiendo que nadie es perfecto, y que podemos equivocarnos Y cambiar de rumbo si fuera necesario. Y, por último, en saber pedir ayuda.

18 El Equipo Scrum Vaya diferencia de roles para un Jefe de Proyectos, el participar en un proyecto Scrum. Pasas de ser el que toma las decisiones a ser un pobre tipo que la misma metodología quiere hacer desaparecer. No lo dicen abiertamente, pero los creadores de SCRUM tienen en claro que se quieren sacar a los Jefes de Proyectos de encima. Un buen equipo Scrum es auto gestionado, auto controlado, se inspecciona a si mismo y elige como mejorar para la próxima iteración (o sprint). El equipo Scrum consta de tres roles muy bien definidos:

19 El Dueño del Producto (o Product Owner, o PO) El Scrum Máster (el Facilitador) El Equipo de Desarrollo (Development team). y una muy buena aclaración: En Scrum, la palabra Desarrollador no connota a un Programador, todos desarrollan algo en Scrum, ya sea un experto en Bases de Datos, o un Arquitecto. En sí, el Equipo de Desarrollo es el que trabaja en cada ítem y lo desarrolla. Los equipos auto gestionados eligen ellos que trabajo hacer; cómo hacerlo; y que criterios usar para darlo por Terminado en cada Entrega Incremental La idea es que un equipo Scrum no necesite de otras personas (externas) para entregar el producto/programa objetivo. El Dueño de Producto No hablamos de un equipo, siempre de una persona, incluso cuando esta sea la cabeza visible de un equipo del cliente, o de analistas de negocio, detrás de él. Lo dicho, normalmente es parte del cliente, pero puede ser una persona que conoce muy bien el negocio, y el sistema a ser entregado; lo suficiente como para definir granularmente las tareas a ser completadas. Es la única persona que es RESPONSABLE de gestionar la Lista de Producto (Product Backlog) o sea, la lista discreta de tareas que el Scrum Máster y el Equipo de Desarrollo debe entregar sprint a sprint. Aunque puede delegar esa tarea, la responsabilidad no se delega. Entre sus objetivos están:

20 Crear y mantener la Lista de Producto Ordenarla y Priorizarla Clarificarla, que nadie tenga dudas, y todos entiendan cada ítem. Al ser el único responsable, es también el único que puede venir con nuevos requerimientos de parte del cliente. Y es trabajo del Scrum Máster de controlar que esos nuevos pedidos no interfieran con lo que el equipo ya esta haciendo en este periodo (sprint) El Equipo de Desarrollo Son las personas que tienen que entregar las tareas de cada iteración o sprint en un formato Terminado. No a medias tintas. Se trata de un equipo multidisciplinario y jerárquicamente plano. No hay títulos para nadie, todos son Desarrolladores, aunque haya arquitectos, programadores, testers, etc. No existen tampoco sub-equipos. Y todos, TODOS, son responsables del objetivo del sprint, por más que se distribuyan las tareas. Así que idealmente tienen que ayudarse entre sí. En cuanto a su número, se acuerda que tiene que estar entre 4 y 9 miembros (ni tan pocos como para que haya problemas de capacidad al realizar las distintas tareas, ni tantos como para que no puedan trabajar en equipo). A esto hay que agregarle que no podemos agregar nuevos miembros durante el sprint porque rompe con la sinergia del grupo (y obligatoriamente debemos re-comenzar el sprint si así fuera)

21 El Scrum Máster Aunque exista la tentación de pensarlo como un Jefe de Proyectos, el Scrum Máster es un Facilitador. Alguien que se encarga de que todos los miembros del Equipo Scrum se adhieran a su marco de trabajo. Es un líder AL SERVICIO del equipo. Entre otras tareas tiene que: Ayudar al Dueño de Producto a lograr una Lista de Producto aceptable. Facilitar durante los eventos del Scrum (las reuniones, etc.) Guía (no ordena) al Equipo de Desarrollo para que se auto gestione Eliminar obstáculos que el Equipo vaya encontrando. Guiar a la Organización, a la Compañía, en lo que significa un proyecto Scrum, y manejar sus expectativas. Motivar a que haya mejoras en cada iteración. En otras palabras, es quien debe dar la cara ante la Organización, pero por sobre todo llevar el librito bajo el brazo para explicar una, y mil veces, que es Scrum y cómo sacarle mayor valor a la experiencia de utilizarlo.

22 Lista de Producto en Scrum (Product Backlog) Los requerimientos del cliente No hay nada peor en Scrum que tener un Dueño de Producto (Product Owner) que no le da importancia a la Lista de Producto en Scrum (Product Backlog). Recordemos, la Lista de Producto es una lista ordenada de tareas (o en realidad: acciones) que son necesarias para completar el producto final. Esto es, creación del webservice, por ejemplo, o creación de la pantalla principal. La importancia de la Lista de Producto radica que en Scrum es el único listado de Requerimientos válido.

23 Se puede tener un mal Dueño de Producto (o inexperto); para eso está el Scrum Máster, para ayudarlo a entender y adueñarse de ese listado de requerimientos y su priorización. El Dueño de Producto es el único responsable de la Lista de Producto, de su contenido, su disponibilidad, y el ordenamiento, claro. Cada Ítem de la Lista de Producto sería el equivalente al WBS (Work Breakdown Structure) o EDT (Estructura de Decomposición de Trabajos) en los sistemas de Cascada. En definitiva: El listado de todo lo que hay que hacer, componente por componente, pantalla por pantalla.

24 Qué contiene una Lista de Producto? En una Lista de Producto suele contener características, funciones, requerimientos, mejoras y correcciones que aún están pendientes para completar el sistema (o producto). Obviamente de ese listado saldrán las tareas que elegiremos en cada Sprint o Ciclo de nuestro proyecto Scrum. Cada uno de esos items suele llamarse PBI (Product Backlog Item) o ILP (Ítem de la Lista de Producto).

25 Cada Item debería tener las siguientes características: Deben estar expresados en un lenguaje claro (tanto para el equipo Scrum como para el negocio del cliente. Tener valor esto es fundamental -. Recordemos que en Scrum no hacemos nada al divino botón. Puede ser creado o desarrollado por (casi) cualquiera. Deben ser propiedad del Dueño de Producto. Deben estar ordenados de una forma coherente para alcanzar el objetivo. El esfuerzo debe ser estimado por el Equipo Scrum (no por el Dueño) Cómo le ayudamos al Dueño del Producto a elaborar la Lista de Producto? Aunque un PBI puede ser una pantalla, un requerimiento, o un error-bug incluso una historia de usuario, no es sencillo a veces obtener un listado de parte del cliente. Por eso es importante que el Product Owner el Dueño de Producto sea realmente un Analista de Negocio (Business Analyst), o alguien con profundo conocimiento de las necesidades del cliente. Una buena forma de lograr descomponer la solución es mediante el uso de Historias de Usuario, a las que le dedicaremos un artículo en breve. Mediante las historias de usuario que son de un nivel muy alto podemos extrapolar acciones, y de esas acciones, finalmente tareas (que son las que necesitamos en nuestro PBI.

26 Las Historias de Usuario, en general tienen una estructura estable: Como un <tipo de usuario>, necesito <alguna funcionalidad> con la finalidad de <razón o resultado>. Por ejemplo: Una historia de Usuario podría ser: Como usuario, necesito poder enviar un correo electrónico, con la finalidad de confirmar la participación del evento. Esto nos lleva a inferir las siguientes acciones: 1. Pantalla para enviar correo. 2. Detalles del formulario con Selección del Evento 3. Botón de Envío y funcionalidad. Y de esas, podemos concluir los siguientes ítems. 1. Agregar opción de enviar correo (botón) 2. Diseño del Botón 3. Codificar la Re-dirección a la nueva pantalla 4. Testear Botón 5. Crear formulario-pantalla para detalles del correo 6. Configurar la Base de Datos para los nuevos campos 7. Crear Procedimientos Almacenados para la n 8. Agregar campos y opciones a la pantalla de acuerdo a documento de diseño. 9. Comprobar que el destinatario del correo es usuario valido. 10. Configurar textos, títulos, contenidos y validaciones del correo electrónico.

27 11. Codificar el envío del correo. 12. Testear el formulario 13. integrar la solución 14. Hacer pruebas del correo 15. Y así seguiríamos pero ya son ítems accionables por parte de los desarrolladores (diseñadores, expertos de base de datos, programadores y testers). Imagen de Ejemplo: Ejemplo de Descomposición de Historia de Usuario a Tarea.

28 Lista de Tareas de Sprint (Sprint Backlog) La Lista de Tareas de Sprint (o de una iteración o ciclo) está muy unida a la Rapidez (Velocity) de nuestro equipo. Cuánto trabajo puede dar por "Terminado" en el período de tiempo convenido del Sprint. Hablaremos de la Rapidez en otro artículo, pero debo insistir en cuán importante es: La Rapidez o Velocity es lo que nos va a decir que podemos tomar sólo cuatro o cinco tareas del total que hay en la Lista de Producto.

29 Por definición una Lista de Tareas de Sprint (Sprint Backlog) son una serie de ítems seleccionados (PBIs), incluyendo un "plan" para entregarlos, o terminarlos al finalizar el Sprint. En realidad es también un "pronóstico" en sí mismo, que incluye un subconjunto de funcionalidades que el equipo espera terminar en este ciclo o incremento, y el trabajo que hay que hacer para lograrlo.

30 Podemos ver el trabajo pendiente por cada día del Sprint. Cada día se actualiza la Lista de Tareas de Sprint, con el trabajo pendiente. El plan debe tener suficiente detalle como para poder ser seguido, evaluado, mientras avanza su desarrollo durante el Sprint. Para eso es común utilizar una pizarra con columnas, así nos vamos ubicando en qué estado está cada ítem en un momento dado. Cada vez que se identifica una nueva tarea (por ejemplo: la corrección de una funcionalidad entregada anteriormente, un nuevo bug, puede ser agregada a la Lista de Tareas del Sprint. Sólo el Equipo de Desarrollo puede agregar tareas durante el Sprint (nunca el Dueño de Producto, que debe saber esperar; ni mucho menos el Scrum Máster, que está sólo para facilitarle las cosas al equipo). La Lista de Tareas de Sprint es muy visible, ya que casi siempre está puesta en la pared, con sus papeles de colores moviéndose hacia la columna de "Terminado". Siempre hay riesgo que el equipo tome demasiados ítems (o por el contrario muy pocos) durante los primeros ciclos o Sprints. Esto sucede hasta que encuentre su "Rapidez" y pueda pronosticar mejor cuánto trabajo puede realizar en ese período. En el ejemplo que vemos a continuación, el Gráfico de Pendientes (Burndown Chart), que veremos en otro artículo, nos indica que inicialmente el equipo tomó demasiadas tareas, y por tanto no podía completarlas. Entonces, de acuerdo con el Dueño de Producto, y con tal de entregar varios "Terminados" al final del ciclo,

31 accede a quitar algunos ítems de la Lista de Tareas de Sprint y así lograr los objetivos propuestos. Cómo lograr una mejor selección de las tareas que vamos a hacer en un Sprint?: Una alternativa son las reuniones de Refinamiento de la Lista de Producto Refinamiento de la Lista de Producto Como sabemos, la mayoría de las reuniones en Scrum tienen la duración muy restringida, para que el equipo empiece a trabajar cuanto antes en las tareas. Hay una nueva corriente de pensamiento que cree que en crear una reunión semanal periódica, de "Refinamiento de la Lista de Producto". Una reunión

32 donde todos (incluso el Dueño del Producto) puedan sentarse a discutir y agregar detalles a cada una de las tareas. Hay un alto riesgo que ser termine con más ítems en la cola de tareas, así que hay que estar muy atentos. Esta reunión puede ayudar a la hora de elegir las Tareas que vamos a incluir en un Sprint. El objetivo de este refinamiento tiene que ser: Una lista de tareas bien definidas. No es necesario que sean todas las del Sprint o o Logran una buena estimación del esfuerzo. Un entendimiento profundo de cada tarea, al punto que el equipo de desarrollo pueda tomarla sin miramientos, Importante: No perder mucho tiempo en el diseño. Recordemos que en Scrum, todo es incremental. o o Dividir las tareas donde haga falta. Agregas Historias de Usuarios y Detalles. Lograr que haya suficientes detalles en los ítems de la Lista de Producto, que el equipo pueda tomar esos ítems en - por los menos - dos futuros Sprints.

33 El Sprint o la Iteración en Scrum No existiría Scrum si no fuera por los Sprints. Eso está claro. El Sprint o Iteración (o Ciclo) es el Evento más importante y primario de la metodología Scrum. El Sprint es el corazón de la práctica Scrum, un evento con un tiempo acotado (de hasta un mes) en el que se debe entregar "Terminado" una serie de componentes. Terminado se entiende como aceptable por el cliente, debidamente testeado y probado (aunque sea limitado en sus funcionalidades). Todo lo que se entrega, tiene que estar funcionando. Lo que no está "Terminado" no se muestra. Los Sprints deben tener una duración estable durante a lo largo del proyecto. Y un nuevo Sprint comienza ni bien termina el anterior, tantas veces como se haya decidido al principio.

34 Dentro del Sprint se definen una serie de Eventos que son todos fundamentales: La Planificación del Sprint La Ejecución en sí misma. Los Scrums Diarios (Reuniones rápidas de alineación) La Revisión del Sprint. La Retrospectiva del Sprint. Durante un Sprint, no puede haber cambios que afecte el Objetivo del Sprint. Por ejemplo, no puede agregarse más gente al equipo - por más que se pudiera pensar que eso es algo favorable. La naturaleza dinámica y complementaria de las capacidades del grupo hace que el agregar un nuevo componente rompa la relación del grupo (ya que no sabemos probadamente que capacidad aporta). Tampoco deben bajarse las expectativas de calidad, durante el Sprint. Lo que se considera como "Completo y Terminado" es constante. Lo único que es flexible es la Negociación de los Objetivos (en particular de las Tareas del Sprint), junto al Dueño del Producto, en caso que se note la necesidad. De cierta forma, podemos considerar cada Sprint como un mini-proyecto en si mismo; un "mini-proyecto" con un mes de horizonte, como máximo. La razón por la que se limita la duración máxima de un Sprint a un mes es porque, sencillamente, el alargar provocaría más complejidad, mayor riesgo - por lo menos eso se ha comprobado. Es mejor tener horizontes cercanos para poder sentarse a revisar, discutir, corregir errores y comenzar otro nuevo Sprint.

35 Quizás esa sea la característica más loable de los Sprints cortos: Mayor predictibilidad, ya que vamos a estar inspeccionando el progreso y adaptándonos a los cambios al menos una vez al mes (normalmente dos). También eso implica que el riesgo de pérdida - o el costo de lo que se haya hecho mal, decrece a un mes. Una práctica común es comenzar un Sprint los martes, miércoles o jueves. Ya que los lunes y viernes son considerados días menos productivos. También, cuando los equipos están repartidos en diferentes ubicaciones geográficas (no recomendado). Es común que las reuniones de Revisión de Sprint (muestra de resultados), la de Retrospectiva (corrección de errores) y la de Planeamiento del - próximo - Sprint, se realicen al mismo tiempo. Pero no es necesario que estas se lleven a cabo el mismo día, ni mucho menos.

36 Planificación del Sprint Como ocurren en los proyectos en Cascada, cuando se planifica mal, se acaba mal. La Planificación del Sprint es igualmente importante. Después de todo es - como decíamos antes - un mini proyecto en sí mismo. El trabajo que tenemos que realizar durante una Iteración, o Sprint, se planea precisamente en la reunión de Planificación del Sprint. Todo el equipo debe participar: El Equipo de Desarrollo, el Dueño del Producto y el Scrum Máster. Como todos los demás eventos en Scrum, la reunión de Planificación del Sprint tiene un tiempo muy acotado, en promedio de 8 horas por cada mes de Sprint (así que si tenemos Sprints de dos semanas, debemos sentarnos en esta planificación el primer día, y por un máximo de cuatro horas).

37 Por cierto, no sé si lo mencioné antes, en Scrum el "Resultado" que se entrega al final de cada Sprint se llama "Incremento". Los Objetivos de la Reunión de Planificación son: Decidir qué vamos a entregar (Terminado) en el Incremento resultante del Sprint. Cómo vamos a trabajar para lograr alcanzar ese Incremento? La Meta del Sprint Después que el Equipo de Desarrollo haya decidido que ítems incluir en la Lista de Tareas del Sprint, tienen que ponerle nombre a la "Meta del Sprint". Por ejemplo: Mejorar la experiencia del usuario en las Páginas de Mis Pedidos. La Meta del Sprint es un objetivo que se debería alcanzar, si se finalizan todas las tareas que pusimos en la Lista, y proveen una guía al Equipo de Desarrollo como referencia de porqué está creando ese Incremento en particular. Una orientación y motivación. Al mismo tiempo, una buena Meta de Sprint, da al Equipo de Desarrollo cierta flexibilidad en cuanto a la funcionalidad que tiene que incluir en el Sprint, y por tanto intenta ser lo que "une" todo lo que los diferentes miembros del equipo está haciendo por separado. Otros ejemplos:

38 Hacer que la aplicación funcione tanto en la Web como en un teléfono móvil. Mejorar la habilidad del Panel de Control Mejorar los tiempos de respuesta de la Aplicación. Como vemos, las Metas de Sprint suelen ser bastante "generales" o difusas, Y ASÍ DEBEN SER. La idea es que si bien nos podemos ver forzados a quitar un ítem de la Lista porque no llegamos con el tiempo, podamos decir al Dueño del Producto, en la Revisión del Sprint, que la Meta ha sido cumplida.

39 El Scrum Diario Daily Scrum El Scrum Diario, el momento en que comentamos cómo va la serie o la peli que vimos la noche anterior. Naah, es broma. Es en esta mini reunión (de quince minutos, no más) en la que nos ponemos al día de cómo va el proyecto. Consejo: El scrum diario tiene que ser siempre en el mismo lugar y a la misma hora. Es más, propongo hacerlo de pie, que sea dinámico, frente a la pizarra. Que nadie se ponga cómodo. En el scrum diario tienen que estar todos, el Dueño del Producto, el Scrum Máster, y claro... el Equipo de Desarrollo. Puede haber otros invitados, pero están sólo para observar. Es el momento donde se discute todo lo que hay que hacer en el día, el momento de informarse qué es lo que tiene que pasar hoy. Cada miembro del equipo tiene que responder a tres preguntas:

40 Qué hiciste ayer? Qué planeas hacer hoy? Qué obstáculos tienes en el camino para hacerlo? El scrum diario - o daily scrum - no es para "controlar" lo que cada uno está haciendo. Sino el momento donde cada miembro del Equipo de Desarrollo se compromete, cara a cara, a hacer lo que dice. Este punto es muy importante, es donde nuestro compromiso queda grabado en la memoria de todos. No podemos fallarles. Otra alternativa, en vez de ir persona por persona, es ir ítem por ítem en la Lista de Tareas. Asi hay más oportunidades de interactuar para cada persona. Otro punto importante - si eres el Scrum Máster - es el de los impedimentos (u obstáculos). En los que tienes que adueñarte de los problemas e intentar solucionarlos. Ese es tú trabajo. Si no lo puedes hacer inmediatamente te debes encargar de pedir ayuda. Si algo no se puede resolver en 24 hs, el Scrum Máster debe elevarlo en la compañía. La reunión de scrum diario debe ser de 15 minutos, no más. No hay que perder el tiempo. Lo que necesite más tiempo para ser discutido debe ser agregado al listado de tareas y punto. Y recuerda, si eres Scrum Máster, estás allí sólo para facilitar, no para gestionar ni asignar tareas. Si ves a alguien yendo a la reunión de scrum diario apesadumbrado, o sin ganas de estar ahi. Es claramente una señal que hay problemas. La idea del scrum diario es

41 que salga todo el mundo motivado tras escuchar los progresos de los demás. Es más, procura tener chocolates, o caramelos, como premio. Hacer la reunión entretenida. Otro consejo que me han dado, que aún no puedo llevar a la práctica, es el de NO HACER CONTACTO CON LA MIRADA, con quién está reportando su trabajo. Lo de hacer contacto visual es humano, natural, pero si así sucediera estaríamos forzando la imagen del manager-examinador a los miembros del equipo; y Scrum no se trata de gestionar, sino de facilitar. Los miembros del Equipo de Desarrollo están reportándose a sus pares, no al Scrum Máster. Y finalmente, como en toda reunión de Scrum, puedes jugar a darles el trabajo de facilitador a otros miembros del equipo para crear "entendimiento" con el rol que te toca como Scrum Máster.

42 Retrospectivas en Scrum Cuando escuché por primera vez lo de Retrospectivas en Scrum supuse que cada uno tenía que ponerse a pensar en que hizo mal, o bien, como ir al confesionario... y eso que hace rato no piso una iglesia. Una especie de momento de relajación zen para luego compartir lo descubierto con el equipo. Pero me encontré con algo mucho más interesante. En Scrum, el proceso de Retrospectiva (que se hace al final del Sprint, luego de que se enseñasen los resultados al Propietario del Producto - el cliente -), es un ejercicio para re-alinearse con las nuevas lecciones aprendidas. En particular, tiene que ser una charla abierta, sincera y honesta, entre todo el equipo. Preguntarse: Qué funciono bien?

43 Qué cosas deberíamos intentar mejorar en la próxima iteración (sprint)? Qué lecciones hemos aprendido? Y MUY IMPORTANTE: contarle al Scrum Master, el Facilitador, cuales son los obstáculos previstos (para que se ponga a trabajar en removerlos) El objetivo es que gracias - y mediante - el ejercicio de Retrospectiva, todo el equipo de Scrum se beneficie de un crecimiento sostenido, en calidad, productividad, y motivación. Lo que suele suceder - lamentablemente - es que mucha gente dentro del proyecto piense que el ejercicio de Retrospectiva no sirve para mucho, y entonces desperdician ese tiempo (aunque suelen reservar ese espacio ya que creen que es una de las partes necesarias - por definición - de un Scrum). Para no perder el tiempo en una Retrospectiva, tenemos que focalizarnos en lograr Puntos de Acción por cada ítem, decidir que vamos a hacer al respecto. Algo debemos haber aprendido de la última iteración (sprint). Si la respuesta a todo es "Va Bien", "Hubo problemas", o expresiones no "accionables" o concretas, seguro será una pérdida de tiempo. La cuestión es no ver la Retrospectiva (en Agile, Cascada, lo que sea) como una reunión OBLIGATORIA sino como una NECESARIA. Hay varias formas de hacer las Retrospectivas entretenidas y hasta divertidas; hay muchas diferentes técnicas también, ninguna en particular más útil que la otra. Como la de la Estrella de Mar (que veremos luego).

44 Pero también es un problema hacerlo "divertido"; Hay muchos consultores, o programadores, que se toman sus trabajos muy enserio y que suelen esconderse o desconfiar si ven alguna actividad de grupo que parezca divertida. Pero necesitamos de esas cosas. Está claro. Organizar una reunión de Retrospectiva no es fácil. Hay que crear el ambiente y pensar en actividades para "extraer" la información y lograr puntos de acción. Una buena alternativa, para jugar un poco con los roles, es asignar a una persona distinta, cada tanto, para que haga de "Facilitador" de la Retrospectiva. Puede darse cuenta lo complicado que es, o puede extraer otro tipo de información del equipo. No solo se trate de escuchar lo que el equipo dice, sino también de lo que no dicen, de los gestos corporales, las inquietudes aparentes, o el tono de voz. El consejo que Norm Kerth - un gurú en estos temas - da, respecto a Retrospectivas, es intentar que todo el equipo vaya a ellas con el pensamiento de que cada uno de los demás presentes ha hecho lo mejor posible para lograr sus objetivos; evitar estar a la defensiva, pensando en los prejuicios o pre-conceptos que tenemos de esa persona, o que tienen una agenda (o plan ulterior) y que no es sincera. Es como que nos pusiéramos filtros, y realmente no "escuchamos".

45 Revisión del Sprint Sprint Review Al fin y al cabo, lo único importante en Scrum es lo que está "Terminado", lo que el cliente puede empezar a usar ya mismo si quisiera. Para eso, debemos pasar la Revisión del Sprint - Sprint Review. La reunión de "presentación" del Incremento, o en otras palabras, de lo que hemos logrado, del resultado del ciclo. El objetivo de la reunión de Revisión del Sprint es la de inspeccionar el Incremento, si es necesario volver a analizar la Lista de Producto (la lista general de tareas). Es una reunión informal, de máximo cuatro horas al mes (o dos horas si nuestro ciclo - o sprint - tiene dos semanas). En esta reunión tiene que participar todo el mundo: El Dueño de Producto, el Scrum Máster, el Equipo de Desarrollo... e incluso expertos del negocio, u otros invitados que puedan dar una opinión al respecto.

46 Lo fundamental es que en la reunión sólo mostraremos Software que esté funcionando. Que agregue valor al cliente. No mostraremos nada a medio terminar. Mi recomendación es preparar la presentación de forma que las pantallas se muestren o proyecten desde un segundo monitor, en especial si estamos mostrando algo en debugging. EVITAR QUE EL CLIENTE VEA EL CÓDIGO FUENTE en todo momento. Otra opción es capturar pantallas y hacer una presentación PowerPoint (aunque este último punto, lo de preparar una presentación, suele ser muy discutido ya que va a contramano del carácter "informal" que se espera de la reunión" Como decíamos, es ésta una reunión informal, para mostrar progresos y captar comentarios; refinar si acaso el Backlog. Otros conceptos para tener en cuenta en la Reunión de Revisión del Sprint: El Dueño del Producto es quien decide al final qué fue lo realmente "Terminado" y lo que aún no lo está. El Equipo de Desarrollo discute cuales fueron los problemas que se encontraron y cómo los resolvieron. Hay que hacer una demostración en pantalla de lo Terminado. Discutir unos momentos cómo luce ahora la Lista de Producto, y qué expectativas hay para el próximo Sprint con las experiencias del que acaba de terminar. Todos deben discutir sobre qué es lo próximo para hacer.

47 Recuerda: El resultado de esta reunión es una Lista de Producto (la general - insisto -) refinada, y ya una buena idea de qué ítems van a ser incluidos en la Lista de Tareas de Sprint del próximo ciclo. Es durante la reunión de Revisión del Sprint también que todos evalúan si la META del Sprint se ha cumplido o no.?? Recuerdan? La meta es aquel nombre - un tanto genérico - con el que bautizamos el objetivo que teníamos para ese ciclo. Y por último, insistir en una premisa: No se trata de cómo funciona la pantalla o el software en el que hemos trabajado, sino de qué valor tiene para el cliente, en qué le es útil. Hay que contarles historias, ejemplos, un poquito de actuar diferentes roles para que se entiendan los beneficios. Un poco de Show, pero... a no olvidarse, todo lo que se muestre tiene que estar funcionando. Típica Agenda: Reunión de Revisión 1. El Scrum Máster abre la reunión y recuerda a todos el objetivo de ella o o o Muestra lo que se ha conseguido Cuenta historias, la experiencia del usuario Pide opiniones a los presentes. Qué piensan del producto? 2. El Dueño de Producto explica cuáles eran "sus objetivos" para ese sprint o o o Describe la Meta del Sprint Explica por qué es tan importante esa meta para el negocio. Hace referencia a dónde estamos en el panorama del proyecto. 3. El Scrum Máster presenta el Sprint. o Cuenta la historia de cómo fue todo durante el período. Con qué problemas se encontraron, nuevos miembros del equipo, etc.

48 o Da un estado del Sprint y cuenta qué tareas se completaron, y cuáles se quitaron o modificaron. 4. Finalmente las Demos. El Equipo de Desarrollo elabora cada historia de usuario. o o o o El presentador explica qué se intentó hacer con esa historia de usuario. Demostrar el funcionamiento en el sistema real. Responder preguntas. Repetir este punto por cada historia de usuario. 5. El Scrum Máster cierra la reunión.

49 KANBAN KANBAN Un placer tener que escribir sobre Kanban. Pocas veces uno se encuentra con un sistema "nuevo" - por así decirlo - que pueda agregar mucha productividad a un equipo de trabajo. Así de útil resultó ser, en Proyectos Ágiles, una pizarra Kanban. Básicamente el término Kanban viene de Japón y significa más o menos "Tarjeta Visual", y en sí es un sistema que ya viene siendo usado hace sesenta años en la producción de productos y el abastecimiento de partes. Ahora bien, poniendo esos conceptos al servicio del software, nos encontramos con una metodología de

50 trabajo que nos permite hacer que las componentes vayan "fluyendo", lenta y sostenidamente, desde la concepción hasta la producción. A ver si puedo dar un ejemplo: En las metodologías Ágiles, como en Scrum, una de las partes importantes de cada ciclo o Sprint es cuando los desarrolladores escogen una tarea (o más) de la Lista de Pendientes. En Scrum esto se suele hacer de modo voluntario, de acuerdo a las capacidades de cada persona en el equipo. Ellas se encargan de llevar esa tarea a un nivel necesario (definido por lo que el equipo considera como "Terminado". Hasta ahí lo que sabíamos, y nos iba muy bien. En una pizarra Scrum, normal tenemos una columna para las tareas: Pendientes / En Desarrollo / Finalizadas. En Kanban, reemplazamos esa columna del medio "En Desarrollo" y la dividimos en tantas columnas como nuestro "flujo de trabajo" o Workflow necesite, por ejemplo en: Pendientes / Especificaciones / Diseño / Ejecución / Test / Finalizadas

51 Hasta ahí no parece que hiciéramos mucho más, pero el secreto está en que, de acuerdo a la capacidad de nuestro equipo, demos a cada columna un "Tope" de capacidad. Por ejemplo que no podamos estar "Diseñando" más de tres componentes en un momento dado, y que si quisiéramos meter un cuarto ítem, deberíamos mover a Ejecución alguno. De esa forma se crea un flujo de ítems que se van "empujando" unos a otros, como si fueran una cadena de producción hasta que se den por finalizadas todas las tareas. Terminaríamos con algo así: Pendientes (10)/ Especificaciones (3) / Diseño (3) / Ejecución (4) / Test (2) / Finalizadas La ventaja que tiene este modelo es que vamos generando ítems finalizados constantemente. Aquí algunos ejemplos (podemos ver arriba, donde está el nombre de la columna, la cantidad de ítems que puede aceptar)

52 La característica principal que tiene Kanban, es que limita el trabajo que se puede hacer en un momento dado. Es más realista que otros paradigmas.

4.1.1_Reunión de Planificación de Sprint (Sprint Planning Meeting) 4.1.2_Objetivo del Sprint (Sprint Goal) 4.1.4_Revisión de Sprint (Sprint Review)

4.1.1_Reunión de Planificación de Sprint (Sprint Planning Meeting) 4.1.2_Objetivo del Sprint (Sprint Goal) 4.1.4_Revisión de Sprint (Sprint Review) 1_Visión general de SCRUM 2_Teoría de Scrum 3_El Equipo Scrum (Scrum Team) 3.1_El Dueño de Producto (Product Owner) 3.2_El Equipo de Desarrollo (Development Team) 3.3_El Scrum Master 4_Eventos de Scrum

Más detalles

Desarrollo detallado de la fase de aprobación de un proyecto informático mediante el uso de metodologías ágiles.

Desarrollo detallado de la fase de aprobación de un proyecto informático mediante el uso de metodologías ágiles. Autor: Manuel Trigás Gallego Director de Proyecto: Ana Cristina Domingo Troncho Desarrollo detallado de la fase de aprobación de un proyecto informático mediante el uso de metodologías ágiles. Qué es un

Más detalles

Scrum. una descripción. Traducido y revisado por Xavier Quesada Allue, Alan Cyment y Martín Alaimo Marzo 2013

Scrum. una descripción. Traducido y revisado por Xavier Quesada Allue, Alan Cyment y Martín Alaimo Marzo 2013 Scrum una descripción Traducido y revisado por Xavier Quesada Allue, Alan Cyment y Martín Alaimo Marzo 2013 v 2012.12.13 2012 Scrum Alliance, Inc. 1 Scrum Principios de Scrum Valores del Manifiesto Ágil

Más detalles

Proyecto de Grado SoReWa (Social Restaurant Wall) DOCUMENTO ARTICULADOR

Proyecto de Grado SoReWa (Social Restaurant Wall) DOCUMENTO ARTICULADOR Proyecto de Grado SoReWa (Social Restaurant Wall) DOCUMENTO ARTICULADOR Elaborado Por: Alejandro Arbeláez Acevedo Elaborado Para: Proyecto de Grado Versión: 1.0 Mayo, 2014 Confidencial Eafit UP. Versión

Más detalles

DES. Fundamento Institucional. Objetivos. Alcance

DES. Fundamento Institucional. Objetivos. Alcance DES INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de DESARROLLO en el ciclo de vida del software en el cual se debe apoyar para la ejecución de sus actividades;

Más detalles

Aplicación de metodologías Ágiles en TI. Elsa Mangione, PMP, PMI-ACP, CSM II Reunión de Miembros Abierta. Mendoza, 2013.

Aplicación de metodologías Ágiles en TI. Elsa Mangione, PMP, PMI-ACP, CSM II Reunión de Miembros Abierta. Mendoza, 2013. Aplicación de metodologías Ágiles en TI Elsa Mangione, PMP, PMI-ACP, CSM II Reunión de Miembros Abierta. Mendoza, 2013. 1 To Do En Proceso Done! Agile Scrum Intro Lean Kanban Aplicabilidad Cierre 2 To

Más detalles

Ingeniería de Software II Primer Cuatrimestre de 2008

Ingeniería de Software II Primer Cuatrimestre de 2008 Ingeniería de Software II Primer Cuatrimestre de 2008 Clase 14: Introducción a Scrum Buenos Aires, 12 de Mayo de 2008 Scrum: Qué es? Qué es un scrum? Un scrum es un agrupamiento (formación fija) en Rugby.

Más detalles

Gestión de Equipos de Desarrollo. Max Déboli Director de Desarrollo Lagash MVP Azure mdeboli@lagash.com http://mdeboli.wordpress.

Gestión de Equipos de Desarrollo. Max Déboli Director de Desarrollo Lagash MVP Azure mdeboli@lagash.com http://mdeboli.wordpress. Gestión de Equipos de Desarrollo Max Déboli Director de Desarrollo Lagash MVP Azure mdeboli@lagash.com http://mdeboli.wordpress.com Contexto Metodologías agiles de desarrollo de Software y como las usamos

Más detalles

Karen Giraldo Escobar Graciela Catalina Soto PROYECTO DE GRADO I

Karen Giraldo Escobar Graciela Catalina Soto PROYECTO DE GRADO I Karen Giraldo Escobar Graciela Catalina Soto PROYECTO DE GRADO I Qué es SCRUM Beneficios Como Funciona Fundamentos Requisitos Historia Qué es SCRUM Beneficios Como Funciona Fundamentos Requisitos Historia

Más detalles

Ingeniería de Software II Segundo Cuatrimestre de 2008

Ingeniería de Software II Segundo Cuatrimestre de 2008 Ingeniería de Software II Segundo Cuatrimestre de 2008 Clase 14: Introducción a los métodos ágiles y Scrum Buenos Aires, 9 de Octubre de 2008 Scrum: Qué es? Qué es un scrum? Un scrum es un agrupamiento

Más detalles

Ingeniería de Sistemas I

Ingeniería de Sistemas I Ingeniería de Sistemas I Metodologías Ágiles 1 Agenda Metodologías Ágiles, Origen Valores y Principios de las Metodologías Ágiles Ejemplos de Metodologías Ágiles SCRUM XP SCRUM y XP Agilidad o Disciplina?

Más detalles

PRODUCIVIDAD Y METODOLOGÍAS ÁGILES

PRODUCIVIDAD Y METODOLOGÍAS ÁGILES PRODUCIVIDAD Y METODOLOGÍAS ÁGILES FUNDAMENTOS QUÉ ES PRODUCTIVIDAD? Tiempo Eficiencia Capacidad Rendimiento Incluso le han dado funciones matemáticas Capacidad o grado de producción por unidad de trabajo,

Más detalles

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Octubre de 2011. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Octubre de 2011. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland La Guía de Scrum La Guía Definitiva de Scrum: Las Reglas del Juego Octubre de 2011 Desarrollado y soportado por Ken Schwaber y Jeff Sutherland Contenido Propósito de la Guía de Scrum... 3 Visión general

Más detalles

Prototipado Ágil. Mateu Batle Sastre

Prototipado Ágil. Mateu Batle Sastre Prototipado Ágil Mateu Batle Sastre Uso informativo y confidencial Prototipado Ágil Prototipos Metodologías ágiles Metodología Scrum Definición de prototipo Ejemplar original o primer molde en que se fabrica

Más detalles

ACADEMIA AGIL PROFESSIONAL SCRUM. Jr. Huamachuco 1408 Of. 504 - Jesús Maria Tel: +51(1) 4235124 - +51(1) 987500271 www.joedayz.pe

ACADEMIA AGIL PROFESSIONAL SCRUM. Jr. Huamachuco 1408 Of. 504 - Jesús Maria Tel: +51(1) 4235124 - +51(1) 987500271 www.joedayz.pe ACADEMIA AGIL PROFESSIONAL SCRUM JoeDayz EIRL SCRUM - 1 - SOBRE SCRUM Scrum es un proceso ágil y liviano que sirve para administrar el desarrollo de software. El desarrollo se realiza en forma iterativa

Más detalles

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Julio de 2013. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Julio de 2013. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland La Guía de Scrum La Guía Definitiva de Scrum: Las Reglas del Juego Julio de 2013 Desarrollado y soportado por Ken Schwaber y Jeff Sutherland Contenido Propósito de la Guía de Scrum... 4 Visión general

Más detalles

Universidad ORT Uruguay

Universidad ORT Uruguay Facultad de Ingeniería Metodología SCRUM Cátedra de Ingeniería de Software. Docente Responsable: Gastón Mousqués. Autor: Adriana Peralta 123357 2003 ÍNDICE GENERAL Introducción 2 Principales características

Más detalles

Qué es Scrum? Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP Visual Developer - Visual Basic

Qué es Scrum? Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP Visual Developer - Visual Basic Qué es Scrum? Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP Visual Developer - Visual Basic http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx Por

Más detalles

SCRUM. Gestión ágil de proyectos

SCRUM. Gestión ágil de proyectos SCRUM Gestión ágil de proyectos 1 Qué es Scrum? SCRUM es una metodología ágil utilizada en el desarrollo de proyectos de software y que permite obtener el mejor resultado posible en la gestión de un proyecto

Más detalles

MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015

MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015 MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015 DATOS IDENTIFICATIVOS: 1. Título del Proyecto Herramienta para el Desarrollo de Aplicaciones Software con Metodologías

Más detalles

Desarrollo Ágil. Introducción a desarrollo ágil. Periodo: 2012-2 Inicio: Ago 14, 2012 Termino: Nov 27, 2012

Desarrollo Ágil. Introducción a desarrollo ágil. Periodo: 2012-2 Inicio: Ago 14, 2012 Termino: Nov 27, 2012 Desarrollo Ágil Introducción a desarrollo ágil Periodo: 2012-2 Inicio: Ago 14, 2012 Termino: Nov 27, 2012 Agenda Continuación de Scrum Tarea Bibliografía SCRUM Master (Roles) Representa la administración

Más detalles

EXIN Agile Scrum Foundation

EXIN Agile Scrum Foundation Examen tipo EXIN Agile Scrum Foundation Edición Mayo 2014 Copyright 2014 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Más detalles

Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios

Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios Guillermo Watson Datalytics Stibenzon Cañas Sánchez Ceiba Software House Business Intelligence No es una tecnología ni un

Más detalles

Roles Scrum en Profundidad. ScrumMaster, Product Owner, Team

Roles Scrum en Profundidad. ScrumMaster, Product Owner, Team Roles Scrum en Profundidad ScrumMaster, Product Owner, Team Interdependencia entre Roles El verdadero proyecto lo llevan el Product Owner y el Team, mientras que el Scrum Master facilita la interacción.

Más detalles

El método Scrum. > Respuesta a los cambios, sobre cumplimiento estricto de un plan. Ciclo diario Scrum. Ciclo mensual. Sprint

El método Scrum. > Respuesta a los cambios, sobre cumplimiento estricto de un plan. Ciclo diario Scrum. Ciclo mensual. Sprint 54-58 Management - 36.qxd 3/19/07 5:25 PM Page 54 (Management) El método Scrum crum es, actualmente, uno de los métodos S ágiles para desarrollo de software de mayor difusión en la industria, junto con

Más detalles

Principios y valores de la agilidad

Principios y valores de la agilidad Principios y valores de la agilidad Jesús Méndez #WebminarGratis 1 Quien es Jesus Mendez Coach Agile (2) Twitter: @chuzzete Web site: www.jesusmendez.ca Correo: info@jesusmendez.ca Scrum Master (5) + Volunteering

Más detalles

Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM. Por Jesus Demetrio Velázquez Camacho

Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM. Por Jesus Demetrio Velázquez Camacho Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM Por Jesus Demetrio Velázquez Camacho Dentro de las organizaciones de desarrollo de aplicaciones existen dos grandes corrientes para la metodología

Más detalles

Checklist para Scrum Masters

Checklist para Scrum Masters Fuente original : Michael James (mj4scrum@gmail.com). http://www.colabpro.com 14 September 2007 (Revised 24 July 2012) Traducción : José Vázquez Sánchez. (a113779@gmail.com) http://www.gestiondeproyectosit.es

Más detalles

Mejora Ágil de Procesos

Mejora Ágil de Procesos Mejora Ágil de Procesos Introducción Después de haber implementado por muchos años modelos de mejora, de dirección de proyectos y diferentes marcos ágiles, llegué a la conclusión de que el camino hacia

Más detalles

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013 Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles Iñigo Garro, Octubre de 2013 Este documento se ha basado en el informe técnico CMU/SEI-2010-TR-033 del Software Engineering Institute,

Más detalles

Desarrollo Ágil. Introducción a desarrollo ágil. Periodo: 2012-2 Inicio: Ago 14, 2012 Termino: Nov 27, 2012

Desarrollo Ágil. Introducción a desarrollo ágil. Periodo: 2012-2 Inicio: Ago 14, 2012 Termino: Nov 27, 2012 Desarrollo Ágil Introducción a desarrollo ágil Periodo: 2012-2 Inicio: Ago 14, 2012 Termino: Nov 27, 2012 Agenda Continuación de Scrum Tarea Bibliografía Las 3 Preguntas de SCRUM Que hiciste el día de

Más detalles

Notas de Scrum. Licenciado Villarreal, Gonzalo Luján.

Notas de Scrum. Licenciado Villarreal, Gonzalo Luján. Notas de Scrum. Licenciado Villarreal, Gonzalo Luján. Sólo en uno de cada tres proyectos de software se cumple el plan inicial: el sistema realiza las funcionalidades inicialmente previstas, y se desarrolla

Más detalles

PMI Tour Cono Sur Mendoza 2013. Desafíos y lecciones aprendidas al gestionar proyectos ágiles. Mónica Colombo

PMI Tour Cono Sur Mendoza 2013. Desafíos y lecciones aprendidas al gestionar proyectos ágiles. Mónica Colombo PMI Tour Cono Sur Mendoza 2013 Desafíos y lecciones aprendidas al gestionar proyectos ágiles Mónica Colombo 1 Mónica Colombo Es la Directora de QA (Gerente de Aseguramiento de la Calidad) desde hace 10

Más detalles

Son aplicables las metodologías ágiles a la dirección de megaproyectos?

Son aplicables las metodologías ágiles a la dirección de megaproyectos? Son aplicables las metodologías ágiles a la dirección de megaproyectos? Ing. Carla Fernández C, PMP 1 Metodologías Ágiles Son aplicables? Megaproyectos 2 1 El tradicional enfoque de cascada Análisis Diseño

Más detalles

AGILE MANIFESTO. Guillermo Caro Murillo. Intención:

AGILE MANIFESTO. Guillermo Caro Murillo. Intención: Intención: AGILE MANIFESTO Experiencias personales Experiencias personales en temas relacionados con Agile Casos de éxito y fracaso Es posible utilizarlo? Es conveniente? Guillermo Caro Murillo Ingeniero

Más detalles

Introducción a la implementación de Scrum

Introducción a la implementación de Scrum Introducción a la implementación de Scrum Jorge Iván Meza Martínez http://www.jorgeivanmeza.com/ Jorge Iván Meza Martínez - 1 Contenido Introducción. Historia. Qué es un proyecto. Gestión

Más detalles

con Scrum y Kanban Gustavo Quiroz Madueño Open Edge Technologies

con Scrum y Kanban Gustavo Quiroz Madueño Open Edge Technologies Gestión Ágil de Proyectos con Scrum y Kanban Gustavo Quiroz Madueño Open Edge Technologies Acerca del Autor Gustavo Quiroz, CSP, CSM, CSD, CSPO, PSM I Gustavo Quiroz es Consultor, Trainer, Coach y Orador

Más detalles

Certified Scrum Developer (CSD), Módulo 3 y Track Completo

Certified Scrum Developer (CSD), Módulo 3 y Track Completo Certified Scrum Developer (CSD), Módulo 3 y Track Completo Surgida en 2009, la certificación CSD es la última novedad en certificaciones oficiales de la Scrum Alliance a través de la cual los equipos de

Más detalles

Scrum. Juan Palacio Bañeres

Scrum. Juan Palacio Bañeres Scrum Juan Palacio Bañeres La esencia de Scrum Al iniciar cada iteración, el equipo revisa el trabajo pendiente del proyecto y selecciona la parte que terminará como un incremento de funcionalidad incorporado

Más detalles

Scrum en breve. Dan Rawsthorne, PhD, PMP, CST Doug Shimp, CST Marcelo R. López, Jr. CSM/CSPO, Traducción al Castellano

Scrum en breve. Dan Rawsthorne, PhD, PMP, CST Doug Shimp, CST Marcelo R. López, Jr. CSM/CSPO, Traducción al Castellano Contenido Scrum en breve Dan Rawsthorne, PhD, PMP, CST Doug Shimp, CST Marcelo R. López, Jr. CSM/CSPO, Traducción al Castellano El Equipo... 1 La Reserva de Pedidos... 3 El Lanzamiento, o Release... 4

Más detalles

PROPUESTA DE PROYECTO DE DESARROLLO DE PÁGINA WEB PARA GESTIÓN DE PROYECTOS CON METODOLOGÍA SCRUM

PROPUESTA DE PROYECTO DE DESARROLLO DE PÁGINA WEB PARA GESTIÓN DE PROYECTOS CON METODOLOGÍA SCRUM Universidad Rafael Landivar Campus Quetzaltenango Facultad de Ingeniería PROPUESTA DE PROYECTO DE DESARROLLO DE PÁGINA WEB PARA GESTIÓN DE PROYECTOS CON METODOLOGÍA SCRUM Linda Estrella Córdova Monterroso

Más detalles

EVALUAR para avanzar

EVALUAR para avanzar EVALUAR para avanzar La Red ciudadana de Formadores en Seguridad del Paciente está realizando una evaluación de sus acciones realizadas en los últimos 2 años METODOLOGÍA Modelo de formación en cascada

Más detalles

Miguel Torres Jaime Pavlich-Mariscal

Miguel Torres Jaime Pavlich-Mariscal Miguel Torres Jaime Pavlich-Mariscal Implementar algunos requerimientos feedback Implementar algunos requerimientos feedback Implementar algunos requerimientos Iteración de 2-6 semanas Entrega al cliente

Más detalles

IT Project Management Desarrollo de Software

IT Project Management Desarrollo de Software IT Project Management Desarrollo de Software Es posible una mezcla de Waterfall y Agile? Cómo se acerca el PMBOK a Agile? Autor: Norberto Figuerola Resulta muy frecuente que se suela confundir una aproximación

Más detalles

Primero, para organizar tus apuntes no olvides incluir: Ya en clase, algunas sugerencias que debes considerar son:

Primero, para organizar tus apuntes no olvides incluir: Ya en clase, algunas sugerencias que debes considerar son: TOMA DE APUNTES 1 Qué es? Tomar apuntes es la acción de anotar los puntos sobresalientes de una clase y una actividad que apoya tu estudio y tu aprendizaje. Tomar apuntes: Te ayuda a reforzar la atención

Más detalles

El toque humano (Parte 1)

El toque humano (Parte 1) El toque humano (Parte 1) Transcripción del vídeo En este vídeo me gustaría compartir una sencilla estrategia que permitió cerrar un 40% más de ventas... y que, efectivamente nació de una "casualidad"

Más detalles

La Guía Nexus. La Guía Definitiva a Nexus: El exoesqueleto de desarrollo a escala con Scrum. Desarrollado y mantenido por Ken Schwaber y Scrum.

La Guía Nexus. La Guía Definitiva a Nexus: El exoesqueleto de desarrollo a escala con Scrum. Desarrollado y mantenido por Ken Schwaber y Scrum. La Guía Nexus La Guía Definitiva a Nexus: El exoesqueleto de desarrollo a escala con Scrum Desarrollado y mantenido por Ken Schwaber y Scrum.org Agosto 2015 Tabla de Contenido Información General de Nexus...

Más detalles

PDSM: PROCESO DE DESARROLLO DE SOFTWARE MIXTO COMBINANDO RUP Y SCRUM. Mariani, María Florencia Okabe, Evangelina

PDSM: PROCESO DE DESARROLLO DE SOFTWARE MIXTO COMBINANDO RUP Y SCRUM. Mariani, María Florencia Okabe, Evangelina PDSM: PROCESO DE DESARROLLO DE SOFTWARE MIXTO COMBINANDO RUP Y SCRUM Mariani, María Florencia Okabe, Evangelina Agenda Introducción Metodologías RUP SCRUM Proyectos PDSM: Definición y Aplicación del proceso

Más detalles

Índice 1/ 34. 1- Tu primera encuesta

Índice 1/ 34. 1- Tu primera encuesta Índice 1- Tu primera encuesta 1/ 34 2- Planificación previa Qué voy a preguntar? A quién voy a preguntar? Qué voy a hacer con los datos? Cómo los voy a presentar? 3- Recogemos los datos 4- Procesamos los

Más detalles

HOMENAJE A BOAVENTURA DE SOUSA SANTOS: COMENTARIO

HOMENAJE A BOAVENTURA DE SOUSA SANTOS: COMENTARIO HOMENAJE A BOAVENTURA DE SOUSA SANTOS: COMENTARIO Quisiera hablar en estos quince minutos sobre la contribución de Boaventura y del Caleidoscopio de las Justicias en Colombia a la Sociología Jurídica,

Más detalles

Guía Comparativa de Metodologías Ágiles

Guía Comparativa de Metodologías Ágiles Universidad de Valladolid E. U. de Informática (SEGOVIA) Grado en Ingeniería Informática de Servicios y Aplicaciones Guía Comparativa de Metodologías Ágiles Alumno: María José Pérez Pérez Tutor: Francisco

Más detalles

Tema 3. Procesos ligeros de desarrollo de software.

Tema 3. Procesos ligeros de desarrollo de software. Ingeniería del Software II 2011 Tema 3. Procesos ligeros de desarrollo de software. Tipos de procesos ligeros. Tipos de procesos ligeros: Desarrollo Rápido de Software. Desarrollo Ágil. Programación Extrema.

Más detalles

Gestionando Agile/Scrum con Sciforma

Gestionando Agile/Scrum con Sciforma agile Gestionando Agile/Scrum con Sciforma El desarrollo ágil de software son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones

Más detalles

TIPS PARA UN LÍDER ÁGIL

TIPS PARA UN LÍDER ÁGIL TIPS PARA UN LÍDER ÁGIL Desde Lean hacia Ágil Project Management Pablo Lledó Pablo Lledó Master of Science en Evaluación de Proyectos, Univ. of York, Inglaterra Project Management Professional (PMP), Project

Más detalles

Dinámicas de grupo. Presentación por Parejas

Dinámicas de grupo. Presentación por Parejas Dinámicas de grupo Presentación por Parejas El objetivo es promover la presentación de los/las integrantes de un grupo. Se forman parejas cuyos miembros no se conocen que deben compartir información personal.

Más detalles

Reporte inicial. Metodología

Reporte inicial. Metodología Reporte inicial Este reporte inicial expondrá las decisiones que tomamos al momento de selección de metodología, plantillas y métodos de recabado de evidencia y por qué tomamos dichas decisiones. Metodología

Más detalles

FAQ s CONFIGURACIÓN: Es muy complicado manejar el SEYPOS Easytouch sin teclas?

FAQ s CONFIGURACIÓN: Es muy complicado manejar el SEYPOS Easytouch sin teclas? FAQ s CONFIGURACIÓN: Es muy complicado manejar el SEYPOS Easytouch sin teclas? Al contrario, es muy fácil para cualquier persona ya que todo se maneja tocando con el dedo en la pantalla cómo en un teléfono

Más detalles

Ofertas y Contratos en Scrum

Ofertas y Contratos en Scrum Ofertas y Contratos en Scrum Aspectos que se deben considerar para ofertar y contratar proyectos de entrega incremental. José Vázquez Sánchez 2013 José Vázquez Sánchez Twitea sobre el libro! Por favor

Más detalles

SEGUIMIENTO EDUCATIVO. Perfil Madre/Padre

SEGUIMIENTO EDUCATIVO. Perfil Madre/Padre SEGUIMIENTO EDUCATIVO Perfil Madre/Padre Noviembre 2010 INDICE 1. INTRODUCCIÓN...3 2. TAREAS HABITUALES...4 2.1 Cambiar de hijo activo en RAYUELA SEGUIMIENTO...4 2.2 Cambiar la foto mostrada de uno de

Más detalles

INSTRUCIONES PARA PARTICIPAR EN. Antes de explicarte el proceso, te preguntare Porque tantas personas Viven En Un Mundo SI?

INSTRUCIONES PARA PARTICIPAR EN. Antes de explicarte el proceso, te preguntare Porque tantas personas Viven En Un Mundo SI? INSTRUCIONES PARA PARTICIPAR EN http://ganardineroporsiempre.com Antes de explicarte el proceso, te preguntare Porque tantas personas Viven En Un Mundo SI? Si hubiese hecho eso Si hubiese tomado esa oportunidad

Más detalles

Roles y Responsabilidades en la gestión de proyectos Scrum

Roles y Responsabilidades en la gestión de proyectos Scrum en la gestión de proyectos Scrum Jesús E Méndez A #WebinarGratis 1 Quien es Jesus Mendez Coach Agile (2) Twitter: @chuzzete Web site: www.jesusmendez.ca Correo: info@jesusmendez.ca Scrum Master (5) + Volunteering

Más detalles

Scrum. Marcos Bermejo PID_00177692

Scrum. Marcos Bermejo PID_00177692 Scrum Marcos Bermejo PID_00177692 CC-BY-NC-ND PID_00177692 Scrum Los textos e imágenes publicados en esta obra están sujetos excepto que se indique lo contrario a una licencia de Reconocimiento-NoComercial-SinObraDerivada

Más detalles

Tips para un Líder Ágil

Tips para un Líder Ágil Tips para un Líder Ágil Desde Lean hacia Agile Project Management Pablo Lledó PMP Pablo Lledó, PMP Economista 3 MBAs en Europa / Instructor 4 Empresas en marcha / Empresario 8 libros publicados / Autor

Más detalles

Modulo III: - Metodologías: Scrum, metodologías en entornos ágiles

Modulo III: - Metodologías: Scrum, metodologías en entornos ágiles Modulo III: - Metodologías: Scrum, metodologías en entornos ágiles José Vicente Marina. Jefe de Área de Desarrollo. Supermercados Sabeco Únete al foro en: Modulo III: Metodologías Introducción Manifiesto

Más detalles

INTRODUCCIÓN... 3. Gestión de la coordinación... 4 Gestión documental... 5 Validaciones... 6 PASOS PARA CREAR UNA COORDINACIÓN (CONTRATA)...

INTRODUCCIÓN... 3. Gestión de la coordinación... 4 Gestión documental... 5 Validaciones... 6 PASOS PARA CREAR UNA COORDINACIÓN (CONTRATA)... Contenido INTRODUCCIÓN... 3 CARACTERÍSTICAS... 3 Gestión de la coordinación... 4 Gestión documental... 5 Validaciones... 6 PARAMENTOS DE BÚSQUEDA... 7 ACCESO... 7 PASOS PARA CREAR UNA COORDINACIÓN (CONTRATA)...

Más detalles

Tips para un Líder Ágil

Tips para un Líder Ágil Tips para un Líder Ágil Desde Lean hacia Agile Project Management Pablo Lledó PMP Economista Pablo Lledó, PMP 3 MBAs en Europa / Instructor 4 Empresas en marcha / Empresario 5 libros publicados / Autor

Más detalles

Metodologías Lean-Agile: retos, ventajas y los enfoques modernos de calidad y valor. Luis Nava lunava@gmail.com

Metodologías Lean-Agile: retos, ventajas y los enfoques modernos de calidad y valor. Luis Nava lunava@gmail.com Metodologías Lean-Agile: retos, ventajas y los enfoques modernos de calidad y valor Luis Nava lunava@gmail.com Apropiación de nuevas metodologías: En todas las regiones del mundo, la combinación de las

Más detalles

Misión: Éxito Abdiel Ledesma Panamá, 24 de junio de 2015 lunes 22 de junio de 2015

Misión: Éxito Abdiel Ledesma Panamá, 24 de junio de 2015 lunes 22 de junio de 2015 Abdiel Ledesma Su misión, si decide aceptarla... IMPACTO PROFESIONALISMO VOLUNTARIADO COMUNIDAD COMPROMISO COMUNIDAD HEY HEY Jou Jou Ampliando mi red Mi nombre es Trabajo con Ocupo

Más detalles

Formación en Scrum. Formación preparatoria para la certificación PSM I de Scrum.org. Fernando Sacasa v.febrero2014

Formación en Scrum. Formación preparatoria para la certificación PSM I de Scrum.org. Fernando Sacasa v.febrero2014 Formación en Scrum Formación preparatoria para la certificación PSM I de Scrum.org Fernando Sacasa v.febrero2014 Conoces Scrum? (I) Trabajas con requisitos técnicos y funcionales complejos? Gestionas proyectos?

Más detalles

Scrum Manager Curso de formación

Scrum Manager Curso de formación Scrum Manager Curso de formación SCRUM cc-by **Maurice** 1.0 LICENCIA DE USO Este es un recurso educativo abierto (OER) del proyecto Scrum Manager Los contenidos OER de ScrumManager se pueden emplear de

Más detalles

Desarrollo Ágil con SCRUM. Itzcoalt Alvarez M. Joiz.Net

Desarrollo Ágil con SCRUM. Itzcoalt Alvarez M. Joiz.Net Desarrollo Ágil con SCRUM Itzcoalt Alvarez M. Joiz.Net Objetivo Acercamiento a SCRUM, conocer sus ventajas y desventajas, así como su funcionamiento. 2 Agenda Antecedentes Como funciona SCRUM Roles y responsabilidades

Más detalles

Cómo mejorar la usabilidad de nuestra web: Metodologías y técnicas

Cómo mejorar la usabilidad de nuestra web: Metodologías y técnicas Usabilidad web Cómo mejorar la usabilidad de nuestra web: Metodologías y técnicas En apartados anteriores se ha visto la gran importancia de la usabilidad y la experiencia de usuario cuando tratamos temas

Más detalles

SCRUM Metodología de trabajo ágil

SCRUM Metodología de trabajo ágil SCRUM Metodología de trabajo ágil UN ENFOQUE PRÁCTICO Página 1 Página 2 Índice Introducción Características Criterios de referencia Fortalezas de Scrum Trazabilidad Definición Tipos Los Sprint Prácticas

Más detalles

ADONDE NO LLEGA LA TÉCNICA: LA ACTITUD DEL MEDIADOR

ADONDE NO LLEGA LA TÉCNICA: LA ACTITUD DEL MEDIADOR Carme Hernández García ADONDE NO LLEGA LA TÉCNICA: LA ACTITUD DEL MEDIADOR Cuando pensamos en aprender a mediar, normalmente en lo que estamos pensando es en la técnica, en cómo mediar; y cuando hemos

Más detalles

Microsoft Dynamics Sure Step Fundamentos

Microsoft Dynamics Sure Step Fundamentos Fundamentos 06-10-2015/Serie Microsoft Dynamics Sure Step Proyectos Ágiles / Octubre 2015 Rosana Sánchez CCRM: @rosana-sanchez-2 Twitter: @rosansasanchez6 Correo: ingrossanbar@hotmail.com ingrossanbar@gmail.com

Más detalles

Febrero 2010. Scrum: Desarrollado y mantenido por Ken Schwaber y Jeff Sutherland

Febrero 2010. Scrum: Desarrollado y mantenido por Ken Schwaber y Jeff Sutherland Febrero 2010 Scrum: Desarrollado y mantenido por Ken Schwaber y Jeff Sutherland Agradecimientos General Scrum se basa en buenas prácticas aceptadas por la industria, usadas y probadas durante décadas.

Más detalles

Favorecer la confianza en uno/a mismo y en el otro/a. Estimular la cooperación y el sentido del equilibrio. Dividirse en parejas.

Favorecer la confianza en uno/a mismo y en el otro/a. Estimular la cooperación y el sentido del equilibrio. Dividirse en parejas. Construir la confianza dentro del grupo es importante, tanto para fomentar las actitudes de solidaridad y la propia dimensión de grupo, como para prepararse par un trabajo en común. Antes de empezar a

Más detalles

Tema II Métodos Ágiles

Tema II Métodos Ágiles Tema II Métodos Ágiles Dr. Javier Garzás javier.garzas@urjc.es Universidad Rey Juan Carlos ÍNDICE 1 METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS HÍBRIDAS 3 SCRUM 4 PRÁCTICAS ÁGILES 5 OTRAS METODOLOGÍAS

Más detalles

4 a 8 semanas. Equipos pequeños 5 a 9 miembros. Informal. Cara a cara. En cada entrega el cliente dará su aportación. Sólo documentación básica

4 a 8 semanas. Equipos pequeños 5 a 9 miembros. Informal. Cara a cara. En cada entrega el cliente dará su aportación. Sólo documentación básica Tiempo para cada iteración recomendado ASD 4 a 8 semanas AUP Primeras iteraciones más tiempo que las demás. Tamaño del equipo Equipos pequeños 5 a 9 miembros Todos los tamaños Comunicación en el equipo

Más detalles

CUESTIONARIO DE AUTOEVALUACIÓN DE LOS HÁBITOS EMPRENDEDORES

CUESTIONARIO DE AUTOEVALUACIÓN DE LOS HÁBITOS EMPRENDEDORES CUESTIONARIO DE AUTOEVALUACIÓN DE LOS HÁBITOS EMPRENDEDORES INSTRUCCIONES:. Este cuestionario consta de 55 declaraciones breves. Lee cuidadosamente cada declaración y decide cuál te describe de forma más

Más detalles

Documento de análisis y especificación Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil

Documento de análisis y especificación Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil Documento de análisis y especificación Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil 05/04/2014 Ingeniería de Sistemas - PUJ Juan Darío Murcia

Más detalles

HERRAMIENTAS DE BÚSQUEDA DE EMPLEO

HERRAMIENTAS DE BÚSQUEDA DE EMPLEO HERRAMIENTAS DE BÚSQUEDA DE EMPLEO EL TELÉFONO ÍNDICE DE CONTENIDOS I. OBJETIVOS GENERALES... 2 II. OBJETIVOS ESPECÍFICOS... 2 III. CONTENIDOS TEÓRICOS... 3 1. El teléfono como herramienta de búsqueda

Más detalles

Cualquier anuncio o volante similar a este texto usualmente genera un número masivo de llamadas telefónicas.

Cualquier anuncio o volante similar a este texto usualmente genera un número masivo de llamadas telefónicas. EN PERIODICOS Y VOLANTES Reclutar distribuidores por esta vía es muy fácil, usualmente usamos textos que ofrecen salarios muy altos para empleados de medio tiempo y usar las palabras "medio tiempo" es

Más detalles

Guia Nexus. La Guía Definitiva de Nexus: El exoesqueleto del Desarrollo de Scrum Escalable. Desarrollado y mantenido por Ken Schwaber y Scrum.

Guia Nexus. La Guía Definitiva de Nexus: El exoesqueleto del Desarrollo de Scrum Escalable. Desarrollado y mantenido por Ken Schwaber y Scrum. Guia Nexus La Guía Definitiva de Nexus: El exoesqueleto del Desarrollo de Scrum Escalable Desarrollado y mantenido por Ken Schwaber y Scrum.org Agosto 2015 Contenido Vision General de Nexus... 2 Proposito

Más detalles

Qué es scrum? scrumshortcuts.com

Qué es scrum? scrumshortcuts.com Qué es scrum? scrumshortcuts.com Qué es scrum? SCRUM es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar al máximo la productividad de un equipo. La metodología scrumshortcuts.com

Más detalles

Kanban vs. Scrum. Sesión 6b. Metodologías Ágiles de Desarrollo de Software Domingo Gallardo, DCCIA, Univ. Alicante

Kanban vs. Scrum. Sesión 6b. Metodologías Ágiles de Desarrollo de Software Domingo Gallardo, DCCIA, Univ. Alicante Kanban vs. Scrum Sesión 6b Libro de Henrik Kniberg y Mattias Skarin Disponible en InfoQ Muy buena comparación de ambas metodologías Contiene un ejemplo completo de aplicación de Kanban 2 Scrum prescribe

Más detalles

GRABACIÓN DE DATOS Apuntes de mecanografía

GRABACIÓN DE DATOS Apuntes de mecanografía GRABACIÓN DE DATOS Apuntes de mecanografía Página 1 El arte de la mecanografía Convertirse en un buen mecanógrafo es sólo cuestión de tiempo, entrenamiento y práctica. No requiere ninguna habilidad especial.

Más detalles

Autores: Mónica Fernanda Cortés Querales Diana Milena Blanco Moreno. Dirección: María Consuelo Franky

Autores: Mónica Fernanda Cortés Querales Diana Milena Blanco Moreno. Dirección: María Consuelo Franky Guía metodológica para la gestión de proyectos ágiles de software integrando herramientas de seguimiento de actividades, integración continua y repositorio distribuido de versiones. Autores: Mónica Fernanda

Más detalles

Charla sobre los servicios de participación remota

Charla sobre los servicios de participación remota Filiz Yilmaz:.pero que están en la comodidad de sus hogares. Mi nombre es Filiz Yilmaz, soy Directora sénior de participación y compromiso. Y les voy a contar un poco sobre los detalles de los servicios.

Más detalles

PROPUESTA PÚBLICA NACIONAL SCRUM

PROPUESTA PÚBLICA NACIONAL SCRUM BLU Concept PROPUESTA PÚBLICA NACIONAL SCRUM Mexico First Kristian Mir Cervantes Director Comercial (55) 5515-5205 5277-0371 kristian.mir@blu.com.mx www.blu.com.mx Índice Descripción de la Propuesta...

Más detalles

Preparar, presentar y ganar propuestas

Preparar, presentar y ganar propuestas Preparar, presentar y ganar propuestas Una guía orientativa Francisco López, consultor 02/01/2006 (c) Francisco López, 2005 1 Índice Creatividad bien enfocada El cliente es un Cliente, no es una cuenta,

Más detalles

ASA, REY BUENO DE JUDA (C.9.3.7)

ASA, REY BUENO DE JUDA (C.9.3.7) ASA, REY BUENO DE JUDA REFERENCIA BÍBLICA: 2 Crónicas 14, 15; 1 Reyes 15:9-24 VERSÍCULO CLAVE: CONCEPTO CLAVE: "Busquen al Señor mientras puedan encontrarlo, llámenlo mientras está cerca. Que el malvado

Más detalles

Administración y Control de Proyectos II. Guía de TP. 2 Cuatrimestre de 2006 Trabajos Prácticos. Agosto de 2006 Versión 1.2

Administración y Control de Proyectos II. Guía de TP. 2 Cuatrimestre de 2006 Trabajos Prácticos. Agosto de 2006 Versión 1.2 Administración y Control de Proyectos II Guía de TP 2 Cuatrimestre de 2006 Trabajos Prácticos Agosto de 2006 Versión 1.2 Índice Introducción... 3 1 Proceso de Ventas... 5 1.1 Identificación de Relación

Más detalles

GAPS. Gestión Ágil de Proyectos de Software Manuel Angel Rubio Jiménez

GAPS. Gestión Ágil de Proyectos de Software Manuel Angel Rubio Jiménez GAPS Gestión Ágil de Proyectos de Software Manuel Angel Rubio Jiménez Borrador Borrador GAPS Gestión Ágil de Proyectos de Software Manuel Angel Rubio Jiménez Resumen Desde 2004, que comencé trabajando

Más detalles

Con estas actividades transcurriculares, se contribuye al desarrollo de las siguientes competencias:

Con estas actividades transcurriculares, se contribuye al desarrollo de las siguientes competencias: En la gruta, cada personaje tiene una responsabilidad, y Oris es el encargado de la granja. Él se encarga de distribuir las tareas y de que todo funcione correctamente en ella. El resto de los personajes

Más detalles

Arsys Backup Online Manual de Usuario

Arsys Backup Online Manual de Usuario Arsys Backup Online Manual de Usuario 1 Contenido 1. Instalación del Programa Cliente... 3 Pasos previos... 3 Instalación... 3 Configuración del acceso... 6 Ubicación del servidor de seguridad... 6 Datos

Más detalles

Bachilleres: Bustamante Dayana C.I: 22.983.709 Rodríguez Jean C. C.I: 21.169.047

Bachilleres: Bustamante Dayana C.I: 22.983.709 Rodríguez Jean C. C.I: 21.169.047 UNIVERSIDAD NACIONAL EXPERIMENTAL DE LOS LLANOS OCCIDENTALES EZEQUIEL ZAMORA Ingeniería en Informática Subproyecto: Metodología de Desarrollo del Software Semestre VII Bachilleres: Bustamante Dayana C.I:

Más detalles

Programa de Educación Sexual Integral EJERCICIOS FAMILIARES PARA QUINTO DE PRIMARIA COLEGIO VISTA HERMOSA

Programa de Educación Sexual Integral EJERCICIOS FAMILIARES PARA QUINTO DE PRIMARIA COLEGIO VISTA HERMOSA Programa de Educación Sexual Integral EJERCICIOS FAMILIARES PARA QUINTO DE PRIMARIA COLEGIO VISTA HERMOSA México, D. F., octubre de 2012. Estimados padres y madres de familia: Como recordarán, se implementará

Más detalles

REFLEXIONES ESPECIALES MES DE FEBRERO Semana vocacional

REFLEXIONES ESPECIALES MES DE FEBRERO Semana vocacional REFLEXIONES ESPECIALES MES DE FEBRERO Semana vocacional 166 LUNES QUÉ REGALO - Darles a conocer la semana vocacional. - Descubrir que muchas de las cosas de las que disfrutamos, se nos dan gratuitamente.

Más detalles