sexta-feira, 18 de novembro de 2011

PARTE 3/3 - Entrevista Construindo Resultados com Gerenciamento de Projetos

PARTE 2/3 - Entrevista Construindo Resultados com Gerenciamento de Projetos

PARTE 1/3 - Entrevista Construindo Resultados com Gerenciamento de Projetos

Que tipo de Gerente de Projetos é Você?


Olhando ao meu redor e para o meu próprio umbigo, fiquei pensando: “que tipo de gerente sou?”
É fato que as nossas avós e nossos avôs deram suas contribuições para formar o gerentão que somos. Negar isso seria nos negligenciarmos. Quantas vezes já ouvimos dizer – muitas vezes sobre nós mesmos: “o cara tem o perfil para tal função…” ou “esse trabalho é a cara de fulano….” entre outras várias frases….
Mas de fato, temos o perfil? Mais ainda, qual o perfil de um gerente de projetos?
Muitos autores, entre estes a autora Rita Mulcahy, dizem que o perfil do gerente de projetos deve contemplar a facilidade de comunicação, a habilidade de desenvolver relacionamentos ou de influênciar pessoas. Enfim, muitas características podem ser “solicitadas” para se “definir” o perfil de um gerente de projetos.  Dentro disso, os autores Rafael Prikladnicki e Afonso Inacio Orthdo livro “Planejamento e Gerencia de Projetos” apontam algo interessante, que vale ser transcrito: “Para planejar um projeto é necessário conhecer as Técnicas de Planejamento. Mas antes de tudo, é necessário ter perfil para ser um gerente de projeto”.
Então vamos lá: que tipo de gerente sou? Qual o meu perfil?
O Gerente de Projetos, para àqueles que ainda não tiveram a oportunidade de trabalhar com um,  DEVE ser o profissional que atue mais como um facilitador do que um burocrata, mais descentralizador do que centralizador, mais organizado do que desorganizado…
Isto muitas vezes não é bem claro. Pode-se achar que o Gerente de Projetos é a pessoa da burocracia, ou ainda, o profissional que vai controlar tudo e todos. Na verdade, temos que abrir a mente sobre isso. Não é função de o gerente controlar tudo e todos, mas sim, ser o “interprete” da direção junto aos colaboradores – o contrário também é válido, ok?
Com isso, já dá pra notar que o Gerente de Projetos não é um gerente qualquer. O GP, como são chamados os gerentes de projetos, é a pessoa da empresa que flutua em todas as áreas da organização com o objetivo de atender às suas metas estratégicas. Não pode ele ser confundido com um burocrata.  No entanto, o problema está quando nós mesmos confundimos nosso papel, aí a coisa complica.
O autor Joseph Phillips apresenta alguns tipos de Gerentes que nos deparamos:
1) Gerentes que não ouvirão: são aqueles que não prestam a atenção ao que você diz e nem estão interessados em suas observações.
2) Gerentes que são agressivos: são os brutos! Tudo que conseguem é no grito.
3) Gerentes que evitam tomar decisões: são aqueles que adiam ao máximo a tomada de decisão.
4) Gerentes que microgerenciam: são os perfeccionistas! Para eles ninguém é mais capaz de realizar algo, senão eles.
5) Gerentes que monopolizam o crédito: é aquele que quer ser o centro das atenções. A estrela do processo. Estão sempre presentes, mas não registram nada. Se o projeto falhar ele não tem nada haver com aquilo, caso contrário a glória é só deles.
6) Gerentes que aplicam punições: só para dizer quem está no comando!
Eu tomo a liberdade em acrescentar outro tipo de gerente: o gerente animador de auditório!
Sabe aquele que tenta agradar a todos, só vive sorrindo, é só alegria? Então: é o gerente animador de auditório. As reuniões com esse gerente são sempre um show de comédia, todos saem de lá mais leves, os problemas viram piada, as soluções são postergadas… No fim todos o adoram, mas será se este é o perfil ideal?
O animador de auditório é um cara popular. Disso não há dúvidas!
Na área de TI é muito comum dar a função de gerente de projetos ao melhor técnico da equipe,  e algo parecido acontece com o animador de auditório: é o cara que todos gostam, é só simpatia! No caso do excelente técnico que o transformam em GP… a experiência não tem sido muito boa….
Partindo disso, retomo a pergunta: que tipo de Gerente de Projetos você é?

