"Cada vez es más frecuente escuchar que las grandes empresas utilizan equipos autodirigidos en sus diferentes áreas funcionales. Los equipos autodirigidos o autoadministrados son unidades básicas de operación dentro de una empresa, las cuales tienen la capacidad de conducirse sin la presencia de un administrador o supervisor, tomar sus propias decisiones, solucionar problemas y desarrollar sugerencias que mejoren el desempeño de la organización.
con equipos que sean capaces de asumir esas funciones por sí mismos, el gerente estará enfocado a coordinar esfuerzos, planificar el desarrollo de la empresa, investigar las necesidades actuales y futuras de los clientes para desarrollar las condiciones para el proceso de constante innovación, en lugar de dirigir, controlar y supervisar a sus empleados".

Julia García solis
Tesis:"Implantación de equipos autodirigidos: El caso de Industrias Vinícolas Pedro Domecq Planta Tapones " 
 

Ya no es un sueño.

Hace algo menos de un año comentaba: "En este sector, un profesional sin formación continua está "out" en menos de 5 años, y aunque hay nuevas formas de difundir y compartir conocimiento, se siguen empleando sólo modelos de formación económicamente pesados,  que limitan el acceso."

Desde hace algunos meses ya es una realidad el primer OER (Open Educational Resource) para gestión ágil, incluyendo cursos con certificación (contrastada con examen) Open Knowledge Scrum .

Otro problema de la formación presencial es que el precio por cursos de uno o dos días resulta prohibitivo.

Y también son ya una realidad los primeros cursos presenciales Scrum Manager (Flexibilidad con Scrum) de 100 a 200€ en hispanoamérica y de 200 a 300 en España, incluida certificación con examen; y que se están completando a las pocas semanas de anunciarse :-)   Ya los hay en Tenerife, Barcelona, Madrid, Buenos Aires, Valencia, Córdoba (Argentina), San José...

• Lista y calendario de cursos .
• Inscripciones

 

 

En este encuentro se utilizó un diagrama de prácticas ágiles para priorizarlas considerando su aplicación en el desarrollo de producto en su punto inicial (por ejemplo, en una startup).

La priorización de las prácticas difiere del caso tratado en el encuentro anterior, en que se evaluaron el uso de estas prácticas en el caso de un proyecto “corto”, de 3 meses, y sin evolución posterior. Los factores que más condicionan esta diferencia de priorización son la duración del proyecto y, por consiguiente, el grado de responsabilidad del equipo sobre su calidad técnica (la facilidad de mantenimiento/crecimiento del producto a posteriori).

Hacer clic en la imagen para ampliarla

 

A continuación se muestran las principales diferencias en la priorización de prácticas:

  

