No final das contas ainda é o PDCA

Desenvolver software não é uma tarefa fácil, existem diversos riscos em um projeto de desenvolvimento. Esses riscos são variam de projeto a projeto. Existem vários fatores que levam a 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 explicito 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çar a colher resultados.

No momento em que você começa a colher os resultados e os riscos são 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 projeto que em um dia você vira a chama e troca todo um sistema lega 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 facto as pessoas tendem a ignorar esses mais de 2000 anos de civilização judaico-cristã!

Que tamanhado deve ter uma entrega?

Essa é uma pergunta interessante e pode ser "tricky". Antes de laçar uma release você deve se preucupar 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 máquinario adequado?
  • A performace vai continuar ok? Precisamos trocar o banco? Os Servidores?
  • Quem ira dar suporte a isso?
  • Existe documentação?
  • Qual a janela de implantação? Plano de Rollback?
Uma ves que essas perguntas tenham respostas positivas podemos processeguir, mas ainda falta a questão mais importante, essa entrega tras algun valor? Se sim go a head! Se você consegue fazer isso em um dia ou em uma semana ótimo! Quanto mais fequente melhor.

Por que colocar coisas em produção frequentemente?

Por que 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 desnvolvimento que pode ser usado em muitas areas e isso 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 cliclo semelhante ao do PDCA.

Onde esta o problema?

Muitas vezes no Check e no Act! De facto as empresas perdem muito tempo executando e pouco tempo avaliando e fazendo alguma coisa para mudar as coisas. O Scrum por exemplo, em parte ele é 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, 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!


Popular posts from this blog

Telemetry and Microservices part2

Installing and Running ntop 2 on Amazon Linux OS

Fun with Apache Kafka