Anotações do capítulo: Introdução à Metodologia Ágil
A ideia de repetir um processo bem-sucedido é intuitiva e humana demais para ser considerada algum tipo de revolução.
É o que já aprendemos desde pequenos vendo coisas que dão certo.
O que relato a seguir é proveniente das minhas memórias; não tentei verificar nada com os envolvidos. Logo, você deve estar ciente de que minhas recordações têm muitas omissões e coisas inacreditáveis, ou, no mínimo, um tanto imprecisas. Mas não se assuste, pelo menos tentei ser um pouco divertido.
Tudo bem Uncle Bob, as vezes minha memória me confunde também.
Um bom gerente administra os coeficientes desses atributos, em vez de exigir que todos esses coeficientes sejam 100%. A metodologia ágil se esforça para atingir esse tipo de gerenciamento.
Sobre a capacidade de coordenação do gerente quando consegue realizar um projeto bom, rápido e barato e concluído quando necessário.
...os requisitos estão em constante movimento e nunca podem ser congelados. Isso ocorre porque os clientes não sabem realmente o que querem. Eles meio que sabem qual problema querem resolver.
O projeto chegar com o objetivo e utilidade imutáveis e seguir assim até a entrega seria um utopia? Esse trecho me faz lembrar bastante do último item do manifesto ágil: "Responder a mudanças mais que seguir um plano".
Não há como fingir que você implementou alguma coisa.
Imagina a situação em que alguém está revisando o seu código, questiona o motivo de ter usado tal método e você não consegue explicar ou diz algo sem sentido.
Esse processo de escrever histórias, estimá-las, planejá-las e projetá-las nunca para.
Tudo muda no decorrer do projeto, as funcionalidades, o foco do produto final, as necessidades de quem usa, as regras de negócio. Mas mais a frente ele cita que não é necessário desenvolver todas as histórias que foram criadas, mas entregar o necessário para o projeto. A priorização ajuda nesse ponto.
Por enquanto, quais são as possibilidades de a equipe concluir todas as histórias que planejou terminar? Praticamente zero, é claro. Isso ocorre porque o software não é um processo de estimativa confiável.
Colocamos a metodologia ágil em prática para matar a esperança antes que ela destrua o projeto.
Para não ficar vítima do achismo na expectativa de que vão conseguir cumprir o cronograma.
A esperança é a assassina de qualquer projeto. É o que faz uma equipe de software iludir os gerentes sobre seu verdadeiro progresso. Quando um gerente pergunta a uma equipe: “Como as coisas estão indo?”, é a esperança que responde: “Muito bem.” Gerenciar um projeto de software por meio da esperança não é nada bom. A metodologia ágil é uma forma de proporcionar uma bela dose precoce e contínua da realidade nua e crua no lugar da esperança.
O que eu disse?
A metodologia ágil é saber, o mais cedo possível, o quanto estamos ferrados.
Essa frase é boa.
Gerentes gerenciam os projetos de software, coletando os dados e tomando as melhores decisões possíveis com base neles. A agilidade gera dados. A agilidade gera muitos dados. Os gerentes utilizam esses dados para direcionar o projeto rumo ao melhor resultado possível.
Vai além da melhor visualização e acompanhamento do trabalho. Vai além da remoção de impedimentos e cerimônias.
Os gerentes deveriam (saber) coletar esses dados e (como) utilizar isso para estudar possíveis melhorias apresentar para o time e implementá-las.
É uma tarefa fácil?
A Lei de Brooks postula: Adicionar pessoas a um projeto de software atrasado resulta em um atraso ainda maior.
Ainda preciso ler mais sobre a Lei de Brooks.
Mas um antigo colega de trabalho que me guiou no início dos estudos sobre agilidade sempre reforçava que a entrada de uma nova pessoa impactava diretamente na produtividade por um tempo.
Grandes são as chances de eu retornar a essas anotações para atualizar algumas ideias ou trazer mais questionamentos.
Top comments (0)