UTILIZAÇÃO DE METODOLOGIA SCRUM PARA OBTENÇÃO DE NÍVEL F DO MPS.BR 1 Arthur Mauricio da Silva, 1 Maria Aparecida Denardi 1Curso de Sistemas de Informação - UNIPAR - Universidade Paranaense. CEP 85801-180 Cascavel PR - Brazil Arthurmauricio6@gmail.com.br, maria@unipar.br Resumo. Esse artigo apresenta o trabalho realizado na Tecinco Tecnologia em Informática corporativa propondo a utilização da metodologia Scrum em processos internos para a obtenção de nível F no MPS.BR Melhoria de processos de software brasileiro, visando a utilização dos métodos ágeis Scrum afim de obter a maturidade necessária para o avanço do nível F afim de constituir aprendizado para resultados positivos nos projetos. Abstract.
1 INTRODUÇÃO Empresas e organizações, tanto de pequeno, médio e de grande porte necessitam de produtos funcionais, com qualidade e com o mínimo de erros possíveis, devido a esse grande crescimento das necessidades as empresas de software para atender essa crescente necessitam que em seus projetos de desenvolvimento, maior agilidade, diminuição de erros e conflitos, tanto em prazos quanto em entregas e diminuição das taxas de erros existentes hoje em um projeto de desenvolvimento. Devido a essa grande demanda e a preocupação das empresas em manter seus níveis de qualidade e da mesma forma atender as necessidades de seus clientes, que hoje a grande maioria está adotando metodologias de gerenciamento ágil, que possuem menos burocracia pôr se propõem em atender a demanda focando sempre a qualidade e rapidez. Baseado nisso, o estudo realizado propõe a utilização de uma metodologia ágil com um modelo de maturidade de software visando atender as necessidades de ambos. O modelo de maturidade é o MPS.BR - Melhoria de Processo do Software Brasileiro, realizando a utilização da metodologia ágil Scrum em paralelo com o modelo de maturidade adotado. 1.1 - Motivações do trabalho de pesquisa O mercado industrial de desenvolvimento de softwares busca tanto dentro quanto fora do Brasil o aperfeiçoamento do processo de elaboração e desenvolvimento dos softwares, que se traduz em vários níveis de maturidade e de melhoria dos softwares. No Brasil além das empresas seguirem o modelo de maturidade denominado Capability Maturity Model Integration (CMMI), existe o emprego de Processos do Software Brasileiro (MPS.BR), que é um programa para o aprimoramento do processo do software brasileiro. Mencionado programa encontra-se em desenvolvimento desde dezembro de 2003, sob a coordenação da Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). As empresas brasileiras buscam implementações práticas para desenvolvimento e manutenção de produto. O presente estudo se presta a organizar os estudos sobre o aludido programa, a fim de unir a metodologia ágil Scrum com modelo de maturidade MPS.BR, para buscar um avanço de nível dentro deste padrão.
1.2 Metodologias de desenvolvimento do trabalho de pesquisa Para o desenvolvimento do projeto foram utilizadas pesquisas bibliográficas buscando informações em livros, artigos, revistas e outros meios. Além disso, foi realizada uma pesquisa de campo, através de observação in loco e do emprego de questionário, na empresa Tecinco Tecnologia em Informática corporativa, fundada em 1994 que atende ao ramos de gestão comercial, concessionárias de veículos, auto- centers e ao ramos de transporte e logística, que hoje já possui nível G no MPS.BR, para realizar o levantamento dos dados referentes às principais causas de atraso no desenvolvimento de softwares. Tais dados foram tabulados e, através de seus resultados, foi possível evidenciar a metodologia mais adequada para a obtenção de nível dentro da padronização de Melhoria de Processos do Software Brasileiro (MPS.BR). 2 - METODOLOGIA SCRUM Criado por Ken Schwabber e Jeff Suttherland, o Scrum é uma metodologia de gerenciamento de projeto ágil, é uma metodologia iterativa e adaptativa, de acordo com o cenário que a mesma será aplicada, geralmente utilizada para gerenciar projetos completos, que tem como uma das suas principais características a entrega constante de software funcionando ao cliente e um período de tempo relativamente curto. A implantação da metodologia Scrum, necessita que seus envolvidos possuam como características: responsabilidade, transparência, honestidade, comprometimento e auto-organização. Através da implementação dessas características, a metodologia Scrum salienta que é possível realizar entregas incrementais totalmente funcionais. Na metodologia Scrum não existe gerente de projetos, a organização da equipe é realizada por todos, e a equipe é chamada de time, os papeis são: - Product Owner - Team - Scrum Master
O Product Owner tem como função, definir a visão do produto, é quem representa o cliente para o Scrum master, é necessário que entenda do negocio que está sendo realizado, define qual o objetivo do Sprint, elege as prioridades e gerencia o backlog. O time é composto das pessoas responsáveis pela entrega do produto a ser desenvolvido. Todos os membros devem ser multifuncionais, auto-organizados e auto-gerenciados, devem possuir comprometimento igual para um objetivo comum. O time sempre será uma equipe pequena, de cinco até dez membros. O Scrum master tem como responsabilidades o conhecimento do processo a ser realizado, tratar os impedimentos encontrados pelo time no decorrer do Sprint, deve proteger o time, a fim de manter o mesmo sempre focado, evitando desperdício de tempo em tarefas não direcionadas ao mesmo, da mesma forma que deve manter o time com o pé no chão, evitando excesso de otimismo. Auxilia o Product Owner a maximizar o retorno do investimento feito para obtenção do produto final. O ciclo de vida do Scrum é bem definido, dividindo-se em fases, é realizada a preparação e definição dos recursos necessários, segue as fases do ciclo: - Product Backlog: Onde é definido ainda sem prioridade e complexidade o que deverá ser feito, onde é realizada a arquitetura de negócios e arquitetura técnica, definindo o que é desejado pelo cliente. - Sprint Planning: É uma reunião de planejamento onde é analisado o Product Backlog e descartado os itens irrelevantes, reunião essa que contam com a presença do time e do Scrum Master. Após essa primeira reunião é realizada uma segunda reunião com a participação de todos os envolvidos onde é apresentado o Backlog re-organizado. - Sprint Planning II: É realizada uma nova reunião entre o Scrum Master e o time, onde é realizada a divisão das tarefas em tarefas menores e a definição da complexidade e prioridade de todas as tarefas e do comprometimento do time com o Sprint. Antigamente se adotavam Sprints Mensais, o que hoje já não é tão utilizado, sendo que atualmente utiliza-se Sprint de duas semanas (15 dias). Durante o Sprint é realizada uma reunião diária, chamada Daily Scrum, reunião essa realizada entre todos os envolvidos, no período da manhã ou no horário de almoço, duração máxima de 15 minutos, e normalmente é realizada em pé. Devem ser realizados sempre no mesmo local e horário, em uma sala equipada com quadro branco. Todos os comprometidos (Time e Scrum Master) devem participar e os envolvidos podem assistir porem estes não podem opinar e nessa reunião são realizadas três perguntas básicas ao time:
- O quê você fez ontem? - O quê você vai fazer hoje? - Quais os problema encontrados? Essa reunião tende a evitar atrasos no projeto, e baseado nas respostas o Scrum master pode ir tratar os impedimentos que surgirem. O prazo de entrega pode ser acompanhamento através do gráfico de Burn-Down Chart (Figura 1) que diz o quanto falta a ser feito até o fim do Sprint. Figura 1 Grafico de Burn Down Chart Fonte: Propria Após o fim do Sprint é realizado o Sprint Review, onde o Product Owner valida os itens entregues e verifica se o objetivo do Sprint foi atingido. Então é realizada a Restropective, reunião onde são levantados os problemas encontrados durante o Sprint a fim de melhorar para o próximo Sprint. Ressalta-se que todo esse processo é facilmente implementado em um quadro branco e as tarefas são descritas através de post-it colados no quadro. (Figura 2)
Figura 2 Quadro de Scrum ao final de um Sprint de cinco dias. Fonte: Própria. 3 MODELOS DE MATURIDADE Estrutura conceitual compostas por processos definidamente estabelecido, que uma organização se baseia e desenvolve ou adota um método sistemático e repetitivo a fim de atingir um estado futuro desejado, todo modelo de maturidade é descrito em níveis compostos de premissas a ser atingidas para se obter esse nível Os modelos de maturidade baseiam-se na premissa de que as pessoas, organizações, áreas funcionais, processos, etc. evoluem através de um processo de desenvolvimento ou crescimento em direção a uma maturidade mais avançada, atravessando um determinado número de estádios distintos. Estes modelos têm vindo a ser usados em várias áreas e têm sido usados para descrever uma larga variedade de fenômenos. (Burn 1994, King e Teo 1997) 3.1 - Modelo de maturidade MPS.BR O MPS.BR é um programa de Melhoria de Processos de Software Brasileiro, está em constante desenvolvimento desde dezembro de 2003 e é coordenado pela Associação para promoção da Excelência do Software Brasileiro ( SOFTEX). O foco principal do modelo de maturidade MPS.BR é a aplicação da mesma em micro, pequenas e médias empresas, que procuram obter melhorias significativas em seus processos de
software em 1 à 2 anos, empresas essas que possuem recursos limitados para investimentos em qualidade. O MPS.BR se baseia nos conceitos de maturidade e capacidade de processos para a avaliação e melhoria da qualidade e produtividade de produtos de software, esse modelo não define novos conceitos, apenas pega conceitos já existente e procura adequar os mesmos a realidade brasileira de desenvolvimento. O MPS.BR é divido em guias, sendo esses: - Guia Geral: Contem a descrição geral do MPS.BR e detalha o modelo de referencia(mr- MPS). - Guia de Aquisição: Descreve um processo de aquisição de software e serviços correlatos. - Guia de Avaliação: Descreve o processo e o método de avaliação MA.MPS. Dentro também do MPS.BR existe os níveis de maturidade que são obtidos através de avaliação dos processos realizados em um período, sendo os seguintes níveis: A Em Otimização B Gerenciado quantitativamente C Definido D Largamente Definido E Parcialmente Definido F Gerenciado G Parcialmente Gerenciado 3.1.1 - MPS.BR nível G Parcialmente Gerenciado Em 2010 foi obtido o nível G do modelo de maturidade MPS.BR pela empresa TECINCO Tecnologia de informática corporativa e a metodologia utilizada era em forma de cascata, baseando em normas descritas no PMBOK. Para a obtenção do nível G foram executados os seguintes processos exigidos para o mesmo. O GRP (Gerência de Projetos), que consiste em identificar, estabelecer e coordenar as atividades, recursos e tarefas que um processo necessita ter, e o GRE
(Gerência de Requisitos), que consiste em gerenciar todos os requisitos recebidos e gerados pelo projetos, além de identificar inconsistências entre os requisitos. 3.1.2 - MPS.BR nível F Gerenciado Para a obtenção do nível F, a empresa terá que colocar em pratica os seguintes processos propostos pelo MPS.BR, o AQU (Processo de Aquisição), que é obter um produto/serviço que satisfaça a necessidade expressa pelo cliente. O GCO (Gerência de configurações), que estabelece e mantém a integridade de todos os produtos e trabalhos de um processo ou projeto. O GQA (Garantia de Qualidade) que garanti que os produtos de trabalho e execução dos processos estão em conformidade com os planos e recursos predefinidos. O MED (Medição), que coleta e analisa os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos e o GPP ( Gerencia de Portfólio de Projetos) que tem como função iniciar e manter projetos que sejam necessários, suficientes e sustentáveis, de forma a atender os objetivos estratégicos da organização. 3.2 - Metodologia própria da empresa A metodologia utilizada atualmente é a de gerencia de projetos em forma de Cascata, baseada em noções do PMBOK, todo projeto segue passos ordenados do inicio ao fim, sendo que cada etapa só poderia ser iniciado ao final da etapa anterior e ao final de todas as etapas o mesmo era todo revisado do inicio ao fim. Porem muitas vezes o mau planejamento dos requisitos e das reais necessidades do cliente no inicio do projeto, acabava causando atrasos, devido ao fato que a próxima etapa só seria iniciada no momento que o cliente aprovasse a ultima entrega feita. Max s Project Management Wisdom - www.maxwideman.com/
Na seção 4 será tratada todas as características necessárias para a aquisição do nível F do modelo de maturidade MPS.BR. 4 - MPS.BR Nível F Características necessárias 4.1 - AQU - Aquisição O Objetivo do processo de aquisição é obter um produto/serviço que satisfaça as necessidades descritas pelo cliente. AQU 1. As necessidades de aquisição, as metas, os critérios de aceitação do produto e/ou serviço, os tipos e estratégia de aquisição são definidos. AQU 2. Os critérios de seleção do fornecedor são estabelecidos e usados para avaliar os potenciais fornecedores; AQU 3. O fornecedor é selecionado com base na avaliação das propostas e dos critérios estabelecidos. AQU 4. Um acordo que expresse claramente a expectativa, as responsabilidades e as obrigações de ambos (cliente e fornecedor) é estabelecido e negociado entre o cliente e o fornecedor. AQU 5. Um produto e/ou serviço que satisfaz a necessidade expressa pelo cliente é adquirido baseado na analise dos potenciais candidatos. AQU 6. A aquisição é monitorada de forma que as condições especificadas são atendidas, tais como custo, cronograma e qualidade e, se necessário, ações corretivas são conduzidas. AQU 7. O produto e/ou serviço de software entregue é avaliado em relação ao acordado e os resultados da aceitação são documentados. AQU 8. O produto adquirido é incorporado ao projeto. 4.2 - GCO - Gerencia de Configurações Tem como função manter a integridade dos produtos do processo ou projeto a fim de disponibilizar os mesmos, a todos os envolvidos no projeto. GCO 1. Um Sistema de Gerência de Configuração é estabelecido e mantido; GCO 2. Os itens de configuração são identificados com base em critérios estabelecidos; GCO 3. Os itens de configuração sujeitos a um controle formal são colocados sob baseline; GCO 4. A situação dos itens de configuração e das baselines é registrada ao longo do tempo e
disponibilizada; GCO 5. Modificações em itens de configuração são controladas; GCO 6. O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados; GCO 7. Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros, completos e consistentes. 4.3 - GQA - Garantia da Qualidade Tem como função garantir que aquilo que foi solicitado e estimado seja entregue com a qualidade e com a conformidade dos planos e procedimentos estabelecidos. GQA 1. A aderência dos produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente, antes dos produtos serem entregues e em marcos predefinidos ao longo do ciclo de vida do projeto; GQA 2. A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente; GQA 3. Os problemas e as não-conformidades são identificados, registrados e comunicados; GQA 4. Ações corretivas para as não-conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões. Quando necessário, o escalamento das ações corretivas para níveis superiores é realizado, de forma a garantir sua solução. 4.4 - GPP - Gerência de Portfólio de Projetos A Função da Gerência de Portfólio de Projetos é iniciar e manter projetos que sejam necessários, suficientes e sustentáveis, de forma a atender os objetivos estratégicos da organização. GPP 1. As oportunidades de negócio, as necessidades e os investimentos são identificados, qualificados, priorizados e selecionados em relação aos objetivos estratégicos da organização por meio de critérios objetivos; GPP 2. Os recursos e orçamentos para cada projeto são identificados e alocados; GPP 3. A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas; GPP 4. O portfólio é monitorado em relação aos critérios que foram utilizados para a priorização; GPP 5. Ações para corrigir desvios no portfólio e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão; GPP 6. Os conflitos sobre recursos entre projetos são tratados e resolvidos, de acordo com os critérios utilizados para a priorização; GPP 7. Projetos que atendem aos acordos e requisitos que levaram à sua aprovação são mantidos, e os que não atendem são redirecionados ou cancelados; GPP 8. A situação do portfólio de projetos é comunicada para as partes interessadas, com
periodicidade definida ou quando o portfólio for alterado. 4.5 - MED Medição Tem como função, o estudo dos projetos desenvolvidos a fim de coletar, armazenar e relatar os dados relativos ao produto que está sendo desenvolvido e sobre os processos implementados na organização a fim de apoiar os objetivos organizacionais. MED 1. Objetivos de medição são estabelecidos e mantidos a partir dos objetivos de negócio da organização e das necessidades de informação de processos técnicos e gerenciais; MED 2. Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e definido, priorizado, documentado, revisado e, quando pertinente, atualizado; MED 3. Os procedimentos para a coleta e o armazenamento de medidas são especificados; MED 4. Os procedimentos para a análise das medidas são especificados; MED 5. Os dados requeridos são coletados e analisados; MED 6. Os dados e os resultados das análises são armazenados; MED 7. Os dados e os resultados das análises são comunicados aos interessados e são utilizados para apoiar decisões. 5 - Características alcançadas com a implantação da metodologia Scrum na empresa Tecinco A utilização dos Scrum resultou diversas melhorias identificadas em relação a gerencia de projetos, qualidade e desenvolvimento, através dos feedbacks para a equipe envolvida e também em um ambiente de procura continua melhora, a fim de manter os indicadores dentro dos níveis desejados, perante a parte de gerencia de configurações foi possível notar maior controle sobre as versões geradas, nos processos de qualidade as praticas trazem um maior nível de qualidade e um ambiente disposto sempre a obter um nível maior de excelência. Nas fases iniciais com a utilização do Scrum foi possível definir metas e planejamentos com o consenso de todos os envolvidos, promovendo assim o comprometido de todo o time envolvido. Assim promovendo que o time execute toda a estimativa de horas, fazendo com que essa estimativa se aproxime mais da realidade, pelo simples fato de que quem estima é quem realiza. Identificações de erros causados em projetos anteriores são sanadas através dos feedbacks realizados após o termino e inicio de um novo projeto. Indicadores individuais e coletivos a fim de estimular o alcance de resultados tanto sobre os objetivos individuais como a entrega final que é feita coletiva.
Nas etapas de produção como desenvolvimento e realização de testes a menor interferência causada pela presença de um Scrum Master que fica responsável de tratar impedimentos que ocorrem durante os ciclos, ocasionou um time focado sempre no desenvolvimento e entrega do Sprint no tempo planejado. A integração do time ocasionou numa equipe focada e apresentou fácil e ágil medidas para soluções de problemas encontrados dentro do Sprint. Com a utilização da metodologia Scrum nos projetos desenvolvidos foi possível observar o ganho de qualidade e agilidade em etapas importantes de qualquer projeto, tais ganhos vieram a refletir principalmente no coleta de informações e priorização de tarefas, inicialmente foi realizado o levantamento do que realmente era necessário ser desenvolvido e implementado sem comprometer a confiabilidade e qualidade do projeto. Foi então definido um fluxo principal no setor de qualidade onde são realizados todos os testes de software a fim de manter maior qualidade, atendendo ao processo de GQA Gerencia de qualidade. Com a utilização do Scrum nos testes de software foi possível ganhar tempo e ainda sim manter o nível de qualidade, assegurando que o projeto seja entregue sem erros e bugs. Atendendo o processo de GQA - Gerencia de qualidade, foi possível observar que quando a qualidade daquilo que foi proposto é atingida com sucesso, as necessidades do cliente são atendidas, cumprindo com aquilo que lhe foi proposto e atingindo as metas do projeto sem causar atrasos nos cronogramas, atendendo então o processo de AQU Aquisição. Com a utilização do Scrum no setor de desenvolvimento foi possível aumentar a integridade dos itens de configuração que compõe o Release do que deverá e como serão desenvolvidas a fim de diminui as taxas de re-trabalhado fazendo com que os cronogramas e metas sejam atingidos sem atraso, assim contemplando o processo de GCO Gerencia de configurações 4. CONCLUSÃO Baseado nos resultados adquiridos até então foi possível constatar que a utilização de métodos ágeis em processos internos de um projeto e não especificadamente no projeto como um todo, é capaz de trazer resultados rápidos e com qualidade a fim de atender aos processos necessários para elevação e manutenção dos níveis do modelo de maturidade MPS.BR 5. REFERÊNCIAS
AGILE ALLIANCE 2002. Agile Manifesto, http://www.agilealliance.org BRIAN BUTTON - Managing Schedule Flaws using Agile Methods. Disponível em: http://www.methodsandtools.com/archive/archive.php?id=120 BURN J.(1994). A revolutionary staged growth model of information systems planning. Proceedings of the Fifteenth International Conference on Information Systems, Vancouver, British Columbia, Canada, pp. 395-406. DAIRTON BASSI - Gestão de projetos em Scrum, USP Universidade de São Paulo, Janeiro, 2010. Disponível em: http://www.agilcoop.org.br/files/agilcoop-verao10-scrum.pdf KING W. E TEO T. (1997). Integration between Business Planning and Information Systems Planning: Validating a Stage Hypothesis. Decision Sciences, Vol. 28, nº 2, pp. 279-30 MARION EICKMANN - Keep the Balance - The Scrum Product Owner. Disponível em: http://www.devagile.com/modules/news/article.php?storyid=550 MPS.BR- Melhoria de processos de softwares brasileiro, SOFTEX Disponível em: www.softex.br MPS.BR - Melhoria de Processo do Software Brasileiro Guia Geral v. 1.2 Disponível em: http://www.cin.ufpe.br/~if720/downloads/mps.br_guia_geral_v1.2.pdf