FDD - Desenvolvimento Orientado a Recursos

O FDD ( Feature Driven Development , ou Desenvolvimento Guiado por Funcionalidades), apresentado em 1999, é uma das primeiras metodologias ágeis. De acordo com Ambler (2014), uma feature é uma função pequena, mas importante para o cliente, que representa uma maneira de expressar os requisitos do sistema. O FDD possui cinco principais  atividades que são executadas de forma interativa, quais sejam:

• Desenvolver um modelo abrangente: pode envolver o desenvolvimento de requisitos, análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção.
• Construir uma lista de funcionalidades: decomposição funcional do modelo do domínio em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o produto a ser construído, também chamado de lista de espera do produto.
• Planejar por funcionalidade: abrange a estimativa de complexidade e dependência das funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na sequência apropriada para a construção.
• Detalhar por funcionalidade: já dentro de uma iteração de construção, a equipe detalha os requisitos e outros artefatos para a codificação de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos.
• Construir por funcionalidade: cada esqueleto de código é preenchido, testado e inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário. 

AUP - Agile Unified Process

O AUP ( Agile Unified Process )foi desenvolvido por Scott Ambler (2004) e é uma versão simplificada do RUP ( Rational Unified Process )da IBM. Ele descreve uma abordagem simples e de fácil compreensão para o desenvolvimento de aplicações de negócios usando técnicas e conceitos ágeis, mas mantendo a fidelidade ao RUP.

O AUP aplica técnicas ágeis, incluindo Test Driven Development (TDD) e Agile Modeling , para gerenciamento de mudanças ágeis e refatoração de banco de dados para melhorar a produtividade. O próprio criador do AUP, Ambler (2006), informa ter parado de trabalhar no AUP em 2006 e ter se dedicado, desde 2009, ao Disciplined Agile Delivery (DAD) framework. 

 Scott W. Ambler

 

Fonte: www.ambysoft.com .

Cristal

Nota-se que a principal premissa das ferramentas de gestão é “sempre entregar valor” . Este também é o conceito fundamental dos modelos ágeis. Vamos fazer uma abordagem mais geral dos métodos ágeis, dentro de uma perspectiva histórica. 

No início dos anos 1990, Alistair Cockburn foi contratado pelo Grupo de Consultoria da IBM para construir e documentar uma metodologia para desenvolvimento orientado a objetos. Sua abordagem para a tarefa era avaliar o maior número de projetos possíveis, escrevendo o que as equipes achavam ser importante para seu sucesso (ou fracasso). Ele começou a encontrar equipes que afirmaram conseguir sucesso por não terem se limitado a processos ou produtos predefinidos, apenas sentavam-se juntos para que pudessem conversar e, como resultado, entregavam programas testados com mais frequência, frutos destas reuniões informais.

Alistair Cockburn, com base nestes resultados, gerou uma metodologia voltada para pequenos projetos de desenvolvimento, normalmente para uma equipe de seis a oito desenvolvedores, dando enfoque maior na comunicação entre os membros da equipe. Assim surgiu o Crystal Clear.

De acordo com Cockburn (2008), Crystal se concentra nas pessoas e não em processos ou artefatos. A família Crystal de metodologias teve como foco a eficiência, o talento e as habilidades das pessoas como componentes de segurança do projeto.

A metodologia apresenta as seguintes premissas:

• O funcionamento do projeto é influenciado pelo fator humano de desenvolvimento;
• A comunicação é fundamental, e lançamentos frequentes diminuem a necessidade da construção de produtos intermediários;
• Todo projeto é único, tendo necessidade de usar metodologias diferentes.

A metodologia é propositalmente pouco definida para permitir a implementação de atividades que pareçam mais adequadas durante o processo de desenvolvimento. 

 Alistair Cockburn.

Ágil é uma atitude, não uma técnica com limites. Uma atitude não tem limites, assim, não podemos perguntar ‘quem usa ágil aqui?’ mas ‘como eu poderia agir de uma forma ágil aqui?’ ou ‘quão ágeis nós podemos ser, aqui?’.

Alistair Cockburn

Fonte: www.azquotes.com

Valores Ágeis pelo Standish Group

Com a adoção de metodologias ágeis, os projetos têm obtido cada vez mais sucesso quando comparados com as metodologias tradicionais.

O Standish Group tem estudado os métodos aplicados em projetos e tornou-se um dos principais divulgadores de resultados da eficiência da metodologia ágil.

