PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Agile

  • Agile Project Management

    Autor: Jim Highsmith é um consultor e escritor, especialista em engenharia de software e gerenciamento de projetos. Além do livro apresentado aqui, escreveu também “Adaptive Software Development” (Addison-Wesley, 2000), dentre outros. Foi co-autor do Manifesto Ágil.

    Editora: Addison-Wesley | The Agile Software Development Series. Primeira edição de 2004. Esta entrada é sobre a segunda edição, publicada em 2010.

    Do que se trata: Criação de produtos inovadores através do APM – Agile Project Management, ou Gerenciamento Ágil de Projetos. Apesar da intenção de atender um público mais amplo, é claro que Highsmith concentra-se no desenvolvimento de software.

    O autor sugere um Agile Enterprise Framework composto por 4 camadas:

    • Governança do Portfólio
    • Gerenciamento de Projetos
    • Gerenciamento de Iterações
    • Práticas Técnicas

    O livro só não cobre a última camada, que pode ser composta por práticas sugeridas em frameworks como XP (eXtreme Programming), OpenUP etc.  Highsmith defende que a estrutura proposta “facilita a construção de métodos ágeis híbridos que atenderiam necessidades específicas de uma organização”.

    O destaque para o Gerenciamento de Iterações não é novo, mas Highsmith coloca o tema em um novo patamar. O Planejamento Avançado de Releases é uma das principais atualizações desta segunda edição. As outras são: Valores Ágeis; Escalando Projetos Ágeis; Governança de Projetos; e Medição de Performance.

    A quem se destina: Líderes de projetos.

    Mas também pode ser muito útil para:

    • Gerentes de projetos insatisfeitos com sua situação atual;
    • Gerentes de produtos cobrados por inovação, qualidade, valor, agilidade…
    • Qualquer um que queira conhecer o Mundo Ágil de maneira ampla e sem dogmas ou extremismos. É particularmente indicado para executivos e gerentes.

    Prós:

    • Isenção. Highsmith não defende nada específico como Scrum, XP ou FDD, por exemplo. E justifica sua posição lembrando que um dos princípios  do desenvolvimento ágil é a adaptação para diferentes situações.
    • É esta isenção que possibilita que Highsmith critique alguns caminhos e descaminhos do Mundo Ágil.
    • O livro é muito bem estruturado e ilustrado. O que torna a leitura das 370+ páginas um estudo agradável.

    Contras:

    • As alterações em relação à primeira edição são muito grandes. Desconfio que o “segunda edição”, apresentado em letras garrafais na capa, faça com que muitos que conheceram a primeira edição ignorem este lançamento. Não deveriam.
    • Aliás, que capinha mais feia, hem?

    Destaques Aleatórios:

    • “Qualquer um que pratique o desenvolvimento ad hoc sob o disfarce ‘ágil’ é um impostor.” (pág. 9)
    • “Olhando de fora, um time gerenciado e um time liderado podem parecer a mesma coisa. Dentro eles são muito diferentes.” (pág. 48)
    • “Princípios guiam práticas. Práticas instanciam princípios. Não dá para separá-los”. (pág. 86)
    • “Todo projeto deve ter um time de desenvolvimento e um time de produto. O grupo de desenvolvimento deve ser liderado pelo líder do projeto e o grupo de produto pelo gerente do produto (que no Scrum é chamado Dono do Produto).” (pág. 119)
    • “O reconhecimento de que a iteração 0 (zero) não entrega valor para o cliente pressiona o time a mantê-la breve”. (pág. 147)
    • “… ‘Como você consegue estimar o desconhecido?’ A resposta é: ‘Você não consegue’. Quando há o desconhecido você está chutando, não estimando – e isso é o melhor que podemos fazer. É por isso que tempo e custo são vistos como restrições, e não estimativas, em projetos ágeis.” (pág. 153)
    • “A falta de um bom planejamento de releases é endêmico em partes da comunidade ágil”. (pág. 157)
    • “Existem duas estratégias fundamentais para o gerenciamento de mudanças – antecipação e adaptação – e o bom design leva ambas em consideração.” (pág. 218)
    • “Muita gente, inclusive algumas da comunidade ágil, pensa que o gerenciamento ágil de projetos significa menos gerenciamento. Em minha experiência, o gerenciamento ágil pode ser diferente, mas com certeza não demanda menos tempo.” (pág. 225)
    • “O intercâmbio de pessoas é muito mais eficaz que o intercâmbio de papelada.” (pág. 283)
    • “Os relatórios do Standish Group NÃO são bons indicadores da pobre performance do desenvolvimento de software, eles SÃO bons indicadores das sistêmicas falhas de nossos métodos de planejamento e medição.” (pág. 334)
    • “Quem nunca cancela projetos nunca corre riscos. Quem não corre riscos não sobrevive. não é fracasso, é bom gerenciamento.” (pág. 334)
    • “Previsibilidade ou agilidade: escolha uma.” (pág. 336)

    Trilha de Estudo:

    • Como prometido, uma trilha curta (em número de títulos). Esta entrada completa a anterior, “Agile Product Management with Scrum“, de Roman Pichler. Diz aí, você precisa de 2 dias, 2 semanas ou 2 meses para estudar ‘isso tudo’? Inté!

  • Times

    Existem Times, times, timinhos e igrejinhas, como a Copa recém-encerrada bem mostrou. A formação de equipes, para projetos de qualquer natureza, é uma complexa mistura de ciência, bom senso, tato e intuição.

    Ciência porque é preciso conhecer o projeto, as partes interessadas, as habilidades requeridas – tanto sociais quanto técnicas, e o desenho sócio-técnico mais adequado. O bom senso delineia fronteiras, particularmente em relação aos selecionáveis. O tato é exigido tanto na convocação quanto na exclusão de integrantes da equipe. Por fim, a intuição, subjetiva qualidade que permite perceber que aquele improvável jogador pode render bastante em determinado momento do projeto.

    Este artigo trata exclusivamente o primeiro componente, a ciência. E, claro, não falará sobre seleções de futebol. Apesar de sua possível utilidade em outros tipos de iniciativas, o alvo aqui são os projetos para desenvolvimento de sistemas.

    Até pouco tempo atrás eu me gabava de ter feito apenas uma pequena alteração em um metamodelo sócio-técnico que tinha uns 10 anos de idade. Vendia-o como um modelo para um Dream Team, ignorando alguns padrões emergentes que exigiam outro nível de abstração. A ficha só caiu depois de uns tabefes na cara, particularmente os proferidos por Jim Highsmith em “Agile Project Management – 2nd Edition” (Addison-Wesley, 2010). Roman Pichler, em seu “Agile Product Management with Scrum“ (Addison-Wesley, 2010), deu o bofetão de misericórdia.

    O Líder do Projeto

    O Movimento Ágil colocou o auto-gerenciamento no topo da agenda de todos que estavam formando times seguindo seus princípios. “Indivíduos e interações são mais importantes que processos e ferramentas”, é o que diz o primeiro verso do Manifesto Ágil. Dele derivaram os conceitos de auto-direção, auto-organização, auto-disciplina, respeito pelos indivíduos, igualitarismo e um bom ambiente de trabalho.

    Highsmith diz com todas as letras que “times auto-organizados não se caracterizam pela falta de liderança, mas por um estilo de liderança”. Reforça a mensagem citando Larson e LaFasto (“Teamwork: What Must Go Right, What Can Go Wrong”. Sage Publications, 1989): “bons líderes são o principal ingrediente de projetos e organizações de sucesso”.

    Highsmith ataca frontalmente,  resguardando os nomes dos santos, as propostas de auto-direção. Estas sim se caracterizariam pela ausência de um líder único. Os integrantes se revezariam nesta função dependendo de determinada situação em um projeto. Parece claro que ele dirige suas críticas para algumas práticas sugeridas em frameworks como o Scrum e a XP (Extreme Programming). Critica as práticas ou algumas interpretações delas, preciso dizer.

    Déjà vu? Pois é, já falei um tanto sobre o líder aqui no finito, na seguinte série:

    O Time de Produto

    Residem aqui todos os que ajudam a definir e priorizar o que precisa ser feito. Sim, é aqui que fica o Product Owner (PO – Dono do Produto) em um projeto guiado pelo Scrum. Uma coisa que precisa ser mais reconhecida e divulgada é que o PO, normalmente um usuário ou especialista no domínio, raramente terá disponibilidade para executar e entregar tudo o que está sob sua responsabilidade. Para muitos não fará sentido, por exemplo, a execução de várias tarefas operacionais para desenvolvimento e manutenção da Pauta (ou Product Backlog, como queiram).

    Além do PO ou gerente do produto, o time de produto pode ser formado por: analistas de negócios, especialistas no produto / domínio e parte do pessoal de controle de qualidade (QA). Highsmith reconhece que “a formação deste time, com as pessoas mais adequadas e com tempo suficiente, pode ser um complicado desafio para muitas organizações porque o comprometimento exigido é bem maior do que em projetos tocados de maneira tradicional”.

    É por isso que teimo tanto com a Formação de Analistas de Negócios. Por entender que os bons analistas podem compensar a indisponibilidade de usuários e clientes que mal têm tempo para cuidar de seus afazeres cotidianos. Que fique claro: eles compensam, mas não substituem nunca os usuários e especialistas.

    O curioso é que até hoje vemos equipes sendo formadas sem um único representante disso que chamo (depois do Highsmith) de Time de Produto¹. Gerentes de projetos e analistas-programadores normalmente se revezam na posse dessas atribuições. O (imenso) problema com este enfoque é um só: gerentes e analistas-programadores não percebem o “levantamento de requisitos” (sic) como sua responsabilidade principal: “a gente não foi contratado pra isso”. Eles querem é gerenciar e programar. “Requisitos”, vejam só, é um tipo de impedimento para que eles executem seu trabalho real. Uma amolação.

    O Time de Desenvolvimento

    Gerentes de projetos, analistas-programadores (é melhor Desenvolvedores, não?) e afins moram aqui. Se o Time de Produto define o que precisa ser feito, este é o grupo responsável pelo como será feito e pela construção propriamente dita. Apesar de vivermos em tempos de massificação simplista e beócia – formando e contratando “analistas-programadores” como se tudo fosse a mesma coisa – não custa insistir que este time também é multidisciplinar. Que, dependendo do projeto, vários especialistas podem ser requeridos. Um profissional que saiba desenvolver para o Android ou iPhone, por exemplo.

    Gosto de ver, de forma macro, uma estrutura com um mínimo de 4 células: interfaces, serviços, dados e infraestrutura. Isso não significa hierarquização nem divisão excessiva do trampo, mas sim a aceitação de que existem conhecimentos específicos. Não é “linha de montagem”, mas o reconhecimento do fator humano e da impossibilidade de contratar gente que saiba tudo sobre tudo. Estão distantes os tempos dos monoblocos cobolísticos.

    Juntando Tudo

    Se há um projeto então existe um objetivo ou conjunto de objetivos bem definido. Se o Líder, o Time de Produto e o Time de Desenvolvimento trabalham no sentido de alcançar o mesmo objetivo, então eles formam um único time. Este deveria ser o único critério para definir um time de verdade, não as eventuais divisões internas que só existem para organizar o conhecimento e as responsabilidades de cada um.

    É muito sadia a divisão entre a turma do “que” e do “como”:

    • Falando como um usuário: “Eu realmente participo do projeto, faço parte do time. E quando não posso participar de algum encontro, fico tranquilo porque tenho um representante que defende meu ponto de vista. Isso, mais as entregas regulares que um processo iterativo e incremental garante, torna o projeto um trabalho agradável e estimulante, ao contrário do calvário que caracterizava nossos projetos anteriores.”
    • Falando como um desenvolvedor: “Finalmente inventamos uma maneira de ter o usuário bem perto da gente sem aquela sensação de ‘nós contra eles’, de dormir com o inimigo. Somos um time só e o que nos une são os objetivos do projeto.”

    Divisão sadia, mas naturalmente conflituosa. Sempre foi, independente da arquitetura social ou processo de desenvolvimento utilizado. E sempre será. Os conflitos podem gerar uma tensão criativa, desejável ou até mesmo fundamental dependendo da natureza do projeto. Uma hora é um time que apresenta sua caixa – suas restrições e condições. Outra hora a outra divisão o faz. E todos trabalham, como diz Scott Berkun², “pensando dentro da caixa, debaixo dela, fora dela, quebrando-a e fazendo uma bela fogueira”. É nesta hora que a presença de um líder pode fazer diferença. Quando o “que” e o “como” demoram para atingir um consenso, transformando a caixa numa solução criativa, nada melhor que um olhar isento mas igualmente comprometido com os mesmos objetivos. E com 3 votos nunca teremos empates, certo?

    .:.

    Observações:

    1. Já usei o termo “Time do Dono do Produto”, traduzindo literalmente Roman Pichler no livro já citado. “Time de Produto”, conforme sugerido por Jim Highsmith, é bem melhor. Mas confesso que não sei como ficará de forma definitiva em português. Aliás, nem sei se vingará como conceito!!
    2. Em “A Arte do Gerenciamento de Projetos” (Bookman, 2008).
    3. A ilustração utilizada neste artigo, “Chain of People”, foi legalmente surrupiada de HikingArtist.

  • Agile Product Management with Scrum

    Autor: Roman Pichler é um especialista alemão em Scrum e gerenciamento Ágil de produtos. Este é seu primeiro livro em inglês. Anteriormente publicou “Agiles Projektmanagement erfolgreich einsetzen” (Scrum – Applying Agile Project Management Successfully) pela dpunkt.verlag, em 2008.

    Editora: Addison-Wesley | Mike Cohn Series (2010).

    Tema: Gerenciamento Ágil de produtos através do Scrum (dã!). É mais que isso: é o único livro que conheço dirigido especificamente para Product Owners (Donos de Produtos), o papel mais complexo e controverso em projetos guiados pelo framework Scrum.

    São no mínimo curiosas algumas contradições do Universo Ágil, particularmente aquele que defende e dissemina o uso do Scrum. Por muito tempo deram atenção quase exclusiva para a formação de ScrumMasters. Só agora começamos a ver a devida preocupação, através de cursos e deste livro, com aquele que de fato é o papel mais crítico e complexo em um projeto Scrum, o Product Owner (PO).

    A quem se destina: Todos que desempenham, sonham em desempenhar ou caíram de paraquedas no role (hole?) Product Owner.

    Dê de presente para:

    • Super-usuários e / ou especialistas destacados para o papel de PO;
    • Gerentes de Projetos;
    • Gerentes de Produtos;
    • Analistas de Negócios (principalmente se estiverem atuando em projetos guiados pelo Scrum).

    Contra-indicações: Só não é indicado para quem apresenta reações alérgicas ao termo Agile.

    Prós:

    • Texto objetivo (o livro tem só 133 páginas);
    • Bem ilustrado com exemplos e casos reais;
    • Não fica “em cima do muro” em alguns pontos polêmicos sobre o uso do Scrum. (Mais sobre isso abaixo).

    Contra:

    • O que é uma vantagem (a objetividade) pode ser percebida como superficialidade. Roman poderia ter explorado um pouco mais alguns pontos mais complexos, como a criação da Visão do Produto (capítulo 2, “Envisioning the Product”). Apelo para Fred Brooks¹ para justificar minha crítica: “A fase mais complexa e crítica de um projeto de software é aquela onde definimos o que precisa ser feito.” Na trilha de estudo, abaixo, apresento uma sugestão para preencher um certo ‘vazio’ deixado por Pichler.

    Cutucando Feridas (alguns trechos):

    • “Minha experiência sugere que um Product Owner não consegue cuidar de mais de dois times de maneira sustentável”. (pág. 12)
    • “A criação da Visão é melhor compreendida como um processo de descoberta, um processo de aquisição de conhecimento e aprendizagem que requer experimentação”. (pág. 37)
    • “O Scrum não dita como um requisito deve ser descrito”. (pág. 53)
    • “As atividades de manutenção e evolução²  da primeira iteração (sprint) tratam de itens da segunda iteração, e aquelas da segunda iteração têm como foco os item da terceira iteração, e assim por diante.” (pág. 60)
      Destaquei este trecho porque ele toca em um ponto que gera estranhos debates. Quem cuida do desenvolvimento de requisitos, seja o PO ou um analista de negócios, sempre estará pelo menos uma iteração à frente do restante do time. Pichler sugere que, dependendo dos riscos e incertezas acerca do projeto, o PO trabalhe com até três iterações de distância. O planejamento de cada iteração depende da existência de um conjunto de itens adequadamente entendido e detalhado.
    • “Product Owner e ScrumMaster não devem fazer estimativas nem influenciá-las”. (pág. 67)
    • “A fixação do prazo, orçamento e escopo não é possível; pelo menos uma das três restrições deve ser tratada como uma ‘válvula de escape’”. (pág. 76)
    • “Seu papel durante o planejamento de uma iteração é ajudar o time a entender o que precisa ser feito. O time decide quanto pode ser entregue e como será feito”. (destaques em itálico do autor, pág. 98)

    Trilha de Estudo:

    • Será simplificada desta vez: “Agile Project Management – Second Edition”, de Jim Highsmith (Addison-Wesley, 2010), é um complemento mais que necessário e natural para o livro do Pichler. Por isso será  a próxima entrada desta biblioteca, a ser publicada ainda nesta semana.

    Observações:

    1. No artigo “No Silver Bullet” (1987), republicado como capítulo adicional do clássico “The Mythical Man-Month” (“O Mítico Homem-Mês”, Campus, 2009).
    2. Utilizei os termos “manutenção e evolução” como tradução de “grooming”, termo amplamente utilizado por Pichler. Perdão, mas não consegui encontrar tradução mais adequada. Sugestões?

  • Iterativo & Incremental: O Segundo Fator

    Semana passada sugeri uma forma alternativa de apresentar e justificar a adoção de um ciclo de vida para projetos baseado no modelo Iterativo & Incremental. Deveríamos enfatizar a certeza de que todos cometerão erros em detrimento do destaque dado às inevitáveis mudanças.

    Faltou dizer que muito do que chamamos de mudanças são na realidade erros. Usuários e clientes não são obrigados a aprovar o primeiro produto que recebem, por precisas e assinadas que sejam atas, especificações de casos de uso ou afins. Há mais mistérios entre requisitos e o produto final do que imagina nossa vã filosofia. E essa distância sempre exigirá, em alguma medida, um processo de tentativa e erro. Esse tipo de mudança é sim um erro. Muitos não gostam da palavrinha ou de admitir que erram. Mas deveríamos classificar melhor aquilo que chamamos de erros e mudanças. Papo para outra hora.

    Porque hoje eu gostaria de destacar um segundo fator que justifica a adoção do modelo Iterativo & Incremental: as pequenas vitórias. Assim como é indiscutível que o ser humano erra, também é indissociável de nossa natureza a necessidade de motivação – de uma recarga quase diária de nossas baterias. Em projetos não bastam seus objetivos, por nobres e ambiciosos que sejam, nem eventuais compensações financeiras. Imagine um campeonato de futebol, curto como uma Copa do Mundo ou longo (e cansativo) como o Brasileirão. Os times e jogadores comemoram cada vitória e cada gol. No vôlei, um jogo definido após dezenas de pontos, cada um deles é comemorado. Cada gol ou ponto é uma pequena vitória. Elas são tão cruciais para uma equipe de projetos como são para os jogadores.

    Em projetos tocados segundo moldes convencionais, particularmente no popular “cascata”, há pouco espaço para comemorações intermediárias. Por mais que equipe e coordenadores soltem foguetes para um documento de visão bem escrito ou uma coleção de especificações e modelos “nota 10”, o fato é que não há torcida nem usuários ou clientes compartilhando aquele momento e muito menos incentivando-o. É como uma vitória em treino, fechada e sem valor.

    A vitória que conta, por menor que seja, tem participação direta do público externo – dos usuários e clientes. E eles sabem que documentos e modelos não valem como gols e pontos. Ou seja, não substituem o produto final.

    Um projeto guiado pelo modelo Iterativo & Incremental supõe a comemoração de várias pequenas vitórias. Admite sim alguns revezes, como vimos no artigo anterior. Mas, exatamente por conta deste fator, torna a vitória final mais factível. Cada entrega, iteração ou gol é motivo para celebração. E isso ajuda a renovar o ânimo do time. No contexto de projetos há outros efeitos colaterais bastante benéficos, sendo o principal deles o aprendizado. O time tem a chance de rever seus erros e acertos, o que possibilita uma melhor preparação do próximo ataque, jogo ou iteração.

    Imagine um zero a zero arrastado e chato. Pior ainda, decidido nos pênaltis. Compare com uma sonora goleada, um jogo aberto e bonito de se ver, com placar final de 5 a 3. Qual você prefere?

    .:.

    “Goal“, a foto utilizada neste artigo, é do Jonas B.

  • Iterativo & Incremental: Um Convite aos Erros

    Entre todos os mistérios que rondam nossa área há um difícil de explicar e justificar: qual a razão de tanta resistência na adoção de um ciclo de desenvolvimento que seja iterativo e incremental?

    Nos últimos três anos, só por conta do FAN, pude falar com mais de dois mil profissionais e estive pessoalmente em dezenas de empresas. Sei que não tem valor de pesquisa, mas foi fácil concluir que pelo menos 95% deles ainda trabalham baseados em um modelo “cascata” (ou Waterfall) de desenvolvimento¹. Se considerarmos que já tem quase duas décadas que vários autores, metodologistas, empresas e consultores recomendam a adoção de outro modelo, qual a razão da incontestável predominância da “cascata”?

    Não, este (pequeno) artigo não tem a menor intenção de reativar o debate ou destacar prós e contras de cada proposta. Aliás, se você quiser uma boa justificativa *econômica* para adoção do modelo iterativo & incremental, deveria ler este texto do José Paulo Papo. Minha preocupação aqui é outra.

    Comumente apresentamos o modelo iterativo e incremental, independentemente do sabor (RUP, XP, Scrum, OpenUP…), como um remédio para as inevitáveis mudanças. Esse discurso costuma encontrar dois tipos de reflexos:

    1. (Ainda) existem aqueles que acreditam que mudanças ocorrem exclusivamente porque o entendimento do problema não foi bem realizado. São os mesmos que, infelizmente, acreditam que a Análise de Negócios é a resposta definitiva para especificações (sic) mal feitas. O que vemos neste cenário é mais gente gastando mais tempo e dinheiro para escrever mais. Deveríamos escrever melhor, estruturar melhor as informações aprendidas e colaborar, conversar mais. E não escrever mais e de maneira mais detalhada².
    2. “Os requisitos são estáveis e temos uma ótima compreensão do problema que iremos sanar. Podemos trabalhar em ‘cascata’”. É um reflexo parecido com o anterior mas com uma diferença: há realmente a sensação de que o solo pisado é de fato conhecido. Esta é uma das justificativas que encontro com maior frequência para a não adoção de um modelo iterativo e incremental.

    Percebendo os dois reflexos alterei minha maneira de apresentar e “vender” o modelo iterativo e incremental. Transcrevo abaixo o que costumo falar nos treinamentos e consultorias:

    O que é bonito no modelo iterativo & incremental é que ele reconhece um fato que nunca mudaremos: somos humanos. Ou seja, nós vamos cometer erros. Vários! Ao adotar este modelo estamos dizendo para nossos usuários e clientes: “Nós vamos errar, caríssimos, todos nós. Às vezes será um problema de interpretação de seus requisitos e histórias. Outras tantas vocês errarão, na explicação ou apresentação das próprias necessidades. E, precisamos admitir, muitas vezes as funcionalidades entregues não os atenderão pelos mais diversos motivos. Não importa. Aliás, não importa desde que o modelo de desenvolvimento adotado reconheça essa verdade: somos humanos e vamos errar”.

    Esse discurso gera duas respostas muito positivas: i) desarma aqueles que ficam louquinhos por um debate; ii) facilita a compreensão por todos que nunca trabalharam de outra maneira que não seja a “cascata” ou o “caos absoluto”. São bastante perceptíveis também as carinhas de surpresa que surgem com a repetição de uma palavrinha: Erro.

    Criamos uma cultura que combate e pune erros. Mesmo em ambientes que se dizem “inovadores” o erro ainda é mal visto. As pessoas vivem com medo de errar. Imagine então o desafio de dizer, antes mesmo do início de um projeto, que erros acontecerão. Mas é fato: erramos. Pra caramba!

    Clientes e usuários costumam gostar muito dessa transparência, dessa sinceridade. Estranham porque ela não é muito comum em nosso mercado. Mas aceitam o modelo e o consequente desafio com mais facilidade³. Daqui para a adoção de outras práticas mais modernas é “um tirinho”.

    .:.

    Observações:

    1. Num belo dia um cliente pediu que eu pulasse essa parte do curso: “A gente já desenvolve assim”. Obedeci. Mas depois o treinamento caminhou na base de soluços. Descobri o problema e o susto que curou o soluço: “É que nossas iterações duram algo entre 3 e 4 meses”. Ou seja, eles não desenvolviam de forma iterativa e incremental. Era outra coisa.
      Um outro freguês, agora numa turma aberta, disse que usa Scrum mas que tem que levantar todos os requisitos no início do projeto. Ou seja, não era Scrum. Também era outra coisa qualquer que nem merece nome.
    2. Era uma vez uma empresa que terceirizava todo o trampo de codificação para “fábricas de software” (sic). Eu apresentava para eles os 5 ícones recomendados pelo Cockburn (“Escrevendo Casos de Uso Eficazes”, Bookman. 2006) para indicar o nível de detalhamento de uma especificação de caso de uso. Eles disseram que, para trabalhar com fábricas, os 5 não seriam suficientes. Pediram a criação de outro, abaixo da “ostra”. Sugeriram a colocação da logomarca da Petrobras. E explicaram: “É o nível ‘pré-sal’, sete mil metros abaixo do nível do mar! Só assim o pessoal da fábrica entende.” Repito: não é escrever mais. Não deveria ser…
    3. Era outra vez, lá pelos idos de 2001 ou 2002, eu tocava um projetão. ÃO mesmo, em porte e complexidade. Sabe-se lá porque ($$$) topamos que o cliente “espelhasse” toda nossa estrutura gerencial. Para cada líder de nosso lado, eles colocavam um líder do lado de lá. Um mês de lua-de-mel. Um mês de “briguinhas”. E no terceiro mês a pérola: “Para com esse negócio de iterativo e incremental – queremos que seja cascata”.
      Juro, não é cascata não. Contei a história aqui só para dizer que a palavra “facilidade”, escrita ali no último parágrafo, deve ser interpretada com a devida precaução.
    4. “Funny“, a foto utilizada acima, é da Tanakawho. Sempre ela!

  • Eventos: Os Novos e o Velho

    Direto ao ponto: estão liberadas as inscrições para 3 eventos em São Paulo, dois novos e o velho conhecido FAN.

    O Jogo dos 7 Erros para Líderes de Projetos é um dos novos. É uma oficina (workshop) com duração de um dia e formato um pouco diferente. Brincamos com o velho jogo dos 7 erros – aquele onde devemos descobrir diferenças entre duas imagens. Na oficina cada erro aparecerá em uma situação diferente. E cada situação tratará de um tema desafiador e recorrente na vida dos líderes e gerentes de projetos.

    É um jogo mas está longe de ser brincadeira de criança. Os exercícios, elaborados individualmente, são de médio ou alto graus de dificuldade. E são baseados em situações reais. Cada situação terá duração de uma hora e será encerrada com um bate-papo entre os participantes.

    A outra novidade tem o mesmo formato: O Jogo dos 7 Erros para Analistas de Negócios. Não é requerida participação no FAN. Mas é desejável que os participantes tenham experiência em Análise de Negócios.

    Os dois jogos estão sendo lançados em caráter “Beta”. Ou seja, trata-se de um teste realmente. Daí o precinho especial (R$ 199 para clientes da Tempo Real Eventos e R$ 249 para estreantes). Além disso, cada evento contará com a presença de 5 convidados especiais. Na linha de uma famosa revista de informática, talvez estejamos inventando uma nova profissão: Crítico de Oficinas! Será esta a função dos convidados. Se você se interessou pelo desafio, tente sua estréia aqui, deixando um comentário crítico / criativo sobre os novos eventos. Se for aprovado, a vaga é sua.

    .:.

    E o velho FAN dá as caras novamente, rumo ao seu 3º ano de vida. Será a 18ª turma em São Paulo – com certeza um dos recordes da Tempo Real Eventos. Legal que se trate de um velho (na nossa área 3 anos pode ser muito tempo) que ainda está sabendo envelhecer. Esta turma marcará a estréia da versão 1.1 do programa. Em  números absolutos, trata-se da 4ª versão diferente desta oficina de 14 horas.

    Aliás, vale lembrar que é o mesmo evento que será apresentado pela primeira vez em Brasília, nos dias 9 e 10 de abril.

    Críticas, dúvidas ou sugestões podem ser colocadas aqui mesmo, na forma de comentários. Ou através do email: [email protected]

    Desde já agradeço. Inté!

  • O Mundo Mudou

    Terceira parte da nossa conversa sobre “O Novo Gerente de Projetos”.

    O mundo mudou. E não me lembro qual foi a última vez que utilizei um título tão “fraquinho”. Como o antecipei nas duas partes anteriores, seguirei com ele.

    O mundo muda todo dia. Em negócios e TI a impressão que temos e deixamos é de uma dinâmica quase caótica. Uma volatilidade que, segundo experts, gera uma população repleta de pessoas inseguras, ansiosas e desconfiadas. Não raro, exageramos os possíveis impactos de determinado acontecimento. Outras tantas vezes subestimamos tendências. Como a imensa maioria das pessoas é desprovida de dons proféticos e bolas de cristal, é natural que seja assim. Como é normal que indivíduos apresentem reações muito diferentes quando defrontados com uma mesma mudança. Mas o papo aqui é ou deveria ser sobre projetos e seus gerentes.

    Projeto é mudança. Talvez esta seja a verdade absoluta mais ignorada ou desprezada. Quando uma organização dispara um projeto ela está implementando uma mudança. Aqueles que foram selecionados para o trabalho devem estar preparados para lidar com todos os reflexos gerados por ela. Esses reflexos, com maior ou menor intensidade, fazem com que os projetos sejam naturalmente instáveis. Ainda bem que eles têm data para acabar, não é mesmo?

    Porque é natural do ser humano o gosto ou necessidade de estabilidade. Mesmo aqueles viciados em adrenalina, como os praticantes de esportes radicais, valorizam muito os períodos de calmaria. O fato é que estabilidade perene apenas é possível em processos – em ações que repetimos ad infinitum. Projetos são únicos em seus objetivos e restrições. Eles sempre são inéditos de alguma maneira. Por isso é estranha uma certa obsessão por projetos estáveis. Surrupiando um dito de Michael Hammer¹, “projeto instável” é um oxímoro em vias de se tornar um pleonasmo. Por isso é equivocada a crença em planos. Ou, melhor dizendo, a crença na certeza dos planos. Mas, antes de “atacar” os planos (se é que vou fazê-lo), vamos falar sobre a crença. De onde ela vem? O que a alimenta?

    Durante muito tempo jogamos praticamente todas as nossas fichas em padrões e metodologias que, de uma forma ou de outra, prometem estabilidade e previsibilidade. Apesar das promessas raramente cumpridas, particularmente em projetos de TI, essas propostas se espalharam como notícia ruim. As falhas, quando reconhecidas, raramente eram atribuídas aos padrões e metodologias adotados. Quase sempre a culpa é de quem os implementou. Mercados foram criados em torno dessas propostas. E elas se solidificaram. No mau sentido.

    Temos hoje um imenso “sistema legado” de processos de gerenciamento e desenvolvimento. Usei o termo “sistema legado” exatamente porque ele nos remete aos nossos legados mais famosos – igualmente caros e não muito “simpáticos” a mudanças. O “sistema” que aqui trato é composto por treinamentos, certificações, ferramentas, corpos de conhecimento e, principalmente, cultura. Ou, para voltar ao termo utilizado anteriormente, crença.

    Em determinado momento da história alguns componentes do “sistema” se iludiram com sua pretensa estabilidade. Algumas palavrinhas que guiam os tempos modernos, como inovação e criatividade, são simplesmente ignoradas pelo “sistema”. O próprio sentido de mudança e o entendimento de que não se trata de algo indesejável, mas necessário e inevitável, não encontra respaldo real em algumas das peças mais relevantes do “sistema legado” de processos de gerenciamento e desenvolvimento.

    Seria então o caso de jogar todo o “sistema” no lixo? Claro que não. Sugestões assim são ingênuas (mas pouco inocentes). Ingênuas por não perceberem que o “legado” criado, assim como seus pares, é complexo e caro, mas não deixa de ter seu valor. Acredito que, de todos os seus componentes, o primeiro a ser questionado deveria ser a crença ou cultura. Questão de coerência: como um gerente de projetos – um profissional especializado na implementação de mudanças – pode resistir tanto em mudar?

    Ao questionar a crença, ao adotar um perfil mais cético, o profissional tomará os outros componentes do sistema com outros olhos. Ele tenderá a ser mais cuidadoso e desconfiado. Mas será também mais curioso.

    Não se iluda. Mudar cultura ou questionar a crença não é nada fácil. Também não é algo que possa ser implementado como um projeto. Mas é fácil apontar a trilha. Aliás, é até meio besta: 1) Aceitar que mudanças são inevitáveis; 2) Questionar certezas absolutas; e 3) Não ter medo do novo e muito menos de aprendê-lo.

    O Argumento Derradeiro

    Há poucos dias, Scott Berkun, autor de “A Arte do Gerenciamento de Projetos” (Bookman, 2008), retomou um tema que vou traduzir da seguinte maneira: Gerenciamento de projetos é chato? Berkun responde que “o gerenciamento de projetos é tão chato quanto a coisa que está sendo gerenciada”. Por favor, me desculpe a chatice, mas releia a frase negritada.

    Em um artigo anterior Berkun já havia comentado sua impressão de que o Gerenciamento de Projetos não é muito respeitado. E, em outras palavras, não é uma função ou profissão sexy, atraente. Você não vê nenhuma criança ou adolescente dizendo: “Quando eu crescer quero ser gerente de projetos”. Mas Berkun argumenta que diretores de cinema, técnicos de futebol, produtores de discos e várias outras profissões são variações de gerentes de projetos. A diferença é que eles usam outros termos. Nomes que tornam explícita a coisa que gerenciam. E fazem daquela função algo mais atraente, com certeza.

    Me lembro quando chegou a hora de definir minha profissão. Meu velho, como de costume, deu um conselho rápido e nada rasteiro: “Escolhe qualquer coisa, menos contabilidade”. Ele era contador. Dos bons, diga-se de passagem. Trabalhava 30 horas por semana e fazia de tudo para tornar sua rotina menos chata. Mas ele sabia que estava aprisionado em uma função que é, por natureza, 90% do tempo enfadonha.

    Gerenciamento de projetos pode ser tudo, menos chato. Mas, por incrível que pareça, conseguimos torná-la uma profissão dura e carrancuda. Quadrada mesmo. E me parece claro que os ângulos retos de todos os componentes do nosso “sistema legado” são os maiores responsáveis por isso.

    .:.

    Nome aos Bois e Pingos nos ‘is’

    Ao bom entendedor que por aqui navega ficou claro que dentre os componentes do “sistema legado” tratado acima figuram: PMBoK, CMMI, Prince2, MPS.br, ITIL, afins e derivados. Manada devidamente nomeada, resta agora esclarecer alguns pontos:

    • PMBoK e BABoK não tratam de nenhum tipo específico de projeto. Então, pode parecer equivocada uma crítica que considere apenas projetos de TI. Não na minha opinião. Ainda avalio se vale a pena um artigo sobre “O Problema com os BoK’s”. Vale a pena ou a espada?
    • Não estarei aqui para ver a aposentadoria do “sistema legado”. Ele resistirá e sobreviverá por um bom tempo. A torcida, de certa forma otimista, é para que ele encontre e beba de um tipo de fonte da juventude. O tipo de ‘service pack’ que o BABoK receberá, por exemplo², é uma de várias possibilidades de rejuvenescimento. Os únicos pré-requisitos são humildade e olhos e ouvidos abertos.
    • Por ser longevo, o “sistema legado” não pode ser ignorado por nenhum profissional razoavelmente sério. Há muito conhecimento ali.
      Mas é um pecado iniciar a profissão pelo lado quadrado da força. Quem quer iniciar uma carreira em gerenciamento de projetos deveria, antes de qualquer coisa, estudar alguns documentos que ainda são meio “apócrifos”. Eu iniciaria por “A Arte do Gerenciamento de Projetos” (Scott Berkun. Bookman, 2008) e “Agile Project Management – Second Edition” (Jim Highsmith. Addison-Wesley, 2010). Necessariamente nesta ordem. Eu não tive essa sorte. Mas também não virei contador³.

    .:.

    Observações

    1. Michael Hammer utilizou aquela frase para falar sobre mudanças corporativas. A original é: “Mudança corporativa é um oxímoro em vias de se tornar um pleonasmo“.
    2. Em dezembro fiquei sabendo que o IIBA está preparando uma “Extensão Ágil” para o BABoK. Quem viu a “Leitura Crítica” que fiz já sabia que era uma correção mais que necessária. Apesar da tentativa da versão 2.0 em atender os mundos “Plan-Driven” e “Change-Driven”. Mais do que qualquer coisa, devemos elogiar a humildade e iniciativa do IIBA.
    3. Por favor, prezados contadores, não me levem a mal. Além do meu velho, tenho vários outros parentes que assumiram e gostam desta honrosa profissão. Só não dá para discutir o fato dela ser  90% do tempo chatinha. Sabem o que meu velho fazia quando queria um pouco de diversão? Pegava a contabilidade de uma empresa pra lá de enrolada com fisco e afins. Ou então contratava o filho para desenvolver o sistema de contabilidade daquela empresa encrencada. Pois é, eu não estaria aqui se não fosse a contabilidade.
    4. O desenho utilizado neste artigo, flikr0675, é do flikr.

  • Fracasso 2.0

    Sequência do papo sobre “O Novo Gerente de Projetos“. Segunda parte de um total de três (ou quatro).

    Em todas as turmas do FAN, quando mostrando como todos os requisitos devem derivar dos objetivos do negócio, sempre comentei o seguinte: meu currículo apresenta projetos que tiveram problemas com prazos e orçamentos. Alguns maiores, outros nem tanto. Só me sentiria envergonhado se apresentasse ali algum projeto que tivesse falhado na realização dos objetivos do negócio.

    A comunidade de gerenciamento de projetos tem demonstrado maior preocupação com o Valor gerado para os negócios. Dentre vários artigos e outros trabalhos distingue-se, por exemplo, “Diferenciando os Alinhamentos Estratégicos de Projetos“, de Ana Helena Moreira e Fabio Medeiros, publicado na MundoPM de Abr/Mai de 2009. Eles demonstram como a Proposição de Valor de uma organização, da qual derivam as estratégias, deve direcionar “o foco e o conteúdo dos elementos do gerenciamento de projetos”. Aliás, o título do editorial da mesma edição, assinado por Zózimo, é “Valor“.

    O PMBoK¹ não dá margens para dúvidas quando registra que “projetos são meios para a realização de metas ou objetivos da organização”. Nem quando afirma que o gerente “entrega projetos balanceando requisitos de escopo, prazos, qualidade e custos”. Ele falha, em minha opinião, quando não explicita que tal “balanceamento” deveria ser orientado pelos objetivos do negócio. Na realidade, o grande problema do PMBoK é não fazer refletir em seus processos a devida preocupação com a satisfação das metas e objetivos da organização.

    Alinha-se ao PMBoK o Chaos Report, relatório publicado pelo Standish Group desde 1994. Alinha-se? Sim, ao considerar que um projeto *falha* quando atrasa e/ou estoura orçamento e/ou não entrega todo o escopo *planejado*. Ambos os trabalhos ainda apresentam em seu “espírito” uma preocupação exagerada com o plano. Contra desvios são recomendadas “ações corretivas”, o que deixa entender que o plano está sempre correto; Equivocada seria a execução.

    Apesar da qualidade aparecer entre itens que precisam ser “balanceados”, tanto PMBoK quanto o Chaos Report nos remetem ao velho “Triângulo de Ferro” do gerenciamento de projetos: Escopo, Prazos e Custo. Esses três itens configuram as principais preocupações de um gerente de projetos. E elas estão explicitamente refletidas nas várias práticas e processos sugeridos não só nos dois trabalhos mas em vários outros que tratam o gerenciamento de projetos.

    O primeiro dos 12 princípios do Manifesto Ágil diz que: “Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso”. Valioso no sentido de que o produto entregue realmente representa um meio eficaz para a busca dos objetivos do negócio. Vários métodos, frameworks e práticas derivados do Manifesto Ágil atestam tal preocupação. Mas alguns parecem limitar a percepção de valor à medição do ROI (Retorno sobre o Investimento). É suficiente?

    O Novo Triângulo

    Um Novo Triângulo para o Gerenciamento de Projetos
    Um Novo Triângulo para o Gerenciamento de Projetos

    Jim Highsmith, em “Agile Project Management – Second Edition²“, sugere a adoção de um “novo triângulo”, de algo que de fato represente as principais preocupações de um novo gerente ou líder de projetos. Para ele, as três pontas deste novo triângulo são: Valor, Qualidade e Restrições. Segue uma breve explicação sobre cada uma:

    • Valor: representa diretamente a contribuição para a realização dos objetivos do negócio. Quando tratamos de um sistema para uso próprio, avaliamos e valorizamos a eficácia com a qual ele ajudará a empresa na busca pelos seus objetivos.
      Quando a principal saída de um projeto é um produto ou serviço para uso de terceiros, o Valor indica tanto a satisfação destes quanto a realização das estratégias comerciais.
      Aqui é importante destacar que o Valor também representa a Qualidade Extrínseca ou externa do produto ou serviço. Essa qualidade é imediatamente percebida pelo cliente e não é a mesma citada como segunda ponta do triângulo.
    • Qualidade: esta é a Qualidade Intrínseca ou interna do produto, e refere-se principalmente à sua confiabilidade e capacidade de adaptação. Por exemplo: um produto pode ser muito bem recebido por um cliente no primeiro momento – seu Valor foi percebido pelo cliente. No entanto, quando mudanças são necessárias mas de difícil e cara implementação, consideramos que a qualidade do produto é baixa, sofrível ou inexistente.
    • Restrições: e quem disse que o velho triângulo deveria ir para o lixo? Muito pelo contrário. É aqui, formando a terceira ponta do novo triângulo, que manifestamos nossa preocupação com Escopo, Prazos e Custos. Como reforça Jim, utilizando o mesmo padrão de apresentação dos valores do Manifesto Ágil, a colocação das restrições como apenas uma ponta do novo triângulo não significa dizer que elas não são importantes. Mas é considerável o impacto na crença de que a realização sem desvios do escopo, prazos e custos previstos seriam suficientes para determinar o sucesso de um projeto.
      E esta não é a única mudança. Além do livro de Jim, um outro trabalho a ser publicado em 2010, “Agile Product Management with Scrum³“, sugere um interessante tratamento das restrições. Das três – escopo, prazos e custos – uma é mais relevante para a realização dos objetivos do negócio. Apenas ela deveria ser fixada. As outras duas seriam tratadas com certa flexibilidade. Por exemplo: o prazo, o time-to-market, é considerado crucial para o sucesso de determinado produto. Sendo assim, tanto o escopo quanto os custos poderiam variar. É claro que não se trata de flexibilização total (e insana). Mas o cliente ou patrocinador aceitaria a flutuação dentro de uma faixa pré-estabelecida. Os custos ficariam entre $ 80 e $ 120, por exemplo. Também seria aceitável o possível corte de algumas funcionalidades opcionais (ou secundárias). Tudo para que o prazo, neste exemplo a restrição mais importante para o negócio, fosse atendido plenamente.

    .:.

    Me parece inevitável uma revisão da definição de fracasso pelo Standish Group. Assim como espero um PMBoK mais orientado para a adaptação do que para ações corretivas (que visam a colocação do trabalho nos “trilhos” de um plano). Como insiste Jim Highsmith em mais de um trecho do livro, “planos (e arquiteturas) devem funcionar como guias e não como camisas-de-força”.

    Do outro lado, do Mundo Ágil, espero a compreensão de que o ROI (Retorno sobre o Investimento) não é a única unidade de medida ou preocupação que deve nortear um projeto ou mesmo indicar seu sucesso ou fracasso.

    Mas… devo me segurar. Afinal, prometi uma série de artigos com provocações e questionamentos, não com conclusões. Portanto, deixo algumas questões: Como você mede o sucesso de seus projetos? E o fracasso? Você realmente acredita que um projeto cancelado significa um fracasso? Planos não realizados em sua plenitude são fracassos? Essas percepções são compartilhadas por todas as partes interessadas?

    O papo seguirá. O próximo artigo será “O Mundo Mudou“. Inté!

    .:.

    Referências

    1. Guide to the Project Management Body of Knowledge – PMBoK® Guide, Fourth Edition.
      PMI – Project Management Institute. 2009.
    2. Agile Project Management – Second Edition.
      Jim Highsmith. Addison-Wesley, 2010.
    3. Agile Product Management with Scrum
      Roman Pichler. Addison-Wesley, 2010.

    A figura utilizada no topo do artigo, flikr2298, é do Flikr e liberada como Creative Commons (by).

  • O Novo Gerente de Projetos

    Quase cometi um “O Mundo Ágil precisa de Gerentes de Projetos?“. Não o fiz porque, além de apelativo, o título remeteria ao artigo anterior, quando repeti a mesma pergunta para falar sobre analistas de negócios. Se naquele texto eu apresento uma conclusão, agora meu objetivo é apresentar alguns cenários e provocações. Na realidade, vou apenas compilar e repassar uma série de ‘achados’ que devem nos ajudar a debater e, se for o caso, definir um novo Gerente de Projetos. Soou pretencioso, né? Repare que a intenção é ajudar a definir, ok? São meus R$ 0,02.

    Antes de qualquer coisa: por que precisaríamos de um novo gerente de projetos? Algumas respostas: 1) O Mundo Mudou; 2) Os Fracassos são Constantes; e 3) Os Gerentes Vivem Sobrecarregados e Criticados. Se você não acredita nessas motivações ou acha que elas não são suficientes para justificar esse papo todo, então poupe seu tempo. Caso contrário, espero não chateá-lo com a série de 3 ou 4 partes que se inicia aqui. Sim, precisarei de uma série para desfilar alguns ‘achados’. Vamos lá.

    Gerentes de Projetos Vivem Sobrecarregados e Criticados

    E as causas são conhecidas. Em TI, insistimos em gerentes de projetos (GP’s) que também devem apresentar bons conhecimentos de determinadas tecnologias. Ou seja, muitos esperam que o GP seja também uma espécie de arquiteto. Ou, no mínimo, que ele consiga orientar ou validar o trabalho técnico desenvolvido. Isso sem isentá-lo de todas as tarefas administrativas. Não é a primeira vez que toco neste ponto e não pretendo explorá-lo em maiores detalhes. Me limitarei a citar Fred Brooks (“O Mítico Homem-Mês”, Campus, 2009): “Pensadores são raros. Executores são raros. Pensadores-executores são raríssimos”.

    Outra causa do excesso de trabalho é o microgerenciamento. Não importa se a “culpa” é do profissional ou do processo utilizado. Ou mesmo da falta de um. O fato é que, a partir de determinado porte, é simplesmente impossível microgerenciar um projeto. Claro, considerando uma jornada de trabalho de 8 horas por dia.

    Mas o efeito mais importante do microgerenciamento é outro: a insatisfação da equipe. Projetos de TI são tocados por “trabalhadores do conhecimento” – profissionais que gostam e precisam de espaço e autonomia para desempenhar bem suas funções. Temos aqui um típico exemplo de relação “perde – perde”.

    Aquilo que chamo de “Mundo Ágil”, o conjunto de propostas derivadas do Manifesto Ágil, endereça essas questões de diversas maneiras.  Tem poucos dias, por exemplo, Tobias Mayer escreveu em seu Twitter que: “Projetos ágeis não precisam ser ‘gerenciados’. Eu gostaria que este oxímoro fosse banido de nosso vocabulário”. Sua ‘revolta’ foi motivada por este anúncio, que fala de certificação em gerenciamento de projetos ágeis.  Só para clarear: oxímoro é uma figura de linguagem que coloca dois termos antagônicos, contrários, em uma mesma expressão. Tobias considera então que “gerenciamento” e “projetos ágeis” devem ser como água e óleo. Desconfio que ele quer dizer outra coisa: projetos ágeis não precisam de gerentes.

    A implementação mais comum deste conceito de “não-gerenciamento” é o “autogerenciamento”. A equipe se gerencia, sem nenhum tipo de interferência externa. Não há ingerência, já que todos podem falar sobre o trabalho de todos. Na realidade, em dada situação, algum membro da equipe pode assumir a responsabilidade por uma tomada de decisão. Mas o gerenciamento é uma responsabilidade de todos.

    Ainda no Mundo Ágil, mas em um pólo bem diferente de Tobias e outros, está Jim Highsmith. Na segunda edição de “Agile Project Management” (Addison-Wesley, 2010) ele quebra o termo “autogerenciamento” para clarear alguns pontos. Ele defende que uma equipe seja auto-organizada. Isso estaria no ‘core’ do APM (Agile Project Management) e a sua viabilização seria uma das principais responsabilidades de um Líder (ele não usa os termos gerente ou coordenador de projetos).

    Ainda segundo Jim, existem também os times “autodirigidos”, aqueles que independem de um líder. Em inglês ele usa o termo Leaderless. Para ele, esse tipo de estrutura “vai contra várias pesquisas que mostram que o sucesso em projetos e organizações dependem de bons líderes”. Algumas páginas adiante, mais precisamente na 60, Jim ‘desce o malho’: “Equipes auto-organizadas estão no núcleo do gerenciamento ágil, mas os conceitos estão corrompidos em setores da comunidade ágil. Apesar de ser um bom termo, ele tem sido, infelizmente, confundido com anarquia”. E prossegue: “É fácil combater os gerentes fracos e defender sua eliminação. Muito mais difícil é trabalhar com as organizações para que elas alterem seu estilo de liderança de forma a suportar um ambiente ágil”.

    Melhores líderes e um melhor estilo de liderança  não significam, na visão de Jim, que uma equipe não possa se auto-organizar e autogerenciar. Seria tudo uma questão de equilíbrio: “Auto-organização significa que, na medida do possível, a tomada de decisões é delegada para os times”. E explica: “Mesmo que líderes ágeis devam ser ‘light’ em termos de decisões ‘top-down’, eles devem ser ‘heavy’ na articulação de objetivos, facilitação de interações, melhoria da dinâmica da equipe, suporte a colaboração e incentivo da experimentação e inovação”.

    Não me parece uma coincidência o fato da lista acima guardar várias semelhanças com aquela apresentada no artigo anterior, que tratava das responsabilidades de um Dono do Produto em um projeto guiado pelo Scrum. Vale lembrar: o Scrum é uma metodologia que, em certo sentido, se propõe Leaderless. As responsabilidades sobre o gerenciamento são compartilhadas pelo ScrumMaster, Dono do Produto e Time.

    Acontece que, em vários trabalhos mais recentes (como “Product Management with Scrum”, de Roman Pichler – Addison-Wesley, 2010), a função do Dono do Produto está sendo apresentada de tal maneira que chega a ser estranho o fato dele não ser tratado como um Líder. De uma forma ou de outra, os autores são claros em um ponto: trata-se da função mais crítica e difícil em uma iniciativa guiada pelo Scrum.

    Por fim, gostaria de destacar algumas possibilidades apresentadas por Phillip “Shoes” Calçado no papo que tivemos sobre o último artigo: “Cada projeto tem necessidades específicas. Como analogia, em alguns projetos precisamos de alguém 100% do tempo atuando como gerente de projetos e ainda de um gerente de iteração. Em outros projetos apenas o gerente de iteração pode fazer PM e IM. E em outros um desenvolvedor ou BA sênior pode facilmente fazer o seu papel e ainda cuidar de gerência de projetos.”

    Queria apenas acrescentar que essa divisão entre gerenciamento de projetos e gerenciamento de iterações é totalmente compatível com o framework proposto por Jim Highsmith no livro citado acima. Aliás, “Agile Project Management – Second Edition” é uma compilação de práticas estruturada em torno de 3 das 4 “camadas” que formam o que Jim chama de “Agile Enterprise Framework”. As quatro “camadas” são: Governança do Portfolio, Gerenciamento de Projetos, Gerenciamento de Iterações e Práticas Técnicas. Apenas essa última camada, formada por práticas de engenharia, não está no escopo do livro.

    Como eu disse lá em cima, (ainda) não apresentarei conclusões. Na próxima parte da série falarei sobre “Fracassos”. Inté.

    .:.

    Observações

    A imagem utilizada, flikr0629, é de flikr e foi surrupiada no Flickr. Simples assim.

  • O Mundo Ágil precisa de Analistas de Negócios?

    Na realidade, a dúvida mais frequente em nossos papos e debates é: Como o Analista de Negócios (AN) se ‘encaixa’ em um projeto guiado por um método ágil? Acontece que possíveis respostas para essa questão obrigatoriamente nos levam para a pergunta do título: Projetos ágeis precisam de AN’s? Temo que não são poucos os que responderiam com um rápido e sonoro: Não!

    E não é muito difícil entender suas razões. Primeiro, como Roman Pichler lembra em “Agile Product Management with Scrum”¹, nenhum livro “clássico” derivado do Manifesto Ágil cobre aquelas etapas iniciais de um projeto que podem se beneficiar da atuação de um AN. Ken Schwaber, em “Agile Project Management with Scrum” (2004), Kent Beck, “Extreme Programming Explained” (1999) e “Crystal Clear” (2005) de Alistair Cockburn – todos partem de uma visão ou pauta* (Product Backlog) previamente definidos. Pouco ou nada falam sobre aquele momento em que equipe e organização definem ou, melhor dizendo, começam a definir o que precisa ser feito.

    Pichler não cita, mas “Agile Project Management – Second Edition” (2010) de Jim Highsmith e até “Utilizando UML e Padrões” (2008) de Craig Larman apresentam a mesma restrição. Este último não o faz de maneira explícita, como é comum em obras baseadas no Processo Unificado (PU). Mas isso é assunto para outro artigo. O que nos interessa aqui é a confirmação de que não só o AN, mas a própria Análise de Negócios é em parte ignorada por pessoas e obras que ajudaram a fundar, definir e consolidar o Movimento Ágil.

    Por favor, não entenda que a análise de negócios é apenas uma fase no início de um projeto. Utilizada corretamente em um modelo de ciclo de vida iterativo e incremental, ela existirá durante todo o projeto. E até depois dele. O que tento destacar aqui é que, nas fases iniciais de um projeto, a análise de negócios é caríssima. E o é porque é ela que ajuda a definir uma clara visão dos objetivos do negócio ou do produto. E, como diz Jim Highsmith², “na ausência desta clara visão, a natureza exploratória de um projeto ágil resultará numa espiral infinita de experimentações”. No popular: “para quem não sabe para onde vai, qualquer caminho serve”.

    Não é minha intenção tentar explicar essa grave omissão. Já ouvi muitas pessoas dizendo que a Análise de Negócios seria, por si só, um projeto específico. Não concordo. Todo projeto de software depende, mesmo que em graus diferentes, de um conjunto de métodos e práticas que: 1) ajudam a definir o que precisa ser feito; e 2) ajudam a garantir que o que está sendo feito realmente atende aos objetivos fixados (e respeita as restrições colocadas). A esse conjunto foi dado o nome “Análise de Negócios”. E eu não entendo como um projeto para a construção ou implantação de um sistema de informação poderia prescindir dele.

    Um segundo motivo pelo qual os AN’s parecem “ignorados” pelo Mundo Ágil é a forma como este, em seus vários sabores e formas, conclama e exige uma participação mais efetiva dos usuários e demais partes interessadas que não fazem parte do “time de construção”.

    Na proposta conhecida como eXtreme Programming (XP ou XisPê), por exemplo, uma prática requer o usuário literalmente sentado ao lado dos desenvolvedores. Costumo brincar que, quando um bom AN se deparar com um usuário que tenha total disponibilidade para ficar alimentando um projeto com seus requisitos, deveria recomendar sua sumária demissão. É brincadeira. Mas procura iluminar um ponto crítico: quem, nos dias de hoje, pode abandonar seus afazeres cotidianos durante todo um projeto? É claro que se trata de uma prática de difícil aplicação. Assim como deve ser óbvio que, quando possível e em determinados tipos de (pequenos) projetos, ela deve ser adotada. Não questiono sua eficácia. Apenas desconfio de sua viabilidade.

    O Scrum é outra proposta derivada do Mundo Ágil, que se caracteriza ultimamente pelos altíssimos índices de popularidade. Ele concentra suas sugestões nos aspectos gerenciais de um projeto. E define a existência de 3 “entidades” principais na comunidade de um projeto: o ScrumMaster, o Time e o Dono do Produto (Product Onwer). Este seria o representante de todos os usuários e teria, segundo Ken Schwaber (um de seus “criadores”), duas grandes responsabilidades: 1) Maximizar o ROI (Retorno sobre o Investimento); e 2) Gerenciar a Pauta (Product Backlog). Roman Pichler, no mesmo título citado anteriormente, sugere uma revisão das duas principais preocupações que devem guiar o Dono do Produto. Elas seriam: 1) Definir a Visão; e 2) Entregá-la!

    Repare como a sugestão de Pichler se encaixa perfeitamente na definição da análise de negócios que apresentei acima: 1) Ajudar a definir o que precisa ser feito; 2) Ajudar a garantir que a entrega realmente satisfaz os objetivos colocados. A mudança está apenas no tom, no tamanho da responsabilidade: o Dono do Produto realmente define a visão e é o principal responsável por entregá-la**. A análise de negócios ajuda.

    Então podemos dizer que o Dono do Produto (DP) elimina a necessidade de um Analista de Negócios (AN)? Em minha opinião, quase nunca! Citarei Pichler novamente, listando aquelas que seriam as responsabilidades de um DP:

    • Pesquisa de mercado;
    • Planejamento do Produto;
    • Análise de Negócios (!);
    • Gerenciamento da Pauta (Product Backlog);
    • Descoberta, Descrição e Priorização de Requisitos;
    • Gerenciamento de Versões (Releases);
    • Acompanhamento da evolução do projeto;
    • Gerenciamento do orçamento;
    • Relacionamento com clientes, usuários e outras partes interessadas; e
    • Participação nas Reuniões Scrum.

    Gerentes de projetos devem ficar um tanto “encafifados” com a listinha acima. Mas outro dia eu falo com eles. A questão aqui é: até que ponto é possível que apenas uma pessoa realize (bem!) todas as atividades listadas acima? Repare ainda como questões operacionais, táticas e estratégicas são misturadas, causando a falsa impressão de que seriam equivalentes. E lembre-se que existem pessoas que ainda cogitam a utilização de um DP que não tem 100% de disponibilidade de tempo para o projeto!

    Não é por acaso que vários trabalhos recentes – dentre eles o já citado Pichler e também “Scrum Product Ownership”³, de Bob Galen (2009) – afirmam que o trampo do DP é “o mais pesado em um projeto Scrum” (Galen). Portanto, não deve causar espanto nem revolta o fato de alguns autores começarem a sugerir uma Equipe do Dono do Produto. Pichler chega a citar um exemplo mostrando uma equipe formada por “dois analistas de negócios, um arquiteto chefe e um assistente de projeto”, além do próprio DP, é claro.

    É importantíssimo salientar que o DP continua sendo uma única pessoa. O que muda com a sugestão acima é a aceitação de que o DP não dá conta sozinho de tudo o que ele precisa fazer. Mesmo em projetos considerados pequenos. Sendo assim, ele sempre poderá montar um time próprio. Sinceramente, eu não entendi o que um “arquiteto chefe” fez naquele exemplo do Pichler. Mas, tendo em vista a lista de responsabilidades acima, é muito fácil supor a ajuda que AN’s podem dar para os DP’s. Sendo mais direto: todo o trabalho operacional listado (descoberta e descrição de requisitos; análise de negócios de uma maneira geral; pesquisas e parte do relacionamento com outras partes interessadas) pode ser atribuído exclusivamente para AN’s. Além, claro, do apoio na execução de atividades de caráter tático (como o gerenciamento da pauta).

    Eu entendo e até tento compartilhar o temor que muitos demonstram quando veem uma sugestão como essa. Mais pessoas, mais intermediários, podem comprometer a qualidade da comunicação. Nunca vou dizer que esta não é uma preocupação relevante. Acontece que os problemas causados por um DP sobrecarregado podem ser consideravelmente piores. Imagine, por exemplo, o início de uma iteração sem uma pauta fechada; ou então com uma pauta repleta de requisitos (ou histórias) incompletos, ambíguos ou mal estruturados e porcamente priorizados.

    Se ambos os cenários, comunicação e sobrecarga, são ruins e indesejáveis, mas devemos escolher um, qual seria melhor administrado? Qual representa menores riscos?

    Conclusões (?)

    Reparou nas datas de publicação das obras citadas? Pensou na base histórica que temos desde o dia 13 de fevereiro de 2001, data de ‘nascimento’ do Manifesto Ágil? Desconfiou que a consolidação de nossos métodos de experimentação (desenvolvimento) é também uma experiência? Por isso tasquei um ‘?’ ali no subtítulo. Porque conclusões, nesta altura do campeonato, ainda são muito perigosas. E relativamente frágeis. Daí a quantidade de debates e embates que vemos por todo canto. De um lado, ainda vemos muita resistência em mudar (o que configura uma boa piada). De outro, muitas vezes, a falta de humildade para admitir que ainda estamos todos aprendendo.

    Por isso, caros AN’s (e GP’s), não é preciso ter medo do ‘monstrinho’ Ágil. Todo projeto seguirá apresentando necessidades e consequentes atividades, independentemente do processo, metodologia ou ‘modinha’ utilizada. Todo projeto seguirá tendo uma etapa onde definimos o que precisa ser feito. Assim como todo projeto seguirá precisando de líderes.

    O que não pode significar, de forma alguma, que você AN (ou GP) possa baixar a guarda e ignorar tendências fortes, verdadeiras, viáveis e inevitáveis como o Movimento Ágil. E o SEMAT (?). E o Flu? E 2012?? E o Flamengo e a Terezinha???

    Desconfianças (!)

    Foi um bom mineiro, Guimarães Rosa, quem disse: “Sei de nada não… Mas desconfio de muita coisa”. Quem dera eu tivesse as desconfianças do Rosa. As minhas, no assunto em questão, são:

    • Não vejo mais com bons olhos a alocação de um AN para desempenhar o papel de Dono do Produto. Cheguei a sugerir isso algumas vezes. Peço desculpas e retiro minha sugestão. O DP deve ser de fato uma pessoa do negócio (ou, em algumas situações, o Gerente do Projeto).
    • Em projetos guiados pelo Scrum, o AN deve fazer parte do Time do Dono do Produto. Em muitos projetos, bastará 1 (um) AN. Seu par, na maioria das atividades, será o próprio DP ou um integrante do Time.
    • Corpos de conhecimentos vão incorporar cada vez mais práticas ágeis. Não adiantará muita coisa se seus espíritos (Princípios) não forem seriamente questionados.
    • AN’s (e GP’s) que já se deparam com projetos ágeis ou desconfiam (ou desejam!) que eles estejam em seu horizonte próximo, deveriam priorizar o estudo de obras como aquelas listadas abaixo, em detrimento até mesmo do BABoK (por razões já explicadas aqui).
    • Opa, quase me esqueci. A resposta é: Sim, o Mundo Ágil precisa de Analista de Negócios.

    Bibliografia

    1. Agile Product Management with Scrum
      Roman Pichler. Addison-Wesley (2010).
      Obs.: Tomei por base uma versão preliminar do livro, um Rough Cut. Seu lançamento está previsto para 5/mar/10.
    2. Agile Project Management – Second Edition
      Jim Highsmith. Addison-Wesley (2010).
      Obs.: Já disponível.
    3. Scrum Product Ownership
      Bob Galen. Draft v1.3 (2009).
      Obs.: A versão final, independente, já está disponível via Lulu.

    Observações:

    A foto utilizada neste artigo, “Danger: Keep Clear“, é do PSD, surrupiada legalmente no Flickr porque liberada como Creative Commons (by).

    * A sugestão do termo “Pauta” como alternativa para “Product Backlog” deve ser creditada para o colega Leandro Mendonça. Muito obrigado, meu caro. Tenho testado o termo com um surpreendente índice de aceitação.

    ** Antes que me batam: O DP é o principal responsável pela entrega no sentido de que ele deve ser accountable (aah! palavrinha maldita). No popular: é o dele que estará na reta em caso de problemas com a entrega do projeto. Ok? Então guardem as facas, please!