Ao longo dos mais de 8 anos de vida da nossa empresa, nosso time já compartilhou muito conhecimento:

• mais de 250 blog posts
• dezenas de palestras
• 4 livros (2 no Brasil, 2 nos EUA)

Este post é para falar do mais novo livro que um membro do nosso time está lançando: Métricas Ágeis, do Raphael Albino.

www.casadocodigo.com.br/products/livro-metricas-ageis

Mas antes de falar do livro em si, vamos entender um pouco dos panos de fundo por trás do livro.

Primeiro, um pouco de contexto

Na Plataformatec, nós gostamos de uma frase de efeito que os US Marine Corps utilizam:

“Improvise, Adapt and Overcome”

Especialmente das últimas duas palavras: se adaptar e superar. Por que digo isso? Pois acreditamos que o processo de melhoria contínua em um projeto segue esse mantra. Nós não temos a ingenuidade de que, para melhorar um processo, basta apenas implementar uma caixa preta de metodologias. Nós respondemos a quase todas as perguntas com “depende”. Depende do seu contexto, ambiente, pessoas, economia, estratégia. Tudo, em termos de gerenciamento de projetos de software, depende.

E é aí que muitas empresas se perdem. Decidem implementar Scrum, Kanban, XP ou outra metodologia e acreditam que todos os seus problemas estarão solucionados… não é bem assim. Você precisa analisar como está seu processo para que consiga entender quais práticas, ou conjunto de práticas, seu time está preparado para aderir e, a partir de então, fazer pequenos ajustes rumo a um processo melhor (a famosa melhoria contínua). Com isso em mente, nós aderimos a uma filosofia parecida com a descrita acima:

“Analise, se adapte e supere”

E como fazemos isso? Bom, uma das maneiras é através de métricas de processo. Nós coletamos uma série de métricas de processo assim que entramos em um cliente. Não chegamos mudando as coisas, chegamos analisando. Assim que temos as métricas em mãos, as lemos, analisamos e mudamos os pontos necessários para melhorar o processo pouco a pouco de maneira sustentável. E essa é a palavra chave de uma melhoria de processo. Ela precissa ser sustentável, ou seja, não pode incomodar demais a entropia do time, senão tudo se perde.

Por que um livro de métricas ágeis?

Pode parecer difícil e complicado esse processo de coleta de métricas, análise, adaptação e superação. Nós tratamos desse assunto no nosso blog, mas, se quiser realmente “beber da fonte” de tudo isso – saber de onde as métricas vieram, como coletar, ler e, principalmente, como melhorá-las – eu indico o novo livro do Albino.

Não é jabá. É fato. Na minha opinião, é o livro que melhor explica as métricas de processo, todos os tipos de leitura de gráficos e a melhor maneira de utilizar esses dados. Aliás, este é o maior valor do livro. É muito fácil você começar a coletar métricas… Mas isso não traz resultados se você não souber utilizar os dados que você coletou!

Albino aborda no livro toda a parte processual, matemática e heurística que os métodos trazem, sem nunca deixar de lado o valor de negócio atrelado. Resumindo, o livro não trata de “métricas por métricas”… trata de métricas para obter os melhores resultados possíveis no seu negócio. Entre os assuntos abordados estão o Throughput, Lead Time, Simulação de Monte Carlo, Eficiência de Fluxo e muito mais.

Então, se quiser entender melhor como nós fazemos para ter sucesso com nossos clientes e a metodologia por trás das nossas ações, não esqueçam de comprar o livro do Albino, acompanhar os novos blog posts e se cadastrar na nossa newsletter de ágil.

The post Estamos lançando mais um livro: Métricas Ágeis, do nosso consultor Raphael Albino first appeared on Plataformatec Blog.

Then, suddenly, the P.O. discovers that the features D and E were developed by a competitor and that you are losing users because of that. Therefore, the P.O. decides to deprioritize story C. This is only an example of why a card might be deprioritized in the middle of its development. But now that it was deprioritized, what happens to story C?

Well, to answer that, let me make a parallel with an alcohol-based perfume company.

In the backlog column, the company has the bottle ready to be filled but no fluid yet. When the bottle starts to be filled, the card goes to “in progress”. When the bottle is totally filled, the bottle is closed and the card goes to done.