Em 2011 o Standish Group lançou o Chaos Manifesto (2011) que contém as cem mais importantes práticas para desenvolver e manter um ambiente de gestão do projeto bem-sucedido.

Anualmente este importante instituto divulga o Chaos Report, que tem sido publicado desde 1994 e mostra uma fotografia momentânea do estado da arte da indústria de desenvolvimento de software.

A figura ilustra os resultados do Chaos Report 2015, mostrando o comparativo de resultados de projetos usando o método tradicional do modelo em cascata e métodos ágeis.

Modelo cascata (Waterfall) x Métodos ágeis (Agile).

SIZE	METHOD	SUCCESSFUL	CHALLENGED	FAILED
All Size Projects	Agile	39%	52%	9%
	Waterfall	11%	60%	29%
Large Size Projects	Agile	18%	59%	23%
	Waterfall	3%	55%	42%
Medium Size Projects	Agile	27%	62%	11%
	Waterfall	7%	68%	25%
Small Size Projects	Agile	58%	38%	4%
	Waterfall	44%	45%	11%

Fonte: www.infoq.com.
Fonte imagem: cdn.infoq.com.

Seis Sigma (Six Sigma)

O Six Sigma foi inicialmente adotado para medir defeitos e melhorar a qualidade. Segundo Neefs (2016), Six Sigma “refere-se à aplicação de um método científico estruturado para melhoria de um aspecto em uma empresa, organização, processo ou pessoa”. O autor afirma que o Six Sigma tem dois métodos principais, ambos inspirados no ciclo PDCA de Deming:  DMADV – Define, Measure, Analyze, Design and Verify, usado para criar um novo produto, e DMAIC, usado para melhorar um processo de negócio existente. DMAIC refere-se a:

• Define (Definir) – Identifica as metas do projeto e os processos.
• Measure (Medir) –Mede os aspectos-chave do processo existente e coleta dados relevantes.
• Analyze (Analisar) – Avalia os dados para identificar as relações de causa e efeito e seu impacto no ambiente de negócios.
• Improve (Melhorar) – Otimiza o processo com base nos dados analisados, aplicando técnicas e até usando modelos matemáticos.
• Control (Controlar) – Faz o acompanhamento visando garantir que desvios do objetivo sejam corrigidos antes que resultem em problemas ou defeitos.

 

Seis Sigma.

Por nasirkhan / shutterstock.com.

O uso do Seis Sigma visa melhorar a qualidade dos resultados dos processos, identificando as causas de erros. Seus princípios envolvem um conjunto de métodos, inclusive estatísticos, definindo passos e quantificando metas financeiras no negócio.

Quando aplicado de forma adequada, espera-se um resultado produtivo próximo dos 100%.

Pande (2001, p. 115) afirma que o Seis Sigma proporciona:

• a formação de um sucesso sustentado, pois desenvolve as habilidades e a cultura necessárias a uma revitalização constante nas empresas;
• a determinação das metas de desempenho, que é a base sobre a qual está alicerçada a metodologia Seis Sigma, em virtude de o nível de desempenho se aproximar da perfeição;
• a intensificação do valor para os clientes, considerando que o foco é o ponto vital do método, que busca compreender o significado e a importância do valor para o consumidor;
• o aprimoramento das melhorias, que é garantido pela utilização de várias ferramentas de gestão empresarial disciplinadas pela estrutura do método;
• a promoção da aprendizagem, em virtude de o Seis Sigma aumentar o desenvolvimento e acelerar o compartilhamento de ideias inéditas dentro das empresas; e
• a execução de mudanças estratégicas, pois a sua incorporação possibilita a compreensão detalhada dos processos e procedimentos das empresas, oferecendo, assim, a capacidade de implementação de simples ajustes a complexas mudanças.

 Six Sigma: métodos DMAIC e DMADV.

Fonte: Neefs (2016).

Ciclo PDCA

O ciclo PDCA (Plan – Planejar, Do – executar, Check – verificar, Act – agir), também chamado ciclo de Deming, é uma ferramenta muito útil.

Este conceito foi criado para abordar qualquer problema na administração ou produção. Parte do princípio de que não existe uma organização ou equipe perfeita, pois todos cometem erros e temos que aprender com nossos erros se quisermos evoluir no aprendizado e na qualidade de nossas atividades. Os erros podem afetar diretamente o desempenho do negócio.

Este ciclo incentiva o constante aprendizado com os erros, não a insistência neles. É um ciclo que entra em uma espiral de atividades que reduz a margem de erros comuns e frequentes.

