gelsimar machado da cunha implantando metodologias Ágeis ... · metodologias ditas ágeis, scrum e...

0

GELSIMAR MACHADO DA CUNHA

IMPLANTANDO METODOLOGIAS ÁGEIS, HÍBRIDAS, NO

DESENVOLVIMENTO DE SISTEMAS COMPUTACIONAIS, COM EQU IPES

TRABALHANDO EM UM AMBIENTE SEM PADRONIZAÇÃO NOS PRO CESSOS

DE TRABALHO

CANOAS, 2012

1





DE TRABALHO

Trabalho de conclusão de curso apresentado à banca examinadora do Curso de Ciência da Computação do Centro Universitário La Salle – Unilasalle, como exigência parcial para a obtenção do grau de Bacharel em Ciência da Computação.

Orientação: Profº Me. Abraham Lincoln Rabelo De Sousa

CANOAS, 2012

2





DE TRABALHO.

Trabalho de conclusão aprovado como requesito parcial para obtenção do grau de bacharel em Ciência da Computação pelo Centro Universitário La Salle – Unilasalle.

Aprovado pela banca examinadora em 03 de julho de 2012.

BANCA EXAMINADORA:

__________________________________________________

Profº Me. Roberto Petry

Unilasalle

__________________________________________________

Profº Me. Abraham Lincoln Rabelo De Sousa

Unilasalle

__________________________________________________

Profº Me. Gustavo Passos Tourinho

Unilasalle

3

À minha mãe Marli (in memoriam), que se foi durante a escrita deste trabalho e não pode realizar nosso sonho em vida.

4

AGRADECIMENTOS

Agradeço à minha esposa, Daiana, pelo amor e dedicação com que cuidou de nós dois

durante esta caminhada.

Agradeço aos meus amados pais, Marli (in memoriam) e Amaro, pela oportunidade de

estudar durante minha infância e por permitirem que eu desenvolvesse o gosto pelo

aprendizado contínuo.

Agradeço ao meu estimado professor Valter Nei Da Silva, o maior incentivador na

minha eterna busca pela minha vocação.

Agradeço ao meu orientador, Lincoln, pelo norte na definição deste trabalho e por

todo o apoio e tempo dedicados na conclusão do mesmo.

Agradeço a todos os professores que contribuíram de forma inestimável ao

enriquecimento de meu conhecimento e pelo direcionamento da minha atenção.

Agradeço ao Unilasalle, empresa em que trabalho, por disponibilizar um ambiente

para o estudo de caso proposto neste trabalho.

5

“Tudo o que a sua mão encontrar para fazer,

faça-o com todo o seu coração.”

(JESUS DE NAZARÉ)

6

RESUMO

A engenharia de software, ao contrário das engenharias tradicionais e milenares, não é capaz

de fornecer cronogramas num ambiente de desenvolvimento, de forma precisa e rígida. Em

diversos projetos, semelhantes, os dados para estimar prazos e recursos, mostram-se muito

voláteis e dificultam de maneira feroz a possibilidade de definição de prazos de conclusão ou

até mesmo, datas para entregas parciais do produto solicitado pelo cliente. Entre as diversas

causas para isso, destacam-se a dependência da criatividade da equipe desenvolvedora, a

baixa habilidade do cliente em descrever suas funcionalidades, a pouca experiência da equipe

de análise em entender do negócio específico do cliente e o alto acoplamento entre os

módulos que são desenvolvidos com o tempo. O surgimento de metodologias ágeis prometia a

solução para este problema, tratando a engenharia de software como algo muito mais

dependente da experiência dos projetistas e da aceitação, antecipada, das mudanças

necessárias no projeto. Neste sentido, são diminuídas tarefas de análise e projeto de um

sistema, entrando diretamente em reuniões informais com os stakeholder partindo para a

codificação propriamente dita. Partindo desta premissa, analisou-se durante 12 meses o

comportamento de uma equipe de desenvolvimento, que não adotava padrões nos processos

internos, quando a mesma equipe passou a implementar as soluções propostas por duas

metodologias ditas ágeis, Scrum e EXtreme Programming. Verificou-se se foi possível

implementar estas metodologias em um cenário sem planejamento algum, de forma a ganhar

produtividade de forma substancial.

Palavras-chave: Métodos ágeis. Gerenciamento de projetos e equipes. Engenharia de

software. Implementação de Scrum e XP.

7

ABSTRACT

Software engineering, instead the traditional engineering and ancient, is not able to provide

schedules in a development environment in a precise and rigid. In several projects, similar, the

data to estimate time and resources, proved to be very volatile and difficult so ferociously the

possibility of setting deadlines for completion or even dates for partial deliveries of the

product requested by the client. Among the various reasons for this, we highlight the

dependence on the creativity of the developer team, the lower the client's ability to describe its

features, the limited experience of the analysis team to understand the client's specific

business and the high coupling between the modules that are developed. The appereance of

agile methodologies, promised a solution to this problem, treating software engineering as

something far more dependent on the experience of designers and acceptance, early, the

necessary changes in design. In this sense, are decreased tasks of analysis and design of a

system, going directly to an informal meeting with stakeholder and for the coding itself.

Starting from this premise, we analyzed the behavior during 12 months of a development

team, which did not adopt the standards process internal, when the team went on to

implement the solutions for two proposals said agile methodologies, Scrum and Extreme

Programming. We wanted to see if you can implement these methodologies in a scenario

without any planning, in order to gain productivity substantially.

Keywords: Agile methods. And project management teams. Software engineering.

Implementing Scrum and XP.

8

SUMÁRIO

1 INTRODUÇÃO .................................................................................................................................. 9

1.1 Dificuldades em planejar, controlar e executar .......................................................................... 12

2 FUNDAMENTAÇÃO TEÓRICA .................................................................................................. 15

2.1 Gerência de projetos ..................................................................................................................... 15

2.2 Metodologias ágeis......................................................................................................................... 16

2.3 Medidas, medições e métricas ...................................................................................................... 17

2.4 Estimativas ..................................................................................................................................... 18

3 TRABALHOS RELACIONADOS ................................................................................................. 21

3.1 Estudo de caso para compreensão da equipe .............................................................................. 21

3.2 Estudo de caso com vantagens e desvantagens dos métodos ágeis ............................................ 21

3.3 Principais diferenciais geradores de agilidade. .......................................................................... 22

4 PROGRAMA DE MEDIÇÃO ......................................................................................................... 23

4.1 Cenário, problema contextual ...................................................................................................... 23

4.2 Ambiente e forma de análise propostos ....................................................................................... 24

4.3 Como nós estimamos ..................................................................................................................... 26

5 RESULTADOS E AVALIAÇÃO ................................................................................................... 28

5.1 Resumo dos dados ......................................................................................................................... 28

5.2 Dados coletados ............................................................................................................................. 29

5.2 Análise qualitativa dos dados ....................................................................................................... 41

6 CONSIDERAÇÕES PRÓPRIAS .................................................................................................... 46

7 CONCLUSÃO E TRABALHOS FUTUROS................................................................................. 48

REFERÊNCIAS .................................................................................................................................. 52

9

1 INTRODUÇÃO

Ao nos deparamos com a clássica descrição da restrição tripla, figura 1, definida pelas

práticas de gerenciamento de projeto, a saber, prazo, escopo e custo, podemos observar que

qualquer alteração em uma das arestas deste triângulo afetará o projeto como um todo. O PMI

defende que uma vez definido o escopo de um projeto ainda na fase de análise, caso o mesmo

seja alterado, compromete-se todas as outras atividades previstas na execução do projeto.

Desta forma, é entendido que o projeto precisa ser revisto a cada ponto de checagem definido,

mas que, não pode sofrer alterações profundas em suas definições iniciais, sob-risco de não

conseguir-se entregar aquilo que foi proposto inicialmente. Esta visão permite um maior

controle e gerenciamento das atividades sequenciais da execução do projeto, garantindo que

todas as tarefas foram definidas para atender um propósito inicialmente especificado e

validado pelos interessados no projeto.

O grande desafio surge quando o objetivo final do software é um produto inovador.

Torna-se difícil conceber a ideia final do produto a ser entregue, quando não possuímos um

histórico de desenvolvimento de produtos idênticos e sim similares. Segundo Amaral,

Conforto, Benassi e Araujo (2011, p. 7) “a inovação pode variar dependendo do observador”.

Nesta linha, se o produto final for um sistema computacional ou simplesmente software, a

inovação reside no fato de que o software a ser desenvolvido deverá apresentar diferenças

entre outros softwares existentes. A gerência de projetos, neste caso, torna-se uma tarefa com

um foco muito maior em estimativas do que definição de prazos, recursos e tarefas. Caso um

projeto seja definido seguindo o conjunto de boas práticas do PMI (2011, p. 6), por exemplo,

serão estimadas as etapas do projeto baseadas nos processos de gerência: Integração, escopo,

tempo, custo, qualidade, recursos humanos, comunicação, riscos e aquisições. Apesar de o

PMI recomendar que “o plano de gerenciamento do projeto é iterativo e passa por uma

elaboração progressiva no decorrer do ciclo de vida do projeto” (PMBOK, 2011, p. 13), a

revisão da elaboração inicial não pode comprometer os índices definidos antes do início do

projeto propriamente dito. O problema que surge nesta abordagem é a “tendência natural para

adaptar a realidade ao plano do projeto” (AMARAL et al., 2011, p. 113).

No centro desta restrição tripla da gerência de projetos, encontra-se um elemento que

teoricamente não deve ser alterado, mesmo quando as arestas são alteradas: A qualidade. A

teoria prega que, independente de alterações no prazo, escopo ou custo, a qualidade não é

negociável, “É responsabilidade, da equipe, manter a qualidade do sistema sob todas as

circunstâncias e isso simplesmente não é negociável. Nunca” (KNIBERG, 2007, p. 17). Mas a

10

prática tem mostrado exatamente o contrário. Ao enfrentar problemas com prazos que

excedem o previsto, custos que não estavam contabilizados e requisitos adicionais ao projeto

inicial, a qualidade é o primeiro item a ser manipulado em grande parte dos projetos, isto por

que, este item não é tangível de forma simples por parte do cliente. Esta manipulação não

ocorre de maneira pré-definida e sim de forma experimental. São relegadas ou encurtadas

fases de teste ou diminuídos os recursos gastos com dispositivos de segurança. Mas como

saber quando a qualidade foi relegada o suficiente para garantir o cumprimento do projeto nos

planos traçados inicialmente?

Com base nestas situações a abordagem utilizando metodologias ágeis no

gerenciamento de projetos, aparece como um complemento à teoria tradicional. Neste caso,

segundo Cohn, a manipulação do escopo do projeto surge como o mais viável e aconselhável

a ser feito, uma vez que, fazer menos, mas fazer melhor pode ser o diferencial técnico em um

cenário altamente competitivo. As metodologias ágeis apresentam uma série de técnicas para

prover uma maior flexibilidade na análise de requisitos e planejamento de um projeto.

Aliando estas técnicas a um projeto teoricamente inovador, temos uma combinação que

contempla a possibilidade de mudanças mais drásticas durante a execução do planejado.

Apesar de existir uma definição informal, de que é necessário optar entre uma

metodologia ágil ou a metodologia tradicional na gerência de projetos, este trabalho pretendia

