Agile Development in Practice |
Current Work
In recent years, agile software development process models, such as Extreme Programming and SCRUM have become increasingly popular. Despite growing adoption by practitioners, there has been little academic study of the merits and impact of these process models. In this project, we seek to perform an empirical study of the state of agile software development in industrial practice. Previous research has used a combination of field studies and laboratory studies. We plan to use similar methods, although we will primarily be using surveys (interviews and questionnaires). We wish to observe and document how agile development is used in real world settings, compare how practice converges or diverges from theory, and consult practitioners in the development of new methods and tools. The research questions we aim to address are:
BackgroundAgile processes have been highly controversial, but very popular among practicing software engineers, especially among small teams building software that requires fast development and fast reaction to changes. Agile Processes are predicated on the ability to adapt to change, rather than avoiding change through up-front planning, specification, and design. One of the most popular Agile Process Models is Extreme Programming (XP.) XP was first introduced in 2000 by Kent Beck [1]. Its name comes from the concept of taking a good software development practice, for example, inspections, and pushing it to the logical extreme, to continue the example, Pair Programming. There are 12 key practices in XP and they function because they form an interrelated web of forces and dependencies. XP represents a significant departure from previous phased, plan-based approaches to software development, such as the Waterfall model, in terms of philosophy, emphasis, structure, and organization. Rather than having a requirements phase where all the system requirements are systematically collected at the start of the project, XP uses the key practices of User Story, Planning Game, and Onsite Customer. User Stories are descriptions of features or to-do items written with a motivation from the user's point of view [2]. The customer ranks the importance of various stories, while developers estimate the cost, or amount of resources required. During the Planning Game, customers, developers, and managers work together to select the stories that will be implemented in the next release. Additional details about the feature or to-do item are gathered from the Onsite Customer by the assigned developer as the User Story is implemented. In addition to eliminating phases by diffusing the work into key practices, the ordering of activities is different as well. After the stories are created and assigned, a developer begins work by writing unit test cases and then writes code to pass the tests. This practice is called Test-Driven Development and the use of a unit test framework in XP is just as important as using a revision control system. When implementing, developers use Simple Design, that is, they use the simplest design that will get the job done. Any shortcomings in the design are remedied later by Refactoring. XP has been highly controversial. Critics charge that it is merely an attempt to avoid documentation and metrics. However, it is very popular among practitioner. The planned research will not settle the controversy nor does it take sides in this debate. Instead, it seeks to understand how XP is use in real world setting including, including its merit and impact. We also aim to observe and compare how practices, such as planning game, converge or diverge from the theory.
References[1] Kent Beck, Extreme Programming Explained: Embrace Change (1st Edition): Addison-Wesley Professional, 1999. [2] Mike Cohn, User Stories Applied: For Agile Software Development: Addison-Wesley Professional, 2004
|