O documento resume conceitos e práticas de metodologias ágeis como Scrum, XP e Ruby on Rails. Apresenta características de desenvolvimento ágil, papéis em Scrum, ciclo de vida do XP e práticas como programação em par e teste.

1. Universidade Federal de Sergipe
Departamento de Computação
Metodologias de Desenvolvimento de Software
Desenvolvimento de aplicações WEB
utilizando XP, Scrum e Ruby on Rails
Alunos: Rafael Mendonça França
Marcos José Ribeiro Barrêto
Vilnei Leite Bottari
Leonardo Araujo Zoehler Brum
Gabriel Viana Passos

2. Agenda
Introdução
Características
Ágeis x RAD
Exemplos de metodologias ágeis
Scrum
XP
Ruby on Rails
Trabalhos futuros

3. Introdução
Aliança de Desenvolvimento Ágil de Software
Fundada em 11-13/02/2001
17 pessoas envolvidas
Metodologia Ágil
Há Modelagem
Há Documentação
Há Planejamento
Valoriza-se
Individualidade e interações > processos e ferramentas
Software funcional > documentação
Colaboração do cliente > negociação de contrato
Responder às mudanças > seguir um plano

4. Características
Maior prioridade: satisfazer o cliente com entrega contínua
e mais cedo possível de um software usável
Mudanças de requerimentos são sempre bem vindas,
mesmo quando for tarde
Entregar freqüentemente um software que funcione
Algumas semanas/meses
Cliente e desenvolvedor trabalham juntos diariamente no
projeto

5. Características
Construir projetos com individualismo e motivação
Proporcionar ambiente e suporte que os
desenvolvedores precisam e confiar que eles farão o
trabalho
Conversa cara-a-cara
Método mais efetivo e eficiente de se obter informação
em uma equipe
Um software funcionando é a medida de progresso
Processos ágeis promovem desenvolvimento sustentável

6. Características
Atenção contínua na excelência técnica e num bom design
aumentam a agilidade
Simplicidade
Fácil de mudar
A melhor arquitetura, requerimento e design surgem das
equipes com auto-organização
Em intervalos regulares, a equipe discute sobre um meio de
aumentar a eficiência e então ajusta-se de acordo

7. Papéis?
O Manifesto Ágil não define qualquer papel a ser exercido
dentro de uma equipe
Apenas princípios e valores com os quais se caracteriza
uma metodologia como ágil

8. Ágeis x RAD
Não admite protótipos
Projetos são quebrados em funcionalidades
No RAD o foco está em entregar todas as
funcionalidades de uma vez
Baixa qualidade antes para depois haver um
melhoramento depois
Equipes democráticas
Membros das equipes são auto-gestores

9. Ágeis x RAD
As práticas ágeis focam nos problemas e os resolvem o
mais rápido possível
Equipes se comunicam
Equipes demonstram apenas trabalhos completos
Equipes incluem também testadores e especialistas com
experiência de usuário

10. Exemplos de Metodologias Ágeis
Crystal Family
FDD (Feature Driven Development)
DSDM (Dynamic Systems Development Method)
ASD (Adaptative Software Development)
Scrum
XP (eXtreme Programming)

11. Crystal Family
Características:
Os projetos sempre usam um ciclo de desenvolvimento
com um tempo máximo de quatro meses, mas,
preferivelmente, entre um e três meses;
A ênfase é focada na comunicação e cooperação das
pessoas;
Não há limitação de qualquer prática de
desenvolvimento, ferramentas ou produtos de trabalho;
Provêem diretrizes padrão de política, produtos de
trabalho, assuntos locais, ferramentas, padrões e papéis
a serem seguidos no processo de desenvolvimento.

12. Feature Driven Development
FDD
Características
Resultados úteis a cada duas semanas ou menos
Blocos bem pequenos de funcionalidade valorizada pelo
cliente, chamados quot;Featuresquot;
Planejamento detalhado e guia para medição
Rastreabilidade e relatórios precisos
Monitoramento detalhado dentro do projeto, com
resumos de alto nível para clientes e gerentes
Fornece uma forma de saber, no início, se o plano e a
estimativa são sólidos

13. ESTRUTURA FDD
Fonte: http://www.heptagon.com.br/fdd-estrutura

14. Dynamic Systems Development
Method
DSDM
Características do DSDM:
Envolvimento ativo do Usuário
Poder de decisão da equipe DSDM
Entrega freqüente
O critério mais importante para aceitação é adequação à
tarefa requisitada
Teste integrado ao ciclo de vida

15. Dynamic Systems Development
Method
DSDM
Ciclo de vida DSDM:
Estudo de Viabilidade - determina se o projeto é
factível ou não, e se o DSDM é o método adequado.
Estudo do Negócio - Nesta etapa são determinados os
requisitos primários.
Iteração para o Modelo Funcional e Iteração para
Desenvolvimento - ocorre o desenvolvimento em si,
sendo que na primeira é aprimorado o levantamento de
requisitos, e na segunda, assegurada a qualidade dos
protótipos gerados.
Implementação - Esta fase engloba a entrega do
produto e as atividades relacionadas.

