MPS.BR Nível G: Metodologias Ágeis

O trabalho apresenta um estudo de caso sobre a melhoria de processos de desenvolvimento de software em uma pequena empresa, a SoftPC, localizada em Florianópolis. A SoftPC, focada no desenvolvimento de soluções para o setor governamental, enfrenta dificuldades em seu processo de desenvolvimento, principalmente nas áreas de análise, testes e gerenciamento de projetos. A falta de documentação consistente, resultante de uma equipe reduzida, leva a retrabalho e dificuldades na manutenção do software. O objetivo principal é analisar como a adoção do modelo MPS.BR, em conjunto com práticas das metodologias ágeis Scrum e Kanban, pode melhorar os processos da SoftPC, atingindo o nível G de maturidade do MPS.BR. O estudo pretende gerar recomendações práticas e implementar melhorias que otimizem os processos e reduzam falhas no desenvolvimento de software, demonstrando uma pesquisa aplicada que busca resolver a problemática da empresa.

A SoftPC, sendo uma empresa iniciante, carecia de processos de desenvolvimento de software bem definidos. Inicialmente, a prioridade era atender às necessidades dos clientes e crescer de forma sustentável, sem uma preocupação formal com documentação ou regras para levantamento de requisitos. A ausência de um processo estruturado para gerenciamento de projetos e requisitos resultava em falta de documentação, desde a fase de análise com o cliente até a entrega final do produto. Essa falta de documentação levava a retrabalhos, dificuldades na manutenção do software e comprometia a qualidade do produto final. A equipe reduzida da empresa não possuía um profissional dedicado à qualidade e documentação, agravando a situação. A pesquisa identificou que a falta de um framework estruturado para gerenciamento de projetos e requisitos era uma causa principal dos problemas.

O estudo se baseia em referências teóricas relevantes para a melhoria de processos de software. A norma ISO 12207 é apresentada como um padrão internacional para Engenharia de Software, fornecendo uma estrutura comum para os processos de ciclo de vida do software. As metodologias ágeis Scrum e Kanban são analisadas detalhadamente. Para Scrum, os autores Schwaber e Sutherland (2011) são citados, abordando os três pilares do controle de processo empírico (transparência, inspeção e adaptação), o tamanho ideal da equipe, e os eventos do Scrum (Daily Scrum, Sprint Review). Kniberg (2007, 2009) contribui com insights sobre a definição de escopo e importância pelo Product Owner, a estimativa da equipe e a importância da reunião diária. Já para Kanban, David Anderson (2009) é citado, destacando a abordagem Lean, o limite de trabalho em progresso (WIP) e a importância de um sistema puxado. A comparação entre Scrum e Kanban destaca as diferenças na priorização e resposta a mudanças.

A pesquisa culminou em uma lista de recomendações para a SoftPC, baseadas na análise dos processos existentes e nos resultados esperados para o nível G do MPS.BR. Essas recomendações incluem a adoção de práticas de Scrum e Kanban, visando à melhoria do gerenciamento de projetos e requisitos. A implementação de um Quadro Kanban para visualização do fluxo de trabalho e o uso do Product Backlog do Scrum são destacados como práticas adotadas pela empresa. A descrição detalhada dos processos GPR (Gerenciamento de Projetos) e GRE (Gerenciamento de Requisitos) no nível G do MPS.BR, incluindo itens como definição do escopo, estimativa de esforço e custo, identificação e gestão de riscos, e envolvimento das partes interessadas, são fundamentais para a implementação das melhorias. A pesquisa evidencia a utilização de uma abordagem mista, combinando as melhores práticas de ambos os métodos ágeis para atender às necessidades específicas da empresa e alcançar o objetivo proposto. A conclusão demonstra que a implementação das recomendações gerou resultados positivos para a SoftPC.

A seção descreve o framework Scrum, um modelo de desenvolvimento ágil baseado em iterações (Sprints). Schwaber e Sutherland (2011) são citados, destacando os três pilares do controle de processo empírico: transparência, inspeção e adaptação. A transparência exige que aspectos significativos do processo sejam visíveis aos responsáveis; a inspeção envolve a inspeção frequente de artefatos e progresso; e a adaptação requer ajustes no processo caso desvios inaceitáveis sejam detectados. O tamanho ideal da equipe Scrum é discutido, sugerindo um número entre três e nove membros para manter a agilidade e a produtividade. A reunião diária do Scrum, um evento time-boxed de 15 minutos, serve para sincronizar atividades, planejar as próximas 24 horas e identificar obstáculos. A revisão da Sprint, realizada ao final, inspeciona o incremento e adapta o Product Backlog. O Product Backlog lista todas as características, funções, requisitos, melhorias e correções para futuras versões, enquanto o Sprint Backlog define o trabalho para a próxima iteração. Mike Cohn (apud Kniberg, 2007) enfatiza a necessidade de entregas palpáveis e funcionais ao final de cada Sprint, descartando a busca pela perfeição teórica em design e documentação em favor da construção prática do produto.

A seção apresenta o método Kanban, destacando sua utilidade em equipes ágeis e tradicionais de desenvolvimento de software. David Anderson (2009) é citado, descrevendo o Kanban como uma abordagem para mudanças gerenciais, não como um processo ou ciclo de vida específico. O Kanban visa a introduzir mudanças incrementando processos existentes, alinhados a valores Ágeis e Lean. O foco é no mapeamento do fluxo de valor, na limitação do trabalho em progresso (WIP) em cada estágio do processo e no rastreamento das atividades. O sistema puxado, onde as equipes puxam o trabalho de acordo com sua capacidade, é enfatizado. O Kanban encoraja o comprometimento tardio em priorização e entrega. A comparação entre Scrum e Kanban destaca a diferença na priorização: enquanto o Scrum prioriza no Product Backlog para o próximo Sprint, o Kanban permite mudanças de prioridade assim que a equipe estiver disponível. Um exemplo de quadro Kanban ilustra como as colunas de Backlog, Selecionados e Desenvolver gerenciam o fluxo de trabalho com limites de WIP.

A seção compara Scrum e Kanban, destacando suas similaridades e diferenças. Ambos os métodos são baseados no desenvolvimento incremental e na resposta a mudanças, um dos quatro valores do Manifesto Ágil. Contudo, Kanban geralmente permite uma resposta mais rápida. Em Scrum, a priorização se dá através da triagem do Product Backlog, com mudanças ocorrendo no próximo Sprint. No Kanban, a priorização é mais flexível e as mudanças podem ser implementadas assim que a equipe estiver disponível. Apesar das diferenças, a coluna mais à esquerda em um quadro Kanban desempenha um papel semelhante ao Product Backlog do Scrum, necessitando de regras para definir quais itens serão executados primeiro. A adaptação e otimização dos processos são enfatizados através de retrospectivas, em ambos os métodos, após cada iteração ou sprint. A conclusão dessa seção reforça a possibilidade e a eficiência do uso conjunto dos métodos para um contexto específico, como o da SoftPC.

O estudo centra-se no Modelo de Melhoria de Processo de Software Brasileiro (MPS.BR), um framework criado pela SOFTEX para auxiliar empresas, principalmente micro, pequenas e médias empresas (MPMEs), a melhorar seus processos de desenvolvimento de software. O MPS.BR busca compatibilidade com padrões internacionais de qualidade, aproveitando a competência existente em modelos de melhoria de processo. Ele estabelece requisitos de processos baseados em modelos de melhoria e implementa princípios de Engenharia de Software adequados ao contexto das empresas. O programa MPS.BR conta com o Fórum de Credenciamento e Controle (FCC) e a Equipe Técnica do Modelo (ETM) para dar suporte, garantindo a credibilidade e o aprimoramento contínuo do modelo. O FCC credencia Instituições Implementadoras e Avaliadoras (IA), monitorando seus resultados e garantindo a qualidade do modelo. A ETM auxilia em aspectos técnicos, na capacitação e na criação de materiais como cursos e workshops. Uma das metas principais do MPS.BR é ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software e serviços, atendendo às necessidades de negócio das MPMEs.

O MPS.BR define sete níveis de maturidade, que representam patamares de evolução dos processos de uma organização e permitem prever o seu desempenho futuro. A escala inicia no nível G (Parcialmente Gerenciado) e progride até o nível A (Em Otimização). Os níveis intermediários são F (Gerenciado), E (Parcialmente Definido), D (Largamente Definido), C (Definido), e B (Gerenciado Quantitativamente). Cada nível possui um perfil de processos específicos, indicando onde a organização deve focar seus esforços de melhoria. O alcance de um determinado nível de maturidade é obtido ao atender aos propósitos e resultados esperados dos processos e dos atributos de processo estabelecidos para aquele nível. A SOFTEX destaca que a adoção do MPS.BR tem como metas a melhoria e avaliação de processos de software e serviços, especialmente em MPMEs, e sua disseminação nacional e internacionalmente, tanto em PMEs (principal foco) quanto em grandes organizações.

