Archivo de la categoría: Sin categoría

Enlace

testingDays

Seguimos con los PucelaTestingDays! 

Esta vez nos centramos en los lenguajes de programación PHP y Java. Isidro Merayo hablará sobre Testing en PHP e incluirá una parte de taller práctico. Adjuntamos los requisitos para el taller un poco más abajo. Jorge Jimenez nos enseñará cómo utilizar Geb. Geb es una solución para hacer tests funcionales/web/aceptacion a través de frameworks como Spock, Junit & TestNG.

cartel-testing-days

Ya puedes apuntarte a la 2º charla => “Testing en PHP y Test funcionales con Java y Geb” desde el siguiente enlace:

Eventbrite - katayuno 5 de octubre 2013 Valladolid

 

Charla: Testing en PHP y Test funcionales con Java y Geb

Día: 23/11/2013
Hora: 10:00 – 14:00
LugarAgencia de Innovación y Desarrollo Económico – Valladolid

 

Entorno necesario para el taller de PHP:

Instalar paquetes y configuración básica
========================================

Utilidades
----------

root@vm-taller:~# apt-get install curl tree
root@vm-taller:~# apt-get install vim vim-gtk
root@vm-taller:~# aptitude install git gitg meld
root@vm-taller:~# aptitude install graphviz graphviz-dev

PHP (recomendable 5.4+)
-----------------------

root@vm-taller:~# apt-get install php5 php5-cli php-pear php5-mysql php5-sqlite php5-xdebug php5-json php5-curl php5-xsl

Composer
--------
root@vm-taller:/usr/local/bin# curl -sS https://getcomposer.org/installer | php
root@vm-taller:/usr/local/bin# ln -s composer.phar composer

PEAR
----
root@vm-taller:~# pear update-channels
root@vm-taller:~# pear upgrade-all
Nothing to upgrade-all

PHPQATools
----------

root@vm-taller:~# pear config-set auto_discover 1
config-set succeeded
root@vm-taller:~# pear install pear.phpqatools.org/phpqatools
root@vm-taller:~# pear channel-discover pear.phpdoc.org
root@vm-taller:~# pear install phpdoc/phpDocumentor

Java - OpenJDK
--------------

root@vm-taller:~# apt-get install openjdk-7-jdk openjdk-7-jre openjdk-7-doc
root@vm-taller:~# apt-get install maven ant

Jenkins
-------

root@vm-taller:~# aptitude install jenkins

Intalar plugins: Seguir las instrucciones de http://jenkins-php.org/ (añadimos un SCM como Git)

(se puede hacer como usuario sin privilegios)

taller@vm-taller:~$ wget http://localhost:8080/jnlpJars/jenkins-cli.jar
taller@vm-taller:~$ java -jar jenkins-cli.jar -s http://localhost:8080 install-plugin checkstyle cloverphp dry htmlpublisher jdepend plot pmd violations xunit git
taller@vm-taller:~$ java -jar jenkins-cli.jar -s http://localhost:8080 safe-restart
taller@vm-taller:~$ curl https://raw.github.com/sebastianbergmann/php-jenkins-template/master/config.xml | java -jar jenkins-cli.jar -s http://localhost:8080 create-job php-template
taller@vm-taller:~$ java -jar jenkins-cli.jar -s http://localhost:8080 reload-configuration

Creando proyecto con simple_php_skeleton
========================================
$ git clone https://github.com/isidromerayo/agilecyl_ptd_php_kata
$ cd agilecyl_ptd_php_kata
$ composer install --prefer-dist

Hay una máquina virtual configurada configurada como se indican en la instrucciones, con Virtual Box.

Datos

usuario: taller
contraseña: agilecyl

Primer katayuno 2013

¿Esta entre tus propósitos de año nuevo practicar TDD, reflexionar sobre la mejor estrategia para resolver un problema y mejorar como desarrollador? Seguro que sí. Por esto contamos contigo la mañana del 9 de Febrero para el primer katayuno del año 2013. Comencemos bien el año.

Y como primera kata, las torres de Hannoi :)  El enunciado en http://www.solveet.com/exercises/Torres-de-Hannoi/72

¡Te esperamos!

Tienes más información sobre los katayunos  en http://www.katayunos.com.

Día: 09/02/2012
Hora: 10:00 – 13:30 (apertura de puertas 9:45)
LugarAgencia de Innovación y Desarrollo Económico – Valladolid

 

 

