A importância da meta.

Em vários projetos, não apenas ágeis, metas identificam pontos de verificação e validação do que está sendo realizado dentro de um projeto. Para projetos ágeis, especificamente utilizando Scrum, a meta é a razão de existir de uma iteração, também conhecida como Sprint. Se olharmos para o Scrum como um jogo onde o ideal é vencer e para vencer a meta dever ser alcançada, fica claro a importância de uma meta clara e atingível. Mais ainda, sem uma meta, não faz o menor sentido por exemplo, ter uma reunião diária, que serve para o time sincronizar os esforços e verificar o quanto longe está justamente da meta.
Meta para times Scrum
Assim como no futebol a meta é fazer o gol, no Scrum a meta deve ser entendida por todo o time Scrum e todos sem exceção devem jogar o jogo para vencer e tendo sempre em mente aonde querem chegar e porque a meta é importante para a Sprint e por consequência para o Produto. A analogia pode ser feita da seguinte forma também: Um produto pode ser considerado como um campeonato e as Sprints comparadas às partidas que são jogadas para que o time vença o campeonato. Pode ser que às vezes percamos alguns jogos, mas o campeonato é sempre mais importante que os jogos. Desta forma podemos ver que a Visão do Produto nada mais é que a meta maior que permeia o desenvolvimento, guiando o time à vitória final. 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

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

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

Cuidado com a dívida técnica

Depois de mais de um mês se escrever no blog, ufa, também com essa mudança de empresa, cidade e estado, só faltou mudar o país!! Bom, estava lendo alguns artigos na InfoQ e algo me chamou a atenção e resolvi escrever a respeito: Dívida Técnica. Primeiramente vou falar sobre o que é dívida técnica e depois abordarei algumas das causas mais comuns.

Definição de Dívida Técnica

O conceito de “Dívida Técnica”, é uma metáfora para indicar que toda vez que você toma um atalho técnico (o bom e velho “não importa que saia sujo, o importante é lançar o produto rápido!”), ou também as famosas POGs(Programação orientada a gambiarra). Continue

Quanto do seu software é realmente usado pelo seu cliente

Se você fosse um CIO de uma empresa qualquer e tivesse um orçamento de 1 milhão de reais, isso mesmo R$ 1.000.000,00 para desenvolver um software para atender a uma determinada área da sua empresa, você aceitaria que 650 mil, isso mesmo R$ 650.000,00 fossem para a lata do lixo?

Pois bem, um estudo realizado pelo Standish Group revela que cerca apenas 7% de todas as funcionalidades escritas em um software comercial nos EUA são utilizadas sempre, ou seja são aquelas que o usuário da aplicação ao utilizar o sistema, vai efetivamente utilizar. Acredito que esses números são bem próximos dos aplicados aos mesmos tipos de software no Brasil. O mesmo estudo mostra que outros 13% das funcionalidades da aplicação são utilizadas frequentemente, e que ainda de acordo com o estudo, 16% das funcionalidades são utilizadas as vezes. Então como é de se imaginar, sobram uma boa parte das funcionalidades que são utilizadas raramente(19%) e nunca(45%). Pasme você porque é isso mesmo, 65% das funcionalidades de um software não são utilizadas nunca, ou no melhor dos casos raramente são utilizadas. Sabe aquele cadastro fácil (de cidade, estado, sexo, religião e afins) que alguns desenvolvedores adoram fazer, muitas vezes perifericamente até para ir acostumando com o sistema, o negócio para depois entrar nos mais difíceis, pois bem esse cadastro está com certeza entre os 65% do seu software que o cliente nunca irá usar, e digo isso com toda a certeza, porque até algum tempo atrás eu mesmo iniciava meus sistemas por estes cadastros. Continue