Edição das 16h08min de 17 de abril de 2016

Esta pesquisa deve fornecer um conteúdo atualizado sobre o tema acima. Não esqueça de incluir as  
referëncias (fontes) no último item, reforçando que não deve ser um Copy/Paste e sim uma síntese 
das pesquisas que fizer.

Conceito

O desenvolvimento de software tradicional é uma tarefa difícil, laboriosa e possui riscos. Riscos estes que envolvem orçamento, tempo para levantamento de requisitos e planejamento que não atendem ao cronograma estipulado e que tornará o projeto ainda mais caro, etc e que ao final de um período tudo pode estar perdido devido a não solução do problema do cliente.

Pensando nisso, no início do ano de 2001, um grupo de consultores veteranos da área de engenharia de software se reuniu em Snowbird, Utah, EUA. Apesar de cada um ter aprendido segundo a cartilha tradicional, ter suas próprias práticas e teorias preferidas, concordaram que os riscos inerentes ao desenvolvimento de software tradicional só poderiam ser atenuados se houvesse uma forma diferente do existia até então para desenvolvimento. Apesar de seus métodos serem diferentes, houve consenso de que os projetos tinham em comum um pequeno conjunto de princípios e com base nisso criaram o Manifesto para Desenvolvimento Ágil de software.

Principais métodos

Mesmo antes da reunião dos consultores da área de engenharia de software em Snowbird, Utah, EUA no início do ano de 2001, já haviam definições de desenvolvimento de software ágil que evoluíram a partir de meados dos anos de 1990 como parte de uma reação contra métodos “pesados”, caracterizados por regulamentação pesada, regimentação e micro gerenciamento usando o modelo em cascata para desenvolvimento.

Inicialmente, métodos ágeis eram conhecidos como métodos “leves”. Após a reunião em Snowbird foi adotado o nome métodos ágeis, tendo publicado o Manifesto ágil, documento que reúne os princípios e práticas desta metodologia de desenvolvimento.

Os métodos ágeis iniciais – criado a priore em 2000 – incluíam:

- XP (Extreme Programming) (1996)
- SCRUM (1986)
- Feature Driven Development (FDD)
- Dynamic Systems Development Method (DSDM) (1995)
- Lean Development
- Crystal Clear
- Adaptive Software Development

Princípios do Manifesto Ágil

Principais conceitos do Manifesto Ágil:

- Indivíduos e interações 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

"mesmo havendo valor nos itens à direita, são mais valorizados mais os itens à esquerda."

De acordo com estes conceitos, são 12 os princípios do Manifesto Ágil:

- Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;
- Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
- Softwares funcionais são a principal medida de progresso do projeto;
- Até mesmo mudanças tardias de escopo no projeto são bem-vindas. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente;
- Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto;
- Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho;
- Design do software deve prezar pela excelência técnica;
- Simplicidade;
- 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;
- Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente;
- As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis;
- Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Vantagens

Vantagens:

- Redução do tempo de entrega da primeira versão do software pedido;
- Métodos ágeis seguem processo iterativo de desenvolvimento e de sucessivas entregas ao cliente, o qual vai constatando e evolução e participando na avaliação e definição das novas funcionalidades a serem acrescentadas;
- Aumento de controle por parte dos gestores, uma vez que se baseia no que realmente está sendo produzido e no que vai ser feito a curto prazo. Como tal, há menos especulação, há mais visibilidade e adequação das medições e avaliações do estado das funcionalidades e tarefas realizadas;
- Por haver maior comunicação neste método, há maior aproximação entre desenvolvedores e gestores, havendo assim um ambiente propício a maior produtividade dos envolvidos. É especialmente adequado a projetos onde requisitos vão evoluindo constantemente e não se exigem muitas pessoas. A maioria dos relatórios de documentação são produzidos pelas ferramentas de trabalho, o que alivia as equipes de trabalho.

Desvantagens:

- Uma desvantagem apontada aos Métodos Ágeis é o fato de estes não serem escaláveis. Na realidade, estes não foram desenhados para projetos muito longos existindo, contudo abordagens mais escaláveis, como o Scrum;
- “O desenvolvimento ágil é mais difícil com equipes maiores . O projeto médio tem apenas nove pessoas , bem ao alcance dos processos ágeis mais básicas. No entanto, é interessante encontrar ocasionalmente projetos ágeis de sucesso com 120 ou até 250 pessoas”[1];
- Menor controle de custos. Tipicamente, nesta metodologia, o projeto termina quando o cliente não levantar mais funcionalidades relevantes que deseje ver concretizadas, em oposição a ser acordado um preço e um plano. Daqui tira-se que os custos e durações podem variar e podem ser de difícil gestão para a organização;
- Documentação do projeto tipicamente mais pobre com relação aos métodos tradicionais.

Scrum

Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. Scrum permite criar produtos melhor adaptados à realidade do cliente de forma ágil. Além do mais, praticar Scrum nos projetos traz grandes benefícios para a equipe como comprometimento, motivação, colaboração, integração e compartilhamento de conhecimento, o que facilita em muito o gerenciamento e sucesso dos projetos.

Segundo o seu autor SCHWABER (2004), o Scrum não é um processo previsível, ele não define o que fazer em toda circunstância. Ele é usado em trabalhos complexos nos quais não é possível prever tudo o que irá ocorrer e oferece um framework e um conjunto de práticas que torna tudo visível. Isso permite aos praticantes do Scrum saber exatamente o que está acontecendo ao longo do projeto e fazer os devidos ajustes para manter o projeto se movendo ao longo do tempo visando alcançar os seus objetivos.

Logo, o Scrum não vai dizer exatamente o que fazer, não irá resolver todos os seus problemas, mas com certeza os problemas serão mais facilmente identificados. Por ser um framework, irá servir como um guia de boas práticas para atingir o sucesso. Entretanto, as decisões de quando e como usá-lo, quais táticas e estratégias seguir para obter produtividade e realizar as entregas ficam por conta de quem estiver aplicando. O conhecimento das suas práticas permite a aplicação das mesmas de forma variada e este é um dos aspectos positivos do Scrum, a adaptabilidade.

Vale ressaltar que as práticas do Scrum podem ser aplicadas em qualquer contexto onde pessoas precisem trabalhar juntas para atingir um objetivo comum. Scrum é recomendado para projetos de outras áreas além de software e principalmente para projetos de pesquisa e inovação.

No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.

As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog[2]. No início de cada Sprint, faz-se um Sprint Planning Meeting[4], ou seja, uma reunião de planejamento na qual o Product Owner[3] prioriza os itens do Product Backlog[2] e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog[2] para o Sprint Backlog[5].

A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum[6]. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting[7]. Finalmente, faz-se uma Sprint Retrospective[8] e a equipe parte para o planejamento do próximo Sprint.

Arquivo:Ciclo scrum.gif

[2] Product Backlog: O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner[3]. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários [3] Product Owner: O Product Owner é a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings. [4] Sprint Planning Meeting: O Sprint Planning Meeting é uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente. [5] Sprint Backlog: - O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades. [6] Daily Scrum: - A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. [7] Sprint Review Meeting: - Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades. [8] Sprint Retrospective: - O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.

XP eXtreme Programming

Extreme Programming (XP)

Criada na década de 90, nos Estados Unidos, é uma Metodologia Ágil de desenvolvimento de software para equipes pequenas e médias que utilizam requisitos básicos e vagos e que se modificam com rapidez. É uma metodologia que tem feito sucesso em vários países por ajudar no desenvolvimento de sistemas com maior qualidade, produzidos em tempos menores e de forma mais econômica que o habitual.

Como o principal objetivo da XP é dar agilidade ao desenvolvimento de projetos e buscar a garantia de satisfação do cliente, as práticas, regras, e os valores da XP garantem um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro princípios básicos:

- Princípio da Comunicação - busca manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação.
- Princípio da Simplicidade - entende-se como simplicidade, a busca do objetivo de implementar o software com o menor número possível de classes e métodos. Outra ideia importante deste princípio é procurar implementar apenas requisitos atuais, evitando assim adicionar funcionalidades que podem ser importantes apenas no futuro. A aposta da XP é que é melhor fazer algo simples hoje do que implementar algo complicado hoje que talvez não venha a ser usado.
- Princípio do Feedback - A prática do feedback constante significa que o desenvolvedor terá informações constantes do código e do cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado.
- Princípio da Coragem - Sabe-se que não são todas as pessoas que possuem facilidade de comunicação e têm bom relacionamento interpessoal, este princípio também dá suporte à simplicidade, pois assim que a oportunidade de simplificar o software é percebida, a equipe pode experimentar e buscar novas soluções, além disso, é preciso coragem para obter e cobrar constantemente um feedback do cliente.

Principais práticas da Extreme Programming (XP)

- Planejamento - Define o que é ou não necessário ser feito no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, não em requisitos futuros.
- Entregas Frequentes - Baseiam-se no desenvolvimento de um software simples, e conforme os requisitos aparecem, há a atualização da versão do software. Cada versão entregue deve ter o menor tamanho possível, contendo os requisitos de maior valor para o negócio. É recomendado que as versões devem ser entregues a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente.
- Metáfora - São as descrições de um software sem a utilização de termos técnicos com o objetivo de guiar o desenvolvimento do software com a maior transparência possível para o cliente.
- Projeto simples - O software desenvolvido de acordo com a metodologia XP deve ser o mais simples possível e satisfazer os requisitos atuais, sem a preocupação de requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim que eles realmente existirem.
- Testes - A Extreme Programming (XP) prioriza a validação do projeto durante todo o processo de desenvolvimento. Os desenvolvedores implementam o software criando primeiramente os testes.
- Programação em pares - A implementação do código é feita em dupla, ou seja, dois desenvolvedores trabalham em um único computador. Procurando identificar erros sintáticos e semânticos, pensando estrategicamente em como melhorar o código que está sendo implementado. Esses papéis podem e devem ser alterados sempre que possível.
- Refatoração - Focaliza a lapidação do projeto do software e está presente em todas as etapas do desenvolvimento. A refatoração deve ser feita sempre que possível, buscando principalmente simplificar o código atual sem perder nenhuma funcionalidade.
- Propriedade coletiva - O código do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um código, mesmo que ele próprio não o tenha desenvolvido, pode fazê-lo, desde que faça os testes necessários e não prejudique as funcionalidades atuais. Isto é possível porque na XP todos são responsáveis pelo software. Uma grande vantagem desta prática é que, caso um membro da equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto sem grandes dificuldades, pois todos conhecem todas as partes do software, mesmo que não seja de forma detalhada.
- Integração contínua - É a prática de interagir e construir o sistema de software várias vezes por dia, mantendo os programadores em sintonia, além de possibilitar processos rápidos. Integrar apenas um conjunto de modificações de cada vez é uma prática que funciona bem porque fica óbvio quem deve fazer as correções quando os testes falham. Esta prática é facilitada com o uso de apenas uma máquina de integração, que deve ter livre acesso a todos os membros da equipe.
- 40 horas de trabalho semanal - a XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema sério no projeto que deve ser resolvido não com aumento de horas trabalhadas, mas com melhor planejamento.
- Cliente presente - É fundamental a participação do cliente durante todo o desenvolvimento do projeto. O cliente deve estar sempre disponível para sanar todas as dúvidas de requisitos, evitando atrasos e até mesmo construções erradas. Uma idéia interessante é manter o cliente como parte integrante da equipe de desenvolvimento (Tester).
- Código padrão - Baseia-se na padronização da arquitetura do código, para que este possa ser compartilhado entre todos os programadores e até mesmo entre outros softwares.

Referências bibliográficas

- [1] Cockburn, A. e Highsmith, “Agile Software Development: The People Factor”, IEEE Computer, v.34, n.11, nov. 2001, p. 131-33

@@ Linha 83: / Linha 83: @@
 Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma ''Sprint Review Meeting''[7]. Finalmente, faz-se uma ''Sprint Retrospective''[8] e a equipe parte para o planejamento do próximo Sprint.
+[[Arquivo:ciclo_scrum.gif]]
+[2] ''Product Backlog'': O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner[3]. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários
+[3] ''Product Owner'': O Product Owner é a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings.
+[4] ''Sprint Planning Meeting'': O Sprint Planning Meeting é uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente.
+[5] ''Sprint Backlog'': - O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.
+[6] ''Daily Scrum'': - A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.
+[7] ''Sprint Review Meeting'': - Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades.
+[8] ''Sprint Retrospective'': - O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.
 = XP eXtreme Programming =

Desenvolvimento ágil: mudanças entre as edições