Planejamentos ágil e tradicional — Um é de marte, outro de vênus

agile vs tradicional planning

Plans tend to be like milk on a hot summer’s day in that regard. They go sour quicker than you expect.
Andy Hunt – signatário do Manifesto Ágil

Vira e mexe ouve-se a famigerada acusação de que no Agile não há planejamento.

Arrrrrg! Não é bem assim, isso é um mito. O que o Agile faz é dar mais ênfase no planejamento que no plano em si, mas vamos ver um pouco mais sobre as diferenças.

Um mundo de incertezas

Os dois tipos de planejamento são de mundos diferentes, mais ou menos como naquele livro “Homens são de marte, mulheres são de vênus”.

O Agile assume que estamos em um ambiente de grande incerteza e, portanto, tentar planejar previamente todo o projeto traria consigo um alto grau de especulação, já a abordagem tradicional acredita em um mundo linear com causas e efeitos muito claros e que assim, seria possível planejar com exatidão o projeto antes mesmo do início de sua execução.

Dessa forma, poderíamos dizer que “O Agile é do complexo e caótico, o tradicional do simples e complicado“.

O método cascata

O método cascata
Primeiro vamos tirar a confusão que existe entre gerência de projetos tradicional e método cascata: Apesar dos dois andarem costumeiramente de mãos dadas, o primeiro está mais relacionado com o PMBOK (Project Management Body of Knowledge)  e o segundo com uma forma recomendada pela engenharia de software tradicional.

Como na mentalidade tradicional existe a presunção de que todas as funcionalidades levantadas são indispensáveis e serão, portanto, implementadas, pouco importaria para o cliente a ordem como seriam implementadas. Dessa forma, opta-se por fazer o que parece, à primeira vista, a maneira mais inteligente e eficiente de se fazer software: por meio de etapas bem definidas, com grandes “entregas” de artefatos intermediários de uma fase para a outra.

Um dos problemas dessa abordagem é o tempo prolongado para se obter qualquer feedback, fazendo com que os problemas sejam descobertos tardiamente. Só para exemplificar, imagine que na fase de Análise um primeiro trabalho pode servir como base para completar todo o resto do trabalho antes de haver uma entrega para a próxima fase. Ao entregar o trabalho para a equipe que trabalhará na fase de Codificação, descobre-se que há um problema em todo o material entregue, devido a um problema que poderia, se houvesse um ciclo maior de feedback, ser descoberto mais cedo.

Como se não bastasse, um outro problema comum com essa abordagem é a propensão a gerar silos e pouca responsabilidade compartilhada da equipe pelo projeto. É comum nesse cenário se ouvir a “querida” frase “Fiz minha parte!”.

O planejamento tradicional

A primeira coisa que salta aos olhos no planejamento tradicional é o foco no plano, ou seja, uma vez estabelecido existe uma grande dificuldade em mudá-lo. A busca não é pelo valor para o cliente, e sim em entregar no prazo e no custo tudo que o cliente imaginou de antemão ser necessário para resolver seu problema.

Dado que vamos seguir um plano idealmente sem alterá-lo, e que todas as funcionalidades requisitadas pelo cliente precisam ser feitas, pouco importaria para o cliente a ordem em que serão desenvolvidas. Dessa forma, acaba-se dando enfoque em atividades. Você se lembra dos processos da fase de planejamento do PMBOK? Vou citar só alguns dos envolvidos com levantamento de escopo e definição do cronograma para exemplificar isso:

Coletar os requisitos;
Definir o escopo;
Criar a EAP (Para quem não sabe, EAP é a WBS, algum louco decidiu chamar de estrutura analítica de projeto);
Definir as atividades;
Sequenciar as atividades;
Estimar os recursos das atividades;
Estimar as durações das atividades;

Deu para perceber que o planejamento tradicional foca em atividades, não em funcionalidades? O problema é que normalmente não se produz valor para o cliente a cada atividade concluída, mas sim a cada funcionalidade entregue.

