Assuntos abordados
Métodos ágeis
Técnicas de desenvolvimento ágil Gestão ágil de projetos
Desenvolvimento de software rápido
O desenvolvimento rápido e consequentemente a entrega rápida, são agora frequentemente o requisito mais importante para sistemas de software
As empresas operam muito rapidamente, os requisitos estão em constante mudança, praticamente é impossível produzir um conjunto de requisitos de software estáveis.
Software tem que evoluir rapidamente para refletir mudanças nas necessidades de negócios.
O desenvolvimento seguindo o modelo plano é essencial para alguns tipos de sistema, mas não atende a essas necessidades de negócios. Métodos ágeis de desenvolvimento surgiu no final de 1990, cujo objetivo era reduzir radicalmente o tempo de entrega para sistemas de software
Desenvolvimento ágil
As tarefas de especificação, design e implementação são intercaladas.
O sistema é desenvolvido como uma série de versões ou com incrementos.
Entrega frequente de novas versões para avaliação
Suporte para ferramentas extensas (por exemplo, ferramentas de testes automatizados) utilizada para suportar o desenvolvimento.
Desenvolvimento plano e desenvolvimento ágil
Desenvolvimento plano
Iteração ocorre dentro das atividades. Desenvolvimento ágil
Especificação, projeto, implementação e testes estão
intercaladas e as saídas do processo de desenvolvimento são decididos através de uma negociação durante o processo de
Métodos ágeis
A insatisfação com os custos gerais envolvidos no design de software nos anos 1980 e 1990 levaram à criação de métodos ágeis. Estes métodos:
Foco no código em vez do design
São baseados numa abordagem iterativa para desenvolvimento software
São destinados para entregar rapidamente software functional e evoluir este rapidamente para atender às necessidades de mudança.
O objectivo dos métodos ágeis é reduzir os custos no processo de software (por exemplo, por documentação limitante) e de ser capaz de responder rapidamente as mudanças nos requisitos sem retrabalho excessivo.
Os princípios dos métodos ágeis
Capítulo 3 Desenvolvimento Agile de 10 Princípio Descrição
Envolvimento do Cliente
Os clientes devem estar intimamente envolvidos em todo o processo de desenvolvimento. O Seu papel é fornecer e priorizar novos requisitos do sistema e avaliar as iterações do sistema.
Entrega incremental O software é desenvolvido em incrementos com o cliente a especificar os requisitos para serem incluídos em cada incremento.
As pessoas não processos
As habilidades da equia de desenvolvimento deve ser reconhecido e explorado. Os membros da equipa devem ter autonomia para desenvolver suas próprias formas de trabalhar sem processos prescritivos.
Aceitar a mudança Alterar os requisitos do sistema obdecendo às mudanças e assim projetar o sistema para implementar essas mudanças. Manter a simplicidade Foco na simplicidade, tanto no software que está a ser
desenvolvido como no processo de desenvolvimento. Sempre que possível, trabalhar ativamente para eliminar a complexidade do sistema.
Aplicabilidade do método ágil
Desenvolvimento de produtos, onde uma empresa de software está a desenvolver um produto de pequeno ou médio porte para venda.
Praticamente todos os produtos de software e aplicativos são agora desenvolvido utilizando uma abordagem ágil
Desenvolvimento de sistemas personalizados dentro de uma organização, onde há um claro compromisso do
cliente para se envolver no processo de
desenvolvimento e onde existem algumas regras e regulamentos externos que afetam o software.
Programação extrema
Um método ágil muito influente, desenvolvido na década de 1990, que introduziu uma série de técnicas de desenvolvimento ágil.
Extreme Programming (XP) tem uma abordagem 'extrema' para o desenvolvimento iterativo.
Novas versões podem ser construídas várias vezes por dia;
Incrementos são entregues aos clientes a cada 2 semanas;
Todos os testes devem ser executados para cada construção e a construção só é aceite se os testes forem executados com êxito.
Práticas de programação extremas
Princípio ou prática Descrição
Planeamento incremental
Cada incremento é alvo de um planeamento individual.
Lançamentos pequenos Um conjunto útil mínimo de funcionalidades que fornece o valor do negócio é desenvolvido em primeiro lugar. Versões do sistema são frequentes e incrementalmente adicionam-se funcionalidade.
Design simples Design é realizado para atender às exigências atuais e nada mais.
Testar o
desenvolvimento
Uma estrutura de teste de unidade automatizado é usado para escrever testes para uma nova funcionalidade antes que a funcionalidade seja implementada.
Refatoração Todos os desenvolvedores são esperados para refactoro código continuamente o mais rapidamente possível melhorias de código são encontradas. Isso mantém o código simples e de
Práticas de programação extremas
Capítulo 3 Desenvolvimento Agile de 16
Programação em pares Os programadores trabalham em equipa, verificando o trabalho uns dos outros e proporcionando o apoio.
Propriedade coletiva A equipa de programadores trabalha em todas as áreas do sistema, há algumas especificações de especialização a desenvolver e todos os programadores assumem a responsabilidade por todo o código.
Integração contínua Assim que uma tarefa estiver concluída, ela é integrada no sistema. Depois dessa integração, todos os testes de unidade no sistema deve ser feitos.
Ritmo sustentável Grandes quantidades de horas extras não são considerados aceitáveis, isso origina a redução da qualidade do código e da produtividade a médio prazo.
On-site do cliente Um representante do utilizador final do sistema (o cliente) deve estar disponível a tempo inteiro para o uso da equipa de desenvolvimento. Em um processo de programação extrema, o cliente é um membro da equipa de desenvolvimento e é responsável por trazer os requisitos de sistema para a equipa de implementação.
Programação extrema e princípios ágeis
Desenvolvimento incremental é suportado através de pequenas e frequentes versões do sistema.
O envolvimento do cliente significa o envolvimento do cliente em tempo integral com a equipa.
As mudanças são suportadas de lançamentos regulares de versões do sistema.
Manter a simplicidade através de refactoring constante de código.
Práticas influentes na programação extrema
Programação extrema tem um foco técnico e não é fácil de integrar com a prática de gestão na maioria das organizações.
Consequentemente, enquanto o desenvolvimento ágil utiliza práticas da programação extrema, o método como originalmente definido não é amplamente utilizado.
Práticas chaves
Uso do conhecimento dos utilizadores para a especificação Refatoração
Testar sempre os desenvolvimentos Programação em equipa
Uso dos utilizadores para requisitos
Na programação estrema, o cliente ou utilizador são parte da equipa, e são responsáveis pela tomada de decisões sobre requisitos.
Os requisitos do utilizador são expressos como narrativas dos utilizadores ou cenários/situações.
Estes são documentados e a equipa de desenvolvimento dividi-os em tarefas de execução. Essas tarefas são a base de estimativas de custos e do cronograma.
O cliente escolhe os requisitos para inclusão na próxima versão, com base nas suas prioridades e nas estimativas do cronograma.
Exemplos de tarefas para a prescrição de medicamentos
Refatoração
Em engenharia de software é natural projetar uma mudança. Assim, vale a pena gastar tempo e esforço antecipando mudanças, assim reduz-se os custos mais tarde no ciclo de vida.
Contudo, programação extrema sustenta que isso é impraticável, porque as alterações não podem ser antecipados de forma confiável.
Em vez disso, propõe a melhoria constante do código (refactoring) para fazer alterações mais facilmente quando estas têm de ser implementadas.
Refatoração
A equipa de programação procura possíveis melhorias e fazer essas melhorias no software, mesmo onde não há necessidade imediata das mesmas.
Isso melhora a compreensibilidade do software e assim reduz a necessidade de documentação.
Mudanças são mais fáceis de fazer, porque o código é bem estruturado e claro.
No entanto, algumas mudanças requerem nova
Exemplos de refazer trabalho
Reorganização de uma hierarquia de classes para remover código duplicado.
Arrumar e renomear atributos e métodos para torná-los mais fáceis de entender.
A substituição de código embutido com chamadas para métodos que foram incluídos numa biblioteca de programas.
Testar o desenvolvimento
O teste é central para a programação extrema, esta desenvolveu uma abordagem onde o programa é testado depois de cada alteração foi feita.
Características dos testes em programação extrema: Testar o desenvolvimento primeiro.
Teste incremental dos desenvolvimento de cenários.
O envolvimento do utilizador no desenvolvimento de testes e validação.
Série de testes automatizados são usados para executar todos os testes de componentes cada vez que uma nova versão é construída.
Desenvolvimento do plano de testes
Escrever testes antes do código esclarece as exigências a serem implementadas.
Os testes são programados para que possam ser
executadas automaticamente. O teste inclui uma
verificação que tenha executado corretamente.
Geralmente baseia-se num framework de testes, tais como jUnit. Todos os testes anteriores e novos são executados automaticamente quando uma nova funcionalidade é adicionada, verifica-se assim que a nova funcionalidade não introduziu erros.
O envolvimento do cliente
O papel do cliente no processo de teste é ajudar a desenvolver
testes de aceitação para os requisitos que estão a ser
implementados no próximo lançamento do sistema.
O cliente faz parte da equipa e escreve testes a par com o progresso do desenvolvimento. Todo o código novo é validado para garantir que este é o que o cliente precisa.
No entanto, as pessoas que adotam o papel de cliente têm pouco tempo disponível e, portanto, não pode trabalhar em tempo integral com a equipa de desenvolvimento. Eles podem sentir que fornecer os requisitos é o suficiente para a sua contribuição e assim podem estar relutantes em se envolver no processo de teste.
Descrição do caso de teste para a verificação da dose de medicamento
Automação de testes
Automação de testes significa que os testes são escritos como componentes executáveis antes que a tarefa seja implementada
Estes componentes de teste deverão ser stand-alone, deve simular a apresentação de entrada a ser testado e deve verificar se o resultado corresponde a especificação de saída. Uma estrutura de teste automatizado (por exemplo o jUnit) é um sistema que faz com que seja fácil de escrever testes executáveis e apresentar um conjunto de testes para execução.
Dado que a experimentação é automatizado, não é sempre um conjunto de testes que podem ser rapidamente e facilmente executado
Sempre que qualquer funcionalidade é adicionada ao sistema, os testes podem ser executados e os problemas que o novo código introduziu
Problemas com os testes no desenvolvimento
Programadores preferem a programação aos testes e às vezes não planeiam bem os testes. Por exemplo, podem escrever testes incompletos que não verificam para todas as exceções possíveis que possam ocorrer.
Alguns testes podem ser muito difícil de escrever de forma incremental. Por exemplo, uma interface de utilizador complexa, muitas vezes é difícil escrever testes de unidade para o código que implementa a 'lógica de exibição' e fluxo de trabalho entre as telas.
É difícil julgar a completude de um conjunto de testes. Embora possa ter um monte de testes do sistema, o seu conjunto de teste pode não fornecer uma cobertura completa.
A programação em pares
A programação em equipa envolve programadores que trabalham juntos, desenvolvem código juntos.
Isso ajuda a desenvolver código comum e a que toda a equipa o conheça.
Serve como um processo de avaliação informal como cada linha de código é olhado por mais do que uma pessoa.
Estimula a refatoração, onde toda a equipe pode beneficiar com a melhora do código do sistema.
A programação em pares
Na programação em pares, em alguns casos os programadores sentam-se juntos no mesmo computador para desenvolver o software.
Pares são criados dinamicamente para que todos os membros da equipa trabalhem uns com os outros durante o processo de desenvolvimento.
A partilha de conhecimentos que acontece durante a programação em pares é muito importante, pois reduz os riscos globais para um projeto quando algum membro da equipa sair.
A programação em pares não é necessariamente ineficaz e há alguma evidência que sugere que um par a trabalhar em conjunto é mais eficiente do que 2 programadores trabalhar separadamente.
Gestão ágil de projetos
A principal responsabilidade dos gestores de projeto de software é gerir o projeto para que o software seja entregue no prazo e dentro do orçamento.
A abordagem padrão para gerir projetos é orientada para o plano. Gestores elaboram um plano para o projeto mostrando o que deve ser entregue, quando
deve ser entregue e quem irá trabalhar no
desenvolvimento do projeto.
Gestão ágil de projetos requer uma abordagem diferente, que é adaptada para o desenvolvimento incremental e às práticas utilizadas em métodos ágeis.
Scrum
Scrum é um método ágil que se concentra na gestão do desenvolvimento iterativo ao invés de práticas ágeis específicas.
Existem três fases no scrum.
A fase inicial é uma fase de esboço do planeamento onde se estabelecem os objetivos gerais para o projeto e se projeta a
arquitetura do software.
Isto é seguido por uma série de ciclos de sprints, onde cada ciclo desenvolve um incremento do sistema.
A fase de encerramento do projeto, alem da entrega total do software, envolve toda e completa documentação necessária,
Terminologia scrum
Termo Scrum Definição
Equipe de desenvolvimento
Um grupo de auto organizado de programadores de software, onde não devem ser mais do que 7 pessoas. Eles são responsáveis pelo desenvolvimento do software e outros documentos essenciais do projeto. Incremento do produto
potencialmente utilizável
O incremento de software que é entregue a partir de um sprint. A idéia é que este deve ser 'potencialmente utilizável', que significa que ele está em um estado acabado e não necessita de nenhum trabalho adicional, tais como testes, é necessário incorporá-lo no produto final. Na prática, isso nem sempre é possível.
Product backlog Esta é uma lista de itens 'fazer' que a equipe Scrum deve enfrentar. Eles podem ser definições de recurso para o software, requisitos de software, ou descrições de tarefas suplementares que são necessárias, tais como a definição de arquitetura ou a documentação do utilizador.
Product Owner Um indivíduo (ou possivelmente um pequeno grupo), cujo trabalho é identificar características ou requisitos do produto, priorizar estes para o desenvolvimento e rever continuamente a lista de tarefas do produto para garantir que o projeto continua a atender as necessidades críticas de negócios. O Product Owner pode ser um cliente, mas também pode ser um gestor de produto numa empresa de software ou outro representante das partes interessadas.
36 2017/2018
Terminologia scrum
Termo Scrum Definição
Scrum A reunião diária da equipa, onde se analisa os progressos e prioriza trabalho a ser feito naquele dia. Idealmente, esta deve ser uma breve reunião que inclui toda a equipa.
Scrum Master O Scrum Master é responsável por assegurar que o processo Scrum é seguido e orienta a equipa. Ele é responsável pela ligação com o resto da empresa e para garantir que a equipa Scrum não é desviada por interferência externa.
Sprint A iteração de desenvolvimento. Sprints são geralmente 2-4 semanas de duração.
Velocidade Uma estimativa de esforço da equipa num único sprint. Compreender a velocidade da equipa ajuda a estimar o que pode ser realizado num sprint e fornece uma base para medir e melhorar o desempenho.
O ciclo de sprint Scrum
Sprint são de comprimento fixo, normalmente 2-4 semanas.
O ponto de partida para o planeamento é a lista de tarefas, que é a lista de trabalho a ser feito no projeto. A fase de seleção envolve toda a equipa de projeto que
trabalham com o cliente para selecionar os recursos e
funcionalidades da lista de tarefas a serem
O ciclo de Sprint
Uma vez que estes são acordados, a equipe se organizar para desenvolver o software.
Durante esta fase, a equipa está isolada do cliente e da organização, com todas as comunicações canalizadas através do chamado 'Scrum master'.
O papel do mestre de Scrum é proteger a equipa de desenvolvimento de distrações externas.
No final do sprint, o trabalho feito é revisto e apresentado às partes interessadas. O próximo ciclo de Sprint começa.
Trabalho em equipa no Scrum
O 'mestre Scrum' é um facilitador, que organiza reuniões diárias, controla o trabalho a ser feito, registra decisões, mede o progresso contra o atraso e comunica com o clientes e outros gestores fora da equipe.
Toda a equipa participa das reuniões diárias curtas (scrums), onde todos os membros da equipa partilham informações, descrevem o seu progresso desde a última reunião, problemas que surgiram e o que está previsto para o dia seguinte.
Isto significa que todos na equipa sabem o que está a acontecer no projeto e, se surgirem problemas, podem re-planear trabalho
Benefícios de Scrum
O produto é dividido em um conjunto de pedaços geráveis e compreensíveis.
Requisitos instáveis não têm progressão, rapidamente são
detetáveis.
Toda a equipa tem visibilidade de tudo e, consequentemente, a comunicação da equipa é melhorada.
Os clientes recebem o incremento e ficam em condições de darem
feedback sobre como o produto funciona.
A confiança entre clientes e programadores é estabelecida e uma cultura positiva é criada em que todo mundo espera que o projeto tenha sucesso.
Dimensionamento de métodos ágeis
Métodos ágeis têm-se revelado bem sucedidos para pequenos e médios projetos feitos sob medida que podem ser desenvolvidas por uma equipa pequena.
Às vezes é argumentado que o sucesso destes métodos vem por causa das comunicações melhoradas que é possível quando todos trabalham juntos.
Intensificação dos métodos ágeis envolve mudar estes para lidar com projetos maiores, mais longos, onde há várias equipes de desenvolvimento, talvez a trabalhar em locais diferentes.
Problemas práticos com métodos ágeis
A informalidade de desenvolvimento ágil é incompatível com a abordagem legal para a definição do contrato que é comumente usado em grandes empresas.
Métodos ágeis são mais adequados para o
desenvolvimento de novos software, em vez de
manutenção de software. No entanto, a maioria dos custos de software em grandes empresas vêm de manutenção dos seus sistemas de software existentes. Métodos ágeis métodos são projetados para pequenas
equipas, ainda que atualmente o desenvolvimento de software envolva equipas distribuídas por todo o mundo.
Questões contratuais
A maioria dos contratos de software para sistemas
personalizados são baseados em torno de uma
especificação que define o que deve ser implementado pelo programador do sistema para o cliente sistema.
No entanto, isso exclui especificação intercalar e desenvolvimento como é a norma no desenvolvimento ágil.
Um contrato que paga por tempo de desenvolvimento em vez da funcionalidade necessária.
Métodos ágeis e manutenção de software
A maioria das organizações gastam mais em manutenção de software existente do que no novo desenvolvimento de software. Então, se os métodos ágeis são para ser bem sucedidos, eles têm de apoiar a manutenção, bem como o desenvolvimento original.
Duas questões-chave:
sistemas que são desenvolvidos usando uma abordagem sustentável ágil, é dada a ênfase no processo de desenvolvimento de minimizar documentação formal?
Podem os métodos ágeis serm utilizados de forma eficaz para a evolução de um sistema em resposta a solicitações de mudança do cliente?
Podem surgir problemas se a equipa de desenvolvimento original não pode ser mantida.
Manutenção ágil
Os principais problemas são: Falta de documentação do produto
Manter os clientes envolvidos no processo de desenvolvimento Manter a continuidade da equipa de desenvolvimento
O desenvolvimento ágil conta com a equipa de desenvolvimento para saber e compreender o que tem que ser feito.
Para os sistemas de longa vida, este é um problema real, como os programadores originais não continuam no projeto.
Métodos ágeis e planeados
A maioria dos projetos incluem elementos de processos baseados em modelos planos e ágeis. Decidir sobre o equilíbrio depende:
É importante ter uma especificação muito detalhada e design antes de passar para a implementação? Se assim for, provavelmente precisará usar uma abordagem orientada para o plano.
É uma estratégia de entrega incremental, onde entregar o software ao clientes e obter feedback rápido a partir deles é realista? Se assim for, considerar o uso de métodos ágeis.
Quão grande é o sistema que está a ser desenvolvido? Métodos ágeis são mais eficazes quando o sistema pode ser desenvolvido com uma equipa pequena que pode se comunicar informalmente. Isto pode não ser possível para sistemas de grande porte que exigem equipas de desenvolvimento maiores, assim uma abordagem baseada em plano deve ser usada.
Princípios ágeis e prática organizacional
Princípio Prática
O envolvimento do cliente Isso depende de ter um cliente que está disposto e capaz de passar tempo com a equipa de desenvolvimento e que podem representar todos os stakeholders do sistema. Muitas vezes, os representantes dos clientes têm outras obrigações ao mesmo tempo e não podem desempenhar um papel integral no desenvolvimento de software.
Aceite a mudança Periorizar as mudanças pode ser extremamente difícil, especialmente em sistemas para os quais há muitas partes interessadas. Tipicamente, cada uma das partes interessadas transmite diferentes prioridades para diferentes alterações.
Entrega incremental Iterações rápidas e planeamento a curto prazo para o desenvolvimento nem sempre se encaixa com os ciclos de planeamento a longo dos negócios e do marketing. Os gestores de marketing podem precisar de saber vários meses de antecedência qual o produto que apresenta para preparar uma campanha de marketing eficaz.
Manter a simplicidade Sob pressão dos prazos de entrega, os membros da equipa podem não ter tempo para realizar simplificações no Sistema.
Problemas do sistema
Quão grande é o sistema que está a ser desenvolvido?
Métodos ágeis são mais eficazes numa equipa pequena que pode comunicar informalmente.
Que tipo de sistema está a ser desenvolvido?
Sistemas que requerem muita análise antes da implementação, necessitam de um design bastante detalhado para realizar esta análise.
Qual é a vida útil do sistema esperado?
Sistemas de longa vida exigem documentação para comunicar a intenções dos programadores para a equipe de suporte.
É o sistema sujeito a regulação externa?
Se um sistema é regulado, provavelmente será necessário para produzir documentação detalhada como parte do plano de segurança do sistema.
Pessoas e equipas
Como bom são os designers e programadores na equipa de desenvolvimento?
Por vezes argumenta-se que os métodos ágeis exigem níveis mais elevados do que as abordagens baseadas plano em que os programadores simplesmente traduzem um projeto detalhado em código.
Como a equipa de desenvolvimento se organizada?
Documentação do projeto é necessária se a equipa está distribuída.
Questões organizacionais
Organizações tradicionais de engenharia têm uma cultura de desenvolvimento baseado no plano, pois esta é a norma em engenharia.
É prática padrão organizacional desenvolver uma especificação detalhada do sistema?
Representantes do cliente vão estar disponíveis para fornecer feedback de incrementos do sistema?
Desenvolvimento ágil informal pode caber na cultura organizacional da documentação detalhada?
Métodos ágeis para grandes sistemas
Grandes sistemas são geralmente coleções de sistemas separados que comunicam, onde equipas diferentes desenvolvem sistemas diferentes. Frequentemente, essas equipas trabalham em lugares diferentes, por vezes, em diferentes fusos horários.
Grandes sistemas incluem e interagem com um número de sistemas existentes. Muitos dos requisitos do sistema estão preocupados com essa interação e assim realmente não se prestam a flexibilidade e desenvolvimento incremental.
Onde vários sistemas são integrados para criar um sistema, uma fração significativa do desenvolvimento está preocupado com a configuração do sistema, em vez de desenvolvimento de código original.
Desenvolvimento em grandes sistemas
Grandes sistemas e os seus processos de desenvolvimento são muitas vezes limitados por regras externas e regulamentos que limitam a maneira que eles podem ser desenvolvidos.
Grandes sistemas têm uma longa aquisição e duração desenvolvimento. É difícil manter equipas coerentes que sabem sobre o sistema durante esse período como, inevitavelmente, as pessoas passarem para outros trabalhos e projetos.
Sistemas grandes geralmente têm um conjunto diversificado de stakeholders. É praticamente impossível envolver todas estas diferentes partes interessadas no processo de
Ampliando a grandes sistemas
Uma abordagem completamente incremental para engenharia de requisitos é impossível.
Não pode haver um dono único do produto ou representante do cliente.
Para o desenvolvimento de sistemas de grande porte, não é possível focar apenas no código do sistema.
Mecanismos de comunicação entre as equipes têm que ser concebidos e utilizados.
A integração contínua é praticamente impossível. No entanto, é essencial para manter o sistema em frequente alteração e lançar regularmente novas versões do sistema.
Métodos ágeis nas organizações
Os gestores de projeto que não têm experiência em métodos ágeis podem estar relutantes em aceitar o risco de uma nova abordagem. As grandes organizações têm muitas vezes procedimentos de
qualidade e padrões que são seguidos em todos os projetos, devido à sua natureza burocrática, estes são suscetíveis de ser incompatível com métodos ágeis.
Métodos ágeis parecem funcionar melhor quando os membros da equipe têm um nível relativamente alto de habilidade.
Pode haver resistência cultural aos métodos ágeis, especialmente nas organizações que têm uma longa história de uso de processos de engenharia de sistemas convencionais.
Pontos chave
Métodos ágeis são métodos incrementais de desenvolvimento que
se concentram no desenvolvimento de software rápido,
lançamentos freqüentes do software, reduzindo despesas gerais de processo, minimizando documentação e produzir código de alta qualidade.
Práticas ágeis de desenvolvimento incluem
Requesitos dos utilizadores para a especificação do sistema Lançamentos freqüentes do software,
Melhoria contínua do software Testar o desenvolvimento
Pontos chave
Scrum é um método ágil que oferece uma estrutura de gestão de projeto.
É centrado em volta de um conjunto de sprints, que são fixadosem períodos de tempo quando um incremento sistema é desenvolvido.
Muitos métodos de desenvolvimento práticos são uma mistura de desenvolvimento baseado em plano e ágil. Dimensionamento métodos ágeis para grandes sistemas
