Catálogo de publicaciones - libros

This paper is believed to be the first documented account of a full adoption of lean by a software company. Lean techniques were devised by Toyota and other manufacturers over the last 50 years. The techniques are termed lean because they require less resource to produce more product and exceptional quality. Lean ideas have also been successful in service industries and product development. Applying lean to software has been advocated for over 10 years. Timberline, Inc started their lean initiative in Spring 2001 and this paper records their journey, results and lessons learned up to Fall 2003. This case study demonstrates that lean thinking can work successfully for software developers. It also indicates that the extensive lean literature is a valuable source of new ideas for software engineering.

Many have reported successful experiences using XP, but we have not yet seen many experiences adapting agile methodologies in developing countries such as Brazil. In a developing economy, embracing change is extremely necessary. This paper relates our experience successfully introducing XP in a start-up company in Brazil. We will cover our adaptations of XP practices and how cultural and economical aspects of the Brazilian society affected our adoption of the methodology. We will discuss how we managed to effectively coach a team that had little or no previous skill of the technologies and practices adopted. We will also cover some new practices that we introduced mid-project and some practices we believe emerged mostly because of Brazilian culture. The lessons we learned may be applicable in other developing countries.

Introducing Extreme Programming (XP) to an industrial software development team usually involves technical and professional aspects as well as social and organizational ones. The introducing of a new software development method in general and XP in particular into a software project team that operates in the army emphasizes and extends these issues. In this paper we present a process through which XP has been introduced into a 60-members software development project at the Israeli Air Force. Focus is placed on an XP workshop conducted with ten officers who worked at different teams of the project. Specifically, we present the principles according to which we facilitated the workshop, the workshop agenda and data regarding the way the participants perceive some of the XP practices. Recently, the first XP team in this project has started to work the XP way.

On January 14, 2004, two vice presidents met with a group of directors, project managers, and developers, and indicated their desire to embrace agile software development as “the way forward” in their organization. This was not the beginning of this company’s adoption of XP and Agile Methodologies, but rather the culmination of almost two and a half years of learning, experimentation, prototyping, and promotion. Making change “stick” in any large organization is problematic, and dramatically changing the way a risk-averse, highly-regulated company develops software requires more than just a successful pilot and a couple of months of coaching. This experience report documents the “agile journey” undertaken by one such corporation between 2001 and 2004. They began by outsourcing a small effort to an XP-proficient consulting firm, and proceeded to use agile techniques on a series of increasingly-significant efforts, allowing sufficient time for the new approach to gain acceptance. In retrospect, all parties involved now believe that the slow, gradual approach to XP adoption – building on incremental successes project by project – was the key to its success.

User stories in software engineering serve the purpose of discovering requirements and are used as units of system development. When applying stories in a project, two elements seem to be crucial: the ability to write coherent sequences of events and the ability to transform these sequences into code quickly and resourcefully. In this paper, these qualities are reflected in a notation that can be described as “stories with notions”. This notation separates the story’s sequence of events from the description of terms used in this sequence. Such a formal separation does not limit and rather enhances invention, at the same time rising the level of consistence, and facilitating translation into models of code. This translation maps domain notions into static code constructs (classes, interfaces) and also maps stories into dynamic sequences of messages. With such a mapping, programming becomes equivalent to skilled transformation of user stories, thus giving shorter development cycles.

Effectively evaluating the capability of a software development methodology has always been very difficult, owing to the number and variability of factors to control. Evaluating XP is by no way different under this respect. In this paper we present a simulation approach to evaluate the applicability and effectiveness of XP process, and the effects of some of its individual practices. Such approaches using simulation are increasing popular because they are inexpensive and flexible. Of course, they need to be calibrated with real data and complemented with empirical research.

The XP process has been modelled and a simulation executive has been written, enabling to simulate XP software development activities. The model follows an object-oriented approach, and has been implemented in Smalltalk language, following XP process itself. It is able to vary the usage level of some XP practices and to simulate how all the project entities evolve consequently.

The effective provision of security in an agile development requires a new approach: traditional security practices are bound to equally traditional development methods. However, there are concerns that security is difficult to build incrementally, and can prove prohibitively expensive to refactor. This paper describes how to grow security, organically, within an agile project, by using an incremental security architecture which evolves with the code. The architecture provides an essential bridge between system-wide security properties and implementation mechanisms, a focus for understanding security in the project, and a trigger for security refactoring. The paper also describes criteria that allow implementers to recognize when refactoring is needed, and a concrete example that contrasts incremental and ‘top-down’ architectures.

It is possible to apply Information Theory to the Software Development process – an approach I have dubbed ’Iterative Theory’. Focusing on the user requirements Iterative Theory is introduced and then used to quantify how the choice of development methodology affects the ’value at risk’ on a software project. The central theme is that end-user requirements cannot be described exactly resulting in an inherent uncertainty in the correctness of any specification. This uncertainty can only be removed by receiving feedback on working software. Iterative Theory, the application of Information Theory to the software development process, is certainly an area requiring further study.

One of the main dilemmas with which software development teams face is how to choose a software development method that suits the team as well as the organization. This article suggests a theory that may help in this process. Specifically, Extreme Programming (XP) is analyzed within the well known framework of the prisoner dilemma. We suggest that such an analysis may explain in what situations XP may fit for implementation and, when it is used, the way it may support software development processes.

Pair programming is one of the more controversial aspects of several Agile system development methods, in particular eXtreme Programming (XP). Various studies have assessed factors that either drive the success or suggest advantages (and disadvantages) of pair programming. In this exploratory study the literature on pair programming is examined and factors distilled. These factors are then compared and contrasted with those discovered in our recent Delphi study of pair programming. Gallis et al. (2003) have proposed an initial framework aimed at providing a comprehensive identification of the major factors impacting team programming situations including pair programming. However, this study demonstrates that the framework should be extended to include an additional category of factors that relate to organizational matters. These factors will be further refined, and used to develop and empirically evaluate a conceptual model of pair programming (success).