Relatório do Caos - Por quê os Projetos Falham?

O Relatório do Caos é criado, anualmente, pelo Standish Group, e tem como objetivo apresentar um estudo sobre o cenário de projetos de TI. Para o estudo, o relatório apresenta uma comparação entre projetos para contrução de pontes e projetos de sistemas. O motivo do relatório escolher tal comparação, deve-se ao fato de serem projetos com características opostas. Enquanto um projeto de contrução de ponte tem pouquíssimia possibilidade de mudança de escopo, projeto de sistemas tem muita necessidade de mudança, devido ao dinamismo de seu mercado.

Para o relatório, projetos de contrução de pontes são, mundialmente, vistos como projetos de sucesso. E, quando fracassam, as causas do fracasso são investigadas profundamente, o que impede, ou mitiga, a possibilidade de repetição. Nos casos de projetos de sistemas, em caso de fracasso, suas causas não são investigadas e tratadas de forma correta, o que direciona para sua repetição.

O relatório aponta números impressionantes sobre os valores desperdiçados, por grandes empresas, devido a projetos que são cancelados antes mesmo de serem concluídos. Apenas nos Estados Unidos, 31% dos projetos são cancelados em fase de construção, o que implica em mais de 81 bilhões de dólares em prejuízos. E quando o projeto é concluídos, apenas 16% são entregues no prazo e custo estimados e com cerca de apenas 42% dos requisitos originais.

Mas por quê isto acontece? Por que os projetos de TI possuem números tão assustadores? 

Acredito que a maior causa dos problemas esteja relacionado justamente com a comparação realizada pelo instituto para criação do relatório. Os projetos de TI nasceram com os conceitos da construção civil, como a fase de planejamento, a engenharia, arquitetura e contrução. Muitas metodologias de gestão colocam  projetos de TI no mesmo patamar de outros projetos. Porém o dinamismo do mundo corporativo, não permite tal inclusão.

Eu costumo fazer uma alusão entre projetos de TI e seriados de TV, que acredito serem muito mais parecidos. Requisitos de projeto são como personagens do seriado; crescem de importância ou são excluídos de acordo com o andamento do projeto, ou seriado. E a comunicação entre a equipe técnica com seu cliente, é parecida com o retorno dado pelo público, durante a temporada de um seriado.

Outro ponto que difere projetos de TI dos demais projetos, é o fato de sistemas serem menos visíveis e tangíveis durante seu desenvolvimento. Em uma casa, ou ponte, podemos ver o que é contruído a cada etapa, sentir e tocar. Projetos de TI, por vezes, impedem tal percepção.

Por isso precisamos fazer com que o cliente esteja próximo da equipe técnica durante toda a fase de desenvolvimento de sistemas. Apresentar cada item desenvolvido e receber feedbacks sobre o andamento do projeto. E, para isso, precisamos mudar conceitos e buscar, no mercado, metodologias que embasem projetos de TI como algo singular, seja ágil ou não. Porém, o mesmo relatório aponta que projetos de TI, embasados por metodologias ágeis, apresentam melhores resultados. 

Até o próximo post.

AMDD e TDD - Arquitetura, Modelagem e Desenvolvimento Ágil

Os princípios, mencionados no artigo Ciclo de Vida de Desenvolvimento de Sistemas Ágil, podem ser utilizados junto à outras metodologias, ou conceitos, para se criar um processo de desenvolvimento de sistemas. Um desses conceitos é a Modelagem de Desenvolvimento Dirigira (MDD em inglês). Esse conceito guia como agrupar os requisitos do projeto, como modelá-los e como arquitetar a solução para atender aos requisitos. Assim, ao ser utilizada sob o foco ágil nasce a Modelagem Ágil de Desenvolvimento de Sistemas (AMDD em inglês).

Esse conceito pode ser utilizado juntamente com diversas metodologias ágeis para completar o Ciclo de Vida do Desenvolvimento de Sistemas. Isto é, a metodologia escolhida suportará o planejamento do projeto bem como suas alterações, como criar o fluxo de comunicação e etc. E o AMDD proverá como realizar estas tarefas, do ponto de vista da equipe técnica. Isto é, como dividir o desenvolvimento em iterações, como criar e manter os documentos necessários para o projeto.

Agile Model Driven Development

A Figura acima - http://www.ambysoft.com/essays/agileLifecycle.html - apresenta as tarefas realizadas em cada iteração do projeto, a partir da iteração 0 – início do projeto. A caixa verde mostra as atividades da iteração 0. Nesta fase, os requerimentos iniciais são modelados assim como a arquitetura inicial do projeto, ambos em caráter de macro-visão.

O modelo, dos Requisitos Iniciais representa a lista de requerimentos que os clientes necessitam que o sistema possua ou execute. Esta lista é chamada de Product Backlog, e contém os requisitos, ordenados por prioridade – as prioridades representam quais requisitos retornam mais valor ao negócio –, e nortearão a equipe técnica a desenvolver e entregar os requisitos mais importantes primeiro, assim como a estimar a duração do projeto de maneira mais eficiente.

É importante ressaltar que esta lista pode ser alterada durante o projeto pelos clientes, com a inclusão, mudança ou retirada de algum requisito. Porém tais alterações são realizadas em momentos específicos, como veremos a seguir.

