ABA SPRINT

A aba Sprint contém alguns dados do sprint que são utilizados para automatizar algumas operações da planilha. As colunas Início e Fim servem para o preenchimento automático dos cabeçalhos das colunas dos dias do sprint. A coluna Hoje é utilizada para destacar a coluna correspondente ao dia corrente. A coluna Feriados é utilizada para que as datas dessas colunas não sejam adicionadas nos cabeçalhos da aba Atividades. A Figura 52 mostra o conteúdo da aba Sprint da planilha template.

Figura 52 - Aba Sprint da planilha template

4.7.8 ABA REF

A aba REF contém informações auxiliares para compor as opções de preenchimento de algumas células da planilha. A coluna responsável contém a lista de pessoas que poderão trabalhar no sprint, isto é, o time. A coluna TIPO contém as opções de preenchimento do tipo da atividade. A coluna Status contém as opções de preenchimento do status da atividade. A Figura 53 exibe o conteúdo da aba REF da planilha template.

Figura 53 - Aba REF da planilha template

5 RESULTADOS

Neste capítulo, apresentamos os resultados da pesquisa-ação, comparando o processo de desenvolvimento do SIGRH antes e depois da implantação do Scrum e da planilha de acompanhamento de desenvolvimento de sistemas. Também são enumeradas as lições aprendidas, que serão úteis para aplicá-las em trabalhos futuros.

A primeira análise realizada foi sobre mudanças no processo de desenvolvimento com a implantação do Scrum, comparando alguns aspectos importantes no desenvolvimento de um sistema informatizado. O Quadro 1 mostra essas mudanças.

Quadro 1 - Antes e depois da implantação do Scrum

Item Antes Depois

Responsabilidade pelo projeto O gerente de projetos é o único responsável pelo controle do projeto.

Todos os membros do time tem a responsabilidade sobre projeto, se comprometendo com o seu sucesso.

Gerenciamento de riscos O gerente de projetos é o único responsável pela gerência de riscos.

Todos os membro do time assumem os riscos e encontram soluções em conjunto.

Comunicação com o cliente O gerente de projetos e o analista de requisitos se comunicam com o cliente. Geralmente, apenas em reuniões antes do início do desenvolvimento.

O product owner representa o cliente durante todo o

desenvolvimento. A comunicação é diária.

Entregas Não havia um planejamento prévio sobre as datas para as entregas.

As entregas são realizadas mensalmente.

Progresso Não havia forma de visualizar o progresso. A única forma de medir o progresso era quando uma entrega era realizada.

O progresso pode ser visualizado a qualquer momento por todos da equipe.

Revisão do processo Não havia revisão do processo. O processo é revisado ao final de cada sprint.

Priorização das demandas O gerente de projetos definia a ordem de desenvolvimento das demandas. Muitas vezes sem o conhecimento do cliente.

O product owner, representante do cliente, define a ordem de desenvolvimento das demandas, priorizando o que irá agregar maior valor ao produto. Fonte: Autoria própria (2017)

Além disso, pôde ser constatada pelo pesquisador uma melhoria na integração entre os membros da equipe. A comunicação constante e o objetivo comum de concluir as demandas no prazo aumentou a colaboração consideravelmente. Antes, cada

desenvolvedor era responsável pelas suas demandas individuais e havia pouca colaboração. Outro fator que merece ser destacado foi o aumento da motivação da equipe com o uso do Scrum. Com as entregas frequentes das demandas, é possível ver o resultado do trabalho mais rapidamente. Com isso, a equipe passou a se sentir mais produtiva e, consequentemente, mais motivada.

A seguir, são listados alguns pontos que foram consenso geral entre os membros da equipe:

● A implementação do Scrum no processo de desenvolvimento do SIGRH foi uma decisão acertada, por ter seu foco nos resultados, na comunicação entre os membros da equipe e na interação com os gestores da instituição e usuários;

● O uso de uma ferramenta de colaboração para o acompanhamento do processo tornou viável a implantação do Scrum com as limitações do ambiente físico apresentadas;

● As oficinas utilizadas na elaboração da ferramenta de acompanhamento de processo de desenvolvimento do SIGRH facilitou a comunicação entre os usuários e o projetista, que nesse caso foi o próprio pesquisador, e a identificação das funcionalidades necessárias. Desde a primeira iteração, foi possível perceber a comunicação direta e aprofundada entre o projetista e os usuários;

● Todos devem estar cientes de que sua participação e opinião são essenciais para que não haja qualquer tipo inibição;

● A participação dos usuários na construção leva a uma aceitação mais fácil da ferramenta;

● O uso do burndown chart de 30 dias confundiu o time, já que considerava também os fins de semana e feriados, que não eram dias de trabalho e, portanto, a sua média de consumo não refletia a realidade;

● O uso do gráfico Horas x Membro, no quarto sprint, que contabilizava as horas trabalhadas, causou desconfiança no time, já que o time era muito heterogêneo em relação ao horário disponível para o sprint. Além disso, as tarefas tinham complexidades diferentes e, portanto, poderia causar

desmotivação no time. O scrum master passou a monitorar as horas de cada membro, mas não exibir o gráfico na aba Dashboard;

● Alguns membros do time trabalhavam em horários diferentes e isso dificultou a realização das daily meetings. Algumas vezes foi necessário fazer a daily meeting mais de uma vez no dia.

Durante as iterações da pesquisa-ação, foi possível coletar as seguintes lições aprendidas:

● Qualquer ação para ajudar a melhorar a integração da equipe foi considerada como positiva. Música no ambiente de trabalho e as reuniões sociais em locais fora do ambiente de trabalho ajudaram neste aspecto; ● Não deve haver diferenças no nível de responsabilidade e comprometimento

entre os membros da equipe. Ninguém é mais ou menos importante dentro da equipe;

● Não deve haver restrição na comunicação entre o scrum master, o product owner e o time;

● Qualquer mudança no processo deve ser uma decisão em conjunto com todos os membros da equipe;

● A equipe é quem deve definir sua capacidade de produção na escolha das demandas do sprint, mesmo que haja pressão do product owner ou dos stakeholders para aumentar o sprint backlog;

● O tempo de correção de erros deve ser considerado na estimativa do custo de uma tarefa. Esse aspecto não foi levado em conta nos primeiros sprints, o que levou ao não cumprimento do prazo estabelecido.