"Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum."

Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro "Succeeding with Agile: Software Development Using Scrum" de Mike Cohn. Hoy publico solo la sección de "Analistas" como parte de la serie "Roles ágiles".

Analistas

Con un conocimiento íntimo del producto y fuertes habilidades de comunicación, algunos analistas van a tender a transformarse en Product Owners. This article is a Spanish direct translation of the "Analist" 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-chapter8Esto 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.


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