Métodos Ágeis no Desenvolvimento de Softwares

Definição

Métodos ágeis ou metodologia ágil são termos usados para descrever abordagens de desenvolvimento de software que enfatizam a entrega incremental, a colaboração da equipe, o planejamento contínuo e o aprendizado.

As metodologias e frameworks que fazem parte do conceito de desenvolvimento ágil providenciam uma estrutura conceitual para conduzir projetos de engenharia de software.

O termo “projetos”, no universo do desenvolvimento de software, de acordo com o PMBoK (Project Management Body of Knowledge), significa “esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”.

Métodos ágeis são estratégias e técnicas direcionadas para a colaboração de todos os membros dentro de pequenos ciclos do trabalho, utilizando o desenvolvimento incremental.

Para construir um grande projeto, o ideal é sempre dividi-lo em partes ou funcionalidades menores, para que fique claro o direcionamento que a equipe precisa seguir em cada etapa e se torne mais fácil alocar recursos ou definir o cronograma. Isso permite o controle de recursos e a transparência, além de garantir o feedback do cliente em cada etapa. Tais ações tornam o manejo das mudanças mais simples do que ao final de todos os processos.

O objetivo é mostrar para o cliente a parte ou o módulo do software já criado, obter seu feedback sobre ela e verificar o que precisa ser alterado ou aprimorado antes de planejar o próximo ciclo ou esperar o final do projeto.

Processo histórico:

O conceito de métodos ágeis surgiu em meados da década de 1990, em contraponto aos métodos tradicionais, vistos como burocráticos, lentos e ineficientes. Começaram a surgir processos alternativos de desenvolvimento de software em resposta àqueles tradicionais, considerados excessivamente regrados, lentos, burocráticos e inadequados à natureza da atividade. Esses novos processos foram apelidados de “leves” (lightweight), em oposição aos anteriores, “pesados” (heavyweight).

Os conceitos de agilidade em gestão de projetos surgiram como uma resposta aos desafios impostos pelas metodologias tradicionais, principalmente no mercado de engenharia de software. Uma abordagem comum nesse contexto era o desenvolvimento no modelo waterfall ou em cascata, com fases rígidas e sequenciais, como coleta de requisitos, desenvolvimento e testes.

As metodologias tradicionais demandavam muita documentação e havia a exigência de seguir estritamente o mesmo conjunto de etapas independentemente do que a empresa estava criando no momento. Na fase de análise, os requisitos eram levantados e documentados de forma extremamente detalhada antes do software ser desenvolvido e testado.

Trata-se de um procedimento pouco eficaz para lidar com mudanças ao longo do projeto ou garantir o atendimento das expectativas de forma integral. Quando alguma nova necessidade surgia ou era preciso realizar alterações, o processo voltava para a fase de análise.

Não havia suporte para a interação com o cliente, o que ocasionava um acúmulo de falhas até o final do projeto, gerava produtos que não agradavam aos contratantes e acarretava atrasos que prejudicavam o planejamento inteiro. Além disso, o esforço despendido para atender aos processos e gerar toda a documentação acabava por alongar o cronograma de execução do projeto e aumentando seus custos.

O Manifesto Ágil

Em 2001, uma equipe americana formada por 17 programadores lançou um documento denominado Manifesto Ágil, no qual o conceito é explicado detidamente.

No documento, encontram-se os princípios fundamentais para o desenvolvimento ágil, aplicáveis a todos os tipos de metodologias.

Os 12 princípios propostos pelo Manifesto Ágil são listados abaixo: 

1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

O Manifesto Ágil também defende a prática de quatro valores, a saber:

1. Indivíduos e interações mais do que apenas processos e ferramentas;
2. Softwares que trabalham com documentação muito mais abrangente;
3. Colaboração do cliente que vai além da negociação de contratos;
4. Respostas rápidas, testes contínuos e mudanças ao longo do projeto seguindo um planejamento estruturado.

A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projeto de software em miniatura.

O método incentiva o feedback constante, a abordagem incremental e o encorajamento da comunicação entre as pessoas.

O fator mais importante é provavelmente o tamanho do projeto. Com o aumento do tamanho, a comunicação face a face se torna mais difícil. Portanto, métodos ágeis são mais adequados para projetos com pequenos times, com o máximo de 40 pessoas. O desenvolvimento ágil é particularmente adequado para equipes que têm que lidar com mudanças rápidas ou imprevisíveis nos requisitos.

