Metodologias Ágeis: um caminho para a eficiência. Será?

Essa semana eu vi a seguinte frase na empresa em que trabalho: “Fazer mais, melhor e mais rápido: este é o objetivo de toda organização que oferece um produto ou serviço para os consumidores (....). Por isso, para oferecer maior eficiência e eficácia em suas atividades, uma novidade vem sendo introduzida nas atividades de desenvolvimento de sistemas. São as metodologias ágeis.(...)”

Gerentes de projetos que atuam na área de desenvolvimento de software convivem com desafios de liderar projetos com cronogramas apertados, metas audaciosas, constante mudanças de requisitos, novas tecnologias e sistemas de informações que cada vez mais suportam a tomada de decisão e os processos chave de negócio das empresas. Em um cenário como esse, ser ágil é crucial, todavia ser ágil não necessariamente é ser mais rápido.

          Porém ser ágil acima de tudo é:

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”

O termo "ágil", nas metodologias ágeis, significa basicamente aderir aos princípios estabelecidos no manifesto ágil (http://www.agilemanifesto.org/). 

Não tem necessariamente a ver com mais rápido. Note que é apenas 

uma palavra, escolhida por um grupo de desenvolvedores de software, 

para representar um conjunto de idéias. Infelizmente, somos levados a 
olhar para o significado habitual da palavra, ou seja, velocidade. 
Porém, em desenvolvimento de software ser rápido engloba um 
significado muito maior, como por exemplo: maturidade da equipe com a tecnologia envolvida, projeto com o mínimo de integrações possíveis, processo de desenvolvimento de software clean e maduro na organização, etc...


    Enfim, o "Ser ágil" está sintetizado na imagem abaixo. Afinal, para você quem é mais rápido e quem é mais ágil?

Os 5 objetivos que precisam ser perseguidos nos projetos de TI

Recentemente os capítulos do PMI no Brasil divulgaram os resultados do Estudo de Benchmarking em GP que envolveu cerca de 300 empresas dos setores de tecnologia da informação, Consultoria, Serviços, Indústria, Engenharia e EPC, Governo.

O relatório é o resultado do trabalho voluntário de vários profissionais de todo o país, representando suas respectivas seções regionais do Project Management Institute - PMI.

O CEO/EUA publicou ontem uma matéria falando sobre: Os cinco objetivos que precisam ser perseguidos nos projetos de TI

Dicas, alguns resultados do estudo e considerações pessoais, você encontra aqui. Boa leitura!
 
Os gerentes de projeto têm a responsabilidade de gerir todos os aspectos das atividades que estão supervisionando, desde recursos e suprimentos até custos de projetos e equipamentos. No começo, parece difícil, mas basta seguir uma metodologia de trabalho que consiste em seguir objetivos relacionados ao projeto. Confira os cinco objetivos que você deve perseguir para alcançar sucesso em cada novo projeto.

1 – Termine no prazo
Esse é o mais velho dos objetivos, mas ainda assim o mais difícil de cumprir, em se tratando de gerenciamento de projetos. A dificuldade está nas constantes mudanças de requisitos e por conta do otimismo exagerado da agenda inicial.
O PMI em seu estudo comentado no inicio deste post fez a segunte pergunta:A Organização costuma ter problemas no cumprimento dos Prazos estabelecidos para os projetos? 72% das empresas de TI responderam sim para essa pergunta.

Para cumprir esse objetivo, o profissional deve gerenciar seu escopo muito cuidadosamente. A primeira coisa é criar um controle de alterações no projeto para gerenciá-los adequadamente. Sempre mantenha seu plano atualizado, com registros do progresso atual em relação ao que estava planejando. Identifique rapidamente qualquer desvio e trate de consertá-lo.

2 – Finalize o projeto dentro do orçamento
Para ter a certeza de que os custos do projeto não subam à estratosfera, você precisa ganhar visibilidade sobre custos logo no início para manter o controle. O budget deve ser elaborado incluindo todos os custos do projeto, não importando se tem a ver com pessoas, equipamentos, fornecedores ou materiais. Saiba, então, o custo de cada tarefa do planejamento e mantenha o controle para observar qualquer desvio.
A Organização costuma ter problemas no cumprimento dos Custos estabelecidos para os projetos? 59% das empresas de TI responderam sim para essa pergunta.

Com essa postura, se você gastar demais em alguma tarefa, consegue corrigir o orçamento gastando menos em outras. Só dessa forma é possível garantir que o projeto fique dentro do orçamento, ou até abaixo dele.

3 – Conheça os requisitos
Não importa qual é o objetivo do projeto, ele deve produzir soluções que atendam a 100% do que foi requisitado. O truque aqui é garantir a existência de uma lista bem detalhada dos requisitos necessários e ter a certeza que todos foram bem compreendidos. Isso porque requisitos ambíguos, que antes pareciam um pequeno fragmento do projeto, podem se tornar enormes, tomando tempo e recursos não esperados.
Adiciono a dica do CIO/EUA, a utilização do Product Backlog pregado pelo Scrum, que nada mais é que uma lista dos requisitos de forma priorizada. Assim o desenvolvimento, adotando um ciclo de desenvolvimento iterativo e incremental, poderá desenvolver primeiro os requisitos de maior prioridade para o cliente, obtendo mais rapidamente a satisfação dos usuários e o ROI para a organização.


4 – Mantenha os clientes felizes
Você pode até ter conseguido terminar o projeto a tempo, abaixo do orçamento e atendido 100% dos requisitos, mas ainda assim ter clientes infelizes. Isso pode acontecer porque suas expectativas mudaram desde que o projeto foi iniciado e não foram devidamente gerenciadas.

Para garantir que os patrocinadores do projeto, usuários e outros stakeholders fiquem felizes na entrega, algumas atitudes são necessárias. A primeira é ter certeza de que todos fiquem bem informados do progresso do projeto. Mantenha todos com o pé no chão com uma visão transparente do que está acontecendo.

Deixe que todos expressem suas preocupações e idéias com regularidade. Diga-lhes com antecedência se há algum problema com relação ao prazo de entrega ou quando mudanças são necessárias. Abertura, honestidade e clareza nas informações são sempre as melhores ferramentas para manter o projeto alinhado com as expectativas dos clientes.


5 – Zele pela felicidade da equipe do projeto
Se você conseguiu preencher os quatro objetivos anteriores com um time feliz, a disposição para repetir tudo em uma próxima vez será bem maior, assim como a disposição da equipe.

A melhor forma de manter a equipe motivada é reconhecer e premiar os bons trabalhos. Delegue atividades de acordo com os pontos fortes de cada um e conduza exercícios de equipe para aumentar a confiança. Divulgue metas e objetivos, promova, mesmo que de forma contida o autogerenciamento e a troca de informações do time.

Para finalizar, o estudo do PMI revelou também que para a maioria das empresas do ramo de TI, o maior problema enfrentado nos seus projetos é a: COMUNICAÇÃO.

Sendo assim, mais um ponto para as reuniões diárias de 15 minutos na qual cada membro da equipe deve responder a 3 (três) perguntas:

    O que cada um fez desde a última reunião?
    O que pretende fazer até a próxima reunião?
    Teve ou está tendo algum impedimento?

    Através desta reunião o time(equipe) obtém uma maior visibilidade de como está o projeto e se estão de fato alinhados com as metas e objetivos.

Até mais!
 

Fontes:

1) Estudo de Benchmarking em Gerenciamento de Projetos Brasil 2009, Project

