Extreme Programming e o Valor das Interações Sociais

Universidade de Brasília – UnB Instituto de Psicologia – IP Departamento de Psicologia Escolar e do Desenvolvimento Disciplina de Desenvolvimento Psicológico e Ensino Professora: Marisa Brito da Justa Neves Mestranda em estágio supervisionado: Cecília G. Muraro Alecrim Aluno: Charles Antônio Nascimento Costa Matrícula: 02/32301

Análise Crítica do Texto 07: Papel e Valor das Interações Sociais na Sala de Aula Claudia Davis, Maria Alice Setúbal S. e Silva, Yara Espósito

Extreme Programming e o Valor das Interações Sociais Charles A. N. Costa

Resumo Neste artigo fazemos uma correlação entre as idéias de Vygotsky, particularmente o valor das interações sociais para a aprendizagem, e a estratégia para o desenvolvimento de projetos de software conhecida por Extreme Programming – XP, proposta por Kent Beck. Pretendemos também demonstrar a relação que existe entre os processos de aprendizagem e os processos de produção industrial de software. A construção de um software como um processo de aprendizagem A atual crise de produtividade na indústria de software tem incentivado a pesquisa por estratégias que levem a um melhor aproveitamento das habilidades das pessoas envolvidas na concepção e construção de artefatos de software. De fato, cerca de 75% dos projetos de software são considerados, em algum grau, fracassados [DoD, 1994]. Uma solução para este problema precisa ser encontrada, porém, antes de tudo, precisamos entender o que acontece no desenvolvimento de um software em escala industrial. Embora possa parecer surpreendente a princípio, muitos poucos processos nesta indústria parecem-se com uma linha de produção. As atividades mais importantes na produção de software em escala industrial são aquelas que envolvem algum tipo de concepção. Embora existam padrões internacionais de processo, como o CMMI-SW [SEI], ou o SPICE [SQI], estes padrões apenas sugerem o que “deve” ser feito, mas não o “como”. O “como” envolve muito dos processos cognitivos internos de quem realiza a tarefa. A atividade de programar (escrever um texto que após traduzido para a linguagem de máquina torna-se um programa) assemelha-se mais ao artesanato do que a produção industrializada. Vejamos um exemplo: Embora muitos artesãos produzam

jarros, e um artesão durante sua vida produza vários jarros, nenhum será exatamente igual ao outro, e isto é exatamente o que se observa na atividade de escrever programas. Deixado claro o que acontece, necessitamos agora procurar os motivos para isso, já que, produzir “programas iguais” para solucionar “problemas iguais” não é teoricamente impossível. Uma boa resposta é que simplesmente não há motivação para isso. Segundo Peter Naur, “Programação não é a criação do texto de um programa tanto quanto a ciência é a criação do texto de um artigo. Enquanto a ciência está muito mais relacionada a criar teorias sobre o universo que nos rodeia, programar é sobre criar teorias quanto ao que supomos acontecer no computador” [Naur, 1992]. Levando-se este aspecto em consideração, fica claro que existe uma forte influência das motivações pessoais (pulsões, para os psicanalístas [Kupfer, 1995]) na execução destas atividades. Existem várias tentativas de explicar o surgimento destas motivações pessoais nos desenvolvedores de software. Neste artigo, destacaremos o que disse Fred Brooks [Brooks, 1995], que indicou cinco motivações específicas: 1 – A alegria crescente de se construir coisas; 2 – O prazer de produzir coisas que são úteis às pessoas; 3 – A fascinação de resolver enigmas complexos; 4 – A satisfação de estar sempre aprendendo e, finalmente, 5 – O deleite de trabalhar moldando o intangível. Parafraseando-o, o programador constrói seus castelos no ar. Estas motivações pessoais devem ser levadas em consideração quando da implantação de uma estratégia de desenvolvimento O motivo enumerado com o número 4 exemplifica de forma clara a relação entre aprendizagem e o desenvolvimento de software. Em outras palavras, para se sentir motivado o desenvolvedor, indivíduo que desenvolve um software, necessita estar constantemente aprendendo. Um outro aspecto importante no processo industrial de desenvolvimento de software é que este é inerentemente um desafio para ser vencido em grupo. Devido a complexidade dos problemas abordados várias habilidades são requeridas, sendo relativamente difícil para um indivíduo isolado atingir o objetivo explicitado na motivação 2, o de construir um software que seja útil para os seus usuários. Levando-se em consideração este aspecto coletivo e o atendimento das cinco motivações específicas, o gerente de desenvolvimento deve ter uma postura muito semelhante ao professor, no sentido de criar um ambiente propício para que a aprendizagem ocorra. Procurando uma abordagem pedagógica baseada na teoria de Vygotsky, ele poderá contribuir para a formação de um ambiente propício para interações sociais, onde as contribuições individuais são vistas como necessárias para o sucesso da equipe e do projeto [Davis, 1989]. A estratégia utilizada para construir o software, também conhecido como Processo de Desenvolvimento de Software (PDS), ou Metodologia de Desenvolvimento de Software (MDS) é um fator que pode contribuir efetivamente na criação deste ambiente propício às trocas e a aprendizagem. Neste ponto, a Extreme Programming destaca-se justamente por valorizar as interações sociais dentro da equipe de desenvolvimento, equipe esta que engloba, além dos desenvolvedores, usuários e clientes.

