Etiqueta: kanban

Deixa fluir

Tudo que impede fluxo é ruim. Uma excelente forma de perceber isso é ter uma clareza visual de que o trabalho não está andando.

Se um item demora muito para ser concluído ou se muita coisa fica parada esperando respostas que não chegam nunca, temos problemas. Estes problemas indicam tarefas grandes demais, que podem ainda ser carregadas de incertezas. E talvez um processo de falta de autonomia ou falta de gestão de conhecimento. 

Todo fluxo organizado em um kanban pede limites, pede representação da realidade, pede visualização e pede políticas. E as políticas são na minha opinião a parte mais importante. As políticas emergem dos aprendizados. Os aprendizados acontecem com a prática do dia a dia, tentando fazer o trabalho acontecer. Todos problemas se resumem em saber: 

Continuar a ler →
Publicado em por dwildt 0

Uma nova tarefa no meio da iteração planejada. O que fazer? #dwresponde ep. 15

Mais uma edição do Daniel Wildt responde! No episódio 15, pergunta de Vitor Consalter!

Fala Daniel, blz?
Situação é a seguinte: 4 desenvolvedores tocando um sprint de um projeto X. No meio do sprint um “Cliente especial” liga e pede uma alteração em projeto Y. Um dos desenvolvedores deixa o projeto X e começa a tocar o Y. Por muitas vezes esse desenvolvedor não volta para o projeto X até o final do sprint. GP reduz as tasks do kanban e essa redução não tem piores complicações.
Problema: motivação dos outros 3 desenvolvedores vai por água abaixo. Em diversas reuniões de retrospectivas é comentado essa situação e os desenvolvedores comunicam suas insatisfações.
O que fazer? 🙂
Abraços Daniel.
Vitor Consalter

Continuar a ler →

Publicado em por dwildt 0

A importância das filas e da variabilidade

Nenhum sistema consegue funcionar com 100% de utilização. De uma forma ou de outra, procuramos uma cadência para funcionar e gerir nossas equipes de trabalho.

Uma das grandes descobertas que tive no aprendizado e prática de metodologias ágeis, foi a importância de minimizar a variabilidade das atividades que executamos. Ao invés de permitir que o sistema tenha atividades de 5 horas e outras de 40 horas, procuramos de alguma forma mais estabilidade.

Ao fazer isto, começamos a fazer mais quebra das atividades maiores, mas o impacto no time não é simplesmente aumento de atividade de análise para garantir a quebra, mas a baixa significativa da complexidade e do risco que acabava indo junto com o planejamento.

O grande jogo de minimizar o tamanho das atividades é com isto minimizar a variabilidade das atividades e encontrar neste processo cadência.

Para ajudar nesta discussão, aconselho demais a aula gratuita do Alisson Vale sobre este assunto, no Software Zen.

Deixe no comentário aí desafios que você enfrenta com o seu time no processo de aprendizado em virtude de grandes esperas.

Publicado em por dwildt 0

Chegando ao tal MVP (Minimum Viable Product)

Um MVP, no português Produto Mínimo Viável, pode ser visto como a versão de um produto ou serviço que vai ser colocada a teste, para a comunidade tida como público alvo do mesmo.

Um MVP não precisa ser um software pronto. O Dropbox tem a história clássica de fazer o pitch do produto tendo apenas uma página de sign-up e um vídeo mostrando como o serviço “funciona” (na época não existia nada).

O que se quer neste processo? Validação. Entender o que está sendo feito e poder validar com usuários potenciais. Ganhar aprendizado para poder ajustar e poder testar com uma gama maior de usuários. Entender se as taxas de conversão seguem funcionando e de preferência crescendo.

Queremos entender se o entendimento do produto/serviço é claro para o público que estamos buscando e também entender se existem outros públicos para qual deveríamos estar dando atenção.

Um projeto colocado em uma plataforma como o Catarse ou Kickstarter pode ser visto como um MVP.

Ao lançar um MVP, existe uma intensão, um experimento. Queremos testar alguma hipótese, vendo se o texto está sendo mais efetivo que o anterior. Vendo se o modo de divulgar o preço se faz mais atrativo que o modo anterior. Se quer validar e ganhar um novo aprendizado, para então se poder rodar um novo experimento.

Ah, o mais importante. Um MVP é o início. Não o fim. 🙂

Você pode citar exemplos de MVPs?

Publicado em por dwildt 2