Desenvolvimento Agil Limpo - 2. O Porque da Metodologia Agil

Principal Aprendizado

É um capítulo bem mais "filosófico", encorajando o profissionalismo e o trabalho de qualidade. E alegando que as "práticas ágeis" proporcionam isso.

Práticas Ágeis:

[TOC]

Profissionalismo

O desenvolvimento ágil é importante por motivos éticos e filosóficos mais enraizados. Eles têm a ver com profissionalismo e expectativas razoáveis de nossos clientes.

O principal alerta aqui é:

Exemplos de episódios lamentáveis:

Produtividade Estável

🌱 Em um projeto novinho, equipes de programação geralmente conseguem avançar rapidamente nos primeiros meses. Isso acontece pois não há um codebase para atrasá-la.

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.

🐌 Quanto mais a equipe se atrasar, maior a pressão do cronograma e maior o incentivo para as desordens ainda maiores no código. Esse ciclo de retroalimentação pode levar uma equipe à beira da paralisação.

🤦‍♂️ Os gerentes, perplexos com essa desaceleração podem finalmente decidir acrescentar recursos humanos à equipe com o objetivo de aumentar a produtividade.

😭 Há aquela esperança de que o atraso inicial para treinar os novatos seja recompensado após um tempo. No entanto, quem está treinando esse pessoal? As pessoas que fizeram a desordem. Os novatos certamente imitarão esse comportamento instituído.

Os clientes e gerentes não esperam que as equipes de software desacelerem com o tempo. Ao contrário, esperam que uma funcionalidade semelhante à que demorou duas semanas para ser feita, no início do projeto, demore também o mesmo tempo um ano depois. Eles esperam que a produtividade se estabilize com o passar do tempo.

Isso 👆 me lembrou um PM que tive...

Software e Adaptabilidade

Achei essa definição bem interessante:

Software é uma palavra composta. A palavra "ware" significa "mercadoria", "produto". A palavra "soft" designa a fácil mudança. Portanto, o software é um produto fácil de mudar. Ele foi inventado porque queríamos uma forma rápida e fácil de alterar o comportamento de nossas máquinas. Se quiséssemos que esse comportamento fosse difícil de alterar, o chamaríamos de hardware.

Desenvolvedores reclamam das mudanças de requisitos. Uncle Bob:

Se uma mudança nos requisitos quebrar sua arquitetura, sua arquitetura não presta.

Estimativas Realistas

A estimativa mais honesta é "não sei". Porém mesmo não sabendo tudo, existem algumas coisas que você sabe. Portanto as estimativas devem ser feitas com base no que você sabe e no que você não sabe.

Exemplo: Eu estimo que vou morrer dentro dos próximos 100 anos.

Você precisa dizer "não"

diga "não" quando nenhuma solução puder ser encontrada. Você precisa perceber que foi contratado mais por sua habilidade de dizer "não" do que por sua habilidade de programar. Vocês programadores, são as pessoas que sabem se algo é possível ou não. Como seu CTO, estou contando com você para nos infromar quando estivermos à beira do abismo.

conteúdo extra