Ambiente ideal para o desenvolvimento ágil:

• Baixa criticidade.
• Desenvolvedores sênior.
• Mudança frequente de requisitos.
• Pequeno número de desenvolvedores.
• Cultura que tem sucesso no caos.

Os Métodos Ágeis no Brasil:

As ideias ágeis vêm sendo adotadas desde os anos 70 em vários países do mundo. Diversos profissionais reportam que o “pensamento ágil” já era adotado no desenvolvimento de software no Brasil bem antes da formalização do Manifesto Ágil. Por volta de 1999, Klaus Wuestefeld e Vinícius Teles, profissionais de desenvolvimento de software atualmente considerados precursores da agilidade no país, estavam em busca de uma abordagem alternativa que proporcionasse aumento das chances de sucesso no desenvolvimento de software. Para ambos, estava claro que abordagens orientadas a pessoas seriam mais bem-sucedidas, pois projetos melhores eram aqueles que lidavam bem com aspectos humanos e sociais do desenvolvimento de software.

Com a formalização do Manifesto, o movimento pela agilidade no Brasil teve início, em 2001, desencadeado por professores universitários e profissionais da indústria que tiveram contato com o movimento internacional, iniciado em 2000. Palestras sobre Programação Extrema (XP) foram ministradas em universidades e departamentos de Tecnologia da Informação de instituições públicas e empresas privadas.

Alunos de pós-graduação e profissionais da indústria organizaram a primeira edição do AgileBrazil em 2010. Desde então, a cada ano, a conferência tem atraído mais de 800 participantes de todo o país.

Desde 2001, houve diversas iniciativas educacionais no Brasil sobre a promoção de Métodos Ágeis na academia, como as desenvolvidas pelo IME-USP, UFRJ, UFPE, PUC-RS, UTFPR e UnB Gama. Da mesma forma, algumas empresas, como a Caelum e a Scrum Alliance, realizaram cursos para que profissionais do mercado conhecessem valores, princípios e práticas Ágeis.

Principais Benefícios para os clientes:

Agilidade: O tempo de entrega do produto é um dos maiores benefícios dos métodos ágeis na perspectiva do cliente. O ciclo extremamente reduzido – em comparação aos outros métodos – é um atrativo que faz toda a diferença.

Múltiplas entregas: as múltiplas entregas que fazem parte do ciclo ágil permitem que o cliente adquira expectativas de como o software funcionará, muito antes de chegar à versão final.

Participação no projeto: as metodologias ágeis integram o consumidor ao projeto, de modo que suas solicitações e feedbacks sejam prontamente assimilados pela equipe.

Customização do produto: existe possibilidade de customizar o produto de acordo com necessidades e preferências, pois os métodos ágeis têm alta adaptabilidade.

Principais vantagens para a equipe:

Entregas rápidas e frequentes: Para as empresas, a maior vantagem é ter que gerenciar equipes menores e com profissionais experientes, o que facilita todo o processo. Os desenvolvedores se concentram em uma quantidade limitada de atribuições, inclusive, é o que ajuda a manter o pessoal motivado.

Qualidade do produto: Os métodos ágeis consistem nas entregas em escala semanal ou mensal, integrando o cliente ao processo de desenvolvimento. Isso faz notável diferença para a qualidade final do software, visto que todas as falhas e modificações foram feitas muito antes do último lançamento.

Mitigação de riscos: Considerando a participação do cliente no processo e os constantes testes de software feitos pela equipe, os bugs e as falhas que surgem durante o projeto são rapidamente identificados.

Os principais métodos ágeis:

Método Scrum:

O nome “Scrum” tem origem no jogo de Rugby. É um método de reinício de jogada no Rugby, onde os jogadores dos dois times se juntam com a cabeça abaixada e se empurram com o objetivo de ganhar a posse de bola.

O Scrum foi elaborado tendo como foco a resolução de problemas complexos em ambientes de alta imprevisibilidade. Essas são características bem comuns no universo de desenvolvimento de software.

Fig 1: o framework do Scrum.

