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

Tema: Retrospectiva del grupo AgileCyL: ¿Que ha ocurrido este último año? ¿Como ha funcionado el grupo? ¿Como te has sentido?

Facilitada por: Amalia Hernández
En una retrospectiva, es muy importante la participación. Te esperamos!!

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

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

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.

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

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.