• Demo cada 2 semanas y cliente siempre disponible. Pasan a ser un Must. el éxito en desarrollo de producto depende del enfoque en proporcionar valor al usuario / consumidor final por parte de todos (tanto del cliente como del equipo, al cual se está pagado con stock options). Es por eso que la métrica de proyecto de valor entregado por unidad de tiempo también pasa a ser un Must. Por el contrario, en un proyecto corto, su éxito suele depender más de la visión del cliente. Él tiene que saber qué quiere obtener en ese espacio de tiempo, por que no hay mucho margen para una gran innovación o cambios radicales (eso no quita que existan proyectos cortos en que el equipo tiene que aportar mucho en definición de producto, incluso más que el cliente).
• Historias de usuario. Pasa a ser un Must. Es muy importante tener foco en el valor aportado al usuario final o consumidor. Como se ha comentado anteriormente, en el caso del desarrollo de producto hay mucho más interés en este valor que en un proyecto de 3 meses. Asimismo este valor será de gran ayuda para priorizar el Product Backlog.
• Modelo de Dominio. Pasa a ser un Must. Es un mapa conceptual que permite tener un vocabulario común entre las personas de negocio y el equipo de desarrollo, por lo que debe estar claro y bien definido. Se elabora en la iteración 0 para dar soporte a la primera release y se va refinando cada iteración. En el caso de un proyecto corto donde sólo se utilizaba durante 3 meses era un Have por que podría bastar con el esquema de base de datos.
• La gestión de cambios de requisitos deja de ser un Have, dado que no hay que negociar desviaciones con un cliente externo. El control de los resultados del proyecto, del valor proporcionado, es una responsabilidad interna en la empresa, con lo que todos los cambios, modificaciones y adiciones de funcionalidad se entienden como necesarios.
• Move people around y propiedad colectiva del código. Pasan a ser un Must. En la construcción de producto hay que asegurar el collective ownership y no perder conocimiento si en algún momento desaparece algún miembro del equipo. En un proyecto corto esto era menos perjudicial, dado que es inferior la probabilidad de que marche alguien con un conocimiento exclusivo y muy grande del producto.
• Paso sostenido 40 horas a la semana. A corto plazo es un Have en una startup donde para aumentar su implicación el equipo incluso está pagado con stock options, con lo que puede “apretar” más para sacar la primera release. A medio/largo plazo debería ser un Must.
• Hoja de cálculo o aplicación para seguimiento del Sprint. Deja de ser un must si se utiliza un Tablero de Tareas.
• Los spikes (también llamados “balas trazadoras” o pruebas de concepto), aún sin aportar valor de negocio, son de especial importancia en el desarrollo de producto, dado que permiten desechar o validar soluciones tecnológicas (por ejemplo averiguar si un Framework va a mejorar la velocidad de desarrollo o si va a llevar a un callejón sin salida por que no soluciona una problemática), así como obtener una estimación del coste de un desarrollo masivo de aspectos concretos del producto. Es importante que un spike se realice dentro de un timebox, para forzar la toma de decisiones.
• El refactoring sin miedo pasa a ser refactoring sin piedad, dado que el equipo se juega poder construir de manera sostenida en el futuro.
• Peer reviews. Pasan a ser un Must. Dado que la empresa va a tener que vivir de este producto durante varios años y es muy posible que en siguientes iteraciones el código lo tengan que ver otras personas (en parte debido a las prácticas de Move people around y propiedad colectiva del código).
• Gestión de defectos. Pasa a ser un Must. Posiblemente ya no sea suficiente o posible resolver los defectos ASAP para olvidarse de ellos, por lo que es importante disponer de un soporte electrónico adecuado para gestionar  defectos y obtener estadísticas que permitan averiguar qué está sucediendo.
• Pruebas de rendimiento. Pasan a ser un Must.
• Métricas de proceso. Pasan de no ser especialmente relevantes en un proyecto corto a ser un have en desarrollo de producto.
• Programación en parejas. Es conveniente ir realizando esta práctica aunque sea de manera ocasional, planificando un número de horas por iteración o escoger para ello historias de usuario concretas. 

 

Otras observaciones:

• En el caso de desarrollo de producto en un entorno competitivo, es especialmente importante construir con calidad interna para tener “cintura” a la hora de hacer cambios y conseguir un paso sostenible.
• Los casos de prueba de aceptación sirven como checklist de completitud de las historias de usuario, aunque no deben de servir como excusa ni “descarga” para decir “he probado lo que había escrito, si no funciona es por que no estaban todos los tests identificados”.
• Los casos de prueba de aceptación también actúan como TDD. El hecho de escribirlos y pensar en cómo se probará una funcionalidad permite evitar la aparición de errores por malos entendidos y evitar retrabajar (siguiendo los principios Lean). Por ello es recomendable no empezar a desarrollar en una iteración sin antes haber escrito los casos de prueba, especialmente por que es más barato escribir texto y pensar en cómo desambiguar los requisitos que arreglar errores importantes debido a su mal entendimiento.
• La estimación siempre debe ser realizada por el equipo que vaya a ejecutar el proyecto. De esta manera será más realista, por tener en cuenta sus diferentes conocimientos, experiencias, fortalezas y debilidades. Recordar que como característica básica de los métodos ágiles, la estimación y planificación ágil permitirá calcular el ROI en función del tiempo y del gasto, así como saber qué cabe en cada release.

 

Artículos relacionados

• Priorización de prácticas ágiles en un proyecto corto - IX y X encuentros ágiles en Barcelona

 

Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.

Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona

 

Nota del system administrator de ProyectosAgiles.org:

Si estás viendo este artículo a través del RSS de ProyectosAgiles.org, asegúrate de estar accediendo a través de la siguiente URL: http://www.proyectosagiles.org/rss.xml

Se ha detectado que (por razones históricas) también se está accediendo desde: http: //www.proyectosagiles.org/taxonomy/term/11/0/feed, que sólo muestra un conjunto muy reducido de artículos.

 

 

Poner las pruebas (el testing) delante de la programación ha marcado un hito en las prácticas de programación, un antes y un después, que ha transfromado a la "cenicienta" del testing en princesa; de trabajo indeseado (probar lo que iban terminando los programadores) a tarea "cool" de diseño y pre-codificación.

TDD ha hecho que sean las pruebas las que tracen la pauta al desarrollo, y no al revés, y al hacerlo ha abierto dos dimensiones nuevas al testing tradicional: documentación, y sobre todo: diseño:

• Se empiezan a escribir pruebas unitarias con herramientas como JUnit o NUnit.
• Empieza a aumentar la confianza en el código, en la misma proporción que el volumen de pruebas que se va generando.
• Al escribir las pruebas en primer lugar, el código gana simplicidad, programándose lo extrictamente necesario.
• Las pruebas van tomando una nueva dimensión: "documentación", porque cuando se retoma código ya olvidado,  son las que mejor explican qué es lo que hace ese código.
• Poco a poco se empieza a descubrir la segunda dimensión: desarrollar pruebas revela el "API" del código, y pasa entonces a ser también un proceso de diseño.
  

Leer más...

Se acaba de anunciar la  Conferencia Agile-Spain 2010 (CAS2010), bajo el lema "Haciendo realidad la agilidad". CAS2010 es la primera conferencia sobre metodos ágiles en España.

Es una cita donde se encontrarán empresarios, desarrolladores, gerentes, investigadores, etc. Está enfocada principalmente a la industria de tecnologías de la información y consultoría tecnológica.

CAS2010 es una oportunidad para intercambiar experiencias y hacer contactos con otros profesionales del sector, además de examinar las últimas tendencias en el desarrollo del software ágil de mano de las figuras más representativas del panorama nacional.

A continuación aparecen los datos más relevantes:

• Fechas: 10-11 de Junio de 2010.
• Lugar: Madrid, Campus de la E.U. Informática de la U.P.M., Madrid, España.
• Keynote: Henrik Kniberg. Es el autor de “Scrum y XP desde las trincheras” y “Kanban vs. Scrum – Obteniendo lo mejor de ambos”, además de ser Certified Scrum Trainer y miembro de la junta directiva de la Agile Alliance.
  
• Constará de Sesiones, Talleres y presentación de Artículos.
• Tendrá lugar un panel de expertos (mesa redonda).

Se han abierto las siguientes convocatorias:

• Petición de sesiones y talleres
• Petición de contribuciones
• Patrocinio

También es posible colaborar como voluntario y aportar ideas.

El detalle de la información anterior se encuentra en la web oficial de la conferencia: http://conferencia2010.agile-spain.com.

 

 

Hoy tengo una gran noticia. Ya se ha dado el pistoletazo de salida para la primera conferencia sobre Ágiles en España. En Agile-Spain la estamos organizando: CAS2010.
En la web podeis encontrar toda la información necesaria. En estos momentos están abiertos los procesos para la selección de sesiones, contribuiciones y talleres. Cualquier planteamiento relacionado con las prácticas y metodologías ágiles es bien recibido para poder plantear una charla, donde podamos compartir experiencias.

Conferencia Agile-Spain 2010

Contaremos además con la más que interesante visita de Henrik Kniberg.
Henrik Kniberg será el orador principal de la conferencia. Henrik es autor de “Scrum y XP desde las trincheras” y de “Kanban vs. Scrum – Obteniendo lo mejor de ambos”, además de ser Certified Scrum Trainer, miembro de la junta directiva de la Agile Alliance, y uno de los máximos divulgadores de la aplicación práctica de las metodologías ágiles internacionalmente.No te lo pierdas, las inscripciones se abrirán próximamente. Y si te seleccionan como ponente para una sesión, podrás asistir gratuitamente a la conferencia ;)

Se acaba de anunciar la Conferencia Agile-Spain 2010 (CAS2010), bajo el lema "Haciendo realidad la agilidad". CAS2010 es la primera conferencia sobre metodos ágiles en España.

Es una cita donde se encontrarán empresarios, desarrolladores, gerentes, investigadores, etc. Está enfocada principalmente a la industria de tecnologías de la información y consultoría tecnológica.

Leer más...

Ayer tuve el privilegio de poder hablar un rato sobre la gestión Ágil de proyectos como parte de las charlas sobre innovación pública que está organizando el Gobierno Vasco, con el impulso de los incombustibles Alberto Ortiz de Zárate(@alorza) e Iñaki Ortiz, responsables de Atención al Ciudadano y Modernización de la Administración respectivamente y promotores desde hace tiempo del blog Administraciones en Red . El video lo podéis ver en Irekia, y la presentación que usé la tenéis en Slideshare:

