teorico 3

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

<p>Conteudista: Prof. Me. Erwin Alexander Uhlmann</p><p>Revisão Textual: Esp. Pérola Damasceno</p><p>Objetivos da Unidade:</p><p>Adquirir conhecimento para compreender, planejar e implantar a eXtreme</p><p>Programming em sua organização;</p><p>Capacitar a participação nos times de desenvolvimento, testes, rastreadores,</p><p>observadores e gerentes, com propriedade tal que permita alcançar o sucesso do</p><p>programa, sem, no entanto, esgotar o assunto ou aprofundar a ponto de</p><p>pesquisa científica crítica que torne o texto denso e exija um tempo maior do</p><p>que necessário à compreensão do método.</p><p>˨ Material Teórico</p><p>˨ Material Complementar</p><p>˨ Referências</p><p>Introdução ao eXtreme Programming</p><p>Introdução</p><p>O manifesto Ágil teve diversos signatários, ou seja, como vimos anteriormente,</p><p>desenvolvedores, gerentes de engenharia de software de grandes empresas desenvolvedoras,</p><p>que se reuniram e discutiram o que poderia ser feito para tornar o processo de desenvolvimento</p><p>mais ágil. Deste encontro cada um de seus participantes teve uma ideia que se adaptava de forma</p><p>mais adequada sobre o que foi discutido e o que poderia ser feito na própria organização. Como</p><p>premissa do movimento, a adaptação ao ambiente. O Scrum foi uma das metodologias</p><p>desenvolvidas para um ambiente e agora iremos estudar outra adaptação: eXtreme Programming,</p><p>ou simplesmente XP.</p><p>O XP teve como princípio encantar o cliente com entregas rápidas e parciais que permitem a</p><p>vivência dele ao que será entregue e, com isto, as solicitações de adaptações, que antes eram</p><p>temidas, caras e demoradas de serem resolvidas e entregues, agora são rápidas e simples,</p><p>justamente pelo fato de serem feitas durante o avanço das etapas seguintes. Com este ciclo de</p><p>desenvolvimento curto (de uma a duas semanas) e a minimização de reuniões e documentos</p><p>que explicam longamente todos os aspectos esperados do software (antes completo), o tempo e</p><p>a energia dedicada ficam focados justamente no objeto de entrega: a codificação do sistema, de</p><p>onde vem o nome de programação extrema, ou seja, minimize tudo, maximize a programação.</p><p>Como a visão do XP é o encantamento do cliente, a compreensão do esperado e a codificação são</p><p>facilitados, pois aumenta a eficiência da entrega. Como assim, aumenta a eficiência da entrega?</p><p>Se em uma reunião de coleta de requisitos o cliente, com um processo de mil páginas, decide</p><p>entregar, muitas funções, segundo Sommerville – para quem já estudou a disciplina de</p><p>Engenharia de Software – necessitam de análise da completeza e da consistência, isto é, uma</p><p>1 / 3</p><p>˨ Material Teórico</p><p>função precisa descrever completamente o que irá realizar, por exemplo: o campo de gravação</p><p>do nome do usuário tem como completeza o nome “name”, o tamanho de interface de 50</p><p>colunas, o comprimento no banco de dados de 100 caracteres do tipo varchar e ter como regra de</p><p>negócio impedir abreviações. Só neste ponto a compreensão deve ser total, e estamos tratando</p><p>apenas do item nº 1 da seção “cadastro”, que tem várias páginas das mil a serem estudadas.</p><p>A consistência talvez seja o item mais complexo, pois em toda a documentação que se refira ao</p><p>campo “nome”, seja na interface, na regra de negócio ou mesmo no banco de dados, nenhuma</p><p>vez a completeza pode ser diferente ou conflitante com o já estabelecido. Por isso, consistência.</p><p>As definições devem ser bem compreendidas e todas as funções em sua completeza devem ser</p><p>verificadas com todas outras para procurar inconsistências! Não podemos chamar de</p><p>propriamente ágil.</p><p>Neste formato opus citatus (op. cit.), anteriormente citado, o cliente entregava os requisitos, e a</p><p>empresa, depois de produzir, entregava. Qualquer alteração era um fato gerador de estresse em</p><p>todos. O cliente com novos prazos e custos, o gerente com os prazos de outros softwares a</p><p>desenvolver e a equipe que deveria refazer parte do código. Com o XP, as entregas rápidas</p><p>garantem a plasticidade desejada pelo cliente, o gerente minimiza o tempo de produção e a</p><p>equipe reduz a refatoração de códigos.</p><p>Outro ponto importante é o método de desenvolvimento que a equipe passa a marcar todos os</p><p>pontos históricos de desenvolvimento realizando a regressão para facilitar os testes, assim, ao</p><p>desenvolver o cadastro do usuário no sistema, a versão inicial entregue, quando alterada, tem</p><p>seus pontos sinalizados para que a equipe de teste inicie os testes da última versão para a</p><p>primeira, entendendo que em determinado momento os pontos A, B e C, por exemplo, foram</p><p>alterados. Isto facilita o teste e a eventual necessidade de correções.</p><p>Ciclos Curtos</p><p>Equipes com até doze pessoas e entregas constantes para o cliente o envolvem no projeto. Desta</p><p>forma, mesmo que o prazo de entrega já seja definido, a incerteza de conclusão em tempo</p><p>corresponsabiliza o cliente e o coloca sempre a par do que está sendo desenvolvido, do ponto de</p><p>maturidade do software. Eventuais adaptações no calendário são fáceis de negociar ou mesmo</p><p>alterações são evitadas a fim de se cumprir o calendário.</p><p>Saiba Mais</p><p>Como no XP os ciclos de entrega são curtos, durante o</p><p>desenvolvimento os programadores criam as funções já verificando o</p><p>correto funcionamento. Isto minimiza a necessidade de testes mais</p><p>básicos, como se o campo X ou Y estão funcionando. Sim, eles estarão,</p><p>pois a equipe desenvolveu em funcionamento. Caso ocorra algum erro</p><p>nos testes sistêmicos, a equipe identifica rapidamente o ponto de falha,</p><p>pois ciclos curtos produzem funções menores ou até mesmo poucas</p><p>funções.</p><p>Valores</p><p>Um dos principais desafios de se implantar uma metodologia ágil nas organizações é a</p><p>redefinição dos processos já estabelecidos. Comumente com “isto sempre foi assim...”, “não</p><p>inventa moda...”, “ninguém vai querer...” entre outras frases que pouco ou nada explicam a</p><p>razão de se manter o status quo. Mudar procedimentos é um complicador; mudar hábitos é o</p><p>desafio.</p><p>O grande fator de sucesso na implantação é a adaptação do ambiente organizacional, da cultura e</p><p>dos processos aos valores do XP.</p><p>Saiba Mais</p><p>No clássico artigo de Frederick Brooks, No Silver Bullet, o autor lembra</p><p>que software não pesa, nem se acomoda em uma caixa, e o cliente</p><p>interage apenas com um botão, indiferente ao tamanho, complexidade</p><p>da lógica e do tempo de desenvolvimento. Com o XP, o cliente passa a</p><p>ter maior contato com a complexidade e a dificuldade de se obter o</p><p>resultado desejado, assim, o software deixa de ser apenas botões e</p><p>interface.</p><p>Figura 1 – Valores do XP</p><p>Simplicidade</p><p>O método XP emprega que se elenque funções por ordem de complexidade. Os itens mais</p><p>simples e de entregas mais rápidas em primeiro lugar os mais complexos ou demorados para</p><p>depois. Desta forma, os desenvolvedores começarão a trabalhar em códigos simples e, aos</p><p>poucos, as funções são criadas, podendo, eventualmente, ajudar em itens mais complexos.</p><p>Por outro lado, não se deve desenvolver funções, planejar ações futuras ou itens que poderão ser</p><p>úteis. Simplicidade. Como um dos principais focos do XP é o desenvolvimento de aplicações, que</p><p>ficam sob constante mudança, itens futuros poderão ser sumariamente ignorados ou</p><p>inutilizados por uma mudança no decurso do desenvolvimento.</p><p>Exemplo: dois departamentos requisitam o desenvolvimento de três funções num aplicativo</p><p>para celulares: o visualizador de holerites para cada funcionário (ele deve estar ativo na</p><p>empresa), um sistema de planejamento de férias, e o departamento de marketing solicitou o</p><p>desenvolvimento de um sistema de interação com seus clientes, em que eles poderiam fazer o</p><p>upload de fotos com frases e sempre autenticados pelo sistema interno, que verifica se eles</p><p>existem no cadastro. Qual deles deve ser feito primeiro? Qual o mais importante? Quais as datas</p><p>de entrega?</p><p>O sistema de holerites é o mais simples de todos, logo, o primeiro a ser entregue; o sistema</p><p>solicitado pelo marketing possui menos funções do que o sistema de férias (solicitado pelo RH),</p><p>ganhou o segundo lugar, e o último é o sistema de férias.</p><p>Comunicação</p><p>Desde o início do projeto a comunicação é fundamental,</p>
<p>não apenas por ser um método Ágil,</p><p>mas este é um dos grandes calcanhares das empresas. Todos os envolvidos foram avisados?</p><p>Todos devem participar das reuniões – que são diárias e rápidas – e a conversa deve ser</p><p>amplamente incentivada. Todos devem conhecer o objetivo do projeto, quem solicitou, para</p><p>quando, quais são os envolvidos, recursos, requisitos, status de desenvolvimento,</p><p>impedimentos, premissas e problemas.</p><p>Os problemas devem ser compartilhados com todos para que a solução seja resolvida na própria</p><p>reunião. As premissas são verdades assumidas como reais, ou seja, as pessoas assumem que</p><p>aqueles fatos estão no estado estabelecido por não ter tal informação. Complicado?</p><p>Exemplo: assumamos a premissa de que o sistema operacional do servidor do cliente é Linux.</p><p>Desta forma, os desenvolvedores assumem este fato de que o sistema operacional do servidor</p><p>esteja estabelecido como Linux.</p><p>Ok, e se não for Linux?!</p><p>Bem, diante da desinformação, este fato é colocado como verdade para permitir o</p><p>desenvolvimento, mas, caso não seja, o problema deve ser passado ao cliente. É claro que apenas</p><p>itens externos ao projeto podem ser transmitidos ao cliente.</p><p>Ex.: naqueles três projetos do aplicativo da empresa, dos holerites, o sistema de férias e o de</p><p>upload de fotos, os desenvolvedores devem conversar com o pessoal de interface, estar</p><p>presentes nos requisitos, com o pessoal de teste, marketing e RH, em todas as reuniões.</p><p>Feedback (Retorno)</p><p>Durantes as reuniões diárias, além da comunicação, o objetivo é o retorno a todos e</p><p>principalmente ao cliente. O feedback é fundamental para que o status do projeto seja</p><p>demonstrado e as iterações sejam realizadas. Veja que são “iterações”, não “interações”. Iterar é</p><p>acrescentar novas funcionalidades; alterar o projeto durante a execução quando novas</p><p>possibilidades são percebidas a partir das entregas realizadas.</p><p>Em fato, a realidade das organizações muda de tal forma e com velocidade, que os requisitos são</p><p>alterados e o desenvolvimento precisa acompanhar tais necessidades. O desafio aparece quando,</p><p>em um dos retornos, uma funcionalidade existente deixa de ser necessária e parte do tempo de</p><p>desenvolvimento, necessário para a conclusão do projeto como um todo, acaba desperdiçado.</p><p>Para o feedback adequado é preciso demonstrar o estado anterior e o atual, os requisitos da</p><p>última reunião e o teste com os resultados obtidos, sempre tudo anotado.</p><p>Exemplo: naqueles três projetos do aplicativo, holerite, férias e upload no site, após uma semana</p><p>de trabalho a equipe de desenvolvimento entregou o sistema de holerites com a leitura individual</p><p>dos arquivos e download. O cliente, no entanto, avisou que a lei sofreu uma alteração e os</p><p>holerites deveriam ser disponibilizados sempre em formato de folha contínua, anual com o</p><p>histórico de horários de entrada e saída, o ponto. O solicitado e entregue era apenas o holerite,</p><p>mas a lei mudou tudo. Se este retorno não fosse dado, o sistema seria entregue com um ponto já</p><p>por modificar.</p><p>Coragem</p><p>Mudanças acontecem, previstas ou não, por motivos internos ou externos, até mesmo por</p><p>erros. Em muitas situações as pessoas acabam ocultando os erros, postergando o aviso da</p><p>mudança de requisitos ou inativações de funções. Por outro lado, informar atrasos no</p><p>desenvolvimento ou falhas também podem trazer os mesmos problemas.</p><p>Informar à equipe ou ao cliente o quanto antes é o melhor ato. O desenvolvedor do XP, Kent</p><p>Beck, propõe sempre uma “ação efetiva diante do medo”, isto é, diante da diversidade, das</p><p>mudanças, falhas, criar um plano de ação para corrigir o rumo do projeto.</p><p>Para Beck e Fowler (2001) apud Teles (2005, p. 52), os clientes temem:</p><p>Desenvolvedores, por sua vez, temem:</p><p>Não obter o que pediram;</p><p>Pedir a coisa errada;</p><p>Pagar demais por muito pouco;</p><p>Jamais ver um plano relevante;</p><p>Não saber o que está acontecendo;</p><p>Fixarem-se em suas primeiras decisões e não serem capazes de reagir a</p><p>mudanças nos negócios.</p><p>Ser solicitados a fazer mais do que sabem fazer;</p><p>Ser ordenados a fazer coisas que não fazem sentido;</p><p>Ficar para trás tecnicamente;</p><p>Receber responsabilidades, sem autoridade;</p><p>Não receber definições claras sobre o que precisa ser feito;</p><p>Sacrificar a qualidade em função de prazo;</p><p>Os atrasos são os motivos mais comuns no desenvolvimento dos projetos e, na maioria dos</p><p>casos, a falha no cálculo do tempo de desenvolvimento. Planeje as funções pelos requisitos e o</p><p>que envolve de programação para evitar atrasos, mas ainda que isto não seja suficiente, crie um</p><p>controle diário de verificação de progresso do desenvolvimento e sempre informe à equipe e ao</p><p>cliente. Mais fácil que ter coragem de informar um resultado ruim é informar constantemente o</p><p>desenvolvimento.</p><p>Exemplo: nos bons e velhos exemplos do aplicativo de holerite, férias e upload, o tempo de</p><p>desenvolvimento do sistema de holerite era de dois dias. Em razão disso, mudou-se o</p><p>planejamento da ordem de desenvolvimento dos sistemas. Entretanto, o desenvolvimento no</p><p>segundo dia ainda estava carente de algumas funções e só seria entregue em quatro dias.</p><p>Coragem para informar o atraso, pois isto pode permitir a decisão de se inverter a ordem do</p><p>planejamento. Melhor seria informar, dia a dia, o percentual de desenvolvimento.</p><p>Ter que resolver problemas complicados sem ajuda;</p><p>Não ter tempo suficiente para fazer um bom trabalho.</p><p>Reflita</p><p>Conhecendo o medo, quais práticas efetivas você pode adotar para</p><p>mitigar? Como ajudar o cliente a pedir a coisa certa? Pergunte os</p><p>requisitos e informe o resultado. Os desenvolvedores temem ficar para</p><p>trás tecnicamente. Como ajudar? Promova cursos na empresa.</p><p>Respeito</p><p>No XP, o Respeito é a base dos quatro outros valores. É preciso entender que respeito é além de</p><p>educação, é respeitar a qualidade do outro, a forma de trabalho, as necessidades e os</p><p>conhecimentos. Apesar de ser o último a ser citado, o respeito é o mais importante no XP. Todos</p><p>devem se respeitar.</p><p>Ex.: naquele costumeiro exemplo do aplicativo de visualização do holerite, férias e upload de</p><p>fotos, o desenvolvedor deve respeitar o desejo de forma de visualização dos funcionários; o</p><p>designer tem de respeitar a forma que melhor atende seu cliente interno. Todos devem respeitar</p><p>as formas de trabalho e os próprios profissionais.</p><p>Princípios</p><p>Os princípios do XP são simples e norteadores para quem está no projeto.</p><p>Feedback Rápido</p><p>Trocando Ideias...</p><p>De certa forma, via de regra, o respeito pode ser obtido com amplo uso</p><p>da empatia, isto é, colocar-se no lugar do outro, projetar-se na</p><p>necessidade do outro, no que o cliente espera e em como ele espera.</p><p>Planeje o tempo mínimo entre o recebimento e a entrega. Isto não significa correr com o</p><p>projeto, mas, no tempo certo, quanto tempo, no mínimo, para demonstrar algo.</p><p>Vamos imaginar o desenvolvimento de um aplicativo que profissionais de uma determinada</p><p>classe, por exemplo, profissionais de Educação Física ou professores de programação de uma</p><p>faculdade. Este aplicativo deve estar instalado em todos os celulares que participarão desta</p><p>comunidade. O profissional ou professor cadastra as pessoas que assistirão às aulas; o login</p><p>registra a frequência; o aplicativo habilita a câmera, microfone e um pequeno sistema de</p><p>interação com respostas simples como alternativas.</p><p>Quanto tempo para criar a função de adição de pessoas? Planejar, desenvolver e testar?</p><p>Poderiam ser feitas as outras funções em conjunto?</p><p>Não!</p><p>Qual o tempo mínimo de feedback? Apenas uma função, pois mudanças podem aparecer neste</p><p>ponto e o tempo não pode ser perdido.</p><p>Simplicidade</p><p>Este princípio nos ensina a criar soluções da forma mais simples. Simplicidade significa</p><p>apreensibilidade rápida, compreensão rápida, modificação rápida.</p><p>Pratique profundamente o não desenvolver para o futuro. Você não irá precisar de funções que</p><p>não existem. Seja simples.</p><p>A orientação a objetos é um dos maiores facilitadores do reuso dos códigos. Não refaça, não</p><p>copie, não repita, reuse. Se uma função tiver</p>
<p>de ser reutilizada, mas isto implicar em complicar o</p><p>desenvolvimento, simplifique, crie como uma nova função, ainda que semelhante, mas simples.</p><p>Mudança Incremental</p><p>Planeje e execute as menores mudanças no código, no design, na equipe, no projeto. Desenvolva</p><p>o projeto como uma escada, degrau a degrau, mudanças sutis são mais facilmente adaptáveis e</p><p>ao final de todas as mudanças a diferença pode ser grande, no entanto, com baixo impacto.</p><p>No aplicativo dos professores, citado no título Feedback Rápido, imagine que o cliente pede uma</p><p>grande alteração na forma de interagir dos alunos com o professor. Separe as funções e comece</p><p>as mudanças em pequenas partes, pequenas funções até que o sistema esteja todo alterado. A</p><p>cada parte, Feedback Rápido!</p><p>Aceitação</p><p>Aceitar uma mudança é atender à necessidade do cliente, ainda que interno, mas respeitar sua</p><p>necessidade. Reprogramar é normalmente detestado pelos desenvolvedores, este é um dos</p><p>fatores de se ter Feedbacks Rápidos. Se um desenvolvedor não consegue aceitar as mudanças, é</p><p>uma boa ideia mudar o próprio programador, pois aceitar é adaptar e adaptação é um dos</p><p>principais valores do XP.</p><p>Qualidade</p><p>Para a Norma ISO 9.001, “qualidade é o atendimento às necessidades do requisitante”. Entregar</p><p>exatamente o solicitado não é apenas olhar para o papel e cumprir o estabelecido, é ter um</p><p>processo de produção de alta qualidade.</p><p>Promova um trabalho em equipe;</p><p>Equilíbrio de cargas de trabalho;</p><p>Estimule a solidariedade entre os funcionários para promover a carga de trabalho</p><p>equilibrada;</p><p>Práticas</p><p>O XP tem por objetivo criar práticas que facilitem o que retornar ao cliente e uniformizem para</p><p>ganho de qualidade, de forma a não atrasar o processo do software algo mais fluido o possível.</p><p>Outro viés é a compreensão de todos do projeto sobre o que se precisa fazer, um entendimento</p><p>compartilhado para evitar ruídos e, principalmente, que o desenvolvedor esteja bem, uma vez</p><p>que o seu bem-estar é fundamental, pois ele é o responsável por realizar o projeto.</p><p>Feedback em Escala</p><p>Teste</p><p>Ao se planejar e desenvolver os testes, o desenvolvedor, ciente do que será verificado,</p><p>desenvolve com especial atenção à aprovação. Como se o professor dissesse aos alunos as</p><p>questões da prova antes de ensinar. Claro que neste caso o desenvolvimento é estrito, diferente</p><p>do aprendizado, que é amplo.</p><p>Para que o desenvolvedor realize com maior qualidade, estabeleça:</p><p>Cliente Presente</p><p>Todo projeto que pode contar com o cliente presencialmente evolui de forma contínua e rápida,</p><p>pois ele conhece exatamente o que precisa, ele é o principal esclarecedor e responde</p><p>Mantenha um ambiente que permita o funcionário se manter focado no</p><p>desenvolvimento e que ele se sinta bem para que as entregas sejam boas.</p><p>Todos os testes a serem realizados;</p><p>Testes de unidade e de integração;</p><p>Testes automatizados.</p><p>imediatamente às dúvidas pontuais.</p><p>Com o cliente presente no desenvolvimento, as dúvidas são sanadas no momento em que</p><p>surgem, sem necessidade de e-mails e documentos. A primeira questão é: e a documentação</p><p>comprobatória? Se ele está presente, não haverá necessidade de comprovações, pois está</p><p>desenvolvido corretamente e ele, presente, já é parte do desenvolvimento.</p><p>Processo Contínuo</p><p>O desenvolvimento de um software deve primar pela qualidade, mas isto não deve impedir que o</p><p>desenvolvimento e as entregas sejam realizados continuamente. Em sistemas cliente-servidor</p><p>este desenvolvimento contínuo é simples, pois o código está disponível o tempo todo, no</p><p>entanto, se pensarmos em aplicativos para celulares, o desenvolvimento deve ser feito com mais</p><p>cuidado para permitir a distribuição. Como entregar continuamente sem perder a qualidade?</p><p>Numa aplicação móvel, dois desenvolvedores fazem cópias do sistema original e cada um</p><p>trabalha uma função nova. Quando o primeiro entrega a atualização, o segundo inicia os testes</p><p>de integração. Neste momento, o primeiro inicia um novo desenvolvimento a partir da última</p><p>cópia distribuída; o segundo desenvolvedor, então, distribui uma nova cópia. Desenvolvimento e</p><p>testes rodando continuamente.</p><p>Reestruturação</p><p>Reestrutura significa refazer a estrutura do software, claro. Quais são as partes que são a</p><p>estrutura do programa? Banco de Dados, as conexões com ele, os objetos principais de login e</p><p>senha, sessão, entre outros. Alguns são parte do projeto, por exemplo: um aplicativo que calcula</p><p>a qualidade da água para um laboratório. O cálculo é a parte estruturante.</p><p>Refazer estes códigos de forma a não alterar ou modificar minimamente os códigos acessórios,</p><p>a fim de melhorar o processamento, segurança e outros pontos.</p><p>É notável a diferença de desempenho do Windows® 7 para o 11 e como o aplicativo do WhatsApp®</p><p>melhorou a criptografia.</p><p>É importante saber que um código acessório é aquele que entrega funções não estruturantes.</p><p>Ex.: no exemplo do aplicativo que calcula a qualidade da água para o laboratório, o sistema de</p><p>relatórios é importante, mas não estruturante, assim como o sistema de geolocalização. Eles não</p><p>mudam a estrutura do sistema.</p><p>Entregas Pequenas e Rápidas</p><p>Ao realizar pequenas entregas (como vimos no item Processo Contínuo) permite o cliente</p><p>visualizar o progresso do sistema, novas funcionalidades e novas funções surgem. Como o</p><p>desenvolvimento é menor, as entregas são rápidas, logo, o desenvolvimento é facilitado, os</p><p>testes e a aceitação também.</p><p>Se pensarmos naquele aplicativo do cálculo da qualidade da água, podemos imaginar um sistema</p><p>de busca; depois, um novo relatório no sistema de busca de como visualizar o registro</p><p>específico; e depois, o relatório do sistema de busca, e assim por diante.</p><p>Entendimento Compartilhado</p><p>No início do levantamento dos requisitos, é fundamental que o cliente seja ouvido, mas,</p><p>principalmente, que participe do próprio planejamento, do calendário de entregas e das funções,</p><p>e os desenvolvedores também devem participar. Com todos cientes dos anseios do cliente, a</p><p>priorização das entregas fica mais simples: calcular o tempo de entrega, planejar os itens a</p><p>serem entregues, determinar funções, custos e o design. Todos devem conhecer o que estão</p><p>fazendo.</p><p>Naquele aplicativo do cálculo da qualidade da água, o sistema é incomum, os cálculos são</p><p>executados por um químico, o design deve agradar profissionais de laboratório, entre outras</p><p>especificidades. Supor, acreditar e entender são coisas comuns durante o desenvolvimento, pois</p><p>com o conhecimento compartilhado, os erros e crenças são reduzidos e todos podem auxiliar</p><p>para a melhor assertividade do desenvolvimento.</p><p>Design Simples</p><p>Desenvolva o que é para ser desenvolvido, nem mais, nem menos, apenas o essencial. O simples</p><p>sempre resolve. É fácil de desenvolver, de usar, de manter, atualizar e de explicar para a equipe de</p><p>desenvolvimento.</p><p>Quanto menos linhas de código, menos possibilidades de erro.</p><p>Alguns sites e aplicativos do governo são tão complexos que os usuários normalmente se</p><p>perdem e não encontram o que precisam. Os celulares com a interface infantil foram pensados</p><p>desta forma: simples.</p><p>Exemplo: um aplicativo de satisfação de compras de clientes de um mercado. Ao se cadastrar,</p><p>alguns ficam informando o nome do usuário logado. É necessário? O ambiente é de alta</p><p>segurança? A interface pode ser limpa e deixar as informações somente do objetivo em tela:</p><p>responder à pergunta e um ou dois botões adicionais, como “voltar” e “configurações”.</p><p>Metáforas</p><p>No ambiente de desenvolvimento é comum o uso de jargões específicos da tecnologia, mas</p><p>fazendo uma metáfora com os médicos, é como ir à consulta e ouvir os termos técnicos como</p><p>Encefalomielite Miálgica com necessidade de tratamentos do sono, ou seja, dormir para curar o</p><p>estresse.</p><p>O uso desta linguagem simplificada não determina o fato em si, mas facilita a compreensão por</p><p>todos. Use metáforas fáceis de entender e compreenda o uso das metáforas para conseguir</p><p>desenvolver.</p><p>Propriedade Coletiva</p><p>Todos os desenvolvedores devem conhecer o código</p>
<p>por completo. Todos podem corrigir, todos</p><p>podem melhorar, e, se alguém deixar o projeto, ele não é o dono do código, outros saberão como</p><p>aquela função foi feita.</p><p>É de suma importância estimular que todos conheçam o código por completo, ainda mais se o</p><p>aplicativo for muito específico, pois qualquer um poderá corrigir ou desenvolver as partes</p><p>específicas.</p><p>Além disso, com todos conhecendo o código por completo, em caso de eventuais erros, evita que</p><p>uns culpem outros e atrase a correção. Todos são responsáveis por todo o código e não podem</p><p>negligenciar.</p><p>Padrões de Codificação</p><p>Assim como muitos dos conceitos aqui descritos você já deve ter pensado “isto é meio</p><p>natural...”, ou para quem já está na área “mas já fazemos mais ou menos assim”, os padrões de</p><p>codificação (ou Design Patterns) também soam como natural.</p><p>Durante o desenvolvimento, muitas soluções acabam por ser referenciadas para que os</p><p>desenvolvedores lembrem dela, como “use a solução do crypto-decrypto” ou “chame o objeto do</p><p>CRUD”.</p><p>Os padrões de codificação soam como rótulos, nomes às funções que que servem para todos</p><p>entenderem do que está sendo tratado, de forma simples e clara.</p><p>Naquele aplicativo do cálculo da qualidade da água (esta referência dispensa a descrição do</p><p>aplicativo toda vez, logo, um padrão), o cálculo pode ser chamado de “cálculo”, simplesmente.</p><p>Todos que precisarem do cálculo saberão do que se trata.</p><p>Respeito ao Desenvolvedor</p><p>O desenvolvedor é uma peça importante no projeto, pois é ele quem executa a programação e</p><p>trabalhar demais ou estressado por sobrecarga pode reduzir muito a produtividade e aumentar</p><p>os erros de desenvolvimento.</p><p>Limite o trabalho da equipe a 40h semanais. Trabalhar mais que 8h ao dia é indício de</p><p>descontrole do projeto, e sobrecarregar a equipe para corrigir este erro é pior. Lembre-se do</p><p>item “Coragem”! Comunique imediatamente ao cliente sobre o atraso e procure alternativas de</p><p>correção, mas proteja sua equipe.</p><p>Artefatos do XP</p><p>Para colocar o XP em prática alguns artefatos são necessários, como os itens a seguir.</p><p>Cartões de História</p><p>Os cartões de história contam o que o cliente pede. São chamados de cartões do usuário.</p><p>Cartões de Tarefas</p><p>Os Cartões Tarefa são o descritivo técnico das funções a serem desenvolvidas a partir dos</p><p>Cartões de Usuário. Para cada cartão é feito um cartão tarefa com as atividades necessárias para</p><p>implantação da história que ele contém.</p><p>Crie um cartão do usuário com o descritivo do cliente e suas metáforas;</p><p>A partir do cartão de usuário, crie um descritivo detalhado para que os</p><p>desenvolvedores estimem o tempo de produção;</p><p>Para cada requisito, crie um cartão a parte e nele descreva o tempo necessário para</p><p>desenvolver aquela função;</p><p>Junte os cartões.</p><p>Em cada cartão tarefa deve conter, além do histórico e descritivo das tarefas, quem deve fazer e a</p><p>estimativa de tempo para realizar com seu prazo de entrega. O líder da equipe deve separar as</p><p>tarefas, determinar os prazos e combinar com os desenvolvedores, que devem estar de acordo</p><p>ou devem revisar.</p><p>Fases do eXtreme Programming</p><p>A Figura 2 ilustra as fases do XP.</p><p>Nos Requisitos do Usuário é aberto o Cartão do Usuário com seus Requisitos;1</p><p>Então, o planejamento de iteração é feito juntamente com as estimativas de tempo e</p><p>esforço de equipe;</p><p>2</p><p>Novos requisitos ocorrem nesta fase e são definidas as prioridades de</p><p>desenvolvimento;</p><p>3</p><p>O desenvolvimento com pequenas entregas rápidas permite novos Requisitos;4</p><p>A última versão que servirá de cópia para o Programação Contínua é entregue ao</p><p>teste de aceitação;</p><p>5</p><p>Uma nova versão é disponibilizada e é iniciado um novo ciclo.6</p><p>Figura 2 – Diagrama das Fases do XP</p><p>Em Síntese</p><p>O XP é um método um pouco mais complexo de implantação, mas ele</p><p>permite maior qualidade e velocidade de entrega em softwares e, em</p><p>especial, para aplicativos de celulares, ou computação móvel, pois</p><p>estes exigem maior controle de qualidade e entregas rápidas.</p><p>Apesar disto, o XP ainda assim é de fácil implantação, pois não</p><p>demanda grandes transformações, nem estrutura própria, apenas uma</p><p>mudança de cultura organizacional se não existir uma mentalidade</p><p>ágil.</p><p>Indicações para saber mais sobre os assuntos abordados nesta</p><p>Unidade:</p><p>Vídeo</p><p>Extreme Programming 20 Years Later</p><p>Neste vídeo, o autor do XP discursa sobre o que foi aprendido e o futuro do XP. Importante vídeo</p><p>para que uma implantação seja bem-sucedida.</p><p>2 / 3</p><p>˨ Material Complementar</p><p>Extreme Programming 20 years later by Kent Beck</p><p>https://www.youtube.com/watch?v=cGuTmOUdFbo</p><p>Leitura</p><p>Utilização da Metodologia Ágil eXtreme Programming (XP)</p><p>como Ferramenta de Gestão: um Estudo de Caso numa</p><p>Empresa do Ramo de Tecnologia e Serviços</p><p>Este artigo descreve os valores, características e utilidade do XP. Fundamental para quem quer se</p><p>aprofundar num estudo de caso simples.</p><p>Clique no botão ao lado para conferir o conteúdo.</p><p>ACESSE</p><p>Agile: Parte III – Implantando Processos Ágeis, a Escolha da</p><p>Estrutura e Mapeamento</p><p>Este breve artigo relata o como implantar o XP numa empresa exemplo. Muito importante para</p><p>entender os passos para implantação.</p><p>Clique no botão ao lado para conferir o conteúdo.</p><p>ACESSE</p><p>Estudo Comparativo entre a Metodologia Tradicional e Ágil</p><p>de Gerenciamento de Projetos</p><p>http://revistas.icesp.br/index.php/Cosmopolita/article/view/154#:~:text=S%C3%A3o%20Paulo%2C%20que%20emprega%20em,liberais%2C%20criativas%20e%20menos%20tradicionais.</p><p>http://estrategiasdademanda.com.br/como-implantar-o-agile-nas-empresas/</p><p>Este artigo científico compara o modelo amplamente documental como o Pmi com o XP. Muito</p><p>importante para entender a dificuldade de resolver o software com um modelo tradicional.</p><p>Clique no botão ao lado para conferir o conteúdo.</p><p>ACESSE</p><p>http://www.abepro.org.br/biblioteca/TN_STO_295_1664_38216.pdf</p><p>BERNARDO FILHO, O. Engenharia de Software: Metodologia XP (eXtreme Programming).</p><p>Disponível em: <http://www.eng.uerj.br/~orlando/xp.pdf>. Acesso em: 20/02/2022.</p><p>MELO, C. O.; SANTOS, V. A.; CORBUCCI, H.; KATAYAMA, E.; GOLDMAN, A.; KON, F. Métodos Ágeis</p><p>no Brasil: estado da prática em times e organizações. Relatório Técnico. Departamento de</p><p>Ciência da Computação. IME-USP. n. 2010, p. 9, 2012.</p><p>SATO, D. T. Uso eficaz de métricas em Métodos Ágeis de Desenvolvimento de Software. Instituto</p><p>de Matemática e Estatística, Universidade de São Paulo, São Paulo, v. 139, 2007. Disponível em:</p><p><https://www.teses.usp.br/teses/disponiveis/45/45134/tde-06092007-</p><p>225914/publico/dissertacao.pdf>. Acesso em: 20/02/2022.</p><p>TELES, V. M. Um estudo de caso da adoção das práticas e valores do eXtreme Programming.</p><p>UFRJ–Universidade Federal do Rio de Janeiro, 2005. Disponível em:</p><p><https://www.ime.usp.br/~ale/Dissertacao.pdf>. Acesso em: 02/03/2022.</p><p>WELLS, D. eXtreme Programming: A Gentle Introduction. Disponível em:</p><p><http://www.extremeprogramming.org/>. Acesso em: 20/02/2022.</p><p>3 / 3</p><p>˨ Referências</p>