… de personas y sistemas.
Archivo de febrero, 2010
Metodologías Agiles & PMI
20 feb
El Jueves 4 de Marzo de 2010 a las 18:30 horas estaré brindando una charla de aproximadamente una hora en la reunión mensual de miembros del Capítulo Buenos Aires del PMI.
La charla se titula “Metodologías Agiles & PMI” donde se presentarán los supuestos que dan forma a la gestión de proyectos tradicional desde un enfoque más ágil acerca de la gestión del tiempo, costo y alcance. Recorriendo los procesos y áreas de conocimiento del PMBOK, se mostrará la manera de adaptarlos a los proyectos ágiles. Se presentarán consejos prácticos que cualquier PMP puede aplicar hoy mismo para comenzar a construir de inmediato un entorno ágil en sus proyectos. Todo esto estará comentado en base a experiencias pasadas.
Todo PMP que asista acreditará 1.5 PDUs (categoría 3).
Quién esté interesado en participar en esta Reunión de Miembros, por favor, exprese su intención de asistir cliqueando aquí. Ante cualquier duda, consulte a rm@pmi.org.ar
Metodologías Agiles & PMI
Roles Ágiles
11 feb
“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
10 feb
“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. Más >
Testers Ágiles
9 feb
“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. Más >
DBAs Ágiles
5 feb
“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 “DBAs” como parte de la serie “Roles ágiles“.
DBAs Ágiles
Los profesionales de datos, sean administradores de bases de datos, ingenieros de base de datos, o algo más, pueden ser unos de los más resistentes a la adopción de Scrum. Mucho de lo que en la sección anterior se dijo acerca de los programadores también aplica para los administradores de base de datos. Además, los profesionales de datos se enfrentan a aprender a hacer gradualmente lo que ha sido considerado tradicionalmente como parte de un proyecto tradicional. Más >
Programadores Ágiles
5 feb
“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. Más >
Gerentes Funcionales Ágiles
2 feb
“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. Más >
Agile en Acción! en Buenos Aires – Marzo de 2010
1 feb
Estaré dictando un workshop en Marzo orientado a la inicialización y planificación de un proyecto real con Scrum.
Las fechas son 16, 19, 23 y 26 de marzo de 2010 de 18:30 a 22:30 horas.
Este workshop de 4 días pone el foco en iniciar y planificar un proyecto real de desarrollo de software utilizando Scrum. Se verá muy detalladamente cada uno de los elementos que componen scrum (backlog, user story, priorización, estimación, release planning, sprint planning, etc) y los participantes crearán a lo largo de una serie de talleres los elementos del proyecto real.
El objetivo de este entrenamiento práctico es que los participantes:
- Obtengan un conocimiento más profundo sobre metodologías ágiles, valores y prácticas.
- Pongan en práctica los conocimientos adquiridos en el curso de certificación CSM (para quienes lo hayan hecho)
- Obtengan experiencia vivencial a través de una simulación de proyecto ágil
- Estén preparados para trabajar en un entorno ágil
Agile en Acción! está dirigido a:
- Equipos de desarrollo, Gerentes de Proyecto y CTOs que quieran implementar metodologías ágiles en su entorno de trabajo y prefieran tener una experiencia práctica antes de hacerlo
- Equipos de desarrollo, ScrumMasters y CTOs que estén implementando metodologías ágiles en su entorno de trabajo y quieran encontrar soluciones prácticas a problemas comunes
- ScrumMasters que hayan asistido a un curso de CSM y quieran aplicar los conocimientos adquiridos en un ejemplo real
- Estudiantes de Sistemas o carreras afines que deseen adquirir experiencia real en desarrollo ágil y gestión ágil de proyectos para de esa manera adquirir un perfil más competitivo en el mercado de IT
- Profesionales de Sistemas o afines que deseen incorporar conocimientos y experiencia real en gestión de proyectos ágiles
Arquitectos Ágiles
1 feb
“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?
