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.

“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.

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. Mis descripciones favoritas de cómo funcionan los diseñadores ágiles han surgido de Autodesk en Toronto. Lynn Miller y Desiree Sy han escrito sobre el enfoque que han utilizado para integrar el diseño en un proceso ágil. He trabajado en docenas de proyectos en los que los equipos y diseñadores adoptaron su consejo.

Según Miller y Sy, debería haber dos vías paralelas de trabajo en el proyecto: una para el desarrollo y una para el diseño de interacción. La figura 8.2 muestra estas dos vías y la interacción entre ellas. La idea esencial aquí es que el trabajo UED siempre precede a la labor de desarrollo en por lo menos un sprint. A los UEDs se les da una ventaja inicial en el proyecto a través de una combinación de un sprint cero inicial y un enfoque en el sprint uno en funcionalidades con pocas o ninguna implicancias de interfaz de usuario.

El enfoque que se muestra aquí puede trabajar bien, pero trae consigo el riesgo de que UEDs se ven a sí mismos como un equipo independiente. Lynn Miller esbozó la primera versión de este diagrama y está de acuerdo en que no debe ser interpretado como que hay equipos separados.

Siempre que he enseñado este concepto en insistí en que los diseñadores no debe pensar en sí mismos como un equipo independiente y que la comunicación estrecha y frecuente es esencial para el concepto funcione. Siempre ha habido un fallo en el diagrama que parece sugerir la separación del equipo cuando esa nunca fue mi intención.

Es esencial que los UEDs se ven a sí mismos como parte del equipo. La idea de equipos interdisciplinarios es fundamental en Scrum, el equipo debe incluir a todos los necesarios para llegar de la idea a la implementación. ¿Qué impediría a un equipo de testing la preparación de su propia versión de la figura 8.2 que muestre las pistas paralelas de la programación y sprints de testing?

Si yo encontrara a un UED en el pasillo de su empresa y preguntara, “¿Qué haces tú?” Podría obtener una respuesta como esta: “Soy un diseñador de experiencia de usuario. Yo trabajo de un sprint delante de los desarrolladores. Mi trabajo es asegurarme de que cuando empiezan un sprint les pueda dar un diseño de lo que van a desarrollar en ese sprint“. Esta respuesta se corresponde con la figura 8.2, pero no es una respuesta que me gusta. En lugar de eso prefiere escuchar “Soy un diseñador de experiencia de usuario. Estoy en el equipo de desarrollo, y mi trabajo principal es asegurarnos de terminar lo que nos comprometemos a trabajar para cada sprint. Pero eso no ocupa todo mi tiempo, entonces empleo una buena cantidad del mismo mirando hacia adelante en lo que vamos a construir en un sprint o dos. Luego reúno datos, maqueto diseños, y hago todo lo que está a mi alcance para que cuando empecemos una característica en un sprint futuro, seamos capaces de terminarlo en ese mismo sprint. “

Ambas citas ficticias describir exactamente el mismo trabajo. En ambos casos, los UEDs están trabajando con el equipo durante el sprint para resolver los problemas de ese sprint, pero también miran hacia adelante. Sin embargo, las dos respuestas reflejan diferentes modos de pensar sobre el trabajo. En primer lugar, quiero que los UEDs se sientan parte del equipo y que su principal prioridad sea la entrega de la funcionalidad a la que se han comprometido para el sprint actual. Más allá de eso, su trabajo es mirar hacia adelante de la misma manera que todo el mundo espera de un Product Owner, que mire hacia adelante lo que está haciendo la competencia, lo que los usuarios querrán a continuación, etc.

Yo no soy el único en pensar que una mentalidad ágil es fundamental para que los UEDs hagan la transición a Scrum. Un muy respetado experto en usabilidad -Jakob Nielsen- está de acuerdo:

Para los profesionales de experiencia de usuario que apoyan a los equipos ágil, el principal cambio es de mentalidad. Teniendo buen conocimiento general sobre la experiencia de usuario le ayudará a comprender cómo cambiar el diseño tradicional y métodos de evaluación para cumplir con el nuevo enfoque de su equipo Agile. En última instancia, sin embargo, ambos deben creer en sí mismos y comprender los conceptos del desarrollo ágil si quieren tener éxito. Si están preparados para cambiar sus prácticas y asumir la responsabilidad, hay grandes oportunidades para mejorar su eficacia y su impacto en los equipos en los que trabajan.

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. 

Así como los programadores ya no puede decir: “Dame las especificaciones perfectas, y luego desaparece mientras que hago que el sistema haga exactamente lo que has pidido”, los Testers no pueden decir, “Dame el documento de requisitos perfecto y me aseguraré de que el sistema haga todo lo que en él dice”. Cada una de estas actitudes (muy frecuentes en los proyectos administrados de forma tradicional) conduce a una abdicación de la responsabilidad. Cuando expresiones como éstas se expresan, el programador o tester que las dice está renunciando a la rendición de cuentas para el éxito final del proyecto. “Sólo dime qué hacer y lo haré”, cada uno está diciendo. En su lugar, cada uno tiene que pensar en el producto final y hacer preguntas acerca de cada función y cómo se añade a (o resta) el producto en general.

