These days: 40 JAIIO at UTN Córdoba

Se están desarrollando las Jornadas Argentinas de Informática en la Universidad Tecnológica Nacional Facultad Regional Córdoba .

Del 29 de agosto al 2 de septiembre tienen lugar las Jornadas Argentinas de Informática “JAIIO” en esta Casa de Estudios.  El evento, en su 40º edición, es organizado por el Departamento de Ingeniería en Sistemas de Información de esta Facultad y la Sociedad Argentina de Informática SADIO.
Durante las jornadas se presentan trabajos, se discuten resultados de investigaciones y actividades sobre diferentes tópicos y se realizan conferencias y reuniones de las que participan profesionales de argentina y del exterior.

Más información: www.40jaiio.org.ar

vía [ UTN Córdoba ].

Advertisements

Google compra Motorola Mobility Holding | La Voz…

Google compra Motorola Mobility Holding | La Voz del Interior.

Hoy a la mañana me desayuné con la noticia en mi inbox laboral, de que ya no pertenezco más a Motorola Mobility sino a Google y al igual que a otros, me quedó el sabor extraño de la incertidumbre.

Lejos de la alegría, lejos de la ilusión, todavía seguimos adaptándonos a los cambios recientes por la separación de Motorola Mobility con Motorola Solutions, pero sobre todo adaptándonos a Agile.

Pronto llegó un mensaje de nuestro líder en reconocimiento a nuestro esfuerzo cotidiano, con un mensaje que expresa la imposibilidad de hacer este tipo de fusiones sin esas personas que hacen el esfuerzo cotidiano.

 Google puff

Sabemos que por ahora las cosas no van a cambiar, que ambas empresas seguirán trabajando bajo sus respectivas insignias y así será hasta fines de este 2011 o principios de 2012. No sabemos de nuestro futuro, pero deseo que sea muy bueno, próspero.

Con esto pienso que vamos a tener que innovar mucho, en nuestros modos, en nuestras técnicas y pensamientos de como hacer las cosas, principalemnete por que por ahora lo hemos hecho lo suficientemente bien como para ser interesantes, pero empresas como Google intuyo, no gustan de aquellos que solo siguen pasos seguros.

Creo que hay grandes cosas por venir y espero con ansias el contagio viral de la cultura googleana, aunque aseguro que tenemos una gran cultura para contagiar también desde Motorola y principalmente desde Argentina.

Tal vez estoy en una era donde podré ver  el aprecio por las nuevas ideas,  el valor por las personas que se arriesgan más allá de la propuesta diara.
Sin importar el área al que pertenezcan, ni los años dentro de la organización, ni la jerarquía, ni aún los estudios, quizás un día me veré directamente a los ojos con un líder de estas empresas y tal vez, pueda decirle que lo seguiré apoyando desde mi posición y que tenga por seguro que seguiré contagiando a mis pares y otros con mi reveldía, con mis ideas, con mi entusiasmo.

Extraño, pero cierto.

Facilitador oficial de Open Space

Ayer terminó el entrenamiento de Open Space  Technology dictado por Lisa Helf, del cual pude participar y disfrutar. Ahora soy un facilitador oficial de Open Space Technology y dispongo de una nueva forma que es fabulosa, potente y humanizada.

Open Space es una herramienta poderosa que aprendí para ayudar a las personas a mantener conversaciones enfocadas. Donde exista la necesidad de hablar sobre un tópico importante, allí debería haber un facilitador de Open Space.

El sistema es más interesante si hay grupos grandes, pues la dinámica es tan agil que genera todo los elementos necesarios para sacar lo que cada integrante tiene en su interior.

Ellos mismos exponen los asuntos de los que quieren conversar y que por lo generar involucran algún nivel de conflicto, auto organizan su caos, mantienen un apasionado dialogo pues los asuntos son propios, proponen sus ideas que surgen de varios niveles de habilidad y conocimientos, debaten insesantemente y al escucharse unos a otros, sin importar los intereses, encuentran una salida con el sentido de inmediatez que el asunto requiere.

Yo como facilitador cumplo un rol que es “invisible pero completamente presente”, y que así sea es tan importante como la presencia de los que le dan sentido a un Espacio Abierto.

Un facilitador es una persona que ayuda a negociar sin intervenir, que da las herramientas y sostiene el ambiente, protege a todos aquellos que ingresan al círculo, que es la principal zona donde la persona es el talisman de igualdad e inclusión.