Quando aplicamos este conceito ao desenvolvimento de software para aumentarmos a eficiência, na verdade estamos sendo ágeis, ou usando modelos ágeis:

• P (Plan) – Planejamento: Quando estabelecemos metas e definimos métodos de acompanhamento, estamos planejando. Em modelagem ágil, nada é feito sem planejamento adequado. As necessidades do projeto devem ser claramente entendidas e elaboradas. Isto é planejar em modelagem ágil.
• D (Do) – Executar: Depois de definir um plano de ação, deve-se executá-lo. Isto quer dizer não procrastinar ou ficar infinitamente adiando ou aguardando condições adequadas. Nos modelos ágeis, toda a execução é realizada dentro dos requisitos definidos.
• C (Check) – Verificar: Constante monitoração ou acompanhamento é necessário para o sucesso de cada atividade.
• A (Act) – Ação: Eficiência e eficácia são as metas de uma ação bem-sucedida. Em modelos ágeis, você sempre trabalha com planos de ação que focam um objetivo único, o produto.

 Ciclo  PDCA.

Por one photo / shutterstock.com.

De acordo com Deming (1990), na essência do PDCA encontramos 14 princípios:

14 princípios do PDCA, segundo Deming (1990).

1º princípio	Estabeleça constância de propósitos para a melhoria do produto e do serviço, objetivando tornar-se competitivo e manter-se em atividade, bem como criar emprego.
2º princípio	Adote a nova filosofia. Estamos numa nova era econômica. A administração ocidental deve acordar para o desafio, conscientizar-se de suas responsabilidades e assumir a liderança no processo de transformação.
3º princípio	Deixe de depender da inspeção para atingir a qualidade. Elimine a necessidade de inspeção em massa, introduzindo a qualidade no produto desde seu primeiro estágio.
4º princípio	Cesse a prática de aprovar orçamentos com base no preço. Ao invés disto, minimize o custo total. Desenvolva um único fornecedor para cada item, num relacionamento de longo prazo fundamentado na lealdade e na confiança.
5º princípio	Melhore constantemente o sistema de produção e de prestação de serviços, de modo a melhorar a qualidade e a produtividade e, consequentemente, reduzir de forma sistemática os custos.
6º princípio	Institua treinamento no local de trabalho.
7º princípio	Desenvolva liderança. O objetivo da chefia deve ser o de ajudar as pessoas e as máquinas e dispositivos a executarem um trabalho melhor. A chefia administrativa está necessitando de uma revisão geral, tanto quanto a chefia dos trabalhadores de produção.
8º princípio	Elimine o medo, de tal forma que todos trabalhem de modo eficaz para a empresa.
9º princípio	Acabe com as barreiras entre os departamentos. As pessoas engajadas em pesquisas, projetos, vendas e produção devem trabalhar em equipe, de modo que possam prever problemas de produção e de utilização do produto ou serviço.
10º princípio	Elimine lemas, exortações e metas para a mão-de-obra que exijam nível zero de falhas e estabeleçam novos níveis produtividade. Tais exortações apenas geram inimizades, visto que o grosso das causas da baixa qualidade e da baixa produtividade encontra-se no sistema, estando, portanto, fora do alcance dos trabalhadores.
11º princípio	Acabe com os padrões de trabalho (quotas) na linha de produção. Substitua-os pela liderança, e acabe com o processo de administração por objetivos. Elimine o processo de administração por cifras, por objetivos numéricos. Substitua-os pela administração por processos através do exemplo de líderes.
12º princípio	Remova as barreiras que privam o operário horista do direito de orgulhar-se de seu desempenho. A responsabilidade dos chefes deve ser mudada de números absolutos para a qualidade; remova as barreiras que privam as pessoas da administração e da engenharia de seu direito de orgulharem-se de seu desempenho. Isto significa a abolição da avaliação anual de desempenho ou de mérito, bem como da administração por objetivos.
13º princípio	Desenvolva um forte programa de educação e autoaprimoramento.
14º princípio	Engaje todos da empresa no processo de realizar a transformação,pois a transformação é da competência de todo mundo.

Além do ciclo PDCA, outra importante ferramenta utilizada no ambiente de desenvolvimento de software é o Seis Sigma, ou Six Sigma.

Princípios que Sustentam Agilidade

O que é ser ágil?