Dado que los equipos de Scrum cambian de de enfoque durante la recolección de requisitos, de escribir acerca de los requisitos para hablar de ellos, las conversaciones con el Product Owner se transforman en la principal fuente del tester para averiguar cómo una nueva funcionalidad debería comportarse. Un tester es probable que hable con el Product Owner acerca de cómo debería funcionar una característica, la rapidez con que debe realizar, qué criterios de aceptación debe pasar, etc. Los testers no se limitan a la adquisición de esta información únicamente de los Product Owners. Cuando sea necesario, los testers también deben hablar con los usuarios, clientes y otros stakeholders.

Al igual que para los programadores, trabajar en ese entorno interactivo puede ser incómodo para los testers que hacen la transición a Scrum. Muchos de los testers, como sus colegas, entraron en el desarrollo de software con la expectativa de que podría sentarse día a día en un cubículo con poca interacción humana. Ya no. Los testers de un equipo Scrum tendrá que acostumbrarse a conversaciones más frecuentes y significativas con sus compañeros de trabajo y, en muchos casos, las personas fuera del equipo.

Junto con renunciar al mito de que una especificación perfecta puede ser escrita de antemano, uno de los cambios más importantes que enfrentan los testers es aprender a trabajar de forma iterativa. Conceptualmente, esto no debería ser una cosa difícil de hacer. Si pensamos en cada sprint, como su propio proyecto, entonces la prueba para cada proyecto / Sprint se hace dentro de ese sprint. No es tan sencillo como determinar que la última semana de cada sprint se reservará para las pruebas. Esto no funciona y en su lugar crea cascadas en miniatura dentro de cada sprint. Durante los primeros sprints, los testers se enfrentarán a un reto inmenso. Durante ese tiempo, los programadores también están aprendiendo cómo trabajar de forma iterativa y probablemente no serán buenos en eso tampoco. El equipo probablemente se comprometa a entregar más de lo que puede hacerse en un sprint, y los programadores probablemente no tendrán ninguna de las características planeadas totalmente codificada sino hasta muy cerca del final del sprint. Así que se intentará entregar el código a los testers a los dieciocho días del sprint de veinte días. Después de que los individuos en estos roles aprender a trabajar de una manera ágil, estas entregas de última hora van a desaparecer.

Un mayor énfasis en la automatización de pruebas se convierte en un sello característico de los equipos Scrum. Incluso los equipos que han luchado durante años para lograr avances en la automatización de las pruebas encontrarán que los sprints cortos de Scrum transforman la automatización de pruebas en una necesidad. Con el tiempo esto reduce la dependencia de los testers manuales, los que leen un guión, pulse un botón, y toman nota de los resultados. A estos testers a menudo se les pide el aprendizaje de una o más herramientas de automatización de prueba para ser utilizada por el equipo. Si bien algunas herramientas de automatización de pruebas se basan en lo que bien podría ser llamado la programación para crear las pruebas, no todas lo hacen. He conocido a pocos testers manuales que han sido incapaces de hacer la transición para contribuir significativamente a los esfuerzos de sus equipos con la automatización de las pruebas. Por otra parte, he conocido a muchos que tienen miedo a este cambio. Tiempo, la práctica, la capacitación y la programación de a pares (incluso con un programador) debería ser suficiente para superar los temores.

Lisa Crispin, coautor con Janet Gregorio del libro Agile Testing, recuerda que cuando cambió a trabajar en un equipo ágil, lo primero que notó fue que tenía que ser proactiva.

No se siente y espere a que las cosas vengan a Ud. Sea proactivo! Nosotros los testers no podemos esperar para probar las tareas que vengan a nosotros. Hay que levantarse e involucrarse y averiguar qué hacer. Colaborar con los programadores es algo nuevo para muchos de los testers. Colaborar con los clientes también es nuevo para muchos de los testers. Es salir de la zona de confort para muchas personas. Los programadores son gente ocupada y con un poco de miedo, a veces. Cuando yo era la única tester de un equipo de ocho programadores, aunque la mayoría de ellos eran personas con las que había trabajado durante años en otra compañía, me requirió mucho coraje el hecho de pedir ayuda.

Si yo trabajo muy de cerca con el resto del equipo, voy a desarrollar “ojos de  programador”, haciendo que vea todo desde su perspectiva, no desde la perspectiva de un tester.
Es difícil ver cómo el hecho de trabajar más estrechamente con los programadores hará que los testers pierdan tanto la perspectiva que ya no puedan probar software. Los profesionales de bases de datos han trabajado estrechamente con los programadores durante años sin llegar a contaminarse tanto. Durante décadas, los testers se han abocado a hacer ambas pruebas: de caja blanca (en el que pueden ver el interior del sistema) y pruebas de caja negra (donde no pueden). Si el hecho de trabajar con un programador puede conducir al desarrollo de ” ojos de programador”, parecería lógico pensar que un tester que ha hecho pruebas de caja blanca, de modo similar, perdería la perspectiva y no sería capaz de hacer pruebas de caja negra. Afortunadamente, este no es el caso.

Aunque muchos de los cambios introducidos por Scrum puede ser incómodos al principio, la mayoría de los testers podrán disfrutar de sus nuevas formas de trabajar una vez se acostumbra a ellas. Jyri Partanen es un QA Manager en Sulake, los desarrolladores de Habbo, un mundo virtual con un promedio de más de ocho millones de visitantes únicos al mes. Partanen describe la transición necesaria de los testers.

El testing es una profesión donde los viejos hábitos tienden a durar. En el caso de la transición a la agilidad, adherirse a las viejas maneras de hacer las cosas puede conducir a una implementación mediocre del espíritu de agile. Normalmente la angustia de los ingenieros de pruebas se han relacionado con la seguridad laboral y los cambios que la transición ágil puede generar en su día a día. Esta es, sin embargo, una preocupación innecesaria. Basado en mi propia experiencia y la experiencia de otras personas que realmente han completado la transición a la agilidad con el personal de QA, lo que puedo decir con confianza es que el cambio ha sido sin duda una decisión inteligente. Los ingenieros de pruebas en los equipos ágiles tienen más influencia en el proceso de desarrollo y, lo que es aún más importante, en el producto final.

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.

El estándar en asesoramiento en diseño de bases de datos ha sido el de hacer un análisis completo de las necesidades del sistema, crear un diseño de base de datos lógica o conceptual, y luego el mapeo de esos conceptos a las limitaciones de una base de datos del mundo real, durante el diseño de base de datos física. El éxito en esta serie de pasos se basa en un análisis completo y preciso por adelantado. El punto de vista de los profesionales de datos tradicionales fue resumido de la mejor manera por un compañero de viaje en un avión de Chicago a Sacramento. Era un vicepresidente de desarrollo de base de datos para una compañía de salud relativamente grande. Su punto de vista sobre el mundo era “las aplicaciones cambian, los datos son para siempre”.

Este tipo de pensamiento conduce a un fuerte enfoque en hacer un análisis completo por adelantado. Esto es lindo en teoría, pero al mismo tiempo en que estamos haciendo  el análisis completo, el mundo sigue evolucionando. Las necesidades de los usuarios están cambiando. Los competidores están lanzando sus productos. Las bases de datos necesitan evolucionar para apoyar la evolución de las aplicaciones construidas sobre ellos.

En muchas formas, el diseño de experiencia de usuario, arquitectura y diseño de bases de datos son todos casos especiales del mismo desafío: trabajar de forma incremental en algo que está pensado de manera integral. Gran parte del día a día de un DBA no va a cambiar mucho, pero cómo los DBAs van a enfocarse y agendar su trabajo va a cambiar drásticamente y se discutirá en el capítulo “Trabajando Juntos a lo largo del Sprint”.

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. Hay excepciones. Un proyecto de desarrollo de un juego puede, por ejemplo, beneficiarse de los especialistas en inteligencia artificial. Debido a la naturaleza altamente especializada de sus productos, estos especialistas no pueden hacer nada fuera de su especialidad. La mayoría de los programadores en un equipo Scrum, sin embargo, deben estar dispuestos a contribuir en cualquier número de maneras en optimizar el rendimiento del equipo en general. Esto significa que probarán cuando sea necesario, programar en un lenguaje que no es el preferido, etc.

Uno de los cambios más notables para los programadores en un equipo Scrum es que ya no pueden sentarse en sus cubículos y esperar que se les diga exactamente qué debe programar. Ellos necesitan convertirse en participantes activos en la comprensión de los requisitos del producto. Sorprendentemente, hay muchas personas que simplemente quieren que se les diga en qué trabajar. Yo he escuchado expresiones como, “si me dicen en qué trabajar y yo lo hago, entonces no puedo ser despedido”. Los programadores en un equipo Scrum, como todos los demás en el equipo, se espera que sean responsables del éxito global del producto. Cuando esta responsabilidad se siente plenamente, es más fácil hacer las cosas que van más allá de la mera descripción del trabajo normal.

Los programadores también deberían hablar con los clientes y usuarios. La intensidad de esta interacción se puede ajustar hacia arriba o hacia abajo basado en el programador, la organización, los puntos fuertes de otros miembros del equipo, y la naturaleza del proyecto. Los programadores no necesitan desarrollar una personalidad sociable, vendedora. Pero es necesario que de vez en cuando se sientan cómodos hablando con un usuario o cliente, incluso si es sólo por teléfono.

Del mismo modo, los programadores pueden esperar pasar más tiempo interactuando con sus compañeros de trabajo. Un programador no puede permitirse entrar a las 11 de la mañana y usar auriculares hasta irse en silencio a las 7 de la tarde. En cambio, los programadores deberían sentirse en un espacio de equipo, participar en discusiones, ayudar a otros con problemas, y participar en la programación de a pares.

