Jorge Luis Bublitz Consultor

Transcrição

1 Jorge Luis Bublitz Consultor

2 Contexto Metodologias Agilidade e Metodologias Ágeis Mudanças FDD

3

4 É 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

5 Caótica Eterno ciclo 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

6 O limite do caos é definido como um estado natural entre ordem e caos, um amplo compromisso entre estrutura e surpresa. O limite do caos pode ser visualizado como um estado instável, parcialmente estruturado (...). É instável porque é constantemente atraído para o caos ou para a ordem absoluta. Juan Nogueira, Surfing the Edge of Chaos: Applications to Software Engineering, 2000

7 Projetos de Software Completados com Alterações 49% Falharam 23% Concluídos com Sucesso 28% Standish Group

8

9 Nenhum floco de neve em uma avalanche se sente responsável por ela Stanislaw Lec escritor polonês

10 Adoção de Metodologias Objetivo: tornar o desenvolvimento mais previsível e mais eficiente Impõe disciplinas rígidas Processos detalhados = Documentação Planejamento é a ênfase Passam a impressão de serem uma PANACÉIA cura para todos os males

11

12

13 Também chamado de Modelo em Cascata (Waterfall) Proposto por Winston W. Royce em 1970 Orientado para documentação Ênfase em planejamento, horários, prazos, orçamentos e implementação de sistemas inteiros Há variantes: Incremental, Evolucionário,...

14

15 Qualidade Escopo Prazo Custo

16

17 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

18 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

19 Antes chamadas de Metodologias Leves Tornou-se popular no ano de 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

20 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.

21 Satisfação do Cliente Simplicidade Responder às Mudanças Ritmo Constante Princípios Ágeis Entrega frequente Software que Funciona Motivação

22 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

23

24 Proporcionalmente, as metodologias tradicionais ainda dominam Metodologias Ágeis exigem 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

25 Apoio das instâncias superiores Gerenciamento de equipes Problemas técnicos Interação com outros departamentos Interação com clientes

26

27 Projetos e Processos

28 Única constante do universo: MUDANÇA Para melhorar Para motivar Para nos tornarmos mais eficientes e eficazes Para nos tornarmos mais ágeis

29

30 Um projeto é um problema agendado para solução. Um projeto é uma coleção de valor agendada para realização. Joseph Moses Juran ( ) David J. Anderson

31 É um empreendimento não repetitivo, que possui as seguintes características: É temporário Resulta em produto(s) que não existia(m) antes, ou existirá(ão) de forma diferente (exclusividade) Possui restrições em custo, prazo, qualidade, recursos Exige uma coordenação para ser executado (isto é, possui certo grau de complexidade) Conduzido por pessoas

32

33

34 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 Coad, De Luca (JMCU)

35 É 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

36 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

37

38 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. Jorge L. Bublitz Revisão: Adail Muniz

39 , Singapura Contexto: Desenvolvimento de um grande sistema de empréstimos para um banco internacional Anteriormente, após 2 anos de consultoria, páginas de casos de (in)uso e um modelo de objetos com centenas de classes, foi avaliado como impossível Decisão: Implantação das metodologias de OOAD de Peter Coad e de Gerência de Projetos de Jeff De Luca Resultado: Features entregues por uma equipe de 50 pessoas, 15 meses após a contratação da dupla

40 Jeff De Luca Peter Coad Stephen Palmer John Mac Felsing

41 Inovação Contínua Adaptabilidade do Produto Cronogramas Reduzidos de Entrega Adaptabilidade das Pessoas e Processos Resultados Confiáveis

42 Fornece a estrutura suficiente para equipes maiores Enfatiza a produção de software de qualidade Entrega resultados frequentes, 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

43 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

44 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

45 <ação> <resultado> <objeto> Calcular o total do salário do funcionário ação objeto resultado Novidade? Nunca viu algo parecido? ENTRADA PROCESSAMENTO SAÍDA

46 Emitir recibo de entrega do processo Autorizar a entrada fora do horário do expediente do funcionário Assinar digitalmente o documento PDF Autorizar a transferência do equipamento

47 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 É fácil de determinar quando está pronta

48 Fonte: Autor: Adail Muniz

49

50

51 Sua equipe não ficar assim:

52 Formadas dinamicamente Única forma de desenvolver por feature e manter a posse de código Sob a coordenação de um Programador- Chefe Múltiplas mentes projetando Comparação entre alternativas e escolha da mais apropriada Membros são os Donos 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

53 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 simulacros ou objetos semelhantes

54 Representa algo que necessita ser registrado, que ocorre em algum momento ou durante ou intervalo de tempo São atividades, eventos e serviços Exemplos: Uma venda é algo que acontece num certo momento Uma estada (período de tempo) Cor Rosa

55 Representa: Uma Pessoa Um certo local Algo objeto (normalmente concreto) Desempenham papéis nos Eventos É onde aparecem os cadastros e relatórios simples Cor Verde

56 É a representação de um papel que é desempenhado pelo Pessoa-Coisa-Lugar Exemplos: Uma pessoa, num hotel, pode ser funcionário, hóspede, terceirizado,... Um aeroporto pode ser local de origem, destino ou escala de um vôo Cor Amarelo

57 É como um item num catálogo Usado para concentrar dados comuns a diversos objetos São as famosas referências usadas em combos e lookups Cor Azul

58 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

59 Diagrama de: Classes * Sequência Estados Casos de Uso Lista preliminar de Features Anotações nos Modelos

60