Management Institute – Chapters Brasileiros.

2) Matéria disponível em: http://cio.uol.com.br/gestao/2010/04/26/os-cinco-objetivos-que-precisam-ser-perseguidos-nos-projetos-de-ti/

3) http://www.scrumalliance.org/

Ferramenta de Software Livre para Gestão Ágil de Projetos

Pessoal,

Em uma pesquisa na web encontrei um software chamado "ponto", ele é voltado para o gerenciamento ágil de projetos, vale a pena testar.

Um pouco da histórica do "ponto".

O projeto "Pronto" surge no final do ano de 2008 como um trabalho de conclusão do curso Sistemas de Informação da FIAP - Faculdade de Informática e Administração Paulista.

Foi idealizado por Luiz Faias Jr e André Faria Gomes, com a orientação do Prof. MSc. Jakov Trofo Surjan.

Em junho de 2009 entrou em produção como o sistema de gestão do trabalho da Bluesoft, em substituição ao software Trac.

Sua apresentação ocorreu em 07/12/2009 com aprovação pela banca examinadora.

A versão final da monografia encontra-se disponível no formato PDF.

O Sistema e a monografia podem ser acessados pelo site: http://pronto.bluesoft.com.br/Home

Bons testes. opa eu já fiz uns... muito bacana por sinal.

Trabalhando com equipes ágil

Tradução livre (Com adaptações) de trecho do artigo “The Agile Project Manager” escrito por Mike Cottmeyer e publicado pela VersionOne.com.


Trabalhando com equipes ágil



