Então, começaremos enunciando o primeiro mandamento:

1 – Faça o cliente um membro de sua equipe

Em projetos ágeis sabemos da importância do cliente como membro da equipe para aliar os interesses. Com design não é diferente, faça com que o cliente sinta-se como parte de sua equipe mostre a evolução do seu trabalho. Aproveitando isso, podemos enunciar o segundo mandamento.

2 – Deixe o cliente participar e acompanhar todo o processo de criação

Não espere ter um monte de trabalho pronto para mostrar tudo de uma vez ao seu cliente. Faça isso iterativamente como todo projeto ágil deve ser. Mostre os esboços das ideias, nem que sejam discutidos com papel e caneta. Mas mostre algo.

3 – Crie modelos, faça diagramas.

Logo após a fase de concepção, ao tornar concreto o que o cliente espera que você crie, faça modelos. Crie diagramas que ajudem o cliente enxergar as coisas de forma mais concreta. Eles podem ajudar ao cliente entender a criação das telas do sistema. Podem ajudar a equipe de desenvolvimento a criar uma ordem para a codificação também. Podem ajudar a definir o comportamento do sistema. 

4 – O feedback é seu amigo

Para você ter certeza que as ideias estão alinhadas, tanto do cliente, quando da equipe de programação, quanto do design, procure saber a opinião de todos. Procure saber se todos estão no caminho certo, se os comportamento que você definiu podem ser realmente codificados (não espere ser tarde demais para descobrir que existem problemas arquiteturais que não permitem criar essa ou aquela funcionalidade).

5 – Alinhe pensamentos com a equipe de desenvolvimento. Se beneficie da mentalidade de integração contínua

Não deixe nada para amanhã. Pergunte a equipe de desenvolvimento quais serão os próximos passos do sistema. Esteja sempre integrado a equipe de desenvolvimento. Tente ver suas telas funcionando na aplicação final e veja se o comportamento está do jeito esperado.

6 – Faça testes frequentemente.

Teste as páginas. Em meus dias como agile designer tivemos muito retrabalho porque uma determinada tela não encaixava com determinados dados ou ficava ruim em determinadas resoluções. Se seu sistema não precisa ser responsivo, teste ele em todas as resoluções permitidas. E faça isso antes de mandar o design para a equipe de codificação.

7 – Designers também devem codificar

É ingênuo pensar que mandando uma tela como uma série de imagens, medidas, estilos de fontes e cores, ela ficará idêntica a idealizada pelo designer. Vários artefatos mudarão de lugar, comportamentos deixarão de existir e sem contar que a organização pode mudar. Portanto, codifique suas telas. Faça com que a equipe de codificação não precise fazer muita coisa em relação a interface visual do sistema.

8 – Documente coisas complicadas

Como você codificará a interface visual, talvez possam aparecer comportamentos complicados, e seja necessário muitas linhas de código para fazê-lo. Documente bem essas partes para que a equipe de codificação saiba exatamente o que você fez.

9 – Prove codificando

Nunca assuma que seu design funciona. Prove que funciona codificando. Faça o modelo funcional das suas telas utilizando HTML, CSS e javascripts.

10 – Agile designers não precisam vislumbrar como a aplicação inteira ficará

Em meu tempo de experiência aprendi que não é necessário fazer uma série de artefatos no inicio do projeto. Por exemplo, não é necessário criar todos os botões, todas as janelas, todos os inputs, antes de criar as telas. Verifique com o cliente as demandas mais importantes e conforme forem surgindo estes elementos você os cria e utiliza nas demandas futuras.

The post 10 Mandamentos de um Agile Designer appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Olá a todos! 

Hoje vamos falar sobre um tema muito controverso e, por vezes, muito criticado dentro do Scrum. Vamos falar sobre formas de utilizar o Scrum sem algumas das cerimônias que são preconizadas pelos criados do método. Essa forma de utilização já ganhou até apelido no mundo ágil, o ScrumBut. Neste Agile Brazil, estivemos com o palestrante Alexandre Magno, e ele falou sobre o assunto, então vamos lá.

Vamos começar com uma definição, segundo a revista Engenharia de Software Magazine 50:

“ScrumBut ocorre quando o Scrum expõe uma disfunção ou uma falha difícil de ser corrigida e que leva a empresa a modificar o Scrum com o intuito de tornar invisível o problema”

