Content uploaded by Herez Kattan
Author content
All content in this area was uploaded by Herez Kattan on Apr 26, 2017
Content may be subject to copyright.
Instituto de Pesquisas Tecnológicas do Estado de São Paulo
Herez Moise Kattan
Programação e revisão simultânea em Pares: uma extensão à
programação em par
São Paulo
2015
Herez Moise Kattan
Programação e revisão simultânea em Pares: uma extensão à
programação em par
Dissertação de Mestrado apresentada ao Instituto de
Pesquisas Tecnológicas do Estado de São Paulo - IPT,
como parte dos requisitos para a obtenção do título de
Mestre em Engenharia de Computação.
Área de Concentração: Engenharia de Software.
Data da aprovação ______/_______/____________
__________________________________________
Prof. Dr. José Eduardo Zindel Deboni (Orientador)
IPT – Instituto de Pesquisas Tecnológicas do Estado
de São Paulo
Membros da Banca Examinadora:
Prof. Dr. José Eduardo Zindel Deboni (Orientador)
IPT – Instituto de Pesquisas Tecnológicas do Estado de São Paulo
Prof. Dr. Alfredo Goldman vel Lejbman (Membro)
IME-USP – Instituto de Matemática e Estatística da Universidade de São Paulo
Prof. Dr. Eduardo Martins Guerra (Membro)
INPE – Instituto Nacional de Pesquisas Espaciais
Herez Moise Kattan
Programação e revisão simultânea em Pares: uma extensão à
programação em par
Dissertação de Mestrado apresentada ao Instituto de
Pesquisas Tecnológicas do Estado de São Paulo - IPT,
como parte dos requisitos para a obtenção do título de
Mestre em Engenharia de Computação.
Área de Concentração: Engenharia de Software.
Orientador: Prof. Dr. José Eduardo Zindel Deboni
São Paulo
Dezembro/2015
RESUMO
A programação em pares é uma prática para equipes de desenvolvimento de
software que melhora a qualidade do código desenvolvido, aumenta o nível técnico da
equipe, estimula a disseminação do conhecimento, promove a ideia de propriedade e
responsabilidade coletiva para o sistema, reduz o número de defeitos do sistema,
estimula a satisfação, motivação, colaboração, comunicação e a confiança entre os
membros da equipe. Porém, com perda de produtividade em alguns casos. Este
trabalho usa a Engenharia Simultânea, Code Review, Mob Programming e Coding
Dojo, visando aumentar a produtividade no desenvolvimento da programação em
pares, criando uma nova técnica vantajosa para programadores de diferentes graus de
experiência e tarefas de diversos níveis de complexidade. O trabalho se inicia com a
revisão do estado da arte da programação em pares e em grupo, revisão de código e
engenharia simultânea. A técnica proposta é baseada nos pontos fortes encontrados
na revisão bibliográfica sobre estas técnicas correlatas. São realizados exemplos de
aplicação prática, onde a produtividade e qualidade são medidos. Os resultados
mostram que a nova técnica é eficaz nos exemplos de aplicação realizados,
observando o aumento da produtividade no desenvolvimento e da qualidade do
produto de software.
Palavras-chave: Técnicas ou práticas de desenvolvimento e teste de software;
Programação em Pares ou em Grupo; Revisão de Código; Engenharia Simultânea.
ABSTRACT
Programming and review simultaneous in Pairs: a pair programming extension
The pair programming is a practice for software development teams to improve the
quality of their code and the technical level of the team, encourages the
dissemination of knowledge, it promotes the idea of ownership and collective
responsibility for the system, reduces the number system defects, stimulates
satisfaction, motivation, collaboration, communication and trust among team
members. But its burden is the loss of productivity in some cases. This work uses the
Concurrent Engineering, Code Review, Mob Programming and Coding Dojo, aiming
to increase productivity in the development of pair programming, creating a new
advantageous technique for programmers with different expertise levels and tasks of
various levels of complexity. The work begins with the state of the art review of
pair/mob programming, code review and concurrent engineering. The propose
technique is based on the strengths found in the literature review of this correlative
techniques. Examples application are carried out in practical, where productivity and
quality are measured. The results show that the new technique is effective in
application examples performed by observing the increase in development
productivity and quality of the software product.
Key Words: Techniques or practices to software development and software testing;
Pair Programming; Mob Programming; Code Review; Concurrent Engineering.
SUMÁRIO
1 INTRODUÇÃO ......................................................................................................... 8
1.1 Motivação .............................................................................................................. 8
1.2 Objetivo ............................................................................................................... 10
1.3 Contribuições ...................................................................................................... 10
1.4 Método de trabalho ............................................................................................. 10
1.5 Organização do trabalho ..................................................................................... 11
2 REVISÃO BIBLIOGRÁFICA .................................................................................. 12
2.1 Programação em pares (pair programming) ........................................................ 12
2.1.1 Resumo dos pontos fortes e fracos .............................................................. 29
2.2 Programação em grupo (mob programming) ...................................................... 30
2.2.1 Pontos fortes e fracos .................................................................................. 33
2.3 Revisão de código (code review) ........................................................................ 34
2.3.1 Pontos fortes e fracos .................................................................................. 35
2.4 Engenharia simultânea (concurrent engineering) ................................................ 36
2.4.1 Pontos fortes ................................................................................................ 37
2.4.2 Pontos fracos ............................................................................................... 38
2.4.3 Equipes de trabalho ..................................................................................... 39
2.4.4 Trabalho colaborativo ................................................................................... 40
2.4.5 Groupware ................................................................................................... 41
2.4.6 Trabalho simultâneo ..................................................................................... 42
2.4.7 Equipe multidisciplinar .................................................................................. 44
3 PROGRAMAÇÃO E REVISÃO SIMULTÂNEA EM PARES .................................. 45
3.1 Introdução ........................................................................................................... 45
3.2 Definição da Programação e revisão simultânea em Pares ................................ 45
3.3 Descrição ............................................................................................................ 45
3.4 Fases................................................................................................................... 47
3.5 Dois teclados ao invés de um, ajuda a manter o comprometimento do par ........ 51
3.6 Sentar junto apenas para conversar ao invés de durante todo o expediente,
pode ajudar a aumentar a produtividade ...................................................... 52
3.7 Fatores de produtividade ..................................................................................... 52
3.8 Conclusão ........................................................................................................... 54
4 EXEMPLOS DE APLICAÇÃO DA NOVA TÉCNICA ................................................ 55
4.1 Medidas, métricas, indicadores e ferramentas aplicáveis à PrsP ........................ 57
4.2 Primeiro exemplo, software para atividades esportivas....................................... 62
4.3 Segundo exemplo, homebroker .......................................................................... 64
4.4 Terceiro exemplo, e-commerce ........................................................................... 67
4.5 Quarto exemplo, aplicativos financeiros .............................................................. 69
4.6 Quinto exemplo, software financeiro para Distributed Market Access ................. 70
4.7 Sexto exemplo, software para seguradoras ........................................................ 71
4.8 Sétimo exemplo, gerenciador de contratos ......................................................... 71
4.9 Oitavo exemplo, exercício de programação ........................................................ 72
4.10 Resultados ........................................................................................................ 72
5 ANÁLISE DOS RESULTADOS E VALIDAÇÃO DA NOVA TÉCNICA ................... 74
6 CONCLUSÃO, LIMITAÇÕES E TRABALHOS FUTUROS ...................................... 79
REFERÊNCIAS ................................................................................................................. 81
8
1 INTRODUÇÃO
1.1 Motivação
A programação em pares é uma prática para equipes de desenvolvimento de
software, é também um processo de revisão informal, melhora a qualidade do código
desenvolvido e o nível técnico da equipe. Ela estimula a refatoração, promove a
propriedade e responsabilidade coletiva para o sistema e reflete a ideia de Weinberg
(1971) de programação sem ego, onde o software é de propriedade da equipe como
um todo e os indivíduos não são responsáveis pelos problemas com o código; toda a
equipe tem responsabilidade em resolver estes problemas.
O código produzido é escrito por pares de programadores, que possuem
papéis distintos, sentados lado a lado e usando o mesmo computador. Um parceiro
é responsável pela codificação e pensa nos algoritmos e na lógica de programação.
O outro parceiro observa o código produzido e tenta pensar mais estrategicamente
em como melhorá-lo e torná-lo mais simples, além de verificar possíveis erros e
pontos de falha. (BECK, 1999)
A ideia é desenvolver software em duplas de programadores e não como uma
atividade isolada de uma só pessoa. Dois desenvolvedores dividem o mesmo
teclado e o mesmo monitor. Com isso promove-se aspectos sociais da programação,
enquanto um cria o código o outro desenvolvedor pode revisar, discutir alternativas,
verificar a qualidade do código e ajudar em passagens complexas. Segundo
Cockburn et al. (2000) a programação em pares envolve comunicação e colaboração
constantes. Estimula a disseminação do conhecimento entre os membros da equipe.
A programação em pares promove a confiança entre os programadores
(SLATEN et al., 2004). Bella et al. (2013) constatou em seu trabalho redução do
número de defeitos ao usar a programação em pares. Segundo Plaue et al. (2013) a
programação em pares estimula o companheirismo. É um fator de proteção para
conservação e diminuição da evasão de mulheres e programadores novatos nos
cursos de ciências da computação. Pode ser uma intervenção de baixo custo para a
redução do turn-over em equipes de software. Jones et al. (2013) observa que o
parceiro que não está na posse do teclado, contribui com boas ideias e Sillitti et al.
(2012) que ajuda a manter disciplina e concentração em atividades produtivas.
Conforme Dyba et al. (2007) o produto desenvolvido pela programação em
pares é, em geral, de qualidade superior a métodos convencionais. Porém,
9
constatou-se também ao revisar quinze outras pesquisas sobre programação em
pares, que ocorre perda de produtividade ao usar a técnica, especialmente para
programadores experientes e tarefas simples. Observa-se ao usar a programação
em pares, o aumento do esforço no projeto, se comparado à programação individual.
A perda de produtividade é uma crítica frequente à programação em pares,
uma vez que se está dedicando dois profissionais para executar o mesmo trabalho.
Há uma constante discussão nos meios acadêmicos e profissionais se as vantagens
da técnica, justificam esta perda de produtividade.
Existem técnicas correlatas, como o mob programming, onde toda a equipe
participa em torno de um computador (ZUILL, 2012) e a revisão de código em pares,
que atualmente são alternativas analisadas, inclusive acerca da produtividade obtida
em relação à programação em pares. (SWAMIDURAI, DENNIS e KANNAN, 2014)
Em 1982 foi iniciado um estudo, conduzido pelo DARPA (Defense Advanced
Research Project Agency – Agência de Projetos de Investigação Avançada de
Defesa), buscando uma forma de aumentar o grau de paralelismo das atividades de
desenvolvimento de produtos. O resultado deste trabalho, definiu o termo
Engenharia Simultânea como:
Engenharia Simultânea é uma abordagem sistemática para o
desenvolvimento integrado e paralelo do projeto de um produto e os
processos relacionados, incluindo manufatura e pós-venda Esta
abordagem procura fazer com que as pessoas envolvidas no
desenvolvimento considerem, desde o início, todos os custos, prazos e
requisitos dos clientes. (WINNER et al., 1988)
A Engenharia Simultânea é baseada na ideia do processamento
paralelo/simultâneo dos processos da empresa, que reduz o tempo de lançamento
de um novo produto bem como a melhoria da qualidade.
Os mecanismos básicos para a implementação dos processos em
paralelo/simultâneo são as equipes multifuncionais (também chamadas de “força-
tarefa”), que trabalham simultaneamente juntas, e a correspondente troca de
informações tecnológicas e ferramentas para suportar os processos de Engenharia
Simultânea. (PITHON, 2004)
Uma possível alternativa para o aumento da produtividade na programação
em pares é o uso do paralelismo e das equipes multidisciplinares da Engenharia
Simultânea, para que o desenvolvimento seja feito de maneira simultânea. Outra
possibilidade é a incorporação de um processo de revisão de código baseado em
pares e, uma fase para projetar o emparelhamento do desenvolvimento simultâneo.
10
1.2 Objetivo
Propor uma técnica para desenvolvimento e testes de sistemas de software
mais produtiva em relação à programação em pares, por meio da incorporação de
aspectos de Engenharia Simultânea, Revisão de Código em Pares e Mob
Programming. Avaliar a técnica, e se preserva a qualidade do produto quando
comparada à programação em pares.
1.3 Contribuições
A principal contribuição é uma revisão e aprimoramento da programação em
pares, na forma de uma nova técnica de organização do trabalho dos
programadores com base no paralelismo e equipes multidisciplinares da engenharia
simultânea, incorporação de um processo de revisão de código baseado em pares e,
uma fase para projetar o emparelhamento do desenvolvimento simultâneo e outra
para o descanso reflexivo, prevenção e resolução de conflitos.
O trabalho traz como contribuições complementares, uma revisão bibliográfica
da programação em pares e em grupo, revisão de código e engenharia simultânea,
novas métricas para produtividade das equipes e qualidade do produto software.
Produzir mais em menos tempo, gera um ganho de tempo, que além da economia
de recursos ou redução do time-to-benefit, pode significar a redução do time-to-
market (tempo transcorrido desde a detecção da necessidade, até a introdução de
um novo produto no mercado) do produto de software desenvolvido, que são
contribuições indiretas deste trabalho.
1.4 Método de trabalho
Para cumprir o objetivo, o método de trabalho adotado é: começar pela revisão
do estado da arte da programação em pares, programação em grupo, revisão de
código e engenharia simultânea. Em seguida, são estabelecidas as métricas para
permitir a avaliação da produtividade no desenvolvimento de software e qualidade
do produto de software. Depois é proposta uma técnica baseada nos pontos fortes
encontrados na revisão bibliográfica das técnicas correlatas.
Para avaliar a eficácia da nova técnica são verificados nos exemplos de
aplicação se a nova técnica foi mais produtiva e a qualidade do produto de software.
A aplicação da nova técnica é realizada em ambiente acadêmico e corporativo.
São realizados exemplos de aplicação em empresas de tecnologia da informação,
desenvolvimento de software, instituições financeiras e instituições de ensino que
11
permitam mensurar, classificar e relatar a experiência com programação dos
participantes, produtividade obtida durante o desenvolvimento de software no
exemplo de aplicação, qualidade e o número de defeitos em comparação à
programação em pares.
É feita a análise dos resultados obtidos nos exemplos de aplicação para com
base nestes dados, avaliar a eficácia da nova técnica e na busca por explicações.
Na conclusão, encerra-se a pesquisa discorrendo sobre um resumo dos
resultados obtidos nos exemplos de aplicação, as contribuições, uma explanação
das limitações e as recomendações para trabalhos futuros.
1.5 Organização do trabalho
A seção 2, Revisão Bibliográfica, apresenta o estado da arte da programação
em pares, programação em grupo, revisão de código e engenharia simultânea.
A seção 3, Programação e revisão simultânea em Pares, apresenta a nova
técnica, principal objeto de pesquisa deste trabalho. A PrsP é especificada e descrita
com intuído de permitir a avaliação e comparação com outras técnicas; é descrito
como trabalhar em pares usando uma equipe multidisciplinar; é feita uma
explanação sobre a responsabilidade e autoridade dos pares para as decisões, o
planejamento e emparelhamento do projeto, o paralelismo durante a execução da
tarefa, o processo de revisão do código, o descanso produtivo e reflexivo, bem como
o processo sugerido para resolução de conflitos.
A seção 4, Exemplos de aplicação da técnica, apresenta o sumário e os
detalhes de todos exemplos de aplicação realizados, concentrando-se na
produtividade obtida durante o desenvolvimento de software, qualidade e o número
de defeitos em comparação à programação em pares. São apresentadas as novas
métricas de avaliação da produtividade e qualidade do produto de software obtido
com a PrsP, baseadas nas ferramentas, medidas, indicadores e pesquisas atuais
disponíveis, para comparação da nova técnica à programação em pares com
precisão superior a linhas de código por desenvolvedor e contagem de defeitos.
A seção 5, Análise dos resultados e validação da técnica, detalha e analisa os
resultados obtidos durante a pesquisa, culminando com a avaliação da nova técnica,
baseando-se nos resultados para avaliar sua eficácia e na busca por explicações.
A seção 6, Conclusão, limitações e trabalhos futuros, conclui a pesquisa,
discorrendo sobre um resumo dos resultados, das contribuições, limitações e
sugestões para trabalhos futuros.
12
2 REVISÃO BIBLIOGRÁFICA
Esta seção revisa a literatura da programação em pares (pair programming),
programação em grupo (mob programming), revisão de código (code review) e
engenharia simultânea (simultaneous engineering ou concurrent engineering).
2.1 Programação em Pares (Pair Programming)
A questão da revisão da literatura da programação em pares é: Quais são os
pontos fortes e fracos já observados e/ou constatados da programação em pares?
As palavras chaves utilizadas para pesquisa dos artigos abrangem: pair
programming, paired programming, double programming, programação em par(es),
programação em dupla(s) e pareamento.
O período pesquisado é de 40 anos, com estudos publicados entre os anos
1975 e 2015.
Cada estudo encontrado foi avaliado conforme o seguinte critério de inclusão:
todos os trabalhos cujo objeto de pesquisa é programação em pares são incluídos.
Os seguintes tipos de trabalhos foram excluídos: publicações sem um método
de pesquisa, publicações que já tenham sido analisadas numa revisão sistemática
ou duplicadas e feitas em idioma diferente do português e inglês.
A definição da programação em pares é que dois programadores trabalham
colaborativamente na mesma atividade, sentados lado a lado em frente a um único
computador. Enquanto uma pessoa está escrevendo o código, por exemplo, a outra
observa atentamente o trabalho produzido, buscando defeitos e sugestões de
melhoria. A programação em pares estimula a disseminação do conhecimento,
reduz a quantidade de defeitos e gera software com mais qualidade. (BEGEL;
NAGAPPAN, 2008)
Apesar de ter sido conhecida como uma técnica associada ao método eXtreme
Programming, a criação da programação em pares é anterior ao método XP.
Existem muitos relatos antigos favoráveis à técnica, como o relato de Brooks (1975)
ao programar em par na faculdade entre 1953 e 1956, ele e seu par escreveram
1500 linhas de código, que executaram sem nenhum erro na primeira tentativa.
Coplien e Schmidt (1995) com base em resultados do projeto de investigação
Pasteur (um grande estudo sociológico/antropológico com cinquenta organizações
de desenvolvimento de software altamente eficazes) da Bell Labs Research,
13
publicaram um padrão para organização do trabalho dos programadores chamado
"desenvolvimento em pares", os autores deste padrão destacaram que pessoas às
vezes sentem que apenas podem resolver um problema se tiverem ajuda. Alguns
problemas são maiores do que qualquer indivíduo.
A solução para Coplien e Harrison (2005) é tornar os projetos compatíveis com
o emparelhamento de trabalhar em conjunto; desta forma podem produzir mais do
que a soma dos dois individualmente.
Rotação dos pares, disseminação do conhecimento e redução dos defeitos
Constantine (1995) publicou a redução do número de defeitos ao programar-se
em pares.
Nosek (1998) constatou que a programação em pares melhora a qualidade do
código e do algoritmo, porém, constatou também o aumento do esforço no
desenvolvimento, pois observou que o par gastou mais horas de trabalho do que se
um único programador trabalhasse isoladamente.
Uma vantagem da rotação dos pares é espalhar o conhecimento do sistema
pela equipe inteira. Como importante efeito colateral temos também o
compartilhamento de técnicas e competências entre os membros da equipe
(WILLIANS; KESSLER, 2000).
A inclusão de um novo membro na equipe que não conhece o sistema cria o
problema do primeiro contato com o código. A programação em pares contribui para
resolução deste problema, pois o novo membro da equipe pode trabalhar em par
com alguém mais experiente. (WILLIAMS; KESSLER, 2003)
Os pares são constantemente trocados e os papéis também, objetivando
permitir a todos os membros da equipe ter conhecimento sobre todas as partes do
sistema, resolvendo o problema de um único desenvolvedor deter o conhecimento
sobre uma parte do sistema. Disseminando o conhecimento, mais pessoas
participam do desenvolvimento de uma funcionalidade e aprendem como o sistema
ou uma ferramenta de desenvolvimento funciona. (BECK et al., 2004)
Bella et al. (2013) publicou um estudo de caso que foi realizado para avaliar o
efeito da programação em pares na qualidade e eficiência das correções de defeitos.
Foi estudado um projeto de desenvolvimento de software em uma grande empresa
italiana, por um prazo de quatorze meses. Comparado com estudos de casos
existentes de programação em pares, o período mais longo torna o estudo mais
14
realista. Em análise exploratória, a efetividade da programação em pares foi
investigada no contexto de correções de defeitos e implementações de histórias de
usuários. A análise mostra que a introdução de novos defeitos tende a diminuir
quando a programação em pares é usada. Os resultados são consistentes para
ambos os contextos.
Swamidurai e Umphress (2014) constataram aumento da produtividade
quando a programação em pares é dinâmica, ou seja, há rotação dos pares na
equipe. A produtividade é menor quando a programação em pares é estática, sem
rotação dos pares na equipe.
Projeto pequeno, muitos desenvolvedores e período curto de desenvolvimento
A pesquisa conduzida por Smith et al. (2002) reconheceu o importante papel
da programação em pares. Ela se relaciona diretamente a quase todas as outras
práticas do método XP, conforme ilustra a Figura 1. A centralidade da programação
em pares para o método XP é evidenciada devido ao fato de que caso removida
afetaria diretamente todas as práticas relacionadas. O trabalho observa o problema
de produtividade da programação em pares e conclui que a NASA não deveria usar
método ágil baseado em programação em pares em 64% dos seus projetos. Para os
demais casos, o método usado na pesquisa apenas endossou vantagem sobre
abordagens convencionais em um relativamente pequeno e específico conjunto de
casos: quando o projeto é relativamente pequeno, quando existe uma abundância
de desenvolvedores e se o período de desenvolvimento for curto.
Figura 1 - Práticas do método XP relacionadas à programação em pares
Fonte: Smith et al. (2002)
Para Padberg e Müller (2003), o código produzido usando a programação em
pares é mais livre de defeitos, pois todo o código é revisado por pelo menos um
programador. Eles concluem que, quando a pressão do mercado é forte, acrescentar
15
desenvolvedores e formar mais pares, pode acelerar o projeto e aumentar o seu
valor para o negócio, apesar de aumentar também o custo.
Processo de revisão/inspeção informal e comunicação
Para Williams et al. (2000) a utilização da técnica de programação em pares
atua como um processo de revisão informal, porque cada linha de código é olhado
por pelo menos duas pessoas. Inspeções de código ajudam muito na descoberta de
uma elevada percentagem de erros de software. No entanto, são demorados para
organizar e, geralmente, representam atrasos no processo de desenvolvimento.
Para Cockburn e Williams (2000 e 2001) a programação em pares é um
processo de revisão menos formal e, provavelmente, não encontra tantos erros
como inspeções de código, porém, é muito mais barato que um processo de
inspeção formal. Ela apoia a refatoração, que é um processo de melhoria de
software. A dificuldade de implementar isso em um ambiente normal de
desenvolvimento de software é que o esforço em refatoração é gasto no presente,
para um benefício a longo prazo no futuro. Quando são utilizados a programação em
pares e propriedade coletiva, outros desenvolvedores se beneficiam imediatamente
da refatoração e eles tendem a apoiar o processo, pois reconhecem seu benefício.
Cockburn et al. (2001) e Williams et al. (2000) em seus trabalhos usaram
programadores iniciantes e observaram que a produtividade, ao usar a programação
em pares, parece ser comparável à de duas pessoas trabalhando de forma
independente. Uma razão sugerida é que programando em pares discute-se o
sistema antes de desenvolvê-lo, então provavelmente ocorrerá menos erros e
retrabalho. Além disso, o número de erros evitados pela inspeção informal realizada
pela programação em pares é tal que menos tempo é gasto na reparação de bugs
descobertos durante o processo de testes.
Du et al. (2015) Executaram um experimento de programação básica usando
a linguagem de programação C. Os resultados são analisados por meio de
entrevistas após a realização do experimento e a conclusão é que a programação
em pares é eficaz para melhorar a comunicação em um exercício básico de C.
Experiência do programador e complexidade da tarefa
Arisholm et al. (2007) e Parrish et al. (2004) realizaram seus trabalhos com
programadores experientes. Eles descobriram que houve uma significativa perda de
produtividade em comparação a dois programadores trabalhando sozinhos. Havia
16
alguns benefícios na qualidade, mas que não compensavam totalmente a perda da
produtividade da programação em pares. No entanto, segundo eles, a partilha de
conhecimento que acontece durante a programação em pares é muito importante,
pois reduz os riscos globais de um projeto no caso de algum membro da equipe sair
e isso pode justificar o seu uso.
Hulkko e Abrahamsson (2005) observaram em quatro estudos de caso a
eficácia da programação em pares na disseminação de conhecimento e que ela é
mais útil em tarefas complexas.
A pesquisa conduzida por Dyba et al. (2007) revisou quinze trabalhos sobre
programação em pares e todos eles usaram tarefas de programação como base
para a comparação. O número de indivíduos nos estudos oscilou entre 12 e 295. O
estudo concentrou-se nos aspectos: duração, tempo do calendário de
desenvolvimento; esforço, mensurado em horas de trabalho; qualidade, quanto
melhor ficou o produto final. Ao analisar-se o resultado, constata-se a melhora da
qualidade, redução do número de defeitos, porém, observa-se também, ao usar a
programação em pares, o aumento do esforço no projeto, se comparado à
programação individual.
Conforme é descrito no Quadro 1, há uma relação direta das vantagens da
programação em pares com a experiência do programador e complexidade da
tarefa, apenas um estudo (apesar de grande e consistente) dos quinze revisados
levou em consideração a complexidade da tarefa e experiência do desenvolvedor,
há a necessidade de mais estudos que levem-nos em consideração.
Quadro 1 – Diretriz para quando usar a programação em pares
Experiência do
programador
Complexidade da tarefa
É vantajoso usar a programação
em pares?
Júnior
Simples
Sim, se o aumento da qualidade é o
principal objetivo.
Júnior
Complexa
Sim, se o aumento da qualidade é o
principal objetivo.
Pleno
Simples
Não.
Pleno
Complexa
Sim, se o aumento da qualidade é o
principal objetivo.
Sênior
Simples
Não.
Sênior
Complexa
Não, a menos que a tarefa é
complexa demais para ser resolvida
por apenas um programador sênior.
Fonte: Dyba et al. (2007)
Legenda: Júnior = programador iniciante; Pleno = programador de experiência
intermediária; Sênior = programador experiente.
17
Engenheiros de software relatam que a programação em pares é mais útil para
projetar o software e tarefas complexas de programação. (VANHANEN et al., 2007)
Beck (2012) baseado em sua experiência de décadas com a programação em
pares, publicou em seu perfil @KentBeck na rede social Twitter, que a programação
em pares funciona melhor quando existe um grande espaço de incerteza na busca
pela solução de problemas e soluções, quanto mais próximo da solução do
problema, menos a técnica ajuda.
Sison (2009) observou em dois experimentos realizados com quarenta e oito
estudantes do terceiro ano de ciências de computação, que há melhora da qualidade
(foi medida através da densidade de defeitos) ao usar a programação em pares e
quando o projeto é suficientemente grande ou complexo para permitir a colaboração
entre os programadores, a perda de produtividade é reduzida.
Gênero, confiança e satisfação dos programadores
A programação em pares estimula a motivação e satisfação dos
programadores (PADBERG et al., 2004). Ela melhora a qualidade do código,
aumenta a confiança e satisfação dos programadores (observou-se aumento de
24% para mulheres e 15% para homens) e reduz a evasão de estudantes dos
cursos de computação, pesquisa coletou dados de 554 estudantes da universidade
Santa Cruz na California-USA. (MCDOWELL et al., 2006).
Choi (2013) conduziu um experimento para avaliar a relevância do gênero no
contexto da programação em pares, participaram 128 estudantes, sendo 93 homens
e 35 mulheres. Observa-se no resultado que não há diferença na habilidade de
programação e resolução de problemas, porém, ocorre diferença significativa na
comunicação e compatibilidade do par, pares do mesmo gênero, homem-homem e
mulher-mulher, apresentaram maior nível de comunicação e compatibilidade. Pares
do mesmo gênero, pode ser uma diretriz, na hora de realizar a seleção dos pares.
Mecanismos para melhorar o desempenho da programação em pares
Wray (2010) apresentou quatro mecanismos para melhorar o desempenho da
programação em pares: conversar, avisar mais detalhes, lutar contra práticas ruins
de programação e compartilhar e reconhecer competências.
A conversa entre os programadores é importante para o bom desempenho da
técnica, parte da eficácia da programação em pares é presumivelmente devida à
interação entre os programadores. Quando os programadores falam sobre o
18
problema no momento da dúvida, encontram mais rapidamente a solução, e
consequentemente há o aumento da produtividade.
Nota-se mais detalhes ao programar em par, portanto, é importante avisar o
par, pois talvez ele não tenha notado o mesmo ponto, pois a capacidade de
percepção do ser humano depende do objetivo da busca, há um ponto cego na
atenção humana em relação ao inesperado, o ser humano tem dificuldade de notar
algo que não estava esperando, que não estava concentrado naquele ponto. Isso
ajuda a explicar o motivo da rotação do par evitar a fadiga. A fadiga diminui a
produtividade, e trocar a pessoa do par que digita no teclado durante o expediente
pode aumentar a produtividade. É importante levar em consideração que
programadores iniciantes aumentam sua produtividade quando seu par é mais
experiente.
Lutar contra práticas ruins de programação aumenta o desempenho, a
pressão do par contribui para melhorar a qualidade da programação, porém, deve-se
evitar considerar que o trabalho num trecho de código está concluído simplesmente
porque executou sem erro de sintaxe. É importante buscar seguir os padrões de
programação e programar da melhor maneira possível para que o código não se
torne ruim e desorganizado, desta maneira evita-se retrabalhos e aumenta a
produtividade. Compartilhar e reconhecer competências, promove a disseminação
do conhecimento. A descoberta de quem são os especialistas em determinados
assuntos e compartilhar o conhecimento pode aumentar a produtividade. Wray
(2010) sugere ainda refazer a pesquisa de Dyba et al. (2007) considerando seus
quatro mecanismos e pensar em novos critérios e método para mensurar
eficientemente o desempenho, levando em consideração estes mecanismos.
É realizada uma adaptação na programação em pares por Swamidurai e
Umphress (2015) onde o par não trabalha lado a lado em todas as fases de
desenvolvimento de software; em vez disso, a dupla começa projetando juntos, se
separaram durante a implementação, em seguida, juntam-se novamente para o
teste. Dois estudos empíricos foram realizados na primavera de 2009 e no verão de
2012 para validar a programação em par invertida contra programação em pares
tradicional. Os resultados deste experimento são favoráveis à programação par
invertida e não suportam a alegação de que a programação em pares, em geral
reduz a duração de desenvolvimento de software ou custo total de desenvolvimento
de software.
19
Posse do teclado
É importante o par revezar a posse do teclado para manter ambos
comprometidos (VANHANEN; KORPI, 2007); (WILLIAMS; KESSLER, 2003).
Quando o par tem nível diferente de experiência, o programador mais experiente
tende a dominar a posse do teclado. Os engenheiros de software parecem mais
comprometidos na posse do teclado. Para promover o comprometimento de ambos,
é sugerido o uso de dois teclados e dois mouses. (CHONG; HURLBUTT, 2007);
(FREUDENBERG; ROMERO; BOULAY, 2007); (HÖFER, 2008).
Plonka, Sharp e van der Linden (2012) publicaram um estudo sobre
programação em pares com programadores profissionais e observaram que dentre
os pares, quem não estava na posse do teclado, muitas vezes tinham razão para
separar-se, dependendo da atividade de quem esta na posse do teclado, devido as
interrupções ou porque eles dividiram trabalho a ser feito em paralelo. É observado
que essa separação não é necessariamente um problema.
Programação em pares distribuída
A programação em pares é uma prática que pode ser implementada de forma
distribuída. O trabalho de Bandukda et al.(2010) concluiu que a programação em
pares distribuída, onde os pares estão em dependências físicas diferentes e
comunicam-se por voz e software de mensagens de texto, pode ser usada para
aumentar a produtividade do desenvolvimento e a qualidade do produto.
Um trabalho de Williams e Stout (2008) descreveu algumas modificações nas
práticas ágeis adotadas por uma empresa para reduzir os problemas no
desenvolvimento de software distribuído entre America do Norte e Europa. A criação
do papel do “usuário ágil”. Assim como o “analista de negócio suplente do cliente”
recomendado por Hildebrand et al. (2008) e a criação de “salas virtuais de
conferência”, para resolver problemas de ineficiência de ferramentas de
comunicação e de disciplina durante as reuniões. Concluíram que é possível
distribuir e escalar equipes ágeis, mas mantê-las pequenas e juntas é a melhor
alternativa.
Estácio e Prikladnicki (2015) realizaram uma revisão sistemática sobre a
programação em pares distribuída e concluiu-se que há a necessidade de mais
estudos na indústria de software sobre a programação em pares distribuída; há uma
boa oportunidade para pesquisas neste tema; há uma tendência no uso e pesquisa
da programação em pares distribuída no ensino de programação. Há a necessidade
20
de investigar os efeitos da programação em pares distribuída em profissionais. O
nível de dispersão das equipes foi pouco contextualizada nos trabalhos
pesquisados. Há oportunidade para investigação dos efeitos da coordenação,
comunicação e diversidade cultural na programação em pares distribuída. Há a
necessidade de explorar mais diretrizes (guidelines) para implementação da
programação em pares distribuída na industria de software. Há oportunidade para
explorar o projeto, a implementação e as ferramentas voltadas à programação em
pares distribuída. Há oportunidade para investigar a programação em pares
distribuída com outras formas de programação colaborativa.
Preceptores de desempenho e cultura organizacional
Segundo Hannay et al. (2010), a personalidade pode ser um indicador válido
para o desempenho da equipe no longo prazo. No entanto, não é encontrado
indícios fortes que a personalidade afeta o desempenho ou benefícios da
programação em pares de uma forma consistente, especialmente quando incluindo
indicadores relativos à perícia, a complexidade da tarefa e do país. No curto prazo,
vale a pena para indústria e pesquisadores, concentrarem-se em outros preceptores
de desempenho, incluindo experiência e complexidade da tarefa. Desperta-se
atenção para os fatores que podem ser relevantes, tais como a aprendizagem em
equipe, motivação da equipe, e habilidade de programação. Em contraste com
traços de personalidade, que são fixados em uma pessoa, são fatores maleáveis,
tais como: aprendizagem, motivação, e empenho para realizar benfeitorias ao
software produzido.
Plonka e van der Linden (2012) identificaram em quatro empresas, aspectos
que dificultam a adoção da programação em pares. Eles descrevem que estes
aspectos estão relacionados com questões da organização, como a cultura
organizacional e estilo de gestão. Como consequência, a cultura organizacional é
considerada fundamental para a ampliação da adoção da programação em pares
entre as equipes destas quatro empresas estudadas.
Companheirismo
Foi realizado por Plaue et al. (2013) um estudo experimental de programação
em pares contra programação individual. O resultado mostra que a programação em
pares estimula o companheirismo. É um fator de proteção para conservação e
diminuição da evasão de mulheres e programadores novatos nos cursos de ciências
21
da computação. Pode ser uma intervenção de baixo custo para a redução do turn-
over em equipes de software.
Interrupções e aprendizagem cognitiva
Sillitti et al. (2012) observaram que as pessoas mudam de forma relevante
seus hábitos de trabalho quando trabalham em pares e tendem a concentrar-se mais
em atividades produtivas. As sessões de trabalho são significativamente mais longas
e ininterruptas e eles concentram-se mais nas tarefas, diminuindo distrações como
e-mails, navegadores de internet e programas de bate-papo. Ao mesmo tempo é
encorajada a discussão, melhorando a solução criada e ajudando o par a ter uma
visão mais clara do problema a ser resolvido.
Jones e Fleming (2013) fizeram um estudo qualitativo de 7 pares (14
estudantes), durante tarefas de depuração de código, enfatizaram questões como
ensinamento do parceiro, contribuições do parceiro que não está na posse do
teclado e o impacto das interrupções do parceiro. Observa-se nos resultados que
todos os pares apresentaram episódios de ensinamento do parceiro, a maioria sobre
programação, os parceiros que não estavam na posse do teclado, contribuíram com
várias ideias que foram implementadas pelo par de posse do teclado sem discussão,
não foi apresentado nenhum indício que as interrupções do parceiro foram
prejudiciais ao fluxo do trabalho.
Plonka, Sharp, van der Linden e Dittrich (2014) observaram a programação
em pares como estratégia para transferência de conhecimento entre programadores
seniores e novatos, este é um dentre vários métodos de ensino usados na
aprendizagem cognitiva. O desenvolvedor sênior verbalizar seu ensinamento e o
novato ser apoiado pelo sênior quando ele está desenvolvendo uma tarefa são
métodos de ensino usados na aprendizagem cognitiva e foram observados na
pesquisa. Reflexão (comparar sua solução com a de outros) e a exploração (tarefas
para o novato avançar no aprendizado) também são métodos de ensino usados na
aprendizagem cognitiva e não foram observados, pois, as necessidades da empresa
de produzir código são priorizadas em detrimento ao aprendizado, bem como, a
verbalização do novato durante o aprendizado não é estimulada nas empresas
pesquisadas, porém, melhoraria o processo de aprendizado do novato. Embora os
seniores façam um esforço adicional para transferir conhecimento ao novato, ao
aumentar a consciência sobre práticas de transferência de conhecimento, gera
oportunidade de aprendizado para o sênior.
22
Relação com projeto de interface humano computador
Seyamn e Mccrickard (2015) pesquisaram com estudantes de ciências da
computação, a programação em pares e requisitos de interface humano computador
e recomendam para os estudantes iniciantes em programação em pares que as
duplas não sejam formadas aleatoriamente, é melhor os estudantes escolherem
seus pares ou o par ser formado com base em suas notas na aula de programação.
Os estudantes devem ser encorajados a gastar um tempo no projeto e como será
feito o trabalho. Introduzir a qualidade como um requisito básico, ao invés de como
bônus. Enfatizar a regra de falar e ouvir. É melhor avaliar por meio de um desafio de
programação. Os estudantes devem ser explicitamente questionados acerca dos
contextos e cenários dos usuários. Eles afirmam que a programação em pares
contribui para uma maior interação entre os desenvolvedores, o que permite
alcançar um melhor projeto de interface humano computador e melhor experiência
para o usuário ao usar o software por eles desenvolvido.
A seguir, o Quadro 2 sintetiza os pontos fortes e fracos da programação em
pares observados pelos trabalhos de seus respectivos autores em ordem
cronológica. Os trabalhos representam os principais autores referenciados para
viabilizar um estudo terciário como forma de embasar uma nova técnica que
combine os pontos fortes e evite os pontos fracos.
Quadro 2 – Pontos fortes e fracos relacionados à programação em pares
AUTOR(ES)
ANO
PONTOS FORTES
PONTOS FRACOS
WEINBERG
1971
Programação sem ego.
BROOKS
1975
Entre 1953 e 1956, Brooks e seu par
escreveram 1500 linhas de código,
que executaram sem nenhum erro
na primeira tentativa.
É apenas um relato
realizado com apenas
dois programadores
iniciantes.
CONSTANTINE
1995
Redução do número de defeitos.
COPLIEN;
SCHMIDT
1995
Publicação de um padrão chamado
desenvolvimento em pares.
Pessoas às vezes sentem que
apenas podem resolver um
problema se tiverem ajuda. Alguns
problemas são maiores do que
qualquer indivíduo.
Continua na próxima página
23
AUTOR(ES)
ANO
PONTOS FORTES
PONTOS FRACOS
NOSEK
1998
Melhora a qualidade do código e
algoritmo.
Aumenta o esforço no
desenvolvimento, pois
aumenta o número de
horas de trabalho ao
somar-se as horas de
trabalho do par.
BECK
1999
Melhora a qualidade do produto de
software.
COCKBURN;
WILLIAMS.
2000
Comunicação e colaboração
constantes geram confiança
WILLIAMS;
KESSLER;
CUNNINGHAM;
JEFFRIES
2000
Aumento da satisfação e confiança
entre os programadores. Redução
do número de erros e retrabalho. É
um processo barato de revisão
informal; melhora a qualidade do
código desenvolvido e nível técnico
da equipe.
O número de erros evitados pela
inspeção informal realizada pela
programação em pares é tal que,
menos tempo é gasto na reparação
de bugs descobertos durante o
processo de testes.
Trabalho realizado com
programadores
iniciantes
WILLIAMS;
KESSLER
2000
Disseminação do conhecimento e
compartilhamento de técnicas e
competências entre os membros da
equipe.
COCKBURN;
WILLIAMS
2001
A produtividade, ao usar a
programação em pares, parece ser
comparável à de duas pessoas
trabalhando de forma independente.
As razões sugeridas são que
programando em pares discutem o
sistema antes de desenvolvê-lo,
então provavelmente ocorrerá
menos erros e retrabalho. Estimula a
refatoração.
Trabalho realizado com
programadores
iniciantes
Continua na
próxima página
24
AUTOR(ES)
ANO
PONTOS FORTES
PONTOS FRACOS
SMITH;
MENZIES
2002
É vantajoso para NASA em projetos
relativamente pequenos; quando
existe uma abundância de
desenvolvedores e se for necessário
um período de desenvolvimento
curto.
Perda de produtividade
em projetos
médios/grandes e sem
abundancia de
desenvolvedores
WILLIAMS;
KESSLER
2003
A inclusão de um novo membro na
equipe que não conhece o sistema
cria o problema do primeiro contato
com o código. A programação em
pares contribui para resolução deste
problema, pois o novo membro da
equipe pode trabalhar em par com
alguém mais experiente.
Engenheiros de
software parecem ficar
mais comprometidos na
posse do teclado.
Revezar a posse do
teclado, pode ajudar a
preservar o
comprometimento de
ambos
desenvolvedores.
PADBERG,
MÜLLER
2003
Quando a pressão do mercado é
forte, acrescentar desenvolvedores e
formar mais pares, pode acelerar o
projeto e aumentar o seu valor para
o negócio, apesar de aumentar
também o custo.
Aumento do custo no
desenvolvimento de
software.
PADBERG,
MÜLLER
2004
Estimula a motivação e satisfação
dos programadores.
BECK;
ANDRES
2004
Disseminação do conhecimento,
resolução do problema de um único
desenvolvedor deter o conhecimento
sobre uma parte do sistema e
elevação do nível técnico da equipe.
PARRISH;
SMITH;
HALE, D;
HALE, J
2004
Há alguns benefícios de qualidade,
mas estes não compensam
totalmente a perda da produtividade.
No entanto, a partilha de
conhecimento que acontece durante
a programação em pares é muito
importante, pois reduz os riscos
globais para um projeto no caso de
algum membro da equipe sair e isso
pode justificar o seu uso.
Significativa perda de
produtividade em
comparação à
programadores
trabalhando sozinhos
quando os
programadores do par
são experientes.
Continua na
próxima página
25
AUTOR(ES)
ANO
PONTOS FORTES
PONTOS FRACOS
SLATEN;
WILLIAMS;
BERENSON.
2004
Promove a confiança entre os
programadores.
COPLIEN;
HARRISON
2005
Projetos compatíveis com o
emparelhamento de trabalhar em
conjunto; desta forma podem
produzir mais do que a soma dos
dois individualmente.
HULKKO;
ABRAHAMSSON
2005
Observaram em quatro estudos de
caso a eficácia da programação em
pares na disseminação de
conhecimento e que ela é mais útil
em tarefas complexas.
Quando a complexidade
da tarefa for baixa é
menos indicado o uso
da programação em
pares.
MCDOWELL;
WERNER;
BULLOCK;
FERNALD
2006
Ela melhora a qualidade do código,
aumenta a confiança e satisfação
dos programadores(aumentou em
24% para mulheres e 15% para
homens) e diminui a evasão de
estudantes dos cursos de
computação.
Pesquisa realizada com
554 estudantes da
universidade Santa Cruz
na California-USA
VANHANEN;
LASSENIUS;
MÄNTYLÄ
2007
A programação em pares é mais útil
para projetar o software e tarefas
complexas de programação
VANHANEN;
KORPI
2007
É importante o par revezar a posse
do teclado para manter ambos
programadores comprometidos.
CHONG;
HURLBUTT
2007
Os engenheiros de software
parecem mais comprometidos na
posse do teclado. Para promover o
comprometimento de ambos, é
sugerido o uso de dois teclados e
dois mouses.
Quando o par tem nível
diferente de experiência,
o programador mais
experiente tende a
dominar a posse do
teclado.
FREUDENBERGR
OMERO; BOULAY
2007
Os engenheiros de software
parecem mais comprometidos na
posse do teclado. Para promover o
comprometimento de ambos, é
sugerido o uso de dois teclados e
dois mouses.
Continua na
próxima página
26
AUTOR(ES)
ANO
PONTOS FORTES
PONTOS FRACOS
ARISHOLM;
GALLIS;
DYBA;
SJOBERG
2007
Há alguns benefícios de qualidade,
mas estes não compensam
totalmente a perda da produtividade.
Perda de produtividade
e não é vantajosa para
programadores
experientes e nem para
programadores plenos
quando a tarefa possa
ser considerada
simples.
DYBA;
ARISHOLM;
SJOBERG;
HANNAY;
SHULL
2007
Melhora da qualidade e redução do
número de defeitos,
Perda de produtividade
e não é vantajosa para
programadores
experientes e nem para
programadores plenos
quando a tarefa possa
ser considerada
simples.
HÖFER
2008
Os engenheiros de software
parecem mais comprometidos na
posse do teclado.
Para promover o comprometimento
de ambos, é sugerido o uso de dois
teclados e dois mouses.
BEGEL;
NAGAPPAN
2008
Estimula a disseminação do
conhecimento, reduz a quantidade
de defeitos e gera software com
mais qualidade.
SISON
2009
Melhora a qualidade (foi medida
através da densidade de defeitos) ao
usar a programação em pares e
quando o projeto é suficientemente
grande ou complexo para permitir a
colaboração entre os
programadores, a perda de
produtividade é reduzida.
HANNAY;
ARISHOLM;
ENGVIK;
SJOBERG
2010
Não é encontrado indícios fortes que
a personalidade afeta o
desempenho ou benefícios da
programação em pares de uma
forma consistente, especialmente
quando incluindo indicadores
relativos à perícia, a complexidade
da tarefa, e do país.
Desperta-se atenção
para os fatores que
podem ser relevantes e
estão sob investigação
em curso, tais como a
aprendizagem em
equipe, motivação da
equipe, e habilidade de
programação.
Continua na
próxima página
27
AUTOR(ES)
ANO
PONTOS FORTES
PONTOS FRACOS
BANDUKDA;
NASIR
2010
A programação em pares é uma
prática que pode ser implementada
de forma distribuída.
A programação em pares distribuída
pode ser usada para aumentar a
produtividade do desenvolvimento e
a qualidade do produto.
WRAY
2010
Quatro mecanismos para melhorar o
desempenho da programação em
pares: conversar, avisar mais
detalhes, lutar contra práticas ruins
de programação e compartilhar e
reconhecer competências.
Wray sugere refazer a
pesquisa de Dyba et al.
(2007) considerando
seus quatro
mecanismos e pensar
em novos critérios e
método para mensurar
eficientemente o
desempenho, levando
em consideração estes
mecanismos.
SILLITTI;
SUCCI,
VLASENKO
2012
Mudança relevante de hábitos de
trabalho e os desenvolvedores
tendem a concentrar-se mais em
atividades produtivas.
PLONKA; VAN
DER LINDEN
2012
Requer ajustes na
cultura e estilo de
gestão da organização.
PLONKA; SHARP;
VAN DER LINDEN
2012
Dentre os pares, quem não estava
na posse do teclado, muitas vezes
tinham razão para separar-se,
dependendo da atividade de quem
esta na posse do teclado, devido as
interrupções ou porque eles
dividiram trabalho a ser feito em
paralelo. É observado que essa
separação não é necessariamente
um problema.
CHOI
2013
Pares do mesmo
gênero, homem-homem
e mulher-mulher,
apresentaram maior
nível de comunicação e
compatibilidade. Pares
do mesmo gênero, pode
ser uma diretriz, na hora
de fazer a seleção dos
pares.
Continua na
próxima página
28
AUTOR(ES)
ANO
PONTOS FORTES
PONTOS FRACOS
JONES;
FLEMING
2013
Observa-se nos resultados que
todos os pares apresentaram
episódios de ensinamento do
parceiro, a maioria sobre
programação, os parceiros que não
estavam na posse do teclado,
contribuíram com várias ideias que
foram implementadas pelo par de
posse do teclado sem discussão,
não foi apresentado nenhum indício
que as interrupções do parceiro
foram prejudiciais ao fluxo do
trabalho.
Trabalho realizado com
apenas 14
programadores
iniciantes/estudantes
PLONKA;
SHARP;
VAN der LINDEN;
DITTRICH
2014
O desenvolvedor sênior verbalizar
seu ensinamento e o novato ser
apoiado pelo sênior quando ele está
desenvolvendo uma tarefa são
métodos de ensino usados na
aprendizagem cognitiva e foram
observados na pesquisa com
sucesso.
Reflexão (comparar sua
solução com a de
outros) e a exploração
(tarefas para o novato
avançar no
aprendizado) também
são métodos de ensino
usados na
aprendizagem cognitiva
e não foram observados
SWAMIDURAI;
UMPHRESS
2014
Aumento da produtividade quando
há rotação dos pares na equipe
Programação em pares
estática é menos
produtiva que a
dinâmica
SWAMIDURAI;
UMPHRESS
2015
Dois estudos empíricos foram
realizados na primavera de 2009 e
no verão de 2012 para validar a
programação em par invertida contra
par programação tradicional. Os
resultados deste experimento ponto
a favor da metodologia de
programação par invertida e não
suportam a alegação de que a
programação em pares, em geral
reduz a duração de desenvolvimento
de software ou custo total de
desenvolvimento de software.
Programação em pares
é menos produtiva que a
Programação em pares
invertida
Continua na
próxima página
29
AUTOR(ES)
ANO
PONTOS FORTES
PONTOS FRACOS
ESTÁCIO;
PRIKLADNICKI
2015
Há a necessidade de
mais estudos na
indústria de software
sobre a programação
em pares distribuída.
Há a necessidade de
explorar mais diretrizes
(guidelines) para
implementação da
programação em pares
distribuída na industria
de software.
DU; OZEKI;
NOMIYA;
MURATA; ARAKI
2015
Eficaz para melhorar a comunicação
em um exercício básico de C
SEYAM;
MCCRICKARD
2015
Contribui para uma maior interação
entre os desenvolvedores, o que
permite alcançar um melhor projeto
de interface humano computador e
melhor experiência para o usuário
ao usar o software por eles
desenvolvido.
Fonte: Elaborado pelo autor
2.1.1 Resumo dos pontos fortes e fracos
A revisão da literatura relacionada à programação em pares ilustrada no
Quadro 2, evidencia a diminuição do número de defeitos, a disseminação do
conhecimento, o aumento da qualidade do produto de software, existe um problema
de produtividade associado à técnica, apenas alguns trabalhos levaram em conta a
complexidade da tarefa e a experiência do programador e, observaram que a técnica
funciona melhor para programadores novatos e tarefas complexas.
Para promover o comprometimento, é sugerido o uso de dois teclados e dois
mouses. Para melhorar o desempenho é sugerido os mecanismos: conversar, avisar
mais detalhes, lutar contra práticas ruins de programação e compartilhar e
reconhecer competências.
Observa-se no Quadro 2, o aumento da produtividade quando há rotação dos
pares na equipe. Observa-se também, o aumento da produtividade quando a
programação em pares é invertida, onde o par não trabalha lado a lado em todas as
fases de desenvolvimento de software; em vez disso, a dupla começa projetando
juntos, se separaram durante a implementação, em seguida, juntam-se novamente
para o teste.
30
2.2 Programação em Grupo (Mob Programming)
A ideia de programar em grupo originou-se de reuniões de almoço de
desenvolvedores, originalmente executado em um formato de apresentação, onde
um membro da equipe apresentava um código que conhecia. Esperava-se
proporcionar maior oportunidade para os desenvolvedores trabalharem juntos,
permitindo a troca de informações sobre técnicas de programação, encorajar
mudanças, feedbacks, disseminar conhecimento da arquitetura de software do
projeto, fortalecer o senso de equipe. (HOHMAN E SLOCUM, 2001)
Programação em grupo é uma técnica onde toda a equipe participa em torno
de uma estação de trabalho com uma única pessoa na posse do teclado, mouse e
computador. É programação em par com mais de duas pessoas. (ZUILL, 2012)
Hohman e Slocum (2001) definem o mob programming (programação em
grupo) como sendo a refatoração de um trecho de código em grupos maiores do que
duas pessoas. Conduziram um experimento em seu time de desenvolvimento,
composto por cerca de dez profissionais, para averiguar se os benefícios da
programação em pares são preservados ao programar em grupo de mais de duas
pessoas em um único computador. No experimento deles praticou-se a programação
em grupo oito vezes, relatou-se dificuldade para seguir a própria diretriz. Por
exemplo, uma boa preparação, tem um efeito forte sobre a qualidade de uma
apresentação. No entanto, apenas uma minoria dos casos esta preparação foi
realizada adequadamente. Isso é apontado como uma fraqueza, a partir do ponto de
vista do método XP. Neste experimento são testados dois formatos de mob
programming, um formato com toda a equipe num mesmo grupo e apenas um
projetor e outro onde a equipe é dividida em dois grupos, e cada grupo menor usa
seu próprio projetor. Um projetor é um pouco mais fácil de gerir logisticamente. No
entanto, porque o grupo é composto por cerca de dez desenvolvedores, tendo
apenas um ponto de foco é difícil incluir todos no processo. Com dois projetores, é
possível experimentar vários diferentes formatos, em geral, mais envolvente. Por
exemplo, ao se dividir em duas equipes, uma possibilidade é cada uma fazer a sua
própria refatoração de código e comparar/discutir com a feita pela outra equipe, este
formato é observado o mais bem sucedido. Outro formato é enquanto uma equipe
refatora, a outra equipe trabalha nos testes, este formato sofre do problema de que
para refatorar, é necessário os testes prontos e uma vez que os testes estejam
prontos, muitas vezes é necessário esperar para que a refatoração termine, pois
31
guia a escrita dos testes. Uma equipe acaba esperando a outra. Em ambas
possibilidades, com dois projetores, os pontos de foco envolvem mais pessoas, há
compartilhamento dos papéis, envolvendo mais amplamente os membros do grupo.
É observado no experimento de Hohman e Slocum (2001) que as pessoas
acham difícil manter o foco, especialmente aqueles que não estão na posse do
teclado. Mais de dois programadores evidenciaram a propensão para a dispersão da
atenção, terem outras conversas não relacionadas, a menos que todos na sala
estejam envolvidos na prática, senão, o grupo inevitavelmente torna-se incontrolável.
São feitas críticas mistas, os inegáveis benefícios são indiretos, como: a melhora da
comunicação e cobertura dos testes. É sugerido duas melhorias: completar a
preparação necessária e estabelecer um treinador para supervisionar indiretamente
o trabalho. A equipe sugere alternar a programação em grupo com outros formatos.
Na empresa onde Wilson (2015) trabalha, estão constantemente tentando
melhorar as práticas do eXtreme Programming. No segundo semestre de 2014,
mudaram da Programação em Par em todo o código de programação produzido
para Mob Programming com toda a equipe, influenciados pela apresentação de Zuill
(2014), assemelhava-se ao estilo Randori de Coding Dojos (ROOKSBY et al., 2014),
que já usam durante as sessões de codificação para aprender novas tecnologias. A
equipe declarou que todas as sextas-feiras seriam em grupo (Mob Fridays). Colocam
um quadro branco como uma divisória, isolando a equipe do resto do pessoal da
empresa, na tentativa de aumentar o envolvimento da equipe. Colocar toda equipe
na frente de um monitor é um problema para eles, pois a área de desenvolvimento é
aberta. A solução, conforme mostra a Foto 1, foi colocar os monitores grandes que
eles já usam para programar em par em conjunto com um monitor de 50 polegadas
espelhado no monitor grande da estação de trabalho, na intenção, de quem estiver
na posse do teclado possa ter a visão além do seu monitor, da equipe inteira.
Foto 1 – Programando em grupo de 4 pessoas
Fonte: Wilson (2015)
Legenda: Ao fundo está o programador que está na posse do computador
32
A equipe que Wilson (2015) faz parte, relata uma maior produtividade com
dois monitores, ao invés, de ter apenas um e todos olharem para o mesmo monitor e
apenas passar o teclado entre os desenvolvedores.
O uso de dois monitores facilita a conversa entre quem esta na posse do
teclado e os observadores. Aumentou a confiança usando a programação em grupo
em comparação a programação em pares que era adotada antes, observaram que
fortaleceu a equipe e o aprendizado em conjunto.
É adotada a rotação da posse do teclado a cada 5 minutos, o que significa
num grupo de 4-6 pessoas um intervalo de 15-25 para pilotar novamente o teclado.
É observada a importância de um rápido e atualizado conjunto de testes
automatizados. É pretendido dar sequência na adoção do mob programming para
averiguar realmente se é verídica a alegação de aumento da produtividade devido a
melhora do throughput gerado a partir do One Piece Flow, elemento fundamental da
abordagem Lean, onde é processada uma unidade de ordem do cliente por vez,
deve-se processar somente o que o cliente quer, na quantidade e quando ele quiser.
(KAIZENWORLD, 2015)
É relatado por Wilson (2015) a preocupação dos membros não
desenvolvedores, dentre eles o gerente de produto, acerca da dificuldade de
convencer a empresa que colocar toda equipe trabalhando junta numa história é
mais produtivo e eficaz do que ter pares trabalhando em histórias diferentes.
A equipe tomou a decisão que se o time inteiro necessitasse ser interrompido,
se daria após a completa rotação do time. São observados dois problemas, que
limitam a eficácia do mob programming: o efeito de personalidades dominantes
dentro do grupo e o aparecimento do Groupthink, um bem documentado efeito
psicológico, no qual segundo Janis (1982), a tendência para desenhar uma
percepção enviesada da situação, devido ao excesso de confiança do grupo, tanto
em suas habilidades técnicas e quão bem perceberão os eventos futuros. Juntos
este dois problemas tornam a programação em grupo menos útil que a programação
em pares.
A disseminação do conhecimento operacional foi estimulada e foi observado
que funcionou bem para os códigos críticos e complexos. (WILSON, 2015)
Devido aos problemas de Groupthink e personalidades dominantes em sua
equipe, decidiram não usar sempre mob programming, porém, é uma técnica útil em
33
situações particulares e para resolver problemas específicos, mais uma das muitas
ferramentas para a equipe. (WILSON, 2015)
Conforme observado por Wilson e Weber (2015) a programação em grupo
certamente não resolve os problemas de um código mal escrito ou processo de
desenvolvimento de software ruim. Pode inclusive amplificar disfunções da equipe,
bem como os pontos fortes.
Eles relatam que a programação em grupo ajudou sua equipe na resolução
dos problemas mais complexos e críticos, também ajudou a envolver colegas de
outras áreas, além do desenvolvimento de software nas sessões de programação
em grupo, incluindo especialistas em produtos, infraestrutura e experiência do
usuário. (WILSON E WEBER, 2015)
Segundo Zuill (2015) a equipe decidiu usar o Mob Programming e software de
alto valor é entregue há mais de três anos. É uma abordagem para equipe inteira
fazer todo o trabalho em conjunto, incluindo programação, projeto, testes, e trabalho
com o cliente (sócios, product owner, usuário, etc). Expande-se a natureza de todo
trabalho feito pela equipe, além do planejamento, retrospectivas, e um standup diário
ou outra reunião. Este é um passo evolutivo para a programação em pares,
comunicação presencial, o alinhamento da equipe, colaboração e conceitos de
equipe auto-organizável da abordagem ágil de desenvolvimento de software.
2.2.1 Pontos fortes e fracos
Em relação aos pontos fracos, Hohman e Slocum (2001) relatam que é difícil
manter o foco, especialmente para aqueles que não estão na posse do teclado.
Wilson (2015) cita dois problemas, o efeito de personalidades dominantes dentro do
grupo e aparecimento do Groupthink.
Dentre os pontos fortes, Zuill (2015) destaca que fortalece a comunicação
presencial; alinhamento da equipe; colaboração e conceitos de equipe auto-
organizável. Wilson e Weber (2015) observam que a disseminação do conhecimento
operacional foi estimulada e a técnica funcionou bem para os códigos críticos e
complexos.
Há dois pontos de convergência na conclusão de Hohman e Slocum (2001);
Wilson (2015); Wilson e Weber (2015), ao usar dois projetores ou monitores a
técnica funciona melhor e é vantajoso alternar o uso da programação em grupo com
outras técnicas.
34
2.3 Revisão de Código (Code Review)
A questão da revisão da literatura da revisão de código em pares é: Quais são
os pontos fortes e fracos observados e/ou constatados nos últimos dois anos sobre
revisão de código moderna em pares? As palavras chaves utilizadas para pesquisa
dos artigos abrangem: code review, modern code review, pair review, pair code
review e modern pair review.
Segundo Carver et al. (2015) os dois pontos principais de engenharia de
software para este ano são: o primeiro é a colaboração entre indústrias de software
e universidades; o segundo é a revisão de código moderna, que é uma versão
reduzida das tradicionais inspeções de código e observa-se o aumento do número
de pesquisas sobre revisão de código moderna, devido a sua importância para a
indústria de software.
Morales el al. (2015) examinaram o impacto de práticas modernas de revisão
de código na qualidade do projeto (design) e com base na evidência empírica
coletada em três grandes projetos open sources (Qt, VTK e ITK) concluíram que
contribui para melhora da qualidade do projeto de software.
A análise baseada nos dados de 25 mil desenvolvedores da Microsoft, propicia
uma observação interessante, o principal objetivo de uma revisão de código costuma
ser identificar defeitos, porém, apenas 15% dos comentários dos revisores é sobre
defeitos. Melhorar a manutenibilidade do código é um comentário presente em mais
de 50% do total de comentários dos revisores. (CZERWONKA et al., 2015)
Outra observação interessante é o número máximo ideal de 20 arquivos por
revisão, a partir deste ponto de saturação a qualidade dos comentários feitos pelo
revisor, diminui. (CZERWONKA et al., 2015)
Os resultados na Microsoft mostram que os desenvolvedores precisam de 6
meses a 1 ano de experiência com o código fonte para se tornarem revisores
eficientes. Ainda não há, uma completa compreensão sobre o workflow ideal e
atualmente não são tão eficazes e não se pode negligenciar aspectos sociais da
revisão de código. (CZERWONKA et al., 2015)
Swamidurai, Dennis e Kannan (2014) comparam duas técnicas de revisão de
código colaborativas, a programação em pares tradicional e a revisão de código em
pares, que melhoram a qualidade de programas, são alternativas as inspeções
formais e rigorosas que costumam remover 90% dos defeitos antes de ser
35
executado o primeiro caso de teste. O conceito tradicional de programação em pares
tem o requisito do par estar sentado lado a lado, o que é um obstáculo em muitos
projetos de desenvolvimento. Revisões de código em pares, no entanto, têm se
mostrado tão eficazes quanto programação em pares e são um ajuste melhor para
muitos softwares que estão sendo desenvolvidos colaborativamente de forma
assíncrona e na nuvem. Realizaram um experimento utilizando a técnica de revisão
de código em pares, em comparação com a técnica de programação em pares
tradicional no contexto em que é adotado o Test Driven Development. O resultado
mostra que programas com qualidade equivalente podem ser produzidos com um
custo 28% menor em relação à programação em pares.
Zhang et al. (2015) propõe a revisão de código interativa para mudanças
sistemáticas, que são mudanças similares relatadas para vários contextos, este
recurso de exibir as mudanças é muito útil para o revisor do código, porém, as
vezes, os revisores deparam-se com questões como: em quais outros ponto do
código há alterações similares?
Mesmo as ferramentas populares específicas para revisão de código como:
Phabricator (2015), Gerrit (2015), Collaborator (2015) e Codeflow (2015), computam
mudanças, por arquivo, o que obriga a leitura de linhas de alterações por arquivo,
então para resolver este problema é criado o Critics (2015), uma abordagem
interativa para revisão de código para mudanças sistemáticas, consiste em um plug-
in para Eclipse para detecção de mudanças sistemáticas de forma automática,
similar ao Eclipse/Git/SVN Diff ou show differences da Microsoft®.
Primeiro escolhe a região da mudança, depois permitem ao desenvolvedor
customizar o conteúdo do template da mudança e executam o plug-in com base no
template para detectar possíveis anomalias no código. Os resultados de Zhang et al.
(2015) indicam que o Critics (2015) melhora a acurácia e produtividade das
mudanças sistemáticas durante o processo de revisão de código.
2.3.1 Pontos fortes e fracos
Revisão de código moderna em pares é observada como um ajuste melhor ao
desenvolvimento colaborativo assíncrono e na nuvem e contribui para a melhora da
qualidade do projeto (design) de software. Ainda não há, uma completa
compreensão sobre o seu workflow ideal e atualmente não são tão eficazes e não se
pode negligenciar os aspectos sociais da revisão de código.
36
2.4 Engenharia Simultânea (Concurrent Engineering)
A Engenharia Simultânea ou Concorrente, é uma maneira de abordar o
desenvolvimento de produtos, desde a revolução industrial foi crescente a
necessidade de uma maneira de se pensar em como desenvolver novos produtos ou
melhorar os processos para que se produza mais. Até a primeira metade do século
XX os projetos de desenvolvimento de produtos abrangiam menos áreas, menos
interesses e ,dessa maneira, podemos dizer que os projetos era menos complexos.
Com o progresso científico e tecnológico os projetos foram se tornando cada vez
mais complexos e se tornando cada vez mais interdisciplinares,consequentemente,
aumentando o número de pessoas envolvidas em sua concepção. Inicialmente
produtos eram desenvolvidos de uma maneira sequencial. Com o aumento de sua
complexidade e da competição entre as organizações produtoras, houve a
necessidade de encurtar o tempo de desenvolvimento e grupos multidisciplinares
passaram a ser utilizados para realizar o desenvolvimento do produto e dos seus
processos do ciclo de vida, simultaneamente. Essa abordagem foi chamada de
engenharia simultânea. (Pires e Loureiro, 2010)
O principal objetivo é aumentar a competitividade dos produtos aumentando a
sua qualidade e ao mesmo tempo reduzindo os custos e o tempo do projeto. É
fundamental para isso, o trabalho em equipe (Deboni et al., 1994).
O trabalho colaborativo, as equipes multidisciplinares e o apoio de softwares
para orquestrarem o trabalho simultâneo são fundamentais para a competitividade.
(Deboni et al., 1995)
Segundo Bennett et al. (1995) o principal objetivo da Engenharia Simultânea é
a diminuição do tempo desde o pedido até a entrega, para um novo produto, com
custo mais baixo e maior qualidade. Isto é alcançado pelo desenvolvimento paralelo,
ao invés de sequencial, das diferentes etapas que compõem o projeto do produto,
com o emprego de times ou equipes multidisciplinares. Engenharia Simultânea usa
tecnologia para atingir seus objetivos.
Hauptman e Hirji (1996) colocam que dentre os princípios da Engenharia
Simultânea estão objetivos comuns, completa visibilidade dos parâmetros de projeto,
consideração mútua de todas as decisões, colaboração para resolver conflitos,
equipes de trabalho, melhoria contínua. O desenvolvimento de novos produtos é
uma sequência de ligações entre as necessidades de se conhecer o mercado e as
oportunidades tecnológicas que são traduzidas em informações para a produção.
37
Quanto ao tipo de produto mais adequado a Engenharia Simultânea, observa-
se que os inovadores, apresentam maior redução no custo de criação em relação à
outros tipos de produtos ao usar a Engenharia Simultânea (VALLE et al., 2009).
Quanto às ferramentas usadas, Evans (1991) demonstra que há três grandes
categorias de ferramentas para a Engenharia Simultânea: as ferramentas de base
tecnológica, as técnicas e a ferramenta essencial que é o trabalho em equipe. Após
a apresentação dos pontos fortes e fracos associados à Engenharia Simultânea são
apresentadas as ferramentas que tenham relação direta com a produtividade.
2.4.1 Pontos fortes
O desenvolvimento de um sistema para satélite espacial é dividido em
subsistemas e a engenharia simultânea é uma abordagem eficiente neste caso,
devido ao fato do projeto dos subsistemas ser simultâneo a iteração para elaboração
do design destes subsistemas é mais rápida devido ao paralelismo, pois iniciam em
paralelo, ao invés, de esperar o término do outro subsistema. (STEVENS, 2015)
Segundo Prassad (1996), ao implantar a Engenharia Simultânea, há uma
significativa melhora da qualidade e redução no tempo de desenvolvimento,
mudanças de projeto, refugos, retrabalho, defeitos, tempo de introdução do produto
e frequência de falha de campo.
A Tabela 1 mostra, em percentuais, os ganhos obtidos pelas empresas com a
aplicação da Engenharia Simultânea ao invés da sequencial.
Tabela 1 – Percentuais obtidos com a implantação da Engenharia Simultânea.
tempo de desenvolvimento
30 – 50% menor
mudanças de engenharia
60 – 95% menor
refugos e retrabalhos
75% de redução
defeitos
30 – 85% menor
tempo de introdução do produto
20 – 90% menor
frequência de falha de campo
60% menor
qualidade em geral
100 – 600% maior
Fonte: Mills; Bechert; Carrabine (1991); Hartley (1992); Prasad (1996)
O aumento da produtividade é um ponto forte da Engenharia Simultânea
segundo Mills, Bechert e Carrabine (1991); Carter e Baker (1991); Hartley (1992);
Prasad (1996); Pires e Loureiro (2010).
É observado melhora na curva de aprendizado dos estudantes no curso de
programação robótica com a adoção da engenharia simultânea. A hipótese é que o
aprendizado iterativo por meio da adoção da engenharia simultânea no curso é mais
eficaz na construção de conhecimento, facilita a aprendizagem. (SHIN et al., 2015)
38
2.4.2 Pontos fracos
As restrições quanto a Engenharia Simultânea, apontadas por Rosenblatt e
Watson (1991), Haddad (1996) e Sprague et al. (1991) são: a cultura organizacional
é a tradicional separação entre as várias funções dentro da organização, que
normalmente inviabiliza mudanças dessa natureza com as inconstâncias de
propósitos. A Engenharia Simultânea age integrando as várias funções dentro de
uma cultura de equipes. A falta de comunicação, que pode ser devido à distância
física entre os engenheiros de desenvolvimento e os engenheiros de produção, ou à
falta de experiência, principalmente dos engenheiros de desenvolvimento nas
atuações da produção, ou à falta de infraestrutura. O uso intensivo de equipes e de
ferramentas de interação entre projeto e processo podem amenizar este problema.
Em relação a centralização de poder, há sempre o receio da perda de poder do
primeiro escalão e com isso ocorre a dúvida entre aquilo que deve realmente ser
feito e aquilo que os superiores instruem para ser feito. Influências externas dos
clientes e fornecedores, que podem alterar consideravelmente o caminhar do
projeto, principalmente se mal gerenciados. A necessidade de software que apoie
consistentemente a colaboração e trabalho em equipe para resistência humana
devido a não compreensão dos benefícios e riscos. (DEBONI et al., 1995)
Autores como Albin e Crefelt (1994); Carter e Baker (1991); Lu (1990); Pawar
e Sharifi (2000); Weston (1996); Winner et al. (1988); Yan (1999); Castka e Bamber
et al. (2001) apontam as principais falhas da Engenharia Simultânea que são: a falta
de empenho para os problemas que surgem em função do compartilhamento dos
recursos e a sua implementação necessita de importantes reformas na atual
estrutura e cultura organizacional da empresa.
Muitos autores afirmam que a adoção de uma cultura para desenvolvimento
de software aderente aos métodos ágeis requer que o grupo aceite mudanças
significativas em seu processo de desenvolvimento e que isso muitas vezes exige
uma mudança significativa na cultura organizacional (MCAVOY e BUTLER, 2007).
A mudança de valores que a cultura organizacional inerente aos métodos
ágeis representa na organização é um processo de aprendizagem (ROBINSON e
SHARP, 2003; FRASER et al., 2008). Os valores e princípios dos métodos ágeis,
intrínsecos à prática da programação em pares resolvem os problemas que surgem
devido ao compartilhamento de recursos. Uma oportunidade encontrada por este
trabalho para a fusão com a programação em pares, é o fato dela ser adequada a
39
pequenas e médias empresas. Os métodos ágeis, incluindo o eXtreme Programming
e a prática da programação em pares, reformam a cultura e a estrutura
organizacional da empresa para colaboração, resolvendo outra falha da Engenharia
Simultânea relatada por vários autores da necessidade de importantes reformas na
atual estrutura e cultura organizacional da empresa.
2.4.3 Equipes de trabalho
Para que ocorra o trabalho em equipe, é necessária a realização de
mudanças no relacionamento da empresa com os empregados e estes entre si
próprios. A mudança organizacional ajuda a melhorar o relacionamento e deve
ocorrer para que todos não se sintam inibidos. Os administradores devem estar
empenhados nestas mudanças e são eles que começam o processo de implantação
da Engenharia Simultânea (PITHON, 2004).
A diferença básica entre um grupo de trabalho tradicional e uma equipe de
trabalho da Engenharia Simultânea está na interdependência, ou seja, uma equipe é
formada por um grupo de pessoas com alto grau de interdependência entre os
componentes, direcionada para a realização de uma meta ou a conclusão de uma
tarefa. Uma equipe de trabalho pode ser definida como:
Um grupo de empregados que trabalham através de uma meta comum,
atuando uns sobre os outros para partilharem informações sobre os
melhores procedimentos ou práticas, e tomando decisões as quais
encorajem todos os membros da equipe a atuarem com todas as suas
potencialidades. (Katzenbach e Smith, 1993; Mussnug e Hughey, 1997).
A formação da equipe é imperativa para a existência da Engenharia
Simultânea. Uma equipe satisfeita resolve conflitos, compartilha experiências,
trabalha bem em conjunto, o stress é baixo e o nível de confiança é alto. Quanto à
eficiência dos objetivos projetados, normalmente atingem: o custo do produto
estabelecido inicialmente, o orçamento de investimentos previsto para o projeto, o
ciclo estabelecido e principalmente a qualidade (HAUPTMAN e HIRJI, 1996).
Desempenho é o ponto crucial para as equipes. Diversos fenômenos bastante
conhecidos explicam por que as equipes apresentam bom desempenho. Elas
conseguem reunir conhecimentos e experiências complementares que, por
definição, excedem as de qualquer indivíduo participante da equipe. Essa mescla de
conhecimento e habilidade capacita as equipes a reagir a desafios complexos, tais
como inovação, qualidade e serviço ao cliente. As equipes ao desenvolverem metas
e abordagens claras, elas estabelecem comunicações que dão suporte à solução de
problemas e à iniciativa em tempo real. As equipes são flexíveis em resposta a
40
variações ocorridas em eventos e em exigências. Consequentemente, as equipes
podem ajustar sua abordagem às novas informações e desafios com maior
velocidade, precisão e eficácia, do que fariam indivíduos surpreendidos em meio a
uma malha com maior quantidade de interligações organizacionais. Equipes
oferecem uma dimensão social única, que dá realce aos aspectos econômicos e
administrativos do trabalho. Equipes reais não se desenvolvem enquanto as
pessoas envolvidas não trabalharem duro para superar as barreiras que se
encontram no caminho em direção ao desempenho coletivo. A superação das
barreiras ao desempenho é a forma de os grupos se transformarem em equipes
(Katzenbach e Smith, 1993).
O trabalho em equipe é importante para a Engenharia Simultânea. O trabalho
em equipe não se constitui em uma tarefa fácil de ser implementada, pois há uma
grande quantidade de opiniões, informações, pessoas, etc., para serem
administradas. Entretanto, é necessário que todos os elementos sejam coordenados,
a fim de que os conflitos sejam diminuídos ou controlados e os canais de
comunicação tornem-se mais eficientes, etc. Para o sucesso desta coordenação
torna-se então imprescindível o trabalho colaborativo. (Galdámez, 2000)
2.4.4 Trabalho colaborativo
O trabalho cooperativo é aquele em que várias pessoas articulam, separadas
fisicamente ou não, a realização de uma tarefa comum. (PITHON, 2004)
Cooperar é, acima de tudo, um ato social e requer, portanto, todos os tipos de
interação humana, desde a fala, passando pela escrita e pelas expressões faciais.
Cooperar pode ser considerado, também, um acordo em que todos se
comprometem a trabalhar para atingir um objetivo comum (Borges, 1995).
A colaboração, a troca de informação, a capacidade de comunicação, o
respeito às diferenças individuais e o exercício da negociação são requisitos
importantes para o trabalho colaborativo. O papel da comunicação é fundamental,
podendo ser realizado de várias formas, através de encontros face a face ou por
meios eletrônicos. (PITHON, 2004)
Os benefícios do trabalho cooperativo podem ser medidos em termos dos
objetivos da organização, os quais podem frequentemente ser generalizados por
conseguir o aperfeiçoamento em curto espaço de tempo, ou melhorar a
produtividade ou a qualidade. Hawryszkiewycz (1997) relaciona alguns destes
benefícios: melhor uso do tempo disponível pelas pessoas através da redução da
41
soma do tempo gasto com a realização de tarefas rotineiras; melhor uso da
informação pelo melhor aproveitamento do acesso a ela e garantir que todos
compartilhem desse acesso; redução dos custos com viagens.
2.4.5 Groupware
O termo Groupware pode ser definido a partir da seguinte união de conceitos:
processos e procedimentos intencionais de um grupo para realizar propostas
específicas + ferramentas de softWARE projetadas para suportar e facilitar o
trabalho em grupo. Assim, o termo Groupware pode ser descrito como a
implementação do trabalho colaborativo em nível de software, com o objetivo de
facilitar a comunicação colaborativa e a coordenação das ações entre as diversas
pessoas a fim de promover a integração e a criatividade dentro da empresa. Esta
comunicação pode ser feita através de uma rede interna (Intranet) ou através da
Internet (CRUZ, 2000; HAWRYSZKIEWYCZ, 1997 e GOUVEIA, 2002).
Groupware, segundo a definição de Cruz (2000) é todo e qualquer sistema
computadorizado que permite que grupos de pessoas trabalhem de forma
cooperativa, a fim de atingir um objetivo comum, aumentando-lhes a produtividade.
O uso de Groupware deve estar respaldado pela alta direção, pois a cultura
organizacional da empresa deve estar preparada para realizar as tarefas de pensar,
aprender, escrever, projetar, criar, analisar, decidir, fazer brainstorms, dividir
informação, discutir e apresentar ideias, tudo isso colaborativamente. (PITHON,
2004)
Como causas para o surgimento da tecnologia Groupware, Cruz (2000)
aponta os fatores: Downsizing, Reengenharia e Programas de qualidade.
Downsizing, redução no tamanho das estruturas organizacionais, ocorrida no final da
década de 80, devido à necessidade de aumento da eficiência das empresas, para
que pudessem competir num mercado globalizado. Teve reflexos diretos na área de
computação. Com a substituição de mainframes por máquinas menores e com o
surgimento de duas novas tecnologias: as redes locais e o modelo servidor, também
conhecido como plataforma distribuída. Desde então, as tecnologias de rede não
deixaram de crescer e consolidar-se. Hardware e software, juntos, mais próximos
dos usuários, viabilizaram a ideia de trabalho produtivo em grupo. A plataforma
cliente-servidor foi um fator decisivo para o surgimento e difusão da tecnologia de
groupware. Reengenharia é um termo criado por Michael Hammer (1990) para
designar o desenvolvimento de novas formas para realizar o trabalho. Para Hammer
42
e Champy (1994) a preocupação original de Hammer estava em fazer a
reengenharia a qualquer custo, sem preocupar-se demasiadamente com a
introdução de novas tecnologias da informação. Posteriormente, o significado do
termo foi associado à reinvenção de processos, para aperfeiçoar o que vinha sendo
feito e, desta forma, reduzir perdas. A partir do surgimento da reengenharia passou a
ser incentivada a criatividade, o trabalho em grupo e o envolvimento de todos os
níveis da organização no processo decisório. Programas de qualidade: devido à
forte preocupação em organizar os processos de produção, a estrutura
organizacional de uma empresa está intimamente ligada ao trabalho em conjunto
dos membros do processo (funcionários). O Groupware é um dos responsáveis pela
manutenção das certificações obtidas para os processos, em cada auditoria
realizada.
O Groupware pode ser considerado um polivalente, pois engloba diversas
tecnologias baseadas no mesmo princípio: pessoas trabalhando juntas para que as
atividades sejam realizadas com sucesso em todas as partes do processo,
independente de quem as desenvolva. (CRUZ, 2000)
Resumindo, qualquer produto que permita trabalho cooperativo com ganho de
produtividade, num determinado processo, pode ser considerado membro da família
Groupware. (PITHON, 2004)
O desenvolvimento de métodos que levem em consideração aspectos
cognitivos e sociais no trabalho colaborativo passa a ser de grande importância, que
objetivem a melhoria dos Groupwares adequando-os às características humanas.
(MOECKEL e AZEVEDO, 2005)
2.4.6 Trabalho simultâneo
O paralelismo (simultaneidade) na execução das etapas de desenvolvimento
de produtos ocupa uma posição de destaque no contexto da Engenharia
Simultânea, uma vez que é fundamental na redução do ciclo de desenvolvimento de
produtos, reduzindo desta maneira o time-to-market (tempo transcorrido desde a
detecção da necessidade, até a introdução de um novo produto no mercado) o que
constitui uma importante vantagem competitiva. Para tal é vital que haja a integração
entre áreas de conhecimento, mediante a constituição de equipes multidisciplinares.
A redução dos tempos de lançamento e retrabalho após o lançamento; aumenta o
comprometimento dos membros da equipe com as decisões tomadas. (PIMENTEL e
AUGUSTO, 2003)
43
A integração das informações do produto permite que todos os membros da
equipe tenham acesso a informações atualizadas e comuns a todos, facilitando o
processo decisório e diminuindo os riscos de decisões baseadas em informações
desatualizadas. (PIMENTEL e AUGUSTO, 2003)
O paralelismo (simultaneidade) bem como a integração, entre as diversas
áreas envolvidas nas etapas de desenvolvimento são algumas das diferenças em
relação à engenharia sequencial.
A estratégia de simultaneidade, com o emprego de equipes multidisciplinares,
fornece uma oportunidade para tratar antecipadamente, no processo de
desenvolvimento, de fontes de conflitos entre agentes do desenvolvimento, que
representam os pontos de vista de diferentes áreas: projeto do produto,
planejamento da produção, fabricação.
Segundo Winner (2000 e 2002) o custo tende a ser reduzido sobremaneira,
principalmente devido à participação do pessoal de produção nas equipes
multidisciplinares, desde o início do desenvolvimento, de modo que participando no
desenvolvimento, contribuem para que quando da fabricação não seja detectada a
necessidade de correções no projeto (reprojetos), que ocasionam não só atrasos no
lançamento de produtos, que representam elevado custo em um mercado
competitivo, como também evitam os elevados custos que representam as
alterações de projeto, que aumentam drasticamente à medida que o projeto se
aproxima da etapa de produção, pois quanto mais próximo desta etapa, maior é a
quantidade de itens integrados, e consequentemente maior é a quantidade de
interfaces que necessitam de revisão em função de alterações a serem introduzidas.
A participação do cliente nas equipes multidisciplinares, desde o início, é importante
na medida em que permite um perfeito entendimento, por parte da equipe
multidisciplinar, dos requisitos que o produto deve satisfazer. Assim como o cliente
pode ser assessorado com relação a requisitos conflitantes, que possam trazer
como consequência degradação na operação do produto final. Deste modo, esse
entendimento provoca, desde o início, um desenvolvimento contínuo, sob uma
estrutura sólida (requisitos do produto), perfeitamente compreendida e edificada por
todos os membros da equipe multidisciplinar.
Na aplicação da Engenharia Simultânea é fundamental que as equipes
multidisciplinares de projeto trabalhem em todos os aspectos do desenvolvimento de
forma paralela e simultânea, em contraste com o processo tradicional, resultando
44
com isso na necessidade imperiosa de maior integração entre os dados do produto.
Tais informações devem estar localizadas em uma base de dados única, ao invés de
se encontrarem fragmentadas, como no caso do desenvolvimento sequencial.
Para Terwiesch, Loch e De Meyer (2002) a questão chave na coordenação de
tarefas simultâneas não é a frequência da troca de informação, mas sim quais
informações devem ser trocadas, em qual momento e como reagir a ela. Além disso,
a troca de informações preliminares, resultada da combinação de interdependência
e simultaneidade, tem sua hora apropriada para ocorrer, é proporcional aos avanços
na resolução dos problemas, se a incerteza é causada por eventos externos, como
esses eventos se desdobram influi no momento certo para a troca de informação.
2.4.7 Equipe multidisciplinar
Para alcançar as propostas da Engenharia Simultânea, é fundamental a
formação de uma equipe multidisciplinar com pessoas de todas as áreas e
especialidades envolvidas no projeto. Esta equipe pode crescer ou diminuir ao longo
de sua existência, mantendo sempre um mesmo núcleo de pessoas que
acompanham o desenvolvimento. A equipe deve trabalhar em sintonia,
considerando todos os detalhes, para que o trabalho realizado em cada área
disciplinar seja compatível com as demais e que cada área influa na outra com
informações corretas e no tempo certo.
Como afirma Haddad (1996) em pesquisa realizada numa indústria
automobilística americana, o uso de equipes multifuncionais proporciona
responsabilidade pelo projeto do início ao fim, e assim, permite aos membros da
equipe um maior poder de decisão nos vários níveis e gera um espírito coletivo de
propriedade pelo projeto.
Uma característica importante desta equipe de Engenharia Simultânea é ser
responsável por todo o projeto e possuir autoridade para as decisões. Esta atitude
requer treinamento dos membros do time e da gerência para ser efetiva. É preciso
que exista a comunicação efetiva entre os seus integrantes. Esta comunicação
envolve as pessoas, a troca de dados entre os sistemas utilizados. (PITHON, 2004)
Equipes multifuncionais (também conhecidas como “força-tarefa”) que são as
responsáveis pela instalação da simultaneidade dos processos. O líder da equipe,
além da função de liderança (que inclui a gerência do grupo e outros aspectos da
liderança do grupo), serve também como o elemento de ligação entre a diretoria e o
grupo (membros). (PITHON, 2004)
45
3 PROGRAMAÇÃO E REVISÃO SIMULTÂNEA EM PARES
3.1 Introdução
A revisão bibliográfica indica que os pontos fortes da engenharia simultânea e
revisão de código, podem ser a solução para o problema de produtividade da
programação em pares e em determinadas situações o mob programming pode ser
uma escolha vantajosa e sugere que um possível estudo terciário da programação
em pares, mob programming, code review e engenharia simultânea, possa resultar
numa nova técnica baseada na fusão entre estas técnicas correlatas e
complementares entre si. Esta seção apresenta uma proposta para esta nova
técnica, aqui chamada de PrsP (Programação e revisão simultânea em Pares).
3.2 Definição da Programação e revisão simultânea em Pares
A Programação e revisão simultânea em Pares é definida como: uma atividade
de programação onde no começo, é feito o planejamento, a seleção dos pares,
multidisciplinaridade, é projetado o emparelhamento das tarefas e com base nisso,
dois programadores trabalham colaborativamente na mesma atividade, apenas no
início da atividade sentados lado a lado para trocar experiências (desta forma há
maior número de algoritmos e soluções) ou comunicam-se no início, se estiverem
trabalhando de forma distribuída (locais diferentes), ainda nesta fase inicial, decidem
como dividir a tarefa e, não precisam sentar junto o tempo todo em um único
computador, ou comunicar-se o tempo todo se estiverem trabalhando de forma
distribuída, somente quando necessário e útil. Sempre que possível, o trabalho deve
ser executado de maneira simultânea, em computadores separados. Diferentemente
da programação em pares, na PrsP, um revisa o trabalho do outro de forma
simultânea e, caso for encontrado erro, o trabalho retorna para o programador
corrigir. No final, unem o trabalho do par e durante o descanso, sugere-se falar ou
pensar sobre a melhor maneira para a realização do trabalho, mindset zero defect,
adoção de um processo de redução de stress e para resolução de conflitos.
3.3 Descrição
Ao incorporar as práticas da Engenharia Simultânea na programação em
pares, deve-se notar a importância da comunicação, mesmo se a atividade for
realizada em dependências físicas diferentes. Também é importante frisar que
quanto mais a atividade for desenvolvida de maneira simultânea, maior será o ganho
de produtividade e a comunicação e colaboração são os pilares para junção do
46
trabalho realizado simultaneamente em computadores diferentes com sucesso, sem
comprometer com erros durante a junção do trabalho, o ganho de produtividade
obtido pelo paralelismo durante sua execução.
Os desenvolvedores trabalham em pares para realizarem suas tarefas. Isso
promove o trabalho coletivo, colaborativo, une a equipe, melhora a comunicação e a
qualidade do código. O trabalho é desenvolvido de maneira simultânea e se houver
mais de um par na equipe,as iterações são projetadas para serem simultâneas.
No projeto do emparelhamento, é definido colaborativamente a adoção ou não
do pair/mob programming e caso for adotado, definir em quais requisitos de software
será usada tal técnica. Também colaborativamente identifica-se as vulnerabilidades
técnicas da equipe, para ajudar a direcionar um coding dojo, para aumentar o nível
técnico da equipe, o que por sua vez, pode contribuir para aumentar a produtividade.
Conforme defendem Coplien e Harrison (2005) é adotado design compatível com o
emparelhamento de trabalhar em conjunto; desta forma podem produzir mais do que
a soma dos dois individualmente. A seleção dos pares depende do projeto, da tarefa
a ser realizada, da disponibilidade dos membros da equipe, da necessidade de
disseminação do conhecimento, rotação dos pares e da experiência de cada um.
Programadores, se deixados à sua própria sorte, ignoram os erros mais
flagrantes da sua tela, cujo os quais, qualquer outro programador enxergaria em um
instante (WEINBERG, 1998). Por isso, é importante que a revisão seja realizada por
outro programador, que não esteja com o olhar viciado devido a uma limitação da
capacidade humana, de enxergar apenas, o que sua mente está prestando atenção.
É importante no final, que a revisão seja feita pelo par, mesmo usando dois
computadores é possível beneficiar-se do mecanismo mencionado pelo Wray (2010)
de avisar mais detalhes, pois ele esta baseado na característica humana de não ver
o que não quer ver, então qualquer outro programador enxerga um erro, por mais
flagrante que seja, de maneira mais fácil e rápida, aumentando a produtividade.
Pode-se utilizar Groupware para automatizar, controlar, rastrear e verificar por
meio de software os procedimentos realizados pela equipe multidisciplinar no
desenvolvimento do trabalho colaborativo e simultâneo. Pode ser vantajoso o seu
uso se a equipe valorizar ou necessitar controlar ou rastrear as atividades dos pares,
bem como obter dados para alguma métrica usada em algum indicador escolhido
pela equipe, porém, equipes ágeis, tipicamente abrem mão do controle em prol da
comunicação e confiança. Alta qualidade é priorizada pelo mindset zero defect.
47
3.4 Fases
A aplicação da PrsP é dividida em sete fases.
A primeira fase é para o planejamento. É feita a seleção dos pares,
considerando a multidisciplinaridade, por exemplo, um especialista em programação
com um par especialista em interação humano computador, para evitar algum
problema na junção da interface com a programação. É projetado o emparelhamento
das tarefas, se houver mais de um par na equipe, usar o trabalho simultâneo da
engenharia simultânea para projetar iterações (sprints) simultâneas.
As fases dois e três, são referentes a autoridade e responsabilidade do par
para a divisão do trabalho, onde os desenvolvedores buscam a melhor forma para
desenvolver em paralelo/simultâneo o respectivo requisito de software que irão
implementar em par, eles conversam na fase 2, desta maneira há um maior número
de algoritmos e soluções. O par entra num acordo na fase 3 de como o trabalho será
dividido, para sempre que for mais produtivo usarem dois computadores. É muito
importante que esta divisão leve em consideração a junção que ocorrerá no final,
para não perder o aumento da produtividade obtido com o trabalho simultâneo
devido a algum problema na junção da atividade. O par tem autoridade para dividir
da melhor forma o trabalho e a responsabilidade pela eficácia da divisão e união na
fase final.
Na fase quatro, é realizado o trabalho de maneira simultânea, em dois
computadores distintos, cada um desenvolve e testa a sua parte. O par comunica-se
quando necessário, porém, sempre que possível a programação é desenvolvida de
maneira paralelo/simultânea na busca pelo aumento da produtividade.
Na fase cinco, de revisão, cada desenvolvedor revisa e testa o algoritmo feito
pelo par de maneira simultânea, devido a limitação humana de enxergar somente o
que nota, consequentemente, qualquer outro programador enxergará um erro, por
mais flagrante que seja, de maneira mais fácil e rápida, aumentando a produtividade
e, isso cria a pressão do par amplamente citada na literatura, fator este que aumenta
a qualidade pois outra pessoa irá verificar o trabalho, além de ser uma inspeção
informal. Quando o desenvolvedor testa o seu próprio trabalho muitas vezes o seu
raciocínio pode-se afirmar que fica viciado sempre nos mesmos testes, é mais difícil
para quem desenvolveu o trabalho, ter um olhar de fora, pensar numa forma
diferente para realizar o teste. A nova técnica além deste beneficio já amplamente
conhecido de outro desenvolvedor realizar o teste, para aumentar a produtividade o
48
par conversou no início, então o par que irá realizar o teste, já tem uma visão do
problema, o que é mais produtivo e preserva o olhar de um outro desenvolvedor
efetuar o teste. O fato do par ser responsável pelo trabalho, pode aumentar o
capricho do par no teste.
Durante a sexta fase, os desenvolvedores unem o código fonte, o que estimula
o trabalho coletivo e colaborativo, pois para realizar a união do programa
desenvolvido pelo par sem problemas, é necessário um planejamento prévio eficaz,
na fase inicial. A comunicação também merece destaque nesta fase, o par deve
estar alinhado em relação a como realizar a união do trabalho.
A fase 7, descanso reflexivo e prevenção/resolução de conflitos, é aberta,
devido as muitas possibilidades de um descanso produtivo e maneiras de
prevenção/resolução de conflitos, falar ou pensar sobre o programa/trabalho ajuda a
encontrar a melhor solução, a ideia é estimular o estabelecimento de um ritmo
saudável de trabalho, sem muitas horas extras por exemplo, e logo após a saída do
trabalho, pensar ou falar com o colega sobre o algoritmo/trabalho. A sugestão é
divertir-se, descansar, relaxar, encontrar familiares e amigos, porém, ao invés de
reclamar, lamentar, falar ou pensar mal de outrem, falar ou pensar sobre algo
construtivo, por exemplo, a busca por uma melhor solução para o algoritmo/trabalho,
obviamente é mais produtivo e pode contribuir para um ambiente de trabalho mais
harmônico e motivador, com menos conflitos, o que pode contribuir para o aumento
da produtividade da equipe. Manter-se motivado é mais produtivo em relação à
desmotivado. Reclamar ou lamentar-se é contraproducente, pode dificultar a
percepção de soluções corretas e ao seu alcance. O respeito ao próximo e
solidariedade ajudam na prevenção de conflitos. Se houver conflito, conversar para
resolve-lo, colocar-se no lugar do outro é importante, bem como, manter a
imparcialidade, medir cuidadosamente as palavras e se dispor a escutar.
Alguns conflitos são inevitáveis nas relações humanas. Quando as ações de
alguém são controladas por outra pessoa, ocorre a possibilidade de conflito
(PITHON, 2004). Trabalho em equipe produtivo com alto desempenho, requer
liderança, gerenciamento congruente orientado às pessoas, motivação e resolução
de conflitos entre os membros da equipe. (WEINBERG, 1997)
As fases 1,2,3,4,5 e 6 da Programação e revisão simultânea em Pares estão
ilustradas na Figura 2. A fase 7, descanso reflexivo e resolução de conflitos, tem
49
formato aberto, devido as várias possibilidades para um descanso reflexivo/produtivo
e resolução de conflitos, então está ilustrada na forma da equipe com o trabalho.
Figura 2 – Fases da Programação simultânea e revisão em Pares.
Fonte: Elaborado pelo autor
A Engenharia Simultânea tem características que contribuem ao aumento da
produtividade e algumas já são intrínsecas à programação em pares. Tais
características da Engenharia Simultânea que são fundidas à programação em
pares por este trabalho e as que são intrínsecas estão ilustradas no Quadro 3.
Quadro 3 – Complementares ou já incorporadas à programação em pares.
Engenharia
Simultânea
Característica complementar ou já incorporada na programação em
pares
Trabalho
simultâneo
Complementar, pois é difícil trabalhar de maneira simultânea usando
apenas um teclado e mouse. A incorporação do trabalho simultâneo à
programação em pares, ajuda a aumentar o comprometimento originário da
posse do teclado
Groupware
Complementar, este trabalho sugere usar um groupware para apoiar o
trabalho colaborativo e com isso obter um ganho de produtividade.
Equipe de
trabalho
Já incorporada à programação em pares, pois o par trabalha em equipe,
este trabalho apenas reorganiza o seu formato.
Trabalho
colaborativo
Já incorporada à programação em pares, o trabalho colaborativo é ajustado
por este trabalho para ser simultâneo
Equipe
multidisciplinar
Complementar, na programação em pares são dois programadores e
apenas um teclado. Para formar um par multidisciplinar este trabalho,
através da nova técnica, usa dois computadores e no projeto do
emparelhamento por exemplo, pode-se formar um par composto por um
designer e um programador.
Fonte: Elaborado pelo autor.
A Engenharia Simultânea tem características que aumentam a produtividade
no desenvolvimento de software, que justamente é o problema apresentado pela
programação em pares. O Quadro 6 analisou tais características para saber se de
alguma forma já fazem parte da programação em pares, se podem ser melhoradas,
se é necessário adaptá-las para fundí-las ou se simplesmente são novas
50
características que são incorporadas à programação em pares, tais como: o trabalho
simultâneo e multidisciplinar. O trabalho simultâneo, pode contribuir ao aumento da
produtividade, mas é necessário adaptar a programação em pares, devido à
incorporação de dois teclados e dois mouses, mas pode resolver o problema
relatado na literatura sobre a falta de comprometimento quando o programador não
está na posse do teclado. O trabalho em par auxiliado por Groupware, pode
incrementar a produtividade devido ao auxílio no gerenciamento do
compartilhamento dos recursos. O trabalho em equipe e colaborativo são adaptados
para suportarem o trabalho em par simultâneo. A programação usando pares
multidisciplinares, é incorporada à nova técnica, para melhorar a produtividade,
baseando-se no aumento da produtividade que as equipes multidisciplinares geram
à Engenharia Simultânea.
Este trabalho descreve os pontos fortes e fracos da programação em pares,
mob programming, revisão de código e engenharia simultânea. Uma fusão soa
natural ao analisar-se o fato do ponto forte de uma ser o ponto fraco da outra e vice
versa. O ponto fraco da programação em pares constatado por Smith et al. (2002);
Parrish et al. (2004); Arisholm et al. (2007) e Dyba et al. (2007) é a produtividade,
aumento do esforço de trabalho por pessoa/hora, ao considerar-se programadores
experientes ou tarefas simples. A produtividade é justamente, o ponto forte da
Engenharia Simultânea, pois segundo Mills, Bechert e Carrabine (1991); Carter e
Baker (1991); Hartley (1992) e Prasad (1996); Pires e Loureiro (2010) ela aumenta a
produtividade e o autor observou que nestas publicações os profissionais ou
programadores eram experientes.
A mudança de valores, que a cultura organizacional inerente aos métodos
ágeis representa na organização, observada por Robinson e Sharp (2003); Mcavoy
e Butler (2007) e Fraser et al. (2008) pode auxiliar na melhora dos pontos fracos da
Engenharia Simultânea apontados por Watson (1991), Haddad (1996) e Sprague et
al. (1991) acerca da necessidade de adaptação da cultura organizacional, integração
das funções em uma cultura de equipes. Os valores e princípios dos métodos ágeis,
intrínsecos à prática da programação em pares resolvem o problema da falta de
empenho oriundos dos problemas que surgem devido ao compartilhamento de
recursos na Engenharia Simultânea. Uma oportunidade encontrada por este trabalho
para a fusão com a programação em pares, é o fato dela ser adequada a pequenas
e médias empresas, que é justamente outro ponto fraco da Engenharia Simultânea.
51
O trabalho simultâneo, multidisciplinar e auxiliado por groupware da
Engenharia Simultânea é fundido à programação em pares, o trabalho em equipe e
colaborativo são mantidos e ajustados ao formato da nova técnica, os mecanismos
para aumentar a produtividade: avisar mais detalhes, conversar, lutar contra práticas
ruins de programação e compartilhar e reconhecer competências citados por Wray
(2010) são incorporados à nova técnica, bem como a rotação dos pares na equipe
observada por Swamidurai e Umphress (2014) que gera aumento da produtividade.
Na tentativa de resolver o problema de comprometimento ocasionado pela falta
da posse do teclado citado por Vanhanen e Korpi (2007); Williams e Kessler (2003),
é acatada a sugestão para possível resolução deste problema, de usar dois teclados
e dois mouses, fornecida por Chong e Hurlbutt (2007); Freudenberg, Romero e
Boulay (2007) e Höfer (2008). A nova técnica PrsP incorpora à prática de revisões
de código em pares e adere ao coding dojo, para disseminar e aumentar
conhecimento técnico da equipe. Para a disseminação do conhecimento operacional
e para os códigos críticos e complexos pode-se usar o mob programming.
3.5 Dois teclados ao invés de um, ajuda a manter o comprometimento do par
O brilhante cartunista Scott Adams (2003) ilustra na Figura 10, o problema de
comprometimento ocasionado pela falta da posse do teclado citado por Vanhanen e
Korpi (2007); Williams e Kessler (2003). Na Figura 3, o Dilbert (está usando óculos
redondos) esta na posse do teclado. Chong e Hurlbutt (2007); Freudenberg, Romero
e Boulay (2007); Höfer (2008), sugerem usar dois teclados e dois mouses como uma
forma para manter os dois programadores do par comprometidos. O Dilbert,
provavelmente também apoiaria a ideia de dois mouses e teclados.
Figura 3 – Maior comprometimento de quem esta na posse do teclado.
Fonte: DILBERT © 2003 Scott Adams. Used By permission of UNIVERSAL UCLICK.
All rights reserved.
52
3.6 Sentar junto apenas para conversar ao invés de durante todo o expediente,
pode ajudar a aumentar a produtividade
Para Terwiesch, Loch e De Meyer (2002) a questão chave na coordenação de
tarefas simultâneas não é a frequência da troca de informação, mas sim quais
informações devem ser trocadas, em qual momento e como reagir a ela. Este
trabalho de engenharia simultânea é um dos argumentos da PrsP, para o par não
sentar junto durante todo o expediente, somente para conversar, quando for preciso
e útil.
Há pessoas que não gostam durante o expediente, especialmente em sua
mesa de trabalho de cheiro de comida ou barulho gerado pelo par. A figura 4 mostra
que o personagem Wally com sua caneca de café e seu histórico de baixo
comprometimento não gostou da programação em pares do XP devido ao fato de
ninguém querer ser seu par.
Figura 4 – Duas pessoas e apenas um computador durante todo expediente.
Fonte: DILBERT © 2003 Scott Adams. Used By permission of UNIVERSAL UCLICK.
All rights reserved.
A nova técnica proposta usa dois teclados e dois mouses para o
desenvolvimento do trabalho, desta maneira é mais produtivo, pois o trabalho é
executado em paralelo/simultâneo e resolve eventuais problemas causados por ficar
quarenta horas sentado ao lado de outra pessoa.
Senta-se junto quando é necessário ao invés de durante todo o horário de
expediente. A definição abaixo incorpora o trabalho simultâneo, usando dois
computadores, conseguintemente dois mouses e dois teclados.
3.7 Fatores de produtividade
A nova técnica PrsP, afeta positivamente os fatores listados que causam
problema de produtividade no desenvolvimento de software.
53
O Quadro 4 explica como a fusão entre programação em pares, mob
programming, code review e Engenharia Simultânea atacam em conjunto o
problema da produtividade no desenvolvimento de software, incluindo os fatores
humanos, ainda muitas vezes negligenciados quando o assunto é produtividade no
desenvolvimento de software.
Trendowicz e Münch (2009), fizeram uma revisão sistemática dos fatores que
influenciam a produtividade no desenvolvimento de software, o principal resultado é
que o sucesso dos projetos de software, ainda depende de seres humanos, o
segundo fator mais comumente considerado são ferramenta e método. No entanto,
mesmo a melhor ferramenta ou método não são balas de prata e não substituem
pessoas altamente qualificadas e coordenação eficaz do trabalho. Ferramentas e
métodos devem, portanto, serem considerados amplificadores do impacto positivo
de equipes altamente qualificadas e bem coordenadas sobre a produtividade no
desenvolvimento de software.
A redução de esforço pode proporcionar um aumento gradativo na
produtividade ou pelo menos mantê-la estável durante o ciclo de vida de
desenvolvimento (BOEHM et al., 2009).
A realidade mostra que ainda existe uma lacuna entre a demanda de mercado
e a produtividade do desenvolvimento de software das organizações (SANTOS;
MOURA, 2009).
Segundo Sampaio et al. (2010); Andrade (2012); Kon et al. (2013) e Melo
(2015) vários fatores contribuem para esse cenário, como tamanho da equipe,
estabilidade dos requisitos, qualidade da gestão, habilidades e experiência da
equipe, reuso de software, ferramentas de desenvolvimento, participação e
experiência do cliente, motivação da equipe, tamanho e complexidade do software.
Quadro 4 – Fatores de produtividade afetados pela nova técnica PrsP.
Fatores de
produtividade no
desenvolvimento
Maneira como a PrsP afeta os fatores de produtividade
Reuso de software
Reuso de Software facilitado pela disseminação do conhecimento
e a rotação dos pares
Tamanho e
complexidade do
software (grandes e
complexos)
Estimula a comunicação e é auxiliada por Groupware e
simultaneidade, reduzindo o esforço no desenvolvimento
Continua na próxima página
54
Fatores de
produtividade no
desenvolvimento
Maneira como a PrsP afeta os fatores de produtividade
Motivação da equipe
Trabalho em pares estimula companheirismo, melhora a
motivação, satisfação e pode reduzir a rotatividade de pessoas na
equipe. Trabalho em equipe e a posse do teclado estimulam o
comprometimento. Trabalho simultâneo reduz a morosidade.
Qualidade da gestão
Gestão realizada pela própria equipe, comunicação e Groupware
auxiliam a gestão e satisfação da equipe
Habilidades e
experiência da equipe
Rotação dos Pares (dissemina conhecimento). Equipes
multidisciplinares. Resolução de conflitos pode ajudar a amplificar
a disseminação de conhecimento por meio de um ambiente de
trabalho harmônico e favorável ao diálogo.
Tamanho da equipe
(equipes grandes)
Apoio de software Groupware para facilitar o trabalho colaborativo.
Trabalho em equipe e colaborativo para reduzir conflitos,
facilitando a gestão de equipes grandes.
Estabilidade dos
requisitos
A participação do cliente nas equipes multidisciplinares, desde o
início, é uma importante medida que permite um perfeito
entendimento, por parte da equipe multidisciplinar, dos requisitos
que o produto deve satisfazer, bem como o cliente pode ser
assessorado com relação a requisitos conflitantes.
Participação e
experiência do cliente
Equipe multidisciplinar e trabalho colaborativo com apoio de
Groupware. Mob Programming, pode facilitar o engajamento de
outras áreas no trabalho do grupo.
Comunicação
Equipe multidisciplinar, planejamento colaborativo e trabalho
baseado em pares com comunicação constante.
Práticas modernas de
programação
Na Fase 1 da PrsP, decide-se de forma colaborativa a
necessidade da realização de coding dojo ou mob programming
para disseminar conhecimento. O trabalho em pares inerente à
técnica também pode ajudar a contribuir para o aumento do nível
técnico da equipe.
Turn over
Fase 7 da PrsP, descanso reflexivo e prevensão/resolução de
conflitos, trabalho em pares, equipes, mob programming, podem
aumentar a satisfação, motivação, comunicação, colaboração e
confiança, possivelmente reduzindo o turn over.
Gerenciamento de
conflitos
Fase 7 da PrsP, descanso reflexivo e prevensão/resolução de
conflitos, atua na prevenção e estabelecimento de um ambiente de
trabalho harmonioso e um protocolo de resolução se tiver conflito.
Fonte: Elaborado pelo autor.
Além das explicações do quadro 4, o principal artifício da PrsP para aumentar a
produtividade, é o trabalho simultâneo, que ocorre usando dois computadores,
portanto dois teclados e dois mouses, diferenciando-se da programação em pares
que usa apenas um computador e conseguintemente apenas um mouse e teclado.
As iterações simultâneas, também podem contribuir para aumentar a produtividade.
3.8– Conclusão
Foi apresentada a nova técnica Programação e revisão simultânea em Pares,
foram detalhadas as suas fases e definição. Foram apresentados os argumentos
que embasam/justificam a fusão proposta com base na revisão da literatura.
55
4 EXEMPLOS DE APLICAÇÃO DA NOVA TÉCNICA
Nesta seção são apresentados oito exemplos de aplicação e os contextos nos
quais a nova técnica proposta é aplicada, com descrição e demais detalhes dos
projetos, complexidade da tarefa e experiência do programador. Para manter o sigilo
são omitidos os nomes das organizações nas quais a pesquisa foi realizada e das
pessoas envolvidas. O pesquisador responsável por este trabalho foi consultor das
organizações nas quais este trabalho foi executado. Sua atuação no trabalho foi a
de líder técnico e desenvolvedor de algumas das equipes de desenvolvimento de
software e, o autor realizou um workshop sobre o funcionamento da nova técnica
proposta, apresentou a forma para a coleta dos dados. Nos projetos em que o autor
é um dos desenvolvedores, ele está devidamente identificado. A tabela 2 descreve
os seguimentos de atuação das organizações que aplicam a PrsP, a cidade onde
está situada e a cultura/método de desenvolvimento usado pela organização.
Tabela 02 - Descrição das organizações que aplicaram a nova técnica proposta
Nome da
organização
Cidade
Segmento de
atuação
Cultura e método de desenvolvimento de
software
Cliente 1
São
Paulo
Tecnologia de
Informação /
Desenvolvimento
de Software
Própria, método híbrido do autor e alguns
projetos externos usam os métodos de
desenvolvimento de software dos clientes
contratantes.
Cliente 2
São
Paulo
Instituição
financeira
Formal com auditoria, baseado em
planejamento.
Cliente 3
Lisboa
Tecnologia da
Informação
Híbrido de ágil com planejamento, diversas
auditorias e controle rígido dos projetos em
relação a custo e prazo devido à lei
estadunidense Sarbanes-Oxley (SOX).
Cliente 4
São
Paulo
Instituição de
Ensino
A PrsP é aplicada em sala de aula de cursos
de programação, métodos de
desenvolvimento e engenharia de sofware.
Fonte: Elaborado pelo autor
Para a classificação do nível de complexidade é usada uma fórmula do autor,
é feita uma correlação do número obtido com a complexidade que é classificada em:
baixa, média e alta. É uma aplicação das métricas bem estabelecidas e válidas, que
para computar a complexidade, vai além da Complexidade Ciclomática, é levado em
consideração a coesão, quanto maior for a falta de coesão (Lack of Cohesion of
Methods ou LCOM), maior será o desconto na complexidade. São somados os
valores DIT (Depth of Inheritance Tree), NOC (Number of Children), AC (Afferent
Coupling) e EC (Efferent Coupling). A fórmula usada para medir a complexidade é:
56
Padhy et al. (2015) realizaram uma revisão sistemática sobre métricas
orientadas a objetos e concluíram que complexidade ciclomática, DIT, NOC, AC, EC
e LCOM são bem estabelecidas e válidas. O autor deste trabalho no primeiro
exemplo de aplicação, identifica os mesmos tipos de complexidade que Antinyan et
al. (2015): interna e externa. A interna é a complexidade da própria função/método e
a externa é sua relação de dependência com outras funções/métodos.
Antinyan et al. (2015), realizaram uma pesquisa ação na Ericsson e AB Volvo
com a participação de pesquisadores das universidades de Gothenburg e Skövde,
para identificar os aspectos da complexidade do código e usam as mesmas métricas
usadas pelo autor em seu método de avaliação da complexidade do código, porém,
seu objetivo é identificar a complexidade de código para refatorar, enquanto o
objetivo do autor deste trabalho é levar em consideração a complexidade ao medir a
produtividade no desenvolvimento e qualidade do produto de software, por isso, a
fórmula do autor para complexidade, não exclui do cálculo, quando o método
apresenta um número baixo de complexidade, como fazem na Ericsson e AB Volvo.
Mandhan et al. (2015) observaram significativo nível de acerto na predição da
densidade de defeitos com as métricas complexidade ciclomática,DIT, NOC, AC, EC
e LCOM que fazem parte do NASA KC1 PROMISE Repository of empirical software
(NASA, 2015). Para Nicolaescu et al. (2015) os pesquisadores devem focar agora na
aplicação das métricas bem estabelecidas e válidas para os mais variados
propósitos. A Tabela 03 exibe a classificação da complexidade dos exemplos, bem
como o número total de linhas de código e a quantidade de programadores dos
projetos, bem como se a atuação é exclusiva, em tempo integral para o projeto.
Tabela 03 - Complexidade, número total de linhas de código e quantidade de
programadores dos exemplos de aplicação que usaram a nova técnica PrsP
Nome da
organização
Exemplo de
aplicação –
Nome do projeto
Comple-
xidade
Quantidade
de desenvol-
vedores
Equipe
exclusiva
para o
projeto?
Número total
de linhas de
código
Cliente 1
1-Atividades
esportivas
Média
4
Não, meio
período
± 25 mil
Cliente 1
2-Homebroker
Alta
12
Sim
± 4 milhões
Cliente 1
3-E-commerce
Média
4
Não
± 100 mil
Cliente 2
4-Facebroker /
Farejador
Alta
4
Sim
± 600 mil
Cliente 1
5-DMA
Alta
8
Sim
± 1,4 milhões
Continua na próxima página
57
Nome da
organização
Exemplo de
aplicação –
Nome do projeto
Comple-
xidade
Quantidade
de desenvol-
vedores
Equipe
exclusiva
para o
projeto?
Número total
de linhas de
código
Cliente 3
6-Seguradoras
Alta
12
Sim
± 10 milhões
Cliente 1
7-Gerenciador de
contratos
Média
4
Sim
± 70 mil
Cliente 4
8-Exercício de
Programação
Baixa
16
Sim,
alunos
± 200
Fonte: Elaborado pelo autor
A experiência do desenvolvedor é classificada conforme o registro de contrato
profissional de trabalho e questionário de aderência à programação em pares. É
adaptado e usado o questionário utilizado no trabalho de Sato (2007), construído
com base no trabalho de Krebs (2002) e está disponível online (HEREZ, 2015).
Para coletar de forma automática as métricas de código os 7 primeiros
exemplos de aplicação aderentes a plataforma tecnológica Microsoft .NET, alguns
dos exemplos de aplicação, usaram a ferramenta NDepend, que calcula
acoplamento entre as classes do sistema, e NCover que calcula cobertura de
código. Para verificar o padrão de código é usado o FxCop. Os exemplos de
aplicação que usam as versões mais recentes e completas do Visual Studio®, é
usado o Visual Studio® Code Metrics Power Tool, que calcula a complexidade
ciclomática, linhas de código por método, entre outras medidas e métricas adotadas
por este trabalho. Apenas o oitavo exemplo de aplicação, um exercício de
programação em sala de aula, os alunos usam como ferramenta de desenvolvimento
o Eclipse (2015) com o plug-in Eclipse Metrics (2015).
4.1 Medidas, métricas, indicadores e ferramentas aplicáveis à PrsP
Adicionar linhas de código indica apenas que o tamanho do software
aumentou, não aumenta o conhecimento de domínio do problema a ser resolvido,
guidelines do projeto, conhecimento de programação ou qualquer outro aspecto do
desenvolvimento de software (PUTNAM, 2015). Segundo o fundador da Microsoft,
Bill Gates, medir a produtividade de software pelo número de linhas de código é
como medir o progresso de um avião pelo seu peso (GATES, 2014).
A métrica proposta pelo autor para mensurar a produtividade é ligada à
qualidade do produto de software, pois os melhores algoritmos são os mais simples
que resolvem o problema (provavelmente tem menos linhas de código) e uma
métrica que use apenas as medidas de contagem de linhas de código por
58
desenvolvedor por mês, não funciona para medir a produtividade, uma quantidade
maior linhas de código ou pontos por função não significa que o desenvolvedor é
mais produtivo. Não existe um padrão universal para representar linhas de código,
pois as linguagens podem variar, assim como as regras para cálculo de linhas de
código. Portanto, uma medida pode ser baseada em um padrão local ou universal,
mas o padrão precisa ser bem definido. Neste trabalho, para melhorar a precisão
desta medida, em todos os exemplos de aplicação é definido um padrão de
codificação e por meio das ferramentas de análise de código, é verificada a
aderência ao padrão de codificação. Em relação a métrica referente ao número de
defeitos encontrados após a implantação, as medidas que compõem essa métrica
são o número de defeitos e a fase (ou data) onde o defeito foi identificado.
O aumento substancial no número de defeitos encontrados na última versão é
um indicador de que a qualidade do software piorou, porém, há outros aspectos da
qualidade do produto de software, além da funcionalidade e do número de defeitos,
para melhorar a precisão ao mensurar a qualidade do produto de software, é
necessário levar em consideração também a manutenibilidade, confiabilidade,
usabilidade, eficiência e portabilidade. Conforme padronizado na norma ISO/IEC
9126, que é uma norma ISO para qualidade de produto de software, que se
enquadra no modelo de qualidade das normas da família 9000. A norma brasileira
correspondente é a NBR ISO/IEC 9126. Esta norma refere-se a qualidade do
produto de software, propondo Atributos de Qualidade, distribuídos em seis
características principais, com cada uma delas divididas em sub características,
conforme é ilustrado na Figura 5.
Figura 5 - Modelo para qualidade do produto de software, está na parte 1 da norma.
Fonte: NBR ISO/IEC 9126 ISO 9126, 2001
59
Dyba e Dingsøyr (2008) fizeram uma revisão sistemática de estudos empíricos
de desenvolvimento de software ágil, e no que diz respeito a produtividade de
equipes ágeis versus tradicionais, três dos quatro estudos comparativos usaram
LOC por hora e nenhum dos estudos tinha uma estratégia apropriada para garantir
uma comparação imparcial e não tendenciosa.
Toda a coleta dos dados para as métricas, neste trabalho é de forma
automatizada por meio de ferramentas disponíveis no mercado. Análise estática,
significa analisar o código-fonte sem executá-lo e este tipo de análise pode ser
realizada por meio de ferramentas (como o Visual Studio® 2013 Code Analysis Tool)
ou manualmente através da opção Code Review que é suportada no Visual Studio®
2012 e 2013. A análise de código estática ajuda os desenvolvedores a identificarem
problemas com o código relacionados a design patterns, interoperabilidade,
desempenho, segurança e várias outras categorias de potenciais problemas de
acordo com as regras da Microsoft® para as melhores práticas em escrever código.
Executar uma ferramenta de análise de código em intervalos regulares durante
o processo de desenvolvimento, pode melhorar a qualidade do software, examinar o
código para um conjunto de defeitos e violações comuns do padrão de codificação é
sempre uma boa prática de programação. Além disso, a análise de código, também
pode encontrar defeitos no código que são difíceis de descobrir, através de testes
que permitem atingir um alto nível de qualidade para a aplicação, ainda durante a
fase de desenvolvimento. A análise de código é usada por este trabalho para ajudar
na avaliação e garantia da qualidade do algoritmo, para melhorar a precisão da
medida da produtividade por LOC por desenvolvedor, passa-se a considerar a
qualidade. O Team Foundation Server®, permite a execução da análise do código
no momento do check-in do código fonte no seu sistema de repositório de dados
(controle de versão). Possibilita a criação de políticas de check-in contendo regras
que obrigam os desenvolvedores a seguirem, previne-se código fora do padrão.
É usado o StyleCop (2015) que é uma ferramenta que analisa código fonte,
não compilado, ótimo para checar endentação, comentários, composição do arquivo,
padrão de nomenclatura. Também é usada a ferramenta FxCop, que é outra
ferramenta de análise de código, que verifica assemblies .NET com código
gerenciado, verifica a conformidade com as diretrizes de design para .NET
referenciados previamente, através de configurações. Prevê regras de análise de
60
código e permite que sejam personalizadas as regras para o projeto. Supressão de
avisos também é permitida. O autor sugere e adota em seus projetos, o uso de uma
das abordagens híbrida ou não (depende o caso e esta discussão é longa e
extrapola o objetivo deste trabalho, então são apenas mencionados os métodos):
SAAM, ATAM, CBAM, ou o framework de Supakkul e Chung (2004) para tratar os
requisitos não funcionais de forma prática através de um software de código aberto
bem interessante para levar em consideração e priorizar os requisitos não
funcionais, baseando-se nesta priorização dos requisitos não funcionais e usando
como referência a norma ISO 9126, é configurado o FxCop, e posteriormente
computado o desvio do padrão. As métricas como TLOC, complexidade ciclomática,
LCOM, DIT, NOC, AC e EC são coletadas diretamente do código fonte dos
exemplos por meio das ferramentas Visual Studio® Code Metrics Power Tool,
NDepends, NCover, Plug-in do Eclipse Metrics (2015). Os arquivos são obtidos do
repositório de código, nas revisões correspondentes ao final de cada iteração.
Repositório de dados (SourceSafe®, Team Foundation Server®, Subversion
(2015) ou Git (2015): métricas como o número de commits e número de linhas
código alteradas por commit são obtidas diretamente do repositório, através de um
script em alguns casos, que filtra os dados necessários, analisando o histórico, logs
e diferenças entre versões atualizadas no repositório. Essas métricas são coletadas
ao final de cada iteração.
Degradação da Qualidade: para ser mais produtivo é necessário no mínimo
preservar a qualidade equivalente ao objeto de comparação. Defeitos, linhas de
código fora do padrão, estão diretamente ligados à qualidade do código. Esta
métrica proposta pelo autor para mensurar a degradação da qualidade do código,
leva em consideração os defeitos, pois podem custar vidas, ocasionar perdas e
danos graves à imagem corporativa, materiais, financeiros, entre outros, por isso, é
multiplicado por dois, para que os defeitos pesem com mais rigor. Na literatura da
programação em pares e das métricas de software a qualidade é tipicamente medida
apenas pelos defeitos por KLOC, este trabalho vai além dos defeitos, considera o
desvio do padrão de codificação, pois código ruim, fora do padrão, degrada a
qualidade. A fórmula usada para computá-la é:
61
Desvio do Padrão: representa o percentual total de linhas de código não
aderentes ao padrão de codificação. É a avaliação da conformidade do código
escrito com os padrões estabelecidos pelos órgãos/fabricantes competentes
(ISO/OSI, W3C, PHP.NET, Microsoft .NET, Oracle Java design patterns, etc). Para
Staa (2000) deve-se verificar: sintaxe, retidão e perícia ao escrever o código do
software; perfeita utilização da linguagem de programação; utilização de
comentários; identificação e cabeçalhos; otimização exigida para um código de
qualidade. Conforme a priorização feita dos atributos de qualidade, é usado como
referência a norma ISO/IEC 9126 na calibração das ferramentas de análise de
código. Deve-se buscar nesta métrica proposta pelo autor o valor zero, pois as
ferramentas ajudam durante o desenvolvimento na prevenção de código fora do
padrão, porém, se não for possível, a fórmula para computar o desvio do padrão é:
Onde,
TLOC = número total de linhas de código de produção.
TLOCOOSC = número total de linhas de código fora do padrão de codificação.
Densidade dos defeitos: é computado pelo número de defeitos de uma
unidade. Este trabalho usa para a coleta automatizada dos defeitos usa a aplicação
de código aberto Bugnet (exemplos de aplicação com Visual Studio, com exceção
do primeiro) ou Mantis Bug Tracker (primeiro exemplo de aplicação), para prevenção
contra tendenciosidade e/ou classificação errônea por parte do usuário e atendente,
a classificação deve ser auditada colaborativamente por dois profissionais, um da
área de negócio e outro da área de desenvolvimento de software. O método híbrido
adotado em alguns exemplos de aplicação deste trabalho, usa uma prática japonesa
que faz parte desde a primeira versão do Microsoft® Solutions Framework, chamada
de mindset zero defect, nesta prática deve-se buscar a excelência no
desenvolvimento, sem cometer nenhum erro.
Número de Pontos (story-points) ou “horas ideais”: representa o número total
de pontos implementados e aceitos pelo cliente. Beck e Fowler (2001) sugerem a
utilização de “horas ideais” nas estimativas e controle da iteração, mas a unidade de
medida efetivamente utilizada não importa tanto, contanto que seja usada
consistentemente durante o projeto. Pode ser usado para a complexidade da tarefa,
ao invés de considerar-se o esforço, é levado em consideração a complexidade.
62
Produtividade direta: é necessário desconsiderar códigos fora do padrão e com
defeitos ao computar a produtividade da equipe. Linhas de código atreladas a um
padrão de codificação, não capturam a complexidade do código (mil linhas de código
simples exige uma quantidade de tempo para pensar diferente de mil linhas de
código complexo), que deve ser levada em consideração, pois influi ao medir-se a
produtividade. Esta métrica proposta pelo autor tem lastro direto com o código fonte
e binário gerado pelo programa. Para computá-la, multiplica-se TLOC pela
Complexidade descontando-se a Degradação da Qualidade:
4.2 Primeiro exemplo, atividades esportivas
Primeiro o autor realiza em janeiro de 2008 um workshop explicando sua ideia
para sua menor equipe, escolhida devido ao fato do software para atividades
esportivas ter um risco e complexidade significativamente menor que o principal
projeto da empresa, um homebroker (software para operar no mercado de capitais).
Colaborativamente, são escolhidos os requisitos a serem implementados
usando a PrsP e comparados à programação em pares.
O software para atividades esportivas, teve sua primeira versão desenvolvida
pelo autor em 1995, originalmente desenvolvido em Microsoft Visual Basic® 3,
atualizado para Microsoft Visual Basic® 6 em 1998 e assim permaneceu por 10 anos
sofrendo evoluções funcionais, o autor programou sozinho este projeto até 2005,
onde passou a contar com mais 3 programadores experientes neste projeto, porém,
em tempo parcial, com a priorização das atividades feita pela necessidade dos
clientes da empresa do autor.
O conhecimento dos requisitos do software, experiência como programador,
instrutor de treinamentos de programação e conhecimento da experiência dos
programadores envolvidos, pois são ex-alunos do autor (treinamento para as
certificações de Microsoft Visual Basic® e C# .NET), embasaram o autor a pensar
que este seria o projeto ideal para realizar este primeiro exemplo como um teste
para saber se a PrsP era factível e averiguar com maior profundidade se a PrsP é
mais produtiva e produz código com qualidade em relação à programação em pares.
Os requisitos do software a serem implementado usando a PrsP são referentes
a migração do aplicativo esportivo de Microsoft Visual Basic® 6 para C#.NET.
63
O repositório para código fonte é o Microsoft® SourceSafe. A coleta dos
defeitos é feita de maneira automatizada através do Mantis Bug Tracker.
Para assegurar que o nível dos programadores é equivalente, o autor conduz
um coding dojo no formato de mob programming, onde o autor de posse do teclado
faz uma apresentação de todos os componentes e partes mais complexas, onde são
eliminadas as dúvidas técnicas, antes do início da programação.
São atribuídos de forma colaborativa, story points aos requisitos e divididos em
quatro partes de mesmo valor. Um par programa um quarto com a programação em
pares enquanto o outro par programa o seu um quarto usando a PrsP. Depois é feita
a inversão, o par que estava usando a programação em pares passa a usar a PrsP e
vice-versa. Os quatro programadores sempre iniciaram na mesma hora e minuto,
para facilitar a contagem da carga horária. A migração durou 4 semanas, ambas as
duplas programaram 2 semanas usando a PrsP e 2 semanas usando a programação
em pares. A contagem das linhas de código é feita no Microsoft SourceSafe®.
Os resultados são expressivos, a média obtida pela equipe neste exemplo de
aplicação ao usar a PrsP é de 170 linhas de código por hora por desenvolvedor e ao
usar a programação em pares é de 68 linhas de código por hora por desenvolvedor.
Observa-se neste exemplo de aplicação, uma significativa redução do esforço
e duração no calendário de desenvolvimento, quando usa-se a nova técnica PrsP, a
redução é de 60% em relação à programação em pares e com qualidade
equivalente. A surpresa para o autor são esses 10% acima da metade, pois os
programadores são experientes e capazes, a tarefa era clara, não havia incerteza,
tratava-se apenas de uma migração, é normal pensar em 40% de ganho neste
exemplo, pois é normal pensar em dois teclados sendo digitados por programadores
equivalentes produzindo o dobro em relação à um, também é razoável, pensar num
desconto adicional de 10% para os programadores dividirem o trabalho no começo e
juntarem no final.
O ganho obtido por meio da sinergia do trabalho em equipe composta pela
dupla simultânea é significativo, é justo pensar antes da análise deste exemplo de
aplicação que a perda de dividir e juntar o trabalho seria equivalente a sinergia
obtida pela dupla o que resultaria numa redução de 50% do esforço, porém,
observa-se neste exemplo uma redução de 10% maior que a metade do esforço.
64
Este exemplo durante os 727 dias em que foi usado por 18 horas diárias não
apresentou nenhum defeito, apenas solicitações de novos treinamentos, devido a
entrada de novos funcionários.
Neste primeiro exemplo, o autor, começou a buscar uma forma mais precisa
que a adotada por outros trabalhos da literatura da programação em pares para
mensurar a qualidade, não apenas por meio da contagem do número de defeitos e
produtividade apenas por LOC ou pontos por função por programador, mas levar em
consideração a complexidade do código, tanto interna de uma função, quanto suas
dependências externas, bem como usar a norma ISO 9126, como referência para
uma avaliação acurada da qualidade do produto de software.
O código é inspecionado manualmente e está aderente ao padrão de
codificação e sem duplicidade.
Um resultado inesperado é a opinião dos desenvolvedores a respeito da
preferência pela PrsP em relação à programação em pares, devido ao aumento da
satisfação, motivação, colaboração, comunicação e confiança entre os membros da
equipe. A coleta é realizada por meio de um calendário niko-niko (NIKO-NIKO, 2015)
anotado semanalmente por cada desenvolvedor num flip-chart. Uma possível
explicação para a preferência é o fato de não precisar sentar lado a lado durante
todo expediente e sempre estar na posse do teclado.
4.3 Segundo exemplo de aplicação, homebroker
No final de 2008, é usada a PrsP em metade do projeto de um homebroker
(software para operar no mercado de capitais), a outra metade do projeto utiliza a
programação em pares. É adotada como estratégia implementar os Sprints do
Scrum (SCHWABER e BEEDLE, 2001), bem como, o desenvolvimento iterativo e
incremental. A primeira sprint, o autor destina à arquitetura de software do projeto.
As sprints são baseadas em entregas funcionais, de duração variável (com
duração máxima de 14 semanas), ao invés de timebox (duração fixa de 2 semanas).
O método usado pelo autor neste projeto é híbrido e também é baseado no
eXtreme Programming (BECK et al., 2004) para que o desenvolvimento seja feito
usando programação em pares como mencionado no trabalho, os testes são
automatizados, neste método híbrido também é englobado o Test Driven
Development (TDD). Seguindo a técnica, construímos testes de acordo com a real
necessidades dos requisitos funcionais, e direcionamos o desenvolvimento das
65
funcionalidades a partir destes testes garantindo que estas atendam aos requisitos
por consequência, desta forma é estimulada a agilidade (BECK, 2003). Todavia, o
método híbrido usado neste projeto, também é fortemente baseado em Rational
Unified Process, Open Unified Process, Engenharia Simultânea de Software e
Microsoft Solutions Framework, devido a necessidade de ser um projeto bem
documentado principalmente em sua arquitetura de software para permitir uma
auditoria fácil por parte dos auditores independentes da CVM (Comissão de Valores
Mobiliários) e do PQO (Programa de Qualificação Operacional) da bolsa. O autor
para facilitar estas auditorias, fez uma alteração na matriz de requisitos de Firesmith
(2004) acrescentando um campo para facilitar a rastreabilidade da documentação da
arquitetura aos requisitos, inclusive ao código.
Neste exemplo de aplicação é mostrado apenas o emparelhamento das
atividades, a primeira sprint referente a arquitetura de software, bem como os
diagramas Unified Modeling Language, matriz de requisitos e documentação do
projeto não são apresentados por confidencialidade e o escopo é somente a PrsP.
Todos os programas envolvidos neste projeto usam a <