Libere agora se puder
Sua pergunta sobre quando você começa a liberar o código é ótima. Eu acho que duas condições se aplicam. Primeiro, que você tenha "qualidade suficiente" e, em seguida, que atenda aos requisitos de um MVP (produto mínimo viável).
Roma (e Agile) não foram construídas em um dia
Talvez você esteja pronto com uma equipe ágil pronta para assumir o primeiro dia. Para a maioria das organizações, há o trabalho e as despesas de treinamento, reequipamento e o ciclo habitual de formação, assalto, normatização e execução da formação de uma equipe. Seja franco quanto aos riscos e custos, tenha cuidado para estabelecer expectativas realistas e esteja preparado para defender sua abordagem.
Seja um Bootstrapper reutilizado
Como o poder de fusão, a reutilização de código é e sempre será a solução futura para nossos problemas econômicos. Meu sentimento é que os desenvolvedores costumam dizer que acreditam na reutilização, mas apenas o tipo de reutilização que começa após a construção de uma nova estrutura, em vez do tipo em que se baseia no que outra pessoa já fez. Como isso pode funcionar até que alguém esteja disposto a escolher construir o alicerce de outra pessoa? Na melhor das hipóteses, significa reescrever a cada poucos anos quando a liderança da equipe muda.
Por que lançar cedo e frequentemente?
Liberar cedo e muitas vezes é um mantra por muitas razões. Isso dá vida às nossas discussões sobre o que o produto deve se tornar, torna real onde estamos e fornece uma base para mudanças iterativas / incrementais. O ritmo dos lançamentos é praticamente invariável para o ágil, com a diferença de quem recebe os lançamentos (substitutos do cliente ou usuários finais). Antes do Agile, a manutenção era estimada em 60% do custo dos sistemas de software. Essa é uma fonte de muita consternação para gerentes e outros, alguns que acham que o lançamento do produto é onde o software morre. Para eles, tudo após o lançamento é retrabalhado e pago para consertar um produto pelo qual eles já pagaram uma vez.
Pré-lançamento não é natural
Kent Beck escreve que o pré-lançamento é um estado não natural para produtos de software. Certamente é um momento inconveniente, porque é um momento em que você não tem clientes e está pagando pelo produto, e não pelo produto que está pagando por você.
Não critique a equipe anterior
Embora possa configurar os desenvolvedores que assumem a reescrita como heróis e salvação do projeto, acho que há um custo em criticar as realizações da equipe anterior.
- Primeiro, se você deixar as pessoas se decidirem sobre a equipe anterior, terá mais tempo e energia para sua verdadeira missão.
- Será complicado se você precisar trabalhar com membros da equipe anterior, tanto com desenvolvedores quanto com partes interessadas, como gerentes de produto, gerentes de projeto ou clientes.
- Se você conseguir fazê-lo funcionar, poderá receber (ou pior ainda, receber crédito) pelo que a equipe anterior fez.
- Em média, a equipe anterior provavelmente era média. Em média, você pode ser médio. Você tem mais trabalho do que a equipe anterior, porque possui uma nova metodologia para implementar, além de um projeto.
- Se a equipe antiga era horrível, a menos que você também seja horrível, você receberá crédito por ser melhor do que horrível. Se eles eram melhores que horríveis, e você não é visivelmente melhor, dizer que eles eram horríveis pode convidar comparações desagradáveis.
- Se a equipe antiga foi melhor do que você pensava, e você se mete em problemas porque a organização está quebrada ou o problema está mal definido ou muito difícil, as coisas vão melhorar para você se você não tiver aumentado significativamente as expectativas.
- Se eles esperam o que estavam recebendo, mas você se sai melhor, é uma vitória para você.
- Abster-se de críticas é uma boa educação e mostra que você tem classe.