Subscribe to the gold package and get unlimited access to Shamra Academy
Register a new userDifferences in Jazz Project Leaders Competencies and Behaviors: A Preliminary Empirical Investigation
476
0
0.0
(
0
)
Added by
Stephen MacDonell
Publication date
2021
fields
Informatics Engineering
and research's language is
English
Ask ChatGPT about the research
No Arabic abstract
Studying the human factors that impact on software development, and assigning individuals with specific competencies and qualities to particular software roles, have been shown to aid software project performance. For instance, prior evidence suggests that extroverted software project leaders are most successful. Role assignment based on individuals competencies and behaviors may be especially relevant in distributed software development contexts where teams are often affected by distance, cultural, and personality issues. Project leaders in these environments need to possess high levels of inter-personal, intra-personal and organizational competencies if they are to appropriately manage such issues and maintain positive project performance. With a view to understanding and explaining the specific competencies and behaviors that are required of project leaders in these settings, we used psycholinguistic and directed content analysis to study the way six successful IBM Rational Jazz leaders operated while coordinating their three distributed projects. Contrary to previous evidence reported in personality studies, our results did not reveal universal competencies and behaviors among these Jazz leaders. Instead, Jazz project leaders competencies and behaviors varied with their project portfolio of tasks. Our findings suggest that a pragmatic approach that considers the nature of the software tasks being developed is likely to be a more effective strategy for assigning leaders to distributed software teams, as against a strategy that promotes a specific personality type. We discuss these findings and outline implications for distributed software project governance.
rate research
Read More
Context: Interest in software engineering (SE) methodologies and tools has been complemented in recent years by research efforts oriented towards understanding the human processes involved in software development. This shift has been imperative given reports of inadequately performing teams and the consequent growing emphasis on individuals and team relations in contemporary SE methods. Objective: While software repositories have frequently been studied with a view to explaining such human processes, research has tended to use primarily quantitative analysis approaches. There is concern, however, that such approaches can provide only a partial picture of the software process. Given the way human behavior is nuanced within psychological and social contexts, it has been asserted that a full understanding may only be achieved through deeper contextual enquiries. Method: We have followed such an approach and have applied data mining, SNA, psycholinguistic analysis and directed content analysis (CA) to study the way core developers at IBM Rational Jazz contribute their social and intellectual capital, and have compared the attitudes, interactions and activities of these members to those of their less active counterparts. Results: Among our results, we uncovered that Jazzs core developers worked across multiple roles, and were crucial to their teams organizational, intra-personal and inter-personal processes. Additionally, although these individuals were highly task- and achievement-focused, they were also largely responsible for maintaining positive team atmosphere, and for providing context awareness in support of their colleagues. Conclusion: Our results suggest that high-performing distributed agile teams rely on both individual and collective efforts, as well as organizational environments that promote informal and organic work structures.(Abridged)
In globally distributed projects, virtual teams are often partially dispersed. One common setup occurs when several members from one company work with a large outsourcing vendor based in another country. Further, the introduction of the popular BizDevOps concept has increased the necessity to cooperate across departments and reduce the age-old disconnection between the business strategy and technical development. Establishing a good collaboration in partially distributed BizDevOps teams requires extensive collaboration and communication techniques. Nowadays, a common approach is to rely on collaboration through pull requests and frequent communication on Slack. To investigate barriers for pull requests in distributed teams, we examined an organization located in Scandinavia where cross-functional BizDevOps teams collaborated with off-site team members in India. Data were collected by conducting 14 interviews, observing 23 entire days with the team, and observing 37 meetings. We found that the pull-request approach worked very well locally but not across sites. We found barriers such as domain complexity, different agile processes (timeboxed vs. flow-based development), and employee turnover. Using an intellectual capital lens on our findings, we discuss barriers and positive and negative effects on the success of the pull-request approach.
Despite the sophisticated phishing email detection systems, and training and awareness programs, humans continue to be tricked by phishing emails. In an attempt to understand why phishing email attacks still work, we have carried out an empirical study to investigate how people make response decisions while reading their emails. We used a think aloud method and follow-up interviews to collect data from 19 participants. The analysis of the collected data has enabled us to identify eleven factors that influence peoples response decisions to both phishing and legitimate emails. Based on the identified factors, we discuss how people can be susceptible to phishing attacks due to the flaws in their decision-making processes. Furthermore, we propose design directions for developing a behavioral plugin for email clients that can be used to nudge peoples secure behaviors enabling them to have a better response to phishing emails.
Software systems are increasingly depending on data, particularly with the rising use of machine learning, and developers are looking for new sources of data. Open Data Ecosystems (ODE) is an emerging concept for data sharing under public licenses in software ecosystems, similar to Open Source Software (OSS). It has certain similarities to Open Government Data (OGD), where public agencies share data for innovation and transparency. We aimed to explore open data ecosystems involving commercial actors. Thus, we organized five focus groups with 27 practitioners from 22 companies, public organizations, and research institutes. Based on the outcomes, we surveyed three cases of emerging ODE practice to further understand the concepts and to validate the initial findings. The main outcome is an initial conceptual model of ODEs value, intrinsics, governance, and evolution, and propositions for practice and further research. We found that ODE must be value driven. Regarding the intrinsics of data, we found their type, meta-data, and legal frameworks influential for their openness. We also found the characteristics of ecosystem initiation, organization, data acquisition and openness be differentiating, which we advise research and practice to take into consideration.
Context: The utility of prediction models in empirical software engineering (ESE) is heavily reliant on the quality of the data used in building those models. Several data quality challenges such as noise, incompleteness, outliers and duplicate data points may be relevant in this regard. Objective: We investigate the reporting of three potentially influential elements of data quality in ESE studies: data collection, data pre-processing, and the identification of data quality issues. This enables us to establish how researchers view the topic of data quality and the mechanisms that are being used to address it. Greater awareness of data quality should inform both the sound conduct of ESE research and the robust practice of ESE data collection and processing. Method: We performed a targeted literature review of empirical software engineering studies covering the period January 2007 to September 2012. A total of 221 relevant studies met our inclusion criteria and were characterized in terms of their consideration and treatment of data quality. Results: We obtained useful insights as to how the ESE community considers these three elements of data quality. Only 23 of these 221 studies reported on all three elements of data quality considered in this paper. Conclusion: The reporting of data collection procedures is not documented consistently in ESE studies. It will be useful if data collection challenges are reported in order to improve our understanding of why there are problems with software engineering data sets and the models developed from them. More generally, data quality should be given far greater attention by the community. The improvement of data sets through enhanced data collection, pre-processing and quality assessment should lead to more reliable prediction models, thus improving the practice of software engineering.
Log in to be able to interact and post comments
comments
Fetching comments
Sign in to be able to follow your search criteria