Ser ágil é saber responder de modo rápido a uma mudança. Pode parecer algo lógico, no entanto, quando olhamos para os desenvolvimentos realizados há poucas décadas, encontramos uma preocupação muito maior com qualidade do que com agilidade. Não que não necessitemos de qualidade, continuamos necessitando dela, mas nesta era globalizada, temos a necessidade de mais agilidade, além da qualidade, claro!

O manifesto ágil é uma declaração de princípios que fundamentam o desenvolvimento ágil de software. De acordo com Beck et al. (2001), o manifesto ágil declara:

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:

• Indivíduos e interação entre eles mais que processos 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

Ainda de acordo com Beck et al. (2001), os modelos ágeis propõem 12 princípios para o software ágil, quais sejam:

12 princípios para o software ágil de acordo com Beck et al. (2001).

1	A maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
2	As 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	Deve-se entregar o software funcionando, de poucas semanas a poucos meses, no menor período de tempo.
4	Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
5	Os projetos devem ser construídos em torno de indivíduos motivados. Eles devem ter o ambiente e o suporte necessário e deve-se confiar 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	O 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	A contínua atenção, a excelência técnica e o bom design aumenta a agilidade.
10	A simplicidade e a arte de minimizar a quantidade de trabalho não realizado são essenciais.
11	As melhores arquiteturas, requisitos e design emergem de equipes auto-organizáveis.
12	Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz e então refinar e ajustar seu comportamento de acordo.

Nas teorias da Administração são encontradas algumas técnicas de gerenciamento que buscam a melhoria contínua e que nos ajudam a entender a necessidade de modelagem ágil.

O que é agilidade?

O nome “Ágil” (ou “Agilidade”) foi escolhido para representar um movimento que surgiu em meados dos anos 1990 em resposta aos pesados métodos de gerenciamento de desenvolvimento de software que predominavam na época, que aqui chamamos de “métodos tradicionais”.

O método tradicional mais conhecido para o desenvolvimento de software é o modelo em cascata, ou waterfall. Esse modelo foi inicialmente descrito por Royce em 1970 e se caracteriza por uma sequência de fases de desenvolvimento, em que cada fase somente se inicia quando a anterior se encerra, e a saída de uma fase é a entrada da fase seguinte, conforme mostrado na figura.

Fonte: www.knowledge21.com.br

Escopo em Modelos Ágeis

Não podemos falar de escopo em um modelo ágil sem nos referirmos ao conceito de escopo do guia PMBOK. Nele encontramos aspectos interessantes relacionados com as definições de um modelo ágil:

O gerenciamento do escopo do projeto inclui os processos necessários para assegurar que o projeto inclui todo o trabalho necessário, e apenas o necessário, para terminar o projeto com sucesso. Esse gerenciamento está relacionado principalmente com a definição e controle do que está e do que não está incluso no projeto (PMI, 2013, p. 105).

Esta definição pode ser complementada com a informação de que o sucesso do projeto está ligado à quantidade de requisitos captados e definidos.

Por astephan / shutterstock.com.

Os modelos ágeis possuem a mesma característica em seu escopo.

Segundo o Standish Group,a maioria dos projetos de softwares falham por falta de clareza sobre as funções, requisitos e especificações. Isto ocorre principalmente por causa da falta de definição dos responsáveis para acompanhar o projeto (INFOQ.com, 2015).

Por que isto deve ser uma grande preocupação?

Existe uma brincadeira de crianças que explica bem isso: o “telefone sem fio”. Nesta brincadeira uma grande roda é feita e o primeiro fala uma frase para o companheiro ao lado, sem que qualquer outro o ouça. Este faz o mesmo com o companheiro que está ao seu lado, que repete a mesma ação. Isto se repete até dar uma volta completa entre os participantes. Quando a frase chegar à pessoa que iniciou a brincadeira, na maioria das vezes observa-se que a frase está totalmente distorcida. Isto é exatamente o que ocorre quando as ideias e os conceitos não são contextualizados na especificação de um software.

Existe também a questão da falta de detalhamento ao escrever, ou até mesmo o uso da simplificação de palavras de uso cotidiano em símbolos ou notações específicas de uma determinada área de conhecimento. Deve-se evitar que isso ocorra e que barreiras impeçam uma adequada contextualização do problema a ser modelado.

A figura 6 é uma ilustração comumente aplicada em projetos, que ainda continua válida, e também se aplica ao escopo do modelo ágil.

Importância da definição de escopo.

Fonte: slideplayer.com.br.

Esta figura mostra a diferença entre o que se deseja, o que se entende e o que se pode criar, caso uma comunicação clara e inequívoca não tenha sido realizada.