A primeira e a última fase (Planning e Closure) são constituídas de processos com entradas e saídas bem definidas. O fluxo é linear, com algumas iterações na fase de planejamento (Planning). A fase de Sprints é um processo empírico que segue o ciclo PDCA (Plan, Do, Check, Act). O trabalho é considerado em andamento até a fase de fechamento (Closure). As entregas podem ser alteradas a qualquer momento, garantindo assim que o produto desenvolvido esteja absorvendo os acontecimentos externos e sendo fiel às reais necessidades do negócio. Para isso, o trabalho é estruturado em ciclos (sprints). Em cada sprint, o trabalho é priorizado a partir de uma lista de requisitos, chamada de Backlog do Produto. O desenvolvimento a partir da priorização dos requisitos garante que se trabalhe no que tem mais prioridade e valor para o cliente.

Fig 2: O Scrum é a base sobre a qual os processos ágeis são construídos.

Diferentemente de outros processos, em que há um responsável pelo projeto, o Scrum distribui a gestão de projetos (ou produto) entre três papéis: o Dono do Produto (DP), o ScrumMaster (SM) e a Equipe de Desenvolvimento (ED), formando assim uma equipe de gestão, batizada como Equipe Scrum.

As Equipes Scrum são auto-organizadas e, por isso, decidem a melhor forma de realizar seu trabalho, em vez de serem direcionadas por pessoas de fora.

Backlog: O Backlog do Produto é uma lista ordenada criada pela Equipe Scrum; somente o Dono do Produto pode inserir, remover ou reordenar os itens.

Backlog da Sprint: O Backlog da Sprint é o conjunto de itens selecionados para serem implementados durante a Sprint mais o plano para transformá-los em um incremento.

Basicamente, o Sprint nada mais é que uma reunião formada pelos envolvidos no projeto. Em cada Sprint é estabelecido um conjunto de atividades a serem executadas em determinado espaço de tempo (Time Box).

Incremento do produto: Ao final de cada Sprint, a Equipe de Desenvolvimento entrega um incremento do produto, resultado do que foi produzido durante a Sprint. Esse é um dos conceitos principais do Scrum e vai ao encontro da sua natureza empírica, já que permite ao Dono do Produto perceber o valor do investimento e também vislumbrar outras possibilidades.

Principais características:

• As equipes são pequenas e multidisciplinares, trabalham de forma integrada em um ambiente aberto para produzir versões incrementais de um produto de software em iterações curtas;
• As equipes se auto-organizam para planejar e desenvolver o trabalho das sprints, ou seja, a liderança para fazer esse trabalho é diluída em cada integrante da equipe;
• O trabalho em equipe é facilitado pelo ScrumMaster, que não trabalha diretamente com atividades técnicas, mas remove impedimentos e reforça os pontos centrais do Scrum ao longo do desenvolvimento do produto;
• O trabalho é organizado a partir do Backlog do Produto, constantemente revisado e priorizado; a comunicação e cooperação entre as equipes se intensificam ao longo do desenvolvimento das funcionalidades do produto.

Método Programação Extrema (eXtreme Programming)

O método XP pode ser usado se clientes e desenvolvedores deixarem seus medos e desconfianças de lado e assumirem uma postura orientada à colaboração e à confiança no trabalho uns dos outros, partindo do princípio de que há um objetivo em comum: a produção de um software de alta qualidade e que atenda às necessidades do negócio.

A Programação Extrema (XP) assume que a volatilidade dos requisitos existe e, em vez de tentar eliminá-la, trata o desenvolvimento do software a partir de uma abordagem flexível e colaborativa, na qual desenvolvedores e clientes fazem parte de uma única equipe que tem o propósito de produzir software de alto valor agregado.

A Programação Extrema é a combinação de uma abordagem colaborativa, livre de desconfianças, com um conjunto de boas práticas de engenharia de software que são eficientes por si só, individual e independentemente do contexto. Cada uma dessas práticas contribui para o aumento da qualidade do software e ajuda a garantir que o produto final agregue valor e atenda às necessidades do negócio.

O extremismo vem da proposta de usar ao máximo as boas práticas de engenharia de software já reconhecidas pela indústria. Sobretudo, o poder de XP está no conjunto das práticas. XP é um conjunto de práticas que se apoiam, criando sinergia.

O método XP está pautado em cinco valores:

Comunicação: A criação de um produto de qualidade requer muito entendimento e transparência entre desenvolvedores, clientes e usuários. Desenvolver software é muito mais do que saber programar: é entender as pessoas.

Simplicidade: Uma arquitetura simples é mais fácil de ser implementada do que uma complexa. Para manter a simplicidade, faça só o necessário e quando precisar ser feito.

