In the last decade, Plataformatec has also created and maintained a range of open source projects. In the next paragraphs, I will describe what the next steps are for the open source projects currently owned by Plataformatec.

We are very proud of the contributions we have made to open source communities throughout our history. We have built important projects in the Rails community, such as Devise, Simple Form, among others. We have also developed the Elixir programming language, which started as a Research & Development project inside Plataformatec, and today is used by companies around the world.

So what will happen with these projects from now on?

All of the projects above have one thing in common: they were created and maintained by passionate individuals who wanted to make positive contributions to their communities. Without these individuals and their efforts, these projects would not have become what they are today. Therefore, it is only fair that Plataformatec gives these individuals control of these projects moving forward.

For the Elixir programming language in particular, José Valim and the Elixir Core Team will continue developing and maintaining the programming language in the same capacity as they have been doing over the last few years, independently from Plataformatec and Nubank. We are in touch with the Elixir Core Team to transfer all assets, including the existing trademarks and the Elixir website, to their control. The remaining Elixir projects will be transferred to José Valim and his team at Dashbit.

For all other Open Source projects under the Plataformatec organization on GitHub, we will reach out to the current maintainers and take the necessary steps to transfer the ownership of all relevant assets, including names, source code, and logos of such projects.

We are thankful to these communities for all the support and feedback they’ve given us throughout the years. We are glad to have been the home to these projects and to have worked with the teams that will continue shaping these projects from now on.

The post Important information about our Elixir and Ruby Open Source projects first appeared on Plataformatec Blog.

There is no arguing about how important tests are for our application.

But from time to time, when we are dealing with it, some questions came up on a daily basis.

A very common day-do-day case is our application relying on APIs and external libs, but one of the things we don’t want our test suite to do is to access the external world.

This can lead us to many undesired scenarios, for example: if we have a connection problem on an API test that hits the internet, the test will fail, causing our test suite to be intermittent.

How do we mock or stub a request?

Some libs can help us, I will talk about two of them.

Bypass

The first one I wanna talk about is Bypass.
It is a lib that simulates an External Server, it works to stub the layer closer to the request. The idea is that you remove the external layer and start to call Bypass, so now, instead of talking to the internet, you are talking to a local server that you have control of. This way you can keep your tests protected.

Let’s think about an example, we will build an application that needs to fetch data from an API, and we will create a LastfmClient module that will be responsible for doing that.

defmodule MyApp.Lastfm.Client do
  @moduledoc"""
  Search tracks

  https://www.last.fm/api/show/track.search
  """

  @api_url "https://ws.audioscrobbler.com/2.0/"

  def search(term, url \\ @api_url) do
    response = Mojito.request(method: :get, url: search_url(url, term))

    case response do
      {:ok, %{status_code: 200, body: body}} ->
        {:ok, response(body)}
      {:ok, %{status_code: 404}} ->
        {:not_found, "Not found"}
      {_, response} ->
        {:error, response}
    end
  end
end
Code language: PHP (php)

What this client does is fetch the tracks from our API and according to the type of the response return something. Not that different from most of the clients we wrote on a daily basis. Let’s test it now.

describe "search/2" do
  test "searches tracks by the term" do
    response = Client.search("The Kooks")

    assert {:ok, [
      %{
        "artist" => "The Kooks",
        "name" => "Seaside",
        "url" => "https://www.last.fm/music/The+Kooks/_/Seaside"
      }
    ]} = response
  end
end
Code language: PHP (php)

What’s the problem with this test?

It seems pretty straight forward we exercise the SUT and verify the expected outcome, but this is a fragile test because it is accessing the external world.

Every time we call the Client.search/2 we are hitting the internet. A lot of problems can happen here: if the internet is down the test will fail, if the internet is slow your suit test will be slow, you won’t have the feedback as fast as you need and will be less inclined to run the test suit, or your suit test will become intermittent and you won’t trust your tests anymore, meaning that when a real failure happens you won’t care.

How can we fix it?

And that’s when Bypass comes to our aid.

First, you will need to setup Bypass in your tests.

setup do
  bypass = Bypass.open()

  {:ok, bypass: bypass}
end
Code language: JavaScript (javascript)

And in your test, you will set up which scenarios you want to test. Is it a success call? A not found? How should your code behave in each scenario? Tell Bypass that.

describe "search/2" do
  test "searches tracks by the term", %{bypass: bypass} do
    Bypass.expect bypass, fn conn ->
      Plug.Conn.resp(conn, 200, payload())
    end

    response = Client.search("The Kooks", "http://localhost:/#{bypass.port}/")

    assert {:ok, [
      %{
        "artist" => "The Kooks",
        "name" => "Seaside",
        "url" => "https://www.last.fm/music/The+Kooks/_/Seaside"
      }
    ]} = response
  end
end

defp payload do
  ~s(
    {
      "results": {
        "@attr": {},
        "opensearch:Query": {
          "#text": "",
          "role": "request",
          "startPage": "1"
        },
        "opensearch:itemsPerPage": "20",
        "opensearch:startIndex": "0",
        "opensearch:totalResults": "51473",
        "trackmatches": {
          "track": [
            {
              "artist": "The Kooks",
              "image": [
                {
                  "#text": "https://lastfm.freetls.fastly.net/i/u/34s/2a96cbd8b46e442fc41c2b86b821562f.png",
                  "size": "small"
                },
                {
                  "#text": "https://lastfm.freetls.fastly.net/i/u/64s/2a96cbd8b46e442fc41c2b86b821562f.png",
                  "size": "medium"
                },
                {
                  "#text": "https://lastfm.freetls.fastly.net/i/u/174s/2a96cbd8b46e442fc41c2b86b821562f.png",
                  "size": "large"
                },
                {
                  "#text": "https://lastfm.freetls.fastly.net/i/u/300x300/2a96cbd8b46e442fc41c2b86b821562f.png",
                  "size": "extralarge"
                }
              ],
              "listeners": "851783",
              "mbid": "c9b89088-01cd-4d98-a1f4-3e4a00519320",
              "name": "Seaside",
              "streamable": "FIXME",
              "url": "https://www.last.fm/music/The+Kooks/_/Seaside"
            }
          ]
        }
      }
    }
  )
end
Code language: PHP (php)

When to use Bypass?

When you have code that needs to make an HTTP request. You need to know how your application will behave. For instance, if the API is down, will your application stop working?

But then comes some questions, if I have a module that depends on this Client implementation, will I need to repeat this Bypass code every time in my tests?
Why does another module need to know these implementation details if it is not dealing with the request?

Mox

Mox can help us with that. It forces you to implement explicit contracts in your application so we know what to expect.

Going back to our example, let’s implement a module called Playlist that will be responsible for fetching a list of songs by artist and give it a name.

defmodule MyApp.Playlist do
  alias MyApp.Lastfm.Client

  def artist(name) do
    {:ok, songs} = Client.search(name)

    %{
      name: "This is #{name}",
      songs: songs
    }
  end
end
Code language: JavaScript (javascript)

The simplest test we can write to this code would be something like:

describe "artist/1" do
  test "returns the songs by artist" do
    result = Playlist.artist("The Kooks")

    assert result["name"] == "This is The Kooks"
    assert Enum.any?(result["songs"], fn song ->
      song["artist"] == "The Kooks"
    end)
  end
end
Code language: JavaScript (javascript)

Since the Playlist depends on the Client, to have an accurate test we would need to stub the request with the payload response from the Lastfm API so we can make sure the Playlist behaves accordingly.

You don’t need to stub all the Client requests in the Playlist tests, you need to know what it returns and handle the responses, you need to have a explicit contract.

Let’s see how we can implement those contracts.

Behaviours

Elixir uses behaviours as a way to define a set of functions that have to be implemented by a module. You can compare them to interfaces in OOP.

Let’s create a file at lib/my_app/music.ex that says what our Client expects as an argument and what it returns:

defmodule MyApp.Music do
  @callback search(String.t()) :: map()
end
Code language: JavaScript (javascript)

In our config/config.exs file, let’s include two lines. The first one says which client we are using and the second one is the Lastfm API that we will remove from the default argument, just to keep the callback simple.

config :my_app, :music, MyApp.Lastfm.Client
config :my_app, :lastfm_api, "https://ws.audioscrobbler.com/2.0/"
Code language: JavaScript (javascript)

In our config/test.exs file, let’s include our mock module.

config :my_app, :music, MyApp.MusicMock
Code language: CSS (css)

In the test/test_helper file, let’s tell Mox which is the mock module that is responsible for mocking the calls to our behaviour.

Mox.defmock(MyApp.MusicMock, for: MyApp.Music)
Code language: CSS (css)

Let’s go back to our Playlist module, and let’s change the way we call the Client module, to use the config we just created.

defmodule MyApp.Playlist do
  @music Application.get_env(:my_app, :music)

  def artist(name) do
    {:ok, songs} = @music.search(name)

    %{
      "name" => "This is #{name}",
      "songs" => songs
    }
  end
end
Code language: PHP (php)

In our Client module let’s adopt the behaviour we created, and let’s change the API url to fetch from the config we created.

defmodule MyApp.Lastfm.Client do
  @moduledoc"""
  Search tracks

  https://www.last.fm/api/show/track.search
  """

  @behaviour MyApp.Music

  def search(term) do
    url = lastfm_api_url()
    response = Mojito.request(method: :get, url: search_url(url, term))

    case response do
      {:ok, %{status_code: 200, body: body}} ->
        {:ok, response(body)}
      {:ok, %{status_code: 404}} ->
        {:not_found, "Not found"}
      {_, response} ->
        {:error, response}
    end
  end

  defp lastfm_api_url do
    Application.get_env(:my_app, :lastfm_api)
  end
end
Code language: PHP (php)

We will need to change the test/my_app/lastfm/client_test.exs to change the env config for the API url on the setup of the test, but I’ll leave it to you to do that.

Finally, in our PlaylistTest we will need to import Mox.

import Mox