Todo allí parece inesperdo y dentro del aparente control existe la sorpresa, igual que las personas mismas que al abrirse soprenden.

Tan importante es para mi haber hecho este entrenamiento, que ahora comprendo que todo el mundo necesita reunirse bajo algún formato que eficientice el dialogo y así maestras, empresarios, dirigentes, vecinos, asociaciones, grupos de jóvenes e inclusive niños, podrían gozar de este formato de conversación bajo el cuidado de un facilitador de Open Space.

Espero pronto estar ayudando a muchos equipos, grupos u organizaciones o simplemente a quienes deseen reunirse para conversar de un tema en particular y desarrollar sus propias soluciones.

Open Space Learning Workshop con Liza Helf – Open Space Technology World Community

Open Space Learning Workshop / Taller de Aprendizaje sobre la Tecnología de Espacio Abierto – Open Space Technology World Community.

Hoy a sido un gran día para mi, no solo por participar de este hermoso evento, sino por que descubrí que mis ideas e intuiciones realmente tienen valor, solo hay que encontrar quien las sepa valorar… es cuestión de tiempo de ahora en más.

También vi que debo integrar toda la información que vengo acumulando y darme el tiempo que necesito para reflexionar, pensar, movilizarme, todo esto sin dejar de dialogar, principalmente conmigo mismo.

Liza me ofreció su tiempo sin que se lo pidiera, solo vino y comenzó a hablarme y con bastante timidéz le conté mis asuntos y ella me dió mucho aliento.

Hoy siento cosas nuevas que en realidad están dentro mío desde siempre. Hoy vi las cosas que siempre veo pero desde una perspectiva alentadora.

Si alguna vez puedes hacer este taller, no lo dudes, hazlo.

Agile testing y gestión de defectos

Desde hace un buen tiempo me encuentro en contra de la registración de defectos masiva, principalmente para entornos de desarrollo de software Agile, donde en resumidas cuentas un defecto pierde su razón de ser ni bien es corregido y verificado en el mismo Sprint de desarrollo.

Muchos me han preguntado, pero como hacen los desarrolladores en Agile para saber de que estamos hablando cuando alguien del team encuentra una anomalía, y mi respuesta siempre fue que el trabajo cara a cara evita cualquier tipo de aparato comunicacional y facilita no solo la corrección sino la mejora.

Por otro lado es cierto que existen muchos modelos de trabajo, como los tercerizados o los remotos, que impiden que los equipos se encuentren co-localizados y entonces ya existe la necesidad de algún sistema de gestión de defectos, sobre todo si hay personas que se dedican exclusivamente al testing de los items de trabajo.
Para estos esquemas también hay soluciones verdaderamente livianas, pero sin llegar a mencionar a ninguna, les diría que lo que prima es la real posibilidade contactarnos entre desarrolladores y testers para hablar de los defectos, su severidad, impacto, priorización y soluciones posibles.

Los invito a intetar un esquema simplista, donde el tester detecta el defecto, lo ingresa en una cola de trabajo inmediato, el equipo en una reunión cercana analiza los defectos acumulados (cola de trabajo), prioriza y resuelve. Tomen fecha de ingreso del defecto a la cola y feche de verificación de la solución.
Tomen exáctamente los mismos tiempos para un defecto que ingresa por una herramienta de gestión de defectos y comparen. Luego me cuentan.

Por lo pronto comparto un interesante artículo que habla de un método de gestión de defectos utilizando la automatización de pruebas como herramienta de evaluación del defecto y entidad documentacional, donde lo que se gana es un activo de software (test case automatizado) y capacidad de repetir la ejecución de la prueba las veces que se requiera.

Este punto de vista es muy efectivo y soluciona enormemente varios problemas a la vez, como la falta de cobertura por caminos alternativos significativos, aumenta el volumen de pruebas de regresión fiables, la registración del defecto, etc.

Source: STAREAST: Agile testing and defect tracking.

you´re ready for the daily meeting but you…

you´re ready for the daily meeting, but you find that the team says, “The Project Leader will not come to work today, so today we do not meet …”
WHAAAAAT? really believe that this meeting has to do with a report to a boss?
You do not agree that this meeting serves to synchronize our activities and know where we stand?
what if one of us faces a risk and do not even recognize? Others may discover it before you do at that meeting.
And if what you’re doing is not right for the objectives? could avoid working on things that do not add value to the project, if you talk between partners

