jgarzas
Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
Latest posts by jgarzas (see all)
- ¡Vota la peor frase de 2019! - 11 diciembre, 2019
- Los requisitos nunca se entienden y el usuario sabe lo que quiere cuando lo ve funcionando - 10 diciembre, 2019
- TCR (Test && Commit || Revert) como alternativa a TDD - 9 diciembre, 2019
Escribí hace relativamente poco un artículo sobre T-Shaped skills, y lo tengo en cola, pendiente de publicar. Pero yo lo entiendo más a nivel individual que a nivel de equipo. Es decir, si tengo un equipo orientado a un producto, tengo todos los conocimientos necesarios en él: QA, Front, Back, BD, …
El objetivo de tener habilidades en T, es tener por lo menos a uno que domine de CSS, uno que domine de Angular, uno que domine de las tecnologías de Back, … Pero que todos puedan hacer de todo, para que el equipo pueda adaptarse a las necesidades que requieren las historias que pasa el product owner.
Así cada uno sabe un poco de todo, pero es experto en algo.