# Make sure mocks are verified when the test exits
setup :verify_on_exit!
Code language: PHP (php)

And in our test, we need to tell our MusicMock what is expected to return.

describe "artist/1" do
  test "returns the songs by artist" do
    MusicMock
    |> expect(:search, fn _name ->
      {
        :ok,
        [
          %{
            "artist" => "The Kooks",
            "name" => "Seaside",
            "url" => "https://www.last.fm/music/The+Kooks/_/Seaside"
          }
        ]
      }
    end)

    result = Playlist.artist("The Kooks")

    assert result["name"] == "This is The Kooks"
    assert Enum.any?(result["songs"], fn song ->
      song["artist"] == "The Kooks"
    end)
  end
end
Code language: PHP (php)

What’s the difference?

Looking at the code it seems that we still need to pass the list of music in the tests. But there is a difference, the music’s list is a dependency of the Playlist module, but we don’t know its internals, we don’t know from where we are fetching it, how the request response works, and all these details. The only thing we need to know at the Playlist module is that it depends on a list of songs.

One last thing before we go

We went through all that trouble to make sure the tests are protected from the outside world, but you know, Elixir has this amazing Doctest feature, and one can argue that this replaces the application tests.

That’s not the case, Doctests are not tests and you shouldn’t rely on it to make sure your application behaves the way you expect it to. Make sure you don’t use any code that hits the external world when you are writing your documentation, there is no way to mock calls and this can cause all the problems we already discussed.

That’s all folks

The code from this example can be found here, I hope it helps!

The post Elixir: What about tests? first appeared on Plataformatec Blog.

Assim como qualquer modelo, framework ou ferramenta, existe uma tendência natural das pessoas acreditarem que o artefato resolverá os problemas organizacionais simplesmente por estar sendo aplicado. A partir das minhas andanças como consultor, me deparei com diversas situações onde as pessoas disseram que tentaram aplicar os OKRs e não obtiveram sucesso.

No texto a seguir, compartilharei um compilado de aprendizados e dicas para quem já lida com o framework ou para quem está considerando levá-lo para o seu dia a dia.

1) Qual a relação entre OKR e pensamento estratégico?

Um grande desafio nas organizações diz respeito a como decompor sua estratégia. Tudo começa com a construção de um pensamento estratégico que, em linhas gerais, passa por três grandes etapas: (1) coleta de informações; (2) formulação de ideias; (3) planejamento das ações (essas diretrizes e mais dicas podem ser vistas em Strategic Thinking: A Step-by-step Approach to Strategy and Leadership).

É fundamental que a organização entenda o que está mudando no mercado em que ela atua, como a concorrência tem se posicionado diante de tais mudanças e como a organização está operando hoje.

Passada a etapa de entendimento do contexto, o próximo passo de um pensamento estratégico é o levantamento de desejos, hipóteses e necessidades. É importante que a organização crie uma visão futura inspiradora e que garanta a sustentabilidade do negócio diante dos desafios que ela enfrentará.

O último passo é o planejamento daquilo que será feito. A organização precisa compreender quais são as opções de ações e, com muita clareza, deverá escolher o que será feito e o que não será. Neste momento, é essencial que haja uma clareza do que é prioridade dentro de uma perspectiva de curto, médio e longo prazo. Costumo dizer que prioridade é uma palavra que não deveria ser colocada no plural porque quando tudo é prioridade, nada é prioridade.

Pois bem, então o que OKR tem a ver com o pensamento estratégico exposto acima?

Quando falamos que o OKR é a composição do que desejo alcançar (objetivo) e como vou medir o progresso (conjunto de resultados-chave), precisamos partir de uma referência, que no caso do pensamento estratégico se dá através da coleta de informações. Se eu não conheço meu contexto atual, como eu posso definir onde eu quero chegar?

Além do mais, uma visão clara é necessária para orientar o processo de criação dos OKRs. Quando a organização não consegue estabelecer seu norte, qualquer caminho (ou no caso OKR) servirá. O problema dessa condição é que ela gera desperdício de dinheiro, esforço e energia.

Por fim, os OKRs nos forçam a fazer escolhas quando precisamos pensar no que será o foco de um trimestre, por exemplo. Ao definir poucos objetivos, estamos garantindo que a organização estará voltada naquilo que é o mais importante para o horizonte de tempo determinado.

Portanto, lembre-se: sem estratégia, não faz sentido a aplicação de OKR.

2) Quais problemas você pode resolver com OKRs?

Se você deseja comunicar a estratégia da organização, melhorar a transparência, trazer senso de propósito para as equipes e conectar o trabalho das pessoas com os resultados do negócio, OKR pode ser uma boa forma de você chegar lá.

2.1 – Comunicação da estratégia

A partir do momento em que a organização tem a sua estratégia estabelecida, os OKRs que serão desenhados pelas equipes deverão se comunicar com a mesma. Em outras palavras, caso existam OKRs que não estão conectados com as diretrizes estratégicas do negócio, eles deveriam ser descartados.

2.2 Transparência