La calidad es siempre negociable

La calidad es negociable y en Agile es tan negociable como que la misma es escalable y varia indudablemente con cada iteración, a medida que una historia de usuario emerge como un motor de trabajo para el equipo.

Que “La Calidad No Es Negociable”  lo he leído inclusive en el famoso libro “scrum-y-xp-desde-las-trincheras”, pero queda claro allí que podemos hacer distinciones entre cosas que pueden evolucionar desde diseños y modelos básico, hasta un entregable de avanzada, y cosas que necesariamente deben tener un grado de calidad mínimo y suficiente para garantizar trabajos futuros.

Entre ambas cosas, podemos distinguir para el primer caso, interfaces en general, botones, comandos, scripts, webservices y hasta funciones que son implementadas como soluciones de base y pueden evolucionar completamente en futuras iteraciones. Para el segundo caso, nos referimos a elementos de diseño y arquitectura que mal implementados atentan contra factores de calidad como la mantenibilidad, modularidad, escalabilidad, seguridad, integridad, disponibilidad, etc., e inclusive contra la testeabilidad.

En Agile tenemos presente que la potestad de la calidad la tiene todo el equipo de trabajo y no un “grupo de QA” y para un mejor aseguramiento, preferimos el “testing temprano y colaborativo”, el que nace desde el primer día en que se conversa con dueños de productos (PO), Analista de Negocios, usuarios y otros interesados, el que continúa en nuestras mesas de análisis y continua con las decisiones del equipo y que facilitan que cada involucrado pueda agregar valor a favor de un desarrollo de calidad.

Un principio que sostenemos y nos ayuda en esta cadena iterativa y evolutiva de la calidad del software, es que los equipos Agiles no se dividen en Desarrolladores y Testers (aún cuando hay especialistas en ambas cosas), sino que se mancomunan en la figura de Team Members.

En Agile sabemos que una actividad de testing, exhaustiva o no, al final de la cadena de desarrollo no aporta calidad, aún cuando pueda dar índices y métrica.

Sin embargo esto que suena tan lindo, de ninguna manera se obtiene en los primeras iteraciones, sino que en futuros Sprint, el esperado de calidad comienza a tomar la forma negociada. En nuestras discusiones de proyecto, constantemente evaluamos alguna posible falta de funcionalidad o funcionalidad pobremente desarrollada y la enorme mayoría de la veces, se logra determinar que mientras futuros Sprints darían la cobertura esperada, en el actual contamos con una calidad “lo suficientemente buena”, sin descartar que en cada Sprint finalizamos y demostramos un incremento “potencialmente entregable” Utilizamos un concepto que se llama “good enough quality”, lo cual nos da los límites suficientes y necesarios para el testing que aplicaremos en cada nivel del desarrollo. Lo más importante, negociamos con el PO el grado de calidad de cada incremento.

Puedo decir  a estas alturas de mi experiencia, que cada vez más, y más empresas de cualquier envergadura  migran a Agile, inclusive para sus productos más críticos. Ya lo se, las empresas maduras no buscan “la bala de plata” pues ya saben que no existen, y quien adopte Agile o cualquier otro framework por moda solo está destinado al fracaso rotundo, de hecho atribuyo el fracaso de CMMI a la tendencia fashion de quienes consiguieron una evaluación positiva y luego encajonaron el proceso.

Justamente, sucede que hasta el día de hoy no han podido lidiar con los tiempos de respuesta exigidos cada vez más cortos, los cambios de requerimientos cada vez más demandantes y mayor diversidad de servicios asociados a productos, por lo que vienen dejando enormes “huecos de calidad” que sus metodologías tradicionales facilitan.

No intento debatir sobre metodologías, pero si tal vez un paradigma y éste que a muchos trato de explicar nos dice que “la calidad es siempre negociable”, pero podrás con esta negociación o no, dependiendo de tu paradigma de gestión de proyectos y mucho más que eso, dependerá del paradigma cultural de las organizaciones.

Por eso podremos ver que los managers se entorpecen en intentar modificar sus procesos para adecuar sus organizaciones a las nuevas corriente, pero al carecer de los principios correctos del paradigma al que intentan imitar, solo logran confundir a su plantel y no pasa mucho tiempo en que prefieren retroceder debido a los intensos fracasos.

La evolución es para todos, para algunos de una forma, para otros de otra forma, pero bueno, insisto, no se puede tener cuerpo sin espíritu.

calidad