scispace - formally typeset
Search or ask a question

Showing papers on "User story published in 2002"


Journal ArticleDOI
TL;DR: In the traditional new product development process, manufacturers first explore user needs and then develop responsive products as discussed by the authors, and the traditional approach is coming under increasing strain as user needs change more rapidly, and as firms increasingly seek to serve "markets of one." Toolkits for user innovation is an emerging alternative approach in which manufacturers actually abandon the attempt to understand user needs in detail in favor of transferring needrelated aspects of product and service development to users.
Abstract: In the traditional new product development process, manufacturers first explore user needs and then develop responsive products. Developing an accurate understanding of user needs is not simple or fast or cheap however, and the traditional approach is coming under increasing strain as user needs change more rapidly, and as firms increasingly seek to serve "markets of one." Toolkits for user innovation is an emerging alternative approach in which manufacturers actually abandon the attempt to understand user needs in detail in favor of transferring need-related aspects of product and service development to users. Experience in fields where the toolkit approach has been pioneered show custom products being developed much more quickly and at a lower cost. In this paper we explore toolkits for user innovation and explain why and how they work.

1,098 citations


Book
01 Jul 2002
TL;DR: This book sets out to question Extreme Programming in an attempt to understand and explain the controversy that surrounds Extreme Programming, and is focused on identifying issues surrounding software development and discussing how Extreme Programming interacts with these issues.
Abstract: From the Book: Extreme Programming sounds great—can we do it without changing our process? When I first heard about Extreme Programming in May 1998 I could see that it was going to be controversial. It was immediately obvious from the wide range of reactions that were expressed to two talks given by Kent Beck and Ron Jeffries at a seminar on “Developing Software with Objects” in Oslo. (Hosted by Den Norske Dataforening on 13 May, 1998) Many developers seemed to be attracted to it, but others in the room challenged the ideas and concepts behind Extreme Programming. Personally my reactions were mixed. It sounded like it would be a fun approach to software development and it didn’t sound like it was applicable to the kinds of projects that I was involved in. Admittedly, my initial reservations were about how easy it would be to sell the approach, but as I inquired deeper into Extreme Programming I came to realize that there are fairly stringent preconditions for teams that wish to adopt and use XP. It seems to me that many of the reactions to Extreme Programming can be explained by the fit between these preconditions and the particular project circumstances that a person has experienced. This book sets out to question Extreme Programming in an attempt to understand and explain the controversy that surrounds Extreme Programming. My goal for this book is to allow you, the reader, to determine if Extreme Programming is applicable and appropriate for your projects, to investigate what lessons can be learned from Extreme Programming and to enable you to be more reflective about your software development practices. Before getting down to that I must firstexplain my biases. As a developer I am attracted towards the ideas behind XP, mainly because most of the developers I have talked to that have worked on XP projects have really enjoyed the experience. I am also a strong fan of XP style unit testing and have introduced JUnit (www.junit.org) to many project teams. Although I have never worked on a full XP project, I have worked in a team that initially claimed that it was going to be doing XP, but actually turned out to be doing something that was vaguely related to some of the XP practices. As much as is possible I have tried to present both sides of the debate surrounding Extreme Programming without getting into the continual flame-fest that discussions on usenet newsgroups and email lists often contain. I have written this book as a practical guide for four different audiences: people who are thinking of adopting Extreme Programming people who are resisting the idea of adopting Extreme Programming, people who are looking for alternatives to Extreme Programming people who are interested in improving their current software development process As a practical guide this book is focused on identifying issues surrounding software development and discussing how Extreme Programming interacts with these issues. As this is a practical guide, you will not find much in the way of detailed studies and experimental data. This book focuses on clarifying the issues so that you, the reader, can determine the fit between Extreme Programming and your specific circumstances. Adopting Extreme Programming All processes are situational. Software development is not a mechanical process and as such you will never be able to adopt a process without doing some adapting to fit with your circumstances and team. Before adopting Extreme Programming you need to have a deep understanding of the values that drive it so that the adaptations you make match the overall spirit of XP. This book looks back to the roots of XP to enable you to understand the underlying software development issues so that you can better assess how XP will fit your organization. This book will also expose you to alternate approaches that might be a better fit. Resisting Extreme Programming Extreme Programming is a different kind of software development process, it is one that many programmers actually want to use. All too often however this means that some programmers end up pushing the idea of adopting XP when for one reason or another it does not really fit the organization. This book provides the questions you need to ask to determine whether XP really does fit the needs and circumstances of your organization. Hopefully it will also allow you to identify the issues with your current process that caused XP to be raised as a potential alternative in the first place. Then, rather than shooting the messenger or dismissing the message, the book asks the question “What can we learn from XP?” Looking For Alternatives To Extreme Programming Extreme Programming is a great fit for some projects and organizations, but one size does not fit all. There are many other software development approaches, and with all of the exposure that Extreme Programming is getting, these alternatives are getting somewhat lost. Using an Agile Methodology does not necessarily mean using Extreme Programming. Questioning Extreme Programming attempts to uncover the issues that are driving the creation of new approaches to software development. By exposing these issues I hope to spur software developers and their managers to create alternative approaches that build on the strengths of Extreme Programming while incorporating the strengths of the other approaches. Improving Your Current Software Development Process Adopting a new software development process can be hard. The organization has to learn how to effectively apply the new process and there is the transition period when some projects are using the new process while the rest are still using the old process. Sometimes it just makes sense to retain your existing process and to try to improve it by dropping parts, changing parts and adding new parts. By continually asking the question “What can we learn from XP?” this book highlights different ideas that could potentially be applied within the context of a different process. The resulting hybrid will not be XP, but then again, that is not the goal. By adopting the Extreme Programming mindset of continually reflecting on, and tinkering with, the process, you open up the possibility of creating your own optimized process. Why You Should Read This Book The way that we develop software is changing. Yes, people have always claimed that the IT industry has been a real driver for change, but until recently that change has only really shown up in the hardware and software. The way that we develop software has been remarkably resistant to change. Indeed Watts S. Humphrey spoke for many methodologists in his article, “Why Don't They Practice What We Preach? ” when he said “One of the most intractable problems in software is getting engineers to use effective methods.” http://www.sei.cmu.edu/publications/articles/practice-preach/practice-preach.html Many proponents of Extreme Programming would claim that the problem is no longer intractable - lots of programmers would jump at the chance of using XP. Indeed many developers are very keen to experiment with and try out new ways of developing software. It seems as if developers are beginning to see that things have changed. Jim Highsmith probably summed this up best when he said “We must challenge our most fundamental assumptions about software development.” Highsmith, 2000, p13 Questioning Extreme Programming invites you to take up that challenge. Acknowledgments First I would like to thank Kent Beck, Ward Cunningham and Ron Jeffries for starting the conversation around eXtreme programming. If nothing else they have managed to make software development methodologies interesting again. As usual, the team at Addison-Wesley was extremely supportive and enthusiastic about this project–Ross Venables, Mike Hendrickson, et. al. My reviewers seemed particularly gleeful this time, and although one expressed regrets that the book is not the flame-fest material he hoped for, all helped me to clarify my thoughts about Extreme Programming–Alastair Handley, Andy Hunt, Dave Thomas, Greg Klafki, Jens Coldewey, Jim Highsmith, Kent Beck, Miroslav Novak, Ron Jeffries and Rudy Wrench.

107 citations


Patent
29 Mar 2002
TL;DR: In this paper, a method and apparatus for optimizing the navigation of lists or other hierarchies of alternatives, as presented to the user by electronic devices and computer networks, by automatically recommending the alternatives of the next list to be presented.
Abstract: A method and apparatus for optimizing the navigation of lists or other hierarchies of alternatives, as presented to the user by electronic devices and computer networks, by automatically recommending the alternatives of the next list to be presented. Each alternative is recommended on the basis of the importance of that alternative to the user, or to the operator of the service provided to the user, or to providers of applications that can be selected by the user. The optimization is based upon probabilities estimated by mathematical functions on several variables, statistics, and parameters, including but not limited to the user location, time and date, user's expressed personal preferences, service operators' and application providers' expressed commercial intentions, service operators' and application providers' expressed business rules, implied application relationships, personal information of the user, usage statistics of the user, usage statistics of the general public, and embedded parameters which refine a statistical model of the user's behavior, statistics and estimators based upon that model, and a business objective model of the revenue improvements of service operators using this invention. Such optimization reduces the efforts required of a user to select one item, out of a structure of lists of items, by reorganizing the structure so that the user is likely to use fewer keystrokes or spoken words to select an item of combined higher importance to the user, the service operator, and the application provider. The optimization is personalized to each user by presenting the lists and structures to each user in a way that is automatically adapted to the statistical and deterministic factors pertaining to that individual user, so that users of different personalities and preferences can see or hear differently organized lists from which to choose. The number of keystrokes, or spoken words, is further reduced by intelligent data sharing between applications to avoid requiring the user's reentry of the same data to one application that was already entered in another.

