O porquê da Metodologia Ágil

Acho justo dizer que qualquer sistema que exija que seus usuários pensem como programadores para inserir os dados no formato esperado é uma bela de uma porcaria.

Meus amigos e colegas de trabalho me dizem com uma certa frequência que eu fico procurando bugs nos sites e apps alheios, mas a verdade é que se algo não funciona como deveria (fica o load infinito ou o elemento que some do nada ou até mesmo aquele console.log() no console) fica difícil defender o projeto.
O ponto é, pra tentar descobrir minimamente o que está errado ou o erro apresentado, já precisa de um esforço grande.

Infelizmente, com o passar do tempo, as desordens no código podem se acumular. Se o código não estiver sempre limpo e ordenado, a equipe será pressionada e isso atrasará as coisas.

Em breve eu virei com as anotações do livro The DevOps Handbook que me fez refletir bastante sobre o "fazer certo" e o "fazer rápido".
Será que em alguma situação o modo empurrar com a barriga deu certo?

o código existente é um treinador ainda mais influente.

Aqui o tema era sobre a introdução do projeto a pessoas recém chegadas no time. Acredito que tendo um bom readme ou alguém experiente disponível para passar os padrões do projeto já ajuda bastante.

Mas, de onde a Equipe dos Feras tira os requisitos? Existe um documento de requisitos atualizados? Sim. É o código antigo. Ele é o único documento que descreve com precisão o que o sistema reprojetado deve fazer.

Ainda não tive a oportunidade de refatorar um projeto inteiro (não sei se me sobraria cabelo na cabeça caso o fizesse). Mas faz sentido usar as regras do sistema antigo para o desenvolvimento do novo.
Próximo a esse trecho, Uncle Bob fala sobre a evolução do sistema antigo em comparação com o novo, basicamente o sistema novo dificilmente vai conseguir acompanhar o antigo.

Redesigns grandes são muito caros e é raro serem implementados.

Você tem medo do código, e esse medo o obriga a assumir uma postura incompetente.

Sobre não se sentir confortável o suficiente para fazer uma refatoração que você sabe que é necessária.

Espero que todos os membros de uma equipe de software tenham certeza de que alguém consiga assumir a sua retaguarda caso eles tropecem e caiam.

Vai além do Truck Factor. A maturidade e boa relação do time ajuda tanto na qualidade do fluxo quanto do trabalho em si.

Na realidade, a melhor forma de aprender é ensinar. Portanto, quando pessoas novas se juntarem à equipe, ensine-as. Aprendam a ensinar uns aos outros. Mais uma vez, a prática ágil da Equipe como um Todo é compatível com essa expectativa.

Outro dia conversando com um colega de trabalho me veio o questionamento sobre como/quanto esse primeiro contato com os nossos projetos estariam sendo afetadas por conta do trabalho remoto. Para dar um melhor contexto, a cultura do time anteriormente já era essa, de fazer o onboarding no projeto, bem próximo ao time, para que dúvidas sejam esclarecidas o mais rápido possível. (Acho que esse assunto vale um post)

Os clientes têm o direito de agregar o máximo de valor possível em cada iteração.

Sobre os direitos do cliente (ou qualquer entidade relacionada com o produto/cronograma/orçamento).

A metodologia ágil não é um processo, não é modismo e não é somente um conjunto de regras. Pelo contrário, a agilidade é um conjunto de direitos, expectativas e disciplinas do tipo que alicerça a base de uma profissão ética.

Num vídeo ainda não publicado no meu canal do YouTube eu falo um pouquinho só sobre a metodologia ágil e suas cerimônias. Nele cito a impressão de que as cerimônias são obrigatórias e que todas as regras são escritas em pedra, tem uma diferença entre o fazer errado e o fazer adaptações, às vezes o problema é o desequilíbrio entre essas partes. Mas tendo em mente a importância do trabalho e o impacto que ele tem, acredito que boa parte dos problemas já são mitigados.

Tentei trazer mais links externos com referências para alguns termos, tem mais coisas desse tipo para serem agregadas aqui, mas deixo isso para a próxima revisão.