Archive for the ‘Eventos’ Category

  • Tecnicas de prototipado para aplicaciones web con Marcelino LLano

    3

    El próximo 4 de Junio en Valladolid Marcelino LLano nos estará hablando sobre “técnicas de prototipado para aplicaciones web” dentro del “tour” de interfaces amigables.

    Las charlas sobre diseño no son muy habituales y es un buen momento para aprender/afianzar las técnicas básicas de diseño para nuestras aplicaciones.

    Acerca del ponente

    MARCELINO LLANO es Ingeniero técnico en diseño industrial por la Universidad de Valladolid y Licenciado en comunicación audiovisual por la Universidad Rey Juan Carlos I de Madrid. Tiene más de ocho años de experiencia en el desarrollo de aplicaciones web y ha trabajado en redes sociales como Tuenti Technologies.

    Logística

    Día: Sábado, 4 de Junio del 2011

    Hora: 10:00 a 13:30

    Lugar: Centro Cívico Zona Sur - Sala 31 – Valladolid

  • REUNION 1/06/2011

    2

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

    Tema: Historias de Usuario: la esencia del valor de lo que voy a construir.

    ASISTENTES

    1. Juan Ignacio Sánchez Lara
    2. Ignacio Cruzado Nuño
    3. Fernando Santa Olaya
    4. Javier Santana
    5. Javier Gamarra
    6. Rafa Morón
    7. Mario de Frutos

    RESUMEN

    En este taller se ha tratado las siguientes cuestiones:

    • ¿Qué es una historia de usuario?
    • ¿Cómo escribo mis historias de usuario?
    • ¿Qué formato de tarjetas utilizo?
    • ¿Qué es un DoD y cómo escribimos los DoD?

    Comenzamos poniendo en común, todos los que habíamos trabajado con historias de usuario, qué eran para nosotros. En general todos coincidimos en su utilización como instrumento para la definición de las características de la nueva aplicación en un lenguaje natural para el PO y de forma colaborativa.

    Una vez que se dejó más o menos claro el qué era, pasamos al cómo escribimos cada uno en nuestra empresa las historias de usuario. En este punto la mayor parte coincidía en utilizar el formato estándar “Como [rol] quiero [funcionalidad] para [valor de negocio]” para describir la funcionalidad de la historia de usuario.

    Respecto al formato de tarjetas utilizado, se expuso el formato que utilizaba cada persona en su empresa. Los puntos que se expusieron fueron los siguientes:

    • Descripción de la historia de usuario siguiendo el formato indicado anteriormente.
    • Estimación en puntos de historia.
    • Persona que ha introducido la historia en el Backlog.
    • Fecha en la que se introdujo la historia
    • Persona que la “promociona” para ver quién la paga.
    • DoD en la parte de atrás de la tarjeta.

    Por último se explicó lo que era un DoD (Definition of Done) a los asistentes que no lo sabían y se sacaron las siguientes conclusiones:

    • Es el compromiso que el PO adquiere con la historia de usuario ya que se definen las reglas de aceptación de dicha historia
    • Hacer los DoD ha de ser una tarea colaborativa, sobre todo al principio ya que cuesta bastante a los PO.
    • Es algo muy importante para que el proyecto vaya por buen camino y se pueda validar que la historia está correctamente implementada.
    • Se puede sacar un guión aproximado de cómo debe funcionar la Demo a la hora de mostrarla.
  • Code Retreat con Enrique Comba Riepenhaunsen

    0

    Pero, ¿en qué consiste un CodeRetreat?

    Un Code Retreat es en realidad un día de diversión y aprendizaje. Durante un dia, programaremos de manera repetitiva un problema, practicando TDD (Test Driven Development), PP (Pair Programing)  y mejoras continuas sobre nuestro código ayudados por nuestro facilitador, Enrique Comba. Muchisimas gracias, Enrique!

    PROSPECTO de un Code Retreat

    Ingredientes

    • Problema a resolver: El juego de la vida de Conway
    • Día: 7 de Mayo de 2011
    • Horario: 9:00 a 19:00
    • Duración de cada pomodoro: 45 minutos
    • Portátil: trae tu arma de trabajo
    • Lenguaje: el que cada pareja decida para trabajar de forma cómoda

    Indicaciones

    Mediante Pair Programing, compartiendo conocimiento, se atacará el problema de Conway, ayudados por las indicaciones de nuestro facilitador.
    Se realizarán pomodoros de 45 minutos de duración y al final de los mismos 10 minutos de descanso y reflexión en común sobre el pomodoro ejecutado.
    Todo el código se borra al final de cada sesión y se realiza un cambio de pareja. La forma óptima de trabajo es usando TDD (Test Driven Development).

    Contraindicaciones

    Un Code Retreat es una actividad en la que se comparte y se aprende, no realizarlo si estas solo.

    Posología

    La administración de un Code Retreat se hace utilizando todos los sentidos:

    1. Vista: para ver lo que estamos escribiendo.
    2. Oido: escuchando las indicaciones de nuestro compañero en la sesión y del facilitador.
    3. Gusto: saboreando con TDD como se pasa de rojo a verde, refactorizamos y vuelta a iniciar el proceso.
    4. Tacto: deslizando nuestros dedos por todo el teclado.
    5. Olfato: estando atentos a esos “olores” en el código: nombrado, refactor, etc.

    Efectos secundarios

    Durante la realización del Code Retreat usted puede experimentar varios estados: alegría, frustración, desesperación, euforia. Pero al final tendrá lo que se viene a denominar como cansancio feliz y satisfacción.

    Intoxicación

    Los casos de intoxicación se resuelven con la realización de Katas, Coding Dojos y sobre todo con la práctica individual y constante en la soledad de nuestro dominio.


    LANZAMIENTO
    Próximamente se pondrán a disposición los tickets para el evento y se anunciará en el blog y en twitter

    PATROCINADORES
    Muchísimas gracias a nuestros patrocinadores, sin ellos no seria posible


    Wellness Telecom Agroguia
    EAM Kubbos
    Wiseri
  • Coding Dojo en Segovia

    4

    Tenemos la suerte de estar en una comunidad, Castilla y León formada por muchas provincias en las cuales hay mucha gente con ganas e ilusión.
    Desde Segovia, Javier Garcia Garrido , se ha lanzado y nos propone Coding Dojo todos los últimos viernes de cada mes

    Sitio: Escuela de Informática de Segovia

    Ver mapa más grande
    Cuando: Viernes 25 de Marzo de 2011
    Horario: 16:00 a 19:00
    Practicamos: La kata del mes de 12Meses12Katas

    Os esperamos a todos!!!

  • All Together Now!! Un producto en 48horas

    3

    Siempre has tenido esa idea rondándote la cabeza, ese pequeño producto o servicio que podría funcionar, pero nunca tienes tiempo, siempre tienes dudas… imaginate que puedes plantar la semilla e intentarlo en un fin de semana, junto con otra gente que está haciendo lo mismo que tú, en una casa rural.

    De eso se trata “All together now!!”. desarrollar un producto, servicio o lo que te de la gana en 48 horas.  El compromiso es tener lo que hayamos definido el primer día en ese periodo de tiempo, aunque sea poca la funcionalidad definida a desarrollar.

    Un producto, servicio o cualquier otra cosa funcional requiere mucho más tiempo, lo sabemos, pero un ejercicio de este tipo, además que puedes obtener un prototipo más o menos funcionar, tiene los siguientes objetivos:

    Las restricciones son buenas: en este caso son temporales, nos ayudan a estar enfocados, olvidarnos de los “ruidos” y te exigen soluciones creativas.

    Aprender a decir NO. Con poco tiempo debes simplificar al máximo lo que tienes y tomar decisiones de diseño/desarrollo.

    - Aprender a planificar. En 48 horas no da tiempo a demasiado, así que debes planificar bien tu tiempo.

    - Mejorar el trabajo en equipo: auto-organización

    - Aplicar los conceptos ágiles que promulgamos. Ya hemos hecho katas, practicado el TDD… es hora de aplicarlo a un caso real.

    - Pásalo bien y aprende de los demás. Ver trabajar a los demás es una fuente de conocimiento.

    Reglas:

    - Hacer un producto/aplicación/servicio/utilidad en 48 horas.

    - Se puede participar solo o acompañado en grupos pequeños (preferible para que el ejercicio tenga su interés).

    - El plazo empieza el viernes tarde y acaba el domingo por la tarde, 48 horas.

    - Todo lo que se haga debe estar hecho en ese fin de semana. No obstante ideas, bocetos, servidores, sdks, ide’s, tracker, pomodoros, planificación o lo que sea que necesites para hacerla puede estar preparado. Eso sí, el desarrollo de la idea debe estar hecha en el fin de semana.

    - Una vez terminado se presentará a los demás y se hará una retrospectiva.

    Logística:

    - Juntarnos en una casa rural aquellos que se apunten (ver spreadsheet más abajo). Hay límite de plazas como es evidente, los equipos no pueden ser de más de 4-5 personas.

    - No está patrocinado, así que corremos con los gastos todos los participantes.

    Cómo apuntarse:

    Evidentemente hay un límite de plazas. Por eso se pone a disposición de los interesados esta hoja:

    https://spreadsheets.google.com/ccc?key=0AovZrezMtz3JdDhLR3pUOXZJV3Y2eWhBUGpuVUNlYkE&hl=en&authkey=COPkrfQL

    Donde tenéis:

    - Personas

    - Proyectos

    - Fechas

    - Casas

    En la hoja Proyectos del spreadsheet está el título de la propuesta, cada promotor deberá escribir una entrada en la lista para explicar su propuesta y poder contestar las preguntas que surjan.

    alguien quiere negociar/buscar otras casas rurales puede añadirlas. Las condiciones son: cercanas a Valladolid (sorry por el centralismo) y que tengan espacio suficiente para poder trabajar unas 10 personas o algo más, pero con mesas suficientes (las casas puestas tienen salón y bodega, son amplias y podrían cubrir nuestras condiciones).

    Internet Si /NO. Sería un valor añadido si tenemos conexión, pero no para twitear, ni perder el tiempo, sino como recurso que se pueda necesitar para resolver alguna duda (consulta de API’s, dudas técnicas…). El que quiera hacer uso de Twitter, FB, o cualquier otra red social lo hará bajo penalización a su equipo y su responsabilidad. Hay que estar enfocados.Fechas:

    Fechas

    Hasta el 20 de febrero del 2011 está abierto el plazo de inscripción y votación. Ese día a las 23:59 se cierra el plazo.

    A partir de ese día se anunciarán el resto de fechas.

    Ejemplos

    Ejemplos de otras iniciativas parecidas a esta, con el objetivo de crear aplicaciones en 48 horas.

    rails rumble: anual, para aplicaciones hechas en rails.
    gamejam: creación de un videojuego en 48h. normalmente fijan una temática de la que uno no puede salirse.
    djangodash: lo mismo que railsrumble pero para django
    abredatos: concurso para crear una aplicación en 48h con datos públicos

    Que no se diga que en Castilla y León no tenemos buenos técnicos, gente con ganas y capacidad para hacer cosas :)

    Por último, si tienes alguna duda o sugerencia puedes hacerlo en los comentarios o en el hilo de la lista de correo de agilecyl.

  • 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!!!

  • 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

  • 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

Page 2 of 2«12