MODELO DE MONITORAMENTO E CONTROLE 49 

As práticas internas (I) e externas (E) aplicáveis aos projetos sob o Scrum são apresentadas no Quadro 4, associadas à categoria e, consequentemente, à prática correspondente no modelo CMMI, quando pertinente. Nele, as práticas indicadas com um asterisco (*) são aquelas corroboradas pelo nível hierárquico superior, enquanto a coluna previsão no método organizacional apresenta a confrontação das práticas identificadas com aquelas constantes no método de desenvolvimento de software em uso na Instituição, resultando na classificação nas categorias (TP) Totalmente Previstas, (PP) Parcialmente Previstas, ou (NP) Não Previstas. No Apêndice E, são apresentadas algumas das citações das entrevistas com os gerentes que corroboram cada uma das práticas.

Analisando esse cenário, as práticas de monitoramento e controle identificadas durante a pesquisa nos dois níveis de gerência – GP e GL – demonstram a existência de focos distintos no processo de monitoramento e controle. Os GP trabalham em contato direto com a equipe e executam um ciclo de controle com características orgânicas, onde a equipe e o PO desempenham um papel fundamental, aproximando-se do modelo descrito por Schwaber (2004), conforme apresentado na teoria deste estudo.

Quadro 4 – Práticas identificadas

Categoria Prática proposta

Prática Interna/ Externa Previsão no método institucional Planejar o processo de desenvolvimento

Determinar o timebox para o projeto. (*) E PP Dividir o projeto em releases e determinar um timebox para

cada uma das releases. (*) I TP

Estabelecer os objetivos de negócio de cada release. (*) I/E TP Determinar o escopo mínimo a ser cumprido em cada

release. (*) I/E NP

Estabelecer os marcos para cada uma das releases. I NP Definir o critério para aceitação (conceito de “pronto”) a ser

adotado no projeto. I PP

SP1.1 Monitorar parâmetros de planejamento

Garantir a existência de um nível de detalhamento inicial

mínimo com relação ao escopo do sistema. (*) I/E PP Atualizar a evolução da construção das histórias no backlog

e no gráfico de burndown. (*) I TP

Estimar o custo relativo das histórias com base no planning

poker. I TP

Estimar a velocidade da equipe com base nas iterações

passadas e fazer previsões da evolução do backlog I NP Monitorar a qualidade interna e externa do produto. (*) I/E PP Monitorar o perfil técnico e atitudinal dos profissionais da

equipe de desenvolvimento. (*) E NP

Monitorar o perfil gerencial e de relacionamento do GP. (*) E NP

SP1.2 Monitorar Compromissos

Renegociar o timebox do projeto/release em caso de mudanças de requisitos significativas ou nos casos onde as projeções indicam o não atendimento dos objetivos da release/projeto. (*)

I/E NP

Revisar o tamanho do timebox do projeto/release ao longo

do projeto. I PP

Revisar o escopo do projeto/release ao longo do

desenvolvimento. I TP

SP1.3 Monitorar Riscos

Levantar os riscos junto a equipe nas reuniões diárias, de

retrospectiva ou de planejamento. I PP

Realizar monitoramento periódico de riscos com os

principais stakeholders. (*) I/E NP

SP1.4 Monitorar o Gerenciamento de Dados

Assegurar que todos os envolvidos no projeto tem acesso às informações necessárias para o desempenho das suas atividades. (*)

I PP

Manter mecanismos – kaban físico, kanban virtual, etc. –

que permitam o automonitoramento da sprint pela equipe. I PP

SP1.5 Monitorar o envolvimento dos stakeholders

Selecionar o PO com base no conhecimento de negócio, na

disponibilidade e nas características pessoais do mesmo. (*) E NP Realizar treinamento do PO no início do projeto. (*) I/E NP Assegurar que o PO realiza a priorização de forma efetiva e

com foco nos objetivos da release, bem como envolve todos os interessados na definição dos requisitos e na

homologação do sistema. (*) I/E NP SP 1.6 Conduzir revisões do progresso do projeto

