"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?

This article is a Spanish direct translation of the "Architects" section from the InfoQ Article named "Book Excerpt: Succeeding with Agile: Software Development Using Scrum", which is about Mike Cohn's book "Succeeding with Agile: Software Development Using Scrum".

You can access the Spanish version of this article following this link.

Since the original article is written in English, I see no need to translate it. Please visit the original article here: http://www.infoq.com/articles/cohn-chapter8
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".


Dime lo que piensas. Por favor, deja un comentario más adelante (y luego dale click a ese botón de 'Me gusta'!)

Seguir leyendo


Comentarios

comments powered by Disqus