O modelo da Arquitetura Inicial representa a arquitetura que será utilizada pela solução em uma visão macro. Isto é, o modelo proverá qual tecnologia será utilizada, qual a linguagem de programação, banco de dados, se será Web ou Cliente-Servidor e etc. O detalhamento da arquitetura como componentes, seqüência ou classes serão modelado no início de casa iteração de Construção.

As caixas azuis representam as iterações de Construção, seguintes à iteração 0. Cada iteração de Construção possui a mesma estrutura. Isto é, cada uma das iterações começa, se desenvolve e termina através do mesmo processo.

Ao dividir o Product Backlog, criado na iteração 0, em sub-listas, uma nova lista será criada. Esta nova sub-lista chama-se Sprint Backlog.

O Sprint Backlog proverá ao time de desenvolvimento quais requisitos serão desenvolvidos durante a iteração atual. Ainda que o Sprint Backlog possa ser alterado pelos clientes, é primordial que este seja congelado, no início da iteração, de modo a estabilizar o trabalho da equipe técnica. Assim, se algum requisito, pertencente ao Sprint Backlog, necessitar de alterações, um novo requisito deve ser criado e priorizado para próxima iteração. Se esta alteração é realmente importante, os clientes devem escolher um outro requisito para ser substituído, ou projetado para uma próxima versão do produto.

A primeira atividade de cada umas das iterações de Construção é avaliar e validar o Sprint Backlog. Esta atividade está incluída na tarefa de Modelagem da Iteração. Esta atividade é muito importante, pois através dela é possível certificar que o prazo da iteração é viável e que seus requisitos são possíveis de serem desenvolvidos. Outro ponto é que este é o momento em que os clientes podem sugerir mudanças do escopo de maneira mais eficaz e com menos riscos para a qualidade do projeto.

Além disso, nesta atividade, o modelo da arquitetura é revisto e detalhado para incluir os itens necessários para o desenvolvimento da iteração atual.

A melhor maneira de se criar o Modelo de Tomada (Model Storming) é se reunir com a equipe técnica, por cerca de 30 minutos em média, e analisar todas as possibilidades de risco para o item e apontar a melhor estratégia de desenvolvimento. Esta tarefa é feita para cada item a ser desenvolvido na iteração atual.

A tarefa de Desenvolvimento Dirigido à Teste (TDD em inglês) adiciona a documentação e o desenvolvimento efetivo dos itens. TDD é um conceito que suporta estratégias de desenvolvimento de sistemas, onde o desenvolvedor primeiro constrói o teste que deve ser feito para validar o item desenvolvido e, em seguida, constrói o código fonte para atender os testes com sucesso.

De acordo com este conceito, o desenvolvedor cria o teste necessário para validar alguma funcionalidade e, em seguida, começa a desenvolver o fonte para implementar a funcionalidade. A idéia é criar o código fonte passo a passo – cerca de 10 linhas – sempre testando o código. A funcionalidade está criada com sucesso, quando os testes rodam com cucesso. A figura abaixo apresenta como o TDD funciona.

Test Driven Development

Se o TDD for bem implementado, os testes criados serão utilizados como a documentação técnica e o código certamente será bem executado. Entretanto, nem todas as funcionalidades do sistema deve ter um teste implementado. Somente códigos críticos ou complexos deveriam ter testes implementados. O desenvolvedor deve pensar se a funcionalidade é complexa o suficiente para requerer uma estratégia TDD.

Assim, no final de cada iteração, depois de todos os itens pertencentes ao Sprint Backlog serem desenvolvidos, o sistema estará pronto para ser entregue à equipe de Testadores para certificarem-se que o produto não possui problemas. Se tudo estiver bem, os clientes podem iniciar seus testes. Estes testes proverão um parecer se os requerimentos foram desenvolvidos como necessário e se eles estão satisfeitos com o sistema.

Se tudo estiver de acordo, o projeto segue paras as próximas iterações. Caso contrário, as mudanças necessárias são implementadas e testadas, conforme o ciclo de vida do projeto. 

Até o próximo post.

Ciclo de Vida de Desenvolvimento de Sistemas Ágil

Todo projeto de desenvolvimento de sistemas possui o mesmo fluxo, não importa o tamanho ou propósito. Começam devido alguma necessidade e terminam com a entrega de um produto. Este fluxo é chamado de Ciclo de Vida de Desenvolvimento de Sistemas (SDLC em inglês). Tanto as metodologias tradicionais quanto ágeis possuem um tipo de SDLC.