Normalmente as empresas saem dos métodos tradicionais de engenharia de software e passam a usar o Scrum acreditando nas melhorias e benefícios da agilidade, entrega contínua, adaptação e correção rápida, e todos os preceitos que conhecemos. Mas como podemos descobrir se alguma das cerimônias do Scrum pode estar atrapalhando o pleno funcionamento da organização?

Em primeiro lugar, não podemos retirar algo do Scrum só porque achamos ruim, ou chato, ou demorado. Tudo deve ser medido. Nada que não é medido não pode ser confirmado como problema. Isto é, se você não tem certeza que uma reunião ou outra atrapalha o andamento de um projeto, não ache que retirando essa reunião o andamento do projeto correrá bem. Tudo deve ser medido e devidamento documentado.

Uma ideia, que já foi aplicada aqui na empresa, foi levantar uma hipótese e testá-la. Em um dos projetos aqui, a hipótese levantada foi de que o planning 2 tradicional não tinha efeito prático no andamento das histórias. No caso do projeto em questão, a equipe estava trabalhando em histórias distintas, que é outro ponto que diferencia do Scrum tradicional, e as histórias não tinham uma especificação clara. Por isso, eles precisavam especificar as histórias ao decorrer da Sprint. Resumindo, eles estavam fazendo o planning 2, mas eles faziam durante a Sprint. Depois disso tudo, eles puderam verificar uma melhoria nas entregas.

Eles conseguiram identificar um problema, uma “falha” no Scrum, embora eu ache o termo falha muito forte. Com isso, podemos ver que o Scrum aceita mudanças. O Scrum é um framework e adaptação é seu lema. Então porque não podemos adaptar o framework? Mas é claro que isso deve ser feito com cautela.

A comunidade scrum.org descreve uma sintaxe particular para o ScrumBut, da forma:

(ScrumBut)(Razão)(Solução)

Vamos verificar como isso funcionaria no caso citado acima:

“(Nós usamos Scrum, mas)(não precisamos nos reunir no inicio da Sprint para fazer o Planning 2)(pois fazer ao decorrer da Sprint foi mais vantajoso e prático)”

Outros casos válidos, já testados aqui foram:

“(Nós usamos Scrum, mas)(histórias de design nem sempre são bem definidas)(então algumas histórias não precisam de definição de pronto)”

Mas é claro que, casos como esses devem ser evitados:

“(Nós usamos Scrum, mas)(não fazemos reunião diária)(porque é chato e parece ser perda de tempo)”

“(Nós usamos Scrum, mas)(retrospectiva são perda tempo)(então não fazemos)”

Claro que devemos estudar cada caso cuidadosamente. O que funciona aqui na empresa, pode não funcionar na sua empresa e assim por diante.

E você na sua empresa? Faz algo um pouco diferente do Scrum? Compartilhe com a gente como foi sua experiência.

The post Você conhece o ScrumBut? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Falarei um pouco das dificuldades em se ter uma equipe de design que provê recursos para outra equipe, a equipe de desenvolvimento da aplicação. Então vamos lá.

Eu já havia falado em outros posts sobre a importância do time nas sprints tanto nas estimativas quanto na velocidade da equipe. Mas hoje vamos focar na integração das sprints da equipe de design com as sprints da equipe de desenvolvimento da aplicação, aproveitando que estamos passando por isso atualmente.

Estamos reformando completamente o design de uma aplicação, colocando novas features, mudando totalmente a arte das telas, mudando os menus, substituindo formas de apresentação, e etc. Para que tudo seja devidamente implementado, minimizando os desperdícios, criamos uma forma de se trabalhar que vou compartilhar com vocês como tem sido essa experiência.

Em primeiro lugar, como tínhamos a aplicação já funcionando com o design antigo, a equipe da qual faço parte ficou responsável por criar o novo design enquanto a equipe de desenvolvimento da aplicação não foi interrompida e deu continuidade no trabalho de melhoria a aplicação. Assim, criamos toda a arte conceitual, e depois começamos a fazer os htmls, css e javascripts que eram necessários para a visualização e comportamento das telas.

Após algumas sprints da equipe de design, o desenvolvimento da aplicação antiga foi interrompido e a equipe de desenvolvimento da aplicação começou a trabalhar na aplicação das novas telas. Continuamos as novas sprints de design, mas agora metade do nosso esforço (ou um pouco menos) é destinado a solucionar problemas de integração que a equipe de desenvolvimento encontra durante a aplicação do novo design.