100217 Proyectalis Proyectos Ágiles View more presentations from proyectalis.

Actualización: Wala! Si se puede incrustar el video de Irekia!

Compártelo

"El producto previsto, en el tiempo planificado y por el presupuesto estimado" Vs. "Valor rápido, y de forma continua, en intervalos breves u regulares".

 

Scrum Manager ha publicado un podcast como punto de arranque y encuentro para conocer y compartir con la cantera de comunidades profesionales hispanas.  En él presentan y comentan el origen de las comunidades de Argentina , Chile , Costa Rica y España sus propios promotores o fundadores: Juan Gabardini , Agustín Villena y David Alfaro y José Manuel Beas.

• Podcasts de Scrum Manager.
  

En una de las empresas en las que trabajé en rlanda me pasó lo que probablemente fue ha sido el momento más rocambolesco de mi carrera. Y es que a veces los managers tienen una extraña concepción de lo que puede y no puede motivar a un equipo.

Os pongo en situación: Un banco pagando X dinero (mucho, mucho) al mes durante 24 meses y la aplicación no ha llegado a nada. Ya se sabe como son estas cosas. Grandes especificaciones que tardan meses en completarse y mientras tanto ni una línea de código, a vivir. Llega el momento y resulta que no llegamos a esos 50000 usuarios concurrentes que necesitamos. Hay que contratar personal extra. Ahí llego yo, con seis meses ya de retraso acumulado y sin rumbo claro. Pasan los meses y poco cambia. Por mucho que queramos hacer cosas todo está dirigido por especificaciones inamovibles e irrealistas. Proyecto abocado al fracaso.

Llega el momento del ultimatum. El banco lo quiere ya y necesitamos la aplicación en quince días. ¿Cómo podemos motivar al equipo? Pues a alguien se le ocurrió la siguiente idea tan fenomenal y que he bautizado como TVDD o TV-Driven Development:

1. Comprar una televisión de 42 pulgadas (doy fe de que se puede reusar posteriormente para apostar a las carreras de caballos).


2. Colocar la televisión en la entrada para que sea lo primero que ven los empleados al entrar en la oficina.


3. Mostrar lo más grande que se pueda la cuenta atrás para el día fatídico. 15,14,13,12,...


4. Preparar un PowerPoint cada día donde figuren las incidencias más críticas en JIRA y mostrarlo en grande como índice.


5. En sucesivas páginas del PowerPoint, relatar la incidencia y el responsable de arreglar esas incidencias.


6. Hacer saber a los empleados que esta medida es para que todos mantengamos el foco en el objetivo a conseguir en las próximas dos semanas y que nadie se dedique a otra cosa más que a solucionar sus incidencias.

Así que los "afortunados", y me incluyo porque a mi me tocó alguna, llegábamos por la mañana tan tranquilo y nos encontrabamos con un pantallón donde veías los días, y si "tenías suerte" tu nombre saldría en grande y tendrías tus minutos de gloria ya que alguien te habría asignado un marrón del que probablemente nunca habías oido hablar porque se había colado entre los cientos de documentos Word que los business analyst habían estado reenviando de aquí para allá.

Si alguno está interesado en aplicar esta metodología en su empresa, por favor que me avise primero para evitar acercarme a un kilómetro a la redonda :-) No os tengo que decir que la metodología falló estrepitósamente. En realidad nos lo tomamos bastante a guasa. Lamentablemente la cuenta atrás terminó en el número 7. El banco canceló el proyecto y hubo que despedir a la mitad de la plantilla.

El final es feliz ya que la empresa perdió mucha de la gente que no estaba favoreciendo al rumbo. De hecho, eramos !9 arquitectos! (para unos 50 desarrolladores) y nos quedamos en 3, lo que es un número mucho más razonable. Conseguimos que se cambiase la forma de trabajo a una metodología ágil y reconstruir el producto con iteraciones claras. La empresa por fin, tras unas semanas consiguió un producto que vender, y de hecho se consiguió vender a varios bancos mucho más pequeños. Han pasado varios años, muchos nos hemos ido y la empresa no está pasando los mejores momentos, pero es uno de los lugares donde más he aprendido sobre como transformar algo que está podrido desde su raíz incapaz de sacar algo a la luz en una empresa que realmente produce productos y vende software que funciona.

