… de personas y sistemas.
Traducciones
¿Qué pasaría si los médicos fuesen tratados como desarrolladores web?
21 jun
Mientras está ahi sacando el tumor, arregle mi nariz y ponga unos implantes mamarios. No puedo pagar por eso, pero prometo mostrárselo a todos mis amigos y va a quedar excelente en su currículum.
¿Te imaginas tratando a tu médico de esta manera?
Desafortunadamente, así es como muchos desarrolladores web y desarrolladores de software suelen ser tratados por los clientes.
Debido a que el desarrollo de sitios web es una ocupación bastante nueva, aún hay mucha gente que no entiende qué se requiere para la realización de ese sitio web impresionante.
Yo personalmente he estado como receptor de varias solicitudes bastante ridículas por parte de algunos clientes.
Es tan común, que sitios como Clients from hell existen y están llenos de historias que a primera vista parecen totalmente ficticias. Pero no lo son.
Pero ve y habla con alguien que trabaje en el desarrollo web y pregúntales acerca de los clientes de terror. Cada uno de ellos tendrá una historia que contar.
Mi teoría es que debido a que la persona promedio sólo ve “el frente” de los sitios web, no tienen idea de la labor de codificación y el tiempo que se tarda en crear un buen producto web. No llegan a “mirar debajo del capó” y ver todos los scripts, llamadas, estilos CSS, etc
Si lo hicieran, habría más entendimiento de que este es un trabajo real, no sólo un trabajo que un aficionado realiza en su tiempo libre.
(También, muchos operadores del “descuento”, como los equipos de desarrollo offshore y diseñadores no calificados contribuyen a perpetuar el mito de que esta obra es barata y fácil de hacer)
Piense en las industrias donde los clientes tienen una mejor comprensión del resultado final:
- Los clientes no le dirían a un mecánico que les realice tareas extras gratis sólo porque se encuentran en el motor de todos modos.
- Los clientes no le pedirían a un arquitecto la remodelación total de un plan de construcción una vez que se hace, a las 9 am del día siguiente, debido que a su hijo de 6 años no le gusta.
- A los pintores de casas no se les pide que vuelvan a pintar una casa de forma gratuita, porque el color se ve diferente ahora que cuando se ve en el sol de la mañana.
- A los abogados no se les pide que trabajen en un caso de forma gratuita, ya que puede quedar bien en su currículum más tarde.
Lamentablemente, estos casos existen dentro de la dinámica actual de cliente-desarrollador.
Yo, por ejemplo, espero que esto cambio pronto.
Traducción directa. Fuente: Agent-X.
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 >
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?
Gerentes de Proyecto Ágiles
29 ene
“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
24 ene
“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 >