Coragem: é necessário coragem para mudar, inovar e aceitar que não se sabe tudo e que desenvolvimento de software é uma atividade complexa demais para ser tratada de forma determinística.

Feedback: Quanto mais rápido o feedback acontecer, mais cedo saberemos se o projeto caminha na direção certa. Feedback constante é a chave para a criação de software que atende às necessidades dos usuários.

Respeito: sem respeito, a comunicação e o feedback serão pouco eficientes. A equipe considera que cada membro fará o máximo em cada tarefa que realizar, respeitando as limitações individuais e criando oportunidades para que elas sejam superadas.

Princípios defendidos pelo método XP:

Humanidade: As necessidades individuais de cada desenvolvedor devem ser respeitadas.

Economia: A equipe deve conhecer as necessidades do negócio e definir prioridades que agreguem o máximo de valor no menor intervalo de tempo.

Melhoria: Melhorias devem ser implementadas constantemente, em etapas.

Benefício mútuo: As atividades devem sempre trazer benefícios para os envolvidos. Documentos extensos e planejamentos detalhados de longo prazo não trazem benefício imediato e estão altamente sujeitos a mudanças no futuro.

Semelhança: Boas soluções podem ser aplicadas novamente, inclusive em outros contextos e escalas.

Diversidade: A equipe deve reunir muitas habilidades, opiniões e pontos de vista para aumentar sua flexibilidade e conseguir várias perspectivas que ajudarão a encontrar a melhor abordagem para cada situação.

Passos pequenos: A integração do código, o desenvolvimento dirigido por testes e a entrega de novas versões devem manter um tamanho pequeno o suficiente para que a qualidade seja mantida.

Reflexão: Periodicamente, a equipe deve refletir sobre seu próprio trabalho.

Fluxo: O ritmo de trabalho deve ser sustentável ao longo do tempo, e a quantidade de software entregue também deve se manter estável.

Oportunidade: A equipe deve estar sempre disposta a melhorar e atenta às oportunidades que surgem.

Redundância: Devemos acrescentar maneiras de assegurar a qualidade do software e reduzir os riscos do projeto como um todo.

Falha: A equipe deve ter coragem para experimentar alternativas quando o seu caminho não estiver claro, mesmo sabendo que algumas dessas opções falharão.

Qualidade: A qualidade não é um fator negociável. O escopo e o tempo devem ser ajustados para entregar software de alta qualidade.

Aceitação da responsabilidade: As responsabilidades são aceitas, e não impostas. Cada membro deve estar comprometido e disposto a colaborar da melhor forma possível com a equipe.

Método FDD – Feature-Driven Development

O FDD (Desenvolvimento Dirigido por Funcionalidades) reúne boas práticas de engenharia de software e de gestão de projetos, de forma harmoniosa, eficaz e eficiente.

Foi desenvolvido entre 1997 e 1999 em Cingapura, para atender às demandas do banco UOB (United Overseas Bank).

Para a FDD, uma feature é uma funcionalidade pequena, com valor claro para o cliente no contexto do seu domínio de negócio. Para a equipe de projeto, não deve ocupar mais que uma iteração para ser desenvolvida, ou seja, menos que 2 semanas (80 horas), tipicamente. A maioria das funcionalidades requer, em geral, apenas algumas horas para ser implementada.

Formação da equipe em FDD:

Gerente de projeto: É o responsável pelo gerenciamento geral administrativo do projeto.

Gerente de desenvolvimento: Possui habilidades técnicas, gerenciais e de liderança necessárias para orquestrar as ações da equipe de desenvolvimento.

Especialistas no domínio de negócio: Compreendem as regras e a dinâmica do domínio do negócio sendo considerado.

Arquiteto líder: Profissional com experiência em análise e modelagem de sistemas, capaz de liderar a equipe no desenvolvimento do modelo que será construído e refinado para implementar as funcionalidades identificadas.

Programadores líderes: São os desenvolvedores mais experientes, reconhecidos como líderes pela equipe. Coordenam o desenvolvimento, montam as equipes de funcionalidades e participam das definições técnicas.

Proprietários de classes: São os demais desenvolvedores da equipe, aos quais foram atribuídas certas classes do modelo.

Método Lean

A história do Lean teve início no século XIV. Segundo registros históricos, o conceito de fluxo contínuo foi utilizado pelo exército de Veneza para embarque de seu arsenal em navios de guerra. Posteriormente, no século XVI, foi criado o conceito de partes intercambiáveis, o que possibilitou a produção em massa de armas com baixo custo. Mas foi no Japão, no final do século XIX, que foram forjadas as principais características do Lean, tendo sido extensivamente exercitadas e aprimoradas.

Fundamentos: O Lean é reconhecido mundialmente em diversas indústrias por ser um método altamente eficaz e que proporciona a entrega de cada vez mais valor com a aplicação de cada vez menos esforço. O Lean é fortemente fundamentado em princípios e valores oriundos da cultura japonesa, dentre os quais encontramos responsabilidade e disciplina. Sem estes, de fato, nem o Lean, nem qualquer outro método poderia ser efetivo.

No desenvolvimento de software, a automação é utilizada de diversas formas e vem sendo aprimorada e estendida cada vez mais dentro do seu ciclo de vida. Além de diminuir o tempo gasto com as atividades, proporciona eliminar a variação nos resultados.

Dentro do Lean, são utilizadas duas ferramentas importantes: Just in Time e Poka Yoke, descritas a seguir:

Just in Time: É um sistema de administração da produção que determina que tudo deve ser produzido, transportado ou comprado na hora exata. Pode ser aplicado em qualquer organização, para reduzir estoques e os custos decorrentes.

Poka Yoke: É um dispositivo à prova de erros destinado a evitar a ocorrência de defeitos em processos de fabricação e/ou na utilização de produtos.

Princípios do Lean:

Entregar um fluxo constante de valor ao cliente: desenvolvimento de software é uma atividade muito complexa, que demanda informações oriundas de diversas áreas e ações conjuntas visando à entrega de valor. O Lean busca orquestrar todo este ambiente complexo de modo a criar um fluxo contínuo de entrega de alto valor agregado.

Criar uma organização que aprende: não existe desenvolvimento de tecnologia sem a aquisição contínua de conhecimento. Criar mecanismos para que o aprendizado seja inserido implicitamente no processo de desenvolvimento é um princípio essencial do Lean.

Criar um ambiente de melhoria contínua: no Lean, as pessoas são desafiadas a não se acomodar com o status quo e a criticar continuamente os padrões existentes em busca de melhorias.

Eliminar completamente o desperdício: no desenvolvimento de software, é importante encontrar e remover todo e qualquer desperdício existente no ciclo de vida de um produto ou negócio. O Lean ensina a categorizar e entender o que é desperdício de modo que possamos removê-lo.

Outros elementos importantes:

O Engenheiro Chefe: Um dos segredos da Toyota para o desenvolvimento consistentemente de novos produtos de alta qualidade e rentabilidade está no papel do engenheiro chefe, também conhecido em outras empresas como Campeão do Produto (Product Champion). O Engenheiro Chefe do Produto difere-se do Product Owner definido pelo Scrum principalmente porque, além de se preocupar com o retorno do investimento e as questões de negócio, é também um exímio engenheiro e, portanto, quem tem a palavra final nos aspectos técnicos do produto.

O Líder de Competências: Outro papel fundamental no Lean é o do professor, também conhecido como líder de competências ou gerente de linha. Seu papel é criar as competências necessárias ao desenvolvimento do produto.

As Equipes: Uma organização pode dispor das melhores ferramentas, pode estar estruturada com bons processos, pode ter as melhores habilidades, mas se estas pessoas não tiverem um comportamento diferenciado e não se organizarem de modo a fortalecer a comunicação e colaboração, nada efetivo será construído.

Multidisciplinaridade: Uma equipe Lean é multidisciplinar porque ela possui todas as competências necessárias para transformar um conceito em produto. Em projeto de software, esta equipe pode ser composta por arquitetos, analistas, programadores, DBA’s, designers, testadores, entre outros.

Responsabilidade: No Lean, o conceito de sistema puxado é aplicado sistematicamente por toda a organização. As pessoas e as equipes têm uma característica muito importante: a auto-responsabilidade. Isto significa que ninguém dirá a elas o que fazer, mas elas, por sua vez, devem ser responsáveis o suficiente para saber o que fazer e como fazer.

Autonomia: Numa organização que utiliza o Lean, a tomada de decisão é delegada aos graus mais baixos da hierarquia e, em muitos casos, a decisão é tomada no “chão de fábrica”. Isso elimina desperdícios e possibilita que as decisões sejam tomadas pelas pessoas que efetivamente têm a informação adequada.

