… de personas y sistemas.
Desarrollo de Software
Roles Ágiles
feb 11
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn que habla acerca de cómo se ven afectados estos roles al transicionar a Scrum:
- Analistas
- Gerentes de Proyectos
- Gerentes Funcionales
- Programadores
- DBAs
- Testers
- Arquitectos
- Diseñadores de UX
He encontrado muchas cosas interesantes y dignas de un buen debate. Seguramente proponga discutir el tema en alguno de los encuentro ágiles que hacemos mensualmente en Buenos Aires.
Diseñadores de Experiencia de Usuario Ágiles
feb 10
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Diseñadores de Experiencia de Usuario” como parte de la serie “Roles ágiles“.
Diseñadores de Experiencia de Usuario Ágiles
Los diseñadores de experiencia de usuario (User Experience Designers) a menudo tienen una preocupación legítima con la adopción de Scrum. A pesar de que están acostumbrados a trabajar de forma iterativa, prefieren ejecutar sus iteraciones antes que el resto del proyecto. En un proyecto Scrum, sin embargo, no queremos hacer todo el trabajo UED antes de comenzar las actividades de desarrollo. Lee el resto del articulo »
Testers Ágiles
feb 9
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Testers”” como parte de la serie “Roles ágiles“.
Testers Ágiles
Durante años, el enfoque de la prueba se ha basado en la definición de Philip Crosby de la calidad: la conformidad con los requisitos. Si la calidad es la conformidad con los requisitos, entonces los mejor es que dichos requisitos estén escritos. Esto ha llevado a muchos Testers a una búsqueda exagerada de un documento de requerimiento perfecto con el que puedan confirmar el cumplimiento del sistema. Sin embargo, si bien la conformidad con los requisitos es buena, la conformidad con las necesidades de los usuarios es aún mejor. En el uso de Scrum reconocemos que es imposible predecir a la perfección todas las necesidades de los usuarios. Lee el resto del articulo »
Programadores Ágiles
feb 5
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Programadores” como parte de la serie “Roles ágiles“.
Programadores Ágiles
¿Qué hacen los programadores en un equipo Scrum? Programan. Prueban. Analizan. Diseñan. Hacen todo lo necesario para ayudar al equipo a completar el trabajo comprometido en un sprint. A pesar de que está bien tener un equipo de especialistas en Scrum, los especialistas tienen que estar dispuestas a trabajar fuera de su especialidad cuando sea necesario por el bien del equipo. Lee el resto del articulo »
Gerentes Funcionales Ágiles
feb 2
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Gerentes Funcionales” como parte de la serie “Roles ágiles“.
Gerentes Funcionales Ágiles
Los gerentes funcionales, tales como gerentes de desarrollo, gerentes de QA, etcétera, que están acostumbrados a trabajar de una forma matricial seguirán trabajando de esa manera en los proyectos Scrum. Un gerente funcional típico probablemente experimentará cierta disminución en el poder después de la transición, pero esto dependerá en gran medida de cómo el rol fue definido en la organización antes de la transición. Lee el resto del articulo »
Arquitectos Ágiles
feb 1
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Arquitectos” como parte de la serie “Roles ágiles“.
Arquitectos Ágiles
Muchos arquitectos han trabajado durante años para merecer el título de arquitecto. Están legítimamente orgullosos de sus conocimientos, experiencia y capacidad para proponer soluciones elegantes a los desafíos técnicos y de negocio. Me parece que muchas de las preocupaciones planteadas por los arquitectos frente a la adopción de Scrum se pueden ubicar en estas dos categorías:
- ¿Las Personas seguirán aplicando las arquitecturas que les digo?
- ¿Cómo puedo asegurar que construiremos un producto con buena arquitectura sin una fase de diseño de arquitectura?
Gerentes de Proyecto Ágiles
ene 29
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico solo la sección de “Gerentes de Proyecto” como parte de la serie “Roles ágiles“.
Gerentes de Proyecto
En un proyecto con un proceso de desarrollo secuencial, el gerente del proyecto tiene la difícil tarea de asegurar que el producto que desea un cliente es el que se desarrolla. Para ello, el gerente del proyecto debe tratar de manejar todo lo relacionado con el alcance, costo, calidad, personal, comunicación, riesgo, adquisiciones, etc. Algunas de estas responsabilidades en realidad pertenecen a otros. El control del Alcance, por ejemplo, por derecho le pertenece al cliente. Lee el resto del articulo »
Analistas Ágiles
ene 24
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico solo la sección de “Analistas” como parte de la serie “Roles ágiles“.
Analistas
Con un conocimiento íntimo del producto y fuertes habilidades de comunicación, algunos analistas van a tender a transformarse en Product Owners. Lee el resto del articulo »
Triple Restricción Ágil
ene 17
Volviendo de las vacaciones, este año que pasó fue bastante movilizante; lleno de cambios y desafíos. Este año que vino es uno del cual soy muy optimista; veo muchas oportunidades, espacios de discusión y nuevas ideas apareciendo.
Año Nuevo: blog post nuevo. Esta oportunidad quiero escribir acerca de una comparación/competencia que escucho mucho en el mundo ágil: PMPs en un entorno ágil.
Muchas veces escucho preguntas o argumentos de parte de PMPs (yo mismo también soy PMP) acerca de cómo implementar agile, por qué agile no aplica en un entorno PMI, y demás.
Están sucediendo muchas cosas en el mundoPMI-Agile, especialmente desde mediados del 2009. Un enfoque interesante que he escuchado sobre cómo ayudar a PMPs a cambiar su filosofía/o entender mejor la forma en la que agile funciona a alto nivel es:
Agile se concentra en tres aspectos diferentes:
- Prácticas de Ingeniería
- Prácticas de Liderazgo
- Prácticas de Gestión de Proyectos
Enfocándonos solo en el aspecto de la Gestión de Proyectos, podemos hablar de la conocida “restricción triple”:
En cualquier entorno de Gestión de Proyectos, las variables más importantesa monitorear son: Alcance, Tiempo y Costo. (También lo son la Calidad, la Satisfacción del Cliente y los Riesgos; pero en esta oportunidad prestaremos especial atención a las primeras tres).
la Gestión de Proyectos tradicional determina que siempre que se comience un proyecto, se debería comenzar por el Alcance. Una vez que elalcance esté lo suficientemente claro uno puede comenzar a “jugar” con los recursos, asignaciones, secuencias de actividades, etc., que nos llevarán a determinar el Tiempo que va a llevar y el Costo del trabajo. Resultado: unlindo Gantt chart.
Luego uno presenta este Gantt chart a los sponsors y la reacción típica es: Nos solicitan reducir el Tiempo y el Costo. 
Luego, como Project Manager, uno comienza a pensar en incrementar el equipo, dividir el trabajo en diferentes fases, construir en paralelo (incrementando el riesgo, por supuesto). El desafío tradicional luego se convierte en elproblema tradicional: Gantt charts muycomplejos, con dependencias complejas que van a requerir coordinación compleja.
En vez de eso, el enfoque ágil ataca el problema desde otra dirección; el punto de partida es el Tiempo y el Costo: Cuánto dinero se quiere invertir durante cuento tiempo? Esto da como resultado un equipo durante una tiempo predeterminado, y el compromiso de entregar la mayor cantidad de software funcionando posible.
De esa manera tenemos:
- Un Costo fijo: El equipo en sí (horas de trabajo).
- UnTiempo fijo: Time boxes, iteraciones, releases.
- Un Alcance variable: El alcance es el lado variable del triángulo, el cuales inyectado iteración trás iteración y transformado en software funcionando.
En mi opinión, esta es la explicación más clara de la diferencia de puntos de vista de cada enfoque: tradicional y ágil. ¿No te parece?
Fotografía por Yui Kubo: http://www.flickr.com/photos/yu-kubo/398714467/
Trabajando con la Generación Y
jun 19
Liderar un equipo de gente joven (y no me estoy refiriendo al niño interior que todos llevamos dentro, sino a adultos jóvenes en sus 20s) requiere conocerlos y entender cómo interactúan con las metodologías agiles.
¿Quiénes son? La generación “Y” o también llamados “Millennials”, “Internet Generation” e incluso “Google Generation” es la que comprende al grupo poblacional nacido entre 1981 y 1997. Y ya se han convertido en la nueva “fuerza laboral” mundial.
Es la generación de MTV y las zapatillas “All Stars” que vivió el fin de la Guerra Fría, la expansión de modelos familiares no tradicionales, y la revolución tecnológica. Son los jóvenes que no conciben la vida sin tecnología (SMS, telefonía celular, IPods, Reality Shows, Internet 2.0) y que probablemente no podrían vivir sin ella.
La fuerte identificación de grupo a partir del cual construyen su identidad personal es una de sus características más contundentes (¿a quién no le suena el concepto de “tribus urbanas”?). No piensan en un futuro teniendo como eje el trabajo (como sí sucede en las generaciones anteriores), ni mucho menos piensan en un proyecto a largo plazo. Su proyecto de vida es el “hoy”, son curiosos, les encanta experimentar, cambiar de trabajos y no “casarse con nadie”.
Por alguna razón, a diferencia de la generación que los antecede, no sienten entusiasmo por la vida pública y no aceptan los modelos tradicionales de autoridad, siendo más colaborativos que jerárquicos.
¿Qué es lo que hay que tener en cuenta para trabajar con la Generación Y en el desarrollo de tecnologías, pero también en cualquier otro tipo de trabajo?
- La Generación Y es ávida de aprender, y les gusta mantenerse al día con los avances tecnológicos, algo muy positivo para captar rápidamente nuevos conceptos y modalidades de trabajo
- Mantienen un nivel muy bajo de concentración, y se aburren fácilmente. Por ello son recomendables las tareas que no se expanden en el tiempo y que brindan resultados concretos a corto plazo. Esto no quiere decir que no les guste trabajar, al contrario, son muy entusiastas, pero requieren gratificaciones inmediatas (tal como las obtuvieron en su infancia)
- Por otro lado, ignoran los planes a largo plazo, los alcances estrictamente definidos. Tienen afinidad con la planificación y el desarrollo incremental del cual quieren participar activamente.
- Son impacientes: no pueden esperar para obtener un mejor puesto, incluso aunque recién hayan empezado y no cuenten con la experiencia necesaria. Hay que ayudarlos a controlar su ansiedad.
- Están acostumbrados al caos, y de alguna manera no les disgusta la confusión. Esto representa una ventaja si se consideran los constantes cambios que vemos hoy en los negocios. Sin embargo, requieren de un fuerte acompañamiento que los guie y un entorno tal que acepte estos cambios y los mantenga enfocados hacia objetivos en continua redefinición.
- Son flexibles (tal vez demasiado). La variedad de opciones que tienen al alcance de su mano les hace pensar que si no obtienen lo que quieren de algún modo, pueden conseguirlo de otro. Esto afecta el empleo en la medida en que a la hora de elegir un trabajo, muchos de ellos no trabajan “porque lo necesitan” sino “porque quieren” y los horarios, las exigencias, el salario y el crecimiento laboral son cruciales a la hora de elegir quedarse o irse de un trabajo.
- “multi-tasking”: Desarrollaron una gran habilidad para manejar más de un tema al mismo tiempo. Lo que a simple vista parece una ventaja, Puede tornarse en un problema por la dispersión y el retraso que el multi tasking genera en contraposición a trabajar enfocado en una cosa por vez.
Aun son muy jóvenes. Aunque parece que “lo supieran todo” por el modo en que se presentan, los jóvenes Y no cuentan con una gran experiencia en el mercado laboral, y no sabemos exactamente qué esperar de ellos en su comportamiento laboral. Además, Su reciente incorporación al mercado de trabajo y su modo de trabajar puede traer conflictos de integración con las generaciones anteriores. Por ello es necesario conocer cómo actúan y mantenerse alerta en pos del equipo.
Con sus pros y sus contras, la generación Y llego para quedarse y las metodologías ágiles van a crecer con ellos, retrospectiva tras retrospectiva, incorporando su input y siendo modeladas en base a su comportamiento. Definitivamente.