Um problema que tivemos foi por causa da nossa sprint ser de duas semanas. Por conta deste timebox, só podíamos fornecer as novas modificações ao fim de duas semanas, e por conta disso, muitas histórias de desenvolvimento não ficam prontas ao final da sprint deles. Então, reduzimos o timebox para uma semana, e toda semana conseguimos fornecer as correções solicitadas pela equipe de desenvolvimento da aplicação, necessárias para que as histórias fiquem prontas ao final da sprint deles.

A migração ainda está ocorrendo, mas tem funcionado muito bem conosco.

Essa foi minha experiência, e você, faz diferente na sua empresa? Compartilhe conosco!

The post Integração da sprint de design e de desenvolvimento appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

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”.

The post Estimativas e o Scrum no Design appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Quando lidamos dia a dia com Scrum, estamos sempre focados em entregar valor ao usuário. No design, o foco está na experiência do usuário e de como fazer websites e ferramentas se comportarem de maneira mais inteligente e eficaz. Eu mesmo falei recentemente em “O Designer, o Scrum e o Foco na Experiência do Usuário” da importância de o designer fazer uma interface user-friendly para atender os padrões cada vez mais elevados dos usuários. Depois do boom dos smartphones, tablets, kindles, etc ficamos nos perguntando sobre como fazer interfaces que atendam a todas essas plataformas e ainda sim se comportem bem em um browser de Desktops ou Laptops.

Então no post de hoje vou explicar a vocês o que é Web Design Responsivo, ou Responsive Web Design, e vamos analisar a real necessidade de aplicar isso na sua empresa.

John Allsopp publicou em “A Dao of Web Design” o seguinte texto:

“O controle que os designers conhecem no meio impresso, e muitas vezes desejam para a web, é simplesmente uma função de limitação da página impressa. Devemos aceitar o fato de que a web não tem as mesmas limitações e produzir designs que atendam a essa flexibilidade. Mas primeiro, temos de aceitar o fluir das coisas.”

Ou seja, temos que estar atentos à essa inundação de novas plataformas e nos adaptar a elas. E isso é fazer um design responsivo. Fazer um Website que se adeque em tamanho, conteúdo, textos, imagens, e tudo mais, independente da plataforma, seja ela um Kindle, um Ipad ou um Android. Os browsers de hoje em dia fornecem muito deste tipo de flexibilidade através de técnicas refinadas de CSS 3.0, mas isso é assunto para outro post.

Mas, na verdade, o que sua empresa deve se perguntar é se ela tem realmente necessidade de um site responsivo. Fazer um website responsivo demanda muito trabalho, e para cada uma das plataformas móveis existentes hoje, devemos alocar uma nova equipe, e hoje em dia já temos Android, IOS, Blackberry, Windows mobile, Kindle e  o que mais estiver por vir. 

Este comentário foi retirado do blog Brad Frost:

“Seus visitantes não dão a mínima se o seu site é responsivo. Eles não se importam se é um website exclusivo para plataforma móveis. Eles não se importam se é apenas um simples website feito somente para desktop. Eles se importam se é possível fazer o que precisa ser feito. Eles dão importância quando o site leva 20 segundos para carregar. Eles se importam quando o acesso é difícil ou cai o tempo inteiro.”

E essa é a verdade. A experiência nos diz que o usuário não precisa saber como foi implementada a interface e sim se ela funciona bem e é fluida. Se o seu site foi somente feito para browsers desktops, mas  é fluido, carrega rápido os textos e imagens e as funcionalidades não ficam quebradas, o usuário não se importará se é um aplicativo nativo, um hack CSS para browser móvel ou simplesmente uma página web normal feita para Desktops.

Então a pergunta é: sua empresa precisa de design responsivo? Ou o foco inicial deve estar em melhorar a experiência do usuário?

Em futuras publicações explicarei, em um post mais técnico, sobre como fazer um design responsivo utilizando queries e CSS 3.0. Futuramente tambémexplicarei a diferença entre uma aplicação nativa, uma página web feita pra browser móvel  e uma página web feita para desktop. Por isso, fiquem ligados e aguardem os próximos posts 🙂

The post O que é Web Design Responsivo? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.