Además nos complementamos de GitHub, un lugar donde podemos almacenar nuestros repositorios de código fuente; y que cuenta con varias funcionalidades, por ejemplo: ver los cambios entre versiones, aceptar contribuciones de código a tu proyecto, mezclar los cambios en línea, métricas, estadísticas,  entre algunos otros. Muy recomendable…

Hace ya un par de semanas(y gracias a Andrés Almiray) comenzamos con la inquietud de que GitHub venga a ofrecer un taller de Git, y al ver la respuesta favorable de la gente, nos hemos estado coordinando con la persona encargada del taller: Matthew McCullough (@matthewmccull).

Matthew  se ha mostrado muy animado en ofrecer este taller con nosotros pues tiene la completa disponibilidad de entrenar a aquellos interesado en usar Git + GitHub, para lo cual nos ha dejado un flyer que describe:

• ¿Qué es Git?
• ¿Quién es el instructor? Matthew McCullough
• El contenido del curso
• Pre-requisitos
• Objetivos de clase
• Reconocimientos

GitHub Git Training Flyer v2.0

Les recomendamos ampliamente echarle un ojo a este flyer pues describe el alcance del taller. Además, Matthew también está dispuesto incluso a ir más allá de lo descrito en el flyer y comenta que puede abarcar temas más específicos de ser necesario y del interés para los asistentes.

Para esto último hemos puesto una encuesta en donde podrás votar por el nivel que te gustaría ver en este taller.

Todo este suceso nos tiene bastante emocionados pues de un período a la fecha hemos venido ampliando los tópicos en los cursos de SynergyJ, y el control de versiones de la mano de Git y Github sin lugar a duda será muy bueno para nuestros asistentes.

Como aportación final a este post, les dejamos una de las referencias principales de Matthew hablando de Git:

• Getting started with Git – http://refcardz.dzone.com/refcardz/getting-started-git#refcard-download-social-buttons-display

Los mantendremos al tanto de este suceso vía Twitter y Facebook

Saludos!

La sesión pasada terminó con muchas insatisfacciones y frustraciones, pero con ganas de mejorar, vamos bien, sin embargo, siento la confusión, no saben como mejorarlo, no saben por donde empezar, con esto adentramos con un poco de teoría: User Stories, Estimación, Ejecución, Plan de comunicaciones y espacios de trabajo visuales…

Antes de continuar con las actividades, realizamos la retrospectiva de lo que paso la última vez, en esta ocasión utilizaré otra técnica que permitirá sacar a flote todo aquello que salió mal sin que nos ataquemos entre nosotros o se sienta la tensión…

Una línea de tiempo me ayudará en esta ocasión, sólo pasa y escribe, cuán impactante han sido los temas que hemos visto para ti hasta este momento, ¿donde ha sido tu mejor y tu peor momento?,inclusive apoyar el peor momento de los propios compañeros de equipo; vemos como todos participan, están ansiosos de observar a los demás y ver que es lo que opina el equipo de las actividades que hemos realizado, identificamos las cosas que nos han gustado de sobremanera, y aquellas que no nos han parecido buenas, pero sucede algo interesante, tenemos una tendencia en donde muchas de las fallas del sprint pasado han desaparecido y ahora tenemos mucha área de mejora que no sabemos como atacar pero ahí está, al equipo le cuesta trabajo como es que puede conservar lo bueno que ha obtenido y le cuesta aún más determinar la forma en que aprovechará las oportunidades para optimizar su forma de trabajo, sin embargo, estamos satisfechos, inclusive felices, alguien en el equipo comenta:‘tienen razón, no tenía la actitud, disculpenme…’, podría describir este momento que fue emotivo para quién lo aceptó pero prefiero omitirlo por que causó una sensación que en palabras simples yo no puedo detallar, lo que sí puedo comentar es que llegó el momento donde hemos tocado esa fibra tan sensible que nos hacen personas, no somos máquinas….

Continuamos con las actividades, esto aun no termina…

Expongo un caso más apegado a lo real, la creación de una aplicación, clásico tal vez, pero importante el hecho de que tienen que identificar los puntos más importantes; proveo de herramientas para que ellos mismos hagan su dashboard, en este pondrán los PBI que han identificado y les darán una prioridad basada en lo dictado por el cliente; hay muchos nervios, es fácil pero difícil, tienen muy poco tiempo para exponer lo más importante por el cliente ante sus ojos y ante el desarrollo que están a punto de hacer.

Cuando termina el tiempo, vemos varias historias y las analizamos basados en los conceptos que previamente mencionamos: medible, ‘testeable’, intercambiable, y otros más…

Entonces viene algo interesante, nos vamos a subir a una montaña rusa, donde el sentir subirá y bajará para poder hacer nuestra actividad, y realizamos un ejercicio, en esta ocasión será de confianza con un compañero del equipo, en quién más confíes o con quién más trabajes, les proveo de su material que potencialmente podrían perder si fallan el ejercicio(y al fallar me refiero a la confianza depositada en su compañero); les explico la actividad y veo un par de caras de preocupación, no saben si confiar en esa persona con la que siempre han trabajado, es difícil y más si no podemos ver que es lo que hace…pero lo hacemos, confiamos y ejecutamos,y al ver los resultados quedamos sorprendidos, “¿qué fue lo que pasó?”-dicen algunos-, “todos han hecho la actividad correctamente”-les digo- determinen ustedes mismos, y hablemos de lo sucedido, ¿que pensaron?¿que sintieron?, al ver el resultado ¿cuál es su conclusión?, de aquí destacamos dos comentarios, donde alguien dijo textualmente: “…pensé que no podría confiar en él, incluso al cerrar los ojos supe que se aprovecharía de mí, pero cuando vi el resultado sentí bonito al ver que el también me apoyo…”, y alguien más dijo: “…jamás pensé que pudiera contar de esa manera con mi compañero…”, ya estamos casi del otro lado…

Y siguiendo con el plan de actividades llegó la hora de trabajar en equipo, pero, aún no con el proyecto que analizamos, mejor simulemos una pequeña batalla, donde comunicarse, arriesgarse y entrar en colaboración es fundamental, ¿por qué lo hacemos así?, simple, así son los proyectos, a veces no tenemos idea con que nos enfrentamos, habrá alguien que tenga alguna experiencia en lo que vamos a hacer, tenemos que descubrir un camino, pero no tenemos mucho tiempo, de hecho son minutos o segundos con los que contamos pues alguien nos va a atacar y no sabemos como defendernos, hay que distribuir los recursos, tener una estrategia, asumir control de la situación, cualquiera debe de poder atacar/defender de ser necesario, son tantas cosas las que hay que hacer…

Y damos inicio, de todas las sesiones, en ninguna se habían comunicado tanto como en esta actividad, las voces se alzaban mucho casi a gritos tratando de transmitir sus ideas, dando consejos, pidiendo ayuda, preguntando, y después poco a poco se empiezan a poner de acuerdo, ya conocen un poco más el terreno, ya han explorado, saben que se puede hacer, hay que aprovecharlo, existe un objetivo común y hay que realizar varias tareas para lograrlo, poco a poco la comunicación fluye mejor y justo cuando ya están casi listos, se suspende la actividad(puedo confiar en ellos), y lo hacemos para ver que cosas podemos mejorar, que cosas hicimos mal, ver como atacaremos el problema, veo que hay energía, hay ganas, están ansiosos de seguir; para después continuar con nuestra batalla, los mensajes que se mandan son cada vez menos pero son claros y son muy fáciles de interpretar, ya cada quién sabe que hacer, ellos se han puesto de acuerdo, saben de que son capaces, la justa es pareja pues están al nivel, y por último otra reunión, esta es importante ya que están a punto de conseguir su objetivo, hay muchas mejoras entre lo que deben de hacer y lo que están haciendo, ya casi no hace falta dirigirlos ellos se auto-organizan.

Nuestra batalla termino con resultados que ni ellos mismos se esperaban, se sorprendieron al ver con que facilidad pueden comunicarse, y que tan rápido pueden atacar un problema sin que tengan que planear tanto(claro! no había mucho tiempo…), se apoyaron entre ellos y aportaron ideas, consejos y planes para alcanzar el objetivo…

“¿Qué fue lo que pasó?”-les pregunté-, y un par de ellos contestaron: ”no sé, pero hicimos algo juntos”; claro, ya estaban adoptando los principios ágiles y también los estaban aplicando en algo que no conocíamos pero teníamos que atacar en poco tiempo, y que con ayuda de todos y teniendo muy claro el objetivo pudimos conseguir…

Damos un tiempo de reflexión para que todas esas ideas, conceptos y actividades pasen a un estado consciente, en donde, tomarán forma y por fin aterrizarán en la siguiente y última actividad…

Pasemos al laboratorio, y hagamos la aplicación que analizamos en un principio donde hicimos algunas historias de usuario, tomemos la que tenemos en la prioridad más alta y vamos a desarrollarla, pero ahora con el conjunto de principios que ya conocen, y ahora sí: “¡hagan ágil!”, frase que dejo a la opinión de cada quién…

Lo importante de esto era que llevarán a cabo el conjunto de prácticas que en su momento habíamos mencionado/practicado, es decir, las reuniones que creyeran necesarias, los ajustes y mejoras progresivos, así como los principios mostrados, pero esto no era suficiente, ya que el día a día requiere también de un conjunto de prácticas y pensamientos que permiten a un desarrollador mejorarse, es por eso, que hablamos un poco de TDD y CI, que aunque no lo tocamos a profundidad si resaltamos su importancia, y adicionalmente, coloque en el frente un conjunto de sentencias que mientras estuvieran trabajando deberían leer en cualquier momento, de las cuales comparto algunas de ellas:

¿qué hacemos?

Adelante toma ese atajo, Te ahorrará tiempo, de verdad. Nadie lo sabrá. Puedes terminar esta tarea y seguir rápido. De eso se trata esto, no?

¿qué hacer?

Siempre enfrenta los problemas más difíciles primero, y deja el simple hasta el final

¿qué hacemos?

El primer y más importante paso en el tratamiento de un problema es determinar quién lo causó. Una vez que se haya establecido la culpa, entonces asegúrate de que no vuelva a ocurrir. Nunca.

¿qué hacer?

La culpa no corrige errores. En lugar de dedos apuntando, apunten a posibles soluciones. El resultado positivo es lo que cuenta

¿qué hacemos?

No es necesario entender realmente ese pedazo de código, parece que funciona bien como está. Ah, pero sólo necesita un pequeño ajuste. Solo suma uno al resultado y funciona. Sigue adelante y ponlo, probablemente esta bien.

¿qué hacer?

No caigas en hacks rápidos. Invierte la energía para mantener el código limpio y expuesto.

¿qué hacemos?

Los desarrolladores son creativos e inteligentes y saben más acerca de la aplicación. Por lo tanto, los desarrolladores deben tomar todas las decisiones críticas. Cada vez que la gente de negocios se mete, hacen líos las cosas; no entiende la lógica de la forma en que lo hacemos

¿qué hacer?

Deja que tus clientes decidan. Los desarrolladores, gerentes o analistas de negocio no deben tomar decisiones de negocio críticas. Presenta información a los propietarios de negocios en un idioma que puedan entender, y deja que tomen la decisión.

Entre muchas otras más…

Definitivamente en ese espacio final los chicos trabajaron bastante, algunos de ellos no habían trabajado juntos en algo común, solo en cuestiones relacionadas que podían llevar por separado, ahora pudieron materializar requerimientos transformados en historias de usuario, hubo problemas claro, hubo soluciones claro, pero lo que pudieron ver es que todos estábamos trabajando, y sabíamos que estábamos haciendo, cuál era el status de nuestro producto y cualquiera podría tomar el control, hubo preguntas al cliente, ya no hubo tantas suposiciones, simplemente iniciaron el camino para adoptar métodos ágiles, no se hicieron expertos en ágil, claro que no, ya que también nosotros estamos en el constante sendero de la mejora continua, sólo recibieron de primera mano, los conceptos a través de vivencias que los ayudarían a seguir ese camino…

Para finalizar, nuestra última retrospectiva, ahora usaré la técnica de radar, aquí podremos ver que cosas nos harán falta de aquí en adelante, y de modo personal atacar esas áreas donde hay una potencial oportunidad, la actividad de esta retrospectiva es simple, con tarjetas, un sistema basado en puntos, lo importante son las conclusiones a las que cada uno de ellos puede llegar, pero destaco los 3 aspectos en el orden en el cuál aprendieron/sintieron/gustaron durante el curso:

1. frustración
2. felicidad
3. agilidad

Indudablemente, nuestro objetivo como transmisores de los conceptos y principios ágiles ha sido cumplido…

Para finalizar me atrevo a poner algunas opiniones de los chicos, que muy amablemente me escribieron en una tarjeta cada uno de ellos:

“A manera personal me dejó una gran satisfacción puesto que no tenía idea de que trataría y que sólo era un curso más de algún lenguaje de desarrollo que no entendería.

Me gusto mucho la forma de exposición, algunas cosas no las comprendí pero a futuro y con experiencia me quedarán más claras.

También me cayó el 20 de que está pasando conmigo, cambiando mi visión personal, despertando un gran interés por continuar capacitándome, buscar la forma de ayudarme para poder ayudar…” Anónimo

“Este curso me enseño mucho cómo poder trabajar con cosas sencillas y de manera más rápida…

El curso tuvo muchas dinámicas interesantes que sacaron de mi una frustración que tenía en la mente. Hay una persona del equipo a la cuál no le quería hablar y por lo tanto se me hacía difícil externar lo que sentía, pero una vez que pude en la dinámica de fortalezas no pude dejar de participar de manera continua…

El implementar la técnica con cosas reales me dio la pauta para volver a tomar el gusto y el interés en programar con calidad y en menor tiempo.

Quiero comprometerme pero el que no me tengan confianza me frustra, pero trataré, por que quiero ser ágil por mí y por los demás

Gracias por ponernos el ejemplo…” Anónimo

“Estoy muy satisfecho con el curso desde varios puntos de vista:

- Por la forma de llevar el curso, realmente es un curso para desarrolladores dando la importancia y relevancia de lo que implica considerarse un desarrollador

• El contenido del curso de muy buena calidad
• Los conceptos técnicos también muy bien explicados
• La actitud del instructor
• En general muy bueno”

Anónimo

Al reiniciar, y ver que aún no estábamos todos, le pido a una persona(previamente identificada) que cuente una broma o una anécdota que sea embarazosa, tenía que poner el ejemplo y lo hice, con la finalidad de poder ofrecer confianza, y simplemente no se atrevió, no por que no supiera, simplemente no era su mejor momento; un miembro del equipo le ayudó, ya existía algo de colaboración ante una falla, fue buena y se reavivaron los ánimos, comenzamos bien…

Sentí esas miradas de molestia y de incomodidad, ¿y como no sentirlas?, todo lo que habían usado por años les estaba cobrando y de la forma más dolorosa, y no sólo eso, lo estábamos demostrando, no era solo decir: “lo que usas es incorrecto”, por que ni siquiera esa era la sentencia correcta, es: “…puede que en esto que estás viendo y te estoy demostrando encuentres esa motivación que te hace falta para cambiar la forma y mejorar lo que haces actualmente…”

Retomemos los temas -les digo-, una situación fuerte: ¿son ustedes capaces?¿técnicamente hablando pueden hacerlo?¿qué esperan ustedes de este trabajo?¿que ofrecerán ustedes a este proyecto?¿están motivados?¿si/no, por que?, si no era suficiente con esa tensión inicial donde todos me veían feo, ahora si acabo de aventarle una bomba molotov a ese proyecto que tiene chispas y mucha probabilidad de quemarse en las manos de un Project Manager; lo tenía que preguntar, este tema no es en vano, enfocarnos, ¿Cómo comenzar?, conocernos a nosotros mismo y a nuestros compañeros, describamos el producto que vamos a hacer.

Sigamos un guión, simplemente describamos lo que estamos haciendo de una forma dirigida y enfocada, que vemos en este curso para ustedes, ¿quiénes debemos estar aquí?, ¿que nos diferencia?; afortunadamente, las respuestas son más agradables de lo que esperaba, mejor aún, todos entendemos de que se trata, es simple y conciso, así deberían ser sus objetivos en el desarrollo de un proyecto…

Siendo así, tomemos lo mejor de lo que acabamos de describir y armemos nuestro producto, ¿cómo queremos que los demás lo vean?, ¿nosotros mismos lo compraríamos?, seamos honestos, si nosotros usáramos este producto entonces ¿pagaríamos por él?, ¿no?, ¿por que? si lo estamos usando nosotros mismos, a nuestro producto le hace falta calidad o no hace todo lo que esperamos…

Tomemos esas ventajas y diferencias de los demás para hacer el diseño de nuestro productos, así los demás lo concebirán de la misma forma en que nosotros lo hacemos, y dejemos en claro una cosa, que NO es nuestro producto o que NO cubriremos en el desarrollo de este software, el método de definirlo, muy simple…una lista.

Nuestro siguiente tema, conocer muy bien a nuestros colegas, con quienes estamos trabajando. seguramente no nos hemos dado cuenta pero hay más gente de la que creemos involucrada en nuestros proyectos de software, incluso en este curso, ¿quiénes son?¿cómo hablamos con ellos?, solo estemos conscientes de ello por el momento.

Identifiquemos en el equipo a un par de líderes de proyectos y arquitectos, y hagamos dos grupos iguales, los desarrolladores serán valorados en su momento, mientras tanto, que tomen un descanso y hagamos trabajar a ‘quienes saben diseñar productos’ en algo simple, la transmisión de una idea que deberán de documentar detalladamente para nuestros desarrolladores. Se nota que hay habilidad para transmitir ideas y para tomar notas de los detalles finos, hay confianza en lo que hacen, es el trabajo de todos los días, ¿como no contar con esas habilidades?, corre el tiempo, las descripciones se vuelven complicadas por el nivel de detalle que se solicita, y se acaba el tiempo, que vengan los desarrolladores. Solamente se les deja un documento con la especificación de lo que se desea, arquitectos y líderes de proyecto se retiran a su merecido descanso, ya han trabajado bastante, además, el proyecto está bien documentado y los desarrolladores son buenos en lo que hacen, cuando regresemos el proyecto estará listo…entonces 1==2…claro que no, lo se de antemano, ellos harán su mejor esfuerzo para terminar el proyecto, darán su vida por él y se sobre-esforzarán, sin embargo, no habrá nadie a quien preguntarle, “asumirán” que es lo que quiso decir ese documento, esa especificación, ese renglón, esa palabra.

Cuando todos estamos de vuelta, mostramos lo que esperábamos de los desarrolladores, líderes y arquitectos con un producto medianamente cercano a lo que querían, desarrolladores diciendo: “si hubiéramos preguntado…”, el hubiera no existe, pero ya existe esa inquietud, hemos progresado, hay una incertidumbre natural al desarrollar algo,  no todos están en ese mismo plano, pero alguien del equipo los guiará por que se ha sembrado esa duda.

Ya conocemos a nuestros colegas y sabemos que necesitamos de todos, que hay más gente involucrada, entonces, hay que entrar en acción…

Se habla de presentar soluciones técnicas, examinar los riesgos, dimensionar las actividades, ser claros en lo que vamos a ofrecer, ser realistas con todos…

¿Cuál es la expectativa de nuestros usuarios/clientes en este proyecto de software?¿cuáles son nuestras hipótesis de la posible solución?, pudimos haber charlado de ello, pero era meramente técnico, confío en su habilidad, mejor ataquemos algo más profundo, ¿que nos quita el sueño?, ¿que riesgos hay en un proyecto?, seamos realistas no todo es color de rosa, Scrum no me quita los problemas sólo me ayuda a identificarlos y mostrarlos ante los demás, el espíritu ágil me provee de la capacidad de exponerlos, de colaborar con el cliente/usuario, el reto esta ahí, ya están casi listos para lo que sigue, tal vez no tengan la habilidad técnica, tal vez no tengan el mejor equipo de cómputo, ni la red más abierta, pero tienen algo mucho más importante que ya comenzamos a entender: la actitud profesional, eso nos ayudará mucho, una breve tarea para todos, “para nuestra siguiente sesión me gustaría que cada uno de ustedes comentará acerca de alguna nueva tecnología, o descubrimiento dentro de sus aplicaciones que crean pueda aportar a su labor” – expresé y di un ejemplo breve…

Habrá retos y problemas sin duda, hay que identificarlos, darlos a conocer y sobrepasarlos, adaptarse al cambio; ya hay un sentimiento en el aire de dolor y aceptación, de eso que lástima pero que nos fortalecerá cuando deje de sentirse, y viene lo que todo cliente/usuario o manager quiere saber, ¿cuánto? dinero y tiempo…

Hablemos simple, pensemos en pequeño y establezcamos expectativas, comentamos un par de casos para que las cosas no se escapen de las manos, veamos que pasaría si variamos el tiempo de entrega, inferimos que si el período es corto tendremos que entregar resultados lo más pronto posible, ¿y que no es eso lo que estamos buscando?, no hay duda todos estamos de acuerdo: siempre habrá más cosas que hacer que el recurso económico y el tiempo del que podemos disponer.

Entonces, ¿que podemos ofrecer?, ¿cuáles son los elementos variables en los que nos podemos apoyar?, hablaremos de ello en su siguiente sesión, debemos de cerrar está sesión con un ejercicio muy amplio…

“Ustedes son muy buenos en lo que hacen”, comenté, por lo tanto les confíe una tarea, una labor: crear un producto complejo…

¿Por que era complejo?, bien, el caso era el siguiente: exponer una temática, un contexto de un cliente distinguido que se diferenciaba de los demás por ciertas características que nadie más tenía, y dicho cliente quiere innovar en la línea de sus productos dejando en claro su identidad, hay que establecer las reglas; adicionalmente tengo historias y comentarios con valor que en su mayoría son ambiguos, no están del todo claro, lo importante es que ellos tienen que identificarlos; y seguido a esto, les proveo de su material, papel, clips, globos, algodón, tijeras, entre otras cosas…

Se forman dos equipos del mismo número de personas para esta actividad y hago entrega de una parte de los requerimientos traducidos en pequeños enunciados que tienen la intención de obtener valor, el tiempo es reducido y lo tienen que realizar con las técnicas y conceptos comentados durante el curso. Sin más damos comienzo al ejercicio…

En ambos lados leen las historias, y comienza el desorden, me siento a observar… el desenfoque es total, los esfuerzos están mal dirigidos, primer error: no escucharon. Pero algo bueno sucede, de un lado del equipo se acercan a preguntarme al respecto, y me niego a hablar a propósito, del otro lado sucede lo mismo y soy justo en este momento, al negarle mi atención; de repente sucede: “¿puedo regresar en otro momento?” -me preguntan- “claro” -respondí-…las inquietudes se hacen llegar al respecto de los enunciados, pero la idea principal no es vista aún, les tomo su tiempo, ellos trabajan duro en completar el mayor número de requerimientos, no hay prioridad en las tareas,  hacen las que consideran más simples y sencillas, está claro, parte del gran dolor se acerca, y no obstante, para hacerles más dura su labor agrego más requerimientos…

Medio tiempo, después de un par de ciclos dictados por el marco de trabajo, debemos de mostrar algo, comencemos con el primer equipo, y les digo: “El cliente es diferenciado por una característica muy grande y notoria que es parte de la marca, ¿su producto cuenta con ella?”, por inercia y debería decir incluso inocencia su respuesta es: NO, y sin dejarlos hablar digo: “no me sirve”. Repito la pregunta con el otro equipo, misma inercia, menos inocencia, sin embargo, hay quién alcanza a decir: “aunque tenemos muchas otras características desarrolladas”, y yo afirmo diciendo: “La marca del cliente dice que esta característica debe estar en todos sus productos, ¿este producto la tiene?”, la respuesta del equipo: “NO”, y confirmo: “entonces no me sirve…”, ¿golpe al orgullo?, tal vez, ¿frustración?, seguramente, su entendimiento acerca de lo que esta sucediendo poco a poco va fluyendo, y por fin veo lo que esperaba: prioridad en las tareas, colaboración, aunque temo que en una pequeña parte había influencia del jefe del área, las cosas iban saliendo, se dieron cuenta del valioso tiempo que habían perdido al no atacar los verdaderos problemas; en medio del siguiente ciclo de acciones les hago entrega de más requerimientos, “no lo puedo creer…” -dice alguien-, los comentarios en el salón: “como los proyectos que tenemos…”, claro!, lo que está sucediendo no dista en nada de la realidad, la diferencia es nuestro producto y las herramientas…

Un hecho interesante sucedió cuando les di sus últimas tareas, un par de miembros del equipo se acercó y preguntó: ¿Qué es?¿Qué entró nuevo?, y la persona encargada de filtrar el requerimiento(PO) les dijo: “Yo lo atiendo, ustedes concéntrese…”, ¡Bien! -dije entre mí-

Además casi al final, me acerque y pregunté a cada uno de los equipos: ¿cómo van?, en ambos casos me respondieron: “Llevamos todo esto”, lo observé y solo pude decir:’oh eso se ve bien…’, sin embargo, dentro de mí al leer lo que tenían hecho vi que asumieron muchas cosas, no preguntaron ni se acercaron…lo iban a lamentar seguramente…

Se terminó el tiempo, llego la hora de demostrar que sus productos tienen valor y que cumplieron con la expectativa del cliente. Vamos con el primer equipo, su producto se ve interesante, sus miembros han llamado mi atención por la forma en que trabajaron, muy desenfocados y esparcidos de inicio.

Nuevamente, “el cliente requiere que su marca se vea reflejada en este producto por la característica que los hace únicos ¿su producto cuenta con ella?”-dije-, y una respuesta que los hace respirar: SI, y continuamos, “¿que valor están aportando a su proyecto?”, se ven ambiciosos y comienzan con las tarjetas mejor valuadas, y hay que demostrarlo; inicia la lectura de nuestro requerimiento, y lo cuestiono en cantidad y calidad, se ven entre ellos asustados, “eso no lo preguntamos…”-dice uno de ellos-, su éxito se ve frágil, ahora han probado un poco de ese sentimiento de frustración y de incapacidad pues el tiempo ha terminado, su habilidad se está poniendo a prueba, y al seguir con cada requerimiento viene detrás un cuestionamiento, algunos son cumplidos, algunos no, se ven endebles, con el pensamiento de: ‘hubiera…’, es insuficiente.

Muchos requerimientos fueron descartados, casi más de la mitad que hubieran aportado un gran valor, pero en la demostración de uno de ellos, el de menos valor, en ese se llevaron más esfuerzo, “reflexionen…”-les digo-, “¿cuánto tiempo gastaron en cumplir este de menor valor y cuantas personas ocuparon que bien pudieron aprovechar?”…

Al final de la demostración del primer equipo hacen malabares, improvisan, se ponen nerviosos, “¿no es sencillo verdad?”-les digo-, contemos cuanto valor aportaron para tenerlo presente; continuemos con el segundo equipo y sin decirles una sola palabra dicen “estos requerimientos no los vamos a cumplir mejor no los consideremos”, han visto su proyecto caer antes de tiempo, no hicieron las preguntas difíciles en su momento, que pena por ellos, pero lo han entendido, ese es el punto, han visto que todo va más allá que unos simples documentos: “colaboración con el cliente sobre negociación contractual”.

Comienza su showcase, ya saben que hacer, leen las tarjetas y hacen las pruebas necesarias(pruebas…interesante palabra que examinaremos en lo que restará del curso), ellos saben que hacer y que descartar, menos malabares, menos improvisación, más realidad, simplemente se dan cuenta de lo que ha sucedido, y cuentan los puntos que han acumulado, la diferencia es muy pequeña entre ambos equipos.

Están casi listos, sus sentimientos están expuestos, han fracasado y han entendido, están frustrados, será interesante saber que piensan en la retrospectiva, que les ha gustado, que no, que están haciendo bien y que están haciendo mal, que pueden mejorar, que quitar, que deben de des-aprender…

Existe una corriente conocida como ‘Software Craftsmanship‘ (Artesanía del Software) que intenta crear conciencia acerca de profesionalizar y mejorar el enfoque sobre el cual se desarrolla software, les recomendamos que investiguen sobre el tema.

A pesar de que ya termino un mes de este año, pensamos que es útil un calendario con buenos principios para desarrollar software, así que les regalamos un calendario con estos principios a quien conteste primero y bien a todas las preguntas siguientes:

• ¿Cual es la fecha en la cual se firmo el Manifiesto Agil?
• Menciona al menos 4 metodologías ágiles
• Enumera la mayor cantidad de practicas de XP
• ¿En que consiste PairProgramming?
• ¿Que es Jenkins y quien es su desarrollador principal?
• ¿Que es BDD?
• ¿Que es una User Story?
• ¿Que es Clean Code?

Manden las respuestas a domingo.suarez@synergyj.com, no importa de que parte del planeta seas.

No se desanimen si no pueden ganar, de hecho no es nuestro objetivo premiar a una persona, pensamos que cualquier profesional de desarrollo de software debe conocer las respuestas a estas preguntas para mejorarse a si mismo, y a su vez, incrementar el valor del trabajo que desempeñan. ¿Que esperan para seguir aprendiendo?

En Enero(2011), tuvimos la oportunidad de impartir un curso denominado “Creación de grupos ágiles para el desarrollo de software”, en donde mucha de la temática circulaba alrededor de un marco de trabajo como Scrum y algunos conceptos breves de Kanban, pero más allá de dicha temática meramente teórica, pudimos hacerles llegar a los asistentes la experiencia de trabajar con métodos ágiles y compararlos con las técnicas que han venido usando, esto a través de diferentes actividades tangibles que podrían considerarse el 70% del contenido de un curso con duración de 24 horas.

Me llamó mucho la atención varios aspectos en los que seguramente muchos de nosotros hemos caído ( y no dudo que sigamos cayendo, lo importante es salir de ellos lo antes posible ): la comodidad, la apatía, la indiferencia, la falta de expectativa, la incertidumbre, la presión, la dignidad de tu trabajo, la confianza(mucha o nula), la concepción de un proyecto, la impuntualidad, entre algunas otras. Sin embargo, hubo quién quiso darse la oportunidad de mejorar la forma en que el equipo de trabajo hace las cosas, las personas indicadas, un director de sistemas y un líder de proyecto, personas que querían ofrecerles a su equipo de trabajo una mejora en su trabajo, lo que ellos no sabían era hasta que punto podrían llegar.

Podría describirles estas actividades, pero prefiero escribirles acerca de los sentimientos y percepciones que pude notar de los asistentes…

Un salón vacío, preparando lo necesario para las actividades del día, el espacio muy amplio, justo como lo necesitaba, sillas y mesas acomodadas en ‘U’ de tal forma que podrían rodearme y vernos todos las caras, acomodo un cuadernillo y una pluma en los lugares más cercanos a mí y la gente comienza a llegar, son sólo 3 personas que al ver su material adoptan su lugar, de a poco empiezan a llegar un par más, y comenzamos la actividad, exceso de comodidad, veo como se desempeñan y se sienten a gusto “cómodos” con lo que hacen, nadie siquiera se levanta de su lugar, todos están sentados, llega otra persona y es muy curioso se sienta lo más lejos posible, le invito a que se acerque y se una a la actividad, dándole la indicación a sus compañeros que le expliquen de que trata; al finalizar la actividad cuestiono a los asistentes acerca de lo que pasó, ¿por que no pudieron hacer más?, las respuestas, las que esperaba: “por culpa de X”, “¿cómo podemos hacer más?”, “Hicimos bastantes…”, “No se nos ocurrió otra forma…”, “No nos hablamos…”, etc., los veo diciendo a sí mismos: “si sabemos en que estamos mal”, pero no discerniendo: “¿y que podría hacer para mejorarlo?”, su ventaja y desventaja al mismo tiempo: “Todos se conocen muy bien”, pero no tan bien como creen…

Seguido de esto, su primer acuerdo, ¿a que venimos a este curso?, el objetivo de cada uno de ellos muy diferente, no sabían que esperar de este curso, tenía que hacerlo con discreción, ahí estaba tanto el líder de proyecto como el director de sistemas, su opinión podía estar influenciada, un objetivo no muy claro, era natural al no comunicarles la intención de nuestra presencia.

“Conozcamos un poco de nosotros” – dije -, de forma profesional, técnica y personal, veamos cuales son nuestros intereses; caminamos juntos y poco a poco se empiezan a integrar, ya hablan, ya no les es indiferente lo que pasa, pero hay temor, “puede que diga algo que no sea correcto” -debe ser su pensamiento- , todos están de acuerdo con lo que dice el líder y el director, no podemos equivocarnos, nos van a marcar, – veo en sus expresiones -, rompo la tensión con un comentario tonto, demostrando que lo que diga en este momento no es trascendente, solo quiero la confianza, la integración y alejar la indiferencia. Poco a poco va fluyendo…

Les expreso mi objetivo para con ellos, y les hago un par de advertencias: “se van a entretener y en algunos casos sentirán frustración”.

Comenzamos bien, ya estamos despiertos y atentos, veamos algunos conceptos: predictibilidad y desarrollo iterativo incremental, demostremos de que se trata cada uno de ellos.

Ya basta de teoría, había que ver si estamos listos para este curso, tratemos de cambiar nuestra mentalidad, ¡un ejercicio!, las instrucciones son simples y claras, incluso afirmo con una pregunta -¿sencillo, no?-, todos asienten; nos levantamos y comenzamos, hay problemas al ejecutar la tarea, no lo hacen conforme las instrucciones, en realidad tardan un poco en comprender que es lo que pasa, están confundidos, les pido se detengan y vuelvo a explicar conmigo mismo como ejemplo, empiezan bien, fluye de a poco, existió un momento donde lograron sincronía y de repente, vuelven a tropezarse, les pido se detengan y comiencen de nuevo,  y como en todos los grupos, existen quienes lo comprenden y quienes no saben por que no lo pueden hacer, la respuesta es simple: no escuchamos y nos falta humildad, termina el ejercicio y pregunto ¿qué pasó?, los comentarios muy acertados pero también la confusión, -pero si era muy simple- exclamó alguien, y conjugo -¿donde está el problema entonces?-, reflexión que tienen que hacer para sí mismos…

Seguimos con algunos otros conceptos, desarrollo en cascada, en espiral e iterativo, después, ¿qué es Scrum?, sus bases y más allá, es fácil pero también es difícil; los documentos lo dicen tiene artefactos, roles y reuniones, sigue un flujo, expliquemos de que trata cada uno, el mundo ideal de Scrum, todos es felicidad si tu sigues estas reglas, pinta bien seguirlo, no se parece en nada a lo que han venido usando, pero lo importante es identificar al equipo, ¿quién de ustedes esta comprometido?

Con un paréntesis hacemos otro ejercicio, y nuevamente notamos que aún no escuchamos, y mejor aún, se nota como “el desarrollador sabe lo que hace y sabe que es lo mejor para el cliente”, aunque no haya sido lo que el cliente pidió, pero para el desarrollador es algo que funciona y se puede usar.

Veamos la realidad, ¿que son los equipos ágiles?, no son ni cercanamente ideales como lo dice la teoría, pero debemos de estar conscientes de que podemos aprovechar las habilidades de cada uno de los miembros y tender a la mejora continua con el paso del tiempo, ¿como mejoramos continuamente?, bueno, hay muchas maneras solo hay que encontrar la indicada, y para ello hay que saber con que tipos de personas tratamos, ¿quienes estamos en esta sala? -pregunto yo- y realizo un cuestionario, lo doblamos y lo aventamos de forma simbólica, cada uno deberá recoger un cuestionario que no sea el propio y leerlo ante los demás, con el paso de cada pregunta y respuesta, el asombro se hace presente, mejor aún, a pesar de todo están motivados pero mal enfocados, es evidente, el director de sistemas y el líder de proyecto saben que algo anda muy mal, ¿cómo es posible tener gente con toda la actitud profesional y no poder sacar un proyecto?

Antes de tocar el tema de “Inicio de un proyecto ágil”, hacemos otra actividad, se les presenta un problema común y lo tienen que resolver técnicamente, mostrar la solución(diagrama) con el conjunto de herramientas que van a usar y describirlo ante mí. Solo necesitan un pizarrón, plumones, sus ideas y la habilidad técnica, nuevamente se hace presente el peso del líder de proyecto y del director de sistemas, afortunadamente tengo el remedio para ello, veo que hay quien le interesa, quien no, hay quién observa pero no sabe que decir, quien no dice absolutamente nada, y empiezan a “matar moscas a cañonazos”, y justo cuando me lo presentan, me venden una solución que solo le faltaría hacerme un café para ser perfecta, pero…no es lo que pedí…

“Trabajen nuevamente en ello” – les digo -, la siguiente solución es mucho más simple, pero demasiado simple de hecho no se puede crecer y debe estar pensado para ello como todas las arquitecturas, bueno, última oportunidad, la confusión total, no saben que presentar, también es evidente: hay una brecha técnica incluso entre ellos.

Y entonces, ¿como iniciamos un proyecto ágil?, un poco de charla entre nosotros, meramente la experiencia y el conocimiento que deben de considerar previo a hacerlo de verdad, introduzco algunos de los principios derivados del manifiesto ágil.

Veamos si ya han concebido un poco de esto, aunque de antemano se que no, estamos en el proceso… formamos 2 equipos y les proporciono un material muy delicado; la labor es levantar una torre lo más alto posible en 18 minutos, explico las reglas y comienza a correr el tiempo, transcurren 5 minutos y aún están examinando el plan y el diseño, a los 8-9 minutos comienzan a construir, hay problemas en cada uno de los equipos, la torre no se puede levantar, la levantan y se cae, el plan no está funcionando, veo sus expresiones de frustración, no es posible -exclama alguien- al ver que la torre se cae y ya casi acaba el tiempo, prácticamente no tienen nada, el otro equipo logra levantar algo, termina el tiempo y les hago notar que mentalidad usaron: la cascada…hemos dado el primer paso, sabemos que estamos usando y estamos muy conscientes de ello; y alguien dice: “pero nosotros si logramos la torre e incluso antes de que acabara el tiempo…”, es correcto -dije-, pero la comodidad no les permitió hacer más(la torre más alta) en dado caso de que el otro equipo también levantara una, simplemente se conformaron, ¿donde está la calidad que pueden ofrecer a su trabajo si nos limitamos nosotros mismos?

Fin del primer período, y es tiempo de dirigir una retrospectiva, ya vimos teóricamente ¿qué es y de qué trata una retrospectiva?, y les mencionó la importancia que estas tienen, pido se me preste atención por que todos en algún momento tenemos que hacerlo; y comienzo, “esto nos va a servir para identificar ¿qué hicimos bien?, ¿que hicimos mal?, ¿que debemos agregar o quitar?, y les mostrare una técnica para hacerlo …”, ya había aplicado esta técnica antes, capté su sentir a través de sus propias palabras: “con ganas”,”interesado”, “emocionado”, “algo nuevo”, fueron algunas de sus expresiones; era la primera iteración del curso, ahora es cuando podemos mejorar, seguido capturamos los datos…

Comentarios fuertes, tensión en el ambiente, la temperatura de la comunicación cara a cara se hace presente, sin embargo, no había nada que no se pudiera mejorar, el balance fue bueno para ser su propia instalación y no saber a que me enfrentaba de principio, el grupo aún con miedo de decir ciertas cosas que puedan hacerlos ver mal, aún con eso, pudieron darse la oportunidad de comentar que era lo que les agrado de los temas vistos y actividades hechas y que fue lo que no les agrado y podríamos mejorar, tenía que hacer algunos ajustes para la siguiente sesión…

Primeramente por que Apache Camel es un framework que hemos podido usar durante varios años en proyectos de integración de aplicaciones de manera exitosa. La simplicidad con la cual se pueden conectar diversas tecnologías y transformar datos para intercambio es un factor clave para su uso. A pesar de ser muy poderoso, su uso no ha sido tan extendido, tal vez por ser un framework de nicho, pero por otro lado también la difusión es importante. Por ello, el hecho que ahora contemos con un libro que explique los fundamentos y las cuestiones avanzadas de este framework es vital para su amplia adopción.

Por otro lado, hemos tenido el gran honor de haber sido invitados por Claus Ibsen (desarrollador líder y autor del libro), a participar como revisores técnicos del libro. Hemos trabajado en ello desde el principio y ha sido un placer ver como el libro evolucionaba con el paso del tiempo. Mas de un año tomo todo el proceso. Pero ahora esta terminado. Podemos decir que es la mejor referencia para aprender el framework, pero también una muy buena documentación sobre Patrones de Integración Empresarial. El capitulo de transacciones es una excelente referencia para implementarse en aplicaciones Java. No tiene ni un desperdicio tener este libro.

Para celebrar este hecho vamos a regalar 3 libros impresos a quienes resulten ganadores, contestando una pequeña trivia. Las bases para participar son las siguientes:

• Las respuestas se deberán enviar a domingo.suarez@synergyj.com
• Ganaran aquellos que contesten las preguntas correctamente.
• Se tomara en cuenta la fecha de entrega
• Se recibirán las respuestas hasta el viernes 14 de enero de 2011 a las 11:59 pm.
• Se anunciaran a los ganadores en la 19 reunión de SpringHispano, así como por el blog de SynergyJ y por twitter
• Cuando se anuncien a los ganadores, les enviaremos un correo electrónico para pedirles su información para entrega de los libros
• Los libros se entregaran el sábado 5 de febrero a los que sean de la Ciudad de México, los que se encuentren en otra parte del mundo se enviaran gratuitamente a partir del 7 de febrero de 2011

Las preguntas son las siguientes:

1. Nombre de los creadores de Groovy y Scala, respectivamente
2. ¿Qué hace el patrón Message Router?
3. Nombre completo del libro de Gregor Hohpe en el que se basan las implementaciones hechas en Camel
4. Quienes son los autores del plugin de Routing en Grails?
5. Que despliega el siguiente código en Groovy: println “new enum Organization{ def estatus; void expectation(){ long o; p as String; } }”.tokenize(‘ ‘).collect(){ it.charAt(0)}.join(”).toLowerCase().substring(0,10)
6. ¿Cuando se fundo la comunidad de Artesanos de Software (http://artesanos.de/software)?
7. ¿Cuáles son los estándares asociados con web services?
8. ¿Con que herramienta en Java genero los artefactos portables JAX-WS usados en Web Services leyéndolos de un endpoint?

Es muy sencillo ganar, cualquier duda por favor en este post como comentario. No las manden al correo, revisen las que se hayan hecho, es posible que no tengan que preguntar de nuevo.

Mucha suerte y exitos

En este webinar estaremos presentando como usar algunas herramientas de construcción basadas en el lenguaje dinámico Groovy, estas son Gant y Gradle.

Gant es una herramienta de scripting para tareas de Ant, usando Groovy en lugar de XML para especificar la lógica. Gant no es realmente un framework de construcción, es una fachada del AntBuilder de Groovy.

Gradle es un sistema de construcción que usa el lenguaje dinámico Groovy, retomando ideas de repositorios como Maven, siendo declarativo y simple de usar, haciendo configuraciones personalizadas a sus elementos y acoplandolo a proyectos existentes sin tener que hacer cambios impactantes…

El registro lo pueden hacer desde aquí:

Aquí veremos como se conjugan varias herramientas para el proceso de desarrollo de software en Java, identificando los puntos más relevantes en el mismo y comentando nuestra experiencia al ponerlas en práctica…

Se pueden inscribir en este widget:

This time, I wanna write about one book that I’m reading, this is ‘Griffon in action’ wrote by Andres Almiray and Danno Ferrin. This review describes chapters 1 and 2 …

It’s surprising how the book begins. The authors introduce us to the code immediately with the creation and running of a Griffon application: the trip of 1000 miles in one step begins…

BTW, it was awesome how the Griffon App take the natural look and feel in MacOSX, yeah!!! this mean the menu in the top of the screen and the body in the rest of the app with the aqua style…

The authors’ singular style is something important to highlight ’cause it’s funny, entertained and friendly. In addition to this, they explain of a very detailed way and step to step the development of the application.

I looked at the Griffon’s MVC very similar to Grails in structure (they’re cousins ), however, how they communicate between them(in the MVC way) is different because they go in group. This means that the relation MVC in Griffon is  one view per controller and one domain in each group. In the other hand, Grails can use more than one domain class in controllers or views, In my opinion Grails have many very familiar concepts with Griffon

Also, the book covers the convention over configuration paradigm in a few and is applied in many parts of a Griffon App with specific folders and patterns in names of the components that we’re developing…

The authors spent working with the @Bindable annotation, this is a point essential in this chapter because it’s a very powerful tool that we allow to control the behavior of one component. This annotation is part of the AST transformations (I’ve worked with some ones like @Grab and without a doubt they’re incredible)

This chapter explains some Groovy stuff with detail to the newbies, that’s cool, Java developers can easily understand it and introduce themselves in the Groovy World (yeah! more groovy developers now in desktop)

It’s important to mention that all of this finally is Java, so we have the support in the JVM and all the API’s that nowadays we know and we can add them without problems, Java is a nice place to make desktop apps, but I remember when introduce myself in this kind of apps, well!!! It was a challenge to do some of them and add some behavior, paint the layout, and run it, oh my threads!!! “Somebody gives me another thread in my mind to think the UI and behavior at the same time” I thought…

The bad: In Java we have to deal with some issues like ceremony in the language, UI definition  complexity, app structure, life cycle, build management(a lot, if we’re building desktop, applet’s or to webstart)

The good: Griffon avoids those traps and my knowledge in Grails helps me a lot to understand in one look how it’s structured all the Griffon App’s

After, in the second chapter I learned about the ABC of Griffon, this is:

Application.groovy, Builder.groovy, BuildConfig.groovy and Config.groovy

Each one is very important because it defines how the app is showed, assembled and runned, with all of this, I saw in detail the Griffon’s directory structure.  Also, in this chapter I can see where to put my source files, how to configure my app, how to add some external libraries and a lil’ of testing, with all of this, I explored some of the commands that we have available to work.

Something that we have to deal (also) in Java is about to be careful with the life cycle of desktop app’s (when init resources, when to release it, when it’s ready to use them), well, with Griffon all of that is solved, in some section of this chapter explain in a better way how to organize and manage an app, since the creation until I stopped it.

I`ll continue reading the book `cause my next review will be about the next 4 chapters, dealing with MVC in depth and the MVC groups..

En SynergyJ seguimos comprometidos con la calidad de nuestros contenidos es por esto que los invitamos a que asistan a este webinar, lo unico que tienen que hacer es agregar su correo en el widget que encontraran en nuestros sitios…

En esta sesión hablaremos de las ventajas competitivas de usar Groovy & Grails en proyectos de SW basados en la plataforma Java, así también, veremos como quedaría la integración transparente de ambos en proyectos que ya están en producción.

Te puedes agregar aquí: