SlideShare uma empresa Scribd logo
1 de 32
Metodologias de Desenvolvimento
de Software Integradas
Frank Coelho
Especialista em desenvolvimento
de software.
Solução organizacional para otimização de processos
de desenvolvimento de software,
visando o desenvolvimento com qualidade
com foco na entrega.
Tecnologias
• Linux
• Apache
• MySQL
• PHP
• C#
• VB.NET
• SharePoint
• Project
Server
• Exchange
Server
• Windows
Server
• JBossApp
Server
• Oracle
Weblogic
• Hibernate
• Spring
Framework
• Struts
Framework
• Oracle
• PostgreSQL
• IBM DB2
• MySQL
Java DatabaseMicrosoft .
NET
LAMP
Tópicos abordados
* Problemas comuns em projetos de desenvolvimento de
software.
* O que é uma metodologia?
* Metodologias para desenvolvimento de software.
Problemas comuns em projetos de
desenvolvimento de software.
Falhas de Comunicação
Estatísticas
Motivos
• Consomem mais recursos que o orçado;
• Consomem mais tempo que o estimado;
• Não entregam o que foi combinado;
(+) 500 mil projetos (pequeno -
grande porte) de software nos Brasil.
Para resolver esses problemas, seguimos uma
metodologia.
O que é uma Metodologia?
Padrões
Comunicação
Objetivo comum
Aproveitamento recursos
Metodologia
Equipe
Metodologias para Desenvolvimento
de Software
• Metodologia tradicional: PDI-SW (Processo de
Desenvolvimento Iterativo de Software)
• Metodologia ágil: SCRUM
SCRUM
• Metodologia de desenvolvimento ágil nascida em empresas de
fabricação de carros em 1986 (Takeuchi e Nonaka).
• Jeff Sutherland, John Scumniotales, e Jeff McKenna –
documentaram e implementaram - Easel Corporation em 1993.
• Tipo de formação do Rugby.
• Passou a ser utilizado no mundo a partir de 1995.
• Aborda uma filosofia de gerenciamento com foco no resultado.
Sprint
•Cada sprint é uma iteração que segue um ciclo e entrega incremento
de software pronto.
•Um backlog é conjunto de requisitos, priorizado pelo Product Owner
(responsável pelo ROI “retorno sobre investimento” e por conhecer as
necessidades do cliente);
•Há entrega de conjunto fixo de itens do backlog em série de interações
curtas ou sprints;
•Breve reunião diária, ou daily scrum, em que cada participante fala
sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o
impede de seguir avançando (também chamado de Standup Meeting ou
Daily Meeting, já que os membros da equipe geralmente ficam em pé
para não prolongar a reunião).
•Breve sessão de planejamento, na qual os itens do backlog para uma
sprint (iteração) são definidos;
•Retrospectiva, na qual todos os membros da equipe refletem sobre a
sprint passada.
BACKLOG
Planejamento de sprint (Sprint Planning): Antes de todo sprint, o Product Owner, o Scrum Master e
a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Product Owner
mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser
repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do
produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A
Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser
implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam
o backlog do sprint.
Product Backlog
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O Product
Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente.
O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão
deste.
Sprint Backlog
O Sprint Backlog é uma lista de itens selecionados do Product backlog e contém tarefas concretas
que serão realizadas durante o próximo sprint para implementar tais itens selecionados. O Sprint
Backlog é uma representação em tempo real do trabalho que o Development Team planeja
concluir na sprint corrente, e ele pertence unicamente ao Development Team.
Burndown Chart
O Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que não
ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no Sprint e o eixo
Y os dias que representam o tamanho do Sprint.
Os papéis principais em equipes Scrum são aqueles comprometidos com o projeto no processo do
Scrum - são os que produzem o produto (objetivo do projeto).
Product Owner (dono do produto)
O Product Owner representa a voz do cliente e é responsável por garantir que a equipe
agregue valor ao negócio. O Product Owner escreve centrado nos itens do cliente (histórias
tipicamente do usuário), os prioriza e os adiciona para o product backlog. Equipes de Scrum
devem ter um Product Owner, e, embora esse possa também ser um membro da equipe de
desenvolvimento, recomenda-se que este papel não seja combinado com o de ScrumMaster.
Equipe (Development Team)
A equipe é responsável pela entrega do produto. A equipe é tipicamente composta de 5-9
pessoas com habilidades multifuncionais que fazem o trabalho real (analisar, projetar,
desenvolver, testar técnicas de comunicação, documentos, etc.) Recomenda-se que a equipe
seja auto-organizada e auto-conduzida, mas que muitas vezes trabalhem com alguma forma
de projeto ou gestão de equipe.
Scrum Master
Scrum é facilitado por um Scrum Master, que é responsável pela remoção de impedimentos à
capacidade da equipe para entregar o objetivo do sprint / entregas. O Scrum Master não é o
líder da equipe, mas age como um tampão entre a equipe e qualquer influência ou distração.
O Scrum Master garante que o processo Scrum seja usado como pretendido. O Scrum
Master é o responsável pela aplicação das regras. Uma parte fundamental do papel do
Scrum Master é proteger a equipe e mantê-la focada nas tarefas em mãos. O papel também
tem sido referido como um líder-servo para reforçar essa dupla perspectiva.
Papéis principais
Obrigado!
Proposta.
• Usar os pilares fundamentais do RUP e seus conceitos e
métodos, unificado com as melhores praticas do CMMI.
Definição de processo organizacional sobre a gestão do
SCRUM.
• Utilizar aspectos básicos definindo um mínimo de
documentação inicial tanto quanto necessário.
• Foco na entrega com garantia de qualidade.
• Reuso de artefatos e funcionalidades (Frameworks)
• Formar muito mais que um time, um grupo de pessoas
com os mesmos objetivos e que acreditem no negocio.
Pilares do RUP
Gráfico de esforço nas fases
Concepção Esta fase do RUP abrange as tarefas de comunicação
com o cliente e planejamento. É feito um plano de projeto avaliando os
possíveis riscos, as estimativas de custo e prazos, estabelecendo as
prioridades, levantamento dos requisitos do sistema e preliminarmente
analisá-lo. Assim, haverá uma anuência das partes interessadas na
definição do escopo do projeto, onde são examinados os objetivos
para se decidir sobre a continuidade do desenvolvimento.
Elaboração Abrange a Modelagem do modelo genérico do processo.
O objetivo desta fase é analisar de forma mais detalhada a análise do
domínio do problema, revisando os riscos que o projeto pode sofrer e a
arquitetura do projeto começa a ter sua forma básica. Indagações
como “O plano do projeto é confiável?”, “Os custos são admissíveis?”
são esclarecidas nesta etapa.
Fase de Construção: Desenvolve ou Adquire os componentes de
Software. O principal objetivo desta fase é a construção do sistema de
software, com foco no desenvolvimento de componentes e outros
recursos do sistema. É na fase de Construção que a maior parte de
codificação ocorre.
Fase de Transição: Abrange a entrega do software ao usuário e a fase
de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o
disponível e compreendido pelo usuário final. As atividades desta fase
incluem o treinamento dos usuários finais e também a realização de
testes da versão beta do sistema visando garantir que o mesmo possua
o nível adequado de qualidade.
Fase de Concepção
• Finalidade
– Definir objetivos e viabilidade do projeto (o ideia do projeto) e o escopo de vários aspectos
• Atividades
– Definir: critérios de sucesso de projeto, riscos, recursos necessários e data de realização das
principais etapas
– Delimitar o escopo do projeto
– Identificar os atores que interagem com o sistema
– Identificar as interações dos atores com o sistema (casos de uso)
• Resultados (artefatos)
– Documento de visão: visão geral dos requisitos, características e restrições essenciais do
projeto.
– Modelo inicial de casos de uso (10%-20%).
– Glossário do projeto (opcionalmente um modelo de domínio).
– Definição de objetivos e viabilidade do projeto incluído contexto, critérios de sucesso e prognóstico
financeiro.
– Avaliação inicial de riscos.
– Plano de projeto, com fases e interações.
– Modelo de negócios, se necessário.
– Um ou vários protótipos.
• Critérios de Satisfação
– Concordância quanto à definição de escopo e estimativas de custo e cronograma.
– Compreensão dos requisitos funcionais.
– Credibilidade das estimativas de custo, cronograma, prioridades, riscos, e processo de
desenvolvimento.
– Profundidade e amplitude dos protótipos desenvolvidos.
– Custos planejados versus realizados.
Fase de Elaboração
• Finalidade
– eliminar os elementos de maior risco do projeto através da criação de uma arquitetura coerente
e consistente da solução
• Atividades
– Construir protótipos executáveis, em uma ou mais interações
– Atacar os casos de uso críticos, que expõe os maiores riscos técnicos
– Construir protótipos evolucionários ou descartáveis, com objetivo de analisar custos-benefícios,
demonstrar para investidores, clientes e usuários
• Resultados (artefatos)
– Modelo de casos de uso (80% ou mais).
– Requisitos não funcionais
– Descrição da arquitetura do software
– Protótipos arquiteturais executáveis
– Revisão da visão de negócios e lista de riscos
– Plano detalhado de desenvolvimento do projeto, com interações e critérios de avaliação
– Plano de processo de desenvolvimento
– Manual de usuário preliminar
• Critérios de Satisfação (para suporte à decisão sobre continuar ou não com o projeto)
– A visão do produto é estável?
– A arquitetura é estável?
– A demonstração executável mostrou que os elementos de maior risco foram abordados
satisfatoriamente?
– O plano de desenvolvimento está suficientemente detalhado e preciso? O plano é consistente e
coerente?
– Todos os interessados concordam quando à coerência entre visão, plano e arquitetura?
– Os custos planejados e executados estão aceitáveis?
Fase de Construção
• Finalidade
– Desenvolver todos os componentes e características não resolvidas nas fases
anteriores, testando-as e integrando-as na forma de um produto.
• Atividades
– Diversas
• Resultados (artefatos)
– O produto, descrito e integrado nas plataformas adequadas
• Critérios de Satisfação
– A release do produto é suficientemente estável e amadurecida para ser entregue ao
usuário?
– Todos os envolvidos e interessados estão preparados para a fase de transição?
– O consumo de recursos é ainda aceitável?
Fase de Transição
• Finalidade
– Realizar a transição do produto para a comunidade de usuários
• Atividades
– “beta teste”
– Operações paralelas com sistema legado
– Conversão de bases de dados
– Treinamento de usuários a mantenedores
– Roll-out para setores de marketing, distribuição e vendas
• Resultados (artefatos)
– Em conformidade com atividades
• Critérios de Satisfação
– O usuário ainda está satisfeito?
– Os custos de manutenção ainda são aceitáveis?
Ferramentas de gerenciamento do ciclo de
vida e produção
• Visual Studio
• Arquitetura
• Dados
• Testes
• TFS
• Versionamento
• Tarefas
• Sprints
• Backlogs
• Project
• Cronograma
• Tarefas
• Custos
• Studio manager SQL
• Modelo de dados
Perfil do time técnico
• Gerente de Projetos
• Arquiteto de Software
• Analista de requisitos
• Analista de sistema
• Desenvolvedores
• Analista de Testes
• Documentador
Fluxo de trabalho
Descrição para as fases
CMMI
• CMMI é uma família de conjuntos de melhores práticas para apoiar a
melhoria de desenvolvimento, serviços e aquisição.
• Implementar um modelo baseado nas melhores praticas, levando em
conta o cenário especifico e atual da empresa, voltado para melhoria
continua e crescimento do grau de maturidade do ciclo de vida da
construção de software.
• Processo continuo visando o alcance dos resultados esperados.
• Trabalhar nos detalhes no intuito de evitar esforço desnecessário.
• União das dimensões de construção do CMMI:
• Pessoas
• Ferramentas
• Procedimentos
O que esperar.
• Não existe retorno a curto prazo.
• Certificação CMMI
• Certificação ISO
• Controle absoluto de projetos e custos
• Baixo Custo de manutenção
• Produtos robustos e escaláveis
• Melhoria estratégica de posição no mercado
• Gerencia de configuração consolidada
• Lucros maiores
• Ser um caso de sucesso
• Atingir a EXCELENCIA
Fazer a coisa certa é uma escolha que deve ser mantida, que exige
esforço e comprometimento e o retorno só é visto depois.
Obstáculos são apenas grandes oportunidades de sermos melhores...
Homens comuns contam histórias, homens extraordinários fazem a
história...
Referências
• http://www.infoq.com/presentations/The-Roots-of-Scrum
• http://pt.wikipedia.org/wiki/Scrum
• http://www.agilealliance.org/system/article/file/888/file.pdf
• http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Fase
_de_Concep.C3.A7.C3.A3o
• http://www.cmmi.de/#el=CMMI-DEV/0/HEAD/folder/folder.CMMI-
DEV

