Por esto, tengo que exprimir el tiempo que le dedique a los estudios, usándolo de manera efectiva y aprovechando cada minuto. Se necesita una buena gestión de la cantidad de trabajo, priorizándolo según el retorno de inversión de tiempo que tenga cada tarea. Así que sin pensar demasiado el tema, puedo perfectamente aplicar Scrum para organizar de manera efectiva mis estudios.

Esto sería una aplicación de Scrum personal, donde yo mismo ocuparía el rol de Scrum Master, Product Owner y equipo. Como Product Owner, voy a saber cuáles son las tareas que me interesan más, según su retorno de inversión, poniéndolas por delante de aquellas que me resulten más fáciles o simples. Como Scrum Master voy a ser responsable de que mi Scrum se realice de manera positiva, y como equipo, voy a estar encargado de realizar mis tareas.

Es algo que estoy considerando, debería probarlo por un tiempo. Tendría además que obligarme a cumplir las instancias de Scrum: Sprint Planning, Daily Meeting, Retrospectiva y Reflexión.

Sprint – Debería hacer los Sprints de corta duración: 1 semana; ya que de a poco voy a ir viendo qué hay por estudiar por cada materia. Además, podré priorizar los temas a estudiar según los resultados que vaya obteniendo: “En esta materia me fue mal en el parcial, tengo que dedicarle más tiempo”. El Sprint Planning debería hacerse todos los lunes o domingos, ya que es cuando comienza la semana de clases. Incluso podría hacer un burn chart, donde detectaría qué materias me cuesta más estudiar basado en los resultados que obtenga.

Daily Meeting – Como en un equipo de trabajo, se trataría de verificar la cantidad de tareas estimadas contra las realizadas, detectar problemas, y comprometerse con nuevas tareas.

La retrospectiva y reflexión serían bastantes personales, ya que yo mismo estaría revisando si los resultados obtenidos son satisfactorios.

Es importante tener un backlog, donde pueda ir pegando tareas “por realizar”, para ir incluyendo en Sprints siguientes.

Todo esto requeriría un compromiso personal con el trabajo (el estudio), y demandaría bastante disciplina de mi parte. Es algo bastante complejo, creo, pero sencillo a la vez. Me mantendría fuera de la zona de confort, y como siempre digo: usar Scrum para gestionar el trabajo es mejor que no usar nada.

En fin, realmente lo estoy considerando aplicar. Voy a ver si consigo un pizarrón, unos post-it, y empiezo. También voy a incluir tareas de otros proyectos, reuniones y demás, para gestionar el tiempo completo de forma realista. Al igual que en los proyectos de software, en la vida diaria aparecen muchas tareas no planificadas. Por esto, estoy pensando si usar una referencia de colores de post-it según el área a la que involucren: estudio (incluso por materia), trabajo, otros, etc. o según tareas planificadas, no planificadas, etc.

Creo que podría usar post-it amarillos para tareas que se desprenden de la planificación y post-it rojos para tareas que surjan de apuro. Como referencia, puedo usar los post-it más chicos que hay de distintos colores, para identificar a qué área pertenecen. En fin, por ahora esto es solo una idea, pero creo que por lo menos voy a probarlo…

Estamos organizando el segundo curso en Uruguay con certificación internacional otorgada por la Scrum Alliance de la metodología ágil de gestión de proyectos llamada SCRUM.

La palabra SCRUM fue utilizada como nombre para esta metodología con el mismo significado que tiene ella en el Rugby. En este deporte se utiliza a la unión de todos los integrantes del equipo, como si fuera un solo hombre, para “cruzar” la cancha y poner la pelota en meta contraria. Para ello se basan en táctica y estrategia. De manera análoga un equipo de trabajo que utiliza SCRUM debe ir generando “puntos” durante el proyecto hasta finalizarlo. La metodología es un framework que describe el camino para poder lograrlo, es decir, la táctica y la estrategia.

Contenido del curso

Enseñar todos los fundamentos y conceptos de Scrum: Roles, Rituales y Artefactos.

