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. 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. 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”;
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. 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;
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. 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;
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. 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…);
13. 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;
14. 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;
15. De volta a FDD - papéis
› Project manager;
› Chief Architect;
› Development manager;
› Chief programmers;
› Class owners;
› Business experts;
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. 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. 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. 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. 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. 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;
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. 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. 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;
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. 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. 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. 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. 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. 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. 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. 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. 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;
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. 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. 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. 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. 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. Como as equipes trabalham
no seu dia a dia?
E como elas se comunicam na hora de executar
tarefas relacionadas?
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. 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. 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. 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. Como são as inspeções
no seu dia a dia?
Se elas não são, será que elas podem lhe ajudar?
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. 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. 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. Como é o seu build
schedule atual?
É bom? Pode melhorar?
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;
54. 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!
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. 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. 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. 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);
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. 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. 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. 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;
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. 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. 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;
