INTEGRANDO GERÊNCIA DE PROJETOS ÁGEIS COM SCRUM E OS PROCESSOS MPS.BR NÍVEL G
|
|
- Elias Penha Deluca
- 8 Há anos
- Visualizações:
Transcrição
1 INTEGRANDO GERÊNCIA DE PROJETOS ÁGEIS COM SCRUM E OS PROCESSOS MPS.BR NÍVEL G Claudinei Martins da Silva 1 RESUMO: Com o aumento da dependência tecnológica nas organizações para a tomada de decisões, ocorreu uma demanda por sistemas mais complexos e, consequentemente, aumentaram os riscos de falhas nas entregas, dificultando a liberação de produtos com a qualidade desejada. Tais fatores prejudicam a imagem da organização, aumentam os custos e ampliam o insucesso de projetos existentes. A partir de uma pesquisa bibliográfica, este trabalho descreve como integrar o gerenciamento de projetos com o método ágil SCRUM e o modelo de qualidade do processo MPS.BR voltado para a realidade do mercado de pequenas e médias empresas de software no Brasil. Palavras-chave: MPS.BR, Scrum, Desenvolvimento ágil. 1 INTRODUÇÃO As organizações estão aumentando cada vez mais sua dependência tecnológica, representando um número maior de sistemas informatizados para atender suas operações internas como reflexo de uma tendência natural. Para sobreviver em um ambiente competitivo, as empresas estão buscando tecnologias para reduzir custos e ampliar a sua atuação. A demanda por sistemas cada vez mais complexos com a capacidade de tomada de decisão é primordial para ganhar eficiência e controle. Nesse cenário, todos os processos envolvidos no desenvolvimento de sistemas têm um nível crescente de complexidade, aumentando o risco de mau funcionamento e dificultando a produção com a qualidade desejada. 1 Analista de Sistemas Softplan. Bacharel em Sistemas de Informação. Especialização em Gerência de Projetos de Tecnologia da Informação.
2 Produzir sistemas com falhas prejudica a imagem da organização, aumenta os custos de desenvolvimento e amplia o insucesso de projetos existentes. Para acompanhar essa complexidade, as empresas estão buscando um método de avaliação de maturidade para trazer disciplina e controle no desenvolvimento de sistema, do qual as organizações partem de um modelo evolutivo de qualidade, com início na total falta de controle para gradativamente adquirir maturidade. (BARTIÉ, 2002). A evolução dos processos é definida pelo nível de maturidade do modelo MPS.BR, caracterizado por sete níveis: A (Em otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente definido), E (Parcialmente definido), F (Gerenciado) e G (Parcialmente Gerenciado). Iniciando pelo nível G, seguindo progressivamente até o nível A. (SOFTEX, 2011). A entrega dentro do prazo é outro ponto crítico no desenvolvimento de sistemas. Existem vários métodos, entre eles os chamados ágeis, que possuem esse nome por serem mais adaptativos e flexíveis em relação aos tradicionais, e os resultados devem ser entregues em pequenos intervalos de tempo, realizando entregas ao final de cada ciclo (sprints). (CARVALHO, 2009). Para atender rapidamente à necessidade do mercado, as indústrias de sistemas estão desesperadas em busca do aperfeiçoamento de seus processos internos. Isso evidência que a maioria das empresas que fornecem sistemas a uma organização são amadora, ou seja, desconhecem de um processo de engenharia de software. A principal conseqüência desse cenário é a não existência de nenhuma garantia na entrega da solução tecnológica dentro do prazo e custo negociados. (BARTIÉ, 2002). A união de uma metodologia ágil com os processos de maturidade é um desafio ainda maior a ser vencido para que as organizações alcancem o estado de excelência no desenvolvimento de sistemas, a fim de atender à expectativa de sistemas complexos. O objetivo desse trabalho é apresentar a metodologia Scrum e os processos de maturidade MPS.BR nível G por meio de uma pesquisa bibliográfica e propor a integração entre essas tecnologias. Para tal, apresenta-se no segundo e terceiro capítulo um estudo da metodologia Scrum e o processo MPS.BR. No quarto capítulo será detalhado os processos MPS.BR nível G, os resultados esperados e a sua integração com Scrum.
3 2 SCRUM Scrum é uma metodologia ágil. Seu nome teve origem no jogo de Rugby, o qual tem uma reunião rápida antes de iniciar um lance. Nesse método, cada membro possui um papel específico e todos colaboram para alcançar um objetivo comum. Ele baseia-se em seis características (CARVALHO, 2009): Flexibilidade de resultados; Flexibilidade de prazos; Times pequenos; Revisões frequentes; Colaboração; Orientação a objetos. Product Backlog é uma lista de funcionalidades a serem desenvolvidas que devem estar ordenadas por prioridade. Essas funcionalidades são determinadas por meio da coleta de requisitos. (CARVALHO, 2009). Para Kniberg (2007), Backlog é onde começa tudo, é o coração do scrum. Uma lista de coisas que o cliente deseja, chamadas de estórias. Daily Meeting é uma reunião diária que ocorre entre os membros do time, geralmente realizada em pé para maior agilidade. Três perguntas devem ser respondidas por cada membro: O que foi feito ontem? O que será feito hoje? Há algum obstáculo à realização de suas atividades? O objetivo das respostas é a formalização do comprometimento com os demais membros da equipe. Assim, são disseminadas as metas individuais de cada integrante, que conhecem seus impedimentos e podem cobrar compromissos assumidos. (CARVALHO, 2009). Product Owner define os requisitos iniciais e gerais, retorno de investimento, objetivos e planos de entregas. Garante que as funcionalidades de maior valor sejam priorizadas a cada sprint. O Team desenvolve as funcionalidades do produto, transforma o product backlog em valor ao produto, gerencia seu próprio trabalho, e também é responsável pelo sucesso da sprint e do projeto como um todo. (MARÇAL, 2009). Sprint Planning é uma reunião em que estão presentes o Product Owner, o Scrum Master e todo o Scrum Team. O Product Owner descreve as atividades de maior prioridade
4 para a equipe. A equipe faz perguntas durante a reunião com o objetivo de quebrar as atividades em tarefas que irão dar origem ao Sprint Backlog. (VINÍCIUS, 2012). Sprint é o período de tempo em que são implementados um conjunto de itens definidos no Backlog do Produto. Normalmente dura de uma a quatro semanas, dependendo da decisão da equipe. Para o desenvolvimento de software, uma Sprint possui as fases: requisitos, análise, projeto e entrega. Sprint Review é a reunião que acontece após cada Sprint para ser discutido os erros, acertos e lições aprendidas. (CARVALHO, 2009). Sprint Backlog é construída durante a reunião de planejamento da Sprint, constituída por um subconjunto do Backlog do Produto. (CARVALHO, 2009). Segundo KNIBERG (2007), é uma reunião crítica, é o evento mais importante do scrum. Para Carvalho (2009), o Scrum master é a pessoa responsável por fazer o processo do Scrum acontecer. Ele remove os obstáculos apontados na reunião diária (Dayli scrum) para que os membros da equipe realizem o seu trabalho. Segundo Marçal (2009), o Scrum master também deve ensinar o Scrum a todos os envolvidos no projeto e adequar a cultura da organização. Story points é uma medida que qualifica o tamanho da atividade (ECLIPSE, 2012). O gráfico de BurnDown é uma representação do trabalho restante em comparação com o trabalho já realizado, ele é muito útil para mostrar o fim dos trabalhos e para alertar sobre o atraso antes do prazo final. (CARVALHO, 2009). Sprint retrospective é uma reunião com o objetivo de melhorar o processo e o produto para a próxima Sprint.(CARVALHO, 2009). Segundo Victor (2012), Impediments Backlog é qualquer coisa que impede a realização de uma tarefa de um membro da equipe. Cada membro da equipe pode anunciar impedimento durante a reunião diária. 3 MPS.BR O objetivo do processo MPS.BR é a Melhoria de Processo de Software Brasileiro. Suas metas são (SOFTEX, 2011): a) Meta técnica: aprimoramento do modelo MPS.BR por meio de seus guias e instituições. b) Meta de mercado: disseminação e adoção do modelo em todas as regiões do país. O modelo MPS.BR está divido em 4 guias (SOFTEX (Org.)) :
5 1) Guia Geral: contém a descrição geral do modelo MPS.BR e detalha o modelo de referência MR-MPS. 2) Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. destina-se à instituições que queiram adquirir produtos de software e serviços relacionados. 3) Guia de Avaliação: descreve o processo e o método de avaliação MA.MPS. 4) Guia de implementação: contém orientações para a implementação do modelo de referência MR-MPS. É uma série de onze documentos que fornecem orientações para implementar nas organizações os níveis de maturidade. A base desse modelo são os requisitos de processos definidos nos modelos de melhoria de processo, buscando atender à necessidade de implantar os princípios da engenharia de software ao contexto das empresas brasileiras, em consonância com padrões internacionais. (SOFTEX, 2011). O modelo MPS estabelece um modelo e um método de avaliação de processos, e essa estrutura tem por objetivo garantir que ele esteja sendo empregado de forma coerente com as suas definições. O modelo está divido em níveis de maturidade de G até A, que é uma combinação entre processos e sua capacidade. O nível de maturidade em que se encontra a organização permite prever o seu desempenho futuro ao executar um ou mais processos. Quanto ao nível de maturidade, está dividido em sete níveis (SOFTEX, 2011): A Em otimização; B Gerenciado quantitativamente; C Definido; D Largamente definido; E Parcialmente definido; F Gerenciado; G Parcialmente Gerenciado. Os processos são descritos em termos de propósitos e resultados. O propósito descreve o objetivo a ser atingido e o resultado é o que se espera com a afetiva implementação do processo. A capacidade do processo é representada por um conjunto de atributos de processo descritos como resultado esperado. Ela expressa ao grau de refinamento com que o processo é executado na organização. À medida que a organização evolui os níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido.
6 Os diferentes níveis de capacidade são atribuídos por nove atributos de processo (AP). O seu resultado é avaliado por meio de seus respectivos resultados (RAP), conforme definido a seguir para o nível de maturidade G. AP 1.1 O processo é executado Este atributo evidencia o quanto o processo atinge o seu propósito. Resultado esperado: RAP 1. O processo atinge seus resultados definidos. AP 2.1 O processo é gerenciado Este atributo evidencia o quanto a execução do processo é gerenciada. Resultados esperados: RAP 2. Existe uma política organizacional estabelecida e mantida para o processo. RAP 3. A execução do processo é planejada. RAP 4. A execução do processo é monitorada e ajustes são realizadas. RAP 5. As informações e os recursos necessários para a execução do processo são identificadas e disponibilizadas. RAP 6. As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas. RAP 7. As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência. RAP 8. A comunicação entre as partes interessadas no processo é planejada e executada de forma a garantir o seu envolvimento. RAP 9. Os resultados dos processos são previstos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização. RAP 10. O processo para o projeto é executado. O modelo MPS.BR prevê a exclusão de alguns processos do escopo da avaliação, por não serem pertinentes ao negócio da unidade organizacional, que pode ser total ou parcial. Essa exclusão deve ser justificada no Plano de Avaliação. A aceitação e justificativas são de responsabilidade do avaliador líder. (SOFTEX, 2011).
7 4 MPS.BR- PARCIALMENTE GERENCIADO E SUA INTEGRAÇÃO COM SCRUM Neste capítulo serão detalhados os processos Gerência de projetos e Gerência de requisitos, no qual será apresentada uma proposta de integração com o Scrum. A implementação do nível de maturidade parcialmente gerenciado deve ser executada com cautela por estabelecer o início dos trabalhos. Ao final da implementação deste nível, a organização deve ser capaz de gerenciar parcialmente seus projetos de software. A mudança de cultura organizacional e a definição do conceito acerca do que é projeto são os dois pontos desafiadores para a implementação no nível G. O nível de maturidade G é composto pelos processos Gerência de Projetos e Gerência de Requisitos. A implementação desses processos devem satisfazer os atributos de processo AP1.1 e AP2.1. (SOFTEX, 2011). Neste capítulo, serão apresentados os processos do nível G e sua integração com o Scrum. 4.1 PROCESSO: GERÊNCIA DE PROJETOS GPR Seu propósito é estabelecer e manter planos que definam as atividades, recursos e responsabilidades do projeto e prover informações sobre o andamento do projeto que permitam correções quando houver desvios significativos. (SOFTEX, 2011). GPR 1: o escopo do trabalho para o projeto é definido - Reúne todo o trabalho necessário e estabelece o que está e o que não está no projeto. Ele contém a definição do objetivo e a motivação, os limites e as restrições e todos os produtos que serão entregues. (SOFTEX, 2011). Scrum - Documento de visão e o Product Backlog. GPR 2: as tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados - O escopo do projeto é decomposto em partes menores que deve fornecer uma referência para a atribuição de tamanho, esforço, cronograma e responsabilidades, e são utilizadas como uma estrutura subjacente para planejar, organizar e controlar o trabalho executado. O resultado esperado é a estimativa de tamanho. (SOFTEX, 2011). Scrum Story points. Atribuir um tamanho para cada estória.
8 GPR 3: o modelo e as fases do ciclo de vida do projeto são definidas Consiste de fases e atividades que são definidas de acordo com o escopo dos requisitos. Essas fases geram produtos de trabalho necessários para o desenvolvimento das fases posteriores, no qual permite planejar o projeto, incluindo marcos importantes para o controle de revisões. As fases podem ser chamadas de modelo de ciclo de vida. (SOFTEX, 2011). Scrum Sprint planning, Daily Meeting, Sprint review e Sprint retrospective. O Scrum possui quatro fases de ciclo de vida. GPR 4: o esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas Custo e esforço são baseados em dados históricos aplicados ao tamanho. Para estimar o esforço e o custo, tipicamente são considerados o escopo, produtos de trabalho e as tarefas estimadas para o projeto; os riscos, as mudanças já previstas, o ciclo de vidas escolhido para o projeto, viagens previstas, nível de competência da equipe do projeto, dentre outros. Empresa implementando o nível G, geralmente precisam construir essa base de dados histórica. (SOFTEX, 2011). Scrum - Não possui dados históricos de custo e esforço. GPR 5: o orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos Dependências entre tarefas e potencias gargalos são identificados utilizando métodos específicos, por exemplo, análise de caminho crítico. É estabelecido o cronograma das atividades com início, duração e término. O orçamento do projeto é definido com base no cronograma e na estimativa de custos. Esse resultado é importante, pois o cronograma e o orçamento são fundamentais para o acompanhamento do projeto. (SOFTEX, 2011). Scrum - Sprint planning e Sprint review para estimativa de horas. O orçamento não é contemplado pelo Scrum. GPR 6: os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinadas e documentadas Identificar, analisar e priorizar os riscos do projeto. É interessante elaborar uma lista de riscos mais comuns para identificar quais são potencias para o projeto. Para definir a prioridades dos riscos, é necessária uma análise de probabilidade de ocorrência e gravidade. Esse resultado
9 não significa gerenciamento de riscos, mas um acompanhamento para avaliar como afeta o projeto. (SOFTEX, 2011). Scrum - Daily Meeting, Impediments Backlog. Os impedimentos são levantados durante as reuniões diárias e armazenados no Backlog de impedimentos. GPR 7: os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessário para executá-los Determinam funções, responsabilidades e relações hierárquicas do projeto. As funções podem ser direcionadas para membros internos e externos à organização. Incluir informações de quando e como o recurso será envolvido no projeto, critérios para sua elaboração, mapa de competências da equipe e identificação de treinamento, se necessário. (SOFTEX, 2011). Scrum - Product backlog. A equipe deve ter competência e conhecimento para incluir itens no Product Backlog. Se algum treinamento for necessário, deve ser incluído no próprio Product Backlog. GPR 8: os recursos e o ambiente de trabalho necessários para executar o projeto são planejados - Necessário planejar explicitamente todos os recursos, como ferramentas, serviços, componentes ou despesas, mesmo os considerados como existentes e disponíveis, devido a sua alocação para uso. Se não houver nenhum recurso com necessidade de aquisição para o projeto, deve-se registrar que a questão foi examinada. (SOFTEX, 2011). Scrum - Scrum master e Product owner. São responsáveis em garantir os recursos necessários para o projeto. GPR 9: os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança - A documentação do projeto pode estar representada por diversas formas, por exemplo: relatórios, dados informais, estudos e análises; lições aprendidas, itens de ação e indicadores. Esses artefatos podem estar em qualquer formato, como: impressos, fotografia, meio eletrônico e multimídia. A identificação, coleta, armazenamento e distribuição devem ser planejados para garantir segurança e integridade. É necessário explicitar a existência ou não de dados confidencias. (SOFTEX, 2011). Scrum - Não possui um gerenciamento de dados.
10 GPR 10: um plano geral para a execução do projeto é estabelecida com a integração de planos específicos Garantir que todos os planos que afetam o projeto estejam integrados e que a dependência entre eles tenha sido identificada e considerada durante o planejamento, conciliando o trabalho existente aos recursos existentes. A reunião dos documentos de cronograma, planejamento de recursos humanos, custos, riscos, dados e outros é entendida como sendo o Plano de Projeto. (SOFTEX, 2011). Scrum - Documento de visão e Product backlog representam o Plano do Projeto. GPR 11: a viabilidade de atingir as metas do projeto é explicitamente avaliada considerando restrições e recursos disponíveis. Se necessário, ajustes são realizados Considera o escopo do projeto e examina aspectos técnicos (requisitos e recursos), financeiros (capacidade da organização) e humanos (disponibilidade e capacitação). Uma avaliação preliminar pode ser executada a partir da visão geral dos objetivos e resultados esperados. À medida que o projeto evolui, a viabilidade de sucesso pode ser avaliada com mais precisão. (SOFTEX, 2011). Scrum - Durante a definição do Product backlog, o Scrum master e o Product owner são responsáveis por avaliar a viabilidade do projeto. Durante a evolução do projeto, a Daily Meeting pode identificar restrições. GPR 12: o plano de projeto é revisado com todos os interessados e o compromisso com ele é obtido e mantido É importante revisar o planejamento com os interessados e conciliar as diferenças existentes entre os recursos estimados e os disponíveis. Quando houver conflitos como requisitos, custos e prazos, negociações devem ser realizadas. Os comprometidos deverão ter a confiança de que o trabalho pode ser executado dentro das restrições de custos, desempenho e cronograma. Durante o projeto, novos interessados podem ser identificados e compromissos anteriormente podem ser modificados, por isso, é necessário verificar se os compromissos assumidos estão sendo cumpridos. (SOFTEX, 2011). Scrum - Sprint Planning, Daily meeting e Sprint review são os eventos onde a equipe (team), Scrum master e Product owner revisam os planos. GPR 13: o escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados em relação ao planejado - Avaliar constantemente a aderência entre os planos. Os resultados e os critérios de conclusão de cada tarefa são analisados e as entregas são avaliadas em relação às suas características; a aderência ao cronograma e o dispêndio de
11 esforços são avaliados e o uso dos recursos. Acompanhar o que foi planejado, detectar problemas e corrigi-los é essencial para o gerenciamento. (SOFTEX, 2011). Scrum - Nas reuniões diárias, é possível detectar problemas e desvio de cronograma por meio do gráfico de Burndown. GPR 14: os recursos materiais e humanos, bem como os dados relevantes do projeto, são monitorados em relação ao planejado Monitorar os itens planejados referentes a recursos materiais e recursos humanos. O monitoramento consiste em uma análise do que foi planejado em relação aos valores atuais e, caso seja necessário, planos de ação devem ser executados para evitar a criação de outros problemas futuros. (SOFTEX, 2011). Scrum - O Scrum master poderá identificar a necessidade de recursos materiais e humanos para o projeto. GPR 15: os riscos são monitorados em relação ao planejado Novos riscos podem ser identificados e os parâmetros dos riscos já identificados podem ser alterados. Poderá ser necessário executar ações para diminuir a probabilidade de que um risco ocorra ou, caso já tenha ocorrido, executar uma ação de contingência. A lista de riscos deve ser avaliada periodicamente em conjunto com seus parâmetros e prioridades. (SOFTEX, 2011). Scrum - As reuniões diárias e de Sprint poderão identificar futuros riscos; ou riscos que se concretizaram. Para isso é necessário realizar uma ação para minimizar seus efeitos. GPR 16: o envolvimento das partes interessadas no projeto é planejado, monitorado e mantido Identificar os interessados no projeto, em que fase eles são importantes e como eles serão envolvidos. Depois de identificado e planejado o envolvimento, deverá ser seguido, monitorado e mantido. Deverá haver uma comunicação com os envolvidos, como: questões relativas a prazos, custos, recursos, comprometimentos e também requisitos. (SOFTEX, 2011). Scrum - A essência do Scrum é o envolvimento e comprometimento das partes com o projeto. As reuniões diárias para acompanhamento do que foi planejado é uma forte evidência desse envolvimento. GPR 17: revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento Revisões em marcos do projeto são diferentes do acompanhamento que ocorre dia a dia. Os marcos precisam ser previamente definidos no planejamento do projeto.
12 Os marcos são fundamentais para avaliar de forma ampla o andamento do projeto. (SOFTEX, 2011). Scrum - A Sprint review é o momento ideal para avaliar em linhas gerais o andamento do projeto. GPR 18: registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessantes O acontecimento de problemas e desvios em relação ao planejamento devem ser analisados e registrados. A falha na execução dessa tarefa pode afetar a execução de ações para correção nos desvios e, consequentemente, no andamento do projeto. Os problemas precisam ser corrigidos e gerenciados até a sua solução. (SOFTEX, 2011). Scrum - Os problemas identificados são relacionados no backlog de impedimentos e o Scrum master é responsável pela sua solução. GPR 19: ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão - Com o acompanhamento do projeto, problemas são identificados, analisados e registrados. Ações corretivas devem ser definidas e gerenciadas até serem concluídas. O controle dos problemas levantados, as ações tomadas, os responsáveis pelas ações e os resultados devem ser registrados. (SOFTEX, 2011). Scrum - O Scrum master é o responsável por corrigir os desvios em relação ao planejado, mas no Scrum não há registros das ações e seu acompanhamento até a sua conclusão. 4.2 PROCESSO: GERÊNCIA DE REQUISITOS GRE Seu propósito é gerenciar requisitos do produto e dos componentes do produto, e identificar inconsistência entre os requisitos. O objetivo principal é controlar a evolução dos requisitos. Seu processo gerencia todos os requisitos recebidos ou gerados pelo projeto que são requisitos funcionais, não funcionais e os impostos ao projeto pela organização. Para assegurar que os requisitos são gerenciados, a organização deve executar um conjunto de passos apropriados. Ao receber requisitos de um fornecedor, estes devem ser revisados para resolver questões e promover o bom entendimento, antes da entrada do requisito no escopo do projeto. (SOFTEX, 2011).
13 Dentre outras atribuições da gerencia de requisitos, estão: documentar as mudanças nos requisitos e suas justificativas; manter a rastreabilidade bidiredicional e identificar inconsistências. (SOFTEX, 2011). GRE 1: o entendimento dos requisitos é obtido junto aos fornecedores de requisitos Garantir que os requisitos estejam claramente definidos a partir do entendimento realizado junto aos fornecedores. Os requisitos devem ser documentos para comprovar o entendimento. É importante garantir que a identificação de requisitos atenda às expectativas do cliente. Após avaliação dos requisitos, é necessário registrar o aceite dos fornecedores. (SOFTEX, 2011). Scrum- O Scrum master e o Product Owner são os responsáveis por garantir que os requisitos estejam claramente definidos para posterior entrada no Product backlog. GRE 2: os requisitos são avaliados com base em critérios objetivos e um compromisso da equipe técnica com estes requisitos é obtido Após o requisito ser aprovado pelo cliente, são necessários avaliação e comprometimento com a equipe técnica, esse comprometimento também deve ser registrado na forma de ata, ou algum outro mecanismo. É recomendável que os requisitos sejam submetidos à aprovação técnica antes de ser enviado para aprovação do cliente, evitando assim retrabalho, ou apresentação de um documento sem qualidade técnica. (SOFTEX, 2011). Scrum - O Product owner deve garantir o entendimento e a aprovação por parte do cliente e da equipe técnica. GRE 3: a rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida Estabelecer um mecanismo que permita rastrear a dependência entre os requisitos e os produtos de trabalho. A rastreabilidade facilita a avaliação de impacto das mudanças de requisitos, como: estimativas de escopo nos produtos de trabalho ou nas tarefas do projeto descritas no cronograma. (SOFTEX, 2011). Scrum - Não possui mecanismo de rastreabilidade. GRE 4: revisões em planos e produtos de trabalho do projeto são realizadas visando a identificação de inconsistência em relação aos requisitos Identificar inconsistência entre os requisitos e os demais elementos do projeto. Essas inconsistências devem ser registradas e ações corretivas executadas e acompanhadas até seu término. (SOFTEX, 2011).
14 Scrum - Durante a Sprint review, é realizada avaliação e disparadas ações corretivas, se necessárias. GRE 5: mudanças de requisitos são gerenciadas ao longo do projeto Poderá haver mudança dos requisitos durante o projeto, como: requisitos novos, retirados ou modificados no projeto. Essas mudanças devem ser registradas em um histórico de decisões de requisitos. Scrum - Mudanças de requisitos podem ser detectadas durante o planejamento e revisão da Sprint ou nas reuniões diárias. (SOFTEX, 2011). 5 CONCLUSÃO A adoção de metodologias ágeis vem crescendo cada vez mais, por serem de fácil implementação, porém falta documentação, o que é uma característica dos métodos ágeis. O modelo MPS.BR, possui documentação ampla e contempla todas as etapas do desenvolvimento. Como resultado deste trabalho pode perceber que é possível utilizar uma metodologia ágil com qualidade através de um modelo de maturidade. A integração entre Scrum e MPS.BR foi satisfatória e relativamente fácil de ser alcançada para o nível de maturidade G. O Scrum atendeu quase 100% em sua aderência ao modelo MPS.BR, o que não impede de serem implementados trazendo grandes ganhos no planejamento e qualidade do produto final. O Scrum fornece uma metodologia ágil, adequada para que se tenha ganho na produtividade. Seus principais benefícios são: Flexibilidade de resultados, flexibilidade de prazos, times pequenos, revisões frequentes e colaboração. Por ser de fácil entendimento e sua implantação é rápida. As reuniões diárias promovem o comprometimento da equipe com o projeto. O MPS.BR oferece um modelo e uma forma de avaliação de processos para garantir de forma coerente as suas definições, que estão dividas em níveis de maturidade de G até A, permitindo para a organização prever o seu desempenho futuro com base no nível de maturidade em que se encontra. Os seus processos são descritos em termos de propósitos e resultados. A maior dificuldade em realizar esse trabalho foi entender o modelo MPS.BR por ser um conteúdo extenso e estar dividido em vários documentos chamados de guias.
15 Para trabalhos futuros, sugere-se analisar a integração do Scrum com os demais níveis de maturidade do modelo MPS.BR e integração Scrum com o modelo XP.
16 INTEGRATING PROJECT MANAGEMENT WITH AGILE SCRUM AND MPS.BR PROCESSES LEVEL G ABSTRACT: With increasing dependence on technology in organizations for making decisions, there was a demand for more complex systems and, consequently, increased the risk of failed deliveries, hindering the release of products with the desired quality. These factors affect the organization's image, increase costs and extend the failure of existing projects. From a literature search, this paper describes how to integrate project management with Scrum agile method and process quality model MPS.BR facing the reality of the market for small and medium-sized software companies in Brazil. Keywords: MPS.BR, Scrum, Agile development.
17 REFERÊNCIAS BARTIÉ, Alexandre. Garantia da qualidade de software. Rio de Janeiro: Campus, CARVALHO, Bernardo Vasconcelos de. Aplicação do método ágil Scrum no desenvolvimento de produtos de software em uma pequena empresa de base tecnológica Dissertação (Mestrado em Ciências em Engenharia de Produção) Universidade Federal de Itajubá, ECLIPSE. Concept: Story Points. Disponível em: < ml>. Acesso em: 23 abr KNIBERG, Henrik. Scrum e XP direto das Trincheiras. Estados Unidos: C4Media, MARÇAL, Ana Sofia Cysneiros. SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao CMMI Dissertação (Mestrado em informática aplicada da Universidade de Fortaleza) Universidade de Fortaleza UNIFOR, SOFTEX, MPS.BR. Melhoria de Processo de Software Brasileiro, Guia de Aquisição: 2011 (Outubro de 2011). Disponível em: < Acesso em 12 mar SOFTEX, MPS.BR. Melhoria de Processo de Software Brasileiro, Guia de Avaliação: 2011 (Maio de 2011). Disponível em: < Acesso em 12 mar SOFTEX, MPS.BR. Melhoria de Processo de Software Brasileiro, Guia Geral: 2011 (Agosto de 2011). Disponível em: < Acesso em 12 mar SOFTEX, MPS.BR. Melhoria de Processo de Software Brasileiro, Guia de Implementação Parte 1: Nível G: 2011 (Julho de 2011). Disponível em: < Acesso em 12 mar SOFTEX. Guias. Disponível em: < Acesso em: 2 abr VICTOR. Glossary of Scrum Terms. Disponível em: < Acesso em: 24 mar VINÍCIUS. Sprint Planning Meeting. Disponível em: < Acesso em: 23 abr
A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza
A visão do modelo MPS.BR para Gerência de Projeto - Nível G por Adriana Silveira de Souza Agenda Visão Geral do MPS.BR Processos e Capacidade de Processo Níveis de Maturidade Atributos de Processo Processo
Leia maisGerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo
Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Laboratório de Tecnologia de Software LTS www.ufpa.br/lts Rede Paraense de Pesquisa em Tecnologias de Informação
Leia maisProject Builder: uma Ferramenta de Apoio a Implementação do Processo Gerência de Projetos do MPS.BR
Project Builder: uma Ferramenta de Apoio a Implementação do Processo Gerência de Projetos do MPS.BR Bernardo Grassano, Eduardo Carvalho, Analia I.F. Ferreira, Mariano Montoni bernardo.grassano@projectbuilder.com.br,
Leia maisQualidade de Software MPS.BR - Questões CESPE (2010 a 2013)
Qualidade de Software MPS.BR - Questões CESPE (2010 a 2013) Professor Gledson Pompeu gledson.pompeu@gmail.com Acesse nosso site em WWW.DOMINANDOTI.COM.BR Versões atualizadas de notas de aula e listas de
Leia maisScrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE
Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.
Leia maisQualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura. O Modelo. Wesley Torres Galindo. wesleygalindo@gmail.
Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura O Modelo Wesley Torres Galindo wesleygalindo@gmail.com Agenda O que é? Motivação Organização do MPS.BR Estrutura
Leia maisMASTER IN PROJECT MANAGEMENT
MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como
Leia maisARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.
ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página
Leia maisCHECK - LIST - ISO 9001:2000
REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da
Leia maisAVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br RESUMO
1 AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br Autor: Julio Cesar Fausto 1 RESUMO Em um cenário cada vez mais competitivo e em franca
Leia maisProva de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES
Implementação MPS.BR 26 de maio de 2008 4 horas de duração e-mail: (DEIXAR EM BRANCO) RESULTADO: Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Nota INSTRUÇÕES Para a maioria das questões você tem mais de uma opção e
Leia maisCONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES
CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás
Leia maisWesley Torres Galindo
Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura Wesley Torres Galindo wesleygalindo@gmail.com User Story To Do Doing Done O que é? Como Surgiu? Estrutura Apresentar
Leia maisMódulo de projetos ágeis Scrum Módulo de Projetos Ágeis Scrum
Módulo de Projetos Ágeis Fevereiro 2015 Versão Módulo de Projetos Ágeis O nome vem de uma jogada ou formação do Rugby, onde 8 jogadores de cada time devem se encaixar para formar uma muralha. É muito importante
Leia maisISO/IEC 12207: Gerência de Configuração
ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que
Leia maisWesley Torres Galindo. wesleygalindo@gmail.com
Wesley Torres Galindo wesleygalindo@gmail.com Wesley Galindo Graduação em Análise e Desenvolvimento de Sistemas Mestrado em Engenharia de Software Engenheiro de Software Professor Faculdade Escritor Osman
Leia maisCHECK LIST DE AVALIAÇÃO DE FORNECEDORES Divisão:
4.2.2 Manual da Qualidade Está estabelecido um Manual da Qualidade que inclui o escopo do SGQ, justificativas para exclusões, os procedimentos documentados e a descrição da interação entre os processos
Leia maisDesenvolvimento Ágil de Software
Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento
Leia maisF.1 Gerenciamento da integração do projeto
Transcrição do Anexo F do PMBOK 4ª Edição Resumo das Áreas de Conhecimento em Gerenciamento de Projetos F.1 Gerenciamento da integração do projeto O gerenciamento da integração do projeto inclui os processos
Leia maisGéssica Talita. Márcia Verônica. Prof.: Edmilson
Géssica Talita Márcia Verônica Prof.: Edmilson DESENVOLVIMENTO ÁGIL Técnicas foram criadas com o foco de terminar os projetos de software rapidamente e de forma eficaz. Este tipo de técnica foi categorizada
Leia maisENGENHARIA DE SOFTWARE I
ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis
Leia maisEstudo de caso para implantação do modelo MR-MPS-SV
Estudo de caso para implantação do modelo MR-MPS-SV Giovani Hipolito Maroneze 1, Jacques Duílio Branches 1 1 Departamento de Computação Universidade Estadual de Londrina (UEL) Caixa Postal 10.001 86.057-970
Leia maisAvaliação e Melhorias no Processo de Construção de Software
Avaliação e Melhorias no Processo de Construção de Software Martim Chitto Sisson Centro Tecnológico Universidade Federal de Santa Catarina (UFSC) Florianópolis SC Brasil martim@inf.ufsc.br Abstract. This
Leia maisPós-Graduação em Gerenciamento de Projetos práticas do PMI
Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL
Leia maisSistema de Gestão da Qualidade
Sistema de Gestão da Qualidade Coordenadora Responsável Mara Luck Mendes, Jaguariúna, SP, mara@cnpma.embrapa.br RESUMO Em abril de 2003 foi lançado oficialmente pela Chefia da Embrapa Meio Ambiente o Cronograma
Leia maisGerenciamento de Riscos do Projeto Eventos Adversos
Gerenciamento de Riscos do Projeto Eventos Adversos 11. Gerenciamento de riscos do projeto PMBOK 2000 PMBOK 2004 11.1 Planejamento de gerenciamento de riscos 11.1 Planejamento de gerenciamento de riscos
Leia maisO Modelo Processo de Software Brasileiro MPS-Br
O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,
Leia maisGARANTIA DA QUALIDADE DE SOFTWARE
GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características
Leia maisIntrodução ao MPS.BR Guia Geral. Prof. Elias Batista Ferreira
Introdução ao MPS.BR Guia Geral Prof. Elias Batista Ferreira IMPORTANTE Este NÃO é um curso oficial do MPS.BR. Este curso NÃO é apoiado pela Softex. Objetivo deste Curso Descrever os processos e resultados
Leia maisGerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos
Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos Referência: An Introductory Overview of ITIL v2 Livros ITIL v2 Cenário de TI nas organizações Aumento da dependência da TI para alcance
Leia maisGerenciamento de projetos. cynaracarvalho@yahoo.com.br
Gerenciamento de projetos cynaracarvalho@yahoo.com.br Projeto 3URMHWR é um empreendimento não repetitivo, caracterizado por uma seqüência clara e lógica de eventos, com início, meio e fim, que se destina
Leia maisMetodologia de Gerenciamento de Projetos da Justiça Federal
Metodologia de Gerenciamento de Projetos da Justiça Federal Histórico de Revisões Data Versão Descrição 30/04/2010 1.0 Versão Inicial 2 Sumário 1. Introdução... 5 2. Público-alvo... 5 3. Conceitos básicos...
Leia maisTecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler
Tecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler Introdução Objetivos da Gestão dos Custos Processos da Gerência de Custos Planejamento dos recursos Estimativa dos
Leia maisA Disciplina Gerência de Projetos
A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos
Leia maisGerenciamento de Problemas
Gerenciamento de Problemas O processo de Gerenciamento de Problemas se concentra em encontrar os erros conhecidos da infra-estrutura de TI. Tudo que é realizado neste processo está voltado a: Encontrar
Leia maisImplementação CERTICS em uma empresa avaliada no modelo de referência MPS-SW nível G
Relato da Experiência Implementação CERTICS em uma empresa avaliada no modelo de referência MPS-SW nível G Fumsoft Allan M. R. Moura Charles H. Alvarenga Visual Sistemas Breno F. Duarte Paulo Lana www.visual.com.br
Leia maisMODELO CMM MATURIDADE DE SOFTWARE
MODELO CMM MATURIDADE DE SOFTWARE O modelo CMM Capability Maturity Model foi produzido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon (CMU), em Pittsburgh, EUA, por um grupo
Leia maisPOLÍTICA DE GESTÃO DE RISCOS DAS EMPRESAS ELETROBRAS
POLÍTICA DE GESTÃO DE RISCOS DAS EMPRESAS ELETROBRAS Versão 2.0 30/10/2014 Sumário 1 Objetivo... 3 2 Conceitos... 3 3 Referências... 4 4 Princípios... 4 5 Diretrizes... 5 5.1 Identificação dos riscos...
Leia maisPROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às
Leia maisScrum. Gestão ágil de projetos
Scrum Gestão ágil de projetos Apresentação feita por : Igor Macaúbas e Marcos Pereira Modificada por: Francisco Alecrim (22/01/2012) Metas para o o Metas para treinamento seminário Explicar o que é Scrum
Leia maisLISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE
Questionamento a alta direção: 1. Quais os objetivos e metas da organização? 2. quais os principais Produtos e/ou serviços da organização? 3. Qual o escopo da certificação? 4. qual é a Visão e Missão?
Leia maisScrum e CMMI no C.E.S.A.R Relato de Experiência
Scrum e CMMI no C.E.S.A.R Relato de Experiência Felipe Furtado Engenheiro de Qualidade Izabella Lyra Gerente de Projetos Maio/2008 Agenda Motivação Pesquisas Adaptações do Processo Projeto Piloto Considerações
Leia maisResumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0
O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok
Leia maisIntegração de Projetos Ágeis XP com o MPS.BR Nível G
Integração de Projetos Ágeis com o MPS.BR Nível G Marcelo Stanga Universidade do Oeste de Santa Catarina (UNOESC) São Miguel do Oeste SC - Brasil marcelostanga@gmail.com Resumo. Neste artigo, aborda-se
Leia maisModelo de Referência para melhoria do processo de software (MR mps)
Modelo de Referência para melhoria do processo de software (MR mps) Projeto mps Br: Modelo de Referência para Melhoria de Processo de Software CMMI SPICE SCAMPI MODELO PARA MELHORIA DO PROCESSO DE SOFTWARE
Leia maisPolíticas de Qualidade em TI
Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte II Agenda sumária dos Processos em suas categorias e níveis de maturidade
Leia maisSCRUM. Fabrício Sousa fabbricio7@yahoo.com.br
SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os
Leia maisGerência de Projetos
Gerência de Projetos Escopo Custo Qualidade Tempo CONCEITO PROJETOS: são empreendimentos com objetivo específico e ciclo de vida definido Precedem produtos, serviços e processos. São utilizados as funções
Leia maisProjeto de Sistemas I
Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o
Leia maisMelhorias de Processos de Engenharia de Software
Melhorias de Processos de Engenharia de Software CMMI 1 Profa. Reane Franco Goulart O que é CMMI? O Capability Maturity Model Integration (CMMI) é uma abordagem de melhoria de processos que fornece às
Leia maisPEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS
PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e
Leia maisCRIAÇÃO DA DISCIPLINA SISTEMA DE GESTÃO AMBIENTAL NO CURSO DE ENGENHARIA CIVIL
CRIAÇÃO DA DISCIPLINA SISTEMA DE GESTÃO AMBIENTAL NO CURSO DE ENGENHARIA CIVIL Elias S. Assayag eassayag@internext.com.br Universidade do Amazonas, Departamento de Hidráulica e Saneamento da Faculdade
Leia maisPolíticas de Qualidade em TI
Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software
Leia maisMUDANÇAS NA ISO 9001: A VERSÃO 2015
MUDANÇAS NA ISO 9001: A VERSÃO 2015 Está em andamento o processo de revisão da Norma ISO 9001: 2015, que ao ser concluído resultará na mudança mais significativa já efetuada. A chamada família ISO 9000
Leia maisPEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM
PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM M P S. B R : M E L H O R I A D E P R O C E S S O D O S O F T W A R E B R A S I L E I R O A
Leia maisSISTEMA DA GESTÃO AMBIENTAL SGA MANUAL CESBE S.A. ENGENHARIA E EMPREENDIMENTOS
CESBE S.A. ENGENHARIA E EMPREENDIMENTOS SISTEMA DA GESTÃO AMBIENTAL MANUAL Elaborado por Comitê de Gestão de Aprovado por Paulo Fernando G.Habitzreuter Código: MA..01 Pag.: 2/12 Sumário Pag. 1. Objetivo...
Leia maisMetodologia SCRUM. Moyses Santana Jacob RM 63484. Stelvio Mazza RM 63117. Tiago Pereira RM 63115. Hugo Cisneiros RM 60900
Metodologia SCRUM Hugo Cisneiros RM 60900 Moyses Santana Jacob RM 63484 Stelvio Mazza RM 63117 Tiago Pereira RM 63115 SCRUM? O que é isso? SCRUM é um modelo de desenvolvimento ágil de software que fornece
Leia maisUniversidade Paulista
Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen
Leia maisReferências internas são os artefatos usados para ajudar na elaboração do PT tais como:
Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código
Leia maisCONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI
CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI 1. PI06 TI 1.1. Processos a serem Atendidos pelos APLICATIVOS DESENVOLVIDOS Os seguintes processos do MACROPROCESSO
Leia maisAluna: Vanessa de Mello Orientador: Everaldo Artur Grahl
Ferramenta web para gerenciamento de projetos de software baseado no Scrum Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Introdução Roteiro da apresentação Objetivos do trabalho Fundamentação
Leia maisCláudia Araújo Coordenadora Diego Macêdo Programador Marcelo Rodrigues Suporte
BCON Sistema de Controle de Vendas e Estoque Declaração de escopo Versão 1.0 Histórico de Revisão Elaborado por: Filipe de Almeida do Amaral Versão 1.0 Aprovado por: Marcelo Persegona 22/03/2011 Time da
Leia maisÉ POSSÍVEL SER ÁGIL EM PROJETOS DE HARDWARE?
É POSSÍVEL SER ÁGIL EM PROJETOS DE Doubleday K. Francotti v 1.0 Onde foi parar os requisitos? Trabalhando 30h por dia! Manda quem pode... Caminho das pedras Hum... Acho que deu certo... Onde foi parar
Leia maisGERENCIAMENTO DE PROJETOS PROJECT MANAGEMENT INSTITUTE
GERENCIAMENTO DE PROJETOS PROJECT MANAGEMENT INSTITUTE O PMI e a Certificação PMP Visão Geral sobre o Modelo PMI APRESENTAÇÃO DO PMI O PMI - Project Management Institute é uma instituição sem fins lucrativos,
Leia maisAgilidade parte 3/3 - Scrum. Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br
Agilidade parte 3/3 - Scrum Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br 1 Scrum Scrum? Jogada do Rugby Formação de muralha com 8 jogadores Trabalho em EQUIPE 2 Scrum 3 Scrum Scrum Processo
Leia maisPRINCÍPIOS DE SISTEMAS DE INFORMAÇÃO MÓDULO 17
PRINCÍPIOS DE SISTEMAS DE INFORMAÇÃO MÓDULO 17 Índice 1. Conceitos de Ciclo de Desenvolvimento de Sistemas...3 1.1. Principais Fases... 3 1.2. Técnicas... 4 1.3. Papéis de Responsabilidades... 4 1.3.1.
Leia maisDefinição do Framework de Execução de Processos Spider-PE
Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),
Leia maisPLANEJAMENTO PLANEJAMENTO ESTRATÉGIA CICLO PDCA CICLO PDCA 09/04/2015 GESTÃO DE ESCOPO GERENCIAMENTO DE PROJETOS ACT
UNIVERSIDADE FEDERAL DO PARANÁ DEPARTAMENTO DE CONSTRUÇÃO CIVIL PLANEJAMENTO 2 GERENCIAMENTO DE PROJETOS SUBMETIDA E APROVADA A PROPOSTA DO PROJETO PROCESSO DE PLANEJAMENTO GESTÃO DE Processo fundamental
Leia maisService Level Management SLM. Gerenciamento de Níveis de Serviço
Service Level Management SLM Gerenciamento de Níveis de Serviço 1 É o balanço o entre... Qualidade dos serviços entregues Expectativa do cliente 2 Processo: Definições Service Level Management (SLM) Têm
Leia maisELABORAÇÃO E ANÁLISE DE PROJETOS MÓDULO 10
ELABORAÇÃO E ANÁLISE DE PROJETOS MÓDULO 10 Índice 1. Gerenciamento da qualidade do projeto...3 2. Gerenciamento de recursos humanos do projeto...3 3. Gerenciamento das comunicações do projeto...4 2 1.
Leia maisRELATÓRIO SOBRE A GESTÃO DE RISCO OPERACIONAL NO BANCO BMG
SUPERINTENDÊNCIA DE CONTROLE GERÊNCIA DE CONTROLE DE TESOURARIA ANÁLISE DE RISCO OPERACIONAL RELATÓRIO SOBRE A GESTÃO DE RISCO OPERACIONAL NO BANCO BMG Belo Horizonte 01 de Julho de 2008 1 SUMÁRIO 1. Introdução...02
Leia maisGerenciamento de Projetos
Gerenciamento de Projetos Grupo de Consultores em Governança de TI do SISP 20/02/2013 1 Agenda 1. PMI e MGP/SISP 2. Conceitos Básicos - Operações e Projetos - Gerenciamento de Projetos - Escritório de
Leia maisPR 2 PROCEDIMENTO. Auditoria Interna. Revisão - 2 Página: 1 de 9
Página: 1 de 9 1. OBJETIVO Estabelecer sistemática de funcionamento e aplicação das Auditorias Internas da Qualidade, fornecendo diretrizes para instruir, planejar, executar e documentar as mesmas. Este
Leia maisGerenciamento de Projetos
Gerenciamento de Projetos (ref. capítulos 1 a 3 PMBOK) TC045 Gerenciamento de Projetos Sergio Scheer - scheer@ufpr.br O que é Gerenciamento de Projetos? Aplicação de conhecimentos, habilidades, ferramentas
Leia mais1 2009 CBG Centro Brasileiro de Gestão
1 2009 CBG Centro Brasileiro de Gestão ISO 9001:2015 Histórico da série 2 2009 CBG Centro Brasileiro de Gestão Histórico da série REVISÕES DA SÉRIE ISO 9000 2000 2008 2015 1994 1987 3 2009 CBG Centro Brasileiro
Leia maisEstudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa
Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)
Leia maisScrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain.
Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions www.domain.com Raphael Rayro Louback Saliba Certified Scrum Master 1 Gráfico de Utilização de Funcionalidades Utilização
Leia maisGlossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.
Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis
Leia maisPONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1141 Processo e qualidade de software I Prof. Me. Elias Ferreira Sala: 210 F Quarta-Feira:
Leia maisTrilhas Técnicas SBSI - 2014
brunoronha@gmail.com, germanofenner@gmail.com, albertosampaio@ufc.br Brito (2012), os escritórios de gerenciamento de projetos são importantes para o fomento de mudanças, bem como para a melhoria da eficiência
Leia maisANEXO X DIAGNÓSTICO GERAL
ANEXO X DIAGNÓSTICO GERAL 1 SUMÁRIO DIAGNÓSTICO GERAL...3 1. PREMISSAS...3 2. CHECKLIST...4 3. ITENS NÃO PREVISTOS NO MODELO DE REFERÊNCIA...11 4. GLOSSÁRIO...13 2 DIAGNÓSTICO GERAL Este diagnóstico é
Leia maisSCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com)
SCRUM: UM MÉTODO ÁGIL Cleviton Monteiro (cleviton@gmail.com) Roteiro Motivação Manifesto Ágil Princípios Ciclo Papeis, cerimônias, eventos, artefatos Comunicação Product Backlog Desperdício 64% das features
Leia maisEstratégia de Manutenção em Oficinas utilizando Caminho Critico
SEGeT Simpósio de Excelência em Gestão e Tecnologia 1 Estratégia de Manutenção em Oficinas utilizando Caminho Critico RESUMO Entre as estratégias gerenciais em empresas de médio e grande porte existe o
Leia maisPorque estudar Gestão de Projetos?
Versão 2000 - Última Revisão 07/08/2006 Porque estudar Gestão de Projetos? Segundo o Standish Group, entidade americana de consultoria empresarial, através de um estudo chamado "Chaos Report", para projetos
Leia maisPMI-SP PMI-SC PMI-RS PMI PMI-PR PMI-PE
ESTUDO DE BENCHMARKING EM GERENCIAMENTO DE PROJETOS 2009 Brasil Uma realização dos Chapters Brasileiros do PMI - Project Management Institute PMI-SP PMI-RJ PMI-AM PMI-SC PMI-BA ANEXO 1 PMI-RS PMI PMI-CE
Leia maisGerenciamento de Níveis de Serviço
Gerenciamento de Níveis de Serviço O processo de Gerenciamento de Níveis de Serviço fornece o contato entre a organização de TI e o cliente, para garantir que a organização de TI conhece os serviços que
Leia maisResultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS
Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Mauricio Fiorese 1, Alessandra Zoucas 2 e Marcello Thiry 2 1 JExperts
Leia maisOS 14 PONTOS DA FILOSOFIA DE DEMING
OS 14 PONTOS DA FILOSOFIA DE DEMING 1. Estabelecer a constância de propósitos para a melhoria dos bens e serviços A alta administração deve demonstrar constantemente seu comprometimento com os objetivos
Leia maisApós completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades
Objetivos da Aula 1 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Entendimento sobre os processos essenciais do
Leia maisSETIS- III Seminário de Tecnologia Inovação e Sustentabilidade 4 e 5 de novembro de 2014.
A importância da comunicação no gerenciamento de projetos de softwares: reflexões teóricas Lucas Krüger lucas_kruger-@hotmail.com Resumo: Esse artigo objetiva estudar a comunicação entre cliente e desenvolvedor
Leia maisPLANEJAMENTO E PROJETOS. Lílian Simão Oliveira
PLANEJAMENTO E GERENCIAMENTO DE PROJETOS Lílian Simão Oliveira Contexto Gerentes lutam com projetos assustadores e com prazos finais difíceis de serem cumpridos Sistemas não satisfazem aos usuários Gastos
Leia maisConteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de
Leia mais