ENTREVISTAS COM OS GP 44 

Logo no início do tratamento dos dados, durante o processo de codificação, foi verificado que algumas das assertivas tratavam de temas que, embora vitais ao processo de monitoramento e controle nos métodos ágeis, não se encontravam dentro do escopo definido para esse processo no CMMI, determinando a criação de uma categoria adicional sob a designação planejar o processo de desenvolvimento, sob a qual foram agrupadas algumas práticas de planejamento que são requisitos diretos das demais práticas de monitoramento e controle. Cabe ressaltar que existe no CMMI um processo específico relacionado ao planejamento do projeto (SEI, 2011, p. 281). A decisão de incluir uma prática relacionada a outra área de processo deriva da necessidade de apresentar um modelo integrado para o Scrum, onde várias práticas de monitoramento e controle dependem de aspectos de planejamento.

Posteriormente, a exploração mais detalhada dos aspectos de monitoramento determinou a adição de mais uma categoria, denominada realizar o monitoramento da integração, que responde por práticas relacionadas ao monitoramento da atuação conjunta dos vários integrantes do projetos.

Após a codificação inicial, foi acrescentada uma estrutura complementar de classificação, adjacente à categoria primária, que classificava a assertiva de acordo com o tipo de afirmação, que poderia ser (1) uma informação irrelevante, (2) uma informação adicional, (3) um problema, (4) uma recomendação, ou (5) uma prática. Na análise dos resultados, buscou-se principalmente as práticas apresentadas pelos GP. Posteriormente, em um trabalho interpretativo, práticas adicionais foram derivadas das recomendações e dos problemas. Esse processo de indução só foi utilizado nos casos onde as informações de um GP eram

corroboradas por outro, ou seja, onde existiam recomendações ou problemas análogos em citações de gerentes distintos.

Por exemplo, os GP identificaram vários problemas na precisão do gráfico de

burndown, alertando, por exemplo, que “não é possível confiar plenamente no burndown,

[pois] às vezes as coisas [o escopo] mudam muito” ou “como você vai priorizar se você não sabe o que quer?”. Por outro lado, alguns gerentes faziam recomendações, como “nós temos sempre realizados workshops iniciais e detalhado bem o backlog(...), isso tem dado muito certo.” Assim, a junção de um conjunto de problemas com recomendações relacionadas deu origem a uma prática proposta, no caso garantir a existência de um nível de detalhamento inicial mínimo com relação ao escopo do sistema.

Ao final, para cada prática identificada, foi proposta uma nova redação com o objetivo de padronizar a linguagem, mas buscando manter o texto fiel às ideias dos entrevistados. Nesse processo, também foi equilibrado o nível de especificidade das práticas do Scrum, assumindo-se como padrão uma especificidade ligeiramente superior àquela utilizada nas subpráticas do modelo CMMI. Tal abordagem justifica-se em função do estudo ter um foco naturalmente mais específico que esse modelo, que trata de atividades de desenvolvimento de produtos em qualquer método.

Em algumas situações, os gerentes entrevistados fizeram referências a práticas técnicas de desenvolvimento de software, pertencentes à primeira camada do modelo de Highsmith (2011) (vide Quadro 3), coberta pelo método XP na customização metodológica em uso na Instituição. Essa imprecisão no discurso dos GP decorre do fato de que, no gerenciamento cotidiano do projeto, é irrelevante o fato da prática ser originalmente definida no Scrum ou no XP, visto que a Instituição trata esses dois métodos de forma integrada. No entanto, para manter a coerência com os objetivos deste estudo, as prática citadas pertencentes ao XP, ou mais genericamente à primeira camada do modelo citado, foram desconsideradas no tratamento dos dados.

Como resultado dessa etapa, foi produzida uma relação de práticas do Scrum, agrupadas sob as categorias do modelo CMMI, onde alguns pontos podem ser destacados. Primeiramente, todas as práticas desse modelo estão representadas na utilização do Scrum na instituição pesquisada. No entanto, não pode ser estabelecida de forma clara uma relação de similaridade entre as subpráticas do CMMI e as práticas específicas observadas no Scrum. Dessa forma, pode-se concluir que o Scrum provê um ciclo de monitoramento e controle completo, ainda que simplificado em seus ritos.

Dentre as observações dos GP, algumas se repetem com frequência, indicando um certo nível de consenso. Por exemplo, o uso do gráfico de burndown é frequente para monitoramento do projeto como um todo ou de uma release, bem como o uso do kanban ou de mecanismo eletrônico análogo para monitoramento da sprint. Outro ponto relativamente consensual é a necessidade de zelar pela precisão do gráfico de burndown por meio de levantamentos iniciais mais acurados ou de estimativas de esforço relativo mais precisas. Nos casos onde o gráfico de burndown figura como um meio efetivo de monitoramento, há uma preocupação em se evitar um escopo inicial muito especulativo.

Curiosamente, poucos gerentes relatam problemas relativos ao perfil do PO, que parece, em geral, estar bem adequado ao exigido por um projeto sob o Scrum na Instituição. Com relação a esse aspecto, vários GP relatam um cuidado inicial na formação do PO, seja por reuniões ao início do projeto, onde as responsabilidades do papel são exploradas, seja por treinamentos formais providos pelo departamento de TI.

Um dos aspectos mais paradigmáticos do discurso dos GP foi a abordagem de tempo fixo. Alguns gerentes observaram que a determinação do timebox para um projeto ou uma

release ocorre com base em um processo bastante empírico, que normalmente leva em conta

um escopo inicial estimado e a expectativa de prazo do cliente. Já a administração de um projeto em regime de tempo fixo exige a determinação prévia de um conjunto de objetivos de negócio para o projeto ou para cada release. Dessa forma, admite-se que o projeto ou a

release sejam considerados concluídos se o objetivo de negócio for atingido, ainda que o

escopo incialmente previsto não tenha sido integralmente construído. Como forma de conferir maior objetividade a esse conceito, foi proposto o estabelecimento de um conjunto de histórias que formem um produto mínimo aceitável.

Cabe ressaltar que nem todos os projetos conseguem aplicar adequadamente o

timeboxing, visto que sua utilização exige que o PO entenda e aceite essa abordagem. A esse

respeito, foi ponderado que a Instituição ainda carece de um maior aculturamento dos métodos ágeis nas áreas de negócio.

Com relação ao grau de rigor na adoção das práticas do Scrum, os GP claramente se dividem em dois grupos. O primeiro segue os princípios ágeis de forma rigorosa e não admite a adoção de práticas outras que aquelas preconizadas pelo método. Já o segundo adota uma postura mais pragmática e admite que as práticas do Scrum podem ser flexibilizadas quando necessário, justificando que o princípio da adaptabilidade é hierarquicamente superior às

práticas, que devem ser adaptadas sempre que não se mostrarem adequadas para lidar com a realidade dos projetos.

Esse aspecto é bem evidenciado na decisão sobre ações corretivas, onde a opinião prevalente parece ser que a equipe deve, sempre que possível, participar do processo decisório que define como serão tratados os problemas do projeto, conforme preconiza o Scrum. No entanto, a maioria dos GP admite que algumas ações devem ser tomadas à revelia da equipe, considerando, principalmente, as situações onde o grupo não tem a capacidade de autogerenciamento plenamente desenvolvida.