demonstrar a viabilidade de adaptações que permitam a utilização de ambos os cenários, não

descartando os anos de evolução e estudos adquiridos com a gerência dita mais formal. Como

diz a frase atribuída a Isaac Newton “Se eu vi mais longe, foi por estar de pé sobre ombros de

gigantes”, é necessário que usemos o conhecimento adquirido com a gerência de projetos

tradicional, para que a aperfeiçoemos e possamos trazer a engenharia de software para mais

próximo da exatidão obtida com os outros ramos de engenharia. Unindo estas duas correntes,

gerência tradicional e gerência ágil, acreditamos ser possível melhorar a qualidade do produto

final, melhorar a interação e aceitação do cliente, bem como ter um plano de estimativas mais

centradas nas pessoas do que ditado por ferramentas.

Este trabalho tem como objetivo a aplicação de um programa de melhoria nos

processos de desenvolvimento, utilizando-se de metodologias ágeis, em um ambiente onde

não existe nenhuma metodologia que padronize os processos, que seja capaz de mensurar a

produtividade e que consiga resultar em software de qualidade. Para a aplicação desta

metodologia, são comparadas duas formas de trabalho, uma metodologia dita ágil e um

conjunto de boas práticas tradicionais (PMI), onde se pode observar a aplicação de uma

11

metodologia híbrida, formada pela junção de práticas e conceitos de duas metodologias ágeis

e verificar qual a aderência da mesma em um cenário sem vícios incorporados por outras

metodologias anteriores.

O ambiente que servirá de análise pode ser considerado puro, ou seja, não sofre

nenhum tipo de influência por alguma metodologia previamente implantanda. Além disso, as

características de equipe pequena favorecem a análise dos resultados de forma mais

minuciosa e com menos fatores externos que possam prejudicar a análise. Neste ambiente os

membros da equipe de desenvolvimento executam mais de uma tarefa, não se restringindo

apenas à programação, e sim adentrando em atividades de teste e análise de requisitos. Com

base nos dados coletados e analisados, sobre este ambiente, seremos capazes de fornecer uma

visão sobre a aderência de metodologias ágeis em um ambiente que se configura com certo

nível de caos, uma vez que, não existe uma padronização das atividades e não é regido por

uma metodologia específica.

Para aplicação deste estudo, foram estudadas três (3) metodologias ágeis (SCRUM,

EXtreme Pogramming e Kanban) e o conjunto de boas práticas de gerenciamento tradicional

de projetos (PMBOK). Após este estudo formulou-se uma metodologia híbrida, que continha

os aspectos mais relevantes, segundo conceito dos autores e bibliografia de casos de sucesso,

do SCRUM e do XP. Esta metodologia resultante foi aplicada diretamente no cenário real de

desenvolvimento de software e conforme o estudo avançou, foi possível coletar os resultados

mais relevantes para concluir se, a adoção de métodos ágeis realmente torna um ambiente

“cru” em um ambiente mais ágil.

Convém ainda definir que, toda vez que mencionarmos “projeto”, de forma simples

neste trabalho, estamos nos referindo a um projeto de desenvolvimento de software. Quando

houver a necessidade de referir-se a outro tipo de projeto, o faremos de forma explícita.

Este trabalho está organizado da seguinte forma: No capítulo 2, os principais conceitos

que envolvem estimativas, gerência de projetos tradicional e métodos ágeis. No capítulo3, são

apresentados os resultados de alguns trabalhos relacionados e que foram utilizados na

condução deste estudo. No capítulo 4, o ambiente de estudo e a forma de análise são

apresentados. No capítulo 5, os dados coletados são mostrados e são analisados os resultados

do estudo. No capítulo 6 são exibidas quais foram os aprendizados que o trabalho deixou

durante sua realização. Por fim, no capítulo 7, são feitas considerações finais sobre o trabalho,

incluindo uma indicação de possíveis trabalhos futuros.

12

Figura 1 – Restrição tripla

1

Fonte: PMI

1.1 Dificuldades em planejar, controlar e executar

Apesar de fazer parte do grupo de engenharias formais, a engenharia de software não

consegue usufruir e nem mesmo oferecer o mesmo grau de precisão que oferece, por

exemplo, a engenharia civil na construção de um novo prédio. Quando pensamos na

construção de um novo software ou na evolução de um software qualquer já existente, as

tarefas propostas pela equipe de engenharia apesar de serem metódicas e científicas, se

baseiam em alguns fatores que impedem a obtenção de uma precisão perfeita no que diz

respeito ao prazo, custo e alcance que o software projetado irá possuir na prática.

Um dos maiores entraves para a elaboração e planejamento de um projeto, com todas

as suas etapas de execução precisas é o grau de inovação proposto na construção de um

software. Por mais que um software aparente ter funcionalidades parecidas, senão iguais, a

outros já desenvolvidos, a construção de um novo produto sempre apresenta diferenciais que

são difíceis de serem formalizados com exatidão nas fases inicias do projeto. Muitas vezes a

definição de o que o software irá oferecer, é feita com base em declarações soltas do cliente

final e a interpretação que os engenheiros de software irão fazer em cima destas declarações.

Esta etapa, conhecida como definição de escopo, irá apresentar ao gerente do projeto o

clássico problema do cone da incerteza. Este problema se baseia na assertiva de que, quanto

mais na fase inicial um projeto estiver, maior é o grau de incerteza que o mesmo gera sobre o

que deveria ser entregue. O pensamento inverso é válido, onde sabemos que, quanto mais

trabalhamos no projeto, mais adquirimos conhecimento sobre aquilo que deveríamos estar

tentando entregar. Cohn define o conhecimento do projeto da seguinte forma: “Projects

generate two types of knowledge: knowledge about the product and knowledge about the

Project.”. Podemos então assumir que, em um projeto inovador, o conhecimento sobre o que

13

deve ser desenvolvido e como deve ser desenvolvido, somente será conhecido, com 100% de

certeza, ao final de um projeto bem sucedido.

As etapas de controle de um projeto não são menos incertas, quando o objetivo é

acompanhar o desenvolvimento do projeto: Como medir o progresso? Todo projeto, seja ele

de software ou não, necessita de pontos de checagem que permitam verificar se o produto que

está sendo desenvolvido é o correto, se está sendo feito da forma correta e se está no prazo

correto. De nada adiantará construir o projeto da forma mais rápida possível, menos custosa,

se o produto final não for o desejado pelo cliente. Como forma de analogia livre podemos

imaginar um atleta de maratona que, ao iniciar um prova ele desenvolve uma velocidade

superior aos demais, mas ao contrário dos outros que correm em direção ao sul, ele vai em

direção ao leste. Mesmo sendo o mais rápido entre todos os outros, ele não completará o

objetivo, pois, não correu na direção correta.

No desenvolvimento de um projeto, para as checagens terem efeito concreto é

necessária a definição de métricas que permitam verificar a eficiência da evolução daquilo

que foi planejado. Na engenharia de software, o uso de métricas passou por diversas tentativas

e evoluções, sendo que, ainda não se chegou a um indicador preciso e fácil de manusear. É

possível medir a complexidade de um software com base em cálculos matemáticos, mas é

muito difícil medir o quanto foi produzido de uma determinada funcionalidade do sistema.

Em geral existem indicadores como LOC (em desuso atualmente), pontos por função e casos

de uso, que dão uma ideia geral do panorama da execução da codificação do sistema, mas não

traduzem fielmente o estado atual do desenvolvimento, em virtude de basearem-se em

estimativas.

Outro ponto complexo num projeto é a execução do mesmo. A fase de concepção deve

ser precisa, do contrário, todo o tempo gasto com o projeto terá sido usado para desenvolver o

produto errado. Neste caso pouco adiantará ter sido feita a análise mais adequada possível, se

o desenvolvimento do produto não tiver os cuidados técnicos necessários para garantir

pequenas correções que porventura sejam necessárias. Ao assumir que todos os requisitos

foram definidos nas etapas iniciais de forma concisa, assumimos que o produto projetado é

exatamente aquele que o cliente deseja, ignorando o que o cone da incerteza nos mostra. A

realidade, no entanto tem se mostrado diferente, onde o andar do projeto agrega conhecimento

suficiente sobre o mesmo, que permite rever decisões do projeto que foram tomadas na fase

inicial. Neste caso é de fundamental importância a possibilidade de correções e até mesmo

alterações no produto durante sua fase de desenvolvimento, caso contrário, o projeto estará

14

amarrado a tudo aquilo que pôde ser definido em momentos de muita incerteza. A figura 2

ilustra a famosa cena do cone da incerteza, onde é mostrado que conforme o projeto avança, o

conhecimento adquirido ajuda a diminuir a incerteza sobre o mesmo.

Figura 2 – Cone da incerteza

Fonte: Barry Boehm, 1981.

15

2 FUNDAMENTAÇÃO TEÓRICA

Para o perfeito entendimento do contexto do problema, que será alvo mais direto deste

estudo, faz-se necessário revisar a literatura básica e trazer para a superfície conceitos e

problemas que talvez sejam básicos demais, mas que se relacionam diretamente com o

problema atacado por este estudo. É necessário entender o recorrente problema em estimar

tarefas no desenvolvimento de software e como as metodologias abordam esta questão, com

diferentes enfoques.

2.1 Gerência de projetos

Ainda que existam as dificuldades mencionadas no capítulo anterior, a gerência de um

projeto é sim a tarefa principal do mesmo. Pois, se é a própria gerência que define as etapas

do projeto é também ela que conseguirá detectar o avanço e os principais problemas que o

mesmo terá durante seu desenrolar.

Para agrupar o conhecimento sobre gerência de projetos considerado adequado, foi

criado o Project Management Institute (PMI). O PMI funciona como um conjunto de boas

práticas que podem ser utilizadas em um projeto seja ele de qualquer natureza. Para a

formalização destas práticas é utilizado o PMBOK que no momento da escrita deste trabalho

encontra-se na 4ª edição.

Seguindo conceitos do PMI, a gerência de software divide-se em nove (9) áreas de

conhecimento em gerenciamento: Integração, escopo, tempo, custo, qualidade, recursos

humanos, comunicação, riscos e aquisições. Cada uma destas áreas de conhecimento ocorre

durante todo o projeto, sendo impossível alocar um tempo específico em alguma delas e

depois não mais a usar.

A gerência de projetos é “a aplicação de conhecimentos, habilidades, ferramentas e

técnicas às atividades do projeto a fim de atender aos seus requisitos” (PMBOK, 2011, p. 12).

O planejamento, execução e controle de um projeto necessitam de uma gerência em vistas de

garantir que tudo aquilo que foi pensado em relação ao projeto está sendo executado dentro

dos parâmetros previstos.

A maior crítica que se faz ao uso de uma prática como o PMBOK é que um projeto,

neste caso, precisa ser definido em níveis de detalhamento muito altos, ainda que nos

encontremos na base do cone da incerteza. Os críticos desta prática entendem que, não é

necessário fazer um planejamento muito detalhado nas fases iniciais do projeto e sim planejar

16

de uma forma macro e partir para as fases de execução que será o ponto onde o conhecimento

sobre o projeto será adquirido, diminuindo a “miopia” provocada pelo cone da incerteza.

2.2 Metodologias ágeis

Os métodos ágeis foram uma proposição inicialmente feita no intuito de desvincular o

processo de desenvolvimento das técnicas formais e criar um novo modelo, muito menos

