INTEGRATION OF THE STUDY

El contenido del patrón se definió considerando las adecuaciones aplicadas a la técnica, sugerencias, descubrimientos y lecciones aprendidas que se reportan en los diversos estudios analizados en la revisión de literatura realizada. Para plasmar la estructura e información de este patrón de nuevo utilizamos el formato del patrón de producto propuesto como parte del modelo arquitectónico propuesto en (Sanchez-Segura et al., 2010) y que utilizamos para el patrón “Agile persona” descrito en el capítulo anterior.

La estructura y contenido del patrón “Agile usability” que se presenta en esta sección es resultado del proceso de evaluación aplicado a los patrones que se detalla en el capítulo 6 de este trabajo. Una vez aplicadas las mejoras derivadas de las evaluaciones resulta la estructura final que se muestra en la figura C5-1 y es la misma para el patrón descrito en el capítulo anterior.

  Figura C5-1 Estructura final del patrón "Agile Usability Testing"

En la tabla C5-3 se presenta el formato del patrón “Agile Usability Testing”. Para una descripción más clara de la información contenida en el patrón dividimos la plantilla en cinco partes, el formato completo podemos visualizarlo en la sección final de este capítulo.

Tabla C5–3 Patrón "Agile Usability Testing" (Parte 1 de 5)

Name Agile Usability Testing Related pattern None

Initial context This pattern can be used in agile projects to validate how easy to use is the user interface design. This validation can be applied at the beginning of the process development and/or into the iterations. Low-fi prototypes, high-fi prototypes or even working software are tested with the users in order to identify interaction design features to improve. Tests are applied with real users or representative users from them.

Result Context Observations about user interface design and functionality are gathered from the user’s feedback through tests applied directly to them. The team analyzes, prioritizes and decides which features can be fixed at the current iteration. The remaining features that require more time or analysis to be improved are moved to the backlog for future iterations.

Problem The agile development team must be able to identify and implement as soon as possible those features that assure delivering useful software.

Forces Kind of the organization

This pattern can be used in agile projects regardless of company size.

Kind of system to be developed

This pattern can be used in agile projects that use development methodologies following the agile philosophy.

Kind of client

The user must be available and always involved through the process of the persona’s definition.

Other

 Meetings for interviews, pattern’s review or feedback between development team and user must be established in a friendly and trusting environment

 Users, UI designers and developers must be involved in the presentation, reviews and feedbacks meetings

 Pattern Agile Usability Testing must be kept available to the team through the whole development process at any moment

Nuestro patrón tiene por nombre “Agile Usability Testing” para representar el nombre de la técnica HCI a aplicar en un contexto ágil. En el campo de patrón relacionado se especifica “None” ya que por el momento el patrón Agile Usability Testing no tiene relación con otros patrones sin embargo una vez que forme parte de un lenguaje de patrones se irá actualizando este dato en su descripción. Definimos nuestro contexto inicial y

contexto resultado enfocados en la aplicación de pruebas de usabilidad tipo formativas, de mejora y de validación como un artefacto para validar el diseño y las decisiones sobre los requisitos con los usuarios. El identificar de manera temprana características en el diseño de interfaz que requieran mejora y aplicar las adecuaciones necesarias al momento evitando re trabajos posteriores, representa un problema para el equipo ágil debido a las limitaciones del tiempo establecido en la iteración. El objetivo del patrón es contribuir a minimizar o evitar dicho problema. Como restricciones (Forces) para este patrón se considera que puede ser utilizado independientemente del tamaño de la compañía en proyectos que utilizan cualquier metodología de desarrollo apegada a la filosofía ágil. Por otra parte, la participación del usuario y la disponibilidad de la descripción del patrón “Agile Usability Testing” a través de todo el proceso de desarrollo son cruciales.

El siguiente campo que se presenta en el patrón es la solución propuesta. La Tabla C5-3 (Parte 2 de 5) muestra dicha solución conformada por diferentes elementos. Primero se presentan y describen las actividades que se realizan al aplicar las pruebas de usabilidad, esto con el objetivo de que al hacer referencia al proceso “Usability testing” en los diagramas posteriores de la solución se tenga en mente las actividades involucradas con él. Posteriormente, se presentan dos diagramas en donde a partir del primero de ellos se visualiza el panorama general de los momentos en los que se propone aplicar las pruebas de usabilidad esto es, al inicio del desarrollo y durante las iteraciones. En el segundo diagrama se observa el proceso para la aplicación de las pruebas dentro de una iteración. Por último se van describiendo cada uno de los posibles enfoques para incorporar la técnica de pruebas de usabilidad en el proceso de desarrollo ágil

