gelsimar machado da cunha implantando metodologias Ágeis ... · metodologias ditas ágeis, scrum e...
Post on 11-Feb-2019
223 Views
Preview:
TRANSCRIPT
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
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
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
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.
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
implementação e comparada quando da entrega do item, pela equipe de desenvolvimento.
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
implementação e comparada quando da entrega do item, pela equipe de desenvolvimento.
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
Fonte: Autoria própria, 2012.
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
Fonte: Autoria própria, 2012.
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
Figura 6 – Burndown da sprint 3
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
32
Figura 7 – Burndown da sprint 4
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
33
Figura 8 – Burndown da sprint 5
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
34
Figura 9 – Burndown da sprint 6
Fonte: Autoria própria, 2012.
Figura 10 – Burndown da sprint 7
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
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
Original Commitments Baseline
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.
Figura 11 – Burndown da sprint 8
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
36
Figura 12 – Burndown da sprint 9
Fonte: Autoria própria, 2012.
Figura 13 – Burndown da sprint 10
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
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
Original Commitments Baseline
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.
Figura 14 – Burndown da sprint 11
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
38
desenvolvimento. A taxa de defeitos aumentou, sendo detectada ainda na fase de testes e
tendo seu número reduzido na entrega final.
Figura 15 – Burndown da sprint 12
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
39
Figura 16 – Burndown da sprint 13
Fonte: Autoria própria, 2012.
Figura 17 – Burndown da sprint 14 da equipe A
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
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
Original Commitments Baseline
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
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
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
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
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
Fonte: Autoria própria, 2012.
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
Original Commitments Baseline
pelo domínio de conhecimento do projeto, que é adquirido durante o projeto, do que
propriamente pela metodologia adotada pela equipe.
Fonte: Autoria própria, 2012.
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
pelo domínio de conhecimento do projeto, que é adquirido durante o projeto, do que
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
quanto tempo de um dia ideal de trabalho, seja este um dia sem interrupções e sem
izar 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
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
pelo domínio de conhecimento do projeto, que é adquirido durante o projeto, do que
tante de análise se refere às estimativas geradas. Ao utilizar
de trabalho, a equipe era reunida de forma a predizer
quanto tempo de um dia ideal de trabalho, seja este um dia sem interrupções e sem
izar 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
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
Fonte: Autoria própria, 2012.
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.
top related