Mais conteúdo relacionado

Mais procurados

Plano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents ControlPlano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents Controlazarael2607
 
SCRUM Processo de Desenvolvimento de Software
SCRUM Processo de Desenvolvimento de SoftwareSCRUM Processo de Desenvolvimento de Software
SCRUM Processo de Desenvolvimento de Softwareelliando dias
 
Apresentação Scrum, Xp e Kanban
Apresentação Scrum, Xp e KanbanApresentação Scrum, Xp e Kanban
Apresentação Scrum, Xp e KanbanManoela Oliveira
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalhoRuan Pozzebon
 
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumFerramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumThiago Barros, PSM
 
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...Keila Freitas
 
Modelo de Dicionário da eap
Modelo de Dicionário da eapModelo de Dicionário da eap
Modelo de Dicionário da eapFernando Palma
 
Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Claudia Melo
 
Métodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de SoftwareMétodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de Softwarealexandre_malaquias
 
Projeto e Desenvolvimento de Software
Projeto e Desenvolvimento de SoftwareProjeto e Desenvolvimento de Software
Projeto e Desenvolvimento de SoftwareAragon Vieira
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - ResumoDaniel Brandão
 

Mais procurados (20)

Agile testing
Agile testing Agile testing
Agile testing
 
Plano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents ControlPlano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents Control
 
