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.