PROCESSOS DE DESENVOLVIMENTO (HISTÓRIA)

O desenvolvimento deste trabalho inicia-se tendo como foco o Scrum, porém de acordo com pesquisas realizadas e documentadas no referencial teórico, identificamos que existe uma espécie de “janela” entre os modelos de desenvolvimento tradicional e ágil. Diversos autores defendem a importância de se documentar software, por outro lado, os defensores das MA defendem maior interação entre as pessoas para evitar “perda de tempo” em documentar.

Buscando a ponderação de ambos os lados, foi pesquisada uma forma que pudesse ser realizado o desenvolvimento ágil, mas que documentasse o que fosse necessário para garantir a entrega de um sistema que atendesse as necessidades do cliente. Diante disso, ao aprofundar um pouco mais no framework Scrum, foi verificado que por mais que defende-se que a interação entre as pessoas seja mais importante do que documentação, o Scrum não restringe documentar. Alguns autores mencionam o fato de se utilizar alguns diagramas da UML para apoiar o entendimento tanto do cliente quando da equipe que utilizará o Scrum para o desenvolvimento, desde que seja documentado apenas o que faz sentido para o projeto, para não perder a ideia de ágil.

Buscando uma forma de verificar se seria produtivo a utilização de diagramas da UML para apoiar um desenvolvimento Scrum, foi elaborado um projeto utilizando ambas as abordagens, justificando o uso de cada um dos três diagramas eleitos da UML, sendo eles o de caso de uso (para facilitar o entendimento do cliente

na validação, para servir de base para geração de histórias de usuário e para garantir que todos os pontos desejados do sistema tenham sido checados), o de classes (para apoiar a criação do modelo conceitual do banco de dados e facilitar o entendimento em nível técnico da organização das classes do sistema) e por fim, o diagrama de sequências (que permitiu melhor visualização do comportamento dos objetos do início ao fim do processo, ou seja, a ordem cronológica em que cada atividade deve ocorrer para atender a necessidade da funcionalidade).

O início do levantamento das necessidades foi realizado através de entrevista com a proprietária da cantina (cenário case utilizado para aplicar este trabalho). Esta entrevista inicial possibilitou explorar como eram os processos da cantina, quem os executava e quais eram as dificuldades que eles tinham. Além disso, notou-se que a própria proprietária da cantina que era a pessoa que tinha o conhecimento de todos os processos da cantina, teve dificuldades para expressar o que ela de fato precisava para solucionar algumas dificuldades, mas durante a conversa, foi possível mapear estas necessidades para compor uma documentação inicial que posteriormente seria compilada e serviria de subsídio para a geração da documentação.

Com as informações obtidas nesta entrevista, foram identificados os requisitos, regras, atores e casos de uso. Em seguida, foram elaborados os casos de uso e posteriormente, as histórias de usuário. Nesta etapa, notou-se a facilidade em escrever as histórias após ter escrito os casos de uso, visto que os casos de uso utilizam uma linguagem de fácil compreensão a nível de usuário e demonstram os diferentes cenários de uma funcionalidade, permitindo realizar uma análise minuciosa se todos requeridos foram levados em consideração. A partir de então, os critérios de aceitação foram facilmente descritos visto que os requisitos funcionais e regras de negócio expressaram bem as necessidades que deveriam ser cobertas para que a funcionalidade pudesse atender as necessidades da proprietária da cantina.

Com a documentação inicial levantada, foi marcada uma nova entrevista com a proprietária da cantina para que ela pudesse verificar e validar. Caso necessitasse de algum ajuste ou tivesse faltando algo que não foi informado na primeira entrevista, este poderia ser realizado antes de iniciar o desenvolvimento. A documentação (requisitos, regras, casos de uso, histórias e critérios de aceitação) foi apresentada e, como havia uma documentação mais palpável, ela pôde visualizar

os protótipos e ter uma melhor noção de como seria o sistema. Essa visualização permitiu que ela validasse a documentação com mais segurança de que de fato a necessidade dela havia sido compreendida, o que permitiu então seguir para próxima etapa do projeto.

