Please enable JavaScript.

Coggle requires JavaScript to display documents.

processos de software - Coggle Diagram

- - - - Integração: com as unidades testadas, a próxima tarefa é integrar todas elas para compor um sistema completo.
      - Teste de Sistema: no final da integração, é feito um teste geral para certificar (validação) que os “requisitos do sistema” foram completamente atendidos. Por fim, o software é entregue ao cliente;
      - Teste unitário: no final da implementação, são feitos os “testes de unidade” para certificar (validação) que as implementações atendem aos “requisitos de unidade”;
      - Operação e manutenção: Ao operar, ou seja, utilizar o sistema, o cliente poderá encontrar erros ou necessidades que não foram identificadas anteriormente. Esta fase se responsabiliza pela correção dos erros ou melhorias do sistema (evolução).
      - Implementação: nesta etapa, com o projeto definido, cada “unidade de programa” é implementada, podendo alocar vários programadores simultaneamente.
      - Projeto do software: é elaborado o desenho da arquitetura geral do sistema, seguindo as informações coletadas na etapa anterior. Tudo é separado em partes chamadas de “unidades de programa” para poder agilizar o desenvolvimento. Cada unidade terá seu próprio “requisito de unidade”
      - Especificação: é feita a análise e captação das necessidades do cliente e definidos os “requisitos do sistema” com suas funcionalidades
    - - Por causa de sua natureza separada em unidades, o modelo em cascata possibilita a implementação concorrente entre vários programadores, agilizando a entrega;
      - É útil quando o pessoal envolvido no projeto é fraco tecnicamente. (McCONNEL, 1996);
      - O modelo apresenta uma grande vantagem quando o escopo do trabalho é claramente definido. Se as especificações estiverem corretas (o que é muito difícil em projetos de médio e grande porte), um software pode ser desenvolvido de forma muito rápida.
    - - se a especificação não for bem definida, ele pode ser tornar um risco e um convite para falhas
      - o modelo não possui flexibilidade, seguindo um sequencia engessada, é considerado um modelo frágil, principalmente nos dias de hoje que os projetos mudam muito no decorrer do desenvolvimento
      - Também é difícil estabelecer explicitamente todos os requisitos logo o início do projeto, pois no começo, sempre existe uma incerteza natural
      - EVANS (2017), defensor de uma linguagem de arquitetura que reflita as regras de negócio do cliente, afirma que no Modelo em Cascata, os especialistas de um negócio conversam com os analistas, […] que passam o resultado para os programadores […] No entanto, essa abordagem falha porque lhe falta feedback. Em outra palavras, o software resultante pode atender às necessidades do cliente, mas o código não reflete as regras de negócio, uma vez que os programadores “só programam”, não sendo possível identificar os termos de negócio olhando no código
      - O cliente deve ter muita paciência, pois uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento;
      - Projetos grandes raramente seguem a sequencia proposta pelo modelo. A produção e aprovação de documentos durante as etapas costumam se caras e geradoras de muito retrabalho;
      - Durante o processo, é comum o cliente solicitar o congelamento de partes do desenvolvimento para dar continuidade aos estágios posteriores, tornando a solução dos problemas mais difícil, pois acaba sendo programada para mais tarde e, dependendo da situação, acaba sendo parcial ou totalmente ignorada;
      - O congelamento prematuro de partes da implementação pode resultar em um sistema que não faça o que o usuário quer. Também pode “levar a sistemas mal estruturados, quando os problemas de projeto são contornados por artifícios de implementação”
      - A natureza linear do modelo leva a “estados de bloqueio”, nos quais alguns membros da equipe de projeto precisam esperar que outros membros completem as tarefas dependentes
      - EM resumo:
        
        É muito difícil retornar para as fases anteriores para corrigir problemas detectados posteriormente;
        Muito tempo é gasto para garantir que as fases sejam executadas corretamente;
        Demora muito para o cliente ver algum resultado;
        O cliente se decepciona quando recebe o produto;
        A equipe de desenvolvimento está sempre “quase acabando”;
        Esconde os riscos por muito tempo, retardando sua resolução;
  - - - “O custo de acomodar as mudanças nos requisitos do cliente é reduzido”. (SOMMERVILLE, 2011) A quantidade de análise e documentação a ser refeita é muito menor do que o necessário no modelo em cascata.
      - É mais fácil obter feedback dos clientes sobre o desenvolvimento que foi feito. Os clientes podem fazer comentários sobre as demonstrações do software e ver o quanto foi implementado. Os clientes têm dificuldade em avaliar a evolução por meio de documentos de projeto de software.
      - O cliente não precisa receber todo o sistema para poder usá-lo. Como a implementação é feita por pedaços ordenados por prioridades, o cliente pode ter acesso às partes mais importantes antes, podendo utilizá-las imediatamente;
      - É possível obter entrega e implementação rápida de um software útil ao cliente, mesmo se todas as funcionalidades não forem incluídas. Os clientes podem usar e obter ganhos a partir do software inicial antes do seria possível com um processo em cascata.
      - É particularmente útil quando não há mão-de-obra disponível para uma implementação completa, dentro do prazo comercial de entrega estabelecido pelo projeto
    - - a estrutura do sistema tende a se degradar com a adição dos novos incrementos. Tempo e dinheiro devem ser direcionados para refatoração e melhorias do software, pois as constantes mudanças sem previsão do futuro tendem a corromper sua estrutura. A incorporação de mudanças do software torna-se cada vez mais difícil e custosa.
      - o progresso não é visível e os gerentes precisam de entregas regulares para mensurar o progresso. Se os sistemas forem desenvolvidos com rapidez, não será economicamente viável produzir documentos que reflitam cada uma das versões do sistema;
      - Sistemas de grande porte necessitam de um framework ou arquitetura estável, e as responsabilidades das diferentes equipes de trabalho do sistema precisam ser claramente definidas, respeitando essa arquitetura. Segundo SOMMERVILLE (2011), essa parte deve ser planejada com antecedência, e não pode ser desenvolvida de forma incremental;
      - Os problemas são particularmente críticos para os sistemas grandes, complexos e com vida-longa, onde várias equipes desenvolvem diferentes partes do sistema;
  - - - DEFINIÇÂO DE OBJETIVOS
        : onde são definidos os objetivos para essa fase do projeto, identificando as restrições e preparando um plano de gerenciamento detalhado que inclui todos os possíveis riscos do projeto;
      - AVALIAÇÃO E REDUÇÃO DE RISCOS
        para cada risco identificado é feita uma “Análise de Risco” detalhada com o objetivo de identificar estratégias para reduzi-lo ou evitá-lo. Por exemplo, caso exista uma dificuldade em especificar claramente um requisito, isso significa que existe um “risco de requisitos inadequados” e para amenizá-lo será preciso desenvolver um protótipo para apresentar ao cliente a fim de colher sugestões para refinar os requisitos. (Um protótipo é uma simulação do sistema, podendo ser desenhado em papel ou programado de forma simples e não funcional para que o cliente tenha uma ideia melhor do que o engenheiro entendeu de seus requisitos. Mais informações sobre prototipagem será fornecida em um artigo exclusivo sobre Interface Humano-Computador);
      - IMPLEMENTAÇÃO E VALIDAÇÃO
        com as estratégias definidas, é escolhido um modelo de desenvolvimento, como por exemplo, o “Modelo em Cascata”, “Modelo Incremental”, etc. Pode-se utilizar modelos diferentes em cada volta de implementação, conforme a necessidade;
      - PLANEJAMENTO E ESPECIFICAÇÃO
        o projeto todo é analisado para verificar o que foi realizado e planejar quais serão os próximos passos para iniciar novas voltas do espiral ou concluir o sistema.
    - - Como o modelo exige a consideração dos riscos técnicos em todos os estágios de evolução, se for aplicado adequadamente, reduzirá os riscos antes que se tornem problemáticos;
      - As estimativas se tornam mais realistas e o tempo de implementação é reduzido;
      - Mais versátil para testar e lidar com mudanças;
      - Não faz distinção entre desenvolvimento e manutenção.
    - - pode ser difícil convencer os clientes que o processo de evolução é controlável, pois ele exige competência considerável na avaliação dos riscos e depende dessa competência para ser bem sucedido;
      - Se um risco importante não for descoberto e gerenciado corretamente, fatalmente ocorrerão problemas;
      - A avaliação dos riscos exige um analista com experiência;
      - Aplica-se melhor a sistemas de grande porte;
      - Erros na avaliação de riscos podem impactar o projeto.
  - - - atacar os riscos cedo e continuamente
      - entregar algo de valor ao cliente,
      - focar em um software que possa ser utilizado o quanto antes,
      - realizar mudanças cedo,
      - liberar protótipos da aplicação,
      - utilizar componentes reutilizáveis,
      - trabalhar como um time e
      - fazer da qualidade um estilo de vida”
    - - Iterativo e incremental
        as fases de Elaboração, Construção e Transição são divididas em uma série de interações. Em projetos grandes, a fase de Concepção também pode ser dividida em iterações. Cada iteração resulta em um incremento, que é uma versão do sistema contendo funcionalidades adicionais ou melhoradas em comparação com a versão anterior. Essa divisão de incrementos deve ser feita no inicio do projeto, definindo todas antes de iniciar a programação;
      - Dirigido por Casos de Uso:
        na captura de requisitos, eles são refinados e desenhados na forma de Casos de Uso da UML. Cada iteração tem um conjunto de casos de uso ou cenários de requisitos durante todo o tempo de implementação, teste e desenvolvimento;
      - Centrado na Arquitetura:
        o RUP defende que, para dar forma ao sistema, a Arquitetura deve estar no centro dos esforços da equipe do projeto. Uma vez que não existe um modelo único suficiente para cobrir todos os aspectos do sistema, o RUP suporta múltiplas visões e modelos arquiteturais.
      - Focado no Risco:
        o modelo requer que a equipe do projeto concentre-se em enfrentar os riscos mais críticos no início do ciclo de vida do projeto. As entregas de cada iteração, especialmente na fase de Elaboração, devem ser selecionadas de forma a garantir que os maiores riscos sejam tratados em primeiro lugar.
    - - TIPOS (colunas)
        
        ELABORAÇÃO
        
        nesta fase a maioria dos Casos de Uso são elaborados e especificados. A arquitetura do sistema é projetada, gerando diversos artefatos (Documentação, Diagramas, Planilhas, etc) e uma “baseline” completa é apresentada incluindo os componentes estruturados para posterior formação da equipe de desenvolvimento. No final dessa fase os envolvidos devem estar aptos a planejar a fase de construção em detalhes;
        
        Os artefatos gerados na Elaboração
        
        Modelo de Casos de Uso;
        
        Requisitos suplementares, incluindo não funcionais;
        
        Modelo de análise;
        
        Descrição da arquitetura do software;
        
        Protótipo arquitetural executável;
        
        Modelo de projeto preliminar;
        
        Lista de riscos revisada;
        
        Plano de projeto: planos de iteração, fluxos de trabalho adaptados, marcos e produtos técnicos de trabalho;
        
        Manual preliminar do usuário.
        
        CONSTRUÇÃO
        
        Construção: esta fase envolve a implementação do software e seus testes (GUEDES, 2018). É onde utilização dos vários artefatos possibilita que o sistema seja implementado quase completamente. Tem-se uma visão geral de como o “baseline” do projeto está sendo seguido. Na conclusão dessa fase, você deve ter um sistema de software já funcionando, bem como a documentação associada pronta para ser entregue aos usuários;
        
        Os artefatos gerados na Construção
        
        Modelo de projeto;
        
        Componentes de software;
        
        Incremento integrado de software;
        
        Plano e procedimento de teste;
        
        Caso de teste;
        
        Documentação de apoio: manuais do usuário, manuais de instalação, descrição do incremento atual.
        
        TRANSIÇÃO
        
        nesta fase o software será implantado garantindo que todos os requisitos do projeto foram atendidos e implementados corretamente. O produto final pode ser liberado em uma versão beta. Outras atividades desta fase, dependendo do projeto, podem ser os testes no ambiente real (onde o software irá funcionar), a conclusão do manual do usuário, a identificação e correção de defeitos, etc. No final, deve-se tirar uma conclusão geral do projeto, levantando e documentando os pontos positivos e negativos para serem ser utilizados nas decisões em projetos futuros.
        
        Os artefatos gerados na Transição
        
        Incremento de software entregue;
        
        Relatório de teste beta;
        
        Realimentação geral do usuário (modificar ou adaptar a compreensão dos requisitos do projeto).
        
        CONCEPÇÃO
        
        objetivo da fase é fazer a elicitação de requisitos inicial e determinar a viabilidade de se desenvolver o sistema (GUEDES, 2018). São identificadas todas as entidades externas (pessoas ou sistemas) que vão interagir com a aplicação. Com essas informações, avalia-se a viabilidade do sistema para o negócio e, se for pequena, o projeto pode ser cancelado aqui;
        
        Os artefatos gerados na Concepção
        
        Documento de Visão;
        
        Modelo inicial de Casos de Uso;
        
        Glossário inicial do projeto;
        
        Caso de negócio inicial;
        
        Avaliação inicial de risco;
        
        Plano de projeto: fases e iterações;
        
        Modelo de negócio (se necessário);
        
        Um ou mais protótipos
        
        OBS artefatos
        
        Durante os “fluxos de trabalho”, podem ser produzidos vários “produtos de trabalho”, também chamados de “artefatos”, contendo informações sobre todo o processo. Segundo PRESSMAN (2006), “do ponto de vista dos Engenheiros de Software, o produto de trabalho mais importante, produzido durante a concepção, é o Modelo de Casos de Uso, uma coleção de Casos de Uso que descreve como atores externos (‘usuários’ humanos e não-humanos do software) interagem com o sistema e obtém valor dele”.
      - Essas fases servem de apoio para a execução das tarefas de cada um dos Fluxos de Trabalho, sendo seis da Engenharia de Software e de três para Apoio e Suporte. (linhas)
        
        Modelagem de negócios (ES):
        os processos de negócio são modelados por meio de Casos de Uso de negócios (SOMMERVILLE, 2011). O objetivo principal é que o analista entenda muito bem o problema a ser resolvido, elaborando se necessário uma análise de risco e de viabilidade para o projeto como um todo. É preciso uma grande interação entre o analista e o cliente, para que seja possível a criação dos Casos de Uso e consequentemente a extração dos requisitos. Entender o modelo de negócio do cliente é fundamental antes que um requisito possa ser definido;
        
        Requisitos (ES):
        nesse fluxo de trabalho, procura-se extrair os requisitos de forma que o cliente possa entender claramente a proposta do sistema. O alicerce é que o analista entenda o domínio do problema e consequentemente construa um bom modelo de Caso de Uso. A extração dos requisitos a partir de um Caso de Uso gerará um artefato que será evoluído durante todo o projeto;
        
        Análise e Desenho (ES):
        um modelo de projeto será criado e documentado em artefatos, como Descrição da Arquitetura Básica do sistema, Protótipos de Funcionalidade e Interface, Diagrama de Classes, Diagrama de Estado, Diagrama de Iteração, Diagrama de Seqüência, etc (SOMMERVILLE, 2011). Durante o desenvolvimento do projeto alguns artefatos poderão sofrer ajustes de acordo com as implementações realizadas. O objetivo aqui é compreender os Casos de Uso mais importantes, que serão úteis para a elaboração dos artefatos necessários, lembrando que não é necessária a utilização de todos os artefatos, mas apenas aqueles que sejam relevantes para o cliente entender perfeitamente o que será construído. Com artefatos bem elaborados, a equipe de desenvolvimento terá grande facilidade em realizar a implementação;
        
        Implementação (ES):
        os desenvolvedores poderão fazer uso de componentes (funções) que foram utilizados em outro sistema ou projeto. Ainda na fase de Concepção, pode-se ter um protótipo de funcionalidade. No decorrer deste fluxo de trabalho, tenta-se gerar um sistema executável a cada iteração, além da implementação baseada nos artefatos criados no fluxo de Análise e Desenho. O conceito de componentes deve ser sempre consideração, para que seja possível aproveitar esses “pedaços de código” em outros projetos;
        
        Testes (ES):
        um plano de testes é elaborado, definindo quais tipos de testes serão realizados. Esse plano poderá ser alterado de acordo com as melhorias ou alterações nos requisitos do sistema, impactando no número de testes a serem realizados. Nas fases de Concepção e Elaboração são feitos os testes de módulos e na fase de Construção, os testes de integração;
        
        Implantação (ES):
        neste fluxo de trabalho, um release do produto será criado, distribuído aos usuários e instalado no ambiente do cliente, ou seja, em seu local de trabalho (SOMMERVILLE, 2011). Durante toda a fase de Elaboração, até o meio da fase de Construção, poderá ser criado um documento especificando, de forma simples, algumas características do ambiente do cliente, contendo especificações técnicas sobre a infra-estrutura de rede, os sistemas operacionais, sistemas integrados, etc. Também é interessante adicionar algumas dicas de instalação para reduzir, no futuro, os erros de instalação e o tempo de testes. No final da fase de Construção, começa a migração do sistema para o “ambiente de testes” do cliente e posteriormente, na fase de Transição, o sistema é configurado no “ambiente de produção” do cliente.
        
        Gerência de configuração e mudança (AS):
        nesse fluxo de trabalho são controlados todos os artefatos do projeto e suas versões. Antes de realizar uma mudança corretiva ou evolutiva, deve-se fazer uma análise sobre o que deve ser modificado e quais artefatos serão afetados. Um bom controle de mudança é crucial para garantir o sucesso e a qualidade do projeto. Conforme o projeto entra na fase de construção, aumenta-se a dificuldade em controlar as mudanças e gerenciar a configuração. Quanto maior o projeto se torna, com mais requisitos implementados, maior será a chance de uma alteração afetar outras áreas do sistema. Por isso, saber rastrear e relacionar requisitos é uma importante tarefa do engenheiro de software. Após uma modificação, é necessário executar novos testes em várias áreas do sistema, garantindo que a mudança foi implementada corretamente e que nada foi quebrado. Igualmente importante é a atualização da documentação para que reflita perfeitamente o que foi implementado;
        
        Gerenciamento de projeto (AS):
        aqui se escolhe os artefatos a serem utilizados no desenvolvimento, de acordo com o tipo do projeto e o entendimento do cliente. O gerente de projeto deve ter uma visão clara do que o cliente deseja, do que está documentado e do que está sendo implementado. A atividade de gerenciamento de projeto é constante durante todo o ciclo de vida do software, onde se deve: a) elaborar reuniões para entrega de versões; b) criar documentos de RTF (Revisão Técnica Formal) para cada reunião; c) garantir a correta mudança dos artefatos; d) manter um bom relacionamento com o cliente;
        
        Ambiente (AS):
        Esse fluxo de trabalho está relacionado com a disponibilização de ferramentas apropriadas para a equipe de
        desenvolvimento de software (SOMMERVILLE, 2011). Essa disponibilização pode ser referente ao tipo de plataforma usada, a velocidade da internet e da rede, a organização dos diretórios/repositórios onde serão armazenados os artefatos e os códigos fonte, o sistema de backup etc. No final de cada fase podem acontecer ajustes no ambiente, podendo ser: criação de diretórios, backup de versões do software, etc.
    - - É um dos modelos mais usados em projetos modernos de desenvolvimento de software;
      - É extremamente robusto e bem estruturado;
      - Por fazer uso da UML, a facilidade de compreensão dos requisitos aumenta, tanto para os clientes, como para os analistas e desenvolvedores
      - Os riscos que poderiam ser mais preocupantes são resolvidos no inicio, minimizando o retrabalho e, consequentemente, a chance de fracasso do projeto.
    - - Exige uma equipe experiente e alinhada com os processos;
      - Exigem um bom gerente de projetos;
      - Complexo e trabalhoso para projetos pequenos.
  - - - Comunicação
        A comunicação deve ser contínua, tanto com o cliente como entre os membros da equipe. O objetivo é criar o melhor relacionamento possível, dando preferência às conversas pessoais em detrimento de outros meios como telefone, email, chats etc.
      - Simplicidade
        É preciso fomentar a implementação de funcionalidades com base nos problemas de hoje, deixando os problemas do futuro para o futuro. Como os requisitos são mutáveis, deve-se implementar apenas o que é estritamente necessário, de forma simples e com o mínimo de código possível.
      - Feedback
        Para o XP funcionar, os membros da equipe precisam ser profissionais comunicativos e com facilidade de se relacionar. Assim os feedbacks sobre as estratégias e, principalmente, sobre alterações no código são melhor recebidas e aceitas pelos membros do time.
      - Coragem
        Errar é natural, e quebrar o código de um sistema acontece cedo ou tarde. Por isso é necessário ter coragem para lidar com isso e confiança nos mecanismos de proteção do XP como, por exemplo, os Testes Automatizados.
        A coragem ajuda, principalmente, quando a possibilidade de simplificar o software é detectada. A Refatoração deve ser feita o quanto antes, mantendo a legibilidade do código (isso será abordado mais adiante neste artigo). Por isso a equipe precisa ser corajosa e acreditar nos valores do XP para que o software evolua com segurança e agilidade.
    - - ATIVIDADES EM QUE SE BASEIAM AS PRÁTICAS
        
        Desenhar:
        o bom design é uma excelente ferramenta para o entendimento de sistemas complexos. Por isso, é preciso manter o design sempre simples, evitando aumentar a complexidade que ocorre pela criação de funcionalidades que não sejam realmente necessárias. Para isso existe o princípio YAGNI (You aren’t gonna need it/Você não vai precisar disso) que diz para fazer as coisas somente no momento em que realmente for preciso. Antecipar a implementação antes que seja necessário é um desperdício de tempo, porque aumenta a complexidade do design do software e talvez a implementação adicional nunca seja usada de fato;
        
        Codificar:
        o código fonte deve ser coletivo, ou seja, todos os membros podem modificá-lo e devem ter o conhecimento claro sobre ele. Por isso deve existir um guia para padronização do código (que pode ser definida pelo próprio time), de forma que todos codifiquem da mesma forma
        
        Testar:
        os Testes Automatizados devem ser escritos antes do código real ser produzido. Além disso, os times ágeis devem utilizar a prática da Integração Contínua, para certificar que tudo está realmente funcionando antes de colocar o novo código em produção.
        
        Ouvir:
        é preciso ouvir (e ouvir bastante) para entender as regras de negócio do sistema. Antes de qualquer coisa é preciso ter domínio sobre o negócio a ser emplementado, para que o Design e a codificação ocorram de forma fluida;
      - Observando essas quatro atividades, o XP apresenta 13 práticas para que o processo aconteça.
        
        Prática 1. A presença do Cliente
        
        O XP insiste que o cliente deve estar presente no dia a dia do projeto, pois isso contribui para o sucesso. O contrário também é considerado verdade, pois a ausência do cliente é um sério fator de risco.
        A presença do cliente para tirar dúvidas, sempre que for possível, propicia uma série de pequenos ajustes e evita mudanças bruscas ao longo do caminho. Isso poupa um tempo incrível de trabalho.
        Apesar de existirem vários meios de comunicação, a conversa presencial é a forma mais eficaz, pois proporciona identificar outras informações como os gestos do cliente, expressões faciais, postura, tom de voz, entre outros.
        As expressões faciais que demonstram falta de entendimento, por exemplo, não são visíveis por telefone ou por chat, e podem ocasionar interpretações e decisões equivocadas no projeto.
        
        Prática 2. O jogo de planejamento
        
        O planejamento acontece diversas vezes ao longo do projeto, para que todos tenham a oportunidade de revisar as prioridades, garantindo que a equipe esteja trabalhando no que é mais importante para o cliente.
        Os projetos são divididos em Releases e Interações, de forma que o cliente e a equipe tenham oportunidade de revisar o planejamento.
        
        Interações: são períodos de poucas semanas, onde um conjunto de funcionalidades é implementado.
        Para cada Interação, ocorre uma reunião chamada de Jogo do Planejamento, onde “o cliente escreve histórias de usuário em cartões que representam a necessidade da funcionalidade a ser desenvolvida, e explica para os desenvolvedores tudo o que for preciso para que eles possam implementá-la”
        Como “parte da equipe de desenvolvimento, o cliente discute cenários com outros membros da equipe. Juntos, eles desenvolvem um ‘Cartão de História’, englobando as necessidades do cliente”
        As funcionalidades são descritas pelo cliente nesses pequenos cartões chamados de “Histórias”, respeitando o espaço de cada cartão para ficar o mais objetivo possível. Isso força o cliente a pensar melhor na funcionalidade. Em seguida, o cliente atribui um valor (de prioridade) para cada cartão
        “Membros da equipe XP avaliam, então, cada História e lhe atribuem um custo, medido em semanas de desenvolvimento. Se a História precisar de mais do que três semanas de desenvolvimento, pede-se para o cliente dividir a História em Histórias menores e a atribuição de valor e custo ocorre novamente”
        Nesse processo o cliente fica sabendo dos custos do desenvolvimento e, junto com a equipe, prioriza as funcionalidades que deverão fazer parte de cada Release.
        
        Releases: são períodos de alguns meses, onde as entregas geram um valor definido, ou seja, o cliente pode usar o software;
        Com as Histórias definidas, o cliente deve colocá-las nos Releases. Não é necessário que todas as Histórias sejam distribuídas, pois durante as reuniões de Interação, o cliente vai aos poucos aprendendo mais sobre o sistema e, mudando sua visão, identificará melhor suas reais necessidades.
        Segundo SOMMERVILLE (2011), cada Release deve conter “um conjunto mínimo de funcionalidades útil, que fornece o valor do negócio”.
        Os Realeases devem ser ordenados, com tamanhos fixos e pequenos o suficiente para entregas rápidas. “Cada projeto é realizado para atender às necessidades atuais, e nada mais” (SOMMERVILLE, 2011).
        
        O trabalho dos programadores
        Após definidas as Histórias da Interação, os integrantes do time escolhem os cartões que irão implementar naquele dia de trabalho. Isso ocorre todos os dias até a próxima reunião de Interação, onde as mudanças e novas prioridades poderão ser definidas.
        
        As mudanças nos requisitos
        Em cada reunião de Interação, o cliente poderá mudar as Histórias que achar necessário, criando novas, substituindo as existentes ou removendo as desnecessárias. Assim, o XP simplifica as mudanças do projeto, gerando benefícios para o cliente mais rapidamente
        
        O cliente pode mudar o projeto quantas vezes quiser, mas só é permitido fazer isso na reunião de Interação. Uma vez definidas as Histórias de uma Interação, o cliente não poderá alterá-las e terá que concordar com o que está sendo implementado até a próxima reunião, onde poderá solicitar uma História que ajuste o que foi feito ou deixar como está.
        
        Prática 3. Reunião diária
        
        Chamada de “Stand up meeting” (ou “Reunião em Pé”) para denotar uma conversa rápida, esta reunião deve ocorrer todos os dias (preferencialmente de manhã) com todos os integrantes do time e, se possível, com a presença do cliente.
        Cada membro deve comentar o que fez no dia anterior, fazendo com que a equipe fique atualizada sobre o andamento do projeto. Também é propício cada um apresentar os desafios enfrentados e as soluções criadas por eles. Esse feedback ajuda principalmente quando um desafio parecido acontecer novamente, pois todos saberão como resolver ou a quem procurar para um auxílio.
        Nessa reunião é decidido diariamente quais os cartões de História irão para quais membros do time. Isso não deverá ser decidido apenas por um único membro, mas por toda a equipe, pois assim, com uma visão do todo, será possível ter uma decisão mais assertiva sobre as dependências e desafios de cada História.
        É importante que esta reunião seja o mais breve possível, mas é muito importante que todos os membros falem por alguns minutos.
        
        Prática 4. Programação em pares
        
        No XP, os desenvolvedores nunca trabalham sozinhos, sempre em pares. O “Pair Programming” (ou Programação em pares) deve acontecer em um mesmo computador, onde duas pessoas trabalhem juntas. Uma das pessoas será o Condutor, que assumirá o teclado e digitará os comandos. A outra pessoa será o Navegador, que acompanhará o trabalho como estrategista.
        Quando o Condutor estiver cansado, poderá pedir para trocar de posição, tornando-se um Navegador. Esse revesamento é fundamental e deve ser praticado sempre. Não apenas a troca de papel (Condutor/Navegador), mas também a troca de pares, de forma a propiciar um conhecimento abrangente de toda a equipe dentro do projeto.
        Esse processo provoca uma revisão permanente do código, pois enquanto o Condutor está digitando, o Navegador estará o tempo todo observando para evitar que algum erro passe despercebido. Dessa forma, erros que dariam muito trabalho para serem detectados e corrigidos depois, são corrigidos facilmente, detectados pela pessoa que não está com as mãos no teclado.
        A programação em par produz ideias mais simples e eficazes, pois quando uma pessoa sugere uma solução muito difícil, a outra identifica a complexidade e, na medida que terá dúvidas, poderá sugerir simplificações.
        O código produzido é quase livre de defeitos, pois por causa do processo contínuo de revisão, pouquíssimos erros permanecem no código.
        Distrações como e-mail, mensagens instantâneas, cansaço ou internet causam uma perda de produtividade que o programador não consegue perceber. Mas com a presença do companheiro, ele terá um compromisso maior, porque seu trabalho envolve mais alguém
        
        Prática 5. Refatoração
        
        A Refatoração é o ato de alterar um código sem afetar a funcionalidade que ele executa. É utilizado para tornar o software mais simples de manter, utilizando Testes Automatizados para garantir que as modificações não interrompam seu funcionamento original (TELES, 2004).
        O código-fonte mal formulado despende muito tempo para ser entendido e modificado. Em contrapartida, um código legível é rapidamente corrigido ou alterado. A Refatoração não deve alterar o comportamento do código, mas apenas torná-lo mais legível.
        A prática da Refatoração é especialmente útil para código coletivo, onde todos que precisarem analisá-lo possam entendê-lo. Quando não se usa a refatoração, o código vai ficando cada vez mais ilegível na medida que vai crescendo, dificultando para toda a equipe.
        Em XP, um projeto sem Refatoração não tem a menor chance de sobrevivência. A agilidade de produzir feedback rapidamente para o cliente só é possível com alterações rápidas e constantes no código.
        Porém, a Refatoração também tem um preço: é acompanhada pelo risco de código parar de funcionar. Para resolver isso, o XP possui um ferramenta que combate o risco de se quebrar um código que está funcionando, como será abordado na próxima prática do XP.
        
        Prática 6. Desenvolvimento Guiado por Testes
        
        OBS Atenção: Quem não está acostumado com o termo, pode confundir “Teste Automatizado” com “Teste Automático”, mas estes são duas coisas diferentes. Para ser “automático”, bastaria uma ferramenta que fizesse uma bagatela de testes partindo de um simples clique num botão. Já para um teste “automatizado”, alguém tem que “automatizá-lo”, ou seja, implementar uma rotina que efetue os testes desejados. É este segundo cenário que chamamos de “Testes Automatizados”.
        
        Os Testes Automatizados avisam se o código continua produzindo as mesmas respostas após ter sido alterado, provendo uma enorme segurança ao processo de Refatoração e injetando coragem no desenvolvedor.
        Como os testes precisam ser implementados pelo desenvolvedor, produzi-los é um investimento que gera retornos no futuro, tais como:
        Por serem implementados, os testes se tornam grandes aliados para o entendimento do design do sistema, servindo de “documentação” para a compreensão do código fonte;
        Sempre que um teste detecta uma falha, a equipe ganha tempo de desenvolvimento, pois tem a oportunidade de corrigir o problema rapidamente;
        Evita longas sessões de depuração que costumam tomar boa parte do tempo dos projetos
        “Quanto mais tempo se leva para descobrir que você cometeu um erro, mais caro é para corrigi-lo” (BOEHM, 1988)
        O XP trabalha com dois tipos de testes:
        Teste de Unidade: é realizado sobre cada unidade (classe, método ou função) do sistema com a finalidade de verificar se os resultados gerados estão corretos;
        Teste de Aceitação: são efetuados sobre cada História do sistema, verificando não apenas uma unidade em particular, mas as interações entre um conjunto de classes ou rotinas que implementam uma funcionalidade.
        Para implementar os testes, a equipe pode fazer uso de frameworks de testes, que já possuem diversas funcionalidades, permitindo asserções para várias situaçõe
        Uma característica importante do TDD é o conceito de “test-first”, ou seja, “primeiro o teste”. Isso significa que cada nova funcionalidade, após ser devidamente pensada, deve ter seu Teste de Unidade implementado “antes que a funcionalidade em si seja implementada” (SOMMERVILLE, 2011).
        Isso força o desenvolvedor a “pensar antes de fazer”, o que gera código mais simples de entender e livre de remendos, que poderiam ser causados por erros de design.
        
        Prática 7. Código Coletivo
        Um projeto implementado de forma clássica, geralmente é dividido em pedaços, de forma que cada membro da equipe fique responsável por uma ou mais partes. Isso gera nos projetos as chamadas “Ilhas de Expertise” onde uma pessoa só acaba possuindo o domínio sobre uma área do projeto de forma só ela conhece aquela parte do código.
        O XP defende o contrário! O conhecimento do projeto não deve ser limitado a uma pessoa, mas, pelo contrário, toda a equipe deve ter o conhecimento de tudo e saber como alterar qualquer parte do projeto.
        O XP incentiva a propriedade coletiva do software, isto é, “os pares de desenvolvedores trabalham em todas as áreas do sistema, de modo que não se desenvolvam ilhas de expertise. Todos os conhecimentos e todos os desenvolvedores assumem responsabilidade por todo o código. Qualquer um pode mudar qualquer coisa”. SOMMERVILLE (2011)
        Dessa maneira, cada parte do software pode ser mantida por diferentes desenvolvedores ao longo de sua vida, forçando que o código esteja sempre sendo revisado e levando a equipe a ser mais ágil no desenvolvimento.
        Como não existe um único especialista, qualquer pessoa pode mexer no código sem precisar esperar por uma pessoa mais experiente.
        O código coletivo exige coragem por parte dos desenvolvedores, pois diversas vezes ao dia o desenvolvedor terá de mexer em partes do sistema que não foram construídas por ele. Isso só é possível através de Refatoração e TDD.
        
        Prática 8. Padrões de codificação
        Um dos valores fundamentais do XP é a comunicação, o que inclui o código fonte produzido. A equipe deve se comunicar de forma clara através do código fonte.
        Como são diferentes programadores, existirão diferentes estilos. Essa diferença no código dificulta a compreensão do código por todos da equipe.
        Por esse motivo, deve-se adotar um mesmo estilo de codificação por todos para que exista a mesma velocidade de compreensão. Isso é alcançado estabelecendo um padrão que seja aceito pela maioria e documentado em algum lugar para ser usado como referência.
        Nos momentos de Programação em Pares, o Navegador pode ajudar o Condutor, lembrando-o sobre o padrão documentado e mantendo assim a qualidade do código.
        
        Prática 9. Design simples
        O XP procura entregar valor para o cliente, determinando que é preciso sempre assumir o design mais simples possível e que faça uma funcionalidade passar nos Testes Automatizados.
        Em um projeto de software a mudança é constante, pois requisitos, design, tecnologia e os membros da equipe mudam. O problema não está na mudança em si, mas na incapacidade de lidar com ela.
        “Não é o mais forte que sobrevive, nem o mais inteligente, mas o que melhor se adapta às mudanças.” (Charles Darwin)
        Segundo TELES (2004), para manter um design simples, o XP recomenda os quatro valores mencionados no começo deste artigo:
        Comunicação: o design simples comunica sua intenção de forma mais eficaz que um design complicado;
        Simplicidade: o design simples torna o software mais leve e mais fácil de ser alterado a qualquer momento, visto que é mais fácil de ser compreendido. Como explica PRESSMAN (2006), “um projeto XP segue rigorosamente o princípio KIS (Keep it simple/mantenha a simplicidade). Um projeto simples é sempre preferível em relação a uma representação mais complexa”;
        Feedback: com um design simples, a equipe é capaz de avançar de forma mais ágil e obter feedback do cliente mais rapidamente;
        Coragem: o design simples é aquele que a equipe trabalha apenas para resolver o problema de hoje. Problemas do futuro, mesmo que já sejam previstos, são deixados para o futuro. É necessário coragem para assumir que a equipe será capaz de resolver o problema no futuro caso ele realmente se manifeste.
        Segundo PRESSMAN (2006), “se um problema de projeto difícil é encontrado […] o XP recomenda a criação imediata de um protótipo operacional daquela parte do projeto. Denominado ‘Solução de Ponta’, este protótipo é implementado e avaliado”.
        Ao longo das reuniões de Integração, o design precisa evoluir, mas deve manter-se simples e claro para que a equipe possa fazer alterações no software a qualquer momento e com facilidade.
        Mais uma vez, isso só é possível com Refatoração e TDD.
        
        Prática 10. Metáfora
        Muitas vezes, alguém está explicando algo e não há nada que faça o interlocutor compreendê-lo. Depois de algumas tentativas, a pessoa faz uma comparação daquele assunto com algo que o interlocutor conhece bem. Neste momento, em um instante, consegue entender toda a explicação simplesmente porque a outra pessoa utilizou um artifício chamado Metáfora.
        O XP utiliza a Metáfora para comunicar diversos aspectos do projeto e criar uma visão comum. A equipe deve buscar Metáforas que permitam explicar as ideias centrais do projeto de forma simples e objetiva. Isso facilitará a comunicação com o cliente e com os outros envolvidos no projeto.
        alar da Metáfora é muito fácil, o problema é criá-la :)
        Desenvolver uma Metáfora é um exercício de criatividade e abstração. Para TELES (2004), é necessário olhar para os lados e pensar nas coisas mais absurdas, tentando relacioná-las com o problema a ser resolvido. Normalmente, um simples “insight” pode economizar meses de trabalho.
        A utilização da Metáfora é uma prática que anda de mãos dadas com Ritmo Sustentável, que será abordado a seguir, pois sem um Ritmo Sustentável fica difícil ter criatividade e boas ideias.
        
        Prática 11. Ritmo sustentável
        
        O XP desaconselha o uso de horas extras, recomendando Ritmos Sustentáveis de trabalho. Por duas razões:
        Permitir que os desenvolvedores trabalhem apenas oito horas por dia é mais humano e demonstra respeito com a individualidade;
        A integridade de cada membro da equipe aumenta a agilidade do projeto.
        Programadores exaustos cometem mais erros, assim, a equipe que não trabalha por um tempo excessivo se mantém mais efetiva.
        Os desenvolvedores devem chegar descansados todos os dias. Pessoas descansadas produzem melhor, têm ideias eficazes, são mais atentas e poupam tempo do desenvolvimento, ou seja, não é vantagem trabalhar mais. Vantagem é trabalhar de forma mais eficaz e inteligente.
        ASTELS (2002) fala da necessidade de equilíbrio entre a carga de trabalho e a de descanso, recomendando que se “trabalhe 100% durante as 40 horas e descanse 100% no resto. Se algum deles não tiver foco feito com 100%, um afetará o outro”.
        O XP compreende a natureza humana do desenvolvimento de software e percebe que trabalhar mais horas significa diminuir o ritmo de produção e atrasar o projeto, por mais estranho que isto possa parecer no início.
        A adoção do Ritmo Sustentável é um desafio a ser vencido! As equipes que conseguem adotar esta prática colhem muitos frutos dela. Seus projetos são mais ágeis, as pessoas convivem de forma mais harmoniosa e não precisam sacrificar a vida pessoal em nome do trabalho.
        
        Prática 12. Integração contínua
        Quando uma nova funcionalidade é implementada ela pode afetar outras que já estavam funcionando. Por isso é imprescindível uma integração que coloque todas as funcionalidades para operarem juntas e certificar que os novos códigos adicionados não esteja quebrando nada dentro do sistema.
        Nos processos clássicos, novos módulos são integrados após um determinado ciclo de desenvolvimento. No XP não é assim! Ao invés de esperar muito tempo para integrar as partes do sistema, a equipe deve integrar com a maior frequência possível, testando o sistema inteiro várias vezes por dia. Essa prática é chamada de Integração Contínua (JEFFRIES, 2001)
        Uma das dificuldades de se integrar diversas vezes ao dia diz respeito ao tempo necessário para fazer o build de todo o sistema, por isso, esse tempo precisa ser mantido baixo ao longo de todo o projeto.
        As formas de conseguir isso são:
        Fazer com que a interdependência (acoplamento) entre os arquivos seja baixa;
        Para softwares compilados, é preciso que o compilador só processe os arquivos que tiverem sido editados e utilize diretamente o código objeto para os demais. Trabalhar com carregamento dinâmico de bibliotecas quando isso for possível é uma ótima alterantiva;
        Para softwares baseados na web, é preciso usar ferramentas para build baseadas em conteinerização (Git HUB actions, Bitbucket Pipelines, TravisCi, CircleCi etc), que instalam o projeto e executam testes sempre que um novo código fonte é adicionado.
        Se o build começar a ficar lento, a equipe precisa tratar logo da questão e descobrir uma forma de mantê-lo rápido. Isso é uma prioridade!
        O uso da Integração Contínua permite que a equipe possa avançar com agilidade ao mesmo tempo que diminui a possibilidade de erros.
        Duas categorias de ferramentas são sumamente necessárias:
        Sistema de controle de versão: é uma ferramenta essencial no processo de integração, pois possibilita facilidade e rapidez na tarefa de obter o código fonte e armazenar as suas mudanças, detectando conflitos entre as versões e oferecendo maneiras de resolvê-los. A mais popular (pelo menos no momento que este artigo foi escrito) é o GIT;
        Ferramenta de build: é uma ferramenta capaz de compilar todo o sistema e executar outras atividades que se façam necessárias. A ferramenta deve ser capaz de obter o código fonte do repositório, instalar as dependências do projeto e executar os Testes Automatizados, devolvendo um feedback sobre a situação atual do projeto
        
        Prática 13. Releases curtos
        O XP objetiva gerar um fluxo contínuo de valor para o cliente, de forma que o projeto produza pequenos avanços gradualmente, buscando grandes recompensas o mais rapidamente possível.
        Para isso acontecer, é preciso implementar Releases Curtos.
        O XP sugere que a equipe de desenvolvimento implemente o quanto antes as funcionalidades mais importantes, solicitando ao cliente que selecione primeiro o conjunto de funcionalidades que poderá gerar o valor mais alto. Assim, os primeiros Releases deverão fornecer o máximo de valor, de modo que o cliente consiga obter retorno o mais rápido possível.
        Trabalhando com Releases Curtos, o cliente tem oportunidade de avaliar o projeto com mais frequência, tendo mais chances de reduzir eventuais despesas caso o projeto não esteja atingindo os resultados esperados.
        A abordagem tradicional é mais arriscada que a do XP, pois os usuários não têm a chance de avaliar o software sempre, e o projeto só começa a gerar receita após a conclusão.