User story

About: User story is a research topic. Over the lifetime, 1078 publications have been published within this topic receiving 23717 citations.

The construction of the future user

Abstract: The creation of a user and identification of needs; user configuration is an essential element of the innovation process and not merely the final part of the process. The outcome of consumer configuration is a kind of manuscript according to which the consumer is assumed to act when he or she confronts a new commodity. Technology research refers to this manuscript of "correct consumption", prepared, for example, by means of scenarios, as a "script". What kinds of assumptions about user are there when building the concept for products of the future? What are the user motivations to adopt and use new technology? The emphasis in the constructive future studies which means that we see these manuscripts of the different users are important as the guideline to design and in that way as the final outcome of the product. The technological system, on its behalf, affects on the individual. It is not only a question of whether users or consumers can be divided into different segments by their relationship to technology, but also about new "versions of human beings" emerging as a result of the new technology. In the visions there are different motives to use the technology. Technology gives its user shelter from outside forces; thieves and natural disasters (intelligent home) and also a shelter from illnesses (self-monitoring devices). Technology helps its users in everyday tasks and drudgery. It is also a communication device which replaces other forms of communication and makes possible a more mobile way of life. It is also a transportation device, but more in mental than in physical way. Even though the diversity of the users/consumers is seen as important when thinking about the user's needs, the visions are quite homogenous. In the visions the users are seen as active, social and constantly looking for new stimulus. One may ask whether this is a appropriate way of looking at the user.

Coordinating User-Developer Efforts in Extreme Programming: A Control-Theoretic Approach

Abstract: Extreme programming (XP) calls for intense participation by users to ensure that systems are developed to meet current needs, yet be flexible enough to adapt to future needs [Beck, 2000]. In XP projects, it is crucial for developers to align their efforts with those of the users that are allocated to the project so that the goals of the development activity from the perspective of the organization are achieved. We consider an optimal control model of extreme programming where user and developer efforts (the control variables) are optimally chosen during the development period to maximize net system value (system value minus user and developer effort). Unlike most previous research, our problem incorporates both demand side (user value) and supply side (developer and user effort) considerations in software development.

A computer-based holistic approach to managing progress of distributed agile teams

Abstract: One of the co-ordination difficulties of remote agile teamwork is managing the progress of development. Several technical factors affect agile development progress; hence, their impact on progress needs to be explicitly identified and co-ordinated. These factors include source code versioning, unit testing (UT), acceptance testing (AT), continuous integration (CI), and releasing. These factors play a role in determining whether software produced for a user story (i.e. feature or use case) is ‘working software’ (i.e. the user story is complete) or not. One of the principles introduced by the Agile Manifesto is that working software is the primary measure of progress. In distributed agile teams, informal methods, such as video-conference meetings, can be used to raise the awareness of how the technical factors affect development progress. However, with infrequent communications, it is difficult to understand how the work of one team member at one site influences the work progress of another team member at a different site. Furthermore, formal methods, such as agile project management tools are widely used to support managing progress of distributed agile projects. However, these tools rely on team members’ perceptions in understanding change in progress. Identifying and co-ordinating the impact of technical factors on development progress are not considered. This thesis supports the effective management of progress by providing a computer-based holistic approach to managing development progress that aims to explicitly identify and co-ordinate the effects of the various technical factors on progress. The holistic approach requires analysis of how the technical factors cause change in progress. With each progress change event, the co-ordination support necessary to manage the event has been explicitly identified. The holistic approach also requires designing computer-based mechanisms that take into consideration the impact of technical factors on progress. A progress tracking system has been designed that keeps track of the impact of the technical factors by placing them under control of the tracking system. This has been achieved by integrating the versioning functionality into the progress tracking system and linking the UT tool, AT tool and CI tool with the progress tracking system. The approach has been evaluated through practical scenarios and has validated these through a research prototype. The result shows that the holistic approach is achievable and helps raise awareness of distributed agile teams regarding the change in the progress, as soon as it occurs. It overcomes the limitations of the informal and formal methods. Team members will no longer need to spend time determining how their change will impact the work of the other team members so that they can notify the affected members regarding the change. They will be provided with a system that helps them achieve this as they carry out their technical activities. In addition, they will not rely on static information about progress registered in a progress tracking system, but will be updated continuously with relevant information about progress changes occurring to their work.

Agile Testing: The Rules and Practices of Extreme Programming

Abstract: Its OK to be agile about your agile adoption. David Evans Introduction This appendix reviews the essential rules and practices of Extreme Programming (XP), focusing in more detail on the quality aspects of the method. The XP rules and practices are grouped into four sections: (1) planning, (2) designing, (3) coding, and (4) testing. It is notable that in virtually every description of the principles of XP you read, you will find that testing is covered last. In this appendix, testing is covered as the first topic. Testing Quality assurance (QA) is considered to be an essential aspect of XP. QA may be performed by a separate group, or it can be integrated into the development team itself. In either case, XP promotes the idea that the developers have a high degree of contact with the QA group; this is very much in line with the XP philosophy of closer communications between the stakeholders in a project. XP provides some excellent guidance on testing: XP encourages early and frequent testing. XP looks to make the process as efficient and effective as possible by promoting the use of test automation. XP demands that all code have associated tests, and that where code is changed that the tests be rerun (and/or modified where appropriate to reflect the changes). XP requires test design to be completed before coding has started, with all code having associated unit tests. There are just two types of test in XP: Unit tests written by the developers to test their code. These are white box tests [4], which rely on the knowledge of the code and its purpose. […]