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?