Código = Documentação?
Na pequena série sobre o "Agile BA" eu prometi um post para falar especificamente sobre Documentação - o 2º maior pesadelo dos programadores.
Nick Malik, do Inside Architecture, chegou antes, e no último dia 11/jul publicou 4 razões para não acreditarmos que código é documentação suficiente para processos de negócio.
O excelente artigo do Nick não me isentará de voltar ao assunto. Acontece que eu quero ir um pouco além, tentando entender ou explicar o trauma que é a tal "documentação". Enquanto trato de outras prioridades, fica a provocação:
"Software is the leaky abstraction. It makes poor documentation for a business process."
Nick Malik, do Inside Architecture, chegou antes, e no último dia 11/jul publicou 4 razões para não acreditarmos que código é documentação suficiente para processos de negócio.
O excelente artigo do Nick não me isentará de voltar ao assunto. Acontece que eu quero ir um pouco além, tentando entender ou explicar o trauma que é a tal "documentação". Enquanto trato de outras prioridades, fica a provocação:
"Software is the leaky abstraction. It makes poor documentation for a business process."
.:.
Marcadores: analista_de_negócios, cursos_e_palestras, modelagem_de_negócios
segunda-feira, 16 de julho de 2007 |
Assine o finito
Lista completa no del.icio.us
Eu ia té assinar o feed do cara mas essa afirmação:
"@Brian
"Show me a business process not documented in the code and I'll show you an out of date, innacurate process documentation."
And I will show you an organization at Level 1 of process maturity."
É simplesmente ridícula. É só passear por empresas e cases de empresas com maturidade de processo (i.e. CMMi) e ver que é mentira. Acabo de concluir o phase-out de um sistema comprado de uma empresa com CMMi 5 e os Casos de Uso pararam de ser atualizados quando a empresa se deu conta que não conseguiria mantêr seu processo burocrático com tnatas mudanças de escopo. Um desastre completo, pelo menos para mim como cliente.
De qualquer modo bloguei sobre o tema:
[]s
Ops, faltou o link:
http://blog.fragmental.com.br/2007/07/27/model-driven-development-e-durepoxi/
Estranho isso, mas vou reproduzir aqui o comentário que deixei no blog do Phillip "Shoes" Calçado:
Caro Philip “Shoes”,
O ponto forte do artigo citado são as 4 razões pelas quais código não é uma boa documentação para processos de negócio. Esqueça (ou perdoe) bullshitagens sobre níveis de maturidade e afins. Simplesmente, não é o caso.
E casos de uso, como documentação, são tão ‘fracos’ quanto código. Tanto que são totalmente ignorados pela EPBE (Eriksson-Penker Business Extensions), extensão da UML que indico para a modelagem de negócios.
Como você, quero crer que DDD e DSL’s caminham para reduzir muito (ou eliminar totalmente) o gap que temos entre negócio e código. Tá na fila: vou mergulhar no tema. Espero em breve ter condições de transcrever seus exemplos a partir do outro ponto de vista.
[]’s
Paulo