Aunque rápidamente se viene a la cabeza ese pequeño, cabezón y simpático fantasmilla, nos queremos referir al Conjunto de Artefactos Solo Para Esta Release.
Existe la idea equivocada de estar obligados mantener continuamente toda la documentación que se genera a lo largo de un proyecto. Pero sin embargo, hay cantidad de artefactos de usar y tirar. Es decir, información que sólo tiene sentido durante un ciclo de desarrollo (idealmente lo más corto posible); pero que no es necesario mantener por más tiempo.
Algunos ejemplos son: conjunto de peticiones u ocurrencias del cliente asumidas para la siguiente release, lista de pruebas específicas para dicha versión, notas sobre cambios realizados en los diseños o el código durante este ciclo de desarrollo, diagramas o indicaciones al programador sobre cómo implementar las nuevas funciones, etc.
Debemos asumir que esta documentación no requiere excesivo formalismo y, en general será bastante simplona, ya que en general se trata de indicaciones sobre cómo modificar el producto.
Evidentemente, tendremos artefactos que definen el producto en sí, y que sufren cambios continuos durante el ciclo de vida de dicho producto. Para entendernos, hablamos de la especificación funcional, de la arquitectura, diseño de clases o bbdd, código, hardware, equipo de trabajo,... es decir, el MODELO, con mayúsculas, o todo lo que se va manteniendo desde el principio hasta el final.
Diferenciar claramente entre ambos conceptos (CASPER y MODELO) aclara enormente las cosas a la hora de gestionar documentación, cambios, requisitos o el proyecto en general.
martes, 28 de noviembre de 2006
Gestión de culpas
Hay gente que considera que el desarrollo ha de responder a necesidades de las organizaciones. Esto puede no ser necesariamente verdadero, pero desde luego es irrelevante. El software se desarrolla en general porque a alguien se le ocurre.
Efectivamente, cuando a alguien se le ocurre la idea de que se desarrolle o modifique una aplicación, puede decidir no decírselo a nadie, lo cual suele ser la mejor idea. En ocasiones se le ocurre comentárselo a alguien, con lo que la idea comienza a propagarse hasta que algunas personas empiezan a emplear su tiempo (o dinero, prestigio, etc.) en hacerla realidad o utilizar el producto resultante.
El proceso es sencillo y se realiza naturalmente. Así funcionan muchas aplicaciones en la realidad. Alguien las desarrolla en su tiempo libre y se las enseña a otros, les gustan y empiezan a utilizarlas. El problema empieza cuando la gente empieza a quejarse y no está claro que tú no tienes la culpa. O cuando la gente esta contenta y no está claro que sea gracias a tí, que es el problema resultante de no prometer (comprometerse) a cosas si no creemos que las vamos a cumplir.
Para no tener la culpa lo mejor es no tener nada que ver con el desarrollo en cuestión. Otra opción es demostrar que la culpa la tiene otro. Por definición el culpable es aquel que se comprometió a algo y no cumplió, pero no tiene ninguna otra persona a la que culpar. Por supuesto, todos estamos comprometidos a todo aquello que no hayamos rechazado explícitamente (es decir, se es culpable a no ser que se demuestre lo contrario). Es algo así como un flujo descendente de la culpa.
También se puede tratar de demostrar que no hay culpables, principalmente porque el problema cuestión es irresoluble. Esto es peligroso porque te convierte automáticamente en el principal sospechoso y sobre todo porque se puede se puede producir un rebote hacia arriba del flujo de la culpa hacia los gestores por la falta de planificación. Una variación consiste en culpar a alguien que ya no forma parte del árbol de responsabilidades (un sumidero de culpas).
Resumiendo, el objetivo de la gestión de culpas -más conocida como gestión de riesgos (los riesgos de cargar con la culpa)- consiste en ser capaz de demostrar que has hecho todo aquello que no has rechazado explícitamente, y que lo has hecho bien.
Conceptos relacionados:
- Gestión inversa de requisitos. El objetivo de los requisitos es demostrar que no nos hemos comprometido a satisfacer ciertos requisitos.
- Test-driven development. El objetivo es demostrar que se han satisfecho el resto de los requisitos.
- Métricas de calidad. El objetivo de las métricas es medir y demostrar lo bien que has hecho el trabajo.
Efectivamente, cuando a alguien se le ocurre la idea de que se desarrolle o modifique una aplicación, puede decidir no decírselo a nadie, lo cual suele ser la mejor idea. En ocasiones se le ocurre comentárselo a alguien, con lo que la idea comienza a propagarse hasta que algunas personas empiezan a emplear su tiempo (o dinero, prestigio, etc.) en hacerla realidad o utilizar el producto resultante.
El proceso es sencillo y se realiza naturalmente. Así funcionan muchas aplicaciones en la realidad. Alguien las desarrolla en su tiempo libre y se las enseña a otros, les gustan y empiezan a utilizarlas. El problema empieza cuando la gente empieza a quejarse y no está claro que tú no tienes la culpa. O cuando la gente esta contenta y no está claro que sea gracias a tí, que es el problema resultante de no prometer (comprometerse) a cosas si no creemos que las vamos a cumplir.
Para no tener la culpa lo mejor es no tener nada que ver con el desarrollo en cuestión. Otra opción es demostrar que la culpa la tiene otro. Por definición el culpable es aquel que se comprometió a algo y no cumplió, pero no tiene ninguna otra persona a la que culpar. Por supuesto, todos estamos comprometidos a todo aquello que no hayamos rechazado explícitamente (es decir, se es culpable a no ser que se demuestre lo contrario). Es algo así como un flujo descendente de la culpa.
También se puede tratar de demostrar que no hay culpables, principalmente porque el problema cuestión es irresoluble. Esto es peligroso porque te convierte automáticamente en el principal sospechoso y sobre todo porque se puede se puede producir un rebote hacia arriba del flujo de la culpa hacia los gestores por la falta de planificación. Una variación consiste en culpar a alguien que ya no forma parte del árbol de responsabilidades (un sumidero de culpas).
Resumiendo, el objetivo de la gestión de culpas -más conocida como gestión de riesgos (los riesgos de cargar con la culpa)- consiste en ser capaz de demostrar que has hecho todo aquello que no has rechazado explícitamente, y que lo has hecho bien.
Conceptos relacionados:
- Gestión inversa de requisitos. El objetivo de los requisitos es demostrar que no nos hemos comprometido a satisfacer ciertos requisitos.
- Test-driven development. El objetivo es demostrar que se han satisfecho el resto de los requisitos.
- Métricas de calidad. El objetivo de las métricas es medir y demostrar lo bien que has hecho el trabajo.
Suscribirse a:
Comentarios (Atom)