Existen 3 roles en Scrum: Team, Product Owner y ScrumMaster. Se explicará las funciones de cada rol y su interacción, dependencias, etc. Dedicando más tiempo al rol del ScrumMaster.

Los Rituales se describirán detalladamente, respondiendo; ¿qué son?, ¿para qué sirven? ¿cómo se implementan? ¿cuál es la agenda de cada una? ¿y su frecuencia? ¿cuál es su input/output? ¿cuál es el objetivo concreto de cada una? Todas éstas respuestas determinarán el buen uso de la metodología y el éxito de su aplicación.

El ciclo de vida de Scrum está basado en Sprints, éstos permiten hacer entregas periódicas del producto en lapsos muy breves, en donde se parte de la base que el producto nunca está definido completamente, por el contrario, es entiende que su definición es evolutiva. Por tal razón será una parte fundamental del curso comprender y practicar el ciclo de vida que propone esta metodología.

Se mostrarán los documentos y gráficas que existen en Scrum para poder mostrar datos del proyecto que permitan tomar métricas de gestión.

Aunque no es parte de Scrum, también se explicará como combinar este framework con otras metodologías ágiles, por ejemplo XP. Dentro de este marco se utilizaran las User Stories, ¿cómo aplicarlas? ¿cuál es su formato? etc.

Se expondrán las grandes diferencias, ventajas y desventajas de esta metodología y las tradicionales.

Dada la experiencia del entrenador internacional, responderá cualquier consulta que los participantes tengan y enriquezcan el curso.

Dinámica

Es un curso totalmente interactivo, en donde se forman equipos para ir aprendiendo Scrum para practicar los conceptos. Asimismo el entrenador utiliza novedosas técnicas para sugerir cómo abordar los cambios de paradigma que se necesitan.

No se pueden utilizar teléfonos celulares ni portables durante el dictado del curso.

Entrenador Oficial

El Sr. Alan Cyment estará encargado de dictar este curso. Tiene varios años de experiencia en Scrum, en varios proyectos desarrollados en diferentes países. Es un entrenador certificado por la ScrumAlliance quién es la entidad que evalúa y otorga las certificaciones en esta disciplina. Alan es un investigador graduado en Ciencias de la Computación, título otorgado por la Universidad de Buenos Aires. Actualmente está escribiendo un libro con uno de los practicantes más reconocidos en éstas metodologías, el Sr. Tobias Mayer. Además, Alan es el único entrenador oficial de Scrum de habla hispana, con cualquier otro el curso sería dictado en inglés.

Agenda

Fecha de comienzo: Jueves 22 de julio de 2010.

Fecha de finalización: Viernes 23 de julio de 2010.

El curso se dictará en dos días consecutivos en el Hotel Ibis de Montevideo (A Confirmar).

Cada jornada comenzará a las 9am en punto y finalizará a las 6pm.

Mecanismo de evaluación

Examen escrito al finalizar el curso. Quienes lo aprueben recibirán una notificación por mail para descargar el certficado oficial de la ScrumAlliance y además una membresía gratis por un año.

Costos

El costo del curso son 600 dólares americanos +  impuestos.

(No está incluído el almuerzo, solo coffee break)

Única forma de pago: Depósito en la cuenta dólares 8640416, Banco ITAU, Sucursal Aguada.

CSM Gabriel Ledesma

Va costando un poco, uno de los temas complicados es que un equipo pase de no tener horarios a cumplir con el timeboxing. Si bien los horarios de las reuniones se eligen en equipo, a algunos les sigue costando, por lo que a veces caemos en el error de esperar 5 minutos a que llegue un miembro u otro al Daily Meeting.

Algo que me dió la impresión durante esta primera planificación, es que el Product Owner cayó en la idea que su trabajo no es para nada trivial, sino que acarrea una responsabilidad bastante grande. Si bien demuestra que se nutrió bastante con la metodología, leyendo varias documentaciones y recursos, dió la impresión de que en ese momento realmente asimiló la cantidad de trabajo. Recordemos que el rol del Product Owner conlleva muchas funciones. Debe actuar como filtro y representante de los stakeholders, así como negociar y priorizar elementos del backlog. En fín, al igual que el resto de los integrantes, irá aprendiendo en el camino.