En definitiva, que si un proyecto está retrasado, seguramente ni el no tener una televisión de 42", ni el no tener una cuenta atrás, ni el no tener JIRAs amenazantes, ni el traer refuerzos de última hora van a hacer que el proyecto se salve. Profesionalidad y asumir el "mea culpa", reconocer que las cosas se están haciendo mal y cambiar completamente el chip.

En mi opinión, sólo con la honestidad se puede salir adelante en proyectos como este. No sé si alguno tenéis experiencias parecidas. Os animo a compartirlas

Uno de los factores esenciales para explicar estas divergencias reside en la personalidad de los ejecutores; o más propiamente, en su ego. “Una de las situaciones que con más frecuencia se dan en las organizaciones es que cuanto menos inteligente es una persona más se esfuerza por parecer brillante. Quien tiene madurez y prestigio toma la vida con cierta distancia y decide con seriedad o rigor, pero quien está preocupado por dejar su sello y por darse a conocer, suele tomar decisiones en base a innovar. Como se suele decir, cuanto más tonto es, en más charcos se mete…”

El buen management,  no hace más que formular, de un modo u otro, tres o cuatro asuntos esenciales. Entre ellos, el de “encontrar, captar y motivar al talento”

Son dos citas de Julián Gutiérrez Conde , autor de "El dislate en el management " leídas en el artículo "Tonto el que lo pague ", la verdadera utilidad del management de Esteban Hernández

 

Supongo que todos están familiarizados con la novela A Christmas Carol de Charles Dickens (o alguna de sus adaptaciones), en la cual un viejo gruñon, Ebenezer Scrooge, es visitado durante la Nochebuena por tres fantasmas quienes le hacen reflexionar, reencontrase con su niño interior e imbuirse de espíritu navideño. Hace poco Jim Carrey protagonizó una versión en 3D para la pantalla grande.

Bueno, en las últimas fiestas me topé con una de las tantas versiones en televisión, esta vez representada por Patrick Stewart. Sí, el mismísimo Profesor Xavier de X-Men y Capitán Jean-Luc Picard de Stark Trek. Y sí, sé que ya hace tiempo que pasó la Navidad.

El punto es que al observar la narración de la película en cuestión empecé a encontrar asombrosas similitudes entre lo que ocurría con nuestro héroe (¿o anti-héroe?) y lo que usualmente sucede durante las retrospectivas de los proyectos de software. Veamos a qué me refiero, y para esto nos basaremos en el framework flexible de restrospectivas de Esther Derby y Diana Larsen.

El primer fantasma en visitar a Scrooge es el de las navidades pasadas, quien le recuerda a Scrooge sucesos de su pasado, especialmente de su infancia, adolescencia y juventud. Esto coincide con la etapa de Recolección de Datos (Gather Data), pues lo que se busca es que Scrooge contemple, a modo de observador externo, los hechos relevantes que tengan influencia sobre su comportamiento en la actualidad.

El segundo fantasma es el de las navidades presentes. Este le muestra cómo festejan aquéllos del círculo de personas cercanas a Scrooge. Tanto pobres como ricos personifican el espíritu navideño y celebran con lo poco o mucho que poseen. A partir de aquí se comienzan a formar reflexiones profundas dentro del protagonista (Generate Insights), al combinar elementos pasados y presentes,de maneras no obvias para alguien que se había acostumbrado a vivir de cierta manera y sin pensar mucho al respecto.

Finalmente, el tercer fantasma, el de las navidades futuras, le muestra a Scrooge el triste y lamentable porvenir que le espera, acaso decida seguir por el mismo rumbo carente de compasión y benevolencia con el prójimo. Es aquí que termina la etapa de reflexión y Scrooge comienza a tomar decisiones sobre cómo debe comportarse y qué elementos de su personalidad debe cambiar para mejorar (Decide What to Do).

Si tienen la oportunidad de ver esta película, prueben mirándola a través de estos nuevos ojos y se darán cuenta por qué se afirma comúnmente que las retrospectivas (entre otras prácticas ágiles) no son más que sentido común aplicado al contexto de los equipos de trabajo y el desarrollo de nuevos productos de software.

Tengo el agrado de anunciar que he sido invitado como profesor asociado en el curso del Framework Scrum en el portal open knowledge de Scrum Manager. La profesora titular será Claudia Ruata, una gran amiga mía y profesional de altísimo nivel. Aquí el link: http://www.scrummanager.net/ok/course/info.php?id=4 En esta temporada cada curso tendrá un profesor asociado que fomentará la [...]

El concepto original "Campo de Scrum" definido por Nonaka y Takeuchi describe un entorno de trabajo con principios ágiles en equipos motivados, con delegación y  "empowerment", que desarrollan proyectos de forma iterativa a incremental, que no dividen el ciclo de desarrollo en fases, comparten el conocimiento por socialización (comunicación directa)...  

La implementación de un campo de scrum no depende de las prácticas empleadas (Backlog - Burndown / historias de usuario / Etiquetas kanban ...) o del ámbito de aplicación (proyecto, producto o empresa).

La implementación que Jeff Sutherland realizó en 1993 en su equipo en Easel Corporation, a nivel de proyecto, que Ken Schwaber  documentó, en el libro Agile software development with scrum y que difunde la Scrum Alliance, es una implementación concreta, como lo son tambien cada una de las desarrolladas originalmente por Canon, NEC, Xerox, hp, Honda,  Epson... Es buena, pero nada impide diseñar un campo de scrum con flexibilidad en las prácticas para  adecuarlas a cada realidad, y con ámbito de proyecto, producto o de empresa, según sea para un equipo, departamento (por ejemplo de I+D en una software factory de procesos), o de organización en su conjunto.

Tomando el concepto original de Scrum y "des-monopolizándolo" de la Scrum Alliance, es posible plantear implementaciones con diferentes prácticas y también a nivel de producto o de empresa. Con esta visión de Scrum Manager la agilidad da su mejor resultado cuando se implican y alinean los diferentes ciclos de la empresa: estratégico, proyectos y producción.

 

 

Leer más...

Desde el día de hoy, soy consultor titular en la comunidad internacional Agilar! He aquí la prueba. Estoy muy contento con esto, Agilar está conformada por profesionales realmente espectaculares, a muchos de ellos he tenido el gusto de conocer debido a algunos encuentros internacionales a los cuales he tenido la oportunidad de asistir. Es un honor el haber sido [...]

Una nueva traducción de Agile Spain coordinada por Ángel Medinilla quién ya tradujo el libro anterior de Kniberg y Skarin, “Scrum y XP desde las trincheras“.

Ángel resume muy bien en su anotación el libro y el por qué de esta y anteriores traducciones así que no voy a añadir ni una palabra más.

Nada más que felicitar a todos los que han tomado parte en este proyecto: Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano. Felicitaciones también, cómo no, a Ángel Medinilla.

Aquí tenéis el enlace directo al libro en español.

Lo añado también a la página de Más Información.

Uno de las objetivos que tenemos en Agile Spain es crear y traducir contenido sobre las metodologías ágiles en Español.

Por este motivo, he traducido el Juego del Valor de Negocio creado por Veera Peeters y Pascal Van Cauwenberghe, el cual es un juego de simulación sobre prioridades de funcionalidades e historias de usuario así cómo su valor de negocio. Este juego se ha jugado varias veces en diferentes conferencias como la XP o Scan Agile con muy buenos comentarios sobre él.

Podéis encontrar el juego en aquí (pagina en inglés) o bajarlo directamente desde éste enlace directo. Espero que lo encontréis de utilidad y también, cómo no, que os divirtáis y aprendáis jugando.

Muchísimas gracias a Leo Antolí (también de Agile Spain) y Thomas Wallet (de Pragma Consultores) por la revisión de la traducción y todas sus correcciones y comentarios.

Para los alicantinos que podáis acercaros, el próximo jueves día 4, expondré el seminario "Agilidad: mejores prácticas para desarrollar software" en el salón de actos de la Escuela Politécnica superior de la Universidad de Alicante.

 Será a las 12 de la mañana. La entrada es libre, con inscripción previa en esta página.

Vuelvo a hablar de libros, esta vez para presentar la traducción de un libro Henrik Kniberg y Mattias Skarin al castellano. Se trata del libro Kanban vs. Scrum publicado inicialmente a través de InfoQ. Ahora, gracias a Agile-Spain podemos disponer de este pequeño gran libro en castellano.

Ha sido un trabajo colaborativo, coordinado por Ángel Medinilla, donde han participado personas del grupo de Agile-Spain, que con ganas de contribuir a la comunidad hispano-parlante han realizado un gran trabajo. Desde aquí gracias a Angel, Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano
Ángel os dará más detalles del libro en su blog, y podeis descargarlo desde este enlace.