Tabla C5-3 Patrón "Agile Usability Testing" (Parte 2 de 5) Solution

The process of usability testing from the pattern (figure 1) involves three activities: planning the testing, applying the tests, report and analyzing the users’ observations.

1. Planning the tests, important features must be defined before applying usability testing in order to get valuable information from the users interaction:

i) Firstly the objective of the tests: knowing the goal of applying the tests assures focus on tasks definition on the user’s behavior target.

ii) Define the tasks to be applied on the usability testing: it must be focused on gathering information related to the testing’s goal.

iii) The place to apply the test: it must be defined according to the capacity, availability, advancement of development and tools. Usability testing could be applied in-home, remotely or on-site.

iv) Define test participants: it is highly recommended to apply the tests with end users of the software; however it is well known that it is not always possible. Nevertheless usability testing must be applied with end users or representative users. Developers or team elements playing the user role are not recommended. Finally, the participants are recruited and the usability testing applied.

2. Applying usability tests, the usability testing must be recorded in some way, either video recording, sound recording or capture screen windows (by some software tool). Developers and those stakeholders involved in any way with the software development must be present on the usability testing. During the usability session the observations are registered in a list.

3. Analyzing usability feedback by the whole team, those features which do not represent major changes and can be corrected before the end of the iteration are entered into the tracking system and implemented. New features requested or those too large to be implemented are considered an enhancement required and classified in the review list as urgent, important or desirable to have. These features are considered to be entered into the project backlog for subsequent iterations.

Once the usability testing review has ended and all the features have been analyzed, then the shippable product of the iteration is delivered.

Figure 2 shows when usability testing is used through an agile software development process. The process named “development iteration” has a symbol “µ” to identify the relation to the iteration process depicted in figure 3 which shows when usability testing is applied. In the diagrams the process identified as “Usability Testing” involves the activities described previously and depicted in figure 1.

Figure 2 When pattern “Usability Testing” is applied in agile process

Figure 3 When product pattern “Usability Testing” is applied in agile iteration

At the beginning of the software process the development team gets a scope of the project gathering enough information from users. Depending on time and resources, this scope could be a whole interaction design or just a general scope defining enough interaction design with subsequent enhancements during iterations. Thus, we have a few options:

a) If agile team gets information to make a whole interaction design before any other development tasks then formative usability testing is applied. Initial features can be designed by creating low-fi prototypes (like paper prototypes) to be evaluated with usability testing and then from the feedback of this review define the product backlog. Once the whole scope is designed and product backlog defined then the normal agile process continues defining iteration backlog with the user stories to develop. After the iteration development, the usability feedback gathered is applied to the product backlog update if there is another iteration to be developed. We call this approach “Interaction Design First”. Figure 4 shows the way applying usability testing marked with bold arrows through the development process.

Figure 4 Applying usability testing during iteration with approach “Interaction Design First”

b) If at the beginning of the development process the agile team gets sufficient information to make a general interaction design and decides to apply formative usability, then initial features can be designed by creating low-fi prototypes (like paper prototypes) to be evaluated with usability testing and subsequently from the feedback of this review define the initial product backlog. Once the general scope is designed and initial product backlog defined the normal agile process continues defining iteration backlog with the user stories to develop. Through the iteration development interaction design is refined by gathering data, creating low-fi prototypes and applying usability testing to them. Usability feedback is used to define which features are fixed during the actual iteration or considered in next iterations. When iteration development is finished, the usability feedback gathered is used to update the product backlog. We call this approach as “Minimal Up-Front Design”. Figure 5 shows the way applying usability testing marked with bold arrows through the development process.

Figure 5 Applying usability testing during iteration with approach “Minimal Up-Front Design”

c) Agile team gets just enough information at the beginning of the process and decides not to define interaction design. The product backlog is defined without previous formative usability testing. Once initial product backlog is defined then the normal agile process continues defining iteration backlog with the user stories to develop. Through the iteration development interaction design is defined for the actual user stories and enhanced in subsequent tasks or even iterations. We call this approach as “Implicit interaction design”. Figure 6 shows the way applying usability testing marked with bold arrows through the development process.

Figure 6 Applying usability testing during iteration with approach “Implicit Interaction Design”

d) If the development team has enough elements to work user interface design and implementation activities at the same time on parallel tracks, then get data from the user by developing research activities previous product backlog definition working this activities in a first iteration focused just to get enough information about the user and the software project (it could be named “cycle 0”). Once this initial iteration is complete initial backlog can be defined and start with the iterations where interaction design is implemented, tested and enhanced. Through iterations development team work with design track and implement track; at the design track the interface design is defined ahead for subsequently iterations, at the implement track use the feedback from previous iterations to develop the interface. We call this approach “Parallel Track”. Figure 7 depicts both design track (bold arrows) and implement track (dotted lines).

Figure 7 Applying usability testing during iteration with approach “Parallel Track”

At the end of the iteration if there is a release programmed, then usability testing is shown as optional but this test is strongly recomended and again at the end of entire project.

A continuación se describe con más detalle la solución propuesta. La figura C5-2 muestra los procesos que, de acuerdo a nuestra solución, involucra aplicar las pruebas de usabilidad en un ambiente ágil esto es, cómo se aplica la técnica en dicho entorno.

  Figura C5-2 Cómo es aplicada la técnica de pruebas de usabilidad en un proceso ágil

La planeación de las pruebas de usabilidad involucra la parte más fuerte de actividades debido a la importancia de éstas para preparar las pruebas con el objetivo de obtener la información esperada. Las actividades involucradas son:

 Definir el objetivo de las pruebas lo cual representa un factor clave para mantener en mente la meta perseguida al aplicar la prueba.

 Definir tareas o funcionalidades a probar durante la sesión de prueba

 Decidir dónde aplicar la prueba (no necesariamente en un laboratorio de usabilidad)

 Identificar a los usuarios participantes (preferiblemente usuarios finales o representativos de estos)  Reclutar participantes

 Definir cuestionario post-prueba (Si fuera necesario y se contara con tiempo suficiente para ello) Una vez que el plan de las pruebas es definido entonces se procede a aplicar las pruebas de usabilidad. De acuerdo al avance del proyecto y objetivo de la prueba el equipo decide si se aplica utilizando prototipos de bajo nivel como prototipos en papel o prototipos de alto nivel como los funcionales. Una condición importante es que los desarrolladores deben estar presentes en el test. Los usuarios son alentados para expresar en voz alta las situaciones que experimentan con el software y como las van trabajando durante la prueba que es grabada de alguna forma de acuerdo a la disponibilidad de las herramientas para esto y la comodidad de los usuarios. Conforme se va desarrollando la prueba se va generando la lista de retroalimentación, los observadores de la prueba identifican y registran en la lista posibles mejoras derivadas de las características señaladas por el usuario al interactuar con el software desarrollando las tareas definidas para la prueba. Después de las pruebas la información obtenida y registrada de los usuarios se presenta a todo el equipo con el objetivo de evaluar las observaciones y analizar la retroalimentación de usabilidad. Durante el análisis de la retroalimentación obtenida, las características analizadas y consideradas como mejora se clasifican en la lista como “bugs” (errores) para identificar aquellas que pueden repararse durante el sprint que se está ejecutando o “enhancements” (mejoras) a considerar en el desarrollo de sprints posteriores. Esta lista de características puede ayudar al momento de la planificación de la siguiente iteración para considerar aquellas que deben ser integradas como historias de usuario dentro del product backlog del proyecto. Esta lista debe estar disponible para el equipo de desarrollo en cualquier momento como una evidencia del reporte de las pruebas de usabilidad. En la figura C5-3 observamos dos diagramas en donde el proceso llamado “Usability Testing” en fondo gris indica el momento de aplicar las pruebas de usabilidad. El diagrama de la izquierda representa el proceso general de desarrollo ágil. El diagrama de la derecha muestra a detalle las actividades que corresponden al proceso “Development iteration”, identificado en el diagrama del proceso general con el símbolo “µ”, donde también se indica aplicar pruebas de usabilidad. Cabe recordar que el proceso “Usability Testing” abarca todas las actividades de la figura C5-1 descrita previamente.

