Captcha Generator with SixLabors’ libs on .NET Core 3

Well, if you are reading this article I could guess that you tried to search how to generate captcha images to use in your own .NET Core application because:

1. You aren’t able to use System.Drawing because you want it to run on any Linux-based system;
2. You don’t wanna use any online-based-third-party service to generate it for you (I’m sorry, reCAPTCHA);
3. You like to learn new things (and that’s a really good reason on itself).

If you have any of the reasons above, or any other else, you are welcome here!

By the way, if you don’t know what a captcha is, don’t feel intimidated by it.

A Captcha, in a brief explanation, is a way of preventing your system to be accessed by bots. It may asks the user to click and wait for a while, to click in certain images, to type some alphanumeric characters, etc.

In this article, our Captcha will be an image drawn in a rectangular shape, some multicolored characters on it, and some lines and dots to difficult reading.

So let’s start our mission!

What we’ll be doing here:

1. Creating a bitmap
2. Filling a bitmap
3. Writing a char
4. Writing a text char by char
5. Rotating the text
6. Adding dirt

Mostly, we’ll be using SixLabors’ libraries for our drawing operations because it’s 100% manageable, its code is portable, open source, it has a fluent interface, and its quite easy to learn how to use it. I guess we have plenty of reasons already!

Creating a bitmap

To start our adventure, we need to create a bitmap in which we can work on. We may create an Image variable like any other else: (Use this one if you want your method to return this Image variable.)

var img = new Image<Rgba32>(width, height);

Or within an using statement: (You won’t be able to use this var as a return variable, as it’ll be disposed after the using statement)

using (var img = new Image<Rgba32>(width, height))
{
  
}

Note that when not defining the Image variable within an using statement, it’s a good practice to .Dispose() it after working on it.

Rgba32 corresponds to a Pixel Format and may be substituted by any other Pixel Format of your choice.

So now that we have a bitmap to work on, what can we do to actually start drawing?

Filling the bitmap

backColor = Color.White;
img.Mutate(ctx => ctx.BackgroundColor(backColor));

The way we define colors here is the same way it is used in System.Drawing. As we need a white color, Color.White is the one we’ll be working with.

.Mutate() is an important method in this article, it will be used for almost everything we want to do with the image itself. Note that, when we mutate the image, we apply an action on it overwriting the “old” bitmap with the new actions. In this case we are only defining a background color.

You may also define a color as:

new Color(new Argb32(0.0f, 0.0f, 1.0f))

In this case, the three (shown) parameters are related to Red, Green and Blue color quantities, going from 0 to 1. There’s also another (optional) parameter for Alpha, which controls the transparency/opacity of the color.

(By the way, I’ll be showing our results step by step surrounded by a black line just for visualization matters, as the background is also white.)

Writing a char

var font = SystemFonts.CreateFont("Arial", 10, FontStyle.Regular);
var location = new PointF(x, y);

img.Mutate(ctx => ctx.DrawText(c.ToString(),font, Color.Black, location));

When writing some text in a bitmap, you’re going to use DrawText() in Mutate(), which parameters are:

• text: a string parameter, in this case I converted a char to a string;
• font: a Font parameter, its value is defined using SystemFonts.CreateFont(<fontName as String>,<size as int>,<fontStyle as a FontStyle enum value>);
• color: a Color variable, as explained above;
• location: a PointF variable, requiring x and y float values to determine the start location of the drawing.

Of course you can write a full text with this method, but here we want to write char by char, modifying their location, color and font.

And how to write a string text?

Well, if you want to write char by char like me, you’ll have to use a loop statement (yay!). So let’s start showing a more complete code:

using (var img = new Image<Rgba32>(width, height))
{
   var fontFamilies = new string[] { "Arial", "Verdana", "Times New Roman" };
   Random random = new Random();

   img.Mutate(ctx => ctx.BackgroundColor(backColor));

   foreach(char c in stringText)
   {
      var font = SystemFonts.CreateFont(fontFamilies[random.Next(0,fontFamilies.Length)], 20, FontStyle.Regular);
      var location = new PointF(x+position, y);

      img.Mutate(ctx => ctx.DrawText(c.ToString(), font, new Color(new Argb32(0.0f, 0.0f, 1.0f)), location));

      position = position + TextMeasurer.Measure(c.ToString(), new RendererOptions(font, location)).Width;
   }
}

…Okay, we have a lot of stuff here, so let’s take a look at the new ones now:

• fontFamilies: I created a array of font names so, at the time we’ll be defining the font of each character, I could use a random one;
• position: We don’t want our characters all overdrawn on each other, so we start to manage their position. That’s a quite an easy job when we use TextMeasurer.Measure(). All you need to measure it is the text itself (the character, in this case) and a RendererOption(), that requires a font and a start location.

Given that we have our text drawn, we want to rotate it, adding an extra dificulty when reading the Captcha.

We now have a full text! But is its position ideal? Well, I’m not going to focus on calculus here because you are the one to decide where to position the text. Take this as a challenge!

Rotating the text

When rotating a bitmap, you may use:

var builder = new AffineTransformBuilder();
img.Mutate(ctx => ctx.Transform(builder.PrependRotationDegrees(angle, new PointF(rotateX, rotateY))));

Here we use a .Transform() method, which requires an AffineTransformationBuilder(). In this case, as we want to rotate the image, we use .PrependRotationDegrees().

When you add a rotation operation, you have to specify its angle and the point where the rotation is applied.

So, let’s just add the rotation operation at the end of our algorithm:

using (var img = new Image<Rgba32>(width, height))
{
   ...

   foreach(char c in s)
   {
      ...
   }

   var builder = new AffineTransformBuilder();
   img.Mutate(ctx => ctx.Transform(builder.PrependRotationDegrees(angle, new PointF(rotateX, rotateY))));

}

With width = 200px and height 30px, I got:

…but actually I don’t want the size of my image changing accordingly to the rotation applied.

What just happened? Let’s make a review about what we did so far:

1. Instantiated a bitmap
2. Added a background color to it
3. Wrote some text on it
4. Rotated it

The problem is: when we rotate an image, it won’t be bound to the limits we defined before, with width and height. But we don’t actually want the whole image to rotate, only the text.

So what if we create a separate bitmap to it and, after applying the rotation operation, we draw it into another image?

var img = new Image<Rgba32>(width, height);

img.Mutate(ctx => ctx.BackgroundColor(backColor));

using (var imgText = new Image<Rgba32>(width, height))
{
   ...

   foreach(char c in stringText)
   {
      ...
   }

   var builder = new AffineTransformBuilder();
   imgText.Mutate(ctx =>  ctx.Transform(builder.PrependRotationDegrees(angle, new PointF(rotateX, rotateY))));

   img.Mutate(ctx => ctx.DrawImage(imgText, transparency));

}

return img;

So now we have an bitmap for the captcha itself and another bitmap for our text. The text is applied in our final image with the .DrawImage() method, in which you may also specify a transparency.

Note that I’m not defining our final bitmap in an using clause, because I want it to be our return value to another piece of code somewhere else.

Okay! We are starting to get things ready, but what can we do more?

Adding dirt

So now that we have our text placed, why don’t we add some stuff to make it more difficult to read?

You may add some lines:

img.Mutate(ctx => ctx.DrawLines(color, thickness, new PointF[] { new PointF(x1, y1), new PointF(x2, y2)}));

The color? Your choice. The thickness? A float of your choice. You may even specify the points (x1,y1) and (x2,y2) which define the line itself. You may add them above your text, or below it, or both, why not?

You may also add some dots:

img.Mutate(ctx => ctx.DrawLines(color, thickness, new PointF[] { new PointF(x1, y1), new PointF(x1, y1)}));

In this case I reused .DrawLines() but both the point parameters are the same.

And then I got:

And what more can I do?

I actually played a little bit with characters positions, and got something like this one:

And, well, it’s up to your imagination! You may draw curves, multicolored lines, colorful background, etc.

I recommend exploring SixLabors’ documentation (https://docs.sixlabors.com/) and also their github ( https://github.com/SixLabors) for some samples.

I hope this guide was useful to you! Keep up the good work!

Captcha Generator with SixLabors’ libs on .NET Core 3 was originally published in Agile Content Teamwork on Medium, where people are continuing the conversation by highlighting and responding to this story.

Um fato difícil de aceitar é que adotar um Framework ágil não resolve todos problemas de entrega, qualidade e gerenciamento dos departamentos de TI.

Os processos, habilidades e conhecimento são importantes, mas o que realmente pode transformar, um time, um departamento, ou mesmo uma empresa são as atitudes (Intenções) e comportamentos (Ações) das pessoas que trabalham nelas.

As pessoas precisam ser preparadas para participar de projetos ágeis: ensinadas a serem auto-organizadas, terem respeito e autoridade para decidir como trabalhar e a atuar como time para alcançar uma inteligência coletiva.

“As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.” Manifesto ágil, princípio 11

O desenvolvimento de software é uma atividade humana e a qualidade da interação entre as pessoas pode resolver problemas crônicos de comunicação. O que deve acontecer é colaboração, tomada de decisões em conjunto e trabalho em equipe, fazendo que todos trabalhem juntos em busca de um objetivo.

“Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.” Manifesto ágil, princípio 5

A força propulsora da mudança de comportamento das pessoas está no exercício dos valores descritos nas entrelinhas do Manifesto ágil, tais como: coragem, foco, comprometimento, respeito , abertura. Em intervalos regulares, as pessoas do time devem refletir em como ficar mais efetivo, ajustando e otimizando seu comportamento .

Para crescer nestes valores, podemos analisar e discutir com as pessoas do time, situações como as abaixo, coletadas no dia a dia:

Agimos com coragem quando: admitimos que requisitos nunca serão completos; acreditamos que nenhum plano pode desenhar a realidade e complexidade; a mudança é fonte de inspiração de inovação; não entregamos o que não está pronto; discordamos de uma ideia que o grupo resolveu seguir; compartilhamos riscos, benefícios e toda a informação possível que possa ajudar as pessoas e a empresa.

Mostramos foco quando: não desenvolvemos funcionalidades que ninguém solicitou; fazemos o que é mais importante agora, não fazemos o que talvez um dia possa ser importante; fazemos nosso trabalho da maneira mais simples e objetiva possível.

Atuamos com comprometimento quando: fazemos o melhor todos os dias; apoiamos o time, somos colaborativos, somos preocupados com a qualidade; valorizamos o aprendizado; buscamos a melhoria contínua e a excelência técnica.

Demonstramos respeito quando: demonstramos consideração pelas pessoas, suas experiências profissionais, habilidades, experiências pessoais e diferenças; não desperdiçamos dinheiro e tempo em funcionalidades que não serão usadas; corrigimos rapidamente os erros; seguimos os acordos do time e as regras da empresa.

Temos abertura quando: somos abertos sobre nosso trabalho, nosso progresso, nossa aprendizagem e para as outras pessoas; colaboramos com o ambiente em geral, todos os negócios e competências; compartilhamos feedback e aprendemos uns com os outros.

Na busca de melhoria contínua, temos uma ótima ferramenta, nosso rito de avaliação, as retrospectivas com o time. Nela podemos incentivar o diálogo para crescer nestes valores, utilizando os exemplos do que se passou nos últimos dias de trabalho.

Gosto de usar três perguntas rotineiras: O que foi bom? O que foi ruim? Qual o plano de ação? Entre as várias oportunidades de aprendizado que acontecem nestas reflexões: o que foi bom ajuda a motivar o time, o que foi ruim exercita a confiança, o respeito, abertura uns com os outros e o plano de ação nos leva às mudanças necessárias.

Os líderes devem reforçar uma cultura de aprendizagem organizacional e experimentação para criar resiliência no time, autoconfiança para assumir riscos, aprender com o sucesso e ou com o fracasso.

Cultura ágil : Capacitar, Motivar e Confiar sempre !

Cultura ágil, mudança de valores e mindset was originally published in Agile Content Teamwork on Medium, where people are continuing the conversation by highlighting and responding to this story.

A qualidade de um software não é responsabilidade exclusiva da equipe de QA de um projeto. É mais do que certo que desenvolvedores devem sim testar o próprio código. Mas quantos testes são necessários? Meus testes foram eficientes na busca por falhas? A cobertura de testes deve ser suficiente em testes unitários, de integração, de aceitação, em desenvolvimento em TDD, etc… Portanto, garantir a cobertura de testes em um sistema não é uma preocupação apenas de QA e sim de todos os envolvidos em desenvolvimento de software .

Iniciar na área de QA (Quality Assurance) em uma empresa de desenvolvimento de software pode não ser uma das tarefas mais simples. Nesta área estão em jogo a satisfação do cliente, imagem da empresa perante o mercado e a sua credibilidade. Grandes desafios técnicos e de relacionamento interpessoal serão recorrentes ao profissional que nem sempre é preparado para esta função na universidade (me arrisco a dizer que em toda a vida acadêmica). Um dos maiores desafios técnicos enfrentados está relacionado à cobertura de testes.

Em minha experiencia de 2 anos como Analista de Qualidade percebo que uma das grandes dificuldades é entender como explorar a aplicação (os seus módulos) de maneira a detectar o maior número de falhas relevantes possíveis antes da entrega do produto ao cliente, ou seja, como obter uma boa cobertura de testes a fim de garantir a Alta Qualidade (confiabilidade e corretude) do produto. Por isso decidi expor neste artigo o método o qual utilizo hoje que me ajudou a aumentar a minha cobertura de testes. Talvez isso também possa ajudar vocês. =)

Um analista de Qualidade tem a função não só de encontrar falhas no sistema para sanar as necessidades do cliente, mas também de alertar sobre problemas nos fluxos de desenvolvimento, criar uma consciência dos desenvolvedores em testar seu próprio código, criar um conhecimento aprofundado sobre o projeto e disseminar o conhecimento, entre outras funções.

Na busca por falhas, serão testados todos os requisitos do sistema, sejam eles funcionais e não funcionais. Para aumentarmos a cobertura de testes de uma funcionalidade, podemos traçar estratégias de testes baseados em Limites (vazio, zero, inválido, extremos de array, comprimento e tamanho de variáveis), CRUD (Criar, Ler, Atualizar, Deletar), Variações de configuração e Interrupções.

Após uma análise aprofundada da funcionalidade, os testes de fluxo partem da identificação das funções do software, para assim, verificar se elas funcionam como devem (PRESSMAN, 2005). O entendimento dessas funções se dá através das especificações de requisitos do sistema, portanto é essencial que os requisitos estejam bem definidos, sem ambiguidades ou incompletos, evitando testes mal elaborados. É neste tipo de teste que a cobertura passa a ser mais complexa pois é um processo humano, exige criatividade e visão do negócio, não é um processo mecânico e repetitivo.

A BSTQB emite certificações para analista de qualidade em vários níveis. A CTFL é uma das suas certificações básicas quanto a teste e nela delimita-se que “a qualidade dos testes depende da capacidade dos testadores em fazer perguntas pertinentes sobre o que testar”, perguntas como:

• O que é mais importante para saber sobre o sistema?

• De que forma o sistema pode falhar?

• O que acontece se?

• O que deve acontecer quando?

• As necessidades dos clientes, requisitos e expectativas são cumpridas?

Método de teste baseado no Caminho feliz

Visando facilitar a visão para aumentar a cobertura de testes tracei um plano, o qual baseia-se no caminho feliz de uma funcionalidade. Esse método aprendi e desenvolvi com a vivência e que pode funcionar para pessoas novas na área.

1. Criar o teste do caminho feliz, geralmente o motivo para que aquela funcionalidade está sendo desenvolvida. Esse teste vai ser o que chamaremos de “Fluxo Básico”, tende a ser o principal teste da funcionalidade, aquele caso que motivou o desenvolvimento da funcionalidade.

O teste deve conter todas as informações bem detalhadas como: título, procedimento de execução, objetivo, resultado esperado, pré-requisitos, variação de entrada.

2. A partir desse teste do fluxo Básico bem definido podemos buscar por testes derivados dele, o que chamaremos de “Fluxos Alternativos”. É aqui que entram as perguntas pertinentes, mostradas anteriormente, que o testador deve criar o hábito de fazer. Deve-se avaliar cada pré-requisito, cada passo do teste a fim de encontrar possíveis desvios de fluxo, erros (esperado pelo sistema) e falhas (bugs).

3. Todo Fluxo Alternativo pode gerar novas possibilidades, ou seja, deve ser entendido como um novo Fluxo Básico para buscarmos mais testes derivados dele que possam encontrar erros e falhas.

4. Escolher quais testes devem de fato ser executados como testes planejados e quais casos serão abordados como testes exploratórios.

Pelo diagrama acima podemos exemplificar como seria. Começo pelo entendimento completo da funcionalidade e crio o teste “Fluxo Básico” que é o caminho feliz da funcionalidade. A partir desse primeiro teste, eu começo a analisar cada passo e pré-requisito em busca de fluxos alternativos, seja para encontrar uma falha ou um erro. Pense que em cada pré-requisito e em cada passo pode haver um fluxo alternativo e que esse fluxo alternativo pode originar novos fluxos alternativos.

Para tornar mais factível vamos a um exemplo baseando-se no diagrama acima e na seguinte funcionalidade: Login que pode ser feito pelo e-mail.

Fluxo Básico = Fazer login com o usuário através do e-mail e senha.

Fluxo Alternativo 1 = Tentar fazer login com o serviço de login fora do ar.

Fluxo Alternativo 2 = Fazer login com e-mail do google que não exige o domínio do e-mail (‘@gmail.com’), possui autocomplete.

Fluxo Alternativo 3 = Tentar fazer login com e-mail google não cadastrado. (Derivado de um fluxo alternativo)

Fluxo Alternativo 4 = tentar fazer login Através do e-mail com senha inválida.

• Vale lembrar que muitos outros casos poderiam ser criados, esse é apenas um exemplo prático.

Esse método de criação de testes pode aumentar a sua cobertura através da mecanização do raciocínio, mas vai depender muito do seu entendimento sobre a funcionalidade, afinal, criar um fluxo básico equivocado levará a testes mal elaborados. Essa é apenas uma maneira de pensar na hora de criar cenários de testes, existem várias outras e não existe a certa e a errada e sim a que você mais se adequa. Devemos manter em mente que a análise da funcionalidade que originará o fluxo básico, portanto, deve-se garantir que a especificação não contenha furos e ambiguidades. O testador deve combinar a criatividade, a intuição, a cognição e a habilidade para buscar possíveis problemas no sistema; uma forma de sistematizar isso é através do método exposto. Explore suas aplicações em busca de falhas e garanta a qualidade do seu trabalho. =p

Referências:

https://medium.com/cwi-software/dicas-para-escrita-de-casos-de-teste-ccea14a7fdd9

PRESSMAN, R. Software Engineering: a practitioner’s approach. Palgrave Macmillan, 2005

Syllabus CTFL Certification (Agile Testers). https://www.bstqb.org.br/node/198

https://gaea.com.br/afinal-o-que-e-quality-assurance/

Cobertura de Teste was originally published in Agile Content Teamwork on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design e negócios

O design se uniu aos negócios, mas ainda deve ser centrado no que realmente importa, pessoas.

A área de design tem evoluído gradativamente, o que antes era chamado de arte, agora está mais e mais atrelado aos negócios e a estratégia de um produto ou serviço. Uma tela bonitinha, não resolve os problemas reais de seus usuários é preciso entender a cultura, pensar em como alinhar os objetivos e perspectivas de negócios de um produto a tudo isso, muito antes de desenvolver um projeto e escolher tecnologias.

Design e negócios são atividades distintas, mas hoje em dia, as tomadas de decisões de design estão intimamente atreladas ao negócio e a cada dia que passa elas ficam mais próximas uma da outra. Para resolver grandes, médios ou pequenos problemas, o designer hoje precisa olhar para vários pontos antes de tomar uma decisão.

Problemas, problemas e mais problemas

Em qualquer serviço, produto ou ideia, sempre terão dificuldades e problemas a serem resolvidos, mas acredito que a maior dificuldade do trabalho de um designer e sua equipe hoje, é descobrir o verdadeiro problema. Aquele que iniciou todo o caos e falta de leads. Um trabalho árduo que pode facilmente passar despercebido e trazer muita perda de tempo e de dinheiro se resolvermos somente um sintoma.

Design thinking

O design thinking pode ajudar a entender e a encontrar o verdadeiro problema e pergunta a ser feita. Suas ferramentas, podem nos ajudar a ver além e a enxergar mais longe, também nos força a deixar o fone de ouvido na mesa do computador e a envolver mais as pessoas a trabalharem juntas. O compartilhamento de idéias com pessoas de várias áreas é a melhor forma de um trabalho centrado nas pessoas e para pessoas.

Essa metodologia nos ajuda a pensar de um novo jeito, no porquê antes do como, a entender o que realmente deve ser feito e principalmente para quem. Entender o quem, sua cultura, suas ideias, sua rotina, tudo isso influencia e traz uma gama de informações muito rica e mais correta aos design thinkers do projeto.

Com esse compartilhamento de ideias, pontos de vista diferentes, as pessoas podem "sair de suas bolhas" e visualizar o problema de forma mais ampla que de uma única visão.

Empatizar

A empatia é uma das fases mais importantes do processo, pois aqui além de entender as dores das pessoas envolvidas em um problema, é necessário se "tornar parte" daquela dor, pois assim fica mais fácil visualizar as possíveis hipóteses e ideias de soluções para aqueles problemas.

Definir

Depois de mapeado as dores, agora é hora de usar essas informações e fazer a pergunta problema que deve ser resolvida, é importante citarmos que, essa pergunta deve ser feita em cima do real problema, para que o trabalho seja feito a partir desse real problema e não de um sintoma do problema.

Idear

Nesta fase é hora de fazer um brainstorm com o time e usar as informações das últimas etapas para gerar hipóteses e soluções para a pergunta problema.

Prototipar

Depois de ter encontrado possíveis soluções para a pergunta problema juntamente com o time, é necessário colocar isso de uma forma mais visual para que todos os stakeholders ( pessoas envolvidas no projeto ) entendam as ideias funcionando de acordo. Nesta fase também já é possível uma conversa mais técnica com os desenvolvedores para validar a ideia de possíveis features.

Testar

O estágio final é o teste do protótipo. É disponibilizar a ideia/protótipo para quem realmente irá usar o produto e através disso reunir informações centradas ao usuário, assim, o time consegue avaliar se aquela ideia foi realmente uma boa ou uma má ideia para aquele produto. A fase de testes é muito importante, pois é aqui que o time realmente consegue "validar" se tudo o que foi feito faz sentido para o usuário final.

Conclusão

O processo de design thinking é realmente uma abordagem humana e compartilhada, muito eficaz para a resolução de grandes problemas, porém, tudo depende do momento do produto/time/serviço. É algo que deve ser feito levando em conta a real e atual necessidade do projeto.

Com todas essas ferramentas e perguntas na mesa, o trabalho de design, deveria começar muito antes de se projetar ou desenvolver qualquer tela, o entendimento da cultura, rotina e necessidades de quem vai usar o produto ou serviço é o bem mais importante do projeto. A união desse entendimento, juntamente com a união de decisões tomadas com os objetivos de negocio e os frameworks de design thinking tendem a produzir um produto muito mais centrado, útil e adequado as pessoas.

Referências:

Tim Brown | TED 2009 — http://goo.gl/R9WvnL

Design, The New Business — https://vimeo.com/33531612

Peter Drucker - “The important and difficult job is never to find the right answers, it is to find the right question ”

Entender para projetar was originally published in Agile Content Teamwork on Medium, where people are continuing the conversation by highlighting and responding to this story.

Já se deram conta em como jogos conseguem nos engajar por horas? Em como eles podem nos influenciar e nos tornar pessoas melhores?

Quando falamos de gamification, estamos visando elevar o engajamento das pessoas dentro de um jogo, envolvendo a todos, estabelecendo prêmios, disputas, conquistas, desafios e elevando a motivação.

Considerando que o inconsciente humano possui uma predisposição em se empenhar mais em jogos, a busca por competição é algo natural e a maioria das pessoas se sente extremamente realizada de poder se afirmar como a melhor ou mais poderosa em alguma coisa. E o melhor é que nos games essa competitividade rende prêmios, reconhecimento e itens valiosos que você sabe que estarão disponíveis e que vão facilitar sua caminhada durante o jogo.

Quando falamos de gamification e gestão, estamos falando de explorar uma dinâmica que ao deixar algo mais divertido, mais engajador e mais envolvente, aumenta as chances dos envolvidos fazerem algo que normalmente eles não fariam ou que apresentariam maiores resistências para fazer.

Gamification é capaz de despertar reações e manifestações naturais em colaboradores. Características tais como: socialização, aprendizado, competição, colaboração, autorrealização, altruísmo, entre outras que para muitos se resumem em valores próprios ou até mesmos da empresa em que atuam.

Abordando um pouco melhor o conceito de gamification, onde uma das definições que eu mais aprecio é da Priscilla Albuquerque, ela define gamification como:

“ Mecânica dos jogos aplicada a ambientes que não são games, para tornar experiências “chatas” em interessante.”

Note que quando falamos em jogos, disputas ou competição, a palavra engajamento sempre é bem latente, mas por que jogos engajam? Segundo à especialista Jane McGonigal:

Jogos nos fazem felizes pois são como um trabalho duro que escolhemos fazer e poucas coisas nos fazem mais felizes do que um bom trabalho duro.

Gamification atua diretamente na motivação das pessoas e para tanto é importante ressaltar algumas teorias da psicologia sobre o assunto que são sustentadas em três principais pilares:

Autonomia
As pessoas no geral ficam motivadas quando estão no controle. Quando sentem que são os donos do jogo elas tendem a manter seus objetivos por mais tempo.

Propósito
Acreditar que uma determinada causa é importante.

Maestria
Quanto melhor você fica em determinada coisa mais provável que você continue a fazê-la. Ao mesmo tempo, quando você sabe que algo é mais difícil de alcançar há uma tendência de tentar por mais tempo.

Diga-se de passagem, a grande maioria dos jogos tradicionais, de tabuleiro ou cartas, ou mesmo videogames, possuem traços que reproduzem as relações humanas, o cotidiano, nossos problemas, uniões e conflitos. O jogo é percebido pelas pessoas, ainda que inconscientemente, como um resumo da própria natureza humana. Por essa razão, gamification ganhou e ganha espaço em empresas, escolas, grupos, comunidades e até mesmo entre governos. Ignorar esse poder quando nossa função é, sobretudo, gerenciar pessoas, seria um enorme equívoco.

E o que promove?

• Feedback rápido
  O feedback é instantâneo em jogos, muitas vezes durante sua própria realização. O jogador, nesse caso o colaborador, tem uma boa ideia de como está se saindo durante todo o tempo, ao contrário de métodos de gestão tradicionais e relatórios gerenciais em que apenas vemos o resultado ao final do processo.
• Transparência
  Qualquer um pode protestar caso sinta que outros jogadores romperam o acordo inicial, ou pode lançar mão das regras para se proteger, ou até obter vantagem — tudo de modo direto e claro.
• Metas
  Como dissemos, todo jogo possui metas claras.
  Situações imprevisíveis, que não permitem que a pessoa saiba o que pode acontecer, fazem com que os pensamentos se voltem a ela o tempo todo. Isso a impulsiona a finalizar tarefas para descobrir como tudo acaba.
• Níveis
  Acalma os ânimos, provendo motivação e criando uma sensação de realização antes mesmo do final do processo.
• Participação
  Ninguém é colocado de lado e, em tese e segundo as regras, todos podem atingir as metas e evoluir.
• Competição
  Os jogos exaltam a competição e a concorrência, porém de modo controlado e saudável. Sujeitos às mesmas regras e chances, os participantes podem concorrer entre si sob os olhos de um juiz ou alguém que zele pelas condições igualitárias de cada um, prevenindo discussões e desentendimentos que são comuns em situações onde haja competitividade.
• Colaboração
  Gamification também promove a colaboração. Gerando um alto nível de empatia, onde pares e grupos de alta produtividade são criados, fortalecendo o laço de confiança e ampliando o relacionamento entre equipes.
• Motivação
  As pessoas se sentem motivadas e realizadas quando percebem que estão progredindo, melhorando, crescendo, alcançando níveis mais altos a cada etapa concluída. Ou seja, passando de fase.

Aqui temos dois exemplos de empresas que aplicam gamification buscando o crescimento da usabilidade de seus produtos.

Linkedin — Sales SSI

Quem aguenta olhar essa barrinha sem preencher melhor as informações de cadastro, atualizar uma foto, melhorar a descrição, simplesmente para aumentar o nível ou status?

Waze

Para quem dirige, quem nunca, mesmo dirigindo reportou algum alerta no waze para aumentar a pontuação ou liberar algum personagem?

