UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

Transcrição

1 UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013.

2 Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega rápido Princípios Envolvimento do cliente Entrega incremental Pessoas, não processos Aceitar mudanças Manter a simplicidade Questões técnicas, humanas e organizacionais Dificuldades

3 Revisão aula anterior extreme Programming Princípios Planejamento incremental Pequenos releases Projeto simples Desenvolvimento test-first Refatoração Programação aos pares Propriedade coletiva integração continua Ritmo sustentável Cliente no local Cenários estórias do usuário

4 Teste em XP Testes são fundamentais em XP e são escritos antes de escrever o código Isto é, você pode executar o teste enquanto o código está sendo escrito e pode encontrar problemas durante o desenvolvimento As principais características dos testes em XP são: Desenvolvimento test-first Desenvolvimento de teste incremental a partir de cenários Envolvimento dos usuários no desenvolvimento dos testes e validação Uso de frameworks de testes automatizados

5 Desenvolvimento test-first Escrever testes antes do código esclarece os requisitos a serem implementados Testes são escritos como componentes executáveis geralmente utilizando um framework automatizado de teste JUnit Dessa forma, há sempre um conjunto de teste que podem ser executados rapidamente e com facilidade O programa é testado depois de cada alteração Todos os testes anteriores e novos são executados automaticamente quando uma nova funcionalidade foi adicionada Assim problemas introduzidos pelo novo código são detectados imediatamente

6 Envolvimento do cliente O papel do cliente no processo de teste é ajudar a desenvolver testes de aceitação para as histórias que estão a ser implementadas na próxima versão do sistema O cliente que faz parte da equipe escreve testes como o desenvolvimento avança. Todo novo código é, portanto, validada para garantir que ele é o que as necessidades do cliente No entanto, as pessoas que adotam o papel de cliente tem pouco tempo disponível e, portanto, não pode trabalhar em tempo integral com a equipe de desenvolvimento. Eles podem sentir que o fornecimento dos requisitos era o suficiente de uma contribuição e assim podem estar relutantes em se envolver no processo de teste Dessa forma, os testes automatizados conseguem simular a submissão de entrada a ser testado, como se fosse o cliente, e também verificar se a saída atende as necessidades do cliente

7 Descrição do caso de teste para verificação de dose Teste 4: Verificação de dose Entrada: 1. Um número em mg representando uma única dose da medicação 2. Um número que representa o número de doses únicas no dia Testes: 1. Teste para entradas em que a dose única é correta, mas a frequência é muito baixa 2. Teste para entradas em que a dose única é muito alto e muito baixa 3. Teste para entradas em que a dose única x frequência é muito alta e muito baixa 4. Teste para entradas em que a dose única x frequência é permitida Saída: Mensagem de OK ou erro indicando que a dose está fora da faixa

8 Dificuldades de testes em XP Programadores preferem programar para estes e, por vezes, tomam atalhos ao escrevê-los Por exemplo: eles talvez escrevam testes incompletos que não verificam todas as possíveis exceções que podem ocorrer Alguns testes podem ser muito difíceis de escrever de forma incremental Por exemplo: em uma interface complexa de usuário, muitas vezes é difícil escrever testes unitários para o código que implementa a lógica de exibição e o workflow entre as telas É difícil julgar a completude de um conjunto de teste Embora você possa ter vários testes do sistema, o conjunto pode não fornecer uma cobertura completa Partes essências do sistema podem não ser executadas e, assim, permanecer não testadas

9 Programação em Pares Em XP, programadores trabalham em duplas, eles se sentam juntos para desenvolver o código E de maneira dinâmica, as duplas mudam! Dá suporte a ideia da propriedade e responsabilidade coletiva para o sistema Serve como um processo de revisão informal pois cada linha de código é inspecionada por, pelo menos, duas pessoas Incentiva refatoração pois toda a equipe pode se beneficiar com isso As medições sugerem que a produtividade de desenvolvimento com programação em pares é semelhante ao de duas pessoas que trabalham de forma independente No entanto, o compartilhamento de conhecimento que acontece durante a programação em pares reduz os riscos globais para um projeto quando há saída de membros da equipe a faz valer a pena