Ao acompanhar semanalmente o progresso dos resultados-chave, validar e comunicar mensalmente os resultados dos OKRs e refinar trimestralmente os avanços em um momento de inspeção e adaptação, a organização reduzirá uma natural assimetria de informação que existe nas hierarquias e nos silos departamentais. Ficou na dúvida de como aumentar a transparência? Siga o fluxo abaixo.

Ao atingirmos as cadências mencionadas na imagem acima, aumentamos a visibilidade do que está acontecendo no negócio e deixamos os problemas palpáveis para serem tratados.

2.3 Conexão do trabalho com os resultados

Ao atrelar as iniciativas (ex: projetos, evoluções de um produto) com os resultados do negócio, trazemos um senso de propósito que pode motivar e engajar as pessoas no trabalho que está sendo feito.

Como exercício, tenho proposto uma amarração onde toda iniciativa trabalhada por uma equipe (ex: projeto, história de usuário etc.) deve ter um objetivo e uma clareza do impacto no negócio, além da sua descrição e critério de término.

O exemplo abaixo é uma situação de uma equipe que, a priori, tinha recebido a “demanda” de contratar uma solução de força de vendas. Ao conectar tal demanda com o objetivo do negócio e com os resultados-chave, a equipe conseguiu ter maior entendimento da importância do trabalho que seria feito.

Ao unir a entrega com o resultado, você garantirá a necessidade das pessoas olharem os números e os dados da organização. Além disso, você evitará que a equipe invista tempo e esforço para atender uma demanda que não gera impacto nos objetivos do negócio. E em último caso, mas nem por isso menos importante, você forçará a equipe se questionar o porquê de estarem fazendo algo que não impacta diretamente nos objetivos do negócio.

3) Qual a importância das métricas na definição dos OKRs?

Indicadores de negócio são as melhores medidas para avaliar o progresso em direção aos objetivos. Se você está em busca de sair de um modelo onde há uma cobrança por entregas (output) e deseja ser cobrado por resultado (outcome), defina resultados-chave (key results) que se acoplem com os indicadores de performance (KPI) da organização.

Lembrando que a sigla OKR é composta de duas partes (objetivos e resultados-chave), um KPI que precisa ser melhorado será um excelente ponto de partida para criar um OKR e se tornará um resultado-chave para um objetivo.

Lembre-se: OKR e KPI funcionarão perfeitamente juntos dado que os KPIs ajudam a monitorar o desempenho e a identificar problemas e áreas de melhoria no modo atual de operar da organização. Já os OKRs, contribuem na resolução de problemas, na melhoria de processos e no impulsionamento de inovações.

Para exemplificar, gostaria de compartilhar um caso real de uma organização que tinha como objetivo “Expandir os talentos da área de produto” e possuía como indicadores de performance o tempo médio de contratação, o número de vagas ocupadas e a pesquisa de satisfação. Depois de uma sessão de definição, saímos com o seguinte OKR:

Objetivo: Expandir os talentos da área de produto.

Resultados-chave:

• Contratar 4 novas pessoas de desenvolvimento para aumentar a senioridade da equipe.
• Aumentar o resultado da pesquisa de satisfação de 75% (resultado no último trimestre) para 85%.
• Reduzir o tempo médio de contratação de 45 dias para 30 dias.

4) Dicas práticas

Antes de finalizar o texto gostaria, de compartilhar 6 dicas práticas para você revisar sua estratégia de adoção de OKR:

1. Tenha o apoio executivo: OKR, assim como qualquer outra mudança organizacional precisa do suporte executivo para acontecer. Acreditar que apenas movimentos locais (debaixo para cima) farão com que a transformação aconteça é começar o jogo perdendo. Portanto, é fundamental que os OKRs da empresa se desdobrem para os times.
2. Não defina muitos objetivos: independente do contexto (empresa, equipe, tribo etc.), tenha de 2 até 3 objetivos para garantir que as pessoas estejam focadas naquilo que importa durante o trimestre.
3. Tenha resultados-chave mensuráveis: se você não consegue medir, você não saberá se está alcançado o seu objetivo. Não criei resultados-chave para métricas que não existem. Se você quer ter bons OKRs, coloque um esforço para ter as métricas disponíveis.
4. Não tenha mais do que 3 resultados-chave por objetivo: se é muito difícil de medir um objetivo talvez ela possa ser repensando, reescrito ou reestruturado.
5. Deixe os resultados visíveis para todas as pessoas da organização: visibilidade é alma para um melhor alinhamento e para que os problemas que surgirem de fato sejam resolvidos.
6. Evite resultados-chave orientados por tarefas (ex: entrega de projetos): foque em resultados orientados ao negócio porque isso ajudará a organização a traduzir os benefícios de uma nova abordagem de trabalho e suportará a ideia de equipes multidisciplinares.

Conclusão

OKR é uma ótima forma de pensar de forma estratégica e fazer com que as pessoas colaborem na execução daquilo que a organização busca conquistar. O framework em si é bem simples, porém sua adoção, nem tanto.

Pensando em sistematizar a mensagem deste post, resolvi criar um Canvas que te ajudará no momento de desenvolver os OKRs na sua organização.

Basta seguir os passos sinalizados pelas setas e responder às perguntas necessárias em cada um dos quadrantes. Comece pela estratégia, defina os objetivos, crie os resultados-chave, priorize as iniciativas e defina as áreas que precisarão colaborar com aquele OKR. Cada linha do quadro representará um OKR.

E você, quais têm sido os desafios e os principais aprendizados com OKRs? O que achou do OKR Canvas?

Compartilhe comigo sua opinião nos comentários abaixo!

Referências:

• Como definir OKRs em equipes ágeis?
• The Art of the OKR
• Blog do Felipe Castro

The post OKR: lições aprendidas para você começar a aplicá-lo de forma efetiva first appeared on Plataformatec Blog.

Em praticamente todas as empresas que já trabalhei, existia (e imagino que ainda exista) algum tipo de dívida técnica. Em algumas, para não falar todas, presenciei o cabo-de-guerra entre a equipe técnica, desejando tratar esses itens e defendendo o porque são importantes, e os responsáveis pelo produto, promovendo a criação de novas features.

Neste post eu vou te dar pelo menos um bom motivo para pagar dívidas técnicas, deixar uma dica de quando fazê-las e uma sugestão de como priorizá-las.

Porque fazer

Facilidade de manutenção, ganho de performance, compatibilidade com novas tecnologias, diminuir o tempo que o time gasta lidando com os sintomas dessa dívida técnica (e claro, o tempo que seu time passa lidando com esses sintomas, ele está perdendo de fazer novas features, que melhorariam seu time-to-market)… Existem vários ótimos motivos pra investir esforço e resolver a causa raíz, mas eu vou falar só de um.

Quando todos argumentos se esgotarem e ainda assim ficar a impressão de que “isso é capricho de desenvolvedor”, ainda vale a pena. Por quê? Pela satisfação dos seus funcionários.

Qualquer empregador vai falar que achar mão de obra especializada é difícil. Será que não vale incluir um item no seu backlog pra manter um bom empregado?
Você ralou para achar um especialista, e agora que o encontrou, negligenciar a opinião dele pode gerar insatisfação.

Recentemente conversei com um gerente de produto de uma startup, e ele disse que uma das perguntas da entrevista que passou era: “se um desenvolvedor ameaçar sair caso um item X não seja desenvolvido, o que você faz?”
Segundo ele, várias respostas estariam certas na linha de entender esse item X, mas existe uma resposta errada: “é só um desenvolvedor, eu deixo sair”.

Talvez você não seja surpreendido com um funcionário falando isso explicitamente, mas ligue seu radar se a equipe reclamar muito de dívida técnica. Às vezes isso já é um indicativo da infelicidade desses profissionais e currículos podem já estar sendo disparados para outras empresas.

Quando fazer

Se você leu a seção acima e ficou convencido, ou já começou o texto com a intenção de lidar com dívida técnica, a partir daqui eu posso te ajudar.

Aceitar que vamos trabalhar com dívida técnica não significa que vamos parar tudo e ficar semanas focados nesses itens.

Importante: estou considerando aqui que os “juros” dessa dívida técnica estejam sob controle. Se não estamos fazendo nada da dívida e seria apenas uma melhoria para o processo, essa sugestão se aplica. Agora, se você tem um incêndio, talvez você precise de um plano de ação mais agressivo, incluindo talvez parar e trabalhar apenas na dívida técnica.

No universo do Scrum, o termo “hardening sprint” é usado para designar uma sprint inteira dedicada a consertar bugs e resolver dívidas técnicas. Deixo claro que por mais que o termo seja usado, o Scrum desaconselha totalmente essa prática, sugerindo por exemplo, considerar uma parte do esforço da sprint para tratar esses itens.

Recentemente estive com um time que tinha uma quantidade considerável de dívida técnica e, por alguns meses, até se dedicaram a trabalhar apenas nelas. Foi um período de insatisfação tanto das pessoas desenvolvedoras, quanto das pessoas de produto. Com o tempo, eles voltaram ao desenvolvimento de features, e o backlog de dívida técnica ficou parado, onerando capacity do time com pequenas demandas originadas das mesmas. Eles não trabalhavam com Scrum, nem nenhuma outra metodologia/framework. Existia, porém, um quadro tipo kanban (k minúsculo aqui).

A solução então para garantir que dívida técnica seria endereçada sem paralisar totalmente a entrega de features foi usar limites de WIP (Work in Progress).

O time não utilizava Kanban, nem limites de WIP (e nem era algo para se implantar no momento), mas chegamos num combinado:
Em qualquer dado momento, existirá um item de dívida técnica no quadro do time, sendo trabalhado.

Essa estrutura garantiu que existia um espaço para trabalhar em resolver dívida técnica, e tranquilizou stakeholders no sentido de mostrar que não iríamos “parar tudo” para trabalhar nesses itens.

Dependendo do tamanho do seu time e da sua necessidade, esse limite de WIP pode ser diferente de 1.

Essa ideia pode ser adaptada para um time com Kanban propriamente dito, com a criação de uma raia dedicada e limite de WIP considerando o tipo de demanda da “dívida técnica”.

Como priorizar

Não é só porque garantimos um espaço pra resolver itens de dívida técnica que não precisamos priorizá-las.

Se foi trazida a necessidade de fazer, é porque vamos ganhar alguma coisa, e se estamos falando de valor, podemos priorizar de alguma forma.

Dívida técnica, por natureza, não é algo que vai gerar valor para seu cliente ou usuário, pelo menos não diretamente – se gera valor, deveria estar com o resto do backlog para priorização. Como priorizar, então?

Dado esse dilema, achei na literatura referências à matriz GUT. Em resumo, avalia-se o backlog em Gravidade, Urgência e Tendência. Cada item recebe uma nota nessas três categorias, e o problema com somatória mais alta seria o mais prioritário. Porém isso não me atendia.

A maioria dos problemas não tinham gravidade mensuráveis, e urgência era só quando a bomba estourava. A tendência era uma incógnita.

Usei então a estrutura de BVP: Business Value Points. Seria a definição de critérios que faziam sentido para o time, com pesos ponderados.

Note que esses critérios só fazem sentido para a equipe que estava trabalhando comigo. Você pode usá-los como referência, mas pergunte-se se refletem totalmente a necessidade do seu time.

Existe um critério nessa lista ligado à valor monetário, mas seu peso é o menor, dado que os itens aqui não tem a natureza de impactar financeiramente a empresa, mas ainda assim pode ser relevante (até como desempate).

Daí, foi só jogar os itens e ver o resultado dado a média, considerando os pesos (dados fictícios):

O time então pegou o primeiro item da lista e começou a desenvolvê-lo.
Durante as cerimônias de planejamento, a matriz é revista e atualizada, para que assim que o item em WIP for finalizado, puxarmos o próximo.

Achou que este artigo te ajudou? Tem problemas com dívida técnica e não cobrimos aqui? Deixe nos comentários!

The post Dívida técnica: Por que fazer, quando fazer e como priorizar first appeared on Plataformatec Blog.

Trying to get a better understanding of this subject to talk to clients and stakeholders in general, I decided to collect real project data and analyze the relation between amount of story points of the cards and the time it took for each to be developed, counting since the time they started to be developed until the moment they are delivered to production, the famous Lead Time.

Disclaimers

Before we start, some disclaimers about the context of the project:

• Right in the first few weeks of the project we already had the first big problem with story points: subjectivity in estimate the cards. Why this card is worth 3? How do I know this card is twice or thrice the size of the X card? What do I consider in this estimative?
• Thus, it was suggested to the team to utilize some criteria to estimate, intending to reduce this subjectivity.
• My friend and colleague Henrique Oliveira suggested a Fibonacci-like matrix, taking into account T-Shirt Size estimates, to estimate the cards, that helped the team a lot. Check it below:

• Cards estimated as 13 points or higher were broken into smaller cards, as the only time we worked with a card with 13 points, it exceeded the timebox of the sprint, which was 10 business days. So we decide to do not let any card with 13 or more story points to be added to the sprint backlog.
• Cards were broken down into smaller cards in a way that they delivered something functional in production, so that the backend and frontend stayed together on the same card.

A look into the data

I began by collecting the data of the project as a whole and analyzing the lead time graph with all cards that had already been finished or that were in production.

After acquiring this data, I segmented them by the amount of story points and analyzed them individually, having the following graphs:

Cards with 1 story point

Cards with 2 story points

Cards with 3 story points

Cards with 5 story points

Cards with 8 story points

Cards with 13 story points

Data Analysis

After analyzing the data, I reached some conclusions:

• It’s possible to verify that cards worthing 3, 5 or 8 points have a development time (lead time) similar, not being possible to find a correlation between time and the number of story points (it is not scalar).
• If we take a category with plenty of samples, like the cards with 5 points, it’s evident they differ a lot, not being possible to make some affirmations such as “a card worth 5 points takes between X and Y days to finish” when X and Y a small interval of days (1 to 3 days). The same happens with cards with 3 and 8 points.

Observation: Data referring to cards worth 1, 2 or 13 story points were excluded from the individual analysis, because there was little data to be analyzed individually.

Other Analysis beyond story points x lead time

I reached more conclusions about the use of story points that I would like to share with you all:

• At the beginning of the project, when we started to use story points, the subjectivity was very high. By establishing some criteria for estimation, we were able to stabilize it, making the time of development vary a lot less, increasing predictability. If you want to develop this with your team, consider checking out this article from Mike Cohn.
• With the addition of more scoring criteria, like test complexity, dependency on people that are not in the team (internal or external to the company), risks related to the cards and more, we lowered the lead time variability and increased the card delivery rate by breaking the card into smaller ones.
• Many times people relate story points with only the development effort, and this makes the team consider only the time of the Execution of a task. Another point is that the testers/QAs and UXs/designers, have little to no involvement in the estimatives. Making the team think not only about development, but also about the duration of the process as a whole (considering the steps of code review, tests, deploy, etc) and inviting more people to share their concerns about the estimatives helps to improve the predictability of the team.
• With help from metrics like lead time breakdown and CFD, the process of stabilizing the scoring was much easier, as it made the team think about the whole process and showed in which step of the process the team was spending the most time with.

