Feature driven development Maurício Linhares
O Que é um bom processo? Discutam.
É 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;
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;
Produz dados reais sobre progresso 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”;
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;
Mantém qualidade controlando 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;
Otimiza a comunicação � Dentro e fora da equipe;
� Remove barreiras organizacionais que complicam a comunicação;
� Acaba com os silos de informação;
Quais os componentes de um projeto 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;
Mas antes disso… Processos e pessoas outra vez
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;
Como atrair bons profissionais? � Tenha bons profissionais dentro da
equipe;
� Forneça complementos que não sejam diretamente financeiros (plano de saúde, café, livros, ambientes abertos…);
Como encontrar bons profissionais? � 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;
Como manter bons profissionais? � 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;
� Eventos de comunidade, como refeições, festas e correlatos;
De volta a FDD - papéis � Project manager;
� Chief Architect;
� Development manager;
� Chief programmers;
� Class owners;
� Business experts;
Project manager � Relatórios de progresso;
� Staffing;
� Evitar distrações externas ao projeto;
� Organizar e garantir que o processo está indo pelo caminho certo;
Chief architect � Responsável pela montagem da
arquitetura inicial do projeto;
� Deve ter 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;
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;
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;
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;
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;
Coadjuvantes! � Release manager; � Language Guru; � Build Engineer; � Toolsmith; � System administrator/DevOps; � Testers; � Deployers; � Technical writers;
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;
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;
� O modelo nunca é final, precisa ser refinado o tempo todo conforme o projeto segue em frente;
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;
Vamos modelar! As idéias originais da aula anterior. Ou uma nova idéia J
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;
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;
Developing by feature - 3 � Cada funcionalidade 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;
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;
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;
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;
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;
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;
Mais sobre não ser coletivo � Pessoas podem 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;
Coletivo ou individual? Qual o melhor?
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;
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;
Feature teams - 3 � Ao fim 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;
Feature teams - 4 � Devem ser pequenos, de 3 a 6 pessoas;
� Todos os envolvidos devem ter participação como donos do código que vai ser criado/modificado;
� Cada membro contribui com análise, design e implementação da funcionalidade;
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;
Como as equipes trabalham no seu dia a dia? E como elas se comunicam na hora de executar tarefas relacionadas?
Inspeções � Devem fazer 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;
Inspeções - 2 � Garantem a 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;
� Quando reunidas com dados reais do mundo, podem demonstrar as partes do sistema que mais dão problema;
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;
Inspeções - 4 � Em FDD, uma Feature Team é
responsabilizada pelas coisas encontradas durante uma inspeção, não é uma coisa que depende de uma única pessoa;
� O chief programmer deve organizar as inspecões do código que está sendo produzido;
Como são as inspeções no seu dia a dia? Se elas não são, será que elas podem lhe ajudar?
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;
Regular build schedule - 2 � Em um 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;
Regular build schedule - 3 � É possível usar ferramentas automatizadas
para auditoria e métricas no códifo fonte;
� Organizar os release notes/funcionalidades completadas até o período atual;
Como é o seu build schedule atual? É bom? Pode melhorar?
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;
Quais ferramentas você usa pra CM?
FDD rapidinho 1. 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!
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;
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;
� Depois da criação, todos os times se reúnem mais uma vez para demonstrar as idéias encontradas;
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;
Repasar feature sets para os chief 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);
Desenvolvendo � Com os 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;
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;
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;
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;
Exemplo de gráfico
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);
� Quantidade de serviço por fazer e a probabilidade de ser feito no prazo;
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);
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;
Dúvidas?