SCRUM Processo de Desenvolvimento de Software
SCRUM Processo de Desenvolvimento de SoftwareSCRUM Processo de Desenvolvimento de Software
SCRUM Processo de Desenvolvimento de Software
 
Lista de Práticas Ágeis
Lista de Práticas ÁgeisLista de Práticas Ágeis
Lista de Práticas Ágeis
 
Qualidade de software
Qualidade de softwareQualidade de software
Qualidade de software
 
Apresentação Scrum, Xp e Kanban
Apresentação Scrum, Xp e KanbanApresentação Scrum, Xp e Kanban
Apresentação Scrum, Xp e Kanban
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalho
 
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumFerramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
 
Scrum
ScrumScrum
Scrum
 
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
Estudo de ferramentas em Software Livre para gestão ágil de projetos de desen...
 
Modelo de Dicionário da eap
Modelo de Dicionário da eapModelo de Dicionário da eap
Modelo de Dicionário da eap
 
Feature Driven Development - FDD
Feature Driven Development - FDDFeature Driven Development - FDD
Feature Driven Development - FDD
 
SCRUM - Priorização do backlog
SCRUM  - Priorização do backlogSCRUM  - Priorização do backlog
SCRUM - Priorização do backlog
 
Outras Metodologias Ágeis Parte 3
Outras Metodologias Ágeis Parte 3Outras Metodologias Ágeis Parte 3
Outras Metodologias Ágeis Parte 3
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
 
Métodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de SoftwareMétodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de Software
 
Projeto e Desenvolvimento de Software
Projeto e Desenvolvimento de SoftwareProjeto e Desenvolvimento de Software
Projeto e Desenvolvimento de Software
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
 

Destaque

04 - C# laços de repetição, vetores e matrizes v1.0
04 - C# laços de repetição, vetores e matrizes v1.004 - C# laços de repetição, vetores e matrizes v1.0
04 - C# laços de repetição, vetores e matrizes v1.0César Augusto Pessôa
 
03 - Orientação a objetos e classes em C# v1.0
03 - Orientação a objetos e classes em C# v1.003 - Orientação a objetos e classes em C# v1.0
03 - Orientação a objetos e classes em C# v1.0César Augusto Pessôa
 
Keynote Visual Studio Summit 2016
Keynote Visual Studio Summit 2016Keynote Visual Studio Summit 2016
Keynote Visual Studio Summit 2016Ramon Durães
 
TechLab de dotnet core no dotnetConf.local
TechLab de dotnet core no dotnetConf.localTechLab de dotnet core no dotnetConf.local
TechLab de dotnet core no dotnetConf.localRodrigo Kono
 

Destaque (9)

05 - C# - componentes visuais v1.0
05 - C# - componentes visuais v1.005 - C# - componentes visuais v1.0
05 - C# - componentes visuais v1.0
 