Esses são apenas dois exemplos de como gamification pode influenciar e engajar pessoas. Porém vale ressaltar que como qualquer outro método, metodologia ou processo, gamification não é uma bala de prata.

É algo complexo, envolve marketing, psicologia, diversas áreas
é uma boa tática a curto prazo. O insucesso pode ser fatal, com fórmulas prontas e jogos batidos, às vezes até mesmo infantis, além de disputas que geram mais estresse do que sensação de recompensa, gestores perdem seus funcionários e transformam o que deveria ser uma experiência inteligente e empolgante em algo não apenas maçante, mas também em outra tarefa aborrecida e sem foco.

O verdadeiro engajamento apenas ocorre quando um colaborador se sente emocionalmente ligado à empresa, a um projeto ou uma meta. Jogos excessivamente racionais e sem contexto podem gerar respostas negativas ou até mesmo disputas ferrenhas e acirradas entre funcionários, às vezes separando equipes e criando desavenças, ao invés de unir e aprimorar, como é esperado.

Recentemente aplicamos uma dinâmica dentro do nosso projeto com intuito de gerar regras e artefatos para criação de uma boa estrategia de gamification. Mostrarei em um próximo artigo como foi realizada e como você também pode aplicar em sua empresa, projeto ou equipe.

Abaixo, um pouco do que resultou:

Nos vemos na próxima fase, até mais ;) #AgileContent

.

.

.

Referencias
 — Amy Jo Kim: With a background in neuroscience, computer science, and psychology, Amy Jo Kim is part game designer, part web community architect.
 — Jane McGonigal, PhD is a world-renowned designer of alternate reality games

https://www.linkedin.com/in/priscillaalbuquerque/
 — Fabio Paes, entusiasta e desenvolvedor de jogos
 — https://br.udacity.com
 — https://blog.solides.com.br/

Gestão de pessoas com gamification was originally published in Agile Content Teamwork on Medium, where people are continuing the conversation by highlighting and responding to this story.

A globalização e a automação de processos estão a todo vapor, e em meio a tantas novidades e velocidade de desenvolvimento deixamos escapar uma das melhores características da humanidade durante a história: a capacidade de inovar. Inovar é uma necessidade nos dias de hoje, a competitividade exige isso das empresas, é como um investimento para não ficar para trás, seja melhorando a qualidade do produto, o tempo de desenvolvimento ou um processo interno, se tem algum benefício para a empresa, ajudará a vencer a concorrência.

“Os concorrentes estão bem preparados e os clientes são cada vez mais exigentes. Dentro desse contexto, a inovação aparece como uma ferramenta de competitividade” (DESCHAMPS; NAYAK, 1996)

Mas então surge a dúvida: como inovar?

Inovar não necessariamente é criar algo novo, aproveitar soluções já existentes para sanar problemas a sua volta também é uma forma de inovar. Não precisamos construir algo novo toda vez que encontramos alguma dificuldade, se podemos utilizar alguma ferramenta que já está em uso ou já é conhecida para resolver um problema, por que não? Talvez esse seja o conceito no qual devemos nos basear para inovar dentro do desenvolvimento ágil, aplicar uma tecnologia ainda não conhecida pela sua empresa, mas que já é utilizada no mercado, é uma forma de inovação.

Na atmosfera de trabalho com Tecnologia da Informação (TI), nos deparamos com inúmeras soluções novas a cada dia que podem mudar completamente a forma de pensar sobre o que estamos trabalhando, produtos e serviços para que pessoas possam realizar algo de um jeito melhor, ou para fazer coisas que até então não eram possíveis. O que pode ser difícil é acompanhar toda essa evolução e novidades do mercado, conseguir trazer para o seu dia-a-dia algo novo para resolver seus problemas ou melhorar os processos de desenvolvimento, principalmente com a correria rotineira.

Estou na área de TI há pouco mais de dois anos, trabalho hoje dentro de uma metodologia de desenvolvimento ágil, o que faz parecer ainda mais dificil administrar o tempo para inovar, e encontro grande dificuldade em me manter atualizado e estar por dentro de novas tecnologias e soluções. Quem nunca saiu de uma reunião pensando “como esse cara sugeriu essa tecnologia nova? De onde ele tirou isso?!”

É preciso estudar…

Sabe aqueles 5 ou 10 minutos que temos para dar uma relaxada, limpar a mente do trabalho? Quase sempre recorremos as redes sociais apenas para enriquecimento de relações interpessoais e entretenimento como facebook, instagram, twitter, entre outros… mas e se recorrermos a fontes informativas que agreguem no conhecimento pessoal e profissional de maneira natural e divertida?! Precisamos de fontes de informação que nos deixem entretidos, que consigam manter a nossa atenção e interesse!

E isso não significa que você não possa utilizar redes sociais, muito menos que sou contra o uso das mesmas, mas sim favorecer o aproveitamento do seu tempo, ao invés de passar 10 minutos em redes sociais porque não dedicar esses 10 minutos para algum enriquecimento profissional ou pessoal?!

Vamos a alguns exemplos de como manter-se por dentro dos assuntos em alta:

Sites, comunidades, blogs, canais…

Para aquele período de descontração, por que não investir seu tempo em meios gratuitos que podem agregar e muito na sua vida profissional? O Medium é um grande exemplo de plataforma onde digital influencers estão disponibilizando textos com conhecimentos e opiniões o tempo todo. O site pode te mandar diariamente as recomendações de acordo com os temas que você seleciona como áreas de seu interesse.

Meetups, eventos, conferências, congressos…

Às vezes é bom ter contato direto com alguém para escutar ou discutir sobre algo novo. Como exemplo de conferência, podemos levantar a The Developers Conference, o famoso TDC, um evento que reúne desenvolvedores e grandes comunidades de TI do brasil. O evento traz novidades do mercado e diversos workshops apresentados por profissionais que são referência no assunto. Outro exemplo de evento é a Campus Party, onde jovens (geralmente) encontram um festival de Inovação, criatividade, ciências, empreendedorismo e universo digital, estabelecendo um contato direto com tecnologia e seus usos.

Workshops, seminários…

Geralmente reuniões com caráter de treinamento, workshop ou seminário podem ser muito bem aproveitados para disseminar o conhecimento dentro do time, temos a oportunidade de aprender algo que está em uso com alguém próximo, o que abre o espaço para debate, um melhor entendimento sem tira-lo do conforto, afinal, estará entre colegas de trabalho!

Sites, comunidades, meetups, seminários, congressos, canais, blogs, eventos de Tecnologia, Network… Todos são meios de estar por dentro da comunidade de TI, basta você encontrar os meios com os quais você mais se identifica e investir um pouco de tempo. Muitos destes meios são gratuitos, então aproveite!

“Já sei! É só…”

É hora de estudar para que os impactos nos processos sejam mínimos! Repense a solução… é essa mesmo? Que tal colocarmos em teste?

É preciso avaliar os riscos cuidadosamente, ver se na estrutura atual da sua equipe/sistema/projeto é possível implementar a inovação. Toda inovação tem suas limitações, principalmente se dependem de decisões feitas por pessoas, quanto mais influência de decisão humana, maiores serão os riscos e as limitações da sua solução. Esteja preparado, grandes problemas podem ser encontrados com a implementação da inovação, pois é impossível prever todas as consequências de uma inovação!

Inove!

There’s a way to do it better — find it. (EDSON;THOMAS, 1957)