16. Adaptative Software Development
ASD
Atuação principalmente em sistemas complexos
Estimula o desenvolvimento com repetições e uma
constante prototipação
Ciclo de vida composto por três fases:
Especulação: utilizada no lugar de planejamento
Colaboração: realça a importância de trabalho de equipe
Aprendizado: devido à necessidade para reconhecer e
reagir a decisões erradas e o fato que os requisitos
podem mudar durante o desenvolvimento.

17. Scrum
O que é Scrum
Papéis em Scrum
Fases do Scrum

18. O que é Scrum
Scrum é uma metodologia ágil para gestão e planejamento
de software.
Parte da premissa de que o processo de desenvolvimento é
complexo e imprevisível
Adota uma abordagem empírica em relação ao processo,
em contraposição às metodologias tradicionais

19. Papéis em Scrum
Project Owner : prioriza os requisitos do sistema,
enumerados no chamado backlog ;
Scrum Master : age como facilitador para a equipe de
desenvolvimento
Equipe Scrum : grupo responsável pelo cumprimento das
tarefas definidas

20. Fases do Scrum
Pré-game
Planejamento
Define um novo release através do backlog
Estimativa de prazos e custos
Arquitetura
Revisão do backlog
Estebelece como os itens do backlog serão
implementados

21. Fases do Scrum
Game
Sprints
Desenvolvimento : implementa os itens do backlog e
realiza as mudanças necessárias
Corte : cria uma versão executável daquilo que foi
implementado
Revisão : avalia o progresso do desenvolvimento,
adicionando novos itens ao backlog
Ajuste : consolida as informações adquiridas na
revisão

22. Fases do Scrum
Postgame
Fechamento
Prepara o produto desenvolvido para o release
Testa o sistema
Prepara a documentação para o usuário
Promove treinamento

23. Fases do Scrum

24. XP (eXtreme Programming)
Introdução
Ciclo de Vida
Papéis e responsabilidades
Práticas

25. XP - Introdução
É uma metodologia ágil de desenvolvimento de software
criada por Kent Beck
Prima pela qualidade do software desenvolvido
XP recomenda que mudanças sejam prontamente
“abraçadas”, aceitas sem relutância
Simplicidade e um rápido feedback por parte dos clientes

26. XP - Introdução

27. XP - Ciclo de vida
Exploração
Planejamento
Iterações para liberação
Produção
Manutenção
Morte

28. XP - Ciclo de vida

29. XP - Ciclo de vida
Exploração
O cliente escreve histórias
Cada história descreve uma função adicionada ao
programa
Equipe se familiariza com as técnicas, ferramentas,
tecnologias e práticas que serão usadas no projeto
As possíveis arquiteturas são exploradas, construindo-
se um protótipo do sistema
Esta fase dura o sufuciente para os programadores se
familiarizarem com o projeto

30. XP - Ciclo de vida
Planejamento
É determinada a prioridade das histórias
É feito um acordo das funções que irão constar na
primeira liberação
Não deve exceder duas semanas

31. XP - Ciclo de vida
Iteração para liberação
Inclui várias iterações do sistema antes da sua primeira
liberação
A programação que foi feita durante a fase de
planejamento é quebrada em iterações sendo que cada
iteração leva de um a quatro semanas para ser
completada
A primeira iteração cria um sistema base com as
principais histórias
O cliente decide as histórias que vão ser implementadas
a cada iteração

32. XP - Ciclo de vida
Produção
Faz teste extra e checa o desempenho do sistema antes
que este seja entregue ao cliente
Podem existir mudanças
Reduz as iterações para uma semana
As idéias e sugestões são documentadas para
implementação futura durante a fase de manutenção

33. XP - Ciclo de vida
Manutenção
Depois da primeira liberação, o XP deve manter o
sistema rodando e introduzir novas iterações
A velocidade pode desacelerar para evitar erros no
sistema em produção
Pode haver mudanças na equipe e na sua estrutura

34. XP - Ciclo de vida
Morte
Cliente não tem mais histórias a serem implementadas
Sistema satisfaz as necessidades do cliente
É feita a documentação do sistema, mas nenhuma linha
de código é alterada
Pode ocorrer quando o sistema não esteja exibindo as
saídas corretas ou se tornou muito caro para
desenvolvimento adicional

35. XP - Papéis e responsabilidades
Cliente
Verificador
Fiscal (Tracker)
Técnico
Programador
Consultor
Gerente (Big Boss)

36. XP - Papéis e responsabilidades
Cliente
O cliente escreve as histórias e testes funcionais e
decide quando cada requisito deve ser satisfeito
Também determina a prioridade de implementação dos
requisitos

37. XP - Papéis e responsabilidades
Verificador
O verificador ajuda o cliente a escrever os testes
funcionais
Os verificadores rodam testes funcionais regularmente,
transmitem o resultado dos testes e mantém as
ferramentas de testes

