Peer Reviews

Estaba degustando un aperitivo post-cena mientras hacía un poco de zapping entre las pestañas de mi explorador. Fue entonces cuando me topé con un mail de un ex-compañero de trabajo consultando sobre el tema de referencia. Puntualmente la consulta fue:  ¿cuáles serían los 4 puntos más importantes a tener en cuenta para hacer un peer review? Luego de pensarlo brevemente, comencé a redactar mi respuesta cuando caí en la cuenta que era un tema interesante para compartir y entonces decidí publicarlo aquí.

Haciendo un poco de memoria, creo que mi primer acercamiento a este tema fue con Code Complete, el clásico de Steve McConnell. Pero no estoy seguro, tal haya sido cuando cursé la materia Calidad con Alejando Oliveros en Fiuba.

Comencemos por el principio. El términos generales podemos decir que el peer review es una técnica de revisión del trabajo producido por una persona, realizada por sus pares. El fin de este tipo de actividad suele variar levelmente dependiendo del campo de aplicación, pero usualmente tiene que ver con el aseguramiento del cumplimiento de normas/estándares, la detección de oportunidades de mejora y la validación (esto último es muy común en el campo académico, previo de la publicación de trabajos de investigación).

Bajando a concreto y hablando especificamente del ámbito de desarrollo del software, un peer review es una revisión de un artecfacto (código, especifición, etc) realizada por su autor y un conjunto de pares con el fin de evaluar su contenido técnico y/0 calidad.  La técnicas existentes para realizar este tipo de revisiones varian considerablemente en su nivel de formalidad. En un extremo podriamos encontrar el collective ownership de los métodos ágiles y en otro las inspecciones formales propuestas por el IEEE. En medio hay unas cuantas alternativas. ¿cual de todas es la más apropiada? Dependerá del fin concreto de la revisión y de la cultura de la organización donde pretenda implementarse.

Volviendo a la pregunta de mi colega que motivo estas lineas, asumo en primer lugar que su inquietud apunta a implementar la práctica de peer review en una organización y no a simplemente realizar UN peer review. Al mismo tiempo asumo que estamos habland de review en el sentido de revisión de artefactos y no de evaluar el desempeño general de una persona. Dicho esto, los principales puntos a considerar son a mi enteder:

  1. El objetivo del peer review
  2. La cultura organizacional
  3. La conformación del equipo
  4. El proceso

Si bien los items estan enumerados, dichos números no representan necesariamente su orden de importancia. Más allá de eso, tanto (1) como (2) son fundamentales para determinar la técnica concreta a utilizar y ello sin duda tiene impacto en (3) y (4).

En cuanto a (1), si el objetivo es la implementación de alguna práctica de mejora certificada como la propuestas por modelos como CMMi, entonces tal vez las inspecciones formales propuestas por Michael Fagan resulten muy convenientes.

En lo referente a (2), hay que tener mucho cuidado puessi en la orgnaización hay gente de gran antiguedad que puede sentirse amenaza por este tipo de prácticas. En casos así, la implementación puede llegar a resultar verdaderamente muy dificil y de no hacerlo con la debida precaución podría llegar a resultar contraproducente.

Respecto a (3) creo que el equipo debiera estar conformado por gente con cierto reconocimiento de sus pares, gente que ha demostrado sus habilidades técnicas y que es reconocida por sus pares independiente del título que ostenta dentro de la organización.

Finalmente respecto a (4)  resulta importante mirar el proceso completo, pues solo hacer revisiones y registrar los resultados, no va a llevar por si solo a la mejora. Es necesario definir que hacer a partir de los hallazgos de la revisión.

Algunas recomendación claves a la hora realizar revisiones:

  • El foco es la detección, no la corrección
  • El management no participa de la revisiones (a excepción de lo que se esté revisando sea algún artefacto de gestión como un plan)
  • Lo que está bajo revisión es el artefacto, no la persona que lo produjo
  • Entrenar a los revisores
  • Preparar checklist para realizar las revisiones

Para los interesados en profundizar puedo recomendar algunos materiales que acabo de chequear en mi biblioteca:

Otro titulo importante en esta temática (pero al que no he tenido accesso) es Peer Reviews in Software, de Karl Wiegers.

Por último, les dejo algunos link interesantes sobre el tema:

Espero este ayude a resolver las dudas de mi colega.

¡Nos leemos!

Anuncios

2 comentarios en “Peer Reviews

  1. Hola Nico,
    Hay una frase que se presta a confusión: “revisión del desempeño de una persona”
    Como aclarás más adelante, lo que se revisa es el producto, no la persona.
    Lindo post, mucho para leer 😀

    1. Gracias Juan por la obsevación, ahí la redacción para que dejar bien en claro que lo el item bajo observación es el producto del trabajo de la persona.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s