2. Quem Sou eu?
•
Owner/Consultor – Sparti Tecnologia e Sistemas LTDA.
•
Gerente de Projetos – GSW Soluções Integradas (Base Minas Gerais).
•
Consultoria em:
•
•
Gerenciamento de Projetos.
•
•
Implantação Framework/Metodologias Ágeis (Scrum, XP, Kanban, entre outros).
Engenharia de Software.
Certificado em:
•
Scrum, RUP, ITIL, RSA, RAD.
3. Agenda
•
O que não será falado.
•
Falando um pouco sobre Agile
•
Modelagem Ágil
•
Valores
•
Princípios Básicos
•
Princípios Secundários
•
Práticas Básicas
•
Práticas Secundárias
•
Criando uma cultura Ágil
•
Documentação Ágil
•
Resumo
4. O que não será falado?
•
Notação UML.
•
Ferramentas CASE.
•
Processo Prescritivo para a Modelagem e Documentação.
•
Detalhes do Framework/Metodologia Scrum, XP, entre outros.
•
Papel do Analista de Negocio, Analistas de Requisitos.
6. Para que ser ágil?
•
Porque adotamos Agile?
•
Para seguir a “moda”?
•
Para dizer que uso Scrum?
•
Para falar mal dos processos da minha empresa?
•
Para dizer que meu processo é mais maduro do que o do
outro?
7. Para que ser ágil?
•
Porque adotamos Agile?
•
Para seguir a “moda”?
•
Para dizer que uso Scrum?
•
Para falar mal dos processos da minha empresa?
•
Para dizer que meu processo é mais maduro do que o do
outro?
8. Para que ser ágil?
•
Porque adotamos Agile?
•
Minimização de Falhas.
•
Satisfação dos Stakeholders.
•
Agregar Valor para o Cliente , Projeto, Produto, ...
9. O que é Modelagem Ágil?
•
Processo baseado na prática que descreve como um
modelador ágil deve ser.
•
É guiado por:
•
•
•
Princípios.
Valores.
Não descreve procedimentos detalhados.
10. Quem são os Modeladores Ágeis?
•
Qualquer pessoa que siga a metodologia ágil.
•
Aplique suas práticas guiadas por princípios e
valores.
13. Valor: Simplicidade
•
Aplicação de Padrões.
•
Arquitetura em excesso.
•
•
Não podemos ficar prevendo o futuro.
Desenvolvimento de Infraestrutura complexa.
14. Valor: Feedback
•
Desenvolva o modelo em equipe.
•
Revise o modelo com os Stakeholders.
•
Implemente o modelo.
•
Faça o teste de aceitação.
16. Princípios Básicos
•
O Software é seu Objetivo Principal
•
Software funcionando é a principal medida de progresso.
•
O principal Objetivo não é:
•
Criar documentação.
•
Criar Artefatos de Gerenciamento de Projetos.
•
Criar Modelos.
•
Escrever relatórios.
17. Princípios Básicos
•
Modele com um propósito
•
•
•
Porque criar o modelo?
Para quem estamos criando o modelo?
Ele deve ser suficientemente preciso e detalhado.
18. Princípios Básicos
•
Possibilitar o próximo trabalho é seu objetivo
secundário.
•
•
Um projeto pode ter fracasso mesmo quando entregamos o
sistema funcionando.
Diminua a Carga de Trabalho
•
•
Criar modelos e documentações suficientes para seguir
adiante.
Artefatos criados precisam de manutenção.
•
Modelos, Documentação, Artefatos de Gerenciamento, Cronogramas,
Testes, Códigos Fontes.
19. Princípios Básicos
•
Adote a Simplicidade.
•
A solução mais simples é a melhor.
•
Se a mais simples não funcionar, terá tempo de construir a
mais complexa.
•
Não construa software em excesso.
•
Não modele em excesso.
20. Princípios Básicos
•
Encare a mudança
•
Mudanças acontecem.
•
Requisitos mudam com o tempo.
•
Pontos de vista são alterados.
•
É muito melhor simplesmente gerar algum código e esperar ate que algum
cliente lhe diga para alterar, certo?
21. Princípios Básicos
•
Encare a mudança
•
Mudanças acontecem.
•
Requisitos mudam com o tempo.
•
Pontos de vista são alterados.
•
É muito melhor simplesmente gerar algum código e esperar ate que algum
cliente lhe diga para alterar, certo?
22. Princípios Básicos
•
Encare a mudança
•
Mudanças acontecem.
•
Requisitos mudam com o tempo.
•
Pontos de vista são alterados.
•
É muito melhor simplesmente gerar algum código e esperar ate que algum
cliente lhe diga para alterar, certo?
•
Devemos Investir tempo
compreendendo os requisitos!!!
23. Princípios Básicos
•
Mude Incrementalmente
•
Mude pequenas partes do sistema de cada vez.
•
Entregue Software Frequentemente.
•
O modelo deve ser bom o suficiente para o momento.
•
Devemos ter Humildade para aceitar que não acertamos
tudo na primeira vez, ate mesmo na enésima vez, e
coragem para admiti-lo!!!
24. Princípios Básicos
•
Trabalho de Qualidade
•
Ninguém gosta de trabalho desleixado.
•
É difícil a manutenção.
•
É difícil o incremento.
•
Não devemos investir muito tempo em artefatos que
pretendemos descartar.
27. Princípios Secundários
•
Todos podem aprender com todos.
•
•
Nunca sabemos tudo sobre algo.
Conheça seus modelos.
•
Todos possuem pontos Fortes e Fracos.
28. Princípios Secundários
•
Comunicação Aberta e Honesta
•
•
Devemos ser livres para ouvir e oferecer sugestões.
Trabalhe com o instinto das pessoas
•
Se algo não cheira bem, tome cuidado.
29. Práticas Básicas
•
Modelagem Interativa e Incremental
•
Aplique o Artefato Correto.
•
•
Crie diversos modelos em paralelo.
•
•
Uma imagem vale mais do que mil palavras.
Apenas um modelo não representa o todo.
Modele Incrementalmente.
30. Práticas Básicas
•
Trabalho em Equipe
•
Modele com outras pessoas.
•
Duas cabeças pensam melhor que uma.
•
Organize uma participação ativa dos clientes.
•
Promova a posse coletiva.
Quanto mais o time se envolve com o desenvolvimento mais rápido teremos o
retorno.
• O time adquire experiência.
• Evita confrontos do tipo: “Seu modelo está errado”.
•
•
Mostre os modelos publicamente.
•
Os modelos devem ser acessíveis para o time: “Parede de modelagem”.
31. Práticas Básicas
•
Simplicidade
•
Crie conteúdo Simples.
O modelo deve ter a menor quantidade de elementos possíveis.
• O modelo deve cumprir o seu objetivo.
•
•
Mostre os modelos de modo Simples.
• Agregue valor ao seu modelo!
•
Use as ferramentas mais simples.
•
Quadro, Papel, Foto, Guardanapo, entre outros.
32. Práticas Básicas
•
Validação
•
Considere a Testabilidade.
Se você não pode testar o software que constrói, então você não deve construí-lo.
• Devemos testar o software o mais cedo possível e com frequência.
•
•
Comprove com código.
•
Para validar o modelo devemos escrevê-lo em código.
33. Práticas Secundárias
•
Produtividade
•
Aplique as convenções da modelagem.
•
•
Utilize os padrões com moderação
•
•
Hoje utilizamos como padrão a UML.
Não tente aplicar padrões (Design Patterns) imediatamente.
Reuse os recursos já existentes.
•
Não reinvente a roda.
34. Práticas Secundárias
•
Documentação
•
Descarte os modelos temporários
•
•
Desapegue.
Modelos se tornam obsoletos.
•
Formalize os modelos de contrato.
•
Atualize apenas quando necessário.
•
•
Os modelos não precisam ser perfeitos para ter valor.
Invista melhor o seu tempo.
36. Criando uma Cultura ágil
•
Supere os conceitos Errôneos que envolvem a
Modelagem
•
Modelo não é Documentação.
•
Você não consegue pensar em tudo desde o inicio.
•
Não tente modelar todo o sistema para depois implementar.
•
Você deve ou não, ter uma ferramenta CASE.
•
Modelar não é perda de tempo.
•
Nem todo desenvolvedor sabe modelar.
37. Criando uma Cultura ágil
•
Pense Pequeno
•
•
Equipes Pequenas.
•
Modelos Pequenos.
•
•
Seções curtas de modelagem.
Documentos Pequenos.
Relaxe um pouco.
•
Modelos Ágeis não precisam ser perfeitos.
•
Apoie com firmeza os direitos e responsabilidades dos clientes.
•
Repense as apresentações para os clientes.
•
As vezes ligar ou enviar um email é mais produtivo do que marcar uma reunião.
38. Área de Trabalho Ágil
•
A equipe precisa:
•
•
•
•
•
Espaço exclusivo.
Quadros.
Câmera Digital.
Livros de Referência.
Dicas para ter um ambiente ágil
•
Livre-se dos Fones de ouvido.
39. Equipes de Modelagem Ágil
•
Recrute bons Desenvolvedores.
•
Não existe “EU” na modelagem ágil.
•
Todos devem participar ativamente.
•
Modele em equipe.
40. Documentação Ágil
•
Porque as pessoas documentam?
•
Razões Válidas.
•
Seus Clientes a requisitam.
•
Decisão de Negocio.
•
•
Apoiar a comunicação com um grupo externo.
•
•
Interações entre sistemas.
Para entender.
Razões Questionáveis.
•
O solicitante quer parecer estar no controle.
•
O Solicitante quer justificar a sua existência.
•
O Solicitante não compreende bem.
•
Seu processo diz para criar o documento.
•
Alguém quer assegurar que tudo esta bem.
41. Documentação Ágil
•
Quando um modelo se torna um documento?
•
Há um motivo claro e importante para torna-ló
permanente.
•
Há um público para o qual o modelo fornece algo
importante.
•
Seus cliente estão dispostos a dispensar recursos
para que o modelo vire parte da documentação.
42. Documentação Ágil
•
O que significa diminuir a carga de Trabalho?
•
Criar modelos e documentações suficientes.
•
Podemos ter projetos pequenos sem documentação.
•
Na maioria dos projetos isso não acontece.
•
Crie modelos e documentações quando realmente precisarem deles.
•
Tempo é Dinheiro.
43. Documentação Ágil
•
Quando um documento é ágil?
•
•
•
•
•
•
Maximizam o retorno dos clientes.
São Magros e Econômicos.
Satisfazem um propósito.
Descrevem informações que possuem menor probabilidade
de mudar.
Coisas importantes de saber.
Facilitam o trabalho dos clientes.
•
•
Clientes diferentes requerem documentações diferentes.
Precisos, Consistentes e Detalhados.
44. Documentação Ágil
•
De que tipos de documentos você precisa?
•
•
•
•
•
•
•
Modelos de Contrato.
Decisões de Projeto.
Visão Geral executiva.
Documentação de Operações.
Visão Geral do projeto.
Documento de requisitos.
Documentação de Suporte.
45. Documentação Ágil
•
Entregas eficazes de Documentação
•
Evite as entregas de documentação.
•
•
Não é uma boa forma de comunicação.
Apoie as entregas com outros meios de Comunicação.
46. Documentação Ágil
•
Estratégias para aumentar a agilidade de documentação
•
Centre-se no Cliente.
•
Mantenha a Documentação simples o suficiente, mas não simples
demais.
•
O Cliente determina o quanto é suficiente.
•
Documente com um objetivo.
•
Prefira outras formas de comunicação.
•
Coloque a documentação no local apropriado.
•
Espere que o que você esta documentando se estabilize.
•
Mostre seus modelos publicamente.
•
Peça as pessoas que justifiquem suas solicitações de documentação.
•
“Documentação em Dupla”.
47. Importante
•
A documentação deve fornecer o Máximo de valor possível.
•
Não faça documentação sem pensar.
•
Pense depois Aja.
•
Você não conseguirá o modelo perfeito de primeira.
•
Paralisia da Análise.
•
Seja agente da mudança.
•
Precisamos de documentação mas não muita.
48. Resumo
•
Maior problema da Agilidade é a cultura.
•
Seja agente da mudança.
•
O Ótimo é inimigo do Bom!
•
TEMPO É DINHEIRO!!!