Estos cambios pueden ser bastante inquietante para muchos programadores (yo incluido) que nos metimos en este rubro porque pensamos que podíamos sentarnos solos en nuestros cubículos todo el día. Antes de mi primer trabajo de programación, yo trabajaba en un cuarto oscuro  de seis por cuatro pies totalmente cerrado revelando fotografías todo el día. Salía en los descansos regulares y para comer, de lo contrario yo estaba solo en la oscuridad todo el día y me encantaba. Moverse en el mundo iluminado de cubículos fue un gran cambio. Pasar de cubículos tranquilos al dinamismo de la cultura conversadora es un cambio aún más grande. De los programadores en un equipo Scrum se espera que hagan esta transición. Afortunadamente, sin embargo, el cambio, no es tan difícil para la mayoría de nosotros. Es posible que les guste estar solos, pero nos encontramos participando en conversaciones estructuradas (como en las reuniones de toma de decisiones y los debates sobre un proyecto Scrum) mucho más fácil que las conversaciones no estructurada, en un cóctel.

Más allá de los cambios en la comunicación y la interacción, los programadores es casi seguro que experimenten cambios en la forma en que hacen su trabajo. Prácticas técnicas como la programación de a pares, desarrollo basado en pruebas (TDD), y un fuerte énfasis en las pruebas unitarias automatizadas serán nuevas para ellos. El equipo puede decidir no adoptar todas estas prácticas en un primer momento (o nunca en algunos casos), pero le sugiero que todas sean considerados y probadas.

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.

Los gerentes funcionales suelen conservar la responsabilidad de asignar a los individuos a los proyectos. Se espera que sigan tomando decisiones basadas en las necesidades de los proyectos, la ubicación del proyecto, las necesidades de desarrollo y las aspiraciones profesionales de los individuos, y así sucesivamente. En algunas organizaciones, los gerentes funcionales están acostumbrados a ir más allá de la asignación de individuos a los proyectos y han participado en la asignación de tareas a los individuos dentro de sus grupos. Ya no deberían hacerlo después de la transición a Scrum. La selección individual de trabajo es un aspecto fundamental de cómo los miembros de un equipo se auto-organizan y debe delegarse en el equipo.

El papel de liderazgo del gerente funcional

Los gerentes funcionales han sido siempre líderes. Las tendencias generales de liderazgo en los últimos años han afectado el estilo individual. Mientras yo estaba creciendo, por ejemplo, mi padre gerenció las  tiendas Sears. Esto fue en la época en que Sears era el mundo, la mayor cadena minorista. El estilo de gestión de mi padre era muy jerárquico. Él establecía metas, objetivos, targets  y otras medidas, las comunicaba a los empleados, y luego media a cada empleado contra esos objetivos. Esta fue también una época en que la sabiduría predominante determinaba que un buen gerente puede manejar cualquier cosa. Mi padre, supuestamente, debería haber sido capaz de llevar su experiencia en la gestión de una tienda minorista a la gestión de un banco o de una operación de fabricación con la misma habilidad. Mi padre operaba en el cuadrante inferior izquierdo de la figura 8.1, extraida de “The Toyota Way” por Jeffrey Liker.

Los diferentes tipos de gerentes funcionales, determinado por el tipo de experiencia y estilo de gestión. Adaptado de “The Toyota Way”, Jeffrey Liker, copyright The McGraw-Hill Companies, Inc.

Un tipo diferente de gerente, o tal vez uno trabajando en una época diferente a la de mi padre, podría haber aplicado sus conocimientos de gestión general en una forma más emergente (de abajo hacia arriba). Este gerente estaría en la parte superior izquierda de la figura 8.1. En la parte inferior derecha de la figura, vemos a un directivo con un profundo conocimiento del trabajo y un estilo jerárquico (de arriba hacia abajo). Este gerente, que es bastante común en proyectos de software, le dice a su equipo, tanto lo que debe hacer y cómo debe hacerlo.

En una organización que utilice Scrum, los gerentes funcionales deben operar en el cuadrante superior derecho, donde se combinan un profundo conocimiento del trabajo con un estilo bottom-up. Un gerente funcional es responsable de proporcionar orientación y asesoramiento a los miembros del equipo. Los ScrumMasters y los Product Owners también ofrecen orientación y asesoramiento, pero sus opiniones se limitan a un solo proyecto o producto. Un gerente funcional tendrá una perspectiva más amplia, incluyendo la capacidad de establecer los estándares intersectoriales del proyecto y establecer las expectativas de calidad, mantenimiento, reutilización, etc.  o requisitos no funcionales.

Los gerentes funcionales también conservan la responsabilidad del desarrollo de las personas en sus equipos. Asegurar el presupuesto y tiempo para enviar gente a conferencias, desafiarlos con los proyectos adecuados, y animándolos a unirse o formar comunidades de práctica son todos parte del rol del gerente funcional.

Responsabilidades sobre el personal

