Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Feature Driven Development

764 views

Published on

Published in: Technology
  • Be the first to comment

Feature Driven Development

  1. 1. Feature drivendevelopmentMaurício Linhares
  2. 2. O Que é um bomprocesso?Discutam.
  3. 3. É bem definido›  Define estrutura o suficiente pra garantir inovação e criatvidade;›  Mantém tudo dentro do seu tempo e espaço limitado;›  Evita conceitos vagos, abstratos demais ou difíceis de serem explicados;
  4. 4. Define tarefas›  Tarefas sempre focadas em resultados;›  Não especificam os detalhes, deixando espaço pra experimentação e adaptação na hora do resultado;›  Com foco em um tempo pequeno e limitado para garantir o progresso;
  5. 5. Produz dados reais sobreprogresso e status›  É fácil dizer onde estamos, pra onde vamos e quando vamos chegar lá;›  Demonstra claramente onde estão os gargalos do trabalho;›  Evita ocupar demais o tempo dos desenvolvedores com “gestão de tempo”;
  6. 6. Torna-se natural›  As pessoas não devem ter que ler mil páginas de um livro pra entender como ele funciona;›  Novos membros são facilmente “inoculados” com as novas idéias;›  As pessoas começam a agir naturalmente em vez de por pressão externa;
  7. 7. Mantém qualidadecontrolando a complexidade›  Garante que as pessoas envolvidas sentem-se satisfeitas com os produtos produzidos;›  Não deixa com que a equipe crie complexidade demais para si mesma;›  Foco no pensamento de longo prazo;
  8. 8. Otimiza a comunicação›  Dentro e fora da equipe;›  Removebarreiras organizacionais que complicam a comunicação;›  Acaba com os silos de informação;
  9. 9. Quais os componentes de umprojeto de software?›  Definição de propósito;›  Lista de papéis;›  Pessoas com as habilidades específicas e experiência;›  Um processo bem definido;›  Um conjunto de tecnologias;›  Uma arquitetura;
  10. 10. Mas antes disso…Processos e pessoas outra vez
  11. 11. Produtividade›  Pesquisas indicam que bons desenvolvedores produzem de 10 a 20 vezes mais do que os ruins;›  Equipes com pessoas de pouca formação perdem produtividade e interesse;›  Lidar com pessoas incompetentes aumenta a possibilidade de pedidos de demissão;
  12. 12. Como atrair bonsprofissionais?›  Tenha bons profissionais dentro da equipe;›  Forneça complementos que não sejam diretamente financeiros (plano de saúde, café, livros, ambientes abertos…);
  13. 13. Como encontrar bonsprofissionais?›  A equipe deve ser responsável pela contratação;›  Não deixe pessoas de recursos humanos sem experiência em TI iniciarem as conversas;›  Sabatinas, avaliações de pensamento crítico e modelagem são formas comuns;
  14. 14. Como manter bonsprofissionais?›  Ambiente de comunicação aberta, onde todos sabem o que está acontecendo;›  Qualidade dos produtos e contato com clientes (satisfeitos!);›  Valorização das pessoas por seus companheiros e chefes;›  Eventosde comunidade, como refeições, festas e correlatos;
  15. 15. De volta a FDD - papéis›  Project manager;›  Chief Architect;›  Development manager;›  Chief programmers;›  Class owners;›  Business experts;
  16. 16. Project manager›  Relatórios de progresso;›  Staffing;›  Evitar distrações externas ao projeto;›  Organizar e garantir que o processo está indo pelo caminho certo;
  17. 17. Chief architect›  Responsável pela montagem da arquitetura inicial do projeto;›  Deveter grandes capacidades técnicas e de facilitação, para expor o design para os outros membros da equipe;›  Tem a palavra final sobre as decisões de design do projeto;
  18. 18. Development manager›  Responsável por liderar o trabalho diário de desenvolvimento com a equipe;›  Resolve os conflitos por recursos dentro da equipe e organiza o acesso aos mesmos para que não haja espera;
  19. 19. Chief programmers›  Participam nas definições de requisitos de alto nível;›  Coordenam pequenas equipes de desenvolvimento (de 3 a 6 pessoas) pelo trabalho de codificação e análise final;›  Devem ter qualidades tanto técnicas como também no trato de pessoas;
  20. 20. Class owners›  Desenvolvedores que trabalham em pequenas equipes sobre a supervisão de um Chief Programmer;›  Normalmente são pessoas que desejam continuar na carreira técnica (não querem gerenciar outros) ou ainda estão ganhando experiência;›  Responsáveis pelo design, código, testes e documentação das funcionalidades;
  21. 21. Domain experts›  Clientes, financiadores, analistas de negócios ou qualquer sequência dos passos;›  Pessoas especializadas no domínio onde a aplicação vai atuar, não precisam, necessariamente, ter conhecimento técnico de software;
  22. 22. Coadjuvantes!›  Release manager;›  Language Guru;›  Build Engineer;›  Toolsmith;›  System administrator/DevOps;›  Testers;›  Deployers;›  Technical writers;
  23. 23. Domain object modeling›  Definir diagramas de classes definindo os tipos de objetos dentro de um domínio e os relacionamentos entre eles;›  O foco principal é abrir a discussão entre todos pra que fique claro o que cada objeto deve fazer dentro do sistema;
  24. 24. Domain object modeling - 2›  O foco é definir quais as perguntas cada um dos objetos pode responder dentro do sistema, quais cálculos e serviços eles podem executar;›  Omodelo nunca é final, precisa ser refinado o tempo todo conforme o projeto segue em frente;
  25. 25. Domain object modeling - 3›  O modelo provê um framework onde é possível adicionar funções, a cada funcionalidade definida;›  Ele ajuda a manter a integridade conceitual do sistema e a visibilidade das coisas que estão send produzidas;
  26. 26. Vamos modelar!As idéias originais da aula anterior. Ou uma novaidéia J
  27. 27. Developing by feature›  Cada funcionalidade precisa gerar valor direto para o cliente;›  Tarefas técnicas devem estar incluídas dentro da feature, mas o importante é entregar a feature no final;›  Primeiro se divide a visão geral do projeto em subsistemas;
  28. 28. Developing by feature - 2›  Depois cada subsystema/modulo deve ser mais uma vez dividido em requisitos menores;›  Quando os requisitos chegarem a um tamanho onde é possível saber como eles vão ser implementados, esse é o tamanho ideal;
  29. 29. Developing by feature - 3›  Cadafuncionalidade precisa ser feita em no máximo duas semanas, mas o tamanho ideal é de poucas horas ou dias;›  Features devem ser quantificadas para que haja progresso visível o tempo todo, pra evitar que o desenvolvimento todo pare;
  30. 30. Formato das features›  <ação> <resultado> <objeto> ›  Calcular o total de uma venda ›  Avaliar a performance de um vendedor ›  Validar a senha de um usuário ›  Autorizar uma transação de crédito no banco;
  31. 31. Class/code ownership›  Em FDD desenvolvedores tornam-se donos de classes do sistema e não do sistema como um todo;›  Objetiva manter a consistência do sistema no seu nível mais simples, o das classes;
  32. 32. Class/code ownership›  O responsável pode sempre responder as dúvidas dos outros sobre o que a classe deve fazer ou não;›  Ele pode implementar soluções mais rápido do que outros membros da equipe;
  33. 33. Problemas?›  Uma única pessoa responsável pode fazer com que ela torne-se um gargalo no desenvolvimento;›  Se essa pessoa vai embora da empresa, o seu conhecimento também se vai com ela;
  34. 34. Por que não ser do coletivo?›  As vezes, a propriedade coletiva do código faz com que o código não seja de ninguém;›  Ninguém se sente responsável pelo código escrito;›  A qualidade geral do código produzido diminui e refactorings tornam-se inexistentes;
  35. 35. Mais sobre não ser coletivo›  Pessoaspodem adicionar novas funcionalidades a classe sem ter uma idéia real de como ela deve funcionar realmente;›  Em equipes pequenas e com classes pequenas o funcionamento tende a ser mais simples;
  36. 36. Coletivo ou individual?Qual o melhor?
  37. 37. Feature teams›  Assim como classes vão pertencer a pessoas, funcionalidades também;›  A pessoa responsável pela funcionalidade deve se organizar junto com os responsáveis pelas classes que ela vai precisar que sejam alteradas para coordenar o trabalho da feature;
  38. 38. Feature teams - 2›  Os features devem ser distribuídos entre os desenvolvedores para que cada um tenha um conjunto de itens a trabalhar;›  A equipe deve se reorganizar ao redor das funcionalidades pra garantir que todos os envolvidos estão trabalhando juntos;
  39. 39. Feature teams - 3›  Aofim de cada feature, a equipe se desmancha e novas equipes se fornam para as novas funcionalidades;›  Éimportante que todos estejam o tempo todo trabalhando em conjunto sempre que possível;
  40. 40. Feature teams - 4›  Devem ser pequenos, de 3 a 6 pessoas;›  Todosos envolvidos devem ter participação como donos do código que vai ser criado/modificado;›  Cadamembro contribui com análise, design e implementação da funcionalidade;
  41. 41. Feature teams - 5›  Class owners podem pertencer a várias equipes ao mesmo tempo, mas deve-se evitar fazer disso uma coisa comum (mais de 3 equipes, por exemplo) pra nào acabar com problemas de troca de contexto;›  Todos os envolvidos, inclusive os Chief Programmers, devem estar participando da construção das funcionalidades;
  42. 42. Como as equipes trabalhamno seu dia a dia?E como elas se comunicam na hora de executartarefas relacionadas?
  43. 43. Inspeções›  Devemfazer parte do dia a dia da equipe, com inspeções de todo o código produzido;›  Transferem o conhecimento entre os desenvolvedores, dos mais experientes pros menos experientes;
  44. 44. Inspeções - 2›  Garantema aderência aos padrões de codificação, pois mais de uma pessoa vai ver o código e validar que ele está seguindo o padrão;›  Quandoreunidas com dados reais do mundo, podem demonstrar as partes do sistema que mais dão problema;
  45. 45. Inspeções - 3›  Cuidado pra não fazer com que as inspeções façam as pessoas sentirem-se humilhadas ou diminuídas;›  Inspeções devem ser vistas como uma forma de fazer com que todos aprendam de alguma forma o que está sendo feito;
  46. 46. Inspeções - 4›  EmFDD, uma Feature Team é responsabilizada pelas coisas encontradas durante uma inspeção, não é uma coisa que depende de uma única pessoa;›  Ochief programmer deve organizar as inspecões do código que está sendo produzido;
  47. 47. Como são as inspeçõesno seu dia a dia?Se elas não são, será que elas podem lhe ajudar?
  48. 48. Regular Build Schedule›  A intervalos regulares, o sistema deve ser posto para QA e depois pada produção;›  Os builds devem ser produzidos em uma frequência que faça sentido para o produto, empresa e mercado, pode ser contínuo, diário ou semanal;
  49. 49. Regular build schedule - 2›  Emum ambiente ideal o cliente sempre vai poder ver (e, preferencialmente, usar) as novas funcionalidades conforme elas são entregues;›  O build é o ponto final de avaliação de progresso, é nele que se vê que as coisas estão realmente caminhando;
  50. 50. Regular build schedule - 3›  É possível usar ferramentas automatizadas para auditoria e métricas no códifo fonte;›  Organizaros release notes/ funcionalidades completadas até o período atual;
  51. 51. Como é o seu buildschedule atual?É bom? Pode melhorar?
  52. 52. Configuration management›  Inicialmente, um sistema de controle de versão deve ser o suficiente;›  Soluções complementares devem ser adicionadas conforme as necessidades do projeto, como um sistema de integração contínua;›  É importante manter todos os documentos do projeto também dentro do controle de versão pra garantir backups e o histórico dos mesmos;
  53. 53. Quais ferramentas vocêusa pra CM?
  54. 54. FDD rapidinho1.  Criação do domínio;2.  Usar a informação do domínio e os outros requisitos pra criar a lista de funcionalidades;3.  Planejar rapidinho pra quem vão as responsabilidades;4.  Separar em Feature Teams e começar a produzir por 2 semanas;5.  Volta pro 1 e repete tudo outra vez!
  55. 55. Criação do domínio›  Definir o design inicial do domínio conhecido do projeto, com todos os envolvidos e sobre a guia do Chief Architect;›  Deve funcionar como design de alto nível, não deve incluir preocupações iniciais de baixo nível;
  56. 56. Criação do domínio - 2›  Os especialistas do domínio definem os assuntos gerais e se organizam com as equipes pra produzir os o design inicial de cada um desses assuntos;›  Depoisda criação, todos os times se reúnem mais uma vez para demonstrar as idéias encontradas;
  57. 57. Definir as features›  Depois da modelagem inicial, as equipes devem produzir tantos features quanto possíveis para o primeiro momento;›  As funcionalidades devem ser agrupadas mais uma vez quanto aos assuntos do domínio aos quais elas pertencem;
  58. 58. Repasar feature sets para oschief programmers›  Sequenciar os features em grupos (sets) para que seja possível organizar eles por afinidade;›  Repassar os feature sets para os chief programmers (lembrando da prioridade e dependências das funcionalidades);
  59. 59. Desenvolvendo›  Comos grupos de funcionalidades na mão, os chief programmers formam a equipes e começam a trabalhar nas features;›  Cada feature deve ser planejada e desenvolvida dentro do contexto da equipe;›  Ao fim do desenvolvimento, deve haver um code review do código produzido, estando tudo certo, o código entra pro próximo build;
  60. 60. Progresso e estimativas›  Track by feature;›  O progresso é calculado através da definição de onde cada feature está;›  Tudo é derivado sempre do estado das funcionalidades, não do quanto as pessoas acham que vai demorar;
  61. 61. Fases de uma feature›  Definição de domínio;›  Design;›  Inspeção de design;›  Código;›  Inspeção de código;›  Promoção para o build;
  62. 62. Vantagens›  Não se pergunta nem se gasta o tempo das pessoas discutindo o que elas estão fazendo e a quantas anda o projeto;›  A visibilidade é sempre alta, dado que é facilmente possível de se organizas as features nos seus blocos;
  63. 63. Exemplo de gráfico
  64. 64. Acompanhamento total›  Com o acompanhamento das features é possível indentificar equipes que entregam pouco;›  Tasks que demoram demais pra ser entregues (ou que foram estimados muito errados);›  Quantidadede serviço por fazer e a probabilidade de ser feito no prazo;
  65. 65. Documentação produzida›  Mantenha somente o que for necessário pro futuro ou que sirva de utilidade para a equipe, coisas que eles usam;›  Estimativas,gráficos e acompanhamento de features devem ser mantidos como dados históricos (eles ajudam em planejamentos futuros);›  Responsabilidades (quem fez qual parte do sistema);
  66. 66. Em equipes de integração›  Deve haver uma documentação clara sobre os pontos de integração disponíveis;›  Devem haver exemplos usando as tecnologias que sejam assumidamente as que vão ser utilizadas pra que seja simples de integrar;›  Devem haver pessoas responsáveis por manter essa documentação atualizada e disponível;
  67. 67. Dúvidas?

×