2

Extreme Programming Um Processo de Desenvolvimento de Software (PDS), de uma maneira bastante simplista, pode ser imaginado como um guia passo a passo, com explicações sobre algumas tarefas necessárias para aprontar um software de acordo com os parâmetros da organização que o produz. No processo de desenvolvimento de software podem estar descritos os formulários que atestam a qualidade final do produto, como devem ser preenchidos, quem os revisa, e finalmente onde deverão ser armazenados, por exemplo. Este guia deve ser de conhecimento de todos os envolvidos na produção do software, e deve estar a mão para qualquer eventualidade. É esperado que as equipes empenhadas utilizem as diretrizes ali contidas para que o produto gerado possa ser despachado para o cliente com um mínimo de surpresas. As empresas geralmente não criam os seus PDS’s a partir do nada, elas o criam personalizando instâncias mais genéricas de processos chamadas Macro-Processos. O Extreme Programming não é um guia passo a passo, é uma metodologia de desenvolvimento de software que se baseia em valores e práticas. Faz parte de uma classe de metodologias chamadas “Ágeis” [Ambler], em contraposição às metodologias tradicionais, como as que se enquadram na descrição do parágrafo anterior. O XP é baseado em premissas que são contrastantes com as que baseiam as abordagens tradicionais. Por exemplo: A crença de que a dificuldade de se fazer mudanças em um software cresce exponencialmente com o tempo. Segundo Kent Beck, o criador do XP, o fato do custo das mudanças não crescer com o tempo é uma “premissa técnica do XP” [Beck, 2000]. No entanto, a principal característica do XP é a importância dada à interação e à comunicação entre os membros da equipe de desenvolvimento para que o objetivo seja alcançado. Uma definição dada por Kent Beck para o XP é que “A Extreme Programming é uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança” [Wuestefeld]. Os valores sobre os quais o XP foi concebido são os seguintes: Simplicidade, o projeto do software é continuamente simplificado; Comunicação, os desenvolvedores devem preferir meios de comunicação que permitam que a interação seja a maior possível; Coragem, os desenvolvedores são incentivados a apontar erros no projeto e a pedir ajuda aos colegas; Retorno, tentar encontrar problemas o mais rápido possível para que estes possam ser corrigidos o mais rápido possível. Dentre as catorze práticas recomendadas1 , vamos nos concentrar naquelas que acreditamos estar mais próximas aos objetivos deste artigo, que são as baseadas no valor da Comunicação. São elas [Wuestefeld]: 

Utilizar uma metáfora. A equipe de desenvolvimento se comunica através de uma metáfora. Esta prática faz com que a teoria construída para resolver o problema seja compartilhada pela equipe.

1

Sugerimos que o leitor interessado em uma descrição mais completa das práticas consulte [Beck, 2000] e [Wuestefeld].

3

  

Programação em pares. Todas as partes do programa são escritas por duas pessoas, sentadas na frente do mesmo computador. Mover as pessoas. As duplas de programação são constantemente trocadas. Propriedade Coletiva. Ninguém na equipe precisar pedir autorização para alterar qualquer texto do programa. Toda a equipe é responsável por cada parte do programa. Não existem pedaços que são de responsabilidades de um desenvolvedor específico.

Embora os valores possam parecer óbvios, ou seja, são o que o senso comum espera que sejam os valores de qualquer equipe, as práticas enumeradas podem até ser consideradas uma afronta a razão de qualquer gerente empenhado em concluir o seu projeto dentro das expectativas e com o menor custo possível. De fato, o que a experiência têm revelado é que esta é realmente a reação que se pode esperar perante o primeiro contato com a proposta do XP 2 [McBreen, 2002]. Procuremos, de qualquer forma, entender a aflição desses gerentes. A Programação em pares soa como alocar dois para fazer o trabalho de um, já que sentados em frente ao mesmo computador, apenas um a cada vez poderá escrever as linhas de código que compõem o programa. Porém, a prática consiste em elencar pares assimétricos, de um programador mais experiente, chamado sênior, e um menos experiente, chamado júnior. A intenção é fazer com que o júnior, observando e tendo a oportunidade de interagir com o sênior, absorva parte do conhecimento acumulado com sua experiência. Mover constantemente as pessoas promovendo as trocas de pares parece anular tudo que foi ganho anteriormente, porque esta prática quebraria o entrosamento entre o sênior e o júnior. Mas aqui, a intenção é nivelar toda a equipe, fazendo com que todos interajam e troquem experiências. Isto envolve também dar ao júnior a oportunidade de ser sênior algumas vezes, e vice-versa. A prática de mover pessoas contribui de forma clara para a efetividade da última prática enumerada, a propriedade coletiva do programa, já que proporciona que o conhecimento sobre o texto do programa, a relevância de cada parte para o atendimento da solução, esteja igualmente distribuído entre todos os membros da equipe. Porém, esta prática vai contra uma outra comumente utilizada e recomendada aos gerentes que é a delegação: A divisão de responsabilidades. Com a propriedade coletiva do programa, ao invés da responsabilidade ser dividida, ela é compartilhada. Devemos, no entanto, lembrar que a intenção do XP não é produzir software com o menor custo possível, mas da forma mais previsível possível. Produzir software de forma previsível é tão importante quanto produzi-lo a baixo custo, já que dentre os 75% dos projetos que não atingem pleno sucesso, uma parcela considerável é levada ao fracasso por não conseguir atingir os objetivos no prazo. Vygotsky e o Extreme Programming

2

Um fato interessante, é que geralmente o XP cresce dentro da organização no sentido inverso da cadeia de comando, onde subordinados tentam convencer seus gerentes sobre as vantagens e a efetividade da metodologia do XP.

4

Retornando a tese do processo de produção de software como um processo de aprendizagem, devemos procurar as relações entre os valores e as práticas sugeridas pelo XP e alguma teoria pedagógica. Escolhemos Vygotsky devido à importância das interações sociais na sua teoria, em consonância com os valores e as práticas do XP. Para Vygotsky, a apropriação do conhecimento envolve dois processos distintos, a interação, que ocorre no âmbito das relações interpessoais, e a interiorização, onde a manifestação da interação é reconstruída internamente. Na teoria de Vygotsky, o desenvolvimento das funções cognitivas superiores nos humanos é modulado através das interações sociais por intermédio da linguagem. Assim sendo, o desenvolvimento da cognição na criança não acontece por si só, como na teoria da maturação de Piaget, mas na medida em que é utilizada [Davis, 1989]. Vygotsky argumenta que a construção do conhecimento humano é um processo coletivo, onde a linguagem desempenha um papel fundamental. Para ele, a voz humana diferencia-se dos sons emitidos por outros animais pelo seu poder de comunicar um conceito ou emoção, em outras palavras, o som da voz humana, mesmo quando não é o som de uma palavra, como o de um grito, tem o poder de contagiar a pessoa que a escuta, o que não aconteceria se o mesmo som tivesse partido de um ganso [Vygotsky, 1987]. Em consonância com essas idéias de Vygotsky, mas de forma independente, Naur [Naur, 1992] explica que a criação de um software é um processo de concepção de uma teoria, teoria esta que é interiorizada pela equipe de desenvolvimento, e que é difícil explicá-la para outras equipes sem que haja interação social. Naur afirma que um programa morre quando a equipe que o criou é dissolvida, porque com sua dissolução é perdida a teoria que foi desenvolvida para construí-lo, e um programa revive quando sua teoria é reconstruída por outra equipe. Mesmo quando extensa documentação está disponível, torna-se difícil continuar o desenvolvimento de um programa sem que haja a assistência de membros da equipe original. Um dos sintomas mais claros que apontam quando um programa está morto é quando novas funcionalidades não podem mais ser inseridas em um programa antigo de forma rápida e inteligente. Imagine que uma equipe, que denominamos A, tem de desenvolver uma nova versão de um programa desenvolvido pela equipe B. Toda a documentação necessária, inclusive linhas e mais linhas de texto do programa estão disponíveis para a nova equipe. Por que é tão difícil para a equipe A continuar o trabalho? A nossa explicação é que a equipe A precisa ser contaminada pela teoria construída pela equipe B, e a única forma disso acontecer é através de alguma interação social. De outra forma, restará para A apenas a alternativa de construir uma nova teoria. Acreditamos que as práticas sugeridas pelo XP, notadamente as quatro práticas explicadas anteriormente neste artigo, são um meio eficiente de promover a interação social necessária para a construção de um software, porque criam um ambiente propício para que a teoria do programa cresça e seja disseminada. A criação de uma metáfora fornece a possibilidade dos desenvolvedores se comunicarem com os usuários e clientes de forma clara, sem a utilização de termos técnicos, inerentes aos meios usuais dos programadores e também dos usuários, além de

5

propiciar uma forma simples de transmitir verbalmente a essência da teoria do programa. A programação em pares é interessante, pois Vygotsky afirma que o desempenho de um indivíduo na realização de uma tarefa tem dois patamares diferentes: Um é o que ele pode fazer sozinho, representa o desenvolvimento já aprendido e internalizado; O outro é o que ele pode fazer quando auxiliado por indivíduos mais experientes. Este último Vygotsky chama de desenvolvimento potencial. Esta é a razão principal para se escalarem pares assimétricos, com um programador sênior e um júnior. Mover as pessoas permite que as interações aconteçam de forma mais homogênea e intensa, contribuindo para que o efeito da programação em pares seja maximizado, promovendo igualdade de oportunidades na formulação da teoria do programa. Esta igualdade de oportunidades é expressa através da propriedade coletiva, porque sustenta a idéia de que as contribuições de todos são importantes e necessárias para se atingir o objetivo comum. Conclusão Vários autores vêm levantando e discutindo a importância de fatores subjetivos na construção de software, como Brooks e Naur. Acreditamos que essas proposições são verdadeiras, especialmente quando discutimos seus efeitos em equipes pequenas. Não queremos aqui, diminuir o valor dos processos formais de desenvolvimento, mas destacar que a construção do software é um processo mutuamente de construção e aprendizagem, seja quando falamos da construção de um software novo, seja da manutenção de um software existente. O Extreme Programming é uma estratégia de desenvolvimento que vem atraindo o interesse dos desenvolvedores, principalmente aqueles dos níveis mais operacionais. Um dos aspectos do XP que nos chamou mais a atenção foi a sua congruência com relação à abordagem de Vygotsky, através da construção e transmissão do conhecimento de forma social, representando um grande diferencial em relação aos processos tradicionais. Acreditamos que esse estreitamento entre o XP e as teorias pedagógicas seja uma característica favorável a sua adoção, pois é uma evidência de que existem no XP elementos alicerçados nas teorias do desenvolvimento humano. Elementos estes que levam em consideração os aspectos subjetivos de realização e motivação dos desenvolvedores, difíceis de englobar em abordagens meramente tecnológicas. Bibliografia Ambler. Ambler, Scott W. “What is Agile Modeling (AM)?”. Site: http://www.agilemodeling.com. Beck, 2000. Beck, Kent. “Extreme Programming Explained”, pp.21-25. Boston: Addison-Wesley, 2000.

6

Brooks, 1995. Brooks Jr., Frederick P., “The Mythical Man-Month: Essays on Software Engineering”, Addison-Weslley, 1995. Davis, 1989. Davis, Claudia e Maria Alice Setúbal S. e Silva, Yara Espósito, “Papel e Valor das Interações Sociais em Sala de Aula”, pp.49-54 in Cad. Pesquisa, São Paulo, 1989. DoD, 1994. Software Development and Documentation: ML-STD-498, 1994 DTI, and NCC, The STARTS Guide, NCC Publications, 1987. Kupfer, 1995. Kupfer, Maria Cristina Machado. “Freud e a Educação”, Scipione, 1995. Naur, 1992. Naur, P., “Programming as Theory Building”, pp.37-48 in Computing: A Human Activity, ACM Press, 1992. McBreen, 2002. McBreen, Pete. “Questioning Extreme Programming”. Boston: Addison-Wesley, 2002. SEI. Software Engineering Institute, Carnegie Mellon University. Capability Maturity Model for Software (SW-CMM). Site: www.sei.cmu.edu/cmm. SQI. Software Quality Institute, Griffith University. Site: http://www.sqi.gu.edu.au/spice/. Vygotsky, 1987. Vygostky, L. S. “Collected Works of L. S. Vygotsky. Volume I, Problems of General Psichology, Thinking and Speech”. Editado por Robert W. Rieber e Aaron S. Carton. New York, Plenun Press. 1987. Wuestefeld. Wuestefeld, Klaus. Site: www.xispe.com.br.

7