RUP e Scrum: Processos de Desenvolvimento de Software

Classificado em Tecnologia

Escrito em em português com um tamanho de 8,38 KB

VISÃO GERAL DO RUP
Definição
- O nome é uma abreviação de Rational Unified Process
- mas na verdade é Processo + Métodos + Linguagem (UML)
- e os autores argumentam que é Framework pára gerar processos

RUP – RATIONAL UNIFIED PROCESS
- Processo + Métodos + Linguagem (UML)
- Framework pára gerar processos
- Conjunto de atividades
- bem definidas
- com responsáveis
- com artefatos de entrada e Sáída
- com dependências entre as mesmas e ordem de execução
- com modelo de ciclo de vida
- descrição sistemática de como devem ser realizadas
- guias (de ferramentas ou não), templates
- utilizando diagramas de UML

O RUP é:

- iterativo e incremental
- guiado por casos de uso
- baseado na arquitetura do sistema
- organizado em fases, iterações, fluxos, atividades e passos

ESTRUTURA ESTÁTICA

 Fluxos de atividades
 Atividades
 passos
 entradas e Sáídas
 guias (de ferramentas ou não), templates
 Responsáveis (papel e perfil, não pessoa)
 Artefatos

ESTRUTURA DINÂMICA

O ciclo de vida de um sistema consiste de quatro fases:
|concepção | elaboração | construção | transição |
- Concepção (define o escopo do projeto)
- Elaboração (detalha os requisitos e a arquitetura)
- Construção (desenvolve o sistema)
- Transição (implanta o sistema)

Cada fase é dividida em iterações, e cada uma delas é:
- é planejada
- realiza uma seqüência de atividades (de elicitação de requisitos, análise e projeto, implementação, etc.) distintas
- geralmente resulta em uma versão executável do sistema
- é avaliada segundo critérios de sucesso previamente definidos

ARQUITETURA

- Visão geral do sistema em termos dos seus subsistemas e como estes se relacionam 
-  A arquitetura é prototipada e definida logo nas primeiras iterações 
-  O desenvolvimento consiste em complementar a arquitetura 
-  A arquitetura serve pára definir a organização da equipe de desenvolvimento e identificar oportunidades de reúso

PROCESSO GUIADO POR CASOS DE USO


Os casos de uso não servem apenas pára definir os requisitos do sistema
- Várias atividades do RUP são guiadas pelos casos de uso:
- planejamento das iterações
- criação e validação do modelo de projeto
- planejamento da integração do sistema
- definição dos casos de teste


SCRUM

 Uma alternativa de utilizar métodos ágeis na gerência de projetos
 Pode ser aplicável a qualquer tipo de projeto
 É simples
– Processo, artefatos e regras são poucos e fáceis de
entender
– A simplicidade pode ser decepcionante aós acostumados
com metodologias clássicas

Papéis no Scrum: Product Owner, Scrum Máster e a Equipe.
1. Product Owner(Pó):
Definir as Funcionalidades do produto;
 Definir quais requisitos serão necessários no Product Backlog;
 Decidir a data de liberação e conteúdo do Release;
 Responder pela rentabilidade do Produto (ROI);
 Priorizar as funcionalidades de acordo com o valor de marcado;
 Ajustar as funcionalidades e prioridades a cada 30 dias, conforme necessário;
 Aceitar ou Rejeitar os resultados de Trabalho;
 Normalmente esse papel é desempenhado pelo cliente ou por um gerente da empresa.
2. Scrum Máster
 Garante que o projeto do produto esteja progredindo;
 Garante que cada membro do time tenha as ferramentas necessárias pára realizar seus trabalhos;
 Organiza reuniões (Daily Scrum) e facilita os releases;
 Monitora o trabalho sendo feito;
 Facilita o desenvolvimento de release;
 É responsável por difundir os valores do Scrum e suas práticas;
 Protege o time contra interferências externas;
 Possibilita uma cooperação estreita entre todos os papéis e funções;
3. Equipe/Time/Scrum Team (EQ)
 Grupo pequeno, geralmente de 3 a 9 integrantes;
 Seleciona o objetivo do Sprint e especifica os produtos de trabalho necessários;
 Multifuncional, Auto gerenciada, Auto Organizada;
 Tem a liberdade de fazer qualquer coisa dentro das diretrizes do projeto pára alcançar o objetivo do Sprint.
 Apresenta os produtos de trabalho ao Product Owner;
 Todos podem e devem ocupar todas as funções (Eng. De Software, Arquitetos, Programadores, Analista, Peritos em Qualidade, Testadores e Web-Designers)


Fases: Planejamento, Sprints, Encerramento.
Planejamento:
1. Estima datas e custos.
2. Criação do Product BackLog: O Product Owner cria uma lista de funcionalidades com as necessidades do cliente e prioriza-as (cima: mais importante, baixo: menos importante).
3. Definição de equipes e seus líderes
4. Criação do Release BackLog: O Scrum Team prioriza os requisitos e estima quanto tempo de trabalho envolve cada uma delas. Estimando o tempo total desse Release.
A. Reunião de Estimativa: E->Backlog do produto priorizado; S-> Itens relevantes do backlog estimados; P-> Equipe e ScrumMaster
B. Sprint Planning I: E-> Backlog priorizado e estimado; S-> Objetivo do Sprint, Backlog Selecionado; P-> Todos
C. Sprint Planning II: E-> Backlog Selecionado; S->Comprometimento com o objetivo do Sprint, Itens Quebrados em tarefas; P->Equipe e ScrumMaster
Sprint
Pára estimular o contato entre a empresa e o cliente, os projetos são interrompidos em períodos regulares de tempo. Ao final de cada Sprint, o cliente recebe um conjunto de funcionalidades desenvolvidas e prontas pára ser utilizadas.
1. O time recebe uma parte do Backlog pára desenvolvimento (não sofré alterações no Sprint);
2. Duração de 1 a 4 semanas;
3. Sempre apresentam um executável ao final;
4. Planejamento do Sprint: Ocorre em duas partes, cada uma delas com duração de quatro horas. Na primeira parte do planejamento, o Scrum Máster reúné-se com o Product Owner pára verificar qual é o Product Backlog. Na segunda parte, o Scrum Máster reúné-se com a Equipe pára estimar o esforço necessário pára os itens do Product Backlog (usando estimativa ágil como Planning Poker) e pára planejar o Sprint.
5. Andamento do Sprint: Durante o Sprint, os itens do Product Backlog que devem ser entregues são tratados em um artefato conhecido como Sprint Backlog, que contém os itens do Release Backlog subdivididos em tarefas menores. As tarefas são responsabilidade da Equipe, que tem autonomia pára decidir como elas devem ser executadas.
6. Reuniões Diárias (Daily Scrum):
 Cerca de quinze minutos de duração;
 Todos respondem às perguntas: “oque você realizou desde a última reunião?”, “quais problemas enfrentou?”, “em que você trabalhará até a próxima
reunião?”;
 Benefícios: (integração de equipe, solução de problemas, progresso medido (menos riscos);
7. Revisão
 Product Owner valida os itens entregues e verifica se o objetivo do Sprint foi atingido.
 Apresentação do Produto ao cliente
 Benefícios(resultados concretos p/ o cliente, integrar/testar boa parte do sw, motiva a equipe);
*Burn-Down Chart: Umas das melhores ferramentas de visualização de projeto, assegura que o projeto esteja dentro do prazo.

Entradas relacionadas: