Mostrando entradas con la etiqueta Equipos. Mostrar todas las entradas
Mostrando entradas con la etiqueta Equipos. Mostrar todas las entradas

jueves, 11 de agosto de 2016

[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

viernes, 10 de junio de 2016

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!