[IT Agile Games] Capítulo 4. La comunicación del lince

Como nueva entrada del blog, que por temas laborales se está quedando apartado... He elegido un capítulo del libro ITAgile Games.

"La comunicación del lince" es un juego de, aproximadamente, 15 minutos para demostrar al equipo la importancia de la comunicación entre miembros ágiles. 

Ésta actividad la creo apropiada como uno de los pasos de una reunión de acercamiento del equipo, se puede incluir en la dinámica del Sprint 0. El juego también permite entender conceptos que facilitan el desarrollo ágil, como conciliar a los desarrolladores de que piensen en equipo.

Materiales

• Hojas de Papel Formato A5
• Lápices

Roles

• Facilitadores/as del juego: Explican las reglas y actúan como Scrum Master.
• Desarrolladores: Equipos de 4 personas.

Actividades

1. Cada Miembro del equipo, escribe sobre una hoja de papel una frase. 10 seg.
2. Se pasa el papel al siguiente integrante del equipo.
3. El siguiente miembro realiza un dibujo representativo a la frase que viene indicada en el papel, luego se dobla el papel permitiendo solo ver el dibujo (y no la frase) y se para al siguiente compañero/a. 10 seg.
4. Se pasa el papel al siguiente integrante del equipo.
5. Los siguientes integrantes, mirarán el dibujo y deberán saber identificar una similitud con la frase inicial. 10 seg.

La mecánica se repite hasta que cada componente recupera su hoja original.

Reflexiones

Al acabar, es fácil ver el resultado final. Inicialmente no debería tener mucha relación la frase con el dibujo. Servirá para resaltar la importancia de la comunicación y de compartir una visión en común.

La experiencia personal ha sido bastante buena, los participantes se lo pasan genial, nos reímos viendo los resultados finales, creamos un contexto amigable entre todos/as y, lo más importante, empezamos a darnos cuenta de que tenemos que ser un equipo.

Saludos Ágiles

Un buchito de realidad... ¿Sub-estación, sobre-estación o equipos eficientes?

En el mundo de la informática te encuentras muchos tipos de personas con diversas habilidades de las que aprender o evitar entender.

Entre ellos: los que han sufrido un proyecto estimado de manera ajusatada, por decirlo de manera suave, y/o los que lo van sufrir. Los problemas relacionados con estimaciones así, son tan antigüos como la informática. ¿Porqué crees que aparecieron CMMI o ITIL en su día?

Los problemas, errores, malas prácticas, hábitos y demás leyendas relativas al mundo de la estimación pueden verse en sencillas búsquedas sobre la red.

Debido al dolor que aún producen las cicatrices emocionales por malas estimaciones, caen en intentar cubrirse las espaldas diciendo tiempo de más, sobrestimar.

La naturaleza humana, es exprimir la Ley de Parkinson.

Dice la ley de Parkinson: “el trabajo se expande hasta ocupar el tiempo disponible para realizarlo”. Es decir, que si una tarea se puede hacer sólo en un mes, pero dispongo de dos… Al final estaré los dos meses enredando con la tarea.

Pero, ¿Qué ocurre cuando, simplemente, el equipo ha hecho un buen trabajo?

Por que... Por suerte, todos los informáticos no son grandes followers de dicha ley.

En mi opinión, si trabajas con transparencia y te implicas en el grado que tu equipo espera, o le gustaría, y cada miembro se aplica con la motivación adecuada, es una manera de mitigar algunos de los riesgos que puedes encontrar sobre el desarrollo de una solución a cliente. Aunque siempre tendremos los típicos:

– Al equipo le falta dominio en las tecnologías.
– El equipo desconoce la lógica de negocio.
– El entorno de desarrollo debiera ser más eficiente.
– Si es un proyecto de mantenimiento, el equipo no conoce el código lo suficiente.
– Nebulosas en los requisitos funcionales.
– En los requisitos no se han tenido en cuenta cuestiones de seguridad, rendimiento o creación de marcos de trabajo(Crear: workspaces del IDE, repositorio de versiones, Base de Datos, etc).

La conclusión:

1-SUBESTIMACIÓN: El sobrecoste generalmente crece exponencialmente, cuanto más alejada esté la subestimación del tiempo real (penalizaciones por contrato, cliente cabreado, jornadas interminables, ...).

2-SOBREESTIMACIÓN: Hoy en día, la gran mayoría de clientes tiene un departamento de informática que gestiona las soluciones que necesita la infraestructura de la empresa para tratarla con los proveedores. Si nos pasamos, el cliente lo sabrá y puede decidir buscar otro proveedor.

