You are on page 1of 7

PROJETO E ARQUITETURA DE SOFTWARE FIG - UNIMESP PROFESSOR LUIZ JOAO DE SA NOVAIS JUNIOR ALUNO VITOR HUGO DE MAGALHES R.A.

. 00036

Scrum
Scrum uma metodologia gil para gesto e planejamento de projetos de software. Se voc chegou at aqui interessado em fazer uma das certificaes disponveis para Scrum, veja por que dizemos no certificao? No Scrum, os projetos so dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias geis de desenvolvimento de software so iterativas, ou seja, o trabalho dividido em iteraes, que so chamadas de Sprints no caso do Scrum. As funcionalidades a serem implementadas em um projeto so mantidas em uma lista que conhecida como Product Backlog. No incio de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunio de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela ser capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint so transferidas do Product Backlog para o Sprint Backlog. A cada dia de uma Sprint, a equipe faz uma breve reunio (normalmente de manh), chamada Daily Scrum. O objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia. Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do prximo Sprint. Assim reinicia-se o ciclo. Veja a ilustrao abaixo:

Product Backlog O Product Backlog uma lista contendo todas as funcionalidades desejadas para um produto. O contedo desta lista definido pelo Product Owner. O Product Backlog no precisa estar completo no incio de um projeto. Pode-se comear com tudo aquilo que mais bvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda medida que se aprende mais sobre o produto e seus usurios.

Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe ento determina que itens ser capaz de completar durante a Sprint que est por comear. Tais itens so, ento, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas tcnicas ou atividades diretamente relacionadas s funcionalidades solicitadas. Sprint Backlog O Sprint Backlog uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog so extrados do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepo da equipe sobre o tempo que ser necessrio para completar as vrias funcionalidades. Cabe a equipe determinar a quantidade de itens do Product Backlog que sero trazidos para o Sprint Backlog, j que ela quem ir se comprometer a implement-los. Durante um Sprint, o Scrum Master mantm o Sprint Backlog atualizando-o para refletir que tarefas so completadas e quanto tempo a equipe acredita que ser necessrio para completar aquelas que ainda no esto prontas. A estimativa do trabalho que ainda resta a ser feito no Sprint calculada diariamente e colocada em um grfico, resultando em um Sprint Burndown Chart. Daily Scrum A cada dia do Sprint a equipe faz uma reunio diria, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. Os Daily Scrums normalmente so realizadas no mesmo lugar, na mesma hora do dia. Idealmente so realizados na parte da manh, para ajudar a estabelecer as prioridades do novo dia de trabalho. Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas tambm podem estar presentes, mas s podero escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informaes sobre o estado do projeto. O Daily Scrum no deve ser usado como uma reunio para resoluo de problemas. Questes levantadas devem ser levadas para fora da reunio e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucion-lo. Durante o Daily Scrum, cada membro da equipe prov respostas para cada uma destas trs perguntas: O que voc fez ontem? O que voc far hoje? H algum impedimento no seu caminho? Concentrando-se no que cada pessoa fez ontem e no que ela ir fazer hoje, a equipe ganha uma excelente compreenso sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum no uma reunio de status report na qual um chefe fica coletando informaes sobre quem est atrasado. Ao invs disso, uma reunio na qual membros da equipe assumem compromissos perante os demais. Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possvel.

Sprint Review Meeting Ao final de cada Sprint feito um Sprint Review Meeting. Durante esta reunio, o Scrum Team mostra o que foi alcanado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades. Os participantes do Sprint Review tipicamente incluem o Product Owner, o Scrum Team, o Scrum Master, gerncia, clientes e engenheiros de outros projetos. Durante o Sprint Review, o projeto avaliado em relao aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo que a equipe atinja o objetivo geral do Sprint. Sprint Retrospective O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que aes sero tomadas para melhorar. Fonte: http://improveit.com.br/scrum Extreme Programming Extreme Programming (XP) uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da dcada de 90. Vem fazendo sucesso em diversos pases, por ajudar a criar sistemas de melhor qualidade, que so produzidos em menos tempo e de forma mais econmica que o habitual. Tais objetivos so alcanados atravs de um pequeno conjunto de valores, princpios e prticas, que diferem substancialmente da forma tradicional de se desenvolver software. Manifesto gil Indivduos e interaes entre eles mais que processos e ferramentas; Software em funcionamento mais que documentao abrangente; Colaborao com o cliente mais que negociao de contratos; Responder a mudanas mais que seguir um plano. Fonte: http://improveit.com.br/scrum

FDD - Feature Driven Development


Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) uma metodologia gil para gerenciamento e desenvolvimento de software. Ela combina as melhores prticas do gerenciamento gil de projetos com uma abordagem completa para Engenharia de Software orientada por objetos, conquistando os trs principais pblicos de um projeto de software: clientes, gerentes e desenvolvedores. Seus princpios e prticas proporcionam um equilbrio entre as filosofias tradicionais e as mais extremas, proporcionando uma transio mais suave para organizaes mais conservadoras, e a retomada da responsabilidade para as organizaes que se desiludiram com as propostas mais radicais.

