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