1. Sumário 1  Motivação  Metas  Metodologias Ágeis  Caso de Estudo: Ambiente  Caso de Estudo: Scrum  Caso de Estudo: Resultados eComp - POLI - UPE

2. Motivação  Software nos negócios  Falta de gerenciamento nos processos  Atrasos na entrega do projeto  Produtos de baixa qualidade  Aumento significativo dos custos 2eComp - POLI - UPE

3. Motivação  Emprego dos métodos tradicionais utilizados no desenvolvimento  Os métodos ágeis tem recebido destaque  requisitos mutáveis e não totalmente esclarecidos; e  entrega do produto com valor tangível.  Dificuldades na implantação de métodos de desenvolvimento:  característica comportamental: a resistência à mudança;  queda inicial na produtividade. 3eComp - POLI - UPE

4. Metas  Metas específicas:  adaptar e implantar o método escolhido;  testar a eficiência, no que diz respeito a entrega do produto de qualidade e em tempo hábil;  projetar melhorias no ambiente de desenvolvimento:  comunicação direta e sem falhas;  interatividade, independência e transparência na tomada de decisões entre equipe e gerência;  otimização e homogeneidade do tempo de desenvolvimento da equipe. 4eComp - POLI - UPE

5. Metodologia Ágeis eComp - POLI - UPE5  Desenvolvedores e consultores de software se juntaram para compartilhar valores e princípios que eram utilizados em suas práticas  Agile Software Development Alliance

6. Manifesto Ágil  Princípios básicos de métodos ágeis  Honestidade ao código de trabalho;  Eficácia das pessoas que trabalham em conjunto; e  Foco no trabalho em equipe. 6eComp - POLI - UPE  Características do grupo de desenvolvimento  Bem informado  Competente  Autorizado a considerar o eventual ajuste durante o processo de ciclo de vida do desenvolvimento

7. Abordagens Ágeis  XP – EXtreme Programming  Voltado para pequenas e médias equipes  Ambiente físico é fator crucial  Crystal family of methodologies  Normas de política podem ser substituídas por práticas equivalentes de outras metodologias.  Limitações de espaço físico e horário de trabalho são impeditivos  Incrementos possuem menor periodicidade  Scrum  Possui muitas das características do XP, exceto restrições quanto à localização geográfica da equipe.  Melhor aplicada com equipes ainda menores que o delimitado pelo XP e Crystal. 7eComp - POLI - UPE

8. Caracterização do Ambiente  Processo de Desenvolvimento  Desenvolvimento de softwares educacionais  Grupos de equipes responsáveis por cada matéria  São produzidas em média 3 aulas por mês, por equipe  Não há uso de qualquer ferramenta ou metodologia  Direcionada individualmente para os coordenadores de cada equipe  definição da distribuição e alocação de tarefas  definição e seleção de competências  definição da matriz de responsabilidades e canais de comunicação  geração dos artefatos durante o desenvolvimento 8eComp - POLI - UPE

9. Impactos  Descentralização de informação  Responsabilidade de geração de artefatos para a coordenação  Instabilidade no relacionamento da equipe:  Desmotivação, por não se sentir “parte do processo”;  Não reconhecimento da hierarquia do coordenador pela equipe;  Forte dependência da equipe nas direções da coordenação. 9eComp - POLI - UPE

10. Scrum  As primeiras referências na literatura ao termo “Scrum”  Artigo de Takeuchi e Nonaka: The New Product Development Game [1986]  Deriva de uma estratégia no jogo de rúgbi  Formalizado por Jeff Sutherland e Ken Schwaber  Artigo The Scrum Development Process [1994]. 10eComp - POLI - UPE

11. Scrum - Pilares  Transparência  Inspeção  Adaptação  Pontos de inspeção e adaptação em Scrum:  Daily Scrum Meeting  Sprint Planning Meeting  Sprint Review e Sprint Retrospective 11eComp - POLI - UPE

12. Scrum - Framework eComp - POLI - UPE12  Papéis  Product Owner  Scrum Master  Scrum Team  Artefatos  Product Backlog  Sprint Backlog  Scrum Board  Burndown Chart  Etapas  Release Planning Meeting  Sprint Planning Meeting  Daily Scrum Meeting  Sprint Review Meeting  Sprint Retrospective Meeting

