Fatos e falácias de Engenharia de Software - Profissionais de software

Carnaval chegando, pessoal se preparando para cair na folia e inspirado nessa animação, nada melhor do que discutirmos um pouco sobre engenharia de software não é pessoal?!

Hoje estou dando início a uma sequência de postagens com discussões sobre temas diversos englobados pela engenharia de software. Boa parte dessas discussões são fruto da minha opinião a respeito de partes do livro "Facts and Fallacies of Software Engineering" escrito por Robert L. Glass em 2003. Esse é um livro muito interessante e de leitura super agradável que recomendo a todos que tiverem interesse em se aprofundarem nessas discussões.

Para auxiliar aos mais interessados no tema, segue abaixo partes do livro de Glass disponibilizada pelo Google Books:


Nessa primeira discussão expresso minha opinião a respeito de alguns tópicos que envolvem diretamente os Profissionais de software e seus respectivos Ambientes de trabalho. Espero comentários e críticas para enriquecermos nossos conhecimentos a respeito desse tema.

Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 622 - Engenharia de Software
Resumo no. 1
Fatos estudados
1 - O fator mais importante no trabalho com software não são as ferramentas e técnicas utilizadas pelos programadores, mas sim a qualidade dos próprios programadores.
3 - Adicionar pessoas a um projeto atrasado faz atrasá-lo mais ainda.
4 - O ambiente de trabalho tem um profundo impacto sobre a produtividade e a qualidade do produto
6 - Aprender uma nova ferramenta ou técnica realmente reduz a produtividade do programador e qualidade do produto inicialmente. O benefício final é alcançado somente após a curva de aprendizagem ser vencida. Portanto, vale à pena adotar novas ferramentas e técnicas, mas apenas (a) se o seu valor é visto de forma realista e (b) se paciência é usada na medição dos benefícios.

Discussão
Ambos os fatos analisados tratam de temas pouco tangíveis por serem relacionados a pessoas.

O primeiro fato trata da importância dos profissionais (analistas e programadores) no desenvolvimento de software. Por questões culturais, muitos engenheiros de software ainda consideram as ferramentas e técnicas empregadas no desenvolvimento de software sendo mais importantes que a qualidade dos profissionais que as utilizam, mesmo sendo a importância da qualidade dos profissionais um objeto de muitos estudos há anos, como relata PRESMAN [5].

Gerenciar ferramentas e metodologias a serem aplicadas no desenvolvimento de software é algo mais tangível que o gerenciamento de pessoas, por esse motivo as empresas tendem a dar maior atenção à quais ferramentas e técnicas de desenvolvimento de software serão usadas em determinado projeto do que despenderem tempo com análises de motivação e perfil dos profissionais que serão alocados para o mesmo. Isso é um grande erro, pois de nada adianta empregar as melhores técnicas e usar as melhores ferramentas se o profissional que as utiliza não for competente para exercer suas atividades.

Para amenizar essa deficiência na gestão de pessoas, o SEI criou o PM-CMM, que nada mais é do que uma extensão do CMM, porém com foco exclusivo nesse tipo de gestão, tendo práticas como o treinamento de pessoal, recrutamento, desenvolvimento de carreira e remuneração [4].

O fato três é relacionado à adição de profissionais a projetos de software atrasados com intuito de acelerar o mesmo. Em processo de desenvolvimento de software isso não funciona muito bem, pois as atividades que envolvem esse tipo de processo são mais mentais do que mecânicas. Nesse sentido torna-se muito difícil um profissional ser inserido em um projeto que está em andamento e imediatamente render no mesmo ritmo dos outros profissionais que já participam do processo. Para ficar sintonizado com a equipe, esse profissional demandará uma maior atenção por parte dos outros e isso acarretará em atrasos e menor rendimento da equipe toda.

Baseando-se na análise de alguns relatórios de projetos open source, YILDIRIM [7] afirma que ocorre aumento na média das contribuições com o acréscimo de programadores nas fases iniciais dos projetos, e um declínio na fase adulta. Isso vem a ratificar a Lei de BROOKS [3].

O fato 4 deixa claro que de nada adianta ter a melhor equipe de programadores, usando as melhores ferramentas e técnicas de desenvolvimento de software se estes não estiverem em um ambiente propício ao trabalho que realizam. Interrupções e desvios de atenção causados por ambientes de trabalho tumultuados podem gerar muitos erros, haja vista que os trabalhos realizados em todas as etapas do desenvolvimento de software exigem muita atenção. Existem algumas iniciativas no sentido de controlar a qualidade do ambiente de trabalho, dentro elas vale ressaltar o PM-CMM, que contém diversas práticas em áreas de gestão de pessoas, sendo uma dessas áreas a de qualidade do ambiente de trabalho [4].

O fato 6 trata da curva de aprendizagem de novas ferramentas e técnicas de programação. Empresas investem em atualizar seus profissionais, possibilitando que os mesmos aprendam novas tecnologias aplicáveis aos seus respectivos processos de desenvolvimento de software, mas todo aprendizado tem seu custo, fazendo com que a produtividade e a qualidade dos produtos caiam inicialmente. Isso se deve a diversos fatores, dentre eles a insegurança e inexperiência dos profissionais ao aplicarem as novas tecnologias.

A qualidade dos profissionais e o ambiente de trabalho que ele está inserido podem influenciar muito no tempo gasto para uma equipe passar a dominar determinada técnica ou ferramenta e assim trazer benefícios a empresa, mas é muito difícil mensurar precisamente o esse tempo.

Segundo ANZANELLO [1], “A curva de aprendizado apresenta-se como uma ferramenta capaz de monitorar o desempenho de trabalhadores submetidos a tarefas repetitivas”. As atividades realizadas no desenvolvimento de software não são repetitivas e a aplicação das novas tecnologias pode acontecer de formas diversas, por esse motivo torna-se complicado precisar tempos.

O mais indicado a uma empresa que busca aplicar novos conhecimentos ao seu processo de desenvolvimento de software é a busca de informações com outros que já passaram pelo mesmo processo, pois esse confronto de informações relevantes poderá servir para que se tenha uma média aproximada de tempo que auxiliará nas tomadas de decisão dos gerentes.

Controvérsia
No fato 1, a controvérsia mais comum é o descaso de muitas empresas com relação a gestão de pessoas. Mesmo que a maioria delas tenha consciência da importância da qualidade do profissional no processo, ainda preferem ignorar esse fato e privilegiar os investimentos em ferramentas e novas técnicas. A proposta do PM-CMM criado pelo SEI é muito interessante no sentido de reverter tal situação, mas ainda está longe de ser tão difundida quanto o CMM.

Em controvérsia com o fato 3, RAYMOND [6] acredita que a adição de novos programadores a um projeto não necessariamente acarretará na diminuição do ritmo da equipe. Ele fez a afirmação conhecida como Lei de Linus “Dado uma base grande o suficiente de beta-tester e co-desenvolvedores, praticamente todo problema será caracterizado rapidamente e a solução será óbvia para alguém”.

A base dessa visão de Raymond vem de uma afirmação de Brooks, que diz que se as tarefas de um projeto são divisíveis, você pode dividi-las bastante e atribuí-las as pessoas que são adicionadas ao final do projeto e tem o perfil adequado.

Investimentos feitos em melhorias do espaço, divisão e organização do ambiente de trabalho são fáceis de serem medidos, o difícil é mensurar o quanto eles trazem de lucros. Isso gera uma controvérsia ao fato 4.

Muitos defendem que o ambiente de trabalho deve ser o mais calmo e amplo possível, dando privacidade ao profissional para assim ele conseguir ter uma maior concentração em suas atividades, evitando distrações geradas por diversos fatores, dentre eles o da aglomeração de pessoas em um espaço inadequado. O Extreme Programming vai contra boa parte desses conceitos, gerando assim uma grande controvérsia.

Segundo BECK [2], o XP prega o desenvolvimento de software em comunidade, para tal, o ambiente de trabalho convencional não atende aos requisitos necessários. Para a aplicação do XP, os computadores devem ficar aglomerados em um espaço comum a toda a equipe, evitando divisórias que separem os profissionais ou disposições muito espalhada dos móveis. O objetivo disso é fazer com que a equipe interaja mais, formando duplas que programam juntas e ao mesmo tempo conseguem ver o que a dupla do lado está fazendo, para se necessário também auxiliá-las. Essa interação traz ganhos tanto na identificação e solução de erros quanto no comprometimento da equipe com o projeto.

Existe um consenso geral de que todo aprendizado tem seu custo inicial, portanto é muito difícil haver controvérsias a respeito do fato 6. As empresas devem ter consciência de que é importante adotar novas técnicas e ferramentas para assim evoluírem seus processos e terem retornos, mas não devem de forma alguma achar que esse retorno será imediato, pois de fato ele não será.
Mesmo sendo difícil mensurar quando esses retornos virão, o feedback de outros que já adotaram as mesmas tecnologias é muito importante para traçar um planejamento e fazer projeções.

Referências bibliográficas
[1] ANZANELLO, M. J.; FOGLIATTO, F. S. Curvas de aprendizado: estado da arte e perspectivas de pesquisa. Gest. Prod., São Carlos, v. 14, n. 1, abril 2007 . Disponível em: http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-530X2007000100010&lng=en&nrm=iso. Acesso em 05 Mar. 2010.

[2] BECK, K. Programação extrema explicada: acolha as mudanças. Porto Alegre: Bookman, 2004.

[3] BROOKS, Frederick P., The Mythical Man Month: Essays on Software Engineering. Addison-Wesley, 1995.

[4] CURTIS, B. A Mature View of the CMM. American Programmer, Vol. 7, No. 9, pp. 19-28, set. 1994.

[5] PRESMAN, Roger S. Engenharia de Software. 5ª edição. Rio de Janeiro: McGraw-Hill, 2002.

[6] RAYMOND, E.S. The Cathedral and Bazaar. O’Reilly Books, 1999.

[7] YILDIRIM, H. Getting the Ball Rolling: Voluntary Contributions to a Large Scale Public Project. Journal of Public Economic Theory 8, 503-528. 2006.