A FDD uma metodologia muito objetiva. Possui apenas duas fases: Concepo & Planejamento: Pensar um pouco antes de fazer (tipicamente de 1 a 2 semanas) Construo: Fazer de forma iterativa (tipicamente em iteraes de 2 semanas) Os cinco processos so bem definidos e integrados: 1.DMA (Desenvolver um Modelo Abrangente): Anlise Orientada por Objetos 2.CLF (Construir a Lista de Funcionalidades): Decomposio Funcional 3.PPF (Planejar por Funcionalidade): Planejamento Incremental 4.DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos 5.CPF (Construir por Funcionalidade): Programao e Teste Orientados por Objetos Fonte: http://www.heptagon.com.br/fdd

Rapid Application Development


Rapid Application Development (RAD) ou Desenvolvimento Rpido de Aplicao (em portugus), um modelo de processo de desenvolvimento de software iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias). O termo foi registrado por James Martin em 1991 e tem substitudo gradativamente o termo de prototipao rpida que j foi muito utilizada no passado Histrico Os modelos de processo de software apresentados durante a dcada de 70, cujo o modelo em cascata um bom representante, possuam longos perodos de desenvolvimento e muitas vezes os requisitos do sistema se alteravam antes do fim do processo. Os desenvolvedores de software necessitavam de um modelo mais gil que permitisse um tempo de desenvolvimento mais curto e a mudana dos requisitos durante o processo. Nos anos 80 os trabalhos de Barry Boehm (modelo de processo em espiral) e Tom Gilb (modelo de processo evolucionrio) serviram de base para uma metodologia chamada de Rapid Iterative Production Prototyping (RIPP) criada por Scott Shultz. James Martin estendeu o RIPP agregando valores de outros processos tornando-o maior e mais formal sendo assim denominado de RAD. O RAD foi finalmente formalizado em 1991 com a publicao de um livro.

O Processo O nmero de fases do processo varia de acordo com os autores. Segundo Kerr, o processo se divide em 5 fases: Modelagem de Negcio O fluxo de informaes entre as funes de negcio modelado de modo a responder s seguintes questes: - Que informao direciona o processo de negcio? - Que informao gerada? - Quem a gera? - Para onde vai informao? - Quem a processa? Na modelagem de negcio so levantados os processos suportados pelo sistema. Modelagem dos dados A modelagem de dados responde a um conjunto de questes especficas que so relevantes a qualquer aplicao. O fluxo de informao definido na fase de modelagem de negcio refinado e de forma a extrair os principais objetos de dados a serem processados pelo sistema, qual a composio de cada um dos objetos de dados, onde costumam ficar, qual a relao entre eles e quais as relaes entre os objetos e os processos que os transformam. Modelagem do Processo Os objetos de dados definidos na modelagem de dados so transformados para conseguir o fluxo necessrio para implementar uma funo do negcio. Descries do processamento so criadas para adicionar, modificar, descartar ou recuperar um objeto de dados. Gerao da Aplicao O RAD considera o uso de tcnicas de quarta gerao, trabalha com a reutilizao de componentes de programa existentes quando possvel, ou cria componentes reusveis. So usadas ferramentas automatizadas para facilitar a construo do software. Ex: Clarion, Delphi, Visual Basic, Asp.net, etc. Teste e Modificao Como o processo do RAD enfatiza o reuso, muitos componentes j esto testados, isso reduz o tempo total de teste. Todavia os novos componentes devem ser testados e todas as interfaces devem ser exaustivamente exercitadas. Esta diviso do processo compartilhada por diversos autores inclusive Roger S. Pressman, cuja obra utilizada em diversas faculdades como livro guia para os estudantes. Porm existem outras abordagens utilizadas. Segundo Stephen E. Cross Diretor do SEI - Software Engineering Institute da Carneggie Mellon, uma maneira de abordar o RAD de forma mais eficiente dividi-lo em 6 passos: Projeto e anlise baseado no cenrio Projeto e anlise de Arquitetura Especificao de Componentes com o mximo de reuso Desenvolvimento rpido dos mdulos remanescentes Testes freqentes com o usurio final Campo com ferramentas de suporte para permitir a evoluo A proposta de Stephen disciplinar o RAD, que muitas vezes criticado por sua suposta informalidade, de forma a conseguir at mesmo nveis de CMM - Capability Maturity Model para melhorar e formalizar ainda mais o processo. Fonte: http://ambiente.aied.com.br/UploadFiles/1_RAD.PDF

Test Driven Development


Test Driven Development (TDD) ou em portugus Desenvolvimento dirigido por testes uma tcnica de desenvolvimento de software que baseia em um ciclo curto de repeties: Primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. Ento, produzido cdigo que possa ser validado pelo teste para posteriormente o cdigo ser refatorado para um cdigo sob padres aceitveis. Kent Beck, considerado o criador ou o 'descobridor' da tcnica, declarou em 2003 que TDD encoraja designs de cdigo simples e inspira confiana. Desenvolvimento dirigido por testes relacionado a conceitos de programao de Extreme Programming, iniciado em 1999, mas recentemente tem-se criado maior interesse pela mesma em funo de seus prprios ideais. Atravs de TDD, programadores podem aplicar o conceito de melhorar e depurar cdigo legado desenvolvido a partir de tcnicas antigas. Requisitos Desenvolvimento dirigido por testes requer dos desenvolvedores criar testes de unidade automatizados que definam requisitos em cdigo antes de escrever o cdigo da aplicao. Os testes contm asseres que podem ser verdadeiras ou falsas. Aps as mesmas serem consideradas verdadeiras aps sua execuo, os testes confirmam o comportamento correto, permitindo os desenvolvedores evoluir e refatorar o cdigo. Desenvolvedores normalmente usam Frameworks de testes, como xUnit, para criar e executar automaticamente uma srie de casos de teste. Ciclo de Desenvolvimento Test-driven development.PNG Uma representao grfica de um fluxo de desenvolvimento atravs de um grfico de fluxo A seguinte sequncia baseada no livro Test-Driven Development by Example[1]. 1. Adicione um teste Em Test Driven Development, cada nova funcionalidade inicia com a criao de um teste. Este teste precisa inevitavelmente falhar porque ele escrito antes da funcionalidade a ser implementada (se ele no falha, ento a funcionalidade ou melhoria 'proposta' bvia). Para escrever um teste, o desenvolvedor precisa claramente entender as especificaes e requisitos da funcionalidade. O desenvolvedor pode fazer isso atravs de casos de uso ou user stories que cubram os requisitos e excees condicionais. Esta a diferenciao entre desenvolvimento dirigido a testes entre escrever testes de unidade 'depois' do cdigo desenvolvido. Ele torna o desenvolvedor focado nos requisitos 'antes' do cdigo, que uma sutil mas importante diferena. 2. Execute todos os testes e veja se algum deles falha Esse passo valida se todos os testes esto funcionando corretamente e se o novo teste no traz nenhum equvoco, sem requerer nenhum cdigo novo. Pode-se considerar que este passo ento testa o prprio teste: ele regula a possibilidade de novo teste passar. O novo teste deve ento falhar pela razo esperada: a funcionalidade no foi desenvolvida. Isto aumenta a confiana (por outro lado no exatamenta a garante) que se est testando a coisa certa, e que o teste somente ir passar nos casos intencionados.

3. Escrever cdigo O prximo passo escrever cdigo que ir ocasionar ao teste passar. O novo cdigo escrito at esse ponto poder no ser perfeito e pode, por exemplo, passar no teste de uma forma no elegante. Isso aceitvel porque posteriormente ele ser melhorado. O importante que o cdigo escrito deve ser construdo somente para passar no teste; nenhuma funcionalidade (muito menos no testada) deve ser predita ou permitida em qualquer ponto. 4. Execute os testes automatizados e veja-os executarem com sucesso Se todos os testes passam agora, o programador pode ficar confiante de que o cdigo possui todos os requisitos testados. Este um bom ponto que inicia o passo final do ciclo TDD. 5. Refatorar cdigo Nesse ponto o cdigo pode ser limpo como necessrio. Ao re-executar os testes, o desenvolvedor pode confiar que a refatorao no um processo danoso a qualquer funcionalidade existente. Um conceito relevante nesse momento o de remoo de duplicao de cdigo, considerado um importante aspecto ao design de um software. Nesse caso, entretanto, isso aplica remover qualquer duplicao entre cdigo de teste e cdigo de produo por exemplo magic numbers or strings que ns repetimos nos testes e no cdigo de produo, de forma que faa o teste passar no passo 3. 6. Repita tudo Iniciando com outro teste, o ciclo ento repetido, empurrando a funcionalidade a frente. O tamanho dos passos deve ser pequeno - to quanto de 1 a 10 edies de texto entre cada execuo de testes. Se novo cdigo no satisfaz rapidamente um novo teste, ou outros testes falham inesperadamente, o programador deve desfazer ou reverter as alteraes ao invs do uso de excessiva depurao. A Integrao contnua ajuda a prover pontos revertveis. importante lembrar que ao usar bibliotecas externas no interessante gerar incrementos to pequenos que possam efetivamente testar a biblioteca, a menos que haja alguma razo para acreditar que a biblioteca tenha defeitos ou no seja suficientemte completada com suas funcionalidades de forma a servir s necessidades do programa em que est sendo escrito. Fonte: http://pt.wikipedia.org/wiki/Test_Driven_Development