Si bien las herramientas no son decisivas (y el manifiesto ágil lo deja bien claro), es también cierto que ellas tienen una incidencia importante cuando se trata del desarrollo del software. Una herramienta bien elegida puede minimizar los recursos necesarios para gestionar nuestro proyecto.

Pero es cierto también que aunque no tengamos la herramienta ideal, conociendo el proceso podemos obtener los resultados esperados a un costo accesible y sin necesidad de adquirir la herramienta que consideramos más adapta para nuestra situación.

En este artículo, Antonio Delgado nos comparte su propia experiencia usando Excel para crear un tablero para medir el avance de un proyecto.

Publicado en Scrum

Las metodologías ágiles están de moda... sobre esto no hay duda. De hecho, distintas empresas están buscando transformar su modo de trabajar usando estas metodologías, a veces por motivos que las mismas desconocen.

En estos casos, Scrum suele ser la solución elegida ya que combina la posibilidad de cambiar la visión del equipo desde el producto hacia la necesidad del negocio, al mismo tiempo que otorga al nivel ejecutivo esa sensación de previsión -generalmente falsa- a la que estaban acostumbrados con los procesos anteriores.

En mi experiencia, cuando se trabaja con la provisión de un servicio y no con el desarrollo de un producto, el ritual que presenta más desafíos es el de la demo; probablemente porque se tiene la percepción de que se está realizando un ritual vacío... y esta sensación puede sabotear la transformación a agile de equipos o incluso de organizaciones enteras.

Esto representa un desafío: ¿Cómo hacemos para que el equipo vea el sentido de realizar la demo en aquellos ambientes donde no están trabajando sobre un producto sino sobre un servicio?

En este artículo intentaré aportar elementos para una respuesta...

Publicado en Scrum

Luego del artículo anterior sobre la transparencia, llega el momento de otro valor que forma parte de la misma cadena, y es el coraje.

Y si bien todos sabemos a que nos referimos cuando hablamos de coraje, este suele ser uno de los valores  que suelen generar mas dudas cuando no nos encontramos en ambientes de desarrollo.

¿Qué se entiende con coraje?  ¿Coraje en que sentido? ¿Coraje para hacer qué cosa? Suelen ser las preguntas que más veces he escuchado... Sobre todo por parte de quienes gestionan equipos, quizás temiendo que los actos del equipo puedan provocar actitudes indeseadas.

Veamos algunas reflexiones que quizás aporten a resolver estas dudas.

Publicado en Scrum

Hace algunos meses hice una presentación sobre la reconstrucción lingüistica de las emociones, en la segunda conferencia del año 2015 del curso de coaching ontológico del Grupo Recrearte.

Como me ha sucedido en otras oportunidades, el tener que dar una charla fue una ocasión para profundizar un tema que todo buen coach ontológico debe conocer, y que a veces queda algo relegado debido a la cantidad de temas que se ven durante la carrera.

Luego de realizada la exposición (de aproximadamente 20 minutos), compartí la presentación en slideshare para los estudiantes. Me sorprendió (y me sigue sorprendiendo) la repercusión pública que está teniendo, ya que lo considero un tema técnico de poco interés para el público en general, y además la presentación no tiene el atractivo que podría tener una presentación preparada para un público amplio.

Probablemente la difusión se deba a que no se encuentra mucho material en red sobre este tema.

Pero ¿qué es la reconstrucción linguistica de las emociones?... en pocas palabras, podría entenderse como traducir en palabras la emoción que sentimos, de un modo que sea genuino y al mismo tiempo no tenga la carga emotiva que podemos estar sintiendo y nos puede estar condicionando.

No tengo las fuentes, pero he leído en algún lado que este método se ha probado por ejemplo con prisioneros agresivos, y se han obtenido buenos resultados.

La presentación está disponible en este link: http://www.slideshare.net/eldba/reconstruccion-linguistica-de-las-emociones.

Publicado en Coaching

Desde hace ya varios años, se habla y se discute sobre la deuda técnica como de algo sabido por todos. Sin embargo, en mi experiencia, este no es un tema suficientemente analizado o comprendido por la generalidad de los desarrolladores y los ejecutivos que conozco.

¿A qué nos referimos con el concepto de "deuda técnica"?... básicamente, con este término nos referimos a todas esas decisiones tanto hardware como software, que puedan comprometer la calidad o el funcionamiento del producto. Un ejemplo: desarrollar un sistema software sin pruebas unitarias para minimizar los tiempos de desarrollo por una necesidad urgente de oportunidad o de mercado.

La idea es que "puede ser algo que ahora funciona o tiene sentido", pero que en realidad pagaremos en el futuro cuando suframos las consecuencias de nuestras decisiones (por ejemplo dificultad para mantener el sistema, calidad insuficiente, etc)

Dicho de este modo, pareciera que el concepto de deuda técnica queda claro, y de hecho es un concepto simple, pero hay muchos grises en esta definición ya que queda librada al juicio de un equipo o de una persona, por lo que las interpretaciones pueden diferir entre equipos o personas.

Veamos algunos conceptos que creo son importantes al momento de identificar estas situaciones:

Publicado en Scrum

Esta técnica es en sí misma bastante sencilla, y fue creada por Francesco Cirillo cuando era estudiante. La misma consiste básicamente en dividir el tiempo disponible en "pomodoros" o unidades de tiempo fijas (generalmente 25 minutos) separados entre ellos por momentos de esparcimiento que generalmente son de 5 minutos.

Publicado en Gestión del tiempo
Volver arriba