Agilidade e documentações

[carneiro]

Oi pessoal,

Como que as metodologias ágeis encaram a questão da documentação do software? Vejo vários times de desenvolvimento que, embora afirmem seguir práticas ágeis, requerem uma série de documentações, tais como:

• Casos de uso
• Diagrama de classes
• Diagrama de atividades
• Diagrama de seqüência
• Etc

A princípio toda essa documentação me pareceu excessiva. Na minha opinião, os documentos de casos de uso estariam já de bom tamanho, afinal creio que as regras de negócio e funcionalidades devem estar registradas em algum lugar (além do código), de modo formal, porque ficar “só na conversa” com o usuário pode ser problemático (alguns usuários mudam de idéia toda hora, diz que não disse, etc).

Quanto à diagramas de classes, atividades, seqüência, creio que é muito melhor as empresas investirem um tempo treinando os seus desenvolvedores em boas práticas, arquitetura, etc, de modo que os desenvolvedores consigam produzir código de qualidade mesmo sem auxílio de diagramas feitos por outros profissionais mais experientes.

O que vocês pensam disso tudo?

[Ferryman]

Eai cara,

Na minha opinião, diagrama de classes, sequência, estado e atividade são ferramentas para auxiliar no desenvolvimento. Acho se vc tem como regra que precisa ser produzido diagrama de classes e sequência para cada caso de uso, isso pode causar um overhead desnecessário.
Particularmente, eu gosto bastante de modelar o dominio com diagrama de classes para ter uma visão geral e perceber os pontos onde posso ter problemas ou melhorar o design. Mas isso é uma ferramenta que posso utilizar, e não uma regra que cumprei pra cada caso de uso.

Documentação boa, é a que vc produz agora e ela te poupa tempo no futuro. Se ela só consumir tempo, então não sei se vale a pena.

Essa é minha opinião.
abraços

Ferry

[mueller]

O fato de utilizar práticas ágeis, não significa que essas empresas pratiquem desenvolvimento Ágil.

No desenvolvimento Ágil, os princípios são mais importantes que as práticas.

Sobre documentação eu acho legais os links:
http://www.dtsato.com/blog/default/Agile/XP/?permalink=XP-2007-Dia-4.html&smm=y
http://www.phidelis.com.br/blogs/alissonvale/2007/09/20/DocumentosExecutaacuteveis.aspx

[carneiro]

O fato de utilizar práticas ágeis, não significa que essas empresas pratiquem desenvolvimento Ágil.

Não entendi exatamente o que você quis dizer…

[Mauricio_Linhares]

[quote=carneiro][quote]
O fato de utilizar práticas ágeis, não significa que essas empresas pratiquem desenvolvimento Ágil.
[/quote]

Não entendi exatamente o que você quis dizer… :)[/quote]

A minha empresa pode praticar TDD mas usar o RUP como processo.

[Adolfo_Rodrigues]

[quote=carneiro]Oi pessoal,
Como que as metodologias ágeis encaram a questão da documentação do software? Vejo vários times de desenvolvimento que, embora afirmem seguir práticas ágeis, requerem uma série de documentações, tais como:

• Casos de uso
• Diagrama de classes
• Diagrama de atividades
• Diagrama de seqüência
• Etc

A princípio toda essa documentação me pareceu excessiva. Na minha opinião, os documentos de casos de uso estariam já de bom tamanho, afinal creio que as regras de negócio e funcionalidades devem estar registradas em algum lugar (além do código), de modo formal,
[/quote]

Acredito que maior do que o problema de gerar uma documentação excessiva é não fazer isso iterativamente e incrementalmente, como pregam as principais metodologias. Não vejo problema em gerar muitos documentos, desde que não custem muito para serem mantidos, sejam gerados iterativamente e incrementalmente, gerem valor para a equipe e para o cliente e mapeiem o domínio de forma clara e simples. Como todas estas condições são difíceis de serem atingidas, sou a favor de gerar diagramas para entendimento e abstração de problemas e para se comunicar melhor com o cliente, fazendo isto de forma iterativa e incremental. E, logicamente, entender que testes unitários e código funcionando são sim documentação.