Y es que Scrum es una metodología ideal para ir aprendiendo sobre la marcha. Hemos estado pasando enlaces con documentos y demás y transmitiendo la idea, pero es un proceso evolutivo. Somos dos los que venimos oficiando de Scrum Master, retroalimentándonos en el rol, y tratando que los demás asimilen la esencia de Scrum para aplicarlo en armonía con el ideal que lo hace tan efectivo y productivo.

Todavía falta transmitir algunos conceptos fundamentales, y el equipo se va a ir amoldando. Algunos puntos importantes que quedaron en el tintero para ir mechando durante las reuniones fue la visión del equipo y el working agreement. Si bien no son imprescindibles para implementar la metodología, creo que sirven para afianzar la confianza y el respeto entre los miembros del equipo, y permite concretar un primer proyecto en común.

Pero ya estamos usando la gestión visual del proyecto con un task board. Usamos un pizarrón con 4 columnas:

• Backlog: En esta columna pegamos post-its amarillos grandes, con varias tareas (a alto nivel) que se fueron determinando en el primer planning. Obviamente está abierto a más post-its en el futuro, ya que es el backlog general del producto.
• Sprint Backlog: Es el “TO DO”, lo que hay por hacer, las tareas comprometidas para este Sprint.
• En proceso: Las tareas en las que se está trabajando.
• Terminado: Tareas prontas.

Como referencia, ya que no estimamos esfuerzo por cada tarea, vamos marcando un punto rojo por día transcurrido de la tarea en la columna “En proceso”. Al no haber estimado, no tenemos todavía un Burndown chart, pero los puntos rojos van a ayudar a empezar a estimar más adelante.

Este primer Sprint, como experiencia, lo hicimos de corta duración. Empezamos el lunes y terminamos el viernes. El lunes siguiente haríamos una retrospectiva y review del sprint, y un nuevo planning. Dependiendo de cómo nos vaya, lo haremos de una o dos semanas de duración. Iré comentando nuevas experiencias y observaciones a medida que vayan surgiendo.

Trabajo colaborativo

Como comenté en una entrada anterior estoy trabajando en un nuevo equipo. El pasado lunes hubo una reunión general de todos los integrantes, donde pasamos a explicar varios temas y cambios en la forma de trabajar. Scrum implica un cambio tanto en la estructura y metodologías de trabajo, como en la forma de encarar el trabajo por parte de cada individuo.

En esta reunión, comentamos sobre algunas herramientas que usamos y vamos a integrar en nuestra metodología de trabajo: Subversion, Trac y Scrum. Subversion (además de ser mi sistema de control de versiones preferido) es el servidor que se viene usando para mantener los fuentes versionados. Trac es un sistema de gestión de tickets (bugs, arreglos, etc.) y un gestor de proyectos con integración con Subversion. Y Scrum, va a ser el framework que englobe todo el trabajo.

Comprobamos que el simple hecho de reunir a la gente, hacerla participar y contar apenas unos conceptos clave de la nueva forma de trabajo (roles, horizontalidad, participación, auto organización, etc) logró cambios en la interacción del equipo. En estos pocos días que han pasado desde el lunes, la comunicación entre todos los miembros del equipo ha sido mucho más fluída. Se escuchan conversaciones del proyecto entre varios miembros, todos participan. Y la colaboración ha sido un punto fuerte también. Hay más personas del equipo trabajando en equipo, pidiendo ayuda y ayudando.

Basado en esta experiencia, puedo afirmar con total seguridad:
Scrum fomenta la comunicación y colaboración de forma orgánica. Esto sin siquiera haber comenzado formalmente la implementación, sin task board, ni daily meetings. Solo un planning improvisado, y una introducción a algunos conceptos en una nueva forma de trabajo.