ASP.NET vNext – MVC6
ASP.NET vNext – MVC6ASP.NET vNext – MVC6
ASP.NET vNext – MVC6
 
Abra seu código!
Abra seu código!Abra seu código!
Abra seu código!
 
04 - C# laços de repetição, vetores e matrizes v1.0
04 - C# laços de repetição, vetores e matrizes v1.004 - C# laços de repetição, vetores e matrizes v1.0
04 - C# laços de repetição, vetores e matrizes v1.0
 
03 - Orientação a objetos e classes em C# v1.0
03 - Orientação a objetos e classes em C# v1.003 - Orientação a objetos e classes em C# v1.0
03 - Orientação a objetos e classes em C# v1.0
 
3- POO
3- POO3- POO
3- POO
 
Keynote Visual Studio Summit 2016
Keynote Visual Studio Summit 2016Keynote Visual Studio Summit 2016
Keynote Visual Studio Summit 2016
 
TechLab de dotnet core no dotnetConf.local
TechLab de dotnet core no dotnetConf.localTechLab de dotnet core no dotnetConf.local
TechLab de dotnet core no dotnetConf.local
 
ASP.NET MVC Core
ASP.NET MVC CoreASP.NET MVC Core
ASP.NET MVC Core
 

Semelhante a Metodologias Dev SW Integradas

Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosWilliam Lima
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMLucas Vinícius
 
Scrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilScrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilIsrael Santiago
 
Fdd em uma casca de banana
Fdd em uma casca de bananaFdd em uma casca de banana
Fdd em uma casca de bananaejedelmal
 
Aula05 - Metodologias Ágeis
Aula05 - Metodologias ÁgeisAula05 - Metodologias Ágeis
Aula05 - Metodologias ÁgeisDaniela Brauner
 
Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To ScrumJuan Bernabó
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPaulo Furtado
 
Visao geraldorup 20slides
Visao geraldorup 20slidesVisao geraldorup 20slides
Visao geraldorup 20slideshoraciosila
 
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010Facuuldade Norte Sul
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareRoberto Brandini
 
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL GPROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL Gjrnavarro
 
Aula 3 desenvolvimento de projetos
Aula 3 desenvolvimento de projetosAula 3 desenvolvimento de projetos
Aula 3 desenvolvimento de projetosThiago Cetroni
 

Semelhante a Metodologias Dev SW Integradas (20)

Método Ágil Scrum
Método Ágil ScrumMétodo Ágil Scrum
Método Ágil Scrum
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUM
 
Metodologias Ageis
Metodologias AgeisMetodologias Ageis
Metodologias Ageis
 
Scrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilScrum - Desenvolvimento Ágil
Scrum - Desenvolvimento Ágil
 
Fdd em uma casca de banana
Fdd em uma casca de bananaFdd em uma casca de banana
Fdd em uma casca de banana
 
Aula05 - Metodologias Ágeis
Aula05 - Metodologias ÁgeisAula05 - Metodologias Ágeis
Aula05 - Metodologias Ágeis
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To Scrum
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em Juazeiro
 
