Fatos e Falácias de Engenharia de Software - Reutilização

Após quase um mês sem atualizações aqui, estou voltando a postar continuando a seqüência de temas relacionados a Engenharia de Software. Nessa postagem irei abordar um tema que muito me agrada e que tem relação indireta com minha pesquisa: Reutilização no processo de desenvolvimento do software.

Digo que tem relação indireta pois minha pesquisa envolve bastante sobre Padrões de Análise, que basicamente proporciona reutilização conceitual no processo de software, enquanto que na discussão dessa postagem irei abordar mais especificamente a reutilização de código.

Futuramente estarei postando também sobre Padrões de Análise por aqui, mas enquanto isso vamos ao nosso texto de hoje.

Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 622 - Engenharia de Software
Resumo no. 03

Fatos
15 - Reutilização em pequena proporção (bibliotecas de sub-rotinas) começou há quase 50 anos e é um problema bem resolvido.
16 - Reutilização em grande proporção (componentes) continua sendo um problema na maior parte não resolvido, embora todos concordem que é importante e desejável.
17 - Reutilização em grande proporção funciona melhor nas famílias de sistemas conexos e, portanto, é dependente do domínio. Isso restringe a aplicabilidade potencial desse tipo de reutilização.

Discussão
Ambos os fatos estudados tratam da Reutilização, sendo que cada um deles aborda o tópico por visões distintas. Atualmente muito se fala em reutilização de código, sendo que muitos tratam dessa técnica como se ela fosse novidade. O próprio paradigma de programação orientada a objetos coloca a reutilização como uma das suas grandes inovações. O fato 15 mostra que na verdade Reutilização de código é um conceito que surgiu na década de 50 com a Organização Share [1]. A proposta da Organização Share foi a de criar um espaço semelhante a uma biblioteca tradicional, porém lá ao invés de livros, os programadores compartilhavam códigos de programação de uso freqüente, e sempre que precisavam implementar algo que achavam que alguém poderia já ter feito antes, consultavam a biblioteca de códigos para evitar o retrabalho. Dentre esses códigos de uso comum que eram compartilhados, são exemplos funções para realização de operação matemáticas, funções de ordenação e busca de valores.

Com o passar dos anos a idéia de reutilização em pequenas proporções tornou-se muito difundida e ficou claro que isso agiliza muito o desenvolvimento. A maioria das linguagens mais utilizadas atualmente possui vastas bibliotecas de códigos definidos para diversos domínios comuns, como por exemplo, as conexões com os variados tipos de SGBDs.

As bibliotecas das linguagens geralmente possuem funções que já foram exaustivamente testadas e amplamente utilizadas, passando assim um alto grau de confiabilidade. Portanto é muito mais eficiente em termos de agilidade na implementação e até mesmo de segurança (dependendo do domínio), utilizar funções pré-definidas nas bibliotecas do que ter o trabalho de fazer algo já existente.

O fato 16 trata da reutilização de código em grandes proporções, a chamada engenharia de software baseada em componentes. Essa proposta prega que softwares podem ser montadas unicamente a partir de união de “peças” já existentes (componentes), escolhidos mediante a especificação dos requisitos. Essa idéia nos leva a pensar em uma verdadeira linha de montagem de software, porém na prática isso não acontece exatamente assim.

Essa idéia de reutilização de componentes (reutilização de códigos em grande proporção) também não é nova, mas ao contrário da reutilização de bibliotecas de sub-rotinas comuns (reutilização de códigos em pequena proporção), ela nunca se tornou algo utilizado em grande escala. A discussão do fato 16 é basicamente a respeito do motivo pelo qual isso nunca aconteceu, mesmo sabendo-se que na teoria é algo que traria avanços significativos de produtividade no processo de desenvolvimento de software.

O problema maior da criação de componentes reutilizáveis, é que eles devem ser genéricos o suficiente para atender a qualquer domínio. Porém há grandes diferenças de exceções entre os domínios. Embora alguns problemas grandes quando analisados superficialmente possam parecer semelhantes, há uma série de restrições para as possíveis soluções quando analisamos os mesmos problemas em domínios diferentes.

O fato 17 trata de algo extremamente realista e menos utópico que a reutilização de componentes totalmente genéricos. A grande barreira que impede a disseminação da reutilização em grandes proporções são as sutilezas que diferem os domínios. Elas dificultam muito na criação de componentes genéricos que atendam a todos os domínios de forma eficiente. Porém quando se trata de componentes aplicados a um mesmo domínio de problemas, a chance de sucesso aumenta consideravelmente [4].

Os estudos realizados pelo Software Engineering Laboratory (SEL), da NASA-Goddard [2] exemplificam bem essa afirmação, haja vista que 70% dos softwares desenvolvidos por eles dentro do domínio específico de dinâmica de vôos reutilizaram componentes com sucesso.

Grandes empresas como a Microsoft utilizam desses conceitos em seus softwares principais. Plataformas como o pacote Office e o sistema operacional Windows, são desenvolvidas atualmente reutilizando-se de diversos componentes que foram sendo implementados pela empresa ao decorrer dos anos. A cada nova versão, grande parte dos componentes anteriores é reutilizada e inovações são acrescentadas, gerando assim novos componentes que serão reutilizados posteriormente.

Esse processo de reutilização também torna o processo de desenvolvimento de uma empresa cada vez mais maduro, montando uma espécie de linha de montagem de software, mas é importante observar que o domínio de aplicação desses componentes acaba sendo bem restrito para alcançar tal eficiência na sua aplicação.

Controvérsia
A principal controvérsia do fato 15 é relacionada ao desconhecimento da história da reutilização. Principalmente após a difusão do paradigma de programação orientada a objetos, muito começou a se falar sobre reutilização de código como uma grande inovação. O conceito de reutilização de código não é novo como muitos entusiastas imaginam e já existia muito antes de orientação a objetos por exemplo.

Existem muitas controvérsias entre as tentativas de explicações para o fato 16. Enquanto alguns vêem a engenharia de software baseada em componentes como o futuro, outros são completamente céticos com relação a sua aplicação real.

O NASA's Goddard Space Flight Center [2] realizou durante anos estudos relacionado ao desenvolvimento de softwares específicos baseados em componentes. Cerca de 70% dos softwares desenvolvidos dentro do domínio de atuação do NASA-Goddard foram construídos com reutilização de componentes, um número alto, mas que não pode ser interpretado de qualquer maneira. A eficiência da reutilização de componentes nesse caso foi devido à semelhança real dos softwares. Softwares de um mesmo domínio tendem a terem restrições semelhantes, portanto a generalização eficiente dos componentes fica facilitada.

Outro motivo levantado para a possível não adoção em massa da reutilização em grande proporção, é a chamada síndrome do “Não-Inventado-Aqui” (NIH em inglês). Essa síndrome seria comum a profissionais teimosos que acreditam ser mais complicado administrar algo não criado por eles mesmos.

De uma maneira geral, não se pode afirmar que a engenharia de software baseada em componentes é boa ou ruim, para isso é necessário analisar o contexto. Devido às diferenças entre os diversos domínios, é muito complicado que a criação de componentes totalmente genéricos seja eficiente para aplicação em todos os casos, mas em casos específicos eles podem ser extremamente eficientes. Muitos autores, assim como GLASS [3], acreditam que a reutilização de código em grandes proporções não chegará a ser tão difundida e comum quanto a de pequenas proporções, mas essa visão embasa-se na sua complexidade e não na qualidade da proposta.

As controvérsias ao fato 17 são referentes às pessoas entusiastas da reutilização em grandes proporções da forma mais genérica possível, abrangendo a domínios de qualquer espécie. Essas pessoas acabam tendo esse tipo de visão por desconhecerem as diferenças entre os domínios, pois essas diferenças impossibilitam uma maior eficiência na resolução de problemas comuns a domínios distintos utilizando componentes totalmente genéricos.

Referências Bibliográfica

[1] SHARE Inc. About SHARE. Disponível em: http://www.share.org/AboutSHARE/tabid/65/Default.aspx Acesso em 10 Abr. 2010.

[2] NASA-Goddard Space Flight Center. About the Goddard Space Flight Center. Disponível em: http://www.nasa.gov/centers/goddard/about/index.html Acesso em 10 Abr. 2010.

[3] GLASS, R. Facts and Fallacies of Software Engineering. Addison Wesley. October 2002.

[4] McBREEN, Pete. Software Craftsmanship. Boston: Addison-Wesley. Says "cross-project reuse is very hard to achieve." 2002.

SCRUM + Customização de Processos

Segunda-feira (21/03/2011) tive o prazer de proferir uma espécie de palestra para a turma de Engenharia de Software do mestrado em Ciência da Computação da UFV a convite do professor José Luis Braga. Nessa palestra abordei métodos ágeis e customização de processo de software utilizando especificamente SCRUM + RUP + Parte do MPS.br nível G.

Mesmo para quem não assistiu a apresentação, vale muito a pena dar uma olhada no material disponibilizado abaixo com calma pois ele é bem auto-explicativo e abrange principalmente o SCRUM de maneira ampla. Em caso de dúvidas, sugestões, críticas...etc, comentem por ai pessoal.

Scrum + Customização de Processos

View more presentations from Lucas Vegi

Fatos e Falácias de Engenharia de Software - Estimativas de projetos de software

Dando continuidade a seqüencia de postagens sobre temas polêmicos em engenharia de software, o tema da discussão dessa postagem será: Estimativas de projetos de software.

É impressionante como essa parte fundamental do processo de desenvolvimento de software ainda hoje seja realizada de maneira tão errônea e que sofra com influências tão negativas quanto às discutidas nesse resumo.

Caso alguém já tenha sentido na pele algum desses fatores negativos e queira compartilhar essa experiência ruim para enriquecer nossa discussão, não deixe de comentar.

Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 622 - Engenharia de Software
Resumo nº 2

Fatos Estudados
09 - A maioria das estimativas de software são realizadas no início do ciclo de vida. Isso faz sentido, até que percebemos que as estimativas são obtidas antes dos requisitos serem definidos e, portanto, antes do problema ser compreendido. Estimativa, portanto, ocorre geralmente na hora errada.
10 - A maioria das estimativas de software são feitas tanto pela alta gerência ou pelo marketing, não pelos profissionais que irão construir o software ou os seus gestores. Estimativa é, portanto, feita por pessoas erradas.
11 - Estimativas de software raramente são ajustadas conforme o andamento do projeto. Assim sendo, as estimativas feitas no momento errado, por pessoas erradas, geralmente não são corrigidas.

Discussão
Os fatos estudados analisam alguns problemas relacionados às estimativas de projetos de software. O nono fato trata do momento do processo de software em que as estimativas são traçadas. Ele apresenta um problema que pode soar absurdo nos dias de hoje, mas que na prática acontece em alguns projetos. Algumas equipes traçam as estimativas de tempo e custos de um projeto de software previamente ao levantamento de requisitos, algo que é completamente inaceitável, se considerarmos as melhores práticas de gestão de projetos de software. Após o levantamento e análise dos requisitos é que o problema a ser resolvido pelo projeto começa a ser realmente entendido, portanto, fazer estimativas antes na análise de requisitos é como dar um tiro no escuro, pois dificilmente a equipe terá argumentos sólidos onde se basear neste ponto de partida do ciclo de vida.

Segundo MARÇAL [2], em projetos gerenciados por Scrum, o cronograma é extraído do Product Backlog, sendo que as estimativas são feitas em dois níveis. Primeiro em alto nível, analisando cada requisito do Product Backlog para assim obter-se uma visibilidade geral do projeto e durante o processo são feitas estimativas de cada Sprint Backlog, oferecendo dessa forma uma visibilidade mais precisa de cada iteração.

O décimo fato é diretamente relacionado ao nono. Muitas das vezes as estimativas são traçadas no momento errado porque as pessoas responsáveis por elas também eram inapropriadas para tal. A alta gerência e/ou os responsáveis pelo marketing, na maioria das vezes não tem uma visão bem definida ou entendimento suficiente sobre qual é a importância dos requisitos e muito menos em como a alteração deles pode impactar sobre as estimativas do projeto todo. Sendo assim, ao invés dos profissionais de software (analistas, programadores, etc) serem os encarregados por traçarem as estimativas, baseando-se nos requisitos, dados históricos e outros fatores relevantes, quem acaba traçando as estimativas ao cliente são a alta gerencia e o marketing, pessoas geralmente desqualificadas para realizar tal tarefa. Por esse motivo essas pessoas acabam fazendo-a de forma errônea, geralmente considerando muito mais o desejo em detrimento ao que seria realmente possível.

Embora possa parecer absurdo que softwares profissionais sejam concebidos a partir de estimativas errôneas realizadas por pessoas inadequadas, os autores do estudo de CASE [1] mostram que impressionantes 70% dos softwares são concebidos dessa forma, com estimativas sendo definidas pelos usuários (clientes) e apenas 4% das estimativas são realizadas pela equipe do projeto.

O fato 11 relaciona-se aos dois anteriores, acrescentando ainda mais acontecimentos que fogem ao padrão. Considerando que as estimativas são geralmente traçadas no momento errado e por pessoas inapropriadas, o resultado final só poderia ser um projeto mal estimado e que não atende à realidade, porém, por incrível que pareça, a alta gerência além de traçar suas estimativas erroneamente, ignorando fatores como a complexidade do projeto e o custo real para atender aos requisitos, dificilmente ela permite mudanças de cronograma, obrigando assim a equipe de desenvolvimento a trabalhar o quanto for necessário para atender aos seus desejos.

Controvérsia
Dificilmente alguém conseguirá apresentar uma controvérsia ao nono fato, haja vista que antes de detalhar o que será desenvolvido, o risco de traçar uma estimativa errada é muito alto e pode ser determinante para um projeto fracassar. Mesmo em equipes que já possuem ampla experiência em diversos tipos de projetos, traçar uma estimativa analisando superficialmente um problema e comparando-o a outros projetos “semelhantes” já realizados pela equipe é algo perigoso, pois mesmo que exista muitos pontos em comum entre eles, os pequenos pontos que divergem podem impactar em vários outros, gerando assim um “efeito dominó” que impossibilita a precisão dessa estimativa por comparação superficial de semelhanças.

Controvérsias para o décimo fato também são difíceis de serem citadas, pois é claro que para traçar estimativas de software, precisa-se ter conhecimento de causa e basear-se e referências concretas a fim de dar uma visibilidade mais precisa do projeto, e somente as pessoas ligadas diretamente a ele (programadores, analistas, etc) tem essa capacidade. Tanto a alta gerência quanto o marketing, geralmente só são capazes de traçar estimativas baseadas nos negócios, nos desejos comerciais e não no processo em si.

Geralmente as estimativas traçadas pela alta gerência são motivos de discórdia entre os membros da equipe de desenvolvimento, porém quando a equipe é questionada pela alta gerência sobre o que daria pra ser feito no tempo estimado, freqüentemente essa resposta não é dada com precisão pela equipe, o que acaba gerando desconfiança na alta gerência sobre a capacidade da equipe traçar estimativas, entretanto isso é um erro. Possivelmente as equipes têm dificuldade em dar precisão para a alta gerencia sobre o que seria capaz de fazer em determinado tempo devido a esse questionamento ser feito em momento inoportuno, como por exemplo, antes do conhecimento detalhado dos requisitos.

A controvérsia ao fato 11 chega a ser injusta. As estimativas traçadas no momento errado e por pessoas erradas tendem a gerar cronogramas impossíveis de serem cumpridos a risca, pois como eles são feitos considerando geralmente apenas o desejo da gerencia e não a complexidade real do problema a ser resolvido e os prazos previstos, na maioria das vezes acabam não sendo cumpridos e custos adicionais podem ser gerados por esse descumprimento. A culpa principal desses acontecimentos é dos responsáveis pelo estabelecimento das estimativas (alta gerência ou marketing), porém quem realmente leva a culpa é a equipe, que na verdade é a maior vítima de toda a situação.

Analisando os fatos apresentados de forma ampla, percebe-se que existem poucas controvérsias a respeito deles, isso é ocasionado devido ao consenso geral no qual eles estão inseridos. Todos os profissionais de software sabem na realidade quem deve fazer as estimativas dos projetos, o que deve ser levado em consideração para tal, quando as estimativas devem ser traçadas e no caso de falhas ao estimar, medidas corretivas devem ser tomadas no cronograma e informadas aos stakeholders. Infelizmente na prática essas questões não são respeitadas devido a políticas empresariais internas pouco evoluídas.

Referências bibliográficas
[1] CASE. "CASE/CASM Industry Survey Report." HCS, Inc., P.O. Box 40770, Portland, OR 97240. 1991.

[2] MARÇAL, Ana Sofia; FREITAS, Bruno Celso C.; FURTADO, Felipe; MACIEL, Teresa; BELCHIOR, Arnaldo Dias. Estendendo o SCRUM segundo as áreas de processo de gerenciamento de projetos do CMMI. 2007 Disponível em: http://www.cesar.org.br/files/file/SCRUMxCMMI-CLEI-2007.pdf. Acesso em 27 mar. 2010.

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.