75 citations


Proceedings ArticleDOI
M.J. Rees1
04 Dec 2002
TL;DR: This paper surveys some of the tools that are being used and examines their suitability for the task using a set of requirements and produces a prototype user story software tool for Agile Software Development called DotStories.
Abstract: User stories form the heart of the Extreme Programming methodology planning game. In its turn, Extreme Programming is one of the supporting pillars of the wider agile software development process. The user stories form a set of central work products that determine the software development processes. In the spirit of Extreme Programming the production of user stories is kept as simple as possible. Traditionally, user stories are hand written on index cards as they are easy to store, display, rearrange and distribute to the co-located development team. However, virtually all other work products of an application development team are in electronic format, and agile software development is increasingly being adopted by teams working from remote locations. In these circumstances distributed development teams look to software solutions for creating and using user stories. This paper surveys some of the tools that are being used and examines their suitability for the task using a set of requirements. As a result of this investigation the author has produced a prototype user story software tool for Agile Software Development called DotStories. The paper concludes by discussing the features of DotStories and its how closely it can approach the ideal user story software tool. Indeed, the proposition that software tools can ever improve on index cards is considered in the light of experience to date.

58 citations


Book
01 Jan 2002
TL;DR: Built for Use as discussed by the authors is a book that integrates business strategy and user experience in an easy-to-read format, with case studies that analyze relevant issues, define relevant success metrics, and discuss strategic issues such as productivity enhancement and risk reduction.
Abstract: User experience is a new field that marries business strategy, technology, design and usability into the development of electronically-mediated customer experiences. The field is becoming increasingly important. Despite the recent collapse in the technology market, user experiences continue to impact success for businesses that deliver their products and services online. As more "dotcoms" fail, firms such as Amazon.com and Yahoo! that practice customer-centric design continue to prove that they have an edge that creates business value. The quality of the user experience will become even more critical to business success over the next years. With no seminal books available and no well-established methodologies, the industry needs a book that will deliver strategies for business-relevant, user-centric design, written in a tone for executives, managers and practitioners who need the knowledge, but don't have the time to read a dense, heavy tome. Based on the author's work as a MIT Media Lab-trained user experience strategist (and 14-year industry veteran) with many global Fortune 1000 firms and dotcoms, Built for Use will help readers rapidly become fluent in the language and best practices of user experience strategy and design, and understand how to: * Develop a user experience strategy that builds trust and loyalty among customers * Establish what customers expect online, define metrics for success and catalyze a team to deliver the experience * Gain insight into which parts of the process must be rigorous and which can be accelerated without compromising quality * Ensure that the customer experience will be valued and usable, now and in the future * Influence and change the culture of the enterprise to become "customer-centric" in the design process * Approach fixing user experiences that are broken and failing in the market Built for Use will be the first book to integrate business strategy and user experience in an easy-to-read format. Diagrams will relate business strategies to user experience mechanisms, showing what does and doesn't work for customers. Whenever possible, statistical data gathered from actual site usage for "before" and "after" case studies will show how better design actually resulted in measurable increase in effectiveness in the customer experience. Each chapter includes "Accelerators" allowing readers to understand what levers they can control and the resultant effects upon the online experience, at any stage of the life cycle. Strategic as well as tactical solutions are discussed in detail with case studies that analyze relevant issues, define relevant success metrics, and discuss strategic issues such as productivity enhancement and risk reduction. Like Crossing the Chasm, it quickly articulates the "why" and the "how to" information in a way that is not dense or overly academic, something which is common in many user interface design books. Interviews have been secured with customer experience strategy executives at the top eServices firms (Zefer, Digitas, etc) as well as client companies for Human Logic such as State Street Global Advisors, and will be used along with case studies from these firms.

41 citations