So what happens if another perfume suddenly receives a priority greater than the priority of the bottle being filled? Well, as we all know, alcohol-based fluids are volatile and, with time, they will completely evaporate, requiring them to be refilled.

The same happens with the story and its code. With time, the code that is inside the story gets obsolete and unnecessary, losing its value. What to do with the story depends on the following rationales:

• How long will the story C stay in the same stage?
  • If the story stays too long in the same stage, some part of the work may get useless, therefore, you could just remove it from the board and put it back on backlog, since some refining might be needed when this story is chosen gain.
  • If the story will stay there for a short time, you may want to leave it there and, when it can be worked on, you may still use what was already developed.
• What is the value story C will generate after being done?
  Let’s say that the return on the development of that feature is small. Is it worth to pause its development and run the risk of investing even more money on the development later? Will the return on its development be greater than the development time?

For this to be true, the following needs to happen (visualized in the chart below):

• $ spent with initial development + $ spent with rest of the development < story C $ return
  • The amount spent with rest of the development will increase with time, since the initial development starts to lose value.
• If the amount spent is greater than the return, it is better to ignore the functionality. However, this math is not as easy as it seems… You need to account for risks, increased revenue, increase the number of users of your product, etc. So be careful!

Therefore, based on those, you can possibly do four things:

• Leave it on the column and restart it when its priority arrives
  The pause will be fast and will not harm the development of the card. In this case, it is important to flag the story somehow so that the whole team can see that the story is “blocked” by the P.O. due to its prioritization.

• Take it back to the backlog, and restart it when its priority arrives
  The pause will be long and the card will need more refinement.

• Finish it first, before getting another card
  The card is almost done, and if you stop it, it will not generate value anymore.

• Cancel the card
  The card is a long way from being finished, and its value is too small to pay for the time it will be paused.

It is also important to notice that this should NOT be a common thing in your process. If it is happening too often, you may need to work on your prioritizations!

What are your thoughts on the topic? Leave your comments below

The post The user story in development was deprioritized, what now? first appeared on Plataformatec Blog.

Muitas dessas dúvidas talvez surjam por conta dos conceitos que temos desde o “lançamento” do ágil. O conceito de “história do usuário”, algo que deve ser escrito pelo usuário, indicando na visão dele, uma necessidade para o produto ou projeto. Segundo Mike Cohn argumenta em “User Stories”, uma US deve ser pequena, com descrição simples de uma funcionalidade contada a partir da perspectiva da pessoa que solicitou, geralmente um usuário ou cliente do sistema. Por conta disso nos prendemos muito ao “usuário final”, o cliente, o carinha que está na outra ponta da feature, sem levar em conta todas as outras pessoas que também utilizarão a feature (time de suporte, time de operações, os próprios devs, por exemplo).

Alguns já devem ter lido ou ouvido “User Stories devem ser INVEST”, e pra quem não leu/ouviu, é um acronimo criado por Bill Wake em seu artigo “INVEST in Good Stories, and SMART Tasks” e reproduzido também por Mike Cohn em seu livro “User stories applied”.

São livros e artigos bem interessantes, e em um TL:DR, o que ele diz é que boas user stories possuem alguns atributos desejáveis. São eles: Independent, Negotiable, Valuable, Estimable, Small e Testable. Aqui, o que gostaria de chamar atenção são para 3 itens: Valuable, Estimable e Small. Lembramos sempre do “Valor”, mas esquecemos do Estimável e Pequena. Não uma estimativa mais apurada de esforço, pontos ou dias, mas algo que possa ajudar um Product Owner, por exemplo, a priorizar um backlog sabendo de uma duração próxima que o card terá. E principalmente, pequena, de forma a ser entregue em poucos dias entregando valor mais cedo.

Nos prendemos ao contexto de valor gerado pro usuário final, mas esquecemos que o valor é relativo. Além de ser algo que deve ser benéfico para outras pessoas dentro do processo, como o time de desenvolvimento, por exemplo. No caso de um card que vai gerar uma API que poderá ser utilizada por outros times, isso não gera um valor para o projeto como um todo? User stories técnicas não são user stories? Não devem entrar no backlog? Se formos pensar somente no “card escrito pelo usuário”, uma criação de API não entraria no backlog.