Eventbrite - Katayuno 9 de Febrero en Valladolid

El camino hacia publicar un app

Desde AgileCyL queremos ofreceros la charla ‘El camino hacia publicar un app’. (Caso de éxito emprendiendo desarrollando software para móviles). 

Esta charla ha sido admitida en la prestigiosa conferencia internacional Droidcon y en ella se repasan algunos de los conceptos, ideas y enfoques que le han ayudado al éxito.

Tiene una duración de unos 30′ de exposición, para pasar al debate.

El objetivo de la reunión es lograr una alta interacción entre el ponente y el público para transferir conocimiento y experiencias, debatir constructivamente.


Ponente

Raúl Portales es un emprendedor de origen castellano-leonés.

Tras cursar estudios universitarios en la Universidad de Valladolid de Ingeniería en Informática e Ingeniería de Telecomunciaciones, comenzó su carrera profesional trabajando por cuenta ajena en diversas empresas de la región.

Más tarde continuó en el extranjero, para finalmente lanzarse a emprender con éxito, en varias iniciativas relacionadas con el Desarrollo del Software, siguiendo el enfoque del Manifiesto Agil.

Actualmente es el CEO de PlattySoft, empresa afincada en Holanda dedicada al Desarrollo del Software para Android, tanto projectos propios (incluyendo varios videojuegos) como externos.


Formato

Seguirá el fomato habitual de las reuniones del grupo AgileCyL:

  • Presentación del ponente y asistentes
  • Charla temática
  • Turno de preguntas y Debate
  • Networking y Cañas en lugar adyacente al de la reunión [Sólo asistentes presenciales]


Asistencia online

En esta ocasión, el ponente de la charla no estará físicamente en la sala, ya que reside en el extranjero.

Para paliarlo, la charla va a ser emitida con Hangout on Air.

Esto permite que los asistentes interesados en atender, pero no puedan asistir, podrán acceder por medio de un enlace que se publicará en esta misma página.

Para asistir por este medio se ruega inscribirse, mediante el ticket online.

No obstante, recomendamos a todo el que pueda asistir físicamente lo haga, ya que el networking posterior es uno de los valores principales de las reuniones de AgileCyL.

Día: 25/09/2012
Hora: 19:30 – 21:30
Lugar: Agencia de Innovación y Desarrollo Económico – Valladolid


Eventbrite - El camino hacia publicar un app

Agile Tour Universidades 2012 (Abril)

Después del éxito cosechado en las Universidades de Segovia, Valladolid y Salamanca, continuamos nuestro periplo por Castilla Y León.
Muchísimas gracias a los asistentes de todas y cada una de las ciudades.

Ahora aterrizamos en Burgos.
En esta ocasión contamos con dos pesos pesados de Agile Zona Norte: Jose Ramón Diaz y Jessica Aguado. Es un honor y una satisfacción contar con los dos.

El tema es muy interesante y seguro que no deja indiferente.


Desarrollo de software: Tirando muros, levantando puentes

¿Que es lo que mueve al mundo? ¡El amor! Vale… pero… ¿qué es lo que realmente lo controla? ¡El software!
El desarrollo de software va más allá de lo que nos enseñan en la facultad de informática. Más allá de computación numérica, ingeniería del software y arquitectura de computadores, necesitamos habilidades que debemos desarrollar en nuestra carrera profesional. Así seremos capaces de entrar en un ciclo de mejora continua. Nos centraremos en lo más importante: en las personas. Nos centraremos en la colaboración con el cliente y en la respuesta al cambio. Objetivos: crear software de calidad y la felicidad. Movamos el mundo.

Día: 18/04/2012
Hora: 12:30 –14:00
Lugar: Escuela Politécnica Superior, Edificio C.
C/Francisco de Vitoria s/n
09006 Burgos

Eventbrite - Desarrollo de software: Tirando muros, levantando puentes

Os esperamos a todos en Burgos.

Agile Games – Reunión 28/02/2012

Para transmitir enseñanzas, principios y conceptos, no hay otra forma mejor de aprenderlos que jugando!

Cuando estás jugando, fijas técnicas y conocimientos gracias a las estimulaciones que el juego provoca y que tu mandas al cerebro. El aprendizaje siempre es mucho más fuerte, cuando aprendes algo haciendolo, fija mucho mejor a la memoria los conceptos y por más tiempo. Y todo esto aparte de pasar un rato muy divertido ;)

