Transferir como PDF, PPTX
Carregado porJorge Bublitz
Aula Fdd Cesar.Edu 2017
Este documento discute o desenvolvimento orientado a funcionalidades (FDD). Primeiramente, apresenta o contexto do desenvolvimento de software e as limitações das metodologias tradicionais. Em seguida, discute as metodologias ágeis e como a FDD disciplina as equipes a pensarem antes de implementar funcionalidades de forma incremental, demonstrando claramente o que será e está sendo feito.
Mais conteúdo relacionado
![[Webinar] Scrum - Você está fazendo do jeito certo?](https://cdn.slidesharecdn.com/ss_thumbnails/webinar-scrumdojeitocerto-targettrust-180417193100-thumbnail.jpg?width=640&height=640&fit=bounds)
Aula Fdd Cesar.Edu 2017
- 1. DESENVOLVIMENTO DIRIGIDO A FUNCIONALIDADES Prof. Esp.Jorge Luis Bublitz
- 2. DESENVOLVIMENTO DIRIGIDO A FUNCIONALIDADES "AFDD disciplina as equipes a pensarem um pouco antes de sair fazendo e a fazer aos poucos enquanto continuam aprendendo, demonstrando claramente o que vão fazer e o que estão fazendo."
- 3. Agenda • Contexto • Metodologias •Agilidade e Metodologias Ágeis • Mudanças • FDD
- 4.
- 5. O que éDesenvolvimento de Software? “É o ato de elaborar e implementar um sistema computacional, isto é, transformar a necessidade de um utilizador ou de um mercado em um produto de software.” Nick Birrell A Practical Handbook for Software Development, 1985
- 6. Características • Caótica • Eternociclo “programar e depurar” • Sem planejamento claramente definido • Dificuldade em adicionar novos recursos (funcionalidades) • Fase de testes e depuração na produção • Estimativa de Tempo/Custo difícil de ser determinada
- 7. The Chaos Report- 1995 Standish Group – www.standishgroup.com
- 8. The Chaos Report- 2011 Standish Group – www.standishgroup.com
- 9. The Chaos Report- 2015 Standish Group – www.standishgroup.com
- 10. Vamos Analisar Sucesso AlteraçõesFalharam Standish Group – www.standishgroup.com
- 11. Funcionalidades/Funções Utilizadas em umSistema Standish Group – www.standishgroup.com
- 12.
- 13. Como você quero seu projeto? Rápido Qualidade Barato $$$ Mal Feito Não pode ser rápido UTOPIA
- 14. A Solução é... Nãoexiste uma solução mágica e única, mas sim um conjunto de práticas reconhecidamente eficientes: as Práticas e os Princípios do Movimento Ágil
- 15. A Solução é... •Melhorar a qualidade do software implica na melhoria do processo pelo qual o mesmo é produzido. • Assumir práticas de sucesso • Garantir que estas práticas serão seguidas durante o desenvolvimento • Ser fácil de seguir • Evoluir com o aprendizado do grupo
- 16. A Solução utilizadaaté hoje: • Adoção de Metodologias • Objetivo: tornar o desenvolvimento mais previsível e mais eficiente • Impõe disciplinas rígidas • Processos detalhados • Planejamento é a ênfase • Passam a impressão de serem uma PANACÉIA
- 18.
- 19.
- 20. Modelo Tradicional • Tambémchamado de Modelo em Cascata (Waterfall) • Proposto por Winston W. Royce - 1970!!! • Orientado para documentação • Ênfase em planejamento, horários, prazos, orçamentos e implementação de sistemas inteiros • Há variantes: Incremental, Evolucionário, ...
- 21.
- 22.
- 23. Agilidade • a.gi.li.da.de sf(lat agilitate) 1. Qualidade do que é ágil 2. Desembaraço, ligeireza, presteza de movimentos 3. Mobilidade, perspicácia, vivacidade • Geralmente associa-se AGILIDADE com Rapidez, Flexibilidade, Leveza
- 24.
- 25. Agilidade - Software “Agilidadeé a habilidade para criar e responder às mudanças, para lucrar num ambiente turbulento de negócios, para equilibrar flexibilidade e estabilidade.” Jim Highsmith Agile Software Development Ecosystems 2002
- 26. Metodologias Ágeis • Anteschamadas de “Metodologias Leves” • Tornou-se popular no ano de 2001 • 17 grandes pensadores em processo de desenvolvimento de software • Se encontraram para que cada um explicasse a maneira como desenvolviam projetos de software • E como trabalhavam para que a equipe respondesse rapidamente às mudanças • A partir deste encontro foi criada a “Aliança Ágil” • Estabelecimento dos valores do “Manifesto Ágil”
- 27. Manifesto para o Desenvolvimento Ágil de Software Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o e ajudando outros a fazê-lo. Através deste trabalho passamos a valorizar: Indivíduos e interações mais que processos e ferramentas. Software que funciona mais que documentação detalhada. Colaboração do cliente mais que negociações contratuais. Responder às mudanças mais que seguir um plano. Isto é, embora haja valor nos itens do lado direito, nós valorizamos mais os do lado esquerdo. www.agilemanifesto.org
- 28. Princípios Ágeis • Satisfaçãodo Cliente • Responder às Mudanças • Entrega Freqüente • Motivação • Software que Funciona • Ritmo Constante • Simplicidade
- 29. Cuidado com oManifesto Radical O Manifesto Ágil não pode ser interpretado como indicando que ferramentas, processo, documentos, contratos ou planos são desprezíveis. • Ferramentas são críticas para acelerar o desenvolvimento e reduzir custos • Contratos são vitais para iniciar as relações desenvolvedor- cliente • Documentação auxilia a comunicação • Entretanto, os itens à esquerda são os mais cruciais • Sem indivíduos hábeis, software funcionando, interações fortes com clientes e rapidez de resposta às mudanças, a entrega do produto será quase impossível
- 30. O Sucesso dasMetodologias Ágeis Já é um movimento de grande sucesso • Centenas (milhares?) de instituições já usam • Milhares de projetos já foram completados • Opinião geral dos que tentaram é positiva • Alguns estudos científicos começam a aparecer
- 31. Quem Adotou ouEstá Adotando?
- 32. Mas... • Proporcionalmente, asmetodologias tradicionais ainda dominam • Metodologias Ágeis exigem uma mudança cultural, o que não é nada fácil • Metodologias Ágeis foram criadas por especialistas em Desenvolvimento de Software • Em geral o poder de decisão não está nas mãos desses especialistas
- 33. Maiores Dificuldades • Apoiodas instâncias superiores • Gerenciamento de equipes • Problemas técnicos • Interação com outros departamentos • Interação com clientes
- 34. Levantamento de Requisitos Projeto Implementação Testes Implantação Métodos Pseudo-Ágeis XP,Scrum, ... Implantação com Testes
- 35. Mitos sobre asMetodologias Ágeis
- 36. Programação Radical “Extreme Programming(XP) é um processo de desenvolvimento que possibilita a criação de software de alta qualidade, de maneira ágil, econômica e flexível.“ - Vinícius M. Teles • Valores: ■ Princípios: • Comunicação ■ Feedback rápido • Simplicidade ■ Presumir simplicidade • Feedback ■ Mudanças incrementais • Coragem ■ Abraçar mudanças ■ Trabalho de Qualidade
- 37. Principal Mito • Agilidade= XP • É apenas um processo ágil, centrado no desenvolvedor • Fatos: • Há vários outros processos e metodologias, como FDD, Scrum, Lean, Crystal, MSF for Agile, ASD, DSDM, RAD, etc. • Agilidade é mais habilidade e atitude do que a adoção de um processo • O Projeto C3, que deu origem à XP foi cancelado!
- 38. A “MÁ” Agilidade •“Foco em datas na pior forma possível: ciclos curtos, entregas rápidas, estimativas e re- estimativas freqüentes” • Esse foco agressivo na entrega fere a base geral de código, porque as pessoas não dão a mão para ajudar uns aos outros, e as tarefas “domésticas” são negligenciadas • Eles ficam exaustos por causa do ritmo invariante e das horas anti-naturalmente regulares
- 39. A “MÁ” Agilidade •“São todos novos, com medo de falar, e nenhum deles têm mesmo certeza se é a Agilidade que está causando o problema” • Esse pessoal Ágil é evasivo: “esquivando-se da crítica ao abraçar qualquer coisa boa e repudiando qualquer coisa má”
- 40. A “BOA” Agilidade •A estrutura da organização contém hierarquia, mas na prática ela parece bastante “plana” (código dos gerentes) • As pessoas evoluem os processos quando necessário (em vez dos processos oprimirem as pessoas) • Grande disciplina é praticada com relação à base de código • A “folga” está embutida no sistema
- 41. A “BOA” Agilidade •Permitir aos desenvolvedores explorar outras idéias que os interessem • Os incentivos são ligados ao valor de negócio de cada projeto • A organização facilita o foco na codificação • Por exemplo, fornecendo boas ferramentas e lanches gratuitos ☺ • As pessoas são tratadas com respeito • As requisições são simplesmente enfileiradas e priorizadas
- 42.
- 43. Porque mudar?? • Únicaconstante do universo: MUDANÇA • Para melhorar • Para motivar • Para nos tornarmos mais eficientes e eficazes • Para nos tornarmos mais ágeis
- 44. Além disso... • Para88% dos 1.150 CEOs de todo mundo ouvidos no início de 2009 pela consultoria americana Pricewaterhouse-Coopers a competência mais importante para um executivo atualmente é a flexibilidade para se adaptar a mudanças • “E não basta ter facilidade para aceitar o novo. O profissional deve ser um provocador de mudanças e levar as pessoas junto com ele”, José Aurélio Drummond Jr., presidente da Whirlpool
- 45. O Processo deMudança
- 46. Tradicional • Ser capazde controlar / eliminar a incerteza • Planejamento e controle de progresso através do Caminho Crítico / EVA • Replanejar deve ser a exceção sempre • Controle rígido do escopo do projeto • Teorias básicas: Gerenciamento Total da Qualidade Controle Estatístico de Processos Ágil • Ser capaz de lidar com a incerteza • Planejamento e controle de progresso através da Corrente Crítica / Buffers • Replanejar deve ser a regra (há limites práticos) • Controle do escopo das iterações • Teorias básicas: Teoria do Caos Teoria das Restrições (TOC) Produção Enxuta (Lean)
- 47. 7 Hábitos dasEquipes Altamente Ágeis 1.Seja proativo 2.Comece com o objetivo em mente 3.Primeiro o mais importante 4.Pense Ganha/Ganha 5.Procure primeiro compreender, depois ser compreendido 6.Crie sinergia 7.Afine o instrumento
- 48. Matriz do Tempo Urgente Não Urgente Importante Não Importante ✓Crises ✓Prazos ✓Clienteszangados ✓Alterações na legislação ✓Planejamento e Preparação ✓Educação ✓Treinamento ✓Desenvolvimento ✓E-mails (alguns deles) ✓Reuniões desnecessárias ✓Reuniões mal preparadas ✓Jogos de Computador ✓E-mails em excesso ✓Navegar na internet sem objetivo ✓WhatsApp e Redes Sociais
- 49. Para que serveum Processo? • O propósito de um processo de desenvolvimento de software é: • capacitar e reforçar a entrega repetível de software que funciona... • no prazo adequado e eficiente em relação ao seu custo... • fornecendo informação precisa e significativa a todos os papéis principais, dentro e fora de um projeto... • com o mínimo de interrupção para os desenvolvedores Peter Coad, Jeff de Luca (JMCU)
- 50. Características de umbom Processo • É bem delimitado • Claramente define tarefas, que são focadas nos resultados • Produz progresso e informação de status precisos • Rapidamente torna-se uma questão de hábito • Ajuda a equipe a manter a qualidade e administrar a complexidade • Otimiza comunicação dentro e fora da equipe
- 51. O Processo Ágil... •Capacita a organização a responder facilmente à mudança • Entrega código funcionando ao mercado mais rapidamente (do que com outros métodos – atuais ou anteriores) • Produz código funcionando de alta qualidade • Aumenta a produtividade • Aumenta a satisfação do cliente • Fornece um ambiente de alta satisfação com o trabalho para uma equipe bem motivada
- 52.
- 53. Definição • “FDD éuma metodologia iterativa e incremental de gerenciamento e engenharia de software, que combina as melhores práticas de outras abordagens ágeis com técnicas centradas no modelo, que podem escalar para equipes e projetos maiores. • É caracterizada por uma ênfase na qualidade em todo o processo e um monitoramento de progresso direto, preciso, intuitivo e acurado. • Sua principal finalidade é a entrega tangível e frequente de software funcional.” Autor: Jorge L. Bublitz Revisão: Adail Muniz
- 54. Onde nasceu a FDD •1997-1998,Singapura •Contexto: Desenvolvimento de um grande sistema de empréstimos para o United Overseas Bank •Anteriormente, após 2 anos de consultoria, 3.500 páginas de casos de (in)uso e um modelo de objetos com centenas de classes, foi avaliado como impossível
- 55. Decisão x Resultado •Decisão: Implantação das metodologias de OOAD de Peter Coad e de PM de Jeff De Luca • Resultado: 2.000 Features entregues por uma equipe de 50 pessoas, 15 meses após a contratação da dupla
- 56. Os “Culpados” Jeff DeLuca Peter Coad Stephen R. Palmer . John M. Felsing
- 57. Sede do UnitedOverseas Bank David Anderson, o GUI-Man Peter Coad e a Equipe de Modelagem Paul Szego e Stephen Palmer Jeff De Luca e os Programadores O Berço da FDD
- 58. O que aFDD pode proporcionar?? • Inovação Contínua • Adaptabilidade do Produto • Cronogramas Reduzidos de Entrega • Adaptabilidade das Pessoas e Processos • Resultados Confiáveis
- 59.
- 60. Características da FDD •Fornece a estrutura suficiente para equipes maiores • Enfatiza a produção de software de qualidade • Entrega resultados freqüentes, tangíveis e funcionais • Realiza trabalho significativo desde o início, antes de tornar-se altamente iterativa • Fornece informação de estado e progresso de forma simples e compreensível • Agrada a clientes, gerentes e desenvolvedores
- 61. O que éFeature? • Característica ou funcionalidade • Pequena o suficiente para ser implementada no máximo em 2 semanas • Oferece valor para o cliente • Mapeia passos em uma atividade de negócio • Pode ser um passo de um caso de uso, podendo ser às vezes o próprio caso de uso • Conceito muito próximo de requisito funcional
- 62. MODELO • <A><R><O> • <Ação><Resultado> <Objeto(s)> • Calcular o Total do Salário do Auxiliar
- 63. Outros Exemplos • Calcularo total das Faturas do Cliente • Autorizar a entrada fora do horário do expediente do colaborador • Assinar digitalmente o documento do processo digital • Calcular o total de horas extras do colaborador • Listar os colaboradores ativos • Destacar os colaboradores com horas extras • Imprimir o total das vendas do período • Validar a senha de um usuário
- 64. Exercício • Coloque asseguintes funcionalidades no modelo sugerido (<A><R><O>): • O usuário é validado antes de entrar no sistema • Ao entregar um material, seu estoque é atualizado • O sistema notifica o usuário sobre o envio do seu pedido • A recepcionista escolhe o quarto do hóspede a partir de uma lista de unidades disponíveis • O médico verifica sua agenda para marcar a próxima consulta do paciente • Ao parir sua cria, a vaca deve ser registrada como não estando mais prenha
- 65. Melhores Práticas da FDD •Modelagem de Objetos do Domínio • Desenvolvimento por Feature • Posse individual de classe (código) • Equipes de Features • Inspeções • Builds regulares • Gerenciamento de configuração • Relatório/visibilidade de resultados
- 66. 1) Modelagem deObjetos do Domínio • Diagramas de classes com os principais tipos de objetos no domínio do problema e suas relações • Auxilia na captura e esclarecimento dos requisitos • Possibilita um entendimento comum e mais completo sobre o domínio do problema • O modelo de objetos do domínio • É o mapa da estrada, que guiará a jornada • Fornece uma estrutura abrangente na qual adicionar funcionalidade • Ajuda a manter a integridade conceitual do sistema • Reduz a quantidade de refactoring • É uma forma de armazenamento e comunicação concisa, relativamente acessível e reutilizável, para todos os envolvidos no projeto
- 67. Exemplo de Modelode Domínio
- 68. 2) Desenvolvimento por Funcionalidade •Pensamento sistêmico, processual, visando o resultado final • As features são o que o cliente realmente usará • Ele entende os termos, o valor e o progresso • Ele pode priorizar pela importância para o negócio • O teste é objetivo (funciona ou não funciona) • É fácil de se determinar quando está pronta • Garante a distribuição organizada de responsabilidades através das classes/módulos • É comum a várias abordagens de desenvolvimento (funcional, estruturada, orientada por objetos, etc.)
- 69. Área 1 Atividade 1.1 Feature1.1.1 Feature 1.1.2 Atividade 1.2 Feature 1.2.1 Feature 1.2.2 Área 2 Atividade 2.1 Feature 2.1.1 Feature 2.1.2 Atividade 2.2 Feature 2.2.1 ClasseA ClasseB ClasseC ! ! ! ! ! ! ! As Features Preenchem o Modelo de Domínio
- 70. 3) Posse individualde classe (código) • Estipula quem (pessoa ou papel) é o responsável final pelo conteúdo de uma classe (pedaço de código) • O dono garante que o propósito da classe é mantido e que as alterações são apropriadas • Há um especialista disponível para explicar como um trecho particular do código funciona, especialmente para classes complexas ou críticas para o negócio • O dono pode implementar uma melhoria mais rapidamente do que outro desenvolvedor • O dono, pessoalmente, possui algo do que se orgulhar por ter feito bem
- 71. 4) Equipes deFeatures • Formadas dinamicamente • Única forma de desenvolver por feature e manter a posse de código • Sob a coordenação de um Programador Líder • Múltiplas mentes projetando • Comparação entre alternativas e escolha da mais apropriada • Membros são os Proprietários de Classes relevantes • Benefício da Posse de Código • Enfatiza o trabalho em equipe • Ninguém termina enquanto a equipe de features não terminar
- 72. Dinâmica: Letras Prá Todos •Objetivo • Demonstrar como funciona a posse coletiva • Atividades • Formar grupos de 3 a 5 pessoas • Cada grupo receberá 3 conjuntos de vogais e 2 de consoantes • Todos podem mexer em quaisquer letras • O instrutor mostrará uma palavra • Cada grupo deverá montar a palavra rapidamente sobre a mesa • O grupo que montar a palavra corretamente primeiro ganha 1 ponto • O grupo terá 1 minuto para discutir como melhorar seu desempenho • Repetir o processo para 5 palavras • Ganha o grupo que fizer mais pontos O B A
- 73. Dinâmica: Equipe de Palavras •Objetivo • Demonstrar como funciona uma equipe de features • Atividades • Formar grupos de 3 a 5 pessoas • Cada grupo receberá 3 conjuntos de vogais e 2 de consoantes • Cada pessoa no grupo será dona de um conjunto de letras • Apenas o “dono” das letras poderá mexer nelas • O instrutor mostrará uma palavra • Cada grupo deverá montar a palavra rapidamente sobre a mesa • O grupo que montar a palavra corretamente primeiro ganha 1 ponto • O grupo terá 1 minuto para discutir como melhorar seu desempenho • Repetir o processo para 5 palavras • Ganha o grupo que fizer mais pontos O B A
- 74. 5) Inspeções • Quandobem feitas, são muito úteis na melhoria da qualidade do design e do código • São recomendadas desde 1970 e a evidência pesa fortemente a seu favor • Numa experiência com 11 programas, o erro médio por 100 linhas de código caiu de 4,5 para 0,82 • Inspeções cortam erros em mais de 80% • 1 hora de inspeção pode evitar de 5 a 30 horas de correções • Benefícios secundários • Transferência de conhecimento • Conformidade com padrões
- 75. 5) Inspeções Teste Unitário TesteFuncional Teste de Integração Inspeção de Design Inspeção de Código Jones, C.L. “A Process-Integrated Approach to Defect Prevention”, IBM Systems Journal
- 76. 6) Montagens Freqüentes • Emintervalos regulares, compilar o sistema com todas as features completadas até o momento • Semanalmente, diariamente ou continuamente • Ajuda a antecipar erros de integração • Garante que sempre haverá alguma coisa para mostrar ao cliente • Oportunidades • Geração de documentação • Execução de scripts de auditorias e métricas • Testes de regressão • Notas da versão (novas features, defeitos corrigidos, etc.) • Os resultados podem ser publicados na intranet do projeto
- 77. 7) Gerenciamento de Configuração •Disciplina que suporta e controla as evoluções e modificações em artefatos-chave dentro do ciclo de desenvolvimento de um software • Objetivos • Facilitar o desenvolvimento de software • Garantir a integridade dos produtos • Controlar efetivamente as modificações • Itens de Configuração: Artefatos gerados ou manipulados durante o ciclo de vida da aplicação • Arquivos, Requisitos, Documentos, Modelos, Testes • Processos, Contratos, Regulamentações • Solicitações de Mudança, Defeitos, Tarefas Principais Artefatos de Desenvolvimento Desenvolvimento do Produto Gerenciamento
- 78. Tarefas Rotineiras do Gerenciamentode Configuração • Versionamento • Check out/check in • Histórico de revisões • Branching & Merging • Visões de Projeto • Gestão de Mudanças • Acompanhamento de defeitos • Listas de Melhoria • Associações • Rastreabilidade • Gestão de Tarefas • Criação e Acompanhamento • Ficha de tempo ! Gerenciamento de Processo " Definição de Workflow " Critérios de Entrada/Saída " Notificações " Garantia de Segurança ! Gerenciamento de Montagem " Identificação de Dependências " Controle de Montagens ! Gerenciamento de Liberação " Rótulos " Estados Promocionais " Implantação
- 79. 8) Relatório/Visibilidade de Resultados !Para que o cliente e os gestores possam direcionar o projeto corretamente é preciso " Uma figura acurada do estado atual do projeto " Saber o quão rápido a equipe adiciona funcionalidade " O resultado geral desejado ! Ter um método simples, de baixa sobrecarga, para coletar informação de progresso de forma acurada e confiável ! Formatos de relatórios objetivos e intuitivos, para todos os interessados no projeto
- 80.
- 81. Principais Papéis Líder (Gerente de Projetos) Especialista Domíniodo Negócio Gerente de Desenvolvimento Programador Líder Arquiteto Líder Proprietário de Classes
- 82. Líder / Gerentede Projeto • Coordena as ações da equipe do projeto, controla o progresso e reporta para a alta gerência e interessados no projeto • Responsável pelo gerenciamento de: escopo, tempo, custo, qualidade, riscos, comunicação, recursos humanos, suprimentos e integração • Responsável por todos os assuntos administrativos do projeto, o que inclui o gerenciamento de recursos, orçamento, equipamentos e outros. • Principal meta é fornecer subsídios para que nenhum fator externo atrapalhe a produtividade da equipe do projeto
- 83. Gerente de Desenvolvimento • Possuihabilidades técnicas e gerenciais necessárias para coordenar as ações da equipe de desenvolvimento, operacionalizando as decisões tomadas pelo gerente de projeto • Responsável por liderar o dia-a-dia do desenvolvimento do produto. • Por ser o responsável por resolver qualquer conflito técnico que exista entre programadores- chefes, precisa possuir boa experiência no desenvolvimento de software e nas tecnologias que estarão sendo utilizadas no projeto
- 84. Especialista no Domínio deNegócio • Compreende as regras e a dinâmica do domínio do problema sendo considerado • É o responsável por informar a equipe do projeto sobre o que deve ser feito para que o produto do projeto seja adequado às necessidades dos usuários • Usa o seu conhecimento no negócio para apresentar à equipe do projeto as necessidades para que o software possua valor real • Deve estar sempre disponível para fornecer aos desenvolvedores maior detalhamento sobre determinada funcionalidade • É um um membro fixo da equipe e sempre esta fornecendo feedback das entregas para todos os envolvidos.
- 85. Arquiteto Líder • Éum profissional com experiência em análise e modelagem orientada a objetos, capaz de liderar a equipe no desenvolvimento do modelo que será construído para implementar as features identificadas • Possui habilidade para atuar como facilitador na absorção das regras de negócio • Será ele o responsável pela última palavra em toda arquitetura do sistema.
- 86. Programador Líder • Tambémchamado de Programador-Chefe • É um profissional mais experiente, que possui reconhecimento como tal pela equipe • Coordena o desenvolvimento das features, monta as equipes de features e participa das definições técnicas, além de ser também um Proprietário de Classes • Normalmente é atribuído a ele a propriedade das classes mais complexas do sistema • Possui papel fundamental nas fases de absorção do conhecimento de negócio e no planejamento das funcionalidades.
- 87. Proprietário de Classes •É um desenvolvedor da equipe, ao qual foram atribuídas certas classes do modelo • Sempre que uma feature for escolhida para desenvolvimento e necessitar dos serviços oferecidos por algumas das classes que estão sob sua “custódia”, ele será escalado para participar da equipe de features nessa iteração • Programa, diagrama, testa e documenta as funcionalidades a ele atribuídas pelo Programador- chefe da equipe.
- 88. Gerente de Versão Guru da Linguagem Engenheirode Desenvolvimento Produtor de Ferramentas e Utilitários Administrador de Sistemas Testadores Implantadores Escritores Técnicos Funções de Apoio
- 89. Cuidado para... Sua equipenão ficar assim:
- 90.
- 91. Concepção e Planejamento Construção Desenvolver umModelo Abrangente Planejar por Feature Mais conteúdo na forma Mais forma que conteúdo Modelo de Objetos Pacotes de Trabalho Produto Plano de Desenvolvimento Progresso Construir a Lista de Features Fonte: Heptagon – www.heptagon.com.br Os 5 Processos Detalhar por Feature Construir por Feature
- 92. O Porquê deCada Processo ! Desenvolver um Modelo Abrangente " Modelagem dos Processos de Negócio (BPM) " Captura de Requisitos " Análise Orientada por Objetos (OOA) ! Construir a Lista de Features " Decomposição Funcional ! Planejar por Feature " Plano de Desenvolvimento " Prioridade, Dependência, Distribuição de Trabalho ! Detalhar por Feature " Design/Projeto OO (OOD), Estudo Detalhado ! Construir por Feature " Programação OO (OOP) " Inspeção, Testes, Integração
- 93. Gestão Ágil deProjetos Concepção e Planejamento Construção Análise OO Planejamento Decomposição Funcional Projeto OO Programação e Teste OO Engenharia de Requisitos Desenvolvimento de Requisitos Gerência de Requisitos Gerência de Configuração Principais Disciplinas Envolvidas
- 94. Análise e Desenho/Projeto Orientadospor Objetos ! Análise OO " É um método de análise que examina os requisitos a partir da perspectiva das classes e objetos encontrados no vocabulário do domínio do problema " Enfatiza a construção de modelos do mundo real usando uma visão de mundo orientada por objetos ! Desenho/Projeto OO " É um método de projeto que abrange o processo de decomposição orientado por objetos e uma notação para descrever os modelos lógicos e físicos, estáticos e dinâmicos, do sistema sendo projetado " Enfatiza a estruturação eficaz e apropriada de um sistema complexo, sem se prender a detalhes de implementação
- 95. Programação e Teste Orientadospor Objetos ! Programação OO " É um método de implementação no qual os programas são organizados como coleções cooperativas de objetos, cada qual representando uma instância de alguma classe e cujas classes são todas membros de uma hierarquia de classes unidas por relacionamentos de herança " Enfatiza o uso de objetos, e não de algoritmos, como blocos de construção lógica fundamentais ! Teste OO " É um método de verificação do comportamento dos objetos em tempo de execução " Enfatiza inicialmente o comportamento individual (unitário) de cada classe de objetos, passando para o relacionamento entre objetos, seu funcionamento como componente/serviço, e a orquestração entre os componentes/serviços
- 96.
- 97. Mão Na Massa !É hora de iniciar o projeto! ! O instrutor e a turma decidirão sobre um domínio de negócio a ser usado como exemplo ! Descrever o propósito para o sistema ! Criar o mapa estratégico para o projeto ! Usar mapas mentais para capturar e comunicar os principais conceitos do domínio de negócio
- 98. 1. Desenvolver umModelo Abrangente ! Também chamada de “Modelagem de Objetos do Domínio” ! Preocupa-se mais com a forma do que com o conteúdo ! Auxilia na captura e esclarecimentos dos requisitos ! Possibilita um entendimento comum e mais completo sobre o domínio do problema
- 99. 1. Desenvolver umModelo Abrangente ! É uma atividade inicial de estudo, análise e modelagem do sistema ! Realizada em grupos ! O modelo gerado é suficientemente abrangente, mas não detalhado ! O objetivo é ter uma definição a priori do que será feito, para guiar a equipe durante a fase de construção ! Artefatos produzidos: " Diagramas de classes, sequência, atividades, estados, casos de uso " Lista preliminar de requisitos " Anotações nos modelos DPF CPF DMA CLF PPF
- 100. Formar a Equipe deModelagem (Gerente do Projeto) Conduzir um Estudo Dirigido Sobre o Domínio de Negócio (Ger. Projeto, Especialistas) Estudar Documentos (Equipe de Modelagem) Desenvolver Modelos em Pequenos Grupos (Equipe de Modelagem em pequenos grupos) Desenvolver um Modelo como Equipe (Equipe de Modelagem) Refinar o Modelo de Objetos Completo (Arquiteto Líder, Equipe de Modelagem) Escrever Comentários Sobre o Modelo (Arquiteto Líder, Programador Líder) opcional 1. Desenvolver um Modelo Abrangente
- 101. Apresentação Negócio – Domíniodo Problema Persistência Interface com Outros Sistemas Foco Arquitetura em Camadas
- 102. UML em Cores !Padrão de análise e modelagem desenvolvido por Peter Coad, na última metade da década de 1990 ! Auxilia tanto na criação quanto na melhoria de modelos da classes ! Fácil de aprender e explicar ! Propõe a utilização de 4 arquétipos " arquétipo. s.m. 1 modelo ou padrão passível de ser reproduzido em simulacros ou objetos semelhantes; 2 idéia que serve de base para a classificação dos objetos sensíveis; 3 Derivação: por extensão de sentido: qualquer modelo, tipo, paradigma. (Dic. Houaiss da Língua Portuguesa)
- 103. Arquétipo: Momento- Intervalo ! Representaalgo que necessita ser registrado, por razões de negócio ou até mesmo legais, que ocorre em algum momento no tempo ou durante um intervalo de tempo ! São atividades, eventos e serviços ! Um momento-intervalo também pode ter “mi-detalhes”, ou seja, ser composto por pequenas etapas do evento total ! Exemplos: " Uma venda é algo que acontece num certo momento " Uma estada é o período de tempo que o veículo fica sob a responsabilidade do estacionamento ! Para identificar esse arquétipo usamos a cor rosa e o estereótipo <<moment-interval>> (também usa-se a sigla <<mi>>). Para os detalhes, usamos o estereótipo <<mi-detail>>. ! É comum a classe estar acompanhada de um diagrama de máquina de estados, para definir seu comportamento em tempo de execução
- 104. Arquétipo: Pessoa- Lugar-Coisa ! Representa: "Uma pessoa (física ou jurídica) " Um certo local (endereço, casa, privado ou público) " Algum objeto, geralmente concreto ! São entidades que devem ser registradas no sistema por desempenharem papéis nas atividades (momentos-intervalos) ! Uma mesma pessoa pode participar de eventos distintos, através de papéis diferentes ! Identificamos esse arquétipo com a cor verde e o estereótipo correspondente: <<party>>, <<place>> ou <<thing>> ! É onde geralmente aparecem os “cadastros” e “relatórios” simples
- 105. Arquétipo: Papel ! Éa representação de um papel que é desempenhado por pessoa, lugar ou coisa, em um determinado evento do negócio (momento-intervalo) ! É mais comumente aplicado a pessoas, mas é possível utilizá-lo com lugares e até mesmo com coisas ! Exemplo: " Um aeroporto pode desempenhar o papel de local de origem, destino ou escala de um vôo " Uma pessoa, num hotel, pode ser recepcionista, gerente, hóspede, vigilante, etc. ! Sua cor é o amarelo e o estereótipo é <<role>>
- 106. Arquétipo: Descrição ! Écomo um item num catálogo, definindo as características de uma determinada coisa, lugar ou até mesmo pessoa (menos comum, mas possível) ! Usado para concentrar dados comuns a diversos objetos, possibilitando perguntas de negócio interessantes, como a quantidade de objetos de um determinado tipo ! Aparece na cor azul (quase cinza, dependendo da ferramenta de modelagem) e usa-se o estereótipo <<description>> ! São as famosas “referências” usadas em combos e lookups
- 107. Domain Neutral Component (ComponenteGenérico de Modelagem) ! Padrão para análise OO (Camada de Negócio) ! Mostra o relacionamento entre os arquétipos ! Diminui a variação no processo de modelagem ! Padroniza o entendimento " Equipe de Negócio " Equipe de TI
- 108.
- 109.
- 110. Mão Na Massa !Seguir o processo 1 para criar o modelo de objetos do domínio de negócio " Os Especialistas no Domínio farão apresentações sobre o negócio " A Equipe de Modelagem fará perguntas e anotações " Em pequenos grupos, desenvolver alternativas de modelos (usando os 4 arquétipos e o DNC) " Obter consenso no grande grupo sobre um modelo único " Anotar nesse modelo as razões para as decisões tomadas
- 111. 2. Construir aLista de Features ! Com o modelo básico criado, deve-se agora criar uma lista de features ! É uma decomposição funcional do domínio do negócio ! Categorizada em 3 níveis: " Áreas de Negócio (Grandes Conjuntos de Features) " Atividades de Negócio (Conjuntos de Features) " Passos da Atividade de Negócio (Features) ! Artefatos produzidos: " Lista de Features " Requisitos mais detalhados DPF CPF PPFCLFDMA
- 112. Formar a Equipe deLista de Features (Gerente do Projeto, Gerente de Desenvolvimento) Construir a Lista de Features (Equipe de Lista de Features) 2. Construir a Lista de Features
- 113. Sistema ou Aplicação Área deNegócio Área de Negócio Área de Negócio Atividade de Negócio Atividade de Negócio Atividade de Negócio Atividade de Negócio Atividade de Negócio Atividade de Negócio Atividade de Negócio Atividade de NegócioFuncionalidade Funcionalidade Gerenciamento de ... <Substantivo> <VerboInfinitivo> ... <Ação> <Resultado> <Objeto> FBS: Feature Breakdown Structure
- 114. Classe A Classe B ClasseC ÁREA N Atividade X Feature 1 Feature 2 Atividade Y Feature 3 Feature 4 Feature 5 ... As Features preenchem o Modelo
- 115. Mão Na Massa !Seguir o processo 2 para criar a lista de features " Se necessário, consultar os Especialistas no Domínio " Geralmente são eles quem determinam as áreas de negócio e até as próprias atividades de negócio " Verificar se há redundância entre as features " Verificar se as features estão escritas de acordo com o padrão sugerido
- 116. Processo Nº 3: Planejarpor Feature ! Com a lista e o modelo, deve-se agora planejar a ordem na qual as funcionalidades serão implementadas, tendo como base: " a necessidade do usuário (importância, prioridade) " as dependências entre elas " a carga de trabalho da equipe de desenvolvimento " a complexidade das funcionalidades ! As responsabilidades são distribuídas para a equipe ! Artefatos produzidos: " Plano de desenvolvimento " Pacotes de trabalho " Lista de classes com seus donos DPF CPF DMA CLF PPF
- 117. Formar a Equipe dePlanejamento (Gerente do Projeto) Determinar a Sequência de Desenvolvimento (Equipe de Planejamento) Atribuir Conjuntos de Features para Programadores Líderes (Equipe de Planejamento) Atribuir Classes para os Desenvolvedores (Equipe de Planejamento) Processo Nº 3: Planejar por Feature
- 118. Estimativas • Truco (ouPoker) da Estimativa ! A Escala de 5 Pontos Nº Estimado de Classes na Feature Complexidade da Feature Esforço (Pessoa-Dia) 1 1 0,5 2 2 1 3 3 2 4 4 4 5 5 8 (ou mais) David Anderson, Agile Management for Software Engineering, 2003
- 119. O Plano de Desenvolvimento !Com as features devidamente estimadas, o plano de desenvolvimento é criado a partir da capacidade de produção ! Com as features na ordem desejada, corta-se a lista em blocos que caibam nas durações das iterações (1 ou 2 semanas) " Cuidado para não quebrar em pontos que causem problemas ! Cada pacote de trabalho deve ser atribuído a um Programador Líder ! Com as “datas” de cada iteração, preencher as “datas” planejadas de cada um dos 6 milestones (as datas geralmente são iguais para as features da iteração) Iteração 1 Iteração 2 Iteração 3 Iteração 4 Pacote 1 (10) Pacote 2 (8) Pacote 3 (13) Pacote 4 (15)
- 120. Mão Na Massa !Seguir o processo 3 para criar o plano de desenvolvimento " Estimar as features, de acordo com a escala de 5 pontos ou pelo Truco da Estimativa " Consultar um representante do cliente sobre as prioridades " Determinar a dependência entre as features " Atribuir classes aos desenvolvedores " Verificar a distribuição da carga de trabalho entre os Proprietários de Classes " Determinar quantas iterações de 2 semanas serão necessárias " Criar o plano de desenvolvimento, com as datas previstas para cada iteração
- 121. 4. Detalhar porFeature ! Agora na fase de construção propriamente dita, deve- se refinar o projeto (design) para cada feature ou conjunto de features relacionadas ! A equipe de features será formada pelos proprietários das classes envolvidas ! O resultado será um pacote de trabalho, sob a responsabilidade de um programador líder ! Artefatos produzidos: " Modelos detalhados (classes e seqüência) " Esqueletos de classes com métodos " Pacote de trabalho detalhado " Relatório de inspeção do design " Relatório de progresso atualizado DPF CPF DMA CLF PPF
- 122. Formar a Equipe deFeatures (Programador Líder) Conduzir um Estudo Dirigido Sobre o Domínio de Negócio (Especialista no Domínio) Estudar Documentos de Referência (Equipe de Features) Desenvolver os Diagramas de Sequência (Equipe de Features) Refinar o Modelo de Objetos (Programador Líder) Escrever Prólogos de Classes e Métodos (Equipe de Features) Inspecionar o Projeto (Design) (Equipe de Features) opcional opcional opcional 4. Detalhar por Feature
- 123. 5. Construir porFeature ! Os proprietários de classes desenvolvem o código correspondente a cada feature ! Os testes de unidade e as inspeções são realizados ! O código final (aprovado) é promovido ao build atual ! O resultado são funções com valor para o cliente (features) ! Artefatos produzidos: " Código fonte testado e integrado " Relatórios de inspeção e testes " Lista de alterações feitas/necessárias " Relatório de progresso atualizado DPF CPF DMA CLF PPF
- 124. Implementar Classes e Métodos (Equipede Features) Testes Unitários (Equipe de Features) Conduzir uma Inspeção no Código (Equipe de Features) Promover para o Build (Programador Líder, Equipe de Features) 5. Construir por Feature
- 125.
- 126. Medindo o Progresso !No ciclo iterativo (processos 4 e 5), o progresso é medido com base em 6 marcos (milestones) bem definidos ! A cada etapa cumprida, o percentual respectivo é agregado ao total de progresso da feature Estudo Dirigido Sobre o Domínio 1% Desenho (Projeto) 40% Inspeção do Desenho 3% Codificação 45% Inspeção do Código 10% Promoção ao Build 1% Nº 4: Detalhar por Feature Nº 5: Construir por Feature DMA CLF PPF DPF CPF
- 127. Legenda: Atividade emandamento Requer atenção Completada Não iniciada Id Descrição P.C. D.C. Est. Dirig. Design Insp. Design Codif. Insp. Cod. Build Plan. Real. Plan. Real. Plan. Real. Plan. Real. Plan. Real. Plan. Real. 12 Agendar um serviço para um carro HM AS 10/02 10/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 13 Incluir um novo cliente na lista de clientes HM VS 01/02 01/02 04/02 04/02 05/02 05/02 07/02 07/02 08/02 08/02 09/02 09/02 14 Registrar um serviço realizado num carro AR AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 15 Registrar uma lista de peças utilizadas num serviço AR AS SM 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 Status: SM ficou doente (previsão de retorno: 01/03 16 Calcular o custo total das peças usadas num serviço HM AS SM 10/02 10/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 17 Enviar uma fatura para um cliente AR VS 08/03 10/03 13/03 17/03 19/03 20/03 18 Receber um pagamento por um serviço HM AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 19 Registrar a opção de pagamento preferida por um cliente AR VS Status: Não mais necessária (será feita diretamente no cadastro do cliente) Monitorando as Features
- 128. NE PendentesBacklog Fulano Beltrana Sicrano Zé J.J. Iniciadas Inspeção/Teste Finalizadas NN I N N NE N I N NN N N N N N N I E N N N N N N N I Quadro de Tarefas
- 129. Início: Fim: ID: Resp.: Descrição: Início: Estimativade retorno: ID: Resp.: Motivo: RN12 Sic 18/06 09:15 VN: A Fórmula de cálculo do imposto: I = ValorBruto * Aliquota Aliquota -> parâmetro AI3 Classe -> Venda Tela -> pgVenda Cartão de tarefa normal (azul) ou emergência (amarelo) Cartão de impedimento (rosa) Est.: 4 RN12 Sic 19/06 9:00 18/06 11:30 Classe Venda está sendo alterada por outra tarefa Exemplos de Kanbans
- 130. Mês/Ano Porcentagem Completada: Prazo deEntrega: Completada Mês e Ano para entrega Status da Atividade: Barra de Progresso Em andamento Requer atenção (ex.: impedimento) Completada Nome da Atividade de Negócio (nº features) 75% Ainda não iniciada Iniciais PC Reportando o Progresso
- 131. Painel de Progresso (ParkingLot) Legenda: Em*andamento Atenção***********************Completada*************************Barra*de*Progresso**** Não*iniciada Gerenciamento*de*Vendas*de*Produtos*(VP)* 34% Entrada*de Pedidos (33) Fev$2006 PC*1 Controle*de Contratos (13) Abr$2006 Venda*de Produtos (22) Nov$2005 PC*1 Envio*de Produtos (19) Mar$2006 PC*1 10% Entrega*de Produtos (10) Abr$2006 PC*3 30% Relatórios*de Vendas (14) Dez$2005 75%99% 3% Ger.*Contas*de*Clientes*(CC)* 90% Análise*de Propostas*de Contas (23) Nov$2005 95% Registro*de Transações das*Contas (30) Dez$2005 82% Abertura de*Novas Contas (11) Nov$2005 100% Gerenciamento*de*Estoque*(GE)* 94% Definição*de Unidades*de Estoque (26) Nov$2005 100% Movimentação de*Mercadorias (19) Jan$2006 82% PC*3 Aceite*de Requisições de*Movimento (18) Dez$2005 97% PC*3 PC*2 PC*1 PC*2 PC*2 PC*2 PC*3 Sistema Comercial (238) Abr$2006 65%
- 132.
- 133.
- 134.
- 135.
- 136. FDD x SCRUMx XP FDD SCRUM XP
- 137. 8. Incremento deProduto (pode ser liberado para uso) 6. Dia 5. Iteração (2 a 4 sem.)4. Tarefas detalhadas pela equipe 1. Visão (RSI, marcos, versões) 2. Lista de Espera (Backlog) de funcionalidades do produto, priorizada pelo Dono do Produto 3. Escopo da Corrida (Sprint) 7. Reuniões Diárias (em pé) Concepção e Planejamento 1 DMA 3 PPF 2 CLF Construção 4 DPF 5 CPF 9. Inspeção e Adaptação Scrum e FDD
- 138. FDD XP Certo planejamentoinicial Planejamento durante o desenvolvimento Refactoring é exceção Refactoring é a norma Programadores Líderes e Proprietários de Classes Posse coletiva do código Design formal e Inspeções de código e modelo Programação em pares FDD e XP: Algumas Diferenças
- 139. OID: Inovação eImplantação Organizacional CAR: Análise e Prevenção de Defeitos 5 Em Otimização 4 Gerenciado Quantitativam. 3 Definido 2 Gerenciado Melhoria Contínua do Processo Gerência Quantitativa Padronização do Processo Gerência Básica de Projetos QPM: Gerenciamento Quantitativo de Projeto OPP: Performance do Processo Organizacional RD: Desenvolvimento de Requisitos TS: Solução Técnica PI: Integração de Produtos VER: Verificação VAL: Validação OPF: Foco no Processo Organizacional OPD: Definição do Processo Organizacional OT: Treinamento Organizacional IPM: Gerência Integrada de Projeto RSKM: Gerência de Riscos DAR: Análise e Tomada de Decisão REQM: Gerência de Requisitos PP: Planejamento de Projeto PMC: Monitoramento e Controle de Projeto SAM: Gerência de Acordos com Fornecedores MA: Medição e Análise PPQA: Garantia da Qualidade do Processo e do Produto CM: Gerência de Configuração 1 Inicial Áreas de ProcessosNível Foco Produtividade Qualidade Risco Retrabalho FDD Agile CMMI
- 140. FDD & MPS.BR NíveisF e G PROCESSO ATENDE PARCIAL NÃO % Nível G: Processo Gerência de Projetos (GPR) 10 5 2 73,5 Nível G: Processo Gerência de Requisitos (GRE) 3 1 1 70 Nível F: Gerência de Configuração (GCO) 5 - 2 71 Nível F: Processo Garantia da Qualidade (GQA) 2 2 - 75 Nível F: Processo Medição (MED) 4 2 1 83
- 141. FDD & MPS.BR NíveisF e G Atende Não Atende Atende Parcial
- 142.
- 143. Aspectos • A FDDé um meta-processo, que pode ser adaptado e aplicado a diversos níveis e necessidades de desenvolvimento • Podemos usá-la para desenvolver aspectos diferentes do produto: • Infra-estrutura (frameworks, persistência, bibliotecas, componentes, ...) • Interface com o usuário • Integração com outros sistemas • O segredo é definir, para cada aspecto, quem é o cliente e derivar as features a partir desta perspectiva
- 144. FFDD: Fractal FDD •Podemos também aplicar a FDD em diferentes níveis do problema ou da organização • Processos de Negócio • Planejamento Estratégico e Tático dos Sistemas • Entendimento dos relacionamentos entre produtores e consumidores de informação • A analogia com um fractal é devida à reaplicação da FDD em determinada etapa de outra aplicação da FDD • Nos Estados Unidos, Mac Felsing está aplicando esse conceito, com o nome de “Enterprise FDD”, para conseguir escalabilidade e uniformidade de comunicação
- 145. Resumindo, a FDD... •É um método ágil e altamente adaptativo, que produz resultados freqüentes, tangíveis e funcionais • Oferece vantagens dos métodos prescritivos (rigorosos), pois implementa o conceito importante de planejamento, mas sem os exageros de documentação e controle • Oferece vantagens dos métodos ágeis, onde a preocupação maior é com a produção de código, mas toma o cuidado de planejar o suficiente e controlar o andamento do projeto • Atende às necessidades dos clientes, gerentes e desenvolvedores
- 146. Dicas para Convencer Gerentese Desenvolvedores • Geralmente a iniciativa começa nos desenvolvedores • Mas se o desenvolvimento se tornar ágil e a gerência continuar tradicional, haverá desgaste • Assim, a Agilidade deve ser um objetivo comum • Realize projetos pilotos para experimentar (e errar!) • Adapte a(s) metodologia(s) e práticas às suas necessidades
- 147. Só para lembrar •Adotar Gestão Ágil e FDD não é uma panacéia • Mas é um bom começo para a melhor compreensão dos caminhos a seguir • Agilidade e Responsabilidade não são antagônicos, mas mutuamente necessários
- 148. Conclusão ! A adoçãoda Gestão Ágil de Projetos e FDD, como qualquer tecnologia, deve ser acompanhada de uma revisão no comportamento, nas políticas, nas métricas e nas regras da organização e das pessoas ! Muitos benefícios estão por vir, mas é preciso saber plantar e cuidar para poder colher ! O retorno vale o investimento! ☺ Motivação é a chave para mudanças!!
- 149. Só para lembrar: MetodologiasÁgeis X Tradicionais
- 150. Waterfall X Ágil 2011-2016 StandishGroup – www.standishgroup.com
- 151. Para saber mais !Agile Alliance " www.agilealliance.org ! Agile Project Management Leadership " www.apln.org ! Agile Management " www.agilemanagement.net ! FDD " www.featuredrivendevelopment.com " www.heptagon.com.br/fdd/ ! Grupos de Discussão " http://groups.yahoo.com/group/AgileProjectManagement " http://br.groups.yahoo.com/group/Agile-Brasil " http://br.groups.yahoo.com/group/GUFDD
- 152.
- 153. Jorge Luis Bublitz •Engenheiro de Sistemas • Graduação em Administração de Empresas • Pós-Graduação (Especialização) em Engenharia de Sistemas • Pós-Graduação (Mestrado) em Engenharia de Sistemas " UNEATLANTICO - Valência - Espanha (cursando) • Gerente de Projetos (TRE-MT) • Coordenador de Projetos Mobile da Justiça Eleitoral • Consultor em Metodologias Ágeis • Artigos publicados nas revistas Micro Sistemas, Clube Delphi, MundoPM e Engenharia de Software Magazine • Palestrante na Conferência da Borland – Borcon Revolutions 2007 • Palestrante na Conferência Mundial da CodeGear – CodeRage III 2008 • Palestrante no Ágiles 2012 (Buenos Aires) e Agile Brazil 2013 • Assinante do Agile Manifesto • Membro da Agile Aliance
- 154. Frase "No que dizrespeito ao empenho, ao compromisso, ao esforço e à dedicação, não existe meio termo. Ou você faz uma coisa bem feita ou não faz."
- 155.
- 156. Um abraço!!!! Valeu !!!!! JorgeFDDMan bublitz@hotmail.com bublitz@tre-mt.jus.br Skype: fddman bublitz.tripod.com jorge-fdd.blogspot.com