Os Backlogs estão sob críticas por algum tempo. Lean considera-os como inventário e desperdício. Mary Poppendieck chega ao ponto de sugerir que o product backlog deve ser eliminado se não estiver atendendo ao propósito desejado. Em linhas semelhantes Jeff Patton sugeriu que backlogs curtos achatados falham em transmitir uma visualização de alto nível do sistema. Ele sugeriu usar um mapa de estórias.

De acordo com Jeff, um dos problemas mais comuns que os times Ágeis enfrentam é que eles rapidamente perdem o a visão do todo. A razão para isso é a maneira de como as estórias são organizadas, ignorando completamente o sistema que está sendo construído. Jeff fez uma interessante analogia,

"Nós gastamos muito tempo trabalhando com nossos clientes. Trabalhamos duro para entender seus objetivos, seus usuários, e a maior parte do sistema que poderíamos construir. Então finalmente vamos aos detalhes – os pedaços da funcionalidade que gostaríamos de construir. Na minha cabeça eu vejo uma árvore onde o tronco é construído a partir dos objetivos ou benefícios desejados que impulsionam o sistema; os ramos grandes são os usuários; os pequenos ramos e galhos são as capacidades que eles precisam; e finalmente as folhas são as user stories pequenas o suficiente para colocar dentro do desenvolvimento das iterações."

"Depois de todo esse trabalho, depois de estabelecer todo este entendimento compartilhado eu sinto que temos que puxar todas as folhas da árvore e carragá-las dentro de um saco de folhas – e então cortar a árvore."

"Isto é o que um backlog achatado significa pra mim. Um saco de folhas secas fora de context."

Jeff sugeriu usar um mapa de estórias no lugar do backlog. O mapa de estórias se parece com isso

Aqui, no topo do mapa, estão as grandes estórias ou atividades que os usuários fazem quando interagem com o sistema. A ordem das atividades é a ordem em que os usuários interagem com o sistema. Abaixo as atividades são as tarefas do usuário. Esta é a coleção de tarefas que o usuário executa para realizar a atividade. Por exemplo, se gerenciamento de email é uma atividade então "enviar mensagem," "escrever mensagem," "deletar mensagem," "marcar mensagem como spam", etc, são tarefas do usuário.

Jeff acrescentou que as atividades no mapa formam a espinha dorsal do sistema e as tarefas são as costelas. A idéia não é priorizar a espinha dorsal porque ela é a fundação onde o sistema se encaixa. Portanto, as estórias devem ser priorizadas. Todo o planejamento deve ser feito na base da espinha dorsal e isto é útil para decidir sobre a prioridade das tarefas do usuário que formam as costelas.

O benefício de usar um mapa de estórias é que o todo é agora um tema central. Aparte destes outros benefícios que Jeff sugeriu eram,

Eu posso caminhar pelo mapa do início ao fim com um usuário, pessoas de neǵocio, ou desenvolvedor e contar uma estória sobre os usuários do sistema e o que eles estão fazendo. Eu posso avançar ao longo do topo do mapa, e apenas tocar nos pontos importantes. Eu posso me aprofundar no mapa para discutir os detalhes.

Falando através do mapa com os usuários e com os outros me ajuda a encontrar as coisas que eu esqueci. Eu frequentemente ouço "você esqueceu de alguns passos aqui" para quando os usuários fazem isso.

Eu posso anotar o mapa com pontos negativos ou oportunidades. Como eu falo através do mapa com um usuário é comum ouvir-lhe dizer, "isso aqui é realmente um problema com o sistema de hoje."

Assim, um mapa de estórias ajuda o time a focar constantemente no produto que eles estão construindo. Ele ajuda os times a não perderem o foco na floresta por causa das árvores.

Fonte: InfoQ

1. Você pode ter certeza daquilo que ele é, e de como será.
Nerd não muda.
Ele não tenta fingir que é outra pessoa só para te agradar, porque nem se ele quisesse ele saberia como parecer legal, bonito, etc. As qualidades de um NERD são imutáveis.
Se ele gosta de C++, vai morrer gostando de C++. Pode até ser que passe a usar Java também, mas no fundo é tudo a mesma coisa.

Se ele gosta de De Volta para o Futuro, vai morrer gostando disso.

Se hoje ele é gordinho, amanhã será gordinho.
Se hoje ele é magrelo, amanhã será magrelo.
Diferente dos garotos que fazem musculação para você achar que eles são gostosos, e depois que você casar eles vão virar uns gordos barrigudos.

2. Se ele diz que vai fazer uma festa em rede é verdade.
Sabe aquele papo dos homens comuns de falar que vai jogar futebol e ir a outro lugar.
Se Nerd fala que vai a casa de alguém para fazer uma Festa em Rede e jogar Doom, é porque ele vai fazer isso.

Ele não vai mentir para você, falando que vai fazer uma coisa e ir fazer outra coisa.

3. Nerd tem empregos estáveis.
Muita gente diz que mulher gosta de dinheiro, tremenda mentira.
O que mulher odeia são homens idiotas que não conseguem ter um emprego decente.
Até porque senão você ( mulher ) tiver um marido com emprego tosco, ainda tem que ouvir sua mãe, suas amigas falando:
- Nossa! Mas que marido você arrumou, ele é um banana.

Com Nerds não tem preocupação. Até porque Nerd sempre faz algo que ninguém entende, e daí parece ser muito mais importante o emprego dele do que realmente é.

- Ah! Meu marido cuida de um Servidor de rede.

4. Nerd sempre resolverá o problema do seu computador muito mais rápido e melhor que o suporte técnico. E o melhor, de graça.

5. Ele não vai esquecer seu aniversário.
A menos que a bateria do Palm dele acabe.

6. Ele não tem ciúmes do carro dele.
Ele não vai ficar falando do carro dele o tempo todo.
Mas não pegue o livro do Stephen Hawking e nem toque no computador dele.
Computador é uma coisa sagrada, NUNCA TOQUE NELE.

7. Nerd adora saber como as coisas funcionam.
Então enquanto ele não conseguir fazer você ter um orgasmo, ele vai estudar o porquê, estudar os pontos sensíveis de uma mulher, criar um gráfico com as possíveis formas de te fazer chegar lá medindo a probabilidade de isso acontecer.

Fará cálculos de Permutação para saber qual o conjunto dessas formas é a melhor para fazer você ter um orgasmo.
Só não pergunte para ele o que ele está fazendo, porque se ele tentar te explicar você não vai entender.

8. Nerd esperto grava os programas.
Nerd que é nerd sabe programar o video cassete, o gravador de DVD ou a placa dee captura de TV para gravar seu programa favorito.
Por isso não tem porquê ele não ir a algum lugar com você só porque estará passando Jornada nas Estrelas ( ao contrário dos maridos comuns que ficariam em casa vendo futebol ).
A menos que você queira ir a um lugar movimentado, a maioria dos Nerds odeiam lugares cheios ( pelo menos eu odeio ).

9. Todo mundo tem defeito.
Mesmo tendo bons motivos para amar um NERD, NUNCA, JAMAIS, NEM PENSE, em interrompê-lo quando ele está programando, esse momento é sagrado.
Interromper alguém que está programando é pior que interromper alguém que está no meio de um cálculo.

Motivo: Quase sempre agente tem que ter em mente o valor de 4 ou 5 variáveis nessa hora.
Tem que saber como e porquê o FOR começou e vai acabar
Tem que guardar na cabeça a condição do IF onde estamos lendo.

E guardar muitas outras informações.
Se você interrompe nessa hora, agente esquece todas essas informações e tem que procurá-las de novo. e isso é uma chatice.

Então! AME um NERD!
Mas NUNCA encoste no computador dele, fale mal do Stephen Hawking ou dos programas de TV que ele assiste e NUNCA interrompe no meio de uma programação.
Faça isso e será feliz para sempre !

Obs: sou muito =P NERD (esse trecho foi modificado, mas eh verdade!), caso alguma menina tiver interesse em algum =*

Fonte: Thiago’s Lab

Fevereiro 20, 2009

Fonte: Visão Ágil

Publicado por: Felipe Rodrigues & Flávia Oliveira no blog Fratech
em: 17 Fev 2009 às 13:57

Fonte: Fratech

Descubra os oito indicadores de que está na hora de buscar a ajuda de um profissional para o seu desenvolvimento profissional, bem como aprenda quais os caminhos para encontrar esse tipo de consultor

Meridith Levinson, da CIO USA
Publicada em 18 de fevereiro de 2009 às 15h20

Com o aumento do desemprego e a escassez de boas oportunidades profissionais, quem não gostaria de contar com a ajuda de um especialista para alavancar sua carreira? Este papel, desempenhado pelos coaches tem ganhado cada vez mais destaque entre executivos de TI, nos últimos meses.

“Assim que a crise econômica se desenrolou, em outubro de 2008, a indústria de coaching passou por um período de silêncio. Entretanto, para esse setor, a principal consequência da instabilidade financeira global foi o aumento da demanda pelos serviços prestados pelos consultores de carreira”, conta Kim Batson, coach especializada no mercado de TI.

Porém, o que pode parecer a solução para a maior ameaça que um profissional pode sofre não é uma opção para qualquer um. Em primeiro lugar, a contratação de um coach pode custar caro – alguns desses consultores chegam a cobrar cerca de US$ 500 por hora de trabalho.

Além disso, alerta a coach de carreira Curt Rosengren, muitas pessoas buscam tais serviços na esperança de conseguirem respostas rápidas, quase mágicas. “Àqueles que recorrem a nós na tentativa de comprar uma solução para seus problemas é preciso explicar que não fazemos milagres e que os resultados de nossas ações dependem, exclusivamente, do esforço dos próprios clientes”, enfatiza Curt.

Mas quais os sinais de que está na hora de contratar um consultor para alavancar sua carreira profissional. A seguir, veja os oito sinais de que chegou o momento de ter seu próprio coach executivo:

1. Você está frustrado com seu trabalho mas não tem idéias para possíveis alternativas profissionais;
2. Você está em busca de um novo emprego, mas suas iniciativas (envio de currículos, entrevistas) não estão rendendo frutos reais;
3. Você precisa de ajuda na elaboração de currículo ou cartas de apresentação;
4. Embora tenha esforço, você não tem conseguindo progredir profissionalmente;
5. Você precisa de ajuda para se diferenciar de outros candidatos;
6. Você não consegue transformar seus desejos profissionais em metas objetivas;
7. Você está ansioso para explorar novas idéias e mercados;
8. Você quer alcançar o sucesso e precisa de ajuda para agilizar a realização de seus objetivos.

Três sinais de que você não está preparado para a ajuda profissional:
1. Você acha que um coach de carreira possui todas as respostas relativas a suas dúvidas profissionais;
2. Você não está interessado em se auto-avaliar e fazer networking;
3. Você tem problemas em falar de si mesmo com os outros.

Como encontrar um consultor de carreira:
1. Peça indicações a conhecidos e colegas de trabalho;
2. Consulte pesquisas e revistas especializadas no segmento de negócio no qual você busca oportunidades;
3. Escolha um profissional com credenciais e especializações;
4. Peça referências de outros clientes aos coaches consultados.

O que perguntar a um coach antes de contratá-lo:
1. Há quanto tempo atua como consultor de carreira?
2. Você é credenciado por algum órgão regulamentador da categoria?
3. Você é especializado em algum segmento de negócios? Qual?
4. Que tipos de clientes trabalham melhor com você?
5. Quanto tempo dura sua atuação junto a um cliente?
6. Como são medidos os resultados?
7. Que tipo de retorno devo esperar ao investir em seus serviços?

Como aproveitar ao máximo suas sessões de coach:
1. Não fique envergonhado: tente dar o máximo de informações – pessoais e profissionais – ao consultor;
2. Não superestime o que um coach pode fazer por você: seu currículo e atitudes são os maiores responsáveis pelo sucesso profissional;
3. Seja honesto: diga ao consultor o que espera de seus serviços e dê sua opinião sobre como o trabalho se desenvolve ao longo da consultoria

Fonte: CIO

Postado por Amr Elssamadisy, traduzido por Flávia Castro de Oliveira em 18 Fev 2009 09:00 AM

Há uma importante discussão acontecendo na lista ScrumDevelopment. Há uma dúvida sobre o papel do membro mais importante do time – o product owner. Jean Richardson começou a conversa com a seguinte questão:

Eu estou trabalhando com um cliente que é novo em Scrum. Até agora, eles estão muito anciosos. Nós tivemos e estendemos lições aprendidas na semana passada em um ½ projeto difícil e eles vêem Scrum como a resposta para suas preces. O seu gerente leu /Gerenciamento de Projetos Ágeis com Scrum/, e um dos membros do time está na metade do livro.

Entretanto, o gerente pediu uma reunião comigo no final desta semana em relação a “quem seria o Product Owner.” Eu acho que seu time está empurrando-o para compartilhar esse papel entre todos eles—ou ao menos 3 deles (ele próprio e mais dois). Então, minha questão é, como é que funciona compartilhar esse papel através de duas ou mais pessoas. Será que isso funciona bem? Se sim, o que é preciso para que isso funcione bem? Que tipos de coisas você vê acontecendo?

Isto é, evidentemente, uma questão ou ocorrência comum.  A maioria dos conselhos caiu em duas áreas:

Área 1: Você deveria ter somente um product owner.  Por exemplo, Dan Rawsthorne sugeriu:

Eu sempre tenho uma resposta simples para "quem será seu product owner". Eu pergunto: "quem deve ser responsável pelo sucesso? Quem tem um alvo em suas costas? Esse é o seu product owner." Na minha experiencia, o PO é normalmente ungido em seu exterior.

Isso trouxe uma série de observações interessantes, uma das quais evocando uma inconsistência na maneira que o product owner é tratado e percebido:

No entanto, isso não traz à tona uma dicotomia interessante para o Scrum? Se o PO é o único com a corda no pescoço da perspectiva de requisitos/ROI, por quê não há uma única pessoa com a corda no pescoço da perspectiva do time?

Eu pergunto porque eu já tive inúmeras conversas com os doutores do Scrum que apontam a falta de responsabilidade no time. Enquanto o time é responsável por tornar-se auto organizado e finalmente fazer o que precisa ser feito, não há nenhuma corda no pescoço quando eles não o fazem. Eu tenho visto os times lutando para se tornar auto organizados. Alguns nunca tem sucesso. É difícil de responsabilizar o time inteiro, especialmente quando muitos membros fazem o seu melhor.

Área 2: No front do "isso depende", o comentário de George Dinwiddie foi exemplar:

Sim, isso pode funcionar bem e ainda dividir a carga de trabalho entre os três. Isso também pode ser um desastre. Eu vi os dois.

Eles compartilham a mesma visão do projeto? Se não, qual a visão que os desenvolvedores tem?

Todos os três podem trabalhar na sala com os desenvolvedores? Se não, isso é uma bandeira vermelha para mim.

Os três podem tomar decisões rápidas juntos? Se não, acho que não irá progredir.

Eles podem "falar como uma só voz?" Se não, quem os desenvolvedores vão seguir?

Quando eles discordarem, tem uma maneira segura de resolver o conflito? Se não, quem os desenvolvedores vão seguir?

Para responder adequadamente a questão, deve existir um acordo sobre qual o papel e quais as responsabilidades reais de um product owner. É ser o ‘único pescoço em jogo’? Será que as responsabilidades são muito mais abrangentes de forma que não possam ser cumpridas em um grande ambiente? Quais são seus pensamentos e experiências?

Fonte: InfoQ

Postado por Abel Avram, traduzido por Felipe Rodrigues em 17 Fev 2009 06:00 AM

O ASP.NET MVC está usando o T4 (Text Template Transformation Toolkit) para gerar código por trás das cenas quando um Controler ou uma View é adicionada ao projeto. O T4 é um gerador de texto totalmente customizado baseado em templates.

Uma das funcionalidades do ASP.NET MVC anunciada por Scott Cuthrie é usar o T4 para geração de código. O código é gerado pela engine do T4 a partir de um template de texto. Isso quer dizer que pode-se criar ou editar o template tendo controle completo sobre o código resultante.

Um template T4 parece muito com qualquer outro Web Form, combinando blocos de texto simples com lógica de controle. Abhishek Mishra deu um exemplo detalhado de como editar um.

Não há suporte inteligente para edição de templates T4 no Visual Studio, mas a Clarius Consulting oferece um T4 Editor Community Edition integrado com o VS e fornecendo syntax highlighting. Ele também oferece uma versão Pro que oferece verdadeiro suporte intellisense e edição do gerador de código T4 suportando hosts T4 customizados(WSSF, ASP.NET MVC), integração com o Server Explorer, Drag & Drop de arquivos XML e XSD, API de DB amigável para inspecionar metadados e outros.

O T4 pode ser usado para automatizar a geração de arquivos de texto de qualquer tipo e propósito. Scott Hanselman deu tal exemplo usando um template para gerar código LINQ to SQL. Scott recomenda o uso do T4 para qualquer tarefa repetitiva de geração de texto, não apenas relacionadas ao .NET: “Se você está fazendo algo duas vezes ou mais, manualmente, em sua empresa, gere isso.”

A InfoQ internacional oferece uma introdução técnica ao T4 incluindo links para a documentação no MSDN e posts úteis.

Fonte: InfoQ

“O plano mínimo necessário para iniciar um projeto Scrum, consiste de um Documento de Visão e um Product Backlog. A Visão descreve porque o projeto está sendo implementado e o que se deseja ao seu final.” (Schwaber 2004, p. 68)

Frase de “Ken Schwaber“. Schwaber além de ser um dos criadores do Scrum, é fundador da Agile Alliance e da Scrum Alliance, além de signatário do Manifesto Ágil. Sobre a importância do Documento de Visão para projetos Scrum.

Referência: The Product Vision

Por: André Dourado

Configuração de um servidor de produção para o Redmine, em ambiente Windows, servidor http Apache+Mongrel, acessando base de dados armazenada no MySQL. Este post tem a finalidade de descrever esse processo, passo a passo.

Requisitos

Windows XP SP2: este tutorial foi feito utilizando um XP SP2 previamente instalado. Provavelmente funcionará sem problemas em outras versões de Windows.

Apache Webserver 2.x: neste tutorial foi utilizada a versão “Win32 Binary without crypto (no mod_ssl) (MSI Installer)” que pode ser obtida no endereço: http://ftp.unicamp.br/pub/apache/httpd/binaries/win32/apache_2.2.11-win32-x86-no_ssl.msi

One-Click Ruby Installer: neste tutorial foi utilizada a versão “One-Click Ruby Installer 1.8.6-25″ que pode ser obtida no endereço: http://rubyforge.org/frs/download.php/18566/ruby186-25.exe

MySQL: neste tutorial foi utilizada a versão “mysql-essential-5.5.0-m2-win32″ que pode ser obtida no endereço: http://ftp.astral.ro/mirrors/mysql.com/Downloads/MySQL-5.5/mysql-essential-5.5.0-m2-win32.msi

Redmine: neste tutorial foi utilizada a versão “redmine-0.8.1″ que pode ser obtida no endereço: http://rubyforge.org/frs/download.php/51748/redmine-0.8.1.zip

Instalação do Apache Web Server

1.Execute o instalador do Apache Webserver, clicando sobre o arquivo “apache_2.2.11-win32-x86-no_ssl.msi” a partir do Windows Explorer. Clique então sobre o botão “Next”.

2.Selecione a opção “I accept the terms…” e clique sobre o botão “Next”.

3.Clique sobre o botão “Next”.

4.Informe os endereços solicitados e clique no botão “Next”.

5.Selecione a opção “Typical” e clique sobre o botão “Next”.

6.Clique sobre o botão “Change…” para alterar o caminho onde o servidor será instalado.

7.Informe o caminho desejado. Neste tutorial utilizamos o caminho “c:\apache”. Clique sobre o botão “Ok”.

8.Clique sobre o botão “Next”.

9.Clique sobre o botão “Install”.

10.Clique sobre o botão “Finish”.

11.Teste se o servidor foi instalado corretamente, digitando “http://localhost” no campo url do browser. Se tudo estiver ok, a tela apresentada será semelhante a tela abaixo:

Instalação do Ruby

1.Execute o instalador do Ruby, clicando sobre o arquivo “ruby186-25.exe” a partir do Windows Explorer. Clique então sobre o botão “Next”.

2.Clique sobre o botão “I Agree”.

3.Clique sobre o botão “Next”.

4.Informe o caminho desejado. Neste tutorial utilizamos o caminho “c:\ruby”. Clique sobre o botão “Next”.

5.Clique sobre o botão “Install”.

6.Clique sobre o botão “Next”.

7.Clique sobre o botão “Finish”.

Instalação dos pacotes Rails, Mongrel, Win32 Services

1.Os próximos passos serão executados em linha de comando do Windows, para isso clique no botão iniciar do Windows. Clique em “Executar” e na linha de comando digite “cmd” e pressione a tecla “Enter”. Todas as operações levam alguns minutos e é necessário que você esteja conectado à internet.

2.Mude para o diretório “c:\ruby\bin” e digite o comando de atualização do gerenciador de pacotes do Ruby RubyGems:

    gem update --system

3.Digite o comando de atualização e instalação do Rails:

Obs: Em uma instalação no Windows Vista tive o seguinte erro:

C:\ruby\bin>gem install rails
ERROR: While executing gem ... (Errno::ENOENT)
No such file or directory - C:\Users\André Dourado

Provavelmente pelo espaço no caminho do diretório. Setei a variável “userprofile” para o diretório do ruby e o problema foi solucionado.

C:\ruby\bin>set userprofile=c:\ruby

    gem install rails

4.Digite o comando de atualização e instalação do Mongrel:

    gem install mongrel

5.Digite o comando de atualização e instalação do suporte aos serviços Win32:

    gem install win32-service

6.Digite o comando de atualização e instalação do mongrel como serviço Win32:

    gem install mongrel_service

Instalação do MySQL

1.Execute o instalador do MySQL, clicando sobre o arquivo “mysql-essential-5.1.31-win32.msi” a partir do Windows Explorer. Clique então sobre o botão “Next”.

2.Clique sobre o botão “Next”.

3.Clique sobre o botão “Change”.

4.Entre com o caminho da instalação, no caso “c:\mysql”. Clique sobre o botão “Ok”.

5.Clique sobre o botão “Next”.

6.Clique sobre o botão “Install”.

7.Clique sobre o botão “Next”.

8.Clique sobre o botão “Next”.

9.Clique sobre o botão “Finish”.

10.Clique sobre o botão “Next”.

11.Clique sobre o botão “Next”.

12.Clique sobre o botão “Next”.

13.Clique sobre o botão “Next”.

14.Clique sobre o botão “Execute”.

15.Clique sobre o botão “Finish”.

Instalação do Redmine

1.Clique com o botão da direita sobre o arquivo zip do Redmine e selecione a opção “Extrair tudo…”. Ao abrir o “Assistente para extração” clique no botão “Avançar”. Na próxima tela, no campo de diretório de destino, digite “c:\apache\htdocs”.

2.Para facilitar a navegação pelos diretórios do aplicativo, renomeie o diretório criado pelo Redmine de “redmine-0.8.1” para apenas “redmine”;

3.Copie o arquivo “config\database.yml.example” para “config\database.yml”. Neste tutorial utilizamos o banco de dados MySql, com o usuário “root” sem senha e será executado em nossa máquina local. Para este setup a seção “production:” do arquivo “database.yml”, deve ficar:

   production:
    adapter: mysql
    database: redmine
    host: localhost
    username: root
    password: <senha_mysql>
    encoding: utf8

4.Os próximos passos serão executados em linha de comando do Windows, para isso clique no botão iniciar do Windows. Clique em “Executar” e na linha de comando digite “cmd” e pressione a tecla “Enter”.

5.Mude para o diretório “c:\mysql\bin” e digite o comando de execução do mysql para o usuário “root” no banco de dados mysql.

    mysql -u root mysql

6.Crie a estrutura do banco de dados “redmine” com o comando:

    create database redmine character set utf8;

7.Saia do MySql digitando o comando “quit” e pressionando a tecla “Enter”.

8.Mude para o diretório do redmine “c:\apache\htdocs\redmine”. Crie a estrutura do banco de dados “redmine”, digitando o comando:

    \ruby\bin\rake db:migrate RAILS_ENV=production

9.Insira os dados padrão de configuração no banco de dados, digitando o comando:

    \ruby\bin\rake redmine:load_default_data RAILS_ENV=production

Ao ser solicitado para informar a língua desejada, digite “pt-br” e pressione a tecla “Enter”.

10.Instale o serviço que irá executar o servidor Mongrel para o Redmine na porta 4000, digitando o comando:

    \ruby\bin\mongrel_rails service::install -N Redmine -c c:\apache\htdocs\redmine -p 4000 -e production

11.Inicie o serviço, digitando o comando:

    net start Redmine

12.Através do browser teste se o Redmine está no ar. Acesse o endereço “http:\\localhost:4000\login”

Configuração do Apache

1.Crie o arquivo de configuração de proxy para a aplicação “c:\apache\conf\http-proxy-redmine.conf”, com o seguinte conteúdo:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
ProxyRequests Off

ProxyPass /redmine/ http://127.0.0.1:4000/
ProxyPass /redmine http://127.0.0.1:4000/
ProxyPassReverse /redmine http://127.0.0.1:4000/

2.Edite o arquivo de configuração do Apache “c:\apache\conf\httpd.conf”. Acrescente na última linha do arquivo a seguinte linha:

Include conf/http-proxy-redmine.conf

3.Reinicie o serviço do Apache pelo gerenciador de serviços do Windows.

Configuração do Proxy Reverso

O Rails cria internamente endereços de URL para links de folha de estilo, que faz com que a aplicação não execute da forma correta, através do proxy do Apache. Utilizaremos um plugin do Rails, que altera o modo como as URLs são criadas.

1.Mude para o diretório do redmine “c:\apache\htdocs\redmine”. Instale o plugin, digitando o comando abaixo. Responda para a url base “c:\apache\htdocs\redmine” e para a versão do Rails, escolha a opção “3″:

    \ruby\bin\ruby script/plugin install http://svn.napcsweb.com/public/reverse_proxy_fix

2.Reinicie o serviço do Redmine pelo gerenciador de serviços do Windows.

Teste do Redmine pelo Proxy

1.Através do browser teste se o Redmine está no ar, sendo acessado pelo proxy configurado no Apache. Acesse o endereço “http:\\localhost\redmine\login”

Post Relacionados:
    Tutorial Redmine – Gráficos no Redmine usando a API do Google Charts

Referências:
    Serving Multiple Rails Applications on Windows with Apache and Mongrel
    Mongrel Win32 HOWTO

por Guilherme Chapiewski
em Fevereiro 15, 2009

Me incomoda muito o fato de que desenvolvedores precisam virar gerentes ou coordenadores para ganhar mais.

<história>
Era uma vez um desenvolvedor muito bom e muito eficiente. Ao longo da sua carreira ele foi aprimorando suas habilidades e técnicas e se tornou um super desenvolvedor com um conhecimento técnico absurdo, uma vasta experiência em arquiteturas de software e poliglota em linguagens de programação. Nesse momento ele repara que já é um desenvolvedor sênior ++ na empresa que ele trabalha e por isso não tem como ganhar mais do que ele já ganha a não ser que ele vire gerente. Então, querendo ganhar mais, o excelente técnico que programava e resolvia problemas técnicos com eficiência é obrigado a virar um gerente, porque a empresa não dá para ele outra forma de evoluir financeiramente. O detalhe é que ele não tem nenhuma habilidade para gerir pessoas ou projetos, além de que ele odeia fazer isso. O que ele gostava mesmo era de programar, mas ele não teve escolha. Resumindo: a empresa trocou um excelente técnico por um péssimo gerente e ainda está pagando mais por isso!
<história/>

Já repararam como esse padrão se repete nas empresas brasileiras?

Se você nunca parou pra pensar nisso, pense agora: é muito difícil um programador ganhar mais do que um gerente e por sua vez é muito difícil um gerente ganhar mais que um diretor. A lógica do mercado é a velha lógica do plano de cargos e salários: quanto maior for o seu nível hierárquico, mais você ganha.

O problema é que isso não faz sentido. O argumento preferido das pessoas normalmente é que “os gerentes ganham mais porque tem mais responsabilidades”. Eu discordo totalmente. Por exemplo, um amigo me contou ontem que um funcionário da empresa onde ele trabalhava tirou do ar o sistema de transações financeiras de uma grande empresa, causando com isso algumas centenas de milhares de dólares de prejuizo em poucos minutos. Neste caso, um erro de um desenvolvedor provocou uma catástrofe maior do que 10 anos de erros de uma dezena de gerentes juntos. E então, quem é que tem mais responsabilidade nas mãos?

Outra coisa que me incomoda nos planos de cargos e salários são aquelas regras do tipo “gerentes ganham na faixa de R$ X a R$ Y“: se o cara ganha menos que X não pode ser gerente e se ganhar aumento para mais que Y tem que ser promovido a diretor. Isso também não faz sentido. Em todas as empresas que eu trabalhei conheci gerentes excepcionais e gerentes absurdamente idiotas. Por incrível que pareça os excepcionais com toda sua genialidade sempre ganhavam (e ganham) o mesmo que os idiotas, por causa do maldito plano de cargos e salários. Isso pra mim soa como gado: independente das suas características individuais, uma cabeça de gado custa o mesmo que outra.

Eu trabalho e já trabalhei com vários desenvolvedores de valor altissimo. Não falo isso pelo que eles ganham ou ganhavam, mas sim porque em várias situações eles criaram soluções que melhoraram ou mudaram completamente (para melhor) a forma que as pessoas trabalhavam. Algumas dessas coisas foram tão geniais que eu diria que o valor foi inestimável. Eu também já tirei meus coelhos da cartola e sei que eles foram de grande valor para as empresas que eu trabalhei.

Não deveriam ser esses tipos de coisas que determinam o quanto as pessoas devem ganhar?

Em empresas de software, onde é comum encontrar esse tipo de pessoas, deveria ser normal ter desenvolvedores altamente especializados com remunerações maiores que as de gerentes ou diretores, mas isso é tão improvável que eu diria que é praticamente impossível – pelo menos no Brasil. Já em empresas como Google, Yahoo e cia., isso é possível e normal. Na Globo.com temos alguns casos desse tipo, mas são excessões. Isso está em fase embrionária e é muito muito muito longe do que deveria ser.

Naquela história que eu contei no início não consigo pensar em um motivo sequer para a empresa não manter o funcionário como desenvolvedor e dar o aumento que ele merece. Esqueça o plano de cargos e salários e veja como faz sentido: isso seria muito melhor para a empresa – porque o funcionário iria agregar muito mais valor sendo desenvolvedor e iria ajudá-la a lucrar muito mais – e seria melhor para o desenvolvedor – porque ele iria fazer o que gosta, o que é mais experiente e o que estudou sua vida toda para fazer.

Até quando as empresas vão continuar colocando as pessoas certas nos lugares errados?

Leia também: O que quer dizer “Síndrome do sofá-cama”?

Fonte: Guilherme Chapiewski