Catálogo de publicaciones - libros

Many software engineering organizations around the world are adopting DevOps. One of the goals of DevOps is to foster better collaboration between development and operations personnel, in order to improve organizational efficiency. Since DevOps is lacking a common definition, there are several approaches to adopt it, and organizations largely need to determine how to apply DevOps for themselves. In this paper, we present results from a case study in which a software organization adopts DevOps. The focus of this research is to study the impact of mixing the responsibilities between development and operations engineers. We interviewed 14 employees in the organization during the study, and results indicate several benefits of the chosen approach, such as improved collaboration and trust, and smoother work flow. This comes at the cost of a number of complications, such as new sources for friction among the employees, risk for holistically sub-optimal service configurations, and more.

In this paper, we present an analysis of more than 500 K comments from open-source repositories of software systems developed using agile methodologies. Our aim is to empirically determine how developers interact with each other under certain psychological conditions generated by politeness, sentiment and emotion expressed within developers’ comments. Developers involved in an open-source projects do not usually know each other; they mainly communicate through mailing lists, chat, and tools such as issue tracking systems. The way in which they communicate affects the development process and the productivity of the people involved in the project. We evaluated politeness, sentiment and emotions of comments posted by agile developers and studied the communication flow to understand how they interacted in the presence of impolite and negative comments (and ). Our analysis shows that “firefighters” prevail. When in presence of impolite or negative comments, the probability of the next comment being impolite or negative is 13 % and 25 %, respectively; however, has a probability of 40 % of being followed by a further comment. The result could help managers take control the development phases of a system, since social aspects can seriously affect a developer’s productivity. In a distributed agile environment this may have a particular resonance.

In the last decade, Kanban has been promoted as a means for bringing visibility to work while improving the software development flow, team communication and collaboration. However, little empirical evidence exists regarding Kanban use in the software industry. This paper aims to investigate the factors that users perceive to be important for Kanban use. We conducted a survey in 2015 among Kanban practitioners in the LeanKanban LinkedIn community. The survey results consist of 146 responses from 27 different organisations, with all respondents being experienced in using Kanban. The results show that practitioners perceived Kanban as easy to learn and useful in individual and team work. They also consider organisational support and social influence to be important determinants for Kanban use. Respondents noted various perceived benefits for using Kanban, such as bringing visibility to work, helping to reduce work in progress, improving development flow, increasing team communication and facilitating coordination. Despite the benefits, participants also identified challenges to using Kanban, such as organisational support and culture, difficulties in Kanban implementation, lack of training and misunderstanding of key concepts. The paper summarises the results and includes a discussion of implications for effective deployment of Kanban before describing future research needs.

Software startups are challenging endeavours, with various road blocks on their path to success. The current understanding of the challenges that software startups may encounter is very limited. In this paper, we use the research framework of learning and product development stages to analyse the key challenges that software startups have to deal with at different life cycle stages, from problem definition to solution validation and from concept to mature product. Based on an analysis of the empirical data collected by a large survey of 4100 startups, we find out that what perceived as biggest challenges by software startups do vary across different life cycle stages. Building product is the biggest obstacle for software startups, even though its significance decreases when the learning focuses of the startups move from problem to solution and their products mature. Business related challenges such as customer acquisition and scaling are more noticeable at the later stages. Our study raises the awareness of these challenges and suggests to tackle right challenges at the right time.

The Mob Programming technique proves to be an effective learning instrument with a group of less experienced developers. It is also used to explore topics outside of just software development.

This paper describes how, with a set of weekly Mob Programming sessions, the teams as a whole and all its individuals have grown much faster than they could have done otherwise. They improved their coding skills, mastery of tools, involvement in Scrum ceremonies, estimation skills, process modeling (!) and learned to be much more self-sufficient.

This didn’t happen without plenty of experimentation, and some dead ends. I will describe the different approaches we tried, how we ended up with a surprisingly strict process for our mobbing sessions, and how acceptance was easier with a team that had fewer ingrained habits of work.

Agile development with continuous integration and constant releases is only sustainable followed by a rock solid quality process. At blip/betfair we work very hard to build and continuously improve our quality process to provide at the same time a unique reliability experience to our customers and new features fast. Three major components of this process are: to help us learn more about our product and represent our knowledge about it in a structure way, that must be free and creative and happen as soon as possible in the process to allow fast feedback cycles and with high levels of automation testing to avoid regression. Agile development with continuous integration and constant releases is only possible with a rock solid quality process.

Organizations take up agile transformation as silver bullet for all their business problems, but the fact is transformation journey is an eye opener to discover the real problems which were previously unnoticed. The authors were part of such a journey. It’s easy to reap the obvious benefits of agile, but difficult to sustain and solve systemic obstacles like long build time, complex code base and legacy architecture that become a way of life over a long period of time. Here we describe the challenges we faced in sustaining our transformation beyond early victories and our efforts towards identifying and solving systemic obstacles across the organization by setting up an effective CI environment and addressing top people issues.

Kainos is a software company based in Belfast, Northern Ireland. As well as bespoke development, its work includes service contracts for the maintenance of software created elsewhere. This type of work is challenging because of the knowledge transition involved. The experience reported here is of tackling such projects in a way that integrates with the agile processes of the client. Background on agile practice in Kainos is discussed before focusing on a specific project for the UK Government Cabinet Office.

In 2012 the University of Vienna started a project, named Student Service Portal (SSP), to create a new portal for the universtiy´s students, university teachers, and administrative staff. The university signed a fixed price project with an external main contractor. Although a lot of effort was put into writing detailed requirements documents, it remained unclear what the exact scope was. Project management was lacking, technical problems arose, and finally the university and the supplier got caught up in each other’s blame instead of working together. After two years without tangible results the rectorship of the university stopped the project and ordered a restart – this time with an agile approach. The main contractor was replaced. The IT and the business department took over full responsibility for the product together.

This paper continues telling the story begun in “It has been a long journey, and it is not over yet” (published in , Helsinki – 2015). This experience report tells the tale of the quest to define the role of the architect and of architecture in an agile environment. The primary observation here is that people skills are a key factor in that role.