Regra simples que aprendi com desenvolvimento de software mas que é útil em diferentes aspectos da nossa vida.
(mais…)Etiqueta: dev
-
-
Você deve usar sistemas diversos e por vezes deve encontrar problemas no uso, que podem se mostrar como sugestões de melhoria ou erros de operação.
Que informações seriam importantes?
(mais…) -
Você revisa o trabalho de outras pessoas? O trabalho de revisão se conecta com colaboração e ele pode acontecer de forma síncrona ou de forma não simultânea. A revisão funciona com vários aspectos presentes: de prevenção, educação, humildade e respeito.
(mais…) -
Os critérios de aceite nos dizem como uma determinada história deve ser validada. Será que fizemos tudo o que era esperado? Os critérios de aceite podem servir como tarefas também. Tem contexto e dados de apoio. Cada um deles nos permite entender um dos cenários que devemos atender, representado como algo importante para clientes.
(mais…) -
Projetos evoluem baseados em dados e/ou datas. O que você precisa?
(mais…) -
One of the things I like to say to people learning about software development is that they should be reading more. You need to practice, you need to write code, but don’t forget to read code.
That isn’t different if you are becoming a writer… you should read more. Reading makes you reason about what you are going to focus.
Reading more is like a principle to research and learn a bit, before starting. I’m not telling you to read the whole manual, though. 😛
(mais…) -
Muitas vezes erros não são reportados, pela cultura de medo presente. Já estive em ambientes onde a resposta era “deixa a pessoa que usa o software reportar primeiro, não vamos corrigir antes“. Essa foi a resposta sobre um defeito encontrado em testes internos. Pelo menos foi permitido registrar como um defeito conhecido.
Depois ao longo do tempo de experiência, isso foi ressignificado, e aprendi que existem problemas que tem prioridade em relação a problemas menores. Talvez a melhor forma de resposta seria “vamos registrar e priorizar junto com as diversas falhas menores que temos já registradas”. Ainda assim a resposta não reflete o problema, mas a consequência.
Estamos discutindo como priorizar quais problemas queremos resolver, mas como fazemos para priorizar a prevenção ao desenvolver novas funcionalidades?
(mais…) -
When we are building new software or even a new feature, we are looking for ways to engage customers. We want to create traction, not friction.
We start (actually it’s a lifetime job) by finding a value proposition to a specific customer segment. At the same time, we want to find ways to bring those users and also ways to keep them close to our business.
Not an easy process.
(mais…) -
Eu gosto muito do termo trabalhabilidade, pensando em habilidades que desenvolvemos e que podemos colocar disponíveis para projetos e locais que a gente atua.
Agora, quando você está buscando um novo projeto ou empresa para atuar, quais são os seus critérios?
(mais…) -
Muitas vezes a gente coloca muita energia em cima de ferramentas ou artefatos que nossos projetos podem gerar. E este jogo está relacionado em como estas estruturas influenciam o trabalho a ser feito. As atividades a serem entregues. A qualidade do serviço a ser prestado.
(mais…)
