IC822_-_II_Fatores_Humanos_de_Qualidade

Prévia do material em texto

Qualidade de Software
Fatores Humanos
Eduardo Kinder Almentero
ekalmentero@gmail.com
Fatores Humanos de Qualidade
• A forma como pessoas trabalham, 
individualmente e em equipe, no 
desenvolvimento de software tem impacto
importante sobre os resultados obtidos.
• Parte importante deste trabalho não é 
repetitivo, o que faz com que não seja trivial 
administrá-lo.
17/09/2014 Prof. Eduardo Kinder Almentero 2
Organizações que desenvolvem 
software
• Em todo ambiente de trabalho há situações de estresse 
e problemas de relacionamento pessoal.
• Empresas podem tratar este problema até certo ponto.
– Investir em qualidade de trabalho e vida
– Oferecer opções de lazer e conforto
• Software é diferente de outros produtos, pois o 
processo de manufatura exige grande volume de 
trabalho intelectual não repetitivo.
• Como administrá-lo se este trabalho é aleatório?
• Sistematizar!
17/09/2014 Prof. Eduardo Kinder Almentero 3
Organização do Trabalho
• “Ao elaborar um novo software, os desenvolvedores precisam criar 
soluções e, para conseguir fazê-lo, é essencial que trabalhem em perfeita 
sintonia.” (Weinberg, 1971)
• Obter sintonia depende de fatores como: boas relações informais entre os 
desenvolvedores e uma liderança adequada.
• Weinberg propõe uma medida com conceito simples: fazer o grupo 
partilhar a responsabilidade de definir objetivos.
– Tem impacto positivo, pois permite que todos conheçam o trabalho que está 
sendo desenvolvido.
– Reduzir partes obscuras reduz a probabilidade de incluir erros no código por 
incompreensão de detalhes de seu código.
• A aplicação do conceito é menos óbvia. 
– Dividir um projeto entre várias pessoas pressupõe uma organização perfeita, 
que no caso de software é muito difícil devido as inúmeros itens que devem 
ser administrados (recursos humanos, financeiros, ferramentas e produtos 
intermediários).
17/09/2014 Prof. Eduardo Kinder Almentero 4
Organização do Trabalho
• Uma forma de minimizar o problema é utilizar 
métodos e técnicas para este tipo de contexto.
– CMMI, XP, SCRUM e MPS.BR
• Contudo, uma organização de trabalho não faz 
sentido se as pessoas não sabem porque estão 
utilizando ela, como aplicá-la, quais problemas 
envolvidos e o papel de cada um no processo.
• Por isso, uma boa comunicação desempenha 
papel fundamental na correta realização destas 
tarefas.
17/09/2014 Prof. Eduardo Kinder Almentero 5
Comunicação
• Todo desenvolvedor sabe que para uma 
mesma especificação é possível criar um 
número infinito de programas diferentes.
• Um dos problemas do processo é justamente 
garantir que todos saibam qual a única 
solução adotada.
• Portanto, é essencial que todos possam se 
comunicar corretamente.
17/09/2014 Prof. Eduardo Kinder Almentero 6
Comunicação
• Uma comunicação possibilita a compreensão sobre o 
que se está trabalhando.
• A necessidade de informações vale para todos os 
envolvidos
– Programadores podem trocar informações sobre o código, 
engenheiros de requisitos podem discutir sobre requisitos 
com os clientes
• Segundo Yourdon (1989)
“... o simples ato de colocar três ou quatro pessoas em um 
projeto não faz uma equipe. Implícito no conceito de equipe 
está a ideia de se trabalhar muito juntamente, lendo o 
trabalho um do outro, compartilhando responsabilidades, 
passando a conhecer temperamentos”
17/09/2014 Prof. Eduardo Kinder Almentero 7
Individualismo
• Desenvolver software é uma atividade onde a criatividade tem 
grande influência.
• A solução de um problema ocorre na cabeça de um desenvolvedor.
• Escrever código e projetar arquitetura não é uma atividade 
repetitiva.
• Nas engenharias de um modo geral, há a estética associada com 
uma nova solução.
• Em razão disto, pode haver grande influência do ego dos envolvidos 
durante o trabalho em equipe.
• Livro de Weinberg de 1970: A Psicologia da Programação de 
Computadores.
• O livro continua sendo bastante citado, pois os problemas
abordados continuam existindo.
17/09/2014 Prof. Eduardo Kinder Almentero 8
Individualismo
• Neste cenário, dois pontos merecem atenção:
– Aplicação de padrões.
• Desenvolvedores podem se ofender com a ideia de deixar de 
lado seus próprios hábitos e adotar os padrões de uma 
equipe.
• Weinberg propõe o termo egoless programming 
(programação sem ego) para lidar com esta dificuldade.
– Posse entre desenvolvedor e o produto
• Defeitos no software podem ser interpretador como crítica 
pessoas e esta reação pode acontecer de maneira 
inconsciente.
• Esta postura pode explicar a dificuldade (ou menor 
eficiência) dos programadores em detectar defeitos ao testar 
seu próprio código.
17/09/2014 Prof. Eduardo Kinder Almentero 9
Gerência de Manufatura
• Muito material de qualidade aplicada à indústria. 
• Foi na manufatura que o conceito se fortaleceu.
• A manufatura não é o modelo ideal para pensar em uma 
fábrica de software.
• Com isto, alguns critérios de gerência não são aplicáveis e 
podem até ter resultados opostos ao que se espera.
• Dentre estes critérios, o mais perigoso é, provavelmente, o 
de produtividade.
– Aplicado erroneamente pode resultar em volume maior, mas 
dificilmente em qualidade.
– Algumas organizações adotam este critério, por exemplo, 
premiando àqueles que produzem mais código ou com relação a 
metas do cronograma.
17/09/2014 Prof. Eduardo Kinder Almentero 10
Gerência de Manufatura
• Outro critério perigoso é alocar mais recursos para resolver problemas de 
prazo.
• Se dois caminhões transportam o dobro do volume, dois programadores 
devem produzir o dobro de código.
• 1 trabalhador constrói um muro em 4 dias, dois em 2 dias e 100 em 10 
minutos?
– Problema de aplicar um modelo linear a um problema que não é (Weinberg, 1994)
• O volume de trabalho não cresce na mesma proporção do número de 
pessoas.
– A diferença é ainda mais sensível em programação.
– Quanto maior o número de pessoas, o volume de trabalho que se ganha ao adicionar 
um novo membro na equipe tende a diminuir.
• Problemas de se adicionar mais pessoas:
– Maior volume de comunicação;
– Interação mais complexa; 
– Custo de treinamento para novos funcionários (aprendizado de métodos e padrões 
utilizados pela equipe).
17/09/2014 Prof. Eduardo Kinder Almentero 11
Relação comercial-desenvolvimento
• O ambiente empresarial é muitas vezes inconsistente
– Objetivos e valores declarados não são considerados na execução das 
atividades.
– Ex: “nosso principal ativo são as pessoas”
– Na prática isto não é respeitado, ocorrem jogos de interesses e 
conflitos por poder.
• Em empresas de consultoria em TI, normalmente, há conflito de 
interesses entre áreas comercial e técnica.
• Área comercial: 
– Pressão para obter resultados (muita competição, baixas margens de 
lucro). 
– É necessário vender serviços e apresentar vantagens competitivas a 
todo momento
– Muitas vezes os vendedores acabam realizando promessas difíceis de 
cumprir com relação a prazo ou especificações de produtos/serviços.
17/09/2014 Prof. Eduardo Kinder Almentero 12
Relação comercial-desenvolvimento
• Área técnica
– Desenvolve e implanta soluções.
– Sofre com seus próprios problemas de prazo, modificações de requisitos e correção de 
erros.
– Tendência é simplificar produtos, reduzindo o trabalho (oposto ao vendedor).
• Como consequência ocorrem sérios atritos.
• Normalmente, desenvolvedores ficam desconfortáveis em fazer trabalho sem 
qualidade.
• Também não querem fazer muitas horas extras (causam insatisfação e perda de 
produtividade e qualidade) e trabalhar sob pressão de prazos.
• Nível de atenção, criatividade e diminui após muitas horas consecutivas de 
trabalho sem descanso.
• Mas a tarefa de programação depende destascaracterísticas!
• Qual a solução?
17/09/2014 Prof. Eduardo Kinder Almentero 13
Relação comercial-desenvolvimento
• Uma possível solução é a proposta de uma área 
intermediária entre vendas e desenvolvimento.
• Formada por pessoas com conhecimento em ambas as 
áreas.
– Desenvolvedores que sabem vender e vendedores que 
sabem desenvolver
• O conhecimento técnico possibilitaria entender o 
problema e propor soluções em prazos realistas.
• A responsabilidade do grupo seria harmonizar as 
expectativas do setor comercial com as possibilidades 
de realização do setor de desenvolvimento.
17/09/2014 Prof. Eduardo Kinder Almentero 14
Maturidade de Organizações
• Crosby classificou os estilos de gerência em 5 categorias 
(correspondem aos modelos de maturidade do 
CMM/CMMI)
– Incerteza;
– Despertar;
– Esclarecimento;
– Sabedoria;
– Certeza;
• Cada categoria identifica um estilo de gerência, desde um 
nível onde se trabalha através de tentativa e erro 
(incerteza) até o nível ideal, em que as decisões são 
tomadas com o mínimo de erro e de forma a garantir o 
máximo de eficiência.
17/09/2014 Prof. Eduardo Kinder Almentero 15
Maturidade de Organizações
• Outros autores propuseram classificações segundo 
visões diferentes do funcionamento organizacional.
17/09/2014 Prof. Eduardo Kinder Almentero 16
Nível Maturidade de 
Processo
Maturidade de 
recursos humanos
Congruência entre 
declarado e executado
0 Esquecido
1 Inicial Arrebanhado Variável
2 Repetitivo Gerenciado Rotina
3 Definido Adaptado Direção
4 Gerenciado Institucionalizado Antecipação
5 Otimizado Otimizado Congruência
W. Humphrey B. Curtis G. Weinberg
Maturidade de Organizações
• Cada nível se refere ao estilo de organização e a forma 
de trabalhar da empresa.
• Embora cada indivíduo tenha um comportamento 
distinto, o nível de maturidade representa o 
funcionamento da empresa como um todo.
• Empresas de baixa maturidade podem ser bem 
sucedidas.
– Tudo depende do produto que estiver sendo produzido.
• Os níveis de maturidade devem ser vistos como 
oportunidade de ganho para empresa e não níveis de 
perfeição idealizados.
17/09/2014 Prof. Eduardo Kinder Almentero 17
Maturidade de Organizações
• Avançar nos níveis de maturidade significa que a empresa 
aprende a ser mais precisa ao:
– Traçar objetivos
– Estimar variáveis, como custo e tempo
– Elaborar planos
• A seguir será apresentada uma descrição, de maneira geral 
dos 5 níveis de maturidade. É importante entender que:
– As descrições não traçam limites absolutos entre um nível 
e outro.
– Uma organização pode apresentar características de vários 
níveis.
• Por exemplo, para projetos e setores diferentes.
17/09/2014 Prof. Eduardo Kinder Almentero 18
Maturidade de Organizações
• Nível 1: caótico
– Empresa não possui processos;
– Trabalho realizado sem planejamento;
– Pessoas reagem a medida que problemas surgem;
– Projetos desenvolvidos através de improvisações;
– Projetos dependem de “heróis”;
– Conhecimento pertence ao individuo;
– Não há trabalho em equipe.
• Sem coordenação e planejamento.
– Existem equipes e gerentes!
– Ainda assim, algumas conseguem sobreviver.
17/09/2014 Prof. Eduardo Kinder Almentero 19
Maturidade de Organizações
• Nível 2: repetitivo
– Organizações neste nível funcionam com base em 
rotina: o que funcionou no passado é, 
provavelmente, a solução dos problemas atuais.
– Naturalmente, isto não é verdade.
– A diferença para o nível caótico é que a 
organização possui receitas prontas e é capaz de 
repetir formulas que já deram certo, ainda que 
estas não sejam as ideais.
17/09/2014 Prof. Eduardo Kinder Almentero 20
Maturidade de Organizações
• Nível 3: definido
– A transição para este nível ocorre quando a organização percebe 
que o desenvolvimento de um produto pode ser feito com mais 
segurança se forem aplicados os processos corretos.
– Uma característica chave neste é o conhecimento das pessoas.
• Compreendem os processos, sua utilidade e importância; 
– Cada tarefa tem um propósito claro, permitindo que as pessoas 
executem suas tarefas sabendo o porquê da necessidade de 
seguir um padrão.
– É possível escolher os processos corretos em função de sua 
adequação ao contexto tratado.
• Sem seguir uma base puramente empírica (experiência/observação).
17/09/2014 Prof. Eduardo Kinder Almentero 21
Maturidade de Organizações
• Nível 4: gerenciado
– Os problemas que podem surgir são antecipados.
• É preciso controle sobre a execução de processos.
– Processo são medidos com intuito de otimização.
– Detecção de problemas e elaboração de planos de 
contingência.
– Medidas são parte integrante dos processos e 
atividades de trabalho
• Permite que cada tarefa seja acompanhada de maneira 
muito mais próxima que os níveis anteriores.
17/09/2014 Prof. Eduardo Kinder Almentero 22
Maturidade de Organizações
• Nível 5: otimizado
– Organização incorpora qualidade como um valor que 
se torna institucionalizado.
• Reflete nos seus produtos e em seu funcionamento com um 
todo.
– Procura constante por alternativas para melhorar 
todas as atividades que realiza.
– Histórico de informações sobre processos anteriores 
e coleta de dados sobre processos em andamento.
• Permite analisar sua maneira de produzir e buscar opções 
para torna-la mais eficiente.
17/09/2014 Prof. Eduardo Kinder Almentero 23
Práticas de organizações maduras
• Organizações não precisam sempre inventar 
novas maneiras para resolver seus problemas.
• A maioria das dificuldades são recorrentes e bem 
conhecidas.
• É possível buscar soluções desenvolvidas por 
outras organizações, que foram refinadas ao 
longo do tempo.
• Algumas boas práticas conhecidas: interação com 
o cliente, gerenciamento de projetos, métricas, 
treinamento e revisão por pares. 
17/09/2014 Prof. Eduardo Kinder Almentero 24
Interação com o cliente
• Um dos maiores fatores de fracasso em projetos de software é a constante 
alteração nos requisitos e escopo.
• Porém, estas alterações são inevitáveis. O problema reside em saber como lidar
com elas.
• As duas partes devem ceder
– Desenvolvedores devem saber que é necessário atender as mudanças, apesar do trabalho 
extra que elas acarretam.
– Os clientes devem entender que há riscos nas mudanças: atraso do projeto e aumento dos 
custos.
• Organizações maduras veem os clientes como um parceiro com interesse em 
comum.
– Transparência na discussão de prazos, custo e qualidade do projeto.
– Toda não conformidade é comunicada ao cliente.
– O cliente é encorajado a se comunicar com os desenvolvedores.
• Contratos formais são necessários, mas diálogos informais podem ajudar na 
resolução de conflitos.
• Organizações maduras entendem a importância de contratos bem definidos, mas 
procuram envolver o usuário na sua escrita e estão preparadas para imprevistos.
17/09/2014 Prof. Eduardo Kinder Almentero 25
Gerenciamento de projetos
• Organizações maduras elaboram planos de projetos 
realísticos e honestos.
– Algumas adotam estratégias diferentes para ganhar a concorrência.
• Acarreta projetos de baixa qualidade, cliente sem confiança e 
desenvolvedores pressionados.
– Para elaborar estes planos, são os riscos são analisados e gerenciados.
– Busca-se métricas mais precisas para calcular prazos e custo.
– Base histórica é utilizada para definir parâmetros para os projetos 
atuais e alimentada com os dados destes projetos.
– A utilização de experiências anteriores favorece a repetição de 
sucesso, diminuindo as chances de fracasso.
17/09/2014 Prof. Eduardo Kinder Almentero 26
Treinamento
• Organizações maduras oferecem treinamentos formais para 
novos contratados.
– Introdução aos padrões da organização(processos).
• Garante a padronização do método de trabalho
• Programas com reciclagem para os funcionários antigos.
– Novos projetos podem demandar a utilização de 
tecnologia, processos, linguagem que não são dominados 
pelos funcionários.
– Treinar os funcionários antigos em detrimento de 
contratar novos reduz os custos do projeto.
• Coaching: funcionários mais experientes monitoram e 
auxiliam o desenvolvimento da carreira dos mais novos.
17/09/2014 Prof. Eduardo Kinder Almentero 27
Revisão por pares
• Há uma resistência natural de desenvolvedores em encontrar defeitos em 
seu próprio código.
– Problema da propriedade.
• Uma maneira simples de contornar a situação é solicitar outra pessoa 
para realizar uma revisão.
• Organizações maduras utilizam a revisão por pares.
– Todo artefato produzido por um membro da equipe passa pela revisão de 
outro funcionário.
• Documentos de requisitos, código, diagramas de análise, ...
• Prática eficaz para encontrar erros e não conformidades com os padrões 
estabelecidos.
• Deve ser conduzida corretamente, para evitar conflitos entre os 
integrantes da equipe.
• Gerentes são responsáveis por administrar as revisões
– Participantes devem entender que o que se está julgando são os resultados do 
trabalho, e não a pessoa que o executou.
17/09/2014 Prof. Eduardo Kinder Almentero 28
Material de apoio
• Bibliografia básica
– KOSCIANSKI, A. Qualidade de software. 2. ed. São 
Paulo: Novatec, 2007
– SOMMERVILLE, I. Engenharia de software. 8. ed. São 
Paulo: Addison Wesley, 2007.
• Bibliografia complementar
– PFLEEGER, S.L., et al, “Software Engineering”, Prentice 
Hall, 2005, 3rd edition.
– Guide to the Software Engineering Body of 
Knowledge, IEEE Computer Society, 2004. Disponível 
em http://swebok.org.
17/09/2014 Prof. Eduardo Kinder Almentero 29