Catálogo de publicaciones - libros

Our ability to improve decision making in software development hinges on understanding how decisions are made, and which approaches to decision making are better than others. However, as of yet there are few studies examining how software developers make decisions in software design, especially studies that place agile approaches in the context of decision making. In this paper, we present results of a multi-case study of design decision making in three software organizations of varying levels of agility. We show an agile organization produced a culture that supported communication and debate about alternatives to design decision more than 2 organizations of lesser agility.

In this paper we address how interaction design and agile development work together, with a focus on the issue of interaction design being done “up-front”, before software development begins. Our study method used interviews with interaction designers and software developers on several agile teams. We used the qualitative approach of grounded theory to code and interpret the results. Our interpretation includes appreciation for benefits seen for a certain amount of up-front interaction design, and benefits from some levels of interaction design continuing with the iterations of software development.

While British Telecom (BT) has been progressing the adoption of agile practices across teams for the last two years, the overall organizational transformation has been slow to emerge and a catalyst was needed. In November 2006, BT began running a series of one hundred person, one and a half day events called Joining the Dots 3, aimed at promoting the use of agile throughout the IT organization. The event’s practical approach of embedding learning through the use of videos and activities on agile planning, user stories, customer collaboration and iterative delivery into a large scale end-to-end simulation has proven to be both fun and an excellent learning tool. Simulation retrospectives inside the event echo the learning points and feedback forms have confirmed that BT may have succeeded in generating large scale buy-in to using agile practices across thousands of people in their delivery organization.

This paper describes a process initiative within IBM to make the Corporate Portal ( ibm.com ) development practices more responsive to changing customer needs and explains the bottlenecks that arose with application deployment when this agile approach was not initially extended throughout the wider solution delivery lifecycle. The paper details the simple process changes that were adopted to expand the agile philosophy beyond development.

Agile development and software reuse are both recognized as effective ways of improving time to market and quality in software engineering. However, they have traditionally been viewed as mutually exclusive technologies which are difficult if not impossible to use together. In this paper we show that, far from being incompatible, agile development and software reuse can be made to work together and, in fact, complement each other. The key is to tightly integrate reuse into the test-driven development cycles of agile methods and to use test cases - the agile measure of semantic acceptability - to influence the component search process. In this paper we discuss the issues involved in doing this in association with Extreme Programming, the most widely known agile development method, and Extreme Harvesting, a prototype technique for the test-driven harvesting of components from the Web. When combined in the appropriate way we believe they provide a good foundation for the fledgling concept of agile reuse.

Computer-supported environments for agile project planning are often limited by the capability of the hardware to support collaborative work. We present DAP, a tool developed to aid distributed and collocated teams in agile planning meetings. Designed with a multi-client architecture, it works on standard desktop computers and digital tables. Using digital tables, DAP emulates index card based planning without requiring team members to be in the same room.

Large software development projects are not agile by nature. Large projects are not easy to implement, they are even harder to implement using agile methodologies. Based on over seven years of experience building software systems using agile methodologies we found that large software projects require more practices than the usual used in small projects. In this paper, we will introduce a set of new and modified development practices, which will help developing a large agile project.

Agile software development processes emphasize team work in small groups as one of the features that contribute to high software quality and knowledge dispersion among developers. Research supports claims that agile methods also lead to higher motivation and job satisfaction among developers. Research in workplace psychology indicates that factors like autonomy, variety, significance, feedback, and ability to complete a whole task are significant factors to ensure satisfaction and motivation among workers. In this case study, we show, through the analysis of semi structured interviews with software developers and business representatives, that large teams continuously adapting the SCRUM methodology are able to ensure these empowering factors, and thus ensure a staff of motivated and satisfied software developers. The study presented is based on data from an agile project involving 70 people (including 30 developers) building a software product for the oil & gas industry.

This research explored aspects of agile teamwork initiatives associated with positive socio-psychological phenomena, with a focus on phenomena outside the scope of traditional management, organizational, and software engineering research. Agile teams were viewed as complex adaptive socio-technical systems. Qualitative grounded theory was used to explore the socio-psychological characteristics of agile teams under the umbrella research question: What is the experience of being in an agile software development team? Results included a deeper understanding of the link between agile practices and positive team outcomes such as motivation and cohesion.

Agile methodologies with their close collaboration principle remain in conflict with the present trends of developing software in geographically distributed teams. To resolve it, a suitable tool support for certain lightweight practices must be provided. Although systems of this kind are reported to exist, they do not meet the expectations. Presented paper proposes an iterative approach to developing discussed support. As a verification of the presented assumptions, a dedicated Distributed Pair Programmers Editor was developed and experimentally verified.