Fonte:

eXtreme Programming em Cinco Minutos



eXtreme Programmig (XP) proposta por Kent Beck [BECK, 2004] tem o objetivo de propor uma metodologia ágil para equipes de tamanho pequeno a médio, onde o desenvolvendo de software está inserido em um contexto de requerimentos vagos ou que mudam rapidamente.  O próprio autor descreve a Programação eXtrema como: “A XP é uma maneira leve, eficiente, de baixo risco, flexível, previsível, científica e divertida de desenvolversoftware”. [BECK, 2004].  Ainda segundo [BECK, 2004], a XP reconhece que os projetos precisam dedicar-se à obtenção da redução dos custos e tirar vantagem daquilo que foi economizado. Além disso, defende a não especialização dos membros do time, ou seja, todos participam de todas as atividades, em pares e com sistema de rodízio dos pares o desenvolvimento de infra-estrutura e frameworks durante o desenvolvimento da aplicação, e a comunicação face a face ou por meio de testes eficientes e código cuidadosamente escrito.
Segundo [BECK, 2004], a XP se distingue das outras metodologias por:
  • Seu feedback antecipado;
  • O planejamento incremental, que gera rapidamente um plano geral que evolui com o decorrer do projeto;
  • Sua habilidade de implementar as funcionalidades de forma flexível considerando as necessidades mutáveis do negócio;
  • Sua confiança nos testes automatizados;
  • Sua confiança em comunicação oral;
  • Sua confiança em um processo de projeto evolutivo que dura tanto quanto o sistema;
Risco: O Problema Básico A principal motivação da Programação eXtrema parte do princípio que o desenvolvimento de software tem falhas na entrega e falhas nos produtos entregues caracterizando o problema básico – o risco, portanto, produz-sesoftware de baixa qualidade. Segundo [BECK, 2004], existem vários riscos associados ao desenvolvimento do software, como: (i) cronograma irreal; (ii) cancelamento do projeto por vários atrasos no cronograma; (iii) o sistema é descontinuado pelo alto custo de se fazer modificações ou a taxa de erros cresce tanto que o sistema deve ser substituído; (iv) o negócio é mal compreendido e o software desenvolvido não resolve o problema original; (v) as regras de negócio mudam antes que o software seja finalizado; (vi) funcionalidades inúteis. A missão da XP é aceitar o risco como problema a ser resolvido, onde o objetivo é encontrar a solução. Nesse sentido, a necessidade é criar um modelo de desenvolvimento de software que trate desses riscos. Além de mitigar ao máximo os riscos, a metodologia XP advoga que quatro variáveis têm de ser controladas no projeto – custo, tempo, qualidade e escopo. Dessa forma, o modelo desenvolvimento de software é dirigido sob a perspectiva de controlar as referidas variáveis. Em um projeto, as referidas variáveis são restrições inerentes ao produto final. Eventualmente se o custo e/ou o tempo forem escassos, é muito provável que a qualidade do produto entregue possa estar muito inferior àquela esperada no escopo do projeto.  A XP cria valores, princípios de atividades básicas e práticas para tentar conduzir bem os problemas correlacionados à efetivação dos riscos do projeto. Esses valores podem ser caracterizados em:
  1. Comunicação: deve ser extremamente aberta e franca. A XP dá uma ênfase especial à comunicação e é essencial para tudo o que acontece no contexto de um projeto. Segundo [BECK, 2004], “Os problemas nos projetos podem ser invariavelmente rastreados a alguém não ter conversado com alguém mais sobre alguma coisa importante”.
  2. Simplicidade: é representada na XP pela busca pela “coisa mais simples que possa funcionar” [BECK, 2004]. O propósito é construir algo simples e direto que solucione problemas de hoje e ter certeza de que isso seja suficientemente flexível para ser refinado e expandido de modo a solucionar os problemas de amanhã, mas fundamentalmente não se preocupa hoje com os problemas de amanhã.
  3. Feedbackseu objetivo é criar ciclos de realimentação que atuam em intervalos de tempos pequenos como dias e minutos, em relação aos testes de unidade, e, grandes semanas (dias, semanas) em associação a teste de aceitação de usuário, e,  planejamento e cronograma de projeto.
  4. Coragem: é o valor que permite aos participantes da XP se aventurarem em projetos de alto risco e alta recompensa nas tarefas de desenvolvimento. Isso muitas vezes se manifesta na forma de desenvolvedores que constroem protótipos descartáveis durante a codificação.
