Português (pdf)
Artigo em XML
Referências do artigo
Tradução automática
Enviar este artigo por email
Citado por SciELO 
Similares em
SciELO 
Permalink
1. Introdução
No contexto do uso de tecnologia nas organizações, a adoção de metodologias ágeis para o desenvolvimento de software tem se tornado cada vez mais importante no mercado. Empresas buscam entregar software de forma contínua, colaborar com os clientes e gerar valor antecipado. As inovações, tais como o uso intensivo de machine learning em substituição de técnicas tradicionais de processamento da informação (Martins et al., 2022, 2023), são, não raras vezes, o motor para levar as organizações ao sucesso e para as manter na vanguarda perante os seus concorrentes. (Carvalho, Abreu & Rocha, 2018)
Nesse contexto, a empresa selecionada para este estudo é uma empresa brasileira de grande porte atuante na área financeira, com uma área de Tecnologia da Informação premiada e destacada, com robusta política de segurança da informação (Galegale et al., 2017). Para avaliar a maturidade das equipes Scrum da empresa na adoção de conceitos e práticas ágeis, foi customizado um modelo de maturidade denominado Níveis de Maturidade Ágil Institucional (NMAI), juntamente com um questionário chamado "Diagnóstico de Scrum Teams" (DTS).
No entanto, os resultados do diagnóstico revelaram que a maturidade das equipes Scrum era baixa, com a maioria nos níveis 1 e 2 de maturidade. Diante disso, o presente estudo propõe um artefato chamado Roadmap de Práticas Ágeis para Scrum Teams (RPATS) como complemento aos documentos NMAI e DTS, visando orientar a evolução da maturidade ágil das equipes Scrum.
A questão de pesquisa norteadora deste estudo pode ser assim apresentada: Um roadmap de práticas ágeis ordenadas contribui para aumentar a maturidade ágil das equipes Scrum da instituição financeira?
O objetivo geral é elaborar e avaliar a utilização do artefato RPATS como instrumento complementar na evolução dos níveis de maturidade ágil. Os objetivos específicos incluem a elaboração do referencial teórico, a definição do design do RPATS, o desenvolvimento do artefato, a demonstração para equipes Scrum da instituição financeira, a avaliação da utilização do RPATS pelas equipes e especialistas em agilidade, a divulgação do RPATS para a Equipe de Transformação Ágil da empresa e em eventos científicos e profissionais.
O método de pesquisa adotado é o DSRM (Design Science Research Methodology), que inclui estudos de campo, survey, entrevistas semiestruturadas e grupo focal de especialistas em agilidade.
Este artigo está estruturado em cinco seções principais. A Introdução apresenta o tema, os objetivos da pesquisa e a sua relevância. O Referencial Teórico revisa a literatura existente sobre o assunto, fundamentando teoricamente a pesquisa e fornecendo as práticas que comporão o artefacto a ser produzido. A seção de Metodologia descreve os procedimentos adotados para a coleta e análise dos dados, o delineamento da pesquisa, os instrumentos utilizados e a amostra estudada. Em Resultados e Discussão, são apresentados os achados da pesquisa e por fim, a Conclusão sintetiza os principais pontos abordados, refletindo sobre as contribuições do estudo, suas limitações e sugerindo direções para pesquisas futuras.
2.Referencial Teórico
Com o objetivo de contemplar diferentes aspectos das práticas ágeis, modelos de maturidade e a abordagem de roadmap, a busca por referencial teórico se deu por meio de consultas às bases Web of Science, Scopus e Periódicos Capes, utilizado o algoritmo "maturity model" AND "agile methodology" e, posteriormente, expandida com as bases, IEEE Xplore, ProQuest, SAGE Journal, ScienceDirect, Scopus, Web of Science, Wiley Journals e Springer Link. As strings de busca utilizadas foram "Agile best practices" OR "Agile good practices" AND "Agile Maturity Model" OR "Scrum Maturity Model". Não houve limitação temporal.
Após a junção de todas as buscas, a exclusão de duplicidades e a leitura dos resumos, foram selecionados 72 artigos disponíveis para acesso. Identificou diversos estudos sobre maturidade ágil, com ênfase na proposição e avaliação de modelos para equipes e processos, comparação de modelos, identificação de diferenças e aplicação de metodologias ágeis para alcançar altos níveis de maturidade no CMMI - Capability Maturity Model Integration. No entanto, não foram encontrados artigos específicos sobre ordenação de práticas ágeis. Os estudos foram utilizados para levantamento de práticas que comporiam o artefato RPATS.
Um estudo realizado por Gren et al (2019) investigou a correlação entre práticas ágeis e a maturidade da equipe, destacando os aspectos humanos e comportamentais. Yin (2011) desenvolveu o Scrum Maturity Model (SMM) como resposta a falhas em projetos de software e desalinhamentos na aplicação do framework Scrum para avaliar se a introdução de um modelo de maturidade melhoraria a cooperação com o cliente. Ozcan-Top e Demirörs (2013) questionaram a eficácia dos modelos de maturidade ágil existentes em fornecer informações sobre a capacidade ágil de uma organização, identificando seus pontos fortes e fracos. Eles realizaram cinco estudos de caso, utilizando diferentes modelos de maturidade, incluindo o Agile Maturity Model (AMM) e o Scrum Maturity Model (SMM), com resultados obtidos insatisfatórios, evidenciando lacunas em todos os modelos em algum aspecto do processo, concluindo necessário aprimorar os modelos de maturidade em relação à orientação para adoção, melhoria e avaliação de processos ágeis. Costa et al (2017) avaliaram a maturidade de uma empresa utilizando o Scrum Maturity Model, com o objetivo de propor melhorias no desenvolvimento de software e maximizar a maturidade dos processos ágeis. Nenhum dos modelos encontrados atendeu à questão de pesquisa deste estudo.
2.1 Metodologias ágeis
Metodologias ágeis são definidas como uma combinação de princípios de desenvolvimento que defendem a satisfação do cliente e a entrega incremental de produtos de software por equipes pequenas e altamente motivadas, utilizando métodos informais e buscando simplicidade no desenvolvimento (Pressman, 2011).
O Manifesto Ágil, formalizado em 2001, define valores fundamentais para a adaptabilidade e agilidade, priorizando indivíduos e interações, software funcional, colaboração com o cliente e aceitação de mudanças nos requisitos (Beck et al., 2001).
Diversos métodos de trabalho surgiram para atender aos princípios ágeis. O Scrum é o mais utilizado globalmente. Trata-se de um framework simples e leve, concebido por Jeff Sutherland e equipe, que busca a entrega de valor frequente e a redução de riscos nos projetos de desenvolvimento de software (Pressman, 2011; Sabbagh, 2017). É baseado em pilares de transparência, inspeção e adaptação e possui eventos formais, como reuniões de planejamento, revisão e retrospectiva da Sprint. Também define papéis específicos, como Product Owner, equipe de Desenvolvimento e Scrum Master, além de artefatos, como o Backlog do Produto, Backlog da Sprint e Incremento (Schwaber & Sutherland, 2017).
2.1.1 Práticas ágeis
Embora o Scrum não defina muitas práticas ágeis, ele prevê acoplamento de práticas oriundas de outros métodos ágeis em sua estrutura, conforme reporta Sabbagh (2017).
Nas referências bibliográficas pode-se encontrar pesquisas sobre práticas relacionadas com proposição de modelos de maturidade, práticas isoladas e listas de práticas adotadas mundialmente, construídas anualmente por meio de surveys desenvolvidas para análise e reporte do panorama de agilidade.
A consolidação das práticas ágeis mencionadas nos estudos utilizados incluem: acesso ao cliente e colaboração com o cliente, adaptação e aceitação de mudanças, uso do Canvas MVP, formação de equipes auto-organizadas com características específicas, utilização de casos de teste, colaboração com o cliente on-site, comunicação efetiva, definição de critérios de aceitação, adoção da Definition of Done (Definição de Pronto), implementação de desenvolvimento iterativo com iterações curtas, aplicação do desenvolvimento orientado a testes (TDD), utilização de metodologias como Design Thinking, Lean Inception, Design Sprint, Jornada de usuário e Personas, promoção de colaboração entre equipe Scrum, busca de estabilidade na equipe, estimativa de pontos de história e esforço através de técnicas como Planning Poker, obtenção de feedback rápido e periódico, gestão de projeto abrangendo pessoas, requisitos, mudanças e liberação, gerenciamento de backlog por meio de fatiamento, descarte e priorização, acompanhamento do progresso por meio de gráficos Burn-up e Burn-down, criação de histórias de usuário e metáforas, identificação de riscos de forma colaborativa, entrega de incrementos de produto e entregas frequentes, realização de inspeções contínuas, integração contínua, realização de Lean Inception, priorização da comunicação face a face e acordos orais, manutenibilidade e manutenção do software, elaboração de mapa de competências, trabalho no mesmo ambiente físico, estabelecimento de metas de sprint e releases, utilização de métricas de produtos como OKR, KPIs, negócio e ROI, análise de métricas de processos como Cycletime, Leadtime, CFD, WIP e fila de espera, modelagem de Objeto de Domínio, acompanhamento do Net Promoter Score, adoção de padrões de codificação, refatoração e comentário, prática de programação pareada, realização de pesquisa pós-venda para experiência do usuário, coleta de pesquisa de satisfação, planejamento de entregas e liberação através de Release Plan e Roadmap de Entregas, implementação de plano de ação para melhoria contínua, priorização de histórias e criação de Mapa de Histórias de Usuário, priorização de tarefas, gerenciamento do Product Backlog e seu refinamento, dedicação de um Product Owner, adoção da programação em par, utilização de prototipagem, utilização de quadro de tarefas como o kanban digital e físico, busca pela qualidade de software e excelência técnica, elaboração de relatórios de progresso, realização de retrospectiva e sprint review, realização de reuniões diárias (stand-up meetings) ou daily meetings, revisão e controle de mudanças, presença do Scrum Master como treinador e facilitador, busca por soluções simples, gestão do Sprint Backlog, realização do Sprint Planning ou reunião de planejamento de Sprint, realização do Sprint Review ou reunião de revisão da Sprint, utilização de técnicas de ajuste metodológico, realização de testes de aceitação do cliente, implementação de testes unitários e regressão automatizados, utilização de time-boxed (limitação de tempo) e acompanhamento da vazão de entrega, velocidade de entrega, visão de produto e visibilidade do projeto, além do controle do trabalho em progresso (WIP). Essas práticas contribuem para a adoção e implementação de abordagens ágeis em projetos e equipes de desenvolvimento segundo os pesquisadores Patel e Ramachandran (2009); Yin (2011); Yin et al (2011); Santos et al (2011); Pichler (2011); Talluri e Haddad (2014); Cruz (2015); Layton (2015); Pichler (2016); Torrecilla-Salinas et al (2016); Schwaber e Sutherland (2017); Sabbagh (2017); Caroli (2018); Küpper et al (2019); Silva et al (2015); Campanelli e Parreiras (2015); Hughes (2013); Campanelli e Parreiras (2018); Gren et al (2019); Wilson e Mooz (2003); Chagas et al (2014); Albino (2017); Knapp et al (2017); Teixeira (2015); Sabaggh (2017); Doerr (2018); Beck et al (2001); Koscianski e Soares (2007); Anderson (2011); Turetken et al (2016).
Tais práticas foram utilizadas para seleção e construção do Roadmap de Práticas Ágeis para Scrum Teams- RPATS, produto (artefato) deste estudo.
2.2 Modelos de maturidade de equipes de desenvolvimento de software
A utilização de diversos modelos ou padrões para a implementação de melhoria de processos implica esforço, tempo e custo, gerando complexidade por conterem estruturas específicas. (Mejia, Muñoz, & San Feliu, 2018)
Para projetos de desenvolvimento ágil, as premissas de ambiente, processos de desenvolvimento e organização são muito diferentes das condições de projetos tradicionais (Leppänen, 2013). A busca por aprimoramento contínuo na agilidade é semelhante ao objetivo dos modelos de maturidade de fornecer direcionamentos para a evolução dos processos ao longo do tempo (Henriques & Tanner, 2017). A maturidade ágil concentra-se na implementação de processos e práticas alinhados com a abordagem ágil (Schweigert et al., 2013). Não há consenso sobre um modelo descritivo amplamente aceito para a maturidade ágil embora diversos tenham sido propostos. (Patel & Ramachandran, 2009).
Para este trabalho, foram selecionados dois modelos direcionados para o uso do framework Scrum: o Agile Maturity Model (AMM) (Patel e Ramachandran, 2009) e o Scrum Maturity Model (SMM) (Yin et al., 2011), por estarem citados em diversos artigos lidos e considerando dois fatores críticos determinantes: foco no framework Scrum e necessidade de alinhamento com a realidade da empresa em estudo.
2.3 Roadmap
O Roadmap é conceituado como uma ferramenta que oferece direcionamento e estratégias de inovação para o futuro do produto, estimulando reflexões, definições de metas de evolução e planos de ação para alcançá-las (De Reuver et al, 2013; Wagenaar et al, 2018; Carlos et al, 2018). É uma ferramenta de simples apresentação, mas muito desafiadora de desenvolver, apresentando um escopo amplo e complexas interações conceituais e humanas sendo sua flexibilidade é uma vantagem, permitindo a inclusão de diversos assuntos em diferentes níveis de detalhe. (Phaal et al., 2004, Phaal e Muller, 2009)
O formato mais comum é uma estrutura gráfica de múltiplas camadas, representando um plano detalhado que orienta o progresso em direção a uma meta (De Reuver et al., 2013). Neste sentido, o produto gerado no presente estudo é um Roadmap de Práticas Ágeis que permite às equipes Scrum identificarem seu ponto de partida nos steps, traçar a meta de evolução na maturidade da adoção de conceitos ágeis, e percorrer o caminho orientados pelas práticas sugeridas.
3.Metodologia
A escolha do método é uma das decisões fundamentais na condução do processo de pesquisa e o pesquisador precisa estar seguro de que o produto gerado agregará valor. (Cauchick-Miguel, 2018).
A pesquisa adotou o método Design Science Research Methodology (DSRM), aliado aos métodos de pesquisa bibliográfica, questionários (survey), entrevistas e estudo de campo. Lacerda et al. (2013) destacam que a metodologia Design Science Research é adequada para pesquisas em Engenharia de Produção, pois permite o desenvolvimento de artefatos que solucionem problemas existentes. Essa abordagem busca criar, recombinar ou alterar produtos, processos, softwares ou métodos para melhorar as situações atuais. Hevner et al (2004) enfatizam que uma pesquisa baseada na Design Science deve resultar em um artefato relevante criado para resolver um problema importante e sem solução prévia. A abordagem qualitativa foi utilizada para ordenar práticas ágeis que elevam a maturidade das equipes.
O estudo de campo ocorreu em 2020 com uma empresa financeira brasileira de grande porte cuja área de Tecnologia da Informação e Comunicação conta com aproximadamente 4 mil colaboradores e passava por uma transformação digital com adoção de processos ágeis. À época, possuía 319 equipes utilizando o framework Scrum. A empresa foi selecionada por atender as características estudadas pela pesquisa e concordou em participar do estudo, em anonimato, pelo seu interesse em elevar a maturidade de suas equipes de TI em relação a adoção dos métodos ágeis.
A empresa cedeu os resultados do questionário Diagnóstico de Scrum Teams - DTS, aplicado em novembro de 2019 às suas equipes de Scrum, bem como o documento Níveis de Maturidade Ágil Institucional - NMAI, os quais serviram de insumo para esta pesquisa.
O protocolo de pesquisa seguiu o modelo proposto por Peffers et al. (2007), detalhando cada uma das atividades do DSRM. Essas atividades envolveram a identificação do problema e sua justificativa, definição dos objetivos da solução, criação do artefato, demonstração de seu uso para resolver o problema, avaliação da eficácia do artefato e comunicação dos resultados para pesquisadores e outros públicos relevantes. A Figura 1 apresenta graficamente, o protocolo da pesquisa que norteou o desenvolvimento do artefato.
4. Resultados e discussão
O Os resultados alcançados pela pesquisa foram agrupados de acordo com as atividades do DSRM. A primeira atividade: identificação do problema e motivação, consta na apresentação do estudo na Introdução.
4.1 Definição dos objetivos de uma solução
Conforme apresentado, a pesquisa tem por objetivo geral elaborar e avaliar a utilização do artefato RPATS como instrumento complementar na evolução dos níveis de maturidade ágil. Para fins de validação no estudo de campo, este objetivo pode ser operacionalizado da seguinte forma: (i) fornecer o artefato; (ii) fornecer orientação aos Scrum Masters sobre utilização do artefato; (iii) elevar o score ou nível de maturidade das equipes Scrum participantes da atividade de demonstração do artefato; e (iv) avaliar factibilidade, utilidade e usabilidade do artefato.
4.2 Design e desenvolvimento do artefato Roadmap de Práticas Ágeis para Scrum Teams (RPATS)
A construção do RPATS seguiu os seguintes passos: (i) estudo do NMAI e do DTS existentes na empresa; (ii) Comparação entre NMAI e DTS com SMM e AMM; (iii) Análise da consistência do DTS da empresa por meio do cálculo do alfa de Cronbach, calculado por blocos de questões, cujos resultados variaram entre 0,63 e 0,88, indicando níveis aceitáveis de confiabilidade e consistência interna; (iv) ordenação das práticas ágeis segundo análise descritiva dos dados; e (v) desenvolvimento do artefato, apresentado na Tabela 1.
Tabela 1 Roadmap de práticas ágeis para Scrum Teams - RPATS
| Roadmap de Práticas Ágeis para Scrum Teams | |||
|---|---|---|---|
| Níveis de maturidade do NMAI e suas metas | Steps | Objetivo do Step | Práticas recomendadas |
| 1- Novato: Deseja praticar o ágil, mas não segue com frequência ou não compreende a correta utilização de ciclos curtos, entrega de valor, melhoria contínua e pilares do Scrum (transparência, inspeção e adaptação) Meta 1: Planejamento do projeto Meta 2: Aderência aos processos Scrum | Step 1 | Formação do Equipe Scrum em torno da Visão do Produto buscando maior multifuncionalidade da equipe | - Lean Inception; - Visão do Produto; - Canvas MVP com previsão do resultado a ser atingido; - Roadmap de Releases/Entregas; - Lista inicial de funcionalidades do produto; - Pessoa treinadora do Scrum - Scrum Master (SM); - Pessoa representante do cliente - Product Owner (PO); - Workshop Scrum (ensinar sobre pilares, valores, papéis, ritos e artefatos); - Mapa de Competências; - Identificação de lacunas de conhecimento; - Treinamentos para suprir lacunas de conhecimento |
| Step 2 | Geração de insumos sobre o produto para sprints de desenvolvimento | - Disponibilidade do PO para a equipe Dev (Desenvolvimento); - Escrita de itens de Backlog de Produto (metáforas ou Histórias de usuário); - Regras de negócio; - Backlog de Produto; - Refinamento de Itens de Backlog de Produto; - Definição de Pronto | |
| Step 3 | Sprints de desenvolvimento: Ritos e artefatos | - Sprint Planning parte 1 (O que fazer); - Sprint Planning parte 2 (Como fazer); - Meta/Objetivo de Sprint; - Backlog de Sprint; - Estimativa de esforço (Horas por tarefa); - Estimativa de complexidade (Pontos de História de usuário); - Estimativa de capacidade de entrega (pode ser em pontos de História de usuário); - Daily Meeting/ Reunião diária Planejamento diário da equipe Dev (informal); - Sprint Review; - Inspeção do resultado da Sprint: PO; - Sprint Retrospective. | |
| Step 4 | Sprints de desenvolvimento: Incremento de Produto | - Gerenciamento de Backlog de Sprint (Priorização, inclusão, exclusão de tarefas); - Facilitação pelo SM (Aplicação de técnicas, práticas e conceitos no dia a dia com a equipe); - Testes de software; - Manutenção de software; - Monitoramento de trabalho não planejado (abend, manutenção, correção); - Inspeção do Incremento de Produto: apresentação e feedback do PO e partes interessadas | |
| Step 5 | Trabalhar a evolução da equipe Scrum enquanto equipe | - Planejamento de ausências transparente e visível (Autogestão da equipe Scrum); - Uso do Parking lot nas dailys garantindo foco no planejamento diário; - Plano de ação para melhoria d equipe; - Participação da equipe Scrum em Comunidades de prática; - Encontros periódicos de Scrum Masters da empresa para troca de experiências | |
| 2- Aprendiz: Começa a praticar o ágil e está aprendendo a compreender a correta utilização de ciclos curtos, entrega de valor, melhoria contínua e pilares do Scrum (transparência, inspeção e adaptação) Meta: Planejamento de projeto - entregas e itens de Backlog | Step 1 | Aprimoramento do Roadmap de Releases/Entregas | - Design Thinking, Lean Inception, Design Sprint, Jornada de usuário, Personas; - Roadmap de Releases/Entregas com declaração dos objetivos e benefícios das entregas; - Gerenciamento do Roadmap de Releases/Entregas; - Canvas MVP com detalhamento de escopo, esforço, custo, métricas de produto para o MVP; - Negociação prévia com áreas intervenientes; - ROI (Retorno sobre investimento) |
| Step 2 | Aprimoramento no Gerenciamento do Backlog de Produto | - Gerenciamento de Backlog de Produto (Escrita, Fatiamento, Descarte e Priorização de Histórias de usuário); - Refinamento de Itens de Backlog de Produto; - Mapa de Histórias de usuário; - Matriz de Priorização; - Histórias de usuário contendo as regras de negócio, critérios de aceite e cenários de testes; - Sprint Planning 2 (Como fazer: detalhamento das tarefas, gerenciamento e priorização, além da estimativa) | |
| 3- Praticante: Pratica agilidade e compreende a correta utilização de ciclos curtos, entrega de valor, melhoria contínua e pilares do Scrum (transparência, inspeção e adaptação) Meta: Gestão de Iterações (sprints) por métrica de processo | Step 1 | Métricas de processo para entendimento da capacidade de entrega da equipe | - Throughput (Quantidade de Histórias de usuário entregues); - Pontos de História de usuário planejados por Sprint; - Pontos de História de usuário entregues por Sprint; - Gráfico Burn-up da Sprint; - Quantidade de Histórias de melhoria/evolução entregues por Sprint; - Quantidade de Histórias de manutenção/correção de problemas entregues por Sprint; - Mapa de Histórias de melhoria/evolução versus Histórias de manutenção/correção de problemas |
| Step 2 | Métricas de processo para acompanhamento do ciclo de desenvolvimento do produto | - Cycletime; - Leadtime; -Leadtime breakdown; - CFD (Cumulative Flow Diagram) | |
| Step 3 | Métricas de processo para trabalho a capacidade e sustentabilidade no fluxo de desenvolvimento | - WIP (Working in Progress); - Fila de espera | |
| 4- Experiente: Pratica agilidade e compreende a correta utilização de ciclos curtos, entrega de valor, melhoria contínua e pilares do Scrum (transparência, inspeção e adaptação), tirando proveito das boas práticas em prol da sua evolução Meta: Gestão de qualidade de Incremento de produto por métrica de produto | Step 1 | Métricas de produto - acompanhamento de resultado de lançamento, resultado de negócio e satisfação do cliente | - KPIs (Key Performance Indicator) de negócio; - OKR (Objectives and Key Results) de produto; - NPS (Net Promoter Score); - Pesquisa de Satisfação com usuário |
| 5- Referência: Possui grande expertise em praticar o ágil, utilização de ciclos curtos, entrega de valor, melhoria contínua e pilares do Scrum (transparência, inspeção e adaptação) e pode ser considerado referência para demais equipes Meta: Gestão da Qualidade do produto | Step 1 | Qualidade do Produto - excelência técnica e Satisfação do cliente englobando pesquisa de usabilidade | - Testes automatizados; - Testes de regressão; - Comentário de código; - Refatoração de código; - Pesquisas de pós-venda (UX) |
4.3 Demonstração
Cinco equipes de desenvolvimento de software utilizando Scrum foram indicados pela empresa para participar da atividade de demonstração do RPATS: uma equipe em formação e quatro já formados há mais tempo. O RPATS foi apresentado em uma reunião com os Scrum Masters, bem como a intenção de aplicá-lo em conjunto com o DTS e o NMAI durante duas sprints, com a finalidade de testar sua utilidade, factibilidade e usabilidade, bem como seu papel como orientação na melhoria da maturidade ágil das equipes.
4.4 Avaliação
Após cumprir a etapa de Demonstração, realizou-se a Etapa de Avaliação, cumprindo as 3 Tarefas detalhadas na figura 1. Para a Tarefa 1, foi encaminhado um questionário aos Scrum Masters das equipes participantes para coleta de dados sobre percepção das equipes em relação à utilização do RPATS, insumos para a realização da reunião de entrevista. A reunião com os 5 Scrum Masters para a entrevista teve duração aproximada de 2 horas. Os dados coletados pelos questionários e falas dos Scrum Masters durante a entrevista foram registrados pela pesquisadora e foram analisados em conjunto com os resultados das aplicações do DTS antes e depois das 2 Sprints que eles compartilharam com a pesquisadora. Em síntese, destacam-se os seguintes pontos apresentados pelas cinco equipes:
Equipe Scrum A: Composto por 8 desenvolvedores, 1 Scrum Master e 1 Product Owner e migrou gradualmente para uma metodologia ágil, adotando Sprints mensais e práticas do Scrum. A aplicação do "kit" foi útil para elevar a maturidade ágil. Embora não tenham alcançado um novo nível de maturidade, conseguiram aumentar seu score e aprofundar seu entendimento sobre conceitos ágeis.
Equipe Scrum B: Composto por 6 desenvolvedores, 1 Scrum Master e 1 Product Owner. A equipe considerou o RPATS útil para elevar sua maturidade ágil, pois ajudou a identificar práticas a serem revisadas ou adotadas e foi considerado fácil de ser seguido.
Equipe Scrum C: Composto atualmente por 5 desenvolvedores, 1 Scrum Master e 1 Product Owner. Equipe em formação e seguiu as práticas do Nível 1 do RPATS, alcançando o objetivo de formar a equipe em torno da Visão do Produto. A Scrum Master vê benefícios no direcionamento da equipe e considera o RPATS útil para facilitar seu trabalho e propor melhorias ao grupo.
Equipe Scrum D: Composto por desenvolvedores de alta, baixa plataforma e mobile, 1 Scrum Master e 1 Product Owner e já possuía familiaridade com o Scrum. Como resultado da última aplicação do DTS, a equipe identificou que estava no nível de maturidade 2 - Aprendiz. Após testar o RPATS e reaplicar o DTS elevou sua maturidade para o nível 3 - Praticante, aumentando seu score em 34 pontos. Considerou as práticas sugeridas no RPATS úteis e claras.
Equipe Scrum E: Composto por 6 desenvolvedores, 1 Scrum Master e 1 Product Owner. Adotaram o Scrum como forma de gerenciamento de projetos, no entanto, enfrentaram desafios devido às constantes trocas de Product Owners, A aplicação do RPATS foi considerada fácil e possibilitou à equipe seguir um processo claro para escolher e adotar práticas ágeis.
Como resultado da Tarefa 2, a avaliação do RPATS com grupo focal de especialistas da instituição financeira foi baseada nos critérios de factibilidade, utilidade e usabilidade do artefato RPATS em conjunto com DTS e NMAI. Foi realizada por três especialistas com vasta experiência e conhecimento em agilidade e Scrum da empresa, não inseridos no contexto da elaboração do DTS nem do NMAI, visando manter a imparcialidade. Foram realizadas iterações de avaliação, incluindo uma reunião em formato de workshop para discutir o RPATS e seus propósitos, seguida por um questionário. Os resultados mostraram que os especialistas concordaram que o RPATS é factível, de fácil uso e útil pois facilita a compreensão e adoção de práticas ágeis e contribui para a elevação da maturidade das equipes.
Para concluir a Tarefa 3 a avaliação foi realizada comparação da funcionalidade do artefato com os objetivos da solução, de acordo com Peffers et al (2007). O primeiro objetivo foi alcançado durante as etapas de design e desenvolvimento do RPATS, assim como na atividade de demonstração, onde o artefato foi disponibilizado às equipes Scrum. O segundo objetivo foi cumprido por meio da realização de reuniões com os Scrum Masters para explicar como utilizar o artefato. O terceiro objetivo foi alcançado com a elevação do score ou nível de maturidade das equipes participantes da demonstração, com resultados positivos e depoimentos favoráveis das equipes. O quarto objetivo, que envolveu a avaliação de factibilidade, utilidade e usabilidade do artefato, foi atingido segundo avaliação tanto pelas equipes quanto pelos especialistas em agilidade da instituição. Por fim, o objetivo principal de elaborar e avaliar o RPATS como instrumento complementar ao DTS e NMAI foi alcançado, com indicação de divulgação do artefato para as demais equipes Scrum da instituição financeira.
4.5 Comunicação
Os resultados da utilização do RPATS foram comunicados em reunião interna da empresa e o artefato RPATS foi disponibilizado a todas as equipes, acompanhado do “Roteiro para aplicação do RPATS”, “Orientações e links para auxiliar na aplicação das práticas”.
Adicionalmente, este artigo foi elaborado para comunicar resultado do estudo e propiciar acesso aos profissionais que possam se beneficiar com a utilização do artefato.
5. Conclusão
O trabalho atingiu seu objetivo e demonstrou resultados positivos, tanto para a empresa participante do estudo de campo, como para a academia.
Para a empresa, o RPATS é um conjunto de práticas ágeis subdivididas em cinco níveis, alinhados aos níveis de maturidade do NMAI com orientações para a adoção de tais práticas pelas equipes Scrum, possibilitando às equipes alcançarem o próximo nível de maturidade.
O artefato foi avaliado quanto à utilidade, factibilidade e usabilidade com cinco equipes Scrum da empresa e grupo focal de especialistas em agilidade da empresa, tendo sido considerado útil, de fácil usabilidade e capaz de elevar a maturidade das equipes. No geral, o feedback foi favorável, destacando o valor do RPATS para os Scrum Masters na implementação de práticas e elevação da maturidade das equipes.
Entretanto, este estudo possui limitações em relação à aplicação do artefato em outros contextos e à consideração de aspectos comportamentais e de relacionamento interpessoal que também influenciam a maturidade ágil. Como trabalhos futuros, recomenda-se a generalização do RPATS para outros modelos de maturidade e outras empresas que tenham equipes Scrum em seu ambiente de desenvolvimento de software. Considerar ampliar o tempo de experimentação na etapa de Demonstração espaçando o tempo para permitir experimentação de mais práticas.
