ANÁLISE

A análise do estudo será realizada, comparando o framework apresentado anteriormente na Figura 9 e a aplicação da metodologia Scrum na prática, de forma a verificar as divergências existentes.

5.1.1.Pilares do Scrum

Ao analisar os três pilares do Scrum definidos por Schwaber e Sutherland (2013), percebeu-se que há divergências em todos os pilares no projeto:

• Transparência – Considerando que a estrutura da equipe foi dividida em equipes menores (funcional e DEV), a transparência muitas vezes fica comprometida, visto que os times não se comunicam a todo momento;

• Inspeção – Levando em conta a cobrança e a pressão por parte dos superiores e do cliente, não há tempo para inspeção pela equipe de DEV após o desenvolvimento de alguma funcionalidade. A inspeção é feita apenas pela equipe funcional ao testar a funcionalidade no APP;

• Adaptação – Devido a verticalidade do projeto, a equipe DEV muitas vezes não tem autonomia para realizar adaptações nas user stories sem aprovação prévia dos gerentes da equipe funcional.

5.1.2.Ciclos do Scrum

Conforme citado anteriormente, na prática existem três PO neste projeto e nenhum dos três faz parte do time DEV, trazendo um distanciamento entre os programadores e os PO. Além disso, a definição do que subirá em cada Sprint é definido pela gerente da equipe funcional e posteriormente é validado pelo gerente sênior do projeto, o que atrasa a definição de cada Sprint, além de não envolver o time Scrum nessas decisões.

O Scrum Master cumpre seu papel no projeto, afastando os impedimentos para a realização do trabalho do time, conforme definido por Carvalho & Mello (2012), porém na estrutura da equipe do projeto, o Scrum Master também ocupa a função de gerente da equipe DEV, o que lhe impõe poder hierárquico sobre os integrantes da equipe, contrariando a definição de Cohn (2011).

Analisando a duração das Sprints do projeto definida como duas semanas, é possível perceber que está dentro do período aceitável de uma a quatro semanas. Entretanto, a pressão e a cobrança causam falhas e consequentemente atrasos nas Sprints de alguns dias que passam a ter tamanhos diferentes. Assim, a despadronização no tamanho das Sprints prejudica a definição de velocidade do time Scrum.

5.1.3.Eventos do Scrum

Conforme a definição de Sabbagh (2013), existem alguns eventos necessários na metodologia Scrum, porém conforme analisado no projeto alguns destes não são seguidos de forma correta:

• Reunião de release planning – Por falta de tempo durante as Sprints, a reunião de release planning não é realizada no projeto;

• Sprint – Conforme citado anteriormente as Sprints não são padronizadas, ou seja, não possuem o mesmo tamanho;

• Reunião de sprint planning – A Sprint Planning ocorre normalmente no início de cada Sprint. Porém não é discutido detalhadamente cada item, pois o time Scrum sofre pressão com relação ao tempo de entrega e os integrantes do time não tem poder para vetar alguma user storie;

• Reunião de sprint review – Não existe uma reunião formal de Sprint review. Apenas são realizados testes de cada funcionalidade da Sprint pela equipe funcional;

• Reunião de sprint retrospective – Não é realizada regularmente ao final de cada Sprint pela falta de tempo;

• Daily Scrum – A Daily Scrum era realizada regularmente as 10h da manhã pelo time Scrum e foi de extrema importância na fase anterior ao Minimum Viable Product (MVP). Após subir a primeira versão do APP para produção, as reuniões não acontecem com tanta frequência. No entanto, sempre que ocorre, uma ata é escrita com linguagem natural. Isso facilita para que integrantes da equipe que não tenham participado da reunião possam se inteirar dos assuntos tratados na mesma.

5.2.RESULTADOS

Ao comparar o framework para a aplicação de metodologia Scrum apresentado na revisão bibliográfica e sua aplicação na prática no projeto estudado, chegamos a alguns resultados:

I. A aplicação da metodologia Scrum deve seguir um padrão seguindo o framework proposto.

