Scrum

Scrum é o nome de uma jogada derivada de um esporte chamado rúgbi. Este nome foi adotado para um modelo ágil de processos desenvolvido por Jeff Sutherland, Ken Schwaber e sua equipe na década de 1990. Seu objetivo inicial era atender as empresas de desenvolvimento de software; no entanto, com o tempo, passou a ter seus conceitos aplicados a gerenciamento de projetos.

Scrum é mais um framework do que uma metodologia. Significa, para os envolvidos, uma mudança de conceitos. O envolvimento é obrigatório, e a participação do time é essencial para o sucesso de sua aplicação. 

Scrum no rúgbi

 

Fonte: rugbycamps.ie

Reflexões sobre os modelos ágeis

“Nenhum homem é uma ilha”. Adotar modelos ágeis não é apenas adotar um desafio para realizar uma tarefa difícil em um curto espaço de tempo, mas significa aprender a trabalhar em equipe. Significa respeitar as regras, pessoas e decisões. Existem leis que, assim como princípios, regem a criação em modelos ágeis, e todas devem ser seguidas.

Não existe e nem nunca vai existir uma regra única para ser usada neste conceito, pois cada situação, cada negócio, cada estratégia vai exigir ações e procedimentos distintos.

Imagine um time de futebol em que cada jogador decide jogar como bem entende, desconsiderando as orientações do treinador. O jogador pode saber jogar melhor em uma posição, mas a tática montada pode colocá-lo em outra posição. O que o jogador deve fazer em uma situação dessas? Seguir seus instintos ou obedecer às ordens? Se estivermos falando de um time que pratica modelos ágeis, estamos falando de obedecer às ordens ou participar da estratégia que visa o benefício coletivo e não individual.

Cada orientação sobre a documentação, reuniões, obediência a prazos etc. irá determinar o sucesso do planejamento e do negócio.

O sucesso do grupo depende de cada indivíduo aceitar e respeitar seu papel no planejamento. Aceitar significa visar o bem do grupo e não o bem de cada membro individual do grupo.

Há um ditado popular que diz que a união faz a força. E nas equipes de modelos ágeis nunca se viu tanto na prática a realidade disto.

Importância da equipe em projetos ágeis.

Por 3dmask / shutterstock.com.

 

DSDM - Método de Desenvolvimento de Sistemas Dinâmicos

O DSDM ( Dynamic Systems Development Method ou Metodologia de Desenvolvimento de Sistemas Dinâmicos) é uma metodologia de desenvolvimento de software originalmente baseada em RAD ( Rapid Application Development ou Desenvolvimento Rápido de Aplicação) . O DSDM é uma metodologia de desenvolvimento iterativo e incremental que enfatiza o envolvimento constante do usuário (WIKIDOT.com, 2011).

Além de envolver o cliente, o DSDM tem como propósito a entrega do software sem estourar o tempo e dentro do custo estimado. Para isso, a DSDM realiza a entrega de protótipos gerados em tempos ágeis, suas equipes de desenvolvimento são autônomas, realiza grande quantidade de testes durante todo o desenvolvimento e define prioridades nos requisitos. 

XP - Programação Extrema

O XP ( Extreme Programming ) é um dos processos ágeis mais populares e possui evidências de ser bem-sucedido em empresas de todos os tamanhos e indústrias do mundo inteiro. É visto como bem-sucedido porque salienta a satisfação do cliente. Em vez de entregar tudo o que o cliente poderia desejar em alguma data distante no futuro, este processo fornece o software em pequenos pacotes. 

Programação extrema

 

Por Bakhtiar Zein / shutterstock.com 

O XP capacita os desenvolvedores a responder às mudanças que refletem as necessidades dos clientes, mesmo no final do ciclo de vida. Este processo enfatiza o trabalho em equipe. Os gerentes, clientes e desenvolvedores são todos parceiros iguais em uma equipe colaborativa.

Além disso, implementa um ambiente simples, mas eficaz, permitindo que as equipes tornem-se altamente produtivas. A equipe se auto-organiza em torno do problema para resolvê-lo o mais eficientemente possível.

De acordo com Teles (2014), XP pode melhorar um projeto de software com base em cinco aspectos essenciais:

• Comunicação;
• Simplicidade;
• Comentários;
• Respeito;
• Coragem.

Os programadores mantêm o design simples, limpo e procuram obter feedback , testando o software. Eles entregam o sistema para os clientes o mais cedo possível e implementam mudanças, respondendo rapidamente às alterações nos requisitos e nas tecnologias. Cada pequeno sucesso aprofunda o respeito para as contribuições únicas de cada membro da equipe e de todos.

O aspecto mais relevante do XP são as suas regras simples. Ele é muito parecido com um quebra-cabeça, em que há muitos pedaços pequenos. Individualmente as peças não fazem sentido, mas, quando combinadas, formam uma imagem completa. As regras podem parecer estranhas e talvez até ingênuas no início, mas são baseadas em sólidos valores e princípios.

 

OpenUP - Processo Unificado Aberto

O OpenUP está em conformidade com os princípios do Manifesto do Desenvolvimento de Software Ágil, pois possui uma abordagem iterativa e incremental e é um processo que não está associado a nenhuma ferramenta específica.

De acordo com Santos (2009), o OpenUP é um processo que é considerado mínimo, completo e extensível, que valoriza a colaboração entre a equipe e os benefícios aos interessados ao invés da formalidade e entregáveis desnecessários. 

Características do OpenUP

 

Fonte: www.slideshare.net .

O OpenUP apresenta a mesma distribuição de fases já conhecidas no RUP, em que o critério de saída de cada fase é no mínimo atender as seguintes respostas:

• Iniciação: Todos os stakeholders concordam com o escopo e objetivos do projeto?
• Elaboração: Todos concordam com a arquitetura proposta e o valor entregue ao cliente considerando os riscos levantados?
• Construção: Existe uma aplicação que está quase pronta, bem próxima a ser finalizada?
• Transição: A aplicação está finalizada e o cliente satisfeito?

O ciclo de vida do projeto possui foco nas necessidades dos stakeholders e interação com o time.

Além da divisão por fases, o OpenUP divide o projeto em iterações planejadas que podem variar de alguns dias a algumas semanas. A média recomendada é de quatro semanas, podendo ser reduzida ou aumentada em até aproximadamente seis semanas. Ao final de cada iteração deve ser gerado um incremento ao produto (chamado de build executável ou demo).

Ao final de cada iteração geralmente é realizada uma retrospectiva e avaliação em que são discutidas as lições aprendidas do projeto. Vale mencionar que o principal objetivo da retrospectiva é aprender com erros e acertos e não apontar culpados.

Outro conceito importante é o de microincremento, que é a execução de um pequeno passo que precisa ser mensurável para alcançar os objetivos de uma iteração. Este pode representar o resultado de alguns dias ou horas de trabalho, de uma pessoa ou um grupo determinado.

 

AD - Dados Agile

De acordo com Ambler (2013), o objetivo do método AD ( Agile Data ) é definir estratégias que os profissionais de TI podem aplicar em uma grande variedade de situações para trabalhar em conjunto, de forma eficaz, sobre os dados de sistemas. Isso não quer dizer que o AD engloba todos os conceitos ou metodologias.

O AD pode ser considerado como um conjunto de filosofias que permite que os profissionais de TI trabalhem em conjunto, de forma eficaz, quando se tratam dos aspectos de dados de softwares, em que os desenvolvedores:

• Trabalham em estreita colaboração com as partes interessadas do projeto;
• Devem reconhecer que os sistemas legados e bancos de dados colocam restrições sobre eles;
• Devem seguir as normas da organização e diretrizes e estarem dispostos a fornecer um feedback de sua evolução;
• Irão trabalhar em estreita colaboração com os arquitetos da empresa, pessoas que devem se tornar membros ativos de uma equipe de projeto.

EssUP - Processo Unificado Essencial

O EssUP ( Essential Unified Process ) foi criado por Ivar Jacobson como uma melhoria do RUP ( Rational Unified Process ). O método utiliza práticas como casos de uso, desenvolvimento interativo, ADD ( Architecture Driven Development ), que foram incorporadas do RUP, CMMI e desenvolvimento ágil.

De acordo com Jacobson (2017), EssUP incorpora práticas que contêm um pequeno número de cartas que proveem uma forma estruturada e útil de guiar o desenvolvimento. Estas práticas foram projetadas de forma que possam ser adotadas de forma individual ou em qualquer combinação, o que torna o processo fácil de ser adotado e adaptado à organização. São cinco práticas básicas, endereçadas ao trabalho técnico de desenvolvimento, e três práticas de trabalho, que promovem o trabalho efetivo da equipe e de melhoria do processo.

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.