Então, vamos pensar no seguinte caso: o time X está trabalhando num projeto novo, o lançamento de um e-commerce e precisa desenvolver uma feature que deverá receber um pagamento via cartão de crédito, e após confirmado o pagamento envie por e-mail um documento em pdf listando os itens da compra realizada. Algo como “Eu como cliente gostaria de usar meu cartão para pagar a conta, e ao final quero receber no meu e-mail um pdf listando todos os itens comprados.”. Se formos pensar nesse card, o “valor” geral só será entregue quando o pdf chegar no e-mail do cliente, certo?

Essa US por si só, teria um tamanho considerável, levando em conta que: será necessária uma integração com algum gateway de pagamento, para processar a compra no cartão de crédito, uma API de mensagens que faça a rotina de disparos de e-mail, e uma API geradora de docs capaz de gerar o arquivo PDF que o cliente espera. E também é provável que uma PoC, caso o time não tenha mexido com gateways de pagamento antes. Se formos pensar no tamanho dessa user story, ela poderia levar semanas para ser desenvolvida por completo, se considerarmos o “valor” esperado pelo cliente, o PDF no e-mail, dessa forma não se encaixaria no Estimable e nem no Small. Mas uma API de envio de mensagens pode ser usada pelo time de marketing, por exemplo. O gateway de pagamento também já pode ser utilizado por outros times. Da mesma maneira o gerador de PDF já tem valor para outras equipes dentro do projeto. Além de que uma PoC também serve para validar uma hipótese, nos ajudando a mudar de rumo mais rápido, caso o conceito não seja provado. O que também, se formos pensar, é valor.

Dessa forma, esse “épico”, poderia ser quebrado como descrito acima, criando cerca de 4 US, que também geram valor sozinhas. Valor que provavelmente não será entregue somente ao cliente final, mas sim aos times de operações, marketing e suporte. Pensar no cliente externo é muito bom, mas devemos também pensar no cliente interno, aqueles envolvidos que quase sempre são esquecidos.

O conceito de valor é interpretativo demais, além de ser volátil e perecível. Tendo isso em vista, devemos ter bastante cuidado ao deixar de quebrar uma user story por achar que ela não está gerando o devido benefício, é importante lembrar que outras pessoas dentro do fluxo podem se beneficiar de um card quebrado. Dessa forma, se levamos semanas para entrega de uma user story, estamos depreciando o que poderia ter sido entregue, por conta da volatilidade. Fatiar cards, entregando histórias mais rápido auxilia numa geração de valor acelerada com risco reduzido da solução perecer.

E você? Como lida quando o assunto é a quebra de user stories dentro do seu time? Deixe sua opinião aí nos comentários

The post User Stories. Quebrar ou não quebrar? Eis a questão. first appeared on Plataformatec Blog.

Foi a primeira participação do time de gerentes de projetos da Plataformatec como palestrantes no evento e, neste post, gostaria de compartilhar algumas impressões sobre essa participação e o evento como um todo.

Primeiro dia

Eu e o Lucas Colucci tivemos a oportunidade de compartilhar no WBMA (a frente acadêmica do Agile Brazil) algumas descobertas do short paper que escrevemos sobre o uso de simulações de Monte Carlo como uma abordagem para predição de prazos de entrega em projetos de desenvolvimento de software.

A experiência de conversar com outros pesquisadores sobre a importância em gerar uma convergência entre a ciência (academia) e a aplicação (indústria) foi de extrema importância, afinal, acreditamos que esse tipo de discussão cria um fértil caminho para a inovação.

Caso você tenha interesse em entender como usamos o modelo estatístico de Monte Carlo em nossos projetos, recomendo que você leia o post, em inglês, intitulado Forecasting software project’s completion date through Monte Carlo Simulation.

Além disso, disponibilizamos gratuitamente, uma versão da nossa planilha com este modelo estatístico para que você teste no seu dia a dia. Para ter acesso ao material, basta clicar aqui.

No fim do primeiro dia, depois de muito café e ótimas conversas de corredor com novos e antigos amigos sobre os assuntos abordados no evento até então, tivemos uma nova participação do time da Plataformatec com o Wesley Zappelini.

A palestra conduzida por ele compartilhou estratégias para melhorar o fluxo de trabalho no processo de desenvolvimento de software.

Em linhas gerais, foram compartilhadas 5 maneiras para se trazer eficácia em processos que não estão saudáveis (mais informações podem ser lidas em 5 Strategies to improve software development workflow).

Após a palestra, interagimos com outras pessoas que continuam enfrentando problemas para otimizar o fluxo de desenvolvimento das equipes em que atuam.

Se você se interessou pelas formas de otimizar o fluxo de trabalho em times de desenvolvimento, não perca a oportunidade de ter acesso ao ebook gratuito que lançaremos nas próximas semanas explicando detalhadamente cada uma das estratégias que estamos adotando para melhorar o dia a dia de nossos projetos e clientes. Para ter acesso exclusivo ao material, clique aqui.

Segundo dia

Não houve apresentações do nosso time no segundo dia, portanto, pudemos assistir ótimas apresentações sobre:

• Desenvolvimento de equipes (obrigado, Sandy Mamoli, pela apresentação Creating Great Teams – How Self-Selection Lets People Excel);
• Escalando ágil dentro do governo;
• O uso de uma abordagem de fluxo unificado para a gestão de portfólio de projetos (parabéns Rafael Caceres);
• “No Estimates“.

Terceiro dia

No início do terceiro e último dia do Agile Brazil, tive a oportunidade de conversar com uma das poucas pessoas que conheci no evento que atuava em uma área fora da tecnologia, no caso, recursos humanos. Era a primeira vez que ela participava do evento e fiquei muito interessado em saber quais eram as suas impressões.

Papo vem, papo vai e ela compartilhou que ao participar do evento havia aprendido muito sobre os princípios ágeis, os problemas que uma transformação ágil traz para as empresas e como compreender e avaliar as habilidades necessárias ao contratar Gestores de Produtos e Agile Coaches.

Em outras palavras, ela resumiu que sua participação fazia parte de uma estratégia para aprimorar a visão sobre ágil a partir da ótica de recursos humanos.

O relato dela reforça a ideia de que para o ágil de fato fazer parte da cultura de uma organização ele deve ser entendido por todos. Como diria meu amigo João Britto: “o ágil tem que estar no coração das pessoas”.

Nossa última participação no evento aconteceu com o Breno Campos, com a palestra sobre métricas de processo para melhorar o desenvolvimento de software, assunto que temos abordado em outros posts aqui no blog.

Foi lindo ver a sala cheia de pessoas interessadas em saber de que maneira métricas como lead time e throughput e, visualizações como o Cumulative Flow Diagrams (CFD) e o gráfico de burn down, tem nos ajudado a trazer visibilidade e previsibilidade para nossos clientes.

Caso você tenha interesse em saber porque amamos métricas aqui na Plataformatec, leia os seguintes posts:

• Why we love metrics? Learning with lead time.
• Why we love metrics? Throughput and burnup charts.
• Why we love metrics? Cumulative flow diagrams.

Ainda falando sobre métricas, lancei recentemente, em português, um curso via email com algumas dicas de como usar métricas no processo de desenvolvimento de software de forma contínua. Caso tenha interesse em receber os emails com o conteúdo, clique aqui.

Conclusão

Essa foi a primeira vez que estive no Agile Brazil e uma coisa que me chamou a atenção foi o tamanho do evento (mais de 800 pessoas). Outro ponto interessante foi a qualidade e a diversidade das palestras. O Brasil, como você sabe, é “um país com tamanho de continente”, portanto, conversar com pessoas de todas as regiões do país me mostrou o quão amplo é o movimento ágil em terras tupiniquins.

Ano que vem o evento acontecerá em Belém, Pará, e espero estar por lá comendo açaí e trocando mais ideias sobre como melhorar os negócios a partir de processos ágeis.

E você? Como foi o seu Agile Brazil 2016? Compartilhe suas impressões nos comentários abaixo

The post Nossa participação no Agile Brazil 2016 first appeared on Plataformatec Blog.

But there are also technical impediments, those you annoy ask your beloved developer teammates for help if you don’t usually code.

The truth is that big part of those roadblocks can be tackled with a single line of code. Yes, you can work on low hanging fruits and have a lot of fun!

Which technical impediments can you work on?

Recently I had the opportunity to code a little bit to help the team. I can suggest the following topics, where you can achieve positive outcomes with very little effort:

Outdated project readme files

It’s just text, but it’s a good opportunity to hone your GitHub and markdown skills without breaking stuff.

Besides helping a new member on his onboarding process, it will also spread the message that it’s important to keep it up to date.

Outdated Boxen manifests

Some of our folks use Boxen to set up their environments. We often forget to update the project’s manifest. One more chance to practice. Go for it, your teammates will be grateful when they perform another clean OSX install!

Front-end fixes (color, text, positioning, size, UI behavior)

They’re small, they’re easy to fix and may bore a developer to death. But to you it’s all new and rewarding. Those represent the majority of the commits I’ve done.

As you become more experienced and confident you can expand into other areas, it’s just a matter of curiosity and opportunity.

What are the benefits?

Between one commit and another I noticed some advantages. Below are some that might also work for you:

Codebase knowledge

As you perform fixes, you get in touch with different parts of the code. It will naturally increase your awareness of where things come from and where they belong. From now on when you hear about a bug you will probably track its origin with ease.

This also makes grooming sessions more productive, since you are more familiar with the effects a new feature will bring to the application, improving your negotiation superpowers.

Better communication and relationship

Good communication saves a tremendous amount of time and energy. When you deal with code, you learn the technical vocabulary. In your next conversation with the team, people won’t need to translate jargon so you can understand. The same applies in the opposite direction.

In my opinion, a manager that can code also increases the sense of fellowship, improving the overall relationship among team members.

The feeling of shipping code

My first commit made some checkboxes to be selected by default. Nothing big, I know, but when I saw the customer using it I realized that shipping code feels amazing!

This brings the sense of belonging and increases shared ownership. You should give it a try!

Working with Pull Requests

At my very first day at Plataformatec, I realized that all teams were using Pull Requests. Shortly after, I figured out why we were using this technique. But I really understood it when I first submitted one of my own. Reading code and discussions added value to me, because I could see what was going on without interrupting people. Discussions also acted as a thermometer, revealing some insights about team relationship.

Learning how to write tests

Your code will break some tests (believe me, it will). Panic? Never! Go on and learn how to write and run automated tests. It’s not that hard. Ask your friends, they will be happy to teach you.
Learning about tests will help your communication with developers and reinforce quality culture as well.

Waste reduction

Waste is a fierce enemy and every chance to beat it must be taken. Coding can give you some opportunities to do so.

Every little fix you deal with is one less interruption and context switch for a developer. Every conversation you join in a Pull Request is a shorter feedback cycle being nurtured and less time being spent in queues.

These and other factors combined can positively impact the team’s performance.

Where to start?

I recommend following these steps:

Learning git and Pull Request basics

Here in Plataformatec we use GitHub, so finding documentation about Pull Requests wasn’t difficult. If you use it as well, you can browse Github’s Help and even use our Guidelines as a reference. If you don’t, I’m sure you can find plenty of content about your version control tool with a simple Google search.

Practicing in a controlled environment

Look for a repository that you can commit without spreading panic if you mess things up. For instance, I have practiced in our Campfire bot. If you don’t find any appropriate repository, you can fork a public project on GitHub and use it as your sandbox.

In this phase my colleagues helped me a lot crafting my first Pull Request, I bet yours will do the same. Don’t be shy and ask them for help!

Looking for and working on impediments

You have just developed a new skill, now it’s time to use it! Look for things similar to those examples I suggested and invest a little time in them. A couple of fixes later you will be able to work more independently, and the results will start to come.

Is there any pitfalls in this practice?

If you do things in a careful and balanced way, they will happen just right. But there are some traps you should avoid:

Creating dependencies

Remember that you are coding to help removing obstacles. If you turn yourself into the person responsible for maintenance, you have just become a bottleneck for the system (or an irresponsible developer, as you prefer).

Forcing people to code

Despite the several advantages mentioned, not every manager likes to code. Don’t force people into doing it.

Micromanaging

Joining Pull Request discussions brings great value. Micromanaging doesn’t. Don’t even think of using Pull Request discussions as a control tool. Trust your team!

I hope this blog post can help you and your team to improve. Have you ever tried something like this? What are you thoughts about it? Share them with us in the comments below!

The post Coding can make you a better project manager first appeared on Plataformatec Blog.

Temos uma oportunidade para você. Veja abaixo como é ser um gerente de projetos na Plataformatec, e também como é a cultura da nossa empresa.

Sobre a Plataformatec

A Plataformatec é uma empresa de consultoria em desenvolvimento de projetos de software customizado. Usamos Agile, Ruby, Rails, Elixir e métodos de análise estratégica de negócios para ajudar nossos clientes a alcançarem seus objetivos. Nosso time é organizado em equipes compostas por um gerente de projetos e de dois a seis desenvolvedores que encaram os seguintes desafios:

• entender como um projeto de software se encaixa na estratégia de um cliente e como esse projeto fará com que o cliente alcance seus objetivos
• ajudar o cliente a definir e esclarecer os objetivos de negócio
• criar um roadmap em formato de release backlog, pronto para ser transformado em software
• desenvolver software de modo iterativo, incremental e colaborativo

Por entendermos que a entrega de resultados é de responsabilidade da equipe inteira, não existe hierarquia dentro de uma equipe. Cada pessoa cumpre seu papel da melhor maneira possível para atingir os objetivos do cliente. Não queremos apenas clientes, nosso objetivo é termos fãs.

Como empresa, adoramos compartilhar nosso trabalho e a produção de conhecimento. Mantemos vários projetos open-source, criamos nossa própria linguagem de programação, escrevemos três livros sobre desenvolvimento de software e palestramos em dezenas de eventos de desenvolvimento e agile. Além disso, somos referência mundial na comunidade de Ruby on Rails.

Melhoria contínua sempre esteve presente em nosso DNA. Atuamos no mercado há quase seis anos e desde sempre aplicamos a filosofia agile na empresa inteira, do time de projetos ao RH, do time de vendas ao administrativo.

Nós amamos nosso trabalho.

Sobre a vaga

O que um gerente de projetos faz na Plataformatec

Nossos gerentes de projetos não seguem a chamada linha tradicional. O principal objetivo do nosso GP é potencializar o trabalho do restante da equipe. Para isso, ele mistura atividades de um gerente de projetos, mas também de scrum master, analista de requisitos e proxy de PO.

Algumas atividades típicas do nosso gerente de projetos são:

• participar do entendimento dos objetivos de negócio do cliente
• ajudar o cliente a transformar suas ideias em requisitos de software
• facilitar a comunicação do time com o cliente
• organizar e acompanhar as releases do projeto
• ajudar o cliente a otimizar o escopo do projeto para maximizar o valor de negócio no período do projeto
• planejar e conduzir as cerimônias do agile: planning, daily, grooming, review e retrospectiva
• monitorar a velocidade de entrega e indicadores de sucesso do projeto
• retirar impedimentos da equipe

Requisitos para a vaga

• Educação
  • ensino superior completo em curso da área de computação
  • inglês intermediário (oral e escrito)
• Experiência
  • 1 ano em gestão de projetos de software
  • 1 ano em gestão de projetos com metodologias ágeis (Scrum, Kanban, Lean etc)
• Skills
  • apresentar habilidade analítica
  • ser orientado a resultados
  • gostar de aprender
  • ter boa comunicação (verbal e escrita)
  • ser capaz de comunicar informações técnicas para pessoas não técnicas

• Disponibilidade para trabalhar em SP

Como participar do processo seletivo

Para participar no processo seletivo visite http://plataformatec.com.br/careers e envie seu curriculum. Veja também nossa página no Facebook para conhecer mais sobre o nosso time e nosso escritório.

Nós queremos pessoas que compartilhem dos nossos valores, que se importem com o que fazem e que não cansem de aprender e de se superarem.

Se você compartilha da nossa visão, participe do processo seletivo. Se você conhece alguém que possa se interessar, indique para seu amigo.

The post Estamos contratando gerentes de projetos first appeared on Plataformatec Blog.