En este taller, veremos una serie de divertidos juegos que nos ayudarán a enseñar y transmitir distintos aspectos referidos a conceptos del desarrollo ágil. Estos juegos ayudan a facilitar la adopción de los conceptos ágiles, de una manera interactiva y divertida.

 

Tema: Agile Games
patrocinado por: Amalia y Álvaro

Día: 28/02/2012
Hora: 19:30 –21:00

LugarAgencia de Innovación y Desarrollo Económico – Valladolid

 

 

 

 

 

 

 

 

Taller de Groovy

Si os creíais que para Julio desde AgileCyL no habíamos preparado nada, os habéis equivocado!!

Tenemos preparado nada mas y nada menos que un “Taller de Groovy y Grails”  YEEEEE!!!! Interesante!!! con Alberto Vilches que tratará de evangelizarnos un poco con una introducción a este nuevo sistema de desarrollo rápido de aplicaciones. Para ello tenemos preparado, además, un regalo para que os lo llevéis puesto a casa: la programación de una aplicación con autenticación basada en Twitter/OAuth y con Google/OpenID. Así que no olvidéis traeros el portátil porque vamos a programar.

Aconsejamos a todos los desarrolladores, que no se lo pierdan! (En especial a los que estén cansados de tardar tanto en hacer las cosas con Java ;-) )

Así que ya sabéis, el Sábado 2 de Julio no hagáis más planes!!

Día: 2 de Julio

Hora: 10:00 am

Lugar: Agencia de Innovación y Desarrollo Económico Sala 3

Reunion 26/04/2011

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

Tema: ¿Existen los Product Owner? Mitos y realidades…

Patrocinada por: Amalia Hernández y CIA

ASISTENTES

1. Julio Cesar Arenas
2. Rafa
3. Jose Da Rocha
4.  Ignacio Cruzado Nuño
5. Javier Gamarra
6. David Medina
7. Julio Cesar Arenas
8. Santi
9. Mario de Frutos
10. Alvaro G. Loaisa
11. Fernando Santa Olaya
12. Jorge Jimenez
13. Amalia Hernandez

RESUMEN

La charla/taller de hoy, consistía en hacer un acercamiento al Product Owner.
El primer interrogante que nos planteamos es como considerar al product owner, ¿Cerdo o gallina? ¿comprometido o involucrado?

A partir de aqui, se abrió el debate:

  1. ¿Es deseable un PO técnico?
  2. Responsabilidad compartida, cuando no se cumple el sprint
  3. Relación PO- SM
  4. Labores del PO: redacción de las Historias de usuario, DoD, planificación de entregas, priorizacion
  5. ¿En que reuniones debe estar un PO?

Tras una interesante charla se sacaron los siguientes puntos como conclusión.

Estas son las cualidades, labores de un PO:

  1. Sinceridad: tanto con el cliente, como con el equipo para mantener la confianza
  2. Ayudar en la redacción de las Historias de Usuario
  3. Saber definir DoD: tener claro que es lo que quiero
  4. Priorizar las Historias de Usuario
  5. Ser transparentes, fomentar la colaboración
  6. Respeto al time-boxing
  7. Disponibilidad para resolver dudas. Ser capaz de ofrecer al equipo un backlog con propuestas de mejora
  8. Tener perspectiva de usuario, visión de mercado y capacidad de decisión.

Recortes – el arma secreta en proyectos

Esta entrada va de “recortar”, de quitar funcionalidad en un producto/proyecto y de cómo mediante esa técnica podemos intentar conseguir mantener los proyectos bajo control.

¿De dónde viene esto de recortar?

