Archive for the ‘Resúmenes’ Category

  • Reunión 29/03/2011

    0

    Día: 29/03/2011
    Hora: 19:30 –21:30
    Lugar: Sala 30, Centro Cívico Zona Sur, Plaza Juan de Austria – Valladolid

    Tema: GIT +SVN

     Patrocinada por: Javi Santana

    ASISTENTES

    1. Javier Santana
    2. Alvaro Lazaro
    3. Jose Da Rocha
    6. Isidro Merayo
    7. Javier Acero
    8. Javier Gamarra
    9. David Medina
    10. Julio Cesar Arenas
    11. Sergio D. C.
    12. Mario de Frutos
    13. Alvaro G. Loaisa
    14. Fernando Santa Olaya
    15. Jorge Maroto
    15. Amalia Hernandez
    16. Jorge Jimenez

    RESUMEN

    La charla/taller de hoy, consistía en hacer un acercamiento a Git, y SVN. Gracias a Javi Santana creador de Agroguia , lo hemos tenido mucho más fácil.
    Las diapositivas de la presentación están en: Git +SVN

  • II Code Kata de Agile CyL

    0

    Día: 12/02/2011
    Hora: 10:00 –14:00
    Lugar: Centro Julian Sánchez El Charro, Plaza de la Concordia – Salamanca
    Como llegar: El centro está situado detrás del Corte Ingles de Salamanca

    II Code Kata
    Nos vamos a Salamanca a disfrutar programando.

    Tenemos dos posibles ejercicios:

    Objetivo: pasar un buen rato mejorando nuestras técnicas de desarrollo de software, buscando resolver un problema a partir de TDD y Pair Programming.

    Os esperamos a todos!!!

  • Reunion 22/01/2011

    1

    Día: 22/01/2011
    Hora: 10:00 –13:30
    Lugar: Sala 26, Centro Cívico Zona Sur, Plaza Juan de Austria – Valladolid

    Taller SCM
    Aprendizaje y comparativa acerca de distintos sistemas de control de versiones: GIT, Mercurial y Plastic SCM

    ASISTENTES

    1. Javier Santana
    2. Feliz Lopez
    3. Jose Da Rocha
    6. Isidro Merayo
    7. Javier Acero
    8. Javier Gamarra
    9. Jorge
    10. Rafael Cano Parra
    11. Daniel Primo
    12. Mario de Frutos
    13. Eduardo Ferrandez
    14. Susana
    15. Pablo Santos
    15. Amalia Hernandez
    16. Jorge Jimenez

    RESUMEN

    La charla/taller de hoy, consistía en hacer un acercamiento a Git, y PlasticSCM. De la mano de Pablo Codice Software , uno de los desarrolladores de Plastic SCM lo hemos tenido mucho más fácil.

    Pablo nos ha contado los entresijos de Git, utilizando una presentación de Scott Chacon y nos ha enseñado desde dentro como funciona Git (ls -C .git), para poder entender un poco más, que estamos haciendo en realidad cuando tecleamos git commit -m “Modificado fichero”.
    Conceptos como:

    • DAG, Directed Acyclic Graph, diciendolo de manera simple es la forma en la que se almacenan los objetos Git. Todos se comprimen y se identifican por un hash SHA-1.
    • Cuatro tipos de objetos en Git:

    Blob: todos los objetos son datos
    Tree: representan los directorios
    Commit: se refiere  a un tree
    Tag: etiquetas

    Como Pablo ha comentado, la implementación de Git es una pasada, brutal. Sencilla, pero tan eficiente: la distribución de información en varios directorios, sacar datos de todos los commmit, etc…

    La charla dio para mucho más: momentos distendidos acerca del buen marketing de Git, explicación de la forma de trabajo en Codice Software  por supuesto una presentación de Plastic SCM.

    Plastic SCM, es sobre todo una herramienta gráfica.

    Las joyas de la corona de Plastic son:  la creación de ramas, mostrar la diferencias entre ramas, facilidad para crear una nueva release  (http://www.plasticscm.com/features/task-driven-development.aspx)

    Se ofreció en streaming la charla como primer experimento porque fue un poco precipitado. Parte de la grabación de la charla la podeis encontrar aqui (perdonad la calidad, mejoraremos en siguientes reuniones):

    Algunas imágenes del Taller SCM:

    Muchísimas gracias a Pablo por su charla y a todos los asistentes.

    En las cañas agiles se plantearon proyectos, reuniones, … vamos a por ellos!!

  • Reunion 29/11/2010

    0

    Día: 29/10/2010
    Hora: 19:30 – 21:30
    Lugar: Sala 30, Centro Cívico Zona Sur, Plaza Juan de Austria – Valladolid
    Posteriormente 5 valientes fueron tomar unas cañas para seguir hablando.

    AGENDA

    Motivación

    ASISTENTES

    1. Javier Santana
    2. Feliz Lopez
    3. Jose Da Rocha
    4. Dani Carrión
    5. Arancha (e Isabel nuestra benjamina)
    6. Isidro Merayo
    7. Nestor Diaz
    8. Amalia Hernandez
    9. Jorge Jimenez
    10. Alvaro García
    11. Ignacio Cruzado Nuño

    RESUMEN

    La reunión de Noviembre tenía un único tema: La motivación.

    Alvaro nos expuso el tema mediante la siguiente presentación, disponible para todos:

    La charla fue muy amena y participativa.

    Descubrimos gracias a Alvaro las teorias de la motivación:

    • Piramide de Maslow
    • Motivación-Higiene de Herzberg

    fundamentos, y como en toda teoria no compartes todo lo que muestran.

    Una parte importante de la charla discurrió acerca de la automotivación.

    Todos necesitamos una motivación que puede encontrarse en nuestro trabajo, en lo que hacemos o puede ser esta sea algo externo pero que nos llene tanto que nos lleva a encontrar la satisfacción personal. Siempre hay factores que nos influyen a la hora de buscar y encontrar la motivación.

    Se llego a plantear incluso si hay motivación por sexos en lo relativo al trabajo. Si el reconocimiento del trabajo bien hecho, como parte de la motivación, debe ser distinto en hombres y en mujeres.

    Pero con los comentarios tanto de la parte masculina como de la femenina quedo claro, que [email protected] buscamos reconocimiento al trabajo que como profesional realizas, independientemente del sexo.

    Seguimos comentando, siguiendo el hilo de las transparencias:

    • Motivación en los equipos: permitir esa independencia del equipo que sabe autogestionarse, estar atentos a las necesidades para facilitarles el trabajo. Es verdad que toda esta parte se planteó desde la visión de equipos ágiles.
    • Jefe != Lider. Cada uno comentó cual era su mejor y su peor jefe, que en algunos casos coincidían. Una reflexión al hilo fue que en muchas ocasiones nosotros mismos somos nuestros mejores y nuestros peores jefes.

    Incentivos

    Fue el otro punto fuerte de la reunión. Alvaro comentó el vídeo que Dan Pink, que para el que no lo haya visto es muy recomendable.

    ¿Que pasa con los incentivos monetarios? ¿Funciona?

    Comentamos las “horas libres” que se le otorgan al equipo, al final del sprint. ¿Como las utilizan? Pues hay de todo, desde gente que se pone a realizar mejoras para los procesos internos, o las dedica a autoformación o incluso que se dedican a Facebook.

    La charla mas o menos se dio por finalizada aquí, para continuar con unas cañas.

    Muchas gracias Alvaro por presentar este tema para aprender mas y generar debate.

  • Reunion 25/10/2010

    1

    Día: 25/10/2010
    Hora: 19:30 – 21:30
    Lugar: Sala 30, Centro Cívico Zona Sur, Plaza Juan de Austria – Valladolid
    Posteriormente en cafetería (cerveza en mano, como mandan los cánones).

    AGENDA

    1. Frecuencia quedada
    2. Calendario de trabajo
    3. Brainstorming de temas
    4. Desarrollo de Temas

    ASISTENTES

    1. Javier Santana
    2. Ignacio Cruzado
    3. Olivier Salmon
    4. Alfonso Bernal
    5. Isidro Merayo
    6. Alvaro García
    7. Jose Da Rocha

    RESUMEN

    1. Frecuencia quedada y Orden del día
    Se confirmó por parte de todos la utilidad de conocer a priori las citas y quedó aprobado la regla de quedar todos los martes de cada mes.
    Se espera reservar el Centro Cívico. En principio queda encargado el pobre Jorge, por no poder asistir ;-) .
    Se plantea la posibilidad de tocar dos temas en cada reunión: uno de Gestión y uno más Técnico, dando cobertura a las dos vertientes principales.
    En los Temas se desarrollarán PUNTOS (topics) sean teóricos, prácticos o herramientas.
    Se podría realizar algún otro SEMINARIO intensivo en algún sábado, en probable colaboración con ExeCyL.

    2. Calendario de trabajo
    Se va a intentar tener ya pre-configurados los TEMAS de las REUNIONES (tanto el técnico como el de gestión) a ser posible al menos 3 semanas antes de la reunión.
    En esta reunión (y posteriormente en el foro se completará una lista de 2 Temas al mes para que todo el mundo sepa cuándo se va a tratar qué y pueda organizarse personalmente para asistir a aquellas que le sean más afines.

    La idea sería:
    Asignar 2 Temas por mes. Esta tarea de planificación a M/P la haríamos ahora, y una única vez en la primera semana (este año de Noviembre; años posteriores podemos comenzar, al menos, un mes antes).

    Luego se entraría en un ciclo durante los meses hasta junio (incluido):

      1ª semana del mes: publicar el acta de la reunión y acabar de concretar quién desarrollará qué Punto en cada Tema (Plan).
      2ª y 3ª semanas: los voluntarios generarán algún post en el blog sobre sus topics a desarrollar (Sprint). Al final de la 3ª semana (Sábado); publicación.
      4ª semana del mes: lectura del grupo de los post: asistencia a la reunión (Demo). Repaso y discusión de los post en la reunión; la reflexión de mejora ya en la cafetería (se debería publicar con el acta de reunión las conclusiones o propuestas de mejora más interesantes)

    El verano (julio-agosto) podría convenir no considerarlo ‘hábil’ (la gente coge vacaciones y el que no tenga irá generando gusanillo para el otoño).

    El Orden del día de una reunión sería (comenzando a las 19:30 -alguien propuso adelantarlo, pero dado que no empezamos hasta las 19:50…):
    1. Breve presentación asistentes (1′ por persona).
    2. Discusión Tema técnico (40′).
    3. Discusión Tema de gestión (40′).
    4. Retrospectiva y lanzamiento de ideas de mejora a postear (5′).

    Sería importante aplicar más puntualidad a la hora de llegada, para poder aprovechar el poco tiempo disponible del CC. Para ello hay una vieja técnica consistente en pensar que tienes la reunión a las 19:15 :-P

    3. Brainstorming de Temas.
    Se plantaron los siguientes Temas, a repartir por el calendario anual

    Temas de Gestión (escritos por orden de aparición):

    • Gestión de proyectos (general; PMBok)
    • Gestión comercial
    • Dirección
    • Liderazgo
    • Gestión de equipos humanos

    Los problemas de la interfaz comercial-técnicos:

    • Gestión del tiempo
    • Gestión de calidad
    • Gestión de imprevistos
    • Gestión del conocimiento

    Temas Técnicos (en orden según se aplican en un ciclo de vida de cascada):

    • Administración de sistemas (instalación de software, seguridad, …)
    • Análisis y especificación de requisitos
    • Arquitecturas y Diseño software
    • Implementación y Codificación del software
    • Gestión de configuración (branching, merge…)
    • Pruebas

    En ambas pilas de producto se hizo una votación entre los asistentes y se seleccionaron como más deseados (en orden de votación):
    Temas de Gestión

    • Gestión de imprevistos
    • Gestión comercial
    • Gestión de equipos humanos

    Temas Técnicos:

    • Pruebas
    • Gestión de configuración

    Y se decidió dejar para el foro el debate final de cuáles en concreto encajarían en cada mes y cuales, de estos 5 son los dos seleccionados para su desarrollo y reunión en noviembre.
    Aquí no encontramos la técnica y herramienta adecuada (¿doodle?) así que salvo que alguien aporte alguna idea mejor (espero!) lo haremos por discusión en un hilo del foro.

    4. Desarrollo de Temas
    Aquí comenzamos a desarrollar los Puntos de los temas de este mes.
    Uso T=Teoría, P=Práctica, H=Herramienta

    Pruebas

    • T. Factores a tener en cuenta en la Estimación del trabajo de pruebas
    • T. Debate sobre cuándo se pueden evitar las pruebas
    • P. ATDD y BDD
    • H. Hudson
    • H. Cruise Control

    Gestión configuración

    • T. Patrones de ramas (intentar contar con Pablo Santos)
    • P. Gestión de Dependencias en Ruby y Python
    • H. PlasticSCM
    • H. Mercurial
    • Git

    Gestión de imprevistos

    • T. Cómo gestionar el conocimiento extraído de los imprevistos sucedidos
    • T. Qué hacer con tareas imprevistas y con las no-terminadas en una planificación agile-time-boxed
    • P. Revisión de historias

    Gestión de equipos:

    • T. Motivación
    • T. ¡Reunion-itis!
    • P. Resolución de conflictos
    • P. Equipos distribuidos

    Gestión comercial:

    • T. Contratos comerciales y agilismo
    • T. Validación del cliente: ¿el rol del Client-ficticio es operativo?
    • T. ROI (Return Of Inversion) de organizaciones que adopten agilismo
    • P. Mercadotecnia: métricas y argumentos que soporten el agilismo comercialmente
    • P. Comercial interno: cómo evangelizar tu propia organización.

    CONCLUSIONES

    El nombre de los temas espero que no de lugar a mucha confusión: de ser así los re-nombramos.
    Desde luego el nombre de los Puntos se puede mejorar y se pueden meter o sacar, en función de los voluntarios a desarrollarlos.

    Ahora nos queda las siguientes tareas:
    A. Asignar Temas a los meses (al menos votar las 2 de noviembre).
    B. Coger un Punto cada uno de los voluntarios y redactar un Post al respecto.
    C. Leer el trabajo de los demás.
    D. Afinar nuestro modo de trabajo.

  • Probando mi TDD

    0

    El sábado 25 de Septiembre, tuvo lugar el segundo taller práctico del grupo agilecyl.

    Fue un taller especial por muchas razones: por la gran participación de gente del grupo, por el ejercicio y porque se nos unieron tres personas de Madrid, Jose Manuel Beas, Jesús Jimenez y David Salgado.

    El taller estuvo patrocinado por Jorge Jimenez e Isidro Merayo que hicieron de maestros de ceremonias y explicaron el ejercicio. La idea surgió de una sesión de la Conferencia Agile 2010 que dieron Juan Gutierrez y Carlos Ble.

    El grupo de personas participantes se reparte por parejas y por lenguajes. Es conveniente que por cada pareja se tenga una contraria que trabaje con el mismo lenguaje.

    Hay dos ejercicios a realizar, A y B. En la primera parte del taller, dos pomodoros, cada pareja desarrolla el ejercicio que le ha tocado haciendo TDD, desconociendo el enunciado del otro. En la segunda parte del taller, cada pareja borra el desarrollo realizado y cede su ordenador al otro equipo. El objetivo es que los test, sirvan de guía para poder hacer el desarrollo. Se puede comprobar cuan buenos son los test para conseguir tener todo en verde, o yendo más allá poder entender el problema que se estaba resolviendo.

    En la retrospectiva final, salieron detalles como:

    • La diferente dificultad de los problemas
    • Cómo hacer un test sobre elementos aleatorios
    • Si no hay nombres claros de test, se ponen en verde pero no sabes lo que haces

    Fue una mañana fantástica, compartiendo ordenadores, código y la sabiduría de cada uno.

    ¿Quien patrocina la siguiente?

    Explicando el ejercicio de TDD

  • REUNION 23/06/2010

    0

    LUGAR DE ENCUENTRO

    Ciudad: Valladolid

    Hora: Desde 19:30 a 21:00
    Punto de encuentro: Cafetería Púrpura (en la parte de arriba)

    Ver mapa

    • C/ Las Mercedes, 7 (en el portal) 47006 Valladolid

    OBJETIVOS

    • Resumen y conclusiones sacadas de las sesiones a las que asistimos en CAS2010

    REFERENCIAS

    Blogs

    Podcasts

    Presentaciones

    AGENDA

    1. Presentaciones individuales
    2. Revisión de los tracks de CAS2010
    3. Retrospectiva de la reunión.
    4. Actualización de Backlog de temas para los encuentros
    ASISTENTES
    1. Jorge Jiménez Pérez
    2. Amalia Hernández García
    3. Jezabel González Diez
    4. Alvaro Garcia Loaisa
    5. Jose Antonio Da Rocha Padilla
    6. Pencho Herrero
    7. Javier Acero Guerra
    8. Susana Mielgo Fernández

    RESUMEN

    Los miembros de Agile-CyL que asistieron a la CAS2010  realizaron un resumen de la coferencia para el resto del grupo. Lo que empezó en el bar, acabo en una terraza con una charla muy productiva pues el resultado de ella es este blog que podeis leer. Ya tenemos otro lugar donde compartir nuestras experiencias.

  • I Code Kata de Agile-CyL

    2
    Día: 29/05/2010
    Hora: 10:00 - 13:30
    Lugar: Sala 24, Centro Cívico Zona Sur, Plaza Juan de Austria - Valladolid
    Objetivo: pasar un buen rato mejorando nuestras técnicas de desarrollo de software, buscando resolver un problema a partir de TDD y Pair Programming.
    NO es necesario encontrar la solución, sino discutir los caminos que nos encontremos buscando mejores soluciones.
    El lenguaje de programación no es importante.
    Requisitos: Quien tenga portátil preparado para desarrollar y con xUnit será bienvenido ( no es una sala de informática, necesitamos equipos)
    Ganas de pasarlo muy bien.
    Procedimiento:
    1. Organizarnos por parejas
    2. Trabajar en base a Pomodoros de 25 minutos, con 5 de descanso y retrospectiva
    3. Cambio de pareja para siguiente pomodoro
    Asistentes:
    1. Jorge Jiménez Pérez
    2. Amalia Hernández García
    3. José Luis Balmaseda Franco
    4. Alvaro Garcia Loaisa
    5. Javier Acero Guerra
    6. Francisco Pascual
    7. Eduardo Ferrández

    KATA: STRING CALCULATOR

    El problema a resolver es el siguiente: se parte de una cadena formada por número que están separados por comas o por nuevas
    líneas (\n). Se trata de ir haciendo la suma de los números recibidos y devolver el valor total.
    Dos cosas a tener en cuenta:

    • Si la primera línea de la cadena es de la forma “//”, entonces es posible encontrar el delimitador *. Esto es válido para cualquier cadena.
    • No se admiten números negativos.

    Esta información está en la página:

    http://blog.extracheese.org/2010/01/string-calculator-kata-in-python.html

    Pero es que además la página de Osherove nos da toda una serie de pasos para ir desarrollando
    la Kata (http://osherove.com/tdd-kata-1)

    1. Crear una calculadora sencilla con un método int Add (números de serie)
      1. El método puede tener 0, 1 ó 2 números, y devolverá su suma (para una cadena vacía devolverá 0) por ejemplo ” ” ó “1″ ó ” 1,2 “
      2. Comience con el caso más simple de prueba de una cadena vacía y luego  pasar a 1 y 2 números
      3. Debes resolver las cosas de la manera mas sencilla posible, para forzarte a escribir los test que no habías pensado
      4. Hay que refactorizar después de pasar los test.
    2. Permitir que el metodo Add trabaje con una cantidad desconocida de números
    3. Permitir que  el método Add trate con el carácter nueva línea, situado entre los números (en lugar de comas).
      1. la siguiente entrada está bien: “1 \ n2, 3″ (será igual a 6)
      2. la siguiente entrada NO se acepta: “1, \ n”
      3. Asegurar la prueba para las entradas correctas. No hay necesidad de probar para las entradas incorrectas.
    4. Permitir el método Add trabaje un delimitador diferente:
      1. Para cambiar un delimitador, el comienzo de la cadena contendrá una línea independiente que tiene este aspecto: ”/ / [delimitador] \ n [números ...]” por ejemplo “/ /; \ n1; 2″ debe devolver tres cuando el delimitadorpor defecto es ‘;’.
      2. La primera línea es opcional. Todos los escenarios deben estar soportados.
    5. Las llamadas al método Add con un número negativo deben lanzar una  excepción “Números negativos no admitidos” - y mostrar  el numero negativo. Si existen múltiples negativos, se muestran todas en el mensaje de excepción.

      Hasta aquí, si eres un novato. Continúa si puede terminar los siguientes pasos  en menos de 30 minutos.


    6. Los números superiores a 1000 deben ser ignorados. La suma 2 + 1001 = 2
    7. Los delimitadores pueden ser de cualquier longitud con el siguiente formato: “/ / [delimitador] \ n”, por ejemplo: “//*** \ n1 *** 2 *** 3 “debe devolver 6
    8. Se pueden permitir  delimitadores múltiples de esta manera: “/ / [delim1] [delim2] \ n”, por ejemplo “//[*][%] \ n1 * 2% 3 “debe devolver 6.
    9. Se pueden tratar delimitadores múltiples con una longitud superior a un char.

    RESUMEN

    El sábado 29 de Mayo de 2010, 7 valientes acudimos a realizar la I Kata del grupo Agile-CyL practicando TDD y Pair Programming ( en algún caso se practicaron trios, pero esa es otra historia), donde pudimos ejercitar nuestras habilidades (skills).
    En las refactorizaciones y en los descansos de los Pomodoros se discutió sobre el diseño que emergía a través del TDD y Edu nos abrió los ojos hacia el destino de la Kata: refactorizar y hacer test sobre los diferentes SUT( Subject Under Test) que aparecían ante nuestros ojos: la calculadora y el separador de números  (Calculator y Splitter, respectivamente).
    Y de prueba unas fotos que atestiguan lo bien que lo pasamos. De las cañas no hya pruebas gráficas pero las gambas estaban muy buenas: foto 1 y foto 2

  • REUNION 25/05/2010

    0

    LUGAR DE ENCUENTRO

    Ciudad: Valladolid

    Hora: Desde 19:30 a 21:00
    Punto de encuentro: Cafetería Púrpura (en la parte de arriba)

    Ver mapa

    • C/ Las Mercedes, 7 (en el portal) 47006 Valladolid

    OBJETIVOS

    • Conocer Extreme Programming.
    • Técnicas de trabajo en XP.
    • Actualizar la lista de temas a tratar.

    REFERENCIAS

    Extreme Programming: A Gentle Introduction.

    Extreme Programming explained de Kent Beck

    Extreme Programming en la Wikipedia

    Texto en español sobre XP

    AGENDA

    1. Presentaciones individuales
    2. Presentación de XP (promovido por Edu Ferrández)
    3. Retrospectiva de la reunión.
    4. Actualización de Backlog de temas para los encuentros
    ASISTENTES
    1. Jorge Jiménez Pérez
    2. Isidro Merayo Castellano
    3. José Luis Balmaseda Franco
    4. Amalia Hernández García
    5. Javier Acero Guerra
    6. Eduardo Ferrández
    7. Pencho Herrero
    8. Alberto Sáenz
    9. Alvaro García Loaisa
    10. Julio César Arenas
    11. Olivier Salmon

    RESUMEN

    Edu nos dio las primeras pistas sobre lo que es XP, eXtreme Programming.

    Valores de XP:

    ·         Comunicación

    ·         Simplicidad

    ·         FeedBack

    ·         Coraje (Hard Work)

    Practicas para llevar a cabo  XP:

    ·         Planificación:  user-stories que desembocan en tareas

    ·         Versiones pequeñas

    ·         Sistema metafórico:  nombrando código

    ·         Diseño simple

    ·         Testeo continuo

    ·         Refactoring

    ·         Pair Programming: dos personas sobre el mismo ordenador, creando código para otros. Es una técnica apropiada para equipos maduros, donde la persona que no teclea conserva una visión global del problema y puede aleccionar al otro. Recodar que Peer Programming no es lo mismo. Álvaro comento que él suele juntar a parejas de distintos ámbitos como Informática y Telecomunicaciones. Y estas parejas le dan buen resultado cuando el informático escribe el código y el teleco es el que tiene la capacidad para afrontar la visión del problema.  Olivier comentó el tema productividad a corto plazo frente a productividad a largo plazo. Pair Programming permite aumentar la concentración.

    ¿Cuándo realizar el cambio de parejas? Depende de la tarea que se esté realizando.

    Pair Programming es una buena técnica para enseñar aprendizaje a alguien nuevo, acerca de la forma de trabajo

    Pair Programming es ideal aplicarlo sobre nuevos procesos, sobre tareas complejas.

    ·         TDD:  Desarrollo Dirigido por Pruebas. Diseñas el código por prueba, partiendo de algo sencillo y con el mínimo código, recordad que los programadores tendemos a escribir mas código del necesario. Ventajas: una mayor fiabilidad. TDD no es aplicable en todos los proyectos.

    ·         Propiedad Colectiva del código

    ·         Integración Continua

    ·         Semanas de 40 horas de trabajo

    ·         Cliente/Usuario cercano

    ·         Estándares de Codificación

  • REUNION 13/04/2010

    0

    LUGAR DE ENCUENTRO

    Ciudad: Valladolid

    Hora: Desde 19:30 a 21:00
    Punto de encuentro: Cafetería Púrpura (en la parte de arriba)

    Ver mapa

    • C/ Las Mercedes, 7 (en el portal) 47006 Valladolid

    OBJETIVOS

    • Conocer KANBAN y sus diferencias con SCRUM.
    • Debate sobre su incorporación a nuestro trabajo actual.
    • Actualizar la lista de temas a tratar.

    REFERENCIAS

    Traducción de “Kanban vs Scrum” de Henrik Kniberg.

    Vídeo y Presentación de la charla de Agustín Yagüe en el grupo local de Madrid

    Presentación utilizada en el Encuentro

    AGENDA

    1. Presentaciones individuales
    2. Presentación de Kanban  (promovido por Jorge Jiménez)
    3. Retrospectiva de la reunión.
    4. Actualización de Backlog de temas para los encuentros

    ASISTENTES

    1. Jorge Jiménez Pérez
    2. Amalia Hernández García
    3. Jezabel González Diez
    4. Alfonso Bernal
    5. Isidro Merayo
    6. Pencho Herrero
    7. Francisco Pascual
    8. Javier Acero
    9. Olivier Salmon
    10. Alvaro García

    RESUMEN

    Nueva reunión del grupo de Agile-CyL para tratar la metodología ágil Kanban, exponente claro de los principios Lean y que fue presentada por Jorge Jiménez.
    Se abrió debate sobre la metodología desde los primeros momentos de la exposición, con lo cual fue bastante interactiva la presentación exponiendo cada uno de los presentes las dificultades y ventajas que le veían a esta metodologÌa.

    Dudas que surgieron y diferentes respuestas aportadas por los asistentes fueron:

    ¿Quién marca la velocidad? Siempre va a estar definida por la fase más lenta del workflow, compartido por todo el equipo. Por esto influye en el tiempo de entrega de las tareas.

    ¿Kanban es ajustable a nivel de tarea? No piensan en tipo de desarrollo, cascada o agil, piensas en un desarrollo constante. Olivier recalcó que lo importante es el flujo del proyecto.

    Jeza le ve un peligro cuando se dice que no es tan prescriptivo como Scrum en cuento a los equipos multifuncionales, permitiendo equipos especializados ya que cuando sólo participas en una parte del proceso, no es como scrum en que tienes una visión completa del proyecto. Es como un operario en una cadena de montaje en que sólo vas a hacer una tarea sin aprender de las demás y del resto del equipo.

    Pencho- que tiene más experiencia en sectores muy diversos aportó su visión en contraposición del símbolo de la melé en Scrum, indicando que  Kanban es como una melé abierta, en cualquier momento se pueden incorporar recursos al sistema para darle valor y mejorar el flujo según las necesidades del proyecto. Es más flexible a modificaciones del equipo.

    En soporte o mantenimiento de software la aplicación de Kanban es donde todo el mundo estaba más de acuerdo en que lo veía más ajustado. En este caso, Pencho explicó el caso de Indal como proceso industrial, en que usaban gráficas similares a las de Kanban (Cummulative Flow Chart) para en la incorporación de nuevos trabajadores meterlos en la “curva de trabajo”, es decir, en coger el ritmo para la entrega de producto en los tiempos de ciclo definidos por el proceso.

    Entregas en cualquier momento:
    - Positivo: en tener actualizaciones en cualquier momento, el tratamiento de parches sobre el producto de manera instantánea.
    - Kanban se ve poco factible en producción pero sí en mantenimiento de producto.
    - Olivier (con su gorra de cliente): si el proveedor da información de sus necesidades futuras, facilita la comunicación para estar preparado ante nuevas peticiones u órdenes de trabajo, tareas…

    Estimaciones:
    - Se usa una velocidad que puede no ser real, ya que el cycle time es valor en términos de media.
    - Hay flujo de dinero y de trabajo a la par, aunque no haya estimaciones se puede pagar por lo que se entrega.
    - Mentalidad española: no dejar que la gente utilice todo el tiempo  estimado que tiene para ese desarrollo, hay que seguir el flujo y no provocar parones.
    - Puede funcionar bien con perfiles comerciales sin objetivos a conseguir, sino que cuanto más hagas mejores recompensas tendrás, pero no marcas mínimos (ejemplo aportado por Pencho acerca del Banco Popular en los años 80 y primeros 90).
    - Malo por no tener tareas homogéneas que su resolución y el tiempo de finalización o de avance en el flujo sea muy diferente entre ellas.

    Scrum / Kanban

    Sugió el clásico problema del tratamiento de las incidencias. Una incidencia no da valor al cliente, es un error del equipo que no debe ser asumido por el cliente.
    En Scrum, Olivier comenta la posibilidad de meter un 7% del tiempo para incidencias en el Sprint, es un colchón previo antes de que aparezcan. Jorge opina que es engañar al cliente, aunque se pueda compensar entre Sprints, pero le cobras por anticipado un tiempo dedicado por tus errores. Javi trata las incidencias desde el principio, dentro de los Story Points del Sprint y asumen que las incidencias se tratan ahí, es el equipo quien se las “come”.

    Fran comentó que Kanban es teoria de colas y de procesos, sin iteraciones, sin backlog y es como el Scrum llevado al limite. Para él, al fin y al cabo, al usarlo para temas de incidencias es como reflejar en un tablero cualqueir herramienta de gestion de incidencias, como Mantis o Bugtrack.

    Alvaro dijo que hay una variante que consiste en mezclar Kanban y Scrum, con lo que se denomina Scrumban en proyectos sobre todo muy grandes, con varios cajas departamentales y varios tableros kanban.

    Pencho aboga por el uso de Kanban utilizado como metodología de trabajo para saber cómo se ha trabajado midiendo eficiencia no eficacia aunque no es necesario utilizar Kanban para realizar esas medidads.

    Comentando las diferencias entre kanban y scrum, Jezabel definía kanban para trabajos repetitivos con tiempos muy definidos, y scrum es más parecido a una consultoría artesana. Su frase que puede definir el tema de la reunión fue:
    Kanban es más una forma de trabajo de consultoría industrial mientras que Scrum es un proceso mucho más artesanal.

Page 1 of 212»