Book ChapterDOI
William Krebs1
TL;DR: By giving team members control of how extreme to be through a 'teaching survey', the team has started at a comfortable level of XP and has opened the door to future extremes.
Abstract: I want to turn the knobs to 10, but my job position doesn't allow me to dictate that my team do so. Even if it did, forcing XP may serve only to cause resentment and backlash. Though I've been learning XP for over a year, it's still new to the rest of our team, and we're used to our old habits. By giving team members control of how extreme to be through a 'teaching survey', the team has started at a comfortable level of XP and has opened the door to future extremes. We've used the survey to define, coach, and track our XP process and have increased our use of XP by 10% in three months.

39 citations


Book ChapterDOI
TL;DR: An approach is described that tries to overcome the XP constraint of co-location by introducing a process-support environment (called MILOS for Agile Software Engineering - MILOS ASE) that helps software development teams to maintain XP practices in a distributed setting.
Abstract: Extreme programming (XP) is arguably improving the productivity of small, co-located software development teams. In this paper, we described an approach that tries to overcome the XP constraint of co-location by introducing a process-support environment (called MILOS for Agile Software Engineering - MILOS ASE) that helps software development teams to maintain XP practices in a distributed setting. MILOS ASE supports project coordination using the planning game, user stories, information routing, team communication, and pair programming.

37 citations


Proceedings ArticleDOI
James Newkirk1
19 May 2002
TL;DR: This tutorial will establish the underpinnings of agile methodology and explain why you might want to try one, and see how XP uses a set of practices to build an effective software development team that produces quality software in a predictable and repeatable manner.
Abstract: Extreme Programming is one of the most discussed subjects in the software development community. But what makes XP extreme? And how does it fit into the New World of agile methodologies? This tutorial will establish the underpinnings of agile methodology and explain why you might want to try one. Then we will see how XP uses a set of practices to build an effective software development team that produces quality software in a predictable and repeatable manner.

36 citations


Proceedings Article
01 Jan 2002
TL;DR: This paper summarises XP, compares the two approaches, outlines the experience with XP, draws out some problems with classic XP and suggests some modifications based on Participatory Design.
Abstract: Extreme Programming (XP) is a lightweight software development methodology that has risen to prominence in the last few years. XP and Participatory Design are related in motivation and approach but complimentary in many ways. The authors believe that integrating some Participatory Design approaches into XP substantially improves XP and may even bring some advantages to Participatory Design. This paper summarises XP, compares the two approaches, outlines our experience with XP, draws out some problems with classic XP and suggests some modifications based on Participatory Design.

34 citations


Book ChapterDOI
TL;DR: Two approaches: eXtreme Programming (XP) and CMM Level 2 have been used in joined industry-academic software projects run at the Poznan University of Technology, and two approaches are compared on the basis of experimental data.
Abstract: Lightweight software development methodologies promise an easy way to deliver products of high quality without excessive cost. On the contrary, classical heavyweight processes are well-defined and proven, but require a lot of effort. Two approaches: eXtreme Programming (XP) and CMM Level 2 have been used in joined industry-academic software projects run at the Poznan University of Technology. Running concurrently those two software approaches allowed us to compare them on the basis of experimental data. After the projects were completed, major risk factors connected with both approaches have been collected and some improvements have been proposed.

33 citations


01 Jan 2002
TL;DR: The methodology and techniques used for the elicitation of user requirements as well as how these were in turn transformed into new design solutions are reported on.
Abstract: Who are the users of a cross-language retrieval system? Under what circumstances do they need to perform such multi-language searches? How will the task and the context of use affect successful interaction with the system? Answers to these questions were explored in a user study performed as part of the design stages of Clarity, a EU founded project on cross-language information retrieval. The findings resulted in a rethink of the planned user interface and a consequent expansion of the set of services offered. This paper reports on the methodology and techniques used for the elicitation of user requirements as well as how these were in turn transformed into new design solutions.