10 Gerenciamento Ágil de Projetos A principal responsabilidade dos gerentes de projeto de software é gerenciar o projeto para que o software seja entregue no prazo e dentro do orçamento previsto para o projeto A abordagem padrão para gerenciamento de projetos é dirigida a planos Os gerentes devem elaborar um plano para o projeto mostrando o que deve ser entregue, quando deve ser entregue e quem vai trabalhar no desenvolvimento das entregas do projeto Gerenciamento ágil de projetos requer uma abordagem diferente, que é adaptada para o desenvolvimento incremental e os pontos fortes dos métodos ágeis

11 Scrum A abordagem Scrum é um método ágil geral, mas seu foco está no gerenciamento do desenvolvimento iterativo, ao invés das abordagens técnicas específicas da engenharia de software ágil Há três fases no Scrum: A fase inicial é uma fase de planejamento geral, em que se estabelecem os objetivos gerais do projeto e da arquitetura do software Isto é seguido por uma série de ciclos de sprint, sendo que cada ciclo desenvolve um incremento no sistema A fase de encerramento do projeto termina o projeto, completa a documentação exigida, como quadros de ajuda do sistema e manuais do usuário, e avalia as lições aprendidas com o projeto

12 O processo Scrum

13 O ciclo Sprint Sprints são de comprimento fixo, normalmente duas ou quatro semanas Eles correspondem ao desenvolvimento de um release do sistema em XP O ponto de partida para o planejamento é o backlog do produto, que é a lista do trabalho a ser feito no projeto A fase de seleção envolve todos da equipe do projeto que trabalham com o cliente para selecionar os recursos e as funcionalidades a ser desenvolvida durante o sprint

14 O ciclo Sprint Uma vez que todos estejam de acordo, a equipe se organiza para desenvolver o software. Nesta etapa, a equipe está isolada do cliente e da organização, com todas as comunicações canalizadas por meio do Scrum Master O papel do Scrum Master é proteger a equipe de desenvolvimento de distrações externas No fim do sprint, o trabalho é revisto e apresentado aos stakeholders. O próximo ciclo de sprint começa em seguida

15 Trabalho em Equipe no Scrum O Scrum Master é um facilitador, que organiza reuniões diárias, controla o backlog, registra decisões, mede o progresso comparado ao backlog e se comunica com os clientes e a gerencia externa à equipe Toda a equipe participa das reuniões diárias onde os membros da equipe compartilham informações rápida, descrevem seu progresso desde a ultima reunião, os problemas que tem surgido e o que esta planejado para o dia seguinte Isso significa que todos os membros da equipe saibam o que está acontecendo e, se surgirem problemas, poderão replanejar o trabalho de curto prazo para lidar com eles

16 Benefícios do Scrum O produto é decomposto em um conjunto de partes gerenciáveis e compreensíveis Requisitos instáveis não atrasam o progresso Toda a equipe tem visão de tudo, e, consequentemente, a comunicação da equipe é melhorada Os clientes veem a entrega de incrementos dentro do prazo e recebem feedback sobre como o produto funciona Estabelece-se confiança entre os clientes e desenvolvedores e cria-se uma cultura positiva, na qual todo mundo espera que o projeto tenha êxito

17 Escalamento de métodos ágeis Os métodos ágeis têm se mostrado bem-sucedidos no desenvolvimento de sistemas de pequeno e médio porte Às vezes se argumenta que o sucesso destes métodos vem por causa da melhoria das comunicações que é possível quando todos estão trabalhando juntos Equipe de programação de pequeno porte trabalhando na mesma sala e se comunicando de maneira informal O escalamento de métodos ágeis envolve a mudança destes para lidar com projetos maiores e mais longos, onde há várias equipes de desenvolvimento, talvez trabalhando em locais diferentes

18 Desenvolvimento de sistemas grandes Sistemas de grande porte geralmente são coleções de sistemas separados que se comunicam, nos quais equipes de desenvolvimento separadas desenvolvem cada um dos sistemas Frequentemente, essas equipes estão em lugares diferentes e, possivelmente, em fusos horários diferentes Sistemas de grande porte são brownfield systems, isto é, incluem e interagem com inúmeros sistemas existentes. Muito dos requisitos do sistema estão preocupados com essa iteração; assim, realmente não se prestam à flexibilidade e desenvolvimento incremental Sempre que vários sistemas estão integrados para criar um único, uma fração significativa do desenvolvimento preocupase com a configuração do sistema e não com o código

19 Desenvolvimento de sistemas grandes Sistemas de grande porte e seus processos de desenvolvimento são frequentemente restringidos pelas regras externar e regulamentos que limitam o desenvolvimento Sistemas de grande porte têm longo tempo de aquisição e desenvolvimento É difícil manter equipes coerentes que saibam sobre o sistema durante esse período, pois as pessoas, inevitavelmente, deslocam-se para outros trabalhos e projetos Sistemas de grande porte geralmente têm um conjunto diverso de stakeholders É praticamente impossível envolver, no processo de desenvolvimento, todos esses diferentes stakeholders

20 Scaling out e scaling up Há duas perspectivas no escalamento de métodos ágeis: Perspectiva scaling up, relacionada ao uso desses métodos para desenvolver sistemas de software de grande porte que não podem ser desenvolvidos por uma equipe pequena Perspectiva scaling down, relacionada com a forma como os métodos ágeis podem ser introduzidos em uma grande organização com muitos anos de experiência em desenvolvimento de software Quando escalando métodos ágeis é essencial manter os seus fundamentos básicos: Planejamento flexível, frequentes releases do sistema, integração continua, desenvolvimento dirigido a testes e boa comunicação entre os membros da equipe

21 Scaling up para sistemas grandes Para o desenvolvimento de sistemas de grande porte, não é possível se concentrar apenas no código do sistema. Você precisa fazer mais projeto adiantado e documentação do sistema Mecanismos de comunicação entre as equipes têm de ser projetados e usados Isto deve envolver telefonemas e videoconferências regulares entre os membros da equipe, bem como reuniões eletrônicas curtas e frequentes nas quais os membros da diversas equipes se atualizam sobre o progresso um dos outros A integração contínua, em que todo o sistema é construído toda vez que um desenvolvedor verifica uma mudança, é praticamente impossível No entanto, é essencial manter construções frequentes e releases regulares

22 Scaling down para grandes companhias Os gerentes de projetos que não têm experiência de métodos ágeis podem ser relutantes em aceitar o risco de uma nova abordagem Nas grandes organizações existem procedimentos e padrões de qualidade que todos os projetos devem seguir e, por causa de sua natureza burocrática, geralmente são incompatíveis com os métodos ágeis Métodos ágeis parecem funcionar melhor quando os membros da equipe têm um nível de habilidade relativamente alta. No entanto, dentro das grandes organizações, é possível encontrar uma ampla gama de habilidades e competências Pode haver resistência cultural para os métodos ágeis, especialmente em organizações que têm uma longa história de uso de processos convencionais de engenharia de sistemas

23 Resumo Um ponto forte da Extreme Programming é o desenvolvimento de testes automatizados antes da criação de um recurso do programa Quando um incremento é integrado ao sistema, todos os testes devem ser executados com êxito O método Scrum é um método ágil que oferece um framework de gerenciamento de projeto Ele é centralizado em torno um conjunto de sprints, que são períodos determinados de tempo, quando um incremento de sistema é desenvolvido. O escalamento de métodos ágeis para sistemas de grande porte é difícil Tais sistemas necessitam de projeto adiantado e alguma documentação A integração contínua é praticamente impossível

24 Referências Engenharia de Software 9º Edição. Sommerville, I. Editora Persson. Capítulo 3