… de personas y sistemas.
Proyectos Ágiles
Diseñadores de Experiencia de Usuario Ágiles
0hace 1 año
“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
0hace 1 año
“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
0hace 1 año
“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
0hace 1 año
“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
0hace 2 años
“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
0hace 2 años
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
0hace 2 años
“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
0hace 2 años
“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. (más…)
Analistas Ágiles
0hace 2 años
“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. (más…)
Pausas entre Sprints
0hace 2 años
por Martin Alaimo
en Proyectos Ágiles
La semana pasada hubo una conversación dentro de una organización en la cual estoy trabajando con la implementación de metodologías ágiles en la industria de servicios creativos.
El punto clave era si había una forma de introducir una pausa entre sprints, esto es algo que surgió de una retrospectiva. El hecho es que el equipo lo solicitó, pero el Product Owner no estaba del todo de acuerdo, en realidad no quería pausas entre sprints. Sus argumentos fueron: Necesitamos un ritmo sostenido y pasar todo el tiempo haciendo el trabajo necesario para producir los entregables.
Después de discutir con ambas partes y que ellos expongan sus puntos de vista, le di mi opinión:
Yo personalmente no creo que tener un descanso entre sprints atente contra el ritmo sostenido. La ritmo sostenido es como su nombre lo indica: “ritmo”, los latidos del corazón, no es sobre “el desarrollo continuo”. Es decir, podemos tener un sprint de longitud fija, sin alteraciones y una pausa de longitud fija, digamos de medio día. Si lo hacemos de esa manera, y preservamos esas longitudes en el tiempo, entonces todavía seguimos hablando de ritmo sostenido, ¿correcto?
Otra situación podría ser completamente diferente si tenemos longitudes de tiempo aleatorias, como la mitad un día después del primer sprint, dos días después del segundo sprint y un día después del tercer sprint. Esto atenta completamente contra el “ritmo sostenido”.
Por otra parte, al hablar de “desarrollo continuo”, me di cuenta de que el PO estaba hablando de que los miembros del equipo solo debían trabajar en entregables creativas todo el tiempo (diseño, redacción, creación, etc) … ok, yo tendría mucho cuidado en esto, debido a que la gente todavía necesita ser capacitada y entrenada, independientemente de la industria en la que estén.
Yo mismo vengo de la industria de la ingeniería de sistemas, un rubro en el que cualquiera puede convertirse en un programador obsoleto si no recibe entrenamiento o actualizaciones sobre las últimas tecnologías. Por supuesto, esto es de alguna manera extremo, pero ocurre a todas las personas independientemente de su industria.
No hubo demasiada discusión hasta que logramos un acuerdo compartido sobre los descansos entre sprints: decidimos tener la demo y reuniones de retrospectiva durante la mañana del último día de cada sprint y luego un espacio libre durante la tarde (cada 2 semanas).
¿Qué van a hacer? Bueno, será utilizado de tres formas diferentes:
- El equipo asistirá a las sesiones de entrenamiento o preparará las sesiones de capacitación sobre actualizaciones de la industria o
- invitar a alguien de interés a asistir a una sesión de discusión con ellos, a fin de actualizarse y discutir sobre nuevos enfoques, nuevos movimientos o de los últimos eventos de la industria o
- Las personas participar en el blog corporativo, con un artículo, o conseguir que participen en las conversaciones en blogs y así conseguir los beneficios de la web 2.0
Estaremos monitoreando de cerca cómo va esto… estoy muy emocionado con este enfoque. Sin duda alguna, recomendaría una pausa de estas características entre sprints. 