Analisando o framework proposto na teoria, entende-se que cada reunião tem seu valor agregado e auxilia na evolução da equipe e do projeto. Ao deixar de lado reuniões como: Release Planning, Sprint Review e Sprint Retrospective, o time Scrum não tem tempo de analisar o trabalho feito e planejar as próximas etapas como maior eficácia.

II. A falta de treinamento prévio para toda a equipe do projeto sobre a metodologia Scrum dificulta a aplicação da mesma.

Considerando que apenas dois integrantes da equipe têm conhecimento aprofundado sobre a aplicação da metodologia Scrum, o cumprimento do framework teórico torna-se mais difícil e interfere na criação do ambiente propício para o desenvolvimento do Software.

III. O modelo de estruturação da equipe do projeto estudado afeta os pilares da metodologia Scrum.

Ao dividir a equipe do projeto conforme ilustrado na Figura 12, há uma falta de transparência entre as equipes, de forma que nem todos os envolvidos no projeto estão cientes dos acontecimentos.

Além disso, a inspeção não é realizada da maneira correta, a partir do momento em que apenas são realizados testes para as novas funcionalidades pela equipe funcional.

Por fim, devido a verticalidade do projeto, o time Scrum não possui autoridade para realizar as adaptações necessárias, de forma que as adaptações são definidas top down.

IV. Alguns dos princípios ágeis não estão sendo seguidos na aplicação da metodologia Scrum no projeto estudado.

De forma contrária ao quinto princípio ágil: “Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.”, existe no projeto estudado uma grande força hierárquica, o que dificulta a construção de um ambiente motivador para que o time Scrum realize o trabalho da melhor maneira possível.

Da mesma forma, o décimo primeiro princípio ágil: “As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.” remete à autoridade que o time Scrum deveria ter para se auto organizar. Porém, no projeto fica claro o descumprimento deste princípio, o que compromete a eficiência do projeto.

V. A falta de padronização na duração das Sprints compromete a medição de velocidade do time Scrum.

Conforme citado anteriormente, Cruz (2015) defende que a definição de velocidade é de extrema importância, pois esta determinará quantas Sprints o projeto deverá ter, além da duração total do projeto. Entretanto, a cobrança e a pressão sob o time Scrum dificultam a padronização da duração das Sprints, as quais sofrem constantes atrasos, o que pode ser um indício de que o planejamento está sendo mal executado ou que o escopo está inadequado para a duração da Sprint. Assim, a medição da velocidade do time fica comprometida.

5.3.RECOMENDAÇÕES

Nesta seção serão apresentadas algumas recomendações para possível melhoria na aplicação da metodologia Scrum no projeto, baseadas nos resultados obtidos com o estudo. Vale ressaltar que as recomendações não garantem a solução para os problemas encontrados:

I. Ao iniciar um projeto, toda a equipe deveria passar por um treinamento intensivo sobre a aplicação da metodologia Scrum e de forma mais geral sobre as metodologias ágeis de desenvolvimento de Softwares. Assim, a equipe estaria mais engajada com os princípios ágeis e possibilitaria um maior cumprimento do framework teórico.

Vale ressaltar que a empresa Alpha já possui uma plataforma online global de aprendizagem, pela qual todos os funcionários tem a possibilidade de aprofundar o conhecimento em algum assunto específico. Dessa forma, para a implementação de um treinamento intensivo sobre a aplicação da metodologia Scrum seria necessário apenas elaborar o curso e torná-lo obrigatório para todos os funcionários que forem participar de algum projeto em que a metodologia Scrum for aplicada.

Nesse sentido, seria interessante elaborar dois cursos com vertentes diferentes: • Certificação da metodologia Scrum para desenvolvedores – Este curso

teria uma intensidade e duração maior (12 horas), visto que os integrantes dos times Scrum necessitam um conhecimento mais aprofundado sobre a metodologia. Ao final do curso, os funcionários realizariam uma prova para avaliar o nível de aprendizagem, gerando um certificado para cada um que concluísse o curso com sucesso.

