10,639 research outputs found
Non-Technical Individual Skills are Weakly Connected to the Maturity of Agile Practices
Context: Existing knowledge in agile software development suggests that
individual competency (e.g. skills) is a critical success factor for agile
projects. While assuming that technical skills are important for every kind of
software development project, many researchers suggest that non-technical
individual skills are especially important in agile software development.
Objective: In this paper, we investigate whether non-technical individual
skills can predict the use of agile practices. Method: Through creating a set
of multiple linear regression models using a total of 113 participants from
agile teams in six software development organizations from The Netherlands and
Brazil, we analyzed the predictive power of non-technical individual skills in
relation to agile practices. Results: The results show that there is
surprisingly low power in using non-technical individual skills to predict
(i.e. explain variance in) the mature use of agile practices in software
development. Conclusions: Therefore, we conclude that looking at non-technical
individual skills is not the optimal level of analysis when trying to
understand, and explain, the mature use of agile practices in the software
development context. We argue that it is more important to focus on the
non-technical skills as a team-level capacity instead of assuring that all
individuals possess such skills when understanding the use of the agile
practices.Comment: 18 pages, 1 figur
Technical Debt Prioritization: State of the Art. A Systematic Literature Review
Background. Software companies need to manage and refactor Technical Debt
issues. Therefore, it is necessary to understand if and when refactoring
Technical Debt should be prioritized with respect to developing features or
fixing bugs. Objective. The goal of this study is to investigate the existing
body of knowledge in software engineering to understand what Technical Debt
prioritization approaches have been proposed in research and industry. Method.
We conducted a Systematic Literature Review among 384 unique papers published
until 2018, following a consolidated methodology applied in Software
Engineering. We included 38 primary studies. Results. Different approaches have
been proposed for Technical Debt prioritization, all having different goals and
optimizing on different criteria. The proposed measures capture only a small
part of the plethora of factors used to prioritize Technical Debt qualitatively
in practice. We report an impact map of such factors. However, there is a lack
of empirical and validated set of tools. Conclusion. We observed that technical
Debt prioritization research is preliminary and there is no consensus on what
are the important factors and how to measure them. Consequently, we cannot
consider current research conclusive and in this paper, we outline different
directions for necessary future investigations
RePOR: Mimicking humans on refactoring tasks. Are we there yet?
Refactoring is a maintenance activity that aims to improve design quality
while preserving the behavior of a system. Several (semi)automated approaches
have been proposed to support developers in this maintenance activity, based on
the correction of anti-patterns, which are `poor' solutions to recurring design
problems. However, little quantitative evidence exists about the impact of
automatically refactored code on program comprehension, and in which context
automated refactoring can be as effective as manual refactoring. Leveraging
RePOR, an automated refactoring approach based on partial order reduction
techniques, we performed an empirical study to investigate whether automated
refactoring code structure affects the understandability of systems during
comprehension tasks. (1) We surveyed 80 developers, asking them to identify
from a set of 20 refactoring changes if they were generated by developers or by
a tool, and to rate the refactoring changes according to their design quality;
(2) we asked 30 developers to complete code comprehension tasks on 10 systems
that were refactored by either a freelancer or an automated refactoring tool.
To make comparison fair, for a subset of refactoring actions that introduce new
code entities, only synthetic identifiers were presented to practitioners. We
measured developers' performance using the NASA task load index for their
effort, the time that they spent performing the tasks, and their percentages of
correct answers. Our findings, despite current technology limitations, show
that it is reasonable to expect a refactoring tools to match developer code
- …