O quanto é apenas o suficiente?

Apresentação do paper "How Much is Just Enough? Some Documentation Patterns on Agile Projects", por R. Hoda, J. Noble e S. Marshall.

O artigo define e descreve alguns padrõe de documentação para times de desenvolvimento que adotam as metodologias ágeis em seus projetos.

Transcript

1. O quanto é “apenas o suficiente?” Bernardo Gurgel Filho
2. Introdução O quanto é “apenas o suficiente”?
3. Documentação na Cultura Ágil “O manifesto ágil define quatro valores, no qual um deles claramente favorece desenvolver software ao invés de ‘compreensíveis documentações’.”
4. “Documentation is the castor oil of programming. Managers think its good for programmers. Programmers hate it!” – Jerry Weinberg “Psychology of Computer Programming” Documentação na Cultura Ágil
5. Documentação na Cultura Ágil “Métodos ágeis recomendam uma leve documentação ou documentar ‘apenas o suficiente’. Mas o que é ‘apenas o suficiente’ e quem o define?”
6. O que é documentação suficiente? • Código auto documentado? ◦ Código claro e bem escrito; ◦ Comentários; • Testes de unidade e de aceitação? • Documentar apenas quando necessário, justificável?
7. O que é documentação suficiente? “Em outras palavras, a definição de ‘apenas o suficiente’ é específico ao contexto.”
8. “Com a falta de uma clara definição e entendimento do que é ‘apenas o suficiente’, times ágeis, especialmente novos times ágeis, podem encontrar todos tipos de problemas.” A problemática
9. Padrões de documentação O quanto é “apenas o suficiente”?
10. Padrões de Documentação • Fake Documentation • Time Stamp • e-Backups • Project Dictionary
11. Cenário - FlexiCo • Um time de desenvolvimento composto por: ◦ 4 desenvolvedores ◦ 1 testador • Clientes externos e in-house • Metodologia tradicional de desenvolvimento
12. “Em uma conferência, um dos desenvolvedores é introduzido ao mundo ágil. Com interesse, ele procura saber mais sobre este universo. Maravilhado ele apresenta para o seu time…” Cenário - FlexiCo
13. Cenário - FlexiCo Alvin (que agora insiste em ser chamado de coach): “Ei galera, vamos ser ágeis! Aqui estão algumas coisas básicas...” [duas horas e 100 slides mais tarde...] Deepak, um dos desenvolvedores: “(phew...sem documentação) Parece legal, vamos tentar.”
14. Cenário - FlexiCo Dave, outro desenvolvedor: “Hmm, eu não sei… (com tanto que nós continuamos com as 40h por semana).” [Debbie and Derek, the other two developers, look around to see what the others think. ..]
15. Tao, o testador: “Eu gosto desse conceito de desenvolvimento orientado a testes (finalmente algum crédito para mim).” Niagara, líder de um outro time não-ágil: “Me pergunto do que se trata isso tudo…” Cenário - FlexiCo
16. Fake Documentation O quanto é “apenas o suficiente”?
17. Fake Documentation Contexto: Time de desenvolvimento ágil em uma organização não-ágil. Problema: Como coordenar a produção de documentos entre projetos ágeis e não- ágeis.
18. Forças – Times Ágeis • Querem produzir "apenas o suficiente" de documentação; • Fazem decisões iterativa e incrementalmente; • Precisam criar uma interface e integrar com times não-ágeis;
19. Forças - Times não-ágeis • Fazem decisões de acordo com um pré-existente e estruturado plano; • Dependem de documentação; • Interpretam a falta de documentação dos times ágeis como uma fraqueza;
20. Solução Organizar (e agendar) a produção de uma quantidade mínima de documentação tradicional para se coordenar com times não-ágeis.
21. Consequências Positivas • Times ágeis fornecem documentação necessária para contextos não-ágeis; • Manter documentação em comum melhora a comunicação e entendimento com times não-ágeis;
22. Consequências Negativas • Manter documentação impõe uma preocupação que um time puramente ágil gostaria de evitar; • Times ágeis precisam resistir a tentação de priorizar documentação ao invés de implementação;
23. Práticas Relacionadas • “Requisitos Implícitos” • Time Stamp • Dicionário de Projeto
24. Time Stamp O quanto é “apenas o suficiente”?
25. Time Stamp CONTEXTO Time ágil co-alocado PROBLEMA Como deixar claro quem iniciou um pedido de mudança?
26. Forças • Projeto ágeis são mais sujeitos a mudanças que projetos não-ágeis; • Clientes podem pedir mudanças no software a qualquer hora; • Times ágeis são obrigados a aceitar as mudanças;
27. Forças • Projetos ágeis usam bastante artefatos em papéis que podem ser alterados com facilidade; • Requisitos são passados pelos clientes como histórias de usuário; • Mudanças nos requisitos são difíceis de rastrear;
28. Forças • Desacordos em relação aos pedidos de mudanças não são esperados; • Stakeholders podem querer acompanhar e revisar as mudanças enquanto os desenvolvedores podem querer gastar pouco tempo e esforço.
29. Solução Documentar as decisões de mudanças em uma wiki o mais cedo possível.
30. Consequências Positivas • O time pode acompanhar a evolução do projeto com relação ao tempo • A wiki pode ser introduzida ao cliente como uma prática benéfica para ele e o time
31. Consequências Positivas • A wiki tem um certo “feeling” de método ágil • As "mudanças recentes" na wiki permitem stakeholders acompanhar as mudanças sem precisar que os desenvolvedores gastem muito esforço
32. Consequências Negativas • Se feito de modo muito "oficial", a wiki pode soar "não-ágil" • Manter documentação comum pode levar a uma preocupação não-desejável
33. Consequências Negativas • Os Stakeholders devem aceitar a abordagem de usar wikis para documentar as mudanças de requisitos
34. Práticas Relacionadas • Fake Documentation • e-Backup
35. e-Backup O quanto é “apenas o suficiente”?
36. e-Backup CONTEXTO Um time ágil dependendo de arterfatos em papéis e tendo um "mural de histórias" em seu escritório. PROBLEMA Como evitar perder todos os cartões de histórias e tarefas em post-its?
37. Forças • Métodos ágeis dependem muito de artefatos físicos como meios de comunicação e elaboração do projeto • Cartões de história físicos e post-its podem ser fácilmente perdidos, danificados, entre outras coisas
38. Solução Criar um backup eletrônico dos artefatos de papéis.
39. Consequências Positivas • Documentar os artefatos de papéis em e-backups podem evitar retrabalhos • Backups eletrônicos como fotocópia digital de diversos hitórias e tarefas de uma vez economizam esforço e tempo
40. Consequências Negativas • Backups de cada artefato individual é uma tarefa tediosa e consome muito tempo • Ao menos que alguém fique responsável pelos backups, a atividade pode ser postergada facilmente
41. Práticas Relacionadas • O “Super Secretário” • “A Distinct Activity” • Time Stamp
42. Dicionário de Projeto O quanto é “apenas o suficiente”?
43. Dicionário de Projeto CONTEXTO Um time ágil co-alocado PROBLEMA Como traduzir requisitos de negócio em tarefas técnicas?
44. Forças • Times ágeis devem interagir e colaborar com os clientes afim de elicitar requisitos • Times de desenvolvimento usam termos técnicos • Clientes usam termos de negócio
45. Forças • Em metodologias ágeis, o cliente fornece os requisitos em forma de histórias de usuário, no qual os desenvolvedores devem extrair
46. Forças • Traduções falhas dos requisitos funcionais podem resultar em software desalinhado com o esperado pelo cliente. • Representates do cliente podem ter termos diferentes para um mesmo
47. Forças • O cliente geralmente tem um tempo limitado para disponibilizar para o time de desenvolvimento.
48. Solução Engajar seus clientes na documentação de termos de negócio, seus significados e contextos de uso em um dicionário de projeto.
49. Consequências Positivas • O cliente não tem que traduzir seus termos para tarefas técnicas • O cliente não precisa repetir os mesmos termos para cada membro do time
50. Consequências Positivas • Tempo gasto em conversas com o cliente pode ser melhor aproveitado para discutir sobre o projeto • Mais confiança ao quebrar histórias de usuário em tarefas técnicas
51. Consequências Positivas • Bom para que novos membros no time aprendam o vocabulário em torno do projeto
52. Consequências Negativas • Criar e manter um dicionário requer colaboração e tempo do cliente
53. Referências O quanto é “apenas o suficiente”?
54. Referências How Much is Just Enough? Some Documentation Patterns on Agile Projects – R. Hoda, J. Noble, S. Marshall