Princípios Fundamentais da XP De acordo com [BECK, 2004] os princípios fundamentais da XP são:
  1. Feedback rápido: o princípio é obter o feedback, interpretá-lo e aplicar o que é aprendido no sistema o mais rápido possível, realimentando o que foi aprendido em dias ou semanas, em vez de meses ou de anos.
  2. Simplicidade presumida: este princípio dita que a equipe deve pressupor que todo problema tem uma solução razoavelmente simples. Como conseqüência, o tempo poupado na maioria dos problemas para os quais isso é válido pode ser usado para abordar problemas que realmente necessitem de soluções complexas.
  3. Mudanças incrementais: parte do princípio que grandes modificações feitas de uma só vez têm grandes chances de não dar certo. Assim, qualquer problema é resolvido por meio de uma série de mudanças menores.
  4. Aceitação das mudanças: este princípio se apóia na premissa da XP que de desenvolver software no contexto de requerimentos vagos ou que mudam rapidamente. As idéias é que os membros da equipe devem simplesmente aceitar as mudanças como algo natural, diário, em vez de algo que ocorre eventualmente.
  5. Alta qualidade: ninguém gosta de fazer um trabalho de baixa qualidade. Todos gostam de fazer um bom trabalho. A XP defende que se você não vai fazer algo bem, então não faça independentemente das restrições de cronograma e orçamento.
Atividades Básicas do Desenvolvimento [BECK, 2004] define quatro atividades básicas associadas ao desenvolvimento de software utilizando XP, sendo elas:
  1. Codificar: as práticas da XP utilizam o código como um mecanismo para atingir objetivos secundários incluindo o aprendizado rápido e uma melhor comunicação. Algumas das práticas citadas no tópico a seguir estão ligadas à codificação: refatoração, programação em pares e integração continua.
  2. Testar: está fortemente relacionada à codificação. Os desenvolvedores devem escrever códigos de teste de unidade antes escrever o código e verificar se o código passa por todos esses testes antes de se tornar um sistema. O cliente também é envolvido nos testes funcionais, onde os mesmos devem confirmar se o sistema satisfaz as regras de negócio.
  3. Escutar: refere-se à necessidade de estruturar a comunicação de modo que as conversas, sempre que possível, envolvam os problemas de hoje, não os de amanha, em um nível de detalhe apropriado.
  4. Projetar: está associado a necessidade de criar uma estrutura que organiza a lógica dentro do sistema de modo a torná-lo robusto e possível de manter. Nesse contexto, a prática utilizada é projetar simples.
Práticas do XP [BECK, 2004] lista algumas práticas que devem ser seguidas pela equipe de desenvolvimento para que os valores, princípios e atividades básicas da metodologia sejam alcançados, são elas:
  1. O jogo do planejamento:determinar o escopo da próxima versão de forma que os requisitos mais importantes sejam contemplados e a entrega possa ser um praza não muito longo. Quando o planejado fugir do realizado, então o plano deve ser reajustado.
  2. Entregas freqüentes: dividir o desenvolvimento em pequenos módulos de acordo com as funcionalidades de forma que possa ser rapidamente colocado em produção.
  3. Metáfora: conduzir o desenvolvimento por meio de histórias simples, compartilhada por todos os envolvidos, sobre como o sistema deverá funcionar.
  4. Projeto Simples: o sistema deve ser pensado e projetado de maneira simplista. Complexidades desnecessárias são removidas assim que descobertas.
  5. Testes: os programadores escrevem os testes de unidade durante todo o desenvolvimento, o qual deve ser executado sem falha para o desenvolvimento continue.
  6. Refatoração: os programadores se preocupam sempre em deixar o código estruturado removendo códigos redundantes, simplificando e aumentando a flexibilidade.
  7. Programação em pares: todo o desenvolvimento é realizado por programadores trabalhando em pares.
  8. Propriedade coletiva: todos podem alterar o código em qualquer trecho e em qualquer momento.
  9. Integração contínua: integre e atualize as versões do sistema várias vezes por dia, cada vez que uma tarefa fora terminada.
  10. Semana de 40 horas: como regra, trabalhe no máximo quarenta horas por semana, evitando fazer hora extra por duas semanas consecutivas.
  11. Cliente presente: mantenha o cliente o mais próximo possível para responder a questões.
  12. Padrões de codificação: os programadores escrevem código respeitando as regras que enfatizam comunicação através do código.
Referência:  BECK, Kent (2004). Programação eXtrema explicada: escolha as mudanças, Bookman, 2004.

quinta-feira, 17 de novembro de 2011

10 erros na implantação do Scrum que você não quer cometer

Muitas empresas de software tem buscado a “solução mágica” no Scrum, mas não estão obtendo o resultado esperado. A maioria delas, após alguns meses, desiste do framework e volta ao ad-hoc, culpando-o pelo fracasso. Mas será que essas empresas estão implantando corretamente?

Pelo que tenho visto, a maioria tem feito “adaptações” no framework que tiram algumas de suas características essenciais. Por exemplo, o intenso ciclo de comunicação garante alinhamento de expectativas; a constante revisão de escopo garante coesão no projeto; as entregas intermediárias buscam atendimento da necessidade do cliente e correção de falhas antes do final do projeto; o conceito de timebox força a equipe a ter o que entregar, evitando o prolongamento de atrasos. Ora, esses benefícios são provenientes dos princípios embutidos no Scrum e adaptar o processo pode trazer resultados desastrosos.

Mas quais são os erros mais frequentes? Fiz um levantamento de erros comuns e que levam a implantação do Scrum ao fracasso:

1.Vestir a capa de scrum, mas trabalhar cascata
Sprints são timeboxes, ou seja, um tempo fechado em que se realizam entregas parciais do projeto. As entregas são priorizadas para que, ao final do tempo, exista uma ”saída”, “alguma” entrega.
Montar sprints como etapas ou fases de um projeto é um erro. Dessa forma perdem-se os benefícios do ciclo de melhoria contínua (que muito lembra o PDCA), mais conhecido como iterativo-incremental, que grossomodo significa entregar parcialmente e agregar valor ao produto a cada ciclo, através da melhoria contínua. Portanto, é importante que as entregas sejam parciais e evolutivas.
2.Impor prazo de “cima para baixo”
A definição de “prazos arbitrários” é uma prática condenada também pelo PMI, deve-se envolver os executores das atividades na fase de Planejamento. O Scrum não precisa de nada disso, ele trabalha com sprints e invés de um prazo fechado. Precisam-se de entregas priorizadas para que a equipe “decida” o que vai ser entregue, caso no prazo não seja possível terminar tudo.
Existe muita polêmica em relação a essa questão, pois as pessoas se sentem desconfortáveis em afirmar que a equipe “poderá não entregar tudo”, mas no mundo real muitas equipes não realizam as entregam na data combinada e atrasam os projetos. O Scrum não quer dizer que a equipe vai fazer “corpo-mole” e deixar de entregar as coisas, pois existe um monitoramento diário das atividades e as entregas são parciais. Desse modo, não haverá aquela pressão do último dia, mas uma pressão a cada sprint, reduzindo o risco de um atraso maior. Além do mais, a equipe fica ciente de que deve fazer primeiro o que for prioridade e que SE for preciso, entreguem parcialmente, mas jamais deixem de entregar no prazo.
3.Realocar membros da equipe para outros projetos “mais prioritários”
A mudança de prioridade entre projetos não combina muito bem o com o agile, pois ele tem como premissa o trabalho integrado, colaborativo e priorizado. Toda a motivação da equipe no Scrum (segundo minha percepção) vem do agrupamento, do cumprimento de metas e da cobrança mútua, parâmetros estimulados pelo Scrum de um modo geral. Além disso, lições aprendidas, sincronia e alto desempenho serão perdidos com a troca de “componentes” (de pessoas).
4.Não fazer reunião diária
É na reunião diária que se faz a gestão da equipe, do desenvolvimento das entregas, da qualidade e dos problemas. Não cumprir essa prática rompe com os ciclos de comunicação, acompanhamento e põe em risco a entrega do Sprint. Além disso, o relato de desempenho diário faz com que a equipe se cobre mutuamente impulsionando a produtividade.
5.Não endereçar e resolver os impedimentos
No Scrum, as pessoas são incentivadas a comentar o trabalho que estão fazendo diariamente (como descrito acima) e também qualquer impedimento que esteja causando impacto em suas atividades. Se você não resolver os impedimentos com muita seriedade, elas simplesmente vão parar de reportar, não cumprirão os prazos e eventualmente até boicotarão o processo. Neste caso, a frase mais comuns nos corredores é: “Eu já falei, mas ninguém faz nada!”.
6.Fazer a reunião diária sem o quadro de acompanhamento
Sem o quadro de acompanhamento fica impossível controlar o andamento do trabalho. Todo tipo de Controle precisa de uma linha de base de comparação, no caso do Scrum essa linha de base é o quadro de acompanhamento.
7.Não gerar o gráfico de burndown
O gráfico de burndown é uma das ferramentas mais poderosas de comunicação do Scrum. Permite que clientes, gestores e equipe tenham uma visão real e atualizada do projeto todo. Ele pode ser feito tanto para os Sprints quanto para os itens do Product Backlog e ajuda a prever a data final do projeto. Lembre-se, sem linha de base não existe controle, sem controle não existe sucesso.
8.Criar sprints estanques
Todo sprint deve ter um objetivo, mas não entregas fixas e invidivisíveis, pois há perda de agilidade. Quando uma entrega está travada (com dificuldade para ser implementada), a equipe pode decidir passar para a próxima entrega, enquanto os impedimentos são resolvidos, ou montar uma força-tarefa para resolver o impedimento . Isso ajuda a chegar no prazo final com alguma entrega pronta, apesar dos percalços. Sem flexibilidade, a chance de atrasos é muito maior.
9.Atrasar o prazo final dos sprints
Scrum é timebox, é ”quanto consigo fazer até o final do sprint”. Isso força a equipe a pensar sempre em entregas funcionais e aceitas pelo cliente, a buscar alternativas, a se superar. Mudar essa perspectiva para “quando consigo entregar um grupo de funcionalidades” pode levar a equipe a atrasos. A pressão deve estar totalmente voltada para a entrega.
10.Ter um Scrum Master sem autoridade (grupos matriciais)
O Scrum Master precisa de autoridade suficiente para planejar, organizar, comandar, coordenar e controlar as atividades de sua equipe. Se uma autoridade externa influenciar na alocação, impuser prioridades ou simplesmente retirá-los da equipe fica muito difícil o SM conseguir formar uma equipe de alto desempenho, como é esperado. Mas quando a equipe+SM não tem autoridade para determinar as atividades e prioridades dentro do sprint, o resultado é totalmente fora do esperado.
A maior dificuldade para as organizações tem sido mudar o dilema: é melhor ter um prazo ou entregar um produto funcional ao final de um período? É melhor ter um escopo congelado ou entregar um produto que corresponde às necessidades do cliente? É melhor ter atas de reunião e relatórios ou fazer uma comunicação simples e entregar o produto no final do projeto?

Esses princípios têm dado bons resultados em vários lugares ao redor do mundo, analise se sua empresa está realmente seguindo os princípios certos, o melhor indicador são os resultados (entregas e clientes satisfeitos), a metodologia pouco importa.