Upload
marcosmaozinha
View
18.225
Download
4
Embed Size (px)
DESCRIPTION
Citation preview
Universidade Federal de SergipeDepartamento de ComputaçãoMetodologias 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
Agenda
IntroduçãoCaracterísticasÁgeis x RADExemplos de metodologias ágeisScrumXP Ruby on RailsTrabalhos futuros
Introdução
Aliança de Desenvolvimento Ágil de SoftwareFundada em 11-13/02/200117 pessoas envolvidas
Metodologia ÁgilHá ModelagemHá DocumentaçãoHá Planejamento
Valoriza-seIndividualidade e interações > processos e ferramentasSoftware funcional > documentaçãoColaboração do cliente > negociação de contratoResponder às mudanças > seguir um plano
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
Características
Construir projetos com individualismo e motivaçãoProporcionar 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
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
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
Ágeis x RAD
Não admite protótipos
Projetos são quebrados em funcionalidadesNo 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
Á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
Exemplos de Metodologias Ágeis
Crystal Family
FDD (Feature Driven Development)
DSDM (Dynamic Systems Development Method)
ASD (Adaptative Software Development)
Scrum
XP (eXtreme Programming)
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.
Feature Driven DevelopmentFDD
CaracterísticasResultados úteis a cada duas semanas ou menos Blocos bem pequenos de funcionalidade valorizada pelo cliente, chamados "Features" 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 gerentesFornece uma forma de saber, no início, se o plano e a estimativa são sólidos
ESTRUTURA FDDFonte: http://www.heptagon.com.br/fdd-estrutura
Dynamic Systems Development MethodDSDM
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
Dynamic Systems Development MethodDSDM
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.
Adaptative Software DevelopmentASD
Atuação principalmente em sistemas complexosEstimula o desenvolvimento com repetições e uma constante prototipaçãoCiclo de vida composto por três fases:
Especulação: utilizada no lugar de planejamentoColaboração: realça a importância de trabalho de equipeAprendizado: devido à necessidade para reconhecer e reagir a decisões erradas e o fato que os requisitos podem mudar durante o desenvolvimento.
Scrum
O que é Scrum
Papéis em Scrum
Fases do Scrum
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
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
Fases do Scrum
Pré-game
PlanejamentoDefine um novo release através do backlogEstimativa de prazos e custos
Arquitetura
Revisão do backlogEstebelece como os itens do backlog serão implementados
Fases do Scrum
Game
Sprints
Desenvolvimento : implementa os itens do backlog e realiza as mudanças necessáriasCorte : cria uma versão executável daquilo que foi implementadoRevisão : avalia o progresso do desenvolvimento, adicionando novos itens ao backlogAjuste : consolida as informações adquiridas na revisão
Fases do Scrum
Postgame
Fechamento
Prepara o produto desenvolvido para o releaseTesta o sistemaPrepara a documentação para o usuárioPromove treinamento
Fases do Scrum
XP (eXtreme Programming)
Introdução
Ciclo de Vida
Papéis e responsabilidades
Práticas
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
XP - Introdução
XP - Ciclo de vida
Exploração
Planejamento
Iterações para liberação
Produção
Manutenção
Morte
XP - Ciclo de vida
XP - Ciclo de vida
Exploração
O cliente escreve históriasCada história descreve uma função adicionada ao programaEquipe se familiariza com as técnicas, ferramentas, tecnologias e práticas que serão usadas no projetoAs possíveis arquiteturas são exploradas, construindo-se um protótipo do sistemaEsta fase dura o sufuciente para os programadores se familiarizarem com o projeto
XP - Ciclo de vida
Planejamento
É determinada a prioridade das históriasÉ feito um acordo das funções que irão constar na primeira liberaçãoNão deve exceder duas semanas
XP - Ciclo de vida
Iteração para liberação
Inclui várias iterações do sistema antes da sua primeira liberaçãoA 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 completadaA primeira iteração cria um sistema base com as principais históriasO cliente decide as histórias que vão ser implementadas a cada iteração
XP - Ciclo de vida
Produção
Faz teste extra e checa o desempenho do sistema antes que este seja entregue ao clientePodem existir mudançasReduz as iterações para uma semanaAs idéias e sugestões são documentadas para implementação futura durante a fase de manutenção
XP - Ciclo de vida
Manutenção
Depois da primeira liberação, o XP deve manter o sistema rodando e introduzir novas iteraçõesA velocidade pode desacelerar para evitar erros no sistema em produçãoPode haver mudanças na equipe e na sua estrutura
XP - Ciclo de vida
Morte
Cliente não tem mais histórias a serem implementadasSistema satisfaz as necessidades do clienteÉ feita a documentação do sistema, mas nenhuma linha de código é alteradaPode ocorrer quando o sistema não esteja exibindo as saídas corretas ou se tornou muito caro para desenvolvimento adicional
XP - Papéis e responsabilidades
ClienteVerificadorFiscal (Tracker)TécnicoProgramadorConsultorGerente (Big Boss)
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
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
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
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
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
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
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.
Práticas do XP
Jogo de planejamentoLiberações em curto tempoMetáforaDesign simplesTesteReconstruçãoProgramação em par
Posse coletivaIntegração Continuada40 horas por semanaCliente no localPadrões de códigoÁrea de trabalho abertaRegras justas
XP - Práticas
Jogo de planejamentoProgramadores estimam o esforço para implementar as históriasClientes decidem o escopo e tempo dos releases
Releases em curto tempo
Produz-se rapidamente um sistema simplesAtualizações freqüentes em ciclos curtos
Metáforas
Descrevem o funcionamento do sistemaFacilitam a comunicação programador/cliente
XP - Práticas
Design simplesSatisfazer estritamente as necessidadesÊnfase na agregação de valor
Testes
Dirigem o desenvolvimento do sistemaTestes unitáriosTestes de aceitação
Reconstrução
O sistema é reestruturado visando sua melhoria contínua
XP - Práticas
Programação em parDois programadores juntos em uma mesma máquinaProvê melhoria de qualidade, segundo experimentos
Posse coletiva
Qualquer parte do código pode ser alterada por qualquer programadorAumento na velocidade de desenvolvimento
XP - Práticas
Integração continuadaNovos blocos de código são integrados com freqüência ao sistemaMantém os progrmadores em sintoniaRequer testes adequados
40 horas por semana
Visa evitar erros por trabalho excessivo
Cliente no localComunicação constante com o clienteDiminuição do número de documentos
XP - Práticas
Padrões de códigoGarante a clareza do código, auxiliando a posse coletiva
Área de trabalho aberta
Espaço amplo para se trabalhar
Regras justasAs equipes têm regras próprias a serem seguidasAs regras são mutáveis, mas é preciso entrar num acordo
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 aplicações Web 2.0
Todas as aplicações Rails são feitas usando o padrão arquitetural MVC (Model-View-Controler)
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
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_nameend
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.
Ruby on Rails
Algumas ferramentas do Rails:
MigrationsFixturesGeneratorTemplatesPlugins
Caminhos Ágeis com o Rails
Caminhos Ágeis com Rails
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
"Try and fail, but not fail on try"
Bons Caminhos