TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR

12,416 views

Published on

Trabalho de conclusão apresentado ao curso de Sistemas de Informação da Universidade de Santa Cruz do Sul, para obtenção do título de Bacharel em Sistemas de Informação.

Orientadora: Prof.ª Daniela Duarte da Silva Bagatini.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
12,416
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
612
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR

  1. 1. CURSO DE SISTEMAS DE INFORMAÇÃO Juliano Silva de Oliveira METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR Capão da Canoa, junho de 2010.
  2. 2. UNIVERSIDADE DE SANTA CRUZ DO SUL METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR Trabalho de conclusão apresentado ao curso de Sistemas de Informação da Universidade de Santa Cruz do Sul, para obtenção do título de Bacharel em Sistemas de Informação. Orientadora: Prof.ª Daniela Duarte da Silva Bagatini. Capão da Canoa, junho de 2010.
  3. 3. “In the end, The Love you take Is equal to The Love you make.” (The Beatles – The End)
  4. 4. AGRADECIMENTOS Este é o trabalho que culmina minha passagem pelo curso de Sistemas de Informação, logo, é impossível não deixar de lembrar que diversas pessoas possibilitaram que eu pudesse chegar até este ponto. Agradeço, aos meus familiares – que sempre estiveram do meu lado –, aos meus colegas – que junto comigo, batalharam por este curso –, aos meus professores – que, a pesar das longas viagens, sempre estavam dispostos a dar o melhor de si –, e a todos que de forma direta ou indireta, contribuíram para minha chegada até aqui.
  5. 5. RESUMO Este trabalho trata do mapeamento entre os processos de Gerência de Requisitos e Desenvolvimento de Requisitos do Modelo MPS.BR alinhados a metodologia ágil Scrum. MPS.BR é um modelo de qualidade do processo de software fundamentado em normas e modelos conceituados, organizado de maneira a facilitar sua implantação por pequenas e médias empresas de desenvolvimento de software do mercado brasileiro. Scrum é uma metodologia ágil, amparada nos princípios e valores do Manifesto Ágil. É um framework para gerenciamento de projetos de desenvolvimento de software, baseado em processos empíricos, com iterações curtas e entregas rápidas de software pronto. Os processos de Gerência e Desenvolvimento de Requisitos, do Modelo MPS, foram mapeados com as práticas Scrum. Alguns resultados esperados dos processos mapeados são parcialmente ou não satisfeitos pela prática Scrum. Nestes casos, algumas ações podem ser tomadas no intuito de adicionar características, que não destituem os conceitos básicos de Scrum, mas que satisfazem os processos do modelo MPS.
  6. 6. ABSTRACT This paper is about a mapping between MPS.BR model’s Requirements Management and Requirements Development processes aligned at Scrum Agile Methodology. MPS.BR is a Process Quality Model based at standards and other models conceptualized, organized to facilitate its implantation at small and medium software development companies from Brazilian market. Scrum is an Agile Methodology, based at Agile Manifesto’s principles and values. It’s a framework for management software development projects, based at empirical processes, with short iterations and quick delivery of software done. The MPS.BR model’s Requirements Management and Requirements Development process were mapped with Scrum practices. Some process expected results mapped are partly or not satisfied by the Scrum practices. In these cases, some actions can be taken to add features that not deprive the Scrum basic concepts, but satisfy the MPS model’ processes.
  7. 7. LISTA DE ABREVIATURAS ABNT Associação Brasileira de Normas Técnicas AP Atributos de Processo BP Backlog do Produto BPV Backlog do Produto para a Versão BS Backlog da Sprint BV Bussines Value CMMI-DEV Software Capability Maturity Model for Development DRE Processo de Desenvolvimento de Requisitos GRE Processo de Gerência de Requisitos IEC International Electrotechnical Commission ISO International Organization for Standardization JAD Joint Application Development MPS.BR Melhoria do Processo de Software Brasileiro MR-MPS Modelo de Referência do MPS.BR PCP Processo de Projeto e Construção do Produto PO Product Owner RAP Resultados esperados de atributos de processo ROI Return Of Investiment RPVE Reunião de Planejamento da Versão para Entrega SM ScrumMaster SOFTEX Associação para Promoção da Excelência do Software Brasileiro SPICE Software Process Improvement and Capability Eternation TS Time Scrum VAL Processo de Validação VER Processo de Verificação XP Extreme Programming
  8. 8. SUMÁRIO 1 INTRODUÇÃO ..................................................................................................................... 9 2 REQUISITOS DE SOFTWARE ......................................................................................... 11 2.1 Visão geral sobre requisitos.............................................................................................. 11 2.2 Tipos de requisitos ............................................................................................................ 14 2.2.1 Requisitos funcionais..................................................................................................... 14 2.2.2 Requisitos não funcionais .............................................................................................. 14 2.2.3 Requisitos de domínio ................................................................................................... 16 2.3 Processo de engenharia de requisitos ............................................................................... 16 2.3.1 Estudo de viabilidade..................................................................................................... 17 2.3.2 Elicitação e análise de requisitos ................................................................................... 18 2.3.3 Validação de requisitos.................................................................................................. 19 2.3.4 Gerenciamento de requisitos ......................................................................................... 20 2.4 Requisitos e os modelos MPS.BR e Scrum ...................................................................... 21 3 FRAMEWORK SCRUM .................................................................................................... 22 3.1 Visão geral sobre metodologias ágeis .............................................................................. 23 3.2 Introdução ao Scrum ......................................................................................................... 23 3.2.1 Times Scrum, seus papéis e responsabilidades ............................................................. 24 3.2.2 Eventos .......................................................................................................................... 25 3.2.3 Artefatos ........................................................................................................................ 27 3.2.4 Software Pronto ............................................................................................................. 29 3.3 Fluxo do Scrum ................................................................................................................ 29 4 MODELO MPS.BR ............................................................................................................. 33 4.1 Introdução ao Modelo MPS.BR ....................................................................................... 33 4.2 Base técnica do Modelo MPS.BR .................................................................................... 34 4.3 Estrutura do MR-MPS.BR................................................................................................ 36 4.3.1 Níveis de maturidade ..................................................................................................... 36 4.3.1.1 Processos .................................................................................................................... 37 4.3.1.2 Capacidades de processos........................................................................................... 38 4.4 Processo de Gerência de Requisitos ................................................................................. 39
  9. 9. 4.4.1 Processo GRE – Propósito............................................................................................. 40 4.4.2 Processo GRE – Resultados Esperados ......................................................................... 40 4.5 Processo de Desenvolvimento de Requisitos ................................................................... 42 4.5.1 Processo DRE – Propósito............................................................................................. 43 4.5.2 Processo DRE – Resultados Esperados ......................................................................... 43 5 METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR .................................. 46 5.1 Mapeamento entre os processos GRE e DRE com Scrum ............................................... 46 5.2 Resultado do mapeamento entre os processos GRE e DRE com Scrum ......................... 51 5.3 Estendendo o Scrum ......................................................................................................... 53 6 APOIO A PRÁTICA DE SCRUM E PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR .................................. 55 6.1 Dificuldades práticas na implantação do processo GRE .................................................. 56 6.2 Dificuldades práticas relacionadas a requisitos de software ............................................ 57 6.3 Dificuldades práticas relacionadas ao Scrum ................................................................... 58 6.4 Além das limitações de MPS e Scrum ............................................................................. 59 7 CONCLUSÃO ..................................................................................................................... 60 7.1 Trabalhos futuros .............................................................................................................. 61 8 REFERÊNCIAS .................................................................................................................. 62 ANEXO A – Manifesto Ágil - Valores .................................................................................. 65 ANEXO B – Manifesto Ágil - Princípios............................................................................... 66 ANEXO C – Atributos de Processo - AP 1.1 ......................................................................... 67 ANEXO D – Atributos de Processo - AP 2.1 ......................................................................... 68 ANEXO F – Atributos de Processo - AP 3.1 ......................................................................... 70 ANEXO G – Atributos de Processo - AP 3.2 ......................................................................... 71
  10. 10. 9 1 INTRODUÇÃO A sociedade moderna, formada por indivíduos, luta diariamente contra o acaso e o caos. O ser humano parece estar sempre caminhando no sentido de buscar uma ordem para o contexto em que vive, seja pensando a respeito do sentido de sua própria existência ou buscando administrar os processos existentes de uma maneira mais eficiente e eficaz. As instituições que compõe a sociedade moderna têm em sua formação estes indivíduos, logo, a necessidade de ordenar, administrar, aplicar uma forma de trabalho nestas organizações é inerente ao seu processo de gerenciamento. Segundo Chiavenato (2000), toda a produção de bens e serviços é realizada dentro de organizações. Na área da tecnologia da informação, não é diferente, todos os produtos e serviços, mesmo o de desenvolvimento de software, é realizado por organizações. E elas estão sob as mesmas regras das demais empresas. Lutam diariamente para sobreviver ao mercado. Dentre as estratégias utilizadas para serem competitivas, as organizações, desde cedo, têm focado no controle de seus processos, buscando produzir mais e com mais qualidade, ao mesmo tempo em que se consome menos. Na história das organizações, existiram diversos modelos que propiciaram este pensamento, como o Taylorismo, o Fordismo ou o Toyotismo (CHIAVENATO, 2002). A indústria do software também tem os seus modelos. Ao entender que, devemos ter plena consciência dos modelos, devemos entender também, e com muito mais ênfase, os modelos que hoje estão na vanguarda das gestões organizacionais. Com isto em mente, a pretensão do presente trabalho é de poder apontar como uma organização pode melhorar seus produtos, serviços e processos, sob o ponto de vista dos requisitos de software, usando o modelo MPS.BR juntamente com o modelo de desenvolvimento ágil Scrum. Este trabalho será focado nos processos do MPS.BR relacionados a requisitos de software justamente porque requisitos e Scrum têm um ponto fortemente em comum: o foco
  11. 11. 10 em pessoas e as implicações do envolvimento delas no processo de desenvolvimento de software. Para tal objetivo, uma visão geral sobre requisitos será apresentada no capítulo dois; o capítulo três fará uma apresentação das metodologias ágeis e um maior detalhamento do Scrum; o capítulo quatro mostra o modelo MPS.BR, com um foco maior sobre os processos de gerência e desenvolvimento de requisitos; o capítulo cinco, é dedicado ao mapeamento, resultados e análise do uso do Scrum associado aos processos de requisitos do MPS.BR; o capítulo seis trará considerações a respeito da possibilidade da aplicação prática do assunto abordado; e por fim as conclusões do trabalho.
  12. 12. 11 2 REQUISITOS DE SOFTWARE Os requisitos são intrínsecos ao processo de desenvolvimento de software, entendê-los corretamente evita a grande maioria dos problemas que uma aplicação poderá ter. Requisitos são temas recorrentes em diversos trabalhos acadêmicos. Neste trabalho, para que se possa compreender o que o modelo MPS.BR e o Scrum apregoam a respeito de requisitos, faz-se uma abordagem da área apresentando algumas considerações a respeito. 2.1 Visão geral sobre requisitos Requisitos segundo Parzianello (2009) “são descrições das propriedades necessárias e suficientes de um produto de software que devem ser atendidas para garantir que se cumpra o que foi projetado, atendendo as necessidades de seus usuários”. De acordo com Ávila (2007), requisitos são “o conjunto de necessidades explicitadas pelo cliente que deverão ser atendidas para solucionar um determinado problema de negócio no qual o cliente faz parte”. Ou ainda, são necessidades ou expectativas expressas, geralmente, de forma implícita ou obrigatória (Associação Brasileira de Normas Técnicas – ABNT, 2000). Podemos entender requisitos como necessidades de um cliente ou usuário que deverão ser atendidas para solucionar um determinado problema do negócio no qual o cliente faz parte. Enxergando o contexto dos requisitos de uma maneira mais ampla, podemos dizer que eles possuem três focos: negócios, usuários e o software. Os requisitos de usuário dirão o quê deve ser feito, enquanto que os requisitos de negócio, são elementos que correspondem às regras do negócio, respondem o porquê algo deve ser feito. E os requisitos de software mostrarão como a solicitação do usuário será atendida dentro das regras do negócio (figura 1).
  13. 13. 12 Figura 1 – O Contexto dos Requisitos Fonte: PARZIANELLO, 2009. Entender os requisitos é descobrir o que o cliente quer com o sistema (WAZLAWICK, ntender ( 2004, p. 24). Logo, por requisitos abrangerem todas as características importantes do software que será produzido, a elaboração destes torna se uma das fases mais importantes de todo o torna-se importan projeto de software. É na análise de requisitos que boa parte dos erros são introduzidos. Cenários, como apresentado na tabela 1 por Ávila (2007), mostram que defeitos não tratados ainda na fase de Á , requisitos podem aumentar consideravelmente o custo do desenvolvimento do projeto. Ao contrário, a correção, ainda nesta fase, possui um custo baixo (conforme primeira linha da ne conforme tabela 1). Tabela 1 – Cenário Atual de Desenvolvimento % do custo de % dos erros % dos erros Custo relativo desenvolvimento esenvolvimento introduzidos encontrados de correção Análise de Requisitos 05 55 18 1 Projeto 25 30 10 1 - 1.5 Codificação teste de 50 unidade Teste 10 10 50 1-5 Validação e 10 Documentação Manutenção 05 22 10 - 100 Fonte: ÁVILA, 2007.
  14. 14. 13 Diversos estudos de caso mostram que pelo menos um terço dos defeitos encontrados nos projetos de software são originados de erros no levantamento de requisitos (PARZIANELLO, 2009). Pela sua importância, a análise de requisitos é uma das fases que mais precisam atenção. E mesmo tendo consciência a respeito de sua natureza e de como elicitar requisitos, ainda há uma grande dificuldade em atingir o sucesso nessa tarefa em um projeto de software. Um ponto que não pode ser deixado de lado, em nenhuma fase da produção de um software ou de qualquer produto ou serviço, e que na fase de análise de requisitos assume uma importância maior ainda, é a natureza humana. Ela está envolvida em cada ação para se chegar ao entendimento dos requisitos, e cabe aos analistas entender o impacto da natureza humana ao elicitar requisitos de software. Chiavenato (2002, p. 113) expõe através da Hierarquia das Necessidades de Maslow, que nas motivações humanas, muitas de nossas necessidades são implícitas, e podem ser organizadas em níveis, com uma hierarquia de importância e influência. Estes requisitos dos seres humanos apresentados por Maslow, de realização pessoal, estima, amor/relacionamento, segurança e fisiologia, são implícitos. Requisitos implícitos fazem parte dos humanos assim como fazem parte dos softwares. A Norma NBR ISO 9000:2000, ao conceituar requisitos, diz que eles podem ser implícitos ou obrigatórios, e explica em nota que, “geralmente implícito significa que é uma prática costumeira ou usual para a organização, seus clientes e outras partes interessadas, e que a necessidade ou expectativa sob consideração está implícita”. A mesma norma também aponta que “um requisito especificado é um requisito declarado, por exemplo, em um documento” (ABNT, 2000, p. 7). Logo, requisitos implícitos para quem os solicita, acabam não sendo especificados por não serem implícitos para os analistas que deveriam documentá-los. Tem-se então um problema entre a maneira como diferentes pessoas enxergam a realidade.
  15. 15. 14 Assim, sendo requisitos um tema central no cenário de desenvolvimento de software, é necessário conhecer algumas das principais definições da engenharia de requisitos, importante no dia a dia de profissionais envolvidos com o ciclo de vida do software. 2.2 Tipos de requisitos Sommerville (2003) classifica os requisitos de software em três tipos: Requisitos funcionais, Requisitos não funcionais e Requisitos de domínio. 2.2.1 Requisitos funcionais Requisitos funcionais são declarações detalhadas das funções que o sistema deve executar e como deve ser seu comportamento diante de entradas e situações específicas (SOMMERVILLE, 2003). Ávila (2007) citam alguns exemplos de requisitos funcionais: • O software deve permitir o cadastro de produtos. • O software deve permitir o gerenciamento do estoque. • O software deve permitir a geração de relatório dos produtos em estoque. 2.2.2 Requisitos não funcionais Requisitos não funcionais são as restrições sobre as funções que serão oferecidas pelo sistema. Eles também podem ser a respeito de requisitos relacionados ao processo utilizado para o desenvolvimento do software, como especificações dos padrões de qualidade. Os requisitos não funcionais surgem em razão do usuário, do orçamento disponível, das políticas organizacionais ou até mesmo de necessidades externas, como necessidades legais ou de segurança (SOMMERVILLE, 2003). Segundo Andrade (2007), alguns exemplos de requisitos não funcionais são:
  16. 16. 15 • O software deve ser compatível com o browser IE (versão 5.0 ou superior) e Firefox (1.0 ou superior); • O software deve garantir que o tempo de retorno das consultas não seja maior e consultas do que cinco segundos. Os diferentes tipos de requisitos não funcionais estão representados na figura 2, classificados por Sommerville (2003) conforme a sua procedência procedência: Figura 2 – Tipos de Requisitos Não Funcionais Fonte: SOMMERVILLE, 2003 Os requisitos de produto são procedentes do comportamento do produto, como o desempenho, o espaço requerido e outros. Requisitos organizacionais especificam políticas e . procedimentos do cliente e do desenvolvedor, como questões relacionadas aos padrões que serão utilizados, quais os prazos de entrega e os requisitos de implementação. Os fatores externos ao sistema ou ao processo de desenvolvimento, como questões legais ou éticas, são representados pelos requisitos externos. los
  17. 17. 16 2.2.3 Requisitos de domínio Nascimento (2009) e Sommerville (2003) explicam que os fundamentos do domínio da aplicação são representados pelos requisitos de domínio, que descrevem características do sistema e qualidades que refletem o domínio, ao invés de serem captados a partir dos usuários do sistema. Andrade (2007) indica alguns exemplos de requisitos de domínio: • O cálculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 + Nota2 * 3) / 5; • Um aluno pode se matricular em uma disciplina desde que ele tenha sido aprovado nas disciplinas consideradas pré-requisitos. 2.3 Processo de engenharia de requisitos Sommerville (2003) aponta que a engenharia de requisitos é um processo que envolve todas as atividades exigidas para criar e manter o documento de requisitos do sistema. Ávila (2007) descreve diferentes definições encontradas na literatura técnica: • Termo usado para descrever as atividades relacionadas à investigação e definição de escopo de um sistema de software; • Processo sistemático de desenvolvimento de requisitos através de um processo de análise onde os resultados das observações são codificados e a acurácia das observações é constantemente verificada; • Processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema; • Atividades relacionadas à produção (levantamento, registro, validação e verificação) e gerência (controle de mudanças, gerência de configuração, rastreabilidade, gerência de qualidade dos requisitos) de requisitos. A figura 3 descreve, de maneira geral, o processo de engenharia de requisitos, composto por atividades relacionadas.
  18. 18. 17 Figura 3 – Processo de Engenharia de Requisitos Fonte: SOMMERVILLE, 2003. 2.3.1 Estudo de viabilidade Autores como Sommerville (2003), recomendam que ao iniciar o projeto de um novo recomendam sistema, o processo de engenharia de requisitos deve ser iniciado com um estudo de genharia viabilidade que indicará se vale a pena ou não seguir adiante no projeto. Ele explica que o estudo de viabilidade deve responder as seguintes perguntas: • O sistema contribui para os objetivos gerais da organização? • O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e prazo? • O sistema pode ser integrado com outros sistemas já em operação? Deve-se buscar informação através dos gerentes de departamentos, engenheiros de se software e usuários finais do sistema e através do relatório de estudo de viabilidade recomendar se o desenvolvimento do sistema deve iniciar/continuar ou não, podendo sugeri continuar sugerir mudanças em questões importantes do projeto, como o enfoque do sistema, o orçamento disponível ou o cronograma de desenvolvimento.
  19. 19. 18 2.3.2 Elicitação e análise de requisitos Após os estudos de viabilidade apontarem que o projeto deve seguir em frente, inicia- se a etapa de elicitação e análise dos requisitos. É nesta etapa que os requisitos são obtidos. A elicitação é a tarefa de identificar os fatos que compõem os requisitos do sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado pelo cliente. Para isso, os responsáveis pelo desenvolvimento do sistema terão de trabalhar com os clientes e usuários finais a fim de descobrir as necessidades e restrições relacionadas ao sistema a ser desenvolvido (SPÍNOLA, 2009). A etapa de elicitação e análise de requisitos, como já comentado anteriormente, é um estágio decisivo e difícil dentro do projeto de qualquer sistema, por diversos fatores, como os listados por Ávila (2007): • Falta de conhecimento do usuário das suas reais necessidades; o Usuário com vaga noção do que precisa e do que um produto de software pode oferecer; • Falta de conhecimento do desenvolvedor do domínio do problema; o Desenvolvedor sem conhecimento adequado do domínio, o que leva a decisões erradas; • Domínio do processo de levantamento de requisitos pelos desenvolvedores; o Desenvolvedor não ouve o que os usuários têm a dizer e força suas próprias visões e interpretações. • Comunicação inadequada entre os desenvolvedores e usuários; o Usuários incapazes de expressar suas necessidades apropriadamente; o Significados diferentes a termos comuns; • Dificuldade de o usuário tomar decisões; o Falta de entendimento sobre as conseqüências das decisões ou as alternativas positivas; • Problemas de comportamento; o O levantamento de requisitos é um processo social; o Conflitos e ambiguidades nos papéis que os usuários e desenvolvedores desempenham;
  20. 20. 19 • Questões técnicas; o Complexidade crescente dos sistemas atuais; No interesse de obter-se um melhor desempenho na elicitação, técnicas foram criadas para apoiar essa atividade. Spínola (2009) comenta algumas delas: • Entrevista: Técnica no qual os requisitos são levantados através de entrevistas com os usuários. Essa técnica pode ser realizada de diversas formas e na literatura técnica há uma boa quantidade de materiais que orientam como aplicar corretamente esta técnica de levantamento de requisitos. • Prototipação: É o desenvolvimento de uma versão inicial do sistema para experimentação. Isso permitirá aos usuários identificar os pontos fortes e fracos do sistema. Essa técnica possui como desvantagem os custos de aprendizagem e os custos de desenvolvimento. • JAD (Joint Application Development): Técnica que deve ser usado no caso em que existe a necessidade de consenso entre diversos usuários. Ela permite que todos os envolvidos tenham uma visão global do sistema através de reuniões e workshops que promovam interação e aumentem o comprometimento dos envolvidos com os requisitos a serem levantados. • Questionários: Técnica indicada para quando há diversos grupos de usuários que podem estar em diferentes locais. Neste caso, elaboram-se pesquisas específicas de acompanhamento com usuários selecionados. Esta técnica permite a padronização das perguntas e tratamento estatístico das respostas. 2.3.3 Validação de requisitos Enquanto a análise de requisitos envolve trabalhar com requisitos incompletos, o processo de validação deve ser executado no sentido de elaborar-se um esboço completo do documento de requisitos (SOMMERVILLE, 2003). Durante esse processo, deve-se examinar a especificação do software, assegurando que os requisitos estão livres de ambigüidades, inconsistências ou omissões, detectando ou
  21. 21. 20 corrigindo possíveis problemas ainda durante a fase de definição dos requisitos (ÁVILA, 2007). Esse processo é finalizado após obter o aceite do cliente sob os requisitos levantados. A dificuldade dessa atividade não deve ser subestimada, pois os usuários devem pensar no sistema em operação e imaginar como o sistema se adequaria ao seu trabalho. Devido a essa dificuldade, raramente o processo de validação consegue descobrir todos os problemas com os requisitos. 2.3.4 Gerenciamento de requisitos Ávila (2007) afirma que o processo de gerenciamento de requisitos é a atividade de administrar os requisitos ao longo do tempo. Explica que softwares complexos estão sempre sendo modificados. Isso ocorre por conta da natureza volátil dos requisitos, que são influenciados por diversos fatores, como mudanças externas nos ambientes (como mudanças de legislação, mercado ou estratégia da empresa), erros cometidos no processo de elicitação dos requisitos, entre outros. As modificações necessárias precisam ser gerenciadas de uma maneira ordenada, para que não se perca controle dos prazos e custos de desenvolvimento do projeto (ÁVILA, 2007). Os benefícios dessa prática são a longo prazo e algumas atividades precisam ser levadas em conta durante o gerenciamento dos requisitos, como o controle das mudanças, a gerência de configuração e a rastreabilidade. Devido às necessidades de alterações dos requisitos, é preciso ter um único canal para o controle das mudanças, podendo assim, diferenciar o que era requisito original, o que foi introduzido e o que foi descartado. Ávila (2007) indica que antes de aceitar ou rejeitar alguma mudança, deve-se analisá-la conforme os impactos e custos que ela pode ter no sistema. Para isso indica os seguintes passos: • Checar validade de solicitação de mudança; • Identificar os requisitos diretamente afetados com a mudança; • Identificar dependências entre os requisitos para buscar os requisitos afetados indiretamente;
  22. 22. 21 • Assegurar com solicitante a mudança a ser realizada; • Estimar custos da mudança; • Obter acordo com o usuário sobre o custo da mudança. A Gerência de Configuração: Consiste em definir os critérios que permitem realizar modificações, seja na especificação dos requisitos ou na implantação do sistema, e o controle sistemático das modificações de maneira a manter a consistência e a integridade do software com as especificações. A rastreabilidade é a capacidade de acompanhar a vida de um requisito bidirecionalmente, ou seja, partindo de requisitos e chegando ao projeto ou partindo de projeto e chegando a requisitos. 2.4 Requisitos e os modelos MPS.BR e Scrum Tanto o modelo MPS.BR como o Scrum não resolverão os problemas relacionados a requisitos. Ambos apenas fornecem ferramentas para gerenciar melhor os requisitos, sendo que o primeiro é focado nos processos que envolvem a gerência dos requisitos e o segundo assume que os requisitos mudam ao longo do processo de desenvolvimento e tem como estratégia iterações curtas, que permitem uma avaliação dos requisitos periodicamente. Tais modelos servem como guias de boas práticas para o alcance do sucesso de um projeto de software. Nos capítulos seguintes, os requisitos serão vistos sob o ponto de vista da metodologia ágil e do modelo de processo, e ao final, tentaremos mostrar como eles podem trabalhar de maneira conjunta e como isso pode contribuir para o sucesso da gestão dos requisitos e conseqüentemente para o sucesso do produto ou serviço a ser desenvolvido.
  23. 23. 22 3 FRAMEWORK SCRUM Nas mais diferentes áreas, nos mais variados serviços, a agilidade é quase que um paradoxo, todos querem ser servidos por ela, mas poucos se dispõem a provê-la. O provê desenvolvimento ágil de softwares é, para muito , algo intangível, que não existe. Mas uma oftwares muitos, série de profissionais, de todas as partes do mundo, dedicam-se a aplicar os conceitos das se metodologias ágeis, divulgando e aprimorando esses conceitos que ganham, cada vez mais a aceitabilidade dentro das empresas de tecnologia da informação. empres Dentre os principais métodos ágeis de desenvolvimento de software podem ser citados: Scrum, Extreme Programming, Lean Software Development, entre outros. O gráfico 1 corrobora a afirmação inicial mostrando a pesquisa apresentada pela VersionOne (2009), inicial, rando respondida por 2.570 participantes, de 88 países, e que teve como resultado que Scrum ou alguma variação deste, é utilizado por mais de 70 % dos participantes. Gráfico 1 – Utilização de metodologias ágeis Fonte: VERSIONONE, 2009. Este capítulo tem como foco os conceitos básicos que levam ao entendimento do Scrum e que permitirão uma avaliação do uso deste framework juntamente com o modelo MPS.BR.
  24. 24. 23 3.1 Visão geral sobre metodologias ágeis As metodologias ágeis são o resultado do esforço de um grupo de dezessete desenvolvedores experientes e consultores, que em 2001, compuseram um manifesto o qual valoriza um conjunto de valores e práticas comuns para o desenvolvimento de software de uma maneira mais ágil. O manifesto ágil identifica valores e princípios que devem prevalecer no desenvolvimento de software (BECK, 2001 apud DIAS, 2010; ANEXOS A e B). Segundo Dias (2010), a essência das metodologias ágeis é o enfoque do desenvolvimento de software calcado na agilidade, na flexibilidade, nas habilidades de comunicação e na capacidade de oferecer novos produtos e serviços de valor ao mercado, em curtos períodos de tempo. A agilidade não significa a falta de estrutura, mas sim a capacidade de adaptação a situações inesperadas. Podemos identificar quatro aspectos que o manifesto ágil impulsiona: a cultura, a comunicação, as pessoas e o processo. O manifesto prega que os projetos dêem o suporte necessário às necessidades da equipe, formando profissionais motivados e confiantes, que reflitam sobre como tornarem-se mais efetivos, empregando seus esforços em entregar software funcionando (PRIKLADNICKI, 2009). Como comentado anteriormente, Scrum é um de vários métodos ágeis, como o Adaptative Software Development (ASD), Crystal Clear, Extreme Programming, Lean Software Development, Feature Driven Development (FDD), Agile Unified Process. Pela importância que tem adquirido perante a comunidade de desenvolvedores e pelas características que garantem um compromisso com a entrega de valor ao cliente, sem perder o foco nos processos, na cultura e nas pessoas que desenvolvem, o Scrum faz parte do escopo deste trabalho. 3.2 Introdução ao Scrum Porque Scrum? No Guia do Scrum, Schwaber (2009), explica que Scrum não é um processo e nem uma técnica, é um framework com objetivo de transparecer a eficácia, onde se
  25. 25. 24 pode empregar diversos processos e técnicas. Scrum é baseado em processos empíricos, possui uma abordagem iterativa e incremental, o que permite uma maior previsibilidade e controle dos riscos. Ao assumir que o objetivo do projeto é o produto e não a documentação, Scrum busca gerar apenas a documentação suficiente e necessária para atingir o objetivo de entregar um produto que dê ao cliente um retorno rápido do seu capital investido. Ao defender que abraçar as mudanças é mais importante do que seguir um plano, Scrum vem de encontro às metodologias tradicionais de desenvolvimento de software, exigindo muita disciplina e organização para que se tenha a habilidade de ser flexível com estabilidade (MACHADO, 2009). O Scrum consiste em Times Scrum com seus papéis associados, Eventos com duração fixa e Artefatos. O framework possui também Regras, que irão delimitar a atuação dos diferentes papéis e eventos e serão descritas ao longo deste capítulo (SCHAWBER, 2009, p. 4). 3.2.1 Times Scrum, seus papéis e responsabilidades Schwaber (2009), explica que os Times Scrum devem ter como objetivo a flexibilidade e produtividade e que para isso eles necessitam ser auto-organizados, interdisciplinados e trabalharem em iterações. Os Times Scrum têm pelo menos três papéis: o ScrumMaster, o Product Owner e o Time. O ScrumMaster é a pessoa responsável por garantir que o processo seja entendido e seguido, é ele quem deve verificar se o Time Scrum está aderindo aos valores, princípios, práticas e regras do Scrum. Apesar do ScrumMaster não gerenciar o Time Scrum, pois este deve ser auto-organizado, ele deve fazer com que o Time Scrum entenda e use autogerenciamento e interdisciplinaridade. A responsabilidade de gerenciar o Backlog do Produto (lista de requisitos) que será desenvolvido é do Product Owner. Ele também é responsável por garantir que o trabalho
  26. 26. 25 realizado pelo Time tenha valor, garantindo uma priorização correta dos itens do Backlog. Seu sucesso depende que haja respeito com relação as suas decisões. O Time é formado pelos desenvolvedores de software, que a cada Sprint, baseados nas prioridades do Backlog, devem entregar Software Pronto. Times também precisam tomar a decisão de como realizar a tarefa de entregar o Software Pronto dentro do prazo, e para isso precisam ser auto-organizados e interdisciplinares. 3.2.2 Eventos Os Eventos no Scrum devem possuir regularidade e por isso têm duração fixa. Reunião de Planejamento da Versão para Entrega, a Sprint, a Reunião Diária, a Revisão da Sprint e a Retrospectiva da Sprint são os elementos com duração fixa empregados no framework. Na Reunião de Planejamento da Versão para Entrega, o Time Scrum estabelecerá, através de planos e metas, quais as prioridades do Backlog do Produto que formarão o Backlog do Produto para a Versão, quais os riscos envolvidos, qual a data de entrega e o provável custo da versão a ser entregue. O planejamento deverá levar em conta o objetivo de alcançar a satisfação do cliente e o retorno do investimento (ROI1) desejados, ele permitirá que a organização avalie o progresso do projeto, possibilitando correções nos planos a cada Sprint. A Sprint é um evento de duração fixa, na qual o ScrumMaster deverá garantir que nenhuma mudança afete o objetivo da Sprint. Por mudança, entendem-se também as mudanças na composição do time e das metas de qualidade. As Sprints são formadas pela reunião de Planejamento da Sprint, o desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. No Scrum, para diminuir a complexidade do projeto, recomenda-se que as Sprints tenham entre duas a quatro semanas. Dessa forma, evita-se que o plano de desenvolvimento 1 ROI significa em inglês Return Of Investiment, é a relação entre o dinheiro ganho ou perdido através de um investimento, e o montante de dinheiro investido. (WIKIPEDIA. Retorno sobre investimento. Disponível em: < http://pt.wikipedia.org/wiki/Retorno_sobre_investimento >. Acesso em: jun. 2010.)
  27. 27. 26 do projeto perca a validade pelas mudanças que podem ocorrer em um plan planejamento muito longo. Em Scrum, a previsibilidade do projeto será controlada dentro do período compreendido por cada Sprint. As Sprints são precedidas pela reunião de Planejamento da Sprint. Nesta reunião, Schwaber (2004), recomenda uma duração de oito horas para Sprints de um mês e no caso de horas Sprints mais curtas, uma duração de cerca de cinco por cento do tamanho da Sprint. A reunião é dividida em duas etapas de quatro horas, sendo que na primeira etapa o objetivo é o time discutir quais itens do Backlog do Produto serão produzidos na Sprint. O time poderá dar sugestões, mas a decisão de quais itens serão produzidos é exclusivamente do Product Owner. Porém cabe ao Time definir, baseado em sua experiência, qual a quantidade de itens será ime possível produzir dentro da Sprint. entro Na segunda etapa o time deve discutir como os itens escolhidos serão transformados em Software Pronto. As tarefas para a concretização desta tarefa formarão o Backlog da ronto. Sprint (figura 4). Ao efetuar o planejamento da Sprint e estabelecer as metas da mesma, a . equipe deverá levar em conta a Meta da Versão para Entrega. Figura 4 – Formação do Backlog da Sprint Fonte: KNIBERG, 2007, p. 22. Ao término de cada Sprint, o Time Scrum deverá reunir-se para a Revisão da Sprint. reunir se Nesta reunião a equipe deve fornecer feedback, discutir sobre sucessos problemas quipe sucessos, enfrentados, como foram solucionados no decorrer da Sprint, com o objetivo de identificar e Sprint corrigir deficiências e/ou imped impedimentos no processo de desenvolvimento. A equipe deve vimento. demonstrar o trabalho pronto, e o Product Owner deve identificar os itens do Backlog da Sprint que foram feitos e os que não foram feitos, e discutir como o restante do Backlog do
  28. 28. 27 Produto será efetuado, fazendo projeções de prováveis datas de entrega com base na velocidade estimada da equipe. O Scrum estabelece que após a revisão da Sprint e antes do planejamento da próxima Sprint, o Time Scrum deve realizar uma reunião com o tempo fixo de três horas para Retrospectiva da Sprint. Nesta reunião o ScrumMaster deve encorajar o Time a revisar o processo de desenvolvimento, inspecionando quais mudanças podem torná-lo mais eficaz e gratificante para a próxima Sprint (SCHWABER, 2009). Durante as Sprints a equipe deve realizar uma Reunião Diária de quinze minutos, que deve ser sempre no mesmo horário e local. No Guia do Scrum2 ela é relatada como fundamental ao processo empírico do Scrum. Nessa reunião, o ScrumMaster deve garantir que a reunião aconteça e ajudar para que o Time seja o responsável pela condução da mesma, obedecendo ao tempo estabelecido. Nela cada membro deve explicar: O que ele realizou desde a última reunião diária; O que ele vai fazer antes da próxima reunião diária; E quais os obstáculos estão em seu caminho. O objetivo da Reunião Diária é inspecionar o progresso da Meta da Sprint e ajudar o time a alcança-lá. 3.2.3 Artefatos O framework também emprega os seguintes Artefatos: Backlog do Produto, que consiste em uma lista de todos os requisitos necessários ao produto; O Backlog da Sprint, que é a lista de itens do Backlog do Produto que, em uma Sprint, serão transformados em Software Pronto; O Burndown de Versão para Entrega, que mede o Backlog do Produto em relação ao tempo estimado para entrega do produto; E o Burndown de Sprint, que mostra os itens do Backlog da Sprint em relação ao tempo da Sprint. O burndown é um gráfico que mostra o backlog a ser desenvolvido pelo tempo estimado de desenvolvimento. Schwaber (2009) indica o Backlog do Produto como uma lista de todos os requisitos necessários ao produto que está sendo desenvolvido, ele deve estar disponível e priorizado pelo Product Owner, que desempenha o papel responsável pelo conteúdo deste Backlog, 2 Detalhes sobre o Guia do Scrum em SCHWABER, 2009.
  29. 29. 28 cabendo ao Product Owner fazer com que o Backlog tenha inicialmente os requisitos conhecidos e melhor entendidos. À medida que o Produto evolui, o Backlog também caminha endidos. neste sentido. O Backlog é dinâmico, mudando constantemente no sentido de identificar o que é o mais apropriado, competitivo e útil ao Produto. O Backlog do Produto deve ser uma lista com todas as características, funções, todas tecnologias, melhorias e correções de defeitos. Seus itens devem conter atributos como: descrição, prioridade e estimativa. Ele deve estar ordenado por prioridade (f prioridade (figura 5). Quanto maior a prioridade do item, maior deverá ser o seu nível de detalhamento e com mais urgência deverá ser o seu desenvolvimento. Os itens do Backlog do Produto deverão ser decompostos de maneira a poderem ser realizados dentro da duração de uma Sprint. Figura 5 – Exemplo de Product Backlog Fonte: inspirada em SCHWABER, 2004. : Os itens do Backlog deverão ter suas estimativas de esforço calculadas durante o Planejamento da Versão para Entrega, sendo atualizadas em qualquer tempo pelo Time. Com a soma das estimativas de esforço necessário para o término do Backlog do término Produto, registradas ao longo do tempo através de um gráfico, é possível analisar a velocidade do Time, podendo-se traçar uma linha de tendência que mostrará uma estimativa do progresso se do desenvolvimento do Produto. Este gráfico é chamado de Burndown da Versão para chamado Entrega. Geralmente as unidades de tempo utilizadas são Sprints e o esforço estimado deve estar em qualquer unidade de medida de trabalho adotada pelo Time Scrum. Schwaber (2009) também explica que o Backlog da Sprint é todo o trabalho que o Time identifica como necessário para alcançar a Meta da Sprint, consiste nas tarefas necessárias para transformar os itens do Backlog do Produto em Software Pronto. Os itens do Pronto
  30. 30. 29 Backlog da Sprint devem ser decompostos ao ponto que possam ser entendidos na Reunião ser Diária. O Time, e somente ele, pode modificar o Backlog da Sprint ao longo da mesma, atualizando também as estimativas de trabalho restante. Assim como o Burndown da Versão para entrega, é possível usar a soma das estimativas de esforço necessárias para o término do Backlog da Sprint e registrá-las ao longo sforço registrá do tempo em um gráfico, gerando o Burndown da Sprint, criando um gráfico que mostre o trabalho restante ao longo do tempo (figura 6 go 6). Figura 6 – Burndown da Sprint Fonte: inspirada em SCHWABER, 2004. pirada 2004 3.2.4 Software Pronto O framework Scrum tem como regra que se deve ter como resultado incrementos de funcionalidade do Produto potencialmente entregáveis ao final de cada Sprint. O conceito de “Pronto” deve incluir toda a análise, projeto, refatoramento, programação, documentação e análise, testes. 3.3 Fluxo do Scrum Isotton Neto (2008), com base no artigo “The Scrum Development Process”, de “The Process Schwaber (1996), define que Scrum é formado pelos seguintes grupos de fases: ),
  31. 31. 30 Pregame: • Planejamento – Definição de um novo release baseado no Backlog do Produto (BP) e estimativa de cronograma e custo. Se for o início de um novo projeto, essa fase consiste em conceitualização e análise do produto. Se for um projeto em andamento, esta fase é limitada à análise. Os passos dessa fase são: o Desenvolvimento claro e objetivo do BP; o Definição da data de entrega e funcionalidades de uma ou mais Sprints; o Definição do release mais apropriado para o início do desenvolvimento; o Mapeamento e estimativa das atividades a serem incluídas no Backlog do Produto; o Definição do Time Scrum (TS); o Avaliação e controle de riscos envolvidos no projeto; o Avaliação das ferramentas de desenvolvimento e infra-estrutura do projeto; o Estimativa de custos. • Arquitetura – Definição de como os itens do BP serão implementados. Modificações na arquitetura do sistema e design de alto nível também são realizadas nessa fase. Os passos desta fase: o Revisão e ajustes ao BP; o Identificação das mudanças necessárias para a implementação do BP; o Realizar a análise do domínio; o Refinar a arquitetura do sistema; o Identificação de possíveis problemas ou impedimentos na implementação dos requisitos; o Reunião de revisão do design, onde são apresentadas as propostas de melhoria e mudanças na implementação de cada item do BP. Game: • Sprints – Desenvolvimento das funcionalidades do novo release, respeitando- se as variáveis tempo, requisitos, qualidade e custo. Normalmente, serão utilizadas múltiplas Sprints para a evolução incremental do sistema. Os passos dessa fase:
  32. 32. 31 o Reunião de Planejamento da Sprint a fim de definir as atividades a serem incluídas na iteração corrente. o Reuniões Diárias com o TS para revisar o andamento do projeto; o Revisão e ajustes nos requisitos do projeto; o Sprints iterativos até que se tenha “Software Pronto”. “Sof Nesta fase, é importante que as definições da Sprint, comentadas no item “3.2.2 Eventos” desse capítulo, sejam plenamente seguidas pelo TS. e Postgame: • Fechamento – Entrega e empacotamento do “Software Pronto”. Preparação do produto desenvolvido para a entrega. Documentações, testes, materiais de desenvolvido treinamento e marketing são artefatos típicos dessa fase. A figura 7 mostra de o fluxo Scrum de maneira ilustrativa. Figura 7 – Fluxo do Scrum Fonte: inspirada em KNIBERG, 2007
  33. 33. 32 O framework foi concebido de maneira simples e aberto, permitindo que características sejam adicionadas sem que a filosofia básica do Scrum seja alterada. Nesse capítulo, buscou-se apresentar uma visão para o entendimento do assunto abordado, porém dificilmente seria possível esgotar o assunto, diante das mais diversas possibilidades da aplicação da metodologia. É possível concluir que Scrum é uma abordagem baseada na flexibilidade, adaptabilidade e produtividade, com ênfase no gerenciamento do projeto.
  34. 34. 33 4 MODELO MPS.BR As atividades das empresas ocorrem através de processos. Conforme Pádua (2007), processos são um conjunto de ações e atividades inter-relacionadas, realizadas para obter um conjunto especificado de produtos, resultados ou serviços. Baseados em boas práticas de execução, surgiram diversos modelos de processos, todos visando o aumento da eficiência e eficácia nas atividades das organizações. O Modelo de Melhoria do Processo de Software Brasileiro – MPS.BR, é um exemplo, e por ser uma importante iniciativa brasileira na área de qualidade do desenvolvimento de software, é objeto de estudo desse trabalho. 4.1 Introdução ao Modelo MPS.BR O modelo MPS.BR é uma proposta brasileira, para micro, pequenas e médias empresas, de um modelo de maturidade de processos de desenvolvimento do software Brasileiro (Associação para Promoção da Excelência do Software Brasileiro – SOFTEX, 2009a). O viés do MPS.BR são os processos, a qualificação desses reflete na qualidade do produto, além disso proporciona: diminuição de retrabalho, maior produtividade, redução do tempo para atender às necessidades de negócio, maior competitividade, maior precisão nas estimativas, entre outros. O MPS.BR é um programa coordenado pela Associação para Promoção da Excelência do Software Brasileiro – SOFTEX que tem apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). O modelo está documentado através de guias, que auxiliam no entendimento e implementação do mesmo. Além do Guia Geral, que expõe uma descrição do modelo e detalha o Modelo de Referência MR-MPS, há também os guias de Avaliação, Aquisição e os guias de Implementação, que divididos por níveis, formam o conjunto de documentos do modelo MPS. Os componentes do modelo podem ser observados na figura 8.
  35. 35. 34 Figura 8 – Modelo MPS.BR Fonte: SOFTEX, 2009. O Modelo de Referência MR-MPS refere-se aos requisitos que devem ser atendidos MR pelas organizações que se submeterão a avaliação ou desejam desenvolver boas-práticas. Nele bo são indicados os níveis de maturidade, processos e seus atributos. O MR-MPS tem sua base MR MPS técnica formada pelas normas ISO/IEC 12207, ISO/IEC 15504 e modelo CMMI-DEV. CMMI 4.2 Base técnica do Modelo MPS.BR A ISO/IEC 12207 (International Organization for Standardization/International ( nization Electrotechnical Commission estabelece uma arquitetura comum para o ciclo de vida de Commission) processos. A norma contém processos, atividades e tarefas a serem aplicadas durante o fornecimento, aquisição, desenvolvimento, operação, manutenção de produtos de software. As normas ISO possuem reconhecimento internacional e, portanto, identificação de qualidade, quando o assunto é exportação. A ISO12207, em especial, teve grande aceitação, servindo de base para diversas normas e modelos que surgiram posteriormente. A organização da ISO12207 permite que processos de apoio possam ser combinados e executados junto a outros, a qualquer momento (SOFTEX, 2009a, p.14; International Organization for SOFTEX, Standardization – ISO, 2010a) ). Já a ISO/IEC 15504, também conhecida por SPICE (Software Process Improvement (Software and Capability Etermination), presta se à realização de avaliações de processos de software ), presta-se com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de
  36. 36. 35 uma unidade organizacional. Um dos importantes conceitos introduzido por essa norma foi o de “capacidades”. Tal capacidade tem a finalidade de indicar como um processo atende determinada classe de requisitos. Quanto à dimensão dos processos, estes são agrupados em cinco categorias: cliente-fornecedor (impactam na relação cliente-fornecedor), engenharia (implementam ou mantém um sistema ou produto e sua documentação), suporte (processos que podem ser empregados por outros), gerência (práticas genéricas usadas por quem gerenciam projetos ou processos), empresa (objetivos do negócio). Assim, pode ocorrer de uma empresa possuir maiores capacidades em algumas categorias ante outras, permitido que a empresa possa buscar por sua certificação enquanto aprimoram outros processos que precisam de melhorias (SOFTEX, 2009a, p. 14-15; ISO, 2010b). E o CMMI-DEV (Software Capability Maturity Model for Development) é a versão do CMMI dirigido à melhoria do processo de desenvolvimento de produtos e serviços. Foi criado pelo SEI (Software Engineering Institute) da CMU (Carnegie Mellon University). O CMMI é um modelo de referência com as melhores práticas para a maturidade dos processos das organizações. Koscianski (2006) comenta que o objetivo do CMMI é: servir de guia para melhoria de processos na organização e das habilidades dos profissionais em gerenciar o desenvolvimento, aquisição e manutenção de produtos ou serviços. Desta maneira, espera-se que a organização construa software com mais qualidade de maneira eficiente. No modelo CMMI quatro áreas de conhecimento estão presentes: Engenharia de Sistemas, Engenharia de Software, Desenvolvimento e Integração de Produtos e Processos e Fontes de Aquisição. O modelo apresenta-se através de duas representações: • Representação por Estágios: Organiza as áreas de processo em níveis de maturidade, de 1 a 5. • Representação Contínua: Apresenta níveis de capacitação, de 0 a 5. As áreas de processo são agrupadas por categorias afins. O modelo CMMI é complexo e caro, e a idéia de tê-lo como base no MPS.BR é trazer para o modelo brasileiro, as boas práticas de gerenciamento de processos, tornando-os mais fáceis e baratos.
  37. 37. 36 4.3 Estrutura do MR-MPS.BR MPS.BR O Modelo de Referência do MPS.BR (MR-MPS.BR) define a maturidade dos (MR MPS.BR) processos de desenvolvimento de software através de níveis de maturidade, que por sua vez to são formados por conjuntos de processos, sendo que há um propósito e um conjunto de resultados esperados para cada um dos 21 processos do MR-MPS.BR (SOFTEX, 2009a) MR 2009a). Para cada conjunto de processos, novas capacidades de processos são exigidas da processos, organização (seguindo a proposta da ISO 15504), sendo estas capacidades mensuradas através 15504), de atributos de processos (AP) e resultados esperados de atributos de processo (RAP). A (RAP) figura 9 mostra a estrutura do Modelo de Referência. tura Figura 9 – Estrutura do MR-MPS.BR Fonte: SOFTEX, 2009a 4.3.1 Níveis de maturidade Os níveis de maturidade foram definidos de maneira que haja um amadurecimento gradual dos processos, eles caracterizam estágios de melhoria da implementação de processos melhoria na organização. São sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A divisão em sete estágios tem como objetivo permitir uma implementação e avaliação mais gradual e aderente, em comparação ao CMMI que possui cinco estágios. A escala de maturidade inicia no nível G e progride até o nível A, conforme tabela 2. 2
  38. 38. 37 Tabela 2 – Níveis de Maturidade e Processos do Modelo de Referência do MPS.BR Nível Processo A - Em Otimização B - Gerenciamento Quantitativo Gerência de Projetos – GPR (evolução) Gerência de Riscos – GRI C – Definido Desenvolvimento para Reutilização – DRU Gerência de Decisões – GDE Verificação – VER Validação – VAL D - Largamente Definido Projeto e Construção do Produto – PCP Integração do Produto – ITP Desenvolvimento de Requisitos – DRE Gerência de Projetos – GPR (evolução) Gerência de Reutilização – GRU E - Parcialmente Definido Gerência de Recursos Humanos – GRH Definição do Processo Organizacional – DFP Avaliação e Melhoria do Processo Organizacional – AMP Medição – MED Garantia da Qualidade – GQA F – Gerenciado Gerência de Portfólio de Projetos – GPP Gerência de Configuração – GCO Aquisição – AQU Gerência de Requisitos – GRE G - Parcialmente Gerenciado Gerência de Projetos – GPR Fonte: SOFTEX, 2009a 4.3.1.1 Processos Para cada um dos sete níveis foram atribuídos perfis de processos que serão o foco de melhoria da organização. Atinge-se um determinado nível de maturidade quando o propósito e os resultados esperados dos processos do nível são atendidos. Segundo Diniz (2009a) alguns processos do MPS.BR afetam o desenvolvimento, no sentido de dar-lhe transparência, outros afetam a gerenciabilidade do desenvolvimento. Por consequência, reduzem-se os riscos e aumenta-se a produtividade. Ao passo que os níveis de maturidade são alcançados, os processos implementados em cada nível também amadurecem (conforme tabela 2).
  39. 39. 38 No modelo descrito no Guia Geral do MPS.BR (2009a, p. 16), os processos são formados por propósitos e resultados. Os propósitos descrevem os objetivos gerais da execução dos processos, enquanto que os resultados esperados dos processos determinam os resultados que devem ser obtidos com a implementação do processo, ou seja, o efetivo alcance dos propósitos. 4.3.1.2 Capacidades de processos A implementação do conjunto de processos de cada um dos níveis de maturidade do modelo é comprovada através da aquisição de determinadas capacidades. A capacidade do processo caracteriza a habilidade do processo de atingir os objetivos de negócio, assim indica o grau de refinamento com que os atributos de processos (AP) são executados e a comprovação do sucesso da implementação destas capacidades é feita através da demonstração de resultados esperados destes atributos. A tabela 3 mostra os níveis de capacidade do MPS.BR: Tabela 3 - Atributos de Processo do MPS.BR Código Descrição AP 1.1 O processo é executado AP 2.1 O processo é gerenciado AP 2.2 Os produtos de trabalho do processo são gerenciados AP 3.1 O processo é definido AP 3.2 O processo é implementado AP 4.1 O processo é medido AP 4.2 O processo é controlado AP 5.1 O processo é objeto de melhorias e inovações AP 5.2 O processo é otimizado continuamente Fonte: SOFTEX, 2010a, 17-21. Ao longo deste trabalho os processos de Gerência e Desenvolvimento de Requisitos serão descritos, assim como seus propósitos e resultados esperados. O processo de Gerência de Requisitos está incluso no nível G, enquanto que o processo de Desenvolvimento de Requisitos está no nível D.
  40. 40. 39 Os níveis, além de graduais, são acumulativos, e isto implica que a organização, ao evoluir de nível, deverá manter as capacidades adquiridas nos níveis anteriores. O modelo descreve nove atributos de processo, e seus respectivos resultados esperados de atributo de processo (RAP), sendo que destes, dois estão presentes no nível G e cinco no nível D de cinco maturidade do MPS.BR. A figura 10 mostra a evolução dos AP em relação aos níveis, do nível G ao nível D (SOFTEX, 2009a, p. 16-17). 16 Figura 10 – Evolução dos AP em relação aos níveis G, F, E e D do MPS.BR Fonte: SOFTEX, 2009a, p. 22. O detalhamento de cada AP dos níveis G ao D está descrito nos Anexos C D, E, F e G C, deste trabalho. 4.4 Processo de Gerência de Requisitos O processo Gerência de Requisitos (GRE) consta no nível de maturidade G do modelo MPS.BR, que é o primeiro nível do modelo e por isso, tem um grande impacto para a organização. Uma mudança de cultura organizacional e uma definição do conceito acerca do que é “projeto” para a organização são implantados e caracterizam um grande desafio para a organização, o que pode determinar o sucesso ou insucesso da implementação do modelo determinar (SOFTEX, 2009b, p. 6). Para esse processo os Atributos de Processos (capacidades) esperados são: e • O processo é executado (RAP 1) e;
  41. 41. 40 • O processo é gerenciado (RAP 2, RAP 3, RAP 4, RAP 5, RAP 6, RAP 7, RAP 8, RAP 9 e RAP 10). 4.4.1 Processo GRE – Propósito O processo GRE tem por objetivo o gerenciamento dos requisitos do produto e dos componentes do produto do projeto, além da identificação de inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto (SOFTEX, 2009a, p. 28). O principal objetivo deste processo é o controle da evolução de todos os requisitos recebidos ou gerados pelo projeto, incluindo requisitos funcionais, não funcionais e os requisitos impostos ao projeto pela organização (SOFTEX, 2009b, p. 18). Neste processo, passos são definidos para assegurar que o conjunto de requisitos acordados (1) é gerenciado e (2) fornece apoio às necessidades de planejamento e execução do projeto. Estabelece que quando requisitos são recebidos, antes de serem incorporados ao escopo do projeto, devem ser revisados e um compromisso entre as partes interessadas é firmado. Documentar todas as mudanças nos requisitos, garantir a rastreabilidade bidirecional entre os requisitos e os produtos, além de identificar inconsistências entre requisitos, planos do projeto e produtos de trabalho do projeto também fazem parte das atribuições do Processo de Gerência de Requisitos. 4.4.2 Processo GRE – Resultados Esperados Segundo a SOFTEX (2009b, p. 20), esperam-se cinco resultados da implementação do processo GRE, a saber: GRE 1 – Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores responsáveis de requisitos, utilizando critérios objetivos. Ou seja, é preciso garantir que os requisitos estejam claramente definidos, comprovados através de um documento de requisitos – que pode ter o formato que melhor atender as necessidades da organização. Após a
  42. 42. 41 identificação dos requisitos, eles precisam ser avaliados, tanto pela equipe técnica da organização quanto pelo cliente, com base em critérios que garantam que os requisitos propostos atendem às necessidades e expectativas do cliente e dos usuários. Um registro de aceite dos requisitos aprovados, obtido pelos fornecedores de requisitos será um marco do projeto, a partir do qual todas as mudanças nos requisitos deverão ser tratadas no interesse de minimizar o impacto dessas mudanças no projeto em termos de escopo, estimativas e cronograma. A cada mudança nos requisitos aprovada, deve-se prover uma avaliação e registro de aceite da mudança aprovada. GRE 2 – O Comprometimento da equipe técnica com os requisitos aprovados é obtido. Os requisitos aprovados pelos critérios estabelecido no GRE1 deverão obter o comprometimento da equipe técnica. Para formalizar que toda a equipe técnica tem conhecimento e aprovam os requisitos, um documento deve ser registrado, por exemplo, uma ata de reunião, e-mail ou algum outro mecanismo. A cada mudança registrada nos requisitos, um novo comprometimento da equipe deve ser obtido (SOFTEX, 2009b, p. 21). GRE 3 – A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida. Obter esse resultado significa que é possível rastrear a dependência entre os requisitos e o produto de trabalho, ou seja, quais artefatos são de quais produtos. Desta forma, facilitando a avaliação do impacto das mudanças nos requisitos, por exemplo, nas estimativas, nos produtos ou tarefas do projeto (SOFTEX, 2009b, p. 21). GRE 4 – Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos. O que resulta no estabelecimento de algum mecanismo para identificação de inconsistências entre os requisitos e os demais elementos do projeto. Todas as inconsistências identificadas devem ser registradas e ações corretivas deverão ser tomadas a fim de resolvê-las, sendo que estas ações deverão ser acompanhadas até que as inconsistências sejam resolvidas (SOFTEX, 2009b, p. 21-22). GRE 5 – Mudanças nos requisitos são gerenciadas ao longo do projeto. Como é raro não haver mudanças nos requisitos ao longo do projeto, espera-se que a organização realize o gerenciamento das mudanças que venham a ocorrer. As mudanças devem ser
  43. 43. 42 registradas, juntamente com um histórico das decisões tomadas, que deverão ser tomadas com base na análise do impacto da mudança no projeto (SOFTEX, 2009b, p. 22). Estes são os cinco resultados esperados do propósito do processo de Gerência de Requisitos, que juntamente com o processo de Desenvolvimento de Requisitos são os processos que atuam na gestão dos requisitos no MPS.BR, A seguir, faz-se uma análise do processo Desenvolvimento de Requisitos, seu propósito e resultados esperados. 4.5 Processo de Desenvolvimento de Requisitos O processo de Desenvolvimento de Requisitos (DRE) está presente no nível D de maturidade do MPS.BR. Evoluir para o nível D implica na definição de processos geralmente mencionados como sendo relacionados à engenharia de requisitos propriamente dita. Neste nível, cinco novos processos são implementados, que incrementam a capacidade de definição dos processos já alcançada no nível E, e que inclui todos os processos que pertencem aos níveis G e F do MPS.BR. A SOFTEX (2009c, p.6-7) indica que os processos do nível D sejam implementados de forma iterativa e alinhados ao ciclo de vida definido do produto, indicando inclusive uma possível sequência de execução dentro do processo de desenvolvimento, sendo: Desenvolvimento de Requisitos (DRE), Projeto e Construção do Produto (PCP), Integração do Produto (ITP), Verificação (VER) e Validação (VAR). Detalhes do processo DRE, objeto de estudo deste trabalho, são apresentados a seguir. Para este processo os Atributos de Processos (capacidades) esperados são: • O processo é executado (RAP 1); • O processo é gerenciado (RAP 2, RAP 3, RAP 4, RAP 5, RAP 6, RAP 7, RAP 8, RAP 9, RAP 10); • Os produtos de trabalho do processo são gerenciados (RAP 11, RAP 12, RAP13, RAP 14);
  44. 44. 43 • O processo é definido (RAP 15, RAP16, RAP 17, RAP 18) e; • O processo está implementado (RAP 19, RAP 20, RAP 21, RAP 22) 4.5.1 Processo DRE – Propósito Ao implementar o processo de Desenvolvimento de Requisitos, a organização terá como propósito definir os requisitos do cliente, do produto e dos componentes do produto (SOFTEX, 2009a, p. 38), atendendo assim a necessidade de todos os envolvidos no projeto. O levantamento de requisitos e seu gerenciamento, além do refinamento dos mesmos, a descrição em termos técnicos, dos cenários e conceitos operacionais requeridos são elaborados em um nível de detalhes que permite a realização de projetos técnicos para a resolução do problema em questão (SOFTEX, 2009c, p.7). 4.5.2 Processo DRE – Resultados Esperados Os requisitos do cliente, do produto e dos componentes do produto deverão ser analisados, validados e gerenciados ao longo do ciclo de desenvolvimento ou de manutenção do produto, o que faz com que os resultados esperados do processo DRE estejam relacionados aos resultados esperados dos processos PCP, GRE, VER e VAL, por serem produtos requeridos para sua execução ou por terem uma interface com o processo propriamente dito (SOFTEX, 2009c, p. 7). O processo DRE possui oito resultados esperados, como segue: DRE 1 – As necessidades, expectativas e restrições do cliente, tanto do produto quanto de suas interfaces, são identificadas. Segundo a SOFTEX (2009c, p. 10), para se alcançar este resultado, é preciso utilizar algum método adequado para identificar as necessidades, expectativas e restrições do cliente, também comenta algumas técnicas de elicitação de requisitos, como: entrevistas; questionários; construção de cenários operacionais e análise de tarefas do usuário final; protótipos e modelos; técnicas facilitadoras de especificação de aplicações (como, por exemplo, JAD); casos de uso; brainstorming; observação de produtos e ambientes existentes; análise de casos de negócio; estudo de fontes
  45. 45. 44 de informação como documentos, padrões ou especificações; etnografia; QFD (Quality Function Deployment) e engenharia reversa (para sistemas legados); e estórias de usuários (Metodologias ágeis); DRE 2 – Um conjunto definido de requisitos do cliente é especificado a partir das necessidades, expectativas e restrições identificadas. As necessidades, expectativas e restrições identificadas, deverão ser transformadas em requisitos do cliente (SOFTEX, 2009c, p. 11); DRE 3 – Um conjunto de requisitos funcionais e não funcionais, do produto e dos componentes do produto que descrevem a solução do problema a ser resolvido, é definido e mantido a partir dos requisitos do cliente. Ou seja, o resultado alcançado deve ser a consolidação das necessidades, expectativas e restrições do cliente na forma de requisitos do produto e dos componentes do produto. A SOFTEX (2009c, p. 11-12), destaca que definir os requisitos funcionais envolve analisar os requisitos do cliente, identificando as funções que são necessárias ao produto. Os requisitos funcionais descrevem as funções ou serviços que são esperados do sistema que será gerado. Os requisitos não funcionais são requisitos que impõe condições ou qualidades que são específicas que o produto e/ou seus componentes devem atender. DRE 4 – Os requisitos funcionais e não funcionais de cada componente do produto são refinados, elaborados e alocados. Para se alcançar este resultado implica em derivar requisitos funcionais e não funcionais que resultem de decisões de projeto; alocar requisitos funcionais e não funcionais e restrições para cada um dos componentes do produto; e estabelecer os relacionamentos entre os requisitos do cliente e os requisitos funcionais e não funcionais de cada um dos componentes do produto, de acordo com o processo de Gerência de Requisitos. É necessário comprovar que o conjunto de requisitos funcionais e não funcionais foi refinado, detalhado e documentado durante o ciclo de vida do desenvolvimento do produto e de seus componentes (SOFTEX, 2009c, p. 12); DRE 5 – Interfaces internas e externas do produto e de cada componente do produto são definidas. Isso será útil para projetar e construir os componentes do produto. Geralmente as definições são quanto aos tipos e formatos de dados de entrada e saída entre os
  46. 46. 45 componentes, especificações de protocolo de comunicação, entre outros (SOFTEX, 2009c. p. 13); DRE 6 – Conceitos operacionais e cenários são desenvolvidos. Os cenários podem ser modelados por UML (Unified Modeling Language), no qual o cenário é uma seqüência específica de ações que ilustra o comportamento de um caso de uso. Para se alcançar este resultado, é necessário definir o ambiente de operação do produto, seus limites e restrições; também é necessário elaborar um conceito operacional detalhado, do produto e seus componentes, que defina a interação do produto, do usuário final e do ambiente, de maneira a satisfazer as necessidades de operação, manutenção e apoio; e revisar os conceitos operacionais e cenários para refinar e descobrir novos requisitos (SOFTEX, 2009c, p. 13-14); DRE 7 – Os requisitos são analisados, usando critérios definidos, para balancear as necessidades dos interessados com as restrições existentes. Isso determinará se os requisitos, analisados em conjunto com os cenários e conceitos operacionais, são necessários, corretos, testáveis e suficientes para atingir os objetivos e requisitos do cliente (SOFTEX, 2009c, p. 14); DRE 8 – Os requisitos são validados. Este resultado visa garantir que os requisitos sejam validados através de técnicas adequadas, o que garantirá o desempenho do produto no seu ambiente alvo, além de permitir que problemas sejam encontrados, evitando retrabalho e custos (SOFTEX, 2009c, p. 14-15); Modelos para Maturidade de Melhoria do Processo Software, como o MPS.BR, são hoje referências no mercado como boas práticas fornecidas de como o processo, e consequentemente, o produto de software, podem ser melhorados e avaliados. Ao finalizar a descrição dos resultados esperados dos processos relacionados a requisitos, do MPS.BR, em conjunto com as informações adquiridas sobre requisitos (capítulo 02) e Scrum (capítulo 03), possível propor o mapeamento e alinhamento destes, conforme será apresentado no capítulo a seguir.
  47. 47. 46 5 METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR Organizações que buscam a melhoria de seus processos através de modelos como o MPS.BR e que acreditam que a introdução de conceitos ágeis, como o Scrum, em seus processos é uma alternativa capaz de promover a melhoria de qualidade dos seus produtos, e consequentemente, aumento da competitividade no mercado (SZIMANZKI, 2009), podem necessitar de orientação que demonstre a possibilidade da aplicação prática conjunta de MPS.BR e Scrum. Para que a organização atinja maturidade e agilidade através do MPS.BR e Scrum, é necessário que ambos modelos possam ser realizados em conjunto e que suas práticas e objetivos sejam satisfeitas. Assim, o presente capítulo apresenta o mapeamento MPS.BR e Scrum. Pretende-se atender os resultados esperados dos processos de Gerência e Desenvolvimento de Requisitos do MPS.BR e satisfazer todos os preceitos da prática do Scrum. 5.1 Mapeamento entre os processos GRE e DRE com Scrum Para analisar se as práticas encontradas no Scrum satisfazem cada um dos resultados esperados dos processos de Gerência e Desenvolvimento de Requisitos do MPS.BR, foram definidos os critérios apresentados na tabela 4. Os critérios demonstram o quanto uma prática Scrum pode estar presente em um resultado de processo, como: é possível evidenciar (Satisfeito), evidencia-se em parte (Parcialmente Satisfeito) e não é possível evidenciar que a prática Scrum pode atender um resultado de processo. Tabela 4 – Critérios de análise do uso conjunto das metodologias Classificação Critérios Não Satisfeito Não há evidências da prática na metodologia Há evidências da prática na metodologia, embora a Parcialmente Satisfeito prática não esteja plenamente atendida. Satisfeito A prática está totalmente atendida na Metodologia. Fonte: inspirada em SZIMANSKI, 2009.
  48. 48. 47 Para cada um dos processos, foi realizada uma análise detalhada dos resultados esperados em relação às práticas encontradas no Scrum, classificando cada resultado esperado de acordo com os critérios estabelecidos na tabela 4. Abordagem similar já foi utilizada e apresentada à comunidade científica, como na obra “Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G”, de Szimanski (2009). No entanto, o foco de pesquisa foram os processos do nível G e o que se propõe é o mapeamento entre os processos GRE e DRE do MPS. As tabelas 5 e 6 ilustram a ordem de mapeamento, o processo MPS e o resultado esperado, a classificação de acordo com os critérios de análise e um resumo das práticas Scrum que podem atender ao resultado esperado. Após o resumo do mapeamento, é apresentada uma descrição para cada alinhamento entre resultado esperado e práticas (MAP). O processo de Gerência de Requisitos é composto por cinco resultados esperados, já detalhados no capítulo 4, de forma correspondente, a tabela a seguir apresenta cinco mapeamentos entre este processo com as práticas Scrum (tabela 5). Tabela 5 – Resumo do mapeamento entre o processo GRE do MPS.BR e Scrum MPS.BR – Nível G Mapea- Scrum mento Gerência de Requisitos (GRE) Abrev. Resultados Classificação Resumo das Práticas Elaboração do Backlog do Produto, Backlog da Os requisitos são entendidos, Versão para Entrega e avaliados e aceitos junto aos MAP 1 GRE 1 SATISFEITO Backlog da Sprint, fornecedores de requisitos, priorizados por Business utilizando critérios objetivos Value e Retorno do Investimento Planejamento da Versão O comprometimento da equipe para Entrega e geração do MAP 2 GRE 2 técnica com os requisitos SATISFEITO Backlog do Produto para aprovados é obtido a Versão A rastreabilidade bidirecional entre os requisitos e os NÃO Prática não MAP 3 GRE 3 produtos de trabalho é SATISFEITO mencionada no Scrum estabelecida e mantida Revisões em planos e produtos de trabalho do projeto são Reunião Diária, MAP 4 GRE 4 realizadas visando a identificar SATISFEITO Revisão e Retrospectiva e corrigir inconsistências em da Sprint relação aos requisitos MAP 5 GRE 5 Mudanças nos requisitos são SATISFEITO Planejamento da Versão
  49. 49. 48 gerenciadas ao longo do para Entrega, projeto Reunião Diária, Revisão e Retrospectiva da Sprint Fonte: Autor. O resumo da análise do mapeamento do processo de Desenvolvimento de Requisitos é apresentado na tabela 6. Esse processo é composto por oito mapeamentos, que correspondem aos resultados esperados. Tabela 6 – Resumo do mapeamento entre o processo DRE do MPS.BR e Scrum MPS.BR – Nível D Mapea- Scrum mento Desenvolvimento de Requisitos (DRE) Abrev. Resultados Classificação Resumo das Práticas Elaboração do Backlog As necessidades, expectativas do Produto, e restrições do cliente, tanto do Reunião de Planejamento MAP 6 DRE 1 SATISFEITO produto quanto de suas da Versão para Entrega e interfaces, são identificadas Reunião de Planejamento da Sprint Um conjunto definido de Backlog do Produto, requisitos do cliente é Backlog do Produto para MAP 7 DRE 2 especificado a partir das SATISFEITO a Versão e necessidades, expectativas e Backlog da Sprint restrições identificadas Um conjunto de requisitos funcionais e não-funcionais, do produto e dos componentes do produto que descrevem a Reunião de MAP 8 DRE 3 SATISFEITO solução do problema a ser Planejamento da Sprint resolvido, é definido e mantido a partir dos requisitos do cliente Os requisitos funcionais e não- funcionais de cada MAP 9 DRE 4 componente do produto são SATISFEITO Backlog da Sprint refinados, elaborados e alocados Interfaces internas e externas Backlog do Produto, do produto e de cada PARCIALMENTE Backlog do Produto para MAP 10 DRE 5 componente do produto são SATISFEITO a Versão e Backlog da definidas Sprint Reuniões de Conceitos operacionais e PARCIALMENTE MAP 11 DRE 6 Planejamento da Versão cenários são desenvolvidos SATISFEITO para Entrega e da Sprint Os requisitos são analisados, Reuniões de usando critérios definidos, MAP 12 DRE 7 SATISFEITO Planejamento da Versão para balancear as necessidades para Entrega e da Sprint dos interessados com as
  50. 50. 49 restrições existentes Conceito de MAP 13 DRE 8 Os requisitos são validados SATISFEITO “Software Pronto” Fonte: Autor. Uma descrição detalhada dos mapeamentos gerados entre os processos de Gerência de Requisitos e Desenvolvimento de Requisitos do MPS.BR com a prática da metodologia ágil Scrum é apresentada a seguir, conforme ilustrado nas tabelas 5 e 6: MAP 1 – No Scrum os requisitos são entendidos diretamente com os clientes, cabendo ao Product Owner (PO) identificar tanto os requisitos como os fornecedores de requisitos. O PO deve avaliar os requisitos, obtendo como resultado o Backlog do Produto (BP). O PO deve usar como critério a priorização por Business Value (BV) e Retorno do Investimento (ROI). O mesmo BP é refinado e os requisitos são novamente analisados quando o Time Scrum (TS) define o Backlog do Produto para a Versão (BPV) e o Backlog da Sprint (BS). Para registrar toda a comunicação realizada, artefatos como estórias de usuário, Atas, BP, Plano de Execução do Projeto, podem ser gerados. Cabe ressaltar que o MPS.BR não indica o formato dos artefatos que devem ser gerados, ficando a critério da organização. Portanto o Scrum atende ao resultado esperado GRE 1. MAP 2 – Scrum atende o resultado esperado GRE 2. Através da Reunião de Planejamento da Versão para Entrega (RPVE), PO e ScrumMaster (SM) trabalham para que todo o TS entre em acordo sobre o entendimento dos requisitos, gerando planos e metas que formarão o BPV. Desta forma, a equipe técnica está se comprometendo com requisitos aprovados a partir de critérios estabelecidos conforme GRE 1. MAP 3 – Scrum não atende a GRE 3, a rastreabilidade bidirecional entre os requisitos e os produtos de trabalho não é mencionada na prática Scrum. Uma possível solução será abordada mais adiante, onde se apresentam sugestões para cobrir incompatibilidades com o MPS.BR. Verificar GAP 1, no tópico “5.3 Estendendo o Scrum”, neste capítulo. MAP 4 – O resultado esperado GRE 4 é atendido pelo Scrum. O objetivo deste resultado esperado, a necessidade de revisões em planos e produtos de trabalho do projeto, realizadas visando à identificação e correção de inconsistências em relação aos requisitos é uma das maiores evidências na prática Scrum. As Reuniões Diárias, a Reunião de Revisão da

×