Método Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Methodology (DSDM) é uma metodologia de desenvolvimento de projetos de software centrada em estabelecer os recursos e o tempo fixo para o desenvolvimento de um projeto, ajustando suas funcionalidades de maneira a atender os prazos estipulados. Foi criada em 1994 e continua sendo mantida por um consórcio de diversas empresas associadas.

Apesar de ser adotada em todo o mundo, a DSDM é uma metodologia muito conhecida e utilizada no Reino Unido.

Princípios básicos do DSDM:

1. Participação ativa dos usuários e stakeholders: todos os envolvidos no projeto e conhecedores do processo devem acompanhar o desenvolvimento a fim de garantir que tudo seja entregue a tempo e de acordo com o solicitado.
2. Abordagem cooperativa e compartilhada: todas as partes interessadas devem cooperar e assumir o compromisso das entregas de partes do software, bem como escolher a ordem de sua implementação, ou seja, essas escolhas devem ser feitas em comum acordo.
3. Equipes com poder de decisão: as pessoas envolvidas no desenvolvimento devem ter conhecimento e autonomia suficiente para decidir o destino do sistema; não é tolerável aguardar decisões por um longo período de tempo.
4. Entregas contínuas que fazem a diferença: é um critério básico da DSDM tentar trazer um retorno ao cliente do projeto desde o início, a fim de promover a validação do que está sendo feito (fazer o produto certo).
5. Desenvolvimento iterativo e incremental: a ideia é convergir o sistema para o negócio e melhorá-lo continuamente em um processo iterativo, buscando e corrigindo os problemas o mais cedo possível.
6. Feedback: o foco está nas frequentes entregas de produtos de software, permitindo ao usuário colocar suas opiniões e solicitar modificações.
7. Todas as possíveis alterações durante o desenvolvimento devem ser reversíveis: deve-se permitir que o impacto das modificações seja testado e, caso não surta os efeitos desejados, as modificações possam ser restabelecidas.
8. Fixar os requisitos essenciais: os requisitos principais devem ser capturados no início, a fim de estabelecer os objetivos gerais. Os requisitos específicos serão norteados pelos principais e sujeitos a modificações, mas sempre focando os objetivos.
9. Teste em todo ciclo de vida: devido ao prazo normalmente apertado, não podemos deixar a fase de testes exclusivamente no final da implementação, devendo ser realizada em todas as fases e componentes do projeto. O teste de regressão é normalmente o mais utilizado pela DSDM devido ao desenvolvimento incremental.

Fases do DSDM:

Estudo de viabilidade: Como o nome sugere, obviamente tem o propósito de analisar a viabilidade do projeto, ou seja, se é possível concebê-lo com o uso da DSDM.

Estudo de negócio: Nessa fase, as regras de negócio são analisadas, bem como todos os processos envolvidos, a fim de captar as características do negócio. Uma forma de executá-la é propor vários workshops, reuniões com representantes da empresa capazes de argumentar e decidir sobre os aspectos relevantes do sistema a ser implementado.

Modelo de iteração funcional: Trata-se de um planejamento de conteúdo e abordagem aplicado após a execução de cada iteração para analisar se os resultados estão corretos com o objetivo de calibrá-los.

É importante observar que não é todo tipo de projeto de software que pode se adaptar ao DSDM, existindo algumas restrições que devemos conhecer. Por se tratar de uma metodologia ágil que exige pouca formalidade, os sistemas de segurança crítica, ou seja, sistemas que não podem falhar por colocar vidas em risco, não devem ser conduzidos com DSDM, bem como por outras metodologias menos rigorosas.

Método MSF

O Microsoft Solutions Framework é a forma como a gigante do Vale do Silício gerencia e desenvolve seus softwares.

Essa metodologia de desenvolvimento surgiu em 1994, como um conjunto de boas práticas compiladas pela Microsoft a partir de sua experiência na produção de software e em serviços de consultoria, evoluindo para um framework flexível para nortear projetos de desenvolvimento de software.

Trata-se de uma metodologia que é utilizada por pequenos grupos de desenvolvedores, também com seus princípios e valores próprios, como: valorização da comunicação entre a equipe, visão transparente e compartilhada quanto às tarefas, capacitação e melhoria contínua da equipe, agilidade para concretizar mudanças, alto grau de adaptabilidade, qualidade e aprendizado contínuo.