Pesquisa de perfis de empresas do interior de São Paulo, cidade de Ribeirão Preto, que utilizam a Dívida Técnica do Scrum e de como o fazem uso

Transcrição

1 2011 Pesquisa de perfis de empresas do interior de São Paulo, cidade de Ribeirão Preto, que utilizam a Dívida Técnica do Scrum e de como o fazem uso Arthur Gera Orientador Profº Marcos Danilo Chiodi Martins 8º Semestre - Ciência da Computação UNISEB 20/11/2011

2 PESQUISA DE PERFIS DE EMPRESAS DO INTERIOR DE SÃO PAULO, CIDADE DE RIBEIRÃO PRETO, QUE UTILIZAM A DÍVIDA TÉCNICA DO SCRUM E DE COMO O FAZEM USO Arthur Gera Resumo Centro Universitário UNISEB Ribeirão Preto SP arthur.gera@gmail.com Com o crescente aumento da complexidade de problemas exigidos de profissionais da computação, fica quase impossível a total compreensão do problema logo nos primeiros contatos. Diversas metodologias já foram utilizadas a fim de se maximizar essa compreensão com o menor tempo possível. Assim a produção de software ocorre em pequenas iterações, mas que em cada uma já é registrado o conhecimento da equipe no produto, mesmo que seja de forma parcial, o que implica uma futura refatoração do código quando o domínio do problema for melhor compreendido. Esta refatoração do código refletindo o atual conhecimento da equipe é denominada Dívida Técnica. Palavras chaves: Dívida Técnica, Scrum, Metáfora da Dívida. Abstract With the increasing complexity of issues required for computer professionals, it is almost impossible to fully understand the entire problem in the first few contacts. Several methodologies have been used in order to maximize this understanding with the shortest time possible. So the software production occurs in few iterations, but each one is already recorded the team's knowledge in the product, even partially, implying a future refactoring of the code when the problem domain is better understood. This refactoring the code reflecting the current knowledge of the team is called Technical Debt. Keywords: Technical Debt, Scrum, Metaphor Debt.

3 PESQUISA DE PERFIS DE EMPRESAS DO INTERIOR DE SÃO PAULO, CIDADE DE RIBEIRÃO PRETO, QUE UTILIZAM A DÍVIDA TÉCNICA DO SCRUM E DE COMO O FAZEM USO Arthur Gera 1 Marcos Danilo Chiodi Martins 2 1. INTRODUÇÃO Segundo MCT (2009), a produção de software no mercado nacional tem crescido rapidamente. O número de organizações brasileiras no setor de produção de software aumentou de cerca no ano de 2005 para pouco mais de no ano de 2007, um aumento de 47,6% comparado ao ano de No mercado internacional este cenário não é diferente. Segundo Chiavenato (2004), a busca constante por melhoria nos processos é o principal foco para se manter ou ampliar as vendas em um mercado com tanta concorrência. 1.1 Contextualização Segundo Takeuchi e Nonaka (1986), as regras de desenvolvimento mudaram de um cenário no qual o time 1 Bacharelado em Ciência da Computação pelo Centro Universitário UNISEB. 2 Profº. Orientador docente do Centro Universitário UNISEB na área de Engenharia de Software. desenvolvia de forma sequencial, de fase a fase do projeto para um desenvolvimento ágil, com constantes iterações e incrementos do inicio ao fim do projeto. Takeuchi e Nonaka perceberam que equipes pequenas e multidisciplinares, obtinham os melhores resultados e fizeram uma associação com a estratégia Scrum utilizada no jogo de Rugby, na qual o time se move em direção ao objetivo como uma única unidade. O Scrum fora concebido e implementado por Jeff Sutherland, John Scumniotales e Jeff McKenna na Easel, 1993 (Sutherland, J. 2007), mas somente em 1995 Ken Schwaber formalizou a definição do Scrum ajudando a implementação deste no desenvolvimento de software. Segundo Takeuchi e Nonaka (1986), já fora observado que outras empresas como Fuji-Xerox, Honda e Canon já estavam utilizando um processo ágil, um processo iterativo e incremental. Entretanto, neste cenário de desenvolvimento ágil, existem armadilhas. Segundo Ward Cunningham (1992), a principal armadilha é a falha na

4 consolidação do código seja por produção de código imaturo ou por falta de documentação. Tal imaturidade produz um produto inflexível e que precisa de programadores cada vez mais especializados. A produção e entrega de um primeiro código imaturo leva a aceitação de uma dívida, que posteriormente deverá ser paga e com juros. 1.2 Justificativa Sendo assim, a pesquisa de algumas empresas que utilizam o Scrum e que usam a Dívida Técnica, é interessante para ver se quando existe a produção de código imaturo, sujo, ou entregas sem documentação, enfim quando se produz qualquer tipo de dívida se esta é paga nas próximas iterações e como tais empresas vem fazendo isso. 1.3 Objetivo Assim tem-se como objetivo realizar uma pesquisa a fim de se avaliar como empresas do interior de São Paulo, município de Ribeirão Preto, utilizam a Dívida Técnica e assim fazer a devida análise dos dados obtidos. 2. Engenharia de Software Engenharia de software é uma disciplina da engenharia cujo foco é o desenvolvimento de software com alta qualidade e com melhor custo-benefício (Sommerville, 2007). Começou-se a falar em engenharia de software no ano de 1968 em uma conferência para discutir de forma a acabar com a chamada crise do software. 2.1 Crise de Software A constante evolução do hardware até a década de 1960 em paralelo com uma estagnação do tipo de software produzidos fez com que os softwares produzidos não utilizassem todo o desempenho que o hardware fornecia. Sistemas mais complexos eram cada vez mais requisitados, mas o desenvolvimento atrasava algumas vezes anos além do fato do custo do software ir muito além do previsto. O código era na maioria das vezes ilegível, de difícil manutenção e de baixo desempenho. Portanto o desenvolvimento de software estava em crise. (Sommerville, 2007).

5 2.2 Processos de Software A engenharia de software surgiu na tentativa de se fazer softwares com melhor qualidade em um tempo menor de acordo com alguns processos que tentam acelerar esta produção. Estes processos são um conjunto de atividades que levam a produção de um produto de Software. Estas atividades podem envolver o desenvolvimento do software, a modificação ou ampliação de um software pré-existente (Sommerville, 2007). 2.3 Modelos de Processo de Software Os processos seguem alguns modelos de processos de software que contém basicamente algumas atividades comuns a elas como: Engenharia de Requisitos: Análise do problema e levantamento de requisitos feito por consulta aos usuários do software, formando assim uma especificação do sistema. Projeto: Identificação das formas abstratas do sistema por meio de diagramas, como Diagrama Entidade Relacionamento (DER), Diagrama de Classes, Diagrama de Fluxo de Dados (DFD)... Codificação: Nesta fase do desenvolvimento, são codificadas, são transformados em unidades de código os diagramas feitos na fase de projeto. Junto a codificação são realizados testes unitários para verificar se a unidade de programa feita está de acordo com os requisitos levantados na primeira atividade. Testes e integração: Integração dos programas e teste do sistema completo validando os requisitos. Após a validação o software é liberado para o cliente. Manutenção: Correção de erros, aprimoramentos e ampliação de serviços 3. O Scrum O que se decorrer neste capitulo será discutido segundo Schwaber, K; Sutherland, J (2011). O Scrum é um framework de gerenciamento de projetos ágeis que utiliza uma abordagem iterativa e incremental de tal forma que permite ao desenvolvedor a produção de sistemas complexos em tempos reduzidos, com alto valor comercial.

6 Este não é um processo, diz apenas o que deve ser feito em cada fase do projeto, e não como deve ser feito. Basicamente, o Scrum tem um ciclo de vida conforme mostrado na Figura 1. Figura 1 Adaptato de: view Com a Sprint em andamento, monitora-se o andamento da equipe realizando uma reunião diária na qual os membros do time basicamente discutem o que cada um fez desde a última reunião, o que cada um irá fazer até a próxima reunião e quais os problemas enfrentados. É uma reunião normalmente rápida, cerca de 15 minutos e feita em pé, fato que tal reunião também é chamada de Standup meeting. Para a monitoria da reunião diária, faz-se uso de um terceiro artefato, o gráfico Burndown. Ao se iniciar o planejamento da Sprint, estima-se a quantia que deve ser desenvolvida pelo tempo da Sprint. Pode-se notar que o processo começa com um planejamento daquilo que será entregue alimentando o backlog do produto, uma lista de atividades a serem realizadas até que o produto fique pronto. Porém o Scrum trabalha com tempos curtos, sprints, de duas a quatro semanas, no qual a equipe se compromete a produzir um incremento de produto potencialmente entregável. Assim no planejamento da Sprint, atividades são quebradas em micro atividades que possam ser realizadas no tempo de uma Sprint. Estas micro atividades são então reunidas no backlog da Sprint. Figura 2 Grãfico Burndown Previsão da Sprint Com as reuniões diárias, calcula-se a quantia restante com novo tempo e o gráfico é reconstruído recalculando-se o tempo estimado final.

7 Figura 3 Gráfico Brundown Comparativo de velocidade real e planejada Conforme visto na Figura 3, a projeção da data de entrega da versão pode ultrapassar a data predeterminada. Para não atrapalhar questões de prazo, o Scrum se faz uso da chamada Dívida Técnica que será discutida no próximo capitulo. 4. Dívida Técnica Um dos problemas do Scrum, quando mal administrado, é o conceito da Dívida Técnica. Esta dívida é assumida pela equipe quando necessita-se reduzir o que será produzido na Sprint para que esta termine no prazo estipulado e não haja atraso. Figura 4 A Dívida Técnica Acunhado por Ward Cunningham (OOPSLA 92) a dívida técnica, ou metáfora da dívida, é o que este explicou pela refatoração que vinham fazendo em seu produto WyCash. A dívida técnica é utilizada como uma analogia financeira e assim, quando se faz uso desta, os juros devem ser pagos assim que possível. Quando se projeta que a equipe esta comprometida com o tempo predeterminado, esta retira algumas tarefas de modo a entregar no prazo aquilo que refletia o entendimento da equipe, mesmo que de forma parcial. Neste caso tem-se uma decisão consciente, a dívida é tomada taticamente. A dívida também pode incorrer sem que haja conhecimento pela equipe, como no caso de codificação ruim por parte de programadores juniores. Cunningham nunca defendeu a escrita ruim, ao contrário, sempre se mostrou preocupado com a escrita do código de tal forma que este represente sempre o grau de conhecimento que a equipe tenha a respeito do produto, mesmo que este seja parcial, o que ajuda na hora de pagar a dívida, ou seja, facilita a refatoração do código. Tão logo a Dívida seja assumida qualquer produção de código nas próximas iterações deve ser utilizada para sanar a

8 Dívida, melhorando o conhecimento a cerca do problema e refatorando o, refletindo o novo conhecimento deste. 5. Materiais e métodos Será realizado uma pesquisa em cerca de 5 empresas, que façam uso do Scrum, do interior de São Paulo, município de Ribeirão Preto, na forma de um questionário com alternativas a fim de se avaliar se usam e como fazem uso da artifício da Dívida Técnica do Scrum. Tal questionário será então tabulado e serão plotados, com auxilio do Excel, gráficos de barras, gráficos em pizza, gráficos em linhas com a finalidade de expor de maneira clara como está sendo utilizada e tratada a Dívida por este grupo de empresas. Essa pesquisa terá caráter meramente acadêmico e portanto todos os entrevistados estarão cientes de que não será mencionado o nome da empresa muito menos dos entrevistados.

9 6. REFERÊNCIAS CHIAVENATO, I., Introdução à Teoria Geral da Administração. 7ª ed. Rio de Janeiro: Elsevier, p. CUNNINGHAM, W. The WyCash Portfolio Management System. OOPSLA, Disponível em: Acessado em: 21/07/2011. MAR, K., Technical Debt and Design Death, Scrum Alliance, Disponível em: Acessado em: 22/07/2011. MCT. MINISTÉRIO DE CIÊNCIAS E TECNOLOGIA., Pesquisa de qualidade no setor de software brasileiro Brasília: Ministério de Ciências e Tecnologia. Secretária de Política de Informática p. SOMMERVILLE, I., Engenharia de Software. 8ª ed. São Paulo: Pearson, p. SUTHERLAND, J., et al, Distributed Scrum: Agile Project Management with Outsourced Development Teams. Disponível em Acessado em 22/04/2011. TAKEUCHI, H., NONAKA, I., The New New Product Development Game, Harvard Business Review, Jan-Fev, 1986.