Zaina, Luciana A. M.; Sharp, Helen and Barroca, Leonor (2021). UX information in the daily work of an agile team: A distributed cognition analysis. International Journal of Human-Computer Studies, 147, article no. 102574. Zaina, Luciana A. M.; Sharp, Helen and Barroca, Leonor (2021).敏捷团队日常工作中的用户体验信息：分布式认知分析。国际人机研究杂志》，147，文章编号：102574。102574.
This document has been downloaded from Open Research Online, The Open University's repository of research publications. This version is being made available in accordance with Open Research Online policies available from Open Research Online (ORO) Policies 本文件从开放大学的研究出版物资料库 "开放研究在线 "下载。本版本根据开放研究在线政策提供，可从开放研究在线 (ORO) 政策中获取。
Versions 版本
If this document is identified as the Author Accepted Manuscript it is the version after peer review but before type setting, copy editing or publisher branding 如果本文件被标识为 "作者接受稿件"，则是经过同行评审后的版本，但还未进行排版、编辑或出版商标识。
UX information in the daily work of an agile team: A distributed cognition analysis 敏捷团队日常工作中的用户体验信息：分布式认知分析
Luciana A. M. Zaina(corresponding) , Helen Sharp , Leonor Barroca Luciana A. M. Zaina(corresponding) , Helen Sharp , Leonor Barroca Computer Department - Federal University of São Carlos (UFSCar), Rodovia João Leme dos Santos (SP-264), Km 110, Sorocaba-SP, 计算机系 - 圣卡洛斯联邦大学（UFSCar），地址：Rodovia João Leme dos Santos (SP-264)，Km 110，Sorocaba-SP、Brazil 巴西 Faculty of Science, Technology, Engineering and Mathematics - The Open University, Walton Hall,MK7 6AA, Milton Keynes, UK. 科学、技术、工程和数学学院 - 英国开放大学，沃尔顿厅，MK7 6AA，米尔顿凯恩斯。
Abstract 摘要
The integration of agile software development and user experience (UX) design has been a topic of investigation for practitioners and researchers for many years, and agile teams have become increasingly aware of the importance of UX design. Most studies have focused so far on the integration of UX theories and methods with agile practices. The objective of this research is to investigate whether and how UX information is embedded in the daily work of an agile team. We conducted an ethnographic study of an agile team based in the UK. We performed a qualitative analysis using different data sources and three complementary analytical lenses: Distributed Cognition of Teamwork, Garrett's set of UX elements and planes, and Hassenzahl's content-oriented model of UX. This combination provided an understanding of the different types of UX information available to the agile team through artefacts and face-to-face meetings, how the information flowed within and around the agile team, and the type of engagement they have with UX information. The findings reveal that: (1) agile team members were consumers of UX information not producers; (2) the most common type of UX information found in the system related to how the user interacts with the product rather than to user goals or needs; (3) information focusing on the user perspective appears in verbal communication rather than being captured in artefacts; and, (4) the flow of UX information around the team is complex. In combination, these factors indicate a potential breakdown in the communication of UX information. We argue that these findings have relevance for other agile teams because the artefacts and methods used by this team are commonly used by other agile teams. To improve the situation, we suggest a number of recommendations to engage agile team members in UX work, and reduce the complexity of information flow. 多年来，敏捷软件开发与用户体验（UX）设计的整合一直是从业人员和研究人员的研究课题，敏捷团队也越来越意识到用户体验设计的重要性。迄今为止，大多数研究都集中在用户体验理论和方法与敏捷实践的结合上。本研究的目的是调查用户体验信息是否以及如何嵌入到敏捷团队的日常工作中。我们对英国的一个敏捷团队进行了人种学研究。我们使用不同的数据源和三个互补的分析视角进行了定性分析：团队合作的分布式认知、加勒特的用户体验元素和平面集以及哈森扎尔的用户体验内容导向模型。通过这种组合，我们了解了敏捷团队通过人工制品和面对面会议获得的不同类型的用户体验信息、这些信息在敏捷团队内部和周围的流动方式，以及他们参与用户体验信息的类型。研究结果表明(1) 敏捷团队成员是用户体验信息的消费者，而不是生产者；(2) 系统中最常见的用户体验信息类型与用户如何与产品交互有关，而不是与用户目标或需求有关；(3) 侧重于用户视角的信息出现在口头交流中，而不是记录在人工制品中；(4) 用户体验信息在团队中的流动是复杂的。这些因素结合在一起，表明用户体验信息的交流可能会中断。我们认为，这些发现对其他敏捷团队也有借鉴意义，因为该团队使用的人工制品和方法也是其他敏捷团队常用的。 为了改善这种情况，我们提出了一系列建议，让敏捷团队成员参与用户体验工作，降低 信息流的复杂性。
Keywords: user experience/UX information, agile team, cognitive system, information flow, DiCoT, distributed cognition, communication. 关键词：用户体验/用户体验信息、敏捷团队、认知系统、信息流、DiCoT、分布式认知、交流。
1. Introduction 1.导言
User experience (UX) designers and agile developers have worked together to incorporate UX in agile 用户体验（UX）设计师和敏捷开发人员携手合作，将用户体验融入到敏捷开发中。
projects for many years (Brhel et al., 2015; da Silva et al., 2011; Chamberlain et al., 2006). Integrating methods from these two areas presents several challenges. While agile practices motivate teams to deliver small feature sets of working software in tight iterations, UX design usually requires upfront research and analysis prior to development (da Silva et al., 2018; Kuusinen, 2015; Jurca et al., 2014; Fox et al., 2008). 多年来，这两个领域的方法在许多项目中得到了广泛应用（Brhel 等人，2015 年；da Silva 等人，2011 年；Chamberlain 等人，2006 年）。将这两个领域的方法整合在一起会带来一些挑战。敏捷实践激励团队在紧凑的迭代中交付工作软件的小功能集，而用户体验设计通常需要在开发前进行前期研究和分析（da Silva 等人，2018；Kuusinen，2015；Jurca 等人，2014；Fox 等人，2008）。
Recently, agile developers have started to recognise that UX is the responsibility of the whole team and not only of UX experts (Ardito et al., 2014; Bordin and Angeli, 2016; McInerney, 2017). However, there are still unsolved problems, such as: sharing UX work with the whole team on an ongoing basis; traceability of UX information; and, the industrial impact of UX models and tools (Kashfi et al., 2017). These problems result in UX designers and agile developers running their activities in parallel, and developer teams having difficulty in seeing what UX work is done as UX is not explicit within agile activities (Cajander et al., 2013; Ferreira et al., 2012). 最近，敏捷开发人员开始认识到用户体验是整个团队的责任，而不仅仅是用户体验专家的责任（Ardito等人，2014；Bordin和Angeli，2016；McInerney，2017）。然而，仍有一些问题尚未解决，例如：与整个团队持续分享用户体验工作；用户体验信息的可追溯性；以及用户体验模型和工具的行业影响（Kashfi 等人，2017 年）。这些问题导致用户体验设计师和敏捷开发人员并行开展活动，开发人员团队很难看到用户体验工作的内容，因为用户体验在敏捷活动中并不明确（Cajander 等人，2013 年；Ferreira 等人，2012 年）。
Typically, in agile development, communication takes place face-to-face with participants aiming to attain shared understanding (Abdullah et al., 2010), however communication about UX relies traditionally on the use of artefacts (Bordin and Angeli, 2016; Garcia et al., 2017). Also, knowledge of UX is often based more on experience and less on the application of UX models, theories or tools (Kashfi et al., 2017; Gray, 2016). The difficulties in using UX methods and tools have led agile developers to adapt artefacts they are familiar with (e.g. user stories), to support UX activities (Choma et al., 2016; Schon et al., 2017). 通常情况下，在敏捷开发过程中，交流是与参与者面对面进行的，目的是获得共同的理解（Abdullah等人，2010年），但关于用户体验的交流传统上依赖于人工制品的使用（Bordin和Angeli，2016年；Garcia等人，2017年）。此外，用户体验知识往往更多地基于经验，而较少基于用户体验模型、理论或工具的应用（Kashfi 等人，2017 年；Gray，2016 年）。使用用户体验方法和工具的困难导致敏捷开发人员调整他们熟悉的工件（如用户故事），以支持用户体验活动（Choma 等人，2016；Schon 等人，2017）。
To the best of our knowledge, little is known about the characteristics of UX information that agile teams process, and how this information is used. Many of the studies on agile and UX focus on the integration of methods and processes from agile and UX (Wale-Kolade et al., 2013; Jurca et al., 2014; Brown et al., 2011), and on communication challenges (Ferreira et al., 2012; Bordin and Angeli, 2016; Garcia et al., 2019). Others present results based on data collected with developers through interviews, questionnaires and focus groups about agile and UX (Larusdottir et al., 2017; Ardito et al., 2014; Kashfi et al., 2017; Gray, 2016), but do not examine how agile teams process UX information in their daily work. Although some researchers observe individuals in their workplace (Bordin and Angeli, 2016; Ferreira et al., 2012) they do not characterise UX information nor explore how it is integrated in software development work. Motivated by the above, we formulated two research questions (RQ): 据我们所知，人们对敏捷团队处理用户体验信息的特点以及如何使用这些信息知之甚少。许多关于敏捷和用户体验的研究都侧重于敏捷和用户体验方法与流程的整合（Wale-Kolade 等人，2013 年；Jurca 等人，2014 年；Brown 等人，2011 年），以及沟通方面的挑战（Ferreira 等人，2012 年；Bordin 和 Angeli，2016 年；Garcia 等人，2019 年）。其他研究人员则根据通过访谈、问卷调查和焦点小组收集到的开发人员数据，介绍了有关敏捷和用户体验的结果（Larusdottir等人，2017；Ardito等人，2014；Kashfi等人，2017；Gray，2016），但没有研究敏捷团队在日常工作中如何处理用户体验信息。尽管一些研究人员观察了工作场所中的个人（Bordin 和 Angeli，2016 年；Ferreira 等人，2012 年），但他们并没有描述用户体验信息的特征，也没有探讨用户体验信息是如何融入软件开发工作的。基于上述动机，我们提出了两个研究问题（RQ）：
RQ1 - Which type of UX information do agile teams process in their daily work? 问题 1 - 敏捷团队在日常工作中处理哪类用户体验信息？
RQ2 - How does UX information flow within the cognitive system of an agile team? 问题 2 - 用户体验信息如何在敏捷团队的认知系统中流动？
To answer the RQs, we carried out an ethnographic study for 3 months in 2018 to examine the cognitive system of the daily work of an agile team supporting and developing a Virtual Learning Environment 为了回答问题，我们在 2018 年开展了一项为期 3 个月的人种学研究，以考察支持和开发虚拟学习环境的敏捷团队日常工作的认知系统
used by many thousands of students a year. We collected qualitative data through observation sessions of daily work and meetings, individual interviews and participation in demo sessions and a process workshop. We followed ethnographic principles to investigate the participants' perspectives rather than formulating pre-conceptions about UX. Our investigation sought to observe how UX information featured and flowed in the day to day activity of the team. Our findings show that: (1) agile team members were consumers of UX information not producers; (2) the most common type of UX information found in the system related to how the user interacts with the product, rather than to user goals or needs; (3) information focusing on the user perspective appears in verbal communication rather than being captured in artefacts; and (4) the flow of UX information around the team is complex. In combination, these factors indicate a potential breakdown in the communication of UX information for this team. We argue that these findings have relevance for other agile teams, as literature shows that the artefacts and methods used for UX by this team are commonly used by other agile teams. We identify three areas for improvement: making more visible to team members both the motivations that lead users to interact with a product, and the functionalities offered by a product to its users; increasing the level of engagement of team members with UX information; and, decreasing the complexity, for team members, of identifying and collating UX information 每年有成千上万的学生使用。我们通过观察日常工作和会议、个别访谈、参加演示会和流程研讨会收集定性数据。我们遵循人种学原则，调查参与者的观点，而不是形成关于用户体验的先入之见。我们的调查旨在观察用户体验信息是如何在团队的日常活动中出现和流动的。我们的调查结果显示(1) 敏捷团队成员是用户体验信息的消费者，而不是生产者；(2) 系统中最常见的用户体验信息类型与用户如何与产品互动有关，而不是与用户目标或需求有关；(3) 侧重于用户视角的信息出现在口头交流中，而不是记录在人工制品中；(4) 用户体验信息在团队中的流动是复杂的。这些因素结合在一起，表明该团队在用户体验信息交流方面可能存在问题。我们认为，这些发现对其他敏捷团队也有借鉴意义，因为文献显示，该团队在用户体验方面使用的人工制品和方法是其他敏捷团队常用的。我们认为有三个方面需要改进：让团队成员更清楚地了解用户与产品互动的动机，以及产品为用户提供的功能；提高团队成员对用户体验信息的参与度；降低团队成员识别和整理用户体验信息的复杂性。
Our study builds on previous work but enhances it by bringing a perspective that focuses on the type of information available to the team, and a distributed cognition view of information propagation and transformation. This perspective supports the identification of potential communication breakdowns in information flow, and highlights the kind of UX information that is lacking in agile team working. 我们的研究建立在以往工作的基础上，但通过引入一种关注团队可用 信息类型的视角，以及一种关于 信息传播和转换的分布式认知视角，对其进行了改进。这一视角有助于识别信息流中潜在的沟通障碍，并突出敏捷团队工作中缺乏的用户体验信息类型。
This paper is organised as follows. Section 2 presents related work, and the theoretical underpinnings that guided the ethnographic study. In Section 3, we explain the research method, describe the study context, its planning, data collection and analysis approaches. The analysis and findings focusing on the use of UX information are presented in Section 4. In Section 5, the research questions are considered and recommendations are presented. In Section 6, we discuss the study validity. Finally, Section 7 offers conclusions and suggestions for future work. 本文的结构如下。第 2 节介绍相关工作以及指导人种学研究的理论基础。第 3 节介绍研究方法，描述研究背景、计划、数据收集和分析方法。第 4 节介绍了以用户体验信息的使用为重点的分析和结论。第 5 部分考虑了研究问题并提出了建议。第 6 节讨论研究的有效性。最后，第 7 部分提出了结论和对未来工作的建议。
2. Background 2.背景情况
2.1. UX and agile 2.1.用户体验与敏捷
User-centred design (UCD) consists of techniques, methods and procedures that place the user at the centre of an iterative design process (Bordin and Angeli, 2016). UCD adds UX techniques to the development process to support the design of a better experience for the user (Salah et al., 2014). 以用户为中心的设计（UCD）包括将用户置于迭代设计流程中心的技术、方法和程序（Bordin 和 Angeli，2016 年）。用户中心设计将用户体验技术添加到开发过程中，以支持为用户设计更好的体验（Salah 等人，2014 年）。
Several systematic literature reviews (SRLs) have addressed the integration of UCD, UX design and agile methods. These focus on aspects such as: (i) practices, techniques, evidence and recommendations (Wale-Kolade et al., 2013; Brown et al., 2011; da Silva et al., 2011); (ii) technical and non-technical gaps and trends (Salah et al., 2014; Jurca et al., 2014; Brhel et al., 2015); (iii) artefacts to report and control requirements (Schon et al., 2017), and (iv) the role of artefacts in the communication of aspects of UX in agile practices (Garcia et al., 2017). Recently, da Silva et al. (2018) discussed the evolution and current state of agile and UX based on a literature review. In the early days of agile, agile and UX design were assumed to work alongside each other; however, nowadays there is a recognition that agile and UX can no longer be seen as separate areas and that a shared understanding is needed. For example Kashfi et al. (2017) reported challenges, such as the impact of UX models, tools and methods in industrial settings, the need for formats other than text to communicate UX-related requirements, and the need for traceability between UX-related and business requirements. 一些系统性文献综述（SRL）探讨了用户中心设计、用户体验设计和敏捷方法的整合问题。这些文献主要涉及以下方面(i) 实践、技术、证据和建议（Wale-Kolade 等人，2013 年；Brown 等人，2011 年；da Silva 等人，2011 年）；(ii) 技术和非技术差距与趋势（Salah 等人，2014 年；Jurca 等人，2014 年；Brhel 等人，2015 年）；(iii) 工件（artefacts）与用户体验（UX）设计（UCD）、2014；Brhel 等人，2015）；(iii) 报告和控制需求的人工制品（Schon 等人，2017）；(iv) 人工制品在敏捷实践中用户体验交流中的作用（Garcia 等人，2017）。最近，da Silva 等人（2018）基于文献综述讨论了敏捷和用户体验的演变和现状。在敏捷的早期，敏捷和用户体验设计被认为是并行不悖的；但如今，人们已经认识到，敏捷和用户体验不能再被视为两个独立的领域，需要有共同的理解。例如，Kashfi 等人（2017 年）报告了一些挑战，如用户体验模型、工具和方法在工业环境中的影响，需要文本以外的格式来传达用户体验相关需求，以及用户体验相关需求与业务需求之间的可追溯性。
Other researchers have explored the integration of UX and agile through practitioners' views. Ferreira et al. (2012) suggested promoting integration by mutual awareness of agile and UX team members and their roles in the development process, and by improving the engagement of both during the development process. Kuusinen (2015) suggested a task-oriented integration approach if UX experts are scarce, clarifying which UX-related tasks could be allocated to a developer and which require UX expertise. The role of developers' mindset in the integration of agile with UX has also been highlighted. Ardito et al. (2014) found two main causes for UX neglect: the lack of suitable UX methods with low resource requirements; and, that developers focus mostly on coding activities. McInerney (2017) investigated how the views of three UX experts changed with experience in agile development, interviewing the same individuals over a period of 12 years. In the more recent interviews, the UX experts indicated a preference for agile instead of the waterfall approach, which was not the case in earlier interviews. When working in an agile way, they could quickly see designs being implemented and could collaborate closely with developers. The UX experts also reported that more recently agile developers had started to pay more attention to UX. 其他研究人员则从实践者的角度探讨了用户体验与敏捷的融合问题。Ferreira 等人（2012 年）建议，通过敏捷和用户体验团队成员的相互了解及其在开发过程中的角色，以及通过提高两者在开发过程中的参与度来促进整合。Kuusinen（2015）建议，如果用户体验专家稀缺，则应采用以任务为导向的整合方法，明确哪些用户体验相关任务可分配给开发人员，哪些需要用户体验专业知识。开发人员的思维模式在敏捷与用户体验整合中的作用也得到了强调。Ardito 等人（2014 年）发现了用户体验被忽视的两个主要原因：缺乏合适的用户体验方法，对资源的要求较低；开发人员主要关注编码活动。McInerney（2017）调查了三位用户体验专家的观点是如何随着敏捷开发经验的变化而变化的，他们对同一人进行了长达12年的访谈。在最近的访谈中，用户体验专家表示更倾向于采用敏捷方式，而不是瀑布式方法，而在早期的访谈中却并非如此。在以敏捷方式工作时，他们能很快看到设计的实施情况，并能与开发人员密切合作。用户体验专家还表示，最近敏捷开发人员开始更加关注用户体验。
Bordin and Angeli (2016) found that the limited involvement of users during an agile project and the lack of UX documentation led to problems with communication. As a solution, the authors recommended the adoption of techniques that require less time and effort, and a clear assignment of responsibilities for UX activities and decisions. Cajander et al. (2013) also found that it was unclear who was responsible for UX in an agile team, and that evaluating with users was the most commonly-used UX method. Bordin 和 Angeli（2016 年）发现，用户在敏捷项目中的参与度有限以及用户体验文档的缺乏导致了沟通方面的问题。作为解决方案，作者建议采用需要较少时间和精力的 技术，并明确分配用户体验活动和决策的责任。Cajander 等人（2013 年）还发现，敏捷团队中谁负责用户体验并不明确，而与用户一起进行评估是最常用的用户体验方法。
Communication between agile and UX experts is made difficult by the different perspectives of the two parties as indicated by Larusdottir et al. (2017); whereas in agile practices the focus is on communication within the team, for UX professionals the emphasis is on communication with users. As a consequence, the methods and artefacts used in agile development and UX design are different and with little integration of information. The authors suggested that agile teams should have a clear vision for UX in an early development phase and refer back to it regularly to check whether it should be changed. Some authors suggested that an artefact-mediated communication approach might reduce communication problems in the conversation between practitioners from different areas (Brhel et al., 2015; Kashfi et al., 2017; Schon et al., 2017; Garcia et al., 2017). According to these authors, artefacts support the introduction of a common language to avoid misunderstandings and misinterpretations. Garcia et al. (2019) investigated an online agile community to understand how artefacts are used to mediate communication between UX and agile professionals. The results revealed that mock-ups, sketches of user interfaces and personas are the most used UX artefacts that support conversation in agile teams. The findings also pointed out that these artefacts are adopted in combination with user stories. 正如 Larusdottir 等人（2017 年）所指出的，敏捷专家和用户体验专家之间的沟通因双方的不同视角而变得困难重重；在敏捷实践中，重点是团队内部的沟通，而对于用户体验专业人员来说，重点是与用户的沟通。因此，敏捷开发和用户体验设计所使用的方法和人工制品是不同的，几乎没有信息整合。作者建议，敏捷团队应在早期开发阶段就对用户体验有一个清晰的愿景，并定期回溯检查是否应做出改变。一些作者认为，以人工制品为媒介的交流方法可以减少不同领域从业人员之间对话中的交流问题（Brhel 等人，2015；Kashfi 等人，2017；Schon 等人，2017；Garcia 等人，2017）。这些作者认为，人工制品有助于引入共同语言，避免误解和曲解。Garcia等人（2019）对一个在线敏捷社区进行了调查，以了解如何使用人工制品来调解用户体验和敏捷专业人员之间的交流。调查结果显示，模型、用户界面草图和角色设计是支持敏捷团队对话的用户体验人工制品中使用最多的。研究结果还指出，这些人工制品是与用户故事结合使用的。
A diversity of virtual and physical environments have arisen to support teamwork and these have impact how information flows (Brown et al., 2011; Garcia et al., 2017). Virtual environments such as JIRA and TFS (Team Foundation Server) have been widely employed in global software development in an effort to reduce the distances in communication and collaboration amongst agile team members distributed geographically (Lanubile et al., 2013; Deshpande et al., 2016). Co-located teams also use these tools to manage the diversity and amount of information created, transformed and flowing daily in their work (Akman et al., 2016; Matta and Marchesi, 2015; Brown et al., 2011). Physical artefacts and tools, such as the Kanban board, continue to be part of the agile workplace (Deshpande et al., 2016; Brown et al., 2011; Liskin et al., 2014) and are used frequently for face-to-face communication, in stand-ups and planning meetings (Garcia et al., 2017). 为支持团队合作，出现了多种虚拟和物理环境，这些环境对信息流动方式产生了影响（Brown 等人，2011；Garcia 等人，2017）。JIRA 和 TFS（团队基础服务器） 等虚拟环境已被广泛应用于全球软件开发，以减少分布在不同地域的敏捷团队成员之间的沟通和协作距离（Lanubile 等人，2013 年；Deshpande 等人，2016 年）。位于同一地点的团队也使用这些工具来管理每天在工作中创建、转换和流动的信息的多样性和数量（Akman 等人，2016 年；Matta 和 Marchesi，2015 年；Brown 等人，2011 年）。看板等实体人工制品和工具仍然是敏捷工作场所的一部分（Deshpande 等人，2016 年；Brown 等人，2011 年；Liskin 等人，2014 年），并经常在站立和计划会议中用于面对面交流（Garcia 等人，2017 年）。
Our work is motivated by existing research but differs in several ways: we emphasise the kind of UX information that an agile team handles, going beyond just identifying which UX artefacts are used; by focusing on the flow of information in the work of an agile team, we also look into how artefacts are used, how they support communication and awareness of , and how developers are involved in the creation and transformation of UX information, an activity known to enhance the shared understanding within teams. 我们的工作受现有研究的启发，但在几个方面有所不同：我们强调敏捷团队所处理的用户体验信息的种类，而不仅仅是确定使用了哪些用户体验人工制品；通过关注敏捷团队工作中的信息流，我们还研究了人工制品是如何使用的，它们是如何支持沟通和对 的认识的，以及开发人员是如何参与用户体验信息的创建和转换的，众所周知，这种活动可以增强团队内部的共同理解。
2.2. Theoretical underpinnings 2.2.理论基础
We applied three complementary lenses in our study, described in more detail below. Distributed Cognition for Teamwork (DiCoT, Furniss and Blandford, 2006) was used to explore communication and collaboration around UX in the team's daily work. As the focus of our study was a small team, DiCOT provided an ideal framework for applying Distributed Cognition principles (Hutchins, 1995) in a practical setting. To help distinguish and categorise UX information, we drew on two well-known models of UX which provide complementary perspectives: Garrett's (2010) set of UX elements and planes, and Hassenzahl's (2010, 2018) content-oriented model. 我们在研究中使用了三个互补的视角，下面将详细介绍。团队工作分布式认知（DiCoT，Furniss 和 Blandford，2006 年）被用来探索团队日常工作中围绕用户体验的交流与协作。由于我们的研究重点是一个小型团队，因此 DiCOT 为在实际环境中应用分布式认知原则（Hutchins，1995 年）提供了一个理想的框架。为了帮助区分用户体验信息并对其进行分类，我们借鉴了两种著名的用户体验模型，它们提供了互补的视角：加勒特（Garrett，2010 年）的用户体验元素和平面集，以及哈森扎尔（Hassenzahl，2010 年，2018 年）的内容导向模型。
2.2.1. Distributed Cognition for Teamwork (DiCoT) 2.2.1.团队合作分布式认知（DiCoT）
Distributed cognition (DCog) considers that cognition manifests itself at the systemic level, rather than at the individual cognitive level of a person (Hutchins, 1995). According to DCog, information acquisition and propagation occur through the interaction of people, their environment, and artefacts. And that all of them affect human work (Hollan et al., 2000). DCog is a powerful framework that has been applied in airline cockpits (Hutchins, 1995), software programming (Mangalaraj et al., 2014) and in requirements engineering (Buchan, 2014). It has also been adopted by researchers in HCI (e.g. Wright et al., 2000) and CSCW (e.g Hoadley and Kilner, 2005) to analyse collaborative work and identify breakdowns in communication. In particular, informal communication can breakdown when the parties involved don't have a common memory of the conversation and what was decided. 分布式认知（Distributed cognition，DCog）认为，认知体现在系统层面，而不是个人的认知层面（Hutchins，1995 年）。分布式认知（DCog）认为，信息的获取和传播是通过人、环境和人工制品之间的相互作用实现的。所有这些因素都会影响人类的工作（Hollan 等人，2000 年）。DCog 是一个强大的框架，已被应用于航空驾驶舱（Hutchins，1995 年）、软件编程（Mangalaraj 等人，2014 年）和需求工程（Buchan，2014 年）。人机交互（HCI）（如 Wright 等人，2000 年）和 CSCW（如 Hoadley 和 Kilner，2005 年）领域的研究人员也采用了这一方法来分析协作工作并识别交流中断。特别是，当参与各方对谈话内容和决定没有共同记忆时，非正式交流就会中断。
Applying DCog can be challenging, and the DiCoT method (Furniss and Blandford, 2006) was developed to support the application of DCog principles when studying small teams. It combines the ideas and models of contextual inquiry (Beyer and Holtzblatt, 1998) with a set of 22 DCog principles (Furniss and Blandford, 2006) and provides a set of guidelines that the researcher can follow. The full DiCoT method categorises these 22 principles into five themes, three of which have been found to be useful in studying collaboration and communication in distributed (Sharp et al., 2012; Deshpande et al., 2016) and co-located (Sharp and Robinson, 2008) agile teams. 应用 DCog 可能具有挑战性，DiCoT 方法（Furniss 和 Blandford，2006 年）就是为了支持在研究小型团队时应用 DCog 原则而开发的。它将情境探究的理念和模型（Beyer 和 Holtzblatt，1998 年）与一套 22 项 DCog 原则（Furniss 和 Blandford，2006 年）相结合，并提供了一套研究人员可以遵循的指南。完整的 DiCoT 方法将这 22 项原则分为五个主题，其中三个主题已被证明有助于研究分布式（Sharp 等人，2012 年；Deshpande 等人，2016 年）和共驻式（Sharp 和 Robinson，2008 年）敏捷团队中的协作与沟通。
These themes are listed below and the related principles are shown in Table 1 (Furniss and Blandford 2006): 下文列出了这些主题，相关原则见表 1（Furniss 和 Blandford，2006 年）：
artefact: concentrates on the structure of tools and representations, and how they affect work in practice; 人工制品：侧重于工具和表象的结构，以及它们如何影响实际工作；
physical: focuses on the layout of the workplace and how it impacts the propagation of information; 物理：侧重于工作场所的布局及其对信息传播的影响；
information flow: focuses on the communication between team members and how information flows and is transformed within a work setting; 信息流：侧重于团队成员之间的交流，以及信息如何在工作环境中流动和转化；
Table 1: DiCoT principles - adapted from Furniss and Blandford (2006) 表 1：DiCoT 原则--改编自 Furniss 和 Blandford（2006 年）
Artefact 文物
Mediating artefacts 中介人工制品
used to support activities 用于支持活动
Creating scaffolding 创建脚手架
how people use the environment to support their tasks 人们如何利用环境来完成任务
Representation-goal parity 代表-目标奇偶性
环境中的人工制品如何体现当前状态与目标状态之间的关系
how artefacts in the environment represent the relationship between the
current state and goal state
Coordination of resources 资源协调
可协调内部和外部资源，以帮助行动和认知（如计划、目标、历史等）
resources can be internally and externally coordinated to aid action and
cognition (e.g. plans, goals, history, and so on)
Physical layout 物理布局
Space and cognition 空间与认知
the role of physical layout to support cognition 实体布局对认知的支持作用
Perception 感知
how spatial representations provide support for cognition 空间表象如何为认知提供支持
Naturalness 自然性
how closely the representation matches the properties of what it represents. 表征与所表征事物属性的匹配程度。
Subtle bodily supports 微妙的身体支持
any bodily actions used to support activities. 用于支持活动的任何身体动作。
Situation awareness 形势意识
如何通过团队所能看到、听到和获得的信息，让他们了解工作情况
how the team are kept informed about the work through what they can see,
hear and is made accessible to them
Horizon of observation 观察范围
what people can see or hear (influences people situation awareness) 人们能看到或听到什么（影响人们的情境意识）
Arrangement of equipment 设备安排
How the physical layout of equipment affects the access of information 设备的物理布局如何影响信息的获取
Information flow 信息流
Information movement 信息流动
用于在认知系统中移动信息的机制（表征和物理实现
the mechanisms (representations and physical realisation) used to move
information around the cognitive system
Information transformation 信息转换
当信息在系统中流动时，为什么、如何以及何时对其进行转换
why, how and when information is transformed as it flows through the
system
Information hubs 信息中心
central points where information flows meet and decisions are made. 信息流汇集和决策制定的中心点。
Buffers 缓冲区
where information is held until it can be processed 在处理信息之前，将信息保存在何处
Communication bandwidth 通信带宽
不同交流渠道的丰富性，如面对面交流、计算机辅助交流等
the richness of different communication channels, e.g. face-to-face
communication, computer-mediated communication, and so on
非正式和正式交流
Informal and formal
communication
交流的形式，如临时谈话或计划会议
the formality of communication, e.g. ad hoc conversation or planned
meeting
Behavioural trigger factors 行为触发因素
cause activity to happen without an overall plan needing to be in place 在没有整体规划的情况下开展活动
2.2.2. Models of 2.2.2.模型
There are many models that describe the UX design process, but in our work we were aiming to identify the type of UX information considered by an agile team, rather than the processes undertaken. Few models conceptualise UX information or UX itself and we couldn't find a single model that would be satisfactory for this purpose; instead, we identified two that provide complementary perspectives. 描述用户体验设计流程的模型有很多，但在我们的工作中，我们的目标是确定敏捷团队所考虑的用户体验信息的类型，而不是所采用的流程。很少有模型能将用户体验信息或用户体验本身概念化，我们无法找到一个能满足这一目的的单一模型；相反，我们找到了两个能提供互补视角的模型。
In 2010, Hassenzahl introduced a process-oriented model to illustrate how the design of the user experience is built from a designer perspective and from a user perspective. He also discusses that users are motivated by goals they want to reach which determine the interactions required to fulfil those goals. Considering this, he also introduced initial ideas of a three-level hierarchy of goals (Hassenzahl, 2010). 2010 年，Hassenzahl 引入了一个面向过程的模型，以说明如何从设计者和用户的角度来设计用户体验。他还论述了用户的动机是他们想要达到的目标，而这些目标决定了实现这些目标所需的交互。考虑到这一点，他还提出了三级目标层次结构的初步想法（Hassenzahl，2010 年）。
In 2018, he evolved this hierarchy of goals to propose a second model, a content-oriented model of UX (Hassenzahl, 2018) that focuses on the user perspective. This model contains three levels (Why, What and How) and a goal, the Wellbeing of users (Figure 1a). Each level guides the design of experiences that are mediated by a product. The Why level, the most abstract one, discusses the motivations that lead users to interact with a product; it focuses on the meaning that this interaction brings for the users. The What level is about the functionalities a product offers to users to fulfil their needs. The How level addresses concrete actions of the users for interacting with the tangible product, e.g. the arrangement of user interface elements. In this work, we adopted the content-oriented model of UX rather than the earlier processoriented model because our focus is on UX information rather than UX processes. 2018 年，他发展了这一目标层次，提出了第二个模型，即以内容为导向的用户体验模型（Hassenzahl，2018 年），该模型侧重于用户视角。该模型包含三个层次（"为什么"、"是什么 "和 "如何做"）和一个目标，即 "用户的福祉"（图 1a）。每个层面都指导着以产品为媒介的体验设计。为什么 "层面是最抽象的一个层面，它讨论的是用户与产品互动的动机；它关注的是这种互动给用户带来的意义。是什么 "这一层次涉及产品为满足用户需求而提供的功能。如何 "层面涉及用户与有形产品互动的具体操作，例如用户界面元素的安排。在这项工作中，我们采用以内容为导向的用户体验模型，而不是早期的以流程为导向的模型，因为我们的重点是用户体验信息，而不是用户体验流程。
Garrett (2010) proposes a different model of UX, the "elements of UX" framework (Figure 1b); this model was originally developed for web interfaces. It comprises five horizontal UX levels (called planes) with the more abstract plane at the bottom and the more concrete plane at the top. Elements of one plane may influence adjacent planes. The strategy plane, at the bottom, aligns users' needs with the product's objective. Next plane up, the scope plane, gives the detailed functionality of the product and the content elements required to meet the users' needs. Then, the structure plane specifies how the system interacts with a user and the arrangement of content. The skeleton plane deals with concrete elements such as buttons, fields and menus (interface design), content representation (information design) and with the interaction through the user interface (navigation design). Finally, the aesthetic elements are considered, in the surface plane, for a pleasing interface and fulfilment of the goals of the other planes. The five planes are split vertically into two perspectives: the product as functionality side reflecting the users' interaction with the product to accomplish tasks; and the product as information side focusing on what information the product offers to users to accomplish their tasks. 加勒特（Garrett，2010 年）提出了一种不同的用户体验模型，即 "用户体验要素 "框架（图 1b）；这一模型最初是为网页界面开发的。它包括五个水平的用户体验层次（称为平面），较抽象的平面位于底部，较具体的平面位于顶部。一个平面的元素可能会影响到相邻的平面。位于底部的战略平面将用户需求与产品目标结合起来。下一个平面，即范围平面，给出了产品的详细功能以及满足用户需求所需的内容元素。然后，结构平面规定了系统与用户的交互方式和内容安排。骨架平面涉及按钮、字段和菜单等具体元素（界面设计）、内容表达（信息设计）以及通过用户界面进行的交互（导航设计）。最后，在表面平面中考虑了美学元素，使界面赏心悦目，并实现其他平面的目标。这五个平面在垂直方向上分为两个视角：产品作为功能的一面反映了用户为完成任务而与产品进行的交互；产品作为信息的一面侧重于产品为用户完成任务而提供的信息。
The two models (Figure 1c), complement each other and together provide a suitable framework for our analysis. Hassenzahl's model (2018) allowed us to take an abstract view in which UX is seen as the experience that a product can provide for the user and hence emphasises the user perspective; Garrett's model supported us with a concrete viewpoint to observe UX from the perspective of product construction. Both models emphasise that answering the Why first is crucial to be able to determine the features (i.e. the What) and the forms of interaction (i.e. the How); however, they provide different lenses. In Hassenzahl's model, the Why level focuses on understanding the effects that the product usage could have on the users' wellbeing; in Garrett's model, the strategy plane focuses on collecting product requirements from the end-users' perspective. The What level (Hassenzahl's model) and scope plane (Garrett's model) 这两个模型（图 1c）相辅相成，共同为我们的分析提供了一个合适的框架。Hassenzahl 的模型（2018 年）使我们能够从抽象的角度将用户体验视为产品能够为用户提供的体验，因此强调了用户视角；Garrett 的模型则为我们提供了一个具体的视角，从产品构造的角度观察用户体验。这两种模型都强调，首先回答 "为什么 "是决定产品功能（即 "是什么"）和交互形式（即 "如何做"）的关键；但它们提供了不同的视角。在 Hassenzahl 的模型中，"为什么 "层面侧重于了解产品使用对用户福祉的影响；而在 Garrett 的模型中，"战略 "层面侧重于从最终用户的角度收集产品需求。什么层面（哈森扎尔模型）和范围平面（加勒特模型）
both have the purpose of defining the functionality of the product, but Garrett focuses on the functional specification of features while Hassenzahl takes an integrated view of the users' overall experience. Finally, the How level (Hassenzahl's model) considers the users' actions with the product, and Garrett's three top planes (i.e. structure, skeleton and surface) specify the mechanisms to support the users' actions. Garrett's model offers a more granular description of the elements that directly impact the design of interaction. 两者的目的都是定义产品的功能，但加勒特侧重于功能特性的规范，而哈森扎尔则从用户整体体验的角度进行综合考虑。最后，如何层面（Hassenzahl 的模型）考虑的是用户使用产品的行为，而 Garrett 的三个顶层平面（即结构、骨架和表面）规定了支持用户行为的机制。加勒特模型对直接影响交互设计的元素进行了更细化的描述。
(a) Content-oriented model of UX proposed by Hassenzal (2018) (a) Hassenzal（2018）提出的以内容为导向的用户体验模型
(b) Elements of UX model proposed by Garrett (2010) (b) 加勒特（2010 年）提出的用户体验模型要素
(c) The complementary view of Hassenzahl and Garrett models (c) 哈森扎尔模式和加勒特模式的互补观点
Figure 1: Models of UX adopted in this work 图 1：本文采用的用户体验模型
3. Research method 3.研究方法
Workplace studies aim to understand not only the professionals' activities but also the rationale underlying their actions in daily work (Ferreira et al., 2012). These studies take into account the social and situated aspects of work providing a holistic view of the whole workplace (Sellberg and Lindblom, 2014). Ethnography is one research method commonly used with DCog in workplace studies. It is a qualitative empirical approach that aims to provide an understanding of people and cultures situated in their social environments. In the case of software engineering studies, the social environment is recognised as the professionals' workplace. An ethnographic study differs from other qualitative research methods in that it stimulates the researcher to have a strong engagement with the participant group (Sharp et al., 2016). 工作场所研究不仅要了解专业人员的活动，还要了解他们在日常工作中采取行动的理由（Ferreira 等人，2012 年）。这些研究考虑到了工作的社会和情景方面，提供了对整个工作场所的整体看法（Sellberg 和 Lindblom，2014 年）。人种学是工作场所研究中常用的一种研究方法。它是一种定性实证研究方法，旨在了解社会环境中的人和文化。在软件工程研究中，社会环境被认为是专业人员的工作场所。人种学研究与其他定性研究方法的不同之处在于，它能激发研究人员与参与群体的强烈互动（Sharp et al.）
Our study consisted of four main parts: (1) pre-planning, (2) study planning, (3) data collection, and (4) analysis (Figure 2). Many iterations were performed to gather data in the organisational setting by repeating steps (2) to (4). Data collection and analysis were guided by the DiCoT principles discussed in Section 2.2.1. The second author established contact with the organisation. The study design, data gathering and analysis were mainly performed by the first author. The second and third authors participated in some observation sessions and meetings, and both supported the reviewing and refining of the study steps. The data analysis was intensely discussed by the three authors. 我们的研究包括四个主要部分：(1) 前期规划；(2) 研究规划；(3) 数据收集；(4) 分析（图 2）。通过重复步骤(2)至(4)，在组织环境中进行了多次反复的数据收集。数据收集和分析以第 2.2.1 节中讨论的 DiCoT 原则为指导。第二作者与组织建立联系。研究设计、数据收集和分析主要由第一作者完成。第二位和第三位作者参加了一些观摩会和会议，并支持对研究步骤的审查和完善。三位作者对数据分析进行了深入讨论。
Figure 2: Overview of the research method 图 2：研究方法概述
3.1. Study context 3.1.研究背景
The study was carried out in the software development unit of a large university's IT function based in the United Kingdom (UK), with more than 100 developers working on building products to support different areas of the university including management information, student support and course design. The university's VLE (Virtual Learning Environment), a version of Moodle (docs.moodle.org), was the project chosen for our study. The VLE platform provides resources for running courses at a distance. The 这项研究是在英国一所大型大学 IT 部门的软件开发部门进行的，该部门有 100 多名开发人员，负责开发支持大学不同领域的产品，包括管理信息、学生支持和课程设计。该大学的 VLE（虚拟学习环境）是 Moodle（docs.moodle.org）的一个版本，也是我们选择进行研究的项目。VLE 平台为远程课程提供资源。该平台
different modules of the VLE are used by many thousands of users (educators, tutors, students). 成千上万的用户（教育工作者、辅导员、学生）使用虚拟学习环境的不同模块。
Five co-located agile teams worked on the VLE project which was sliced into sub-projects. The teams used the Scrum framework to support their agile practices (Rubin, 2012). Each team had around five developers, one of whom played the additional role of team leader, and one Scrum Master (SM). Developers adopted cross-functional roles acting as developers and testers. Nine Product Owners (POs) participated in different VLE sub-projects, typically two POs in each sub-project; they were experts in different VLE modules (e.g. learning tests, students' statistics, delivery of materials) and represented the business view. Business analysts, user interface (UI) designers (who focused on screen design) and UX designers (who carried out research and evaluation with end-users), members of the helpdesk team, and project manager were other professionals that interacted with the VLE project. The developers and SM were co-located; the POs were co-located in another building separate from the developers. Development followed 2-week sprints, or iterations, and the teams used Scrum ceremonies e.g. release planning meetings, sprint meetings, and stand-up meetings. 五个共用同一地点的敏捷团队负责虚拟语言环境项目，该项目被划分为多个子项目。这些团队使用 Scrum 框架来支持他们的敏捷实践（Rubin，2012 年）。每个团队约有五名开发人员，其中一人还担任团队领导，另外还有一名 Scrum Master (SM)。开发人员担任开发和测试人员等跨职能角色。九名产品负责人（PO）参与了不同的 VLE 子项目，每个子项目通常有两名产品负责人；他们是不同 VLE 模块（如学习测试、学生统计、材料交付）的专家，代表了业务观点。业务分析师、用户界面（UI）设计师（专注于屏幕设计）和用户体验设计师（与最终用户一起进行研究和评估）、服务台团队成员和项目经理是与虚拟学习环境项目互动的其他专业人员。开发人员和用户体验设计师在同一地点办公，而项目管理人员则在与开发人员分开的另一栋楼里办公。开发遵循 2 周的冲刺或迭代，团队使用 Scrum 仪式，如发布计划会议、冲刺会议和站立会议。
3.2. Study planning 3.2.研究规划
Planning started with two meetings of the two first authors with an SM. In the first meeting, the researchers gained an overview of how teams worked and what the project was about, by asking two questions: (i) how does a typical VLE sub-project run? and (ii) what are the agile practices they use?. In addition, documentation about the VLE project was explored. In the second meeting, the SM and the researchers agreed on the boundaries of the study. Permission was obtained to conduct contextual interviews and observation sessions with one VLE team. Documents were explored only with the authorisation of team members. The SM suggested observing an agile team whose members were experienced in agile. 规划始于两位第一作者与一位 SM 的两次会议。在第一次会议上，研究人员提出了两个问题：(i) 典型的 VLE 子项目是如何运行的？此外，还探讨了有关 VLE 项目的文件。在第二次会议上，SM 和研究人员就研究范围达成了一致。研究人员获得了对一个 VLE 团队进行背景访谈和观察的许可。只有在团队成员授权的情况下，才能对文档进行探究。高级管理者建议观察一个敏捷团队，该团队成员在敏捷方面经验丰富。
After these meetings, the study was formalised using the five ethnographic dimensions as proposed by Sharp et al. (2016): 在这些会议之后，根据夏普等人（2016 年）提出的五个人种学维度正式确定了这项研究：
(i) observation type (participant or not) was non-participant observation with the researcher asking questions and observing individuals performing their tasks; (i) 观察类型（参与或非参与）为非参与观察，研究人员提问并观察个人执行任务的情 况；
(ii) duration of field study was estimated at 3 months; (ii) 实地研究的时间估计为 3 个月；
(iii) space and location where the observation will happen was the software development unit; (iii) 观察的空间和地点是软件开发单位；
(iv) theoretical underpinnings that support the study consisted of DiCoT (Furniss and Blandford, 2006), (iv) 支持本研究的理论基础包括 DiCoT（Furniss 和 Blandford，2006 年）、
Garrett's framework (Garrett, 2010) and Hassenzahl's content-oriented model of UX (Hassenzahl, 2018); 加勒特的框架（Garrett，2010 年）和哈森扎尔以内容为导向的用户体验模型（Hassenzahl，2018 年）；
(v) the ethnographers' intent in undertaking the study was defined by the RQs (see Section 1). (v) 民族学者开展这项研究的意图是由研究课题确定的（见第 1 节）。
A paper form with the DiCoT themes and principles was designed and used in all observation sessions. 设计了一份印有 DiCoT 主题和原则的纸质表格，并在所有观察中使用。
3.3. Data collection 3.3.数据收集
The investigation was conducted over 20 days between March and May 2018. Interviews were carried out to obtain further details and clarifications after a set of observation sessions. Semi-structured interviews were constructed based on analysis of the data collected from observations. The first interview was with the SM to get an overview of teamwork. Some interviews took place in June 2018 to validate whether the interpretation of the data collected was correct. 调查于 2018 年 3 月 日至 5 月 ，历时 20 天。在进行了一系列观察后，为了获得进一步的细节和说明，进行了访谈。根据对观察所得数据的分析，构建了半结构式访谈。第一次访谈的对象是 SM，目的是了解团队工作的概况。一些访谈在 2018 年 6 月进行，以验证对所收集数据的解释是否正确。
Each observation session lasted between 1 and 3 hours, and sessions were conducted on two nonconsecutive days each week. The researchers and the SM agreed on the best days respecting the demands of the team. The observations comprised: team member individual work, stand-up meetings, one release meeting, and one demo meeting. The data was collected through different media: audio recordings, handwritten notes, photographs and digital copies of documents and artefacts. To complement the data gathered, the first author drew sketches of the workplace layouts. DiCoT models guided all data collection. 每次观察持续 1 到 3 个小时，每周在两个不连续的日子进行。研究人员和 SM 在尊重团队需求的前提下商定了最佳观察日。观察内容包括：团队成员的个人工作、站立会议、一次发布会议和一次演示会议。数据通过不同媒介收集：录音、手写笔记、照片以及文件和人工制品的数字副本。为补充收集到的数据，第一作者绘制了工作场所布局草图。DiCoT 模型指导了所有的数据收集工作。
The kick-off question in the first interaction with a team member was: How does your daily work run? Please explain, giving examples of artefacts, task and ways of communication that you and other team members use. When asked about the UX information flow within the agile projects, all interviewees insisted that they were not responsible for giving information or preparing artefacts about UX, so we decided to ask more about "the UX artefacts they used and who was responsible for their creation". We deployed a questionnaire to collect demographic data of team members. Table 2 summarises the profiles. 在与团队成员的第一次互动中，启动问题是你们的日常工作是如何进行的？请解释一下，举例说明你和其他团队成员使用的人工制品、任务和沟通方式。当被问及敏捷项目中的用户体验信息流时，所有受访者都坚称他们并不负责提供用户体验信息或准备用户体验工件，因此我们决定询问更多关于 "他们使用的用户体验工件以及谁负责创建这些工件 "的问题。我们制作了一份问卷，以收集团队成员的人口统计数据。表 2 汇总了这些资料。
Table 2: Demographic data of the team members 表 2：小组成员的人口统计学数据
Participant 参与者
在
Experience in
that role at
敏捷开发经验
Experience
In agile development
在团队中扮演的角色
Roles played in
the team
VLE 领域的专业知识
Expertise in VLE
domain
18 years 18岁
years 岁月
开发人员、测试人员、领导者
developer, tester,
leader
Expert 专家
12 years 12 年
4 years 4 年
开发人员、领导者、交付经理
developer, leader,
delivery manager
Proficient 精通
11 years 11 年
2.5 years 2.5 年
developer,tester 开发人员、测试人员
competent 能干
10 years 10 年
1.5 year 1.5 年
developer 开发人员
competent 能干
3 years 3 年
5 years 5 年
developer 开发人员
expert 专家
2 years 2 年
6 years 6 年
scrum master 年终总结
expert 专家
The first author also participated in a workshop in which all the agile teams working on the VLE project (including POs and other collaborators) discussed the process they were currently using for product development and delivery. UX was not discussed explicitly, however participants expressed concerns about not using the feedback collected from end-users as well as they could. From our perspective, the workshop was 第一作者还参加了一次研讨会，会上所有参与 VLE 项目的敏捷团队（包括 PO 和其他合作者）讨论了他们目前使用的产品开发和交付流程。虽然没有明确讨论用户体验问题，但与会者对没有充分利用从最终用户那里收集到的反馈意见表示担忧。从我们的角度来看，此次研讨会
key to understanding how information from other collaborators entered the cognitive system. Table 3 summarises the study instruments. 这是了解其他合作者的信息如何进入认知系统的关键。表 3 概述了研究工具。
3.4. Analysis 3.4.分析
Analysis was conducted in an iterative process in which the three authors discussed the data collected using the three DiCoT themes. The first author arranged the data weekly after each data collection session (i.e. observations sessions, interviews). Then, a first analysis of the data was conducted to get some insights or make adjustments to the planning for subsequent collection activities. Additionally, any uncertainties about the data collected were clarified soon after with the team. 分析是在一个迭代过程中进行的，在这个过程中，三位作者使用三个 DiCoT 主题对收集到的数据进行了讨论。第一位作者在每次数据收集工作（即观察、访谈）后每周整理一次数据。然后，对数据进行第一次分析，以获得一些见解或对后续收集活动的规划进行调整。此外，对于收集到的数据，如有任何不确定之处，也会很快与团队进行澄清。
The tool supported the first author in managing the data. The three authors met regularly to discuss the results. Successive iterations of writing, discussing and reflecting helped to shape the findings. 工具 支持第一作者管理数据。三位作者定期会面，讨论研究结果。写作、讨论和反思的反复进行有助于形成研究结果。
Table 3: Study instruments and data gathered 表 3：研究工具和收集的数据
采用的方法
Method
applied
Source and media 资料来源和媒体
Data collected 收集的数据
访谈（团队成员）
Interviews
(team
members)
8 小时音频、13 页手写笔记和 10 张照片。
8 hours of audio, 13 pages of
handwritten notes and 10
photographs.
概述日常工作和成员对自己工作的看法。
overview of daily and members
perspective of their own work.
访谈（成员核查）
Interviews
(member
checking)
2 个小时的音频，绘制了 3 幅草图。
2 hours of audio, 3 sketches were
drawn.
验证研究人员对数据的解释；工作场所的特点。
validation of the researchers'
interpretation of data; workplace
features.
观摩课（日常工作）
Observation
sessions
(daily work)
6 个小时的观察、10 页手写笔记、3 个小时的音频和 3 张照片。
6 hours of observation, 10 pages of
handwritten notes, 3 hours of
audio and 3 photographs.
在会议（启动、发布和演示）和日常工作中与成员互动。
members interaction during
meetings (stand-up, release and
demo) and daily work.
观察会议（研讨会）
Observation
session
(workshop)
4 个小时的观察、20 页手写笔记和 4 张照片。
4 hours of observation, 20 pages of
handwritten notes and 4 photographs.
30 名与会者在工作坊期间进行了互动和讨论。
interaction and discussion of 30
participants during the work-
shop.
文物探索
Artefacts
exploration
4 documents and 12 artefacts. 4 份文件和 12 件文物。
人工制品的特点及其与团队工作的关系。
characteristics of the artefacts and
their relationship with team work.
The iterative analysis process was organised in two rounds: in the first round, the authors looked for explicit evidence of UX in all the data, e.g. use of a UX artefact. When evidence of UX was identified, tags were assigned to that chunk of data and notes were added to it. During this round, we also attributed codes to identify the ceremony in which the evidence arose or the artefact was used. During this step, the relationship among artefacts, people and activities was coded. We also took extracts from audio recordings of the interviews that could explain some of our findings. 迭代分析过程分为两轮：第一轮，作者在所有数据中寻找用户体验的明确证据，例如用户体验工件的使用。一旦发现用户体验的证据，就会为该数据块分配标签并添加注释。在这一轮中，我们还赋予了代码，以确定证据产生或人工制品使用的仪式。在这一步骤中，对人工制品、人和活动之间的关系进行了编码。我们还从访谈录音中摘录了一些可以解释我们某些发现的内容。
In the second round, the set of data was analysed using the DiCoT themes (see Table 1). This led us to an understanding of how UX information featured in the cognitive system and its propagation. Finally, we inspected the analysis for potential communication breakdowns in UX information flow. 在第二轮中，我们使用 DiCoT 主题对数据集进行了分析（见表 1）。这使我们了解了用户体验信息在认知系统中的特征及其传播方式。最后，我们检查分析了用户体验信息流中潜在的沟通障碍。
4. Findings 4.研究结果
We first present the findings according to the DiCoT themes: artefact (4.1), physical (4.2) and information flow (4.3). This analysis focuses on identifying the artefacts that contain UX information, how they are used, and how UX information flows within the agile team's daily work, in order to determine where UX features within the team's cognitive system, answering RQ2. We then apply Hassenzahl's and Garrett's lenses to investigate the type of UX information within this system (4.4) answering RQ1. Some aspects of the findings reflect more general issues raised by DiCoT analyses of agile teams, e.g. the importance of stand-up meetings as key co-ordination activities (Sharp and Robinson, 2006), but we aim to emphasise findings related specifically to UX information and only provide more general findings for completeness. 我们首先根据 DiCoT 的主题：人工制品（4.1）、物理（4.2）和信息流（4.3）来介绍分析结果。分析的重点是确定包含用户体验信息的人工制品、人工制品的使用方式以及用户体验信息在敏捷团队日常工作中的流动方式，从而确定用户体验在团队认知系统中的位置，回答问题 2。然后，我们运用哈森扎尔（Hassenzahl）和加勒特（Garrett）的视角来研究该系统中用户体验信息的类型（4.4），从而回答了问题 1。研究结果的某些方面反映了对敏捷团队进行的 DiCoT 分析所提出的更为普遍的问题，例如作为关键协调活动的站立会议的重要性（Sharp 和 Robinson，2006 年），但我们旨在强调与用户体验信息具体相关的研究结果，仅提供更为普遍的研究结果，以求完整。
4.1 Artefacts 4.1 手工艺品
Furniss and Blandford (2006) state that there may be many artefacts within a cognitive system that support the coordination of activity and recommend that analysis should concentrate only on those that are relevant to the study. In our case then, we focus only on those artefacts that impinge directly on daily work of the agile team, and that relate to UX. These were identified through early cycles of data collection including interviews with team members and initial observations. Consequently, we analyse six artefacts that carried UX information or impacted upon it. These are: user stories (represented as story cards or tasks), the Kanban board, a virtual tool to manage team work (Team Foundation Server), the handover checklist, mock-ups, and the newsboard. The Kanban board, story cards and newsboard were physical artefacts while the others were virtual. The Kanban board and Team Foundation Server (TFS) were key mediating artefacts that supported coordination of team work. Both of them can be seen as containers, i.e. they hold other artefacts together in one place (Liskin, 2015). Developers, code reviewers, testers and POs tracked their goals and coordinated their activities by following information in TFS and the Kanban board. We describe these artefacts in detail below, drawing on the DiCoT principles to describe their role in the cognitive system. Furniss 和 Blandford（2006 年）指出，在一个认知系统中，可能有许多人工制品支持活动的协调，并建议分析应只集中在与研究相关的人工制品上。在我们的案例中，我们只关注那些直接影响敏捷团队日常工作、与用户体验相关的人工制品。这些工件是通过早期的数据收集周期（包括对团队成员的访谈和初步观察）确定的。因此，我们分析了携带用户体验信息或对其产生影响的六个工件。它们是：用户故事（表现为故事卡或任务）、看板、管理团队工作的虚拟工具（团队基础服务器）、交接清单、模型和新闻板。看板、故事卡和新闻板是实物，而其他则是虚拟的。看板和团队基础服务器（TFS） 是支持团队工作协调的关键中介人工制品。它们都可以被视为容器，即把其他人工制品集中在一个地方（Liskin，2015 年）。开发人员、代码审阅人员、测试人员和 PO 通过跟踪 TFS 和看板中的信息来跟踪他们的目标并协调他们的活动。下面我们将详细介绍这些人工制品，并借鉴 DiCoT 原则来描述它们在认知系统中的作用。
4.1.1 User stories 4.1.1 用户故事
User stories were captured in two places: on the Kanban board as story cards, and in TFS as tasks. Story cards (sticky notes) were displayed on the Kanban board. Each story card represented a user story which had been created in TFS previously. Each card contained a hand-written user story name and an identification number corresponding to the task in TFS, for use during daily stand-up meetings. The colour of a sticky note represented which sub-project the story was related to, and coloured dots stuck on the notes denoted additional information, such as a yellow dot indicating that more information about that story was needed before going ahead. A template to guide story card elaboration was provided. No other information was captured on the story card. 用户故事被记录在两个地方：看板上的故事卡和 TFS 中的任务。故事卡（便签）显示在看板上。每张故事卡都代表了之前在 TFS 中创建的用户故事。每张卡片上都有一个手写的用户故事名称和一个与 TFS 中的任务相对应的标识号，以便在每日例会上使用。便签的颜色代表该故事与哪个子项目相关，便签上粘贴的彩色圆点表示附加信息，如黄色圆点表示在继续之前需要更多关于该故事的信息。我们还提供了一个模板，用于指导故事卡的阐述。故事卡上没有记录其他信息。
User stories were also captured as tasks in TFS. Two formats were used for describing the user stories. The first followed the common user story template "As a I want because " (Cohn, 2009). In the second, user stories were written in a free format describing, for example, step by step how a feature works and its technical details. Team members reported that they did not follow a pattern as to which format was used when. 用户故事也作为 TFS 中的任务被记录下来。用户故事的描述使用了两种格式。第一种格式遵循常见的用户故事模板 "As a I want because"（Cohn，2009 年）。在第二种格式中，用户故事以自由格式书写，例如，逐步描述功能的工作原理及其技术细节。团队成员表示，他们在何时使用哪种格式上没有固定模式。
4.1.2 Kanban board 4.1.2 看板
The Kanban board supported the coordination of resources and was used to represent sprints (Figure 3). It contained story cards in the form of sticky notes in different colours, which were placed in one of five columns to show which implementation stage the story had reached; these stages were: committed to sprint; in progress; ready for review; in test; or that the test was finished and the implementation was ready for verification by the PO. During stand-up meetings, the story cards on the Kanban board were moved between the columns and together they kept a record of progress on a daily basis. 看板有助于协调资源，并用于表示冲刺阶段（图 3）。看板上有不同颜色的便签形式的故事卡片，这些卡片被放置在五列中的一列，以显示故事所达到的实施阶段；这些阶段是：承诺冲刺；进行中；准备审查；测试中；或测试已完成，实施已准备就绪，可由参与方验证。在站立会议期间，看板上的故事卡在各栏之间移动，共同记录每天的进展情况。
Representation-goal parity was found in the positioning of story cards in different columns on the Kanban board to represent the overall progress of activities. As is commonly the case, the structure of the Board was designed to emphasise that the stories need to move from the left-hand side of the Board to the right-hand side, i.e. to the last column for PO approval. 在看板的不同列中放置故事卡，以表示活动的整体进展情况，这体现了目标与表述的一致性。与通常情况一样，看板的结构设计强调故事需要从看板的左侧移动到右侧，即移动到最后一栏，以便 PO 批准。
The information on the Kanban board complemented that available in TFS' backlog (see below). 看板上的信息是对 TFS 积压工作信息的补充（见下文）。
Figure 3: Physical Kanban board showing coloured story cards and annotations using coloured dots (colours are orange (upstream); green/black (bug); red (patch); yellow (more info required) 图 3：实物看板，显示彩色故事卡和使用彩点的注释（颜色为橙色（上游）；绿色/黑色（错误）；红色（补丁）；黄色（需要更多信息））。
4.1.3 Newsboard 4.1.3 新闻板
The newsboard was a wall-mounted physical board placed at the entrance to the team's room. Feedback from users about the VLE platform, collected after product release, was displayed on the board. Printed copies of user interface screens were fixed on the board, and speech bubbles representing user's voices contained user feedback. Figure 4 shows a diagrammatic representation of the newsboard. 新闻板是一个壁挂式实物板，放置在团队房间的入口处。产品发布后收集到的用户对虚拟学习环境平台的反馈意见都显示在板上。用户界面屏幕的印刷副本被固定在板上，代表用户声音的语音气泡包含了用户反馈。图 4 是新闻板的示意图。
[Participant #6] reported “...UX designers and POs report the users feedback during the retrospective meetings. However, there are no formal representations of users' feedback (model, etc...'. Yet during the workshop the participants mentioned that although the IT department frequently conducted research to gather users' feedback, the developers had access to few results; they suggested that the results of user research should be permanently available to the software development unit. None of them cited the newsboard as a source of UX information, indicating that this artefact was not seen as relevant to their work. [6 号与会者]报告说："......用户体验设计师和参与人员在回顾会议上报告用户的反馈。然而，用户反馈并没有正式的表现形式（模型等......'。然而，在研讨会上，与会者提到，尽管信息技术部门经常开展研究以收集用户反馈，但开发人员能获得的结果却很少；他们建议，软件开发部门应长期获得用户研究的结果。他们中没有人将新闻板作为用户体验信息的来源，这表明新闻板与他们的工作无关。
Figure 4: Diagrammatic representation of the newsboard 图 4：新闻板示意图
4.1.4 Team Foundation Server (TFS) 4.1.4 团队基础服务器（TFS）
TFS supported the coordination of resources and held all the project information in one place. It provided different ways to visualize this information, with the backlog and the task views being the most used by the team we observed. TFS 支持资源协调，并将所有项目信息集中在一处。它提供了可视化这些信息的不同方法，其中积压和任务视图是我们观察到的团队使用最多的。
The backlog view showed an overview of all the tasks (user stories). Figure 5 contains a diagrammatic representation of the backlog and example photograph. From the backlog, the team could see the main task details: its priorization, an identification number, brief description, where it is in the development process, the estimated effort to do it, the assigned developer, and the sprint to which the task belonged. In addition, tags could be added to provide additional information like that represented on the Kanban board by coloured dots, such as whether the team had requested more information from the PO. 积压工作视图显示了所有任务（用户故事）的概况。图 5 包含积压任务的图示和示例照片。从积压任务中，团队可以看到主要任务的详细信息：优先级、标识号、简要说明、任务在开发流程中的位置、完成任务的估计工作量、指定的开发人员以及任务所属的冲刺阶段。此外，还可以添加标签，以提供额外信息，如看板上用彩色圆点表示的信息，如团队是否已要求参与方提供更多信息。
Figure 5: Diagrammatic representation and a photograph of the backlog view format in TFS 图 5：TFS 中积压工作视图格式的图示和照片
The task view contained many details of the project, the team, the task and acceptance criteria. Additionally, complementary information could be added to any field through external links to repositories and tools, or as attachments, e.g. a mockup (see below). Figure 6 shows a diagrammatic representation of the task view. 任务视图包含项目、团队、任务和验收标准的许多细节。此外，还可以通过与资源库和工具的外部链接或作为附件（例如模型，见下文）在任何字段中添加补充信息。图 6 显示了任务视图的示意图。
As a dynamic artefact, TFS created scaffolding for the team in the form of notifications that were triggered when tasks were updated, bringing any changes to the attention of team members. 作为一个动态的人工制品，TFS 以任务更新时触发通知的形式为团队创建了脚手架，使团队成员注意到任何变化。
TFS contained many other artefacts, and had a complex structure, which became particularly evident for our focus on UX information. This was illustrated by the difficulties we observed when team members were trying to find information that required a number of artefacts to be used together. For instance, when we asked participant #1 to explain a feature he was handling, he opened a number of TFS 包含许多其他人工制品，结构复杂，这在我们关注用户体验信息时尤为明显。当团队成员试图查找需要同时使用多个人工制品的信息时，我们观察到的困难就说明了这一点。例如，当我们要求 1 号参与者解释他正在处理的一项功能时，他打开了许多网页，其中包括
different screens in TFS and followed several navigation paths to find the information. 在 TFS 的不同屏幕上，按照多个导航路径查找信息。
Figure 6: Diagrammatic representation of the task view in TFS, as used by this team (US = user story; AC = acceptance criteria) 图 6：该团队使用的 TFS 任务视图的图解表示法（US = 用户故事；AC = 验收标准）
In the interview [participant #6] stated that "TFS is the main place where information is shared". However, difficulties relating to making information visible and accessible from TFS were also mentioned. [Participant #2], for instance, mentioned “...the backlog of TFS does not provide enough resources to represent all the information we need... so we use different elements on the Kanban board to represent our work...”. [Participant #1] said “...we are not able to set up in TFS our process of testing and reviewing of coding... to do this we need to create some extra tasks...". These difficulties were also evident in our observations, and were mentioned explicitly during the process workshop, when some participants pointed out that TFS was not flexible enough to accommodate the team's development practices. In TFS, the representation-goal parity of artefacts and the coordination of resources were neither explicit nor visible in the cognitive system. 在访谈中，[6 号与会者]指出，"总部外协调局是共享信息的主要场所"。然而，也有人提到了与使信息可见和可从 TFS 获取有关的困难。例如，[参与者 #2]提到"......TFS 的积压工作没有提供足够的资源来表示我们需要的所有信息......因此我们在看板上使用不同的元素来表示我们的工作......"。[参与者 #1]说："......我们无法在 TFS 中设置测试和审查编码的流程......为此，我们需要创建一些额外的任务......"。这些困难在我们的观察中也很明显，在流程研讨会上也被明确提及，当时一些与会者指出 TFS 没有足够的灵活性来适应团队的开发实践。在 TFS 中，工件的表征-目标对等和资源的协调在认知系统中既不明确也不可见。
4.1.5 Handover checklist 4.1.5 交接清单
This created scaffolding for the team by reminding team members of the important actions they must do for each story before it can be evaluated by the PO. It contained a set of questions with Yes/No options, sorted by topics related to quality requirements and documentation updates. All team members used the same handover checklist. 这为团队搭建了脚手架，提醒团队成员在 PO 对每个故事进行评估之前必须采取的重要行动。它包含一系列问题，按与质量要求和文件更新相关的主题进行分类，并提供是/否选项。所有团队成员都使用同一份移交清单。
The handover checklist was embedded as an attachment in TFS and was linked to other official project documents such as web standards, accessibility and usability checklists. The checklist questions were completed as the story progressed through the different stages of development, e.g. from coding to testing, helping with the coordination of resources. After completing the checklist, the story state changed to 交接清单作为附件嵌入到 TFS 中，并与其他正式项目文件相链接，如网络标准、可访问性和可用性清单。随着故事在不同开发阶段（如从编码到测试）的进展，核对表问题也随之完成，从而帮助协调资源。完成核对表后，故事状态变为
signal it was ready for PO evaluation. 信号，可以进行 PO 评估。
All team members cited the handover checklist when questioned about artefacts which supported their work. For example, [participant #5]: “...we run [handover] by ourselves before we send code for review so this checks basically common things which we might have missed... things which we need to take into account as accessibility checks..."; and [participant #6]: “...handover plays the role of a reminder of what the developers should not forget to do before deploying the code into Git". 在被问及支持其工作的人工制品时，所有小组成员都提到了移交清单。例如，[5 号与会者]："......我们在将代码送审之前会自己进行[交接]，因此这基本上检查了我们可能遗漏的常见问题......我们需要考虑的可访问性检查......"；[6 号与会者]："......在将代码部署到 Git 之前，移交起到了提醒开发人员不应忘记的作用"。
4.1.6 Mock-ups 4.1.6 模拟
Mock-ups are a visual representation of the user interface associated with a user story. Developers followed these when coding features. Usually, they were attached to the task as a PDF document in TFS. Mock-ups created scaffolding for the team. The mock-ups gave details of user interface elements, formats, styles, positions on the screen, label names, and so on. They also had representation-goal parity as the intended interface (the goal state) was captured in the mock-up. 模拟模型是与用户故事相关的用户界面的可视化表示。开发人员在对功能进行编码时会使用这些模型。通常，它们会以 PDF 文档的形式附在 TFS 的任务中。模型为团队搭建了脚手架。模拟图提供了用户界面元素、格式、样式、在屏幕上的位置、标签名称等细节。由于模拟界面捕捉到了预期界面（目标状态），因此模拟界面还具有表征-目标对等性。
Team members reported that UX and UI designers were both responsible for the creation of mock-ups with the support of a PO: [participant #5]: "I discuss technical issues about UI development generally with another developer... about what it should do, what it should look like, the language we should use...in some cases if there is a lot of new user interface work as part of the project, we will have a UX designer working with the PO..."; [participant #2]: "UI designers are not part of the team...The mock-up shows the position that an element should be ...it gives specific marks on the screen, colours, style guides...". 团队成员报告说，用户体验和用户界面设计师都负责在 PO 的支持下创建模型：[5 号与会者]："我一般与另一位开发人员讨论有关用户界面开发的技术问题......讨论它应该做什么、它应该是什么样子、我们应该使用什么语言......在某些情况下，如果项目中有大量新的用户界面工作，我们会让用户体验设计师与 PO 一起工作......"；[参与者 #2]："用户界面设计师不是团队的一部分......模型显示了元素应该在的位置......它给出了屏幕上的具体标记、颜色、风格指南......"。
Sometimes, developers made sketches of the user interface (Figure 7) to elaborate on the mock-ups, when meeting one-to-one with their PO, or to capture information from a meeting. These sketches created temporary scaffolding, and were drawn by developers to confirm their understanding of what was required and then used during the coding activity. 有时，开发人员在与参与方进行一对一会谈时，或为了捕捉会议信息，会绘制用户界面草图（图 7），以详细说明模型。这些草图创建了临时脚手架，由开发人员绘制，以确认他们对所需内容的理解，然后在编码活动中使用。
Figure 7: Example of sketches drawn by a developer during a one-to-one demo meeting with the PO. These formed temporary scaffolding 图 7：开发人员在与 PO 进行一对一演示会议期间绘制的草图示例。这些草图构成了临时脚手架
4.2 Physical (and virtual) layout 4.2 物理（和虚拟）布局
Through our data collection it soon became clear that virtual layout of information was as important to the agile team as the physical layout; for example, the team's situation awareness relied on virtual artefacts such as mock-ups and handover checklists that were updated regularly. Hence, we consider below both physical and virtual layout, starting with physical layout. 通过数据收集，我们很快发现，信息的虚拟布局对于敏捷团队来说与物理布局同样重要；例如，团队的态势感知依赖于虚拟人工制品，如定期更新的模型和交接清单。因此，我们在下文中将同时考虑物理和虚拟布局，首先从物理布局开始。
The software development unit was located in a large room and team members were mostly spread out. Figure 8 shows the room layout and its dimensions; the circles identify where members of the team we observed were sitting; other workspaces were occupied by members of other teams. The Kanban and newsboard were located at one end of the room. 软件开发部门位于一个大房间内，团队成员大多分散在各处。图 8 显示了房间的布局和尺寸；圆圈表示我们观察到的团队成员所坐的位置；其他工作空间由其他团队成员占据。看板和新闻板位于房间的一端。
Figure 8: Physical room layout illustrating the seating plan for the team members in the office (developers - red circle and SM - blue circle) 图 8：实际房间布局，说明团队成员在办公室的座位安排（开发人员--红圈，高级管理 人员--蓝圈）
Due to the large dimension of the room and the location of the Kanban board, developers could not see story cards easily, nor their detail. This arrangement of equipment affected their horizon ofobservation and situation awareness of ongoing activities. The newsboard was visible only when the members were exiting or entering the room. This artefact attempted a naturalness of representation by using speech bubbles to capture users' comments. 由于房间很大，看板的位置也很高，开发人员不容易看到故事卡，也看不到它们的细节。这种设备安排影响了他们的观察视野和对正在进行的活动的情况了解。新闻板只有在成员进出房间时才能看到。通过使用语音气泡来捕捉用户的评论，这种人工制品尝试了一种自然的表达方式。
Release and sprint planning meetings took place in a nearby building where POs, UI and UX designers were located. They were supported by a large display screen which was controlled by a computer. Participants sat around a large table and shared the TFS backlog, mock-ups and simulations of features displayed on the screen, allowing everyone to see the virtual information during face-to-face discussions. Patterns of subtle bodysupports were identified specifically during the meetings such as movements in the air to draw some parts of a user interface or to simulate user interaction with the system. 发布和冲刺计划会议在附近的一栋大楼里举行，PO、UI 和 UX 设计师都在那里。会议由计算机控制的大型显示屏提供支持。与会者围坐在一张大桌子旁，共享屏幕上显示的 TFS 积压工作、模型和功能模拟，让每个人都能在面对面讨论时看到虚拟信息。在会议期间，还特别发现了一些微妙的身体支持模式，如在空中移动来绘制用户界面的某些部分或模拟用户与系统的交互。
TFS was visible to all team members throughout the day, via their workstations. TFS supported situation awareness virtually and provided a very long but hidden potential horizon of observation. The team's work was driven by user stories, but as the Kanban board was only reviewed once a day, TFS was key. However, UX information was embedded in TFS's tasks, and from a UX perspective, neither the principle of space and cognition, nor the principle of perception were applied effectively to support cognition. Figure 9 shows a diagrammatic representation of how UX information was accessed via deep navigation paths. 通过工作站，所有团队成员全天都能看到 TFS。TFS 支持虚拟的情况感知，并提供了一个非常长但隐蔽的潜在观察视野。团队的工作由用户故事驱动，但由于看板每天只审查一次，因此 TFS 就成了关键。然而，用户体验信息蕴含在 TFS 的任务中，从用户体验的角度来看，无论是空间和认知原则，还是感知原则，都没有得到有效应用以支持认知。图 9 展示了如何通过深度导航路径获取用户体验信息的图示。
This illustrates the complexity around UX information: to gather it, team members had to fol low virtual navigation paths within and outside TFS. 这说明了用户体验信息的复杂性：为了收集这些信息，团队成员必须在 TFS 内部和外部折叠出较低的虚拟导航路径。
Figure 9: Diagrammatic representation of UX information embedded in TFS and its deep navigation paths 图 9：嵌入 TFS 及其深度导航路径的用户体验信息图示
4.3 Information flow 4.3 信息流
Figure 10 presents an overview of how the information flows around this team's cognitive system. In creating this diagram, we focused on artefacts that the team used in their daily work, and any interactions where we could find evidence of UX information. We also included other professionals involved to illustrate the direct and indirect influence each one had in the information flow; developers (i.e. team members in Figure 10) received UX information via different pathways. 图 10 是该团队认知系统的信息流概览。在绘制该图的过程中，我们重点关注了团队在日常工作中使用的人工制品，以及我们可以找到用户体验信息证据的任何互动。我们还包括其他相关专业人员，以说明每个人在信息流中的直接和间接影响；开发人员（即图 10 中的团队成员）通过不同途径接收用户体验信息。
The inception of information movement into the cognitive system came from informal or formal requests from VLE users (i.e. educators, students, and so on) and sometimes UX designers. The requests reached the support team in the form of an electronic ticket input to the incident system. Additionally, the POs might receive informal or formal requests from educators and the technical support team. The POs or UX designers checked the viability and accuracy of the requests and added checked requests to the list of requests (information transformation). 信息进入认知系统的初始阶段来自虚拟学习环境用户（即教育工作者、学生等）的非正式或正式请求，有时也来自用户体验设计师的请求。这些请求以电子票据的形式输入到事件系统中，由支持团队处理。此外，PO 可能会收到来自教育工作者和技术支持团队的非正式或正式请求。参与人员或用户体验设计师检查请求的可行性和准确性，并将检查过的请求添加到请求列表中（信息转换）。
The filtered requests were re-written by POs into tasks in TFS as a result of conversations between the POs and the agile team members in groups or individually (i.e. the information was transformed), and some UX information was added to some stories. The tasks may then be refined by developers, during 经筛选的请求由主要负责人在 TFS 中重新编写成任务，这是主要负责人与敏捷团队成员分组或单独对话的结果（即信息转换），一些用户体验信息被添加到一些故事中。然后，开发人员可在以下过程中完善这些任务
sprint planning meetings. The most common information added to tasks at this point was the inclusion of details regarding acceptance criteria, technical requirements, or testing steps, i.e. a translation of the mockup into a step-by-step interactive test sequence. 冲刺计划会议。此时，任务中最常添加的信息是有关验收标准、技术要求或测试步骤的细节，即把模型转化为一步一步的交互式测试序列。
UX information was also transformed when the UI/UX designers constructed mock-ups for the tasks; these were added to TFS by themselves or POs. UI designers obtained insights and information from the POs and from the description found in the list of requests. If a project involved the development of new solutions, a careful study with users was performed by UX designers before the release planning meeting. [Participants #2 and #6] commented about the transformation of information from UX designers to mockup development: “...this data can come from PO's previous knowledge or from some more elaborate user research... In big projects the mock-ups are built considering outcomes of user research conducted previously". Depending on the level of detail, the PO would link some parts of the mock-ups by explicitly mentioning them in the task description. The handover checklist was added as an attachment for each task in TFS and developers, reviewers and testers assigned to a task completed the checklist through the implementation process. 当用户界面/用户体验设计师为任务设计模型时，用户体验信息也发生了变化；这些模型由他们自己或项目负责人添加到 TFS 中。用户界面设计师从 PO 和请求列表中的描述中获取见解和信息。如果项目涉及开发新的解决方案，用户体验设计师会在发布计划会议之前对用户进行仔细研究。[2 号和 6 号与会者]谈到了用户体验设计师将信息转化为模型开发的过程："......这些数据可以来自用户体验设计师以前的知识，也可以来自一些更细致的用户研究...在大型项目中，模型的制作会考虑到之前进行的用户研究的结果"。根据详细程度，参与项目的人员会在任务描述中明确提及模拟模型的某些部分。交接清单作为附件添加到 TFS 的每个任务中，被分配到任务中的开发人员、审核人员和测试人员在实施过程中都要填写该清单。
The mock-ups and handover checklist were static artefacts from the agile team's point of view in that the team did not elaborate the UX information they contained and only received and applied the information provided to them. 从敏捷团队的角度来看，模型和移交清单都是静态的人工制品，因为团队并没有详细说明其中包含的用户体验信息，只是接收并应用了提供给他们的信息。
Figure 10: UX information flow within the team's cognitive system 图 10：团队认知系统中的用户体验信息流
Formal or informal communication about UX could arise in stand-ups, demos, release, sprint or retrospective meetings, although the focus was not always on UX. Examples of where UX information was exchanged and decisions made include user interface issues in the discussion of a story during standups. During a demo or sprint planning meeting team members might recount typical situations of end-users in an informal way and suggest a context to illustrate possible solutions. For instance, [participant #2] mentioned 关于用户体验的正式或非正式交流可能出现在站立、演示、发布、冲刺或回顾会议中，尽管重点并不总是用户体验。用户体验信息交流和决策制定的例子包括在站立讨论期间讨论故事中的用户界面问题。在演示或冲刺计划会议上，团队成员可能会以非正式的方式讲述最终用户的典型情况，并提出一个背景来说明可能的解决方案。例如，[参与者 #2]提到
“...in the real life day, the user submits their work on the deadline... ". During demos, team members used mock-ups and a user testing tool to demonstrate the status of the development by simulating how a user interacted with UI elements and information. In addition, team members had parallel conversations, informal communication, which commonly happened after stand-up meetings. For example [Participant #5] reported “...Some ad-hoc demos can also be done at any time... there are particular issues that arise from development - usually raised at stand-ups. ". "......在现实生活中，用户在截止日期前提交作品......".在演示过程中，团队成员使用模拟模型和用户测试工具，通过模拟用户如何与用户界面元素和信息进行交互来展示开发状况。此外，团队成员还进行了平行对话和非正式交流，这通常发生在站立会议之后。例如，[参与者 #5]报告说："......一些临时演示也可以随时进行......开发中出现的一些特殊问题--通常在站立会议上提出。".
Key decisions were made in stand-ups, demos, release, sprint and retrospective meetings indicating that these represent information hubs of the cognitive system. TFS and the Kanban board held information on which key decisions could be made, and hence were information buffers. However, we found no evidence of information hubs and buffers dedicated to UX in the agile team's cognitive system. Usually, all the decisions regarding mock-ups, accessibility and usability checklists were made by POs and UI/UX designers. 关键决策是在站立会议、演示会议、发布会议、冲刺会议和回顾会议上做出的，这表明这些会议是认知系统的信息中心。TFS 和看板保存着可以做出关键决策的信息，因此是信息缓冲区。然而，在敏捷团队的认知系统中，我们没有发现专门针对用户体验的信息中心和缓冲区。通常情况下，所有关于模型、可访问性和可用性检查表的决定都是由 PO 和 UI/UX 设计师做出的。
We did not identify any behavioural trigger factors specifically regarding UX information. Team members received UX information from POs or UX professionals as part of the standard development process. Although they may contact the POs or designers with queries, most of the time, the team was the receiver of UX information. 我们没有发现任何专门针对用户体验信息的行为触发因素。作为标准开发流程的一部分，团队成员从主要负责人或用户体验专业人员那里获得用户体验信息。虽然他们可能会联系主要负责人或设计师询问情况，但在大多数情况下，团队才是用户体验信息的接收者。
4.4 UX information within the team's cognitive system 4.4 团队认知系统中的用户体验信息
The DiCoT analysis shows that UX information appears in some development artefacts and is discussed during some meetings and interactions involving agile team members, the POs and UI/UX designers. This section applies the UX models introduced in Section 2.2.2 and uses them to explore the type of UX information that teams handle in their daily work. We use the levels and planes of the UX models introduced in Figure 1 to describe the information we found. DiCoT 分析表明，用户体验信息出现在一些开发工件中，并在一些涉及敏捷团队成员、项目负责人和用户界面/用户体验设计师的会议和互动中被讨论。本节运用第 2.2.2 节中介绍的用户体验模型，探讨团队在日常工作中处理的用户体验信息类型。我们使用图 1 中介绍的用户体验模型的层次和平面来描述我们发现的信息。
4.4.1 UX information: Why 4.4.1 用户体验信息：为什么
Traces of Hassenzal's Why level of UX information appear in face-to-face meetings and informal conversations, but only occasionally. For example, when discussing scenarios of use in demo meetings, developers and POs may talk about the goal of a feature, i.e. whether this feature meets the user needs (Garrett's model); end-users' feedback and results of user research were presented to the team during retrospective 哈森扎尔的 "为什么 "层面的用户体验信息出现在面对面的会议和非正式谈话中，但只是偶尔为之。例如，在演示会议上讨论使用场景时，开发人员和主要负责人可能会谈论某个功能的目标，即该功能是否满足了用户需求（加勒特模型）；在回顾会议上向团队介绍最终用户的反馈和用户研究的结果。
meetings. 会议。
The only artefact that showed traces of this level of UX information was the newsboard. Here, the speech bubbles together with the user interface screens showed traces of all three levels: the Why, What and How types of UX information. In particular, the bubbles contained descriptions of users' reactions when they used a feature. These descriptions reflected the Why, i.e. their motivations to use that feature or their feelings when using that feature. 唯一显示出用户体验信息这一层次的人工制品是新闻板。在这里，语音气泡和用户界面屏幕显示了所有三个层次的用户体验信息："为什么"、"是什么 "和 "如何"。特别是，气泡中包含了用户使用某项功能时的反应描述。这些描述反映了 "为什么"，即他们使用该功能的动机或使用该功能时的感受。
4.4.2 UX information: What 4.4.2 用户体验信息：什么
As would be expected, user stories contain information regarding the What of a system (its features) and hence defined its scope. However, their main focus was on technical and business information rather than explicitly considering the user experience more holistically, or understanding the users' perspective. For example, the Kanban Board and story cards held only identification and technical information related to system structure and process, and did not include any references or pointers to UX information. In TFS, the main body of tasks contained functional specifications and contents requirements, however, they also linked to mock-ups and other artefacts that contained how UX information. The newsboard included some UX information at the What level from the users' point of view. For example, in the speech bubbles users are reacting a feature and hence are providing information in the What level. 正如我们所预料的那样，用户故事包含与系统的内容（功能）有关的信息，因此也界定了系统的范围。然而，它们主要关注的是技术和业务信息，而不是更全面地考虑用户体验或理解用户的观点。例如，看板和故事卡只包含与系统结构和流程相关的识别和技术信息，而不包括任何用户体验信息的参考或指向。在 TFS 中，任务主体包含功能规格和内容要求，但它们也与包含用户体验信息的模型和其他人工制品相关联。从用户的角度来看，新闻板包含了一些用户体验信息。例如，在语音气泡中，用户正在对一项功能做出反应，因此提供了 "什么 "层面的信息。
We also see evidence of the What level in demo meetings and stand-ups - mostly in the form of discussions relating to features that are implemented through tasks. 我们还可以在演示会议和站立会议上看到 What level 的证据--主要表现为与通过任务实施的功能有关的讨论。
4.4.3 UX information: How 4.4.3 用户体验信息：如何
In contrast to the other two levels, UX information that focuses on the How level appears in many places within the cognitive system. Specifically, this type of information was identified in mock-ups, newsboard, TFS tasks, and handover checklists. Mock-ups were concrete models of the VLE user interface and carried details regarding styles, interface design and information architecture, respectively surface, skeleton, and structure planes of Garrett's framework. The handover checklist guidelines, i.e. web standards, accessibility and usability checklists, contained aspects of sensory design, interface design and navigation design, belonging respectively to Garrett's surface and skeleton planes. All elements found in the mockups and guidelines were therefore related to the How level. 与其他两个层面不同，用户体验信息侧重于 "如何 "层面，在认知系统的许多地方都有出现。具体来说，这类信息出现在模拟模型、新闻板、TFS 任务和交接清单中。模型是虚拟学习环境用户界面的具体模型，包含有关风格、界面设计和信息架构的详细信息，分别是加勒特框架的表面、骨架和结构平面。交接清单指南，即网络标准、可访问性和可用性清单，包含感官设计、界面设计和导航设计的各个方面，分别属于加勒特的表面和骨架平面。因此，模型和指南中的所有元素都与 "如何 "层面相关。
Most TFS tasks contained technical and business information, but some contained links to other VLE modules to give concrete examples of what the developer should implement, and others showed evidence of user interaction (interaction design), mandatory user interface styles (sensory design), and elements of the user interface (interface design). These also focused on the How level. There were no structural elements in tasks dedicated to UX. In some tasks there was evidence of the following UX elements: user 大多数 TFS 任务都包含技术和业务信息，但也有一些任务包含与其他 VLE 模块的链接，以提供开发人员应实施的具体实例，还有一些任务显示了用户交互（交互设计）、强制性用户界面风格（感官设计）和用户界面元素（界面设计）的证据。这些也都集中在 "如何 "层面。用户体验任务中没有结构元素。在一些任务中，有证据表明存在以下用户体验要素：用户
interactions (interaction design), mandatory user interface styles (sensory design), and interface (interface design). 交互（交互设计）、强制性用户界面风格（感官设计）和界面（界面设计）。
User stories and mock-ups took complementary perspectives on UX information when viewed through Garrett's vertical planes. Mock-ups provided the team with details of what users could see and which parts they could interact with, i.e. product as information in Garrett's framework. User stories, on the other hand, captured the product's behaviour by describing the user's interaction, i.e. product as functionality in Garrett's framework (see Table 4). 通过加勒特的垂直平面来观察用户体验信息时，用户故事和模拟模型的视角是互补的。模型为团队提供了用户可以看到的细节，以及他们可以与哪些部分进行交互，即加勒特框架中的产品信息。另一方面，用户故事通过描述用户的交互行为来捕捉产品的行为，即 Garrett 框架中作为功能的产品（见表 4）。
Table 4: "How" UX elements captured in user stories (tasks) and mock-ups within Garrett's vertical planes 表 4：Garrett 垂直平面内的用户故事（任务）和模型中捕捉到的 "如何 "用户体验元素
Artefact 文物
表面平面
Surface
plane
骨架平面
Skeleton
plane
结构平面
Structure
plane
加内特的观点
Garrett's
Perspective
TFS 中的任务（用户故事）
Tasks in TFS
(User stories)
sensory 感觉
interface 界面
interaction 互动
产品即功能
product as
functionality
Mock-ups 模拟
sensory 感觉
interface 界面
architecture 建筑
产品信息
product as
information
The newsboard contained How level information too, e.g. the links between the bubbles and the user interface screens illustrated the concrete elements that made up the user interaction with the product. 新闻板还包含了多层次的信息，例如，气泡和用户界面屏幕之间的链接说明了用户与产品互动的具体元素。
We found evidence of how information in all the information hubs identified in the information flow model: stand-ups, demos, release, sprint and retrospective meetings. For example, in demo meetings, when the PO and developers were guided by a scenario of use, the conversation focused on interaction design, information architecture and navigation design; in sprint planning meetings, conversations focused on prototypes referred to interface widgets (e.g. buttons), potential usability problems, navigation (sequence of actions) and position of interface elements; and in stand-ups specific parts of the interface were discussed. 我们在信息流模型中确定的所有信息枢纽中都发现了信息如何流动的证据：站立会议、演示会议、发布会议、冲刺会议和回顾会议。例如，在演示会议上，当参与人员和开发人员在使用场景的指导下进行讨论时，对话的重点是交互设计、信息架构和导航设计；在冲刺计划会议上，对话的重点是原型，其中提到了界面小部件（如按钮）、潜在的可用性问题、导航（操作顺序）和界面元素的位置；在站立会议上，讨论了界面的具体部分。
5. Discussion 5.讨论
In this section, we answer the research questions from Section 1, and extract recommendations for improving the flow of UX information in agile teams. To answer RQ1, we analysed the data using the models of UX described in Section 2.2.2 (Figure 1). DiCoT provided a structure to answer RQ1 and RQ2 by identifying where UX information could be found within artefacts, and how information flows and is transformed through the cognitive system. Throughout this section we also consider whether our findings may be applicable to other agile teams, by comparing our key insights with previous studies reported in the literature. 在本节中，我们将回答第 1 节中的研究问题，并提出改善敏捷团队中用户体验信息流的建议。为了回答问题 1，我们使用第 2.2.2 节中描述的用户体验模型对数据进行了分析（图 1）。通过确定用户体验信息在工件中的位置，以及信息如何在认知系统中流动和转换，DiCoT 为回答问题 1 和问题 2 提供了一个结构。在本节中，我们还通过将我们的主要见解与以往文献中的研究进行比较，考虑我们的发现是否适用于其他敏捷团队。
5.1 RQ1 - Which type of UX information do agile teams process in their daily work? 5.1 问题 1 - 敏捷团队在日常工作中处理哪类用户体验信息？
In our study, UX information appeared in artefacts and in interactions between members of the team, POs and UI/UX designers. Information relating to the How level, specifically the surface, skeleton and structure planes, were the most common type of information captured in the artefacts used in the daily work of the team. This type of information 在我们的研究中，用户体验信息出现在人工制品中，也出现在团队成员、项目负责人和用户界面/用户体验设计师之间的互动中。在团队日常工作中使用的人工制品中，最常见的 信息类型是与 "如何 "层面相关的信息，特别是表面、骨架和结构平面。这类信息
was identified in mock-ups, TFS tasks, newsboard and handover checklists. Information relating to the What level featured in user stories (specifically tasks in TFS) and also arose during verbal interactions between team members and POs or UX/UI designers. The newsboard contained traces of all three levels of UX information. All levels of UX information were mentioned to some degree in the various Scrum ceremonies and in informal interactions. The Why level was least well-represented in both artefacts and information flow, although was occasionally mentioned in meetings. 在模型、TFS 任务、新闻板和交接清单中都能找到。与 "什么 "层级相关的信息出现在用户故事（特别是 TFS 任务）中，也出现在团队成员与 PO 或用户体验/用户界面设计师的口头交流中。新闻板包含了所有三个层面的用户体验信息。在各种 Scrum 仪式和非正式互动中，所有层面的用户体验信息都在一定程度上被提及。为什么 "层面在工件和信息流中的体现最少，但偶尔也会在会议中被提及。
The handover checklist and newsboard artefacts are peculiar to our studied setting, but mock-ups and TFS tasks (user stories) are commonly used in agile teams. For example, several studies report that mockups are the artefact most often adopted by software professionals to represent UX work (Gray, 2016; Kashfi et al., 2017; Ardito et. al, 2014) and that mock-ups are used in combination with technical documents and user stories (Bordin and Angeli, 2016; Garcia et al., 2019). Others have also found that most UX information is discussed in agile ceremonies rather than captured in artefacts (Cajander et al., 2013; Garcia et al., 2019). 交接清单和新闻板是我们所研究的环境中特有的工件，但模型和 TFS 任务（用户故事）在敏捷团队中很常用。例如，一些研究报告指出，模拟图是软件专业人员最常采用的代表用户体验工作的人工制品（Gray，2016；Kashfi 等人，2017；Ardito 等人，2014），而且模拟图与技术文档和用户故事结合使用（Bordin 和 Angeli，2016；Garcia 等人，2019）。其他人还发现，大多数用户体验信息是在敏捷仪式上讨论的，而不是在人工制品中记录的（Cajander 等人，2013 年；Garcia 等人，2019 年）。
This comparison with other studies indicates that our findings regarding the type of UX information considered are relevant beyond the studied setting. 这种与其他研究的比较表明，我们关于用户体验信息类型的研究结果超越了所研究的环境。
5.2 RQ2 - How does UX information flow within the cognitive system of an agile team? 5.2 问题 2--用户体验信息如何在敏捷团队的认知系统中流动？
In our study, UX information flowed within the cognitive system via the key information buffer TFS, and via synchronous communication in ceremonies and meetings, and asynchronous communication by email. However several aspects of this information flow are problematic. 在我们的研究中，用户体验信息通过关键信息缓冲区 TFS、仪式和会议中的同步交流以及电子邮件中的异步交流在认知系统中流动。然而，这种信息流在几个方面存在问题。
First, some types of UX information, particularly the Why, flow almost exclusively through oral communication and are not captured in artefacts. This suggests an increased level of transformation of this type of UX information between people and representations, e.g. between individuals and through individuals' own notes or sketches. High levels of information transformation can be a positive sign of teams developing a shared understanding (Abdullah et. al., 2010), but it can also cause communication problems if understandings are not discussed sufficiently and aligned. 首先，某些类型的用户体验信息，尤其是 "为什么"，几乎完全是通过口头交流传播的，并没有记录在人工制品中。这表明，这类用户体验信息在人与人之间和表象之间的转换程度有所提高，例如，在个人之间以及通过个人的笔记或草图进行转换。高水平的信息转换可以成为团队形成共同理解的积极标志（Abdullah et al.
Second, UX information was gathered from users by POs, UI designers and UX designers, and transformed into user stories and mock-ups which were then delivered to developers. Accessibility and usability guidelines were also usually prepared by POs, UX designers and UI designers with no developer input. Developers therefore had no active participation in constructing UX information but only transformed it to produce code, supported by style guides and accessibility guidelines. This may have contributed to the team members' view that UX issues were the responsibility of the PO, UX designers 其次，用户体验信息由用户体验专家、用户界面设计师和用户体验设计师从用户那里收集，并转化为用户故事和模型，然后交给开发人员。可访问性和可用性指南通常也是由主要负责人、用户体验设计师和用户界面设计师编写的，开发人员并不参与其中。因此，开发人员没有积极参与用户体验信息的构建，而只是在风格指南和可访问性指南的支持下将其转化为代码。这可能导致团队成员认为用户体验问题是 PO、UX 设计师和 UI 设计师的责任。
and UI designers, and not themselves. Figure 11 is derived from Figure 10 and focuses on the agile development team alone. Where double-headed arrows appear in this diagram, detailed inspection shows that exchanges are restricted to clarification of How and some What information resulting in the translation of mock-ups and guidelines into task details. This emphasises the team members' passive consumption of UX information. A lack of engagement by developers with early UX discussions has been found to compromise technical qualities of the system (Plonka et al., 2014) 而不是他们自己。图 11 源自图 10，仅关注敏捷开发团队。在图中出现双头箭头的地方，仔细观察可以发现，交流仅限于澄清 "如何 "和一些 "什么 "信息，从而将模型和指南转化为任务细节。这说明团队成员被动地接受用户体验信息。开发人员缺乏对早期用户体验讨论的参与会影响系统的技术质量（Plonka et al.）
Figure 11 UX Information flow focusing on the agile team, based on Fig 10. (Note: team members' input of UX information relates to translation of mock-ups and guidelines into code, focused on the How, rather than active engagement with What or Why) 图 11 敏捷团队的用户体验信息流，基于图 10。(注：团队成员对用户体验信息的输入与将模型和指南转化为代码有关，侧重于 "如何"，而不是积极参与 "是什么 "或 "为什么"）。
Third, TFS contained most of the persistent information about UX. However, team members struggled to track UX information through it, and UX artefacts were often 'hidden' as attachments to tasks. If information is not visible or is difficult to collate, extra cognitive effort is needed to search for and gather it before use (Scaife and Rogers, 1996), and this can lead to mistakes. Kashfi et al. (2017) and Ferreira et al. (2012) also found that software practitioners struggle to keep UX information visible throughout software development. Virtual software management environments such as TFS are commonly used by agile teams (VersionOne, 2019), but they can be difficult to manage because of the wide choice of settings available (Akman et al., 2016). 第三，TFS 包含了大部分有关用户体验的持久性信息。然而，团队成员却很难通过它来追踪用户体验信息，用户体验工件往往被 "隐藏 "起来，成为任务的附件。如果信息不可见或难以整理，在使用前就需要付出额外的认知努力来搜索和收集信息（Scaife 和 Rogers，1996 年），这可能会导致错误。Kashfi 等人（2017 年）和 Ferreira 等人（2012 年）也发现，软件从业人员在整个软件开发过程中都在努力保持用户体验信息的可见性。TFS等虚拟软件管理环境是敏捷团队常用的软件管理环境（VersionOne，2019），但由于可供选择的设置较多（Akman等人，2016），管理起来可能比较困难。
Taken together, these observations indicate that UX information flow was complex and carried a high cognitive load, and that the structure of the commonly-used environment TFS contributed to that complexity. In addition, the more abstract levels of UX information relating to the user perspective were 总之，这些观察结果表明，用户体验信息流是复杂的，具有很高的认知负荷，而常用环境 TFS 的结构则加剧了这种复杂性。此外，与用户视角相关的用户体验信息中较为抽象的层次是
communicated verbally and often informally, which suggests a potential breakdown in understanding. Comparisons with the literature suggests that these findings are also relevant beyond the studied setting. 这表明在理解方面可能存在障碍。与文献的比较表明，这些研究结果也适用于所研究的环境之外。
5.3 Recommendations to support agile teams in making better use of UX information 5.3 支持敏捷团队更好地利用用户体验信息的建议
Based on our findings that are relevant beyond the studied setting, we suggest three areas for potential improvement in the use of UX information by agile teams: 根据我们的研究结果，我们提出了敏捷团队在使用用户体验信息方面可能需要改进的三个方面：
make the Why and What of UX information from the users' point of view more explicit and visible to team members; 从用户的角度出发，使用户体验信息的 "为什么 "和 "是什么 "更加明确，让团队成员更加清晰可见；
increase the level of engagement of team members with UX information; and, 提高团队成员对用户体验信息的参与度；以及
decrease the complexity for team members of identifying, collating and hence tracking UX information. 降低团队成员识别、整理和跟踪用户体验信息的复杂性。
Combining the discussion above and related literature we propose the following recommendations to address these areas: 综合上述讨论和相关文献，我们针对这些领域提出以下建议：
5.3.1 Recommendation 1 - Create an informative workspace to make Why and What information more visible (addressing areas 1 and 2 ) 5.3.1 建议 1--创建一个信息丰富的工作区，使 "为什么 "和 "是什么 "的信息更加醒目 （涉及领域 1 和 2）
Although agile team members are aware of the importance of UX (Kollman et al, 2009), their mindset is mostly focused on coding (Ardito et al., 2014; Kuusinen, 2015) and an overall view of UX is uncommon in agile settings (Cajander et al., 2013; Bordin and Angeli, 2016), making it difficult for developers to engage with UX. This is exacerbated because agile and UX artefacts are often completely different and with little integration of information (Larusdottir et al., 2017; Garcia et al. 2019). A UX informative workspace that displays UX artefacts and end-user feedback could help the whole team remain engaged with UX, and promote discussion of UX at different levels (i.e. abstract and concrete perspectives). Making UX information visible is easier than trying to integrate information and artefacts. 尽管敏捷团队成员意识到用户体验的重要性（Kollman 等人，2009 年），但他们的思维模式大多集中在编码上（Ardito 等人，2014 年；Kuusinen，2015 年），对用户体验的整体看法在敏捷环境中并不常见（Cajander 等人，2013 年；Bordin 和 Angeli，2016 年），这使得开发人员很难参与用户体验。由于敏捷和用户体验的人工制品往往完全不同，而且几乎没有信息整合，因此这种情况更加严重（Larusdottir 等人，2017 年；Garcia 等人，2019 年）。显示用户体验工件和最终用户反馈的用户体验信息工作区可以帮助整个团队保持对用户体验的参与，并促进不同层面（即抽象和具体视角）的用户体验讨论。让用户体验信息显而易见比试图整合信息和人工制品更容易。
Informative workspaces are not new in the agile context and have been used by UX designers working with agile teams; however, we are suggesting an informative workspace specifically to keep the user perspectives of Why and What aspects more visible, i.e. to make user feedback and user research part of the workspace for the team. Giving prominence to user research feedback impacts positively on the development of the team's expertise regarding users, has a motivational effect on developers (Sach, 2013), and supports team members in taking decisions for future product features or improvements (GonzálezTorres et al., 2013; Paredes et al., 2014). 信息工作区在敏捷环境中并不陌生，与敏捷团队合作的用户体验设计师也曾使用过；不过，我们建议专门设立一个信息工作区，让 "为什么 "和 "是什么 "的用户视角更加明显，即让用户反馈和用户研究成为团队工作区的一部分。重视用户研究反馈会对团队有关用户的专业知识发展产生积极影响，对开发人员产生激励作用（Sach，2013 年），并支持团队成员为未来产品功能或改进做出决策（González-Torres 等人，2013 年；Paredes 等人，2014 年）。
5.3.2 Recommendation 2- Encourage those who engage directly with users to take a more active role in facilitating the team's understanding of Why and What (addressing areas 1 and 2) 5.3.2 建议 2--鼓励直接与用户打交道的人员在促进团队理解 "为什么 "和 "是什么 "方面 发挥更加积极的作用（针对领域 1 和 2）。
Agile practices often encourage end-user participation during the development process and several authors recognise that the involvement of end-users brings benefits and quality to product development (Cajander et al., 2013; Abelein and Paech, 2015), but this can be hard to achieve. Even when end-users are involved, agile teams may lack information about the product's motivation and its impact in the end-users' daily activity (Bordin and Angeli, 2016; Kashif et al., 2017), but when other professionals facilitate communication with end-users, their needs become advisory rather than integral to the team's work (Bordin and Angeli, 2016; Ardito et al., 2014). 敏捷实践通常鼓励最终用户参与开发过程，一些作者认为最终用户的参与能为产品开发带来益处和质量（Cajander 等人，2013 年；Abelein 和 Paech，2015 年），但这可能很难实现。即使最终用户参与其中，敏捷团队也可能缺乏有关产品动机及其对最终用户日常活动影响的信息（Bordin 和 Angeli，2016；Kashif 等人，2017），但当其他专业人员促进与最终用户的沟通时，他们的需求就变成了咨询，而不是团队工作的组成部分（Bordin 和 Angeli，2016；Ardito 等人，2014）。
To overcome the difficulties perceived in involving end users, and building on the common practice of having an intermediary, e.g. PO or UI designer, we suggest that those who engage directly with users take a more active role in helping team members to understand the users' motivations and goals. 为了克服在让最终用户参与方面遇到的困难，我们建议，那些直接与用户打交道的人应发挥更积极的作用，帮助团队成员了解用户的动机和目标。
5.3.3 Recommendation 3- Create guidelines to establish clear and simple structures to organise UX 5.3.3 建议 3--制定指导方针，建立清晰、简单的用户体验组织结构
information in software tools (addressing area 3)
The effort required to acquire information using a virtual tool increases if navigation structures are complex, deep or disjointed (referred to as virtual distance in Bjarnason and Sharp, 2017), and traceability becomes difficult when information is dispersed (Kashfi et al., 2017). Liskin (2015) investigated impediments to artefact use in requirements communication and concluded that handling multiple artefacts is challenging and leads to manual translation effort and inconsistencies. Our DiCoT analysis indicates similar problems with UX information. Integrated software development tools are widely used by agile teams and are important to support the team sharing UX and software information (da Silva et al., 2018). To improve the situation with UX information we suggest the following: 如果导航结构复杂、深奥或不连贯（Bjarnason 和 Sharp，2017 年称之为虚拟距离），使用虚拟工具获取信息所需的精力就会增加，而当信息分散时，可追溯性就会变得困难（Kashfi 等人，2017 年）。Liskin（2015）调查了需求交流中使用人工制品的障碍，并得出结论：处理多个人工制品具有挑战性，会导致人工翻译工作和不一致性。我们的 DiCoT 分析表明，用户体验信息也存在类似问题。集成软件开发工具被敏捷团队广泛使用，对于支持团队共享用户体验和软件信息非常重要（da Silva 等人，2018 年）。为改善用户体验信息方面的情况，我们提出以下建议：
encourage designers of these tools to support an integrated vision of UX. Most tools to support agile working still treat agile and UX as separate activities, which can lead to barriers that prevent UX from being seen as a cross-cutting concern (da Silva, 2018); 鼓励这些工具的设计者支持用户体验的综合愿景。大多数支持敏捷工作的工具仍将敏捷和用户体验视为独立的活动，这可能会导致用户体验被视为跨领域问题的障碍（da Silva，2018）；
create guidelines or good practices that team members can use for linking and organising UX information within the tools, e.g. using information templates (Liskin, 2015); 创建团队成员可用于在工具中链接和组织用户体验信息的指南或良好实践，例如使用信息模板（Liskin，2015）；
create markers that highlight different types of information and differentiate UX information from other types, e.g. using different colours, highlights or keywords as tags. Each team could then devise a suitable UX vocabulary to give meaning to the tags; 创建标记，突出不同类型的信息，并将用户体验信息与其他类型的信息区分开来，例如使用不同的颜色、亮点或关键词作为标签。然后，每个小组都可以设计一个合适的用户体验词汇表，以赋予标记意义；
keep UX artefacts in a central repository and reference them via links. This would help maintain consistency, avoid duplication of UX artefacts, and enhance UX traceability (Kashfi et al., 2017). 将用户体验人工制品保存在一个中央资源库中，并通过链接进行引用。这将有助于保持一致性，避免用户体验人工制品的重复，并提高用户体验的可追溯性（Kashfi 等人，2017 年）。
6. Study Validity 6.研究的有效性
We discuss the trustworthiness of our work from the perspectives of threats to validity in flexible designs, bias and rigour and generalizability based on Robson and McCartan (2016). We identify relevant issues and discuss any mitigations below. 我们以 Robson 和 McCartan（2016 年）为基础，从灵活设计的有效性威胁、偏差、严谨性和可推广性等角度讨论了我们工作的可信度。我们将在下文中指出相关问题并讨论任何缓解措施。
6.1 Threats to validity in flexible designs 6.1 对灵活设计有效性的威胁
The description of our study covers the setting details and the steps we followed. To guarantee the quality of our descriptions, we took into account data gathered from different sources, e.g. audio recording and hand-written notes. The methodology is reported in detail, supporting replication in other studies. 我们的研究描述包括环境细节和我们所遵循的步骤。为了保证描述的质量，我们考虑了从不同来源收集的数据，如录音和手写笔记。我们详细报告了研究方法，以支持其他研究的复制。
Our data interpretation was guided by the DiCOT framework and UX models which avoided some bias from the researchers' points of view. We chose two complementary UX models, Hassenzahl's model (2018) and Garrett's framework (2010), to mitigate any disconnected interpretation that could be arise from multiple researchers. Using these established approaches in our analysis provides a frame of reference for readers. The participation of three researchers avoided conclusions based on a single interpretation. Each step of the analysis was revised by the others through discussion of the results, findings and their implications. We did not adopt any theory to give a prior conception about the research. 我们的数据解释以 DiCOT 框架和用户体验模型为指导，避免了研究人员观点的偏差。我们选择了两个互补的用户体验模型，即 Hassenzahl 的模型（2018 年）和 Garrett 的框架（2010 年），以减少多个研究人员可能产生的任何互不关联的解释。在我们的分析中使用这些既定的方法为读者提供了一个参考框架。三位研究人员的参与避免了基于单一解释的结论。通过对结果、发现及其影响的讨论，其他研究人员对分析的每一步都进行了修正。我们没有采用任何理论对研究进行预先构想。
6.2 Bias and rigour 6.2 偏差与严谨
The issues of bias and rigour may be found in research involving people observation, such as ethnographic studies. To mitigate such issues, we first sought to establish a prolonged involvement in the fieldwork by keeping close contact with the agile team members and other collaborators for three months. The development of a trusting relationship helped us to collect data from different perspectives and also observe the team work in different ceremonies, meetings and daily activities. We also had access to documents used by the team. The significant amount of gathered data supported data triangulation which gave us a better confidence in our interpretation. In addition, debriefing sessions were regulary conducted where the data and its interpretation were discussed between all in order to limit any influence of individual opinion. And we conducted regular member checking meetings with the SM to verify whether our interpretations were correct. 在涉及人员观察的研究（如人种学研究）中，可能会出现偏差和严谨性问题。为了减少这些问题，我们首先通过与敏捷团队成员和其他合作者保持长达三个月的密切联系，寻求建立长期参与实地工作的关系。信任关系的建立有助于我们从不同角度收集数据，并观察团队在不同仪式、会议和日常活动中的工作。我们还可以查阅团队使用的文件。收集到的大量数据为数据三角测量提供了支持，使我们对自己的解释更有信心。此外，我们还定期举行汇报会，让所有人讨论数据及其解释，以限制个人意见的影响。我们还定期与工作人员-管理层举行成员核查会议，以核实我们的解释是否正确。
Reliability issues concern the methods and practices used to produce consistent results. In our study, we followed a set of procedures to guarantee data integrity (i.e. audit trail). We maintained a backup of all the 可靠性问题涉及到产生一致结果的方法和实践。在我们的研究中，我们遵循了一套程序来保证数据的完整性（即审计跟踪）。我们备份了所有
audio recordings, photographs, notes in digital format and documents in an external hard drive. After each observation session or interview, the first author listened to the audio recordings and analysed the photographs, 录音、照片、数字格式的笔记和外置硬盘中的文件。每次观察或访谈结束后，第一作者都会聆听录音并分析照片、
documents and the hand-written notes to create a memo document containing the initial data interpretation. 将文件和手写笔记合并，形成一份包含初步数据解读的备忘录文件。
6.3 Generalizability in flexible designs 6.3 灵活设计的通用性
Internal generalizability refers to the generalizability of conclusions within the setting studied; the studied team represented one instance of several teams working on the same project who undertook similar activities using the same process. We believe that the results could be extend to other teams of the same organisation. 内部可推广性是指结论在所研究的环境中的可推广性；所研究的团队是在同一项目中开展类似活动的多个团队中的一个，他们使用相同的流程。我们相信，研究结果可以推广到同一组织的其他团队。
For external generalizability, there could be a limitation by focusing on one agile team. However, we compared the key results regarding artefacts and UX information with others' published findings. The consistency of our results with the ones presented in other studies gives us confidence that our findings are applicable more widely. The tools and artefacts adopted by the team are commonly used in other settings, and the team's product is a version of Moodle, a tool used by thousands of educational institutions worldwide. Detailed descriptions of team work are provided to allow others to explore whether the findings are applicable to another team. 就对外推广性而言，专注于一个敏捷团队可能存在局限性。不过，我们将有关人工制品和用户体验信息的主要结果与其他已发表的研究结果进行了比较。我们的研究结果与其他研究结果的一致性使我们相信，我们的研究结果具有更广泛的适用性。团队采用的工具和人工制品在其他环境中也很常用，团队的产品是 Moodle 的一个版本，而 Moodle 是全球数千家教育机构使用的一种工具。我们提供了团队工作的详细描述，以便其他人探讨这些发现是否适用于其他团队。
7. Conclusions 7.结论
In this paper, we have presented the results of an ethnographic study to understand the collaborative activities of an agile software development team with a specific focus on UX information. The distributed cognition framework for small teams (DiCoT) guided us in data collection and analysis. To examine the type of UX information available in the team's workplace, we drew on two complementary models of UX: Garrett's framework and Hassenzahl's content-oriented model. We have not found any other reported study that combines these analytical lenses. Although this study focused only on one team, the findings resonate with reported studies of other teams in different contexts, which provides confidence that aspects of our findings and the recommendations arising from them will be useful to others. 本文介绍了一项人种学研究的结果，该研究旨在了解一个敏捷软件开发团队的协作活动，特别关注用户体验信息。小型团队的分布式认知框架（DiCoT）为我们的数据收集和分析提供了指导。为了研究团队工作场所可用的用户体验信息类型，我们借鉴了两个互补的用户体验模型：加勒特的框架和哈森扎尔的内容导向模型。我们还没有发现任何其他将这些分析视角结合起来的研究报告。虽然这项研究只针对一个团队，但研究结果与其他团队在不同背景下的研究报告产生了共鸣，这让我们相信，我们的研究结果和由此提出的建议对其他团队也会有用。
The study results in four main conclusions: 研究得出了四个主要结论：
Agile team members are largely passive receivers of UX information and commonly have no active role in its creation. This reduces the teams' engagement with the information and may affect their shared understanding of ; a lack of engagement in UX discussions may also compromise technical qualities of the system. 敏捷团队成员大多是用户体验信息的被动接收者，通常不会积极参与信息的创建。这降低了团队对信息的参与度，并可能影响他们对 的共同理解；缺乏对用户体验讨论的参与也可能影响系统的技术质量。
The commonly-used agile artefacts of user stories and mock-ups capture concrete UX information relating to How the user interacts with the product, and functional specifications about (rather than the user perspective on) What the product will do. As these artefacts are central to an agile team's work, this may lead to an overemphasis within a team's cognitive system on user interaction rather 用户故事和模拟模型这些常用的敏捷工件捕捉的是与用户如何与产品交互相关的具体用户体验信息，以及关于（而不是从用户角度看）产品将做什么的功能规范。由于这些工件是敏捷团队工作的核心，这可能会导致团队的认知系统过分强调用户交互，而不是用户体验。
than user needs or goals. 而不是用户的需求或目标。
Information that focuses on the user perspective, relating to users' goals (Why) or What they want to do with the product, is not captured in artefacts and is communicated mostly in meetings and one-to-one verbal discussions. This results in multiple transformations of information which may lead to inconsistencies and misunderstandings of the users' perspective by the team, particularly if this information is not widely discussed. 以用户视角为重点的信息，与用户的目标（为什么）或他们想用产品做什么有关，并没有在人工制品中捕捉到，而主要是在会议和一对一口头讨论中交流。这就造成了信息的多重转换，可能导致团队对用户视角的不一致和误解，尤其是在这些信息没有得到广泛讨论的情况下。
Tracking UX information through the cognitive system supporting the studied team was complex and time-consuming, requiring cognitive effort to complete. This was mainly due to the structure of UX information within the key information buffer TFS, which is widely adopted by agile teams. This complexity may affect productivity and result in agile team members having only a partial understanding of the product's UX. 通过支持所研究团队的认知系统跟踪用户体验信息既复杂又耗时，需要付出认知努力才能完成。这主要是由于敏捷团队广泛采用的关键信息缓冲器 TFS 中的用户体验信息结构造成的。这种复杂性可能会影响工作效率，导致敏捷团队成员只能部分了解产品的用户体验。
Taken together, these findings indicate a potential communication breakdown in the cognitive system that supports UX activities, and we suggest three areas which would benefit from improvement: making the user perspective, specifically the Why and What of UX information, more explicit and visible to team members; increasing the level of engagement of team members with UX information; and, decreasing the complexity for team members to identify, collate and hence track UX information. To address these areas we recommend the use of a UX informative workspace to promote better understanding of the users' point of view, and engagement with and visibility of Why and What UX information; more active attempts to communicate the users' perspective of What and Why to team members; and development of guidelines for clear organisation of UX information in software development environments such as TFS. 总之，这些发现表明，在支持用户体验活动的认知系统中存在潜在的沟通障碍，我们建议从以下三个方面加以改进：使用户视角，特别是用户体验信息的 "为什么 "和 "是什么 "更加明确，并使团队成员更加清楚；提高团队成员对用户体验信息的参与程度；降低团队成员识别、整理和跟踪用户体验信息的复杂性。为了解决这些问题，我们建议使用用户体验信息工作区，以促进更好地理解用户的观点，以及用户体验信息 "为什么 "和 "是什么 "的参与度和可见度；更积极地尝试向团队成员传达用户对 "是什么 "和 "为什么 "的观点；以及制定在软件开发环境（如 TFS）中明确组织用户体验信息的指导原则。
Potential future work in this area includes developing a more sophisticated model of UX information, e.g. by synthesising Hassenzahl's model and Garrett's framework; implementing the recommendations and evaluating the results; and investigating further the analysis of virtual artefacts and online development environments using distributed cognition principles. Work is increasingly conducted within a virtual environment rather than a physical one, and analytical frameworks need to adapt to take this into account. 该领域未来可能开展的工作包括：通过综合哈森扎尔的模型和加勒特的框架，开发更复杂的用户体验信息模型；实施建议并评估结果；利用分布式认知原则进一步研究虚拟人工制品和在线开发环境的分析。工作越来越多地在虚拟环境而不是物理环境中进行，因此分析框架需要加以调整，以考虑到这一点。
8. Acknowledgments 8.致谢
The authors thank our collaborators for their participation in the study. We also acknowledge the financial support from grant#2017/03397-0, São Paulo Research Foundation (FAPESP); grant 313312/2019-2 (CNPq); and Agile Business Consortium, Agile Research Network. 作者感谢我们的合作者参与本研究。我们还感谢圣保罗研究基金会（FAPESP）赠款#2017/03397-0、CNPq赠款313312/2019-2以及敏捷研究网络敏捷商业联盟提供的资金支持。
References 参考资料
Abdullah, N.N.B., Sharp, H., Honiden, S., 2010. Communication in context: A stimulus-response account of agile team interactions, in: Sillitti, A., Martin, A., Wang, X., Whitworth, E. (Eds.), Agile Processes in Software Engineering and Extreme Programming, Springer Berlin Heidelberg, Berlin, Heidelberg. pp. 166-171. Abdullah, N.N.B., Sharp, H., Honiden, S., 2010.Communication in context：A stimulus-response account of agile team interactions, in：Sillitti, A., Martin, A., Wang, X., Whitworth, E. (Eds.), Agile Processes in Software Engineering and Extreme Programming, Springer Berlin Heidelberg, Berlin, Heidelberg. pp.
Abelein, U.; Paech, B., 2015. Understanding the Influence of User Participation and Involvement on System Success - a Systematic Mapping Study. Empirical Software Engineering, vol. 20, pp. 28-81. Abelein, U.; Paech, B., 2015.了解用户参与和介入对系统成功的影响--系统映射研究》，《实证软件工程》，第 20 卷，第 28-81 页。实证软件工程》，第 20 卷，第 28-81 页。
Akman, S., Ozmut, M., Aydın, B., Gokturk, S., 2016. Experience report: implementing requirement traceability throughout the software development life cycle. Journal of Software: Evolution and Process, vol 28, n. 11, pp. 950-954. Akman, S., Ozmut, M., Aydın, B., Gokturk, S., 2016.经验报告：在整个软件开发生命周期中实施需求可追溯性。软件期刊：Evolution and Process, vol 28, n. 11, pp.
Ardito, C., Buono, P., Caivano, D., Costabile, M.F., Lanzilotti, R., 2014. Investigating and promoting UX practice in industry: An experimental study. International Journal of Human-Computer Studies, vol 72, n. 6, pp. 542-551. Ardito, C., Buono, P., Caivano, D., Costabile, M.F., Lanzilotti, R., 2014.在行业中调查和推广用户体验实践：一项实验研究。国际人机研究杂志》，第 72 卷，第 6 期，第 542-551 页。
Bjarnason, E., Sharp, H., 2017. The role of distances in requirements communication: a case study. Requirements Engineering, vol 22, pp. 1-26. Bjarnason, E., Sharp, H., 2017.距离在需求沟通中的作用：案例研究》。需求工程》，第 22 卷，第 1-26 页。
Beyer, H., Holtzblatt, K., 1998. Contextual Design. Morgan Kaufmann, San Francisco, CA. Beyer, H., Holtzblatt, K., 1998.Contextual Design.摩根考夫曼，加利福尼亚州旧金山。
Bordin, S., Angeli, A.D., 2016. Focal points for a more user-centred agile development. In: Sharp, H., Hall, T. (Eds.), Agile Processes, in Software Engineering, and Extreme Programming, Springer International Publishing, pp. 3-15. Bordin, S., Angeli, A.D., 2016.以用户为中心的敏捷开发焦点。In. Sharp, H., Hall, T. (Eds.), Agile Process：Sharp, H., Hall, T. (Eds.), Agile Processes, in Software Engineering, and Extreme Programming, Springer International Publishing, pp.
Brhel, M., Meth, H., Maedche, A., Werder, K., 2015. Exploring principles of user-centered agile software development: A literature review. Information and Software Technology, vol 61, n. C, pp. 163 - 181. Brhel, M., Meth, H., Maedche, A., Werder, K., 2015.探索以用户为中心的敏捷软件开发原则：文献综述。信息与软件技术》，第 61 卷，第 C 期，第 163 - 181 页。
Brown, J.M., Lindgaard, G., Biddle, R., 2011. Collaborative events and shared artefacts: Agile interaction designers and developers working toward common aims, In: Proceedings of the 2011 Agile Conference, pp. 87-96. Brown, J.M., Lindgaard, G., Biddle, R., 2011.协作事件与共享人工制品：Agile interaction designer and developers working towards common aims, In：2011 敏捷大会论文集》，第 87-96 页。
Buchan, J., 2014. An Empirical Cognitive Model of the Development of Shared Understanding of Requirements. Communications in Computer and Information Science, vol 432 CCIS, pp. 165-179. Buchan, J., 2014.共同理解需求发展的经验认知模型》。计算机与信息科学通讯》，第 432 卷 CCIS，第 165-179 页。
Cajander, Å., Larusdottir, M., Gulliksen, J., 2013. Existing but Not Explicit - The User Perspective in Scrum Projects in Practice. In: Kotzé P., Marsden G., Lindgaard G., Wesson J., Winckler M. (eds) Human-Computer Interaction INTERACT 2013. INTERACT 2013. Lecture Notes in Computer Science, vol 8119. Springer, Berlin, Heidelberg. Cajander, Å., Larusdottir, M., Gulliksen, J., 2013.Existing but Not Explicit - The User Perspective in Scrum Projects in Practice.In：Kotzé P., Marsden G., Lindgaard G., Wesson J., Winckler M. (eds) Human-Computer Interaction INTERACT 2013.INTERACT 2013.计算机科学讲座笔记》，第 8119 卷。Springer, Berlin, Heidelberg.
Chamberlain, S., Sharp, H., Maiden, N., 2006. Towards a Framework for Integrating Agile Development and User-Centred Design. In: Abrahamsson P., Marchesi M., Succi G. (eds) Extreme Programming and Agile Processes in Software Engineering. XP 2006. Lecture Notes in Computer Science, vol 4044. Springer, Berlin, Heidelberg. Chamberlain, S., Sharp, H., Maiden, N., 2006.Towards a Framework for Integrating Agile Development and User-Centred Design.In：Abrahamsson P., Marchesi M., Succi G. (eds) Extreme Programming and Agile Processes in Software Engineering.XP 2006。计算机科学讲座笔记》，第 4044 卷。Springer, Berlin, Heidelberg.
Choma, J., Zaina, L.A.M., Beraldo, D., 2016. UserX story: Incorporating UX aspects into user stories elaboration, in: Kurosu, M. (Ed.), Human-Computer Interaction. Theory, Design, Development and Practice, Springer International Publishing. pp. 131-140. Choma, J., Zaina, L.A.M., Beraldo, D., 2016.UserX story：将用户体验方面纳入用户故事阐述》，Kurosu, M. (Ed.), Human-Computer Interaction：Kurosu, M. (Ed.), Human-Computer Interaction.理论、设计、开发与实践》，施普林格国际出版公司，第 131-140 页。
Cohn, M., 2009. User stories applied: for agile software development. Pearson Education, Inc. Boston, MA. Cohn, M., 2009.用户故事应用：敏捷软件开发》。Pearson Education, Inc.波士顿，马萨诸塞州。
Deshpande, A., Sharp, H., Barroca, L., Gregory, P., 2016. Remote Working and Collaboration in Agile Teams. In: Deshpande, A., Sharp, H., Barroca, L., Gregory, P., 2016.敏捷团队中的远程工作与协作》。In：
Proceedings of the International Conference on Information Systems - Digital Innovation at the Crossroads, pp. 11-14 Dublin, Ireland. 信息系统国际会议论文集--十字路口的数字创新》，第 11-14 页，爱尔兰都柏林。
Ferreira, J., Sharp, H., Robinson, H., 2012. Agile development and user experi- ence design integration as an ongoing achievement in practice, in: 2012 Agile Conference, pp. 11-20. Ferreira, J., Sharp, H., Robinson, H., 2012.敏捷开发与用户体验设计整合作为实践中的一项持续成就》，《2012 年敏捷大会》，第 11-20 页：2012 Agile Conference, pp.
Fox, D., Sillito, J., Maurer, F., 2008. Agile methods and user-centered design: How these two methodologies are being successfully integrated in industry, in: Agile 2008 Conference, pp. 63-72. Fox, D., Sillito, J., Maurer, F., 2008.敏捷方法和以用户为中心的设计：这两种方法是如何在行业中成功融合的？Agile 2008 Conference, pp.
Furniss, D., Blandford, A., 2006. Understanding emergency medical dispatch in terms of distributed cognition: A case study. Ergonomics, vol 49, pp. 1174-1203. Furniss, D., Blandford, A., 2006.从分布式认知角度理解紧急医疗调度：案例研究。人体工程学》，第 49 卷，第 1174-1203 页。
Garcia, A., da Silva T. S., Selbach Silveira, M., 2017. Artifacts for agile user-centered design: A systematic mapping. In: Proceedings of the 50th Hawaii International Conference on System Sciences. Garcia, A., da Silva T. S., Selbach Silveira, M., 2017.敏捷用户中心设计的人工制品：系统图谱。In：第 50 届夏威夷系统科学国际会议论文集》。
Garcia A., da Silva T.S., Silveira M.S., 2019. Artifact-Facilitated Communication in Agile User-Centered Design. In: Kruchten P., Fraser S., Coallier F. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2019. Lecture Notes in Business Information Processing, vol 355. Springer, Cham. Garcia A., da Silva T.S., Silveira M.S., 2019.以用户为中心的敏捷设计中的人工制品辅助交流》。In：Kruchten P., Fraser S., Coallier F. (eds) Agile Processes in Software Engineering and Extreme Programming.XP 2019。商业信息处理讲座笔记》，第 355 卷。Springer, Cham.
Garrett, J.J., 2010. The Elements of User Experience: User-Centered Design for the Web and Beyond. 2nd ed., New Riders Publishing, Thousand Oaks, CA, USA. Garrett, J.J., 2010.The Elements of User Experience：The Elements of User Experience: User-Centered Design for the Web and Beyond.第 2 版，新骑士出版社，美国加利福尼亚州千橡市。
Gonzalez-Torres, A., Garc1a-Penãlvo, F.J., Theron, R., 2013. Human-computer interaction in evolutionary visual software analytics. Computers in Human Behavior, vol 29, pp. 486 - 495. Gonzalez-Torres, A., Garc1a-Penãlvo, F.J., Theron, R., 2013.进化视觉软件分析中的人机交互。人类行为计算机》，第 29 卷，第 486-495 页。
Gray, C.M., 2016. "It's more of a mindset than a method": UX practitioners' conception of design methods. In: Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems, ACM, New York, NY, USA. pp. 4044-4055. Gray, C.M., 2016."与其说是一种方法，不如说是一种心态"：用户体验从业者对设计方法的概念。In：pp.4044-4055.
Hassenzahl, M., 2010. Experience design: technology for all the right reasons. Morgan Claypool, San Francisco. Hassenzahl, M., 2010.Experience Design: Technology for all the right reasons.摩根克莱普尔公司，旧金山。
Hassenzahl M.,2018. The Thing and I (Summer of '17 Remix). In: Blythe M., Monk A. (eds) Funology 2. HumanComputer Interaction Series. Springer, Cham. Hassenzahl M.，2018.The Thing and I (Summer of '17 Remix).Blythe M., Monk A. (eds) Funology 2：Blythe M., Monk A. (eds) Funology 2. HumanComputer Interaction Series.Springer, Cham.
Hoadley, C.M., Kilner, P.G., 2005. Using Technology to Transform Communities of Practice into Knowledge-Building Communities, SIGGROUP Bulletin, vol 25, n. 1, pp. 31-40. Hoadley, C.M., Kilner, P.G., 2005.Using Technology to Transform Communities of Practice into Knowledge-Building Communities, SIGGROUP Bulletin, vol 25, n. 1, pp.
Hollan, J., Hutchins, E., Kirsh, D., 2000. Distributed cognition: Toward a new foundation for human-computer interaction research. ACM Transactions on Computer-Human Interaction, vol 7, n. 2, pp. 174-196. Hollan, J., Hutchins, E., Kirsh, D., 2000.Distributed cognition：Toward a new foundation for human-computer interaction research.ACM Transactions on Computer-Human Interaction, vol 7, n. 2, pp.
Hutchins, E., 1995. Cognition in the wild. A Bradford Book. Hutchins, E., 1995.野外认知》。布拉德福德之书。
Jurca, G., Hellmann, T.D., Maurer, F., 2014. Integrating agile and user-centered design: A systematic mapping and review of evaluation and validation studies of Agile-UX, In: Proceedings of the 2014 Agile Conference, pp. 24-32. Jurca, G., Hellmann, T.D., Maurer, F., 2014.敏捷与以用户为中心的设计融合：敏捷-用户体验评估与验证研究的系统映射与回顾》，《2014 年敏捷大会论文集》，第 24-32 页：2014 敏捷大会论文集》，第 24-32 页。
Kashfi, P., Nilsson, A., Feldt, R., 2017. Integrating user experience practices into software development processes: implications of the UX characteristics. PeerJ Computer Science 3:e130. Kashfi, P., Nilsson, A., Feldt, R., 2017.将用户体验实践融入软件开发流程：用户体验特征的意义》。PeerJ Computer Science 3:e130.
Kollman, J., Sharp, H. and Blandford, A. (2009) 'The role of user experience practitioners on agile project' in Proceedings
of Agile 2009 2009 年敏捷
Kuusinen, K., 2015. Task allocation between UX specialists and developers in agile software development projects, in: Abascal, J., Barbosa, S., Fetter, M., Gross, T., Palanque, P., Winckler, M. (Eds.), Human-Computer InteractionINTERACT 2015, Springer International Publishing. Kuusinen, K., 2015.敏捷软件开发项目中用户体验专家与开发人员之间的任务分配》，Abascal, J., Barbosa, S., Fetter, M., Gross, T., Palanque, P., Winckler, M. (Eds.)：Abascal, J., Barbosa, S., Fetter, M., Gross, T., Palanque, P., Winckler, M. (Eds.), Human-Computer InteractionINTERACT 2015, Springer International Publishing.
Lanubile, F., Calefato, F., Ebert, C., 2013. Group awareness in global software engineering. IEEE Software, vol 30, pp. . Lanubile, F., Calefato, F., Ebert, C., 2013.全球软件工程中的群体意识。IEEE Software, vol 30, pp. .
Larusdottir, M., Gulliksen, J., Cajander, A., 2017. A license to kill - Improving UCSD in Agile development. Journal of Systems and Software, vol 123, pp. 214-222. Larusdottir, M., Gulliksen, J., Cajander, A., 2017.杀人许可证--在敏捷开发中改进 UCSD。系统与软件期刊》，第 123 卷，第 214-222 页。
Liskin, O., 2015. How Artifacts Support and Impede Requirements Communication, In: Proceeding of the 21st International Working Conference, REFSQ 2015, Essen, Germany, March 23-26, pp. 132-147. Liskin, O., 2015.How Artifacts Support and Impede Requirements Communication, In：Proceeding of the 21st International Working Conference, REFSQ 2015, Essen, Germany, March 23-26, pp.
Liskin, O., Schneider, K., Fagerholm, F., Munch, J., 2014. Understanding the role of requirements artifacts in Kanban. In: Proceedings of the 7th International Workshop on Cooperative and Human Aspects of Software Engineering, ACM, New York, NY, USA. pp. 56-63. Liskin, O., Schneider, K., Fagerholm, F., Munch, J., 2014.理解需求工件在看板中的作用。In：第 7 届软件工程合作与人性化国际研讨会论文集》，ACM，美国纽约，第 56-63 页。
Mangalaraj, G., Nerur, S., Mahapatra, R., Price, K.H., 2014. Distributed cognition in software design: An experimental investigation of the role of design patterns and collaboration. MIS Q, vol 38, pp. 249-274. Mangalaraj, G., Nerur, S., Mahapatra, R., Price, K.H., 2014.软件设计中的分布式认知：设计模式与协作作用的实验研究》。MIS Q》，第 38 卷，第 249-274 页。
Matta, M., Marchesi, M., 2015. Understanding approval rating of agile project management tools using twitter, in: 2015 10th International Joint Conference on Software Technologies (ICSOFT), pp. 1-6. Matta, M., Marchesi, M., 2015.使用 twitter 理解敏捷项目管理工具的认可度，in：2015 第 10 届国际软件技术联合会议（ICSOFT），第 1-6 页。
McInerney, P., 2017. UX in agile projects: Taking stock after 12 years. Interactions, vol 24, pp. 58-61. McInerney, P., 2017.敏捷项目中的用户体验：12 年后的总结》。互动》，第 24 卷，第 58-61 页。
Paredes, J., Anslow, C., Maurer, F., 2014. Information visualization for agile software development. In: Proceedings of the 2014 Second IEEE Working Conference on Software Visualization, pp. 157-166. Paredes, J., Anslow, C., Maurer, F., 2014.敏捷软件开发的信息可视化。In：2014 年第二届 IEEE 软件可视化工作会议论文集》，第 157-166 页。
Plonka, L.; Sharp, H.; Gregory, P., Taylor, K., 2014. UX design in agile: a DSDM case study. In: Cantone G., Marchesi M. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2014. Lecture Notes in Business Information Processing, vol 179. Springer, Cham. Plonka, L.; Sharp, H.; Gregory, P., Taylor, K., 2014.敏捷中的用户体验设计：DSDM 案例研究。In：Cantone G., Marchesi M. (eds) Agile Processes in Software Engineering and Extreme Programming.XP 2014。商业信息处理讲座笔记》，第 179 卷。Springer, Cham.
Robson, C.; McCartan, K., 2016. Real world research: a resource for users of social research methods in applied settings, 4th edition, Wiley Robson, C.; McCartan, K., 2016.真实世界研究：应用环境中社会研究方法用户的资源》，第 4 版，Wiley 出版社。
Rubin, K.S., 2012. Essential Scrum: A Practical Guide to the Most Popular Agile Process. 1st ed., Addison-Wesley Professional. Rubin, K.S., 2012.Essential Scrum：最受欢迎的敏捷流程实用指南》。第 1 版，Addison-Wesley Professional 出版社。
Sach, R., 2013. The Impact of Feedback on the Motivation of Software Engineers. PhD thesis. The Open University. Sach, R., 2013.反馈对软件工程师积极性的影响》。博士论文。开放大学。
Salah, D., Paige, R.F., Cairns, P., 2014. A systematic literature review for agile development processes and user centred design integration. In: Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering, pp. 5:1-5:10, ACM, New York, NY, USA. Salah, D., Paige, R.F., Cairns, P., 2014.敏捷开发流程与用户中心设计整合的系统性文献综述。In：第 18 届软件工程评估与评价国际会议论文集》，第 5:1-5:10 页，ACM，美国纽约。
Scaife, M., Rogers, Y., 1996. External cognition: How do graphical representations work?. International Journal of Human Scaife, M., Rogers, Y., 1996.外部认知：How do graphical representation work?.国际人类期刊
Computer Studies, vol 45, n. 2, pp. 185-213. 计算机研究》，第 45 卷第 2 期，第 185-213 页。
Schon, E. M., Thomaschewski, J., Escalona, M. J., 2017. Agile requirements engineering: A systematic literature review. Computer Standards Interfaces, vol 49, pp. 79 - 91. Schon, E. M., Thomaschewski, J., Escalona, M. J., 2017.敏捷需求工程：系统文献综述。计算机标准界面》，第 49 卷，第 79 - 91 页。
Sellberg, C., Lindblom, J., 2014. Comparing methods for workplace studies: a theoretical and empirical analysis. Cognition, Technology and Work, vol 16, n. 4, pp. 467-486. Sellberg, C., Lindblom, J., 2014.工作场所研究方法比较：理论与实证分析》。认知、技术与工作》，第 16 卷，第 4 期，第 467-486 页。
Sharp, H., Dittrich, Y., de Souza, C.R.B., 2016. The role of ethnographic studies in empirical software engineering. IEEE Transactions on Software Engineering, vol 42, n. 8, pp. 786-804. Sharp, H., Dittrich, Y., de Souza, C.R.B., 2016.人种学研究在实证软件工程中的作用》。IEEE Transactions on Software Engineering, vol 42, n. 8, pp.
Sharp, H., Giuffrida, R., Melnik, G., 2012. Information flow within a dispersed team: a distributed cognition perspective. In: Wohlin C. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2012. Lecture Notes in Business Information Processing, vol 111. Springer, Berlin, Heidelberg. Sharp, H., Giuffrida, R., Melnik, G., 2012.分散团队中的信息流：分布式认知视角。In：Wohlin C. (eds) Agile Processes in Software Engineering and Extreme Programming.XP 2012。商业信息处理讲座笔记》，第 111 卷。Springer, Berlin, Heidelberg.
Sharp, H., Robinson, H., 2008. Collaboration and Co-ordination in mature eXtreme Programming teams. International Journal of Human-Computer Studies, vol 66, n. 7, pp. 506-518. Sharp, H., Robinson, H., 2008.成熟 eXtreme 编程团队中的协作与协调。国际人机研究杂志》，第 66 卷，第 7 期，第 506-518 页。
Sharp H., Robinson H., 2006. A Distributed Cognition Account of Mature XP Teams. In: Abrahamsson P., Marchesi M., Succi G. (eds) Extreme Programming and Agile Processes in Software Engineering. XP 2006. Lecture Notes in Computer Science, vol 4044, pp. 1-10. Springer, Berlin, Heidelberg. Sharp H., Robinson H., 2006.A Distributed Cognition Account of Mature XP Teams.In：Abrahamsson P., Marchesi M., Succi G. (eds) Extreme Programming and Agile Processes in Software Engineering.XP 2006。计算机科学讲座笔记》，第 4044 卷，第 1-10 页。Springer, Berlin, Heidelberg.
da Silva, T.S., Martin, A., Maurer, F., Silveira, M., 2011. User-centered design and agile methods: A systematic review, In: Proceedings of the 2011 Agile Conference, pp. 77- 86 . da Silva, T.S., Martin, A., Maurer, F., Silveira, M., 2011.以用户为中心的设计和敏捷方法：A systematic review, In：2011 敏捷大会论文集》，第 77-86 页。
da Silva, T.S., Silveira, M.S., Maurer, F., Silveira, F.F., 2018. The evolution of agile UXD. Information and Software Technology, vol 102, pp. 1 - 5 . da Silva, T.S., Silveira, M.S., Maurer, F., Silveira, F.F., 2018.敏捷用户体验设计的演变。信息与软件技术》，第 102 卷，第 1 - 5 页。
Wale-Kolade, A., Nielsen, P.A., Päivärinta, T., 2013. Usability Work in Agile Systems Development Practice: A Systematic Review. In: Linger H., Fisher J., Barnden A., Barry C., Lang M., Schneider C. (eds) Building Sustainable Information Systems, pp. 569-582. Springer, Boston, MA Wale-Kolade, A., Nielsen, P.A., Päivärinta, T., 2013.敏捷系统开发实践中的可用性工作：系统回顾。In：Linger H., Fisher J., Barnden A., Barry C., Lang M., Schneider C. (eds) Building Sustainable Information Systems, pp.马萨诸塞州波士顿 Springer 出版社
Wright, P.C., Fields, R.E., Harrison, M.D., 2000. Analyzing Human-Computer Interaction as Distributed Cognition: The Resources Model. Human-Computer Interaction, vol 15, n. 1, pp. 1-41. Wright, P.C., Fields, R.E., Harrison, M.D., 2000.Analyzing Human-Computer Interaction as Distributed Cognition：资源模型》。Human-Computer Interaction, vol 15, n. 1, pp.
TFS is a Microsoft product that covers the entire product lifecycle, including source code, requirement and project management. TFS 是微软的一款产品，涵盖整个产品生命周期，包括源代码、需求和项目管理。