porque ficar “só na conversa” com o usuário pode ser problemático (alguns usuários mudam de idéia toda hora, diz que não disse, etc).

Um dos princípios das metodologias ágeis é “aceitar mudanças”. Além disso, acredito que quando um cliente (preparado, que entenda o objetivo do sistema que ele requisitou) vê a principal funcionalidade do seu sistema operando em poucas semanas saberá das mudanças estruturais (as maiores, que têm impacto efetivo no planejamento) necessárias. E ele também estará envolvido com a equipe, ele faz parte dela; qualquer mudança que queira negociar vai ter que ser priorizada em detrimento de outra. Neste contexto, não acredito que um cliente queira fazer mudanças desnecessárias e estúpidas. O bom andamento do projeto é interessante para a equipe de desenvolvimente mas sobretudo para o cliente. Se ambos trabalharem como uma única equipe, não vejo grandes problemas em identificar, priorizar e implementar mudanças. Daí a importância do pilar “valorizar pessoas ao invés de processos”. É importante que a equipe e também cliente sejam bons.

Quanto à diagramas de classes, atividades, seqüência, creio que é muito melhor as empresas investirem um tempo treinando os seus desenvolvedores em boas práticas, arquitetura, etc, de modo que os desenvolvedores consigam produzir código de qualidade mesmo sem auxílio de diagramas feitos por outros profissionais mais experientes.
O que vocês pensam disso tudo?

Concordo. Sem investimento em pessoas, infra-estrutura e tecnologia é impossível ser ágil. Sofro isso na pele…

[mueller]

[quote=carneiro][quote]
O fato de utilizar práticas ágeis, não significa que essas empresas pratiquem desenvolvimento Ágil.
[/quote]

Não entendi exatamente o que você quis dizer… :)[/quote]

Empresas como a GM imitaram as práticas da Toyota mas não conseguiram obter um bom resultado como a Toyota obtem. Simplesmente pq elas seguiram as práticas e não os princípios. O importante é entender e seguir os princípios do desenvolvimento Ágil, as práticas são consequências.

Uma empresa que utiliza somente as práticas e esquece o pq elas existem, não pratica desenvolvimento Ágil (embora essas empresas adoram dizer que praticam), da mesma forma que posso praticar desenvolvimento Ágil sem utilizar TDD e pair programming, por exemplo.

[thiagomont]

Algumas questões a serem consideradas:

Como podemos manter um código rapidamente se não conhecemos?

Como podemos discutir com o cliente a melhor forma de implementar uma regra de negócio se não temos documentado como é realizado hoje no sistema?

Como podemos mudar o custo / prazo de um projeto se não temos a documentação para comprovar que ocorreu uma alteração de requisitos?

A documentação é trabalhosa sim, mas necessária. Claro que temos que ter uma documentação o mais fácil possível de ser mantida, mas cedo ou tarda ela se fará necessária. Outra consideração é que com um processo de desenvolvimento tudo acaba saindo mais organizado, fica mais fácil de controlar a produtividade e também evitar os famosos esquecimentos e alterações absurdas de escopos no meio do projeto sem alterações no preço.

Sei que definir um processo ideal é difícil, mas mesmo assim é melhor ter um processo e ir aperfeiçoando este processo aos poucos.

[cv1]

Como podemos manter um código rapidamente se não conhecemos?

TDD, Pair Programming, Collective Code Ownership

Como podemos discutir com o cliente a melhor forma de implementar uma regra de negócio se não temos documentado como é realizado hoje no sistema?

Claro que temos. Ta na suite de testes. De uma lida sobre BDD, JBehave e RSpec.

Como podemos mudar o custo / prazo de um projeto se não temos a documentação para comprovar que ocorreu uma alteração de requisitos?

Faca contratos de risco-e-beneficio ao inves de tempo-e-materiais ou escopo fechado.

Outra consideração é que com um processo de desenvolvimento tudo acaba saindo mais organizado, fica mais fácil de controlar a produtividade e também evitar os famosos esquecimentos e alterações absurdas de escopos no meio do projeto sem alterações no preço.

O proprio ato de desenvolver o software altera seus requisitos (ja tentou usar um termometro comum numa gota d’agua? Mesma coisa). Entao, pq tentar bolar um jeito de fazer com que os requisitos nao se alterem, ao inves de simplesmente estar bem preparado pra essas alteracoes quando elas vierem?

[peczenyj]

Puxa!

Esse post do cv me lembrou as minhas aulas de mecânica quantica onde o fato de vc observar um dado fenômeno altera o mesmo. Porém nunca tinha pensando em termos de software.

Outra coisa que estava muito em voga nessas aulas era a dificuldade de algumas gerações de cientistas acostumados com o Aristotelismo de prever exatamente o que a natureza faz ou fará, com as evidências de que algumas coisas são probabilisticas e até insoluveis em tempo finito.

Em outras palavras, quem acredita que os requisitos de um sistema são imutaveis ao longo do tempo e que haverá uma forma de converter tudo em um sistema perfeito é algo que se fazia nas ciências até o fim do século 19, ao passo que sistemas propositalmente abertos e evolutivos atendem melhor as necessidades dos nossos clientes por algum periodo de tempo.

[thiagomont]

Blz?

Em relação a resposta do CV

O proprio ato de desenvolver o software altera seus requisitos (ja tentou usar um termometro comum numa gota d’agua? Mesma coisa). Entao, pq tentar bolar um jeito de fazer com que os requisitos nao se alterem, ao inves de simplesmente estar bem preparado pra essas alteracoes quando elas vierem?

Acredito que não tenha me explicado direito. O problema não é alterar os requisitos, mas sim controlar as alterações e cobrar o custo dessas alterações para o cliente. Apenas identificando quais requisitos foram alterados após o fechamento de um escopo inicial podemos identificar essa mudança e, aplicando a APF identificar o novo custo e prazo do projeto.

Em relação ao Pair Programming concordo com vc, porém nem todas as empresas entendem a facilidade de uso dessa técnica.

E em relação a usar a suite de testes, serve apenas para implementações já realizadas. O ideal é primeiro definirmos os requisitos do projeto para depois implementar, ok? Além disso o cliente não conseguiria entender o que foi mudado através de rotinas de teste e é de fundamental importância deixar claro para o cliente quais as alterações das funcionalidades serão necessárias.

A questão não é deixar de alterar o requisito, mas sim controlar quais alterações estão sendo realizadas e documentar de forma mais adequada para o entendimento de analistas de negócio e cliente.

[cmilfont]

" Acredito que não tenha me explicado direito. O problema não é alterar os requisitos, mas sim controlar as alterações e cobrar o custo dessas alterações para o cliente. Apenas identificando quais requisitos foram alterados após o fechamento de um escopo inicial podemos identificar essa mudança e, aplicando a APF identificar o novo custo e prazo do projeto. "

Alterar um requisito não necessariamente está alterando o escopo, voce pode ter que alterar todo o requisito e o escopo permanece o mesmo.
APF? O.o

" E em relação a usar a suite de testes, serve apenas para implementações já realizadas. O ideal é primeiro definirmos os requisitos do projeto para depois implementar, ok? Além disso o cliente não conseguiria entender o que foi mudado através de rotinas de teste e é de fundamental importância deixar claro para o cliente quais as alterações das funcionalidades serão necessárias."

O CV mandou você ler sobre:"De uma lida sobre BDD, JBehave e RSpec. "
É evidente que não conhece muito bem como funciona TDD também

