#Notes: Clean Agile - Chap. 2
Tags: books, agile
Published: 2021-05-27 03:07:26

# 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](https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002) 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](http://www.agileadvice.com/2005/05/15/agilemanagement/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](https://www.youtube.com/channel/UCypjXGqArVqgH8SK_fYUT8Q) 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.