Ok, não é só isso, acontece que em geral as atividades não terminam antes do planejado, por algumas razões como a Lei de Parkinson (não, não é o mal de Parkinson), a Síndrome do estudante e uma extraordinária falta de incentivo para tal.

Lei de Parkinson: Diz que o trabalho ocupará o tempo disponível para ele.
Síndrome do estudante: Se houver um prazo para concluir algo, o aluno ou estudante (ou no caso o desenvolvedor) deixará para a última hora.
Falta de incentivo: Quando alguém termina cedo, costuma-se culpar essa pessoa por supostamente adicionar muito padding à estimativa ou, então, querer exigir que termine as demais atividades mais cedo também. Ou seja, em geral não há qualquer incentivo para o desenvolvedor dizer que terminou algo antes do prazo.

Outro ponto é que os atrasos são transferidos no encadeamento de atividades. A ideia de que um atraso se compensa, na média, com atividades entregues mais cedo quase nunca é verdade. Um dos motivos disso é que apenas uma combinação de resultados permite que uma atividade possa começar mais cedo, enquanto um único problema pode atrasar o começo de uma atividade. Aliás, há outro motivo para os atrasos não se compensarem na média, é que  as atividades não são eventos independentes.
Jogar uma moeda múltiplas vezes é uma atividade independente. Já no desenvolvimento de software as variações nos tempos de conclusão das atividades tendem a se repetir. Por exemplo, se criar um interface gráfica demorou mais que o estimado, há uma tendência de que outras atividades similares também levem mais tempo que o esperado.

O foco em atividades ainda leva a um outro problema: devido às atividades não serem desenvolvidas por prioridade, normalmente leva-se muito tempo para se ter algo em funcionamento e, mesmo assim, dificilmente serão as funcionalidades de maior valor para o negócio. Caso o dinheiro acabe antes do tempo ou seja preciso adiantar a data de lançamento do produto, não haverá algo muito útil para se entregar, nem tampouco é dada a oportunidade ao negócio para encerrar o projeto antes da hora se a maior parte do valor já foi entregue.

Esse último não está ligado às atividades, mas talvez seja o problema mais irritante em relação ao planejamento tradicional, as estimativas tornam-se compromissos. Estimativas são probabilidades; e compromissos não devem ser tomados sobre probabilidades. É quase como pedir para um meteorologista se comprometer com a previsão de um dia específico num futuro mais distante que um mês.

