Nesta seção é apresentada a descrição do processo atual realizado pela empresa para estimar as tarefas, respondendo assim a seguinte questão de pesquisa:
QS2. Qual o processo atual realizado pela empresa para estimar as tarefas?
Para responder esta questão foram estabelecidas perguntas no questionário da pesquisa de campo que possibilitou coletar as informações necessárias. O pesquisador também acompanhou presencialmente utilizando a técnica de observação participante, as várias etapas do processo ao longo de uma sprint, podendo assim confrontar as respostas dos entrevistados
com a prática realizada. O processo foi descrito e mapeado utilizando a notação BPMN (Business Process Management Notation). Para o mapeamento foi utilizada a ferramenta Bizagi.
Após interpretar as várias respostas dos entrevistados, observou-se que a empresa possui fases no ciclo de desenvolvimento, envolvidos no processo e uma sequência de etapas do processo que são citados e descritos a seguir. A empresa possui um ciclo de desenvolvimento distribuído em 5 fases:
• Levantamento dos requisitos; • Planejamento da sprint; • Execução da sprint; • Revisão;
• Disponibilização de versão.
Também foi observado que a empresa possui os seguintes envolvidos no processo, com as seguintes responsabilidades:
• Cliente: solicita a sprint para a equipe de desenvolvimento, apresenta as necessidades desejadas e ao final do ciclo homologa os requisitos através de testes de aceitação; • Chefe de desenvolvimento: responsável por esclarecer dúvidas quanto as necessidades
do cliente, especifica os requisitos, faz parte da equipe de desenvolvimento participando das atividades de planejamento da sprint, realização das estimativas e desenvolvimento das tarefas;
• Equipe de desenvolvimento: responsável por implementar, corrigir ou alterar as funcionalidades. Os membros da equipe participam das atividades de estimativa e desenvolvimento das tarefas;
• Responsável pelos testes: responsável por testar e validar as funcionalidades que posteriormente serão entregues ao cliente para a homologação.
A seguir são descritas as atividades que fazem parte do processo que a empresa estudada utiliza para o desenvolvimento de uma sprint. Na Figura 4.2 é apresentado o mapeamento
61
deste processo utilizando a notação BPMN. A letra "d"nomeada como estimativa das tarefas foi definida e detalhada como um subprocesso, sendo apresentada na Figura 4.3.
a. Apresentação das necessidades desejadas: é realizada uma reunião na qual o cliente expressa suas necessidades. O chefe de desenvolvimento solicita ao cliente o preenchimento e envio de uma planilha contendo o detalhando dos requisitos desejados. Nesta reunião participam o cliente, o chefe de desenvolvimento e a equipe de desenvolvimento;
b. Envio das funcionalidades desejadas: o representante do cliente envia uma planilha com formato pré-definido para o chefe da equipe de desenvolvimento com a descrição dos requisitos;
c. Definição das tarefas: o chefe de desenvolvimento analisa os requisitos enviados pelo cliente e reescreve-os na forma de tarefa de software.
d. Realizar estimativa das tarefas da sprint: o chefe e a equipe de desenvolvimento reúnem-se para estimar o tempo das tarefas a serem implementadas. A seguir é apresentada a sequência de etapas deste subprocesso que foi representado na Figura 4.3:
i. Verificar se todos tem experiência quanto ao sistema: nesta atividade o chefe de desenvolvimento analisa a situação da equipe quanto a experiência no sistema. Se toda a equipe tem conhecimento desejável quanto ao sistema, é utilizada a técnica planning poker, senão, o chefe de desenvolvimento apresenta a sua estimativa da tarefa e os demais desenvolvedores apresentam suas opiniões, discutem as possíveis dúvidas e podem sugerir alterações na estimativa da tarefa;
ii. Apresentação da tarefa para a equipe: esta etapa ocorre caso a equipe tenha conhecimento desejável quanto ao sistema. Assim o chefe de desenvolvimento apresenta a tarefa a ser executada, tira as dúvidas dos demais desenvolvedores e após é iniciado o planning poker;
iii. Aplicar planning poker: cada membro tem as cartas do planning poker, para cada tarefa todos os membros definem uma estimativa, discutem sobre as estimativas e chegam a um consenso em torno da quantidade de horas;
iv. Apresentação da tarefa e sua estimativa para a equipe: o chefe de desenvolvimento detalha a tarefa para a equipe e dá seu parecer quanto à quantidade de horas para realizar
a determinada tarefa, oferecendo uma base para os demais desenvolvedores e ao mesmo tempo influenciando em suas estimativas. Os demais desenvolvedores buscam entender a tarefa e opinam em relação a escolha da estimativa, de modo a chegar num consenso quanto ao tempo de realização da tarefa;
v. Opinar em relação à estimativa apresentada: caso os membros discordem ou concordem com as estimativas, podem defender seus argumentos em relação a estimativa apresentada pelo chefe de desenvolvimento;
vi. Verificar se existem mais tarefas a serem estimadas: define quando o processo de estimativas termina. Enquanto existirem tarefas a serem estimadas, o processo se repete. No momento em que todas as tarefas foram estimadas estão prontas para serem enviadas ao cliente;
vii. Encerrar o processo de estimativas: chefe de desenvolvimento encerra o processo informando que as estimativas das tarefas serão enviadas para o cliente, juntamente com a quantidade de horas disponíveis para a realização da sprint;
e. Envio das estimativas para o cliente: após estimadas todas as tarefas a quantidade de horas de todas as funcionalidades é somada e definido o tempo disponível para a equipe trabalhar na sprint. Assim sendo, pode ocorrer de não serem implementadas todas as tarefas, mas apenas as que que forem as escolhidas dentro do tempo disponibilizado naquela sprint. Estas informações são enviadas para o cliente;
f. Definição das tarefas a serem implementadas: o cliente define quais tarefas são prioritárias e devem ser implementadas na sprint atual;
g. Recebimento das tarefas a serem implementadas: o chefe de desenvolvimento recebe o retorno do cliente com as tarefas a serem desenvolvidas na sprint;
h. Adicionar as tarefas ao Redmine: o responsável pelos testes adiciona as tarefas ao Redmine, contendo o código da tarefa, status (andamento, aguarda teste, em teste, entre outros), descrição, notas diárias do que foi desenvolvido, desenvolvedor responsável pela tarefa, quantidade de horas estimadas e realizadas;
i. Desenvolvedor seleciona a tarefa a ser implementada: cada desenvolvedor escolhe uma tarefa no qual tem mais conhecimento e experiência para implementar;
63
j. Desenvolver tarefa: neste momento ocorre a programação (implementação) da tarefa e atualização no Redmine com o decorrer do desenvolvimento, no qual são acrescentadas notas relacionadas às tarefas contendo detalhes de implementação, regras que foram seguidas, entre outras informações;
k. Testar a tarefa e fazer validações: no momento em que cada tarefa é desenvolvida ela está pronta para testes, os quais são realizados pelo responsável pelos testes. O setor de testes realiza as verificações/validações necessárias. Após possíveis correções, a tarefa novamente é enviada para esta etapa. O responsável por testes constata no Redmine os problemas e situações encontrados nos testes;
l. Verifica se a tarefa possui defeitos: caso o responsável de testes encontrou defeitos ou correções a serem realizadas, é encaminhada para a etapa de correção de defeitos, este ciclo ocorre até que a tarefa esteja correta. Caso a tarefa não possui defeitos, recebe o status de concluída e aguarda homologação do cliente. Os desenvolvedores acessam o Redmine para saber qual é defeito da tarefa e após corrigida inserem notas relacionadas a correção da tarefa;
m. Corrigir defeitos e realizar alterações: ocorre quando correções ou possíveis alterações são solicitadas pelo cliente ou responsável de testes;
n. Tarefa concluída e aguardando homologação: permanece neste estado até que todas as tarefas da sprint tenham sido concluídas, para testes posteriores pelo cliente;
o. Análise se existem mais tarefas a serem desenvolvidas: caso existam tarefas a serem desenvolvidas, retorna para a etapa da definição de uma tarefa para implementar. Caso não existam mais tarefas a serem feitas, ocorrem paralelamente as atividades de reunião de retrospectiva e atividade de homologação do cliente;
p. Reunião de retrospectiva: a equipe se reúne para discutir referente as situações encontradas durante a última sprint e definir melhorias para as sprints posteriores;
q. Atividade de homologação pelo cliente: permite ao cliente testar e ver se é aquilo mesmo que ele esperava das funcionalidades. Para a homologação dos requisitos pelo cliente é enviado um email a ele relatando quais funcionalidades foram desenvolvidas e o link para o cliente testar. Após a homologação, o cliente retorna um email apresentando as correções necessárias e as tarefas que não possuem correções automaticamente estão aprovadas;
r. Analisa se atende a necessidade: se as tarefas cumprem o que deveriam fazer vão para a fase de implantação, senão é analisado a quantidade de correções a serem realizadas; s. Analisa se existem muitas correções e alterações: caso sejam poucas correções
necessárias, a equipe contorna a situação realizando as correções, caso existam várias correções ou alterações, não são realizadas nesta sprint e somente os requisitos aprovados vão para implantação;
t. Informa cliente caso não seja possível corrigir nesta sprint: quando a quantidade de correções é grande e exige muito tempo, deve ser solicitada uma nova sprint para realizar as correções e possíveis tarefas que não foram desenvolvidas na sprint atual;
u. Implantação dos requisitos aprovados: Após o cliente homologar as funcionalidades atendendo assim a suas necessidades, o chefe de desenvolvimento juntamente com outros membros da tecnologia de informação da empresa implantam as novas funcionalidades no sistema que está em funcionamento.
67
4.7 Considerações finais
Durante a pesquisa de campo através das entrevistas ou por meio da observação participante no qual foi acompanhado o processo completo de uma sprint, observou-se algumas situações e foram estabelecidos pontos de reestruturação do processo atual, conforme apresentado na Tabela 4.5.
Situações identificadas na pesquisa de campo
Nem todos os membros tem o mesmo conhecimento referente aos fatores levados em consideração para estimar.
Tarefas que foram subestimadas ou superestimadas, o que causou significativos desvios no gráfico burndown. Raramente os dados do Redmine são consultados para realizar estimativas das sprints posteriores.
Dados são armazenados no Redmine de forma não estruturada, ou seja, sem categorias de classificação, impedindo
uma busca eficiente na base.
Tabela 4.5: Situações identificadas na pesquisa de campo
No momento das estimativas o que cada membro aborda sobre a tarefa estimada, são os fatores que em seu parecer interferem nas estimativas, porém considerando membros que não tem conhecimento em relação a algum dos fatores, não terá condições de opinar em relação à estimativa da tarefa. Deste modo, visando reduzir a incerteza durante o processo de estimativas, mais informações sobre tarefas similares permitiriam aos membros menos experientes melhores condições para estimar corretamente.
A atividade de estimar corretamente, mesmo sendo considerada fácil ou média pelos membros entrevistados, apresenta alguns problemas uma vez que ocorreram desvios no gráfico burndown. Isso indica que algumas tarefas foram subestimadas ou superestimadas fenômeno que normalmente acontece perante o desenvolvimento de software, porém é essencial que esta incerteza diminua com o passar do tempo e possibilite avanços no processo de estimativa nas empresas.
Manter informações armazenadas ao longo dos projetos de desenvolvimento de software é importante para possibilitar a análise de tarefas similares realizadas anteriormente. Estas informações teriam mais utilidade caso fossem consultadas constantemente visando reduzir falhas ou dificuldades encontrados ao longo processo de estimativa.
as mesmas. Porém, não possui muitos filtros de busca ou categorização de tarefas, assim dificultando meios de busca agilizada na base, pois de acordo com a responsável pelos testes da empresa que insere as tarefas no Redmine, a única forma de busca existente é pela descrição.
Além dos fatores apresentados anteriormente referente as constatações da pesquisa de campo com as entrevistas e observação participante, alguns fatores que interferem nas estimativas convergem com o resultado da revisão sistemática da literatura como por exemplo: experiência dos membros com o sistema que estão desenvolvendo e com tarefas semelhantes, o tamanho e a complexidade da tarefa, observando-se que estes problemas são comuns nas empresas de software que utilizam métodos ágeis.
Através dessas análises, foi possível propor a reestruturação do processo atendendo especificamente a situação atual da empresa estudada.
69
5 PROPOSTA DE REESTRUTURAÇÃO DO PROCESSO
Este capítulo apresenta a proposta de reestruturação do processo de estimativas da empresa estudada, buscando assim, responder a QS4 de pesquisa:
• Como reestruturar o processo de estimativa de tarefas utilizado pela empresa, buscando amenizar os fatores que interferem na precisão das estimativas de tarefas e considerando uma base histórica de estimativas, sem deixar de atender aos princípios ágeis?
Para responder a esta questão foram utilizados os resultados da revisão da literatura e da pesquisa de campo, através dos quais foi possível identificar fatores que interferem nas estimativas das tarefas em projetos de software que utilizam o método ágil Scrum e mapear o processo atual realizado pela empresa, identificando possíveis alterações a serem realizadas.