Inclusive Technologies es un sitio que a sido creado con el objeto de ayudar al desarrollo, evaluación o compra de productos usables y accesibles. Tal como ellos los indican, “productos que trabajan mejor por que son fáciles de utilizar”.
He decidido tomar la definición o conceptos de éste sitio, en relación a como diferenciar Funciones de Características de un producto, ya que en solemos utilizar ambos términos en el idioma ingles (Functions and Features) sin distinciones.
It is important to remember the distinction between product functions and product features. Functions are the “product’s answer to the set of user tasks”; features are the “user tools” inherent in the product used to perform the functions (Wood, 1995).
Placing a telephone call is a function; the dial tone and the touch-tone keypad are features used to accomplish the function. Product Types have different sets of functions, and each Model within a Type accomplishes its functions through potentially different features.
Pero en el desarrollo de software es algo muy relevante hacer buenas distinciones, tanto así que cada ciclo se apoya en el anterior y sin bases bien establecidas, estaríamos nada más y nada menos que desarrollando un gran error, y lo demostraremos al final de la iteración o al final en los releases.
Dicho en otras palabras, sabemos que en Agile, pero en cualquier otro método de desarrollo de software o de negocios, la comunicación es el hilo conductor hacia el éxito o hacia el fracaso.
Entonces… Por que la importancia de distinguir entre Functionality y Features en el desarrollo de software?
- por que solemos confundir User Stories con Tasks para desarrollo, cuando en realidad las User Stories deberían representar pedidos del cliente (the “product’s answer to the set of user tasks) y las Task serían las acciones concretas a realizar para crear Features que irán de cumplimentando Functions.
- Por que las User Stories al ser Functionalities, se expresan en el lenguaje del negocio en cuestión y tendientes hacia un lenguaje de alto nivel, muy comprensible por cualquier ser humano. Típicamente no incluyen expresiones asociadas a la tecnología, como restricciones de lenguajes y tipos de bases de datos o formatos de los campos, lo cual es expresado cuando desarrollamos Features.
- Por que las User Stories ayudan a determinar alcances y límites del negocio, sin exclusiones ni inclusiones, por ende dependencias y con ello desarrollamos criterios de aceptación para validar, no para verificar.
- Por que al confundir User Stories con Tasks, los criterios de aceptación no se manifiestan en un lenguaje de usuario final o perteneciente al dominio del negocio, sino a un cliente del dominio tecnológico, por lo tanto la tendencia es a la verificación en lugar de a la validación.
- Debido a esto terminamos haciendo demostraciones técnicas de como impacta la entrada de un dato en la base de datos, o como funciona el sistema de mensajería, o como un dato es transformado, en lugar de hacer demostraciones para que el cliente valide nuestras aplicaciones desde un punto de vista de valor funcional para su de negocios.
- Por que ésta confusión nos hace olvidarnos del “para que” (Funciones) y concentrarnos en el “como” (Características) y todo luego tiende a la verificación tardía (Quality Control), en lugar de tender a la anticipación de lo que desarrollaremos (Quality Assurance)
De ahora en más me gustaría que pienses como están desarrolladas (expresadas) tus matrices de trazabilidad, tus casos de pruebas funcionales, tus escenarios de pruebas genéricas, tus pruebas de sistemas, tus pruebas de integración y unitarias, tus requerimientos y tus historias de usuario.
Piensa como está tu backlog, tanto de producto como del sprint. Piensa ahora en los releases y finalmente piensa en que cosas de valor le estás demostrando a tu cliente.
No será que te pases las iteraciones demostrando la infraestructura en lugar de la utilidad que le hace ganar dinero a tu cliente.