Este estudo foca no nível G do MPS.BR, que engloba os processos de Gerência de Projetos e Gerência de Requisitos. Segundo a SOFTEX (2012), o propósito da Gerência de Projetos nesse nível é estabelecer e manter planos que definam atividades, recursos e responsabilidades, fornecendo informações sobre o andamento para correções de desvios. Este propósito evolui com a maturidade da organização. No nível B, por exemplo, há um enfoque quantitativo. O propósito da Gerência de Requisitos no nível G é gerenciar os requisitos do produto e componentes, identificando inconsistências entre requisitos, planos e produtos de trabalho. O IEEE (1990, apud SOFTEX 2011) e a ISO/IEC 12207 definem a Gerência de Projetos como a aplicação de planejamento, coordenação, medição, monitoramento, controle e divulgação de relatórios para garantir o desenvolvimento e manutenção sistemática e qualificada do software. A seção detalha aspectos cruciais do nível G, como o desenvolvimento do plano do projeto, incluindo a identificação e análise de riscos, o planejamento de coleta e distribuição de dados, a avaliação da viabilidade do projeto e o monitoramento do escopo, tarefas, estimativas, orçamento e cronograma.

Após a análise dos processos da SoftPC e a definição de recomendações baseadas no MPS.BR, Scrum e Kanban, a empresa iniciou a implementação das melhorias. A principal mudança foi a adoção de um quadro Kanban, afixado na parede, onde cada membro da equipe atualiza diariamente o status de suas atividades, utilizando papéis para identificar autor e nome de cada tarefa. Essa visualização permite ao analista identificar gargalos no fluxo de trabalho, sejam por falhas ou atrasos. A integração de algumas práticas Scrum, como a utilização do Product Backlog para o gerenciamento dos requisitos, também foi implementada. A combinação de elementos do Kanban e Scrum, de acordo com as necessidades específicas da empresa, demonstra uma abordagem prática e adaptável para a melhoria de processos. A abordagem combinada se mostrou um caminho eficiente para a empresa atingir seus objetivos de otimização.

A implementação do quadro Kanban foi um passo crucial na melhoria dos processos da SoftPC. A visualização do fluxo de trabalho permitiu que a equipe identificasse facilmente gargalos e pontos de falha. A atualização diária do status das atividades, com o uso de papéis identificando autor e nome da atividade, possibilitou o monitoramento do andamento dos projetos e a identificação de atrasos. Esse recurso visual facilita a comunicação e colaboração entre os membros da equipe, permitindo uma resposta mais rápida a problemas e a uma melhor gestão de tempo. A utilização do quadro Kanban se mostrou uma ferramenta prática e eficaz para melhorar a visibilidade e o controle dos projetos, contribuindo significativamente para a otimização dos processos de desenvolvimento. A empresa implementou um sistema visual que trouxe agilidade para a resolução de problemas e organização das atividades, facilitando a gestão.

A adoção do Kanban e de práticas Scrum, guiada pelas recomendações da pesquisa, resultou em melhorias significativas nos processos da SoftPC. A implementação do quadro Kanban, com sua visualização clara do fluxo de trabalho, possibilitou a identificação rápida de gargalos e a tomada de ações corretivas. A integração do Product Backlog do Scrum contribuiu para um melhor gerenciamento dos requisitos e da priorização das tarefas. A empresa passou a ter uma melhor compreensão do andamento dos seus projetos, permitindo um controle mais eficaz do tempo e recursos. A pesquisa evidencia a eficácia da combinação de métodos ágeis, customizados para as necessidades da empresa, para resolver problemas de documentação e processos, demonstrando um impacto positivo na produtividade e na qualidade do software desenvolvido. A conclusão do estudo demonstra a eficácia das metodologias ágeis na resolução de problemas em empresas de desenvolvimento de software. O sistema implementado trouxe melhorias significativas na organização do trabalho e na resolução de problemas.