DA MELHORIA DE PROCESSOS, NO DESENVOLVIMENTO DE SOFTWARE, À MELHORIA DE
PESSOAS; CONSEQÜÊNCIA: MELHORIA DA QUALIDADE.
Flávio Bernardes
Mestrando do curso de Mestrado Profissional em Sistemas da Computação
Centro Universitário FIEO – UNIFIEO.
Orientador: Prof. Dr. Fábio Kawaoka Takase
Área de Concentração:
Sistemas da Informação
[email protected]
[email protected]
Resumo
Este artigo enfatiza a necessidade de um processo de aprendizagem
organizado para tornar efetivas e reais as melhorias dos processos de
desenvolvimento de software.
As melhorias são propostas e freqüentemente implementadas, mas muitas vezes
deixadas de lado por falta de conhecimento ou entendimento dos
desenvolvedores. No processo de maturidade das equipes, o que necessita ser
sedimentado e estabilizado é o conhecimento que nem sempre é explicitamente
relacionado ou considerado às atividades de desenvolvimento.
Nosso propósito nesse documento é acentuar a necessidade de tornar a
aprendizagem um processo contínuo do desenvolvimento e não apenas uma fase
inicial ou uma atividade fora deste. A existência e a necessidade de
pessoas com conhecimento técnico avançado não garante, nem as torna capazes
de entender os procedimentos e normas envolvidas num projeto de
desenvolvimento de software. Um processo organizado seria capaz de atenuar
essa necessidade, garantir a maturidade da equipe e assegurar a melhoria da
qualidade do software desenvolvido.
ARTIGO
**DA MELHORIA DE PROCESSOS, NO DESENVOLVIMENTO DE SOFTWARE, À MELHORIA DE
PESSOAS; CONSEQÜÊNCIA: MELHORIA DA QUALIDADE.**
FLÁVIO BERNARDES
1. INTRODUÇÃO
Este artigo relaciona o processo de aprendizado de uma pessoa que participa
do desenvolvimento de um software com a melhoria da qualidade do software.
Métricas foram introduzidas para que o planejamento e controle do processo
de desenvolvimento de software e a qualidade dos softwares desenvolvidos
pudessem ser estimados. A experiência tem mostrado que a interpretação dos
dados coletados é extremamente importante, porque permite avaliar os
processos do dia-a-dia e identificar se eles estão sendo de fato
eficientes. Esta abordagem permite verificar, de forma indireta e portanto
inconclusiva, a maturidade das pessoas envolvidas no processo de
desenvolvimento de software. Podemos supor que os desenvolvedores estão
aprendendo com sua atuação no processo de desenvolvimento de software e que
há um desafio a ser vencido: o estabelecimento de um processo explícito de
aprendizagem.
A importância do fator humano para o sucesso do desenvolvimento de software
é geralmente aceita, porque o sucesso de um projeto de software é
determinado, sobretudo, por ter as pessoas certas, no lugar certo, na hora
certa. Mas isso conduz a ter o custo certo, o conhecimento certo e a
qualidade certa?
A impossibilidade de a empresa adquirir conhecimento sem que seus
funcionários aprendam e a dependência da melhoria constante e sustentável
dos processos na maturidade da equipe, explicitam a necessidade de um
processo organizado de aprendizagem.
2. DESCRIÇÃO DO PROBLEMA
Sempre que se busca a melhoria da qualidade, da performance e de outros
fatores relacionados ao desenvolvimento de software, tem-se em conta
somente os processos. Como qualquer sistema de engenharia, estabeleceu-se
que ao melhorarmos os processos teremos como conseqüência a melhoria dos
demais fatores. Essa lógica faz todo sentido, uma vez que ao corrigir um
processo responsável por uma falha, essa não se repetirá e assim passa a
ser evitada para sempre. Mesmo assim, isto não tem se mostrado tão
determinante quanto o enunciado, o que leva a refletir que melhorar os
processos não tem sido suficiente para o sucesso dos projetos de software
devido ao fator humano envolvido. Algumas premissas devem ser atendidas
para que o software tenha a qualidade adequada. (Schulmeyer, 1998,
pg.68,69,70)
Quanto ao projeto:
Exatidão – Nível de conformidade do software com as especificações e
os objetivos declarados.
Manutenibilidade – Facilidade de localizar e corrigir falhas dentro de
um tempo especificado sem grande esforço.
Verificabilidade - Facilidade em identificar as peculiaridades e a
performance baseada nos objetivos declarados.
Quanto à performance:
Eficiência – O quanto o software é capaz de fazer utilizando o mínimo
possível dos recursos do sistema no qual está inserido (hardware,
sistema operacional, comunicação, etc).
Integridade – Garantia de que o software resistirá ao acesso não
autorizado.
Confiança - O software vai atuar (executar), de acordo com seus
objetivos, dentro de um especifico período de tempo.
Usabilidade – Fácil de aprender e de operar.
Testabilidade – Fácil de testar a fim de verificar se executa as
funções especificadas.
Quanto à adaptação:
Expansibilidade – Relativo ao esforço requerido para expandir suas
capacidades ou performance através do aumento de funções ou
funcionalidades.
Flexibilidade – Refere-se ao esforço requerido para mudar a missão,
funções ou dados a fim de atender mudanças de necessidades ou
requerimentos.
Portabilidade – Facilidade com que se pode transportar o software de
um para outro ambiente ou plataforma de hardware.
Interoperabilidade – Esforço necessário para acoplar o software de uma
plataforma a outro software ou a outra plataforma, ou ambos.
Intra-Operabilidade – Esforço requerido pela comunicação entre
componentes no mesmo sistema de software.
É extremamente difícil, senão impossível, desenvolver um software que seja
aderente a todos estes fatores; mas sem atender, pelo menos à maioria
deles, não terá sido atingida a qualidade necessária. Há que se considerar
também que não há um único caminho que garanta a qualidade de todo
desenvolvimento de software. De Marco (apud Peter Meddleton) diz: "A idéia
de que uma simples metodologia deveria controlar mesmo dois diferentes
projetos é altamente suspeita. As diferenças entre projetos são muito mais
importantes que suas similaridades". Ele diz também que condições de
trabalho são fatores críticos para o aumento da produtividade e observou
que metodologias detalhadas estabelecidas como regra reduzem, ao invés de
aumentar a produtividade. A complexidade, conformidade, mutabilidade e
invisibilidade do software, são propriedades essenciais para as quais não
há nenhuma solução milagrosa ou genial (Brooks, 1995). Como os processos
determinam onde quando e como as coisas devem ser feitas, a correção do
processo leva a uma atividade com qualidade mínima garantida. As
metodologias têm, portanto, encontrado meios de garantir a qualidade mínima
necessária, mas não têm se mostrado suficientes, sobretudo porque o que se
busca não é o mínimo, mas o máximo possível.
Mas como melhorar a qualidade se a melhoria dos processos não atingiu esse
objetivo? Podemos então supor que o insucesso no desenvolvimento de
software se deve também a fatores humanos, uma vez que todas as iniciativas
que trabalharam com os processos foram insuficientes? Desenvolvimento de
software é um trabalho de intensivo conhecimento e habilidade que como
conseqüência determinam a qualidade do produto resultante.
O problema parece estar no fato de que os processos não são totalmente
aceitos ou entendidos pelos desenvolvedores, e freqüentemente são
percebidos como inúteis, apenas mais um controle ou como um trabalho
adicional. Os desenvolvedores vêem os processos escritos como uma regra de
um grupo, que impõe normas a serem seguidas sem qualquer contestação.
Possivelmente a rigidez da norma ou sede de controle tenha levado a este
estado de coisas. Talvez, se o desenvolvedor se sentisse responsável pela
qualidade, não por causa da norma ou do processo, mas pelo entendimento dos
requerimentos do produto que ele está ajudando a criar, pelo conhecimento
das condições de adaptação necessárias e pela avaliação dos erros cometidos
pelo grupo do qual faz parte, pudesse então haver um salto na qualidade do
software.
Sendo este um fator crítico, o que é preciso ser feito para que seja
aprimorado? Se o foco é o desenvolvedor, o que fará com que ele responda
melhor a estas questões? O que o levará a executar melhor suas tarefas de
modo a obter a qualidade desejada no desenvolvimento de software?
Podemos melhorar as pessoas, que por sua vez melhorarão os processos? Como
isso é possível?
3. O APRENDIZADO
A teoria do conhecimento deve ser investigada para que seus conceitos
essenciais sejam entendidos. "O aprendizado é o processo pelo qual o
conhecimento existente é enriquecido ou novo conhecimento é criado".
(Weggeman, 1997, p 4). O aprendizado lida com a expansão do conhecimento,
que é a habilidade pessoal que permite a uma pessoa executar certas
tarefas. Muitas classificações do processo de aprendizado são descritas na
literatura. Por exemplo: conhecimento cognitivo versus motor, declarativo
versus procedural, explicito versus implícito ou racionalístico versus
empírico (Swieringa, 1990).
Nonaka e Takeuchi (1995) distinguem 4 processos de aprendizado.
Socializado – processo de aprendizado entre pessoas em que o
conhecimento implícito é transferido por copia, imitação,
relacionamento mestre pupilo, e experiências de tentativa e erro.
Externalizado – um processo de aprendizado individual ou entre
pessoas, em que o conhecimento implícito é tornado explícito por
construção de modelo, diálogos e formulações de hipóteses.
Combinado – um processo de aprendizado em que conhecimento explícito
de diferentes fontes é combinado, como por exemplo, estudo, análise,
reconfiguração e integração.
Internalizado – um processo de conhecimento individual em que o
conhecimento explícito é tornado implícito pela aprendizagem, pelo
fazer, criar rotinas e aumentar a eficiência operacional.
Todos os quatro processos estão presentes durante o desenvolvimento de
software.
A mudança de comportamento deve ser produto de aprendizagem em grupo e de
reflexão sobre o impacto dessa mudança sobre os processos, sobre os
resultados e sobre o grupo de modo geral e individualmente.
Aprendizado individual.
Ocorre quando uma única pessoa tem seu conhecimento enriquecido. A teoria
da aprendizagem por experiência define um explicito processo de
aprendizagem em que experiências são transformadas em conhecimento através
de modelo criado e modelo testado.(Kolb,1984). De acordo com essa teoria,
nem a experiência, nem o processo de transformação sozinhos é condição
suficiente para alcançar o aprendizado.
Há diferentes classes de experiências e transformações, mas quatro são
importantes ao nosso propósito:
Aprendizagem divergente – durante a qual observações são analisadas.
Aprendizagem assimilativa – durante a qual os modelos são criados.
Aprendizagem convergente – durante a qual os modelos são testados na
prática.
Aprendizagem acomodativa – durante a qual experimentos são observados.
De acordo com Kolb, a combinação desses quatro aprendizados resulta no mais
alto nível de aprendizagem. O entendimento desses processos requer o
conhecimento de detalhes abrangentes de todo o processo. As pessoas iniciam
com um certo conhecimento e experiência, e freqüentemente adquirem novos
conhecimentos correlatos ou aumentam a amplitude do conhecimento que
possuem. A ligação entre o conhecimento existente e o novo conhecimento faz
com que as pessoas interpretem o não-familiar utilizando o familiar.
Aprendizagem em grupo.
Desenvolvimento de software acontece em equipes, projetos, departamentos e
companhias, que se ocupam com grupos de pessoas. Desenvolvimento de
software é sempre compartilhado. Os processos, os objetivos, tudo é
compartilhado. Não apenas a aprendizagem individual acontece, mas também a
organizacional. Podemos dizer que a aprendizagem organizacional acontece a
partir da sinergia que resulta da contribuição do conhecimento de todos os
colegas membros das equipes. Importante lembrar o que diz Weggeman:
"Organizações não aprendem: indivíduos aprendem e podem aprender juntos"
(Weggeman, 1997, pg 12).
Huber destaca que o aprendizado tem lugar quando "o comportamento potencial
é modificado" (Huber,1991, pg 4). Sabemos que o comportamento não precisa
ser modificado a todo momento, no entanto, a expansão do conhecimento pode
trazer o potencial para essa mudança no momento oportuno. Se o
comportamento se mantém inalterado, aparentemente não houve aprendizado.
Argyris e Schön identificam dois modos de aprendizagem (Argyris e Schön,
1992, pg 120):
Single Loop Learning (Aprendizagem de único laço) – É o aprendizado em
que o ator apenas aprende dentro dos limites da teoria que ele já
utiliza. Tem o foco no nível operacional: aprendizagem baseada em
detecção e correção de erros.
Double Loop Learning (Aprendizagem de laço duplo) – É o aprendizado
que ocorre quando um evento é diagnosticado como incompatível com a
teoria que já utiliza. Nesse momento, o modelo e a teoria são
alterados e uma nova estratégia é identificada provocando um
aprendizado mais eficiente através da otimização do procedimento
anteriormente utilizado.
Um balanço deve ser encontrado entre a otimização dos processos existentes
(single loop learning) e a experimentação com novas abordagens (double loop
learning).
Segundo Peter Senge, as habilidades e capacidades requeridas para a
aprendizagem em uma organização são (Senge, 1990, pg 47):
Aspiração: a capacidade dos indivíduos, equipes, e até organizações de
ter foco no que é importante e aprimorar porque querem e não porque
precisam.
Reflexão e conversação: a capacidade de refletir sobre os padrões de
comportamento e suposições profundamente escondidas no comportamento
das pessoas, individual e coletivamente.
Conceitualização: a capacidade de enxergar os sistemas e forças em
jogo e construir um modo público e testável de expressar essas visões.
A interação mestre-aprendiz é um importante elemento na aprendizagem, e
dentro dos processos de desenvolvimento é representada pela retro-
alimentação, ou seja: os participantes recebem a informação dos resultados
de suas atitudes e ações, formando assim um raciocínio realimentado pela
percepção dos outros participantes. Essa interação acontece nas reuniões de
avaliação, ou durante todo o processo de programação. Assim, de acordo com
a teoria, um laço (loop) representa o aprendizado de um participante, e o
outro o aprendizado influenciado pelos demais participantes. Importante
frisar que ambos, estudante e professor (nesse caso colaboradores do mesmo
projeto) influenciam o resultado do processo de aprendizagem.
4. CONCLUSÕES.
Utilizar todos os meios disponíveis para facilitar a aprendizagem é um
objetivo a ser atingido. Cuidar apenas dos processos já mostrou ser
insuficiente. O desejo de obter o desenvolvedor no mercado, pronto para se
integrar à equipe é até certo ponto, possível de ser realizado. Ele deve
vir com os conhecimentos necessários ao bom desempenho de suas funções, e
isto é fato. No entanto, durante o seu trabalho de desenvolvimento, um
processo de aprendizagem deve ser formalmente desenhado, com o propósito de
capacita-lo a resolver os problemas do dia-a-dia. Isso significa que os
elementos da equipe devem trocar informações, conhecimentos e experiências
vividas no projeto.
Isto só se dará se forem criados mecanismos que permitam esse
compartilhamento e também que possibilitem que os indivíduos não se sintam
ameaçados, que sintam-se livres em apresentar suas idéias, compartilhar os
problemas e erros. Para isso um ambiente de aprendizagem e cooperação deve
ser incentivado. As métricas devem ser utilizadas com o propósito de
controlar. A gerência deve mostrar-se aberta e não punitiva. Se esse
ambiente existir, certamente haverá um maior aprendizado.
5. RECOMENDAÇÕES.
A importância e o impacto que o fator humano tem no sucesso do
desenvolvimento de software, embora largamente aceito, não tem tido a
devida relevância. Conhecimento e habilidades técnicas são pré-requisitos
dos desenvolvedores. Entretanto tem de haver um modo de tornar esse
conhecimento disponível a todo o grupo, principalmente o conhecimento que é
adquirido durante o processo de desenvolvimento, uma vez que todo
desenvolvedor continua a aprender durante o desenvolvimento. Criar uma
estrutura organizacional em que o aprendizado seja efetivo é um desafio a
ser perseguido. Não é escrever um manual para o usuário do sistema,
tampouco detalhar os processos repetitivos. É fundamental criar um ambiente
em que o aprendizado seja facilitado.
Os processos de avaliação geralmente são considerados como forma de
controle. As reuniões de avaliação e atualização maçantes e enfadonhas
formas de cobrança em que os participantes poupam-se de críticas e de
assumir responsabilidades. Mas esse quadro pode ser alterado se um ambiente
de aprendizado é disponibilizado e incentivado. A gerência tem o dever de
fazer a equipe entender que os erros não serão punidos, mas servirão como
base para que novos procedimentos sejam adotados a fim de se evitar
problemas futuros. Os desenvolvedores se sentirão participantes e
responsáveis. Como tornar os processos de avaliação suaves o suficiente
para serem eficazes e prazerosos e cumprirem algumas funções importantes:
fazer a equipe trabalhar porque quer e refletir e interagir (Aspiração,
Reflexão e conversação - Senge, 1990). A proposta é que as reuniões de
avaliação diárias ou semanais para a troca de experiências e idéias,
estejam baseadas num ambiente de abertura em que o fluxo de informações e o
debate seja aberto e livre; que os problemas sejam compartilhados e as
lições aprendidas, de modo que se torne prática comum não burocrática.
Num primeiro momento, até que todos os participantes entendam essa idéia,
as reuniões talvez não sejam muito produtivas. Para que esse propósito seja
atingido deve haver uma intervenção positiva da gerência no intuito de
mostrar que as falhas não serão punidas e sim aprendidas, corrigidas e
absorvidas num novo processo ou tornar-se fator determinante na melhoria de
outros processos utilizados. Em pouco tempo, essas praticas tornar-se-ão
comuns e terão a simpatia de todos os participantes.
É, no entanto, fundamental que exista um elemento aglutinador, alguém que
seja designado a registrar essas impressões e formar um acervo para
consultas posteriores das lições aprendidas.
Muitos pontos colocados nesse artigo precisam ser aprofundados, mas é
importante salientar que facilitar a aprendizagem é dever de toda a
companhia e certamente vai trazer benefícios de longo prazo. Esse
procedimento não deve ficar restrito a um pequeno período ou grupo. Deve
ser um processo que perdure por toda a vida da empresa.
Vamos melhorar as pessoas e certamente teremos os processos melhorados e,
principalmente, teremos produtos de melhor qualidade voltados não apenas
para a satisfação dos objetivos da empresa, mas para atendimento das
necessidades do ser humano e da sociedade.
6. REFERÊNCIAS BIBLIOGRÁFICAS
ARGYRIS, C., SCHÖN, D.A, On Organizational Learning, Addison-Wesley, 1992.
BROOKS, JR, FREDERICK, The Mythical Man-Month, Addison-Wesley, 1995.
HUBER, G.P., Organizational Learning: the contributing processes and the
literatures, Organization Science, Vol 2 nº 1, pp 88-115, Fev.1991
I. NONAKA, H. TAKEUCHI, The knowledge-Creating Company, Oxford University
Press, New York, 1995.
J. SWIERINGA, A.F.M. WIERDSMA, On the way to learning organization: on
learning and education in organizations, Wolters Noordhoff Management,
1990. (http://www.gqm.nl/, Eindhoven University of Technology)
KOLBI, D. A., Experiential Learning, Prentice-Hall, 1984.
M. WEGGEMAN, Knowledge Management, Scripitum Management, 1997.
MIDDLETON, Peter, McCollum, Barry, Management of process improvement by
prescription, The Journal of Systems and Software, Elsevier Science B.V
July 2000.
R. VAN SOLINGEN, E. BERGHOUT, R. KUSTERS, J. TRIENEKENS, From process
improvement to people improvement: enabling learning in software
development, Elsevier Science B.V. 2000.
R. VAN SOLINGEN, E. BERGHOUT, On software engineering and learning theory.
Facilitating learning in software quality improvement programs,
SENGE, P. M., The Fifth Discipline: The art and practice of the learning
organization, Doubleday, New York, 1990
SCHULMEYER, G.C. E J.I. MCMANUS, Handbook of Software Quality Assurance, 3ª
Ed, Prentice-Hall, 1998
