Para apresentar uma objeção com cuidado, eu não acho que código possa substituir documentação. As linguagens de programação ainda não têm a riqueza de expressão e a capacidade de comunicação da linguagem natural e, na prática, quem vai ler todo esse código?
Ter um código que possa substituir documentação é uma esperança e um desejo, mas é uma Torre de Babel impossível de alcançar.
Parece melhor, antes, se dedicar com afinco a OOAD.
O que significa exatamente escrever a própria spec de forma ágil?
Escrever a spec por alto.
Escrever a spec do jeito que o cliente vai ditando.
Quando os requisitos do cliente mudarem, fazer a manutenção com ajuda de ferramentas para conseguir mudar a spec rapidamente.
Escrever a spec de forma ágil.
O ponto principal daquele texto é que, desde o começo, eu simplesmente não entendo o que é agile. Só ficam falando que agile tem essas características e que é preciso fazer isso e aquilo, mas até hoje nunca vi um texto que mostrasse de fato “este é um produto criado com a metodologia agile”. Mesmo olhando o manifesto, achei tudo meio nebuloso. Que tal mostrar um exemplo?
Não sei por que tratam metodologias como se fossem escrituras sagradas. Acho que o autor original também não deixava de ser dogmático, apenas seguia uma direção diferente.
A partir do momento em que você escolhe o SQLite para um servidor de produção, precisa ficar pensando o tempo todo em quando vai migrar.
Antigamente, valia a pena pensar nisso porque o custo do próprio DB (compra de servidor, IDC, custo de licença etc.) era alto,
mas hoje em dia, quando dá para montar tudo com um simples clique, será que ainda há necessidade de se preocupar com isso?
Só de pensar em romper com a tomada de decisão vertical e em melhoria iterativa em ciclos curtos, a mensagem que isso nos deixa já é enorme (e, claro, o mesmo vale para as técnicas/ferramentas de gerenciamento de projetos).
A conclusão de que 'o Agile em si não trouxe novos insights e acaba distorcendo todos que defendem o Agile como fanboys cegos do Agile' me parece extrema demais.
Gostei muito da leitura. Também do que você escreveu no blog. Não sei se a analogia é adequada, mas fico pensando se isso não segue a mesma linha do motivo de Hello World! ser o primeiro tutorial de tantas linguagens e, no passado, do processo de aprender desenvolvimento web construindo fóruns e lojas virtuais. Antigamente eu pensava assim: se você tiver técnica suficiente para criar um fórum e uma loja virtual, consegue implementar a maior parte da web. E, no fim das contas, programação é, em última instância, apenas input e output.
Acho que a conclusão está um pouco exagerada. Comercialização ou formalização podem ser o problema, mas isso não significa que ferramentas como sprint ou backlog tenham deixado de ser úteis. Elas também ajudaram a consolidar uma cultura de reuniões mais horizontal e orientada a objetivos. Concordo que o SDD se tornou mais importante, mas como a própria especificação pode ser escrita de forma rápida e colaborativa com a IA, isso ainda continua sendo ágil. Só que o sprint de duas semanas foi encurtado para algumas horas; a essência de iterar e ir lapidando continua a mesma, na minha opinião.
Que texto bobo. O ponto principal é que a própria spec. deve ser escrita de forma ágil... Agile é se adaptar rapidamente às mudanças nos requisitos do cliente.
É por causa de pessoas com esse tipo de mal-entendido e imaginações superficiais sobre agile que tanto o agile quanto a cultura de desenvolvimento acabam se desviando do caminho certo.
Parece mais uma mudança de perspectiva, mas vocês todos estão bem sensíveis, hein.
Acho que eu também vou tentar uma vez.
Obrigado pela boa informação.
Para apresentar uma objeção com cuidado, eu não acho que código possa substituir documentação. As linguagens de programação ainda não têm a riqueza de expressão e a capacidade de comunicação da linguagem natural e, na prática, quem vai ler todo esse código?
Ter um código que possa substituir documentação é uma esperança e um desejo, mas é uma Torre de Babel impossível de alcançar.
Parece melhor, antes, se dedicar com afinco a OOAD.
O que significa exatamente escrever a própria spec de forma ágil?
O ponto principal daquele texto é que, desde o começo, eu simplesmente não entendo o que é agile. Só ficam falando que agile tem essas características e que é preciso fazer isso e aquilo, mas até hoje nunca vi um texto que mostrasse de fato “este é um produto criado com a metodologia agile”. Mesmo olhando o manifesto, achei tudo meio nebuloso. Que tal mostrar um exemplo?
BckHWP. Automação em Excel VBA
https://m.blog.naver.com/husky81/222045248589
Eu só queria que o Gemini CLI pelo menos funcionasse direito, mas ele vive travando.
Ultimamente tenho visto esse tipo de caso com mais frequência.
Não entendi exatamente, mas acho que mais ou menos consigo captar a sensação.
Obrigado.
Não sei por que tratam metodologias como se fossem escrituras sagradas. Acho que o autor original também não deixava de ser dogmático, apenas seguia uma direção diferente.
A partir do momento em que você escolhe o SQLite para um servidor de produção, precisa ficar pensando o tempo todo em quando vai migrar.
Antigamente, valia a pena pensar nisso porque o custo do próprio DB (compra de servidor, IDC, custo de licença etc.) era alto,
mas hoje em dia, quando dá para montar tudo com um simples clique, será que ainda há necessidade de se preocupar com isso?
Este próprio texto não é ágil!
Concordo.
Só de pensar em romper com a tomada de decisão vertical e em melhoria iterativa em ciclos curtos, a mensagem que isso nos deixa já é enorme (e, claro, o mesmo vale para as técnicas/ferramentas de gerenciamento de projetos).
A conclusão de que 'o Agile em si não trouxe novos insights e acaba distorcendo todos que defendem o Agile como fanboys cegos do Agile' me parece extrema demais.
Seria bom se o codex também passasse a oferecer suporte a token OAuth, como o Claude.
Gostei muito da leitura. Também do que você escreveu no blog. Não sei se a analogia é adequada, mas fico pensando se isso não segue a mesma linha do motivo de
Hello World!ser o primeiro tutorial de tantas linguagens e, no passado, do processo de aprender desenvolvimento web construindo fóruns e lojas virtuais. Antigamente eu pensava assim: se você tiver técnica suficiente para criar um fórum e uma loja virtual, consegue implementar a maior parte da web. E, no fim das contas, programação é, em última instância, apenas input e output.Acho que a conclusão está um pouco exagerada. Comercialização ou formalização podem ser o problema, mas isso não significa que ferramentas como sprint ou backlog tenham deixado de ser úteis. Elas também ajudaram a consolidar uma cultura de reuniões mais horizontal e orientada a objetivos. Concordo que o SDD se tornou mais importante, mas como a própria especificação pode ser escrita de forma rápida e colaborativa com a IA, isso ainda continua sendo ágil. Só que o sprint de duas semanas foi encurtado para algumas horas; a essência de iterar e ir lapidando continua a mesma, na minha opinião.
Que texto bobo. O ponto principal é que a própria spec. deve ser escrita de forma ágil... Agile é se adaptar rapidamente às mudanças nos requisitos do cliente.
É por causa de pessoas com esse tipo de mal-entendido e imaginações superficiais sobre agile que tanto o agile quanto a cultura de desenvolvimento acabam se desviando do caminho certo.
Que porra é essa? Você acha que se usa db por causa de performance?
O link está apontando incorretamente para o domínio
com.Segue o link do aviso relacionado.
[Aviso] 16/04 (qui) Ocorrência de problema de acesso ao serviço ▶ Resolvido
Dá para viver sem geladeira, mas seria inconveniente.
Se você pode usar uma geladeira, não há motivo para não usar.
Pois é, não é Apache 2.0.