Para cumplir con el criterio de Timeboxing, debe definirse una duración inicial para la reunión de planificación. Es importante que se cumpla con esta duración, y la reunión no profundice en temas que no son importantes al momento. El objetivo de esta reunión es obtener la planificación del Sprint.

Duración del Sprint

Mínimo 1 semana, máximo 1 mes.
Esto puede variar a medida que el equipo se adapte a Scrum, o de acuerdo a las entregas que quieran realizarse del producto.

Product Owner

Debe filtrar todos los intereses de jefes, directores, gerentes, de distintas áreas y con distintos intereses hacia el equipo. Para evitar el ruido, el Product Owner es el único que transmite las necesidades del producto al equipo, basado en el retorno de inversión.

Tiene que tener preparado para la reunión el backlog del producto: la lista de funcionalidades que hay que implementar. Durante la primera parte de la reunión, el P.O. explica el backlog.

El equipo

Una vez armado el backlog, el equipo debe seleccionar las funcionalidades con las que se va a comprometer a terminar en el Sprint. El objetivo es tener un producto potencialmente entregable al final del Sprint, y que la funcionalidad sea demostrable. Debe analizar y estimar qué se puede hacer, y despejar dudas sobre funcionalidad con el P.O..

Definiendo el Sprint

El Product Owner y el equipo deben definir juntos el trabajo a realizar en el Sprint. El P.O. es el responsable de elegir la prioridad, y el equipo de elegir cuánto trabajo va a poder terminar en esta etapa. De esta forma, se define el objetivo de cada Sprint. Su éxito será determinado al final del Sprint en una reunión de review. De esta manera, se arma un backlog para el Sprint.

Estimando el Sprint

Una vez definido el backlog del Sprint, cada tarea debe ser estimada, y dividida en partes que puedan ser medidas idealmente en 1 día o menos de trabajo. Cuanto más pequeño sea el alcance de cada tarea, más fácil de estimar.

Duke Trabajando

Hace ya 2 meses que cambié de trabajo.

Hasta ahora los posts relacionados a la implementación de Scrum en este blog habían sido siempre en la misma empresa. El cambio de trabajo debe ser uno de los momentos en que queda más evidente la utilidad de haber hecho este blog plasmando mis experiencias con Scrum.

Si bien no escribí tanto como me hubiera gustado desde mayo cuando empecé el blog, hay muchas cosas útiles que vi en su momento, que aprendí, que apliqué, que me pueden servir hoy en el nuevo trabajo. Links, recursos, artículos y demás. Si bien no ha sido tanto como esperaba, algo se ha ido guardando.

En este nuevo trabajo estamos por empezar una nueva implementación de Scrum. Por lo tanto, a partir de ahora, reimplemento Scrum.

Una de las ventajas es que trabajo con otro Scrum Master certificado. Ya han habido ideas de Scrum y agilidad en la empresa, pero aparentemente no se ha llegado a hacer una implementación completa.

Prometo en esta nueva instancia de implementación de Scrum, comentar más experiencias en el blog.

Scrum comenzó su vida como uno de las nuevas formas Agiles para construir software. En estos días, se lo considera una forma que puede ser usada para mejorar el mundo del trabajo, en un sentido más general, y así, cambiar la forma en que los individuos piensan e interactúan con otros en situaciones de trabajo. El potencial completo de Scrum está por explorar.

En resumen, Scrum es una manera simple de manejar problemas complejos, proveyendo un marco de trabajo para soportar la innovación y permitir que equipos auto-organizados entreguen resultados de alta calidad en tiempos cortos. Scrum es un estado de la mente; en una manera de pensar que libera el espíritu creativo mientras se mantiene firmemente apoyado en principio sólidos y largamente respetados, incluyendo el empirismo, la emergencia y la auto-organización.

Empirismo se refiere al proceso continuo de inspeccionar/adaptar que permite que tanto trabajadores como gerentes tomen decisiones en tiempo real, basado en datos actuales, y como resultado, puedan responder rápidamente a  condiciones siempre cambiantes que se presentan en el ambiente, como por ejemplo, el mercado donde el software a construir es vendido o distribuido.

La Emergencia surge de una aproximación empírica. Implica que todas las soluciones a todos los problemas se volverán claros a medida que trabajamos. No se volverán claros si simplemente hablamos de ellos. El “Big Up Front Design” (gran diseño de antemano) sólo producirá un “Big Wrong Design” (gran diseño erróneo) o a lo sumo un “Big Working But Totally Inflexible Design” (gran diseño que funciona pero totalmente inflexible). Cuando permitimos que las soluciones emerjan es siempre la solución más simple y apropiada, para el contexto actual, la que sube a la superficie. La emergencia junto con el empirismos nos guiaran a la solución más apropiada y flexible (es decir, que podemos cambiar).

Auto-organización se refiere a la estructura de los equipos que crean el producto. Se les da poder a pequeños equipos multidisciplinarios para que puedan tomar decisiones importantes, necesarias para 1) crear un producto de alta calidad, y 2) manejar su propio proceso. Acá la idea es que aquellos que hacen el trabajo conocen mejor que nadie cómo hacer el trabajo. Estos equipos trabajan de una manera altamente interactiva y generativa, donde el producto emerge del diálogo continuo, de la exploración e iteración. La auto-organización funciona cuando hay objetivos y límites claros.

Además de estos principios, Scrum se apoya en dos mecanismos principales: priorización y “timeboxing” (poner límites de tiempo a una tarea).

Priorización simplemente significa que hay cosas que son más importantes que otras. Esto es tan obvio que se olvida muchas veces cuando pensamos “necesitamos esto AHORA”. Scrum nos ayuda a poner el foco de vuelta en seleccionar cuáles son las cosas más importantes a hacer primero, y entonces, a hacerlas! Tomándose el tiempo para priorizar, y siendo rigurosos sobre eso, es esencial para el éxito de Scrum.

Timeboxing es un mecanismo simple para manejar la complejidad. No podemos imaginar el slistema completo de una vez, todo junto, entonces, tomamos un pequeño problema y en un corto espacio de tiempo, digamos una semana o un mes, trabajamos en solucionar ese problema. Los resultados de esa acción nos guiaran entonces a una solución para el próximo problema, más grande, y nos dará más conocimiento sobre las necesidades del sistema en conjunto.

Cambio organizacional

Con Scrum, las jerarquías de gerencia de las organizaciones tienden a ser niveladas y los equipos de desarrollo tienen más contacto directo e inmediato con los clientes. El ambiente de trabajo se vuelve menos “comandar-y-controlar” hacia un estilo más colaborativo. Se promueve el diálogo regular y abierto sobre la documentación extensiva, y el acuerdo negociado es preferido a los contratos de trabajo formales e impersonales.

Las cualidades de apertura, honestidad y coraje son fomentadas en todos los niveles, y la ganancia individual se vuelve secundaria ante el avance colectivo. Un ambiente Scrum es uno que soporta a la gente, donde las personas de todos los niveles muestran respeto y confianza entre ellos. Las decisiones se toman por consenso, más que por imposición de alguien de más arriba, y todo el conocimiento es compartido, de una manera transparente y sin recelos.

Scrum va en contra de lo que hacen muchas compañías de la industria del software, donde una forma en fases acoplada con un alto grado de micro-gerenciamiento, y una insistencia en procesos definidos y documentación extensiva, se han hecho la norma por treinta años. Muchas compañías se basan en el miedo y el dinero como motivaciones claves para sus trabajadores. Esta forma de trabajo ha mostrado éxitos a corto plazo, pero más y más compañías están comenzando a entender que no es una buena estrategia para el largo palzo. Sin embargo, el concepto de cambiar a algo tan radical como Scrum aterroriza a muchos corazones de ejecutivos y gerentes de nivel medio.

