Este é um assunto relevante em qualquer empresa, pois salário, mais do que remuneração, reflete no reconhecimento sobre o trabalho. Em um modelo de gestão horizontal e distribuído, percebemos um panorama especialmente desafiador, sempre cercado por debates e discussões.

Adotamos o termo gestão horizontal para definir nossas práticas de gerenciamento, pois não nos orientamos em hierarquias. Ou seja, uma decisão de aumento salarial não vem de um gestor, pois não há gestores!

Leia também: Gestão das pessoas ou do sistema?

A principal dificuldade nesse contexto é que não há uma figura objetiva para pedir um aumento, e conversar com o grupo por vezes gerava algum nível de constrangimento. É comum o assunto ser visto pelas pessoas como tabu. Em razão dessas dificuldades cotidianas, buscamos alternativas que pudessem nos ajudar.

O primeiro passo foi combinar a frequência com que o tema seria abordado, além da definição de uma "fórmula" para que as pessoas pudessem saber o valor do dinheiro disponível, criando então alguns indicadores. Essa fórmula nos ajudou a manter a sustentabilidade da empresa, dando visibilidade à disponibilidade financeira, e apreciação sobre possibilidade de aumento para os interessados. Contudo, sempre parar toda a empresa para apreciar salários e discutir os indicadores não estava mais se mostrando algo viável.

Neste contexto, utilizamos da ajuda de uma valiosa ferramenta: Percival (“PERCeIved VALue”), desenvolvido por Klaus Wuestefeld . O Percival tem como finalidade gerar uma mensuração mais simples e mais justa sobre a apreciação de nossa contribuição.

Sabemos que algumas empresas utilizam esses resultados de forma direta na definição de salários. Em nosso contexto, porém, preferimos usar esses dados de forma auxiliar, sendo uma das variáveis implicadas nas decisões sobre aumentos.

A apreciação dos resultados do Percival se dá em dois momentos distintos: o primeiro momento é para definir quais pessoas teriam prioridade em obter um aumento salarial. Esta informação é uma mensuração individualizada, que consiste na combinação do resultado do Percival, do salário atual da pessoa e da quantidade de dias em que ela está sem receber aumento. Já o segundo momento consiste efetivamente na decisão sobre o aumento salarial: se haverá, e de quanto será . Como os resultados do Percival já representam uma percepção do grupo, entendemos que no momento de decisão sobre aumento salarial já não é mais necessária a participação de todos da empresa. A apreciação sobre um pedido de aumento é feita por um grupo pequeno e voluntário (em uma dinâmica que batizamos de WillRaise), onde apresentam seus pontos de vista e apontam juízos importantes para que possam chegar a uma síntese e consequente decisão. Toda colocação é bem vinda, inclusive questionar o próprio resultado do Percival.

Sobre o funcionamento do Percival: sua utilização é simples e eficaz. Todas as pessoas da empresa acessam a ferramenta através de seu e-mail corporativo, onde estão dispostos os nomes de todos os colegas em uma planilha composta por linhas. Cada participante poderá elencar o nome do colega para cima ou para baixo, de acordo com sua apreciação sobre sua contribuição na empresa. Em paralelo, é pedido ao participante que indique o grau de certeza para sua apreciação acerca de cada pessoa. Um baixo grau de certeza, por exemplo, indica que você não tem conhecimento suficiente para fazer uma apreciação precisa sobre a contribuição daquele colega, o que é considerado no resultado da ferramenta. Depois de executadas as apreciações, são gerados gráficos que exibem, segundo a visão do grupo, o quanto cada pessoa contribui para a empresa, e o quanto essa pessoa conhece e é conhecida pelos seus pares (o que é chamado de notoriedade).

Com esta ferramenta, agora podemos saber com maior precisão quem teria prioridade em receber um aumento salarial, sempre de acordo com o tempo em que a pessoa está sem receber aumento e com sua contribuição na empresa.

Lembrando que, com o resultado do Percival, ainda tomamos a decisão sobre o aumento salarial em relação a outros indicadores, apreciada na dinâmica citada anteriormente (WillRaise). Consiste em criar uma fila de prioridades, com ajuda do Percival, e alguns tópicos que podem ser abordados durante a dinâmica. São elas:

• Resultado do Percival;
• Depoimento de um membro do time da pessoa;
• Consulta ao P.O do projeto em que ela atua;
• Escuta da pessoa candidata ao aumento;
• Verificação se há recursos financeiros para o aumento.

Um dos problemas que encontramos é que as pessoas recém contratadas, normalmente, ficam com um nível de contribuição mais baixa, o que pode se justificar por sua recente integração. Por mais que este fenômeno possa ser compreendido, isso pode gerar um real desconforto.

