6 research outputs found

    Better, Not More Expensive, Faster? The Perceived Effects of Pair Programming in Survey Data

    Get PDF
    There are many different techniques used with agile software development methods. Some of these, such as common coding guidelines and test driven development, are widely adopted and there appears to be a consensus that they can be beneficial. Others, however, are more controversial, none more so perhaps than pair programming. This technique meets resistance both from developers, who do not always wish to program with another person, and from managers, who see the sharing of a workstation as a potential barrier to programmer productivity. Its supporters, however, claim that it can have many benefits, in particular improving software quality. In this paper we look at the outcomes of previous research into the effects of pair programming and analyse some survey data to see how practitioners perceive its potential benefits for project outcomes in terms of quality, productivity, stakeholder satisfaction and cost. We conclude that the survey data appears to reinforce many of the previous claims made for the benefits of pair programming, but also raises questions that need further investigation

    Programação em duplas: estado da arte

    Get PDF
    Resumo: Programação em Duplas (Pair Programming – PP) é uma prática colaborativa de desenvolvimento de software em que dois programadores trabalham ao mesmo tempo em um único computador e na mesma tarefa de programação. Foi relatado na literatura que o conhecimento sobre PP encontra-se disperso e desorganizado. Com o intuito de colocar um pouco de ordem a esse caos, o presente estudo realizou uma busca exaustiva de trabalhos sobre PP em algumas das bibliotecas digitais mais importantes do mundo em Ciência da Computação (Sociedade Brasileira de Computação, ACM, IEEE Explore, Springer, CiteSeer e ScienceDirect, entre outras) e no Google/Scholar. A partir da completa leitura dos trabalhos encontrados, procurou-se definir temas chave dentro da área descrevendo todos os estudos que se relacionam com cada tema. Os achados são interessantes e extensos – eles podem ser encontrados durante toda a leitura do presente artigo

    Veröffentlichungen und Vorträge 2004 der Mitglieder der Fakultät für Informatik

    Get PDF

    Towards understanding the value-creation in agile projects

    Get PDF
    In recent years, iterative and incremental approaches for software development appeared as an alternative to the traditional, waterfall-style development. The reason for this is the large number of software projects in the past that failed to deliver useful products within budget, and struggled with changing requirements and scope creep. Meanwhile it is a common sense understanding that not all projects are predictable from the beginning. Market uncertainty and a fast changing business environment drives changes during the development of a software product.\ud One of the key characteristics of any agile approach is its explicit focus on Business Value. Although any software development method aims at creating a product and thus creating value, in agile software projects the value creation for the clients represents the essence and defines the focus of the process. Thus, the agile development process is a value creation process.\ud The agile methods allow for frequent decisions about the requirements that will be considered for implementation during the short development cycles called iterations. In practice this decision-making is implemented by the process of requirements prioritization and re-prioritization, performed at the beginning of each iteration.\ud This work is dedicated to exploring and understanding the process of value-creation for clients in agile projects, with a particular focus on the requirements prioritization and reprioritization during a project, as an agile-specific value creation practice.\ud We performed a number of research steps to explore some of the current agile practices that seem to contribute to the value creation, and thus to distil knowledge that the agile practitioners apply and that might help to improve the agile practice.\ud Further, we studied in detail the agile prioritization process and identified the criteria, used in the decision-making process, and relations between the project context and the instantiation of the process.\ud In particular, we researched the following topics:\ud • How is business value perceived and measured in agile projects?\ud • What practices contribute to value creation in agile projects in different contexts?\ud • What concepts play a role in making re-prioritization decisions about\ud requirements?\ud These questions represent the focus of our research activities. They lead and framed the formulation of our Research Questions and the research design.\ud The main contribution of our work to the research and practitioners’ communities\ud consists in the rich contextual description of the process of requirements prioritization in agile projects as well as a conceptual model of this process

    Modeling the Impact of a Learning Phase on the Business Value of a Pair Programming Project

    No full text
    Pair programmers need a ”warmup phase” before the pair can work at full speed. The length of the learning interval varies, depending on how experienced the developers are with pair programming and how familiar they are with each other. We study how large the impact of the lower pair productivity during warmup is on the business value of the pair programming project. To this end, we extend our net present value model for pair programming to explicitly include a learning interval for pairs. We then carry out a simulation study where we vary the shape of the learning curve, the length of the learning interval, the final productivity level of the pairs, the market pressure, and the size of the workforce. Our simulations show that the cost of the warmup phase is reasonably small compared to the project value, but nonetheless must be taken into account when estimating the project. Our results also suggest that the learning overhead is not an obstacle to introducing and using pair programming in a real environment
    corecore