archivo

Archivos diarios: diciembre 10, 2012

Como indicaba en el artículo anterior el Product Owner decide sobre la línea de desarrollo del producto, sean aspectos funcionales y no funcionales pero hay aspectos que le trascienden y sobre los cuales no tiene la última palabra.

Supongamos que el sistema es sospechoso de dejar sin recursos a la base de datos de producción y que eso afecta a terceros sistemas de información. Esta situación hará necesario la dedicación de esfuerzo para estudiar el problema y para solucionarlo si efectivamente el producto es el responsable del mismo. Este esfuerzo afectaría al alcance del sprint porque de la fuerza total de trabajo una parte se tiene que dedicar a este asunto.

En este caso hay una situación que trasciende al Product Owner porque el problema va más allá del producto que se está desarrollando por lo que la decisión de hacer o no esa tarea no le corresponde. Si se le explica y esta persona es razonable lo entenderá y la cosa no pasará de ahí, si no es razonable se producirá un conflicto y tendrá que ser un tercero quien lo resuelva.

No entro a valorar si la resolución de la incidencia impacta o no en el presupuesto ya que habría que conocer el momento y la causa que lo originó sino en su impacto en la línea de desarrollo del producto (provocará que determinadas funcionalidades o modificación de las existentes tengan que esperar).

Otra posible situación (de las muchas que puede haber) donde nos podamos encontrar con esto es el posible deseo del Product Owner de incrementar la velocidad de desarrollo restando peso al proceso (por ejemplo eliminando determinada documentación). Estamos ante otra circunstancia en la que la decisión le trasciende dado que se trata de políticas de otro Departamento y/o de otras personas de un orden jerárquico superior. ¿Que quiere reducir carga de proceso? Tendrá que acudir a los cauces oportunos para hacerlo pero no es decisión suya imponerlo al equipo de desarrollo y éste no debe aceptarlo porque por cerrar un conflicto creará otro posiblemente mucho mayor.

Entiendes que sería conveniente dedicar esfuerzo adicional a refactorizar código (más allá del que puedas invertir si en tu proceso de desarrollo ya está contemplado un tiempo a esta tarea), para realizar cambios en algunos de los entornos (desarrollo, integración, preproducción o producción) o para dar una solución a los problemas de disponibilidad que tiene la aplicación (hay un largo etcétera de tareas que el equipo de desarrollo puede realizar más allá de la construcción de nuevas funcionalidades o modificación de las existentes) y lo más probable es que no estés equivocado y esas tareas produzcan un beneficio real al producto o al proceso de desarrollo (y en consecuencia también al producto).

Recuerda que el sistema de información no es para ti y que la inversión la ha realizado otro (o es responsabilidad de otro su gestión) por lo que por mucho que veas absolutamente necesario realizar esas tareas no es tu decisión ejecutarlas. Tu obligación es incluirlas en la pila de producto, exponer al Product Owner las ventajas e inconvenientes que tiene su realización (hay que tener en cuenta que no tiene por qué tener conocimientos técnicos y/o de la situación que les permita conocer la trascendencia del problema) y él decida su importancia y su inclusión o no en el próximo sprint o en sprints venideros.