Outra dificuldade está na crença de que pessoas com perfil mais introvertido não são notadas, e que isso impactaria na avaliação, ainda que seja mensurado o grau de certeza ao apreciar um colega. Temos incentivado a troca de pares entre times para ajudar o grupo a se conhecer (o que, além de tudo, promove uma troca de conhecimento sensacional). Temos percebido também que, independentemente destes receios, pessoas tímidas e comprometidas vêm sendo sim bem reconhecidas.

O uso do Percival com este mini-processo tem nos ajudado a abordar o tema Aumento Salarial com maior eficácia em nosso modelo de gestão distribuída. Contudo, o tema permanece sensível, e sempre revisitamos nossos métodos em debates e discussões. Obviamente, problemas novos surgirão e, como somos iterativos e incrementais, sempre estaremos em busca de respostas.

→ NEWSLETTER ASSINE NOSSA! E fique por dentro de tudo o que acontece no Ateliê de Software da Webgoal .

Dê um alô pra gente! Você pode acompanhar as redes sociais:
→ Email: contato@atelie.software
→ Site
→ Facebook
→ Instagram
→ Twitter
→ Youtube

Tratando de Aumento Salarial em uma Gestão Horizontal was originally published in Share! por Ateliê de Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Neste post vamos configurar um projeto em Ruby on Rails para enviar emails via AWS SES de forma segura, sem utilizar credenciais (usuário e senha).

O serviço que permite configurar o gerenciamento de identidades e níveis de acesso aos recursos da AWS (Amazon Web Services) é o IAM (Identity and Access Management). Nele você cria Policies (políticas que agregam um conjunto de permissões), Users (perfis com credenciais) e Roles (perfis sem credenciais).

Vamos usar como exemplo a configuração do serviço de envio de email, o Amazon SES (Simple Email Service). O mesmo se aplica aos outros serviços, como o de armazenamento de arquivos (Amazon S3). Se pesquisarmos como configurar um projeto em Ruby on Rails para utilizar o SES, a grande maioria dos resultados encontrados ensinam a gerar credenciais SMTP e utilizá-las. Alguns outros ensinam a criar um User e configurar alguma gem que faça o envio utilizando a API do SES.

A forma mais segura e recomendada pela própria AWS, no entanto, é utilizar uma Role. E estes são os principais motivos:

• Não necessita credenciais de acesso (usuário e senha). Seu código fonte não vai conter nenhuma informação sensível.
• Não necessita configuração no servidor. O IAM provê dinamicamente credenciais temporárias para instâncias EC2.
• As credenciais temporárias, como o nome sugere, são renovadas automaticamente de tempos em tempos.

Ao configurar uma nova instância EC2, seja diretamente ou via ElasticBeanstalk, você informa qual Role aquela instância (ou conjunto de instâncias) deve assumir quando em execução. São as permissões dessa Role que definem a quais recursos a instância terá acesso.

Na AWS são apenas 3 passos

Vamos demonstrar via console web mas poderiam ser executados via awscli no terminal.

1. Para garantirmos o mínimo de privilégios possíveis, vamos começar criando uma Policy que somente permita o envio de emails. Se você desejar, também é possível limitar qual o remetente dos emails, e uma série de outras coisas.

2. Depois, crie uma Role do tipo AWS Service Role → Amazon EC2 → selecione a Policy criada no passo anterior.

3. Agora é só definir que a EC2 terá essa Role no momento que você estiver criando ela.

No Rails também são apenas 3 passos

1. No seu projeto Rails, adicione a gem aws-sdk-rails no seu Gemfile, oficial da AWS. O último commit dela é antigo, mas ela mesma não tem praticamente nenhum código, ela apenas configura o Rails para usar a gem que tem os códigos importantes.

2. Configure seu production.rb para fazer o envio via :aws_sdk.

3. Por fim, configure a variável de ambiente AWS_REGION para a região que estiver usando.

Pronto! Faça deploy do seu projeto na EC2 e ele já vai enviar emails sem necessidade de especificar nenhuma credencial!

Em ambiente de desenvolvimento não daria pra fazer isso, pois as Roles só funcionam nas EC2. Como costumamos usar o Mailtrap.io neste ambiente, isso não é nenhum problema pra gente.

Apenas como lembrete, inicialmente o SES provê apenas acesso Sandbox, ou seja, só envia emails para emails que você previamente confirmou serem seus. Para ter acesso de produção é necessário solicitar um aumento no limite de envio. Você não entendeu errado, é necessário solicitar um aumento no limite de envio para liberar o acesso de produção.

→ ASSINE NOSSA NEWSLETTER! E fique por dentro de tudo o que acontece no Ateliê de Software da Webgoal.

