Metodologias de Desenvolvimento Ágil – Parte 5: Estudo de Caso


Metodologias AgeisEsta é a quinta parte da série de artigos sobre Metodologias de Desenvolvimento Ágil. Estes artigos são baseados no Trabalho de Conclusão de Curso apresentado como exigência para a obtenção do grau de Bacharel em Ciência da Computação da Faculdade Anhanguera de Campinas – Unidade 3, denominado “Metodologias de Desenvolvimento Ágil Aplicadas No Desenvolvimento De Softwares Em Empresas De Pequeno Porte“, escrito por Felipe Morandin, Fernando Fonte e Tiago Souza.

Espero que você aproveite a leitura.

3 – Estudo de Caso

3.1 – Apresentação

O estudo de caso representa o resultado de um sprint de duas semanas dentro de um projeto de desenvolvimento de software, com fins comerciais, utilizando a metodologia ágil Scrum durante um período de oito semanas.

Por se tratar de um projeto comercial protegido por um acordo de sigilo, as informações apresentadas abaixo foram modificadas para preservar os dados relativos ao cliente e de modo que os acontecimentos e resultados apresentados não sejam distorcidos. Para isso serão utilizadas metáforas com o objetivo de descrever características do projeto sem revelar informações reais do cliente.

Os procedimentos abaixo apresentam uma das etapas do desenvolvimento que foi divido em quatro partes, a etapa descrita abaixo está dividida nos seguintes tópicos: Planejamento, Desenvolvimento e Considerações Finais.

3.2 – Modelo conceitual do projeto

O projeto que será apresentado abaixo faz parte de uma campanha publicitária de uma empresa especializada em vendas de produtos de varejo. A campanha em questão foi veiculada durante Julho de 2009. Através de um site voltado para os seus clientes, a empresa em questão incentivava os filhos a enviarem mensagens homenageando seus pais. A homenagem poderia ser enviada através de mensagens de texto e mensagens de áudio, ambas as mensagens eram enviadas para o telefone informado no site.

3.3 – Planejamento

Para iniciar um projeto utilizando metodologias ágeis é preciso fazer o planejamento inicial, que, por sua vez, pode levar alguns dias para ser concluído. Esse tempo é necessário para que todos os envolvidos com o projeto tenham entendido claramente o objetivo do projeto. É nessa fase que são definidas todas as diretrizes técnicas, regras de negócio e papéis de cada integrante do time.

3.3.1Estórias

Abaixo temos o Product BackLog com as estórias apontadas pelo cliente e suas prioridades, elas serão discutidas durante a Planning Meeting I (descrita no tópico abaixo) e todas as dúvidas são levadas ao cliente e devem ser solucionadas antes do inicio do desenvolvimento.

Enviar homenagens para o pai

10

Entrar em contato com a empresa

40

Visualizar a mensagem que foi enviada para o pai a qualquer momento

20

Avisar o pai sobre a mensagem via SMS[1]

30

Avisar o pai sobre a mensagem via TTS[2]

35

Enviar várias mensagens para destinatários diferentes.

25

Conferir o regulamento da campanha

60

Buscar e visualizar mensagens de qualquer participantes

50

Usuário deve se cadastrar

15

Tabela 2 – Product Backlog

3.3.2Planning Meeting I

Durante a Planning Meeting I o PO apresenta o Product Backlog para a equipe de desenvolvimento do projeto levantar os pontos de complexidade e gerar o Sprint Backlog. Como foi a primeira vez o time não estava acostumado a fazer estimativas usando pontos de complexidade muitos dos integrantes do time começaram a estimar fazendo uma relação entre os pontos de complexidades e as horas que seriam gastas realizando cada estórias.

Outro problema que aconteceu, e que é comum nas primeiras plannings, foi que o time não acertava as estimativas na primeira tentativa, e, em algumas estórias, foi preciso mais que três tentativas para que o time entrasse em um acordo sobre a complexidade de uma história. Como era de se esperar, a reunião não acabou no tempo programado, levando, ao invés de 2 horas, 3 horas.

Abaixo temos o Sprint Backlog no qual a equipe mapeou as tarefas para o primeiro Sprint e definiu o grau de complexidade de cada uma.

ID

Nome

Importância

Estimativa

Critério de aceitação

Notas

1

Usuário deve se cadastrar

100

5

Criar usuário;Alterar usuário;Apagar usuário;Efetuar login;Efetuar logoff; Deve ser utilizada criptografia MD5[3].

2

Enviar homenagens para o pai

70

30

Cadastrar mensagem;Enviar mensagem; Usuário deve estar logado

3

Visualizar a mensagem que foi enviada para o pai a qualquer momento

50

30

Visualizar mensagem;Buscar mensagem;Exibir mensagem selecionada;