Comunicar aos patrocinadores e stakeholders principais a evolução do projeto por meio do backlog e do gráfico de burndown. (*)

I/E TP

Administrar o backlog, agrupando ou desagrupando histórias

Categoria Prática proposta Prática Interna/ Externa Previsão no método institucional SP1.7 Conduzir

revisões dos marcos do projeto

Revisar os marcos associados a cada uma das releases

quando da ocorrência de mudanças. I NP

Realizar

monitoramento da integração

Realizar monitoramento da integração dos elementos do

projeto (PO, Equipe, GP, Produto). (*) E NP

SP2.1 Analisar problemas

Analisar as alternativas de tratamento de problemas em

conjunto com a equipe sempre que possível. (*) I TP Realizar retrospectiva ao final de cada sprint/release. I TP Realizar controle de impedimentos no projeto/programa. I PP

SP2.2 Tomar ações corretivas

Adaptar o método de trabalho em uso pela equipe sempre

que necessário. I TP

Decidir ações de correção à revelia da equipe quando

necessário. (*) E NP

Renegociar escopo e prazo com o cliente nos casos onde a evolução do backlog indicar possibilidade de não

cumprimento de compromissos assumidos.

I/E NP

Propor a realização de iterações dedicadas à qualidade

interna ou externa do produto quando necessário. (*) I TP

SP2.3 Gerenciar as Ações Corretivas

Acionar as instâncias externas ao projeto necessárias para a

ação proposta. (*) I TP

Adequar o backlog em função dos impedimentos ativos. I PP Remover os impedimentos que são levantados pela equipe.

(*) I/E TP

Por outro lado, a aplicação do Scrum na Instituição parece ter criado um segundo laço de monitoramento e controle executado pelo nível hierárquico imediatamente superior, que amparado em indicadores e em aspectos humanos observa a saúde do método que é aplicado àquele projeto específico. Dessa forma, é delineado um ciclo de controle de laço duplo, conforme a Figura 4.

Figura 4 – Modelo de Monitoramento e Controle para projetos sob o Scrum

O modelo apresentado parte de um processo de trabalho que gera um produto, no caso um software. Um primeiro ciclo de monitoramento e controle é executado pelo Scrum Team

Processo Produto Gerência Tática Automonitoramento Autocontrole Monitoramento e Controle externos GP PO Equipe

que, baseado na evolução do produto, pode atuar em modificações pontuais do processo de trabalho para ajustar problemas de desempenho. Ainda que esse ciclo seja orquestrado pelo GP, há um forte coletivismo nas ações, que envolvem toda a equipe, caracterizando processos de automonitoramento e o autocontrole.

A seguir, uma camada gerencial mais externa, pertencente ao nível tático da organização, engendra um segundo ciclo de monitoramento e controle, cujos insumos são os indicadores do processo e o contato direto com os envolvidos, em especial com o GP e o PO, respondendo, dessa forma, pelo monitoramento e controle externos. Nesse caso, quando o monitoramento demonstrar problemas de desempenho, o gestor pode atuar utilizando a sua influência sobre os envolvidos, ou substituindo profissionais que não estejam bem integrados ao processo.

O modelo desenvolvido foi submetido a um conjunto de cinco GP e GL para avaliação, onde os gerentes consideraram que o modelo reflete a realidade dos processos de monitoramento e controle na Instituição. No entanto, algumas considerações importantes foram tecidas. Primeiramente, foi colocado que, em algumas situações, o GP não atua de forma tão integrada à equipe. Isso ocorre principalmente em situações onde é estabelecida uma distinção entre os papéis de SM e GP, ficando o SM em uma posição de intensa interação com a equipe e o GP assumindo o papel de monitoramento e controle externos. Além disso, foi destacado que o PO tem um papel especial no ciclo interno de monitoramento e controle, visto que ele representa a coletividade da área de negócio, que, dessa forma, está presente nesse ciclo. Novamente tem-se uma situação onde a qualidade do um processo interno do Scrum depende da capacidade do PO atuar com efetividade.