En la mayoría de las organizaciones, los gerentes funcionales mantendrán la responsabilidad sobre la evaluación y revisión periódica del personal en sus departamentos. Aunque el gerente funcional espero haya siempre incorporado los aportes de los compañeros de trabajo de cada persona y de los clientes en las revisiones; la necesidad de hacerlo es mayor en un entorno de Scrum porque el empleado es probable que trabaje más alejado del gerente funcional en el día a día.

En muchas organizaciones, los gerentes funcionales también conservan la responsabilidad de tomar decisiones de contratación y despido. Ni el ScrumMaster ni el Product Owner tienen este nivel de autoridad sobre los individuos en los equipos de desarrollo de productos.

Después de que la organización adopta Scrum, la mayoría de los gerentes funcionales se encuentran con más tiempo de lo que tenían antes. Este tiempo extra debería ser utilizado para permanecer en estrecho contacto con sus colaboradores directos, para saber más acerca de cada proyecto en el que los empleados están trabajando (asistiendo a varias retrospectivas y así sucesivamente), y prestar más atención a los temas transversales a los proyectos y direcciones futuras.

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?

La respuesta a la primera de estas cuestiones depende totalmente del arquitecto en cuestión. Muchos arquitectos pueden encontrar muy poco cambio acerca de su trabajo. Soluciones recomendadas por estos arquitectos son aplicadas, porque otros desarrolladores le tienen el suficiente respeto y saben que sus consejos probablemente sean buenos. Por ejemplo, si uno de mis compañeros de trabajo tiene una reputación por haber tomado decisiones acertadas de arquitectura en el pasado, y observo que su toma de decisiones de arquitectura sigue siendo buena en este proyecto, estaré dispuesto a ir a él con preguntas arquitectónicas. Lo haría incluso siendo un equipo auto-organizado y aunque nadie me obligue a obtener una segunda opinión sobre mis decisiones.

La segunda preocupación es en gran medida infundada. Las necesidades de arquitectura de un producto se utiliza en conjunción con los objetivos de negocio para impulsar el establecimiento de prioridades del backlog. Esto permite que un arquitecto tenga la capacidad de centrar su atención y esfuerzo en las incertidumbres sobre la arquitectura de la aplicación. En un producto de arquitectura complicada o riesgosa, el arquitecto tendrá que trabajar estrechamente con el Product Owner para educarlo acerca de las implicaciones arquitectónicas de cada ítem del backlog. Todos los Product Owners son conscientes de que tienen que escuchar al mercado, a los usuarios o a los clientes para tener input en las decisiones de producto. Los buenos Product Owenrs también sabemos que recabe la opinión del equipo técnico sobre las prioridades. Aunque la decisión final es del Product Owenr, los buenos, consideran todos los puntos de vista al priorizar el trabajo.

Andrew Johnston de AgileArchitect.org ha escrito: “En un desarrollo ágil el arquitecto tiene la responsabilidad principal al considerar el cambio y la complejidad, mientras la atención de los otros desarrolladores debe ser la próxima entrega”. La secuenciación prudente del trabajo en los sprints puede ayudar a un equipo a ganar conocimientos claves antes, evitando o descubriendo los riesgos con el tiempo suficiente para reaccionar y minimizar el costo total de desarrollo.

El Arquitecto “no-coding”

Los arquitectos “no-coding” es probable que vean el cambio más grande en lo que hacen. Estos son los que Scott Ambler llama “arquitectos torre de marfil.” La mera presencia de un arquitecto “no-coding” es un presagio muy conocido de problemas, los proyectos Scrum están librados de ellos. Algunos arquitectos “no-coding” verán en Scrum una oportunidad para volver a hacer parte de la programación que esperamos hayan disfrutado previamente en sus carreras. Estos arquitectos son contribuyentes bienvenidos en los equipos Scrum. Ellos serán respetados por la profundidad de sus conocimientos y experiencia y su capacidad para aremangarse y meterse en el código.

¡Cuidado con el arquitecto que se resiste a un rol que requiera de contribuciones “manos-a-la-obra” en los proyectos. En muchos casos estos arquitectos “no-coding” tomaron su carrera en esa dirección como una manera de salir de las manos-en la programación. Uno de tales arquitectos, Tom, me confundía cuando lo conocí. Hablaba y sonaba bien informado sobre todas las tecnologías adecuadas. Sin embargo, fue el primer desarrollador que conocí que gozaba de las reuniones. Siempre estaba buscando oportunidades para programar más reuniones. Cuando conocí mejor a Tom, me di cuenta de que su conocimiento técnico era muy superficial, no era tan bueno como yo pensaba. Pronto me di cuenta por qué le gustaba tener al equipo tanto tiempo en las reuniones: en una reunión innecesaria todos los asistentes son igualmente productivos y valiosos. Es cuando los miembros del equipo vuelven a sus escritorios y comienzan a hacer el trabajo real cuando las diferencias a menudo dramáticas, entre los desarrolladores comienzan a aparecer. La preferencia de Tom para las reuniones innecesarias era una técnica de auto-preservación: cuanto más tiempo el equipo pase en reuniones, más tarde se darían cuenta de que Tom no era tan bueno.

Para ser un colaborador valioso, alguien con una tarjeta de negocios que diga “Arquitecto”, no es necesario que codifique tiempo completo. De hecho, es muy posible que pase un sprint o dos sin que un arquitecto escriba código de producción. La distinción que quiero marcar es entre los arquitectos que todavía pueden codificar y aquellos cuyas habilidades de programación quedaron atrás. El Arquitecto Johannes Brodwall dice que “los cambios más grandes en mi rol como arquitecto han sido que, formalmente, el arquitecto ya no tiene el poder de dictar las soluciones técnicas. En cambio, un arquitecto tiene que ser un asesor y un facilitador. Como asesor, aún soy capaz de hacer el trabajo para el cual doy consultoría”.

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. Nadie más está en mejor posición para realizar los cambios necesarios a raíz de las decisiones que se producirán durante el desarrollo de productos, como prioridades, la velocidad del equipo, y las condiciones del mercado. La determinación de prioridades no es una actividad estática, por una sola vez, hecha al comienzo que pueda ser administrada por un gerente del proyecto. Sin embargo, una y otra vez, los proyectos secuenciales exigen que los gerentes de proyectos realicen conjeturas para entregar el producto correcto.

En los proyectos Scrum, reconocemos el papel insostenible del gerente del proyecto y lo eliminamos. La eliminación del rol, sin embargo, no significa que podamos deshacernos del trabajo y las responsabilidades. Como puedes imaginar, ya que los equipos auto-organizados son un principio central de Scrum, una gran parte de la responsabilidad previamente asumidas por el gerente del proyecto es transferido al equipo Scrum. Por ejemplo, sin un gerente de proyecto que asigne tareas a los individuos, los miembros del equipo asumirán la responsabilidad de la selección de las propias tareas. Otras responsabilidades se han movido  al ScrumMaster o Product Owner.

Ex gerentes de proyecto a menudo asumen una de las funciones que han tenido en algún momento de su pasado  -el gerente de proyecto se convierte en Product Owner o ScrumMaster o miembro del equipo, dependiendo de la experiencia, habilidades, conocimientos e intereses.

Algunas personas se convirtieron en gerentes de proyecto porque lo consideran el siguiente paso en una carrera deseable, sin embargo, no disfrutan de la gestión de proyectos. Estas personas se pierden el desafío técnico de trabajar como programador, tester, ingeniero de base de datos, diseñador, analista, arquitecto, etc. Muchas de estas personas se beneficiarán con la eliminación de la función de gerente de proyecto para volver al trabajo que encuentran más satisfactorio.

Otros gerentes de proyectos han utilizado sus funciones para llegar a conocer la empresa y sus clientes. Un gerente de proyecto en esta situación aprovechará ese conocimiento para adoptar un rol de Product Owner. Esto puede ser una coincidencia excelente, especialmente para aquel gerente de proyecto que tiene dificultades para abandonar por completo la capacidad de decir al equipo qué debe hacer. Como parte de su función, los Product Owners están autorizados a decir al equipo acerca de “qué hacer” siempre y cuando eviten decirles “cómo hacerlo”. Esto puede satisfacer a un ex gerente de proyecto cuya naturaleza haga que le cueste parar de dirigir al equipo.

Si un gerente de proyecto puede superar los viejos hábitos de dirigir el equipo y tomar decisiones por ellos, es probable que pueda convertirse en un buen ScrumMaster. Este es el nuevo rol que comúnmente adquieren los gerentes de proyectos en las organizaciones que adoptan Scrum. El nuevo rol probablemente será difícil al principio para el ex gerente de proyecto, mientras aprende a morderse la lengua y dejar que el equipo aprenda a resolver sus propios problemas y tomar sus propias decisiones. A menudo, los nuevos ScrumMasters son colocados en la posición desafiante de entrenar a los equipos en algo que todavía ellos mismos no son buenos, ser ágiles. Las mejores estrategias para un ScrumMaster en esta situación son las siguientes:

• Limitarse lo máximo posible a seguir Scrum según el manual. Inicialmente seguir el consejo de este u otro libro de Scrum de cerca. O contratar a un entrenador y seguir sus consejos al pié de la letra. Sólo empezar a personalizar el proceso después de que haya experiencia real y práctica.
• Hablar con otros ScrumMasters tanto como sea posible. Si hay ScrumMasters en su organización, formar una comunidad y compartir buenas y malas experiencias. Busque aprender de las lecciones aprendidas de situaciones comunes. Si usted es el único ScrumMaster en su organización, encuentre ScrumMasters fuera de la misma con quienes pueda compartir historias y comparar métodos.
• Aprender tanto como pueda lo más rápido posible. Lea libros, artículos, blogs y sitios web. Mira en los grupos de interés locales y asista a sus reuniones. Trate de asistir a una o más conferencias principales de Agile o Scrum.

Doris Ford, una gerente de ingeniería de software en Motorola, es una gerente de proyectos de formación clásica y Project Management Professional (PMP). Sin embargo, a pesar de tener un trasfondo tradicional en la gestión de proyectos, el enfoque de Doris ha sido siempre el de apoyar y dar libertad a sus equipos. Debido a esto, ella fue capaz de pasar más fácilmente de gerente de proyectos a ScrumMaster. Ella escribe sobre cómo su trabajo ha cambiado con Scrum:

Durante los años en la gestión de desarrollo ágil he aprendido a no preocuparme por los detalles de las tareas. Como gerente de proyectos tradicional, siempre necesité estar al tanto de quién estaba haciendo qué, cuáles eran sus dependencias, y si se estaban haciendo a tiempo. Pasé innumerables horas haciendo estas preguntas para obtener las respuestas en un intento por satisfacer el alcance/cronograma/presupuesto/calidad y la presentación de informes sobre los progresos (a veces utilizando el método de valor ganado). En un entorno ágil tuve que aprender a confiar en los miembros del equipo en que iban a identificar y realizar las tareas necesarias para completar el alcance de cada sprint. Fue difícil al principio, pero rápidamente aprendí que el equipo podría hacerlo. Ahora paso la mayor parte de mi tiempo a asistiendo a los miembros del equipo abordando los obstáculos que aparecen y conteniendo el ruido externo para que no desvíe su atención.

¿Por qué cambia el título?

Si es posible que un gerente de proyectos pase a convertirse en ScrumMaster de un equipo o product owner, ¿por qué tenemos que cambiar el título de la persona? Vamos a considerar el término ScrumMaster. Hace años, cuando empecé a realizar proyectos Scrum, el término ScrumMaster no existía, y nunca se me ocurrió llamar al rol de otra forma que gerente del proyecto. Esto funcionó bastante bien. Pero, yo estaba a cargo de la contratación de nuevos individuos para estos roles, yo tenía claras mis expectativas sobre cómo debían interactuar con el equipo. Evité los individuos de estilos dominantes, de “command-and-control”. Además, estos nuevos gerentes de proyectos reportaban a mí, lo que me dió mucha influencia sobre la forma en que interactuaban con sus equipos. Llamarlos  gerentes de proyectos funcionó bien.

A medida que nuestra compañía continuaba teniendo éxito y crecimiento, comenzó a adquirir otras empresas. En esas empresas heredaría gerentes de proyectos que a veces tenía la mentalidad muy tradicional sobre el papel del gerente de proyectos. Me encontré ayudándoles a cambiar esa mentalidad, a una más compatible con el desarrollo ágil. He encontrado esto mucho más difícil que contratar gerentes de proyectos con un enfoque de colaboración adecuado a la auto-organización de los equipos.

Años más tarde, en un debate con Ken Schwaber, me ayudó a comprender por qué la transición de los gerentes de proyecto existentes había sido más difícil de lo previsto. Schwaber me informó que al permitir que los gerentes de proyecto retuvieran sus títulos,  les permitía pensar que los cambios eran menos de lo que realmente eran. Él inventó la palabra ScrumMaster en 1997, en parte para recordarles  a todos que este no era sólo el rol del gerente de proyectos con algunas responsabilidades menos o adicionales. Schwaber me dijo que “el vocabulario de Scrum es un vocabulario de cambio. Las palabras son a menudo deliberadamente feas: Burndown, backLog, ScrumMaster-porque nos recuerdan que el cambio se está produciendo”.

Aunque lo recomiendo, no necesariamente tienen que desterrar el título de gerente de proyectos. Si usted o su organización están enamorados de él, siga utilizándolo. Sin embargo, sean conscientes del consejo de Ken Schwaber y de mi experiencia, el uso de las viejas palabras retardar o previenen la adopción del nuevo enfoque. El mantenimiento de un título anterior no motiva a pensar en la nueva forma. Además, si las personas no están dispuestas a renunciar a algo tan insignificante como un título de trabajo, es probable que tampoco estén dispuestos a realizar los cambios más difíciles y profundos al adoptar 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. Esto es especialmente común en grandes proyectos que hacen uso de una jerarquía de Product Owners. Alguien con el título “Project Manager” en su tarjeta, por ejemplo, actuaría como el Product Owner en jefe para el producto en general, ocupando la mayor parte de su tiempo poniendo atención al usuario y al mercado. Un individuo con el título de “Analista” en su tarjeta personal, por otro lado, se transformaría en un Product Owner que trabajaría para el Product Owner en jefe, traduciendo su visión en product backlog para su equipo.

Varios equipos descubren que tener un analista dentro del equipo sigue siendo muy beneficioso, aunque la forma en la que el analista trabaja cambiará. En proyectos gerenciados de forma tradicional, la misión del analista parece ser la de ir tan adelante del resto del equipo como le sea posible. En Scrum , el análisis en tiempo real es el objetivo. La nueva función del analista es la de estar levemente por delante del equipo pero pudiendo proveer informaci´pon valiosa al equipo sobre los requerimientos actuales y funcionalidades a corto tiempo.

Los analistas pueden ser claves en el logro del objetivo de mover el foco de la escritura de requerimientos a la conversación acerca de los mismos. Porque los analistas no están trabajando tan adelante del equipo como acostumbraban hacerlo, deben acostumbrarse a compartir la información con el equipo de forma más informal en vez de hacerlo por medio de un gran documento. Tanta información como sea posible debería ser compartida en forma verbal, pero el analista aún deberá documentar algunos requerimientos, especialmente trabajando con equipos distribuidos. De todas formas, lo que el analista escriba deberá ser más informal; más parecido a una wiki que a un documento con una página para la firma y aceptación.

En proyectos tradicionales, los analistas frecuentemente se transforman en intermediarios a través de los cuales los miembros del equipo y el Product Owner se comunican. En un proyecto Scrum el analista debe transformarse en un facilitador del equipo-product owner más que en un intermediario. Los miembros del equipo y el product owner deben conversar. En vez de ser conductor de las conversaciones, el buen analista ágil se enfoca en hacer que esas conversaciones son tan productivas como sea posible teniendo en cuenta las restricciones de tiempo que el equipo y el product owner tengan. Esto puede significar que el analista conduce al product owner y al equipo a discutir acerca de cierta historia de usuario en vez de otra, porque es en esta primera en la cual hay más riesgo involucrado. O puede significar que el analista comunica al equipo un overview de una nueva funcionalidad antes de reunirlos con el product owner para discutir los detalles.

En un proyecto tradicional , el analista le diría al equipo, “Hablé con nuestro stakeholder, entendí lo que quiere y escribí este documento describiéndolo en detalle”. En contraste, en un proyecto Scrum, el mismo analista diría, “Hablé con nuestro product owner y tengo una intuición acerca de lo que busca. Escribí estas seis user stories para darles un comienzo, y tengo muchas otras preguntas para hacerle al product owner. pero quisiera asegurarme que un par de ustedes vienen conmigo cuando tengamos esas discusiones”.

Con toda esta charla de analista mirando hacia el futuro, puede ser tentador pensar que los analistas trabajan un sprint delante del equipo. No lo hacen. Gregory Topp, un analista en Farm Credit Services of America, describe cómo la utilización de Scrum le permitió concentrarse en el sprint actual: “Antes de Scrum, debía enfocarme en requerimientos que no iban a ser desarrollados en semanas, sino en meses. Ahora me enfoco en el sprint actual (dos semanas para nosotros), algo de tiempo puede utilizarse para detallar user stories, desarrollarlas y probarlas.” La prioridad de un analista es lograr el objetivo del sprint actual. Un analista dentro de un equipo Scrum va a asistir con el testing, va a responder preguntas (o registrar la respuestas a las preguntas) acerca de funcionalidades en desarrollo, va a participar totalmente en todas las reuniones regulares del sprint, y demás.

De todas maneras, es muy probable que todas estas actividades no terminen de ocupar completamente la capacidad del analista. El tiempo durante el cual no es necesario que el analista esté trabajando en el sprint actual, puede ser utilizado para mirar hacia adelante. Ser parte del equipo en este sprint y pasar parte del tiempo mirando hacia adelante, no significa estar un sprint adelante del equipo. Topp explica cómo el hecho de ir muy adelante puede de hecho dejarlo detrás del equipo: “Traté de trabajar un sprint o dos adelante, definiendo detalles de los user stories. Descubrí que esto hizo peligrar el Sprint actual. También descubrí que muchas veces los detalles de un user story cambian para el momento en el cual el equipo comienza a trabajar en él.”

Una pregunta común es si el tiempo que el analista invierte mirando hacia adelante debe ser incluido en el backlog del sprint actual. Mi recomendación es que debe ser incluido en el backlog cualquier esfuerzo de análisis que sea identificado durante la planificación del sprint. Por ejemplo, supongamos que el equipo está trabajando en una aplicación que aprueba o rechaza solicitudes de créditos. Si el Product Owner y el equipo acuerdan que el próximo sprint incluirá trabajo relativo a obtener el score crediticio de los postulantes, entonces las tareas relativas al análisis de esa funcionalidad deben ser identificadas, estimadas e incluidas en el sprint backlog. Por otro lado, si el trabajo del próximo sprint aun no se conoce, no deben incluirse niguna tarea relativa al análisis de funcionalidades de futuros sprints.

Generalmente, muchos analistas disfrutan el cambio a Scrum siendo que deben renunciar al trabajo de simple intérprete de los deseos del cliente.

Dos años luego de adoptar Scrum, Topp comenta cómo su relación con otras personas del equipo ha cambiado: “Porque todos nosotros estamos en el mismo equipo y porque trabajamos en la misma user story al mismo tiempo, el equipo parece tener más unidad. Antes de utilizar Scrum, parecía que cada función (analista, programador, tester, DBA) se realizada en un silo. Había más búsqueda de culpables. Ahora con Scrum, todo el equipo se enfoca en un conjunto chico de historias. La búsqueda de culpables se eliminó por una ideología “de equipo”.”

Nota: 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”, con tiempo iré traduciendo para los hispano-parlantes el resto de los roles.