O projeto mudou, e agora?

Perdido e sem direçãoParece até besteira, mas o que vou relatar aqui é uma narrativa de um fato que se assemelha a muitos outros, e que pode determinar o fim de um projeto e o fracasso de uma organização.

Uma empresa do ramo da construção civil contratou uma software house para desenvolver o ERP para atender suas necessidades, eram elas básicas: Controlar entrada e saída de mercadorias, realizar vendas, controlar patrimônio, emitir notas fiscais, controlar gastos com centro de custos, folha de pagamento, impostos, ou seja, quase todos os processos da empresa estariam neste ERP.

A equipe de vendas da software house ficou encantada com a oportunidade que se apresentava diante deles. Promessas e mais promessas foram feitas. Tudo o que os clientes queriam estava no “pacote“, nada iria faltar, os clientes teriam acesso total a tudo o que era necessário, milhares de gráficos e relatórios, indicadores até para a ração que os cães de guarda da empresa consumiam. Continue

Trazendo ordem a partir do caos

CaosO cenário é simples, uma empresa com projetos atrasados, qualidade baixa e entregas demoradas. Parece o panorama de uma empresa qualquer de software não só no Brasil, mas em qualquer lugar do mundo. Acredito que pode ser a minha empresa, a sua ou de algum amigo seu.

No primeiro momento é simples, há uma necessidade clara de maior controle sobre os prazos, sobre o andamento dos projetos, e principalmente sobre a qualidade e as entregas. Dentro desta configuração não se pode imaginar algo diferente, que não seja agir com mão firme, trazer as rédeas para junto do corpo e traçar metas para melhoras os indicadores da nossa empresa.

O grande desafio agora é com fazer isso, sem pressionar desnecessariamente os desenvolvedores envolvidos com cada um dos projetos. Com fazê-los pensar como empresa, sendo parte não apenas do problema, mas principalmente da solução.
Continue

A ilusão da previsibilidade

Bola de cristalÀs vezes alguns projetos de software são medidos pelo tempo de entrega ou pelo tempo de atraso no desenvolvimento do software. Verdade é que essa é uma vertente muito perigosa da forma tradicional de gestão de projetos. Fato é que, projetos em geral, não apenas tradicionais, são geridos muitas e muitas vezes pela entrega no prazo, com custo e escopo mantido.Verdade é, que nem sempre conseguimos prever de antemão tudo o que pode ocorrer dentro de um projeto. Por exemplo, é possível prever uma greve de ônibus que faz com que metade ou mais da sua equipe não consiga simplesmente chegar à empresa durante uma semana? Ou prever uma enfermidade que afaste justamente o líder técnico do projeto por um determinado tempo, comprometendo assim todos os prazos que foram previstos.
Continue

Gerando alto valor agregado ao software

Muito tem se falado sobre gerar valor agregado, que o Backlog do produto tem que ser ordenado de forma a enfatizar os itens que tenham mais valor. Costumo ser muito questionado sobre o que de fato significa gerar valor agregado. Bem como não poderia ser diferente, tudo o que é executado dentro de uma Sprint deveria por definição ter seu valor, já que tudo tem um custo para ser realizado. Quando falamos em valor agregado, temos que pensar em três fatores: Primeiro qual o custo efetivo daquela porção de software, ou seja, quanto custará para construir aquele pedaço do sistema. Segundo, qual será o retorno que este incremento de software trará para o meu Negócio. Terceiro qual o tempo que levará até que eu tenha retorno sobre investimento que foi desprendido para criar o incremento.

Gráfico de valor agregado

Bom, você agora deve estar imaginando que tudo gera em torno do retorno financeiro que o software trará, correto?
Bem, valor agregado não é apenas dinheiro em caixa, e talvez seja ai que esteja a grande confusão, valor agregado pode ser algo que para você talvez não tenha tanto valor ou importância dentro do contexto do software, mas para o cliente, será algo que poderá talvez, mudar a vida dele. Continue

Team Estimation Game – Porque usar!

Olá galera, primeiramente peço desculpas por não ter escrito já há algum tempo, devido a correria nossa de cada dia, mas, aqui estou eu novamente para falar de uma técnica de estimativa de software que aprendi ha algum tempo em um curso de Scrum que fiz em São Paulo. Algum tempo atrás falei sobre Estimativa em projetos ágeis, hoje irei abordar outra técnica.

Estimativa: Seria muito bom se não precisássemos fazê-la, mas, muitas vezes é necessário fazer. Em um sistema de desenvolvimento maduro ágil com lean/kanban, onde o valor prioritário está fluindo a uma taxa aceitável, e num contexto sem obrigação de conhecer a data de entrega as estimativas fornecem pouco ou nenhum valor. Portanto, não cegamente, você deve estimar suas características/histórias. E se você avaliar a necessidade de estimativas e determinar que eles valham a pena, você precisa determinar o quanto de valor que elas oferecem, para que você possa ter certeza que o esforço despendido estimativa é compatível com esse valor. Continue

Perigos dos “Mini-Waterfalls” utilizando Scrum

Tenho lido muito a respeito sobre mini Waterfalls camuflado de Scrum. Fato é que pessoas tem enganado a si próprias e a seus cliente tentando fazer um Scrum em fases dentro das sprints. A estes desavisados ou mal intencionados fica a dica, isto não é Scrum. O Scrum antes de qualquer coisa segue os princípios do Manifesto Ágil, ou seja, se o teu cliente não está próximo ao desenvolvimento, não é Scrum!! Se no início da sua sprint você dedica 1 ou 2 dias a análise e documentação, isso não é Scrum. Se você deixa para testar as features no final da sprint, ou seja, se não escreve os testes antes, lamento informar, isso também não é Scrum. Nosso framework de desenvolvimento para produtos complexos é relativamente simples nos princípios e nas regras, mas estritamente difícil de ser aplicado na prática. Requer boa vontade, determinação e muita, mas muita coragem. Continue

Qualidade não é negociável

No meu post anterior falei sobre dívida técnica. Um dos causadores de tal dívida é a falta de qualidade no código escrito. Pois bem, imagine então estes cenários:

Você decide que irá construir uma casa. Pensa na casa mais linda do mundo, janelas de vidro fumê, portão de elevação, cerca elétrica, a cor que você sempre quis.

Logo você irá contratar um bom engenheiro, um bom empreiteiro para para cuidar da construção, com seus auxiliares, pintores, serralheiros, vidraceiros e tudo o que uma bela edificação tem direito. Você explica que quer tudo bem direitinho do jeito que você sonhou, detalhe a detalhe relata o seu sonho para seus parceiros na obra. Apenas tem um exigência básica: o tempo tem que ser 3 meses exato, e a obra não pode passar de 120 mil reais. Continue