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
Comentarios sobre las prácticas
A continuación se enumeran algunos de los comentarios que se hicieron en el encuentro:
- Visión compartida. Es muy importante que el equipo tengo una visión compartida de los objetivos (mediante el Product Backlog) y de las tareas a realizar (mediante el Sprint Backlog).
- Propiedad colectiva del código. Hay que erradicar la costumbre de que “esta tarea la tendrá que hacer esta persona por que fue él quien hizo esta parte del producto”. Cuanto más se tarde en erradicar, peor será. Para dar soporte a esto, existen prácticas que definen los estándares de trabajo del equipo (estándares de codificación, patrones de diseño) y prácticas de transferencia de información y conocimiento (peer reviews, pair programming, etc.).
- La inversión en Unit Testing se recupera pronto, a partir de los 2 meses.
- Aunque el cliente tenga poca disponibilidad para asistir a demostraciones (por ejemplo sólo puede hacerlo 1 vez al mes al mes), es importante hacer demostraciones internas (por ejemplo cada 15 días) para cerrar objetivos y tener estabilizado el producto.
- El Scrum Master debe detectar quienes trabajan de manera más solitaria y no son suficientemente transparentes con el trabajo que están realizando. En esta línea, se pueden fomentar las peer reviews.
- Es más barato y produce un mejor resultado hacer pruebas unitarias automatizadas que funcionales.
- En el tipo de proyecto que se trató en el encuentro (sin evolución posterior y de corta duración, no desarrollo de producto), puede no ser necesario hacer diseño funcional ni diseño técnico. Puede ser suficiente la propia documentación del código y la que proporcionan automáticamente las herramientas de desarrollo (esquema de base de datos, etc.).
- Se comentó que la calidad interna debería ser siempre alta (aunque se tratase de un proyecto sin evolución posterior y de corta duración), ya que esto facilita desarrollar incrementalmente, encima de código ya escrito, y el equipo también tiene que estar a gusto con lo que se está haciendo.
- Hubo una propuesta de no utilizar una gestión de defectos (bugs) formal. Para que no fuese necesaria, se planteó el resolverlos lo antes posible y/o gestionarlos directamente en el sprint backlog.
Artículos relacionados
Para saber más
- Agile Adoption Patters – Amr Elssamadisy
- Patterns of agile development adoption – The technical cluster – Amr Elssamadisy
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles:http://agile-spain.wikidot.com/quedadas-barcelona
Nota del system administrator de ProyectosAgiles.org:
Si estás viendo este artículo mediante el RSS de ProyectosAgiles.org, asegúrate de estar accediendo a través de la siguiente URL: /wordpress/rss.xml
Se ha detectado que (por razones históricas) también se está accediendo desde: http: //www.proyectosagiles.org/taxonomy/term/11/0/feed, que sólo muestra un conjunto muy reducido de artículos.
Proyectos Ágiles 