La primera vez que leí sobre esto fue en uno de mis libros favoritos sobre gestión de proyectos: “Rapid Application Development” de McConnell (también quizá mi autor preferido). Hablaba del concepto de triage que creo que tiene una traducción difícil pero viene a ser algo así como decidir a quién salvar y a quién no basándose en la gravedad de sus heridas cuando hay una catástrofe, conflicto, etc. El caso es que McConnell explicaba el triage como una forma de decidir qué entra y que no en un proyecto en un momento dado.
Puede parecer evidente pero ese concepto marcó la diferencia para mí: hasta entonces todo el tema de planificación, estimación y demás siempre acababa chocando con la idea de trabajar más horas para poder encajarlo todo y que diera tiempo. Esta idea lo cambiaba todo: deja cosas fuera. Así de simple.
Claro, McConnell dice que hay veces en las que es más importante entregar a tiempo aunque falten funcionalidades, que no llegar para nada. Una idea interesante que además es prácticamente la clave de todos los métodos ágiles, el desarrollo incremental, etc, etc.
En mi opinión (especialmente en desarrollo de productos, pero creo que también en proyectos porque siempre abre las puertas a la negociación) es siempre mejor poder entregar 3 funcionalidades completas en un momento dado que no poder entregar absolutamente nada porque tenemos 5 a medias. Abre las puertas a poder sacar un producto antes que la competencia (esto lo menciona McConnell en su libro), a poder negociar con el cliente (oye, tenemos 3 características listas para poner en producción, con esto podéis empezar a trabajar perfectamente porque lo que falta son puntos adicionales… y con esto comenzar a facturar) y a tener una solución de respaldo en el equipo (cubrirte las espaldas estando siempre, o casi, listo para la entrega).

Recortar siempre funciona

Me he puesto a escribir esto porque el otro día apliqué, de forma casual, esta misma técnica en la vida real, y funcionó bien: estábamos visitando una serie de sitios y comenzaba a hacerse tarde. Nos faltaba un único lugar por ver y posiblemente nos daría tiempo a visitarlo deprisa pero, decidimos dejarlo para otra ocasión y regresar. Vamos, eran las 6 y algo de la tarde, teníamos una hora y pico de vuelta hasta el punto de partida y en lugar de continuar volvimos.
La primera idea que me pasó por la cabeza fue: “¿y qué hacemos el resto de la tarde?”. Porque claro, veía que al final nos iba a sobrar tiempo si no visitábamos ese último sitio… que sería una “pérdida de tiempo”. Al final dimos la vuelta, como dije, pero: en lugar de a las 6 y pico eran casi las 7 cuando comenzamos el regreso, llegamos en algo más de una hora, las 8 y algo, así que no “sobró tiempo” precisamente (siempre hay algo que se complica), y sin embargo nos dio tiempo a volver sin prisa y nos dimos cuenta que de ninguna forma podríamos haber visto el último sitio. Nos dio tiempo a volver, cenar tranquilamente, dar una vuelta… vamos, un buen plan para un fin de semana tranquilo.
¿A dónde voy con esto? Pues que la primera impresión cuando quitas una característica de un SPRINT y dejas algo de holgura es: “qué vamos a hacer con el tiempo que sobra?”. Se crea como una cierta sensación de “desasosiego” en la cual se tiende a pensar que vamos a acabar con los brazos cruzados arrepintiéndonos de no haber metido la característica XXX. Al final, desgraciadamente (o no), eso nunca pasa: las cosas se alargan un poco, siempre se tarda algo más de lo esperado y el haber quitado esa característica nos permite llegar al final del camino en condiciones en lugar de con la lengua fuera y con cosas a medias (como el último punto del camino visitado en 10 minutos en lugar de con calma).

Recortar es la principal herramienta para maniobrar el proyecto

Siguiendo con el mismo autor, en “Software Estimation: Demystifying the Black Art” McConnell cuenta que gestionar un proyecto es posible cuando la diferencia entre la estimación y el tiempo disponible es menor de un 20%. Por encima de esa diferencia el proyecto simplemente es imposible (proyecto suicida, por cierto, otro buen libro sobre este tipo de proyectos es Dead March, de Yourdon, otro clásico), y o se cambian los objetivos o mejor no meterse (o asumir en dónde estamos). Precisamente cuando esto ocurre (y hay muchos más dead march de los que pensamos) estar preparados como equipo y gestionar las funcionalidades a implementar correctamente (cubrirnos las espaldas entregando de forma incremental) puede ser totalmente clave.
Al final recortar puede ser postponer para una siguiente versión, pero quitar de la actual a fin de cuentas.

El impacto del recorte