Observamos que el proceso “Usability testing” se indica en diferentes momentos durante el proceso de desarrollo ágil. Se establece como opcional al principio del desarrollo ágil, obligatorio durante las iteraciones, opcional al finalizar las iteraciones y opcional después del último release. Es importante señalar que en aquellos momentos donde se indica como opcional aplicar las pruebas de usabilidad sí es altamente recomendable hacerlas. En particular durante el desarrollo de la iteración dependiendo del tipo de bloque que se trabaje (diseño o desarrollo) se indica aplicar las pruebas de usabilidad en dos momentos; este diagrama se describe a detalle más adelante.

  Figura C5-3 Cuándo es aplicado el patrón "Agile Usability Testing"

Profundizando en el proceso solución sobre cuándo aplicar las pruebas de usabilidad en un desarrollo ágil que se presenta en la figura C5-3 observamos que al inicio del proceso el equipo obtiene información de los usuarios realizando una mínima investigación por medio de observaciones y entrevistas; esto proporciona al equipo un enfoque general que le permita comenzar con el desarrollo del software. Los datos obtenidos proporcionan solamente información representativa pero importante que se irá complementando y refinando a través de las iteraciones subsecuentes. Ya con un enfoque inicial, el equipo decide si requiere aplicar una primera etapa de

pruebas de usabilidad formativa, creando prototipos de bajo nivel, para utilizar el resultado de retroalimentación de ésta en la definición del product backlog inicial. El equipo también puede decidir definir el product backlog sin necesidad de los resultados de las pruebas de usabilidad de tipo formativas. Si el equipo decide aplicar una primera etapa de pruebas de usabilidad formativa antes de la definición del product backlog inicial puede dedicar tiempo a estas actividades trabajando un ciclo 0 (Sy, 2007).

Durante la planificación de la iteración además de la priorización establecida de las historias de usuario la retroalimentación de usabilidad de iteraciones previas (en caso de no ser la primera) puede proporcionar información útil para determinar las historias de usuario a desarrollar y para ir actualizando el product backlog. Es necesario aplicar pruebas de usabilidad en cada iteración por lo que una vez definido el iteration backlog el equipo ágil decide el tipo de pruebas de usabilidad que aplicará durante la iteración que se está planificando. Esta decisión depende del avance del proyecto, el tiempo de entrega establecido y los usuarios finales o representantes que evaluarán el producto.

Una vez completa la planificación de la iteración el desarrollo de esta inicia con el equipo de desarrollo

verificando la línea de proceso a aplicar decidiendo realizar o no el diseño de interfaz (UI Design) inicialmente. Cada una de las opciones de la decisión representa bloques de actividades. La decisión de no definir un diseño de interfaz conlleva la implementación de historias de usuario para generar una aplicación funcional. Si el equipo cuenta con elementos del equipo enfocados en particular a cada uno de los bloques mencionados la solución puede trabajar ambos con actividades en paralelo (parallel track). Además, en caso de desarrollarse en paralelo el diseño puede definirse con iteraciones por adelantado a la implementación. De esta manera los equipos agiles pueden visualizar más allá de la primera iteración y definir un esbozo sobre futuros iteration backlog.

Siguiendo la línea del bloque de diseño de la interacción en la figura C5-4 tenemos que durante el desarrollo de la iteración después de diseñar prototipos de bajo nivel el aplicar pruebas de usabilidad es opcional. Sin embargo, al finalizar con la última historia de usuario es necesario aplicar pruebas de usabilidad. Similarmente siguiendo la línea del bloque de desarrollo las pruebas de usabilidad se aplican necesariamente después de implementar el desarrollo de la última historia de usuario. La retroalimentación de usabilidad obtenida de cualquiera de los dos bloques se utiliza para la planificación de la siguiente iteración.

Figura C5-4 Momentos en los que puede aplicarse pruebas de usabilidad durante la iteración

Una vez que se lleva al cabo un releaseuna nueva prueba de usabilidad puede ser aplicada y es usualmente más