Como Scrum é uma metodologia iterativa e incremental, quando você lida com design no Scrum não é diferente.
Os designers do seu projeto devem ter um conhecimento prévio sobre as funcionalidades e características do produto que esta sendo desenvolvido, pois eles atenderão às exigências da equipe sob demanda.
Os designers podem compor uma equipe Scrum a parte configurando um outro projeto e o resultado obtido do projeto dos designers servirá de entrada a vários outros projetos de codificação. Essa configuração acontece quanto nos demais projetos um dos critérios de história preparada é ter o design pronto da história a ser implementada. Ou seja, a equipe de codificação do produto não é responsável pelo design do produto.
A criação do product backlog em um projeto de design pode acontecer de duas maneiras diferentes:
1. Em um projeto que já está em andamento, as demandas vão surgindo ao longo do desenvolvimento e estas vão sendo relatadas a equipe de designers e são adicionadas diretamente no product backlog do projeto de design.
2. Em um projeto que está para ser iniciado é importante que o P.O. e a equipe tenham uma boa visão das telas iniciais que precisam para gerar as histórias no product backlog dos designers.
Em ambos os casos a sprint de design deve ser feita de forma a atender uma sprint futura dos demais projetos. Ou seja a sprint do designer deve estar sempre um passo a frente da codificação.
Quando lidamos com design em scrum, temos que estar aptos a nos adaptar a mudanças de requisitos. Como o conceito de "bom" design depende do gosto de cada um, nós dependemos mais que outros da aprovação do P.O. e por isso a definição de pronto também é mais complicada neste caso. Fazemos as histórias com as prioridades definidas pelo P.O. de acordo com as necessidades mais urgentes de cada equipe, e devemos tentar ao máximo seguir essa ordem para não atrasarmos as outras equipes.
Existe uma diferença fundamental da Sprint do design para as outras:
Como a equipe de designers pode atender à varias projetos diferentes, não existe um incremento do produto a ser entregue ao fim da Sprint. Na verdade, as histórias da sprint dos designers podem ser entregues no decorrer da Sprint, em casos em que o PO está participativo e avaliando a todo instante o trabalho que está sendo realizado. Além do mais, pode ocorrer de novas histórias surgirem no decorrer de uma sprint e devemos então conseguir nos adaptar a mudança de requisitos e prioridade.
E você, designer, como tem trabalhado usando o Scrum? Relate aqui sua experiência.
Legal esse post! Muitos desenvolvedores se esquecem de que, para o usuário, a "página web" é seu produto! E é sempre muito ruim a percepção imediata de uma solução realizada somente por programadores (webdesign sofrível, mensagens de erro absurdas) ou somente por designers (pouca interação do sistema, excesso de animações).
Quando trabalhei numa agência de design, tive a excelente oportunidade (e certeza) de incorporar webdesigners em equipes multidisciplinares Scrum…eles costumam ser ótimos elicitadores de requisitos (apenas utilizando outras técnicas, como wireframes) e ótimos executores de testes de integração! Assim, eles alternam sua alocação na preparação da próxima sprint (essa defasagem é, realmente, fundamental) e na aceitação das histórias da sprint atual.
Ah, também contribuem para melhor comunicação (na equipe, com PO e demais interessados), forçando menor uso de termos técnicos de TI, e ampliam os critérios da definição de pronto ("done") do time auto-gerenciado.
Há pouco tempo, escrevi um post semelhante (http://www.sw.eng.br/#!/2011/10/em-qual-desenvolvimento-web-eu-nao.html), no qual enfatizo o que a 37Signals chama de "epicenter design": construa páginas reais, deixe as limitações guiarem sua solução criativa e não force soluções pré-concebidas de arquitetura técnica (http://vimeo.com/15772341).
OBS.: Estamos de "design" como "webdesign", né?! 😉 Esse termo, em português, é perigoso.