Al llegar a la Universidad del CEMA me recibió Anabela Amoresano, quien estaba a cargo de la coordinación del evento. Pocos minutos más tardes llegaron varios otros voluntarios del Capítulo Buenos Aires del PMI.

Mientras esperabamos el arranque, tuve un debate e intercambio muy interesante sobre el universo de aplicación de las metodologías ágiles con Abel Bernal. Seguramente trate el tema en un futuro post, porque vale la pena.

A las 18:30 José Esterkin, Presidente del capítulo Buenos Aires, inició el encuentro comentando acerca de las novedades del capítulo, posibilidades de voluntariado y PMI Tour Buenos Aires. Inmediatamente después, Cecilia Boggi realizó la introducción de la charla y allí fuimos… Abajo dejo la presentación que utilicé durante la misma:

Un agradecimiento a Cecilia y José por el espacio para desarrollar este tema en particular.

Saludos!

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

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

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

Más Información… / Inscripción…

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