Conclusions

The major conclusions I had were:

• It wasn’t possible to relate time of development (lead time) with Story Points directly, as the goal of the study was.
• It is important to say Story Points should be used inside the team level. If you want to know more about this subject, I recommend the reading of this text from Troy Magennis.
• It was possible to increase the predictability of team delivery and stabilize the process of development using story points with other tools at the same time.
• There are indications that, when you add more criteria to the estimation to breakdown the cards into smaller cards, the smaller the risk/effort/complexity will be and, consequently, the predictability you also increase.
• An important point here is that story points and other estimative methods consider only the moments in which a demand is being worked on, and not consider/can’t predict the time that a demand will be staying in waiting to be worked on. Basically, the team considers how long it will take for a demand to be developed and tested, but don’t consider in this estimatives (as it is not possible to predict some points in the middle of the development) how long the demand will be staying in waiting to be tested, to be deployed or how long it will take to resolve a hypothetical impediment. In other words, the process efficiency will impact your lead time, and consequently, the relation between story points with the time of development. This way, it’s plausible that a user story of 1 story point takes the same amount of days that a 13 points user story to be delivered, because of the flow efficiency. If you would like to know more about process efficiency, check this article.

And if you were asked if you would use story points to estimate a deadline for a delivery of a project or card, what would you respond?

I would say that story points, like the matrix for complexity and uncertainty (T-shirt Size), are excellent tools to instigate your team in better breaking user stories down and help with improvements in the processes, however, to estimate deadlines, I prefer to utilize process metrics and other tools, like a Monte Carlo simulation to help predict when a set of cards will be delivered.

What about you? Do you have any experience with Story Points and time estimates? Have you passed through any similar scenario? What’s your opinion about what I shared in this text? Share with us commenting below or in this email contagil@plataformatec.com.br

The post Relation between Story Points and Development Time (Lead Time) first appeared on Plataformatec Blog.

Qual a sua teoria favorita sobre o papel de um líder? Para mim um resumo perfeito é esta fala do Jack Welch em What is the role of a leader. Em resumo, sem a pretensão de captar a emoção de ouvi-lo:

1. Ser o “Chief Meaning Officer”! Deixar claro para todas as pessoas à sua volta: para onde você está indo, por que você está indo e, mais importante, o que haverá para elas quando elas chegarem lá com você.
2. Remover os impedimentos do caminho para que as pessoas possam agir e fazer as coisas acontecerem. Quebre os silos, se livre das burocracias.
3. Ser generoso. Vibrar com o sucesso das pessoas.
4. Ser o “Chief Fun Officer”. Dê seus pulos para tornar o trabalho divertido!

E qual o papel de um líder em uma empresa de produtos digitais? Não deve ser nada diferente disso, certo? Mas afinal, como traduzir estes conceitos para a realidade de uma empresa de produtos?

Trazendo para este contexto, quem melhor traduz o papel de um líder é o Marty Cagan em Empowered Product Teams. Na minha opinião, este conteúdo é o mais relevante que ele publicou direcionado para líderes que estão à frente de empresas de produtos digitais. E por que é tão relevante? Porque coloca de uma forma mais tangível estratégia e cultura, temas muito falados mas pouco colocados em prática.

Motivos de resistência da liderança

Um tópico bem interessante deste artigo é a explicação do por que líderes resistem tanto para empoderar seus times e continuam mantendo o estilo comando-controle.

Segundo ele, existem duas formas de gerenciar uma empresa de produto:

• O jeito errado: “Na maioria das empresas, os times de tecnologia existem para atender o negócio”. De alguma forma, líderes de outras áreas de negócios (vendas, marketing, CEO) acabam direcionando o produto, que é apenas construído pelo time de tecnologia.
• O jeito certo: “Em empresa com forte cultura de produto, times de produto existem para um propósito muito diferente. Eles existem para atender os clientes, de formas que também atendam às necessidades do negócio”. Ou seja, o foco é o cliente e não stakeholders internos. Mas obviamente o produto também tem que ser sustentável para o negócio. Gibson Biddle diz algo semelhante de uma forma mais poética “encantar clientes, de maneiras que sejam lucrativas e difíceis de copiar”.

Marty Cagan conta que conversou com CEOs de várias empresas para entender porque eles continuam trabalhando do jeito errado com desenvolvimento de produtos, mesmo conhecendo o jeito certo. A resposta foi “falta de confiança” no time. A crença é que este modelo de trabalho (o jeito certo) só funciona em empresas que podem contratar profissionais extraordinários, como os do Google, Netflix, etc.

O curioso é que já existem muitos estudos que comprovam que times de alto desempenho não são formados por estrelas, mas sim por pessoas comuns. Aliás, estrelas muitas vezes atrapalham!

“They would be surprised at how ordinary the vast majority of the members of these company’s product teams actually are, and that maybe the important difference lies elsewhere.”

Outra justificativa comum para não empoderar os times é “pessoas de tecnologia não entendem de negócios”! Quem de tecnologia já não precisou respirar bem fundo quando ouviu esta frase? Times de produto precisam do contexto de negócio, para que possam descobrir a melhor forma de resolver problemas dos clientes.

A falta de confiança certamente não é um problema fácil de resolver, já que em muitas situações os times são de fato muito inexperientes. Mas é importante caminhar nesta direção, desenvolvendo as pessoas para que elas possam atuar do jeito certo. Definitivamente, entrar em um ciclo vicioso de falta de estratégia, time inexperiente e comando-controle, não é um bom caminho!

Papel do líder no “jeito certo” de trabalhar

Trazendo para o contexto de empresas de produto, como ser o “Chief Meaning Officer”? Ou seja, como deixar claro para as pessoas para onde você está indo e por que. A Visão e Estratégia de produto são essenciais para trazer este significado e dar um direcionamento ao time, para ele possa trabalhar de forma autônoma.

Visão de Produto

A visão de produto descreve o futuro que queremos criar, em 2 a 5 anos. A importância desta visão é setar um norte inspirador e delimitar um contexto de atuação. Em startups, é muito comum o foco do produto principal ir se perdendo ou o escopo de atuação ficar muito amplo. Isto acontece principalmente quando empresas recebem investimentos e começam a diversificar o portfólio. Sem uma visão para guiar e delimitar as fronteiras, os times de produto podem ficar sem foco, não atingirem resultados e a liderança voltar a assumir o estilo comando-controle.

Estratégia de Produto

A estratégia define qual caminho precisa ser seguido para se alcançar a visão. Um erro comum na definição da estratégia é não fazer uma reflexão do momento atual e traçar uma estratégia pouco realista. Em Escaping the Building Trap, Melissa Peri apresenta um framework bem interessante para definição de estratégia.

Outro artefato, o Product Principles, também ajuda a delimitar o contexto e facilita decisões em priorização. Os princípios descrevem a natureza dos produtos que pretendemos desenvolver e reflexões sobre nossas crenças sobre o que é importante.

Exemplo de coisas que podem ser interessantes explicitar no Product Principles:

• Vamos aceitar desenvolver customizações (features específicas para alguns clientes)?
• Se o produto tem mais de um cliente (vendedores e compradores, por ex), quem vamos priorizar?
• O que é mais importante, velocidade ou qualidade?
• Queremos desenvolver tudo sozinhos ou vamos fazer parcerias?

Uma vez que a Visão e Estratégia estejam definidas, como garantir que elas sejam seguidas? Em empresas com muitos times, como desdobrar a estratégia para os diversos times e manter o alinhamento? No artigo How to Run a Quarterly Product Strategy Meeting, Gibson Biddle, apresenta um processo bem interessante para definição de estratégia de times e também um passo a passo de como estruturar uma reunião de “review” de produto.

Mais sobre o jeito certo de trabalhar

Outras fontes interessantes para entender este jeito certo de trabalhar:

• Escaping the Building Trap, Melissa Perri. Apresenta uma boa explicação da relação entre Customer, Business e o papel do Product Manager em Product-led e Sales-led organizations. As dicas para desenhar estratégia também são valiosas.
• Product team vs Feature Team, Marty Cagan. Reforça de forma bem didática e enfática os conceitos já apresentados em Empowered Product Teams. Feature team é o jeito errado de se trabalhar, no qual os times de produto existem somente para entregar features já priorizadas em um roadmap.
• Coach – Customer Centricity, Marty Cagan. Explica quem são os verdadeiros clientes de um Product Manager: as pessoas que usam o produto! Stakeholders internos (vendas, CEO, etc) não podem ser considerados clientes. Afinal, o time de produto não existe para servir ao negócio!
• Digital or Traditional, Joca Torres. Reflete sobre a diferença do escopo de atuação do Product Manager em empresas Digitais (que tem como core do negócio um software), empresas Tradicionais (que tem como core outros tipos de produto) e empresas que não vendem software, mas tem o software como parte vital do negócio, denominadas born-digital traditional company.

Resumindo

Uma das responsabilidade principais de um líder de produto é definir um norte para o produto e garantir que toda empresa esteja alinhada à ele. Para isso:

• Defina a visão e estratégia de produtos.
• Divulgue para toda a empresa, não apenas para os times de Produto e Engenharia.
• Desdobre a estratégia para todos times.
• Crie cerimônias para garantir o alinhamento entre todos os times.

Caso isso já esteja sendo feito, mas mesmo assim os times não estejam trabalhando com autonomia e alcançando resultados, vale refletir:

• Existe resistência da liderança para empoderar os times?
• Existe um entendimento sobre o papel de um time de produto?
• Se não existe confiança no time, qual é o plano para desenvolver e empoderar este time?

Como tem sido a liderança de produto na sua empresa? Deixe sua impressão nos comentários abaixo.

The post O Papel do Líder de Produto first appeared on Plataformatec Blog.