Olá pessoal! Como vocês sabem já falei muito aqui no blog sobre o ponto de vista do Design dentro de um projeto Scrum, como vocês podem conferir em “Definição de pronto e preparado para histórias de design”, “O designer, o Scrum e o foco na experiência do usuário”, “Design: planejando e construindo” ou “Responsabilidades da Equipe e do Designer em uma Sprint de Design”.
Hoje compartilharei com vocês mais um pouco da minha experiência como designer aqui na empresa. Como somos uma empresa com foco em agilidade utilizamos o framework Scrum para nos ajudar nas organizações dos projetos, mas isso vocês já devem saber. Eu era o único responsável pelo design, seja ele voltado ao front-end de ferramentas web ou voltado a construção de ilustrações, banners, cartazes etc. Compartilharei com vocês nossas dificuldades no início para estimar as histórias, as dificuldades no andamento das histórias, as interrupções inadiáveis, então vamos lá.
Quando você já tem projetos com sprints em andamento, normalmente já existe uma release funcional estável e as alterações tem que ser feitas visando a alterações ou incremento de algo que já funciona e que já deve estar no ar. Minha experiência foi desta forma. A sprint da equipe de desenvolvimento estava em andamento e havia inúmeros pedidos de design pendentes. E é aí que vêm o problema.
No inicio eu não tinha muita noção de como estimar, haviamos tentado fazer as estimativas com o planning poker, mas não dava muito certo pelo fato de eu não ter com quem discutir, era questão de aprendizado, ver quanto uma história demorou em uma sprint, e colocar algo parecido em termos de pontuação na próxima sprint.
Mas depois havia requisições de mais de um projeto. Decidimos então mudar o esquema de estimativas para tamanhos (pequeno, médio e grande). Onde demoraria muito, médio ou pouco para fazer uma história. E deveria haver uma presença forte do Scrum Master fazendo valer o Scrum, mas como havia muitos projetos de vários Product Owners, ficava difícil estimar e priorizar, mesmo sabendo a quantidade de pontos que eu conseguia fazer em uma sprint, justamente por causa dos imprevistos e histórias importantes que deveriam entrar com a sprint já em desenvolvimento.
Hoje em dia temos uma equipe de Design com dois web designers, um Product Owner e um Scrum Master que atende a um projeto em específico. Apesar de ser abaixo do que o Scrum recomenda, tem funcionado muito bem aqui na empresa. Voltamos a estimar utilizando o planning poker, porém agora funciona melhor pois podemos discutir a complexidade das histórias. E hoje sabemos nossa velocidade e ela está sempre condizente com a realidade das histórias nas Sprints, as interrupções não acontecem mais, no sentido que estamos com foco em terminar a Sprint, e o Scrum Master está sempre presente para não deixar nada atrapalhar o andamento das histórias. Meu aprendizado só confirmou o que sabemos. O Scrum é um framework para suporte a projetos onde a chave está na auto organização da equipe, e para tal equipes devem ser formadas, evitando assim aquele famoso “euquipe”.
