1,789,449 research outputs found
XP customer practices: A grounded theory
No full textThe Customer is a critical role in XP, but almost all XP practices are presented for developers by developers. While XP calls for Real Customer Involvement, it does not explain what XP Customers should do, nor how they should do it. Using Grounded Theory, we discovered eight customer practices used by successful XP teams: Customer Boot Camp, Customer’s Apprentice, Customer Pairing, and Programmer’s Holiday support the well-being and effectiveness of customers; Programmer On-site and Road shows support team and organization interactions; and Big Picture Up Front and Re-calibration support Customers steering the whole project. By adopting these processes, XP Customers and teams can work faster and more sustainably
The XP customer team: A grounded theory
No full textThe initial definition of XP resulted in many people interpreting the on-site customer to be a single person. We have conducted extensive qualitative research studying XP teams, and one of our research questions was “who is the customer”? We found that, rather than a single person, a customer team always exists. In this paper we outline the different roles that were typically on the team, which range from the recognized “Acceptance Tester” role to the less recognized roles of “Political Advisor” and “Super-Secretary”
Some Findings Concerning Requirements in Agile Methodologies
No full textgile methods have appeared as an attractive alternative to conventional methodologies. These methods try to reduce the time to market and, indirectly, the cost of the product through flexible development and deep customer involvement. The processes related to requirements have been extensively studied in literature, in most cases in the frame of conventional methods. However, conclusions of conventional methodologies could not be necessarily valid for Agile; in some issues, conventional and Agile processes are radically different. As recent surveys report, inadequate project requirements is one of the most conflictive issues in agile approaches and better understanding about this is needed. This paper describes some findings concerning requirements activities in a project developed under an agile methodology. The project intended to evolve an existing product and, therefore, some background information was available. The major difficulties encountered were related to non-functional needs and management of requirements dependencies
An Empirical Comparison of Two Agile Projects in the Same Organization
No full textThe appearance of Agile methods has been the most noticeable change to software process thinking in the last fifteen years[1]. The main goal of this research is to investigate the quality of Agile projects empirically, in order to help software development organizations increase their understanding of Agile methods, principles and practices. This paper presents a multi-case study that was conducted using semi-structured interviews with two project teams that are using Agile methods within one organization. Our data was analyzed using the constant comparison method. The results are presented to illustrate how the teams adopted Agile methods and a comparison between the two projects is provided. From this it can be concluded that both projects were successful with multiple releases, the quality is generally seem to be as good as other projects in the same organization, the time release is reduced, and the differences between the two projects in terms of communication, the iteration length and the approach to quality, may result from the different team sizes
Agile methods for agile universities
No full textWe explore a term, Agile, that is being used in various workplace settings, including the management of universities. The term may have several related but slightly different meanings. Agile is often used in the context of facilitating more creative problem-solving and advocating for the adoption, design, tailoring and continual updating of more innovative organizational processes. We consider a particular set of meanings of the term from the world of software development. Agile methods were created to address certain problems with the software development process. Many of those problems have interesting analogues in the context of universities, so a reflection on agile methods may be a useful heuristic for generating ideas for enabling universities to be more creative
Evaluating the Impact of Critical Factors in Agile Continuous Delivery Process: A System Dynamics Approach
No full textContinuous Delivery is aimed at the frequent delivery of good quality software in a speedy, reliable and efficient fashion – with strong emphasis on automation and team collaboration. However, even with this new paradigm, repeatability of project outcome is still not guaranteed: project performance varies due to the various interacting and inter-related factors in the Continuous Delivery 'system'. This paper presents results from the investigation of various factors, in particular agile practices, on the quality of the developed software in the Continuous Delivery process. Results show that customer involvement and the cognitive ability of the QA have the most significant individual effects on the quality of software in continuous delivery
Agile Game: A Project Management Game for Agile Methods
No full textSince mid-1990s, companies have adopted agile methods and incorporated them in their development methodologies. For this reason, future project managers and developers need to have a full understanding of these methods. At present, the university’s approach to agile methods is theoretical and is not reflected during the development of a product and their practical use. The purpose of this project is the creation of a software system in the form of a game, named Agile Game, which simulates their use. The system is designed for use as supplementary material in lectures, to help students understand agile methods, to present their use within a project, and to demonstrate how they differ from traditional project management methodologies. The final system, which is web based, was implemented using PHP, MySQL and JavaScript. It was fully tested against the requirements and evaluated by peer students. The evaluation showed that the majority of users were satisfied with the system but they thought that it should contain more detailed information at every step of the game. For this reason, some parts of the design and the content were reviewed to meet user requirements
Um estudo exploratório a partir de um framework para seleção de práticas ágeis
No full textDissertação (mestrado) - Universidade Federal de Santa Catarina, Centro Tecnológico. Programa de Pós-Graduação em Ciência da ComputaçãoO principal objetivo dos métodos ágeis existentes é promover o desenvolvimento eficiente de software através de práticas que priorizam a comunicação com o cliente e entregas frequentes. Cada método ágil apresenta um conjunto próprio de práticas. Com esta diversidade de práticas torna-se interessante a construção de novos processos ágeis que contemplem apenas as práticas mais adequadas a partir destes métodos. O problema, entretanto, é que a combinação de práticas de diferentes métodos ágeis não garante, necessariamente, que o novo processo definido seja ágil. Este trabalho avalia a agilidade do conjunto de práticas de um framework de práticas ágeis e busca identificar quais práticas apresentam maior harmonia quando usadas no mesmo processo. A agilidade das práticas é avaliada através dos dados de uma grande pesquisa de opinião online e a harmonia entre elas é identificada através da técnica de análise de agrupamentos. Os melhores resultados foram apresentados pelas práticas de Integração contínua, Desenvolvimento lado a lado e Testes de aceitação. A análise de agrupamentos, por sua vez, formou quatro grupos de práticas: o primeiro formado por Projeto da arquitetura do sistema e Lista de requisitos; o segundo por Desenvolvimento coletivo de código, Integração contínua, Refatoração e Testes de aceitação; o terceiro por Projeto da iteração e Modelagem geral; e o quarto por Desenvolvimento lado a lado e Reuniões diárias.The main objective of agile methods is to promote efficient software development through practices that prioritize communication with the client and frequent deliveries. Each agile method presents its unique set of practices. This diversity of practices may lead to the definition of new agile processes that include only the more appropriate practices from these methods. The problem, however, is that combining practices from different methods does not guarantee that the resulting process can be considered agile. This work assesses the agility of a set of practices of a framework for selecting agile practices and seeks to identify which practices provide more harmony when used in the same process. The agility of the practices is evaluated using data from a large online survey and the harmony between them is identified by the technique of cluster analysis. The best results were presented by the practices of Continuous integration, Side by side development and Acceptance tests. The cluster analysis resulted in four practice groups: the first with System architectural design and Requirements list; the second with Collective code ownership, Continuous integration, Refactoring and Acceptance tests; the third with Iteration design and General modeling; and the fourth with Side by side development and Daily meetings
Historical roots of Agile methods: where did “Agile thinking” come from?
No full textThe appearance of Agile methods has been the most noticeable change to software process thinking in the last fifteen years [16], but in fact many of the “Agile ideas” have been around since 70’s or even before. Many studies and reviews have been conducted about Agile methods which ascribe their emergence as a reaction against traditional methods. In this paper, we argue that although Agile methods are new as a whole, they have strong roots in the history of software engineering. In addition to the iterative and incremental approaches that have been in use since 1957 [21], people who criticised the traditional methods suggested alternative approaches which were actually Agile ideas such as the response to change, customer involvement, and working software over documentation. The authors of this paper believe that education about the history of Agile thinking will help to develop better understanding as well as promoting the use of Agile methods. We therefore present and discuss the reasons behind the development and introduction of Agile methods, as a reaction to traditional methods, as a result of people's experience, and in particular focusing on reusing ideas from histor
Agile Construction and Evolution of Product-Line Architectures
No full textSoftware Product Line Engineering (SPLE) has proved to have significant advantages in family-based software development, but also implies the up¬front design of a product-line architecture (PLA) from which individual product applications can be engineered. The big upfront design associated with PLAs is in conflict with the current need of "being open to change". However, the turbulence of the current business climate makes change inevitable in order to stay competitive, and requires PLAs to be open to change even late in the development. The trend of "being open to change" is manifested in the Agile Software Development (ASD) paradigm, but it is spreading to the domain of SPLE. To reduce the big upfront design of PLAs as currently practiced in SPLE, new paradigms are being created, one being Agile Product Line Engineering (APLE). APLE aims to make the development of product-lines more flexible and adaptable to changes as promoted in ASD. To put APLE into practice it is necessary to make mechanisms available to assist and guide the agile construction and evolution of PLAs while complying with the "be open to change" agile principle. This thesis defines a process for "the agile construction and evolution of product-line architectures", which we refer to as Agile Product-Line Archi-tecting (APLA). The APLA process provides agile architects with a set of models for describing, documenting and tracing PLAs, as well as an algorithm to analyze change impact. Both the models and the change impact analysis offer the following capabilities: Flexibility & adaptability at the time of defining software architectures, enabling change during the incremental and iterative design of PLAs (anticipated or planned changes) and their evolution (unanticipated or unforeseen changes). Assistance in checking architectural integrity through change impact analysis in terms of architectural concerns, such as dependencies on earlier design decisions, rationale, constraints, and risks, etc.Guidance in the change decision-making process through change im¬pact analysis in terms of architectural components and connections. Therefore, APLA provides the mechanisms required to construct and evolve PLAs that can easily be refined iteration after iteration during the APLE development process. These mechanisms are provided in a modeling frame¬work called FPLA. The contributions of this thesis have been validated through the conduction of a project regarding a metering management system in electrical power networks. This case study took place in an i-smart software factory and was in collaboration with the Technical University of Madrid and Indra Software Labs. La Ingeniería de Líneas de Producto Software (Software Product Line Engi¬neering, SPLE) ha demostrado tener ventajas significativas en el desarrollo de software basado en familias de productos. SPLE es un paradigma que se basa en la reutilización sistemática de un conjunto de características comunes que comparten los productos de un mismo dominio o familia, y la personalización masiva a través de una variabilidad bien definida que diferencia unos productos de otros. Este tipo de desarrollo requiere el diseño inicial de una arquitectura de línea de productos (Product-Line Architecture, PLA) a partir de la cual los productos individuales de la familia son diseñados e implementados. La inversión inicial que hay que realizar en el diseño de PLAs entra en conflicto con la necesidad actual de estar continuamente "abierto al cam¬bio", siendo este cambio cada vez más frecuente y radical en la industria software. Para ser competitivos es inevitable adaptarse al cambio, incluso en las últimas etapas del desarrollo de productos software. Esta tendencia se manifiesta de forma especial en el paradigma de Desarrollo Ágil de Software (Agile Software Development, ASD) y se está extendiendo también al ámbito de SPLE. Con el objetivo de reducir la inversión inicial en el diseño de PLAs en la manera en que se plantea en SPLE, en los último años han surgido nuevos enfoques como la Ingeniera de Líneas de Producto Software Ágiles (Agile Product Line Engineering, APLE). APLE propone el desarrollo de líneas de producto de forma más flexible y adaptable a los cambios, iterativa e incremental. Para ello, es necesario disponer de mecanismos que ayuden y guíen a los arquitectos de líneas de producto en el diseño y evolución ágil de PLAs, mientras se cumple con el principio ágil de estar abierto al cambio. Esta tesis define un proceso para la "construcción y evolución ágil de las arquitecturas de lineas de producto software". A este proceso se le ha denominado Agile Product-Line Architecting (APLA). El proceso APLA proporciona a los arquitectos software un conjunto de modelos para de¬scribir, documentar y trazar PLAs, así como un algoritmo para analizar vel impacto del cambio. Los modelos y el análisis del impacto del cambio ofrecen: Flexibilidad y adaptabilidad a la hora de definir las arquitecturas software, facilitando el cambio durante el diseño incremental e iterativo de PLAs (cambios esperados o previstos) y su evolución (cambios no previstos). Asistencia en la verificación de la integridad arquitectónica mediante el análisis de impacto de los cambios en términos de dependencias entre decisiones de diseño, justificación de las decisiones de diseño, limitaciones, riesgos, etc. Orientación en la toma de decisiones derivadas del cambio mediante el análisis de impacto de los cambios en términos de componentes y conexiones. De esta manera, APLA se presenta como una solución para la construcción y evolución de PLAs de forma que puedan ser fácilmente refinadas iteración tras iteración de un ciclo de vida de líneas de producto ágiles. Dicha solución se ha implementado en una herramienta llamada FPLA (Flexible Product-Line Architecture) y ha sido validada mediante su aplicación en un proyecto de desarrollo de un sistema de gestión de medición en redes de energía eléctrica. Dicho proyecto ha sido desarrollado en una fábrica de software global en colaboración con la Universidad Politécnica de Madrid e Indra Software Labs
- …
