Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG

616 views
484 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
616
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG

  1. 1. Modelagem Ágil Palestrante: Neubio Ferreira
  2. 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. 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. 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.
  5. 5. Participantes
  6. 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. 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. 8. Para que ser ágil? • Porque adotamos Agile? • Minimização de Falhas. • Satisfação dos Stakeholders. • Agregar Valor para o Cliente , Projeto, Produto, ...
  9. 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. 10. Quem são os Modeladores Ágeis? • Qualquer pessoa que siga a metodologia ágil. • Aplique suas práticas guiadas por princípios e valores.
  11. 11. Valores • Comunicação. • Simplicidade. • Feedback. • Humildade.
  12. 12. Valor: Comunicação • Problemas ocorrem quando a comunicação em um projeto termina.
  13. 13. Valor: Simplicidade • Aplicação de Padrões. • Arquitetura em excesso. • • Não podemos ficar prevendo o futuro. Desenvolvimento de Infraestrutura complexa.
  14. 14. Valor: Feedback • Desenvolva o modelo em equipe. • Revise o modelo com os Stakeholders. • Implemente o modelo. • Faça o teste de aceitação.
  15. 15. Valor: Humildade • Você não sabe tudo. • Aprendemos com pessoas menos experientes. • Pontos de Vista.
  16. 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. 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. 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. 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. 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. 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. 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. 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. 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.
  25. 25. Princípios Básicos • Retorno Rápido • O trabalho próximo ao cliente possibilita o retorno rápido. • Razões em que o retorno rápido é importante:
  26. 26. Princípios Secundários • O conteúdo é mais importante que a forma. Diagramas a título de ilustração
  27. 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. 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. 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. 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. 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. 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. 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. 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.
  35. 35. Práticas Secundárias • Motivação • Modele para entender. • • Explore o espaço problema. Modele para comunicar. • Nós modelamos para transmitir uma ideia.
  36. 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. 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. 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. 39. Equipes de Modelagem Ágil • Recrute bons Desenvolvedores. • Não existe “EU” na modelagem ágil. • Todos devem participar ativamente. • Modele em equipe.
  40. 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. 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. 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. 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. 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. 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. 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. 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. 48. Resumo • Maior problema da Agilidade é a cultura. • Seja agente da mudança. • O Ótimo é inimigo do Bom! • TEMPO É DINHEIRO!!!
  49. 49. Dúvidas
  50. 50. Contatos neubio.ferreira@gmail.com @Neubio

×