Introduction

When we use WIP limit, we limit the number of concurrent tasks. It could be a limit to each column of a Kanban Board; it could be a limit to the whole system; or even a limit to a set of steps of the process.

The idea behind limiting the work in progress is to work side-by-side with Little’s Law and try to improve the flow of the system, diminishing the lead time (LT) of a work item. And that works like a charm for machines. For software development? The relationship between WIP, LT and throughput is not that straightforward.

People are different

When we have a chain of machines linked together, in which the output from one feeds the input of other, everything is easier to predict. Now, imagine a situation in which:

• Items entering the first machine are not always the same size. And the machines don’t follow a linear relationship between size and time to complete a task.
• Each machine can, unpredictably, change its behavior. One week, it may receive an input of size x and generate its outcome in 1 hour. In another week, it will, unpredictably, take 3 hours to produce the same result.

Things start to get tricky, right?

WIP Saturation Chart

From my experience, some readings and even the way I work, I saw that different people work best with different workloads. I believe that a chart of WIP by the throughput of a person follow something like this:

This chart was taken from https://www.infoq.com/articles/how-kanban-works.

Some people work best with more than one task at a time. For different reasons. They might get unmotivated with few responsibilities, or it might be easy for them to rapidly change focus between tasks, for example. On the other hand, other people have a really difficult time changing focus and handling many tasks at once.

Other than depending on the person, it also depends on the project: it might involve third-parties that regularly block their work, it might have a testing process that takes weeks or months to finish, etc.

So, how can we come up with a single number that will magically fit all those curves under the same process? You can’t. But that doesn’t mean you shouldn’t.

So what? Should I just go crazy and forget limits?

As I said, it is just impossible to get a number that limits the work of everyone in an optimal manner. But that doesn’t mean you shouldn’t use one. I see, until the time of this post, two options for two different contexts:

1. You have someone looking at your process. If you have a Project Manager, an Agile Coach, a Scrum Master or other person that takes care of your process, you don’t need WIP limits. You need WIP management. This person can better understand how each person works and alert people to the amount of WIP according to each individual necessity as well as the type of project. I’d only use WIP Limits here to give process ownership to the rest of the team. This means that the person looking at the process would be actually temporary.
2. You don’t have a process guru. In this case, limiting the WIP with numbers and trying to tune it with time will give you a better process. It will not give you the optimal outcome, but it will unquestionably give you a better result.

Conclusion

WIP limit works. It will improve your process. But it is not a silver-bullet (I feel like a parrot repeating this). Look at your context (people + project) and use whatever delivers a better outcome.

What do you think? Do you believe in WIP Limits or not? Leave your comments below!

The post WIP Limit – A further study first appeared on Plataformatec Blog.

Esta ação é mais indicada antes de começar um projeto ou nas primeiras semanas de desenvolvimento, pois é quando normalmente há mais flexibilidade para mudanças de prazos.

Na nossa experiência, já vimos diversos motivos para uma definição de prazo imprópria em um projeto, no entanto a mais recorrente é a falta ou falha de comunicação entre o CTO e o CEO. Com isso, vamos focar em como melhorar essa comunicação para que seja possível alinhar as decisões de negócio com as decisões de tecnologia.

Sabe-se que a área de desenvolvimento de software segue processos que diferem não só do resto da indústria mas muitas vezes difere também das outras áreas na mesma empresa. A quantidade de incertezas são, geralmente, maiores e faz com que o tempo para terminar um projeto seja altamente variável mesmo quando, aparentemente, tenha natureza conhecida. E essa diferença precisa ser entendida por ambos CTO e CEO.

As causas desse desalinhamento podem ser:

1. Falta de comunicação quando decisões de negócio e tecnologia são tomadas. Essas duas decisões precisam estar em constante harmonia pois uma é o que impulsiona a outra.
2. Falta de priorização das demandas. Às vezes existem muitas features para serem desenvolvidas de uma vez, sem qualquer priorização. Isso faz com que o processo de desenvolvimento fique saturado e demore para dar vazão a toda essa demanda.
3. Conflito de mentalidade. Devido aos diferentes backgrounds dos envolvidos e, portanto, diferentes visões sobre a empresa, a relação entre CTO e CEO pode se tornar deficiente e conflitante. Isso impede a evolução do processo por não haver acordos.

Por mais que seja possível dar um manual com um passo-a-passo do que se deve fazer para melhorar essa relação, tudo se resumiria a uma ação: melhorar a comunicação.

Quando você se encontra em posições de alta responsabilidade, você precisa ter um entendimento maior dos seus pares e o trabalho que estes exercem para que consigam, juntos, traçar o futuro da empresa. Por isso, para melhorar a comunicação, é necessário entender melhor como funciona a tomada de decisões do CEO, quais são as estratégias da empresa para os próximos meses e anos e porque elas são importantes.

Com isso feito, é necessária a explicação de como um processo de desenvolvimento de software difere de outros processos, e como lidar com isso da melhor maneira possível. Com ambas as partes a par dos caminhos que precisam ser tomados, é possível alinhar prazos de modo mais fácil.

