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:
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!
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?
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
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!
