domingo, 31 de julio de 2011

El dolor de los aspirantes ágiles(Parte 3 – final)

El día inicia con la labor que les deje previamente: aportar algún conocimiento adicional fuera o dentro del contexto de un proyecto, interesante actividad, que pueden compartir cada semana y no dura mucho, cuanto más unos 15/20 minutos; sucede algo bueno, todos han aportado algo, no hay medida, simplemente aportaciones, inclusive se soluciona el misterio de la generación de un reporte que dos personas estaban haciendo de formas separadas en donde una de ellas se había atorado por un tipo de dato que su herramienta no reconocía, esta actividad se ve prometedora ante sus ojos…

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”
Fuente: SynergyJ

sábado, 30 de julio de 2011

El dolor de los aspirantes ágiles(Parte 2)

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…”

gracias a SynergyJ


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…

Fuente: SynergyJ

El dolor de los aspirantes ágiles(Parte 1)

Hoy en día, mucha gente considera que el poder del ser ágil reside solamente en la rapidez con la que se pueden crear productos, sin embargo, no vemos en la mayoría de las veces todos los principios que debemos de considerar en la realización de proyectos ágiles y tampoco los valores que debemos adoptar para enfrentarlos.

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…

cortesia de: Synergyj


Python y matemáticas: Theano



Theano son unas librerías matemáticas basadas en Python. Con ellas podemos definir, evaluar y optimizar expresiones matemáticas que involucren arrays multidimensionales de forma eficiente.

Lo cierto es que viene muy bien para definir funciones matemáticas de cualquier dimensión, pudiendo especificar los parámetros de las funciones. Otra característica que he encontrado muy interesante es que calcula las derivadas de las funciones con un código sencillo y claro.

Destacar que estas librerías son totalmente compatibles con Numpy, Scipy y las he usado sin problemas con Mathplotlib para dibujar las gráficas de funciones.

Bien, para que veáis cómo se usan con un ejemplo un poco más elaborado que los que vienen en su documentación he realizado un pequeño programa que dibuja la función logística y su recta tangente en un punto dado, para ello he usado Mathplotlib, de esa forma podéis aprender a dibujar funciones de forma sencilla, con soporte LateX en las figuras, creación de leyendas y guardado de las imágenes en formato .png. El código es el siguiente:

#!/usr/bin/python

from matplotlib import rc
from pylab import *
from theano import *
import theano.tensor as T
import numpy

rc(‘text’, usetex=True)
rc(‘font’, family=’serif’)

x = T.fvector(‘x’)
x1 = T.fscalar(‘x1′)
y = 1/(1 + T.exp(-x))
y1 = 1/(1 + T.exp(-x1))
logistic = function([x], y)
logistic1 = function([x1], y1)
grady = T.grad(y1, x1)
derivada = function([x1], grady)

a = float(input(‘Introduce el extremo izqdo. \n’))
b = float(input(‘Introduce el extremo drcho. \n’))
particion = float(input(‘Introduce la longitud de particion del intervalo. \n’))
pderiv = float(input(‘Introduce el punto donde hallar su recta tangente. \n’))

xval = arange(a,b,particion, dtype=’float32′)
z,w,w1=T.fscalars(‘z’, ‘w’, ‘w1′)
rectatg2 = (x-z)*w+w1
rectatg3 = function([x, Param(z, default=pderiv), Param(w, default=derivada(pderiv)), Param(w1, default=logistic1(pderiv))], rectatg2)

figure(1)

plot(xval, logistic(xval), linewidth=1.5, color=’r')
plot(xval, rectatg3(xval), linewidth=1.0, color=’g')
ylim([0,1])

xlabel(r’\textbf{Abcisa}’, fontsize=12)
ylabel(r’\textit{Ordenada}’,fontsize=12)
title(r”Funcion logistica f(x) = $\displaystyle\frac{1}{1+e^{-x}}$”, fontsize=12, color=’r')
legend((‘Funcion Logistica’, ‘Recta Tangente’),’upper left’, shadow=True, fancybox=True)

leg = gca().get_legend()
ltext = leg.get_texts()
llines = leg.get_lines()
frame = leg.get_frame()

frame.set_facecolor(’0.80′)
setp(ltext, fontsize=’small’)
setp(llines, linewidth=1.5)

grid(True)
axhline(linewidth=1.5, color=’b')
axvline(linewidth=1.5, color=’b')

figure(2)

plot(xval, logistic(xval), ‘k.’)
plot(xval, rectatg3(xval), linewidth=1.0, color=’g')
ylim([0,1])
legend((‘Funcion Logistica’, ‘Recta Tangente’),’upper left’, shadow=True, fancybox=True)
leg = gca().get_legend()
ltext = leg.get_texts()
llines = leg.get_lines()
frame = leg.get_frame()

frame.set_facecolor(’0.80′)
setp(ltext, fontsize=’small’)
setp(llines, linewidth=1.5)

xlabel(r’\textbf{Abcisa}’, fontsize=12)
ylabel(r’\textit{Ordenada}’,fontsize=12)
title(r”Funcion logistica f(x) = $\displaystyle\frac{1}{1+e^{-x}}$”, fontsize=12, color=’r')
grid(True)
axhline(linewidth=1.5, color=’r')
axvline(linewidth=1.5, color=’r')

figure(1)
savefig(‘fig1′) &npbs;
figure(2)
savefig(‘fig2′)
show()

El resultado es el siguiente:






Fuente: Linuxmúsica

Sitio oficial de Theano: http://deeplearning.net/software/theano/

Las 10 razones para tener un novio geek


by Fito elizondo

  1. Hacen más dinero: con sus blogs bien posicionados, haciendo reviews sobre múltiples servicios y proporcionando soporte técnico por aquí y por allá, sin gastar en oficinas, transportes, empleados… todo el dinero se destina al amor de los amores.
  2. Son más inteligentes: si bien los tachamos de antisociales no podemos discutir que un geek sabe desde cómo hervir un huevo hasta los componentes del circuito eléctrico de una secadora de pelo, cosa que lo convertirá en un fuerte candidato para ser tu rival.
  3. Prestan más atención a detalles:acostumbrado a discernir entre cientos de blogs de los que recibe información a diario, usar 5 aplicaciones al mismo tiempo, revisar las instalaciones de su blog constantemente son una “máquina de poner atención” sin duda nada desperdiciable para cualquier mujer.
  4. Tienen excelente memoria: ejercitadas sus neuronas en recordar fechas de vencimiento de hostings, lanzamientos de distribuciones Linux y expiración de programas shareware, recordar una fecha de nacimiento o el día del primer beso es pan comido para un geek.
  5. Seleccionan -ydan- mejores regalos: el tiempo invertido delante de una computadora les proporciona la mejor información al momento de elegir un obsequio -generalmente un gadget- que sin lugar a dudas será el mejor, evaluado por los expertos en la materia.
  6. Ponen un esfuerzo adicional: cuando la chica le solicita a un geek ayuda para un trabajo, éste le entregará no sólo un resumen de las 3 primeras búsquedas de Google sino documentos y ebooks PDF, videos y podcasts, y la habrá suscrito a un grupo de Yahoo! donde se está discutiendo el asunto.
  7. Son mejores amantes: debido a que no invierten sus hormonas en manifestar su virilidad ante otros “machos”, a la hora del amor el geek se comporta como todo un conocedor del Kamasutra -del que ya sabía por unas diapositivas que le llegaron a su email-, además, antes de ir “al grano” incomodando a la chica, realiza una “vuelta de reconocimiento”.
  8. Muestran con naturalidad al niño que llevan dentro: para un geek es normal tener sobre su PC una figura articulada de Mazinger o taparse por la noche con una cobija de Superman, cosas que un hombre convencional no se lo permite… y a las chicas les encanta.
  9. Los desperfectos eléctricos son cosa del pasado: ¿un secador de pelo roto? ¿un equipo de home theatre sin instalar? Las chicas no volverán a preocuparse por este tipo de cosas pues el geek es multiuso en todo lo referente a la electrónica, y si algo no lo sabe hacer, tendrá un amigo que sí.
  10. Son dignos de confianza: si otros se han atrevido a confiarles los sitemas de seguridad informática de su empresas, sus transacciones electrónicas, el diseño de la imagen corporativa de su startup… ¿qué no puede esperar una novia? Fidelidad y discreción garantizada.

jueves, 21 de julio de 2011

Por falta de esperiencia y peresa a la lectura perdio un trabajo geek

Esta historia me la contó un amigo, el es un geeks con algunos defectos ya que le gusta investigar mucho y no lee mucho lo que investiga, y le gusta mucho su carrera es ingeniero en sistemas, por eso nace esta historia.

mi amigo tiene una amiga en una empresa en la gerencia de Informática, no es 100% del área pero es la jefa de proyectos, ya le había tendido la mano en otra ocasión y por cuestiones familiares no pudo aceptar, ella muy buena gente le volvió a tender la mano y esta vez si ingreso le asignaron el primer proyecto y lo empezó por su falta de conocimientos tuvo problemas en entender el esquema de trabajo y la plataforma de desarrollo que ellos utilizan como Struts2, Cayenne, lo confundió la utilización de esta plataforma con sus medios conocimientos de JAVA, en una reunión de proyectos ya muy avanzado el tiempo dijo que su proyecto el lo entregaría en dos semanas... todos sus compañeros se asustaron y le pidieron que recapacitara pero el se mantuvo firme en su decisión.

por mi parte le dije que eso era un gran error y me contó que si que era muy fácil que el había escuchado que los Framework le agilizaban mucho el y eso hizo que se confiara. Fueron pasando los días y el seguía luchando por resolver y entregarlo sin novedad y sin ningún problema o queja de su desarrollo eso fue algo mas que lo hizo demorarse en su proyecto, el siguió adelante codificando y buscando ayuda con lo que no sabia resolver, gracias a dios sus compañeros son muy buenos y le tendieron una mano,

siguieron pasando los días y el seguía investigando, otro día me contó que el había empezado mal su proyecto porque el análisis fue muy superficial que se enfrasco en una información que le paso su jefe sobre el sistema que replasaria el que esta empezando, el tomo esa información y empezó con las pantallas ya que so se había atrevido a solicitar información de la base de datos actual para hacer un mejor análisis y mirar mas sólidamente el desarrollo, no lo hizo lo vino hacer como hace menos de un mes, algo tarde le dije.

pero el siguió adelante con su proyecto y los correos de su jefa iban y venia, lo que lo hizo llegar a las 7:30 todos los días, hoy hablamos cuando salio del trabajo y me dijo que hoy tuvo su ultima reunión de proyectos en el cual se le informo que llegaba hasta el 30 de julio su contrato y que no iba a pasar a nomina fija lo que quiere decir esto que se acaban las relaciones de trabajo, y otra cosa que me contó que estaba conociendo una chica por Internet que le gustaba porque era muy sencilla y alegre entre otras cualidades que a el le gustan mucho, pero que lamentablemente por este fracaso iba a tener que separarse de ella por que dice que si es un fracaso como profesional no se lo quiere imaginar como pareja, y que pensaba irse del país para probar suerte en otro lado ya que no le a ido muy bien en este, yo le recomendé que repasara mejor que tomara manuales y dejara de perder tanto tiempo en su casa metiéndose en facebook, badoo, google+ y estudiara mas que el sabe pero le falta mejorar la calidad de sus conocimientos.