preocupado em projetar uma solução ótima na fase de concepção, privilegiando o

conhecimento adquirido sobre o produto com o passar do tempo adequando as devidas

correções de rumo.

Por meio do manifesto ágil, escrito em 2001, que prega quatro (4) conceitos, que

segundo os autores, visam garantir que um projeto não entregue um produto em desacordo

com o esperado pelo cliente, pelo contrário, seja possível até mesmo adequar a mudança de

vontade do cliente durante a execução do projeto, inicia-se uma nova fase na engenharia de

software.

Os quatro conceitos base descritos no manifesto ágil são:

a) Indivíduos e interação entre eles, mais do que processos e ferramentas (Focar em

quem vai desenvolver o produto e não em como vai desenvolver).

b) Software em funcionamento, mais do que documentação abrangente (Focar nas

fases de desenvolvimento em detrimento de fases de concepção e análise).

c) Colaboração com o cliente, mais do que negociação de contratos (Focar em tornar

o cliente participante ativo e responsável pelo sucesso do projeto).

d) Responder a mudanças, mais do que seguir um plano (Focar em adaptar o

conhecimento adquirido no projeto durante a execução do mesmo).

Baseadas no manifesto ágil surgiram diversas metodologias que tentam criar uma

espécie de framework que permita aplicar os quatro (4) conceitos de forma prática. As

metodologias ágeis mais conhecidas são:

a) SCRUM: Define regras de organização da equipe e funções gerenciais que

possibilitem acompanhar a evolução do projeto e facilitem as estimativas de

duração do mesmo;

17

b) Extreme Programming: Age nas questões técnicas do desenvolvimento,

regrando formas de criar um código fonte mais enxuto e que possibilite

evolução, reaproveitamento e simplicidade;

c) Test Driven Development: O grande foco aqui é a qualidade do software, onde

isso é obtido invertendo a ordem natural de desenvolvimento, fazendo com

que, o teste do software ocorra antes de sua codificação propriamente dita;

d) Kanban: Se preocupa em especial com a quantidade de trabalho que pode ser

realizada de forma satisfatória, definindo um fluxo simples para o controle de

tarefas simultâneas.

No cenário atual, as metodologias ágeis vêm conquistando muitos adeptos, por seu

aspecto mais simples, foco no trabalho pessoal, autogerenciamento e planejamento iterativo.

Entre as empresas o grande atrativo de tais metodologias se deve ao fato de permitir que os

próprios membros da equipe adotem uma postura de gerenciar seu tempo utilizado durante o

trabalho, bem como os mesmos assumirem as decisões mais simples sobre a implementação

do projeto. Já as equipes de trabalho têm mostrado grande interesse por métodos ágeis em

função da possibilidade de trabalhar em algo que não precisa ser considerado como a solução

ideal desde a primeira construção, e sim uma evolução do produto conforme a equipe vai

ganhando conhecimento sobre o projeto no qual está trabalhando.

Não cabe neste trabalho elencar todas as metodologias ágeis existentes, tão pouco

estudar a fundo as mencionadas aqui. Ao invés disso iremos abordar em um capítulo mais a

frente quais metodologias farão parte do estudo e o motivo de escolha das mesmas.

2.3 Medidas, medições e métricas

Medir um software talvez seja uma das tarefas existentes, menos precisa dentre as

áreas de engenharia. Tentar mensurar quão grande, complexo, custoso ou simplesmente

demorado será um software antes de entregar um produto funcional é uma tarefa que demanda

muito mais técnicas de estimativas do que conhecimento científico exato.

São verdadeiras as técnicas que conduzem às estimativas mais próximas do realizável,

mas por mais que se aproximem da realidade, ainda assim serão apenas estimativas. Ou seja,

tentativas de aproximar-se o máximo possível daquilo que se acredita ser possível realizar,

18

sem garantias de que aquilo poderá ser executado em caso de mudanças no cenário inicial ou

não.

Defrontados com este problema, durante anos os engenheiros de software procuram

formas de medir de forma satisfatória o software a ser desenvolvido e principalmente o

software que já foi desenvolvido permitindo alimentar uma base de dados histórica que ajude

na mensuração do produto gerado.

Historicamente as medidas de software foram evoluindo, começando pela medição de

linhas de código produzido chegando até os pontos de caso de uso de um sistema. Ignorando

os defeitos de cada abordagem, torna-se nítido a dependência entre as medidas adotadas e os

profissionais que irão participar de cada item medido. Um desenvolvedor que utiliza mais

linhas de código para fazer o mesmo que outro desenvolvedor faz com menos linhas, pode

acrescentar uma ideia de software maior. Assim como, um analista que consiga desmembrar

funcionalidades de um sistema em itens cada vez menores poderá ajudar muito mais na tarefa

de medir o tamanho do produto final antecipadamente. Mas esta abordagem necessitará que

uma equipe se mantenha unida por todo o projeto, com produção nos mesmos níveis sem

variações bruscas e principalmente não mudar seu estilo (entenda-se, não evoluir). Uma

simples mudança de pessoal, algo extremamente comum, pode comprometer um

planejamento feito de forma exaustiva e compenetrado.

Definir a medida, ou seja, o que será medido no sistema, definir a métrica de como

isso será medido e ainda possuir um referencial para comparar as medições efetuadas, tudo

isso é necessário e altamente complexo em um projeto de software.

Com base neste histórico fica fácil compreender por que é tão difícil definir métricas,

que possam ser uma fonte segura de referência na medição de produtividade em

desenvolvimento de software.

2.4 Estimativas

O maior reflexo da dificuldade em determinar o quanto um projeto de software irá

consumir em termos de recursos, é a necessidade de trabalhar-se com estimativas. Como não

é possível, atualmente, atingir um grau de precisão nas medidas do software, antes de seu

início propriamente dito, utilizam-se técnicas para realização de estimativas. É bom deixar

claro aqui que, estimativas não são “chutes” ou uma mera técnica de “eu acho que...”, trata-se

sim de uma coletânea de procedimentos que baseados em dados históricos ajudam a descrever

um possível cenário que será encontrado no projeto.

19

Dentro das metodologias ágeis um dos pontos mais cruciais é o momento de estimar.

É através das estimativas que conseguimos ter uma dimensão de tamanho e tempo do que será

desenvolvido. E por lidar com base em informações históricas, as estimativas são sempre

relativizadas com um contexto anterior, seja pensando na montagem da equipe, na

similaridade do software a ser desenvolvido entre outras comparações pertinentes.

A tarefa de estimar deve levar em conta alguns fatores chave, como a participação da

equipe que estará trabalhando no projeto. É esta equipe que melhor conseguirá predizer

quanto de esforço será necessário em cada item do software, baseada no seu histórico em

tarefas passadas e na descrição sucinta que recebe na implementação deste novo software. É

bom frisar a participação da equipe do projeto nas estimativas e não de usuários que são peças

chave do projeto, pois, “Despiste well-known evidence that estimates prepared by those Who

Will do the work are better than estimates prepared by anyone else. (LEDERER; PRASAD,

1992)”.

Ao estimar um projeto de software em seu início, o cenário encontrado é de muitas

informações que podem confundir sobre a real complexidade do projeto e de poucas

informações sobre quais pontos podem ser de complexidade crítica. Esta disparidade não é

resolvida até que o projeto se encaminhe por um período em suas etapas de desenvolvimento

e os problemas mais relevantes são apresentados.

A figura 3 nos mostra a tendência que encontraremos ao tentarmos estimar um

software. Nossa visão inicial é de que, quanto mais tempo dispusermos para estimar, maior

será precisão que teremos ao final das estimativas. Mas a figura nos mostra exatamente o

contrário. Existe um ponto onde o aumento de esforço na tarefa de estimar diminui a precisão

da estimativa em si. Isso ocorre por que a partir de um determinado ponto, temos uma forte

inclinação a fazer inferências sobre aquilo que estamos planejando e mais, começamos a

entrar em um nível de detalhamento muito granular, que causará uma necessidade de um

micro gerenciamento em tarefas cada vez menores.

Posto isso, temos que avaliar o momento onde paramos de estimar o trabalho a ser

feito e começamos realmente a fazer o trabalho. Aí fica clara a necessidade de as estimativas

serem constantes durante a vida do projeto e não apenas uma fase executada no início do

mesmo, que servirá de comparativo ao final do projeto para concluir se o mesmo foi bem

sucedido ou não.

Fonte: Mike Cohn, 2006

Figura 3 – Esforço X Precisão

Mike Cohn, 2006.

20

21

3 TRABALHOS RELACIONADOS

Neste capítulo são apresentados os principais trabalhos relacionados, que foram analisados

para a elaboração deste trabalho.

3.1 Estudo de caso para compreensão da equipe

No estudo A teamwork model for understanding an agile team: A case study of a

Scrum Project, os autores abordam o quanto o desenvolvimento de software é dependente dos

fatores humanos. Quando aplicado o estudo sobre equipes que trabalham com metodologias

ágeis ficou visível a necessidade de multidisciplinaridade dentro da equipe, uma vez que,

nenhum membro é responsável por apenas uma área de conhecimento no projeto, e sim, todos

devem ser capazes de responder sobre qualquer aspecto pertinente ao produto em

desenvolvimento. Neste estudo é mostrado que uma das principais barreiras a serem vencidas

por uma equipe trabalhando com metodologias ágeis, é a divisão de trabalho entre os

membros. Caso a divisão não seja feita, irá gerar membros com conhecimento altamente

especializado em determinadas tarefas e práticas, gerando assim uma dependência

subserviente entre a equipe e criando pontos de gargalos para a entrega das releases. Além

disso, é abordado o quanto o autogerenciamento pode ser perigoso, quando não

supervisionado de forma contínua por um membro externo à equipe. Este estudo foi

considerado um ótimo estudo de caso, para definir antecipadamente como organizar a

distribuição dos pacotes de trabalho entre os membros da equipe, na elaboração deste

trabalho. No trabalho citado é apresentada uma figura que ilustra como as equipes, em geral,

reagem sob os principais eventos de um projeto.

3.2 Estudo de caso com vantagens e desvantagens dos métodos ágeis

No estudo A comparison of issues and advantages in agile and incremental

development between state of the art and an industrial case, é feita uma análise sobre o uso de

metodologias ágeis dentro na Ericsson AB. Ao conduzir a adoção de métodos ágeis em um

projeto considerado de grande escala, a nova metodologia se mostrou eficiente ao criar

pequenos grupos autogerenciáveis, mas com a existência de pequenos grupos trabalhando no

projeto, viu-se a necessidade de uma nova forma de gerência sobre estes grupos para a

execução correta do projeto. O estudo mostra ainda algumas das vantagens citadas

22

diretamente às metodologias ágeis, tais como, diminuição da documentação graças a

comunicação direta entre as partes, redução do retrabalho por criar apenas o que é necessário

naquele momento e maior facilidade em estimar os requisitos por serem menores. Os

principais problemas encontrados no estudo foram a necessidade de um maior controle de

integrações e testes contínuos e a necessidade de um aumento no esforço do gerenciamento do

projeto e das equipes.

3.3 Principais diferenciais geradores de agilidade.

No estudo An Empirical Study on the Relationship between the Use of Agile Practices

and the Success of Software Projects that Use Scrum, é feito um estudo sobre quais técnicas e

diretrizes dos métodos ágeis realmente geram diferencial durante o projeto. É visto que, nem

todas as práticas adotadas como ágeis se transformam em diferenciais geradores de diferencial

técnico. A tabela apresentada no estudo é reproduzida no quadro 1 deste trabalho, listando os

pesos de cada atributo, ligado diretamente ao produto final desenvolvido.

Quadro 1 – Pesos dos atributos ágeis

Atributos Ágeis S A01 Entregas regulares do software ,441** A02 Entrega primeiramente das funcionalidades mais importantes ,306 A03 Normas de codificação bem definidas ,165 A04 Aplicando “Design” simples ,117 A05 Rigorosas atividades de “Refactoring ,120 A06 Correta quantidade de documentação ,211 A07 Correto mecanismos de testes de integração ,316** A08 Membros do time com alta competência e experiência ,283* A09 Membros do time com grande motivação ,154 A10 Gerentes com conhecimento em métodos ágeis ,228 A11 Gerentes com estilo adaptativo de gerenciamento ,136 A12 Treinamento técnico apropriado para a equipe ,135 A13 Seguindo processo de gerenciamento ágil de requisitos ,298* A14 Seguindo processo de gerenciamento ágil de projetos ,184 A15 Seguindo processo de gerenciamento ágil de configuração ,326* A16 Bom progresso do mecanismo de tracking ,034 A17 Forte foco em comunicação, como reuniões diárias face a face ,238 A18 Cumprimento regular do cronograma ,246 A19 Colocação de todo time em um mesmo ambiente -,150 A20 Coerência, time auto-organizado ,322* A21 Projetos com times pequenos -,058 A22 Projetos com múltiplos times independentes ,038 A23 Bom relacionamento com o cliente ,316* A24 Forte compromisso e presença do cliente ,083 A25 Cliente com grande autoridade -,191

Fonte: MARIZ; FRANÇA; DA SILVA, 2010. * Significativo a p=0,05 ** Significativo a p=0,01;

23

4 PROGRAMA DE MEDIÇÃO

Neste capítulo são descritos o ambiente de estudo e os problemas que devem ser atacados no

escopo deste trabalho. Mostraremos ainda como será feita a análise e coleta dos dados.

4.1 Cenário, problema contextual

Para a elaboração deste trabalho foi utilizado um ambiente, real, de desenvolvimento

de software. Este ambiente não se trata de uma software house tradicional, empresa que preste

serviços de T.I. ou mesmo qualquer outra espécie de empresa que tenha como atividade fim o

desenvolvimento de software. O cenário escolhido é uma instituição de ensino superior, que

agrega como principais produtos, ensino de graduação, extensão, sensu-strictu e lato-sensu.

Dentro desta instituição existe um departamento de T.I., dividido em três (3) áreas: Suporte ao

usuário (cuida de questões como instalação de softwares e uso dos equipamentos), Redes e

servidores (cuida da parte lógica e física da comunicação utilizando tecnologia) e Sistemas de

informação (desenvolve soluções de software de forma interna). O setor de T.I. possui uma

diretoria administrativa que cuida das questões orçamentárias e decisões mais estratégicas,

enquanto o gerenciamento técnico das três áreas fica a cargo de dois analistas: Analista de

infraestrutura e Analista de sistemas. Dentro da área de sistemas a equipe é composta por:

a) Um analista de sistemas, responsável por toda a área;

b) Um programador pleno, responsável por análises mais triviais e liderança

técnica;

c) Um programador júnior nível cinco de sete, responsável pelo contato mais

técnico com o usuário final e por implementação de soluções mais críticas;

d) Dois programadores júnior nível um de sete, responsáveis pelas

implementações das definições feitas pelos níveis mais acima, bem como,

atendimento de nível dois aos usuários internos;

e) Dois técnico em micro informática, responsáveis pelos atendimentos de níveis

um e dois, bem como correções de falha no software existente e

implementação de funcionalidades básicas definidas pelos níveis acima.

Para a implantação deste trabalho, a equipe de Sistemas de Informação foi escolhida

como sendo a mais adequada à implantação de uma nova metodologia de trabalho, visto que,

a área além de promover o desenvolvimento de soluções customizadas ao cliente interno, não

24

possui nenhum tipo de outra metodologia pré-existente, caracterizando assim um ambiente de

desenvolvimento sem vícios ou dificuldades em livrar-se de velhas práticas no trabalho diário.

A instituição utiliza dois sistemas básicos para o gerenciamento acadêmico: Um

sistema web, desenvolvido utilizando PHP® com banco de dados Oracle®, que atende em

torno de 90% das demandas anuais do gerenciamento acadêmico/administrativo da

instituição, e um sistema desktop utilizando Visual Basic® com bancos de dados Oracle®,

Access® e PostgreSQL®. O sistema dito desktop passa por uma fase de desativação, seguindo

assim várias etapas de migração de funcionalidades para o sistema web. Esta migração

realizada não muda de forma alguma os processos já existes, limitando-se exclusivamente em

transcrever funcionalidades de uma arquitetura para a outra.

Em geral as solicitações de correções, mudanças nos fluxos do sistema, novas

implementações e melhorias diversas, são propostas pelos usuários finais, independente de

seu nível hierárquico ou função interna. As solicitações são examinadas pela área e caso

sejam consideradas viáveis são implementadas conforme disponibilidade da equipe em

atender, caráter de urgência da solicitação ou orientação direta da diretoria responsável.

4.2 Ambiente e forma de análise propostos

Após o estudo das metodologias existentes, optou-se por iniciar a análise do ambiente

com um cenário híbrido, ou seja, juntando-se as técnicas mais importantes de algumas

metodologias e formando uma nova metodologia, que por distorcer-se das definições de cada

uma das metodologias originais, não pode levar o nome de nenhuma delas. Neste caso,

optaremos por chamar esta nova metodologia criada de metodologia híbrida. Para a

concepção desta metodologia híbrida, coletaram-se os aspectos mais relevantes, segundo a

literatura pesquisada, de cada uma das metodologias escolhidas. Para a análise do ambiente,

fez-se necessário um controle dos quesitos técnicos e gerenciais, isolando-se ambos em dois

(2) seguimentos distintos.

Para o estudo dos aspectos gerenciais do ambiente, escolheu-se a metodologia

SCRUM, por ser a mais abrangente em diversos níveis de gerenciamento e também por

possuir um material didático mais vasto e mais simples de ser encontrado. Também através do

SRCUM é possível verificar-se sua eficácia através de benchmarks que a própria metodologia

recomenda.

Para o estudo dos aspectos técnicos, optou-se pela metodologia EXtreme

Programming, ou simplesmente XP, pelo fato de cobrir quase que todas as questões técnicas

25

que um desenvolvedor moderno precisa, ainda, deter-se. Além disso, seu material encontrado

é de fácil assimilação e sua proposta é claramente de tornar o código fonte mais enxuto e

reutilizável.

Cabe salientar que não foram utilizadas todas as diretrizes que ambas as metodologias

sugerem, ao invés disso, fez uma seleção das práticas mais usuais e mais eficazes, segundo a

literatura e segundo a necessidade de trabalho do ambiente utilizado. A compilação das

técnicas escolhidas é demonstrada abaixo.

SCRUM:

a) Sprint: O desenvolvimento se dá em timeboxes fechadas, com tamanho

variável ao longo do tempo. O tamanho de uma sprint pode variar entre

uma e três semanas, segundo recomendação da literatura pesquisada. Para o

estudo proposto escolheu-se sprint de duas semanas por ser considerado, na

literatura pesquisada, o número que permite correções de rota mais

rapidamente e que não causa o micro gerenciamento da equipe e das

tarefas;

b) Burndown: O desempenho evolutivo das sprint é avaliado através da

análise de gráficos burndown, que permitem visualizar o planejado e o

executado dentro de uma sprint;

c) Estimativas em grupo: As estimativas dos itens pertencentes a uma sprint

são feitas por toda a equipe do projeto;

XP:

a) Programação em pares: Os desenvolvedores são alocados para trabalharem

em pares quando for notada uma disparidade técnica entre eles ou quando

os prazos de conclusão de tarefas similares apresentarem diferenças

notáveis entre os elementos;

b) Refactoring: O código é criado com orientação direta a refatoração, ou seja,

será priorizada a funcionalidade desenvolvida naquele momento, sem tentar

antever possíveis usos daquele trecho de código futuramente. Deve ser

evitada a redundância de funcionalidades, mas sem partir para uma

abstração muito ampla.

A primeira sprint foi utilizada como verificador de teste e não foi considerada neste

trabalho. Seu resultado serviu apenas de orientação e introdução da mesma à equipe.

26

A segunda sprint seguiu o mesmo modelo definido na primeira, ou seja, um timebox

de duas semanas, com uma única equipe trabalhando no mesmo. Esta equipe foi composta por

três (3) membros, sendo eles um técnico em microinformática, um programador júnior nível

um e um programador júnior nível cinco. Esta equipe permaneceu junta até a sprint de

número sete (7).

A sprint de número seis (6) trocou as estimativas feitas em dias ideais por estimativas

de tamanho.

A sprint número sete (7) trocou o membro de menor produtividade das sprint

anteriores, por um novo membro.

A sprint número onze (11) adicionou um novo membro, de forma aleatória, à equipe,

formando assim uma equipe de cinco (5) pessoas.

A sprint catorze (14) dividiu a equipe de cinco pessoas em duas (2) equipes, uma de

três (3) pessoas e outra de duas (2) pessoas. A equipe com duas pessoas teve a adição de um

novo membro ao time.

Para este estudo foi considerado um projeto de migração de um sistema legado, em

ambiente desktop, para um ambiente web. Os itens existentes foram refeitos em PHP

seguindo as mesmas funcionalidades já existentes em cada módulo.

4.3 Como nós estimamos

As estimativas foram feitas de forma geral antes de iniciar o estudo. O gerente de

projeto definiu quais itens iriam fazer parte da migração e do estudo e os apresentou a equipe.

Cada membro recebeu um baralho de cartas com a sequência de fibonacci. Neste momento o

gerente apresentou o primeiro item a ser estimado lendo a especificação e os casos de teste do

mesmo. Com base nestas informações cada membro da equipe escolhe um número que sirva

de estimativa ao item, com base naquilo que ouviu, e pega a carta que represente este número.

As cartas escolhidas pelos membros são viradas para cima todas ao mesmo tempo e verificada

a estimativa dada. Caso haja divergências os membros explicam as razões de suas estimativas

e uma nova rodada é feita até que se obtenha um consenso. Caso não haja acordo sobre a

estimativa, o gerente irá intervir escolhendo a estimativa dada que pareça mais adequada.

Após estimar todos os itens foi planejada a primeira sprint, que iria conter um número de

itens a serem desenvolvidos. Ao final da sprint a equipe fez um review onde foram relatados

os problemas encontrados, as soluções adotadas e as demais observações que os membros

achem importantes. Diariamente

foram relatadas as dificuldades e estado atual do projeto. Ao final de uma

diária, ou antes, de iniciar uma nova

anteriormente como forma de adequar o conhecimento adquirido sob

Os itens que compunham

funcionalidades que fazia

gerente do projeto, ou product owner

sistema a ser desenvolvido. Esta lista foi

implementação e comparada quando da entrega do item, pela equipe de desenvolvimento.

Esta lista é chamada de

desenvolvidos dentro de uma

A figura 4 mostra como ficou estabelecido o fluxo de desenvolvimento na nossa

metodologia.

Figura 4

Fonte: Autoria própria, 2012.

achem importantes. Diariamente houve uma reunião de no máximo quinze (

relatadas as dificuldades e estado atual do projeto. Ao final de uma

de iniciar uma nova sprint, a equipe pôde reavaliar as estimativas feitas

anteriormente como forma de adequar o conhecimento adquirido sobre o projeto.

compunham as sprint foram coletados a partir de uma lista de

parte do projeto. Esta lista de funcionalidades foi elaborada pelo

product owner, e corresponde às necessidades que a e

a ser desenvolvido. Esta lista foi validada pelos stackholder


Esta lista é chamada de product backlog e o grupo de itens escolhido

desenvolvidos dentro de uma sprint são conhecidos como sprint backlog

mostra como ficou estabelecido o fluxo de desenvolvimento na nossa

Figura 4 – Fluxo de desenvolvimento interno

, 2012.

27

quinze (15) minutos onde

relatadas as dificuldades e estado atual do projeto. Ao final de uma sprint, na reunião

de reavaliar as estimativas feitas

re o projeto.

coletados a partir de uma lista de

parte do projeto. Esta lista de funcionalidades foi elaborada pelo

, e corresponde às necessidades que a empresa tem no

stackholder antes do início da


e o grupo de itens escolhidos para serem

sprint backlog.

mostra como ficou estabelecido o fluxo de desenvolvimento na nossa

28

5 RESULTADOS E AVALIAÇÃO

Neste capítulo mostraremos os dados que foram coletados em cada sprint executada. Ao final

da coleta destes dados, mostraremos uma análise daquilo que foi observado na execução das sprint e

os principais eventos que explicam o comportamento observado.

5.1 Resumo dos dados

Foram realizadas quinze (15) sprint, sendo que, duas sprint foram realizadas por duas equipes

ao mesmo tempo. O quadro 2 apresenta um resumo de todo o trabalho realizado e é explicado logo

abaixo do mesmo.

Quadro 2 – Resumo das sprint

Sprint Dias trab.

Medida Equipe Estimado Realizado Bugs Entregas Bugs/Mês

VA(%)

2 9 DIAS 4 28 18 41 4 10,25 64,29 3 9 DIAS 4 28 6 53 3 17,66 21,43 4 9 DIAS 4 24 18 40 8 5 75 5 9 DIAS 4 22 22 28 8 3,5 100 6 10 TAMANHO 4 46 46 13 7 1,86 100 7 10 TAMANHO 4 +

TROCA 46 46 19 7 2,71 100

8 9 TAMANHO 4 64 46 25 7 3,57 71,88 9 8 TAMANHO 4 35 32 18 6 3 91,43 10 10 TAMANHO 4 50 44 27 4 6,75 88 11 10 TAMANHO 5 53 52 20 9 2,22 98,11 12 8 TAMANHO 5 48 39 14 7 2 81,25 13 10 TAMANHO 5 58 47 16 9 1,78 81,03

14.A 10 TAMANHO 3 54 44 17 6 2,83 81,48 14.B 10 TAMANHO 3(1

NOVO) 54 31 25 4 6,25 57,41

15.A 10 TAMANHO 3 50 45 15 7 2,14 90 15.B 10 TAMANHO 3 47 26 24 4 6 55,32


O resumo apresenta a sprint, (retirando a sprint um (1) que serviu apenas para introdução à

equipe), identificada por um número que a difere de outras. A segunda coluna apresenta o número de

dias que foram trabalhados naquela sprint. A coluna “Medida” apresenta a forma que as estimativas

foram feitas (analogia de TAMANHO ou DIAS ideais de trabalho). Na coluna “Equipe”, temos o

número de membros da equipe que trabalharam na sprint. Quando houve alguma alteração na equipe

(TROCA de membros ou adição de um NOVO membro), a coluna é devidamente sinalizada. A coluna

“Realizado” mostra o número que as estimativas geraram antes da execução da sprint. Este número

está relacionado à primeira coluna. Em “Bugs” é mostrado o número total de defeitos relatados que

29

esta sprint apresentou após sua conclusão. A próxima coluna apresenta o total de itens foram entregues

ao cliente, após a conclusão da respectiva sprint. A coluna subsequente mostra uma relação de

defeitos/mês, que foram medidos em até três (3) meses após a conclusão da sprint. A última coluna se

refere ao valor agregado que a sprint gerou. Este número é gerado dividindo o previsto a ser entregue

e o que foi efetivamente entregue ao final da sprint.

5.2 Dados coletados

Ao formar a primeira equipe de desenvolvimento que trabalharia na sprint número

dois (2), sendo esta a sprint considerada inicial, uma vez que os resultados da primeira sprint

serviram apenas de introdução da equipe à metodologia, os membros foram convocados a

estimar a duração das tarefas que iriam compor o product backlog. Todos os elementos

opinaram até obter-se um consenso sobre a duração, em dias ideais de trabalho, para cada

item. Ao final da estimativa completa do product backlog, foi composta a sprint número dois

(2) com os itens que completavam o número de nove (9) dias de trabalho multiplicados pelo

número três (3). O número nove (9) se referia a uma sprint de duas (2) semanas, retirando-se

dois (2) finais de semana e um (1) feriado. O número três (3) se referia aos membros da

equipe de execução que trabalhariam na implementação. O resultado foi o número de vinte e

oito (28) dias ideais de trabalho. Apesar de a multiplicação ter na verdade gerado o número

vinte e sete (27), não foi possível alocar itens que completassem este número de forma exata.

Neste caso escolheu-se o número obtido mais próximo do ideal.

Para apresentar os dados coletados, serão exibidas figuras em forma de gráfico, onde

existe uma linha negra, que representa a baseline estimada para a sprint, e uma área laranja,

que representa como foi o comportamento da produtividade em relação a esta baseline. No

eixo horizontal são mostrados os dias de trabalho em ordem crescente e no eixo vertical são

apresentadas as unidades de trabalho estimadas para a sprint, em ordem decrescente.

Ao final da sprint número dois (2) verificou-se que o desempenho ficou abaixo do

esperado, obtendo-se um valor agregado de 64,29%, sendo que foram entregues quatro (4)

itens concluídos. Este número foi obtido extraindo o percentual de itens concluídos sobre os

itens previstos para conclusão, dentro da sprint. Esta sprint apresentou ainda um número alto

de defeitos relatados pelos usuários, num prazo de até três (3) após sua conclusão: quarenta e

um (41) defeitos relatados. Dando uma média de 10,25 defeitos por item entregue. Ao final da

sprint a equipe teve a oportunidade de fazer um review da sprint passada e fazer correções

para a próxima. Optou-se por não serem revisadas as estimativas do product backlog e passar-

30

se a execução da próxima sprint. A figura 5 mostra certa aproximação entre a baseline o

trabalho efetivo, até o sétimo dia de trabalho.

Figura 5 – Burndown da sprint 2


A sprint número três (3) manteve a mesma equipe trabalhando junta e foi planejada nos

mesmos nove (9) dias de trabalho com um sprint backlog de vinte e oito (28) dias ideais. Ao final do

período da sprint foi obervado um valor agregado entregue muito mais baixo que a sprint anterior:

21,43% com três (3) itens concluídos entregues. O número de defeitos relatados em até três meses

após a entrega da sprint também aumentou: 53, chegando num índice de 17,66 defeitos por item

entregue. Ao realizar a sprint review a equipe concluiu que as estimativas geradas antes de iniciar o

projeto haviam sido demasiadamente otimistas e baseadas em requisitos superficialmente descritos.

Com base nisto a equipe destinou o tempo de uma (1) hora da sprint review para realizar um

refinamento das estimativas já preparadas. A figura 6 apresenta o quanto esta sprint foi problemática,

quando analisada a dispersão entre a baseline e o trabalho efetivo.

0

5

10

15

20

25

30

Original 1 2 3 4 5 6 7 8 9

Un

idad

es d

e tr

abal

ho

Days

Brundown final

Original Commitments Baseline

31



A sprint número quatro (4) foi planejada com os mesmos nove (9) dias ideais e a mesma

equipe anterior. Como não havia sido possível cumprir o planejamento feito nas sprint anteriores,

nesta sprint foi alocado um total de vinte e quatro (24) dias ideais no sprint backlog. Ao final da sprint

foram entregues oito (8) itens concluídos com um valor agregado de 75%. O número de defeitos

subsequentes também reduziu em comparação com as sprint anteriores: 40, formando uma média de

cinco (5) defeitos por item entregue, o menor índice até então. Neste ponto já foi possível perceber que

a equipe estava mais integrada, produzindo numa velocidade mais constante e sendo capaz de efetuar

o autogerenciamento básico, um dos requisitos elementares do SCRUM. A revisão das estimativas

também deu uma contribuição significativa, dando a ideia de que a velocidade de produção foi

elevada, quando na verdade as novas estimativas passaram ser feitas levando em conta os desvios,

normais, que um dia de trabalho ideal propicia. A figura 7 nos mostra o desempenho da equipe tendo

uma queda na metade final da sprint.

0

5

10

15

20

25

30

Original 1 2 3 4 5 6 7 8 9

Un

idad

es d

e tr

abal

ho

Days

Burndown final


32



Na sprint número cinco (5), as estimativas não foram revisadas, mas a equipe resolveu

diminuir a quantidade de trabalho que iria compor a sprint backlog. Foram adicionados um total de

vinte e dois (22) dias ideais de trabalho, no espaço dos mesmos nove (9) dias das sprint anteriores. Ao

final da sprint a equipe conseguiu um aproveitamento ótimo. Foram concluídos todos os oito (8) itens

planejados nos vinte e dois (22) dias de trabalho estimados, gerando um valor agregado de 100%. Os

defeitos relatados no período pós entrega antigiram o menor índice: vinte e oito (28), com uma média

3,5 defeitos por item entregue. A figura 8 mostra que esta sprint oscilou demais, muito em virtude dos

ajustes das estimativas, que ainda não conseguiam se adequar ao real volume de trabalho previsto.

Na sprint número seis (6), as estimativas deixaram de ser feitas em dias ideais de trabalho e

passaram a serem feitas considerando analogias de tamanho. Para isso foi considerado um pacote de

trabalho com o menor tamanho possível e em cima deste pacote foram estimados os tamanhos dos

novos pacotes a serem desenvolvidos, sempre adotando uma análise por analogia comparativa entre o

tamanho dos pacotes de trabalho. Ao estimar novamente os pacotes que haviam sido estimados em

dias ideais, a equipe decidiu alocar dentro da sprint um total de quarenta e seis (46) pontos, que

correspondem à soma total de todos os pacotes que entram na sprint. Estes pontos estavam dispostos

em dez (10) dias de trabalho com a mesma equipe da última sprint, quatro (4) pessoas. Ao final da

sprint todos os itens foram concluídos com um (1) dia de antecedência, gerando um valor agregado de

100%. O número de defeitos relatados posteriormente também foi um índice bastante positivo, treze

(13), com uma média de 1,85 defeitos por item entregue, sendo que foram entregues sete (7) itens. A

figura 9 apresenta o desempenho em níveis satisfatórios, ficando grande parte do tempo abaixo da

baseline (mesmo que isso também seja uma falha de projeto).

0

5

10

15

20

25

30

Original 1 2 3 4 5 6 7 8 9

Un

idad

es d

e tr

abal

ho

Days

Burndown final


33



Na sprint número sete (7), houve a alteração de um (1) membro da equipe. O desenvolvedor

com menor produtividade, segundo avaliação da própria equipe, deu lugar à um novo membro. A

equipe continuou com o tamanho de quatro (4) pessoas, alocados em 10 dias de trabalho. Foram

alocados dentro da sprint quarenta e seis (46) pontos, o mesmo número que havia sido alocado na

sprint anterior. Não foi necessária nenhuma reestimativa dos pacotes de trabalho para esta sprint. Ao

final da sprint todos os pacotes haviam sido concluídos gerando, novamente, um valor agregado

máximo de 100%. O número de itens entregues também se manteve em sete (7). A diferença mais

significativa foi o total de defeitos relatados após as entregas que subiu para dezenove (19), gerando

um índice de 2,71 defeitos por item entregue. A figura 10 mostra que a sprint transcorreu quase todo o

tempo dentro do previsto com um pequeno ganho na parte final, mas que este ganho não foi mantido

até o término.

Na sprint número oito (8), o número de dias trabalhados foi de nove (9), sendo a equipe

composta pelos mesmos membros da sprint anterior. Incentivados pelos 100% de valor agregado das

últimas sprint, a equipe resolver alocar mais pontos para serem entregues ao final.

0

5

10

15

20

25

Original 1 2 3 4 5 6 7 8 9

Un

idad

es d

e tr

abal

ho

Days

Burndown final


34





da sprint, sessenta e quatro (64). Ao final dos trabalhos foi visto que foram entregues apenas quarenta

e seis (46) pontos, sendo o mesmo número das duas últimas sprint. O número de pacotes de trabalho

entregues finalizou em sete (7), mas o número de defeitos relatados elevou-se para significativos vinte

e cinco (25), gerando um índice de 3,57 defeitos por item entregue. O valor agregado desta sprint

0

5

10

15

20

25

30

35

40

45

50

Original 1 2 3 4 5 6 7 8 9 10

Un

idad

es d

e tr

abal

ho

Days

Burndown final


0

5

10

15

20

25

30

35

40

45

50

Original 1 2 3 4 5 6 7 8 9 10

Un

iad

ades

de

trab

alh

o

Days

Burndown final


35

ficou em 71,88%. A figura 11 ilustra o comportamento da sprint, onde, o desempenho se manteve

quase todo o tempo acima do previsto, mesmo que dentro de limites toleráveis.



Na sprint número nove (9), o total de dias de trabalho disponíveis foi de oito (8). A

equipe para esta sprint foi a mesma da sprint anterior. A equipe validou as estimativas realizadas

anteriormente e concluiu que os pacotes de trabalho não necessitavam serem estimados novamente,

sendo que, alocaram trinta e cinco (35) pontos para serem entregues nesta sprint. Ao final do prazo,

trinta e dois (32) pontos haviam sido concluídos, gerando um valor agregado de 91,43%, com seis (6)

itens entregues. O número total de defeitos relatados posteriormente foi de dezoito (18), com um

índice de três (3) defeitos por item entregue. A figura 12 mostra uma sprint que ficou quase o tempo

todo acima do previsto. Mas fica visível notar que o atraso se deu no início e não havia um buffer para

compensar este atraso que se estendeu até o fim.

Na sprint número dez (10), o total de dias de trabalho disponíveis foi de dez (10), sem nenhum

tipo de alteração na estrutura da equipe em relação às últimas sprint. Para esta sprint a equipe resolveu

alocar um total de cinquenta (50) pontos. Ao final do prazo a equipe conseguiu entregar quatro (4)

itens concluídos, realizando um total de quarenta e quatro (44) pontos dentro da sprint. O valor

agregado entregue foi de 88%, sendo que, foram relatados vinte e sete (27) defeitos nos pacotes de

trabalho entregues, posteriormente. Este número gerou um índice de 6,75 defeitos por item entregue (o

terceiro maior índice de defeitos de todo o projeto). A figura 13 mostra uma sprint muito parecida com

a anterior, onde as estimativas foram mais otimistas que a realidade vista.

0

10

20

30

40

50

60

70

Original 1 2 3 5 6 7 8 9

Un

idad

es r

esta

nte

s

Days

Burndown final


36





A sprint número onze (11) trouxe uma novidade em relação às sprint anteriores: Foi

adicionado mais um novo membro à equipe, formando um time de cinco (5) pessoas. Foram

disponibilizados dez (10) dias de trabalho para esta sprint, e por escolha da equipe foram

alocados cinquenta e três (53) pontos para serem entregues ao final das duas semanas. Ao

0

5

10

15

20

25

30

35

40

Original 1 2 3 4 5 6 7 8

Un

idad

aes

de

trab

alh

o

Days

Burndown final


0

10

20

30

40

50

60

Original 1 2 3 4 5 6 7 8 9 10

Un

idad

aes

de

trab

alh

o

Days

Burndown final


37

término da sprint cinquenta e dois (52) pontos haviam sido concluídos, gerando um valor

agregado de 98,11%. O número de defeitos relatados posteriormente foi de vinte (20),

gerando um índice de 2,22 defeitos por item entregue. Apesar da inclusão de um novo

membro na equipe, inexperiente em métodos ágeis, o índice de defeitos por item foi o menor

registrado até aquele instante. A figura 14 apresenta esta sprint com um detalhe curioso: Uma

curva de aceleração das entregas no terço final. Esta aceleração se deve a uma dependência,

não prevista, em itens já entregues anteriormente e itens que estavam sendo entregues neste

momento. O bom rendimento da sprint, mesmo com um novo membro, se deve ao novo

membro ter um nível técnico mais elevado em relação aos demais.



A sprint número doze (12) repetiu a equipe anterior, mas com a diferença que ocorreu

em apenas oito (8) dias. Foram estimados quarenta e oito (48) pontos para serem entregues ao

final do prazo, mas apenas trinta e nove (39) concluídos, gerando um valor agregado de

81,25%. A taxa de defeitos ficou em dois (2) defeitos por item entregue, graças ao total de

quatorze (14) defeitos relatados sobre sete (7) pacotes de trabalho entregues. A figura 15

mostra que esta sprint não teve desempenho satisfatório, sendo que, este problema teve uma

relação direta com a quantidade de defeitos que foram sendo encontrados durante o

0

10

20

30

40

50

60

Original 1 2 3 4 5 6 7 8 9 10

Un

idad

aes

de

trab

alh

o

Days

Burndown final


38

desenvolvimento. A taxa de defeitos aumentou, sendo detectada ainda na fase de testes e

tendo seu número reduzido na entrega final.



A sprint número treze (13) continuou com a mesma equipe e ocorreu num intervalo de

dez (10) dias. A equipe alocou um total de cinquenta e oito (58) pontos para serem entregues,

mas entregou apenas quarenta e sete (47) totalizando um valor agregado de 81,03%. Os

dezesseis (16) defeitos relatados nesta sprint, relativos a nove (9) pacotes de trabalho

entregues, geraram uma média 1,77 defeitos por item entregue, valor este o menor índice

registrado durante o estudo. A figura 16 está apresentando novamente o caso de uma sprint

que teve um pequeno atraso e não se recuperou mais. Este fato poderia ter sido evitado com

um pequeno buffer.

A sprint número catorze (14) apresentou uma novidade: a equipe de cinco (5) pessoas

foi dividida em duas equipes. A equipe “A” ficou com três (3) membros da equipe que veio

da sprint anterior, enquanto a equipe “B” ficou com dois (2) membros da equipe da sprint

anterior. Além disso, um desenvolvedor sem experiência em metodologias ágeis foi inserido

na equipe “B”. As equipes ficaram sendo conhecidas como equipe A e B, respectivamente.

Ambas as equipes alocaram cinquenta e quatro (54) pontos para serem entregues ao final de

dez (10) dias.

0

10

20

30

40

50

60

70

Original 1 2 3 6 7 8

Un

idad

aes

de

trab

alh

o

Days

Burndown final


39



Figura 17 – Burndown da sprint 14 da equipe A


Quando a sprint foi encerrada, a equipe “A” havia finalizado quarenta e quatro (44) pontos

enquanto a equipe “B” havia concluído apenas trinta e um (31). Estes números geraram um

valor agregado de 81,48% e 57,41%, respectivamente. A equipe “A” entregou seis (6) itens

0

10

20

30

40

50

60

70

Original 1 2 3 6 7 8 9 10

Un

idad

aes

de

trab

alh

o

Days

Burndown final


0

10

20

30

40

50

60

Original 1 2 3 6 7 8 9 10

Un

idad

aes

de

trab

alh

o

Days

Burndown final


40

com dezessete (17) defeitos relatados, enquanto a equipe “B” entregou quatro (4) itens, mas

com um maior número de defeitos, vinte e cinco (25). Com isso temos que a equipe “A”

obteve um índice de 2,83 defeitos por item entregue, enquanto a equipe “B” obteve o índice

de 6,25 defeitos por item entregue. A figura 17 mostra que a equipe que permaneceu junta

manteve o mesmo índice de aproveitamento, ou seja, uma pequena diferença entre as

estimativas e o realizado, onde as estimativas foram feitas com certo otimismo, não atingido.

A figura 18 mostra que a equipe formada neste momento não conseguiu adequar a inclusão do

novo elemento, ao rendimento que seria esperado com este novo membro. O rendimento foi

muito ruim.

Figura 18 – Burndown da sprint 14 da equipe B


A última sprint foi a de número quinze (15) repetiu as equipes da sprint anterior. Desta

vez a equipe “A” alocou um total de cinquenta (50) pontos enquanto a equipe “B” optou por

alocar quarenta e sete (47) pontos, tudo isto distribuído em um período de dez (10) dias. Ao

final do prazo a equipe “A” obteve 90% de valor agregando, entregando sete (7) itens

concluídos, enquanto a equipe “B” obteve 55,32% de valor agregado com apenas quatro (4)

itens entregues. A taxa de defeitos ficou em 2,14 e 6 defeitos por item, respectivamente. Ao

encerrar esta sprint foi feito um review de todo o projeto, onde as equipes tiveram a

oportunidade de debater as melhorias que o processo de desenvolvimento sofreu as decisões

0

10

20

30

40

50

60

Original 1 2 3 6 7 8 9 10

Un

idad

es d

e tr

abal

ho

Days

Burndown final


41

que afetaram o projeto de forma direta, as práticas que deviam ser utilizadas em futuros

projetos e a evolução que cada membro conseguiu ter no desenrolar do projeto. Foram

apresentados ainda, os gráficos de desempenho de cada sprint, fato este que já acontecia ao

final de cada sprint. A figura 19 mostra que para a equipe “A”, a última sprint foi semelhante

às anteriores, onde houve um pequeno atraso que poderia ser diminuído com um buffer de

aproximadamente 10% nas estimativas. A figura 20 mostra a mesma sprint executada pela

equipe “B” mantinha a tendência de um aproveitamento muito ruim graças a inclusão de um

novo elemento, alheio às técnicas de estimativas que estavam sendo encaixadas ao

desempenho da equipe já formada.

Figura 19 – Burndown da sprint 15 da equipe A


5.2 Análise qualitativa dos dados

Ao analisar o desempenho que as equipes obtiveram ao longo das sprint alguns

detalhes chamaram a atenção nas observações. Um dos fatos notados é de que após conseguir

atingir um valor agregado de 100%, utilizando a métrica de dias ideais de trabalho, mesmo

após mudar a métrica para analogia de tamanho em pontos, a equipe conseguiu manter o valor

agregado em 100%, mesmo que durante apenas duas sprint. Isto fez com que crêssemos que a

métrica utilizada para estimar o pacote de trabalha influenciava pouco as estimativas da

0

10

20

30

40

50

60

Original 1 2 3 6 7 8 9 10

Un

idad

aes

de

trab

alh

o

Days

Burndown final


42

equipe, sendo que, o conhecimento sobre o produto desenvolvido gerava estimativas mais

precisas independente da analogia que se optasse por usar naquele momento. O gráfico na

figura 21 mostra uma relação entre os valores estimados e os valores realizados em cada

sprint. A numeração à esquerda se refere ao número da sprint. Nota-se que mesmo quando

mais próximo do fim do projeto, quase não houve acréscimo da precisão das estimativas,

sendo que, o único ponto em que houve valor agregado perfeito foi nas sprint iniciais.

Figura 20 – Burndown da sprint 15 da equipe B


Como mostra a figura 22, podemos observar que a taxa de defeitos, após a sprint 3, foi

sendo diminuída até um nível considerado normal. Mas a cada modificação na estrutura da

equipe a taxa de defeitos por item entregue era elevada de alguma forma, mesmo que de

forma sutil. Além disso, a oscilação da taxa de defeitos também sofria alterações por aspectos

técnicos, tais como, cansaço dos membros da equipe, complexidade dos itens produzidos,

falta de um melhor detalhamento sobre como um processo deveria ser implementado e outras

razões. Neste sentido não é possível estabelecer que uma metodologia ágil minimize os

defeitos que são inseridos no software produzido. Há sim uma estabilização deste número de

defeitos encontrados, mas que é variável conforme outras situações podem afetar a equipe de

trabalho direta ou indiretamente. Esta estabilidade nos números pode ser explicada muito mais

0

5

10

15

20

25

30

35

40

45

50

Original 1 2 3 6 7 8 9 10

Un

idad

es d

e tr

abal

ho

Days

Total Burndown


pelo domínio de conhecimento do projeto, que é adquirido durante o projeto, do que

propriamente pela metodologia adotada pela equipe.


Outro aspecto impor

estimativas baseadas em dias

quanto tempo de um dia ideal de trabalho, seja este um dia sem interrupções e sem

empecilhos para finalizar um trabalho além de uma definição precisa do trabalho que deve ser

feito, era necessário para concluir determinada funcionalidade. Ao estimar os itens utilizando

esta forma de abordagem, a equipe inicialmente tendia a descontar os períodos, que os

membros julgavam, teriam de interrupções. Esta tentativa de alongar o tempo de uma

atividade era explicada pela lei de Parkinson, que diz

preencher o tempo disponível para ser concluído

6

0 10

2

3

4

5

6

7

8

9

10

11

12

13

14.1

14.2

15.1

15.2


propriamente pela metodologia adotada pela equipe.

Figura 21 – Estimado X Realizado

, 2012.

Outro aspecto importante de análise se refere às estimativas geradas. Ao utilizar

estimativas baseadas em dias ideais de trabalho, a equipe era reunida de forma a predizer


izar um trabalho além de uma definição precisa do trabalho que deve ser



bros julgavam, teriam de interrupções. Esta tentativa de alongar o tempo de uma

pela lei de Parkinson, que diz que, “o trabalho se expande para

preencher o tempo disponível para ser concluído” . Ou seja, mesmo tentando inserir possív

18

18

22

46

46

46

32

44

52

39

47

44

31

45

26

28

28

24

22

46

46

64

35

50

53

48

58

54

54

50

47

20 30 40 50 60

43


tante de análise se refere às estimativas geradas. Ao utilizar

de trabalho, a equipe era reunida de forma a predizer


izar um trabalho além de uma definição precisa do trabalho que deve ser



bros julgavam, teriam de interrupções. Esta tentativa de alongar o tempo de uma

o trabalho se expande para

. Ou seja, mesmo tentando inserir possíveis

64

70

Estimado

Realizado

44

folgas nas tarefas, estas folgas acabariam sendo inseridas como parte do trabalho. Com base

nesta observação, optamos por estimular que a equipe não pensasse em prazos de conclusão e

sim numa forma de medir sua própria velocidade de desenvolvimento, como forma de,

agregar um diferencial qualitativo na busca por novas promoções e resultados financeiros

internos. Quando a equipe pareceu disposta a abstrair a ideia de estimar e cumprir a

estimativa, foram iniciadas as estimativas utilizando analogias de tamanho. Vale salientar que

utilizando a abordagem de dias ideais nas estimativas, apenas na última sprint, utilizando esta

abordagem, foi possível atingir um valor agregado de 100%. Ainda assim, obtendo este valor

agregado máximo, foi perceptível a manipulação das estimativas, por parte dos membros da

equipe, de forma a contemplar períodos de folga em suas jornadas de trabalho, cumprindo

assim o que diz a lei de Parkinson.

Figura 22 – Evolução dos defeitos


Ao mudarmos a abordagem de estimativas para pontos de comparação de tamanho,

utilizando um sistema de pontuação numa escala definida, a equipe passou a estimar o quão

grande era aquela tarefa a ser estimada, comparando-a com outra tarefa de tamanho mínimo,

que servia de modelo básico para fazermos analogias. Com esta mudança, as duas primeiras

sprint mantiveram o 100% de valor agregado da sprint anterior. Isso serve como evidência de

que, a mudança dos parâmetros de estimativa não afeta inteiramente a execução do trabalho

que é feito. Ao mudarmos o enfoque das estimativas de dias ideais para tamanho de pacote de

0

2

4

6

8

10

12

14

16

18

20

2 3 4 5 6 7 8 9 10 11 12 13 14.1 14.2 15.1 15.2

Defeitos

Defeitos

45

trabalho, passamos a trabalhar com a ideia de tamanho de trabalho, eliminando quase que por

completo a necessidade de preencher um dia ideal de trabalho, mesmo que a tarefa não

demandasse isso. Além disso, ao fazermos analogias de tamanhos de pacotes de trabalho a

serem feitos, com pacotes já entregues, passamos a ter maior interesse em detalhar o que cada

pacote de trabalho deveria conter. Ao analisarmos a figura 21 podemos observar que as sprint

realizadas utilizando-se estimativas de tamanho, tiveram um valor agregado maior em

comparação com as estimativas em dias ideais. A diferença que chamou a atenção foi o fato

de que, quando a equipe sofreu alguma forma de alteração, os membros que entram na equipe

não conseguem completar o trabalho na velocidade a qual a equipe já está ajustada.

A análise das sprint realizadas mostra como foi o desenrolar do estudo. Foi possível

ver a dependência entre a equipe o valor que as estimativas produzem. Também ficou claro

que a metodologia, por si só, não é capaz de criar a agilidade no desenvolvimento de software.

46

6 CONSIDERAÇÕES PRÓPRIAS

A implantação da metodologia foi algo muito significante, mas não por promover uma

melhora na agilidade ou desempenho da equipe, e sim por possibilitar a análise de pequenos

aspectos que quando negligenciados, causam uma perda de produtividade significativa.

Ao mudarmos nossa abordagem de estimativas, de dias ideais para analogias de

tamanho, notamos que a equipe se sentia mais confortável em gerar as estimativas, uma vez

que, não havia a pressão por concluir aquela tarefa em um determinado prazo. Quando

estimávamos utilizando esta analogia de tamanho, a produtividade da equipe era mensurada

com base em quantos pontos eram concluídos por dia, ao contrário da estimativa em dias

ideais que sempre dava uma ideia de atraso quando uma tarefa não era concluída na

estimativa inicial, fato este que, acabava sempre comprometendo a produtividade e auto

estima da equipe.

Um ponto crucial verificado neste trabalho, é que, o relacionamento entre a equipe

influi decisivamente para o sucesso do projeto. Percebemos que, um bom relacionamento não

é definido por um ambiente sem rivalidades, pelo contrário, com a convivência diária os

membros acabam por criar pequenos pontos de conflito, que acabam sendo benéficos, uma

vez que, toda opinião emitida sempre encontra um ponto de divergência, que quando

estimulada de uma forma sutil, esta divergência ajuda a verificar incoerências criadas,

principalmente nas tarefas de estimar. Este ponto observado, do relacionamento da equipe,

nos mostrou uma área que pode ser mais explorada nas equipes de desenvolvimento, que são

as dinâmicas de grupo usando conceitos psicológicos que fomentem o desafio e o

questionamento das decisões que o grupo opte por tomar.

Talvez o maior aprendizado que a implantação de métodos ágeis tenham nos

proporcionado foi que, não tentar prever futuras implementações ou reaproveitamento de

código, onde não se tem 100% de certeza de que será necessário o reaproveitamento, trouxe

muito mais simplicidade e velocidade no desenvolvimento. Muitas vezes a equipe erra na

tentativa de prever um futuro uso para um determinado código fonte, quando a realidade

posterior mostra que aquilo não era necessário. Baseados na diretiva ágil que dizia para focar

em software funcionando, deixamos de lado as tentativas de antever estas necessidades e

focamos apenas em entregar aquilo que era necessário naquele momento. A prática nos

mostrou que poucas vezes realmente necessitamos refatorar o código por conta de uma nova

funcionalidade e sim refatorávamos por necessidade de adequar o conhecimento adquirido

47

sobre a funcionalidade implementada, fato este que era obtido com o andamento natural do

projeto.

Por fim, tivemos a certeza daquilo que julgávamos saber antecipadamente:

Metodologias ágeis não são uma “bala de prata”, que podem resolver os problemas de uma

área de desenvolvimento, ou até mesmo, alavancar o rendimento da equipe. São, na verdade,

uma abordagem que agrega alguns conceitos muito bons e que quando corretamente

gerenciada pode agregar em projetos de pequeno e médio porte, onde, o principal fator a ser

observado é a capacidade técnica da equipe, devendo sempre pesar positivamente a

senioridade dos membros escolhidos. O tamanho da equipe, quanto menor, melhor, parece

permitir uma melhor fluência entre o trabalho e uma melhor perspectiva de gerência sobre as

etapas do projeto.

48

7 CONCLUSÃO E TRABALHOS FUTUROS

Antes de qualquer coisa, faz-se justo salientar que não implantamos, em nenhum

momento uma metodologia tradicional, que poderia servir de base comparativa com os

resultados obtidos com esta metodologia ágil. Sendo assim, apenas pressupomos que uma

metodologia tradicional, no pior dos casos, apresentaria resultados iguais a esta metodologia

híbrida implantada. Mas esta suposição não apresenta fundamentos científicos que a sustente,

sendo apenas, um alerta para que não se façam asserções definitivas sobre as metodologias

ágeis e que, talvez, sirva de alento para um possível trabalho futuro, onde o objeto de estudo

seja a implantação de uma metodologia tradicional em um ambiente similar. Para que seja

possível esta comparação entre metodologias diferentes, o cenário deve ser reproduzido de

forma mais próxima ao descrito neste trabalho e os papéis dos participantes devem ser

preenchidos com um grau de experiência próximo ao descrito neste estudo. Todavia, mesma

que esta comparação seja feita, não poderemos ter uma resposta totalmente definitiva sobre

qual metodologia é mais eficaz, uma vez que, uma pequena variação no ambiente estudado

pode significar uma oscilação muito grande nas medidas observadas.

Quando pensamos neste estudo, logo imaginamos em mensurar a produtividade

baseados em estimativas geradas pela própria equipe de trabalho. Sabíamos antecipadamente

que a equipe poderia manipular as estimativas, criando assim um ambiente com baixa

confiabilidade para a análise de desempenho. Não somos capazes de definir qual foi o grau de

manipulação que a equipe possa ter gerado no momento de medir o que seria produzido.

Neste sentido, achamos prudente deixar aqui uma ressalva de que, sem uma forma, isenta, de

estimar os componentes do projeto a serem desenvolvidos, qualquer avaliação sobre o

desempenho da equipe apresenta um vício de origem, onde, não é possível fazer asserção

alguma sobre desempenho da equipe. Dito isto, esclarecemos que, a conclusão deste trabalho

assume, para efeitos científicos, que a equipe estudada, em momento algum, manipulou os

dados sob nenhum pretexto.

Ao efetuarmos a análise dos dados coletados durante o estudo, foi possível ter uma

noção mais precisa sobre o uso de metodologias ditas ágeis, em um ambiente sem vícios de

utilização de outras metodologias. Em nenhum momento verificou-se um incremento

considerável na velocidade de execução das tarefas, pelo contrário, em determinados

momentos a execução ficou mais demorada em virtude das constantes experimentações que a

equipe podia fazer durante o desenvolvimento. Com o passar do tempo, a união entre a equipe

acabou favorecendo a comunicação direta e informal, o que na prática, mostrou-se um fator

49

positivo, uma vez que, os membros conseguiam discutir aspectos técnicos sem a influência de

um líder para estipular regras. A criatividade acabou sobressaindo por muitas vezes,

conseguindo agregar soluções mais arrojadas. Com o decorrer das sprint as equipes

conseguiam estimar as tarefas com mais precisão, garantindo que as expectativas geradas

sobre aquilo que seria entregue ao final das duas semanas fosse real. Esta sensação de maior

agilidade foi sentida pelo usuário final, que passou a ter uma comunicação mais direta por

parte da equipe de desenvolvimento.

A taxa de defeitos que foram encontrados nos pacotes entregues foi reduzindo com o

passar do tempo. Isto ocorreu em grande parte pela pressão que a equipe tinha em produzir

funcionalidades tangíveis ao final de cada sprint. Esta pressão fez com que a equipe

priorizasse software funcional, ao invés de utilizar tempo tentando adivinhar o que o usuário

fosse precisar futuramente no pacote de trabalho em específico.

Ao adicionar um novo elemento a uma equipe já formada a velocidade da equipe era

empurrada para baixo, mesmo que o elemento adicionado fosse tecnicamente superior à

algum outro membro da equipe. Esta redução da velocidade não se explica pela questão

técnica, tampouco pelas estimativas que haviam sido feitas no product backlog, ficou claro

que o aspecto de interação entre a equipe é um elemento primordial para metodologias ágeis.

Ao entrar em um grupo já formado, caso o novo membro possuísse uma postura mais inibida,

seu rendimento era afetado pela falta de informações que ele tinha sobre o produto em si.

Uma vez que, a documentação sobre decisões de implementação é escassa, é de fundamental

importância que os membros da equipe troquem entre si os dados necessários para que o

conhecimento esteja sempre fluindo entre todos. Caso este novo membro do grupo possuísse

uma postura mais ativa e desinibida, o mesmo sofria com a dificuldade do grupo, já formado,

aceitar um novo membro que aparentasse buscar um destaque maior. Quando estudado sobre

formação de grupos, vimos que um grupo sempre elege, mesmo que informalmente, um líder

que exerce certa influência sobre os demais. Esta liderança sempre que confrontada com uma

nova forma potencial de liderança, adota uma postura de tentar isolar este novo membro. Nas

equipes de desenvolvimento este comportamento pode ser observado quando o novo membro

tentava contrariar as estimativas geradas pelo grupo e era facilmente dissuadido a mudar sua

opinião, mesmo que contra sua vontade. Algumas vezes a estimativa inicial, gerada pelo novo

membro, mostrou-se muito mais adequada do que aquela eleita pela equipe como um todo

(paradoxo de Abilene).

50

Ficou clara a dependência do projeto com os recursos humanos empregados. Esta

dependência apesar de parecer óbvia, apresentou elementos que fazem necessária uma

reflexão mais profunda antes da adoção de tais práticas, uma vez que, o autogerenciamento é

uma carga que não é bem aceita por todos os membros de uma equipe. A responsabilidade de

ter que decidir sobre detalhes de implementação traz certo desconforto a alguns membros da

equipe que acabam por optar por executar tarefas menos complexas deixando o trabalho mais

crítico para ser executado ao final dos timeboxes. Portanto, a experiência na condução desse

estudo nos leva a considerar que empregar a implantação de uma metodologia ágil em um

ambiente de desenvolvimento de software, requer muito esforço na montagem da equipe

como ponto inicial para o sucesso de qualquer projeto inovador.

Outro fator interessante a ser mencionado é a sensibilidade que alguns atributos, como

a qualidade (medida pela taxa de defeitos e precisão das estimativas), têm quando é alterada

de forma muito abrupta algum outro atributo correlato. Um exemplo desta situação fica

evidente quando alteramos o atributo equipe, seja no número de componentes ou na

formatação de equipe e no mesmo momento passamos a ter uma oscilação visível nos índices

apresentados nas entregas de pacotes. Uma análise mais detalhada de quais atributos

influenciam outros e em qual intensidade, incluindo gráficos de tornado, seria muito útil, mas

escaparia do escopo deste trabalho.

Sendo assim, consideramos que práticas ágeis possuem sim ótimos avanços na

gerência e condução das equipes, retirando um pouco da carga de gerenciamento do gerente

de projetos e repassando esta responsabilidade à equipe. Mas em contraponto, a dependência

que as metodologias ágeis têm da qualidade técnica da equipe é muito grande. O

relacionamento entre os membros da equipe também é crucial no sucesso de um projeto que

empregue este tipo de abordagem ágil. Fica claro que, em um projeto com equipes maiores e

maior heterogeneidade técnica entre os membros das equipes, uma metodologia ágil seguirá

uma tendência de instalar um caos autogerenciado pelas próprias equipes.

Como sugestão para trabalhamos futuros, elencamos alguns pontos interessantes para serem

observados, por meio de estudos de caso:

• Aplicação de uma metodologia ágil em uma equipe homogênea e com qualificação técnica

sênior, para que seja verificado se a metodologia ágil, neste caso, não irá reduzir o

desempenho dos membros;

• Analisar quais variáveis têm a maior sensibilidade, quando alterados, no que tange a

qualidade do software produzido;

51

• Efetuar a troca de uma metodologia tradicional, em um ambiente já consolidado, por uma

metodologia ágil e efetuar um comparativo com projetos passados, deste mesmo ambiente

com os projetos desenvolvidos de forma ágil.

52

REFERÊNCIAS

AMARAL, Daniel Capaldo et al. Gerenciamento ágil de projetos: aplicação em produtos inovadores. São Paulo, SP: Saraiva, 2011. COHN, Mike. Agile Estimating and Planning. Upper Saddle River. New Jersey: Pearson Education, 2006. COHN, Mike. Desenvolvimento de software com Scrum: aplicando métodos ágeis com sucesso. Porto Alegre, RS: Bookman, 2011. FERREIRA, Susan. COLLOFELLO, James. SHUNK, Dan. MACKULAK, Gerald. Understing the effects of requeriments volatility in software engineering by using analytical modeling and software process simulation. ScienceDirect, The Journal of Systems and Software, 2009. HODA, Rashina. NOBLE, James. MARSHALL, Stuart. The impact of inadequate customer collaboration on self-organizing Agile teams. Elsevier, 2010. KAYES, Imrul. Agile Testing: Introducing PRAT as a Metric of Testing Quality in Scrum. ACM SIGSOFT Software Engineering Notes, 2011. KNIBERG, Henrik. Scrum e XP direto das trincheiras: como fazemos Scrum. São Paulo: InfoQ, 2007. Disponível em: <http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches>. Acesso em 16/08/2011. KNIBERG, Henrik; SKARIN, Mattias. Kanban e Scrum: obtendo o melhor de ambos. São Paulo: InfoQ, 2009. Disponível em: <http://www.infoq.com/br/minibooks/kanban-scrum-minibook>. Acesso em 16/08/2011. LEDERER, Albert L. . PRASAD, Javesh. Nine Management Guidelines for Better Cost Estimating. Communications of the ACM, v. 35, n. 2, p. 51-59, 1992. MARIZ, Leila M. R. de Souza; FRANÇA, A. César C.; DA SILVA, Fabio Q. B. An Empirical Study on the Relationship between the Use of Agile Practices and the Success of Software Projects that Use Scrum. Brazilian Symposium on Software Engineering, 2010. MARUPING, Likoebe M.. VENKATESH, Viswanath. AGARWAL, Ritu. A Control Theory Perspective on Agile Methodology Use and Changing User Requirements. Information Systems Research, v. 20, n. 3, p. 377–399, September. 2009. MIRANDA, Eduardo; BOURQUE Bradley. Agile monitoring using the line of balance. ScienceDirect, The Journal of Systems and Software, n. 83, 2010. MOE, Nils Brede; DINGSØYR, Torgeir; DYBÅ, Tore. A teamwork model for understanding an agile team: A case study of a Scrum Project. ScienceDirect, Information and Software Technology, v. 52, p. 480–491, 2010. NEVES, Jefferson Francischetto. Utilizando EVM e análise gráfica no acompanhamento de projetos. 2009. 56 p. Trabalho de conclusão apresentado como requisito parcial para a

53

obtenção do grau de bacharel, Curso de Ciência da Computação, Centro Universitário La Salle, Canoas, 2009. PETERSEN, Kai; WOHLIN, Claes. A comparison of issues and advantages in agile and incremental development between state of the art and an industrial case. ScienceDirect, The Journal of Systems and Software, v. 82, p. 1479–1490, 2009. PMBOK. Project Management Institute. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK). 4. Ed. Newtown Square, Pensylvania: Project Management Institute, 2011. PROCTER, Rob et al. Agile Project Management: A Case Study of a Virtual Research Environment Development Project. Computer Supported Cooperative Work, v. 20, p. 197–225. 2011. SCHARFF, Christelle. Guiding Global Sotware Development Projects using Scrum and Agile with Quality Assurance. CSEET&T, 2011. SULAIMAN, Tamara. BARTON, Brent. BLACKNURN, Thomas. AgileEVM – Earned Value Management in Scrum Projects. Proceedings of AGILE 2006 Conference (AGILE'06), 2006. ZHANG, Xuesong. DORN, Bradley. Agile Pratices in a Small-Scale, Time-Intensive Web Development Project. 8, International Conference on Information Technology, New Generations, 2010.

gelsimar machado da cunha implantando metodologias Ágeis ... · metodologias ditas ágeis, scrum e...

Documents