AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br
Autor: Julio Cesar Fausto1
RESUMO
Em um cenário cada vez mais competitivo e em franca expansão, o mercado de software brasileiro vem procurando estabelecer-se de forma competitiva através da adoção de modelos de maturidade organizacional que denotem à organização, capacidade plena em gerenciamento de projetos.
Também é cada vez mais frequente a adoção de modelos de desenvolvimento de software ágeis visando obter uma maior produtividade, qualidade e maior satisfação dos clientes.
O grande desafio é alinhar estas duas estratégias de modo que ambas possam conviver lado a lado em uma relação mútua de cooperação em relação aos objetivos estratégicos organizacionais.
Este trabalho estudou de que forma o método Scrum pode se relacionar ao modelo MPS.br (Melhoria de Processo do Software Brasileiro) no sentido de contribuir para a qualificação da empresa em relação aos requisitos necessários para a obtenção do nível G de maturidade do modelo.
Palavras-chave: Scrum, MPS.br, Maturidade Organizacional 1 Introdução
O mercado brasileiro de software tem crescido de forma expressiva nos últimos anos. No ano de 2011, o mercado interno de software registrou um aumento de 21,9% em relação ao mercado de 2009 e alcançamos no cenário mundial uma fatia de 1,8% do mercado (ABES, 2011, p. 10).
Este crescimento trouxe um aumento significativo na concorrência bem como um aumento na preocupação das empresas em se tornar mais eficientes e competitivas através do aprimoramento de seus processos de gestão e da produção de software. Uma das ações frequentemente adotadas para alcançar tais melhorias é a adoção de modelos de qualidade e maturidade tais como o CMM (Capability Maturity Model) e o MPS.br (Melhoria de Processo do Software Brasileiro).
Ambos os modelos apresentam estratégias que quando colocadas em prática promovem dentro das organizações ganhos em maturidade nos processos, capacidade de produção, qualidade do produto, previsibilidade nos processos e alcance dos objetivos estratégicos de negócio levando a um consequente aumento da satisfação dos clientes.
Considerando o cenário acima, o presente estudo tem como objetivo fazer uma análise de como a utilização de um método ágil para desenvolvimento de software pode contribuir e, mais importante, estar alinhado para a obtenção de um maior grau de maturidade organizacional de acordo com um modelo de qualidade tradicional pré-estabelecido e amplamente aceito.
O modelo de qualidade MPS.br (Melhoria de Processo do Software Brasileiro) foi escolhido pelo fato de ser um modelo desenvolvido no Brasil, logo, adequado às necessidades brasileiras, mas que também atende às principais exigências internacionais no que tange a avaliação, definição e melhoria dos processos de produção de software.
O framework (modelo) de desenvolvimento ágil de software escolhido para este trabalho foi o Scrum. Este, contém técnicas, artefatos e cerimônias que, como veremos a diante, contribuem para a definição de um processo de desenvolvimento e o alcance de uma melhor qualidade neste.
O tema deste trabalho tem sua justificativa apoiada na necessidade de esclarecer de que forma novas propostas e tendências que estão sendo amplamente adotadas em empresas de desenvolvimento de software contribuem com os objetivos estratégicos das empresas relacionados ao aprimoramento e busca da qualidade em seus produtos visto que a qualidade é fator crítico de sucesso na indústria de software.
A primeira parte deste trabalho destina-se a esclarecer o que é o modelo MPS.br, quais suas características e benefícios.
A segunda parte deste trabalho destina-se a definir o que é o Scrum e demonstrar suas principais ferramentas, artefatos e cerimônias.
A terceira parte deste trabalho destina-se a análise de como o ferramental do Scrum está alinhado aos requisitos de maturidade presentes no modelo MPS.br e de que forma podem auxiliar a organização a atingir o nível G de maturidade proposto por tal modelo.
2
O Modelo MPS.brO MPS.br (acrônimo para “Melhoria de Processo do Software Brasileiro”) foi criado em 2003 sob a forma de um programa mobilizador de longo prazo conduzido pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX) apoiada principalmente pelo Ministério da Ciência e Tecnologia do Brasil tendo como marcos principais a implantação do modelo até o ano de 2007, entre 2008 e 2011 a consolidação do modelo e entre 2012 e 2015 a internacionalização do modelo. (RELAIS, 2011)
O objetivo do programa é fomentar a melhoria do processo de desenvolvimento do software brasileiro tendo duas metas a serem atingidas:
• Uma meta técnica, visando a criação e aprimoramento do modelo MPS e;
• Uma meta de mercado, visando à disseminação e adoção do modelo MPS em todas as regiões do país de forma acessível tanto a pequenas empresas de desenvolvimento de software quanto a grandes empresas do setor público e privado.
O programa MPS.br se mostrou como uma resposta a uma necessidade crítica e latente das empresas de software que buscam a melhoria na qualidade de seus processos de software e o incremento na competitividade no mercado global.
Tendo como base técnica a ISO/IEC 12207, ISO/IEC 15504 e o CMMI-DEV (MPSBR, 2011, p. 14) o MPS.br apresenta em seu modelo, a seguinte composição:
Figura 1 - Composição do Modelo MPS.br
Nos interessa para o escopo deste trabalho o “Modelo de Referência”, pois, é nele que iremos encontrar os requisitos que as unidades organizacionais deverão atender para estar em conformidade com o modelo proposto e também necessários para obtenção de um maior grau de maturidade.
O modelo, define níveis de maturidade que, segundo o guia geral, são uma combinação entre processos e sua capacidade - definida por um conjunto de atributos de processos em termos de resultados esperados - e estabelece
patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização (MPSBR, 2011, p. 16).
São sete os níveis de maturidade estabelecidos pelo modelo de referencia: A (Em otimização), B (Gerenciado quantitativamente), C (Definido), D (Largamente definido), E (Parcialmente definido), F (Gerenciado), G (Parcialmente gerenciado).
A escala de maturidade vai do G (Parcialmente gerenciado) em sentido a A (Em otimização) e para cada um destes níveis é atribuído um perfil de processos que indica onde a organização deve concentrar seus esforços de melhoria. Cada nível de maturidade possui um grupo de processos relacionado. Estes processos são definidos em temos de seu propósito e de resultados esperados.
A tabela abaixo fornece um resumo geral dos níveis de maturidade definidos pelo modelo, seus processos e atributos de processos:
Figura 2 - Níveis de maturidade do modelo MPS.br
Neste trabalho, vamos nos concentrar nos processos e atributos de processos aplicáveis ao nível G e que conforme a Figura 2 são os processos de “Gerência de Requisitos” e “Gerência de Projetos” tendo como atributos, AP1.1 e AP 2.1. Estes atributos, possuem a seguinte descrição no guia geral do modelo:
AP 1.1 – O processo é executado
Este atributo evidencia o quanto o processo atinge o seu propósito. Resultado esperado:
RAP 1. O processo atinge seus resultados definidos. AP 2.1 – O processo é gerenciado
Resultados esperados:
RAP 2. Existe uma política organizacional estabelecida e mantida para o processo;
RAP 3. A execução do processo é planejada;
RAP 4. A execução do processo é monitorada e ajustes são realizados; RAP 5. As informações e os recursos necessários para a execução do processo são identificados e disponibilizados;
RAP 6. As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas;
RAP 7. As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência;
RAP 8. A comunicação entre as partes interessadas do processo é planejada e executada de forma a garantir o seu envolvimento;
RAP 9. Os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a situação na organização;
RAP 10. O processo planejado para o projeto é executado;
Ambos os processos integrantes do nível G do MPS.br estão alinhados com as definições estabelecida no PMBOK (Project Management Body of Knowledge) publicado pelo PMI (Project Management Institute), um dos mais conceituados e reconhecidos institutos na área de gerenciamento de projetos no mundo (PMI, 2004).
Dois pontos são desafiadores na implantação do nível G: (1) mudança de cultura organizacional, orientando a definição e melhoria dos processos de desenvolvimento de software; (2) definição do conceito acerca do que é “projeto” para a organização (MPSBR1, 2012, p. 6).
3 O Scrum
O SCRUM foi concebido como um estilo de gerenciamento de projetos voltado em um primeiro momento para empresas de fabricação de automóveis e produtos de consumo por Takeuchi e Nonaka no artigo “The New Product Development Game” publicado pela Harvard Business Review na edição de janeiro-fevereiro de 1986. (TAKEUCHI & NONAKA, 1986).
No ano de 1993, Jeff Sutherland, John Scumniotales e Jeff McKenna documentaram e implantaram o Srcum na empresa Easel Corporation através da incorporação do estilo de gerenciamento proposto por Takeuchi e Nonaka.
No ano de 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a empregá-lo no desenvolvimento de software por todo o mundo. (WIKI, 2001).
A fundamentação do Scrum é baseada em teorias empíricas de controle de processo e emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. Três pilares apóiam a implementação de um controle de processos empírico: Transparência, inspeção e adaptação.
No pilar “Transparência” é fundamental que os aspectos significativos do processo devam estar visíveis aos responsáveis pelos resultados. Para que esta transparência seja compartilhada entre todos, é necessário estabelecer alguns critérios de padronização para que os observadores que compartilham da informação tenham o mesmo entendimento sobre o que está sendo visto. Um exemplo desta padronização pode ser observada na definição de um conceito de “Pronto”2, na definição de uma linguagem comum a fim de que os
temos utilizados sejam de conhecimento de todos os envolvidos no processo bem como o estabelecimento de um documento de visão do projeto que fornecerá o entendimento comum do produto alvo do projeto.
Já no pilar da “Inspeção”, os usuários Scrum devem, constantemente, inspecionar os artefatos gerados e o progresso do trabalho em direção ao objetivo, com a intenção de detectar possíveis entraves e variações indesejadas. Esta inspeção deve ser regulada para que não atrapalhe o andamento da própria execução das tarefas e se possível deve ser feito por alguém especializado no trabalho a ser verificado.
Quanto ao último pilar, o da “Adaptação”, é nele que os desvios e problemas detectados no pilar da inspeção são ajustados. Estes ajustes devem ser feitos o mais breve possível para minimizar maiores desvios e problemas.
O Scrum foi idealizado sob a forma de um framework (modelo) que nada mais é do que um conjunto de conceitos usados para resolver um problema de um domínio específico, e está organizados da seguinte forma:
2 O conceito de pronto é estabelecido entre os envolvidos no processo e diz respeito aos requisitos que
quando atendidos fazem com que uma demanda seja considerada finalizada e pronta para ser entregue ao solicitante.
Figure 3 - O Framework Scrum
O “time” necessário para implementar o Scrum consiste em um “Product Owner”, “Time de desenvolvimento” e um “Scrum master”. Este grupo de pessoas deve ser auto-gerenciável e multidisciplinar, pois, o Scrum prega que o próprio time decide a melhor maneira de completar o trabalho sem ser dirigido por outras pessoas fora do time, e a multidisciplinaridade provê ao time todas as competências necessárias para realizar o trabalho sem precisar de recursos externos ao mesmo. A missão de um time Scrum é entregar produtos de forma iterativa e incremental. Abaixo um breve resumo dos papéis utilizados no Scrum:
O “Product Onwer” como a própria tradução já sugere, é o dono do produto, e sua missão é maximizar o valor do produto, ou seja, é a pessoa que irá priorizar as demandas e selecioná-las para que o time de desenvolvimento as implemente.
O “Time de desenvolvimento” consiste nas pessoas responsáveis por executar uma “Sprint” (rodada de implementação no Scrum) e gerar um incremento potencialmente entregável no produto, ou seja, a cada iteração existe um produto potencialmente pronto para ser entregue ao cliente final.
O último componente do framework é o “Scrum master”. Este é responsável por garantir que o Scrum foi entendido por todos e que todos estão praticando da forma correta as atividades definidas no framework. A pessoa nesta posição deve atuar como um líder-servidor do time de desenvolvimento.
O Scrum possui algumas cerimônias e técnicas. Estas, servirão de insumo para a análise realizada neste trabalho. Abaixo uma breve explicação destas:
A “Sprint” é o coração do Scrum. Trata-se de um “time-box” (um período fixo de tempo pré-estabelecido) onde um incremento no software será criado. As “Sprints” ocorrem de forma consistente durante o desenvolvimento, ou seja, ao término de uma “Sprint”, outra é iniciada.
Uma “Sprint” consiste em uma série de etapas estabelecidas pelo Scrum: Reunião de planejamento da Sprint (Sprint planning), Reuniões diárias (Daily meetings), Trabalho de desenvolvimento (Sprint), Review da Sprint (Sprint review) e Retrospectiva da Sprint (Sprint retrospective).
A etapa de “Reunião de planejamento da Sprint” ocorre em duas fases, sendo que a primeira visa deixar claro o que será entregue ao final do ciclo da Sprint. Nesta etapa o “Product Owner” apresenta ao time de desenvolvimento o trabalho a ser feito sob a forma de itens já valorados quanto ao sua contribuição para o negócio.
A segunda etapa é realizada pelo time de desenvolvimento e visa estabelecer (prever) qual é o esforço e quais tarefas serão necessárias para se entregar o incremento solicitado pelo “Product Owner” no produto.
A “Reunião diária”, trata-se de uma cerimônia de geralmente 15 minutos voltada ao time de desenvolvimento e seu principal objetivo é fazer com que o este fique sincronizado em relação às suas atividades e também para que seja criado um plano de ação para as próximas 24 horas.
A “Review da Sprint” é o momento onde o time de desenvolvimento apresenta os itens prontos ao “Product Owner” para que este emita um aceite sobre o que está sendo entregue. É também neste momento que as possíveis dúvidas remanescentes são esclarecidas pelo “Product Owner”.
A “Retrospectiva da Sprint” envolve somente o time de desenvolvimento e é o momento onde a equipe irá fazer uma auto-inspeção e irá discutir o que aconteceu de bom e ruim na Sprint que se encerrou a fim de determinar ações que façam com que as coisas ruins não se repitam e que as boas sejam potencializadas.
O Scrum possui alguns artefatos que serão úteis em nossa análise: Product backlog, Sprint backlog, Monitoramento do progresso da Sprint e a definição de “Feito”.
O “Product backlog” resume-se a todas as demandas de um determinado produto que estão por fazer classificadas geralmente por valor de negócio.
O “Sprint backlog” trata-se dos itens selecionados do “Product backlog” que irão compor a Sprint.
O “Monitoramento do progresso da Sprint” é realizado através dos gráficos de “burndown”, um gráfico que demonstra o progresso da equipe em relação ao compromisso assumido na Sprint e à Release.
Finalmente, mas não menos importante, há o conceito de “Feito”. Este conceito deve conter os requisitos aos quais uma demanda deve atender a fim de ser considerada pronta para entrega. Quanto mais madura é a equipe Scrum, mais criterioso é o conceito de “Feito”.
4 Análise da Correspondência das Práticas Ágeis do SCRUM aos Requisitos do Nível G do MPS.br
Com base nos dados apresentados acima, foi realizada uma análise de correspondência das práticas do Scrum em relação aos resultados esperados pelos dois processos existentes no nível G de maturidade do MPS.br.
A fundamentação teórica para a identificação das correspondências foi baseada nas definições dos resultados esperados encontradas no documento “MPS.br - Guia de Implementação” (MPSBR3, 2012, p. 6).
Para efeitos de melhor entendimento, a análise comparativa, demonstrada abaixo, está estruturada sob a forma de uma tabela onde na primeira coluna será demonstrado os resultados esperados em cada processo do nível G do MPS.br e na segunda, a técnica ou artefato do Scrum que satisfaz o resultado esperado.
Durante a análise, um ciclo de execução do Scrum foi considerado como sendo um projeto, por ser caracterizado com um esforço temporário empreendido com intuito de gerar um resultado específico.
MPS.br (Resultado esperado) MPS.br (Resultado esperado) Correspondência no Scrum (Técnica, artefato ou cerimônia) Processo: Gerência de Projetos
Processo: Gerência de Projetos Processo: Gerência de Projetos
GPR 1. O escopo do trabalho para o projeto é definido.
O documento de visão e o “Product backlog” contém toda a visão e o trabalho necessário para conclusão do projeto.
GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados.
A definição de “histórias” e o dimensionamento através de técnicas de estimativa ágil como os “Story points”, decompõem as histórias em tarefas menores e as tornam gerenciáveis.
GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos.
O Scrum define claramente as fases do ciclo de vida de um projeto a serem executadas de forma iterativa e incremental: Planejamento da sprint, reunião diária, Sprint, review e
MPS.br (Resultado esperado) MPS.br (Resultado esperado) Correspondência no Scrum (Técnica, artefato ou cerimônia) GPR 4. O esforço e o custo para a
execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas.
O planejamento das tarefas, o que inclui o dimensionamento do esforço, no Scrum é feito pela equipe considerando questões técnicas de
viabilidade, porém baseado no empirismo e não em registros históricos. Pode-se afirmar que o Scrum atende a este requisito de forma parcial.
GPR 5. O orçamento e o
cronograma do projeto, incluindo a definição de marcos e pontos de
controle, são estabelecidos e mantidos.
Estas informações podem estar contidas no documento de visão.
GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados. A etapa de planejamento da sprint pode identificar riscos existentes antes do início do projeto (execução de uma sprint) e as reuniões diárias servem para mitigam riscos não identificados que se
transformaram em
impedimentos de uma tarefa. Os riscos que se tornaram impedimentos, devem ser mitigados o mais cedo possível através da ação do “Scrum master” que pode também estabelecer um padrão para registro (através de uma planilha conforme sugerido no guia do MPS.br) dos
impedimentos, embora o Scrum explicitamente não cite esta etapa como mandatória para implementação do framework.
MPS.br (Resultado esperado) MPS.br (Resultado esperado) Correspondência no Scrum (Técnica, artefato ou cerimônia) GPR 7. Os recursos humanos para
o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo.
A definição do time scrum
(Product owner, Scrum master e Time) em termos de suas
competências e disponibilidade deve estar evidenciada no documento de visão. GPR 8. Os recursos e o ambiente
de trabalho necessários para executar o projeto são planejados.
A definição do time scrum evidenciada no documento de visão e o product backlog satisfazem este requisito. GPR 9. Os dados relevantes do
projeto são identificados e planejados quanto à forma de coleta e armazenamento e distribuição. Um
mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança.
A utilização de um quadro para acompanhamento das
atividades e os gráficos de burndown servem de
mecanismos para divulgação das informações relevantes no projeto. Porém não há critérios de segurança e privacidade explicitamente formalizados pelo Scrum. Pode-se dizer que este requisito é atendido
parcialmente. GPR 10. Um plano geral para a
execução do projeto é estabelecido com a integração de planos específicos.
As etapas do framework scrum configuram um plano de
execução do projeto
(Documento de visão, product backlog, sprint planning, sprint, review e retrospectiva) GPR 11. A viabilidade de atingir metas do projeto é explicitamente avaliada considerando restrições e recursos disponíveis. Se necessário, ajustes são realizados.
Durante a reunião de planejamento da Sprint o trabalho é avaliado em termos de capacidade da equipe para concluí-lo e se necessário são feitos os ajustes. Ainda assim é feito um acompanhamento diário através das reuniões diárias da viabilidade de
cumprimento de todo o escopo do projeto.
MPS.br (Resultado esperado) MPS.br (Resultado esperado) Correspondência no Scrum (Técnica, artefato ou cerimônia) GPR 12. O Plano do Projeto é
revisado com todos os interessados e o
compromisso com ele é obtido e mantido.
Durante a execução da Sprint, a reunião diária garante uma revisão periódica do
planejamento inicial e inclui parcialmente os interessados. Já na review da sprint, todos os interessados são envolvidos e ocorre novamente uma revisão acerca do plano traçado para o cumprimento do compromisso assumido pela equipe.
GPR 13. O escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados em relação ao planejado.
Através dos gráficos de acompanhamento da Sprint (sprint burndown) e da Release (release burndown) é possível fazer este acompanhamento. GPR 14. Os recursos materiais e
humanos bem como os dados relevantes do projeto são monitorados em
relação ao planejado.
Através dos gráficos de acompanhamento da Sprint (sprint burndown) e da Release (release burndown) bem como através das reuniões diárias, é possível fazer este
acompanhamento. GPR 15. Os riscos são monitorados
em relação ao planejado.
Durante as reuniões diárias, os riscos identificados são
constantemente monitorados a fim que que não se tornem impedimentos futuros. GPR 16. O envolvimento das partes
interessadas no projeto é planejado, monitorado e mantido.
O Scrum define para cada etapa quais são os envolvidos e é de responsabilidade do Scrum master garantir que este plano seja seguido.
GPR 17. Revisões são realizadas em marcos do projeto e
conforme estabelecido no planejamento.
Através das reviews das sprints, os marcos planejados no
documento de visão podem ser revisados.
MPS.br (Resultado esperado) MPS.br (Resultado esperado) Correspondência no Scrum (Técnica, artefato ou cerimônia) GPR 18. Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas.
Não há formalmente uma forma de registro de problemas
identificados durante o projeto (execução de uma sprint). Pode-se dizer que o Scrum não atende a este requisito.
GPR 19. Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas,
implementadas e
acompanhadas até a sua conclusão.
Durante as reuniões de review e retrospectiva da sprint, ações podem ser planejadas para mitigar problemas identificados.
Processo: Gerência de Requisitos Processo: Gerência de Requisitos Processo: Gerência de Requisitos GRE 1. O entendimento dos
requisitos é obtido junto aos fornecedores de requisitos.
O entendimento por parte de todos os envolvidos das
práticas do Scrum atende este requisito.
GRE 2. Os requisitos são avaliados com base em critérios objetivos e um
comprometimento da equipe técnica com estes requisitos é obtido.
O comprometimento da equipe com os item é assumido
durante a reunião de planejamento da Sprint. GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos e trabalho é estabelecida e mantida.
Não existe formalmente no Scrum uma prática para a rastreabilidade, porém pode-se manter em cada item de
trabalho uma referência que pode ser utilizada para futuras associações e controles de rastreabilidade entre requisito e trabalho realizado.
MPS.br (Resultado esperado) MPS.br (Resultado esperado) Correspondência no Scrum (Técnica, artefato ou cerimônia) GRE 4. Revisões em planos e
produtos de trabalho do projeto são realizados visando identificar e corrigir inconsistências em relação aos requisitos.
As revisões ocorrem
essencialmente durante as reuniões diárias e durante a reunião de review da Sprint.
GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.
As mudanças de requisitos são tratadas durante a reunião de planejamento da Sprint, durante as reuniões diárias e também na review da sprint.
Tabela 1. Análise comparativa entre resultados esperados para os processos do nível G de maturidade MPS.br em relação às práticas, artefatos e cerimônias do Scrum.
Conclusão
Podemos perceber através da análise realizada neste trabalho, que a utilização de uma técnica ágil de desenvolvimento de produtos de software pode conviver pacificamente com modelos tradicionais de qualidade e excelência em gerenciamento de projetos.
Nota-se, que o framework analisado neste trabalho, o Scrum, atende de forma satisfatória a quase todos os requisitos necessários para a implantação de um nível G de maturidade de acordo com o critérios estabelecidos pelo modelo MPS.br. Com poucas adaptações e talvez com a junção de algumas outras técnicas e ferramentas ágeis, uma organização pode considerar-se aderente ao primeiro nível de maturidade em gerenciamento de projetos estabelecido pelo modelo MPS.br.
Entre os benefícios obtidos com a utilização do Scrum como apoio para a implantação e obtenção do nível G de maturidade do modelo MPS.br, podemos destacar a significante contribuição na superação dos principais desafios encontrados na implantação deste, através do auxílio na mudança de cultura organizacional de forma suave e gradual e o apoio no estabelecimento de uma definição do conceito acerca do que é um “projeto” para a organização. Destaco também, finalmente, como benefícios, o ganho em maturidade organizacional e consequentemente maior competividade bem como a modernização do processo de desenvolvimento sem estar desalinhados aos objetivos estratégicos da empresa trazendo maior qualidade para o produto e maior satisfação ao cliente.
REFERÊNCIAS
ABES, 2011. Mercado Brasileiro de Software – Panorama e Tendências. Disponível em: <http://www.abes.org.br/UserFiles/Image/PDFs/
Mercado_BR2011.pdf>
MPSBR, 2011. Guia Geral do MPS.br. Disponível em: <www.softex.com.br>. MPSBR1, 2012. SOFTEX. MPS.br Guia de Implementação. Disponível em: <www.softex.com.br>.
PMI, 2004. PROJECT MANAGEMENT INSTITUTE. A Guide To The Project Management Body of Knowledge. 3ed. Disponível em: <www.pmi.org> RELAIS, 2011. Seminário da Rede Latino Americana da Indústria de Software. Porto Alegra, RS 11 de Maio de 2011. Disponível em: <http://bit.ly/ yGNoB7>
TAKEUCHI & NONAKA, 1986. The New Product Development Game. Disponível em: <http://bit.ly/kgcduM>.
