• Không có kết quả nào được tìm thấy


Nguyễn Gia Hào

Academic year: 2023

Chia sẻ "OER000001405.pdf"


Loading.... (view fulltext now)

Văn bản

Katie Taylor University of Central Lancashire, Združeno kraljestvo Peggy Gregory University of Central Lancashire, UK Industry and Practice Track. Bruce Scharlau University of Aberdeen, Združeno kraljestvo Chris Murray University of Sheffield, UK Empirical Studies Track.

Focal Points for a More User-Centred Agile Development

1 Introduction

2 Related Work

In fact, UCD suggests the use of some artifacts such as personas and prototypes to record requirements and design rationales [28], while Agile promotes face-to-face conversation as the most effective means of communication in its basic principles [3], for it. point of customer involvement in the development team. There are different schools of thought on whether UCD and Agile should be merged into a unified software engineering process, leveraging their common practices, or whether they should continue in parallel.

3 H-umus

  • Field Study Methodology
  • Communication Network
  • Artefacts
  • Findings

A variety of artifacts are used in H-umus to support communication, both internally and with the client. Dev2: "The hardest thing to communicate with the customer is to understand who you need to talk to."

Fig. 1. Communication network in H-umus.
Fig. 1. Communication network in H-umus.

4 Discussion

In Smart Campus, the customer and the user community were two clearly distinct actors; most of the team only had direct contact with the users through a variety of communication channels such as a forum. Therefore, we can argue that the understanding of the scope of user involvement should not only be shared within the company (among designers, developers, managers), but also externally by the customer.

5 Conclusion

We insist that achievable benefits must be clearly presented to the customer to win his acceptance of the principles of design thinking, his recognition. We would like to thank the Smart Campus team, the students who contributed to the project and the Humus team for their kind support.

This chapter is distributed under the terms of the Creative Commons Attribution-NonCommercial 4.0 International License (http://creativecommons.org/licenses/by-nc/4.0/), which permits any non-commercial use, duplication, adaptation, distribution, and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and source, a link to the Creative Commons license is provided, and any changes are noted. In: Proceedings of the 2nd International Workshop on The Interplay between User Experience Evaluation And Software Development, in connection with the 7th Nordic Conference on Human-Computer Interaction (2012).

Agility Measurements Mismatch: A Validation Study on Three Agile Team Assessments

Poonacha and Bhattacharya [14] mentioned that different perceptions of agile practices when they are adopted are worrying, as even people in the same team understand them differently, according to the result of a survey [15]. Will PAM, TAA and OPS give similar results. i) Does convergent validity exist between the tools. ii) Queries that are exactly the same in means will give the same results.

2 Case Study

Data Collection

After the problems indicated by the two subjects were solved, the surveys were sent to the rest of the company's employees. The employees asked to complete the surveys were all members of the software development teams, which consisted of software and QA engineers.

Data Analysis

Of the 42 normality checks (three for each of the 14 practices), only 17 concluded that the data are normally distributed. Of the 35 normality controls (two for each group and three for one group), only 2 concluded that the data are normally distributed.

3 Results


We decided to use the practices covered by each instrument and see if they correlate with the same practices from the other two instruments. Their answer was affirmative, so we continued by checking whether the answers of the subjects were the same.

Direct Match Questions Results

Will PAM, TAA and OPS Yield Similar Results?

Although the tools may cover the same areas for each practice, the results may vary due to the structure of the question. Considering that researchers and specialists in the agile field perceive the concept of agility differently, it would be naive to say that teams do not do the same.

5 Threats to Validity

  • Construct Validity
  • Conclusion Validity
  • External Validity
  • Reliability

Furthermore, Conboy and Fitzgerald [33] state that the principles of the agile manifesto do not provide practical understanding of the concept of agility. To mitigate this, the findings were discussed with an employee of the company who did not participate in the case study.

6 Conclusions and Future Work


Future Work

Escobar-Sarmiento, V., Linares-Vasquez, M.: A model for measuring agility in small and medium-sized software development enterprises. So, C., Scholl, W.: Agile Perceptual Measurement: New Instruments for Quantitative Studies in Tracking the Social-Psychological Effect of Agile Practices. eds.).

Scaling up the Planning Game: Collaboration Challenges in Large-Scale Agile Product Development

In this paper, we present a qualitative case study based on ten semi-structured interviews exploring how program and project leaders, product owners, line managers, and cross-functional team developers coordinate around work scheduling in a large-scale agile setting. First, we provide insight into the challenges of aligning the viewpoints of product owners and product developers during planning in large-scale agile.

2 Background and Related Work

In this process, priority drives the packaging of requirements into releases: the requirements with the highest priorities are packaged for development first [13], and usually the main criterion for such prioritization is the business value of customers and vendors [19]. 19], there is a lack of (empirical) knowledge on how requirements prioritization is done in large-scale agile software development [19], a gap we aim to explore in this paper.

3 Research Method

We further revised the themes we generated from phase four by checking them against interview data and the codes generated from previous phases. In addition to that, we also reviewed the names we gave to the themes based on the sub-challenges we have in each of the themes to determine appropriate and distinctive naming.

4 Findings: Technical Abilities, Context, and Ceremonies

Technical Ability Challenges

Relevant themes for large-scale agile planning relate to technical capabilities as well as context of planning. Unclear requirements, one of the major challenges in large-scale agile planning, affect both estimation and prioritization.

Fig. 1. Relevant themes of large-scale agile planning concern technical abilities as well as context of planning
Fig. 1. Relevant themes of large-scale agile planning concern technical abilities as well as context of planning

Contextual Challenges

Our interviewees described how team spirit begins to grow when team members have been working together and operating successfully for some time. In addition, team spirit in the host team can also be affected.

Ceremonial Agreement

As a result, removing or adding new members to the team can reduce the spirit already established within the team. Again, our findings resonate with Sauer's recommendation to promote team spirit with opportunities for informal exchange, such as coffee breaks [14].

5 Discussion and Conclusion

In Tables 2, 3 and 4 we illustrate the data collection practices, along with the customer feedback methods and types of data collected by different roles in each of the development stages. Illustrated with red and dotted arrows on Fig.

Table 1. Description of the companies and the representatives that we met with.
Table 1. Description of the companies and the representatives that we met with.

TDDViz: Using Software Changes to Understand Conformance to Test Driven Development

To answer these questions, we use code and test changes to understand compliance with a process. Our independent variable used TDDVizor existing visualizations to answer questions about the TDD process.

2 Visualization

Visualization Elements

The snapshot timeline provides more information about the TDD process, specifically showing all snapshots in the current session. To understand the TDD process, a coder must be able to look at the code that was written and see how it evolved over time.

3 TDD Phase Inferencer


Figure1[d] shows an example of a code modification, displaying the changes to the code between two snapshots. By placing the selection box on the timeline as described above, a user can see how all the code has evolved over any two arbitrary photos.

Abstract Syntax Tree


The algorithm's transition from Red to Blue is the case when a single snapshot has lasted the entire Green phase, and therefore the algorithm has moved to the Blue phase. Therefore, after the algorithm has identified a brown phase, it immediately moves back to the blue phase.

4 Evaluation

Controlled Experiment

Both treatments received exactly the same questions about the same practice data in the same order. Measures. The independent variable in this study was the visualization used to answer the questions.

Controlled Experiment Results

When we asked participants to identify TDD, we found that significantly more participants correctly identified TDD and non-TDD sessions using TDDViz than when using the standard cyber-dojo visualization, as Table 1 shows (Fishers Exact Test: p<.0005). RQ2: Comprehension. When we asked participants why a specific code change had been made, we found that significantly more participants correctly identified why the code was changed when using TDDViz than when using the standard cyber-dojo visualization (see Table 1: Comprehension, Fisher's exact test: p<.0013).

Case Study

Accuracy. We calculate the accuracy of our inferents using the traditional F-measure, which takes into account both precision and recall. Once we have calculated these for each session in the Gold Standard, we calculate precision and recall using the standard formulas.

5 Related Work and Conclusions

The interviewees considered that the elements of the framework cover the UX needs well in an early version of the product. The main UX goals and qualities of the early versions of the product had recurring themes from which we abstracted elements of MVUX.

Table 1. Summary of startups and interviewees participating the fi rst phase. Legend:
Table 1. Summary of startups and interviewees participating the fi rst phase. Legend:

Team Portfolio Scrum

An Action Research on Multitasking in Multi-project Scrum Teams

Software Development: Interruptions and Multiple Projects Existing software development literature generally considers task switching to

Working on multiple software projects: A common argument against developing multiple projects is that projects provide a revenue stream to the company at the time of completion. If a team is working on multiple projects, the team should work from one backlog during the sprint, containing work items from multiple projects [16-19].

Psychology: Interruptions and Task Switching

On the other hand [29] found that people very commonly interrupt themselves, which can be a form of self-protection, reduced fatigue and increased performance [30]. Interruptions, work contexts and office spaces: Interruptions are ubiquitous in the work of knowledge workers.

3 Research Objectives

Some practitioner sources claim effects on the order of minutes, which is indicative of such a function and the relationship between task complexity and switch cost. Literature suggests that teams working on multiple projects should work from a backlog during the sprint [16-19].

4 Research Method and Conduct

As such, we pose the following research question: What obstacles can be encountered and what benefits can result from introducing a task prioritization practice to support a team working on several projects in parallel. The team is working on one of those products, but a majority of the time is spent customizing the product implementation per customer.

5 Action Research

  • Diagnosing
  • Action Planning
  • Action Taking
  • Evaluating

A team member said at the outset: “The role itself has too much responsibility, at least too much for what the current TPO is mandated for. The TPO should define the priorities and protect the developers from outside." The POs appreciated this delegation of responsibilities at later stages of the project: "I liked that the TPO could make the choices."

6 Conclusions

Wetherell, M.A., Carter, K.: The multitasking framework: the effects of increasing workload on acute psychobiological stress reactivity. Diamond, D.M., Campbell, A.M., Park, C.R., Halonen, J., Zoladz, P.R.: The temporal dynamics model of emotional memory processing: a synthesis on the neurobiological basis of stress-induced amnesia, flashbulb and traumatic memories, and the Yerkes-Dodson- the law.

Quality Assurance in Scrum Applied to Safety Critical Software

In short – Scrum can be seen as a combined and self-sustaining planning, development and quality assurance process, although it is not traceable. We also see Scrum being used for the development of safety-critical systems, which must meet strict quality and safety standards.

2 Quality Assurance in Agile Software Development

It is necessary to ensure that the functionality as well as the quality of the system meets requirements and expectations. However, the trend in the software industry today is for Scrum to be used in increasingly more complex environments.

3 Safety Critical Software Development

Typically, some version of the V-model is used to guide design, implementation, testing, and validation. As part of each sprint's sprint review, the product backlog may be updated.

Fig. 1. The V-model
Fig. 1. The V-model

5 A SafeScrum Case

RMsis, a plug-in for Jira, was used to establish traceability of the requirements management process. Stash and Git were used to manage software versioning and code reviews, and Bamboo was used for continuous builds, testing, and release management.

6 The Need for Extra Attention to Quality Management

Answer: You need to define something that is useful to you and argue why - the standard does not specify this. Overall, it became apparent that the self-regulatory quality mechanisms in Scrum were overburdened and that the QA function needed to be strengthened.

7 Shaping an Embedded QA Role in SafeScrum

He referred to part 7, chapter C.2.9: “a software module must have a single, well-defined task or function to perform”. The assessor recommended 1000 LOC as the upper limit. There should be a list of what criteria team members must have done before the issue can be decided as resolved, and QA should check that they are met (not do it themselves).

8 Conclusions

Our study consisted of the following three scales: (1) the Short Dispositional Flow State Scale (SDFS-2) [8] used in its entirety, (2) parts of the Intrinsic Motivation Inventory (IMI) [9] including questions regarding interest/pleasure, perceived competence, effort/importance, and perceived choice, and (3) a UX scale consisting of the short version of the AttrakDiff-2 (SAD-2) [10] used in its entirety and our proprietary Developer Experience Scale (DEXI). Aesthetic design was related to the screen layout and the outlook and visual design of the IDE.

Table 1. SDFS-2 scale. Dimensions of state of flow and related survey items [8]
Table 1. SDFS-2 scale. Dimensions of state of flow and related survey items [8]

On the Impact of Mixing Responsibilities Between Devs and Ops

In this article, we present how one particular organization adopted DevOps and what the impact of this adoption was from the perspective of engineers. In particular, we study the impact of mixing responsibilities between development and operations personnel, and how this affects culture, tools and work practices.

2 Background: Approaches to DevOps Adoption

This way, the Dev and Ops responsibilities are maintained, but communication and collaboration are promoted. It is also mentioned in [12] that although promoting communication and collaboration is key, training for Developers and Operations about the responsibilities of other departments can be very beneficial for communication.

3 Research Questions and Study Design

Interview recordings were transcribed, coded and analysed, and some results from that round are reported in [9]. First, the transcripts were read and summarized to get a quick overview of the topics discussed in the interviews.

4 Results

Impact on Culture

Employees mentioned that Devs and Ops now collaborate on various tasks, as they now understand the importance of collaboration. Through collaboration, both Devs and Ops had become more trusting and understanding of the other.

Impact on Internal Development Tools

In addition, the closer collaboration and keeping Devs and Ops in sync was described as time-consuming. Ops had seen that Devs can do the operational tasks without jeopardizing service stability, and Devs had realized what Ops has to contend with to deploy their software.

Impact on Ways of Working

It was described that the combined effort of Devs and Ops has its own complications as more people making configuration and software changes leads to a higher chance of errors simply because the tools and processes to perform such changes have not emerged . One perceived problem was that technical systems were tied to specific APIs and developers and different development teams were given too much freedom to choose their own way of doing things.

5 Discussion

When both Devs and Ops independently make changes to configuration and software, there is a greater likelihood of errors, as long as the tools and processes to perform such changes are not improved. Due to the challenging operational tasks, Devs realized the importance of having automated infrastructure, but achieving it was described as extremely complicated in the case organization.

Arsonists or Firefighters? Affectiveness in Agile Software Development

Researchers are increasingly focusing their efforts on understanding how the human aspects of a technical discipline can affect the final results [3,7,11]. Research has focused on understanding how the human aspects of a technical discipline can affect the final results [3,7,11] and the effect of politeness [14,23,25].

3 Experimental Setup


The authors found that the top-famous authors were more extroverted and expressed less negative emotion than authors of downvoted posts. This will allow the team members to feel satisfied with the work performed by the team without reducing the quality of the software products being developed.

Affective Metrics

For each issue in our data set, we built a temporal series of comments and, using the two tools, assigned a politeness and sentiment value to each comment in the series. Next, for each issue, based on the first comment posted, we calculated the probability of having a polite/impolite/neutral subsequent comment (for politeness) and a positive/neutral/negative comment (for sentiment).

Affective Markov Chains

The tool also provides a level of confidence related to the probability of being assigned a politeness class. The presence of emotion in software engineering artifacts was investigated by Murgia et al.

4 Results and Discussion

Do Developers Change Behaviour in the Context of Impolite/Negative Comments?

It is interesting to see that the probability of staying in a "rude" state is only 13% (much lower than the probability of staying in the "neutral" and "kind" states) and that there is a 70% probability of a moving from “unkind” to “neutral.” Figure 3 shows MC Sentiment which describes the probability of changing from one state to another.

Figure 2 shows the Politeness’ MC describing the probability of changing from a state to another
Figure 2 shows the Politeness’ MC describing the probability of changing from a state to another

What is the Probability of Shifting from Comments Holding Positive Emotions to Comments Holding Negative Emotion?

Ortu, M., Destefanis, G., Murgia, A., Marchesi, M., Tonelli, R., Adams, B.: The JIRA repository dataset: Understanding social aspects of software development. The survey was posted on LinkedIn; there was no control for the researchers regarding external validity (ie, the general applicability of the results).

Table 2. Transiction matrix for emotion MC
Table 2. Transiction matrix for emotion MC

Key Challenges in Software Startups Across Life Cycle Stages

Based on this observation, our study aims to provide a thorough and comprehensive understanding of the key challenges in software startups. RQ: what are the main challenges faced by software startups at different stages of learning and product development.

2 Literature Review

Challenges in Software Startups

However, current Software Engineering (SE) literature offers a very limited understanding of the challenges in the context of software startups. Since the focus of the study is limited to early-stage software startups, a full picture of the challenges faced by software startups at different stages is lacking.

Startup Life Cycle Stages

A study addressing the challenges of early-stage startups is by Bosch et al. Another study focuses on the specific challenges software startups face in relation to user experience design, an increasingly important aspect of software engineering.

3 Research Approach

Background of the Sampled Software Startups

In addition to the traditional titles of the chief officer, there are also "CXO" (Chief user eXperience Ocer), "COO". Chief Operation Officer), "CPO" (Chief Product Officer), etc. Some interesting titles reflect the characteristics of entrepreneurs, such as "All the hats", "jack of all trades", "General Specialist", "do-it-all", "all-in-one", "all rounder", or

Key Challenges Across Life Cycle Stages

Key Challenges in Software Startups Across Life Cycle Stages 177 tests the second and third biggest challenges perceived by software startups at different stages of learning and product development. The survey data provides a snapshot of the challenges faced by different software startups at different stages.

Table 2. Overview of key challenges perceived by software startups
Table 2. Overview of key challenges perceived by software startups


Appendix A Key Survey Questions

Appendix B Challenges Perceived by Software Startups at Different Learning Stages: Frequency Table

Bosch, J., Holmstr¨om Olsson, H., Bj¨ork, J., Ljungblad, J.: The early stage software startup development model: A framework for operationalizing lean princips in software startups. Ries, E.: The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radiically Successful Businesses.

Fig. 3. The fi nal setup:
Fig. 3. The fi nal setup:

Hình ảnh

Fig. 1. Communication network in H-umus.
Fig. 2. Communication network in Smart Campus.
Fig. 1. Relevant themes of large-scale agile planning concern technical abilities as well as context of planning
Table 1. Description of the companies and the representatives that we met with.

Tài liệu tham khảo

Tài liệu liên quan

Quá trình hội nhập kinh tế thế giới của Việt Quá trình hội nhập kinh tế thế giới của Việt Nam đã tạo ra những cơ hội và thách thức Nam đã tạo ra những cơ hội và