Olá pessoal! Aproveitando a deixa do Luiz tomaz sobre os 10 Mandamentos do Agile Tester, irei fazer um post parecido. Mas começo o post me corrigindo. Não são mandamentos como o título nos mostra, eu diria que são 10 filosofias que designers podem seguir para que não aconteçam alguns problema pelo que eu e vários agile designers já passamos. Podem funcionar para o seu negócio, mas podem não funcionar. São pequenas percepções que tive trabalhando por mais de 2 anos como designer em projetos ágeis e também lendo artigos de outros designers em semelhantes situações.

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 (Português) 10 Mandamentos de um Agile Designer appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 Do you know ScrumBut? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

I had already spoken in other posts about the importance of the team as estimating the sprint as on the team’s velocity. But today we will focus on adapting the design to development sprint, since we are going through this here in the company.

We are completely renovating the design of an application, putting new features, completely changing the screens design, changing menus, substituting presentation ways, and for everything is properly implemented, we create a way of working, and I’ll share with you how this experience was.

First of all, since the application had already been running with an old design, my team was responsible for creating the new design and development team initially was not interrupted. We created all the concept art, and then started doing the html, css and javascript that were needed for the visualization and screens behavior.

After a few design sprints, the development of the old application was stopped and the development team began to implement the new screens. We continue the design sprints, but now half of our effort (or slightly less) was to solve the problems that the development team encountered during implementation.

The problem we had because of our two-week sprint. Because of this time box, we could (we should) provide the new changes at the end of two weeks, and because of that, many stories of development were interrupted. So, the solution was reducing the timebox for a week, and every week we gave corrections that the development team needed.

The migration is still occurring, but it worked very well with us, this was my experience, and you? do differently in your business? Share with us!!

The post Integration of design sprint and development sprint appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Hello folks! As you know I've talked a lot here about the point of view of design within a Scrum project, as you can see in "Defining ready and prepared for stories of design", "designer, Scrum and focus on the experience of user "," design: planning and building "or" Team Responsibilities and Designer in a Sprint Design ".

Today I will share with you some of my experience as a designer here in the company. As we are a company focused on agility we use the Scrum framework to help us on projects organization, but that you may know. I was the only one responsible for the design, whether it be directed to the front-end of web tools to build or oriented graphics, banners, posters etc.. I'll share with you our difficulties to estimate the stories, the difficulties in the course of the stories, unavoidable interruptions, so here we go.

When you already have ongoing projects with sprints, usually there is already a stable release and functional changes have to be done in order to change or increment something that already works and it should already be on the air. My experience has been this way. The sprint team development was underway and there were many requests pending design. And that's where the problem comes.

At first I didn't have much idea of ​​how estimate. We had just tried to make estimates with planning poker, but don't work as well because I didn't have argue with anybody, it was a matter of learning to see as a story took on a sprint, and put something in terms of scoring in the next sprint.

But there were requests for more than one project. We decided to change the scheme estimates for sizes (small, medium and large). Where be long, medium or little to make a story. And there should be a strong presence of the Scrum Master to keep the Scrum done, but how many projects had multiple Product Owners, it was difficult to estimate and prioritize, even though the amount of points that I could do in a sprint, precisely because of unforeseen and important stories that should come with the sprint already in development.

Today we have a team of Design with two web designers, a Product Owner and Scrum Master that caters to a specific project. Despite being below the recommended Scrum, has worked very well here in the company. We again estimate using the planning poker, but now works better because we discuss the complexity of the stories. And today we know our speed and that is always consistent with the reality of the stories in the Sprints. Interrupts don't happen anymore, in the sense that we are focusing on finishing the Sprint and Scrum Master is always present to not let anything hinder progress of stories . My learning only confirmed what we know. Scrum is a framework to support projects where the key is in the self-organization of the team, and this team should be formed, thus avoiding individual team.

The post Estimates and the Interface Design on Scrum appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Scrum’s daily work focuses on delivering value to our users. In web design, the focus is on user experience and on how to make tools and websites more intelligent and effective. Recently, I posted an article called “The Designer, the Scrum and Focus on User Experience” in which I talked about the importance of making a user-friendly interface in order to attend the increasingly high standards of users. After the boom of smartphones, tablets, kindles, etc we kept wondering ourselves about how to produce interfaces that support all these platforms and still behave well on PC’s browsers and laptops.

For this, today I will explain what is Responsive Web Design and we’ll analyze if applying it to your business is really necessary.

On “The Dao of Web Design“, John Allsopp stated the following:

“The control which designers know in the print medium, and often desire the web medium, is simply a function of the limitation of the printed page. We should embrace the fact the web doesn’t have the same constraints, and design for this flexibility. But first, we must accept the ebb and flow things.”

In other words, we must be aware of this flood of new platforms and adapt to them. That means: make a responsive web design. A web design that fits on size, content, text, images, and everything else, regardless of platform, be it a kindle, an iPad or an Android. Today’s browsers already provide much of this type of flexibility through refined techniques of CSS 3.0, but that’s a topic for another post.

But, actually, what your company should ask itself is: do we really need a responsive website? To build a responsive website demands working hard and for each one of those platforms, we must allocate a new team, and nowadays we already have Android, iOs, Blackberry, Windows Mobile, Kindle and whatever else is yet still to come.

The comment below was seen on Brad Frost blog:

“Your visitors don’t give a shit if your site is responsive. They don’t care if it’s a separate mobile site. They don’t care if it’s just a plain ol’ desktop site. They do give a shit if they can’t get done what they need to get done. They do give a shit when your site takes 20 seconds to load. They do care when interactions are awkward and broken.”

And that’s the truth. Experience tells us that the user need not to know how the interface is implemented, but if it works well and it’s fluid. If your website was only made ​​for desktop browsers, but it’s fluid, loads text and images fast enough and features are not broken, users don’t care if it is a native application, a CSS hack for mobile browsers or simply a web page made for standard desktops.

So the real question is: does your company needs a Responsive Web Design? Or does the initial focus should be on improving the user experience of your websites?

On future posts we will explain technically how to make a Responsive Web Design using queries and CSS 3.0. Eventually, we’ll explain also the difference between a native application, a Web Page made for Mobile Browsers and a Web page made for PCs only. So, stay tuned and wait for what’s to come 🙂

The post What is Responsive Web Design? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.