Últimos artículos publicados

31/07/10
Xavier Albaladejo

(Este artículo parte de los comentarios realizados en un hilo del foro de Agile Spain)




El equipo es el responsable de proporcionar un producto de calidad, no se puede escudar en etapas posteriores de verificación de calidad o en las pruebas de aceptación del cliente (Product Owner) para no garantizar la calidad del producto que ha construido.

Profundizando en base a la terminología de la ISO9126 de calidad de producto en ingeniería del software:

  • La calidad en uso (satisfacción del usuario, efectividad, productividad, seguridad) es un aspecto a verificar por el Product Owner que, además de ser representante de los usuarios finales, también debe asegurar que el producto cumpla con las necesidades del negocio y estratégicas de los stakeholders del proyecto.
  • La calidad externa (funcionalidad, usabilidad, eficiencia, mantenibilidad, fiabilidad, portabilidad) en algunos aspectos es más difícil de verificar  por el Product Owner.
  • La calidad interna no suele poder ser verificable directamente por el Product Owner.

Como comenta Xavier Quesada en el mencionado hilo, “[allí donde la calidad externa e interna no es observable] el equipo tiene una obligación básica de desarrollar un producto, un software, de calidad, o sea el Product Owner no debe convertirse en el Tester/QA del equipo”.

Si es necesario, el Product Owner se puede servir de diversos mecanismos de apoyo para verificar la calidad externa e interna del producto como, por ejemplo, una auditoría experta. En el caso de desarrollo de software, se trataría de una auditoría del código fuente, patrones arquitectónicos utilizados, trazabilidad entre requisitos (o historias de usuario) respecto a los casos de prueba de aceptación (condiciones de satisfacción) y otros modelos o entregables, etc.

12/05/10
Xavier Albaladejo

 

Ya es posible inscribirse en la Conferencia Agile-Spain 2010, que tendrá lugar en Madrid el 10 y 11 de Junio.

04/03/10
Xavier Albaladejo

En este encuentro se utilizó un diagrama de prácticas ágiles para priorizarlas considerando su aplicación en el desarrollo de producto en su punto inicial (por ejemplo, en una startup).

La priorización de las prácticas difiere del caso tratado en el encuentro anterior, en que se evaluaron el uso de estas prácticas en el caso de un proyecto “corto”, de 3 meses, y sin evolución posterior. Los factores que más condicionan esta diferencia de priorización son la duración del proyecto y, por consiguiente, el grado de responsabilidad del equipo sobre su calidad técnica (la facilidad de mantenimiento/crecimiento del producto a posteriori).

Hacer clic en la imagen para ampliarla

priorizacion-practicas-agiles-producto

 

A continuación se muestran las principales diferencias en la priorización de prácticas:

25/02/10
Xavier Albaladejo

Se acaba de anunciar la  Conferencia Agile-Spain 2010 (CAS2010), bajo el lema "Haciendo realidad la agilidad". CAS2010 es la primera conferencia sobre metodos ágiles en España.

Es una cita donde se encontrarán empresarios, desarrolladores, gerentes, investigadores, etc. Está enfocada principalmente a la industria de tecnologías de la información y consultoría tecnológica.

conferencia-agile-spain-2010 CAS2010 es una oportunidad para intercambiar experiencias y hacer contactos con otros profesionales del sector, además de examinar las últimas tendencias en el desarrollo del software ágil de mano de las figuras más representativas del panorama nacional.

A continuación aparecen los datos más relevantes:

  • Fechas: 10-11 de Junio de 2010.
  • Lugar: Madrid, Campus de la E.U. Informática de la U.P.M., Madrid, España.
  • Keynote: Henrik Kniberg. Es el autor de “Scrum y XP desde las trincheras” y “Kanban vs. Scrum – Obteniendo lo mejor de ambos”, además de ser Certified Scrum Trainer y miembro de la junta directiva de la Agile Alliance.
  • Constará de Sesiones, Talleres y presentación de Artículos.
  • Tendrá lugar un panel de expertos (mesa redonda).
17/01/10
Xavier Albaladejo

 

En estos encuentros ágiles se elaboró un diagrama de prácticas y se hizo una priorización considerando un proyecto sin evolución posterior y de corta duración.
 
La priorización de las prácticas ágiles a aplicar en un proyecto puede depender de diferentes factores:
  • El tipo de proyecto, respecto a si no va a tener evolución posterior, o bien si se trata del desarrollo de un producto.
  • Su tamaño (esfuerzo necesario a realizar), su complejidad, el número de personas implicadas.
  • El conocimiento de la tecnología y del dominio (tipo de negocio) por parte del equipo.
  • El conocimiento del proceso de trabajo.
  • El conocimiento entre los miembros del equipo, si han trabajado anteriormente juntos.
  • El tipo de aspecto a mejorar dentro del proyecto (calidad, tiempos de entrega, productividad, etc.).
 
Hacer clic en la imagen para ampliarla
 
 priorizacion-practicas-agiles-proyecto-corto