Feature Driven Development

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;

›  Removebarreiras 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;

›  Eventosde 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;

›  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;

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;

›  Omodelo 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
›  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;

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
›  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;

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
›  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;

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;

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
›  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;

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;

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
›  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;

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
›  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;

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;

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;

›  Depoisda 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
›  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;

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;

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;

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;

Feature Driven Development

Mais conteúdo relacionado

Mais procurados (20)

Destaque (8)

Semelhante a Feature Driven Development (20)

Mais de Maurício Linhares (20)

Último (19)

Feature Driven Development