Book
02 Nov 2002
TL;DR: Sams Teach Yourself Extreme Programming in 24 Hours includes coverage on Extreme Programming, agile development, automated test frameworks (Junit, etc.), Automated Build, and Refactoring in a step-by-step approach.
Abstract: From the Publisher: Extreme Programming (XP) is a new lightweight software developing methodology. XP is the most popular of the "agile" development methodologies. Agile development is an integral part of technology movements in the software development world. XP has quickly gained in popularity over the last few years and is now becoming recognized by development shops from large consulting firms through small software houses. Some of the companies that are using XP include DaimlerChrysler, First Union National Bank, and Ford Motor Company. Sams Teach Yourself Extreme Programming in 24 Hours includes coverage on Extreme Programming, agile development, automated test frameworks (Junit, etc.), Automated Build (Ant), and Refactoring in a step-by-step approach. Author Biography: Stewart Baird has been involved in software development for over 15 years. He is a certified project manager (PMP) who has practical experience developing software solutions for the fast-changing world of e-business. He's a leading evagelist within KPMG Consulting for XP approaches and was instrumental in their implementation (for the New Zealand practice). He has spoken on XP in a number of public forums. Most recently he spoke at the NZ Computer Society and was the only speaker to have sold out both the main and subsequent catch-up events. He has led numerous development projects around the world and brings a pragmatic approach to his writing. He is also the creator of the BlipIt Web-based defect tracking tool.

Book ChapterDOI
29 Oct 2002
TL;DR: The aim of the paper is to present a modified version of XP that would be acceptable from the point of view of ISO 9000.
Abstract: The main drivers of the growing ICT market are software products. European Information Technology Observatory estimates, that in year 2002 the total value of ICT software products in Western Europe will be more than 70 billions Euro. Unfortunately very few people are satisfied with quality of the software products and processes. Software Process Improvement tools, like CMM and ISO 9000 were to cure this situation, but some people complain that they are too bureaucratic and inflexible. As a result new, so-called agile, methodologies appeared. One of them is Extreme Programming (XP) - a lightweight, change-oriented and customer-oriented approach to software development. Although XP proposes many interesting practices, it has some limitations. Moreover, it is not clear how to introduce XP to an organization certified to ISO 9001:2000. The aim of the paper is to present a modified version of XP that would be acceptable from the point of view of ISO 9000.

Reference EntryDOI
15 Jan 2002
TL;DR: The XP approach to software development is targeted at systems with vague and changing requirements, a short delivery schedule, and limited resources.
Abstract: eXtreme Programming (XP) is a lightweight software development methodology based on the widely recognized and effective paradigms of code inspections, iterative spiral development, integrated product development teams (i.e., full-time customer involvement), frequent builds, programmer teams (i.e., pair programming), design patterns, refactoring, coding standards, risk analysis, and regression testing. XP emerged from the object-oriented programming community. XP is “extreme” in the sense that it diverges from “traditional” software development methodologies in several ways. In particular, it discourages documentation and encourages a willingness to throw code away. The XP approach to software development is targeted at systems with vague and changing requirements, a short delivery schedule, and limited resources. XP is based on four “values” that are assumed to be embraced by those participating in the software development process: Communication; Simplicity; Feedback; and Courage. Keywords: extreme programming; lightweight software development methodology; changing requirements; communication; simplicity; feedback; courage

Proceedings ArticleDOI
07 Nov 2002
TL;DR: A new foundation for interactive storytelling that allows a mobile user to interact with a story that is context-aware and respond to the physical and social context of the user both on an individual and group level is presented.
Abstract: An interactive narrative is a story that is shaped by digital technology and that allows the dynamic presentation of scenes or sequences based on input from the user. In this paper we present a new foundation for interactive storytelling that allows a mobile user to interact with a story. The user is placed at the center of the story and the story comes to the user in transit. The behavior and actions of the user influence the scenes and sequences of the story the user experiences. The framework for this system is an ad-hoc network. Ad-hoc networks allow localized presentation of story elements to users who are in transit and able to receive story elements on a mobile device. Furthermore ad-hoc networks have the capability to be context-aware and respond to the physical and social context of the user both on an individual and group level. This mobile context-aware story form is a powerful format in the fields of education and entertainment. It allows the story to be connected with the surrounding environment and it allows the user to see cause and effect of individual and group behavior. In this paper we present an ad-hoc network story system and examine a case study of its use for a prototype mobile context-aware story.

Journal ArticleDOI
TL;DR: Extreme programming (XP) is a collection of highly disciplined practices that companies can either formally introduce into their existing process or use to supplement individual processes for project management, change management, requirements planning, and testing.
Abstract: Extreme programming (XP) has been making waves among application developers for good reason. Its 12 core processes emphasize the small and simple, which translates to fast, efficient code generation. XP is deliberately lightweight, dispensing with lengthy use-case specifications, requirements definitions, and extensive documentation. As such, it is not, nor was it designed to be, a full life cycle methodology. But neither is it hacking, as some of its critics maintain. Rather, it is a collection of highly disciplined practices that companies can either formally introduce into their existing process or use to supplement individual processes for project management, change management, requirements planning, and testing.

Book
01 Jan 2002
TL;DR: This book discusses how to get the most out of Extreme Programming/Agile Methods, and introduces Extreme Programming and Agile methods, as well as supporting Distributed Extreme Programming.
Abstract: Methods and Support Tools.- Designing Requirements: Incorporating Usage-Centered Design into an Agile SW Development Process.- Supporting Distributed Extreme Programming.- Using Ant to Solve Problems Posed by Frequent Deployments.- Supporting Adaptable Methodologies to Meet Evolving Project Needs.- Introducing Extreme Programming and Agile Methods.- Strategies for Introducing XP to New Client Sites.- Establishing an Agile Testing Team: Our Four Favorite "Mistakes".- Turning the Knobs: A Coaching Pattern for XP through Agile Metrics.- Experience Reports.- Agile Project Management Methods for ERP: How to Apply Agile Processes to Complex COTS Projects and Live to Tell about It.- Extreme Programming in a Research Environment.- Tailoring XP for Large System Mission Critical Software Development.- Testing.- Acceptance Testing HTML.- Probe Tests: A Strategy for Growing Automated Tests around Legacy Code.- An Informal Formal Method for Systematic JUnit Test Case Generation.- A Light in a Dark Place: Test-Driven Development with 3rd Party Packages.- Empirical Studies.- Agile Meets CMMI: Culture Clash or Common Cause?.- Circle of Life, Spiral of Death: Are XP Teams Following the Essential Practices?.- Tracking Test First Pair Programming - An Experiment.- How to Get the Most out of Extreme Programming/Agile Methods.- Empirical Findings in Agile Methods.- Pair Programming.- Exploring the Efficacy of Distributed Pair Programming.- Pair Programming: Addressing Key Process Areas of the People-CMM.- When Pairs Disagree, 1-2-3.- Educator's Symposium.- Triggers and Practice: How Extremes in Writing Relate to Creativity and Learning.- Extreme Teaching - An Agile Approach to Education.- Extreme Programming as a Teaching Process.- From the Student's Perspective.- Perceptions of Agile Practices: A Student Survey.- Tutorials.- XP in a Legacy Environment.- XP for a Day.- Accelerated Solution Centers - Implementing DSDM in the Real World.- Refactoring: Improving the Design of Existing Code.- The Agile Database.- Change Wizardry - Tools for Geeks.- Beyond the Customer: Agile Business Practices for XP.- XP Release Planning and User Stories.- Steering the Big Ship: Succeeding in Changing an Organization's Practices.- Scrum and Agile 101.- How to Be a Coach.- Sharpening the Axe for Test Driven Development.- Pair Programming: Experience the Difference.- How to Start an XP Project: The Initial Phase.- Effective Java Testing Strategies.- Test Drive for Testers: What, When, and How Testers Do for XP Teams.- Scaling Agile Processes: Agile Software Development in Large Projects.- Applying XP Tools to J2EE for the Extreme Programming Universe.- Workshops.- Distributed Pair Programming.- Agile Acceptance Testing.- XP Fest.- Empirical Evaluation of Agile Processes.- Panels.- Are Testers eXtinct? How Can Testers Contribute to XP Teams?.- XP - Beyond Limitations?.- Extreme Fishbowl.- Agile Experiences.

Book ChapterDOI
08 Apr 2002
TL;DR: This paper is an account of using an agile method, eXtreme Programming, to survive and manage rapid requirement changes without sacrificing quality.
Abstract: One problem of moving development at "Internet speed" is the volatility of requirements. Even in a supposedly stable project like that described here, requirements change as the client sees "targets of opportunity." That is one of the unintended side effects of having the client on-site frequently, although it does increase user satisfaction because they are not prevented from adding functionality. This paper is an account of using an agile method, eXtreme Programming, to survive and manage rapid requirement changes without sacrificing quality.