Hay un aspecto de esto de recortar que me preocupa especialmente y no es el impacto que puede tener en el resto de gente implicada en el proyecto (directivos, clientes, dptos. de marketing, etc), sino el que tiene en el propio equipo de desarrollo.
Los desarrolladores, por alguna razón, (para dar más bibliografía recomendaría el clásico Peopleware), somos demasiado optimistas (de ahí que la Ley de Parkinson, vamos, que el trabajo siempre se extiende hasta ocupar todo el tiempo disponible, no se aplique al desarrollo, y de ahí que como muy bien dice McConnell en “black art”, el problema de la industria de software no sea de “estimación” sino de “subestimación”. Nunca te preocupes por sobrestimar, si los desarrolladores tienen tiempo de sobra, terminarán igualmente a tiempo. Ignorar este punto supongo que crea enormes quebraderos a todos los “jefes de proyecto”…). Como iba diciendo, que somos muy optimistas y siempre pensamos que nos va a dar tiempo a terminar todo, y lo que es peor, nos sentimos mal si nos dejamos algo fuera. De hecho el sentimiento inicial ante el recorte es algo así como de “culpabilidad” ya que el equipo siente que “está haciendo trampa”. Y no es fácil superar ese sentimiento. Hay que explicarlo, hay que coger un poco de distancia, hay que priorizar, y hay que entender que tenemos limitaciones claras de tiempo y de personal y que hay que hacer lo que mejor se pueda con lo que tenemos. Y que para eso hay que recortar.
No sé si esto parece una tontería o no, pero la realidad es que es un punto muy a tener en cuenta para que el desarrollo no se descontrole debido a la desmoralización del equipo.
Siempre me viene a la mente el tema de “ingeniería vs ciencia” o lo de “empresa vs universidad”. Me explico: la tendencia natural de muchos de nosotros es la de intentar lograr la solución perfecta (al menos la que creemos que lo es), lo que normalmente es una aproximación muy buena desde el punto de vista “científico” (o de práctica universitaria) y nos sentimos mal ante la solución “de compromiso”: hacerlo lo mejor que puedas teniendo en cuenta que lo importante es respetar las restricciones del proyecto, y el tiempo suele ser la mayor de ellas. Esto último es casi la definición de ingeniería (o de aprox. más empresarial). Vamos, el tema de “mejor algo que funcione bien en la fecha correcta que una maravilla de la técnica con 4 meses de retraso, acumulando pérdidas, poniendo en peligro el proyecto, la empresa, etc, etc, etc”. Curiosamente esto último encaja con todos los métodos ágiles y la idea de “release often and frequently” y lo de “tener algo cuanto antes” (implicaciones empresariales sobre este tema en Rework). Y no hace falta recurrir a un gurú de scrum, la sabiduría popular ya decía “lo perfecto es enemigo de lo bueno”, ¿no?
En definitiva, que hay que explicar siempre al equipo cuáles son los objetivos globales, y que para tener una versión del sistema en la fecha X, es mejor dejar fuera unas cuantas características que llegar sin tiempo, sin haber probado y sin nada que entregar. Cuando todos crean esto firmemente no habrá problemas de motivación ni de entendimiento. Una vez que sepáis cómo hacerlo (variará en cada caso), repetidlo con frecuencia porque todo desarrollador tiende a olvidarlo rápido :)

Priorización

Y una vez que todos nos creemos que esto de recortar va bien… ¿cómo lo hacemos? ¿Qué se deja fuera? Vuelve el debate y el problema. En el fondo es fácil, hay que identificar aquello que realmente es importante considerando los objetivos globales del proyecto. Se dice muy fácil pero luego no lo es tanto porque nos metemos en nuestra burbuja y tendemos a perder la visión global un poco, y nos parece que esa característica super-hacker es muy, muy importante cuando al final el usuario ni la va a ver.
“Black art” nos vuelve a dar unas cuantas pistas: me gusta la técnica T-Shirt sizing que consiste en clasificar cada característica con una escala sencilla en 2 aspectos: desde el punto de vista de implementación y desde el punto de vista de “impacto de negocio”. Por ejemplo, desde el punto de vista de desarrollo:
• Funcionalidad 1: pequeña
• Funcionalidad 2: grande
• Funcionalidad 3: mediana
Y desde el punto de vista de negocio:
• Funcionalidad 1: alto
• Funcionalidad 2: medio
• Funcionalidad 3: alto
Nos llevaría a planificar primero la Funcionalidad 1 (alto impacto y poco coste de implementación), luego la 3 y dejar para lo último (incluso potencialmente fuera) la Funcionalidad 2.
Como decía, McConnell lo explica mucho mejor y en detalle en “Black art”, así que guardad el “puntero”.
Hay otro libro muy conocido “Agile Estimating and Planning”, de Mike Cohn que dedica un buen número de capítulos a cómo priorizar: desde a nivel financiero hasta un punto que considero muy interesante y que es “prioritizing desirability” (capítulo 11) y en el que introduce el modelo de Kano de satisfacción de cliente para identificar qué características son las que hay que implementar primero basándose en si son obligatorias (sin ellas el producto no sirve aunque no “emocionan” a nadie), lineales (cuántas más, mejor), o realmente “innovadoras” (aquellas que marcan la diferencia realmente). Incluso habla de formas de trabajar en las que te saltas alguna característica obligatoria (poniendo los pelos de punta a los desarrolladores más “científicos” :-P ) para tener antes el producto en la calle impactando con “delighters” (como él los llama) y así ganar a la competencia.
Cohn explica cómo hacer encuestas a clientes para saber, de forma objetiva, de qué tipo es cada funcionalidad (Kano model).

User pain

La técnica que usamos en Códice para priorizar bugs es el “user pain” y nos permite “objetivizar” un poco los bugs que metemos en nuestro sistema de “issue tracking”. Básicamente en lugar de meter prioridad alta, media, baja (siempre es alta!!) respondemos a ciertas preguntas en plan:

Hay un cálculo por detrás que da un valor de 1 al 100 (100 es mucho “dolor”) según las respuestas y luego tenemos la lista priorizada, intentando no tener nunca bugs por encima de un valor 30 (de hecho ahora que lo miro veo que tenemos uno del 29!).

Conclusión

Recortar es una “trampa” fantástica que permite que todo encaje. No podíamos aplicarlo en el colegio (“profe, no me examine de los temas 5 y 6 que no me ha dado tiempo a estudiarlos, pero los 4 primeros me los sé de memoria!”) y eso nos ha marcado mucho, pero en “la vida real” puede ser clave para tener éxito en los proyectos y además hay mucha bibliografía aplicable al tema.

Un oasis en el desierto

Bienvenido al blog sobre metodologías ágiles en Castilla y León…España.

Los compañeros de la comunidad ágil de Castilla y León me han pedido que haga la primera entrada de este blog, un honor que creo no merecer y una responsabilidad que es difícil de asumir pero que les agradezco. Y lo agradezco principalmente porque con el nacimiento de este blog se da fe de la existencia de una comunidad ágil en una tierra que siempre vive tapada por la sombra de Madrid, porque ha sido el fruto de unos meses en que nos hemos conocido algunos profesionales que trabajábamos muy cerca con las mismas inquietudes sobre nuestra profesión pero que como siempre vivíamos aislados entre nosotros.

¿Qué son las metodologías ágiles?

Sacando la definición de la Wikipedia (tan recurrida y a veces tan inexacta)  son las metodologías que surgen en contraposición a las metodologías tradicionales o pesadas y que evolucionan el concepto de ingeniería de software de proceso iterativo y prototipado. En el año 2001 se juntaron una serie de profesionales de reconocida valía en el desarrollo de software para crear un manifiesto donde se reflejaran los principios que rigen estas metodologías. Este manifiesto resume la filosofía ágil valorando:

  • Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas
  • Desarrollar software que funciona más que conseguir una buena documentación
  • La colaboración con el cliente más que la negociación de un contrato
  • Responder a los cambios más que seguir estrictamente un plan

Desde AgileCyL queremos hacer llegar los procesos y métodos ágiles al resto de compañeros y empresas en Castilla y León porque creemos que ayudan al desarrollo de proyectos software. Nuestro objetivo es aportar la información necesaria para que cualquier interesado pueda aprender y comparar con las metodologías tradicionales. Como dijo una vez Xavi Albaladejo, una de las personas que más ha extendido la agilidad en España:

agilidad es calidad y competitividad

y tenemos un compromiso moral con nuestra industria en mejorar los productos que desarrollamos en nuestra profesión.

Desde este blog os animamos a participar en las reuniones mensuales que realizamos donde discutimos diferentes aspectos relacionados con la agilidad, desde charlas sobre la gestión ágil de proyectos hasta talleres y debates técnicos de Extreme Programming.

En la lista de correo estamos en contacto y os invitamos a participar y aprender con nosotros. Si quieres colaborar puedes escribir en el blog pidiendo un usuario en la lista de correo y algún administrador del blog te lo creará. Intentaremos superar la barrera idiomática con la traducción de artículos, siempre que contemos con el consentimiento expreso del autor, publicaremos los resúmenes de los encuentros ágiles que hagamos en la comunidad y más actividades que irán surgiendo entre todos, que para eso es una COMUNIDAD.

Gracias por visitar el blog.