[cv1]

O problema não é alterar os requisitos, mas sim controlar as alterações e cobrar o custo dessas alterações para o cliente. Apenas identificando quais requisitos foram alterados após o fechamento de um escopo inicial podemos identificar essa mudança e, aplicando a APF identificar o novo custo e prazo do projeto.

E quem disse que vc precisa fechar um escopo inicial? Custo, prazo e escopo sao as 3 variaveis onde vc pode brincar, fixando ate duas delas de cada vez. O que eu estou dizendo eh que fixar escopo nunca funciona, pq nao eh o que nenhum cliente que eu vi ate hoje quer.

O ideal é primeiro definirmos os requisitos do projeto para depois implementar, ok?

Quem disse que eh o ideal? Voce? Prove.

[thiagomont]

Em relação ao comentário do cmilfont, ninguém me manda fazer nada, ok?.. ele pode ter sugerido…

Em relação ao comentário do CV…acho que vai ser uma longa discussão…rs…enfim…vamos lá…

Para que se esti e um custo de acordo com o projeto cé necessário sim que se levante um escopo inicial, o cliente não quer jogar dinheiro pela janela…ele quer saber exatamente o que está comprando. Existem cliente que também não pode pagar muito, e dessa forma, através de priorização de requisitos documentados podemos estabelacer um melhor desenvolvimento do sistema.

Por isso ainda defendo a idéia de que é melhor primeiro definirmos requisitos antes de implementar. A não ser que seu cliente não seja muito exigente. Mas aqui precisamos comprovar o custo de cada alteração mínima que vamos realizar.

OBS: é perigoso brincar com o custo do projeto…o cliente pode não gostar…rs…

[cmilfont]

"Em relação ao comentário do cmilfont, ninguém me manda fazer nada, ok?.. ele pode ter sugerido…"
Na verdade vale mesmo como obrigação, então ele mandou sim

“Para que se esti e um custo de acordo com o projeto cé necessário sim que se levante um escopo inicial, o cliente não quer jogar dinheiro pela janela…ele quer saber exatamente o que está comprando. Existem cliente que também não pode pagar muito, e dessa forma, através de priorização de requisitos documentados podemos estabelacer um melhor desenvolvimento do sistema.”

Ninguém falou aqui em não levantar o escopo da aplicação, agora escopo não tem nada a ver necessariamento com os requisitos, são duas coisas diferentes, mudança de escopo é difícil mas de requisitos é o que mais se ver.
Você pode mudar o escopo da aplicação, ex. sistema contábil para um sistema de RH? difícil, todos os clientes que trabalhei até hoje sabem perfeitamente o que querem, só que na maioria gritante das vezes não tem idéia precisa de como serão os requisitos e ninguém nunca sabe.
O último sistema que trabalhei (Diário Oficial do Estado do Ceará) desde a “concepção aos testes” (sic) tive que reescrever a aplicação 3 vezes totalmente… o escopo permaneceu o mesmo, já os resquisitos…
Eu não estava preparado para as mudanças, documentos são as coisas mais lindas, tinha tudo, de diagramas de classes a de sequencia… tinha até teste unitário… que fiz depois que codifiquei O.o

“Por isso ainda defendo a idéia de que é melhor primeiro definirmos requisitos antes de implementar. A não ser que seu cliente não seja muito exigente. Mas aqui precisamos comprovar o custo de cada alteração mínima que vamos realizar.”

A definição de todos os requisitos nem o RUP cobra… mas, você defende que só deva implementar depois que já passou tudo para o Editor de textos?

"OBS: é perigoso brincar com o custo do projeto…o cliente pode não gostar…rs…"
Eu que o diga, já brinquei muito com o dinheiro alheio, fazendo projetos waterfall lindos, e a “indústria de software” local também! Agora que estou me profissionalizando, tento economizar o dinheiro já ralo que relutantes clientes sofrem para gastar!

