Desenvolver software não é uma tarefa fácil, existem diversos riscos, que variam de projeto para
projeto. Muitos são os fatores que levam à necessidade de
desenvolvimento de forma iterativa-incremental, e risco é um deles.

Desenvolvimento Ágil?

Agile
não tem nada a ver com isso. Estou falando de algo bem mais básico.
Podemos dizer que isso já deixou de ser conhecimento explícito e virou
tácito. Infelizmente, nem para todos.

Por que desenvolver em pedaços?

A resposta é bem
simples, quanto mais você desenvolve mais risco tem. Isso mesmo,
desenvolver algo é um risco! Quanto menos você desenvolver, melhor, por
isso toda a conversa sobre reaproveitamento, design,
Arquitetura,
SOA
e Asset
Management.

Não interessa o quanto você pesquise, o quanto
você teste, o quanto você faça peer-review! Enquanto você não colocar em
produção, o produto/serviço não existe! Somente quando o produto/serviço
entra em produção é que você começa a colher resultados.

No
momento em que você começa a colher os resultados e os riscos forem mitigados mais rapidamente, você começará a ter ROI,
isso de uma maneira simples. O mais efetivo ROI só pode ser obtido de
um planejamento
estratégico.

Big Bang Boom

Você já deve ter
ouvido falar do termo “big-bang
integration Projects“. Os famosos projetos que em um dia você vira
a chama e troca todo um sistema legado por um sistema novo. Acreditem, não
é nada divertido.

Podemos
usar o mesmo conceito pra releases, quanto menor, melhor. As entregas
devem ser do menor tamanho possível. Ok, ok, ok, não existe novidade aqui, a
questão é que na maioria das vezes não existe mesmo! De fato, as
pessoas tendem a ignorar esses mais de dois mil anos de civilização
judaico-cristã!

Que tamanho
deve ter uma entrega?

Essa é uma pergunta interessante e
pode ser “tricky“. Antes de
lançar um release, você deve se preocupar com algumas coisas, como por
exemplo:

• Todos os testes necessários já foram feitos?
• As
  pessoas vão precisar de treinamento para essa implantação?
• Existe
  maquinário adequado?
• A performance vai continuar ok?
  Precisamos trocar o banco? Os Servidores?
• Quem dará suporte a
  isso?
• Existe documentação?
• Qual a janela de
  implantação? Plano de Rollback?

Uma vez que essas perguntas
tenham respostas positivas, podemos prosseguir, mas ainda falta a
questão mais importante: essa entrega traz algum valor? Se sim, go ahead! Se você
consegue fazer isso em um dia, ou em uma semana, ótimo! Quanto mais
frequente, melhor.

Por que colocar
coisas em produção frequentemente?

Porque precisamos dar
retorno! Esse retorno é duplo! Tanto em termos de valor para o cliente,
quanto em termos de feedback para a equipe. Mas isso é Scrum, é RUP, é
Agile? É mais básico que isso, estamos falando aqui do PDCA.

Plan
Do Check
Act

O
PDCA é um ciclo de desenvolvimento que pode ser usado em muitas áreas, e
isso até fora da TI. Ele é um ciclo para a melhoria da qualidade do
trabalho. Em um projeto, ele é essencial, quando falamos em iteração,
falamos em um ciclo semelhante ao do PDCA.

Onde está o problema?

Muitas
vezes no Check e no Act! De fato, as
empresas perdem muito tempo executando e pouco tempo avaliando e fazendo
alguma coisa para mudar as coisas. O Scrum,
por exemplo, é, em parte, uma especialização do ciclo do PDCA.

Não
adianta de nada só planejar e executar. Se você executar o ciclo todo,
os dois primeiros passos não servem de nada, em termos de melhoria da
qualidade. Executar a checagem alguns fazem, executando as
retrospectivas do Scrum, por exemplo. Mas isso não é o suficiente.

É
necessário agir, mudar as coisas que não estão legais, e para isso é
necessário coragem e honestidade. Admitir que existe um problema na
gestão em um uma empresa não é fácil, mas é a única maneira de corrigir o
problema e progredir!