Scrum está aún en la etapa de los “early-adopter” (los que abrazan tempranamente las nuevas ideas). Tomará muchos años para que la mayoría de las compañías reconozcan los beneficios de crear más lugares de trabajo, llenos de confianza. Sin ese cambio, muchas compañías de software se irán hundiendo bajo el peso de sus procesos pesados, y fuerzas de trabajo sobrecargadas. Otros, aquellos que abracen el método liviano, ágil, de Scrum, tendrán la gran oportunidad de sobrevivir y prosperar. Para aquellos que pasen a Scrum, y lo abracen completamente, la vuelta atrás a a los viejos días de trabajo será impensable. Un cambio de paradigma está ocurriendo en el lugar de trabajo, y Scrum es una parte importante de ese cambio.

Nota: el término Scrum proviene de un “paper” titulado The New New Product Development game de Hirotaka Takeuchi y Ikujiro Nonaka. En rugby, un scrum es una forma de recomenzar el juego, luego de una infracción accidental o después que la pelota salió de juego. La práctica de Scrum en el mundo del software incluye reuniones regulares diarias y cortas donde los miembros del equipo se juntan para comunicar su progreso. Debido a la similitud entre la pausa del juego (trabajo), y habiendo los jugadores (miembros del equipo) armado la reunión, ésta se conoce comúnmente como el Daily Scrum. Jeff Sutherland, John Scumniotales y Jeff McKenna son los responsables de haber introducido el término Scrum en el mundo del desarrollo del software en 1993, mientras trabajaban en la Easel Corporation, una compañía de herrmientas de software de Massachusetts. Ken Schwaber escribió el “paper” original sobre Scrum, SCRUM Development Process, que fue presentado en la conferencia OOPSLA en 1995.

Otras referencias:
Scrum: its place in the world
Scrum for Software Development

Ágiles

Tobias Mayer volverá a visitar Argentina para dar su curso de CSM.

Ya se publicó la noticia en Ágiles BS AS y foro-ágiles, y la información es la siguiente:

Tobias ya ha venido varias veces a Argentina, y dio 6 cursos de CSM. En enero nos visita en la semana del 25 al 26 y aprovechamos con varios actividades:

• Enero 25: Scaling Scrum (gratuito)
• Enero 26: Consultas CSP (gratuito) – ver más abajo
• Enero 27: The Spirit of Scrum - (pago *)
• Enero 28: Improvisation for agile teams – (pago *) (facilitado por Alan Cyment, co-facilitado por Tobias)

(*) En ambos casos, cada día cuesta 220 usd + IVA. Tomando ambos curos el costo es 330 usd + IVA – La facturación la realizará Agilar, que organiza estos eventos.

Consultas CSP

Luego de hacer un curso oficial de Scrum te convertis en CSM. Pero, más allá del valor de tomar el curso, todos sabemos que no es una “certificación” muy exigente. Por eso puede interesarte dar el próximo paso en las certificaciones de la Scrum Alliance: Certified Scrum Practicioner (http://www.scrumalliance.org/pages/certified_scrum_practitioner). Para facilitar este proceso, Tobias Mayer y Alan Cyment ayudarán y responderán dudas sobre como completar el formulario.

Y si tenemos algún tiempo, podremos hacerles otras preguntas.

Dónde: Microsoft Argentina, Bouchard 710 4to piso, Ciudad de Buenos Aires.

Cuándo: martes 26 de enero, de 19 a 21hs
Cuánto: gratis, pero tenes que registrarte.

Al principio de mi anterior implementación de Scrum, usábamos el pizarrón como Task Board. Más adelante, usamos un espejo que había en la oficina de desarrollo. Ya lo habíamos usado en nuestra primer implementación fallida, pero ahora lo enfrentamos con más experiencia y otro conocimiento.

Usamos post-its de distintos colores para diferenciar tipos de tareas.
Referencia de colores:

• Usamos los post-it amarillos para mostrar las tareas que fueron estimadas y asignadas durante el planning del Sprint.
• Los post-it naranja son tareas nuevas que fueron surgiendo, y trataremos de mechar con otras, o realizar si da el tiempo.
• También agregamos post-it verdes, que son tareas opcionales, para tiempo que sobre.

Todos los movimientos en el Task Board se relizaban únicamente en el Daily Meeting, de manera que todo el equipo estuviera al tanto de lo que sucedía con el proyecto, y por el compromiso que implica llevar una tarea a la columna de “finalizado”.

Así fue como decidimos usar el task board en ese momento, y era lo que nos sirvió. Cada equipo debe adaptarlo a sus necesidades y aprender de la experiencia en su uso diario.

www.comunidadagil.org

Leopoldo Simini presentó en la lista de foro-agiles una nueva comunidad online para los que practicamos agil:

Muchos de nosotros, cuando comenzamos a incursionar en el mundo ágil, dedicamos muchísimas horas a recopilar información en Internet, acudiendo a eventos y conversando con otras personas. Dependiendo del momento, nos hemos encontrado con más o con menos “fuentes” de las cuales nutrirnos o experiencias de las cuales aprender; y aun al día de hoy muchos de nosotros percibimos que la gran comunidad Ágil se encuentra muy activa y, en algunos casos, “dispersa” en Internet.

Sin duda cada vez más, con el aporte de iniciativas como estos grupos, estamos logrando extender algunas fronteras y promover el agilísimo. Todos nosotros conocemos nombre y apellido de las personas que claramente son un referente en la materia y sabemos a dónde acudir para encontrar sus experiencias, consejo, puntos de vista e incluso, sus servicios.

Sin embargo, hay también muchos otros agilistas cuyas experiencias son sumamente valiosas y pueden constituir un aporte tanto a quienes ya participamos activamente de la Comunidad, como a quienes están incursionando en el mundo Ágil.

Después de varias conversaciones e ideas de muchas personas, desde hace ya algunas semanas comenzó a tomar forma un proyecto que espero, siga aportando a contribuir y hacer crecer cada vez mas esta Comunidad. Hoy luego de muchas horas de trabajo y la colaboración de varias personas, tenemos la alegría de anunciar el lanzamiento de un nuevo portal dedicado a la Comunidad Ágil Hispanoparlante: www.comunidadagil.org
Este nuevo portal es un espacio especialmente pensado por y para la comunidad Ágil, en todas sus áreas de aplicación. Es un espacio de encuentro, de aprendizaje, de difusión y de contacto profesional.

Basado en Buddypress, una de las plataformas para comunidades más populares, creamos un espacio en donde no solamente podemos publicar y acceder a los aportes de los miembros, sino también esperamos fomentar y promocionar estas nuevas metodologías Accediendo al nuevo portal de la Comunidad Ágil, no solamente podrán participar de debates y compartir experiencias sino también crear sus propios foros, grupos, blogs y redes de contactos.
También sabemos de la gran cantidad de Blogs que actualmente se encuentran dispersos en Internet. Comunidadail.org les permite importar y publicar sus Blogs ya existentes dentro del marco de comunidadagil.org, e incluso crear grupos que se alimenten de los feeds de sus Blogs actuales, dando una mayor visibilidad y difusión a sus publicaciones.

Adicionalmente, comunidadagil.org dispone de un espacio en donde cada miembro puede publicar su Perfil Ágil.
Este Perfil Ágil es la carta de presentación de su experiencia en estas prácticas y metodologías y sirve como punto de acceso para que otras personas o empresas interesadas en su experiencia o servicios puedan contactarlos.
Pero en lugar de contarles todas las herramientas de las que disponen, los invitamos directamente a visitar el Portal, descubrir todo lo que en él pueden hacer y comenzar a participar activamente. Y desde ya, les pedimos hagan extensiva esta invitación a todas aquellas personas que ya participan o se están involucrando en el mundo del agilísimo.
Realmente esperamos y nos gustaría mucho recibir aportes y sugerencias para hacer de esta Comunidad un lugar a gusto de todos.
Esperamos que lo disfruten!

Leopoldo Simini
http://comunidadagil.org/members/leosimini/
comunidadagil.org

¡Nos veremos por ahí!