Feature Driven Development

722 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
722
No SlideShare
0
A partir de incorporações
0
Número de incorporações
16
Ações
Compartilhamentos
0
Downloads
8
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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?

×