13. Scrum - Papéis e Responsabilidades  Pigs x Chickens  Chickens não podem dizer aos pigs como fazer seu trabalho. 13eComp - POLI - UPE

14. Scrum - Papéis e Responsabilidades  Product Owner:  Definir as características do produto e prioridade de execução dos requisitos;  Gerenciar o ROI;  Garantir que os especialistas de domínio estejam disponíveis para o time.  O Product Owner está representado pela alta gerência da empresa, que é responsável pelo contato com o cliente. 14eComp - POLI - UPE

15. Scrum - Papéis e Responsabilidades  Scrum Master:  Garantir que o trabalho seja funcional e produtivo;  Acompanhar o desenvolvimento;  Remover os impedimentos;  Garantir o uso do Scrum de maneira correta.  O papel do Scrum Master equivale ao do coordenador de equipe. 15eComp - POLI - UPE

16. Scrum - Papéis e Responsabilidades  Scrum Team:  Responsável por atingir juntos os objetivos definidos em cada sprint;  Selecionar os itens priorizados a ser executados em cada iteração;  Demonstrar o trabalho desenvolvido ao Product Owner.  A equipe é composta por 6 pessoas, entre programadores, designers e pedagogo. 16eComp - POLI - UPE

17. Scrum - Papéis e Responsabilidades  Aspecto Analisado  Ambiente  Scrum  Distribuição e alocação de tarefas e seleção de competências  Executado pelo coordenador de equipe  Executado pelo Scrum Master  Definição da matriz de responsabilidades e os canais de comunicação  Executados pelo coordenador de equipe  Inerentes à metodologia, representados por ferramentas  Geração dos artefatos  Executados sem pré-definição sob a responsabilidade do coordenador de equipe  Definidos pela metodologia, implementados e adaptados pelo Scrum Master 17eComp - POLI - UPE  Correlação com o Ambiente

18. Scrum - Framework eComp - POLI - UPE18  Papéis  Product Owner  Scrum Master  Scrum Team  Artefatos  Product Backlog  Sprint Backlog  Scrum Board  Burndown Chart  Etapas  Release Planning Meeting  Sprint Planning Meeting  Daily Scrum Meeting  Sprint Review Meeting  Sprint Retrospective Meeting

19. Scrum - Artefatos e Ferramentas  Product Backlog:  Lista de itens priorizados elencando o que deve ser desenvolvido.  Corresponde à matriz de temas de aulas.  Sprint Backlog:  Lista de tarefas extraídas do Product Backlog, com as quais a equipe se compromete a fazer durante uma sprint.  É composto pelas aulas propriamente ditas  É composto pelas aulas propriamente ditas. 19eComp - POLI - UPE

20. Scrum - Artefatos e Ferramentas  Scrum Board  Stories: aulas divididas em páginas.  To Do: tarefas listadas para cada página por membro.  In Progress: tarefas em execução.  Impediments: problemas encontrados no desenvolvimento.  Meetings: comunicação interna da equipe. 20eComp - POLI - UPE

21. Scrum - Artefatos e Ferramentas  Método Planning Poker  Montar o Burndown Chart  James Grenning, 2002  Mike Conh, 2005 - Agile Estimating and Planning  Cada tarefa é discutida de modo sucinto. Cada participante dá sua nota de complexidade com base na escala definida para cada tarefa. 21eComp - POLI - UPE

22. Scrum - Artefatos e Ferramentas eComp - POLI - UPE22  Escala utilizada no baralho: 1, ½, 2, 3, 5, 8, 13, 21, 40 e 100.  Todas as tarefas listadas na seção To Do são mensuradas, de forma que somadas preenchem o valor total de pontos no gráfico.

23. Scrum - Artefatos e Ferramentas  Gráfico Burndown (Burndown Chart) 23eComp - POLI - UPE

24. Scrum - Artefatos e Ferramentas  Correlação com o Ambiente  Nova realidade: a geração de artefatos.  Formalizar toda a documentação necessária.  Diagramas de estado de cada página da aula em execução na sprint  Elaborados pelo Scrum Master;  Detalham o fluxo de ocorrência dos eventos e animações definidas para cada página;  Aceleram o desenvolvimento e reduzem o número de manutenções e alterações feitas por página. 24eComp - POLI - UPE

25. Scrum - Framework eComp - POLI - UPE25  Papéis  Product Owner  Scrum Master  Scrum Team  Artefatos  Product Backlog  Sprint Backlog  Scrum Board  Burndown Chart  Etapas  Release Planning Meeting  Sprint Planning Meeting  Daily Scrum Meeting  Sprint Review Meeting  Sprint Retrospective Meeting

26. Scrum - Etapas da Sprint  Release Planning Meeting  Estabelecer plano e metas que a equipe e o resto das organizações possam compreender e se comunicar.  Questões que guiam a reunião:  “Como podemos transformar essa visão em um produto vencedor da melhor maneira possível?”  “Como podemos atender ou exceder a satisfação do cliente e o ROI?” 26eComp - POLI - UPE

27. Scrum - Etapas da Sprint  Sprint Planning Meeting  A iteração é planejada, sendo selecionadas as estórias a serem implementadas durante a sprint baseando-se num Product Backlog pré-definido e priorizado.  Sprint Planning 1:  Decidir o que será feito na sprint.  O Product Owner e o Scrum Master selecionaram as estórias da matriz contendo as aulas pré-selecionadas do Product Backlog.  Sprint Planning 2:  Decidir como serão construídas as funcionalidades selecionadas no Product Backlog.  A equipe definiu como construir a aula no Sprint Backlog durante a sprint. 27eComp - POLI - UPE

28. Scrum - Etapas da Sprint  Daily Scrum Meetings  Melhorar a comunicação  Eliminar outras reuniões  Identificar e remover obstáculos ao desenvolvimento  Destacar e promover a rápida tomada de decisões  Melhorar o nível de conhecimento de todos sobre projeto  Três questões que guiam a reunião:  “O que tem realizado desde a última reunião?”  “O que pretende fazer antes da próxima reunião?”  “Quais são os impedimentos para realizar seu trabalho com eficácia?”  Se mostraram as mais complicadas de adaptar, devido às divergências de horários entre os membros da equipe. 28eComp - POLI - UPE

29. Scrum - Etapas da Sprint  Sprint Review Meeting  Ponto de inspeção ao fim de cada iteração.  Mostrar o produto da sprint;  Servir como estímulo para a continuação de mais sprints.  Somente uma Sprint Review Meeting foi realizada, resumindo os releases de duas sprints.  Ausência do Product Owner, que obteve a ata da reunião posteriormente. 29eComp - POLI - UPE

30. Scrum - Etapas da Sprint  Sprint Retrospective Meeting 30eComp - POLI - UPE  Vantagens  Melhorias  Manter o controle das tarefas a serem feitas, evitando esquecimento.  Alterar as dimensões das áreas de To Do e Done no Scrum Board.  Organizar as etapas do desenvolvimento, auxiliando determinar o início, meio e fim.  Definir um padrão para determinar as dependências entre as tarefas nos post-its.  Prover uma visão do projeto todo para a equipe inteira.  Permitir maior flexibilidade nos horários das Daily Scrum Meetings.  Permitir toda a equipe de ter noção da complexidade de todas as tarefas.  Inserir uma melhor divisão do desenvolvimento, permitindo detectar um padrão.  Perceber o andamento do projeto, através do Burndown Chart.

31. Scrum - Ciclo de Desenvolvimento  Correlação com o Ambiente  Escolha de uma metodologia simples de ser rapidamente assimilada e aplicada pelos coordenadores.  Devido à sua adaptabilidade, atende essas exigências de simplicidade e rápida aplicabilidade. 31eComp - POLI - UPE

32. Coleta e Análise de Dados  Análise Comportamental da Equipe  Máximo de aceitação da metodologia  interesse pelas reuniões diárias  participação ativa na Sprint Planning Meeting  comprometimento com as Sprint Review e Sprint Retrospective  Scrum Board: “uma ferramenta que fornece uma visão global do projeto”.  Planning Poker: cumplicidade gerada entre os membros da equipe.  Violet UML Editor: responsabilidade do Scrum Master, tendo a equipe acesso às imagens e arquivos fonte gerados dos diagramas de estado. 32eComp - POLI - UPE