3-UN BUEN TRABAJO: Realizar un estimación de 100/100 es prácticamente imposible. Pero si hacemos unas estimaciones coherentes y contamos con el respaldo de un equipo implicado, asertivo y motivado; podremos conseguir el win-to-win. Nos ayudará en gran medida a seguir teniendo trabajo... No olvidemos que en la empresa entra el capital por: 

A)Aportaciones de accionistas (Que a menos que sea una startup, no estarán invirtiendo dinero diariamente...).

B)Soluciones facturables (Sirven para pagar las nóminas, toners de impresión, ordenadores, la cena de empresa ...).

Con este post, quiero mostrar mi orgullo y agradecimiento por el equipo que tenemos para ayudar al cliente a obtener las soluciones que precisa.

¡Gracias!

¿Te encuentras en un proyecto un huevo de grande?

En andalucía se oscila mucho las unidades de medida propias. Vienen a ser: el pelín, la mijilla, er peazo, la jartá, la pechá y el huevo.

Muchos proyectos de software se comportan de igual manera, de repente se transforman en un huevo de tediosas (tiempos y costes se disparan, incidencias de todo tipo, incluir una nueva y simple funcionalidad conllevan una jartá de esfuerzos, etc.), e igualmente, muchas veces, nos ofrecen, o buscamos, sugerentes vías de escape que, con apenas esfuerzo, nos solucionen el problema (bastaría pasar por algunos foros de software), tecnologías que de manera casi inmediata prometen acabar con la intensidad de un proyecto de software gigante. 

El tiempo ha dado lugar a la creación de un amplio cuerpo de conocimiento en ingeniería de software que nos ha enseñado la mejor manera de trabajar, afrontar o resolver problemas asociados a la naturaleza del software, como, por ejemplo, a no utilizar el “go to”, la importancia de la ocultación de la información, el diseño orientado a objetos, las arquitecturas en capas, cómo estimar proyectos, el valor de las mejoras, economia software, patrones, etc, etc, etc. Pero éstos, en más ocasiones de las que nos gustaría, se olvidan, o desconocen, y se buscan soluciones desde lo accidental (una determinada herramienta, entorno automático o CASE, cambiar a un lenguaje de programación, utilizar otro modelo de procesos, etc.). 

Como experiencia personal, la mayoría de los problemas del software parten de obviar los principios esenciales, y se incrementan al intentar solucionarlos exclusivamente desde la vía accidental. Como profesional deberíamos cuidar más el conocimiento esencial, la educación y formación en el mismo. El conocimiento accidental es necesario para poder trabajar, pero el esencial es necesario para además hacer un buen trabajo. El difundir y aprender el cómo trabajar correctamente con la parte esencial del software, esa jartá de conocimiento que existe y se ha ido creando a lo largo de la cronología del software, es quizás uno de los principales retos de nuestra profesión y muchos deberían aprender a apreciarlo en su justa medida. Muchos han sido los  partífices en estableces esas bases.

Al Liquindoi... ¿Reconocerías a un Knowmads?

El término knowmad combina las palabaras know (conocer) y nomad (nómada) nos informa del perfil de un trabajador capaz de ser un "nómada del conocimiento y la innovación", es valorado por sus conocimiento personales, lo que nos proporciona una ventaja competitiva coon respecto a otros trabajadores/compañeros.

Algunas de las características sobre éste tipo de perfiles:

• No está limitado a una edad determinada.
• Adaptativoa diferentes contextos y entornos.
• Creativo, innovador, colaborativo y motivado.
• Consciente de liberar el acceso a la información (sin límites geográficos).
• Entiende cómo y porqué funcionan las tecnologías digitales.
• Aprendizaje permanente.
• No teme al fracaso.

En la sociedad TIC los trabajadores de la sociedad de la información y del conocimiento se han vuelto mucho menos específicas en términos de ubicación y de las tareas a desempeñar, lo cual se ve favorecido por las tecnologías que permiten efectuar buena parte del trabajo de manera virtual. Los knowmads tienen la capacidad de volver a configurar y contextualizar su espacio de trabajo en cualquier momento, intercambiando información e ideas con otros profesionales, lo que genera ideas, productos y servicios muy diferentes a lo que haría cada uno por su parte.

Cualquier persona, desde CEO o empresario hasta el empleado de primera línea, puede ser knowmad.Y no es moda pasajera porque va a ser el tipo de profesional que más crezca y se desarrolle en el futuro cercano, básicamente porque es el que reúne todas las condiciones para trabajar con las exigencias que piden los nuevos tiempos, y que por lo tanto también será el que requieran las empresas.

Foto: Obtenida de "ENJI - Encuentro Nacional de Jóvenes Innovadores"