Do que se trata o artigo:

O artigo apresenta a estrutura e a força da aplicação da metodologia ágil FDD (Desenvolvimento Guiado por Funcionalidades) em ambientes que exigem priorização no desenvolvimento de requisitos de Softwares e agilidade em suportar a mudança nos requisitos funcionais do produto em desenvolvimento.

Em que situação o tema útil:

A metodologia FDD é útil em organizações que necessitam desenvolver projetos de Software complexos em curto espaço de tempo, de forma a suportar as necessidades mais prioritárias da organização. A metodologia também se apresenta como opção para aquelas empresas que desejam migrar seus processos de desenvolvimento tradicionais para os considerados ágeis.

Resumo DevMan:

Este artigo demonstra a importância do manifesto ágil para as organizações atuais e descreve como a metodologia ágil denominada Desenvolvimento Guiado por Funcionalidades (FDD) pode ser adequada às empresas que desenvolvem projetos complexos e que tem a necessidade de responderem rapidamente às novas demandas negociais.

A necessidade de aproximar a área de TI (Tecnologia da Informação) com o negócio torna-se cada vez mais relevante à medida que os altos executivos das grandes corporações mundo a fora compreendem o quanto as soluções desenvolvidas por este departamento, até então, restritamente técnico, poderiam alavancar seus negócios.

Muitos fatores foram responsáveis por estimular os gestores das mais diversas corporações a procurarem racionalizar seu modelo de negócio com base no uso das soluções oriundas da TI. Mas, sem dúvida, a necessidade de se manter atual em relação às constantes mudanças nas regras do negócio, originárias de um novo mundo mais integrado e dinâmico, é o fator mais relevante. Por isso, a mudança nos requisitos do sistema durante o seu desenvolvimento deve ser encarada com naturalidade. Este é um fator de alta relevância para um projeto de Software!

Neste contexto, a grande revolução provocada pela modernização dos sistemas de comunicação, que passaram a integrar diversas culturas do mundo, acabou por criar novas necessidades globais. As soluções de TI, principalmente os softwares, não eram mais um produto de prateleira que possuía versões a cada ciclo tecnológico ou a cada iniciativa do fabricante. Os fatores externos, provenientes dos novos mercados em expansão, dos concorrentes cada vez mais agressivos e do consumidor mais seletivo, despertaram para a necessidade das organizações de se adequarem e anteciparem rapidamente às mudanças exigidas por um mundo globalizado e integrado.

Essas mudanças estão associadas à reconstrução do modelo de negócio da empresa, da constante necessidade de inovar e atender a diversos públicos com níveis distintos de exigência e comportamento. E como não poderia ser diferente, o ciclo de vida de um modelo de negócio teve seu tempo reduzido, o que faz as organizações atuais a implantarem ciclos de melhoria contínua que impulsionam, de forma constante, a empresa a buscar o novo. Estes fatores servem como motivação para uma nova linha de produção de software, que acabou por inverter a ordem – ou colocar tudo na devida ordem – na produção de um novo sistema. Os novos produtos de software passaram a possuir versões baseadas no ciclo de mudança do negócio. A cada nova necessidade, um novo produto. Este é o novo ciclo da Engenharia de Software.

Como consequência disso, a cultura da mudança passou a estar cada vez mais enraizada no dia-a-dia das organizações e a TI deixou de ser um mero setor de suporte para fazer parte do negócio. Este é o grande ponto de transformação para desenvolvedores, engenheiros, analistas de software e gerentes de projetos de TI. Para estes profissionais envolvidos na concepção, no planejamento e construção de novos projetos, passa a ser evidente que o usuário e o cliente digam suas expectativas e necessidades e, também, participem de todo o processo de Engenharia de Software. Mas, apesar disso, muitos profissionais ligados à área de TI ainda resistem em compreender esta nova ordem.

Com este cenário, o modelo em cascata – muitas vezes injustamente criticado – passou a não ser mais adequado, já que a sua estrutura metodológica não tolera a necessidade de produzir, utilizar e suportar novos requisitos ao mesmo tempo em que se constrói. O cliente até ajuda a construir um novo software, se em contra partida ele conseguir utilizar, em um pequeno espaço de tempo, alguma funcionalidade produzida. Esta funcionalidade não significa ser o produto completo e perfeito, mas deve atender as necessidades mais críticas da organização. E, assim, surgem as metodologias ágeis baseadas nos valores e princípios do manifesto ágil de 2001.

Os valores do manifesto ágil comprovam o que foi dito:

· Indivíduos e iterações mais que processo e ferramentas;

· Software em funcionamento mais que documentação abrangente;

· Colaboração com o cliente mais que negociação de contratos;

· Responder a mudanças mais que seguir um plano.

Neste sentido, ao longo deste texto serão apresentadas a estrutura e as forças da metodologia ágil denominada FDD (Future Driven Development) ou Desenvolvimento Guiado por Funcionalidades que, apesar de valorizar os processos e a forma de se fazer, tem sua ênfase nos valores e princípios do manifesto ágil.

A origem do FDD

O site featuredrivendevelopment.com ...

Quer ler esse conteúdo completo? Tenha acesso completo