38. XP - Papéis e responsabilidades
Fiscal (Tracker)
Fornece feedback ao processo XP
Traça as estimativas feitas pela equipe (por exemplo,
estimativas de custo) e dá o feedback de quão exatas
essas estimativas estão para melhorar as futuras
Determina o progresso de cada iteração e avalia se o
objetivo é alcançado com os recursos e o tempo
fornecidos ou se qualquer mudança é necessária
durante o processo

39. XP - Papéis e responsabilidades
Técnico
É a pessoa responsável pelo processo como um todo
Quem exerce esse papel deve possuir um
conhecimento amplo de toda a metodologia XP,
conhecimento esse que deve habilitar o técnico a guiar
os outros membros do time durante todo o processo

40. XP - Papéis e responsabilidades
Programador
Escreve os testes e programa mantendo o código do
programa o mais simples e definido possível
A primeira coisa que faz o processo XP obter sucesso é
a comunicação e coordenação com os outros
programadores e membros da equipe

41. XP - Papéis e responsabilidades
Consultor
É um membro externo que detém conhecimento técnico
específico necessário
Guia a equipe para resolver os problemas específicos

42. XP - Papéis e responsabilidades
Gerente (BIG BOSS)
Toma as decisões comunicando-se com a equipe de
projeto para determinar a situação atual e para distinguir
qualquer dificuldade ou deficiência no processo.

43. Práticas do XP
Jogo de planejamento Posse coletiva
Liberações em curto tempo Integração Continuada
Metáfora 40 horas por semana
Design simples Cliente no local
Teste Padrões de código
Reconstrução Área de trabalho aberta
Programação em par Regras justas

44. XP - Práticas
Jogo de planejamento
Programadores estimam o esforço para implementar as
histórias
Clientes decidem o escopo e tempo dos releases
Releases em curto tempo
Produz-se rapidamente um sistema simples
Atualizações freqüentes em ciclos curtos
Metáforas
Descrevem o funcionamento do sistema
Facilitam a comunicação programador/cliente

45. XP - Práticas
Design simples
Satisfazer estritamente as necessidades
Ênfase na agregação de valor
Testes
Dirigem o desenvolvimento do sistema
Testes unitários
Testes de aceitação
Reconstrução
O sistema é reestruturado visando sua melhoria
contínua

46. XP - Práticas
Programação em par
Dois programadores juntos em uma mesma máquina
Provê melhoria de qualidade, segundo experimentos
Posse coletiva
Qualquer parte do código pode ser alterada por
qualquer programador
Aumento na velocidade de desenvolvimento

47. XP - Práticas
Integração continuada
Novos blocos de código são integrados com freqüência
ao sistema
Mantém os progrmadores em sintonia
Requer testes adequados
40 horas por semana
Visa evitar erros por trabalho excessivo
Cliente no local
Comunicação constante com o cliente
Diminuição do número de documentos

48. XP - Práticas
Padrões de código
Garante a clareza do código, auxiliando a posse coletiva
Área de trabalho aberta
Espaço amplo para se trabalhar
Regras justas
As equipes têm regras próprias a serem seguidas
As regras são mutáveis, mas é preciso entrar num
acordo

49. Ruby on Rails
É um framework que torna fácil o desenvolvimento, a
distribuição e a manutenção de aplicações Web
Ele é uma das principais escolhas no desenvolvimento das ap
Web 2.0
Todas as aplicações Rails são feitas usando o padrão
arquitetural MVC (Model-View-Controler)

50. Ruby on Rails
Todas as aplicações Rails vêm com suporte a testes
integrados.O framework facilita o teste de aplicações e,
como resultado, as aplicações Rails tendem a ser testadas
As aplicações Rails são feitas na linguagem Ruby, uma
linguagem moderna, de script orientada a objetos
É fácil ler uma aplicação em Ruby, por ser uma linguagem
concisa e que facilita a expressão de idéias no código

51. Ruby on Rails
class Project < ActiveRecord::Base
belongs_to :portfolio
has_one :project_manager
has_many :milestones
validates_presence_of :name, :description
validates_acceptance_of :non_disclosure_agreement
validates_uniqueness_of :short_name
end

52. Ruby on Rails
Os projetos em Rails seguem uma dupla de conceitos
chaves:
DRY (Don't Repeat Yourself)
Convenção sobre configuração
Rails traz o que há de mais novo em padrões para
desenvolvimento Web (Ajax, REST)
O Rails facilita a distribuição e configuração das aplicações.
As mudanças são geridas facilmente e podem ser feitas e
desfeitas sem prejuízo algum para o desenvolvimento.

53. Ruby on Rails
Algumas ferramentas do Rails:
Migrations
Fixtures
Generator
Templates
Plugins

54. Caminhos Ágeis com o Rails

55. Caminhos Ágeis com Rails

56. Trabalhos Futuros
SCRUM, XP e certificações existentes (MPS.BR, CMMI,
PMBOK, etc)
Testar, validar e aperfeiçoar a metodologia proposta na
Empresa Júnior de Informática da UFS (Softeam Jr.)
utilizando o Ruby on Rails como uma das ferramentas de
desenvolvimento de software

57. quot;Try and fail, but not fail on tryquot;
Bons Caminhos