61 É uma decomposição funcional do domínio do negócio Categorizada em 3 níveis: 1. Áreas de Negócio 2. Atividades de Negócio (Conjunto de Features) 3. Passos (Features) Artefatos produzidos: Lista de Features Requisitos mais detalhados

62 Área de Negócio (Gerenciamento/Administração de...) Gerenciamento de Recursos Humanos Atividade Atividade Atividade Análise da Registro de Registro de (<Verbo Infinitivo>...) Feature 4 Feature 9 Documentação Novos Cursos e Feature 1 Feature 5 Feature 10 Feature 12 Servidores Eventos Feature 2 Feature 6 Feature 11 Feature 13 Feature 14 Feature x Feature 3 Feature 7 Feature 15 Feature y Feature 8 Feature 16 Feature z

63 Área n Atividade X Feature 1 Feature 2 Atividade Y Feature 3 Feature 4 Feature 5... Classe A Classe B Classe C

64 Com a Lista e o Modelo, deve-se agora planejar a ordem na qual as funcionalidades serão implementadas, tendo com base: A necessidade do usuário 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

65 Pressuposto: a equipe usa UML em cores e arquétipos A Escala de 5 Pontos Nº Estimado de Classes na Feature Complexidade da Feature Esforço (Pessoa-Dia) (ou mais)

66 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 Cuidado para não quebrar em pontos que causem problemas Interação 1 Interação 2 Interação 3 Interação n (10) (8) (13) (y)

67 Deve-se refinar o projeto para cada Feature ou Conjunto de Features relacionadas Artefatos produzidos: Modelos detalhados (Classes e Sequência) Esqueletos de Classes com métodos Pacote de Trabalho detalhado Relatório de progresso atualizado

68 Os proprietários de classes desenvolvem o código correspondente a cada Feature Testes * e Inspeções são realizados O código final o aprovado é promovido

69

70 Status da Atividade: Em andamento Requer atenção Completada Não iniciada Nome da Atividade de Negócio (nº de features) 75% Mês/Ano

71 Fonte: Autor: Adail Muniz

72

73 Autorização para Entrada fora do Horário do Expediente Como funciona hoje: 1. Servidor preenche Requerimento 2. Chefia imediata autoriza 3. Chefia Superior também autoriza 4. Encaminha requerimento a Seção de Segurança 5. Encaminha Requerimentos Autorizados a guarita

74 1. Servidor preenche requerimento em uma página da Intranet, acessada através de senha 2. Chefia imediata recebe com a solicitação e ali mesmo clica em link para acessar o sistema, que pode autorizar ou não 3. Sendo autorizada, é enviada para Chefia Superior, que também pode autorizar ou não 4. Chefe da Segurança recebe informando da autorização 5. O sistema gera uma página automaticamente a cada dia com os requerimentos autorizados

75

76 Autenticar usuário no sistema Preencher o requerimento de autorização Enviar a Chefia Imediata Autorizar/Recusar o requerimento pela Chefia Imediata Enviar a Chefia Superior Autorizar/Recusar o requerimento pela Chefia Superior Enviar ao Chefe da Segurança Gerar listagem de requerimentos autorizados

77 1ª Entrega 2ª Entrega 3ª Entrega Autenticar usuário no sistema Preencher o requerimento de autorização Autorizar/Recusar o requerimento pela Chefia Imediata Autorizar/Recusar o requerimento pela Chefia Superior Gerar listagem de requerimentos autorizados Enviar a Chefia Imediata Enviar a Chefia Superior Enviar ao Chefe da Segurança

78 RUP Rigorosidade Controle Equipes grandes Quero apenas o Processo Suficiente XP / SCRUM Agilidade Liberdade Equipes pequenas Escalável para Equipes Pequenas, Médias e Grandes

79 Estratégia Feito pela gerência superior Portfólio Produto Entrega Interação Feito pela equipe de projeto Dia

80

81 Nível 2 Gerenciado Foco: Gerência Básica de Projetos Gerência de Requisitos Planejamento de Projeto Monitoramento e Controle de Projeto Gerência de Acordos Com Fornecedores Gerência de Subcontratação Medição e Análise Garantia da Qualidade do Processo e do Produto Gerência de Configuração Fonte: Autor: Adail Muniz

82 Nível 3 Definido Foco: Padronização do Processo Desenvolvimento de Requisitos Solução Técnica Integração do Produto Verificação Validação Foco no Processo Organizacional Definição do Processo Organizacional Treinamento Organizacional Gerenciamento de Risco Análise e Tomada de Decisão Ambiente Organizacional para Integração Fonte: Autor: Adail Muniz

83 A adoção da 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 muitas vezes o investimento! Motivação é a chave para mudanças!!

84 Agile Alliance Agile Project Management Leadership Agile Management FDD Grupos de Discussão

85

86 Principal divulgador da FDD no Brasil Adail Muniz Retamal Heptaman

87 "No que diz respeito 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."

88 Jorge Luis Bublitz Formado em Administração de Empresas MBA em Planejamento Estratégico Pós-Graduação (Especialização) em Engenharia de Sistemas Chefe da Seção de Banco de Dados (TRE-MT) Certificação Delphi e JBuilder Artigos publicados nas revistas Micro Sistemas (!?) e Clube Delphi Palestrante no 12º Congresso MT Digital Palestrante na Conferência da Borland Borcon Revolutions 2007 Palestrante na Conferência Mundial da CodeGear CodeRage III 2008 Assinante do Agile Manifesto Membro da Agile Aliance

89

90 Jorge FDDMan e MSN: bublitz@hotmail.com Páginas: