Ricardo Vargas publicou em seu site, para download gratuito, com o intuito de divulgar o PMBOK Guide.

O Fluxo do PMBOK 4a Edição está disponível nas versões Português (Colorido ou preto e branco) e Inglês (Colorido ou preto e branco).

Para efetuar o download acesse o endereço abaixo: http://www.ricardo-vargas.com/pt/downloads/?type=download_files&category=216

Essa pesquisa não faz parte de nenhum estudo sério, ou ao menos tem a intenção de ser algo que possa ser tomado como referência para qualquer coisa.

Apenas hoje fiquei curioso, qual seria o retorno de pesquisa em um site de colocação profissional das palavras: scrum, agile, pmi e pmp.

Seguem os resultados:

Scrum

Agile

PMI

PMP

PMI e Scrum

O link utilizado para a pesquisa foi: http://v.catho.com.br/buscar/empregos/?tipoBusca=palavra_chave&perfil_id=4

No evento “PMI Global Congress 2009“, sendo realizado nos dias 10 a 13 de Outubro em Orlando, estão sendo lançadas novas comunidades de prática. A primeira da lista é a “CoP Agile“.

Confira no link PMI Launches New Communities of Practice

Fonte: Twitter Ricardo Vargas

Bas de Baar do blog e video podcasts “Project Shrink“, que discute liderança em gerencimento de projetos, entrevista Jesse Fewell em seu podcast episódio 28. Jesse é o líder de um grupo de integrantes do PMI, interessados nas práticas ágeis.

Na entrevista são discutidos diversos pontos, dentre eles, o que a comunidade ágil pode contribuir com o gerenciamento de projetos tradicional e vice-versa.

Mais Informações:
    PMI lança Comunidade de Práticas Ágeis na Agile2009
    Oficializada a comunidade “PMI Agile”!
    

O Ricardo Vargas liberou no YouTube uma série de 8 vídeos com o treinamento “Excelência em Projetos com o Microsoft Project”, que apresenta por um processo simples e interativo, os conceitos básicos do gerenciamento de projetos utilizando o Microsoft Project.

Seguem os vídeos:

Parte 1:

Parte 2:

Parte 3:

Parte 4:

Parte 5:

Parte 6:

Parte 7:

Parte 8:

Ricardo Viana Vargas é especialista em planejamento, gerenciamento e controle de projetos. Atualmente atua como presidente da Macrosolutions, uma empresa de consultoria de gerenciamento de projetos no Brasil com mais de 20 perfis complexos de projetos do Brasil e América Latina, abrangendo um portifólio de investimentos de mais de $5 bilhões. Ricardo Vargas é membro do PMI desde 1997, e atualmente ocupa a posição de diretoria do Board do PMI. Participou da revisão do PMBOK®, Project Management Body of Knowledge (PMBOK® Guide), e foi membro da equipe do projeto de atualização do PMBOK® Guide em 2004. Também foi presidente do Comitê de Verificação de Tradução para língua portuguesa do PMBOK® Guide 2004.

Postado por Chris Sims, traduzido por Luiz Fernando Signorelli em 10 Set 2009 12:26 PM

O Project Management Institute (PMI) lançou oficialmente a sua Comunidade de Práticas Ágeis na conferência Agile2009. A missão do grupo é: "Equipar os membros do PMI e com habilidades e conhecimentos de metodologias Ágeis" Mike Griffiths foi o responsável por fazer as coisas andarem, quando ele lançou um desafio ao PMI na Agile 2007, para que este formasse um grupo de trabalho específico para metodologias ágeis.

O grupo de voluntários que criou a Comunidade de Práticas Ágeis (CoP), aplicou práticas ágeis durante o trabalho de criação da própria organização. Eles trabalharam com iterações de 2 semanas e fizeram retrospectivas visando melhorar seus processos. Jesse Fewell, desempenhou um papel análogo ao Product Owner de uma equipe Scrum. Em uma entrevista gravada para o Project Shrink Podcast, Jesse deu um exemplo de como a equipe repriorizou seu"backlog" com o intuito de entregar mais valor rapidamente. O resultado foi a criação de um wiki onde as pessoas puderam encontrar informações sobre o grupo, e sobre metodologias ágeis, mesmo antes de todo o trabalho administrativo de formação do grupo estivesse completo.

O lançamento foi comemorado em uma festa promovida pela ThoughtWorks, na sua sede em Chicago. O evento atraiu mais de 200 pessoas, incluindo Martin Fowler, Jim Highsmith, Ward Cunningham, Alistair Cockburn .

O lançamento não foi o único evento relacionado ao PMI durante a conferência Agile2009.Na "Fresher’s Fair " da primeira noite Jesse, Ainsley Nies, Brian Bozzuto, Sanjiv Agostinho, e outros, notificaram um maior envolvimento e interesse do PMI na comunidade ágil.

O que é um Gerente de Projetos Ágil? foi uma sessão interativa, apresentada por Pat Reed e Jesse Fewell, que explorou o papel do gerente de projetos em um contexto ágil.

Mike Cottmeyer apresentou O PMP Ágil: Ensinando novos truques a um cachorro velho, que examinou os processos e as áreas de conhecimento do PMI e como adaptá-los aos projetos ágeis.

No último dia de sessões oficiais, Jesse apresentou a história de como a Comunidade de Práticas Ágeis do PMI foi criada, no Growing PMI Using Agile (Melhorando o PMI usando metodologias ágeis) .

A equipe distribuída responsável por fazer da Comunidade de Práticas Ágeis do PMI uma realidade inclui:

• Sanjiv Agostinho
• Rodney Stijns
• Brian Bozzuto
• Mike Cottmeyer
• Mike Griffiths
• Jean Laporte
• Dan Mezick
• Ainsley Nies
• Dave Antes
• Pat Reed
• George Schlitz
• Michele invasao
• Bob Tarne

Fonte: InfoQ

Matthew Hotle
27 de julho de 2009

Transformar uma empresa em uma organização de projetos e uma organização de suporte não é incomum. Existem várias razões para que isso aconteça, mas essa mudança definitivamente não é a solução para orçamentos restritos.

Considerações básicas
- Modificar a estrutura da sua empresa deve ser a última opção a se levar em conta.
- Habilidades e disposição são mais importantes do que uma estrutura teoricamente perfeita.

Recomendações
- Não faça mudanças organizacionais para resolver falhas de processo. Foque no procedimento antes de tudo.
- Alterne tarefas, por exemplo, para estimular a disposição dos funcionários caso opte por um modelo de segmentação.
- Verifique se os contratos entre provedor e clientes (em inglês service-level agreements – SLAs) continuam válidos antes de dar início à mudança organizacional.

O que você precisa saber

Os clientes normalmente perguntam se deveriam dividir sua equipe em projetos (a que normalmente se referem como desenvolvimento, mas na verdade são estratégias de aperfeiçoamento e para obter novos contatos) e suporte.

Empresas que já seguem esse modelo de estrutura questionam se esta é a melhor escolha ou se deveriam retornar a um estilo de organização mais diversificado. Essa é uma decisão do tipo “será que a grama do vizinho é mais verde?”. A maioria das companhias que consideram a possibilidade de organizar sua estrutura dessa maneira estão na verdade tentando solucionar um de diversos problemas de processo.

- Os projetos estão atrasados (embora nunca estourem o orçamento) porque os recursos destinados a eles acabam sendo gastos com suporte.

- Funções de suporte exigem habilidade para lidar com múltiplas tarefas ao mesmo tempo.

- Recursos de suporte costumam ser fragmentados.

- Habilidades de suporte ou estão indisponíveis ou deixarão de existir em breve devido à transferencias ou a aposentarias.

- Relações disfuncionais entre grupos levam a conflitos morais e de gerenciamento.

Apenas modificar a estrutura da empresa não vai resolver nenhum desses problemas. Ao contrário, se esta for a única mudança da situação, eles ficarão mais graves em seis a 18 meses, simplesmente porque além de apresentar processos falhos a empresa terá de lidar com a ruptura de um padrão. Há bons motivos para alterar o modelo estrutural de uma companhia (esta não é uma pesquisa sobre quando mudar, mas sim sobre como mudar), porém essa decisão deve ser tomada cautelosamente, se levando em conta o potencial de solucionar problemas com novos processos.

ANÁLISE

A primeira regra para mudar o design de uma organização: não faça isso!

Nem sempre isso é verdade, obviamente. Entretanto, mexer constantemente nas relações hierárquicas essenciais ao bom funcionamento da companhia é um dos erros corporativos mais comuns. Essa é uma saída relativamente fácil porque os gerentes influenciam diretamente essas estruturas. Além disso, é um tipo de mudança que rapidamente se pode notar. Mas há dois inconvenientes:

- Mudar a estrutura de uma empresa implicará de seis a 18 meses de adaptação. Alguns funcionários se sentirão bem com seus novos chefes, outros nem tanto. Quando essas hierarquias são modificadas, há sempre um período posterior de familiarização. Haverá ainda uma fase na qual as tarefas deverão se encaixar ao novo modelo estrutural.

- Os processos falhos permanecem ineficazes. Esse é o ponto crucial. Muitas companhias tentam alterar sua estrutura porque precisam resolver problemas de processo, mas isso não funciona. Primeiro solucione a falha no procedimento, depois avalie se vale a pena implementar uma mudança estrutural.

Grande parte da atividade em que se fundamenta uma organização se origina de relacões informais e processos implícitos. As estruturas atribuem status ou poder a determinados cargos. Muitas empresas não estão cientes desse elemento subliminar e normalmente os prejudicam ou destroem durante restruturações. Justamente as estruturas e processos que precisam ser eliminados costumam sobreviver às mudanças. Várias empresas almejam solucionar problemas de planejamento e de recursos humanos segmentando suas estruturas. Vamos supor que essa separação é válida. Como ela deve acontecer?

Fundamentos de uma separação de projetos e suporte

Se você pretende segmentar sua empresa, precisa seguir os seguintes passos:

- Definir claramente o que é um “projeto” e quais atividades estão relacionadas com o “suporte”. Isso pode parecer simples, mas as empresas costumam chamar de projeto conjuntos amorfos de tarefas ou qualquer atividade que precise ser coordenada. Suponhamos que um projeto é uma tarefa que exige no mínimo 320 horas. Há uma explicação para isso. Baseando-se nas oito horas do plano de tarefas do Instituto de Gerenciamento de Projetos, chegamos a conclusão de que um projeto inclui cinco fases (demanda, avaliação/planejamento, organização, testes e implementação), e cada fase implica três atividades. Cada atividade envolve três tarefas (cinco fases: três atividades por fase e três tarefas por atividade), o que nos leva a um total de 320 horas. Todo o restante é suporte. Normalmente, há três tipos de suporte: reparação de falhas, pequenas mudanças ou aperfeiçoamento e questões relacionadas com as SLAs. Temas regulatórios entram em ambas as categorías. Caso a demanda por pequenas mudanças seja constante, deve ser incluída em suporte; senão devem ser classificadas como projetos e receber prioridade máxima.

- Para cada demanda, crie uma SLA. Recapitulando: suporte é solução de problemas, aperfeiçoamentos simples e outras atividades relacionadas com SLAs (responder a dúvidas de clientes, analisar possibilidades e assim por diante). Essas demandas precisam ser claramente definidas e traduzidas para uma SLA que eficazmente permita que a empresa ofereça o nível de serviço a que se propõe.

- Com base nas SLAs e na demanda, classifique a organização. Infelizmente a maioria das empresas que querem segmentar sua força de trabalho começam por essa etapa. Saber quantas pessoas devem ficar no setor de suporte é impossível antes de: 1 perceber a gravidade e a frequência das falhas dos projetos 2 quantas pessoas a empresa pretende pagar para implementar melhorias 3 quais outros serviços devem ser oferecidos, quando e como. Pode ser que tudo isso pareça simples. Mas agora devemos prestar atenção no principal desafio da mudança: as pessoas envolvidas nesse processo. Reparação de erros é uma atividade que exige profissionais que se sentem confortáveis trabalhando sob pressão e que são pragmáticos. Essas habilidades podem não ser raras, mas é comum haver pessoas dispostas a trabalhar no setor de suporte que não possuem essas habilidades básicas. O principal problema, entretanto, é que a maioria dos profissionais de TI não quer realizar apenas tarefas de suporte. Eles interpretam essa atividade como algo sem futuro e limitado. Além disso, os profissionais de desenvolvimento tendem a se considerar superiores aos do setor de suporte. Quando uma empresa segmenta sua estrutura, precisa pensar em como fazer com que seus funcionários se sintam confortáveis com tarefas de suporte e inclusive queiram realizá-las. Existem alguns truques para isso:

- Pague bônus à equipe de suporte. Muitas empresas rejeitam essa ideia, principalmente porque subvalorizam o trabalho que esses profissinais desempenham.

- Crie o hábito de delegar tarefas diferentes ou mais complexas a membros da equipe de suporte por um período, seguindo um rodízio. Tipicamente, esses períodos duram de 12 a 18 meses. Não deixe que sejas mais longos. Quando isso acontece, se perde toda a credibilidade do processo de rodízio. Com o tempo, esses períodos podem se tornar mais curtos.

- Convença profissionais a desempenharem funções de suporte dizendo a eles que após concluírem o rodízio poderão se aperfeiçoar em tarefas que lhe interessam.

Faça a mudança acontecer

Uma empresa não precisa ser completamente segmentada. Há ocasiões em que apenas alguns setores precisam adotar esse modelo estrutural:

- Quando um único projeto grande tem uma trajetória de implementação dividida em fases e a empresa quer estabelecer sua estrutura logo no início para conseguir alcançar seus objetivos a longo prazo. Nesse caso, se a estrutura de longo prazo for segmentada, é melhor começar o processo criando um grupo de suporte separado logo após a instalação. Esse grupo deve ser formado por membros da equipe de desenvolvimento que realizam diferentes tarefas seguindo um esquema de rodízio.

- Desenvolvimentos rápidos ou repetitivos podem resultar em diferentes mesclas de recursos. Projetos rápidos normalmente exigem tarefas de tempo integral e monopolizam os recursos; não é aconselhável que esses mesmos recursos atendam às atividades de produção. Portanto, a equipe de desenvolvimento poderia lidar com falhas e aperfeiçoamentos simples enquanto um outro grupo seria responsável por necessidades de suporte críticas.

- Em algumas empresas, há certas atividades nas quais a demanda de recursos para suporte é mínima. Ou seja, normalmente uma única pessoa é responsável por essa tarefa. Treinar outros profissionais parece desnecessário e às vezes acabam utilizando recursos externos.

- Em muitas companhias, a necessidade de dar suporte a aplicações ERP exige segmentação, porém o modelo segmentado se baseia em escalas, independentemente de elas serem suficientes ou não.

Em seguida, é preciso organizar o tempo disponível. Mudanças impactantes têm consequências impactantes. Tente implementá-la por partes. Também é necessário tomar uma decisão de recursos muitas vezes difícil: em alguns casos, as empresas optam por terceirizar completamente o setor de suporte, e fazem isso por motivos realmente válidos. Embora essa decisão esteja fora da abrangência desta discussão, externalizar os processos é algo a ser analisado, planejado e executado cuidadosamente.

Conclusão

Separar uma empresa em uma de projetos e outra de suporte não otimiza recursos e atividades. Se essa mudança é implementada sem que se leve em consideração as questões aqui expostas, as falhas de recursos permanecerão e serão agravadas pela ruptura do fluxo de trabalho e de relações hierárquicas. Frequentemente, os problemas de planejamento de recursos podem ser resolvidos sem uma mudança estrutural. No caso de a separação ser a melhor alternativa, o planejamento e a execução detalhados serão a diferença entre obter um bom resultado ou apenas criar um novo conjunto de padrões ineficazes.

Fonte: Info Corporate

Post interessante no blog Software Development Today, onde é discutida a viabilidade do uso das ferramentas em projetos que não sejam especificamente de desenvolvimento de software.

O post pode ser lido pelo link: Can Scrum and Kanban be used for non-software development work?

Fonte: JustKanban pelo Twitter

Por André Dourado

Não sou um especialista nem em Redmine, nem em Rails, portanto essa pode não ser a melhor solução no tocante às ferramentas, mas acabou sendo uma forma simples de implementar gráficos de controle de nosso backlog no Redmine.

Descrição da Solução

Precisávamos de uma tabela para armazenar uma fotografia do backlog de nosso setor de desenvolvimento. Nessa tabela inserimos, através de uma tarefa agendada, diariamente às 2 da manhã: quantos tickets entraram e saíram no dia anterior e o total de tickets no backlog.

A partir dessa tabela geramos dois gráficos: um gráfico de linhas, com a quantidade diária de tickets abertos, outro de barras verticais, com a quantidade de tickets que entram e que saem.

Google Charts API

Google Charts API é uma ferramenta muito útil e interessante para quem desenvolve aplicações web e quer gerar gráficos de uma forma dinâmica. Esta API caracteriza-se pela facilidade de utilização e implementação, não sendo necessária a instalação de qualquer software ou frameworks. Para a sua utilização, basta a URL da API no qual serão referenciados os dados e características necessários para gerar o gráfico pretendido.

Os parâmetros são separados por “&”. Podem ser especificados quantos parâmetros se desejarem e pretenderem. Não pretendo aqui tentar esgotar as diversas opções de gráficos possíveis. A documentação completa da API pode ser encontrada em: http://code.google.com/intl/pt-BR/apis/chart/

Detalharei aqui apenas os que utilizamos em nossos gráficos, de forma que tenham um ponto de partida para que possam adaptá-los a suas necessidades.

Construção do Gráfico
“chs” Tamanho do gráfico gerado. Use chs=largura,altura. Ex: chs=430×225&

“cht” Especifica o tipo do gráfico. Linhas do tipo lc, onde são desenhadas diversas linhas para diversos conjuntos de dados, ou do tipo lxy, onde um par de conjuntos de dados é necessário para cada linha. Ex: cht=lc&

“chxt” Especifica os diversos eixos que serão usados no gráfico. O índice do primeiro eixo é 0, o índice do segundo eixo é 1 e assim por diante. Você pode especificar diversos eixos incluindo x, t, y ou r diversas vezes. Ex: chxt=x,y& onde x corresponde ao eixo 0 e y ao eixo 1.

“chxr” Define a escala de um eixo. O primeiro parâmetro é o número do eixo relacionado ao especificado em “chxt”. Os seguintes definem o início e o fim da faixa do eixo. Ex: chxr=1,0,150&

“chd=t” Codificação dos dados em forma de texto com dimensionamento de dados. Usa uma string de qualquer número positivo ou negativo em conjunto com um parâmetro de dimensionamento (chds). Ex: chd=t:108,111,111,111,120&

“chds” Maneira alternativa de definir a linha zero, combinado à codificação de texto. Um conjunto de dados que varia de -60 a 120, pode definir uma escala de -80 a 140 para deixar algum espaço acima e abaixo das barras. Ex: chds=0,150&

“chxl” Todos os rótulos de eixo são separados por uma barra vertical “|”.Os rótulos de eixo devem ser especificados em seqüência (0, seguido de 1, seguido de 2 e assim por diante). Ex: chxl=0:|25|26|27|28|29&

Formatação do Gráfico
“chls” Especifica os estilos de linha. Espessura da linha, comprimento da linha contínua, comprimento do segmento em branco. Ex: chls=2,1,0& linha de espessura média (2), linha não tracejada (1,0).

“chco” Especifica as cores das linhas, barras etc. Todos os valores de cores são números hexadecimais no formato RRGGBB. Ex: chco=DE091A,EBB671& mostra dois conjuntos de linhas/barras.

“chf” Especifica o preenchimento sólido com “bg ou c ou a,s,cor|”, onde “bg” para preenchimento de plano de fundo, “c” para preenchimento da área do gráfico ou “a” para aplicar transparência ao gráfico inteiro. é um número hexadecimal em formato RRGGBB. Ex: chf=c,lg,45,ffffff,0,b1cbfa,0.75|bg,s,fcfcfc&

“chm” Para colocar valores e marcadores sobre os pontos dos gráficos. São muitos os detalhes relativos a esse parâmetro. Sugiro consultar diretamente a documentação na Google: http://code.google.com/intl/pt-BR/apis/chart/#shape_markers2

“chma” Define as margens do gráfico. Use chma=esquerda,direita,topo,baixo. Ex: chma=30,20,20,30&

Por exemplo o gráfico de linha que utilizaremos no tutorial, seria gerado a partir da seguinte url:

http://chart.apis.google.com/chart?
chd=t:108,111,111,111,120&
chxl=0:|25|26|27|28|29&
chm=o,FF0000,0,0,6,0|o,FF0000,0,1,6,0|o,FF0000,0,2,6,0|o,FF0000,0,3,6,0|o,FF0000,0,4,6,0|
t108,FF0000,0,0,10,0|t111,FF0000,0,1,10,0|t111,FF0000,0,2,10,0|t111,FF0000,0,3,10,0|t120,FF0000,0,4,10,0&
cht=lc&
chxt=x,y&
chs=430x225&
chds=0,150&
chxr=1,0,150&
chco=FF0000&
chls=2,1,0&
chf=c,lg,45,ffffff,0,b1cbfa,0.75|bg,s,fcfcfc&
chma=30,20,20,30&
chdl=Tickets+Abertos&
chdlp=b

Criação do Modelo

1.Execute o comando de criação do modelo “backlogs”:

ruby script/generate model backlogs project_id:integer
back_date:date back_abertas:integer back_fechadas:integer back_total:integer

2.Execute a migração:

rake db:migrate

Instalação do Google Charts API

1.Instale a gem do Google Charts API. Mude para o diretório raiz do redmine e digite o seguinte comando:

gem install googlecharts

2.Adicione a nova gem no ambiente de sua aplicação. Edite o arquivo redmine/config/environment.rb e acrescente a linha: config.gem “googlecharts”, :lib => “gchart”

Rails::Initializer.run do |config|
  config.gem "googlecharts", :lib => "gchart"
end

3.Edite o arquivo redmine/app/controllers/application.rb e acrescente a linha: require “gchart”

require "gchart"
class ApplicationController < ActionController::Base
...

Implementação dos gráficos no Redmine

1.Edite o arquivo “redmine/app/controllers/projects_controller.rb” e insira as seguintes linhas:

  def graficos_backlog
    dados = ""
    legenda = ""
    pontos = ""
    pontos_barras = ""
    dados_abertas = ""
    dados_fechadas = ""
    max_total = 0
    max_abertas = 0
    max_fechadas = 0

    nponto = 8

    Backlogs.find(:all, :conditions => {:project_id, @project.id},  rder => "id desc", :limit => 9).each do |s|
      dados = "," + s.back_total.to_s() + dados
      dados_abertas = "," + s.back_abertas.to_s() + dados_abertas
      dados_fechadas = "," + s.back_fechadas.to_s() + dados_fechadas
      legenda = "|" + s.back_date.strftime("%d/%m") + legenda
      pontos = "|o,FF0000,0," + nponto.to_s() + ",6,0|t" + s.back_total.to_s() + ",FF0000,0," + nponto.to_s() + ",10,0" + pontos
      pontos_barras = "|t" + s.back_abertas.to_s() + ",FF0000,0," + nponto.to_s() + ",10,0|t" + s.back_fechadas.to_s() + ",FF0000,1," + nponto.to_s() + ",10,0" + pontos_barras

      nponto = nponto - 1

      if max_total < s.back_total
         max_total = s.back_total
      end

      if max_abertas < s.back_abertas
         max_abertas = s.back_abertas
      end

      if max_fechadas < s.back_fechadas
         max_fechadas = s.back_fechadas
      end
    end

    if dados.length > 0
      dados = "chd=t:" + dados[1, dados.length] + "&"
      dados_abertas = "chd=t:" + dados_abertas[1, dados_abertas.length] + "|" + dados_fechadas[1, dados_fechadas.length] + "&"
      legenda = "chxl=0:|" + legenda[1, legenda.length] + "&"
      pontos = "chm=" + pontos[1, pontos.length ] + "&"
      pontos_barras = "chm=" + pontos_barras[1, pontos_barras.length] + "&"

      # define pontos maximos dos graficos
      if max_total > 10
         multi = 1.1
      else
         multi = 2
      end

      max_graf_linha = "chds=0," + (max_total * multi).to_i().to_s() + "&chxr=1,0," + (max_total *multi).to_i().to_s() + "&"

      if max_abertas > max_fechadas
         max_barra = max_abertas
      else
         max_barra = max_fechadas
      end

      if max_barra >= 10
         multi = 1.1
      else
         multi = 2
      end

      max_graf_barra = "chxr=1,0," + (max_barra * multi).to_i().to_s() + "&chds=0," + (max_barra * multi).to_i().to_s() + "&"

      # define parametros de saida
      custom_linha = dados + legenda + pontos + max_graf_linha + "cht=lc&chxt=x,y&chs=430x225&chco=FF0000&chls=2,1,0&chf=c,lg,45,ffffff,0,b1cbfa,0.75|bg,s,fcfcfc&chma=30,20,20,30&chdl=Tickets+Abertos&chdlp=b"
      custom_barra = dados_abertas + pontos_barras + legenda + max_graf_barra + "cht=bvg&chs=430x225&chco=DE091A,EBB671&chbh=15,0,12&chxt=x,y&chs=430x225&chdlp=b&chdl=Abertos|Fechados&chf=c,lg,45,ffffff,0,b1cbfa,0.75|bg,s,fcfcfc&chma=30,20,20,30"
    else
      custom_linha = ""
      custom_barra = ""
    end

    {:custom_linha => custom_linha, :custom_barra => custom_barra}
  end

2.Ainda no arquivo “redmine/app/controllers/projects_controller.rb”, na definição da ação “Show” insira a seguinte linha:

    @graficos_backlog = graficos_backlog

3.No arquivo “redmine/app/views/projects/show.rhtml”, insira as seguintes linhas:

    <%= Gchart.line :size => '430x225',
                    :custom => @graficos_backlog[:custom_linha],
                    :format => 'image_tag' %>

3.Ainda no arquivo “redmine/app/views/projects/show.rhtml”, insira as seguintes linhas:

    <%= Gchart.bar :size => '430x225',
                   :custom => @graficos_backlog[:custom_barra],
                   :stacked => false,
                   :bar_width_and_spacing => '15,0,5',
                   :format => 'image_tag' %>

4.Inclua no arquivo “redmine/config/routes.rb” a linha:

map.resources :graficos_backlog

5.Reinicie o serviço do redmine para que as alterações tenham efeito.

O resultado final deve ser semelhante a tela abaixo: