PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Scrum

  • Sistema de Blindagem Inteligente, Parte II

    Sistema de Blindagem Inteligente, Parte II

    Caso tenha perdido, aqui está a primeira parte. A encerrei relacionando quatro impedimentos para a adoção do Scrum na empresa YYZ (nome alterado). Importante lembrar: mais que ao Scrum, são impedimentos para a realização de sete objetivos da área de TI daquela empresa. O Scrum é só (!) um possível meio de atendê-los. Dos quatro ‘bloqueios’, um é mais crítico: os times consomem aproximadamente 80% de seu tempo cuidando de problemas do dia a dia. Como proteger os times? Há uma forma de blindagem minimamente inteligente? Abaixo, o desenrolar do enrolado causo.

    ?

    O impedimento crítico foi apresentado para uma equipe de coordenadores – quase todos os responsáveis pelos onze times que formam aquela unidade de TI. Seguiu-se um debate sobre alternativas de solução – opções de blindagem.

    A primeira, aparentemente bastante simpática aos coordenadores, considerava a alocação de poucos membros (20%) de cada vertical para o atendimento das demandas emergentes / urgentes. Além disso, todos os times dedicariam cerca de 20% de seu tempo para essas questões. Era, com certeza, a alternativa que menor impacto causaria na estrutura atual.

    O diagrama¹ acima destaca duas restrições principais para a sugestão. A primeira é “matemática”: mesmo que destacássemos 20% dos membros do time mais 20% do tempo de toda a equipe para cuidar dos requisitos urgentes, não seria possível atender todas as demandas (lembre-se: elas consomem atualmente 80% do tempo útil de todo o time). A consequência natural seria o acúmulo de demandas não atendidas, seguido do aumento da insatisfação dos usuários e assim por diante. Além disso, há o aspecto cultural que não pode ser negligenciado. Ele foi destacado na primeira parte: a empresa YYZ tem uma (honorável) política de portas abertas. Todo mundo pode falar com todo mundo praticamente a qualquer hora do dia (e da noite!). Fazer com que os usuários falassem apenas com determinados membros e/ou em período pré-determinado vai contra uma cultura estabelecida de longa data.

    A mesma questão cultural aparece como impedimento para a alternativa #2. Nela, conforme sugerido pelo responsável pela área de TI, todas as demandas seriam encaminhadas para a área de help desk. Muitos dirão que já deveria ser assim. De certa forma, é. A área de suporte da YYZ recebe uma média de seis mil (6k!) chamados por mês, 1500 deles relacionados ao ERP. E consegue fechar (bem) algo em torno de 85% deles. O resto? Sobra para as verticais de negócios. E junta-se aos requisitos que os usuários preferem apresentar de maneira direta (em uma mistura de demandas ditas “evolutivas” com simples alterações de telas, pequenos bugs etc). Como adiantei, há a questão cultural: os usuários não podem ser impedidos de se relacionar com as verticais que os espelham em TI. Mas há uma segunda e mais grave restrição para a segunda alternativa. Falta gente. Mais: falta gente qualificada. Cheguei a sugerir o deslocamento de analistas de negócios e desenvolvedores para lá. Propus engolindo. E engoli seco. Ninguém aceitaria um movimento que tinha cara e jeito de “rebaixamento”, por nobre que seja o serviço de suporte. O treinamento de novos integrantes foi cogitado. Mas, como o diagrama tenta indicar, é coisa que toma tempo. Muito tempo.

    Sobrou a terceira alternativa. Aquela que, como consultor, defendi. Partindo do princípio de que a blindagem total dos times é impossível, não resta outra opção que não seja a criação de um novo time. Um time que seja desconhecido pelo negócio e respectivos representantes. Ou seja, além de blindado ele também é invisível². Desta forma as verticais de negócios cuidariam exclusivamente do cotidiano – atendimento aos usuários e solução de pequenos problemas. Seriam também a porta de entrada para as chamadas “demandas evolutivas”. Para tanto, seguiriam contando com pessoal capaz de executar atividades de análise de negócios. Talvez um pouco mais que isso. O coordenador de cada área poderia vir a ser um Dono do Produto (Product Owner ou simplesmente PO, como queira). Eu sei, eu não curto muito esse papo de dublê de PO. Mas, neste caso, dado o invejável conhecimento do negócio que cada coordenador apresenta, os riscos inerentes ao desenho eram consideravelmente reduzidos. E haveria outro benefício: o novo time seguiria de fato invisível. Mas, quem integraria o novo time?

    Você se lembra que os coordenadores estavam dispostos a “sacrificar” 20% de seu time para cuidar exclusivamente das demandas não previstas? Bom, se pegarmos 20% de cada uma das sete verticais de negócios (que têm, em média, 8 integrantes) mais o time de controle de qualidade (pelo menos 60% dele – seis profissionais) temos uma nova composição com cerca de 17 pessoas. Praticamente 3,5 times de Scrum (considerando o tamanho ideal sugerido: 5 (+/- 2)). Claro, este time seria multidisciplinar, auto-organizado, dono de seus processos e, o mais importante, orientado por um e apenas um Product Backlog. Quase sem querer (querendo!) já atendemos o objetivo #1 da lista que foi apresentada na primeira parte: “Ter uma fila única de demandas”. Dois coelhos, talvez alguns mais, numa única porretada. Parecia tudo muito bom para ser verdade. Quais restrições para esta alternativa foram apresentadas?

    “Esse time não teria real domínio do negócio”, disseram alguns. Oras, para isso existem os PO’s e seus asseclas (analistas de negócios e afins), certo? Além disso, o novo time é formado por gente que já tem, em média, três anos de casa. E são provenientes de todas as verticais de negócios, o que representa um certo conhecimento e visão do todo. Sinceramente, isso não é restrição que se apresente. Porque ela não para em pé. Então, uma segunda restrição – aparentemente mais forte – foi colocada: “O <nome_do_responsável_por_ti> não quer que demandas evolutivas sejam separadas das corretivas”; “Além disso, o <nome_do_responsável_por_ti> não permite em hipótese nenhuma que duas equipes trabalhem nos mesmos artefatos“. Quantos traumas, quantas noites mal dormidas e quantos sistemas bisonhos de controle de versões são necessários para criar restrições tão… sei lá. Prefiro não adjetivar. Assim como preferi não gastar meu tempo com um estudo antropológico daquelas raízes pré-históricas. Me limitei a lembrar Peter Senge: “Os problemas de hoje vêm das soluções de ontem.”

    Percebi que não se tratava apenas de restrições do <nome_do_responsável_por_ti>. Os próprios coordenadores não gostaram nadinha da ideia de um novo time. Um time que provavelmente viveria sem a figura de um coordenador e que ficaria com o filé, enquanto eles seguiriam com o feijão com arroz do cotidiano. A antipatia deles pela sugestão é perfeitamente compreensível. Mas não é justificável.

    Faltou a eles enxergar um pouquinho além e entender que este desenho, como todos os outros, é temporário. Não entenderam que o novo time seria um “super” prestador de serviços para eles. E faltou acreditar que, com o tempo, o novo time poderia ser gradativamente incorporado às suas unidades. E que isso seria possível tão logo o tempo de resposta fosse reduzido para prazos que excedessem minimamente as expectativas dos usuários; o que os levaria para a fixação de acordos de níveis de serviços (objetivo #4 da lista original). Antes que você me chame de ingênuo e/ou simplório: resumi veredito e consequências.
    {Mas, caso queira explorar um pouco mais esta parte, por favor, comente! Acho que o assunto é bom demais para morrer aqui, só com minhas palavras.}

    Algumas Referências para a Alternativa #3

    Pois é, o artigo está ficando mais longo que o usual. Mas não quero fazê-la(o) esperar por uma terceira parte. Conto com mais um pouco de sua atenção.

    Já tem um bom tempo, creio que quatro ou cinco anos, que li um artigo sobre uma grande mudança que estava acontecendo na Promon. Eles estavam “duplicando” várias gerências. Uma cuidaria do dia a dia. A outra, nova, trabalharia apenas no “amanhã”. Me apaixonei pela ideia mas, infelizmente, não vi mais nada a respeito. Sei lá se foi mantida, muito menos o que conseguiram. Temo que, por considerar apenas os gerentes, a coisa não tenha vingado.

    Mais recentemente começaram a pipocar artigos e teses sobre “organizações ambidestras“. Apesar de algumas interpretações meio tortas e rebuscadas, a proposta central parece ser a mesma: separar o presente do futuro. E fazer com que as organizações trabalhem nas duas frentes com a mesma atenção e dedicação. Não necessariamente com o mesmo volume de recursos. Mas, desejavelmente, com princípios e processos em comum.

    Sinceramente, não vejo alternativa que não passe por uma divisão assim. O problema com esse tipo de mudança é que ela é drástica. O que significa dizer que a resistência a ela será igualmente forte. Pensando Scrum ou, mais precisamente, pensando Lean, não estamos mais falando de Kaizen (melhoria contínua) e sim de Kaikaku (mudança radical). E o que é necessário para a implementação de uma mudança radical? Coragem; sangue frio; apoio dos altos escalões; comprometimento com a solução… A lista é longa e não é estranha para você que conhece mudanças. Por isso vou tocar em um ponto relativamente incomum: quem promove uma mudança radical não alimenta a ilusão de que não haverão “mortos” e feridos. Muitos pularão do barco. E isso não é necessariamente ruim.
    {Está aqui outro ponto que podemos discutir bastante, não?}

    Epílogo

    Se você respeita o jeito Lean de pensar, então sabe que não pode tratar problemas (impedimentos ou bloqueios) com remendos rápidos e muito menos fazer vista grossa para eles. Você deve, literalmente, “parar a linha”, analisar as raízes do problema, encontrar e implantar uma solução para ele. Foi o que aconteceu com este serviço de consultoria. Interrompemos o processo, eu parei meu “relógio”, apresentei e propus discussões sobre os impedimentos. Um mês. Dois meses. Três meses…

    Fiquei sabendo que o <nome_do_responsável_por_ti> foi transferido para outro negócio da YYZ. Não sei dizer se as restrições que ele defendia permaneceram. Creio que não. Mesmo assim, não acredito que minha sugestão tenha uma nova chance. É assim mesmo: quantas vezes já fomos aconselhados a ter uma vida mais saudável, menos sedentária, mais preocupada com o amanhã? E quantas vezes seguimos os conselhos? São poucos os consultores, pais, esposas, médicos e afins que são de fato escutados. Menor ainda é o número dos que recebem prêmios milionários por seu poder de persuasão e objetivos alcançados.

    ?

    Observações:
    1. Não julgue o “diagrama” rabiscado, please! É só um resumo da apresentação das três alternativas e respectivas restrições. E, sim, é um Causal Loop Diagram (Diagrama de Círculos Causais). Caso você não conheça, a “o” (bolinha) ao lado de uma linha significa força (ou feedback) contrário (ou negativo). O “c” significa uma restrição (ou constraint). É uma ferramentinha que, pelo visto, está ganhando novo impulso. Na última segunda vi Jurgen Appelo utilizá-la para mostrar como esse negócio de desenvolver software é “doomed”. Mas pode ser salvo! Craig Larman também usou e abusou dela em seu último livro, “Scaling Lean & Agile Development” (Addison-Wesley, 2009).
    2. O aspecto “invisível” (do novo time) é desejável neste caso específico. Não o indicaria em ambientes que não tenham uma política tão aberta e generosa de “relacionamentos muitos-para-muitos 24×7”. Insisto, na YYZ o time só estaria 100% blindado se fosse “invisível”.
    3. “Trainee hatchings” é o título do cartoon de hoje. Como sempre, foi surrupiado do HikingArtist.
    4. Aquele xampu segue me provocando com o seu “Sistema de Blindagem Inteligente”.
  • Sistema de Blindagem Inteligente, Parte I

    Sistema de Blindagem Inteligente, Parte I

    Não é piada: o “sistema” que dá nome a este post aparece em uma embalagem de xampu. E me incomoda, a cada banho, há algumas semanas. Até xampu consegue fazer uma blindagem inteligente! Então por que seria tão difícil para algumas organizações isolar e proteger, ou seja, blindar um time de projetos? A questão passou a me atazanar com mais frequência depois que publiquei uma breve compilação sobre problemas mais comuns na adoção do Scrum. Aquele artigo passou batido pelo problema. Tentarei corrigi-lo agora. E vou fazê-lo através de um causo real minimamente maquiado por razões óbvias¹.

    ?

    A empresa YYZ, um imenso conglomerado com presença global, desenvolveu seu próprio ERP. Lá se vão anos desde que aquele imenso monolito viu a luz. Ele fora concebido para cuidar do núcleo do negócio e, claro, das finanças. Com o passar do tempo, ganhou inúmeras novas responsabilidades, da produção até a logística de armazenamento e entrega passando por tudo o que é possível existir entre estes polos. Ou, melhor dizendo, quase tudo. Não se aventurou a cuidar do RH, por exemplo. Apenas um detalhe. O fato é que o ERP, cimentado firmemente em um desenho Cliente/Servidor (de duas camadas e milhares de Stored Procedures), é grande. Quase imensurável.

    São onze os times que cuidam da manutenção e evolução do sistema. Sete deles cuidam de verticais específicas, como Vendas, Administração e Produção, por exemplo. Os outros quatro “prestam serviços” para eles. Bem, para dizer a verdade, eles não são vistos assim na maior parte do tempo. Um deles é o Controle de Qualidade. E não é tão comum assim ver este “departamento” sendo percebido ou se apresentando como um “Prestador de Serviços”. A verdade é que ninguém lá dentro precisava de um consultor para informar que a qualidade e seu respectivo controle deveriam ser incorporados aos times. Acho que apenas a própria área de qualidade. Consultor? Retomemos o causo.

    “Paulo, você nos ajuda a implantar o Scrum?” Claro, por que não? Mas, diga aí, por quê? Ops… perguntinha maldita, não? Alguns meses se passaram até que a contratação fosse fechada e, mais importante, até que a perguntinha maledeta fosse respondida:

    1. Ter uma fila única de demandas
    2. Saber o esforço que cada demanda consumiu
    3. Reduzir o tempo de entrega
    4. Fechar acordos de níveis de serviços (SLA) com áreas usuárias
    5. Tornar as demandas visíveis para as áreas usuárias
    6. Ter tempo para o planejamento estratégico
    7. Medir o desempenho dos integrantes das equipes

    Rabisquei o diagrama acima para determinar uma sequência de trabalho. Conclui que a realização do item 3, a redução do tempo de entrega, favoreceria a satisfação de todos os outros requisitos. E que o fechamento de SLA’s (item 4) só seria possível depois que todos os outros objetivos fossem minimamente atingidos. Portanto, o próximo passo era descobrir a razão das entregas serem tão demoradas (60 dias, em média, entre o registro da demanda e sua entrega definitiva para os usuários).

    Não nos custou um dia o diagnóstico dos quatro principais fatores que retardavam as entregas:

    • As especificações, elaboradas por analistas de negócios, são muito extensas (e de pouca ou nenhuma utilidade após as entregas);
    • A área de qualidade só sabe que algo é prioritário quando ouve gritos. No mais, administra uma fila que mistura tudo das sete verticais de negócios. E tem pouca gente para tanto trabalho, apesar de não cobrir 20% dos tipos de testes possíveis;
    • Dada a complexidade da distribuição – várias unidades espalhadas geograficamente – é compilada e entregue apenas uma “versão” por mês; e
    • Os desenvolvedores são atropelados diariamente por problemas, de bugs até o mal entendimento de determinadas funcionalidades pelos usuários, passando pelo que é mais grave: novas demandas urgentes.

    Me sinto à vontade para descrever o causo principalmente porque sei que os quatro problemas acima podem apontar para um sem número de empresas ao redor do globo. Não há nada de particular aqui, o que pode tornar este artigo realmente útil. Voltando para a história.

    Seria relativamente fácil solucionar os três primeiros problemas. Existe um padrão único para especificação de demandas. Requisitos imensos e minúsculos recebem o mesmo tratamento (burocrático), o que não faz sentido. Mais: toda a análise de impacto e definição do “como” (protótipos de telas, lista de alterações nos bancos de dados etc) é realizado pelos analistas de negócios, o que torna a vida dos desenvolvedores um sossego (e uma chatice só). Qualidade, o segundo problema, deveria ser incorporada (de fato e de direito) pelas verticais de negócios. Que deveriam ganhar também autonomia em relação a atualização de versões. Apesar do jeitão monolítico do ERP, vimos que era perfeitamente possível gerar mais de uma versão por mês. Daí a estimar (salivando) que seria possível uma redução de 60 para 15 dias do tempo médio de entregas foi um pulinho. Ingênuo pulinho.

    O quarto problema – o atropelo das verticais de negócios por questões do dia a dia – se apresentou monstruoso logo no primeiro dia da experiência com o Scrum. A empresa YYZ tem uma bela política de “portas abertas” para todos. Aliás, mal existem portas (e paredes). O que gera um efeito dramático na área de TI: usuários aparecem a qualquer momento com seus choramingos e requisitos. E não atendê-los está fora de questão.

    “Oras, Paulo, parece que fazes tormenta numa pequena caneca d’água! Não bastaria separar alguém do time ou parte do tempo de todo o time para o atendimento das demandas imprevisíveis?” Como, respondo perguntando, em um cenário onde elas consomem cerca de 80% do tempo útil de toda a equipe?

    O papo segue na parte II. Inté!

    ?

    Observações:

    1. Não revelo a identidade de meus clientes de consultoria exatamente para ter a liberdade de tratá-los como causos, aqui no {finito} e em meus cursos e palestras.
    2. Não, o xampu com “Sistema de Blindagem Inteligente” não é meu, ok?
    3. “getting away from it all” é outro cartoon que surrupio do HikingArtist.com

     

  • Management 3.0

    Management 3.0

    Autor: Jurgen Appelo, holandês que se apresenta como escritor, palestrante, instrutor, desenvolvedor, empreendedor, gerente, blogueiro, leitor, sonhador, líder e pensador livre. Figura relativamente nova na Comunidade Ágil. Este é seu primeiro livro.

    Editora: Addison-Wesley (2011).

    Promessa do Subtítulo: Liderando Desenvolvedores Ágeis, Desenvolvendo Líderes Ágeis

    Do que se trata: GERENCIAMENTO. O autor dirige o livro para gerentes “de linha” (de áreas de Desenvolvimento ou Departamentos de TI) reforçando que não se trata de (mais) um livro sobre Gerenciamento de Projetos. Também “filtra” um pouco mais a seleção colocando que o livro é sobre Gerenciamento Ágil. Mas parece que todo mundo que já teve o prazer de conhecer esta obra descobriu que se trata de um trabalho sobre Gerenciamento no século XXI, o século da Complexidade. GERENCIAMENTO em seu sentido mais amplo.

    Três ponto zero?: O gerenciamento 1.0 foi aquele chamado de científico, caracterizado por hierarquias e originado no início do século passado. O gerenciamento 2.0 brota em meados dos anos 1980 e é caracterizado pelas manias e modismos, por patches e add-ons (TQM, BPR, TOC, BsC, Six Sigma etc) que tentavam “corrigir” a versão anterior.

    Então veio a teoria da complexidade e sua aplicação na matemática, biologia, economia e sociologia. Aí chega o Jurgen, mergulha na teoria e em sua aplicação nos mais diversos domínios, e a destila em um modelo que ele chamou de Management 3.0.

    Indicado para: Gerentes, líderes, desenvolvedores, empreendedores, sonhadores, pensadores livres e todos que queiram entender a razão de tudo neste mundo parecer um tanto complicado e/ou complexo e porque todo sucesso não passa de um adiamento do fracasso.

    Contra-indicações: Puristas, extremistas, conservadores, preconceituosos, adoradores de ângulos retos e eleitores do Jair Bosonaro podem sentir um certo desconforto em diversos trechos do livro.

    Breve Resenha: Quem lê livros técnicos sobre um mesmo tema com uma certa frequência vive com a sensação de déjà-vu. Nos últimos tempos engoli, total ou parcialmente, mais de uma dúzia de livros sobre o Desenvolvimento Ágil de Sistemas. Poucos realmente colocaram assunto novo na mesa. Dois deles mereceram entrada nesta biblioteca. O resto girou em torno dos mesmos temas, problemas e sugestões. Às vezes mudando nomes, outras tantas reciclando histórias.

    Jurgen Appelo acaba de colocar o assunto “Agile” em outro patamar.

    Não se trata de um reset, pelo contrário. Jurgen conhece e respeita toda a história que no próximo dia 13 de fevereiro completará dez anos (data da publicação do Manifesto Ágil). Mas ele se apresenta como um pensador livre. E é. Por isso busca coisas com milhares ou milhões de anos de idade ou situações bobas do cotidiano para ilustrar suas colocações e tornar mais palatáveis as ideias e teorias que sustentam seu modelo. Estratégia mais que necessária, porque Jurgen parte de um Corpo de Conhecimentos de Sistemas formado por coisinhas espinhosas como: Teoria Geral dos Sistemas, Cibernética, Teoria dos Sistemas Dinâmicos, Teoria dos Jogos, Teoria do Caos e Teoria da Evolução. Não se assuste ainda. Esta é apenas parte da história que ele conta para justificar o uso do Pensamento da Complexidade (ou Teoria da Complexidade ou ‘simplesmente’ Complexidade, hehe) como base para o seu modelo.

    Perdão, não há motivos para sustos. Jurgen apresenta essas teorias e conceitos para “humanos normais” como você e eu. Primeiro em um único capítulo, o terceiro, pavimentando o caminho que seguiremos. Depois em capítulos que concentram toda a parte teórica de cada Visão proposta no modelo Management 3.0. Cada uma das seis visões da Martie (o monstrinho que Jurgen desenhou para representar o modelo) é apresentada em dois capítulos, um teórico e outro prático. Essa sacada, além de facilitar a compreensão de suas sugestões, permite o planejamento de nossos estudos. Este é um livro para ser estudado, não simplesmente lido. Optei por estudar um visão por dia: o capítulo teórico na parte da manhã, o prático bem depois do almoço.

    Hora de apresentar, afinal, os seis “olhos” da simpática Martie:

    • Energizar Pessoas: “Penso que as pessoas são as partes mais importantes de uma organização e que os gerentes devem fazer de tudo para mantê-las ativas, criativas e motivadas.”
    • Fortalecer¹ Times: “Acredito que os times podem se auto-organizar, e isto requer delegação de poderes, autorização e confiança por parte dos gerentes.”
    • Alinhar Restrições: “Expliquei que a auto-organização pode resultar em qualquer coisa, portanto é necessário proteger as pessoas e os recursos compartilhados e dar para as pessoas propósitos claros e objetivos definidos.”
    • Desenvolver Competência: “Também acredito que os times não podem atingir esses objetivos se seus integrantes não forem capazes, e que os gerentes devem contribuir para o desenvolvimento da competência de cada um deles.”
    • Desenvolver² Estrutura: “Muitos times trabalham no contexto de uma organização complexa, por isso estou convencido de que é importante considerar as estruturas para melhorar a comunicação.”
    • Melhorar Tudo: “Também penso que as pessoas, times e organizações devem continuamente melhorar tudo de forma a adiar o fracasso o máximo possível.”
    • “Finalmente, acho que a apresentação acima está bem fácil de entender, o que significa que ela provavelmente está errada.”

    O resumo acima é apresentado lá no finalzinho do livro, quando o autor confessa: “Sim, meu modelo está ‘errado’”. “Todos Estão Errados, mas alguns são úteis” é o título do capítulo 16. O humor e a honestidade de Jurgen, além, claro, do tanto que ele conhece e estudou, fazem deste livro um marco. Suecos (e seus 1.217 mosquitos), belgas, cubanos e eleitores do Bosonaro terão alguns motivos para reclamar do livro. Acho que nenhum relacionado ao que ele ensina sobre GERENCIAMENTO.

    Alguns Trechos Selecionados, Surrupiados e Livremente Traduzidos:

    “Acho que o Movimento Ágil negligenciou a importância dos gerentes (de linha). Se os gerentes não sabem o que fazer nem o que esperar de uma organização Ágil, como esperar que eles se envolvam na transição para o desenvolvimento Ágil de software? Qual é a mensagem do Movimento Ágil aqui? Se for apenas ‘não precisamos de gerentes’, então não causa espanto saber que transições para o Ágil estão sendo obstruídas ao redor do globo.”

    “Lembre-se que valores Ágeis não são listas fixas com cinco, sete ou doze itens. Este livro é sobre complexidade, não sobre respostas simples.”

    “Nenhum sistema³ que se auto-organiza existe fora de um contexto. E é o contexto que restringe e direciona a organização de um sistema.”

    “Gerentes inteligentes sabem que devem tomar o menor número de decisões possível.”

    “Acredito que um ‘ponto fraco’ do Manifesto Ágil é o fato dele não reconhecer (explicitamente) que todos os projetos de software precisam de pessoas inteligentes, disciplinadas e atentas. O paradigma ‘pessoas mais que processos’ é jóia, até você descobrir que seu time se limita a dois duendes, um papagaio, uma cabeleireira e um gerente de projetos aparentemente brilhante mas que é cego, surdo e mudo. Não há coaching no mundo que faça este time se auto-organizar e entregar um produto bem sucedido.”

    “Disciplina * Habilidade = Competência”

    “A melhor maneira de implementar processos Ágeis é fazê-lo do seu jeito.”

    “Modelos de maturidade são pouco úteis, talvez até um pouco ofensivos.”

    “Se eles podem escovar seus dentes todos os dias para se livrar de cáries, por que não podem escovar o código diariamente para se livrar dos bugs?”

    “Gerentes de projetos estão ali para servir os times, não para controlá-los. Gerentes de projetos estão ali para gerenciar projetos, não pessoas.”

    “Se você introduzir um novo produto de software em um ambiente, o ambiente vai mudar, consequentemente os requisitos para o produto também mudarão.”

    “O valor percebido de uma mudança é proporcional à dor que se sente por não mudar.”

    “Compañero, no hay camino. Se hace camino al andar.”

    Observações:

    1. O termo original é “empower”. Optei por “fortalecer” (times) como tradução porque empowerment normalmente é entendido apenas como “delegação de poderes”. O autor tem objetivos mais amplos e ambiciosos para a palavra.
    2. Outro termo comum que ainda me atrapalha é “grow”. Simples: é crescer… ou aumentar, germinar, florescer, produzir. Optei por “desenvolver” por achá-lo mais coerente com a intenção do autor: “grow structure”.
    3. A palavra “sistema” é utilizada no livro em seu sentido mais amplo. Empresas, times, pessoas e bactérias são sistemas.
    4. Esta entrada ficou longa, muito longa! O livro, em cada uma de suas 413 páginas, fez por merecer. De tempos em tempos me deparo com um título que realmente me “melhora”. Muito. Não vejo a hora de estudá-lo de novo.
  • 2 0 1 1

    2 0 1 1

    Apesar de tentar obedecer o padrão, minha noção de “Ano Novo” não ocorre entre dezembro e janeiro. Começo a visualizar o próximo ano ‘letivo’ em julho ou agosto. Até dois meses depois eu preciso ter um bom desenho sobre como eu quero estar quando o próximo ano acabar. Tão ou mais importante que as metas financeiras (que, no final das contas, nunca se realizam mesmo) são os objetivos de estudo e das conversas que ele pode gerar. Há uma década adquiri o hábito de desenvolver um tema por ano. Faço uma imersão e depois tento repassar o que aprendi em artigos e eventos. Como já fiz no ano passado, neste artigo vou escancarar (um pouquinho) meus planos para 2011.

    Planos que devem ser especiais porque em 2011 completo 25 anos de relacionamento com esta área chamada genericamente de Tecnologia da Informação. Pois é, Bodas de Prata! No namoro fui programador. Noivado na marra se deu quando me converteram em gerente de projetos. Há cinco anos, quando voltei para minha terra natal e me converti em consultor independente (sem patrão nem sogra), resolvi que era casório mesmo.

    Ano especial significa um pouco mais de ambição. Boa ambição. Ao analisar a evolução histórica das visitas ao finito foi fácil perceber uma inevitável estabilização. Não posso forçar a barra ou questionar convicções e estilo para tentar conquistar quem não gosta de meu trabalho. Não. Em relação ao finito a minha principal preocupação será não perder quem eu consegui atrair. Para isso eu sei que devo continuar entregando o que eles esperam, em torno dos temas já consolidados (Análise de Negócios, Gerenciamento de Projetos e Engenharia de Software, principalmente).

    Mas quem me conhece sabe que esse papo de estabilização e mesmice não tem nada a ver comigo. No início do ano passado tentei explorar algumas ideias diferentes, em artigos e eventos. Falo principalmente dos fracassados “Jogo dos 7 Erros” e do épico do “Seu Moreira”. Quebrei a cara. Como sou teimoso como um bom burro mineiro, tentarei lançar o jogo novamente. Motivado principalmente por participantes do FAN que falaram: “eu quero”. Mas meu cardápio, como eu antecipei em meados de 2010,  tem novas opções:

    • FDP – Formação de Donos de Produtos: único produto que já testei em 2010 (com resultado pra lá de positivo). Ele seguirá em testes beta por mais duas ou três edições. O que eu não havia contado até agora é que este evento foi um chute de longa distância para testar outro lançamento, o
    • FAN4Scrum: sim, a formação de analistas de negócios para trabalho específico com o framework Scrum. Ele se sobrepõe de certa maneira ao FDP, mas tem um perfil bem diferente. Enfatizo técnicas de desenvolvimento de requisitos e histórias. O ‘4’ no nome tem outro significado: celebra o 4º ano do programa FAN. A primeira versão (aberta) será uma oficina com 7 horas de duração.
    • FLiP – Formação de Líderes de Projetos: há tempos ensaio meu retorno ao tema Gerenciamento de Projetos. É meu tiro mais arriscado porque se trata de uma área em fase de estranha ebulição. O alto risco justificará uma estratégia de testes diferente daquela que utilizei no lançamento do FDP. Conto mais em breve.
    • Análise de Negócios – Linguagem Chave para Executivos: oficina que desenvolvo a quatro mãos com o Sérgio Storch, da ContentDigital. Em quase todas edições do FAN ouvi o seguinte: “Queria muito que meu gerente estivesse aqui”. Este evento foi desenhado para eles e outros executivos, de TI ou não. Melhor dizendo: está em fase de desenho. Mas sairá ainda no primeiro semestre.

    Outros temas ‘xodó’ passaram todo o ano de 2010 clamando por um pouco de atenção: Gestão do Conhecimento; o “i” de TI; Software como Negócio; Software como Ativo; e, jogando no ventilador, TI, Vida Digital, Carreira e Negócios de uma maneira geral. Confesso que não sei o que pode sair daqui. Talvez eu lance alguns artigos e palestras sobre alguns desses temas. Minha única certeza é que ressuscitei o GRAFFiTi para que ele possa servir como um repositório de assuntos aleatórios. Conto neste artigo um pouco das minhas intenções. Aquelas que já conheço, hehe. Ah, migrei para lá a sequência da conversa que comecei ao comentar o livro “Capital Intelectual“. Aquele papo sobre fábricas de software e coisa e tal. Está em “Cadeia, Rede ou Oficina de Valor?”

    Muita coisa para uma cabecinha só? Depende: 2011 é o ano do Coelho, e Coelho é símbolo de agilidade e fertilidade. Saber aproveitar e utilizar melhor o tempo é uma qualidade cada vez mais necessária (particularmente depois de determinada idade). E, como já dizia o poeta, “Disciplina é Liberdade”. Aquele modelinho que utilizo há tempos – Lucro | Troco | Truco – ajuda bastante. O novo GRAFFiTi ainda é apenas um “truco”. Merecerá só 10% de meu tempo. O restante seguirá aqui, nos estudos, artigos e eventos do finito. Precisa dizer que seguirei contando com você? Feliz 2011. Inté!

    .:.

    Observações:

    1. É muito difícil escrever e pensar de verdade em um “Feliz 2011” vendo o terror dos últimos dias na região serrana do Rio, em São Paulo e aqui no Sul de Minas. Entristece mais a certeza de que daqui poucos dias a grande mídia mudará de assunto (Carnaval!) e só voltará a se preocupar quando desgraças começarem a marcar o próximo verão. Quem pensa que é o “4º Poder” e que como tal tem poder de fiscalização deveria entender que é tão responsável pela inexistência de políticas de prevenção quanto os governos. Repito: tão responsável quanto. Nossa “grande” mídia não é só babona, interesseira e pobre não. É irresponsável também.
    2. A imagem utilizada, No 11 – black on white, é da Kirsty Hall.

  • FDP – Sprint Review II

    Prometi esta segunda revisão para a semana passada. Mas a agenda e o medo de que meu entusiasmo contaminasse a avaliação me impediram. Entusiasmo? Sim – o evento foi bom pra caramba! Tanto que só consegui baixar a adrenalina lá pelas duas da matina, depois de incontáveis rodadas de chopps. Agora, com o espírito crítico devidamente calibrado, tentarei escrever uma honesta prestação de contas.

    .:.

    Tivemos cinquenta participantes. Me lembrei das primeiras edições do FAN. Já chegamos a atender setenta pessoas, um número pra lá de exagerado em eventos desta natureza. Mas a quantidade de pessoas não comprometeu em nada o curso, pelo contrário. Criou um clima de trabalho onde todos pareciam realmente motivados. E mesmo aqueles que tradicionalmente gostam de ficar quietos em seu canto colocaram a mão na massa. Grupos de 6~8 pessoas emulavam times Scrum. E em um time Scrum é difícil alguém fingir que está trabalhando.

    Comecei o evento confessando um ‘frio na barriga’ mais gelado que o normal. Era uma estreia. De um programa que fez algumas apostas arriscadas: i) ‘Esticar’ o framework Scrum de forma a contemplar as etapas de Visualização e Especulação (criação da Visão do Produto; planejamento de Releases; definição da primeira versão do Backlog do Produto); e ii) Reapresentar componentes básicos do Scrum, criticando alguns pontos dos checklists oficiais.

    Não eram pré-requisitos para participar do evento o conhecimento ou experiência com o Scrum. Pouco mais da metade da plateia já trabalhava com o Scrum. Foi de parte deles que ouvi alguns “ah’s!”. Tipo: “não foi bem assim que nos ensinaram, mas acho que é disso mesmo que a gente tá sentindo falta”. Como coloquei na revisão anterior, os trabalhos clássicos sobre o Scrum partem de uma Visão pré-estabelecida. Apesar dos alertas (que não são poucos), muitos acreditam que o trabalho começa ali, traçando histórias e empilhando-as em um backlog. É preciso reforçar que um backlog frouxo, fruto de uma visão embaçada, é um dos principais suspeitos em implementações Scrum que “não vingam”.

    Mas eu errei na segunda aposta. Não na reapresentação (dos componentes básicos do Scrum), mas no momento. Segundo avaliação da própria turma – ao vivo e tête-à-tête – eu deveria ter concentrado tal apresentação no início do curso, quando optei por um simples “Scrum em 15 minutos” Ao salpicar estas revisões no decorrer do curso e, principalmente, por acumular boa parte delas no finalzinho do dia, acabei quebrando o ritmo (e o clima). A turma vinha quente de três atividades consecutivas, com a mente centrada no projeto e, de repente, vê seu pique freado por uma sequência de “blá-blá-blás”. Insisto: bla-blá-blá necessário, porém mal posicionado. Mensagem que não esquecerei nunca mais: coloque toda a parte “chata” do evento no período da manhã – o pessoal prefere “chatice” concentrada do que diluída. Mas não abrem mão dela, da tal “teoria”.

    Assim como não abrem mão de exemplos. Alguns participantes sugeriram a apresentação de resultados pré-elaborados. Não curto isso, porque eles são naturalmente artificiais (hehe!). Mas entendo a necessidade. E tentarei saciá-la através da demonstração dos resultados pelos próprios grupos. Contribuo mais criticando os resultados do que apresentando um só meu. O problema é o cronograma…

    A outra dica / reclamação principal eu já esperava: um dia é muito pouco! Praticamente não tivemos atropelos – cancelamos apenas uma atividade prática – e todo o programa (“teórico”) foi cumprido. Eram 17h55 quando a turma foi “dispensada”. Mas ficou – se não em todos, na grande maioria – a sensação de “quero mais”. Eles queriam tempo para debater cada exercício, ver exemplos e trocar experiências entre os grupos. Apenas estes pequenos reviews exigiriam algo em torno de duas horas adicionais. Por um único motivo (custos!), meu parceiro e eu gostaríamos de manter o FDP com carga de 7 horas. Somos voto vencido. Precisarei de um tempinho para redesenhar a oficina – não gostaria de repetir a fórmula dos dois dias consecutivos já consagrada no FAN. Sei lá porque mas não gostaria.

    Um ponto chamou a atenção de quem já tinha mais experiência com Scrum: a preocupação com a definição e medição do *Valor*. Em uma pequena grande série de artigos, publicada no meio do ano, eu já havia adiantado parte de minhas ideias. Surrupiei sugestões do Jim Highsmith e as misturei com técnicas que já utilizava (particularmente com a Matriz hiper-mega-super Simples de Priorização). A montagem e priorização do backlog do produto não é uma atividade trivial. Tentei mostrar como a definição do Valor e o debate sobre a complexidade ou riscos técnicos podem (ou devem) acontecer no mesmo momento e com envolvimento de todos – DP, ScrumMaster e Time – inclusive de outros representantes das áreas usuárias. Aquela tal matriz nasce neste encontro. E facilita demais a montagem de um Backlog.

    Por incrível que possa parecer, a percepção do *Valor* (do que o negócio ganhará com aquele produto) parece ser difícil. A impressão que fica é que as pessoas não têm o costume de falar sobre isso. Muito menos de tratar tal definição como O fator crítico de sucesso para um projeto. Aliás, a própria definição de sucesso ou fracasso depende desta definição. Eu até tentava compreender quando notava essa dificuldade em Analistas de Negócios. Agora, falando com Donos de Produtos, a luz vermelha piscou e a sirene berrou.

    .:.

    A estreia do FDP ficou muito acima de minhas expectativas. Com certeza foi “sorte de estreiante”. E não tenho dúvidas de que a turma destoou: era muito boa e muito participativa. Já encontrei várias assim no FAN. E é pela experiência com ele que sei que encontrarei turmas mais arredias, selvagens, sonolentas ou simplesmente meio-desligadas. Só espero que elas não apareçam logo na segunda ou terceira edições. Prefiro encontrá-las quando a oficina estiver um pouquinho menos verde.

    Assim como aconteceu com o FAN, tentarei registrar aqui todo o processo de maturação. Transparência ingênua? Não! A certeza de que só o seu feedback pode fazer o FDP amadurecer de fato. Aos que já participaram e seguirão participando meu sincero agradecimento. Inté!

    .:.

    Observações:

    1. Cometi uma injustiça danada na lista de referências bibliográficas publicada na primeira revisão. Me esqueci de mencionar o livro “Scrum Product Ownership“, de Bob Galen (RGCG, 2009). Foram os seus escritos que motivaram e inspiraram boa parte das “licenças poéticas” do FDP. Forma, com”Agile Project Management“, de Jim Highsmith, e “Agile Product Management with Scrum“, de Roman Pichler, a base para a Formação de Donos de Produtos. Ou seja, a base (teórica) do FDP.
    2. Todas as fotos publicadas neste artigo foram tiradas pelo fiel escudeiro e parceiro Anderson Oliveira, da Tempo Real Eventos. O cara tá ficando bom nisso! Outras fotos podem ser vistas no Flickr.

  • FDP – Sprint Review I

    No artigo que escrevi sobre “O Dono do Produto” prometi mostrar um pouco mais sobre a oficina “Formação de Donos de Produtos“. Vou fazê-lo em duas partes. Na próxima semana, logo após a estreia, publicarei uma prestação de contas com avaliações dos participantes. Hoje, neste primeiro Sprint Review, tentarei explicar a mecânica e filosofia do evento.

    .:.

    Um treinamento sobre Scrum ou fortemente baseado nele, como é o caso do FDP, deveria ser planejado, construído e apresentado como produto de um esforço guiado pelo próprio Scrum. Sem artimanhas ou enfeites baratos – ou até com alguns deles, como mostrarei na sequência – mas preocupando-se e ocupando-se com a experiência e a contínua melhoria do produto. Daí a necessidade de aparição aqui e das possíveis conversas que virão. Daí o fato da última atividade prevista, de um total de sete, ser uma revisão informal do próprio evento. As fichas de avaliação, por exigência do parceiro, seguirão existindo. Mas todos os participantes serão convidados para um Sprint Review no final do dia. Papo informal que deve escorregar para um etílico happy-hour. Mas é papo sério!

    Ainda são poucos os trabalhos, livros e eventos dirigidos especificamente para os Donos de Produtos (DP’s). Meu trabalho de exploração, além das experiências práticas, se baseou principalmente em dez títulos (apresentados no final deste artigo). Como adiantei no programa e em outros lugares, esta oficina está repleta de “licenças poéticas”. Explico: apesar de respeitar integralmente as diretrizes do Scrum e práticas mais aceitas (ou comuns), precisei adaptar e incluir várias coisinhas que são ignoradas pela gramática oficial do framework.

    Dediquei especial atenção ao momento inicial de um projeto. E incorporei elementos do framework APM (Agile Project Management) apresentado por Jim Highsmith no livro homônimo. As etapas de Visualização (Envision) e Especulação (Speculate) são cruciais para o DP. Mas elas são ignoradas em trabalhos clássicos sobre métodos ágeis ou mesmo sobre Scrum. A grande maioria deles parte de uma Visão já existente e não se preocupa em mostrar como ela é construída. Por isso dediquei dois “capítulos” do programa só para isso, “O Produto” e “Roadmaps, Releases, Sprints…”. Os participantes vão elaborar a Visão de um produto e derivar dela o Backlog do Produto. Das seis atividades práticas, quatro têm esta finalidade.

    Outro relativo “buraco negro” da gramática oficial do Scrum é a definição do Valor: a relevância de determinada funcionalidade, requisito, história ou tarefa para o negócio ou para a realização do produto. Incorporei parte do método que sugiro no FAN, mas o temperei com o algoritmo de definição de Pontos de Valor também sugerido por Jim Highsmith. Gostei tanto da brincadeira que adaptei o Planning Poker para o debate sobre o Valor de cada item do Backlog. Os participantes ganharão um jogo de cartas personalizado. Para a definição de pontos de valor utilizamos um conjunto menor da escala de Fibonacci. Mas, como já estava com a mão na massa mesmo, fiz um baralho que pode ser utilizado no Planning Poker tradicional.

    Aliás, o baralho é um dos “enfeites baratos” que citei acima. Aquilo que chamei de “Kit do DP Moderno” também é composto por fichas para anotação de Histórias de Usuários, um modelinho para especificação de Casos de Uso (mesmo utilizado no FAN), um Risque & Rabisque com um Quadro Scrum e, claro, post-it’s.

    Os enfeites, que pra falar a verdade não são assim tão baratos, evitam improvisos e perda de tempo. E são ferramentas que o DP utilizará em seu dia a dia. Mas ai de quem aparecer na oficina só para ganhar brinquedinhos.

    Não é fácil consolidar em um evento com sete horas de duração uma boa simulação da vida de um DP em um projeto. Só a primeira execução me dará uma boa noção da distribuição do tempo, mas eu estimo que teremos algo entre 2h30 e 3 horas de atividades práticas. É pouco, eu reconheço. E está aqui o principal ponto de extensão (para uma possível versão com carga horária maior).

    Já sei que estamos com sala praticamente lotada (40+ inscritos). Levarei também alguns convidados – gente que não pisa em cascas de ovos quando vai me criticar. É um feedback mais que necessário para um evento totalmente novo. Resta torcer para que eu não tenha cometido muitos erros. Na próxima semana eu conto o resultado. Inté!

    .:.

    Os Principais Livros Utilizados:

    • Agile Project Management – Second Edition
      Jim Highsmith | Addison-Wesley (2010)
    • Agile Product Management with Scrum
      Roman Pichler | Addison-Wesley (2010)
    • Kanban e Scrum – Obtendo o Melhor de Ambos
      Henrik Knibert e Mattias Skarin | InfoQ (2009)
    • Succeeding with Agile
      Mike Cohn | Addison-Wesley (2010)
    • Agile Estimating and Planning
      Mike Cohn | Prentice-Hall (2006)
    • Coaching Agile Teams
      Lyssa Adkins | Addison-Wesley (2010)
    • Subject to Change
      Peter Merholz et al | O’Reilly (2008)
    • REWORK
      Jason Fried e David H. Hansson | Crown Business (2010)
    • Sistema Toyota de Desenvolvimento de Produtos
      James M. Morgan e Jeffrey K. Liker | Bookman (2006)

    A imagem utilizada neste artigo, “Walking in Circles“, é de HikingArtist.com.

  • O Dono do Produto

    Tão ou mais complicado do que criar o produto – em meu caso, um treinamento – será o trabalho de ‘criar’ uma freguesia para ele. Sei que o FDP¹(Formação de Donos de Produtos) atrairá gente letrada e com experiência em projetos de software. Ok. Entendo que a maioria delas não vai desempenhar o papel e sim apoiar e orientar os profissionais que o farão. O treinamento deve contemplar esta modalidade de uso e o faz². Mas eu também sei que o evento não será legal se não contar com “não-letrados”, gente que não seja de TI e sim do negócio. Este treinamento foi desenhado principalmente para eles, nossos (frequentemente) mal compreendidos e (invariavelmente) mal tratados usuários. Ok, sei que não vou atrai-los com demagogia barata. Antes de mais nada, é preciso explicar melhor quem é esse tal de Dono do Produto (ou Product Owner), o que ele faz, como, porque etc. É o que tento com este artigo.

    .:.

    O dono do produto é O Cara. O cara que deve gerenciar o escopo de um projeto e garantir que o produto criado realmente gerará valor para o negócio. Do glossário oficial não consta o termo “escopo do projeto” e sim “Product Backlog”. Aqui, para desagradar a gregos e troianos, vamos chamar esse trem de Pauta. Antes que você tenhas ideias criativas e/ou nocivas, retomemos o fio da meada. O dono do produto, como o próprio nome confessa, tem a palavra final sobre funcionalidades, características e formato da obra gerada pelo projeto. E, acima de tudo, ele deve garantir que o produto atenda os objetivos pré-estabelecidos, ou seja, que ele gere valor. Peço sua atenção para o termo “pré-estabelecidos”. Obrigado. Já já conversaremos sobre isso.

    O dono do produto (DP daqui pra frente) deve ser do negócio. Aqui temos duas possibilidades. Se o produto destina-se para uso interno, então o DP será um representante de todos os usuários. Dele será exigido domínio do problema que o produto ajudará a resolver. Ele será escolhido não só pelo (amplo e profundo) conhecimento que detém, mas também pelo bom relacionamento com todas as outras partes interessadas. Deve ser reconhecido e merecedor da autonomia que receberá.

    Quando o produto é dirigido para o público externo, então o DP pode ser o próprio gerente do produto, quando existir, ou então um representante da área de marketing da empresa. É interessante notar que neste contexto o DP, na maioria das vezes, não cuidará de apenas um projeto mas de todo o ciclo de vida de um produto. Desconfio que seja uma possibilidade pouco aproveitada em solo tupiniquim.

    Do DP espera-se autoridade e autonomia em todas as decisões sobre o escopo do produto e as prioridades do projeto. Dele será cobrada disponibilidade para atender os demais membros da equipe do projeto. Recomenda-se que ele dedique, no mínimo, uma hora por dia ao projeto.

    Um DP por Projeto – Um Projeto por DP

    Por óbvio que pareça, é preciso dizer que cada projeto, cada produto tem um e apenas um dono. Invertendo a equação pisamos em terreno não tão óbvio: um DP deveria cuidar de apenas um projeto. Dois, no máximo. E desde que sejam pequenos. As empresas de Pindorama têm a péssima mania de jogar em seus profissionais uma carga de trabalho exagerada. Os profissionais de Pindorama têm o péssimo costume de tentar equilibrar em seus ombros uma carga de trabalho muito além de sua capacidade de entrega. Daí a relevância deste parágrafo.

    Um ponto não tão claro que só agora ganha a devida relevância é a solidão do DP. Segundo algumas interpretações, esta seria função de uma só pessoa. Uma visão mais prática e pragmática nos abre outras possibilidades. O DP pode ser uma pessoa sem disponibilidade para entrevistar n usuários, detalhar n cenários, responder n dúvidas do time etc. Pode ser muito n para uma pessoa só. Por isso autores como Jim Highsmith e Roman Pichler sugerem a existência ou necessidade de um Time do Produto³. Este time, como já foi apresentado aqui no finito, pode ser composto por analistas de negócios, consultores, especialistas no domínio e outros usuários ou partes interessadas. Cabe ao DP manifestar a necessidade de apoio. E ele não pode ser constrangido por dogmas bobos. Ele é o *dono* e, como tal, deve saber do que precisa para fazer seu trabalho bem feito.

    Colocado e Falante

    De boa que é, merece repeteco uma afirmação que fiz em artigo recente: “é o olho do dono que engorda o boi”. Colocando de outra forma: não há DP distante ou remoto. No mundo ideal ele ocupa a mesma sala dos outros integrantes do time. No mundo real ele deve visitar esta sala pelo menos uma vez por dia. E permanecer lá, à disposição e sem interrupções (celular desligado, please!), por pelo menos uma hora.

    Quando apostamos na figura de um DP estamos fazendo uma aposta bem maior: no valor do conhecimento tácito, na eficácia das conversas. Ou, como colocou um freguês, “estamos trocando 10 páginas de documentação por 10 minutos de prosa”. Se o DP não tiver disponibilidade e não for onde o time está não há conversas. Se elas não ocorrem então perdemos a aposta. Simples assim.

    O Passo Esquecido

    Este é o título de um dos capítulos do FAN. Descreve aquele fundamental e mal tratado momento que ocorre entre o entendimento de um problema e o desenvolvimento de sua solução. Aqui ele ganha escopo mais amplo. Trabalhos clássicos que ajudaram a criar e definir o papel do DP – como “Agile Project Management with Scrum“, de Ken Schwaber (Microsoft Press, 2004) – partem de uma visão do produto já definida. Sim, agora estou falando sobre aqueles “objetivos pré-estabelecidos” para os quais chamei sua atenção lá no início do artigo. É razoável supor que o DP participará da criação da visão do produto do qual é *dono*, não? Não me pergunte porque aqueles trabalhos ignoram este momento. Eu não saberia responder. Não sem uma considerável dose de veneno.

    Os conhecimentos do DP são mais exigidos nos momentos iniciais do projeto. Será um sinal de sanidade do projeto a decrescente dependência dos outros membros do time em relação ao DP. Significará que o conhecimento realmente se espalhou pela equipe. Todos passarão a demonstrar de razoável a impecável domínio do problema que tentam resolver. O que não pode significar, de forma alguma, o afastamento ou distanciamento do DP. Ele sempre terá responsabilidade pela manutenção e priorização da Pauta do projeto, do primeiro ao último dia do projeto. E, claro, é ele quem aceita ou não o resultado de cada iteração (ou sprint).

    Os Passos Executados

    Como já vimos, o DP tem duas grandes responsabilidades em um projeto: i) Definir a Visão do Produto e respectiva Pauta – funcionalidades e características de um produto. Fica subentendido aqui que a Pauta é formada por itens devidamente priorizados e que a priorização também é responsabilidade exclusiva do DP; e ii) Garantir que o produto em gestação está definitivamente a caminho de realizar os objetivos do negócio. Cada responsabilidade compreende um conjunto de atividades que fica a cargo do DP.

    A Pauta (lembre-se, o Product Backlog segundo gramáticas oficiais) deriva da Visão do Produto. A criação de ambas é responsabilidade do DP. Espera-se que a Visão, normalmente de alto nível (2km X 2cm…), seja estável durante todo o projeto. Ela explica funcionalidades e características gerais do produto, além de oficializar restrições (escopo, prazos e custos). A visão deve mostrar, principalmente, como o produto gerará valor para o negócio.

    Já a Pauta será desenvolvida de maneira iterativa e incremental. O DP e o time se preocuparão em detalhar apenas os itens necessários no horizonte pré-fixado (da iteração ou sprint). Uma iteração geralmente dura duas ou quatro semanas. Projetos estressados (complexos em sua porção negócio ou tecnologia ou ambas) devem utilizar a primeira opção. Projetos tranquilos se contentam com a calmaria dos ciclos de trinta dias. Espera-se que o DP (e seu opcional Time de Produto) esteja trabalhando no entendimento e detalhamento dos itens que comporão a pauta da iteração imediatamente posterior. Particularidades do projeto, da organização ou a velocidade do time podem pedir que o DP trabalhe com duas ou até três iterações de antecedência. É importante notar que isso não pode significar, em hipótese nenhuma, o não atendimento do time na iteração atual – dirimindo dúvidas e verificando a realização do produto, principalmente.

    Praticamente todos os proponentes de métodos que utilizam a figura do DP sugerem que os itens que compõem a Pauta sejam redigidos na forma de Histórias de Usuários (ou User Stories). Este padrão “força” a realização de conversas. É importante que o DP saiba que existem alternativas (casos de uso, por exemplo) e que ele deve optar pelo formato que lhe deixe mais confortável. Algumas organizações precisam de um pouco mais de formalidade (aka Documentação), por razões mil (sendo que 989 são bullshitagem/burocracia pura). Dependendo de suas exigências, parte do time pode ser destacado para atendê-las. Colocando de outra maneira: da porta (da sala do time de projetos) pra fora é oferecida uma documentação mais formal; Da porta para dentro o time pode optar por um padrão de conversas mais informal e leve. Um bom DP saberá lidar com as duas modalidades de comunicação.

    Em inglês fala-se que o DP é responsável por “grooming the product backlog”. Em tradução literal o verbo groom significa preparar, arrumar (ou adestrar cavalos). Acho que, em português, devemos nos contentar com o termo “manutenção da Pauta”. É crucial que o DP saiba que a Pauta é um (documento? artefato? ferramenta? – são tantos termos detestados, tantas emoções desperdiçadas…) Começando de novo: É crucial que o DP saiba que a Pauta é um trem vivo – um negócio que exigirá sua atenção diária. Itens da Pauta (requisitos, histórias ou casos ou…) ganharão ou perderão prioridade; mudanças surgirão (e não serão tratadas como más notícias); erros serão cometidos (e não significarão pena de morte aos seus causadores). Se o DP não administrar (!) diariamente todas as ocorrências as quais estão sujeitas a sua Pauta, me diga: que p%&R@ o cara está fazendo lá?

    Aos Donos com Carinho

    Por tudo isso e mais um tanto é que se diz que a função do DP é a mais crítica e complexa em um projeto guiado pelo framework Scrum. A vida de um DP não é nada fácil. Mas pode ser muito gratificante e edificante (Houaiss: que conduz à virtude). Quem já entregou projetos e viu os olhos dos usuários brilharem (e seus respectivos negócios lucrarem) sabe do que estou falando. A entrega de um produto pelo DP guarda uma satisfação ainda maior, exatamente porque foi ele quem desenhou e de certa maneira conduziu aquela realização. O bom DP sabe que o sucesso deve ser compartilhado por todos que participaram do projeto. Mas lá no fundo ele guarda algo que não confessará: a impressão digital mais notável deixada no produto é sua. Para o bem ou para o mal.

    .:.

    Observações:

    1. Foi em um belo boteco de Copacabana, bem servido de chopps, que consegui convencer meu parceiro de que a sigla FDP é filhadaputamente excepcional para uma oficina que se propõe a Formar Donos de Produtos. Além do apelo pop, serve também para peneirar e manter chatos ultrasensíveis bem distantes. Quem não güenta o leve tranco d’uma brincadeira boba demonstra não possuir um requisito mínimo que todo DP deve apresentar: bom humor!
    2. Faço questão de frisar na divulgação do FDP que todo o material didático utilizado está liberado para uso. As restrições são mínimas: i) Agradeça publicamente o autor; ii) Compartilhe o material utilizando a mesma licença; e iii) Se você pretende ganhar algum $ com o material, combine antes a comissão que irá me pagar. Preciso salientar isso porque sei que muitos vão querer replicar o treinamento em suas empresas. Em breve vou mostrar aqui no finito alguns dos itens que vão compor aquilo que estou chamando de “Kit do PO moderno” e que você poderá reutilizar.
    3. De longe já são os dois livros mais citados aqui no finito: “Agile Project Management – Second Edition“, de Jim Highsmith (Addison-Wesley, 2010) e “Agile Product Management with Scrum“, de Roman Pichler (Addison-Wesley, 2010). Se eu seguir referenciando-os assim periga eu te dispensar de estudá-los. Hehe.. brincadeira.
    4. Aproveitei o artigo para experimentar mais um pouquinho o método do Pensamento Visual. A sequência utilizada para apresentação do DP – quem, quanto, onde, quando, como e porque – obedece as regrinhas dos 6 W’s propostas por Dan Roam em “The Back of the Napkin” (Portfolio, 2008).
    5. A foto utilizada no topo, “Home Market: 1941 in Worthington, Ohio“, é do Don O’Brien.

    Faltou dizer:

    Caramba, ainda estás por aqui? Este artigo está com o dobro do tamanho padrão (2200 palavras!). Mas faltou dizer… Que o DP não é uma exclusividade dos projetos que são guiados pelo framework Scrum. Aliás, não precisa ser uma exclusividade. Ele é uma adaptação, por exemplo, do Engenheiro-Chefe utilizado pela Toyota há décadas. Pode ser visto também como uma exótica e criativa remixagem das funções do gerente de produtos e do gerente de projetos.

    É claro que, apesar das “licenças poéticas”, baseio boa parte de minhas sugestões no DP conforme definido na gramática oficial do Scrum. Mas preciso dizer que a idéia do DP, de boa que é, não deve ficar limitada ao uso do Scrum. Pronto, disse. Inté!

  • Scrum kanbanbanban balangandã

    Conclusão do papo iniciado em “Scrum praticundum burungundum“¹. Naquela primeira parte tentei ilustrar a crescente adoção do Scrum em Pindorama. O texto de hoje se ocupará dos principais problemas enfrentados, possíveis causas e soluções. É necessário lembrar que minhas conclusões não estão baseadas em uma pesquisa estruturada. Elas são fruto de conversas e consultas informais.

    .:.

    O Scrum, pequeno e simples que é, não deveria ter significados diferentes para as pessoas. Quando alguém me diz que está adotando o Scrum, minha primeira pergunta é: “Scrum e?…” Muitos interlocutores não entendem a questão. Ignoram o fato de o Scrum orientar apenas o processo de gestão de um projeto. Uma parte deles está de fato adotando derivações ou até mesmo o XisPê (eXtreme Programming). Outra parte descobre depois de um tempinho que “tá faltando um monte de definição”. Alguns deixam que a equipe técnica selecione suas práticas favoritas ou que trabalhem como os Allman Brothers, em puros e longuíssimos improvisos. Nada disso se configura um problema se combinado previamente. No entanto, no mínimo para não falar besteiras, é bom saber o que vem do Scrum e o que foi importado de outros lugares.

    Um dos exemplos de “práticas importadas” são as User Stories (ou histórias de usuários). O Scrum não diz como deve ser explicitado o backlog do produto nem como devem ser redigidas as necessidades dos usuários. Autores como Jim Highsmith, Mike Cohn e Roman Pichler² manifestam sua preferência pelo padrão User Story. Sua natureza evolutiva “combina” melhor com o Scrum e com métodos ágeis em geral. Acontece que muitos acreditam que esta seria a única maneira de registrar os requisitos do negócio ou dos usuários, o que não é verdadeiro.

    Mas o que realmente importa é a necessidade de *completar* o Scrum com práticas de engenharia. E aqui deveríamos ver variações mil. Por quê? Oras, organizações, equipes e projetos têm necessidades e restrições bastante específicas. O chapéu Scrum, largo e leve que é, pode caber em qualquer cabeça. Mas seu complemento demanda cuidado. Um zelo que tem faltado em algumas implementações.

    E por falar em implementação. Qual a melhor estratégia? Implantar o Scrum em toda a organização em uma tacada só ou, como um bom e legítimo mineiro, promover uma adoção gradual (comendo quieto e pelas beiradas)? Sou mineiro. E quanto mais conservador ou desestruturado for o ambiente, mais lento é o ritmo que recomendo. Aposto nos hábitos e gostos que são desenvolvidos de maneira natural e orgânica, sem imposições. Deveríamos acreditar mais no potencial das boas ideias que são incorporadas – aprendidas de verdade – através de bons exemplos. Mesmo em organizações que precisam ou merecem radicais safanões, é complicada a implantação do tipo big-bang. Só o exorcismo do espírito Waterfall (cascata), que assombra por anos ou décadas, já é um trabalho e tanto. Representa uma mudança que raríssimas vezes pode ser classificada como simples ou sem traumas. Resumindo: é mais fácil adotar o Scrum de maneira gradual. Poucos casos, como o da Salesforce.com documentado por Mike Cohn em “Succeeding with Agile” (Addison-Wesley, 2010), justificam outra estratégia.

    E por falar em cascata. Não é que tem gente que fala que tá usando o Scrum mas manda um analista lá no cliente para “levantar *todos* os requisitos”? Gente que depois compila isso tudo numa proposta com escopo, preço e prazo fechados? Isso sim pode ser julgado como pecado mortal – um crime premeditado. Mas, guarda o fósforo menino! Não é questão de jogar hereges na fogueira. Uma das perguntas mais frequentes que ouço é exatamente sobre isso: como um prestador de serviços vende um projeto baseado no Scrum? O assunto é tão espinhoso e controverso que merecerá um artigo (ou série) só para ele.

    Outro ponto que facilmente se converte em discussão é o autogerenciamento pelo time do projeto. Existem duas interpretações principais: i) o time cuida de tudo e decide tudo; ii) “autogerenciamento não significa falta de liderança mas um estilo diferente de liderança”, escreveu Jim Highsmith na segunda edição de “Agile Project Management“ (Addison-Wesley, 2010). Sou ignorante pra burro (hehe) e conheço pouquíssimos casos da história da humanidade que comprovem a viabilidade da primeira opção. Pra citar assim, de cabeça, só o caso da Democracia Corinthiana, que durou cerca de dois anos (1982-83). Ainda assim, garanto que a leitura da última frase lhe trouxe lembranças do Dr. Sócrates, Casagrande e Vladimir.

    Henrik Kniberg e Mattias Skarin colocam em “Scrum e Kanban – Obtendo o Melhor de Ambos” (InfoQ, 2009) que “o Scrum é suficientemente minimalista tal como é, se você remover coisas e continuar chamando isso de Scrum a palavra ficará sem sentido e confusa”. Porém, nada nos impede de “colocar coisas” no Scrum. Parece ser o que fez Jim Highsmith no livro  já citado. Ele coloca a figura de um líder de projetos. Estranhamente, sem usar o termo Scrum. Sei lá se por respeito ou qualquer outro motivo. Também precisamos considerar um aspecto cultural: o brasileiro parece gostar de líderes e de ser liderado. Não é o caso de discutir se isso se dá por preguiça, submissão ou letargia (que é a preguiça chique). Ou é (o caso de discutir isso)? Sei lá.

    Outra pergunta de meu informal check-list: “Você confia em seu PO? Ele tem a palavra final sobre o escopo do projeto?” Espanta o número de vezes que ouço um “não” como resposta. Um “não” que algumas vezes nem tem noção do tamanho de engano que representa. Se há um termo muito feliz³ criado no Scrum é Product Owner (PO) – *Dono do Produto*. “Dono” dispensa explicações. Quando um dono não tem palavra final então ele não é dono de nada. Não existe meio dono.

    Existe um dito popular que ensina que é “o olho do dono que engorda o boi”. Adaptado para nosso caso, podemos dizer que é “o olho do PO que garante a entrega do produto”. E o que dizer dos PO’s indisponíveis, daqueles que não têm tempo para olhar o boi?

    E que dizer dos PO’s que não são do negócio? O que dizer dos PO’s?

    Outro dia eu digo. Inté!

    .:.

    Observações:

    1. Sigo firme na tradição dos títulos ridículos. Mas desta vez escondi ali uma provocação. Se surtiu efeito eu não vi. Chamei o artigo anterior de “Scrum praticundum burugundum”. A rima (!) só é possível se a pronúncia estiver errada. É  que eu ouço “ScrUm” com mais frequência que  “ScrÃm” (ou “Scrammm”). Fecho a provocação (mas não a tradição dos títulos ridículos) com o “Scrum kanbanbanban balangandã” de hoje.
      E não, (ainda) não tenho a intenção ou condição de falar sobre o Kanban. Dele só aproveitei a rima mesmo. Se o tema lhe interessa, aquele livro aberto e gratuito citado é uma boa dica.
    2. No próprio texto já referenciei os trabalhos de Highsmith e Cohn. Faltou citar o livro do Roman Pichler, “Agile Product Management with Scrum” (Addison-Wesley, 2010). Um dos poucos dirigidos especificamente para PO’s.
    3. Não sei se você sabe, mas os termos criados para o Scrum são intencionalmente “infelizes” ou “ruins”. Ruins no sentido de serem bastante diferentes daqueles utilizados tradicionalmente: Product Backlog, ScrumMaster, Product Owner, Sprint Backlog… A sacada do vocabulário original e radical é boa porque evita confusões. Bom, deveria evitá-las…
    4. “Battle against Time”, a bela foto que ilustra o artigo, é do Joakim Jardenberg.

  • Scrum praticundum burungundum

    A crescente adoção do Scrum por empresas tupiniquins chega a ser surpreendente. Seu uso por pequenas e médias empresas da indústria digital é facilmente justificável. Mas quando vemos grandes negócios – de áreas não relacionadas diretamente com TI – adotando aquele framework ágil para gerenciamento de projetos, devemos entender que algo importante está acontecendo.

    Este artigo é o primeiro de uma pequena série que tem a intenção de ilustrar um pouco o estágio atual de uso do Scrum no Brasil. Nesta primeira parte, um breve panorama – uma fotografia com 2km de extensão por 2cm de profundidade. Na sequência escreverei sobre os probleminhas que tem sido reportados com mais frequência em relação ao uso do Scrum. Questões relativamente pequenas, mas com potencial para batizar o mais novo integrante da família das boas ideias que fracassaram.

    .:.

    O Scrum, na forma como o conhecemos hoje, está quase completando 20 anos de existência. Partiu de ideias e experiências da dupla Takeuchi e Nonaka¹. Mas adquiriu corpo e alma nos trabalhos e escritos pioneiros de Ken Schwaber e Jeff Sutherland². Ganhou trilha e impulso para o mainstream com a publicação do Manifesto Ágil. Dentre as diversas propostas de métodos e processos ágeis, o Scrum se destaca por ser o único que se preocupa exclusivamente com os aspectos gerenciais de um projeto. Por não incorporar nenhuma prática de engenharia, o Scrum possibilita sua combinação com diversas outras propostas, do RUP (Rational Unified Process) ao XisPê (eXtreme Programming), passando pela galáxia que existe entre eles.

    O que vou colocar no próximo parágrafo não tem a força de uma pesquisa estruturada. Por outro lado, a população amostral é suficientemente grande (2000+) para garantir que eu não esteja viajando ou forçando a barra.

    Nas primeiras turmas do FAN, no já longínquo 2007, apenas 5% dos participantes, em média, levantavam a mão quando eu perguntava: “Quem *conhece* o Scrum?” Na última edição do evento em São Paulo, no final de setembro, mais de metade da sala respondeu positivamente. E esta é a média de todas as turmas que encontrei neste ano, em São Paulo, Belo Horizonte e outras praças. Claro que não posso concluir que a adoção do Scrum no Brasil aumentou 1000% em três anos. Mas, pensando bem, desconfio que foi algo com tal magnitude que aconteceu. Aliás, está acontecendo.

    Testemunhei algo parecido, em menor escala, entre os idos de 1998 e 2000 e pedrinha. A moda e elixir para todos os males dos projetos de software de então era o RUP. Foi adotado por grandes empresas, como Petrobras e BankBoston, e estava nas bocas e agendas de todo mundo minimamente antenado com a área. Algum tempo depois, em empresas diferentes e distantes, vi reações parecidas: “Não fala de RUP que me dá urticárias!” Não vale o espaço e muito menos o seu tempo o diagnóstico sobre o que aconteceu com aquele incomensurável corpo de boas ideias (pobres estratégias e falsos evangelistas).
    {Mas merece nosso tempo a preocupação de que algo semelhante aconteça com o Scrum. Neste artigo, publicado em setembro/2009, eu falo um pouco sobre isso.}

    Antes, porém, vale a pena ilustrar um pouco mais a crescente adoção do leve processo de gestão que sugere a divisão das partes interessadas entre “porcos” e “galinhas”. Como já coloquei, não é difícil justificar o uso do Scrum por pequenas e médias empresas prestadoras de serviços de TI. Elas não puderam saborear adequadamente o RUP porque ele era um produto (leia-se: seu uso significava, na maioria das vezes, um pesado investimento em ferramentas que ‘viabilizariam’ o uso do método). Agora, elas ganharam um método que não cobra royalties nem força o uso de (dispendiosas) ferramentas. E, talvez um ponto mais importante: elas ganharam um método cuja implantação é relativamente fácil, rápida e barata. Ou seja, um sonho.

    Surpreendente é o fato de algumas grandes empresas também apostarem no Scrum. Inclusive empresas de ramos que têm a péssima fama de serem conservadoras e burocráticas – pelo menos no que se refere a TI – como bancos e seguradoras. Entre tudo o que é sinalizado em movimentações deste tipo, parece nítida uma grande insatisfação com processos, padrões e metodologias utilizados até então.

    No primeiro semestre apresentei duas palestras para um dos maiores bancos do Brasil. Fui convidado para “provocar” e apresentar “tendências”. A segunda palestra foi motivada pelo “burburinho” gerado na primeira. E foi dirigida para gerentes e afins. Ao justificar o encontro, um dos principais executivos da área disse: “Precisamos de novas ideias”. Em outro momento, nas entrelinhas de uma nova intervenção do mesmo executivo, havia uma mensagem bem direta: “Não dá pra continuar trabalhando da forma como fazemos hoje”.

    Há tempos, esta e diversas outras empresas acreditam que os problemas de comunicação entre áreas de negócios e TI podem ser combatidos com mais documentos, assinaturas, change requests e coisas do tipo. Ao final do evento aquele mesmo executivo brincou concluindo que “cada dez minutos de boa conversa pode eliminar a necessidade de dez páginas de papel”. Para todas as empresas que chegaram neste ponto, e não são poucas³, o Scrum apresenta possibilidades maravilhosas. É difícil ignorar o canto da sereia que cobra tão pouco pelo muito que promete.

    O movimento no mundo dos negócios tem reflexos no universo da educação. Agora, além dos tradicionais cursos relacionados com Scrum e similares, passaremos a ver apostas mais ambiciosas e, de certa forma, mais abrangentes. Um curso de extensão da Universidade Federal de São Carlos (UFSCar), que neste ano fez uma experiência com um método “genérico” baseado no modelo iterativo e incremental, adotará o Scrum para a turma de 2011. Os Donos dos Produtos (Product Owners, ou simplesmente PO’s) já foram nomeados – são funcionários da Universidade – e os projetos já foram definidos. Assim como a grade com a distribuição das disciplinas. É o tipo de experiência com potencial para espalhar ainda mais a “novidade” Scrum. Realizada por uma entidade com o nome e peso da UFSCar, pode significar um impacto ainda maior.

    .:.

    Observações:

    1. Desconfio que Takeuchi e Nonaka nem prestem muita atenção em sua distante “criatura”. Na realidade eles apenas inspiraram a criação do Scrum. O que eles devem realmente lamentar é o fato de outras grandes descobertas e experiências suas não ganharem o impulso “pop” que o Scrum experimenta hoje. A dupla – que digo parecer dupla sertaneja ‘de raiz’ de Piracicaba – publicou alguns dos trabalhos mais relevantes da mal interpretada disciplina conhecida como Gestão do Conhecimento. Vou citar três: “Gestão do Conhecimento“, compilação de artigos organizada pelos dois (Bookman, 2008); “Theory of Organizational Knowledge Creation” e “Reflection on Knowledge Management from Japan“, artigos publicados na obrigatória coletânea “Knowledge Management – Classic and Contemporary Works” (MIT Press, 2000).
    2. De Ken Schwaber: “Agile Project Management with Scrum” (MS Press, 2004) e “Enterprise and Scrum” (MS Press, 2007).
      De Jeff Sutherland: Scrum Log (desde 2002).
    3. Essa coisa que diz que escrever mais é a solução gera situações cômicas. Em uma turma fechada do FAN no Rio de Janeiro, eu explicava os cinco níveis de detalhamento que uma especificação de casos de uso pode ter. Mostrava aqueles cinco ícones sugeridos por Alistair Cockburn em “Escrevendo Casos de Uso Eficazes” (Bookman, 2006). Quando terminei a explicação um aluno falou: “Pra gente, que trabalha com fábricas de software, isso aí não vai funcionar não. Faz o seguinte: depois da ‘ostra’ (o nível mais baixo) vamos colocar mais um ícone. Sete mil metros abaixo do nível do mar. Coloca o símbolo da Petrobras e vamos chamar isso aí de ‘Nível Pré-Sal’. Só assim as fábricas fazem o que a gente precisa”.
      Triste conclusão de outro participante: “Nem assim funciona…”
    4. A foto utilizada, “Vertical Scrum“, foi tirada pelo Jurvetson.

  • 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é!