Mantenha-se atualizado para as novidades do mercado e suas tendências. Assim, quando surgir um problema, a chance de você já ter a solução em sua base de conhecimento é maior. Encontrou um problema complexo para se resolver com as ferramentas que você utiliza hoje? Pesquise novas maneiras, como outras empresas e pessoas têm resolvido problemas parecidos ou até iguais. Não deixe o mercado te deixar para trás, alguns minutos por dia podem ser suficientes para estar sempre atualizado. O que está esperando para arregaçar as mangas e começar a inovar? Não espere o futuro chegar, crie ele!

Referências:

https://medium.com/ch%C3%A1-com-design/divagando-sobre-originalidade-e-inova%C3%A7%C3%A3o-2f05757b3e7b

https://uxdesign.cc/meetup-a-usability-case-study-e909c33f1e3e

https://quoteinvestigator.com/2013/07/16/do-it-better/

https://blog.mastertech.tech/tecnologia/novas-tecnologias-como-estar-sempre-atualizado-na-area/

Inovar em Desenvolvimento Ágil was originally published in Agile Content Teamwork on Medium, where people are continuing the conversation by highlighting and responding to this story.

O misterioso mundo do NoSQL

Então, o que é NoSQL?

Eu sei! Eu sei! É um monte de JSON!

Bem… não. Que dizer, não muito. A diferença é mais na forma em que você acessa os dados do que como eles são armazenados.

Tem um monte de db’s NoSQL por aí com diferentes estruturas que são usadas para problemas específicos. Como grafos para redes de conexões, pessoas, cidades; ou arrays associativos (ou KV, key-value) usados para cache. E existem dbs orientados a documentos que usam sintaxes como XML ou JSON para manipular os dados, MongoDB é um deles.

O que todos eles têm em comum é que eles tendem a evitar a “Linguagem de Consulta Estruturada” para retornar dados. Not only SQL, como dizem por aí.

Mas é muito diferente de SQL?

Às vezes. A preferência por outras sintaxes se dá porque elas funcionam melhor para algumas estruturas de dados ou casos de uso.* Se você tem uma estrutura KV, por exemplo, você só precisa da chave pra procurar o valor.

Não é o caso do MongoDB.

* Existem algumas diferenças em como distribuir os dados, partição de rede e outras coisas como o Teorema CAP. Mas não quero falar sobre isso hoje.

Mesmos conceitos, estrutura diferente

Imagine que nós temos uma aplicação de vídeo sob demanda (VOD para os íntimos) só de filmes de super-heróis. Hoje você vai lá e cria um banco de dados relacional com uma tabela Filmes para o nosso catálogo, algo como esta aqui:

+--+-----------------+-------+---------------+-----------+
|id|title            |year   |publish_date   |studio_fk  |
+--+-----------------+-------+---------------+-----------+
|1 |"Justice League" |2017   |2018-02-10     |1          |
|2 |"Deadpool"       |2016   |2017-10-19     |3          |
|3 |"Wonder Woman"   |2017   |2017-09-19     |1          |
|4 |"Captain America"|2016   |2017-09-19     |2          |
+--+-----------------+-------+---------------+-----------+

Junto com uma tabela de Estúdios. Índices, foreign keys, normalização e essas coisas. Sabe como é. Não vamos pensar sobre isso agora.

Eu já falei que MongoDB usa uma sintaxe parecida com JSON para guardar dados, não tabelas. Então como, por exemplo, seria o registro “Deadpool”?

{
    "_id": 2,
    "title": "Deadpool",
    "year": 2016,
    "publish_date": Date("2017-10-19"),
    "studio": {
        "name": "21th Century Fox",
        "logo": "url_to_fox_logo.png"
    }
}

Nossa! Nem é tão diferente assim!

Dá pra ver o padrão, né!? Tem algumas coisas estranhas, mas a maioria dos nomes das colunas foram traduzidos para campos do JSON e os valores atribuídos respectivamente.

Outra coisa em comum nesse caso é que o _id age como uma chave primária: tem que existir e seu valor tem que ser único. Se você não passar um quando inserir um registro, o banco de dados gera um pra você.

Então existe uma chave primária. Quer dizer que tem índice também?

Sim, tem sim. Os indices são definidos para cada coleção de documentos chamados…bem… collections! E collections se comportam de maneira parecida com tabelas. A única diferença real é que vocẽ não precisa especificar o esquema dos dados. Se o índice não consegue encontrar a chave, ele trata isso como null ou impede você de inserir o documento, dependendo de como você criou o índice. Bem parecido com o SQL Server.

Legal! E aquele studio que tem no final?

Ah é! Quase esqueci! Se você precisar desnormalizar seus dados, por questão de performance (ou mesmo sanidade), você pode incluir outro documento dentro dele mesmo, e até realizar consultas nele.

Por falar em query

Como você pede os dados nesse banco? Vou começar com a sintaxe SQL de novo.

Se você precisa listar os filmes do estúdio “Warner”, em ordem reversa de publicação, você escreveria algo assim:

SELECT title, publish_date
FROM dbo.Movies AS movie
JOIN dbo.Studios AS studio ON movie.studio_fk = studios.id
WHERE studio.name='Warner'
ORDER BY publish_date DESC

Vamos traduzir para a linguagem que o MongoDB entende, que por acaso é JavaScript.

var filter = {"studio.name": "Warner"};
var projection = {"title": 1, "publish_date": 1, "_id": 0};
var order = {"publish_date": -1};

db.movies.find(filter, projection).sortBy(order);

Perceba a semelhança! O db.movies ali no final significa que estamos na collection movies no banco atual, igual a cláusula FROM. O filter funciona como o WHERE, com uma ajudinha da desnormalização aqui. A cláusula SELECT é convertida em um objeto JSON chamado projection. E o ORDER BY vai dentro do método sortBy, com -1 indicando ordem decrescente.

A grande diferença nesse exemplo é que você precisa explicitamente dizer que o campo _id não deve ser retornado escrevendo "_id": 0 no projection, já que o padrão é que ele sempre é retornado.

Igual mas diferente

Os dois sistemas de banco de dados são bem parecidos, mas qual a diferença no MongoDB afinal? Além da estrutura de dados e a linguagem de consulta, tem algumas coisas que os desenvolvedores do MongoDB decidiram deixar de lado. A maioria porque, na visão deles, essas características poderiam tornar difícil trabalhar com dados distribuídos do jeito que eles queriam.

A maior delas é a ausência de Transações.

É por isso que muitos desenvolvedores e dba’s usam documentos aninhados quando projetam um banco de dados MongoDB. Claro, quando você aninha documento, existe um limite no tamanho documento, e algumas vezes pode causar alguns updates estúpidamente complexos e lentos. Eu recomendo usar isso com cuidado. Existe um ótimo tutorial de como criar operações transacionais em documentos MongoDB, então você pode “normalizar” seus dados através de collections e tratar alguns updates complexos em mais de um documento.

Resumindo

Vamos ver o que aprendemos:

• Os documentos JSON em MongoDB são basicamente entradas SQL com {}
• Collections são tipo tabelas
• _id é uma chave primária obrigatória
• Quando consultamos o MongoDB nós usamos todos os elementos de uma consulta SQL, mas escrito em JavaScript.
• Não tem Transações

Esse é o básico. Espero que você se sinta mais confortável para pesquisar sobre bancos de dados NoSQL após ver que não é tão diferente assim. Talvez isso ajude a melhorar suas habilidades e a forma de pensar no SQL. Quem sabe?

Usei o MongoDB como exemplo por causa dessas semelhanças. Se você quiser saber sobre mais bancos de dados, com outros paradigmas, recomendo o livro Seven Databases in Seven Weeks.

É isso aí. Que a Força esteja com vocês.

Originalmente publicado em thiagoabreu.github.io (in english)

NoSQL Relacional com MongoDB was originally published in Agile Content Teamwork on Medium, where people are continuing the conversation by highlighting and responding to this story.

I confess: at the time, I hadn’t given due importance to that. I was more interested to learn unit test practices, continuous integration, etc.

Now, 1 year later, something curious just happened.

I developed a module for my current project, a payment integrator library, which communicates with one of the payment gateways available. As a new project, I was so excited to apply the best practices, create lots of unit test to cover 100% of the code, and so on.

Soon after I finished the project, I ran a tool available in Visual Studio (the software we use to develop), which analyzes the code, and outputs some quality metrics. One in special caught my attention:

Maintainability Index. My first thought was: “Nice, 84 seems a good value, at least It’s green.” After some time, I was wondering what this value really meant, and what are the thresholds which limit a good and a bad code in terms of maintainability. I was obsessed to increase this number, changing my code to optimize it as much as I could. Almost one entire work day for this, lots of new commits created, for every class in the project.

Microsoft says: “Maintainability Index calculates an index value between 0 and 100 that represents the relative ease of maintaining the code. A high value means better maintainability. Color-coded ratings can be used to quickly identify trouble spots in your code. A green rating is between 20 and 100 and indicates that the code has good maintainability. A yellow rating is between 10 and 19 and indicates that the code is moderately maintainable. A red rating is a rating between 0 and 9 and indicates low maintainability.”[1]

I thought these thresholds very distant from each other, especially between green and yellow. So I started to research more about it.

Then I discovered the Maintainability Index was first introduced in 1992, in a software conference. Long story short, it’s about a mathematical formula which describes how maintainable a piece of code is.

I won’t dig into the details of it, but it relies on four variables:

• Halstead Volume: essentially the number of operators you use
• Cyclomatic complexity: measures how many paths (decisions) your code has, including if and loop clauses.
• Lines of code: how big your module is (in terms of number of code lines)
• Percentage of code commentaries (yes, that’s true). This variable, in particular, was added later by SEI (Software Engineering Institute)[2]

Observation: Microsoft also changed this formula a little bit to fit into a 0–100 scale.

I started to feel a little confused because there was no consensus about the values of the thresholds. The original paper mentions 65 and 85 values.[3]. I understand Microsoft fits into a different scale, but the distance between their good and medium values is very big.

Then I found the following article: “Think Twice Before Using the ‘Maintainability Index’”[4]. That really caught my attention. Essentially the author argues and questions about the efficiency of this metric. Furthermore, he mentions a study [5] from the University of Oslo. They hired four different companies to develop a software with the same requirements. Then they required them to do some maintenance tasks on it and measured the time and results with some software quality criteria. The following table summarises it:

One of their conclusions was: there’s no direct relation between the Maintainability Index and the efficiency of the maintenance tasks. But there’s a direct relation between lines of code and the efficiency of the tasks.

My conclusions

At first, I was incredulous: all the best practices applied to my code, including SOLID principles, unit testing, use of inheritance and polymorphism over decision clauses (if, while, for). Don’t I have to consider all of this, because, essentially it’s a waste of time and effort? Then I started to think more about it, and I concluded some points:

• Metrics really shape behaviors. My willingness to reach the highest Index possible was obfuscating what’s really important: to keep the code maintainable, but simple. Of course, it doesn’t mean I have to code monolithic classes and forget about some best practices, but apply them as I need, when I need, keeping them in a developer toolbox.
• The Maintainability Index (among other metrics) is important, but it’s more a guideline than a value you must pursue to be the highest possible at all costs. In my opinion, it’s more beneficial to run it once, check the results, and sometime later, after a lot of modifications in your code, run it again. The important thing here is to compare with your own code, regardless of the value first obtained. This value itself is not so important. But I tend to agree that when there’s red flag, it is always worth aiming for a code refactoring.
• The study from the University of Oslo clarifies a lot of points, but some of them are questionable: the Maintainability Index of the four projects is very close to each other. What if we compare the results with good and bad written code, more distant in terms of quality? Also, for me, four projects are not enough to verify some of the results. For a comparison closer to the market reality, it could also consider older projects, written and rewritten by dozens of different people. That really makes the difference when you’re about to do any maintenance task.

References (accessed on 06/28/2018):

[1] — Code Metric Values — https://msdn.microsoft.com/en-us/library/bb385914.aspx

[2] — C4 Software Technology Reference Guide — https://resources.sei.cmu.edu/asset_files/Handbook/1997_002_001_16523.pdf

[3] — Using Metrics to Evaluate Software System — http://www.ecs.csun.edu/~rlingard/comp589/ColemanPaper.pdf

[4] — Think Twice Before Using the “Maintainability Index” — https://avandeursen.com/2014/08/29/think-twice-before-using-the-maintainability-index/

[5] — Questioning Software Maintenance Metrics: A Comparative Case Study — https://www.mn.uio.no/ifi/personer/vit/dagsj/sjoberg.anda.mockus.esem.2012.pdf

Metrics Shape Behaviors was originally published in Agile Content Teamwork on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sim! O Scrum é uma metodologia ágil voltada ao desenvolvimento de software, mas somente utilizar o framework não torna uma organização ágil.

Assim como em outros métodos, a proposta do Scrum é fornecer subsídios para o gerenciamento de atividades muitas vezes complexas, porém de uma forma flexível e que facilite a adaptação do projeto diante das adversidades.

A maioria das empresas desenvolvem produtos ágeis se apoiando no Scrum, de forma a forçar o uso da metodologia, acreditando fielmente ser o ideal para o negócio independente dos problemas que surgem.

Já parou para pensar se o Scrum realmente é o melhor para o seu negócio ou organização?

Agilidade vai além de modinha, trata-se da evolução de um produto e da evolução de pessoas. Ser ágil é ter resiliência correndo nas veias e não usar um framework só porque o concorrente usa.

Ser ágil não significa APENAS ser mais rápido!

Hoje somos extremamente eficientes em entregar software rápido, mas com qualidade questionável e com baixa manutenibilidade.

Em um projeto realizado utilizando o Scrum, a execução acontece em iterações. Baseado em um modelo tradicional, a planning é realizada, os prazos são determinados e o ciclo continua.

Supondo que um desenvolvedor agilize uma funcionalidade, de forma rápida, não testável e funcional… ele foi produtivo, certo!? Porém pensando em qualidade e valor, foi um período de desenvolvimento desperdiçado.

Ser ágil, mais do que ser rápido, é diminuir riscos, maximizar qualidade do que está sendo feito e sempre realizar avaliações sobre o que está sendo entregue.

Para o autor Jeff Sutherland, em um de seus livros mais vendidos: Ser ágil é literalmente: “A arte de fazer o dobro na metade do tempo”

Recomendo leitura.

Mas são tantos detalhes, problemas e insatisfações. Não ter a certeza se o framework que utilizo está funcionando, fica difícil. Então como mudar?

