Resumen: En el negocio del software, la actitud y la personalidad de los miembros del equipo, puede ser el factor determinante del éxito o fracaso de un proyecto. Sigue leyendo
Archivo de la etiqueta: desarrollo de software
La competitividad en el software tiene poco que ver con ajustar estimaciones o tarifas
Resumen: Una situación habitual en nuestro sector, es la que se presenta cuando los gerentes de cuentas nos piden que ajustemos estimaciones o tarifas de cara a tratar de ser más competitivos en los procesos de capacitación de proyectos y en definitiva ganar oportunidades. Sigue leyendo
Qué es experiencia de usuario y quienes tienen que velar porque esta sea buena
Hace ya algunos días que no pasaba por aquí, no obstante, esta semana por fin he sacado un poquito de tiempo para escribir un post que me ronda por la cabeza desde hace mucho tiempo. El post lo he publicado en el blog de Kabel Sistemas de Información y habla sobre que es la experiencia de usuario, que no es y sobre todo quienes son las personas que han de velar porque esta, sea siempre buena.
El susodicho post podéis leerlo a continuación:
¿Que es la Experiencia de Usuario?
De un tiempo a esta parte, por todos lados se esta hablando de experiencia de usuario (ux), no obstante, continuamente nos encontramos con situaciones que ponen de manifiesto que en el sector todavía no está muy claro que es eso de la experiencia de usuario y quienes son los responsables de conseguir una buena experiencia de usuario.
Wikipedia, define la experiencia de usuario como:
Conjunto de factores y elementos relativos a la interacción del usuario, con un entorno o dispositivo concretos, cuyo resultado es la generación de una percepción positiva o negativa de dicho servicio, producto o dispositivo.
Normalmente cuando en el ámbito del desarrollo de software se habla de experiencia de usuario, nos encontramos con que de lo que se habla realmente es de usabilidad y diseño gráfico y según la definición anteriormente citada, podemos deducir que la experiencia de usuario desde luego tiene que ver con aspectos como usabilidad y diseño gráfico, pero realmente con lo que tiene que ver es con la percepción.
Por lo tanto:
Experiencia de usuario, no es usabilidad.
Experiencia de usuario no es diseño gráfico.Experiencia de usuario es más que todo esto, experiencia de usuario es percepción.
La percepción es el acto de recibir, interpretar y comprender a través de la psiquis las señales sensoriales que provienen de los cinco sentidos orgánicos.
La percepción obedece a los estímulos cerebrales logrados a través de los 5 sentidos, vista, olfato, tacto, auditivo, gusto, los cuales dan una realidad física del medio ambiente.
Por lo tanto, podemos afirmar que la experiencia de usuario cuando interactuamos con un producto concreto, sera buena o mala en base a los estímulos recibidos y la manifestación del producto en una realidad física. En desarrollo de software, los estímulos que vamos a recibir, van a ser los relativos a eficiencia, sencillez, visibilidad y calidad de la información, navegabilidad, encontrabilidad, consistencia, estándares, performance o gestión de los errores por citar algunos.
No obstante, de todos estos factores enumerados, encontramos que varios de ellos, si que están totalmente relacionados con el desarrollo de interfaces de usuario, pero también encontramos otros, que tienen más que ver con negocio y arquitectura del producto.
¿Quienes son los responsables de trabajar la experiencia de usuario?
Por lo general, se identifican a los arquitectos de información, diseñadores de interacción o diseñadores gráficos como los responsables de definir, trabajar y conseguir una experiencia de usuario buena, pero esto es un error.
El responsable de conseguir una buena experiencia de usuario es el equipo.
El equipo de desarrollo es el responsable de la experiencia de usuario, ya que es muy difícil encontrar una única figura que pueda ejecutar las acciones necesarias para garantizar que la experiencia de usuario es buena, principalmente porque para conseguir una buena experiencia de usuario, tenemos que trabajar aspectos de disciplinas muy diferentes.
Por un lado, tenemos que tener un responsable de producto (Product Owner) que además de velar por los aspectos relativos al negocio, sea consciente de que una buena experiencia de usuario es directamente proporcional a la calidad del producto y en muchos casos, también al éxito del mismo.
Por otro lado, el líder tecnológico del proyecto, además de velar por el diseño, arquitectura y calidad del software, también tiene que velar por la experiencia de usuario que en su ámbito de actuación, se traduce en performance.
Las aplicaciones han de ser rápidas y ágiles, y este objetivo, lo perseguirán tanto el arquitecto como los desarrolladores.
Y por supuesto, arquitectos de información, diseñadores de interacción y diseñadores gráficos, concibiendo una interfaz de usuario usable, accesible y amigable, con buena navegabilidad, con una acceso a la información sencillo, haciendo uso del diseño gráfico como medio no como un fin en si mismo.
No hay ningún producto de calidad y éxito en el mercado que tenga una mala experiencia de usuario o dicho de otra forma, la totalidad de los productos que hay en el mercado que han tenido éxito, tienen una experiencia de usuario excelente.
Pensad en los iPods de hace 6 años.
¿Y vosotros qué opináis?
El diagrama de burndown en la práctica: El burndown del proyecto NBICI
El viernes de la semana pasa, publique una entrada en el blog de NBICI en la que hablaba del diagrama de burndown. El proyecto NBICI, se esta desarrollando de forma ágil y podría casi casi decir que en modo garage. Muchas veces los profesionales del sector ajenos al agile, tienen la opinión que desarrollar en modo ágil por medio de scrum (o lean o kanban), implica no gestionar lo cual está totalmente alejado de la realidad.
El diagrama de burndown tiene como cometido representar de forma gráfica la evolución del desempeño del equipo en un proyecto concreto y compara este desempeño con el trabajo ideal a realizar.
A continuación podeís leer la entrada y ver el diagrama de la primera semana del sprint:
El diagrama de burndown, es una representación gráfica del trabajo por hacer (y por supuesto también del trabajo hecho) en el tiempo. Este diagrama normalmente se utiliza para predecir cúando se completara un trabajo concreto en base a una temporalidad concreta.
Por medio de este diagrama, representamos el trabajo actual en comparación con el trabajo ideal, y nos permite de un solo vistazo, detectar si vamos adelantados o retrasados respecto al trabajo planificado a realizar durante el Sprint. El diagrama de burndown, es muy utilizado en las metodologías de desarrollo ágil de software (agile), y sobre todo en Scrum.
El burndown, de esta semana, podéis verlo a continuación:
Como se puede observar, en esta primera semana, hemos acumulado un retraso importante aunque seguro que podemos subsanarlo
TDD, Unit Testing y Code Coverage
Todo desarrollo de software que se precie debería realizarse según las directrices del TDD (Test Driven Development) o Desarrollo Orientado a Pruebas, ya que nos va a permitir crear un código más mantenible y escalable.
Esto no es algo nuevo, al contrario, y la verdad es que está bastante trillado, pero siempre es bueno recordarlo ya que lo considero una de las mejores prácticas para el desarrollo de software.
Las pruebas unitarias son, más que útiles, fundamentales ya que nos permiten trabajar de una forma desacoplada y nos ayudan a estructurar y encapsular nuestro código. Pero una vez que las tenemos en verde, ¿Cómo podemos saber qué es lo que se está probando y si están bien hechas?
Aquí es donde entra el Code Coverage.
El code coverage como medida de calidad de nuestras pruebas unitarias, por lo tanto de nuestro software.
El Code Coverage, es una medida que nos va a permitir conocer el porcentaje de ejecución de nuestro código, tras haber ejecutado una batería de pruebas.
De esta medida, podemos sacar varias conclusiones:
- Podemos necesitar más pruebas unitarias.
- Hay código que hemos creado, que nunca se va a ejecutar, por lo tanto no es necesario y sobra.
El Code Coverage, no es necesario que este al 100%, ya que para conseguir esto, quizás tengamos que realizar pruebas unitarias que realmente no sean tales o no sean muy útiles (por ejemplo que estemos probando el Framework en lugar nuestro código), pero sí que es verdad que cuanto más cercano sea al 100% mejor.
La buena práctica, es trabajar con pruebas unitarias, y usar el code coverage como métrica de la calidad de nuestro software y eficacia de nuestro equipo, ya que lo interesante es ver como el code coverage va creciendo (o por lo menos va manteniéndose) iteración tras iteración en el ciclo de vida del desarrollo el software.
Y para finalizar, deciros, que hay varias herramientas por ahí, aunque yo la verdad, solo he usado la que viene con Visual Studio 2008.
Para activar el Code Coverage, únicamente tenéis que ir a:
Test -> Edit Test Run Configuration -> Local Test Run
Y en el dialogo que aparece, vamos a la pestaña de Code Coverage y elegimos los proyectos a los que se lo queremos aplicar.
Aqui teneis una captura del Code Coverage de uno de los proyectos que hemos acabado recientemente, aunque no se vea el porcentaje total (por no desvelar el proyecto que es), ha sido un 91%.
Code Coverage en el ultimo proyecto en el que he estado
Nada más por hoy mis druguitos. Os dejo que tengo que estudiar, pero no os quedais solos, aqui teneis a The Pains of Being Pure At Heart que son geniales y me ponen mogollon.
A deshoras 