Recentemente no meu post "Como lidar com o design no Scrum" escrevi um pouco sobre o papel do designer em um projeto que está começando.
Neste artigo, veremos um pouco mais sobre este tipo de abordagem. Isto é, como fica a Sprint de Design quando um projeto novo está pra ser iniciado?
Um design muitas vezes, atende a vários projetos, então como fica a sprint quando um projeto que ainda não tem uma definição concreta de design inicia?
Em muitas empresas, as equipes aguardam, que o design ideal apareça espontaneamente, sem qualquer tipo de planejamento. E então, os programadores iriam fazer sua parte com o design pronto. Bem, é como na falácea do gêneo, nas artes ou nas ciências, onde o gênio se isola do mundo e então entrega o produto, a obra-prima. Mas sabemos que não é exatamente assim que funciona.
Então o que fazer a respeito disso? Sabemos que o design ideal não aparecerá diante dos seus olhos. A obra prima não surgirá pra sua equipe de um dia para a noite.
Passamos por isso recentemente. E posso falar um pouco da experiência que passamos. Em primeiro lugar, não é só o designer que tem responsabilidades com a equipe, ou só a equipe tem responsabilidades com o designer. O que deve acontecer é uma troca conjunta de idéias. Isto é, o designer e a equipe devem trabalhar como uma rede, como um complexo que funciona de forma sincronizada.
É importante que o designer participe das reuniões de planejamento do novo Projeto, que ele esteja a par de todos os requisitos do sistema, o designer tem que entender cada funcionalidade do sistema.
Com Scrum, trabalhamos com a entrega de pequenos releases, como já foi dito em outros posts, a sprint do Designer tem que estar sempre um pouco à frente da Sprint de Desenvolvimento, de forma que de acordo com os requisitos do sistema e da demanda da equipe de desenvolvimento. Mas no nosso caso, funcionou também, a entrega de partes do design durante a sprint, antes da sprint terminar. Claro que muitas vezes algumas idéias são reprovadas, e isso pode até afetar a velocidade da sprint, mas isso deve ser revisto cuidadosamente na reunião de revisão. Porém, é algo que pode funcionar muito bem, a sprint do Design fazer vários pequenos entregáveis durante a Sprint, e receber o feedback da Equipe de Desenvolvimento de forma imediata.
Então, o mais importante por fim, e a interação contínua da Equipe de Desenvolvimento e do designer.
Olá Rafael! No nosso caso o design é feito em uma equipe separada da equipe de desenvolvimento de software. Há um projeto específico para o design com sprints próprias. E buscamos sempre andar com os trabalhos do design antecipando o que a equipe de desenvolvimento precisará em sprint futura.
É complicado fazer assim, mas tem fluido. Vez ou outra a equipe de desenvolvimento ao aplicar o design desenvolvido acaba retornando o trabalho para a equipe de design para ajustar algo ou fazer melhorias. Mas aí que entra a agilidade. A equipe de design acaba atendendo essa demanda incluindo o trabalho na sprint em troca de outros.
Resolvemos fazer dessa forma, pois a equipe de design atende mais de um projeto de software e também atende a design de outros materiais para a empresa. Dessa forma se o designer participasse da sprint da equipe de desenvolvimento do projeto acabaríamos caindo na situação que você se encontra hoje.
Se me permite a sugestão, porque você não tenta separar o design do desenvolvimento e fazer as sprints com timebox menor que o timebox das sprints da equipe de desenvolvimento. Assim você pode andar na frente deles, e se der qualquer problema que você tenha que rever seu trabalho você executa na sua sprint seguinte, mas ainda dentro da sprint da equipe de desenvolvimento.
Experimente! Faça a retrospectiva e depois reajuste para o que ficar melhor. O importante é buscar a melhoria do processo sempre! Espero tê-lo ajudado. Qualquer nova dúvida, não deixe de perguntar!
Meu caso é diferente do de vocês. Faço só o design e não implemento. Como o designer fica depois das tarefas concluidas no sprint?
Ou seja, a equipe ainda tem tasks para desenvolver na estoria, e o designer já acabou a parte de design da estoria. Isso tá certo? Como proceder?
Estamos começando com SCRUM agora, e essa é uma das maiores dúvidas na equipe.
Obrigado.
É importantíssimo que a equipe entenda a questão da diversidade profissional. Saber que o profissional poderá ter dificuldade em entender a linguagem técnica da área de desenvolvimento, entre outras coisas… Belíssimo post!!! Parabéns a todos!!! Aqui no trabalho, sou designer e implementador, super estranho, não?!
Sim, corretíssimo Roberto. Nem sempre ( na maioria das vezes eu diria), um designer, por exemplo, vai entender a linguagem técnica dos desenvolvedores. Aqui no trabalho eu não codifico tanto, mas também faço, isso facilita um pouco na hora de trocar idéias com a equipe de desenvolvimento, mas esse ponto que você tocou é completamente relevante, e não pode ser ignorado!!