Dê um alô pra gente! E nos acompanhe nas redes sociais:
→ Email: contato@atelie.software
→ Site
→ Facebook
→ Instagram
→ Twitter
→ Youtube

Permissões na AWS, use Roles e não Users was originally published in Share! por Ateliê de Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quando criamos nosso primeiro projeto ruby usando o Docker tínhamos que fazer um "docker build" a cada alteração no Gemfile e cada build instalava todas as gems…

Na versão 2 do docker-compose podemos criar volumes de forma bem intuitiva e transparente, sendo que os volumes têm as seguintes características:

• Volumes são inicializados quando um container é criado. Se a imagem base do container contém dados no ponto de montagem, estes dados são copiados para o novo volume após sua inicialização. (Isto não se aplica a volumes que mapeiam um diretório do host.)
• Ao subir um container baseado em uma nova imagem, possíveis diferenças no diretório não serão replicadas no volume.
• Volumes persistem mesmo que o container seja excluído.
• Volumes podem ser compartilhados e reutilizados entre containers.
• Alterações em um volume são feitas diretamente.

Sabendo disso, nosso Dockerfile não adiciona Gemfile nem faz bundle:

E nosso docker-compose.yml tem um volume específico para as gems:

Desta forma, ao executar um "bundle update" apenas as gems novas são baixadas e instaladas, acelerando bastante o ciclo de instalação das gems. Mesmo que você exclua o container e crie um novo, o volume continuará existindo. Sempre que quiser fazer um bundle limpo, basta remover o volume executando "docker volume rm …"

Puristas podem considerar a paridade de ambientes entre desenvolvimento e produção e questionar a existência de um volume que não existirá em produção. Mesmo neste caso, acredito que esta técnica seja útil no início do projeto e, a partir do momento que as gems do projeto "estabilizarem", você remove o volume do docker-compose.yml sem nenhuma outra modificação no projeto.

→ ASSINE NOSSA NEWSLETTER! E fique por dentro de tudo o que acontece no Ateliê de Software da Webgoal.

Dê um alô pra gente! E nos acompanhe nas redes sociais:
→ Email: contato@atelie.software
→ Site
→ Facebook
→ Instagram
→ Twitter
→ Youtube

gems e Docker em dev was originally published in Share! por Ateliê de Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quem não tem uma boa história para contar sobre o quanto sofreu ao mergear alguma funcionalidade que desenvolveu durante alguns dias e a versão atual do código que estava em produção? A medida que nossa experiência aumenta, percebemos que este tipo de atitude, segurar código sem comitar ou mesmo comitar numa branch independente, frequentemente traz dores de cabeça.

Quando trabalhamos em um time ágil, que realmente deseja entregar valor para o cliente o mais cedo possível, devemos observar as diversas práticas da eXtreme Programming. Quando estas práticas são usadas em conjunto os benefícios são evidentes. Neste post vamos destacar a Integração Contínua, que está diretamente relacionada ao uso de um VCS (sistema de controle de versão, como o git), a criação de testes automatizados e à programação em par.

A primeira dica é que trabalhar em um código obsoleto pode causar muita dor de cabeça, por isso, o recomendado é integrar (mergear) o código desenvolvido pelo par com o código desenvolvido por todos os outros pares várias vezes ao dia. No pior dos casos, ao menos uma vez ao dia.

Entre os problemas que podem acontecer se não integrarmos frequentemente estão: grande quantidade de conflito a ser resolvido, duplicação de código (dois pares desenvolveram a mesma funcionalidade de forma parecida) e problemas de compatibilidade entre as funcionalidades desenvolvidas. Para que você consiga integrar seu código com mais frequência, pode ser necessário alguma mudança na sua forma de programar. Três coisas que funcionam muito bem em nosso time são:

1. Ao trabalhar em uma estória de usuário, iterar nesta estória, ou seja, dividi-la em pedaços entregáveis que até podem ir para produção (continuous delivery);
2. Quando não conseguimos dividir a estória em entregáveis que façam sentido para o usuário, organizamos o desenvolvimento do código de forma que o usuário não tenha acesso à funcionalidade. Em um exemplo simplista, deixamos para colocar o link da funcionalidade no menu do sistema na última iteração da estória;
3. Usar feature toggles, ou seja, existe uma flag no sistema fácil de alterar, que habilita o uso da funcionalidade em desenvolvimento. Neste último caso é bastante comum habilitar a funcionalidade para alguns clientes (os beta testers) antes de habilitar para todo mundo.

