Comments on: Kanban para Design Gráfico e User Experience (UX) usando Scrum

By: Marcelo Paiva

Marcelo Paiva — Fri, 16 Jul 2010 19:39:31 +0000

Muito legal a iniciativa de voces e espírito de colaboração em dividir seus KanBans.

Estou curioso em saber como o seu processo evoluiu desde de Dezembro. Esse artigo merece um update, uma vez que – como voce disse – todos falam muito em SCRUM, mas não tanto em UX+SCRUM. Existem várias teorias com relação à esse tópico.

No nosso time, eu estou tentando implementar SPRINTS NEGATIVOS, onde os designers trabalhariam com o Product Owner durante essa fase gerando os todos artefatos de design POSSIVEIS (user research, heuristic eval, task analysis, information architecture, wireframes, paper prototype, interaction/visual design,etc. (the whole shebang!) Se o seu grupo é responsável pelo front-end development, entregaria os templates em HTML/CSS/JS.

Uma vez que os wireframes estejam prontos, o time de desenvolvimento poder começar a correr em paralelo (Sprint 1)

Separando os sprints de desenvolvimento dos sprints de design daria uma ótima bagagem para o product owner gerar os User Stories e criar os Sprints Backlog – o que eles precisam para iniciar o Planning Meeting.

Em suma, no seu Kanban detalhado ficaria mais on menos assim:

Sprint (-2): Compreensão e Pesquisa
Sprint (-1): Concepção e 1a rodada de Usabilidade (paper prototyping)
Sprint 0: Especificação e Finalização de User Stories/Backlog
Sprint 1: Desenvolvimento em paralelo com Look&Feel
Sprint 2: 2a rodada de Usabilidade

O que voces acham? Estou buscando opiniões de designers que já estejam trabalhando com SCRUM.

Obrigado,
Marcelo

By: Vinicius Serpa

Vinicius Serpa — Wed, 30 Dec 2009 13:51:05 +0000

Apesar de ter ficado com uma cara boa achei que mistura um pouco alguns conceitos.

No painel genérico uma sugestão seria não estipular de maneira fixa quais seriam as atividades desempenhadas em cada sprint por dois motivos: imagino que nem todas as atividades são executadas em todo sprint e segundo e mais importante, os sprints devem ser orientados às estórias. O cliente ou product owner pode não estar diretamente interessados em “pesquisas de usuário”, “mapas conceituais”, “wireframes” ou “protótipos”.

No painel detalhado, as atividades de compreensão e pesquisa não deveriam ser realizadas exatamente durante o sprint mas sim no product backlog e posteriormente no planejamento do sprint, para que seja possível estimar qual o esforço/tempo necessário para entregar cada estória. Sem essas informações teoricamente não seria possível estabelecer quais estórias poderiam ser entregues.

De qualquer forma esse é apenas um ponto de vista, o mais importante é fazer a metodologia realmente funcionar na prática.

By: tiago jaime machado

tiago jaime machado — Wed, 04 Nov 2009 04:50:14 +0000

RSS Feeds completos por favor!

By: Alberto Sasso de Sá

Alberto Sasso de Sá — Fri, 30 Oct 2009 21:31:01 +0000

Grande (ou seria pequeno) Hélio…
Legal disponibilizar pros visitantes do blog o kanban que usamos.
Está sendo muito útil e funcional usar o kanban. Não sei se um software seria tão utilizado e atualizado como o nosso (físico).
Abraço

By: Georges Herzog

Georges Herzog — Fri, 30 Oct 2009 20:06:09 +0000

Ferrari e Luiz,

Concordo com vocês quando dizem que o Kanban deve ser o mais simples possível de ser alterado… Afinal ele deve trabalhar de acordo com os nossos métodos (que vão se alterando com o tempo) e não nós nos moldarmos em função dele. Alias já estamos na segunda versão do nosso Kanban e acho que não deve ser a última.

Mas o negócio é o SEGUINTE, ehehe o nosso Kanban é para designers e todos tem acesso a ferramentas de edição (Photoshop, Illustrator…) assim acho do que fácil de se editar.

E Ferrari se tu tiver precisando de uns servicinhos de design pra alterar o kanban da sua área me dá um toque ae!!! ehehe
abração!!

By: Ricardo Longa

Ricardo Longa — Fri, 30 Oct 2009 13:55:23 +0000

O negócio é unir o útil ao agradável e criar um painel digital com um bom sistema para apoio ao SCRUM (como por exemplo o PRONTO, citado acima) substituindo assim o quadro físico. Este painel digital deve ser Touch Screen.

Logo, temos um software (melhor controle) + o “kanban físico”.

Lembra daquela tela touch screen utilizada no Fantástico?

Um abraço!

By: Luiz Faias Jr

Luiz Faias Jr — Fri, 30 Oct 2009 12:38:21 +0000

Olá Hélio,

Acredito que tanto faz se o kanban é digital ou não, se é feio ou bonito. O importante é a preocupação de entrega e melhoria contínuas como citou o Fábio Ferrari acima.

Na minha empresa temos o kanban físico, que dá uma visão rápida para todos os envolvidos e torna o trabalho mais transparente e também temos o digital através de um software livre chamado Pronto que desenvolvemos.

http://pronto.bluesoft.com.br

Ficou bem legal o design. Parabéns.

Abraço

By: André Faria Gomes

André Faria Gomes — Fri, 30 Oct 2009 12:03:31 +0000

Bacana Cara!!!

By: Gabriela

Gabriela — Fri, 30 Oct 2009 11:59:55 +0000

A primeira vez que ouvi falar de Kanbam e Kainzen foi no mestrado (Ergonomia, na Eng. Produção). Visitamos algumas indústrias, e os quadros eram sempre bem “rústicos”. Por isso acho esquisito isso de Kanbam digital, porque a idéia mesmo é poder mudar e dar visibilidade, fazendo com que todos do posto tenham “responsabilidade” pelo estado do trabalho. Por isso achei a forma de vocês usarem muito boa mesmo. Não é porque a gente trabalha “com computador” que a gente tem que fazer tudo “no computador”.

By: helio.costa

helio.costa — Fri, 30 Oct 2009 01:20:50 +0000

Menlina,

Arrumamos, obrigado

By: Carlos Gustavo Xavier

Carlos Gustavo Xavier — Thu, 29 Oct 2009 21:48:03 +0000

Mandou bem Hélio! Vou passar pra todos da empresa.

By: melina alves

melina alves — Thu, 29 Oct 2009 21:25:20 +0000

Ops, o link para “Download Kanban UX (PDF)” está com
arquivo errado.

By: melina alves

melina alves — Thu, 29 Oct 2009 21:18:53 +0000

Muito inteligente e funcional seus “Kanbans”. Já baixei aqui;
Obrigada por disponibilizar.

By: Fabio Ferrari

Fabio Ferrari — Thu, 29 Oct 2009 11:58:50 +0000

O problema de montar um Kanban muito bem desenhado é o desencorajamento da mudança do processo por melhoria contínua (Kaizen).
Um Kanban precisa ser mais vivo que possível, permitindo ajustes e experimentos de mudança de processo em pequenos incrementos.
Já vi Kanbans de diversos tipos, alguns com Kanban desvios por um tipo de FastTrack, outros que incorporam preceitos de criticidade e/ou dificuldade e ainda outros que implementam até desvios por limitação de estoque de trabalho em curso (WIP).
Este engessamento do Kanban é exatamente uma das críticas mais forte dos defensores do Lean/Kanban contra o SCRUM.