Não é sempre que uma equipe irá exigir um gerente de projetos dedicado. Muitos projetos ágeis contam com membros da equipe que pode executar mais de uma função. Um membro da equipe de desenvolvimento ou um Product Owner pode servir como o Gerente de Projeto para uma pequena equipe ágil. Entretanto, um gerente de projetos pode ser convidado para assumir um papel na equipe com o objetivo de ajudar a preencher uma lacuna entre a equipe e a empresa ou para gerenciar as atividades que acontecem fora do próprio time.

O Gerente de Projeto pode ser convidado a trabalhar em um projeto ágil porque há necessidade de definir um plano de comunicação, uma abordagem de gerenciamento de risco, ou de coordenar as atividades de diversas equipes que trabalham em conjunto para entregar um grande projeto ou carteira de projetos.

O Gerente de Projeto deve tornar-se parte da equipe e envolver outros membros na criação de planos e artefatos do projeto. Isso ajuda manter um ambiente de alta confiança e da garantia as membros do time.

A iteração Agile começa com um período intenso de colaboração seguido por mais interações ad-hoc entre os membros da equipe. O gerente de projeto pode ajudar a equipe se aglutinam em torno de iteração e das metas, garantindo que os compromissos sejam razoáveis e baseados em um ritmo sustentável e métricas de monitoramento dentro da iteração e global através de iterações.

A maioria das metodologias ágeis não defini explicitamente o papel de um
Gerente de Projetos. No Scrum muitas das responsabilidades do gerente de projetos foram distribuídas entre o papel do Product Owner e do ScrumMaster. Entender funções do projeto e ajudar a definir responsabilidades são atribuições importantes, típicas de um Gerente de projetos, principalmente quando há integração com uma equipe ágil de projetos.

Amigo “Líder”: Você seria liderado por si mesmo?

Texto de Manoel Pimentel


Há alguns anos atrás, gerenciava uma pequena equipe de TI numa indústria alimentícia. Foi um tempo muito bom e antes de toda a correria pré “bug do milênio”. As aplicações MS-DOS (Leia aplicações Clipper) reinavam e tecnologias como NOVELL e NT eram o grande paradigma em debate.

Nesse pequeno ambiente de TI (que na época chamávamos de CPD), tive uma oportunidade de num contexto extremamente caótico (sobre o ponto de vista organizacional) liderar essa equipe rumo a projetos de desenvolvimento de software ambiciosos para a época e conjuntura regional da empresa.

Como na época nem sonhávamos com algo chamado Agile, confesso que se fosse hoje, faria muita coisa diferente nesses projetos. Contudo, o objetivo desse artigo não é debater o processo, mas sim mostrar um aspecto cultural importante, que é exatamente a forma como os líderes pensam e atuam dentro das equipes.

Não que nessa época eu tenha sido um ótimo líder; Na verdade minha juventude e inexperiência ainda eram muito grandes (que saudade desse tempo...). Mas para compensar essas limitações, acabei construindo e adotando um pensamento que me foi extremamente útil na liderança desse time.

Esse pensamento é bem simples, pois consiste no seguinte auto questionamento: Eu aceitaria ser liderado por mim mesmo? Essa é uma pergunta extremamente simples e direta, porém, respondê-la a você mesmo é enormemente complicado.

Eu diria que essa pergunta me acompanha desde então, de forma que quanto mais eu fui interagindo com outras equipes (de diferentes lugares e tamanhos) e me aprofundando em meu trabalho de coaching, mais forte se tornou minha convicção que mesmo sendo complicado responder essa pergunta, é muito benéfico colocar o cérebro em busca dessa resposta.

Afirmo que é benéfico buscar por essa resposta, pois esse processo de procura, pode mexer de maneira desconfortável com a sua estrutura de crenças e valores. Esse desconforto acontece pois a busca por essa resposta, criará uma espécie que espelho no qual é possível refletir quais os seus valores e crenças e, as vezes a imagem refletida nesse espelho não é bonita.

Mas alem de refletir sobre seus valores e crenças, é muito importante também você procurar visualisar nesse espelho, o quanto esse conjunto de pensamentos estão limitado suas ações como um bom líder e consequentemente, impedindo a sua equipe de gerar melhores resultados.

Veja que buscar respostas para essa singela pergunta, já nos coloca num caminho de mudança de pensamento, contudo, existe uma lacuna entre o pensamento e a ação. Essa lacuna é preenchida com a emoção. Ou seja, mesmo que você mude seu pensamento, somente se houver alguma emoção, ele provocará ações para uma verdadeira mudança de comportamento.

Apesar de haver uma lista de emoções possíveis para ligar um pensamento a uma ação, todas elas são originárias de dois tipos de sentimentos: Dor ou Prazer. Ou seja, você só mudará realmente seu comportamento se houver uma dor atual suficientemente capaz de lhe motivar para uma ação de saída da dor, ou um desejo por um prazer (seja na meta fim ou processo meio) capaz também de o motivar a mudar suas ações .

