Search

One of the main obstacles in software development projects is requirement volatility (RV), which is defined as uncertainty or changes in software requirements during the development process. Therefore, this research tries to understand the underlying factors behind the RV and the best practices to reduce it. The methodology used for this research is based upon qualitative research using interviews with 12 participants with experience in agile software development projects. The participants hailed from Austria, Nigeria, the USA, the Philippines, Armenia, Sri Lanka, Germany, Egypt, Canada, and Turkey and held roles such as project managers, software developers, Scrum Masters, testers, business analysts, and product owners. Our findings based on our empirical data revealed six primary factors that cause RV and three main agile practices that help to mitigate it. Theoretically, this study contributes to the body of knowledge relating to RV management. Practically, this research is expected to aid software development teams in comprehending the reasons behind RV and the best practices to effectively minimize it. [ABSTRACT FROM AUTHOR]

The competition in the software market demands that the time required for any software product to reach the market be reduced if the product is to survive competition from other developers. The pursuit of this goal has led to the adoption of agile software development methodologies. While other agile methodologies provide guidelines as to the software engineering (SE) practices to be used during the development lifecycle, Scrum does not. The purpose of this study is twofold: first, to identify the usage and level of importance of software engineering practices in the Scrum development environment; and second, to investigate how Scrum teams adopt an appropriate set of SE techniques and whether a hybrid Scrum/Extreme Programming (XP) methodology is an appropriate approach to take. This research was conducted by examining sample data from five organizations using the Scrum methodology. The sample included a range of industries including communications and embedded systems, financial asset management, software development houses and consulting firms in South Africa. The study employed a mixed method approach. A key finding was that, regardless of the fact that Scrum does not explicitly recommend engineering practices, there was extensive use of these practices by all of the participating organizations. The study also found that the lack of software engineering practices in Scrum does not constitute a barrier to a successful adoption of Scrum, provided the 'inspect and adapt' principle inherent in Scrum is properly followed. The study discusses the findings, explains the implications and suggests future research. [ABSTRACT FROM AUTHOR]

Continuous integration is an agile software development practice. Instead of integrating features right before a release, they are constantly being integrated into an automated build process. This shortens the release cycle, improves software quality, and reduces time to market. However, the whole process will come to a halt when a commit breaks the build, which can happen for several reasons, e.g., compilation errors or test failures, and fixing the build suddenly becomes a top priority. Developers not only have to find the cause of the build break and fix it, but they have to be quick in all of it to avoid a delay for others. Unfortunately, these steps require deep knowledge and are often time-consuming. To support developers in fixing a build break, we propose Bart, a tool that summarizes the reasons for Maven build failures and suggests possible solutions found on the internet. We will show in a case study with 17 participants that developers find Bart useful to understand build breaks and that using Bart substantially reduces the time to fix a build break, on average by 37%. We have also conducted a qualitative study to better understand the workflows and information needs when fixing builds. We found that typical workflows differ substantially between various error categories, and that several uncommon build errors are both very hard to investigate and to fix. These findings will be useful to inform future research in this area. [ABSTRACT FROM AUTHOR]

Abstract: Traditional software teams that implement agile methodologies frequently experience difficulty working efficiently as agile teams. While agile methodologies support and promote social activities and behaviors, the understanding of the social phenomena and challenges that arise during the transformation of traditional teams into agile teams is limited. We conducted an extensive 10‐month case study in a software enterprise to analyze the changes in the communication and social interactions of employees during the transformation process, and to delineate the social challenges that arise during this process. Using social interaction registers, we collected data on the communication and social interactions of employees, first when they worked as a traditional team and then as an agile team. Then, we processed the data using social network analysis methods to identify the differences between these 2 types of teams and to create graphs of communication and social interaction networks. We identified that the transformation process influences formal, informal, oral, and written communication and increases conjunctive and disjunctive social interactions. Further, from the results of interviews conducted with all the enterprise members, we identified 5 social challenges to transforming a traditional team into an agile one. The results of this research suggest that the transformation process requires broad changes in the relationships and interactions among employees. [ABSTRACT FROM AUTHOR]

The lack of user engagement, the absence of user feedback, incomplete and continuously changing user requirements are among the critical concerns that cause projects to fail. User-centered design (UCD) and agile software development are two iterative approaches that have been proposed to overcome such concerns. UCD is a design process focusing on user research, user interface design and usability evaluation. Introduced by software engineering practitioners, agile refers to a number of iterative and incremental software development practices that emphasize people's needs, communication between developers and stakeholders and the ability to adapt to change. In both the agile and UCD communities, however, a full understanding of user requirements is often seen as incompatible with early and quick development iterations. We performed a literature review aiming to identify how agile teams have integrated UCD tools into their agile software development process to a better understanding of the user requirements without losing sight of the agile values and principles. UCD tools adaptations and minimal-up-front design applied in agile development are among the approaches discovered in this study. The findings could lead to a comprehensive user-centric software engineering that will overcome inherent problems faced by agile teams to understand user needs, priorities and goals. [ABSTRACT FROM AUTHOR]