33. Coleta e Análise de Dados  Análise de Eficiência da Metodologia Scrum no Desenvolvimento das Tarefas  Prazo  As aulas, a priori desenvolvidas numa média de 3 por semana, passaram a ser produzidas 2 semanalmente.  Qualidade  Produto com menos erros, adequado ao uso (cumprindo as requisições de usabilidade) e satisfazendo os requisitos do Product Owner.  Custos  Aspectos:  de tempo de produção; e  de aquisição de ferramentas. 33eComp - POLI - UPE

34. Coleta e Análise de Dados  Ambiente Pré-Implantação  Ambiente Pós-Implantação  Hierarquia da equipe composta pelas três instâncias: alta gerência, coordenador de equipe, equipe.  Hierarquia da equipe composta pelas três instâncias: Product Owner, Scrum Master e Scrum Team.  Papel da alta gerência: gerenciar os coordenadores de equipe e contatar os clientes. Não participa do desenvolvimento em nenhuma etapa.  Papel do Product Owner: colaborar com Scrum Master e equipe na seleção e manutenção das prioridades de acordo com o valor de negócio da empresa.  Papel do coordenador de equipe: Líder. Responsável por guiar a equipe para obter resultados de acordo as próprias definições e regras básicas da empresa.  Papel do Scrum Master: facilitador. Responsável por remover os impedimentos da equipe e assegurar que o Scrum seja seguido: etapas, artefatos e papéis.  Papel da equipe: desenvolver aulas de acordo com a documentação de roteiro e instruções do coordenador e reportar as dúvidas ao coordenador.  Papel do Scrum Team: ser auto-organizado e selecionar os itens priorizados a ser executados na sprint, com liberdade e comprometimento. 34eComp - POLI - UPE

35. Coleta e Análise de Dados  Ambiente Pré-Implantação  Ambiente Pós-Implantação  Papel da equipe: desenvolver aulas de acordo com a documentação de roteiro e instruções do coordenador e reportar as dúvidas ao coordenador.  Papel do Scrum Team: ser auto-organizado e selecionar os itens priorizados a ser executados na sprint, com liberdade e comprometimento.  Processo de desenvolvimento: iterações sem etapas definidas ou delimitadas.  Processo de desenvolvimento: sprints com etapas pré-definidas e obrigatórias.  Ciclo de desenvolvimento: produção do roteiro, desenvolvimento (com testes periódicos, mas sem padronização) e publicação da aula.  Ciclo de desenvolvimento: produção do roteiro, Sprint Planning Meeting (validação do roteiro com equipe e Product Owner), desenvolvimento (com verificações diárias – Daily Scrum Meetings), Sprint Review (validação do Product Owner) e publicação da aula. 35eComp - POLI - UPE

36. Conclusão e Trabalhos Futuros  Falta de gerenciamento nos processos  Justifica a necessidade da adoção de processos que utilizem práticas ágeis.  Metodologia ágil Scrum: adequada para o uso em ambientes de desenvolvimento de softwares educativos  Sua aplicação engloba todas as etapas do desenvolvimento, através de pequenas e médias adaptações.  Remove a obrigatoriedade de geração de vasta documentação. 36eComp - POLI - UPE

37. Conclusão e Trabalhos Futuros  As etapas definidas fornecem importantes dados relativos à produtividade das equipes.  Aspecto comportamental  Boa adaptabilidade e aceitação da equipe à metodologia. 37eComp - POLI - UPE

38. Conclusão e Trabalhos Futuros  Dificuldades Encontradas  Daily Scrum Meetings ficaram comprometidas;  Atrasos e interferências causadas pelo Product Owner.  Trabalhos Futuros  Implantação do processo de Gerenciamento de Qualidade;  Desenvolvimento do artifício de indicação de dependências;  Implantação do método em todas as equipes da empresa. 38eComp - POLI - UPE

39. 39  Thanks you