A Figura abaixo apresenta um Cico de Vida de Desenvolvimento de Sistemas baseado no Scrum (extraída da página: http://www.ambysoft.com/essays/agileLifecycle.html). Segundo a figura, o projeto é dividido em fases subseqüentes e as fases de construção em sub-projetos.

A iteração -1 representa a pré-fase do projeto, quando os requerimentos são levantados e apurados. Esta iteração é de responsabilidade do cliente junto à área de negócios. Isto é, eles devem entender quais suas necessidades e listar o que gostariam que fosse desenvolvido. A responsabilidade da equipe técnica do projeto é garantir que é possível entregar o que os clientes esperam.

A iteração 0 determina o início do projeto. Após o projeto ser aprovado e iniciado, o escopo é fechado e os requisitos listados e priorizados. Os clientes, junto com a equipe técnica, irão priorizar os itens e dividi-los em sub-listas. A quantidade de sub-listas tornarão-se a quantidade de iterações da Fase de Construção. Nesta iteração o ambiente começa a ser planejado e configurado. Isto é, o número de estações de trabalho são listadas, as configurações dos servidores revistas, licenças de aplicativos revista – para garantir que a equipe terá condições de trabalhar – ou qualquer outra informação relevante para garantir não só o encaminhamento do projeto, mas como a operação deste em produção. E finalmente, a equipe do projeto é arquitetada, isto é, quantos desenvolvedores, testadores, arquitetos e demais estarão inclusos no projeto e por quanto tempo.

As iterações de Construção são todas as iterações necessárias para desenvolver o sistema. Cada uma possui as mesmas atividades. Isto é, todas possuem as tarefas de análise, desenvolvimento, teste e publicação dos pacotes, e devem possuir durações curtas, de 2 a 4 semanas. Devido à existência de todas essas tarefas, as iterações de Construção são consideradas sub-projetos.

No início dessas iterações, a equipe técnica define os itens que serão desenvolvidos. Então inicia-se a modelagem, desenvolvimento e teste destes itens (a maneira de como planejar as atividades foi comentado no artigo Planejamento Ágil).  Para criar um fluxo de comunicação, dentro da equipe técnica, claro e objetivo, o time deve realizar uma reunião curta toda manhã. O Scrum nomeia esta reunião como Stand Up Meeting, o que em português significa Reunião em Pé. Está reunião tem curta duração e deve ser realizada em pé (razão de seu nome) por volta de 15 minutos, onde o time discute o que foi feito desde a última reunião, o que será feito até a próxima e se existem impeditivos para tal. Sua realização proverá, à cada integrante da equipe, uma visão geral do andamento do projeto e prevenir que o time caminhe para um caminho errado.

Ao final do desenvolvimento de cada item, dentro da iteração, os desenvolvedores devem testar o que foi desenvolvido. O ideal seria que um outro desenvolvedor, ou o líder do desenvolvimento, testassem algo que foi desenvolvido, como uma revisão de código. Isto ajudaria a equipe a entregar sistemas com mais qualidade, pois os testes seriam realizados de uma maneira menos viciada. Além disso, esta ação podem aprimorar a confiança dos clientes, nos produtos e no time de desenvolvimento, pois eles terão produtos com menos problemas. Ao final de cada ciclo da iteração de Construção, a equipe de Qualidade testará o pacote entregue, para garantir a confiabilidade e qualidade do produto.

Em seguida aos testes da equipe de qualidade, os clientes podem realizar seus testes. Se os clientes avaliarem positivamente o produto apresentado, eles estarão mais confiantes e entusiasmados para investir no projeto. Entretanto, se eles não avaliarem positivamente, o projeto pode ser cancelado – diminuindo assim o prejuízo por antecipar seu fim – ou alterações podem ser feitas para garantir que o projeto entregue valor real ao negócio.

Ao final de cada ciclo da iteração de Construção, bem como no final do projeto, uma reunião de Lições Aprendidas deve ser realizada. Esta reunião tratará de como o projeto foi conduzido e apresentará o que cada integrante entende como boas práticas para um próximo projeto e o que deve ser reformulado. Estas reuniões alimentarão uma base de conhecimentos compartilhada por todos na empresa e serão base para próximos trabalhos.

A fase de Release é a fase onde o projeto e publicado no ambiente de Produção. Se todas as outras fases obtiveram sucesso, esta fase representará um intragável que atende às necessidades do negócio. E este é sempre o maior objetivo do projeto. Entretanto, se alguma das outras fases obteve fracasso, ou foi realizada com ressalvas, devido à falta de participação por parte dos clientes, ou problemas técnicos, a tendência é que produto entregue não atenda as necessidades reais do negócio. Ainda nesta fase, as documentações necessárias para o usuário, como manual ou itens para treinamento devem estar prontos.

A Produção é a fase onde apenas correções de erros e suporte são feitos. Além disso, esta fase proverá informações úteis sobre o que pode ser melhorado ou alterado no sistema, e que podem ser listados para uma próxima versão do produto. Assim, um novo projeto será iniciado.

A fase “Retirement”, ou Retirada em português, é a fase onde o produto é removido do ambiente de produção, seja devido à uma nova versão do sistema, ou devido o produto não ser mais necessário.

Até o próximo post.

Comunicação – Ponto Chave para o Sucesso de um Projeto

Existem diversos fatores que podem ser considerados como fundamentais para o sucesso de um projeto: bom planejamento, levantamento de requisitos adequado, entre outros. Porém todos convergem em um ponto: a necessidade de nos comunicarmos de forma eficiente e eficaz. Mas, antes de falarmos sobre eficiência e eficácia, no processo de comunicação, vamos entender seu processo, e seus agentes, conforme a figura abaixo.

O processo de comunicação é composto pelos agentes: Transmissor, aquele que envia a mensagem; e o Receptor, aquele que recebe a mensagem e prove um feedback ao Transmissor, para que a comunicação continue. A forma como a mensagem será transmitida – conversa, e-mail, telefone, etc., é o que chamamos de Meio.

Tornar a comunicação eficiente, significa fazer com que o Receptor entenda a mensagem, de maneira clara e adequada. Enquanto que tornar a comunicação eficaz, significa buscar o melhor Meio de entregá-la. Em ambos os casos, o mais importante é analisarmos o perfil da pessoa que receberá a mensagem, pois diferenças entre culturas, religiões, classes sociais, ou nacionalidade, podem fazer com que a mesma mensagem seja recebida de maneiras distintas.

Para exemplificar os conceitos acima, podemos observar um Gerente de Projetos (GP), que precisa se comunicar com os interessados no projeto (Stakeholders).  Cada stakeholder possui uma visão distinta do projeto, de acordo com sua necessidade e experiência. Assim, ao criar um relatório para o diretor financeiro, o GP precisa entender quais expressões usar, como apresentar a informação – gráficos financeiros, neste caso – e qual o melhor meio para enviar a informação – uma matriz em Excel talvez seja a melhor opção. O mesmo relatório, talvez, não seja tão oportuno para o gestor de RH, que precisa de outras informações e em um outro formato, PowerPoint por exemplo.

Por fim, é muito importante que o Receptor envie um feedback ao Transmissor, para comprovar que entendeu a mensagem corretamente. Resumir os itens entendidos é uma boa maneira de enviar tal feedback e, somente com um feedback adequado, o Transmissor poderá ter certeza que o Receptor entendeu a mensagem enviada. Quanto mais curto for o processo entre o envio da mensagem e o recebimento do feedback, menor será o risco de mensagens serem recebidas inadequadamente e, por consequência, menor será o risco de falhas no projeto. A figura abaixo apresenta alguns Meios de comunicação. Na esquerda temos os Meios mais frios, que precisam de mais tempo para prover feedbacks. Quanto mais a direita, mais quente será o Meio, com menor tempo para envio do feedback.

Desta forma é possível observar que uma conversa pessoalmente é mais rica do que um documento em papel, pois os aspectos de uma conversa possuem mais do que palavras. Através de expressões corporais, pausas, indagações e questionamentos, é possível obter um ambiente mais rico de conhecimento e mitigam possíveis falhas de entendimento. A comunicação pode ser aprimorada, se a conversa tiver o apoio de um Quadro Branco, para funcionar como uma lousa, onde o Transmissor pode aprofundar uma explicação e facilitar o entendimento pelo Receptor.

Por fim, vale frisar que os conceitos de comunicação eficiente e eficaz atravessam as fronteiras de projetos e podem ser aplicados no dia-a-dia, em conversas formais e informais, dentro e fora do ambiente corporativo. Quando pensamos em nos comunicar, com parceiros, amigos ou parentes, precisamos pensar no perfil da pessoa que receberá a mensagem e qual o melhor Meio para transmitir tal mensagem.

Planejamento Ágil - Um Planejamento Eficiente

De acordo com as metodologias tradicionais, a fase de planejamento de um projeto é realizada em seu início, em seguida ao levantamento de requisitos. Segundo essas metodologias, a fase de planejamento é realizada em profundidade, no início do projeto. E com o passar do tempo, e início da implementação, essa fase dá lugar ao controle do planejamento criado, conforme a figura abaixo.

Gráfico de esforço, por atividade, durante um projeto

Porém, tal iniciativa gera burocracia, quando uma mudança é necessária no projeto. Primeiro porque tal mudança reflete em alterações em diversos documentos. E também porque faz com que o planejamento seja revisto. No fim das contas o esforço empreendido na fase inicial foi inútil.

O conceito embasado pelas metodologias ágeis aponta para uma maneira mais eficiente de se planejar um projeto. A fase de planejamento é distribuída durante o projeto, e não somente em seu início, da seguinte maneira:

No início do projeto, após o levantamento das necessidades com o(s) cliente(s), a equipe do projeto realiza um planejamento, superficial, do caminho esperado para o projeto e levanta os riscos principais. Essas atividades são realizadas de forma superficial, pois neste momento não se tem muitas informações sobre o projeto.

Neste momento a equipe, juntamente com o cliente, dividem o projeto em grandes entregas, chamadas Releases. Esse pacote de entregáveis engloba um conjunto de funcionalidades que provem benefícios comuns ao cliente. A primeira release conterá os itens mais importantes para o projeto, isto é, o itens que mais retornam valor ao cliente. A segunda release conterá os itens de maior satisfação para o cliente e assim por diante. A duração de cada release varia em torno de 6 meses a 1 ano. A participação do cliente, nesta fase é fundamental para o sucesso do projeto.

Ao início de cada release a equipe e o cliente voltam a se reunir para o planejamento das fases subsequentes. A release é novamente dividida em entregas menores, chamadas iterações, ou Sprints, com duração média de 2 a 4 semanas. O planejamento da release é um pouco mais aprofundados que na fase inicial, a medida que a equipe passa a ter mais informações a respeito do projeto.

Da mesma maneira que o início de cada release, a cada início de iteração, a equipe se reúne com o cliente para um planejamento da fase que vem a seguir. Neste momento o planejamento é mais profundo, visto que o objetivo da fase é mais específico e a equipe tem informações suficientes para se planejar adequadamente.

Ainda ao final de cada uma das fases acima, antes do início da próxima fase (seja ela qual for), a equipe se reúne novamente com o cliente para apresentar o que foi desenvolvido. Esta fase de aceitação, por parte do cliente, vai nortear se a equipe está no caminho certo ou se alguma mudança deve ser realizada já na próxima fase do projeto.

Isto proporciona, à equipe, ter maior assertividade nos itens desenvolvidos, aprender com o cliente durante o projeto, e entregar um produto de maior qualidade. E com um menor custo e risco de mudanças para o projeto.

Até o próximo post.

Radiadores de Informação - Informações de Forma Ágil

Durante um projeto, precisamos compartilhar informações como, o andamento do projeto, acompanhamento de riscos, custo, lições aprendidas entre outras. Estas informações devem estar disponíveis para todas as pessoas, interessadas no projeto, com perfis e interesses diferentes. 

Para isso utilizamos radiadores de informação, que são conjuntos de informações, apresentadas de maneira simples e com a maior exposição possível, para que todos recebam a informação necessária de maneira eficiente – conforme o artigo Comunicação – Ponto chave para o sucesso de um projeto.

Metodologias ágeis como Scrum e XP empregam, fortemente, o uso de relatórios sumarizados, para transmitir informações, aos seus interessados. Estes relatórios são expostos em forma de gráficos em lugares de fácil acesso, geralmente paredes e corredores, para que a informação esteja disponível a todos.

Radiadores de Informação – Kamban e Burn Down chart

Os formatos mais utilizados, segundo Scrum e XP, são o Burn Down Chart (utilizado para apresentação do andamento do projeto e controle de riscos), Earned Value Chart (para apresentação de índices financeiros, retorno de investimento e também para controle de riscos), Kanban (para visão de andamento de atividades), entre outros.

Burn Down Chart

Outra maneira de apresentar informações diversas, é criar um modelo de newsletter. Li outro dia, um artigo em que um gerente de projetos dizia ter criado um jornal interno do projeto, que era distribuído para todos os interessados. Esta forma de radiar informações é bastante interessante, inclusive para equipes distribuídas onde os integrantes não estão alocados no mesmo espaço físico.

O formato utilizado para apresentar a informação pode variar de acordo com cada projeto. O foco não é no modelo utilizado, e sim na informação apresentada. Desta maneira, o melhor modelo é aquele em que as pessoas se sentem mais confortáveis para entender a informação apresentada. E, uma vez que a informação não é mais necessária, ela pode ser descartada.

Utilize formatos embasados por metodologias ou crie seu próprio modelo de relatórios. Mas faça com que seu modelo seja um radiador de informação. Isto é, que a informação se propague por todos os interessados, com a mesma qualidade e linguagem.

Retrospectiva - Aprenda com Erros e Celebre Sucessos

Publicado em Julho 25, 2013 por Thiago Novelli

Todo projeto, independente da metodologia utilizada, tem uma fase de retrospectiva para avaliar o que foi feito de bom e o que poderia ter sido melhor. Algumas metodologias apontam o fim do projeto como fase ideal para – avaliação das lições aprendidas, mas talvez esse período já seja tarde para se pensar no que poderia ter sido melhor.  Ainda mais quando falamos sobre projetos de sistemas, que geralmente, possuem poucas características em comum. Assim, nem tudo que se aprende em um projeto, pode ser utilizado em outro.

De acordo com a metodologia de Scrum, as reuniões de retrospectiva são feitas ao final de cada ciclo de desenvolvimento, chamado iteração, que geralmente possui de 2 a 4 semanas de duração. Nesses encontros, a equipe pode compartilhar experiências, aprender mais sobre o projeto e suas necessidades, e entender o que poderia ter sido melhor. Em outras palavras, as lições aprendidas são maturadas e utilizadas durante o desenvolvimento/implementação do projeto, momento em que mais agregam valor, e, caso algo esteja em desacordo, pode ser rapidamente corrigido, com menor custo e esforço.

Ainda segundo essa mesma metodologia, as reuniões de retrospectiva são divididas em duas etapas distintas. A primeira é realizada junto ao cliente, para se apresentar o que foi desenvolvido durante a iteração. Este é um alinhamento importante, pois garante que os itens desenvolvidos estão de acordo com os solicitados e atendem corretamente às necessidades do negócio, ou ainda, se precisam ser alterados. Em um projeto de desenvolvimento de um sistema corporativo, por exemplo, ao final de cada iteração, o cliente pode acessar e navegar pelas telas desenvolvidas. Isso lhe dará a oportunidade de avaliar se a usabilidade das telas tornará o processo mais eficiente ou pode ser aprimorada. Tal validação é muito mais eficaz quando se pode manejar o sistema na prática, em vez de apenas imaginar como seria sua utilização.

A segunda reunião acontece apenas entre os membros da equipe, para que o processo seja discutido. Neste encontro, cada integrante apresenta seu ponto de vista sobre o projeto, as atividades, a relação entre o grupo e com o líder. Tudo da forma mais transparente possível, para que todos sejam ouvidos e compreendidos. Se algo não está bom, pode ser melhorado e se algo está indo bem, pode ser mantido.

Para cada problema, risco ou incidente levantado, a equipe busca uma solução comum. Se houverem pontos de vista divergentes, o consenso deve prevalecer. O líder deve agir como mediador, para se certificar que o respeito seja mantido e que todos tenham as mesmas condições de se pronunciar. É importante ressaltar que, em todas as reuniões devemos lembrar de celebrar os sucessos e não só apontar os pontos negativos. Muitas vezes, olhamos apenas o lado negativo e pensamos que o positivo é mera responsabilidade, o que não é verdade. Celebrar o sucesso mantém as pessoas motivadas, mostra o caminho a ser seguido e melhora o desempenho individual e do time.

Para equipes distribuídas, em que os membros não se encontram no mesmo ambiente físico, existem ferramentas como Skype, ou outros aplicativos de vídeo conferência, para integrar todos os membros no mesmo ambiente, ainda que virtual.

Ao realizar reuniões periódicas de retrospectiva, podemos avaliar, inclusive, a qualidade do processo de aprendizado da equipe e aprimorá-la. As pessoas passarão a se respeitar mais, entender suas lacunas e se desenvolver, tanto como indivíduos quanto como equipe. Da mesma maneira, o cliente estará mais próximo do projeto e terá mais espaço para buscar oportunidades de melhoria de processos, que talvez entendesse estarem otimizados, junto à equipe.

O Caminho até Conseguir uma Equipes de Alto Desempenho

Toda e qualquer equipe que se forma busca atingir um nível de alto desempenho em suas atividades. Mas, o que é preciso para se atingir tal nível de excelência? Será que são necessários profissionais de alta performance para se ter um time de alta performance? A verdade é que qualquer equipe, independente de seus profissionais, pode atingir um nível de alto desempenho. Porém, o caminho, até lá, é árduo e lento. E o papel do líder é fundamental!

Toda equipe passa por 4 níveis distintos até chegar ao de alto desempenho, de acordo com os Estágios de Desenvolvimento de Uma Equipe, de Bruce Tuckman. São eles: Formação, Confronto, Normatização e Desempenho.

Na primeira fase, a equipe está em formação, os membros pouco se conhecem e evitam confrontos e divergências de opinião para serem melhores aceitos. Os membros buscam trabalhar de forma mais individualista e possuem pouca visão das metas do time. Desta maneira, precisam ser direcionados em suas tarefas e decisões. O líder dita as atividades, de forma diretiva, porém deve explicar o porquê de cada tarefa, para evitar rejeições. Esta é uma fase muito importante, visto que é a base para a criação de uma equipe coesa, em que os membros criam laços de amizade.

Na segunda fase pequenos grupos começam a se formar e as divergências de opinião começam a aparecer. Os membros buscam se afirmar e contam com seus grupos para ajudá-los. Algumas equipes passam rapidamente por esta fase, outras nunca a deixam. A forma como o líder introduz seu modelo de liderança e a forma como este modelo é aceito pelo grupo, além da maturidade da equipe, vão dizer o tempo que time precisará para passar por esta fase. O líder ainda apresenta tarefas de modo diretivo e é responsável pelas decisões, mas precisa apresentar informações e argumentos para quaisquer questionamentos. O líder também precisa, em certos momentos, entender o momento da equipe, e mitigar qualquer problema entre os membros, para a criação de um ambiente saudável e de cooperação mútua.

 Em seguida vem a fase da normatização, onde os membros começam a buscar uma meta comum, acima de suas metas individuais. O sentimento de pertencer a uma equipe começa a florescer e cada um começa a assumir sua responsabilidade, perante ao grupo. O líder começa a ser menos diretivo, tanto nas atividades quanto nas decisões, que começam a ser feitas pelo grupo, e a delegar mais as tarefas. Isto alavanca o sentimento de confiança e a própria equipe começa a criar suas próprias regras.

 A última fase é a do alto desempenho, onde o time trabalha em comunhão e busca novos meios de realizar suas atividades. Nesta fase, divergências de opiniões são positivas e os membros buscam criar um ambiente de conflitos construtivos. O líder passa a ser menos ativo e a monitorar as atividades de longe e a pensar mais no futuro. Os integrantes ficam motivados, entregam mais resultados e passam a querer, cada vez mais, pertencer à equipe.

 Porém, trocas de membros da equipe, novos desafios e até mesmo uma mudança de atitude podem fazer com que a equipe retorne a fases anteriores. Assim, o líder e a própria equipe devem sempre estar alertas para imprevistos.

Planning Poker - Um Modelo de Estimativa de Esforço Ágil

Como apresentado no post uma introducao sobre user story, a estimativa de esforço para uma User Story (US), ou qualquer outra atividade, deve ser criada pela equipe de desenvolvimento. Existem muitas maneiras, embasadas pelas metodologias ágies, de se avaliar o esforço de uma US. A mais difundida e apreciada é o Planning Poker.

Planning Poker consiste em realizar uma reunião, com todos os membros da equipe de desenvolvimento, e o cliente. Cada membro da equipe possui um leque de cartas, que representam a sequência Fibonacci - 0, 1/2, 1, 2, 3, 5, 8, 13, 20 -, mais as cartas "?" - que significa não sei responder -, mais a carta "Café" - que significa a requisição de uma pausa para relaxar.

Baralho de Planning Poker

A sequência Fibonacci representará um valor simbólico de esforço, para equipe, e não a quantidade de horas para sua execução. Assim, uma vez escolhido uma US com esforço 1, por exemplo, as demais terão seus esforços comparados à esta, para terem seus esforços avaliados. A carta 0 representa uma US pronta, onde não é necessário nenhuma ação para sua implementação. 

Na primeira fase da reunião, o líder da equipe apresenta os objetivos da reunião, do projeto e apresenta as US separadas para iteração. O cliente aprova as US separadas, ou pode redefinir as prioridades das US, que ainda estão pendentes no Product Backlog e alterar as US da iteração.

Na segunda fase da reunião o cliente pega, uma US e a apresenta para a equipe de desenvolvimento. Todas as questões são respondidas até o pleno entendimento de todos. Após o entendimento, todos os membros da equipe apresentam suas respostas, ao mesmo tempo, através da escolha de uma de suas cartas. 

Se houver um consenso entre a equipe, o valor apontado é confirmado como o esforço da US. Porém, caso haja uma discrepância muito grande, entre os membros da equipe, há uma radada de conversa, onde alguns argumentos são apresentados, pelos membros e, em seguida, uma nova rodada de votação é realiazada, até que se tenha um consenso interno. O mesmo processo é realizado para todas as US que serão desenvolvidas na iteração.

O Planning Poker acontece em cada início de iteração. De acordo com os esforços apresentados pela equpie, o tamanho definido para a iteração e a quantidade de US que couberem nesta iteração, teremos as US que serão desenvolvidas na iteração atual. Caso alguma US precise ser retirada da iteração, será o cliente que decidirá qual sera excluída.

No início do projeto, a quantidade de US, por iteração, será feita na base da intuição, ou por conhecimento da equipe, em projetos anteriores. Com o passar do tempo, os valores serão mais concretos, visto que a equipe terá uma base estatística para avaliar a precisão dos comparativos entre US e do total de US por iteração.

Por fim, os maiores benefícios de se utilizar o Planning Poker, é fomentar, na equipe, o sentimento de comprometimento, visto que será a equipe quem indicará o esforço da US. Além disso, jogos liberam sensações de prazer, que fazem com que uma atividade chata, de estimativa e planejamento, seja encarada com mais vontade, o que eleva a acuracidade da informação recolhida.

Até o próximo post.

Uma Introdução sobre User Story

Existem muitas maneira de se especificar requisitos de um projeto, seja ele tradicional ou ágil. Alguns preferem utilizar UML, outros apenas descrevem as necessidades em documentos Word. Proveniente da metodologia ágil XP, User Story (US) passou a ser bastante difundido, e utilizado, por outras metodologias, para se especificar requisitos de um projeto.

US é uma visão superficial, e resumida, sobre aquilo que se precisa saber para atender à uma necessidade específica. Em outras palavras, é como se o desenvolvedor escrevesse um resumo de sua conversa com o cliente.

O padrão adotado, para criação de uma US é o User Story Card (USC). USC é um cartão que contém, em sua parte frontal, a necessidade, seu esforço de desenvolvimento e sua prioridade. E, na parte de trás, os detalhes da US, bem como seus requisitos para aceitação

A forma mais utilizada para se descrever a necessidade, apresentada em uma US, é: Como (papel) eu quero (algo) para que (benefício). Exemplo: Como estudante, eu quero poder acessar minhas notas online, para que eu possa ter mais controle sobre minhas notas e faltas.

É importante frisar que uma US deve ser desenvolvida em uma única iteração (falaremos sobre isso mais a frente). Em casos em que o esforço necessário, para entregar uma US, seja maior que o tamanho de uma iteração, esta deve ser dividida em uma fração que não perca sua identidade e que caiba em uma única iteração. Daí o surgimento da sigla SMART, que serve para avaliar a qualidade de uma US. SMART significa: Specific / Significant; Mensurable; Achievable; Realistic / Reasonable; Time-bound / Testable / Trackable. Em português, podemos traduzir como: Específico / Significante; Atnigível; Relalístico / Responsabilizável; Tempo Definido / Testável / Rastreável.

Uma vez escrita, a US será priorizada e seu esforço será avaliado. No início do projeto, como temos poucas informações sobre muitas US, sua prioridade e esforço serão apresentados de forma superficial. Em seguida, elas serão incluídas no Product Backlog - uma lista de todas as US que serão entregues, durante o projeto, e divididas em iterações (este processo será discutido em um post sobre planejamento ágil). E, na iteração em que ela será desenvolvida, ela será novamente discutida, entre o cliente e a equipe de desenvolvimento, para que seu entendimento seja pleno.

Por fim, são de responsabilidade do cliente apontar a prioridade, os detalhes necessários e os requisitos de aceitação, da US. E é responsabilidade da equipe de desenvolvimento, apontar o esforço necessário para entrega da US, com desenvolvimento, teste e transição para produção.

Até o próximo post.

Seu Time Está Preparado para Jogar?

Falar de esporte é sempre prazeroso. Independente da cultura, país de origem ou estilo social, nós buscamos no esporte uma maneira de aliviar a tensão, melhorar a saúde e nos entreter. O que muitas vezes não pensamos é que o esporte pode nos ensinar muito em relação ao nosso dia-a-dia corporativo. Isso porque o dia-a-dia de uma equipe esportiva é parecido com o dia-a-dia de muitas empresas. Ela tem atividades que devem ser planejadas, objetivos a cumprir, riscos, imprevistos e uma necessidade fundamental de gestão de pessoas. Neste paralelo, tiramos grandes lições que podemos transferir para projetos de qualquer natureza.

1. A força da equipe não vem da força unitária de seus integrantes, e sim da forma coesa com que a utilizam em prol do grupo.

Uma das principais jogadas do Rugby chama-se Scrum. Nesta jogada, os integrantes de um time se agrupam para, juntos, formarem uma corrente forte, empurrar seu adversário e ficar com a bola. Neste momento, o valor mais importante é como os integrantes conseguem utilizar suas forças de forma conjunta para fortalecer o grupo ao invés de tentarem utilizar suas forças separadamente em prol de si mesmos.

Se transferirmos essa visão para uma equipe corporativa, entende-se que é necessário utilizar nossos talentos, dedicação e conhecimentos com o intuito de elevar a capacidade do time, ao invés de pensarmos individualmente. E não só dentro de nossa equipe, mas na empresa como um todo, pois um departamento individualizado não conseguirá sustentá-la. Enfim, todos fazemos parte do mesmo time e, como tal, precisamos trabalhar juntos para um benefício comum.

2. Dentro de uma equipe, todos somos iguais, temos a mesma oportunidade de contribuir e devemos ser tratados com igualdade e respeito.

Pode parecer uma coisa simples, mas muitas vezes não damos, como líderes, a mesma atenção para todos os membros de nossa equipe. Quando isso acontece, geramos frustrações que futuramente tornarão a equipe menos criativa.

No futebol moderno, aprendemos que um time é feito de mais do que 11 jogares. Se o técnico não souber manter sua equipe motivada e tratar a todos com igualdade, poderá promover desarmonia e tornar o time menos motivado.

Do mesmo modo, em uma equipe de projetos, devemos promover um ambiente onde todos sintam-se capazes de criar igualmente, independente da senioridade ou do cargo empregado. Muitas vezes, uma pessoa pode ser considerada Júnior para uma determinada tarefa, mas suas experiências de vida não podem ser avaliadas da mesma maneira. Assim, precisamos ficar atentos a não menosprezar considerações com base no peso do crachá e sim no conhecimento da pessoa, frente ao problema encontrado.

3. Motive todos a fazer o melhor para equipe. Mesmo que, para tal, seja necessário se sacrificar.

Muitas vezes fazemos algo que não gostamos, mas que deve ser feito para o bem da equipe. Incentivar e valorizar tais ações é fundamental para promover um ambiente produtivo.

Para o melhor do time, às vezes, o técnico muda o posicionamento de um jogador e o coloca para atuar onde não gosta; ou é obrigado a defender, quando seu desejo é atacar.

Em um time corporativo, em certos momentos, precisamos que os membros da equipe realizem tarefas que não gostam. Nesses momentos, o líder precisa mostrar de forma clara o valor da atividade, valorizar o empenho do profissional e entender certas falhas. Ao contrário, vai desmotivar ainda mais o profissional que já está angustiado com a atividade.

4. Controle a expectativa de seu cliente.

Gerenciar a expectativa de seus respectivos clientes é algo fundamental para o sucesso, tanto de uma equipe corporativa, quanto de uma equipe de futebol. Quanto melhor a expectativa for gerenciada, menor será a possibilidade de frustração.

No caso do futebol, os clientes de um time são seus torcedores e suas expectativas são diversas, de acordo com o momento de cada time. Certas vezes, um técnico sabe que não conseguirá apresentar atuações brilhantes, porém sabe que pode atingir o objetivo imposto pela diretoria e pela torcida, seja um título, uma classificação ou uma fuga do rebaixamento.

No caso de equipes de projeto, gerenciar expectativas vai além de entregar aquilo que foi prometido. É também ser honesto em relação aos prazos de entrega e àquilo que não pode ser realizado.

Em ambos os casos, pautar a expectativa em algo possível de ser atingido é um fator fundamental para o sucesso. Metas audaciosas demais podem gerar frustações, perda de confiança e declínio de apoio por parte dos clientes.

5. Celebre hoje, retome o foco amanhã.

Diversas vezes ouvimos um esportista dizer, logo após a conquista de um troféu ou medalha, que mal poderá celebrar, pois outra competição iniciará em breve, ou mesmo que conquistou a competição, enquanto ainda disputa outra competição. Outras vezes, ouvimos comentários de que certo esportista perdeu uma competição por ter comemorado excessivamente a conquista passada.

Da mesma maneira, na vida corporativa, quando entregamos um projeto ou finalizamos uma atividade, precisamos celebrar o sucesso, pois celebrar o sucesso de uma empreitada é fundamental, seja na vida pessoal ou profissional. Entretanto, devemos nos precaver para que a fase de celebração não se prolongue demais, a ponto de nos fazer perder o foco em novas empreitadas.

6. Tenha adversários na vida, nunca inimigos.

Não existe competição sem adversário, seja no esporte ou em nossas vidas pessoais. Mas isso não quer dizer que nosso adversário seja nosso inimigo. Adversários enaltecem nossa vitória, fazem com que aprendamos com nossa derrota e que busquemos uma constante evolução. Inimigos nos fazem perder, independente de quem tenha vencido a disputa.

O UFC pode ser considerado um esporte violento, mas também pode ser considerado um esporte que preza pelo respeito mútuo e incondicional de seus competidores. Da mesma maneira, no ambiente corporativo, empresas podem identificar concorrentes como adversários em uma venda. Mas, em outra oportunidade, o uma empresa outrora concorrente pode ser parceira em um projeto ou consórcio. Em nossas vidas podemos encontrar muitos adversários: um pretendente à pessoa que gostamos, um concorrente à promoção que almejamos, ou a pessoa que negocia conosco em uma compra ou venda. Em todos os casos, a pessoa que concorre conosco deve ser tratada como nosso adversário e não como inimigo.

Por fim, podemos dizer que o valor em praticar e acompanhar esportes não se restringe à saúde do corpo e da mente, mas também em aprender conceitos que podem nos fazer pessoas e profissionais melhores. Pense nisso na próxima vez que assistir a um jogo de futebol, partida de tênis ou qualquer outro tipo de competição. Pode ser que você extraia desse momento muito mais do que apenas distração!