• Curso de aplicação da metodologia Scrum para demais funcionários – Este curso teria uma intensidade e duração menor (04 horas), a fim de que os demais funcionários fossem capazes de absorver as informações básicas necessárias, de forma auxiliar as equipes de desenvolvedores nos projetos que utilizem a metodologia Scrum.

Para a elaboração dos dois cursos seria necessário contratar uma equipe especializada em cursos online para gravar as aulas e organizar o conteúdo em forma de uma apostila digital que os funcionários poderiam baixar e realizar consultas futuras ao material. Com isso, a empresa Alpha teria um custo inicial de R$ 50.000,00, conforme consulta a fornecedores deste serviço, para a elaboração dos dois cursos juntos e posteriormente um custo Homem x Hora (HH) com cada funcionário que realizasse o curso, visto que a empresa teria que pagar pelas horas

em que os funcionários estão realizando o curso e não estão alocados em projetos. Abaixo temos uma estimativa média do custo com cada nível de funcionário:

• Estagiário – R$ 16,70/hora • Analista – R$ 28,00/hora • Consultor – R$ 50,00/hora • Gerente – R$ 75,00/hora

O custo com cada curso por cargo pode ser melhor observado na Tabela 1. Tabela 1: Custo cursos por cargo

Fonte: Autor, 2019

Como estimativa foi considerado que a empresa Alpha atuará aproximadamente em 50 projetos no próximo ano no Brasil, que utilizem a metodologia Scrum. Cada projeto é formado por uma equipe funcional e uma equipe DEV com no mínimo um estagiário, um analista e um consultor cada. Vale ressaltar que cada gerente, funcional e DEV, é responsável por dois projetos simultâneos. Nesse sentido, os custos indiretos com HH seriam de R$ 105.760,00. Assim, o custo total estimado com a implementação do treinamento seria de R$ 155.760,00. Vale ressaltar que o cronograma desta implementação não poderá iniciar imediatamente, visto que o projeto está em andamento e interferirá nos prazos alinhados previamente com o cliente. Assim, será necessário esperar o término deste projeto, que está previsto para julho de 2020, para contratar uma equipe especialista para desenvolver o treinamento. O prazo para a elaboração dos dois cursos é de seis meses.

Assim, a partir de janeiro de 2021, os cursos estarão disponíveis na plataforma online de treinamento da empresa Alpha para todos os funcionários que participarão de algum projeto envolvendo a aplicação da metodologia Scrum.

Cargo HH Curso 04 horas Curso 12 horas

Estagiário R$ 16,70 R$ 66,80 R$ 200,40 Analista R$ 28,00 R$ 112,00 R$ 336,00 Consultor R$ 50,00 R$ 200,00 R$ 600,00 Gerente R$ 75,00 R$ 300,00 R$ 900,00

II. Uma restruturação do modelo de equipe para os próximos projetos, de forma a facilitar a transparência entre a equipe e reforçar a horizontalidade do projeto, definindo melhor as funções de cada integrante.

III. Permitir uma maior autoridade para o time Scrum sobre as decisões durante as Sprints. Além disso, o time deveria ter a possibilidade de se auto organizar da melhor forma que desejassem, criando um ambiente favorável ao desenvolvimento de Software e uma busca contínua pela maior eficiência do time.

IV. Uma reavaliação da duração das Sprints, de forma a estabelecer um padrão cujo tempo seja suficiente para a equipe se organizar, planejar as Sprints e principalmente inspecionar as funcionalidades desenvolvidas. Além disso, realizar todas as reuniões necessárias para reavaliar o desempenho do time durante o período. Assim, seria possível medir a velocidade do time Scrum e realizar um melhor planejamento sobre a duração do projeto como um todo.

V. A fim de melhor estabelecer uma padronização na aplicação da metodologia Scrum em todos os projetos externos de desenvolvimento de Softwares, a empresa Alpha deveria organizar a área de gestão da mudança para instruir todas as equipes sobre a melhor aplicação da metodologia e um maior cumprimento do framework teórico e dos princípios ágeis.