RUP SCRUM

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Processo de Software: RUP / SCRUM
José dos Reis Mota - 2015
Problemas em projetos
atraso 
estouro em orçamentos 
escopos mal definidos
http://blogs.msdn.com/blogfiles/andredias/WindowsLiveWriter/ChaosReport2009novasinformaesvelhosprobl_10E/caos-report2009_2.jpg
RUP (Rational Unified Process)
Workflows estáticos
Fonte: Sommerville (Engenharia de Software)
Ciclo
Período de tempo que decorre entre o início do projeto e o lançamento do produto (ou cancelamento do projeto).
Geralmente, distingue-se o ciclo de desenvolvimento de um novo produto dos ciclos de evolução/manutenção.
Linha de tempo típica para um Ciclo de Desenvolvimento 
(I = Iniciação, E = Elaboração, C = Construção e T = Transição)
Fases do RUP
Concepção
Estabelecer o business case para o sistema.
Elaboração
Desenvolver um entendimento do domínio do problema e a arquitetura do sistema.
Construção
Projeto, programação e teste de sistema.
Transição
Implantar o sistema no ambiente operacional.
Iterações 
Cada fase pode incluir uma ou mais iterações. 
Efetua-se desenvolvimento de software em cada iteração e cada uma delas produz um determinado resultado concreto (interno ou externo). 
Esse resultado serve para analisar o progresso do projeto. 
O produto de software cresce incrementalmente à medida que se iteram as atividades.
Iterações em Projetos
Princípios do RUP
Fonte: IBM RUP.
Desenvolvimento iterativo
Papeis e Responsabilidades no RUP
Analistas: organizam os papeis envolvidos principalmente na identificação e na investigação de requisitos. 
Analista de Sistemas, Designer de Negócios, Revisor do Modelo de Negócios, Analista do Processo de Negócios, Revisor de Requisitos, Especificador de Requisitos, Analista de Teste e Designer de UI
Desenvolvedor: organizam os papeis envolvidos principalmente no design e desenvolvimento de software. 
Designer de Componentes, Revisor de Código, Designer de Banco de Dados, Implementador, Integrador, Arquiteto de Software, Revisor de Arquitetura, Revisor de Design, Designer de Teste;
Testador: organizam os papeis que lidam com habilidades específicas exclusivas para teste 
Gerente: organizam os papeis envolvidos no gerenciamento e na configuração do processo de engenharia de software. 
Engenheiro de Processo, Gerente de Projeto, Gerente de Controle de Mudança, Gerente de Configuração, Gerente de Implantação, Revisor do Projeto e Gerente de Testes.
Métodos Ágeis
Princípios dos métodos ágeis
Indivíduos e interações entre eles 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 as mudanças mais que seguir um plano.
Mesmo havendo valor nos itens à direta, valoriza-se mais os itens à esquerda.
Utilização Das Funcionalidades
(adaptado de HEMRAJANI, 2009 p.275)
Utilização Das Funcionalidades
Metodologias Ágeis mais usadas
SCRUM
Leve
Simples de entender
Difícil de dominar
O framework Scrum consiste nas equipes do Scrum associadas a papeis, eventos, artefatos e regras.
Emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.
Guia do SCRUM, disponível em http://www.scrum.org/Scrum-Guides
SCRUM
Pilares do SCRUM
Pilar Transparência
Processo visível para todos os responsáveis (compartilhar linguagem, definição de “Pronto”)
Pilar Inspeção
Garantir a correta execução em direção ao objetivo (revisão, auxílio).
Inspeção não deve ser tão frequente que atrapalhe a execução das tarefas.
Pilar Adaptação
Aliado da Inspeção: acompanhamento das mudanças.
Se necessário, ajuste, o mais breve possível, para adequar produto.
Pilares com o mesmo ideal: o desenvolvimento de forma rápida, assertiva e significante.
Reuniões (4 oportunidades)
Time SCRUM
Composto por:
Product Owner (PO)
Equipe (Time) de Desenvolvimento (ED) 
Scrum Master (SM)
Product Owner
Uma pessoa, não um comitê.
Decisões no conteúdo e na priorização do Backlog do Produto.
Gerenciamento do Backlog do Produto:
Expressar claramente os itens
Ordenar os itens para alcançar metas e missões;
Garantir o valor do trabalho realizado pela ED;
Garantir que o Backlog do Produto seja visível, transparente, claro
Garantir que a ED entenda os itens no nível necessário.
Aceitar ou rejeitar os entregáveis
Equipe de Desenvolvimento
Auto-organizável
Multifuncional
Título único: Desenvolvedor
Divisão de Responsabilidades
Não contém subdivisões. Ex.: teste, suporte, análise de negócios.
Tamanho ideal: pequeno suficiente para se manter ágil e grande o suficiente para completar parcela significativa de trabalho (3 a 9 pessoas).
Scrum Master
Garantir que o Scrum seja entendido e aplicado.
Servir ao Product Owner:
Técnicas para gerenciar backlog do produto.
Comunicar a visão, objetivo e itens do Backlog do Produto.
Ensinar o Time Scrum a criar itens de Backlog do Produto de forma clara e concisa.
Compreender a longo-prazo o planejamento do Produto.
Servir à Equipe de Desenvolvimento:
Treinamento em auto-gerenciamento e interdisciplinaridade.
Ensinar e liderar.
Remover impedimentos .
Servir à Organização
Sprint
Time-boxed de um mês ou menos.
Um “pronto”, versão incremental potencialmente utilizável do produto, é criado.
Não são feitas mudanças que podem afetar o objetivo da Sprint.
A composição da Equipe de Desenvolvimento permanecem constantes.
As metas de qualidade não diminuem.
O escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido.
Pode ser cancelada pelo Product Owner (cancelamentos de sprints são traumáticos, mas incomuns).
Reunião de Planejamento da Sprint
Time-box de 8 horas (para Sprint de 30 dias).
Duas partes:
O que será entregue como resultado do incremento da próxima Sprint?
Entradas:
o Backlog do Produto, 
o mais recente incremento do produto, 
a capacidade projetada da ED, 
o desempenho passado da ED.
Trabalho da ED nesta etapa: 
o número de itens selecionados do Backlog do Produto.
Como o trabalho necessário para entregar o incremento será realizado?
Backlog da Sprint: 
itens selecionados para a Sprint
plano de entrega destes itens
Ao final da reunião: 
explicar como completar o objetivo da Sprint (o incremento previsto).
Reunião diária
Time-boxed de 15 minutos
Sincronizar as atividades e criar um plano para as próximas 24 horas.
Durante a reunião cada integrante da ED esclarece:
O que foi completado desde a última reunião?
O que será feito até a próxima reunião?
Quais os obstáculos que estão no caminho?
Scrum Master marca a reunião, mas a ED é responsável por conduzi-la.
Revisão da Sprint
Time-boxed de 4 horas para Sprint de 30 dias.
Inspecionar o incremento e adaptar o Backlog do Produto se necessário.
O Product Owner identifica o que ficou “Pronto” e o que não ficou “Pronto”.
Tarefas:
A Equipe de Desenvolvimento discute quais problemas ocorreram dentro da Sprint e como foram resolvidos.
A Equipe de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento.
O Product Owner discute o Backlog do Produto tal como está e projeta as prováveis datas de conclusão.
O grupo colabora sobre o que fazer a seguir (entradas para a Reunião de Planejamento da próxima Sprint).
Retrospectiva da Sprint
Time-boxed de três horas para Sprint de um mês.
Inspecionar como a última Sprint foi em relação as pessoas, relações, processos e ferramentas.
Identificar e ordenar os principais itens que foram bem e as potenciais melhorias.
Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho.
Resultado:
Identificação de melhorias que serão implementadas na próxima Sprint. 
A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a si próprio.
Artefatos
Backlog do Produto
Lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas
no produto nas futuras versões.
Ordenado por valor, risco, prioridade e necessidade
Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa. 
Estimativas mais precisas são feitas com base na maior clareza e maior detalhe.
Enquanto um produto é usado, ganha valor, e o mercado oferece retorno, o Backlog do Produto torna-se uma lista maior e mais completa . 
Artefato vivo: requisitos nunca param de mudar.
Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo pode ser resumido. 
O Product Owner acompanha o total do trabalho restante pelo menos a cada Reunião de Revisão da Sprint.
Artefatos
Backlog da Sprint
Conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano de entrega do incremento “Pronto” do produto
Backlog da Sprint vai surgindo durante a Sprint
Incremento
Soma de todos os itens do Backlog do Produto completados durante a Sprint e tudo das Sprints anteriores. 
Ao final da Sprint um novo incremento deve estar “Pronto”.
Estórias de Usuário
Surgiram no XP, mas podem ser utilizadas em qualquer processo incremental.
Afirmação do que o usuário quer fazer (linguagem de negócios).
As Estórias do Usuário podem ser representadas por meio do seguinte template: “Como um(a) <PAPEL> gostaria/devo <FUNÇÃO/META> para/por <VALOR DE NEGÓCIO/MOTIVO>”. 
“Como <supervisor> eu gostaria de <autorizar> um <desconto numa venda>”
Como <candidato a emprego>, quero <procurar um trabalho>, para <que eu possa avançar na minha carreira>
Cartão de estória – 
Frente (descrição)
Fonte: http://www.carlostristacci.com.br/blog/estorias-do-usuario/
Cartão de Estória –
Verso (casos de teste)
Fonte: http://www.carlostristacci.com.br/blog/estorias-do-usuario/
Mais sobre Estórias de Usuário
Escrevendo Estórias do Usuário Eficazes. Disponível em: http://pt.slideshare.net/Ridlo/escrevendo-estrias-do-usurio-eficazes
SCRUM Experience. Disponível em: http://pt.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum 
Esquema bem básico de KanBan
Princípios do SCRUM
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; 
Cooperação constante entre pessoas que entendem do ‘negócio’ e desenvolvedores;
Projetos surgem através de indivíduos motivados, e que deve existir uma relação de confiança; 
Design do software deve prezar pela excelência técnica; 
Simplicidade; 
Rápida adaptação às mudanças; 
Indivíduos e interações mais do que processos e ferramentas;
Princípios do SCRUM
Software funcional mais do que documentação extensa; 
Colaboração com clientes mais do que negociação de contratos; 
Responder a mudanças mais do que seguir um plano.
Princípios do SCRUM
RUP ou SCRUM: Qual modelo utilizar?
Tanto o modelo RUP, quanto o SCRUM propõem o modelo de ciclo de vida iterativo e incremental (agilidade nas entregas do projeto).
RUP é um modelo de desenvolvimento de software e SCRUM é um modelo de gerenciamento ágil de projetos: são justamente estes conceitos que permitem mesclar os dois modelos, pois um aborda mais a engenharia do software como um todo e o outro a gestão do projeto.
Ciclo de vida Scrum x RUP
Revista Eng. Software Magazine 54.