Não será da noite para o dia XD !

Lembre-se, sempre uma coisa por vez, como a aplicação de uma nova metodologia ágil em um projeto pequeno, treinamentos para os colaboradores, questionar se o Scrum é realmente a opção certa para empresa.

Talvez haja a necessidade de usar outra forma de desenvolvimento, como XP, Lean, Kanban, etc. Cabe a nós entusiastas do manifesto ágil, buscar, inovar e evoluir. Só assim conseguiremos alcançar iterações curtas, times multidisciplinares, times autogerenciáveis, foco em entrega de valor para o cliente, escopo flexível, visibilidade e previsibilidade, além do constante envolvimento do cliente com a empresa.

Bora ser ágile!

Se é agil é Scrum? was originally published in Agile Content Teamwork on Medium, where people are continuing the conversation by highlighting and responding to this story.

É engraçada a história de como surgiu a Teoria do Beija-Flor. Eu sempre achei o beija-flor um tipo de passarinho muito bonito e diferente. As curiosidades sobre ele são bem impressionantes e um dia desses minha atenção voltou-se pra ele. Tive a dúvida de como poderia chamá-lo em uma cidade urbana como São Paulo, que possui pouquíssimas árvores e flores. Mais especificamente para a janela do meu quarto — aliás, deve ser uma delícia acordar com passarinhos em casa, não? Depois de algumas pesquisas descobri que, para chamar o beija-flor, bastava implementar um bebedouro colorido com água limpa e açúcar. Com o tempo ele descobriria esse novo recurso e viria até mim. E era isso. Simples assim.

Você deve estar se perguntando o que essa teoria tem a ver com a construção do espaço seguro e acessível, certo? Te explico: acontece que algumas pessoas são uma espécie de beija-flor. E falo especificamente dos grupos de minorias.

Uma observação: Utilizo como termo minoria, o grupo de pessoas que tem menos direitos e/ou se encontram fora do padrão determinado pela sociedade. Portanto, não o digo no sentido quantitativo, embora sejam impressionantes as medidas desproporcionais, por exemplo, com relação à quantidade de pessoas com deficiência no mercado de trabalho comparada à quantidade total de pessoas com deficiências no Brasil. (Segundo o Censo Demográfico do IBGE, 24% dos brasileiros possuem algum tipo de deficiência e apenas 0,77% das pessoas com deficiências estão formalmente inseridas no mercado de trabalho. Fonte: Estadão.)

Acessibilidade (ou a falta dela) VERSUS Tecnologia de Informação

Diariamente as pessoas com deficiência sofrem com a falta de acessibilidade em lugares privados e públicos. As barreiras de comunicação afetam a comunidade surda e as pessoas com deficiência auditiva pela falta de legendas em vídeos e ausência de intérpretes de língua de sinais (Libras). Calçadas esburacadas, elevadores quebrados, entradas pequenas, banheiros não-adaptados afetam tanto cadeirantes quanto pessoas com mobilidade reduzida. A falta de pisos táteis e referências sonoras afetam as pessoas cegas. Enfim, a lista é longa.

Partindo por essa lógica, por que a área de Tecnologia de Informação seria diferente, então?

Resposta: ela não é diferente. Não restam dúvidas de que a tecnologia veio para facilitar a vida de todos mas, para as pessoas com deficiência, ela conseguiu transformar algumas coisas inacessíveis em possíveis. A exemplo disso, temos o boom do WhatsApp e redes sociais que tornaram o acesso possível para as pessoas surdas se comunicarem por escrito, sem precisar fazer qualquer ligação ou gastar uma fortuna, como fazíamos há um tempo com SMS — ou não fazíamos. O mesmo serve para as pessoas cegas, com a chegada dos leitores de tela cada vez melhores e capazes de reconhecer diversas línguas do mundo.

O Youtube e o Facebook possuem agora um recurso para criar legendas e closed caption. Quantos de nós estamos preocupados e habituados em sempre transcrever um vídeo de 3 minutos, por exemplo? Quando postamos uma linda imagem com um texto, estamos lembrando de que os leitores de tela ainda não são capazes de transcrever uma imagem para uma pessoa cega? Estamos habituados a não nos apoiar somente nas cores como indicativos, mas adicionar também, alguma legenda ou ícones simples e com contrastes, para as pessoas com autismo e/ou daltônicas?

O que diferencia nós que trabalhamos na área de Tecnologia de Informação dos profissionais de outras áreas, é que temos bastantes recursos, tanto tecnológicos quanto sociais pelo privilégio e acesso às informações e notícias mas mesmo assim ainda não estamos maduros o suficiente para utilizar a tecnologia a favor de todos e todas. A tecnologia avança e evolui

cada vez mais rápido à medida que a nossa consciência humana está cada vez mais longe e atrasada. E o mais contraditório disso tudo, é que a tecnologia só existe graças à consciência humana.

Começando pelo começo

Agora, fazendo ponte com a Teoria do Beija-Flor: quando a gente trabalha, transita e frequenta ambientes presenciais e virtuais pensados somente para pessoas sem deficiência, nós, pessoas com deficiência, somos os beija-flores dessa sociedade. Isso significa que, se não tiver o bebedouro com água e açúcar, estão nos dizendo que aquele espaço não é nosso — mesmo que ele seja nosso por direito.

Portanto, é nosso papel social e como profissionais da T.I, implementarmos um bebedouro gigante. Precisamos internalizar uma cultura da acessibilidade, começando pela nossa consciência, mudando nossos hábitos e valores de inclusão e pôr a mão na massa na rotina do trabalho também. E então, como fazer isso?

• Se você tem um colega ou uma colega com alguma deficiência no seu trabalho, comece a conversar com ele/ela. Troquem experiências. Isso contribui para a construção de novas ideias e agilidade na solução de problemas.
• Leia artigos, estudos e pesquisas sobre Acessibilidade na Web.
• Questione a falta de acessibilidade nos eventos de T.I. Com o mercado em expansão, há uma grande probabilidade de vermos mais pessoas com deficiência atuando na área. Logo, é direito de todo mundo ter acesso à informação por igual.
• Chame os amigos, divulgue os eventos que contam com acessibilidade. Se vai criar um evento, faça um check-list de recursos essenciais para tornar um espaço possível e acessível. Lembre-se, a maioria dos espaços não estão preparados para receber o público com deficiência. Você vai precisar divulgar, por exemplo, que o evento contará com intérprete de libras. Ou que tem entrada para cadeirantes. Ou que haverá audiodescrição. Deixe tudo isso bem claro ou as pessoas com deficiência não se sentirão convidadas.
• Permita-se errar, sempre. Mas também permita-se entender que errou e diminuir a margem de erros a todo momento. Ninguém nasce sabendo e tudo bem. Estamos aqui para aprender com todo mundo.

É importante lembrarmos que a diversidade existe e não tem como escaparmos dela. No campo de tecnologia e produtos, a diversidade contribui para novas ideias, trabalho em equipe, criatividade e agilidade na solução de problemas. A experiência de cada pessoa que trabalha na empresa, é um passo muito importante para a criação de produtos inovadores. Portanto, usufrua desse privilégio e faça parte desse mundo tão diverso.

E os beija-flores virão.

Teoria do Beija-Flor e os espaços acessíveis was originally published in Agile Content Teamwork on Medium, where people are continuing the conversation by highlighting and responding to this story.