Com apenas a documentação inicial que foi levantada, faltava ainda detalhes técnicos para que o time de desenvolvimento melhor compreendesse como o sistema deveria se comportar. A partir de então, foram elaborados os diagramas de classes e de sequência, os quais permitiram uma melhor visibilidade técnica da arquitetura e comportamento do sistema.

Com uma documentação mais enxuta, buscando demonstrar apenas o que fosse essencial, foi realizado a seguir a lista do Product Backlog para então iniciar as sprints do Scrum.

Na primeira reunião do ciclo Scrum, a Sprint Planning, o PO apresentou as histórias, contextualizou o time de desenvolvimento e apresentou os documentos elaborados anteriormente com os diagramas da UML. Os desenvolvedores tiveram mais facilidade para entender cada funcionalidade a ser realizada já que o documento é bastante detalhado tanto a nível de usuário, quanto a nível técnico. Assim ficou mais claro quais funcionalidades caberiam em uma determinada sprint e facilitou a estimativa de o tempo de execução de cada tarefa.

O próximo passo foi desenvolver as tarefas escolhidas para a sprint. O desenvolvimento seguiu sem grandes problemas, visto que trata-se de um sistema simples, com regras não tão complexas e que a documentação produzida supriu as eventuais dúvidas que poderiam vir a surgir. Todas as sprints foram finalizadas no prazo determinado na Sprint Planning e acredita-se que isso se deve ao bom planejamento das sprints e aos documentos da UML que auxiliaram os desenvolvedores em diversos momentos. Ao longo do desenvolvimento foram feitas as reuniões diárias que foram muito importantes, pois ajudaram os desenvolvedores a prosseguir e se manterem atualizados na implementação do sistema e até apoiar um ao outro para a entrega das tarefas dentro do prazo.

Todas as reuniões da Revisão da Sprint foram bastante produtivas, pois o sistema era apresentado para a proprietária da cantina e a equipe, com isso surgiam debates em relação ao funcionamento do sistema e consequentemente novas sugestões de melhorias futuras. Além disso, este tipo de reunião foi importante para

o time de desenvolvimento verificar o resultado do planejamento da sprint e receber

feedbacks.

Por fim, a última fase do ciclo da sprint, foi a reunião de retrospectiva da

sprint em que a equipe discutiu os pontos fortes e fracos que aconteceram ao longo

da sprint corrente. Foi uma reunião muito importante, pois contribuiu com as sprints sucessoras de tópicos que deveriam ser melhorados ou simplesmente descontinuados, pois não estavam funcionando.

O Scrum é umas das metodologias ágeis mais usadas atualmente pelas empresas como já foi relatado nos tópicos anteriores, e ao longo deste trabalho foi possível perceber o porquê disso. Porque é simples, eficaz e principalmente, é ágil. O Scrum permite entregas frequentes ao usuário e por isso aumenta satisfação do mesmo, já que é possível utilizar o sistema enquanto ainda está em desenvolvimento e isso também leva a receber feedbacks frequentes do cliente para saber se o projeto está no caminho certo ou se precisa ser interrompido e ajustado. É possível também ter uma transparência durante todo o desenvolvimento em que a equipe consegue acompanhar cada passo do ciclo da sprint e verificar seu progresso. Cada etapa da sprint orienta a equipe no que deve ser feito naquele momento e é importante segui-lo, pois trará uma grande produtividade no projeto, resultando em uma equipe mais motivada, melhoria contínua no processo e correção de problemas.

Durante todo esse processo de desenvolvimento foi possível perceber o quanto os documentos da UML ajudou a equipe no desenvolvimento do sistema. Foi muito útil no início, pois permitiu uma visão ampla e um melhor entendimento do produto por parte do usuário e do time de desenvolvimento. A documentação da UML permitiu economizar tempo para verificar regras e comportamentos que o sistema deveria ter, uma vez que a indisponibilidade do PO no momento do desenvolvimento poderia causar atrasos. A documentação da UML continuará sendo útil também após a finalização do sistema, pois será mais fácil realizar manutenções e realizar repasses para novos integrantes da equipe por possuir detalhes técnicos e de negócio.