The post Definição de prazo em projetos de software first appeared on Plataformatec Blog.

As rubyists and railers, we already know there are solutions, like God, that do this job for us. However, there are another solutions, like Bluepill. Bluepill is a process monitoring tool like God, but, unlike God, it doesn’t have memory leak, according to its authors.

Well, as I don’t want to wake up in the dawn to restart my Delayed Job process, and neither I want to restart my God process because of memory leaking, I decided to use Bluepill. But, how I use Bluepill to monitor my Delayed Job process?

In order to configure Bluepill to monitor Delayed Job, and use Capistrano to automate some tasks, we have basically 4 steps:

1. Install and configure Delayed Job
2. Install and configure Bluepill
3. Write a Capistrano Recipe for Bluepill
4. Set some stuff in /etc/sudoers

Let’s take a look at each step.

Installing and configuring Delayed Job

Installing and configuring Delayed Job is super simple, just read the project’s README, which is very clear. I also recommend watching the RailsCast episode about Delayed Job, there is some good information there, like using the Delayed Job CollectiveIdea’s fork, instead of the original repo’s version.

Installing and configuring Bluepill

There’s no secret in installing Bluepill too, you just need to read the project’s README and follow its steps.

In the confiuration part, you can see all the options in the README too. In my case, the configuration file is at RAILS_ROOT/config/production.pill.

Bluepill.application("my_app") do |app|
  app.process("delayed_job") do |process|
    process.working_dir = "/home/deploy/my_app/current"

    process.start_grace_time    = 10.seconds
    process.stop_grace_time     = 10.seconds
    process.restart_grace_time  = 10.seconds

    process.start_command = "ruby script/delayed_job -e production start"
    process.stop_command  = "ruby script/delayed_job -e production stop"

    process.pid_file = "/home/deploy/my_app/shared/pids/delayed_job.pid"
    process.uid = "deploy"
    process.gid = "deploy"
  end
end

However, I had a little problem between the interaction of Bluepill and Delayed Job. Delayed Job is not interpreting very well the -e production flag. You can see more details about that in an issue I opened.

The first solution I thought was to use RAILS_ENV=production ruby script/delayed_job start, however, for some reason that I don’t know exactly, it didn’t work.

So, the solution I came up with was to modify the file in RAILS_ROOT/script/delayed_job to the following one:

#!/usr/bin/env ruby

# TODO improve the line of code below
# The line below is just a hack while we wait the delayed job guys answer the following issue
# http://github.com/collectiveidea/delayed_job/issues#issue/38
ENV['RAILS_ENV'] ||= "production"
require File.expand_path(File.join(File.dirname(__FILE__), '..', 'config', 'environment'))
require 'delayed/command'
Delayed::Command.new(ARGV).daemonize

As the -e production was not being interpreted properly by Delayed Job, I’m setting manually the RAILS_ENV to production (line 6), therefore I’m supposing that you are using Bluepill to monitor processes that are in a production environment.

Capistrano recipe for Bluepill

In order to automate the start and stop Bluepill’s tasks, I wrote the following capistrano’s recipe:

# deploy credentials
set :user, "deploy"
set :deploy_to, "/home/deploy/#{application}"
set :use_sudo, false
set :rails_env, "production"

# Bluepill related tasks
after "deploy:update", "bluepill:quit", "bluepill:start"
namespace :bluepill do
  desc "Stop processes that bluepill is monitoring and quit bluepill"
  task :quit, :roles => [:app] do
    sudo "bluepill stop"
    sudo "bluepill quit"
  end

  desc "Load bluepill configuration and start it"
  task :start, :roles => [:app] do
    sudo "bluepill load /home/deploy/my_app/current/config/production.pill"
  end

  desc "Prints bluepills monitored processes statuses"
  task :status, :roles => [:app] do
    sudo "bluepill status"
  end
end

Note that instead of using the run capistrano’s method, I’m using the sudo method. I’m doing this because the bluepill command must be run as root. And that, takes us to the next topic.

/etc/sudoers

Since I need to run the bluepill command as root, should I change from set :user, "deploy" to set :user, "root"? I think it’s not a good idea, we don’t like to give root access to anything, even to deployment. So, what should I do? It’s simple, you just need to edit your sudoers file.

In order to do this, you need to use the visudo command to open and edit the /etc/sudoers file. Once with the file opened, just add the following line to the end of the file:

deploy ALL=(ALL) NOPASSWD: /usr/local/bin/bluepill

Now, you’re done, the deploy user already can do sudo bluepill without giving any password. Problem solved without opening security holes.

After these 4 steps, you’re ready to sleep at night without worrying about your Delayed Job process. And, if you want to know the status of the monitored processes by Buepill, you just need to run the following capistrano task in your local machine:

cap bluepill:status

And you, what are your solutions to sleep in peace?

Update: if are having trouble with restarting Bluepill with Capistrano, take a look at this.

The post Monitoring Delayed Job with Bluepill and Capistrano first appeared on Plataformatec Blog.