4

Enviar várias mensagens para destinatários diferentes.

60

20

Cadastrar mensagem;Informar destinatários múltiplos;Enviar mensagem;

5

Avisar o pai sobre a mensagem via SMS

80

40

Integração com webservice de SMS;Validar dados para integração;Salvar dados enviados;Salvar resposta do Webservice; Os dados devem ser validados conforme especificação técnica.

Tabela 3 – Sprint BackLog

3.3.3Planning Meeting II

Durante a Planning Meeting II para a definição do Sprint Backlog os integrantes da equipe definiram as tarefas que formaram o Board e o Burndowns, mas a falta de costume com o desenvolvimento ágil fez com que a definição das tarefas não fosse precisa.

Como era de se esperar para a segunda planning, o numero de Tarefas definidas não foi suficiente para finalizar as Users Stories do Sprint, mas durante o dia-a-dia eram incluídas novas Tarefas para que fosse possível cumprir as Users Stories.

3.4 – Desenvolvimento

A partir do final da Planning Meeting II a equipe já pode começar a desenvolver, mas como as duas Plannings foram feitas em seqüência a equipe não teve tempo para trabalhar nas tarefas no mesmo dia então o resto do dia foi utilizado para montar os boards com os gráficos e as tarefas.

3.4.1Stand-Up

Em um determinado período foi feita a Stand-Up, na qual os integrantes da equipe apresentaram as suas tarefas que foram feitas, as próximas tarefas a serem feitas, as dificuldades encontradas e se algo está bloqueando a conclusão de uma determinada tarefa, mas devido a falta de experiência a Stand-Up leva um período maior que o estipulado, levando, ao invés de 15 minutos, 45 minutos, mas isso ocorre porque os integrantes começam a tirar dúvidas relacionadas a tarefas ou mesmo a falar de tarefas não relacionadas a este Stand-Up.

Ao final da Stand-Up o Scrum Master deve resolver os problemas apresentados pelos integrantes que estão bloqueando outras Tarefas . Ao resolver esses problemas o Scrum Master informa à equipe que já pode prosseguir com o desenvolvimento das Tarefas .

3.5 – Considerações Finais

Chegando ao último dia do Sprint é hora de fazer a demo e a retrospectiva. Na demo a equipe mostrou ao PO as Users Stories concluídas, ele por sua vez aprovou todas as Users Stories seguindo os critérios de aceitação e com o Sprint pode ser finalizado.

Durante a finalização da primeira etapa do projeto o cliente pôde validar algumas telas do projeto, essas telas por sua vez não apresentavam diagramação e ilustrações aprovadas pelo cliente, pois seriam implementadas nos próximos Sprints.

Nas figuras 3, 4, 5, 6 e 7 é apresentando o resultado final do projeto. Já na figura 8 é demonstrado o quadro de tarefas do sprint que a equipe utilizou durante o desenvolvimento do projeto.

Na retrospectiva os integrantes da equipe apresentaram os pontos positivos e negativos do Sprint, após apresentação desses pontos a equipe propõe soluções que são colocadas diretamente no Board do próximo Sprint. Como tratava-se de uma equipe com pouca experiência foram apresentados poucos pontos positivos e negativos, veja abaixo alguns pontos apresentados pela equipe:

  • A equipe começou a habituar-se a metodologias ágeis.
  • Todas as Tarefas do Sprint foram cumpridas.
  • Deveria ser gasto mais tempo para quebrar as Users Stories em Tarefas.
  • Interferências externas causaram atraso no desenvolvimento.
  • Ambiente de trabalho ruim para a concentração da equipe.

Após o final desse dia foi executada a nova planning para a definição do novo Sprint e todo o processo foi retomado.


[1]             SMS é um serviço disponível para troca de mensagens entre dispositivos de telefonia móvel.

[2]             TTS é o sistema de texto-voz, onde as mensagens de texto são convertidas em linguagem de voz.

[3]             MD5 é um algoritmo de criptografia unidirecional.

Índice:

Últimos 5 artigos de Fernando Fonte

Sobre Fernando Fonte

De Campinas-SP, bacharel em Ciência da Computação. Atua como Analista Programador em uma empresa de tecnologia. Tem experiência no desenvolvendo de softwares para comunicação e controle de hadware via porta serial e sistemas ERP. Possui conhecimento em sistemas operacionais Windows, programação Delphi e Visual Basic 6 e Banco de Dados SQL Server e MySQL. Atualmente estuda C# e Android. Tem interesse em Jogos, Celulares, Smartphones, Notebooks e tudo que for relacionado a tecnologia. Fundador deste site e editor chefe, convidou amigos para lhe ajudar com este projeto.

Deixe uma resposta