Visao geraldorup 20slides
Visao geraldorup 20slidesVisao geraldorup 20slides
Visao geraldorup 20slides
 
Artigo23
Artigo23Artigo23
Artigo23
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
 
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
 
Scrum agil
Scrum agilScrum agil
Scrum agil
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de software
 
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL GPROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
 
Aula 3 desenvolvimento de projetos
Aula 3 desenvolvimento de projetosAula 3 desenvolvimento de projetos
Aula 3 desenvolvimento de projetos
 
Artigo
ArtigoArtigo
Artigo
 

Metodologias Dev SW Integradas

  • 1. Metodologias de Desenvolvimento de Software Integradas Frank Coelho Especialista em desenvolvimento de software. Solução organizacional para otimização de processos de desenvolvimento de software, visando o desenvolvimento com qualidade com foco na entrega.
  • 2.
  • 3. Tecnologias • Linux • Apache • MySQL • PHP • C# • VB.NET • SharePoint • Project Server • Exchange Server • Windows Server • JBossApp Server • Oracle Weblogic • Hibernate • Spring Framework • Struts Framework • Oracle • PostgreSQL • IBM DB2 • MySQL Java DatabaseMicrosoft . NET LAMP
  • 4. Tópicos abordados * Problemas comuns em projetos de desenvolvimento de software. * O que é uma metodologia? * Metodologias para desenvolvimento de software.
  • 5. Problemas comuns em projetos de desenvolvimento de software.
  • 7. Estatísticas Motivos • Consomem mais recursos que o orçado; • Consomem mais tempo que o estimado; • Não entregam o que foi combinado; (+) 500 mil projetos (pequeno - grande porte) de software nos Brasil.
  • 8. Para resolver esses problemas, seguimos uma metodologia.
  • 9. O que é uma Metodologia? Padrões Comunicação Objetivo comum Aproveitamento recursos Metodologia Equipe
  • 10. Metodologias para Desenvolvimento de Software • Metodologia tradicional: PDI-SW (Processo de Desenvolvimento Iterativo de Software) • Metodologia ágil: SCRUM
  • 11. SCRUM • Metodologia de desenvolvimento ágil nascida em empresas de fabricação de carros em 1986 (Takeuchi e Nonaka). • Jeff Sutherland, John Scumniotales, e Jeff McKenna – documentaram e implementaram - Easel Corporation em 1993. • Tipo de formação do Rugby. • Passou a ser utilizado no mundo a partir de 1995. • Aborda uma filosofia de gerenciamento com foco no resultado.
  • 12.
  • 13. Sprint •Cada sprint é uma iteração que segue um ciclo e entrega incremento de software pronto. •Um backlog é conjunto de requisitos, priorizado pelo Product Owner (responsável pelo ROI “retorno sobre investimento” e por conhecer as necessidades do cliente); •Há entrega de conjunto fixo de itens do backlog em série de interações curtas ou sprints; •Breve reunião diária, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting ou Daily Meeting, já que os membros da equipe geralmente ficam em pé para não prolongar a reunião). •Breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos; •Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.
  • 14. BACKLOG Planejamento de sprint (Sprint Planning): Antes de todo sprint, o Product Owner, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Product Owner mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog do sprint. Product Backlog Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O Product Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão deste. Sprint Backlog O Sprint Backlog é uma lista de itens selecionados do Product backlog e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar tais itens selecionados. O Sprint Backlog é uma representação em tempo real do trabalho que o Development Team planeja concluir na sprint corrente, e ele pertence unicamente ao Development Team. Burndown Chart O Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que não ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no Sprint e o eixo Y os dias que representam o tamanho do Sprint.
  • 15. Os papéis principais em equipes Scrum são aqueles comprometidos com o projeto no processo do Scrum - são os que produzem o produto (objetivo do projeto). Product Owner (dono do produto) O Product Owner representa a voz do cliente e é responsável por garantir que a equipe agregue valor ao negócio. O Product Owner escreve centrado nos itens do cliente (histórias tipicamente do usuário), os prioriza e os adiciona para o product backlog. Equipes de Scrum devem ter um Product Owner, e, embora esse possa também ser um membro da equipe de desenvolvimento, recomenda-se que este papel não seja combinado com o de ScrumMaster. Equipe (Development Team) A equipe é responsável pela entrega do produto. A equipe é tipicamente composta de 5-9 pessoas com habilidades multifuncionais que fazem o trabalho real (analisar, projetar, desenvolver, testar técnicas de comunicação, documentos, etc.) Recomenda-se que a equipe seja auto-organizada e auto-conduzida, mas que muitas vezes trabalhem com alguma forma de projeto ou gestão de equipe. Scrum Master Scrum é facilitado por um Scrum Master, que é responsável pela remoção de impedimentos à capacidade da equipe para entregar o objetivo do sprint / entregas. O Scrum Master não é o líder da equipe, mas age como um tampão entre a equipe e qualquer influência ou distração. O Scrum Master garante que o processo Scrum seja usado como pretendido. O Scrum Master é o responsável pela aplicação das regras. Uma parte fundamental do papel do Scrum Master é proteger a equipe e mantê-la focada nas tarefas em mãos. O papel também tem sido referido como um líder-servo para reforçar essa dupla perspectiva. Papéis principais
  • 16. Obrigado! Proposta. • Usar os pilares fundamentais do RUP e seus conceitos e métodos, unificado com as melhores praticas do CMMI. Definição de processo organizacional sobre a gestão do SCRUM. • Utilizar aspectos básicos definindo um mínimo de documentação inicial tanto quanto necessário. • Foco na entrega com garantia de qualidade. • Reuso de artefatos e funcionalidades (Frameworks) • Formar muito mais que um time, um grupo de pessoas com os mesmos objetivos e que acreditem no negocio.
  • 18. Gráfico de esforço nas fases
  • 19. Concepção Esta fase do RUP abrange as tarefas de comunicação com o cliente e planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos do sistema e preliminarmente analisá-lo. Assim, haverá uma anuência das partes interessadas na definição do escopo do projeto, onde são examinados os objetivos para se decidir sobre a continuidade do desenvolvimento. Elaboração Abrange a Modelagem do modelo genérico do processo. O objetivo desta fase é analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Indagações como “O plano do projeto é confiável?”, “Os custos são admissíveis?” são esclarecidas nesta etapa. Fase de Construção: Desenvolve ou Adquire os componentes de Software. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema. É na fase de Construção que a maior parte de codificação ocorre.
  • 20. Fase de Transição: Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e também a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.
  • 21. Fase de Concepção • Finalidade – Definir objetivos e viabilidade do projeto (o ideia do projeto) e o escopo de vários aspectos • Atividades – Definir: critérios de sucesso de projeto, riscos, recursos necessários e data de realização das principais etapas – Delimitar o escopo do projeto – Identificar os atores que interagem com o sistema – Identificar as interações dos atores com o sistema (casos de uso) • Resultados (artefatos) – Documento de visão: visão geral dos requisitos, características e restrições essenciais do projeto. – Modelo inicial de casos de uso (10%-20%). – Glossário do projeto (opcionalmente um modelo de domínio). – Definição de objetivos e viabilidade do projeto incluído contexto, critérios de sucesso e prognóstico financeiro. – Avaliação inicial de riscos. – Plano de projeto, com fases e interações. – Modelo de negócios, se necessário. – Um ou vários protótipos. • Critérios de Satisfação – Concordância quanto à definição de escopo e estimativas de custo e cronograma. – Compreensão dos requisitos funcionais. – Credibilidade das estimativas de custo, cronograma, prioridades, riscos, e processo de desenvolvimento. – Profundidade e amplitude dos protótipos desenvolvidos. – Custos planejados versus realizados.
  • 22. Fase de Elaboração • Finalidade – eliminar os elementos de maior risco do projeto através da criação de uma arquitetura coerente e consistente da solução • Atividades – Construir protótipos executáveis, em uma ou mais interações – Atacar os casos de uso críticos, que expõe os maiores riscos técnicos – Construir protótipos evolucionários ou descartáveis, com objetivo de analisar custos-benefícios, demonstrar para investidores, clientes e usuários • Resultados (artefatos) – Modelo de casos de uso (80% ou mais). – Requisitos não funcionais – Descrição da arquitetura do software – Protótipos arquiteturais executáveis – Revisão da visão de negócios e lista de riscos – Plano detalhado de desenvolvimento do projeto, com interações e critérios de avaliação – Plano de processo de desenvolvimento – Manual de usuário preliminar • Critérios de Satisfação (para suporte à decisão sobre continuar ou não com o projeto) – A visão do produto é estável? – A arquitetura é estável? – A demonstração executável mostrou que os elementos de maior risco foram abordados satisfatoriamente? – O plano de desenvolvimento está suficientemente detalhado e preciso? O plano é consistente e coerente? – Todos os interessados concordam quando à coerência entre visão, plano e arquitetura? – Os custos planejados e executados estão aceitáveis?
  • 23. Fase de Construção • Finalidade – Desenvolver todos os componentes e características não resolvidas nas fases anteriores, testando-as e integrando-as na forma de um produto. • Atividades – Diversas • Resultados (artefatos) – O produto, descrito e integrado nas plataformas adequadas • Critérios de Satisfação – A release do produto é suficientemente estável e amadurecida para ser entregue ao usuário? – Todos os envolvidos e interessados estão preparados para a fase de transição? – O consumo de recursos é ainda aceitável?
  • 24. Fase de Transição • Finalidade – Realizar a transição do produto para a comunidade de usuários • Atividades – “beta teste” – Operações paralelas com sistema legado – Conversão de bases de dados – Treinamento de usuários a mantenedores – Roll-out para setores de marketing, distribuição e vendas • Resultados (artefatos) – Em conformidade com atividades • Critérios de Satisfação – O usuário ainda está satisfeito? – Os custos de manutenção ainda são aceitáveis?
  • 25. Ferramentas de gerenciamento do ciclo de vida e produção • Visual Studio • Arquitetura • Dados • Testes • TFS • Versionamento • Tarefas • Sprints • Backlogs • Project • Cronograma • Tarefas • Custos • Studio manager SQL • Modelo de dados
  • 26. Perfil do time técnico • Gerente de Projetos • Arquiteto de Software • Analista de requisitos • Analista de sistema • Desenvolvedores • Analista de Testes • Documentador
  • 29. CMMI • CMMI é uma família de conjuntos de melhores práticas para apoiar a melhoria de desenvolvimento, serviços e aquisição. • Implementar um modelo baseado nas melhores praticas, levando em conta o cenário especifico e atual da empresa, voltado para melhoria continua e crescimento do grau de maturidade do ciclo de vida da construção de software. • Processo continuo visando o alcance dos resultados esperados. • Trabalhar nos detalhes no intuito de evitar esforço desnecessário. • União das dimensões de construção do CMMI: • Pessoas • Ferramentas • Procedimentos
  • 30.
  • 31. O que esperar. • Não existe retorno a curto prazo. • Certificação CMMI • Certificação ISO • Controle absoluto de projetos e custos • Baixo Custo de manutenção • Produtos robustos e escaláveis • Melhoria estratégica de posição no mercado • Gerencia de configuração consolidada • Lucros maiores • Ser um caso de sucesso • Atingir a EXCELENCIA Fazer a coisa certa é uma escolha que deve ser mantida, que exige esforço e comprometimento e o retorno só é visto depois. Obstáculos são apenas grandes oportunidades de sermos melhores... Homens comuns contam histórias, homens extraordinários fazem a história...
  • 32. Referências • http://www.infoq.com/presentations/The-Roots-of-Scrum • http://pt.wikipedia.org/wiki/Scrum • http://www.agilealliance.org/system/article/file/888/file.pdf • http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Fase _de_Concep.C3.A7.C3.A3o • http://www.cmmi.de/#el=CMMI-DEV/0/HEAD/folder/folder.CMMI- DEV