Feature Driven Development

  • View
    453

  • Download
    0

Embed Size (px)

DESCRIPTION

 

Text of Feature Driven Development

  • 1. Feature drivendevelopmentMaurcio Linhares

2. O Que um bomprocesso?Discutam. 3. bem definido Defineestrutura o suficiente pra garantirinovao e criatvidade; Mantm tudo dentro do seu tempo eespao limitado; Evita conceitos vagos, abstratos demaisou difceis de serem explicados; 4. Define tarefas Tarefas sempre focadas em resultados; Noespecificam os detalhes, deixandoespao pra experimentao eadaptao na hora do resultado; Com foco em um tempo pequeno elimitado para garantir o progresso; 5. Produz dados reais sobreprogresso e status fcil dizer onde estamos, pra onde vamos e quando vamos chegar l; Demonstra claramente onde esto os gargalos do trabalho; Evita ocupar demais o tempo dos desenvolvedores com gesto de tempo; 6. Torna-se natural Aspessoas no devem ter que ler mil pginasde um livro pra entender como ele funciona; Novos membros so facilmente inoculadoscom as novas idias; Aspessoas comeam a agir naturalmenteem vez de por presso externa; 7. Mantm qualidadecontrolando a complexidade Garanteque as pessoas envolvidassentem-se satisfeitas com os produtosproduzidos; No deixa com que a equipe criecomplexidade demais para si mesma; Foco no pensamento de longo prazo; 8. Otimiza a comunicao Dentro e fora da equipe; Removebarreiras organizacionais quecomplicam a comunicao; Acabacom os silos de informao; 9. Quais os componentes de umprojeto de software? Definio de propsito; Lista de papis; Pessoas com as habilidades especficas eexperincia; Um processo bem definido; Um conjunto de tecnologias; Uma arquitetura; 10. Mas antes dissoProcessos e pessoas outra vez 11. Produtividade Pesquisasindicam que bons desenvolvedoresproduzem de 10 a 20 vezes mais do que osruins; Equipescom pessoas de pouca formaoperdem produtividade e interesse; Lidar com pessoas incompetentes aumenta apossibilidade de pedidos de demisso; 12. Como atrair bonsprofissionais? Tenhabons profissionais dentro daequipe; Fornea complementos que no sejamdiretamente financeiros (plano de sade,caf, livros, ambientes abertos); 13. Como encontrar bonsprofissionais? Aequipe deve ser responsvel pelacontratao; Nodeixe pessoas de recursos humanossem experincia em TI iniciarem asconversas; Sabatinas, avaliaes de pensamentocrtico e modelagem so formas comuns; 14. Como manter bonsprofissionais? Ambiente de comunicao aberta, ondetodos sabem o que est acontecendo; Qualidade dos produtos e contato comclientes (satisfeitos!); Valorizaodas pessoas por seuscompanheiros e chefes; Eventosde comunidade, como refeies,festas e correlatos; 15. De volta a FDD - papis Project manager; Chief Architect; Development manager; Chief programmers; Class owners; Business experts; 16. Project manager Relatrios de progresso; Staffing; Evitar distraes externas ao projeto; Organizare garantir que o processo estindo pelo caminho certo; 17. Chief architect Responsvel pela montagem daarquitetura inicial do projeto; Deveter grandes capacidades tcnicase de facilitao, para expor o designpara os outros membros da equipe; Tema palavra final sobre as decises dedesign do projeto; 18. Development manager Responsvelpor liderar o trabalho diriode desenvolvimento com a equipe; Resolve os conflitos por recursos dentroda equipe e organiza o acesso aosmesmos para que no haja espera; 19. Chief programmers Participam nas definies de requisitos dealto nvel; Coordenam pequenas equipes dedesenvolvimento (de 3 a 6 pessoas) pelotrabalho de codificao e anlise final; Devemter qualidades tanto tcnicascomo tambm no trato de pessoas; 20. Class owners Desenvolvedores que trabalham empequenas equipes sobre a superviso de umChief Programmer; Normalmente so pessoas que desejamcontinuar na carreira tcnica (no queremgerenciar outros) ou ainda esto ganhandoexperincia; Responsveispelo design, cdigo, testes edocumentao das funcionalidades; 21. Domain experts Clientes,financiadores, analistas denegcios ou qualquer sequncia dospassos; Pessoasespecializadas no domnio ondea aplicao vai atuar, no precisam,necessariamente, ter conhecimentotcnico de software; 22. Coadjuvantes! Releasemanager; Language Guru; Build Engineer; Toolsmith; System administrator/DevOps; Testers; Deployers; Technical writers; 23. Domain object modeling Definir diagramas de classes definindo ostipos de objetos dentro de um domnio eos relacionamentos entre eles; Ofoco principal abrir a discusso entretodos pra que fique claro o que cadaobjeto deve fazer dentro do sistema; 24. Domain object modeling - 2 Ofoco definir quais as perguntas cadaum dos objetos pode responder dentrodo sistema, quais clculos e servios elespodem executar; Omodelo nunca final, precisa serrefinado o tempo todo conforme oprojeto segue em frente; 25. Domain object modeling - 3 Omodelo prov um framework onde possvel adicionar funes, a cadafuncionalidade definida; Ele ajuda a manter a integridadeconceitual do sistema e a visibilidade dascoisas que esto send produzidas; 26. Vamos modelar!As idias originais da aula anterior. Ou uma novaidia J 27. Developing by feature Cada funcionalidade precisa gerar valordireto para o cliente; Tarefas tcnicas devem estar includasdentro da feature, mas o importante entregar a feature no final; Primeirose divide a viso geral do projetoem subsistemas; 28. Developing by feature - 2 Depois cada subsystema/modulo deveser mais uma vez dividido em requisitosmenores; Quando os requisitos chegarem a umtamanho onde possvel saber comoeles vo ser implementados, esse otamanho ideal; 29. Developing by feature - 3 Cadafuncionalidade precisa ser feita emno mximo duas semanas, mas otamanho ideal de poucas horas oudias; Features devem ser quantificadas paraque haja progresso visvel o tempo todo,pra evitar que o desenvolvimento todopare; 30. Formato das features Calcularo total de uma venda Avaliar a performance de um vendedor Validar a senha de um usurio Autorizar uma transao de crdito nobanco; 31. Class/code ownership Em FDD desenvolvedores tornam-sedonos de classes do sistema e no dosistema como um todo; Objetiva manter a consistncia dosistema no seu nvel mais simples, o dasclasses; 32. Class/code ownership Oresponsvel pode sempre responder asdvidas dos outros sobre o que a classedeve fazer ou no; Ele pode implementar solues maisrpido do que outros membros daequipe; 33. Problemas? Uma nica pessoa responsvel podefazer com que ela torne-se um gargalono desenvolvimento; Se essa pessoa vai embora da empresa,o seu conhecimento tambm se vai comela; 34. Por que no ser do coletivo? As vezes, a propriedade coletiva do cdigofaz com que o cdigo no seja de ningum; Ningum se sente responsvel pelo cdigoescrito; Aqualidade geral do cdigo produzidodiminui e refactorings tornam-se inexistentes; 35. Mais sobre no ser coletivo Pessoaspodem adicionar novasfuncionalidades a classe sem ter umaidia real de como ela deve funcionarrealmente; Em equipes pequenas e com classespequenas o funcionamento tende a sermais simples; 36. Coletivo ou individual?Qual o melhor? 37. Feature teams Assim como classes vo pertencer apessoas, funcionalidades tambm; Apessoa responsvel pelafuncionalidade deve se organizar juntocom os responsveis pelas classes que elavai precisar que sejam alteradas paracoordenar o trabalho da feature; 38. Feature teams - 2 Os features devem ser distribudos entreos desenvolvedores para que cada umtenha um conjunto de itens a trabalhar; Aequipe deve se reorganizar ao redordas funcionalidades pra garantir quetodos os envolvidos esto trabalhandojuntos; 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 possvel; 40. Feature teams - 4 Devem ser pequenos, de 3 a 6 pessoas; Todosos envolvidos devem terparticipao como donos do cdigo quevai ser criado/modificado; Cadamembro contribui com anlise,design e implementao dafuncionalidade; 41. Feature teams - 5 Classowners podem pertencer a vriasequipes ao mesmo tempo, mas deve-seevitar fazer disso uma coisa comum (mais de3 equipes, por exemplo) pra no acabarcom problemas de troca de contexto; Todosos envolvidos, inclusive os ChiefProgrammers, devem estar participando daconstruo das funcionalidades; 42. Como as equipes trabalhamno seu dia a dia?E como elas se comunicam na hora de executartarefas relacionadas? 43. Inspees Devemfazer parte do dia a dia daequipe, com inspees de todo o cdigoproduzido; Transferemo conhecimento entre osdesenvolvedores, dos mais experientespros menos experientes; 44. Inspees - 2 Garantema aderncia aos padres de codificao, pois mais de uma pessoa vai ver o cdigo e validar que ele est seguindo o padro; Quandoreunidas com dados reais do mundo, podem demonstrar as partes do sistema que mais do problema; 45. Inspees - 3 Cuidadopra no fazer com que asinspees faam as pessoas sentirem-sehumilhadas ou diminudas; Inspeesdevem ser vistas como umaforma de fazer com que todos aprendamde alguma forma o que est sendo feito; 46. Inspees - 4 EmFDD, uma Feature Team responsabilizada pelas coisasencontradas durante uma inspeo, no uma coisa que depende de uma nicapessoa; Ochief programmer deve organizar asinspeces do cdigo que est sendoproduzido; 47. Como so as inspeesno seu dia a dia?Se elas no so, ser que elas podem lhe ajudar? 48. Regular Build Schedule A intervalos regulares, o sistema deve serposto para QA e depois pada produo; Os builds devem ser produzidos em umafrequncia que faa sentido para oproduto, empresa e mercado, pode sercontnuo, dirio ou semanal; 49. Regular build schedule - 2 Emum ambiente ideal o cliente semprevai poder ver (e, preferencialmente, usar)as novas funcionalidades conforme elasso entregues; Obuild o ponto final de avaliao deprogresso, nele que se v que as coisasesto realmente caminhando; 50. Regular build schedule - 3 possvel usar ferramentas automatizadas para auditoria e mtricas no cdifo fonte; Organizaros release notes/ funcionalidades completadas at