Defesa de Tese de Doutorado de Felipe Curty do Rêgo Pinto, em 15/12/2023, às 14:00 horas, na sala 310 do Instituto de Computação e por videoconferência

Defesa de Tese de Doutorado de Felipe Curty do Rêgo Pinto, em 15/12/2023, às 14:00 horas, na sala 310 do Instituto de Computação e por videoconferência

Será defendida no dia 15 de dezembro de 2023, às 14:00 horas, na sala 310 do Instituto de Computação e por videoconferência, a Tese de Doutorado intitulada “On the Impact of Rapid Releases in the Development Duration and Collaboration”, do candidato ao título de Doutor em Computação – Felipe Curty do Rêgo Pinto.

 

Link para defesa: https://meet.google.com/hie-jobb-zpf

 

On the Impact of Rapid Releases in the Development Duration and Collaboration

Resumo:

 

Alcançar um ciclo de releases rápidas é um requisito para a maioria dos métodos de desenvolvimento ágeis e enxutos. Um ciclo de releases rápidas permite que os desenvolvedores recebam feedback antecipado sobre as funcionalidades entregues e ajustem o planejamento para adaptar melhor as necessidades dos clientes. No entanto, a literatura provê poucas evidências sobre as estratégias adotadas pelos projetos para lidar com entregas de releases rápidas. As releases rápidas são desenvolvidas rapidamente, em equipes grandes e mais ativas, tanto em termos de contribuições quanto de contribuidores, ou as equipes desenvolvem releases em paralelo para passar a percepção de releases rápidas para os usuários? Esse trabalho coletou evidências sobre os benefícios e prejuízos em adotar releases rápidas em relação a duração do desenvolvimento e a colaboração. Nós analisamos um corpus contendo 1.039 projetos relevantes de código aberto, com 13.102 releases rápidas e 7.071 Releases tradicionais (sem contar os patches), totalizando 20.173 releases com 3.167.563 commits. Nós desenvolvemos uma infraestrutura para minerar releases que cobre os passos necessários para extrair informações das releases e analisar um corpus com essa magnitude. Nós também criamos uma estratégia para associar commits e releases, chamada history-based strategy, a qual supera a maioria das limitações observadas nas estratégias existentes. Finalmente, nós comparamos as releases rápidas e tradicionais do nosso corpus para entender as mudanças em relação à duração do desenvolvimento, intervalo para iniciar o desenvolvimento, percentual de commits no ciclo da release, número de commits por dia, número de colaboradores principais, produtividade do desenvolvimento e número de novos colaboradores. Nós descobrimos que, na maioria dos casos, a duração do desenvolvimento das releases rápidas é maior do que o ciclo da release, o que significa que a maioria dos projetos entregam releases rápidas fazendo uso de desenvolvimento de releases em paralelo. No entanto, na média, a quantidade de trabalho realizado em paralelo tem pouco impacto no desenvolvimento da release. O desenvolvimento das releases rápidas começa antecipadamente e sem atrasos. O desenvolvimento das releases tradicionais é normalmente precedido por uma pausa, provavelmente para o desenvolvimento de patches e estabilização da release. Além disso, o desenvolvimento das releases rápidas é mais ativo, i.e., os colaboradores principais contribuem mais frequentemente. Entretanto, os projetos adotam equipes menores para desenvolver releases rápidas. Por isso, apesar da produtividade do desenvolvimento se maior, as releases rápidas possuem menos colaboradores novos contribuindo para o seu desenvolvimento. Esses resultados expandem o conhecimento sobre releases rápidas. Eles também podem ajudar projetos que possuem intenção de transicionar de releases tradicionais para rápidas. Por exemplo, o projeto pode começar o desenvolvimento antecipadamente e gerenciar o desenvolvimento paralelo de releases para alcançar um ciclo de releases rápidas. Um projeto pode também gerenciar o tamanho da equipe para manter contribuições frequentes e aumentar a produtividade do desenvolvimento.

 

Abstract:

 

Achieving a rapid release cycle is a requirement for most agile and lean development methods. A rapid release cycle allows developers to have early feedback about the delivered features and adjust the development plans to better adapt to the customers’ needs. However, the literature provides little evidence about the strategies adopted by projects to manage delivering rapid releases. Are the releases rapidly developed, with a larger and more active team, respectively in terms of contributors and contributions, or do teams manage to develop multiple releases in parallel to provide the perception of rapid releases to the users? This work collected evidence about the benefits and impairments of adopting a rapid release cycle in the development duration and collaboration. We analyzed an corpus comprising 1,039 relevant open-source projects, with 13,102 rapid releases and 7,071 traditional releases (without counting the patches), totaling 20,173 releases with 3,167,563 commits. We developed an infrastructure to mine releases that covers the steps required to extract release information and analyze such a large project corpus. We also created the history-based strategy to assign commits to releases, which overcomes most of the limitations observed in the existing strategies. Finally, we compared the rapid and traditional releases of our corpus to understand changes regarding the development duration, development start delay, percentage of commits in the release cycle, number of commits per day, number of main collaborators, development productivity, and number of newcomers. We discovered that, in most cases, the development duration of rapid releases is higher than its release cycle, meaning that most projects delivering rapid releases employ parallel release development. However, on average, the amount of work done in parallel has a small impact on the release development. The development of rapid releases starts early and without delays. Traditional releases’ development is generally preceded by a pause, probably due to patch development and release stabilization. Moreover, the development of rapid release is more active, i.e., the main collaborators contribute more frequently. Nonetheless, the projects adopted smaller teams to develop rapid releases. Thus, despite having higher development productivity, the rapid releases have fewer newcomers contributing to its development. These results expand knowledge about rapid releases. They also may help projects willing to transition from traditional to rapid releases. For instance, the projects may start the release development early and manage parallel release development to achieve a rapid release cycle. Also, the projects may manage the team size to keep frequent contributions and increase the development productivity.

Banca  examinadora:

 

Prof. Leonardo Gresta Paulino Murta, UFF – Presidente

Prof. Marcos de Oliveira Lage Ferreira, UFF

Profa. Vânia de Oliveira Neves, UFF

Profa. Tayana Uchôa Conte, UFAM

Prof. Marcos Kalinowski, PUC-Rio