Curiosamente as palavras emoção e motivação derivam da mesma origem latina que é a palavra movere, que trazendo para o português, teríamos algo como mover-se (existem outras variações também). Portanto, veja que despertar essa emoção em nós, é a chave para compreendermos e construirmos a motivação necessária para nos levar de um estado atual(ponto A) para um estado ideal(ponto B), assim, um líder, só será um excelente líder, se o mesmo tiver algum motivo que provoque essa mudança de pensamento e de comportamento (afinal líder é “gente” e também precisa de motivação) . E esse espelho criado quando fazemos esse questionamento, já é um bom ponto de partida para gerar essa emoção.

Na verdade a essência desse questionamento (Você seria liderado por si mesmo?) pode ser aplicado a vários outros contextos em nossas vidas, por exemplo, experimente responder para si mesmo algumas questões como: Você contrataria a si mesmo? Ou: Você usaria um produto feito por você? Ou mais profundo ainda: Você se casaria com consigo mesmo?

Finalizo esse breve texto lembrando que não estou aqui dizendo a você: “seja um líder tipo tal” ou “siga determinado estilo ou processo gerencial”, mas pretendo com esse texto estimular que você (líder) encontre seu próprio caminho rumo a sua visão daquilo que acredita ser um ótimo líder dentro do seu contexto. Também quero reforçar que idealmente esse tipo de questionamento não seja usado apenas uma única vez, mas sim de maneira constante e cíclica, pois assim, será possível criar um cenário propício para a tão sonhada melhoria contínua de indivíduos e de equipes. Dessa forma, para exemplificar a importância desse pensamento em minha vida, vou lhe compartilhar qual o meu pensamento final quando termino um artigo como esse: Eu leria um artigo escrito por mim mesmo?

Onde surgiram os métodos ágeis?

Em Janeiro de 1986 foi apresentado na Harvard Business Review um artigo chamado “The New New Product Development Game” (TAKEUCHI e NONAKA, 1986), onde os autores chamam a atenção dos gestores para perceberem que a tradicional abordagem seqüencial usada para desenvolvimento de novos produtos não funcionaria no cenário atual. Eles afirmaram que, os gestores de projetos devem adotar uma abordagem mais flexível, ou seja, uma estratégia global de desenvolvimento de produto em que uma equipe de desenvolvimento funciona como uma unidade para alcançar um objetivo comum. Compararam ainda o alto desempenho de equipes multifuncionais com formação Scrum usadas por equipes de um jogo chamado Rugby.
Tal publicação desencadeou uma serie de discussões no mundo acerca da necessidade de mudança na forma como se gerencia e desenvolve projetos.

Em 2001, Kent Beck e outros 16 famosos desenvolvedores, produtores e consultores de software assinaram o “Manifesto para o Desenvolvimento Ágil de Software”. Na época eles afirmaram que estavam descobrindo maneiras melhores de desenvolver software, fazendo e ajudando outros a fazê-lo. Por meio desse trabalho passaram a valorizar:

Indivíduos e interações em vez de processos e ferramentas;
Software funcionando em vez de documentação abrangente;
Colaboração do cliente em vez de negociação de contrato;
Responder a mudanças em vez de seguir um plano;

Isto é, embora haja valor nos itens em à direita, eles valorizam mais os itens à esquerda.
Segundo Ken Schwaber(2004), quanto mais complexo o projeto, mais necessário se torna para delegar a tomada de decisões a agentes independentes que estão perto do trabalho.

O documento “The New New Product Development Game” pode ser facilmente encontrado na internet.

Boa leitura a todos.

Departamento de Defesa americano está adequando sua legislação para agilizar suas contratações de TI.

Mais detalhes em:
http://www.jessefewell.com/2009/10/02/defense-procurement-goes-agile/


"In his presentation, he cited a number of points that reveal a growing consensus within the military that old ways of procurement are becoming less effective. He started by noting the key regulatory standard for procurement, DODD 5000.1, was originally developed in 1977 and has remained mostly unchanged since then.
(...) eventually the momentum became so great in 2008, Congress responded to these concerns by mandating a Defense Science Board (DSB) to study current policies and procedures. At the end of their analysis, they recommended a new IT iterative, incremental approach to project acquisition and execution. The DRB’s recommendations have been so compelling, they were invited this past May/June to testify to Congress about their strategy"

Penso que é hora do Brasil avançar neste sentido também...

Mais sobre o assunto em:
http://blog.seatecnologia.com.br/2009/12/16/o-problema-da-contratauao-de-ti