[youtube http://www.youtube.com/watch?v=RVjpVCwvnFg]

O planejamento ágil

Dada a premissa que estamos em um ambiente de incertezas (mundo da complexidade), todo ato de planejar e estimar é um ato de especulação. Isso não significa que o Agile entenda que estamos completamente no escuro, apenas que nossa visão é limitada e cada vez menos nítida conforme nos lançamos a “ver o futuro”.

Outro ponto de fundamental diferença é o foco, não mais no triângulo de ferro, escopo, prazo e custos, mas na entrega de valor. É óbvio, contudo, que prazo, escopo e custo não são desprezados, apenas deixam de ser o objetivo principal do projeto.

O que é diferente, afinal, no planejamento ágil?

Encoraja mudanças. Como o enfoque está na entrega de valor, é necessário aceitar e encorajar as mudanças caso entreguem mais valor que o planejado.

Um dos primeiros efeitos desse entendimento é que o foco passa a ser no plajenamento e não mais no plano. Isso facilita que o plano possa ser facilmente alterável.

Planejamento por funcionalidade e não por atividade. Como o Agile visa a entrega de valor, não importa a ordem pela qual as atividades são executadas, mas importa a ordem pela qual as funcionalidades são entregues, afinal, as que entregam mais valor deveriam ser priorizadas e entregues antes.

A incerteza é aceita como “parte do processo”.

O planejamento é iterativo. deve ser feito em níveis de Release, Sprint (Iteração timeboxed e incremental) e dia; evoluindo o plano de forma incremental. Em outras palavras, o planejamento é diluído pelo projeto, afinal, conforme o projeto progride, aprendemos mais sobre o projeto (o como) e sobre o produto (o que).

Estimativas não são compromissos, são estimativas.

Medida primária do progresso do projeto é software funcional (Entrega real). Consequentemente há uma contribuição maior para uma evolução apurada do planejamento.

Estabelece confiança. Entregas constantes de software funcional ajudam a estabeler a confiança entre o negócio e o desenvolvimento.

É importante saber em que mundo você está antes de escolher um tipo de planejamento, mas nunca perca de vista o foco na entrega de valor. É muito triste entregar um projeto no prazo, no escopo e no custo se no final das contas o projeto falhar no mais importante que é resolver o problema do seu cliente.

They had “achieve failure” — successfully, faithfully, and rigorously executing a plan that turned out to be utterly flawed.

Eric Ries, no Livro “Lean Startup”

Sobre o autor:

Leonardo Campos

Leonardo Campos trabalha na área de TI desde 2000, Atuou boa parte deste tempo como desenvolvedor Java, mas também desenvolveu profissionalmente com Ruby, .NET, VB, PHP e ASP. Desde do começo de 2009 vem atuando como Scrum Master e agente de mudanças na Editora Abril. É estudioso de processos e entusiasta de Lean e Agile, sendo um dos organizadores do Lean Coffee São Paulo e editor da InfoQ. Leonardo é graduado em Direito pela Universidade Presbiteriana Mackenzie e aprovado pela OAB.  E também é instrutor associado na Adaptworks treinamentos, onde ministra o treinamento de EPC (Estimating, Planning and Contracting).
LinkedIn: @leonardocampos

2 Comentários »

Categorias deste post

Agile, Release, Scrum

O que o mercado espera de um bom treinamento para executivos e gestores?

A necessidade de aumentar a produtividade aliada à preocupação constante de líderes de equipes em reter seus profissionais faz com que o universo corporativo volte suas atenções, cada vez mais, para a especialização e treinamento de suas equipes e gestores.

Diante do aumento de demanda surgem inúmeras teorias e cursos que prometem capacitar líderes para conduzirem seus negócios e times frente à imprevisibilidade do mercado com maior eficiência. Mas como saber diferenciar um bom curso de gestão de um amontoado de dicas pré-formatadas que não se aplicam a todas as empresas?

Segundo Manoel Pimentel, Coach da AdaptWorks, empresa especializada em cursos de gestão e para equipes de TI, o grande segredo para o sucesso de um treinamento é ter um conteúdo interativo, que permita ao aluno compreender a dinâmica do pensamento e aplicá-la à sua realidade, ao invés de apenas absorver teorias prontas. “Nos cursos que ajudo a desenvolver priorizamos a participação e a troca de experiências entre alunos e professores, para que aconteça uma mudança no pensamento. A ideia é ajudá-los a criar mecanismos que possibilitem encontrar suas próprias respostas para cada problema encontrado ao longo do caminho”, explica.

Um treinamento tradicional ou até mesmo um curso de MBA acaba sendo direcionado para o aprendizado de teorias e técnicas, levando a um pensamento quase que mecânico. Ao aplicar o conteúdo aprendido para a solução de um problema real, o profissional percebe que as soluções não podem ser aplicadas de forma repetível, cada desafio está inserido em um contexto diferenciado e, por isso, exige uma abordagem específica.

Para atingir tal objetivo e preparar os alunos para enfrentarem um mercado cada vez mais complexo, a empresa em que Manoel trabalha investe no apelo lúdico e didático dos treinamentos que aplica. “Cada curso pode levar até 2 meses para ser criado”, afirma Pimentel. O processo costuma ter início com uma extensa pesquisa de mercado, nacional e internacional, e observação das práticas profissionais daquele determinado setor.

A partir daí, para embasar o conteúdo teórico do curso, são criadas diversas dinâmicas como o “innovation games”, formatado por Luke Homann com a intenção reproduzir situações complexas do cotidiano com as quais os profissionais costumam se deparar ao longo de suas carreiras. “Criamos o contexto, damos algumas ferramentas e orientações para que os alunos possam encontrar suas próprias soluções, baseadas na verdade de cada organização ou time. No universo corporativo, não existe uma receita pronta para o sucesso ou gestão, cada empresa tem que se especializar para encontrar seu próprio caminho”, esclarece Pimentel.
O sucesso do modelo, que aplica a teoria na prática, tem levado algumas empresas a requisitarem os treinamentos corporativos para seus profissionais, muito em função da necessidade de aprimorar o currículo e reter profissionais do conhecimento, que são estratégicos no atual contexto da economia mundial.

Nenhum comentário »

Categorias deste post

Imprensa, Release

AdaptWorks fecha parceria com a Rally Software líder em Ágil e amplia área de atuação

“Adaptworks irá fornecer treinamento e coaching para acelerar a adoção de métodos ágeis e uso das ferramentas Rally no Brasil”.

São Paulo, 14 de Janeiro de 2013 – A Adaptworks empresa brasileira especializada em treinamento, coaching, implementação de SCRUM e outras metodologias ágeis, fechou uma parceria com a Rally Software e irá oferecer treinamento e coaching especializado para acelerar a adoção de Agile e Rally pelas empresas.

A Rally Software, fornecedora global de soluções baseadas em nuvem para gestão de desenvolvimento de software Ágil, foi reconhecido como líder em Application Lifecycle Management (ALM) por dois institutos de pesquisa independentes: The Forrester Wave: Application Life-Cycle Management, Q4 2012” em 23 de Outubro de 2012 e Gartner “Magic Quadrant for Application Life Cycle Management” em 5 de Junho de 2012. Mais de 144 mil usuários em 115 países usam a plataforma Rally Agile ALM para alinhar o desenvolvimento de software e os objetivos estratégicos de negócios, facilitar a colaboração, aumentar a transparência e automatizar processos manuais.

 “Através da AdaptWorks oferecemos ao mercado brasileiro um extenso portfólio de serviços, que permitirá aos nossos clientes trazer inovações ao mercado mais rapidamente usando princípios Ágeis e a plataforma Rally Agile ALM”, diz Brendan Walsh, vice-presidente de estratégia internacional. “Nossos clientes em comum e as oportunidades no mercado brasileiro são um reflexo da adoção global e contínua das práticas ágeis.”

“Trata-se de uma parceria onde ambas as empresas só têm a ganhar, somamos em expertise, temos um portfólio de serviços complementar e nosso conhecimento do mercado local, clientes e canais de marketing estão alinhados com o foco e missão da Rally de servir sua base de clientes globais e ajudá-los a transformar a forma com que as empresas gerenciam o ciclo de vida de desenvolvimento de software.”, analisa Alexandre Magno, sócio-fundador e diretor da Adaptworks.

Rally Software e AdaptWorks estão planejando uma série de eventos no Brasil, já iniciando no mês de março com uma série de Webinars sobre métodos ágeis e a plataforma Rally Agile ALM. As inscrições estarão abertas em breve no sitehttp://www.rallydev.com/br. Os interessados em conhecer mais sobre métodos ágeis e a solução Rally Agile ALM podem entrar em contato através do site: www.adaptworks.com.br

Nenhum comentário »

Categorias deste post

Agile, Coaching, Imprensa, Notícias, Parcerias, Release, Scrum

Release: o quão curto e frequente for possível.

Em ambientes de projetos ágeis é comum sermos questionados se o resultado de uma Sprint deve automaticamente se tranformar em uma entrega – algo que vai entrar em produção – ou se podemos aguardar um momento mais apropriado para fazê-lo. A resposta padrão é: uma Sprint gera algo potencialmente entregável, algo que está Done, mas se isso vai entrar em produção ou não, vai depender de como você pretende trabalhar com seus Releases. Neste post pretendo explorar um pouco mais esse tema e deixar minha opinião sobre quando e como trabalhar com Releases.

O que é um Release?
Um Release é a representação de uma entrega de produto em produção. Ele é comumente planejado através de um cerimônia chamada Release Planning. Releases são planejados principalmente em ambientes onde estas entregas precisam ter uma data fixa, seja por obrigações contratuais, necessidades de mercado, eventos (conferências, product lauch, etc.) ou – principalmente em ambientes largos – para seguir um roadmap de releases corporativos.

Preciso planejar Releases?
As duas mais comuns situações em que o planejamento de Relase não será necessário:

  • Um (ou vários) Release(s) por dia: dependendo do tipo de produto que você desenvolve e de quão maduro seu time é em boas práticas ágeis de engenharia de software, você pode conseguir este estado de nirvana. Release diários ocorrem através de uma boa estrutura de build e deploy para que estes possam ser feitor frequentemente. Aqui a sua definição de Done teria a instrução “Release it!” (ou algo do gênero). Além disso seu time precisaria de um Product Owner trabalhando MUITO próximo a eles e  um Product Backlog com itens realmente pequenos.
    Um case com esta característica que ficou bem popular nos eventos de Agile foi o do Flickr, que publicou conseguir uma média de 10 deploys diários através da coperação entre Dev e Ops.
  • Um Release a cada Sprint: este cenário é bastante comum, o time trabalha para que o resultado final da Sprint, aquele que será apresentado no Review, já esteja em produção. Empresas que, por exemplo, liberam uma “nova versão” do produto aos seus clientes a cada mês/quinzena provavelmente trabalharão desta forma. Neste caso a Sprint Planning já será suficiente para enxergar o que o cliente receberá em produção e quando, não precisando assim de um Release Planning.

Planejando Release curtos e frequentes
Se o seu cenário não é semelhante aos dois que eu apresentei acima, provavelmente você precisará planejar Release para poder enxergar além de uma Sprint (mesmo que de forma embaçada) e, assim, planejar entregas em produção para seus clientes. Tenha em mente  que, mesmo planejando além de uma Sprint, trabalhar com Releases curtos e frequentes é mais que uma boa prática em Agile, é quase uma obrigação. Releases curtos e frequentes contam com um tempo de resposta menor para colher feedback do cliente, evitando assim o desenvolvimento de funcionalidades desnecessárias ou com um comportamento diferente do esperado pelo cliente. Além disso o retorno sobre o investimento do cliente é acelerado, já que na maioria das vezes o ROI real só será recebido pelo cliente com o produto em produção.

Lembro que quando comecei a trabalhar com Agile alguém me falou que o tamanho ideal de um Release seria 06 meses, lembro que no mesmo momento pensei “Isso é loucura, acho quase impossível isso acontecer!”. Hoje quando escuto falar em Release deste tamanho penso “6 meses? Não, isto é muito tempo!”. Na verdade o tamanho “ideal” de um Release vai depender diretamente do ambiente corporativo que você está inserido. Se a empresa possui uma política de Releases corporativos onde n produtos precisam “entrar” juntos, bem, você pode precisar de Release de 06 meses, ou até mais. O que sugiro nestes cenários é evitar Release BIG-BANG, ao invés disso lance Releases menores para uma base selecionada de usuários (field-beta testers, por exemplo).

Release Planning Meeting – Agenda
Abaixo segue uma sugestão de algumas práticas comuns que procuro utilizar em reuniões para planejamento de um release. Muito provavelmente parte destas práticas não servirão para você, remova-as e adapte a agenda para que esta gere o resultado e visibilidade que seu ambiente precisa para um Release.

  1. Abertura: ScrumMaster revisita o propósito da reunião, sua estrutura, agenda, etc.
  2. Visão do Produto e Roadmap: Product Owner revista a Visão do Produto com o propósito de trazer todos novamente para o foco e alinhar expectativas.
  3. Status atual do projeto: Product Owner apresenta gráficos e Status Reports onde possam ser visualizados resultado das últimas Sprints e momento atual do projeto.
  4. Meta/tema da Release: Product Owner propõe a meta para o Release. Normalmente esta meta é expressa em objetivo de negócio alinhado à data de entrega.
  5. Estimativa de velocidade: Time estima sua velocidade para esta Release baseando-se no resultado de Sprints anteriores. Caso esta seja a primeira Sprint de um primeiro Release, sugiro que execute duas ou três Sprints antes de planejar um Release.
  6. Agenda da Release e número de Sprints: ScrumMaster facilita um trabalho colaborativo entre Time e Product Owner para enxergar Milestones, definir tamanho de Sprints, etc.
  7. Estimativa de itens do Product Backlog: Time estima itens do Product Backlog caso estes não estejam estimados. Só deverão ser estimados uma quantidade de itens suficiente para planejar o Release e, talvez, para deixar uma “sobra”.
  8. Mapear itens nas Sprints do Release: seguindo a priorização do Product Owner o Time irá mapear quais itens “cabem” em quais Sprints. Como o Plano de Release será revisto ao fim de cada Sprint, não aconselho tentar encaixar item a item em cada Sprint. Se você está planejando, por exemplo, um Release de 05 Sprints, mapeie itens para as 02 primeiras Sprints apenas, e deixe o restante selecionado sem posicionar na Sprint 03, 04 ou 05.
  9. Riscos, dependência e preocupações: de forma colaborativa Time, ScrumMaster e Product Owner trabalham com práticas para identificar riscos, dependências, impedimentos arquiteturais, desafios, etc. Caso necessário será elaborado um plano de riscos, impediments backlog e/ou um simples plano de ação.
  10. Comprometimento: ScrumMaster provoca Time e Product Owner para que haja um comprometimento com esta Meta. É importante todos estarem confiantes e entusiasmados com a Meta.
  11. Plano de comunicação e logística da Sprint: principalmente em ambientes largos, a comunicação do Release (e consequentemente do projeto) perante a organização não podem falhar. Se necessário montar plano de ação para este trabalho.
  12. Montar gráfico(s): montar Release Burndows e/ou Parking Lot e/ou qualquer gráfico que ajude a comunicar o andamento do Release.
  13. Retrospectiva: Por fim, como de costume em qualquer cerimônia do Scrum, considero uma boa prática ser feita uma Retrospectiva para avaliar pontos positivos e de melhoria desta reunião.

Muitos me perguntam sobre o tempo que normalmente leva uma Release Planning Meeting. Minha resposta é: não mais que dois dias. Talvez você diga “Dois dias trancados em uma sala fazendo planejamento? Isso é desperdício, um tédio, rg$5sfga!” Bem, tudo depende do quão bom facilitador seu ScrumMaster for. Faço uma analogia destas cerimônias ágeis a um treinamento…dependendo da dinâmica aplicada, do conteúdo e do instrutor, 02 horas podem ser uma tortura – ou 32 horas podem ser extremamente proveitosas e você nem sentir o tempo passar.

Atualizando e revisando o Plano de Release
Por fim é importante ficar claro que o Plano de Release é um artefato vivo e que a cada Review deve ser atualizado, revisado e comunicado pela organização. O Product Owner é o responsável por fazer esta comunicação e, caso tenha sido elaborado uma plano de comunicação, este deverá ser seguido.

No nosso treinamento de Certified Scrum Product Owner são abordados alguns importantes aspectos do Planejamento de Release. Conheça mais sobre este treinamento e veja as datas de nossas próximas turmas.
1 Comentário »

Categorias deste post

Agile, Release, Scrum