ps. Tenho um sistema aqui completo, feito por uma consultoria local, belíssimo! Todo tipo de documentação, tudo mapeado, de case uses aos modelos do PMBOK, dá gosto de navegar no sistema… pelo Office, porque no sistema mesmo não passa do login.

[mueller]

ps. Tenho um sistema aqui completo, feito por uma consultoria local, belíssimo! Todo tipo de documentação, tudo mapeado, de case uses aos modelos do PMBOK, dá gosto de navegar no sistema… pelo Office, porque no sistema mesmo não passa do login.

Isso é lindo! hahahaha

Tenho algo parecido, acabaram de contratar a empresa onde trabalho para iniciar um projeto, o cliente já chegou com mais de 15 documentos, cada um com suas 20~100 páginas… O detalhe é que esse projeto, com toda documentação maravilhosa, toda mínima alteração de escopo, prazo e testes pré-definidos, tudo planejado… acabou de ir pro buraco em outra empresa depois de 6 meses de desenvolvimento

Lendo a documentação (sick!), o projeto é um enorme waterfall :S

Esse pessoal não aprende…

[peczenyj]

Documentação homologada pelo cliente:

• Quando X for maior que Tanto e Y estiver entre A e B, então o campo Z sera 1, do contrario sera 0

Plano de teste pronto, o cliente reclama

• Quando H for maior que OutroTanto e Y estiver entre C e D, então o campo Z sera 1, do contrario sera 0

Olhando o codigo fonte COBOL do sistema LEGADO que estavamos convertendo pra Oracle +j2ee

• Quando X for maior que Tanto e Y estiver entre A e B, então o campo QQ_COISA_MENOS_Z sera 4, do contrario sera 10

Nem sempre os clientes sabem tudo

[thiagomont]

Não vale como obrigação. Acredito que essa discussão será inútil, já que você acha que o que falam aqui (com todo o respeito às pessoas, inclusive o CV, que sugerem as soluções) sere como auxílio não como obrigação, quem vai desenvolver que tem que assumir a responsabilidade, ok?

E novamente, se mudar os requisitos, de forma que dobre o esforço, custo e prazo da aplicação, como vc vai provar para o cliente que isso é uma verdade? como irá discutir regras de negócio com o cliente se não tem uma forma de comunicação e documentação do que vai ocorrer no sistema?

Onde trabalho documentamos os sistemas e a documentação ajuda muito no sentido de evitar entendimentos errados e implementarmos errado. Isso é essencial.

Também trabalho com sistemas grandes, e pelo sistema ser grande que devemos atentar para a documentação de requisitos. Acredite, é mais importante do que você imagina.

O RUP indica que é necessário sim a documentação de requisitos, inclusve no CMMI é indicado como prática específica a aprovação dos requisitos pelo cliente.

OBS: o processo de desenvolvimento organizado é importante, não podemos deixar conhecimento na cabeça das pessoas, o desenvolvimento de sistema deve ter realizado de forma a deixar todo o conhecimento do sistema documentado…ainda mais os requisitos.

Agora se não conseguiu realizar a implementação a partir de uma documentação organizada, acho que o problema não é na documentação, certo?

Não responderei mais mensagens relacionadas a este tópico visto que não está sendo de ajuda.

[peczenyj]

O RUP indica que é necessário sim a documentação de requisitos, inclusve no CMMI é indicado como prática específica a aprovação dos requisitos pelo cliente.

Ok. Agora se vc chama essa documentação de diversos arquivos do word num template X e faz o uso deles da forma mais burocrática possível, vc pode ter implementado o RUP ou CMMI de uma forma que vc vai perder agilidade e, consequentemente, dinheiro.

E novamente, se mudar os requisitos, de forma que dobre o esforço, custo e prazo da aplicação, como vc vai provar para o cliente que isso é uma verdade? como irá discutir regras de negócio com o cliente se não tem uma forma de comunicação e documentação do que vai ocorrer no sistema?

Não existe dialogo?

[cmilfont]

Não vale como obrigação. Acredito que essa discussão será inútil, já que você acha que o que falam aqui (com todo o respeito às pessoas, inclusive o CV, que sugerem as soluções) sere como auxílio não como obrigação, quem vai desenvolver que tem que assumir a responsabilidade, ok?

Se o que te mandam é pesquisar pelas melhores formas de se fazer algo, isso é obrigação sim!
É a mesma coisa de um médico abrir o peito de um homem baseado em seus achismos. Você confiaria em um médico lhe operar sem este ter o conhecimento das últimas novidades sobre o tipo de operação? mas isso foge ao “escopo” dessa discussão, vamos ao que interessa…

E novamente, se mudar os requisitos, de forma que dobre o esforço, custo e prazo da aplicação, como vc vai provar para o cliente que isso é uma verdade? como irá discutir regras de negócio com o cliente se não tem uma forma de comunicação e documentação do que vai ocorrer no sistema?

Que tipo de documentação você discute com seu clientes? casos de usos? modelos de requisitos? quem disse que o cliente está entendendo o que voce está mostrando? para mim a única forma de explicar ao cliente é mostrando o sistema funcionando, no mínimo um protótipo!
Ele pode até abastrair que no requisito RQ151-PQP7 voce garante que o fluxo principal terminará com o status X… mas pode ter certeza que na cabeça dele tem uma arvorezinha e uma corda com seu pescoço dentro…

Onde trabalho documentamos os sistemas e a documentação ajuda muito no sentido de evitar entendimentos errados e implementarmos errado. Isso é essencial.

Adotamos uma tática diferente aqui, desenhamos a UI para ele com alguma coisa (vale pincel e quadro), discutimos o que tem que ser feito, batemos uma foto (ou várias se for um fluxo) e pronto. Todo mundo fica feliz, ainda sou tão sacana com eles que mando a foto renomeada de AtaReuniao.jpg

Também trabalho com sistemas grandes, e pelo sistema ser grande que devemos atentar para a documentação de requisitos. Acredite, é mais importante do que você imagina.

Não acredito não, projetos geralmente (até para governos) tem prazos e recursos escassos. Sabe quando você terminará de documentar todo o sistema? quando acabarem os prazos e os recursos e olhe que todo governo destina uns 50% a mais porque já sabe o sofrimento que é.

O RUP indica que é necessário sim a documentação de requisitos, inclusve no CMMI é indicado como prática específica a aprovação dos requisitos pelo cliente.

Não falei que o RUP não indicava, só alertei para voce observar que o RUP adota modelo iterativo, inclusive a técnica de implementar os casos de usos principais já era implementada antes do manifesto ágil ser assinado. Esperar fazer toda a documentação como voce sugeriu nem o RUP indica.

OBS: o processo de desenvolvimento organizado é importante, não podemos deixar conhecimento na cabeça das pessoas, o desenvolvimento de sistema deve ter realizado de forma a deixar todo o conhecimento do sistema documentado…ainda mais os requisitos.

Só a "move people around"do XP já nivela todo mundo e evita o conhecimento contido, só com isso eu já resolveria esse problema, mas juntemos com outras práticas?

Agora se não conseguiu realizar a implementação a partir de uma documentação organizada, acho que o problema não é na documentação, certo?

Não, o problema é uma empresa que levou um ano e não mostrou uma miséria de uma tela de Login funcionando, engraçado que o gerente de projetos falava em toda reunião: “mas o cronograma de riscos está atualizado” O.o
como meu deus? se o sistema não passa do Login?
Daí foi cancelado e passou para outra desenvolver, e nem olharam a “documentação organizada” da outra!

Não responderei mais mensagens relacionadas a este tópico visto que não está sendo de ajuda.

Volta, tá tão bacana, estou me vendo no passado