• Save
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 335 views

 

Statistics

Views

Total Views
335
Views on SlideShare
334
Embed Views
1

Actions

Likes
1
Downloads
0
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • Modelagem Ágil Palestrante: Neubio Ferreira
    • 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.
    • 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
    • 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.
    • Participantes
    • 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?
    • 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?
    • Para que ser ágil? • Porque adotamos Agile? • Minimização de Falhas. • Satisfação dos Stakeholders. • Agregar Valor para o Cliente , Projeto, Produto, ...
    • 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.
    • Quem são os Modeladores Ágeis? • Qualquer pessoa que siga a metodologia ágil. • Aplique suas práticas guiadas por princípios e valores.
    • Valores • Comunicação. • Simplicidade. • Feedback. • Humildade.
    • Valor: Comunicação • Problemas ocorrem quando a comunicação em um projeto termina.
    • Valor: Simplicidade • Aplicação de Padrões. • Arquitetura em excesso. • • Não podemos ficar prevendo o futuro. Desenvolvimento de Infraestrutura complexa.
    • Valor: Feedback • Desenvolva o modelo em equipe. • Revise o modelo com os Stakeholders. • Implemente o modelo. • Faça o teste de aceitação.
    • Valor: Humildade • Você não sabe tudo. • Aprendemos com pessoas menos experientes. • Pontos de Vista.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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?
    • 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?
    • 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!!!
    • 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!!!
    • 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.
    • 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:
    • Princípios Secundários • O conteúdo é mais importante que a forma. Diagramas a título de ilustração
    • Princípios Secundários • Todos podem aprender com todos. • • Nunca sabemos tudo sobre algo. Conheça seus modelos. • Todos possuem pontos Fortes e Fracos.
    • 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.
    • 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.
    • 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”.
    • 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.
    • 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.
    • 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.
    • 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.
    • Práticas Secundárias • Motivação • Modele para entender. • • Explore o espaço problema. Modele para comunicar. • Nós modelamos para transmitir uma ideia.
    • 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.
    • 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.
    • Á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.
    • Equipes de Modelagem Ágil • Recrute bons Desenvolvedores. • Não existe “EU” na modelagem ágil. • Todos devem participar ativamente. • Modele em equipe.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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”.
    • 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.
    • Resumo • Maior problema da Agilidade é a cultura. • Seja agente da mudança. • O Ótimo é inimigo do Bom! • TEMPO É DINHEIRO!!!
    • Dúvidas
    • Contatos neubio.ferreira@gmail.com @Neubio