A segunda dica é: somente um par integra por vez. É muito possível que mais conflitos sejam gerados em decorrência dos merges paralelos! A importância da comunicação entre os membros do time pode ser destacada mais uma vez aqui, tanto para saber quando os outros estão integrando e ajudar na resolução dos conflitos, quanto para saber o que está sendo feito
e o que possivelmente você poderá reaproveitar.

A terceira dica é automatizar a execução da suíte de testes. É aqui que entram as ferramentas como Jenkins, Trevis, GoCd e outros. Esta dica é a última por uma razão, como diz o manifesto ágil:

“Indivíduos e interações mais que processos e ferramentas”

De nada irá adiantar a ferramenta se o time não tiver o hábito de integrar frequentemente, como vimos nas duas primeiras dicas. Estas ferramentas executam toda suíte de teste a cada commit e, possivelmente, geram algum artefato. O grande ganho deste tipo de ferramenta é o feedback constante da saúde do código de produção. Se acontece algum descuido e sobe algum teste quebrado para o VCS, a ferramenta de integração contínua irá executar os testes e notificar o time por email, Slack ou qualquer outra forma.

Lembrando que o objetivo aqui não é encontrar culpados, mas sim descobrir o problema mais cedo. Como a propriedade do código é coletiva, qualquer membro do time pode corrigir o erro apontado pela ferramenta.

Compartilhe nos comentários alguma atitude positiva do seu time e aguarde um dos nossos próximos posts sobre Entrega Contínua.

Facebook: https://www.facebook.com/atelie.software
Instagram: @atelie.software
Twitter: @atelie_software
E-mail: contato@atelie.software
Site: ateliedesoftware.com.br

Mitos da Integração Contínua was originally published in Guilda do Código on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nós podemos, por exemplo, começar por melhorar nossa linguagem não chamando mais um bug de bug, mas chamando-o de um erro. Isto é muito mais justo porque dá a culpa a quem realmente ela pertence, a saber, ao programador que cometeu o erro. A metáfora animista do inseto que se infiltrou maliciosamente enquanto o programador não estava olhando é intelectualmente desonesta, uma vez que ela encobre que o erro é uma criação do próprio programador. O bom desta simples troca de vocabulário é que ela tem um efeito profundo: enquanto, antes, um programa com apenas um bug costumava estar "quase certo", depois, um programa com um erro está apenas "errado" (porque contém um erro).

Muita gente acredita que o termo surgiu por conta dos insetos que queimavam as válvulas do ENIAC (Electronic Numerical Integrator and Computer), o primeiro computador digital criado. Raramente utilizadas hoje, substituídas pelos semicondutores, as válvulas emitiam luz que atraíam os insetos os quais, por sua vez, provocavam curtos-circuitos nas placas do ENIAC. No entanto, sabe-se que o termo bug foi usado como jargão na engenharia mecânica, décadas antes da criação da Ciência da Computação.

Hoje nossas aplicações rodam na Nuvem, abstraídas em containeres. Utilizamos tecnologias que reagem às interações dos usuários e às mudanças do estado da aplicação de uma maneira que não imaginávamos alguns anos atrás. Utilizamos frameworks para a gestão do projeto e práticas de engenharia que minimizam nossa incrível capacidade humana de cometer erros. É por essas e outras razões que quando cometemos um erro, ao invés de acreditar que foi alguma coisa mística, simplesmente corrigimos. Sem desculpas.

Autor do algoritmo do caminho mínimo, Dijkstra era professor da Universidade do Texas. Ele escrevia e enviava para diversos professores de instituições de diversos países cartas chamadas de EWD. Há mais de 1300 EWDs disponíveis em sua página.

A EWD 1036, datada de 2 de dezembro de 1988, gira em torno da ideia de que a computação é uma coisa radicalmente nova. Enquanto metáforas e outras técnicas de ensino funcionam bem quando há uma evolução em algo conhecido, o ensino de algo totalmente novo como a computação necessita de abordagens diferenciadas. Seguindo esta linha de raciocínio ele dá diversas dicas do que deveria ser mudado no ensino da computação, como voltar às raízes e ensinar computação de verdade.

Se em 1988 Dijkstra estava bastante desapontado com a forma com que se estava ensinando Ciência da Computação, qual seria sua opinião a respeito do ensino nas faculdades de hoje? E nós, o que podemos fazer para melhorar essa realidade?

Quer saber mais sobre este assunto? Tem alguma sugestão? Entre em contato comigo!

Site: ateliedesoftware.com.br
Facebook: https://www.facebook.com/atelie.software/?fref=ts
Instagram: @atelie.software
Twitter: @atelie_software
E-mail: contato@atelie.software

Bugs, não acredite nos insetos infiltrados was originally published in Guilda do Código on Medium, where people are continuing the conversation by highlighting and responding to this story.