PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: eXtreme Programming

  • Times Líquidos, Parte 2

    Times Líquidos, Parte 2

    Como uma organização pode promover fluidez entre seus times sem comprometer a coesão interna das equipes, as relações com clientes, a qualidade e o ritmo das entregas? O post anterior tentou explicar a motivação para este movimento. É hora de conversar sobre como ele pode ser feito.Que o profissional possa conhecer todas as alternativas e escolher o projeto, processo ou produto onde trabalhar é requisito tanto óbvio quanto raro, particularmente em terras tupiniquins. Normalmente contratamos para uma posição pré-determinada. Quase sempre para apagar incêndios. A inexistência de testes – de um onboarding minimamente planejado – explica boa parte dos problemas que testemunhamos desde sempre. Essa mentalidade mecanicista – a peça que deve porque deve se encaixar em dado mecanismo – tem poucas chances de sucesso em trabalhos criativos. E este é só o começo da história.

    Porque, nos atos seguintes, trabalhamos pela manutenção daquela estrutura. Não vou negar o que escrevi no artigo anterior: devemos premiar as equipes duradouras. Faltou alertar: desde que tenhamos ciência e antídotos para os riscos que elas representam. 

    Um time com estrutura estável tende a ter uma forte coesão interna (bonding). Se essa estrutura for pouco porosa – de poucas trocas com outras equipes (baixo building) – ela se torna um silo. Pois é, uma estrutura moderna – multidisciplinar, autônoma e bem alinhada – está sujeita ao mesmo mal que aflige as unidades funcionais das organizações tradicionais: se transformar num silo que pouco colabora e não raro atua como se fosse o fim e não apenas um meio¹. 

    O alto nível de building – de convivência e trocas constantes entre times – é a principal condição para o desenho de uma organização flexível. Se o building é alto, os profissionais vão transitar com mais facilidade entre os diversos times². 

    Guildas e Capítulos

    Não é por outra razão que não seja a promoção do building a presença de guildas e capítulos no modelo Spotify. Essas formações visam a troca de experiências e conhecimentos. São releituras pouco criativas das Comunidades de Prática, outra ideia elegante, simples e pouco eficaz na promoção de trocas entre times. Essas propostas são fracas para o building porque:

    • seus encontros são esporádicos (os ciclos de feedback são longos);
    • geralmente envolvem muita gente (12+ é muita gente);
    • têm sérias restrições de tempo;
    • favorecem temas amplos visando atender o maior número possível de colegas, o que aumenta o risco de papos superficiais e pouco práticos;
    • muitos usam os formatos de palestra, aula ou demonstração. Leia-se: há grande risco de tédio, alienação, papos paralelos etc. 

    Ou seja, essas estruturas são caras, de difícil implantação e com resultados no mínimo duvidosos. Apesar do início promissor, da motivação natural que vem das coisas novas, esses grupos tendem ao esvaziamento em poucos meses. O building pede por desenhos mais criativos e ambiciosos.

    Desenhando o Intercâmbio entre Times

    Uma das receitas mais enxutas e promissoras é o Pareamento Promíscuo³ ou Pareamento Cruzado. É simples pra chuchu.

    Ingrediente: Um par, sendo cada membro de um time diferente

    Modo de uso

    1. A dupla se encontra diariamente
    2. O encontro dura entre uma e duas horas
      (Claro, a dupla tem autonomia para definir o melhor momento)
    3. A cada dia ou semana eles atuam em um dos dois projetos
    4. Eles paream, ou seja, trabalham juntos em uma mesma história ou item do backlog
    5. Este casamento deve durar pelo menos um mês. E não mais do que dois ou três meses, dependendo da complexidade dos domínios envolvidos.

    O trabalho em pares, uma prática essencial da XP (eXtreme Programming), não é uma exclusividade dos desenvolvedores. Designers, analistas e zagueiros também podem trabalhar em duplas. Por que não? Como não?

    Preciso me distanciar da ideia para fazer uma avaliação mais isenta. Porque, neste momento, vejo só benefícios: o potencial do olhar de fora para descobrir novas possibilidades; o refresco da troca de contexto; a possibilidade de trabalhar em outro domínio e/ou com outras tecnologias e ferramentas; além, claro, da intenção original da polinização cruzada. Tudo isso a custo zero? Pois é, parece bom demais para ser verdade. O que estou ignorando?

    Uma estrutura tão promissora e rica mas não tão econômica quanto a sugerida acima é o Time Plugin4.

    Ingredientes

    • O time Plugin formado por 2+ profissionais que não estejam alocados em nenhum projeto específico.
    • Se envolver um processo de onboarding, então os integrantes do Plugin são um tutor (coach não, tutor! – alguém que senta, ensina pareando e entrega) e pelo menos um novato (na organização, não necessariamente na profissão)
    • Um time hospedeiro. A equipe ideal deve ter pelo menos uma das seguintes características:
      – Um ou mais membros prestes a sair do time em caráter temporário (férias ou licença programada) ou permanente
      – Código relativamente antigo (2+ anos)
      – Um cliente que há tempo (12+ meses) só demanda mais do mesmo

    Modo de Uso

    1. Conecte o time Plugin ao time hospedeiro
    2. O acoplamento deve ser muito suave. Leia-se: os hábitos e rotinas do time hospedeiro não devem ser alterados
    3. O time Plugin pode ou não participar das cerimônias (dailys, retros, reviews etc). A palavra final é do time hospedeiro ou de seu cliente
    4. Se o objetivo é uma substituição, então
    5. Após 15~30 dias de conexão, espera-se que o membro novato tenha condições de assumir uma posição, qualquer posição, no time principal
    6. Isso é possível porque o novato realmente trabalhou naquele projeto, orientado inicialmente pelo tutor e depois por membros do time principal com quem pareou
    7. No início da conexão, pelo menos por duas semanas, é indicado que o novato atue exclusivamente em refatoração. Depois, oportunamente, ele pode se aventurar em itens novos ou até mesmo participando de alguns experimentos (spikes).

    Casos de Uso

    Um time plugin pode oferecer diversas funcionalidades para uma organização:

    • Cobertura de férias e licenças.
    • Substituição permanente de membros.
    • Área de onboarding: região segura onde um novo colaborador pode ser acomodado para entender o que é trabalhar naquela organização (cultura, métodos, ferramentas etc). Neste caso, a estrutura deve ser plugada nos diversos times existentes. Recomenda-se conexões com duração mínima de uma semana. Claro, desde que isso não resulte em meses e meses de onboarding.
    • Refatoração Oportunista: todas as refatorações são oportunistas de alguma forma. Aqui a intenção parece ser outra: a cobertura de férias, por exemplo. A usamos como desculpa para dar um belo tapa (por 15 ou 30 dias!) no código. O cliente fica duplamente agradecido: pela manutenção da estrutura do time e pelo código que ganhou um banho de loja a custo zero.
    • Spikes Interesseiros: há tempo o cliente não desafia o time principal. O relacionamento caiu na rotina. Há o risco do cliente cancelar ou pedir pela redução do contrato. É chegada a hora do código vendedor. Que o time plugin faça pesquisas e experimentos (spikes) na esperança de descobrir novas oportunidades de negócio para aquele cliente. Esta proatividade tende a render, no mínimo, uma boa surpresa e ótima impressão. 

    Quanto maior a rotatividade no time plugin, maior o nível de building alcançado. Quanto ele custa? Cerca de 10% de sua folha de pagamento atual, se houver a intenção de cobrir férias. Não é uma estrutura barata. Por isso é importante que ela seja rica em termos de funcionalidades oferecidas. 

    Nada impede que você mantenha as guildas e capítulos enquanto testa as duas sugestões acima. Não há conflito. E você ganha a possibilidade de fazer uma comparação mais objetiva dos benefícios e custos de cada estrutura. Se você o fizer, por favor, não deixe de compartilhar. Os desenhos sugeridos acima foram testados em apenas uma organização. Há outras referências (veja notas abaixo), mas nada substitui a validação no mundo real, com times de verdade. Se você quer conversar mais sobre as ideias e não gosta do formato assíncrono, considere a participação em uma edição da aula sobre Grandes TIMES Pequenos. Se pretende colocar as ideias para rodar e quer alguma orientação, conte comigo.

    Notas

    1. Um mal muito bem documentado em The Silo Effect, de Gillian Tett (Simon & Schuster, 2016).
    2. Bonding (coesão entre membros de um time), Building (desenvolvimento de parcerias com outros times) e Believing (confiança na organização) são os três tipos de Capital Social apresentados por Robert Bruce Shaw em Extreme Teams (Amacom, 2017). A matriz sugerida acima não é de Shaw. Sua elaboração é possível através de pesquisas internas. O building pode ser capturado através de duas perguntas: 1) Com que frequência você aprende coisas com outros times; e 2) Com que frequência você tem a oportunidade de ensinar coisas para membros de outros times.
    3. Na versão original, citada por Scott Ambler em Beautiful Teams (O’Reilly, 2009), a promiscuidade é total: os casais são trocados todo santo dia. A diferença é que todos atuam no mesmo produto / projeto. Na versão aqui sugerida os participantes são necessariamente de times diferentes. E o par não é trocado diariamente. Caso contrário, não há building. A versão aqui apresentada recebeu colaborações inestimáveis de Altieres Lopes, Will Marcondes, Klaus Wuestefeld e grande elenco.
    4. Pode ser confundido com os times capacitadores (enabling) propostos por Matthew Skelton e Manuel Pais em Team Topologies (IT Revolution Press, 2019). A versão aqui sugerida é um tanto mais ambiciosa em termos de funcionalidades oferecidas.
    5. Foto de Karim Ghantous no Unsplash
  • Times Líquidos, Parte 2

    Times Líquidos, Parte 2

    Como uma organização pode promover fluidez entre seus times sem comprometer a coesão interna das equipes, as relações com clientes, a qualidade e o ritmo das entregas? O post anterior tentou explicar a motivação para este movimento. É hora de conversar sobre como ele pode ser feito.Que o profissional possa conhecer todas as alternativas e escolher o projeto, processo ou produto onde trabalhar é requisito tanto óbvio quanto raro, particularmente em terras tupiniquins. Normalmente contratamos para uma posição pré-determinada. Quase sempre para apagar incêndios. A inexistência de testes – de um onboarding minimamente planejado – explica boa parte dos problemas que testemunhamos desde sempre. Essa mentalidade mecanicista – a peça que deve porque deve se encaixar em dado mecanismo – tem poucas chances de sucesso em trabalhos criativos. E este é só o começo da história.

    Porque, nos atos seguintes, trabalhamos pela manutenção daquela estrutura. Não vou negar o que escrevi no artigo anterior: devemos premiar as equipes duradouras. Faltou alertar: desde que tenhamos ciência e antídotos para os riscos que elas representam. 

    Um time com estrutura estável tende a ter uma forte coesão interna (bonding). Se essa estrutura for pouco porosa – de poucas trocas com outras equipes (baixo building) – ela se torna um silo. Pois é, uma estrutura moderna – multidisciplinar, autônoma e bem alinhada – está sujeita ao mesmo mal que aflige as unidades funcionais das organizações tradicionais: se transformar num silo que pouco colabora e não raro atua como se fosse o fim e não apenas um meio¹. 

    O alto nível de building – de convivência e trocas constantes entre times – é a principal condição para o desenho de uma organização flexível. Se o building é alto, os profissionais vão transitar com mais facilidade entre os diversos times². 

    Guildas e Capítulos

    Não é por outra razão que não seja a promoção do building a presença de guildas e capítulos no modelo Spotify. Essas formações visam a troca de experiências e conhecimentos. São releituras pouco criativas das Comunidades de Prática, outra ideia elegante, simples e pouco eficaz na promoção de trocas entre times. Essas propostas são fracas para o building porque:

    • seus encontros são esporádicos (os ciclos de feedback são longos);
    • geralmente envolvem muita gente (12+ é muita gente);
    • têm sérias restrições de tempo;
    • favorecem temas amplos visando atender o maior número possível de colegas, o que aumenta o risco de papos superficiais e pouco práticos;
    • muitos usam os formatos de palestra, aula ou demonstração. Leia-se: há grande risco de tédio, alienação, papos paralelos etc. 

    Ou seja, essas estruturas são caras, de difícil implantação e com resultados no mínimo duvidosos. Apesar do início promissor, da motivação natural que vem das coisas novas, esses grupos tendem ao esvaziamento em poucos meses. O building pede por desenhos mais criativos e ambiciosos.

    Desenhando o Intercâmbio entre Times

    Uma das receitas mais enxutas e promissoras é o Pareamento Promíscuo³ ou Pareamento Cruzado. É simples pra chuchu.

    Ingrediente: Um par, sendo cada membro de um time diferente

    Modo de uso

    1. A dupla se encontra diariamente
    2. O encontro dura entre uma e duas horas
      (Claro, a dupla tem autonomia para definir o melhor momento)
    3. A cada dia ou semana eles atuam em um dos dois projetos
    4. Eles paream, ou seja, trabalham juntos em uma mesma história ou item do backlog
    5. Este casamento deve durar pelo menos um mês. E não mais do que dois ou três meses, dependendo da complexidade dos domínios envolvidos.

    O trabalho em pares, uma prática essencial da XP (eXtreme Programming), não é uma exclusividade dos desenvolvedores. Designers, analistas e zagueiros também podem trabalhar em duplas. Por que não? Como não?

    Preciso me distanciar da ideia para fazer uma avaliação mais isenta. Porque, neste momento, vejo só benefícios: o potencial do olhar de fora para descobrir novas possibilidades; o refresco da troca de contexto; a possibilidade de trabalhar em outro domínio e/ou com outras tecnologias e ferramentas; além, claro, da intenção original da polinização cruzada. Tudo isso a custo zero? Pois é, parece bom demais para ser verdade. O que estou ignorando?

    Uma estrutura tão promissora e rica mas não tão econômica quanto a sugerida acima é o Time Plugin4.

    Ingredientes

    • O time Plugin formado por 2+ profissionais que não estejam alocados em nenhum projeto específico.
    • Se envolver um processo de onboarding, então os integrantes do Plugin são um tutor (coach não, tutor! – alguém que senta, ensina pareando e entrega) e pelo menos um novato (na organização, não necessariamente na profissão)
    • Um time hospedeiro. A equipe ideal deve ter pelo menos uma das seguintes características:
      – Um ou mais membros prestes a sair do time em caráter temporário (férias ou licença programada) ou permanente
      – Código relativamente antigo (2+ anos)
      – Um cliente que há tempo (12+ meses) só demanda mais do mesmo

    Modo de Uso

    1. Conecte o time Plugin ao time hospedeiro
    2. O acoplamento deve ser muito suave. Leia-se: os hábitos e rotinas do time hospedeiro não devem ser alterados
    3. O time Plugin pode ou não participar das cerimônias (dailys, retros, reviews etc). A palavra final é do time hospedeiro ou de seu cliente
    4. Se o objetivo é uma substituição, então
    5. Após 15~30 dias de conexão, espera-se que o membro novato tenha condições de assumir uma posição, qualquer posição, no time principal
    6. Isso é possível porque o novato realmente trabalhou naquele projeto, orientado inicialmente pelo tutor e depois por membros do time principal com quem pareou
    7. No início da conexão, pelo menos por duas semanas, é indicado que o novato atue exclusivamente em refatoração. Depois, oportunamente, ele pode se aventurar em itens novos ou até mesmo participando de alguns experimentos (spikes).

    Casos de Uso

    Um time plugin pode oferecer diversas funcionalidades para uma organização:

    • Cobertura de férias e licenças.
    • Substituição permanente de membros.
    • Área de onboarding: região segura onde um novo colaborador pode ser acomodado para entender o que é trabalhar naquela organização (cultura, métodos, ferramentas etc). Neste caso, a estrutura deve ser plugada nos diversos times existentes. Recomenda-se conexões com duração mínima de uma semana. Claro, desde que isso não resulte em meses e meses de onboarding.
    • Refatoração Oportunista: todas as refatorações são oportunistas de alguma forma. Aqui a intenção parece ser outra: a cobertura de férias, por exemplo. A usamos como desculpa para dar um belo tapa (por 15 ou 30 dias!) no código. O cliente fica duplamente agradecido: pela manutenção da estrutura do time e pelo código que ganhou um banho de loja a custo zero.
    • Spikes Interesseiros: há tempo o cliente não desafia o time principal. O relacionamento caiu na rotina. Há o risco do cliente cancelar ou pedir pela redução do contrato. É chegada a hora do código vendedor. Que o time plugin faça pesquisas e experimentos (spikes) na esperança de descobrir novas oportunidades de negócio para aquele cliente. Esta proatividade tende a render, no mínimo, uma boa surpresa e ótima impressão. 

    Quanto maior a rotatividade no time plugin, maior o nível de building alcançado. Quanto ele custa? Cerca de 10% de sua folha de pagamento atual, se houver a intenção de cobrir férias. Não é uma estrutura barata. Por isso é importante que ela seja rica em termos de funcionalidades oferecidas. 

    Nada impede que você mantenha as guildas e capítulos enquanto testa as duas sugestões acima. Não há conflito. E você ganha a possibilidade de fazer uma comparação mais objetiva dos benefícios e custos de cada estrutura. Se você o fizer, por favor, não deixe de compartilhar. Os desenhos sugeridos acima foram testados em apenas uma organização. Há outras referências (veja notas abaixo), mas nada substitui a validação no mundo real, com times de verdade. Se você quer conversar mais sobre as ideias e não gosta do formato assíncrono, considere a participação em uma edição da aula sobre Grandes TIMES Pequenos. Se pretende colocar as ideias para rodar e quer alguma orientação, conte comigo.

    Notas

    1. Um mal muito bem documentado em The Silo Effect, de Gillian Tett (Simon & Schuster, 2016).
    2. Bonding (coesão entre membros de um time), Building (desenvolvimento de parcerias com outros times) e Believing (confiança na organização) são os três tipos de Capital Social apresentados por Robert Bruce Shaw em Extreme Teams (Amacom, 2017). A matriz sugerida acima não é de Shaw. Sua elaboração é possível através de pesquisas internas. O building pode ser capturado através de duas perguntas: 1) Com que frequência você aprende coisas com outros times; e 2) Com que frequência você tem a oportunidade de ensinar coisas para membros de outros times.
    3. Na versão original, citada por Scott Ambler em Beautiful Teams (O’Reilly, 2009), a promiscuidade é total: os casais são trocados todo santo dia. A diferença é que todos atuam no mesmo produto / projeto. Na versão aqui sugerida os participantes são necessariamente de times diferentes. E o par não é trocado diariamente. Caso contrário, não há building. A versão aqui apresentada recebeu colaborações inestimáveis de Altieres Lopes, Will Marcondes, Klaus Wuestefeld e grande elenco.
    4. Pode ser confundido com os times capacitadores (enabling) propostos por Matthew Skelton e Manuel Pais em Team Topologies (IT Revolution Press, 2019). A versão aqui sugerida é um tanto mais ambiciosa em termos de funcionalidades oferecidas.
    5. Foto de Karim Ghantous no Unsplash

  • 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.

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

  • Rendiconti: A Morte do Patinho Feio, a Gripe Terremoto e outras novas

    Várias novas. Tanto que precisarei d’outro post para apresentá-las por inteiro. Mas antes, nossa tradicional prestação de contas. Aconteceu na última quinta (24/abr), a 2ª turma da oficina “Análise e Modelagem de Negócios” em Sampa. É o meu “patinho feio”. Explico: ao contrário de sua co-irmã, a oficina “Engenharia de Requisitos”, esta não está sexy o suficiente – não é atraente. Tanto que o público foi “só” 1/3 da média apresentada pelo outra. Sigo sem entender (“elas são indissociáveis!”, é meu choro frequente), mas não insistirei no modelo. Teimosia tem limite. Senão vira burrice, hehe. Mas falarei sobre as mudanças depois.

    Turma pequena é turma privilegiada. Posso atender todo mundo de uma forma mais frequente e pessoal. As interações tendem a ser um pouco mais ricas. E que sorte tivemos neste último evento! Experiências com Aris; AN’s (Analistas de Negócios) de uma grande empresa que utiliza XP (eXtreme Programming) como seu principal processo de desenvolvimento (!); um “Dino Coboleiro” (em suas próprias palavras); e, pela segunda vez, uma profissional de marketing interessadíssima na matéria; quatro participantes já haviam participado da outra oficina, o que também enriquece o evento – dois são professores (!); três pessoas foram de Curitiba exclusivamente para o evento; empresas importadoras e pequenas e médias empresas que desenvolvem sistemas. Ou seja, a turma era pequena mas eclética, variada, rica. O evento ganha muito com a diversidade – podemos conversar sobre vários modelos de negócios, estratégias, processos, problemas e oportunidades. Tanto que eu não via a hora de publicar esta “rendiconti”. Tanto que nem esperei pelas fotos. Quando elas aparecerem, publico aqui.

    Pelo resumo das avaliações que recebi, posso concluir que todos gostaram muito do evento. Mesmo assim, recebi 3 belos “puxões de orelha”. Vou aproveitar este espaço para comentá-los e, quando for o caso, rebatê-los.

    Aris

    O Aris vem no SAP R/3; é uma “linguagem” madura; “todo mundo usa”; “o usuário não precisa de treinamento para entendê-la”; “você não pode ignorá-la”. Pois bem, é a primeira vez que alguém me cobra isso. O que, definitivamente, torna o “todo mundo usa” um exagero. Quando iniciei este trabalho, há mais de um ano, naveguei brevemente pelo “mundo Aris”. O ignorei por completo por um simples motivo: meu trabalho simplesmente não cita nada que não seja um padrão aberto. Mesmo que a tentação (e as justificativas acima) sejam muito fortes, não cometerei o pecado de amarrar os conceitos e práticas que apresento em uma tecnologia ou ferramenta proprietária. Seria um suicídio. No mais, trata-se apenas de outra linguagem, assim como BPMN e a EPBE (UML) que apresento. Assim como eu falo sobre UML, deve ser fácil aprendê-la em um treinamento de 4 horas, mais ou menos.

    UML (e a extensão EPBE) seguirão no núcleo de meu trabalho sobre análise e modelagem de negócios. Mas vou considerar seriamente a inserção de um capítulo sobre outras notações. Mais que isso, deixarei em aberto a possibilidade de uma versão deste evento que utilize o Aris ao invés de EPBE. Mais sobre as extensões do programa FAN (Formação de Analistas de Negócios) abaixo e em futuros artigos.

    Inovação

    Veio do mesmo (simpático) crítico que sugeriu Aris: “esperava algo novo”. Ele falava especificamente da parte onde mostro a elaboração de um balanced scorecard (BSC) em EPBE. Juro, sigo achando que isso é novo! E me esqueci de perguntar se isso seria possível em Aris. Agora, se ele esperava uma alternativa ao BSC, acho que seguirei devendo por um bom tempo. Não vi surgir nada – com exceção do irmão do BSC, o Mapa Estratégico – que represente melhor a estratégia de uma empresa. Sério – não vejo nada no horizonte. Posso estar enganado. Mas, como não foi colocado nada no lugar, seguirei com minhas sugestões.

    XisPê

    A dupla (de AN’s) de uma grande empresa nos mostrou como eles trabalham com XP (ou XisPê ou eXtreme Programming). Foi muito legal. Usam stories (e não casos de uso); pair programming; TDD (Test-Driven Development); ou seja, todas as práticas fundamentais de XP. Detalhe: exceto uma! São eles que se sentam ao lado dos programadores, não os usuários. Meio na brincadeira (e meio sério), alertei-os que os “radicais” falarão que então não se trata de XP de verdade. Afinal, os “radicais” detestam AN’s! Não importa: estão felizes com o processo e, mais importante, está funcionando! Atenção pessoal que vive sendo cobrado (inclusive por este que aqui rabisca) por casos de sucesso na implantação de XP: taí um belo caso. Com AN’s!

    Gripe Terremoto

    Tive uma reunião logo após a oficina. Quando ela se encerrou, lá pelas nove, o primeiro tremor. Sinto uma gripe chegando de longe. E esta resistiria até a uma dose cavalar (e perigosa) de Resfenol. Só sei que não tem nada a ver com Dengue e afins porque estou quase sem voz, parecendo um poço artesiano e tremendo mais que prédio de Sampa na última terça. Ou seja: trata-se da gripe terremoto. Problemão: tenho vários compromissos na próxima semana. Se a overdose de chás e outros remédios não adiantar, não sei o que vou fazer. Só sei que o final de semana será diferente, com o note na barriga acompanhando meus tremores, hehe..

    Cadê o Cisne?

    Pois é: se o patinho feio se foi, cadê o cisne? Bom, ele precisa de alguns dias para concluir sua metamorfose. O coração do programa não sofrerá alterações, é lógico. Mas a oficina sofrerá grandes alterações, inclusive na forma como é comercializada. Preciso deixar mais nítida a amarração entre “Análise e Modelagem de Negócios” e a “Engenharia de Requisitos”, mesmo que um dos meus requisitos fundamentais seja o “leve acoplamento” dos eventos (ou seja, um não é e não será pré-req para o outro). Complicado, não? Bom, acho que já tenho a solução, e espero apresentá-la em breve.

  • Agile BA Parte III – Criando Caso

    Última parte de uma pequena série que tratou dos problemas da Anne, uma Scrummaster que foi ligeiramente afetada por um curso de Análise de Negócios. Como adiantei na semana passada, vou criar caso questionando algumas estórias.

    .:.

    Como já reclamei aqui em outras ocasiões, nossa área adora reinventar algumas coisas. Começar do zero, ao invés de melhorar algo que já existe. Assim nasceram as User Stories, peça fundamental da metodologia-religião popularmente conhecida como XP (eXtreme Programming). Segundo um de seus apóstolos, as User Stories são formadas por três elementos:

    • Cartão: onde escrevemos as estórias ;
    • Conversas: que nos levariam a entender e detalhar as estórias; e
    • Confirmação: o ‘the end’, o fim da estória.

    A motivação para tamanha invenção gira em torno da palavrinha ‘documentação’ (um dos pecados mortais, segundo aquela doutrina). Por isso outro apóstolo reforça: “os cartões representam os requisitos do cliente, mas não os documentam”. Vai na linha de um mestre-pacificador (mezzo tucano) que vive insistindo: “gente, modelagem não é documentação… modelagem não é documentação… isso é um mito”. Documentação parece um trauma incurável. Mas falarei mais sobre isso em outras oportunidades. A história aqui são as estórias.

    No post anterior eu destaquei um probleminha com o processo adotado pela Anne: “Nós organizamos as cento e poucas estórias por processos de negócios…”. Vai na linha do problema reconhecido por aquele primeiro apóstolo (que escreveu um livro só sobre estórias) : “É difícil saber por onde começar”.

    Se o trabalho começa por uma correta análise do negócio e seus processos, não devem existir dúvidas sobre o ponto de partida. Ao organizar os trabalhos de coleta e análise de requisitos a partir dos processos de negócio, não existe o trabalho de “organização de estórias”. Assim, não há justificativas para adoção do POREM (Post-it-Oriented Requirements Elicitation Method).

    Ironias à parte, o fato é que as user stories, apesar de bem intencionadas, trazem mais problemas (inclusive alguns que não existiam antes) do que soluções. Sua granularidade e a doentia independência dificultam o gerenciamento; Tornam as atividades de priorização e planejamento das iterações bastante confusas. Ou seja, sua utilização em projetos médios e grandes deve ser um pesadelo .

    .:.

    Se começamos do começo, ou seja, pela análise do negócio e seus processos, é mais natural a adoção dos Casos de Uso como técnica para coleta, organização e análise de requisitos. Segundo seu criador , “um caso de uso é o nosso constructo para um processo de negócio”; ” descrevem o negócio e o seu ambiente”.

    A adoção de casos de uso não significa, de maneira alguma, deixar de ser ágil. Aliás, se bem adotada, a técnica deve promover maior agilidade do que as estórias. As 6 qualidades das boas estórias também devem caracterizar os bons casos de uso :

    • Independentes: até o limite onde a independência é desejável, ou seja, até o ponto em que ela não gere surpresas e omissões no projeto;
    • Negociáveis: se o cliente e demais stakeholders não puderem negociar os casos de uso, o que sobra?
    • Valiosos para Usuários e Clientes: óbvio? Nem tanto. Vide o tanto de caso de uso descrevendo CRUD’s e afins por aí.
    • Estimáveis: ok, UCP‘s são frágeis. Tanto quanto todos os outros métodos conhecidos. Mas, independente do método, casos de uso são (ou deveriam ser) estimáveis.
    • Pequenos: não tanto quanto uma história, mas o suficiente para representar uma unidade significativa para o negócio (seja ela uma tarefa, atividade ou processo). Se um caso de uso for grande ou de difícil leitura ele está errado – regrinha básica;
    • Testáveis: wow. Outra regrinha: se não pode ser testado então não é um caso de uso. Deriva de outra regrinha que diz que : “Se um requisito não pode ser testado então ele não é um requisito”.

    Resumo da ópera cômica: sejamos ecologicamente responsáveis: post-its e cartões são feitos de árvores; vamos parar com esse papo de ‘casa de ferreiro… espeto de bambu’ (bambu solta farpas); municiemos nossas equipes e stakeholders com informações consistentes, bem pensadas, analisadas e estruturadas…

    … começando do começo: o Negócio.

    .:.

    Notas:

    1. Não tenho (quase) nada contra XP e afins. Meu problema é só com os fundamentalistas mal educados e donos da verdade suprema. XP e afins foram úteis, representaram um avanço, chacoalharam o status quo. Ou seja, foram um mal necessário.
    2. User Stories Applied: For Agile Software Development
      Mike Cohn. Addison-Wesley (2004).
      Obs: Mesmo autor do artigo sobre UCP referenciado acima.
    3. Lembram-se daqueles livrinhos da Ediouro que sempre traziam uma discussão sobre “estória versus história”? Pois é, me lembrei deles na hora de traduzir stories.
    4. The Power of Stories
      Rachel Davies. XP 2001.
    5. Debunking Modeling Myths
      Scott W. Ambler. Software Development (Agosto/2001).
    6. Deve ser (um pesadelo). Nunca testei e nunca terei coragem para tanto.
    7. The Object Advantage – Business Process Reengineering with Object Technology
      Ivar Jacobson. Addison-Wesley (1995).
    8. Requirements-Led Project Management
      Suzanne e James Robertson. Addison-Wesley (2005).

    .:.

  • Como montar Times e influenciar Projetos

    Série “De Brooks a Berkun” – 2ª Parte

    A experiência prática de Fred Brooks, como citado anteriormente, foi com projetos mastodônticos: 1000 pessoas envolvidas ou mais. Mas ele lembra que desde aquela época os ‘gerentes de programação’ preferiam “pequenos e ‘agudos’ times formados por pessoas de ‘primeira classe’”. Brooks cita um estudo (de Sackman, Erikson e Grant) que mostra que um programador de ‘primeira classe’, que recebia US$20.000/ano, podia ser até 10 vezes mais produtivo que um programador de US$10.000/ano. Mas um pequeno grupo de ‘estrelas’ seria capaz de desenvolver um OS/360? Talvez em 10 ou 25 anos, segundo cálculos do autor. Por outro lado Brooks lembra que times grandes, orientados para a execução de um trabalho na base da ‘força bruta’, são “lentos, caros, ineficientes, e produzem sistemas que não possuem ‘integridade arquitetônica’. OS/360, Exec 8, Scope 6600, Multics, TSS, SAGE, etc. A lista é longa”. E “o dilema é cruel”, escreve Brooks. Haveria solução?

    A sugestão de Brooks, baseada em uma proposta de Harlan Mills , dá título para o terceiro capítulo do seu livro, “O Time Cirúrgico”. Segundo ele, o time ideal é formado por:

    • Programador Chefe (Cirurgião)
    • Co-Piloto
    • Administrador
    • Editor
    • Secretárias (duas)
    • Bibliotecário
    • Almoxarife
    • Testador
    • Advogado (da Linguagem)

    Reparem bem. Nós temos praticamente 9 pessoas trabalhando para o programador! Dando-lhe “todo suporte que fará aumentar sua eficácia e produtividade”. Lembram-se que o Brooks também sugeria que alocássemos apenas 1/6 de nosso cronograma para tarefas de codificação? Outro mundo, não é mesmo? Pode e deve ser factível em um time cirúrgico de verdade mas aplica-se a equipes montadas para o desenvolvimento de sistemas?

    O ‘cirurgião’ seria responsável pela execução de todas as tarefas principais daquela parte do projeto: sua especificação, design, codificação, testes e documentação. Não difere muito de alguns job descriptions e anúncios de vagas que ainda vemos por aí. Seria um “analista-programador” que, segundo Brooks, deveria ter 10 anos de experiência.

    O mundo da programação mudou muito desde os tempos do COBOL e da PL/I. A complexidade e abrangência de nossas linguagens e arquiteturas de aplicações aumentaram ‘para os lados e para baixo’. E é cada vez mais comum que cada uma das tarefas listadas acima seja atribuída a um especialista. Uma divisão que é nítida em ‘fábricas de software’, por exemplo. Em caminho oposto, alguns advogados de métodos ágeis enaltecem a importância de um time formado por ‘generalistas’.

    A analogia com equipes médicas reaparece em um artigo de Peter Drucker publicado pela Harvard Business Review em 1988, “O Advento da Nova Organização” . Segundo Drucker, “informação é dado investido de relevância e propósito. Por conseguinte, a conversão de dados em informação requer conhecimento. E conhecimento, por definição, é especializado. (Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especialização, qualquer que seja seu campo de atuação, exatamente porque sempre se deparam com muito mais a aprender).”

    Apesar de ser simpático aos chamados métodos ágeis, não acredito na possibilidade ou eficácia de um time composto por ‘generalistas’. Prefiro apostar em uma formação que valorize o perfil e a experiência de cada um de seus membros. No diagrama abaixo apresento um exemplo de um time desenhado para desenvolver uma aplicação web (ou ‘cliente/servidor n camadas’, como queiram):

    O arquiteto é o novo ‘cirurgião’. É o dono e principal responsável por aquele projeto ou módulo. Mas só coloca ‘a mão na massa’, codificando, para transferir conhecimentos. Ocupa-se com a concepção e manutenção da integridade arquitetônica da solução. Ele é diretamente apoiado por cinco especialistas:

    • Analista de Negócios (biz): cuida da coleta e organização dos requisitos, e apóia seu desenvolvimento, fazendo a ponte entre os usuários e a equipe de desenvolvimento;
    • Desenvolvedor de Interfaces (front): é especialista em usabilidade e ‘manda bem’ em conceitos de arquitetura de informações. Hoje deve ‘brincar’ com AJAX (Javascript), Flash, HTML, CSS, ASP, JSP, JSF e afins.
    • Desenvolvedor de Serviços (srv): domina orientação a objetos, componentização e, mais recentemente, serviços. É um programador clássico que, como tal, não leva o menor jeito com as ‘frescuras da camada de apresentação’.
    • Arquiteto de Informações (data): uma versão remoçada dos DBA’s (administradores de bancos de dados). Domina o desenho e desenvolvimento de bases tradicionais, transacionais, mas também sabe quando lançar mão de sistemas gerenciadores de conteúdo e bases analíticas.
    • Nosso antigo inimigo (infraestrutura): são os responsáveis por nossos servidores, redes, firewalls e outros brinquedinhos. Tê-los como parte da equipe de projeto desde os primeiros dias é uma prática que, com certeza, minimiza aquele ‘jogo de empurra’ que costuma acontecer um pouco antes ou um pouco depois do delivery da solução.

    Mas… e o coordenador? No próximo sub-capítulo falo especificamente sobre ele e sua convivência com o arquiteto.

    Agora, seguindo com o time cirúrgico proposto por Fred Brooks. O co-piloto que ele sugere é o ‘alter ego’ do cirurgião, capaz de executar qualquer tarefa atribuída à este. A única diferença é que o co-piloto seria menos experiente. Mas, ainda assim, funcionaria como um backup do cirurgião, inclusive representando-o em reuniões com outras equipes. Porém sua principal função é avaliar e discutir as idéias do programador-chefe. Lembra uma das práticas sugeridas pelo método conhecido como eXtreme Programming (XisPê – para os íntimos), a Pair Programming. A prática é polêmica e eu não disponho de dados que confirmem ou não as promessas de produtividade. Quero crer que a qualidade do código gerado realmente seja superior. Mas tenho algumas considerações que, por questão de tempo e espaço, tratarei em outra oportunidade.

    O ‘Administrador’ sugerido por Brooks é um tipo de Coordenador do Projeto. Apesar do cirurgião ter a palavra final em todas as questões, é o administrador que cuida do dia-a-dia da gestão financeira, de pessoal, suprimentos etc. Mais sobre o assunto no sub-capítulo seguinte.

    O ‘Editor’ é o responsável pela documentação. O cirurgião, segundo a proposta de Brooks, gera os documentos principais, tanto técnicos quanto aqueles para os usuários finais. Mas seria o editor o responsável pela compilação final, anexação de referências, bibliografia etc. É um luxo. Porém, ainda hoje brigamos para obter bons documentos de bons programadores, inutilmente.

    O ‘Bibliotecário’ – ‘escriturário’, ou program clerk, como sugerido por Brooks, não faz muito sentido nos dias de hoje. Mas parecia ser crucial nos tempos dos cartões perfurados e das intermináveis listas impressas em formulários contínuos. No entanto eu acredito que toda organização que esteja buscando o reuso de seus ativos de software, ou implantando uma SOA (Arquitetura Orientada a Serviços), demandará a presença de um bibliotecário, um especialista que em outro artigo eu chamei de GBA (Gestor da Biblioteca de Ativos).

    Se prestarmos atenção na complexidade dos atuais ambientes integrados de desenvolvimento (IDE’s – Integrated Development Environment), com seus frameworks, testes automáticos, integração com ferramentas de modelagem etc, veremos que pode fazer sentido o papel do ‘Almoxarife’, ou toolsmith, na nomenclatura original utilizada por Brooks. Um profissional especializado nas ferramentas e na sua adequação para cada tipo de projeto e função. Em equipes grandes ou em ‘fábricas’, parece ser uma função de grande utilidade.

    O ‘Testador’ é o nosso “Engenheiro de Testes”, uma função que aos poucos vai se tornando mais comum. Pena que muitos ainda o confundam com um ‘programador que não deu certo’. Teste é coisa séria, tanto que Brooks, como mostramos na 1ª parte desta série, dedicaria 50% do esforço de um projeto exclusivamente para ele.

    Por fim Brooks sugere a alocação de um ‘Advogado da Linguagem’. Creio que nossos espertíssimos e modernos IDE’s, nossos ‘testadores’ e, lógico, o arquiteto, eliminam a necessidade de um ‘language lawyer’. Advogado não, né?

    continua…

    ===

    1. Mills, H., “Chief Programmer teams, principles, and procedures”, IBM Federal Systems Division Report FSC 71-5108, Gaithersburg, Md., 1971.
    2. Artigo republicado em “Gestão do Conhecimento” (Harvard Business Review on Knowledge Management), Editora Campus, 2001.

  • [SOA # 8] – Processo de Gestão e Desenvolvimento

    Uma implementação SOA não deve significar a adoção de um conjunto totalmente novo de processos e métodos. Principalmente se a empresa contar com uma equipe relativamente estável e um conjunto de melhores práticas comprovadamente eficazes. O processo existente deveria ser customizado de forma a implementar atividades, perfis e produtos específicos de um programa SOA. A principal barreira para a adoção de um processo atual seria o fato deste não prover um ciclo de vida de desenvolvimento que seja iterativo e incremental. Um modelo waterfall, definitivamente, não é adequado para o desenvolvimento de Serviços SOA. Também é desejável que o processo utilizado seja :

    • Cooperativo: aproxime a equipe de projeto com os futuros usuários dos serviços;
    • Direto: o método deve ser de fácil aprendizado e bem documentado;
    • Adaptável: fácil de ser customizado de forma a atender particularidades de determinado projeto;
    • Escalável: de forma que possibilite sua adoção em projetos dos mais variados portes e níveis de complexidade;
    • Orientado pela Arquitetura: ou seja, pressupõe que os produtos dos projetos em desenvolvimento fazem parte de algo maior e devem, conseqüentemente, respeitar os padrões fixados; e
    • Incentivador do Reuso de Ativos: uma conseqüência direta de sua orientação à arquitetura.

    Não há um único processo no mercado que, em seu formato padrão, atenda todos os requisitos listados acima. Os 3 primeiros itens da lista mais as características “iterativo e incremental” configuram o que se chama de um “Processo Ágil”. Porém todos os mais conhecidos são indicados para pequenas equipes ou seja, não escalam. Já processos que atendem os 3 últimos requisitos da lista, como o Rational Unified Process (RUP), raramente são considerados “Cooperativos” ou até mesmo “Diretos”.

    Uma combinação do RUP, Scrum e eXtreme Programming (XP) pode gerar um excelente processo para a gestão e desenvolvimento de Projetos SOA. Abaixo é apresentada uma visão geral deste modelo customizado.

    Visão Geral de um Processo Customizado

    Dos 3 processos listados acima, o RUP é o mais completo. Por isso muitas vezes é tido como excessivamente burocrático e “pesado”. Seus críticos, na maioria das vezes, desconsideram o fato dele ser bastante customizável. O RUP é a base desta sugestão exatamente por sua completitude e adaptabilidade. Geralmente ele é apresentado, em alto nível, da seguinte maneira :


    As disciplinas do RUP mais afetadas em uma customização para atendimento dos requisitos de um processo SOA são:

    • Modelagem de Negócios: que passa a gerar, como principal produto, o Contrato do Serviço que, por sua vez, é a base para elaboração do Backlog do Serviço (Produto, na terminologia Scrum). A captura de indicadores de qualidade e níveis de serviço esperados também merece destaque;
    • Implementação: que deve incorporar algumas práticas XP, particularmente a liberação de produtos em ciclos curtíssimos;
    • Teste: que incorpora testes específicos de uma Arquitetura Orientada a Serviços, como a validação da abrangência das interfaces expostas, potencial de reuso, dentre outros;
    • Implantação: que deve assimilar também todas as atividades de publicação dos Serviços, dentre elas o encapsulamento final dos artefatos e o agendamento da publicação;
    • Gerenciamento do Projeto: que é totalmente trocada pelo método Scrum. Veja mais abaixo.

    Gerenciamento de um Projeto SOA

    Como adiantado no sub-capítulo “Equipes de Projetos” acima, a responsabilidade pelo Gerenciamento de um Projeto SOA é compartilhada pelo Coordenador do Projeto e pelo Dono do Serviço (Product Owner, na terminologia Scrum original). O primeiro cuida de todas disciplinas previstas no PMBoK (Project Management – Body of Knowledge) exceto a “Gestão do Escopo”, que seria de responsabilidade exclusiva do Dono do Serviço*. Mas a adoção do Scrum como método para a gestão de um projeto SOA implica em mudanças ainda mais profundas na rotina de trabalho do coordenador de projetos.

    Sua principal atividade pode ser vista como uma “obsessiva (extrema) gestão de riscos”. Ele deve buscar e eliminar todas as barreiras que estejam impedindo a equipe de atingir seu ponto máximo de performance. O diagrama abaixo expõe uma visão geral do processo Scrum adaptado para o desenvolvimento de projetos SOA:


    Na etapa de Planejamento é compilada a primeira versão do Contrato do Serviço. Em tempo de desenvolvimento é desejável que este contrato seja a principal ferramenta de controle e acompanhamento do projeto. Para tanto ele deve contemplar também :

    • Estimativas de Custos e Prazos para o projeto;
    • Plano de Desenvolvimento e das Iterações (Sprints);
    • Definições de sincronismo com outros projetos;
    • Plano de Testes; e
    • Plano de Publicação.

    O contrato é desenvolvido a partir dos requerimentos coletados pelo Analista de Negócios e de definições prévias oriundas do Comitê Gestor do Programa SOA. O contrato deve respeitar integralmente os Padrões SOA definidos por este comitê nos momentos iniciais do programa. É parte integrante do Contrato um desenho em alto nível da arquitetura do serviço. Por isso ele é elaborado em conjunto pelo Dono do Serviço e pelo Analista de Negócios.

    A negociação final do contrato com as áreas usuárias é conduzida diretamente pelo Dono do Serviço. O processo pode prever uma etapa de revisão de contratos pelo Comitê Gestor, que ocorreria antes da elaboração do Backlog do Serviço. Esse backlog é desenvolvido pelo Dono do Serviço. Sua elaboração é acompanhada pelo Coordenador do Projeto, que pode discutir prioridades e definir a estrutura de divisão de tarefas. É também neste momento que as estimativas de prazos e custos podem ser refinadas, com apoio de integrantes das equipes de desenvolvimento.

    A partir do Backlog do Serviço o Coordenador do Projeto elabora o Backlog do Sprint (Iteração), que é o plano de trabalho da próxima iteração a ser executada. Um sprint, na concepção original do método Scrum, é uma iteração com duração fixa de 30 dias. Apesar dos benefícios da fixação de um prazo comum para todas as iterações de todos projetos, entende-se que em muitos casos tal “regra” pode se tornar uma barreira a ser derrubada pelo Coordenador de Projetos. Um serviço, dependendo de sua granularidade, pode demandar ciclos de duração mais curta. No entanto trata-se de um excelente balizador para projetos mais complexos.

    Um sprint contempla todas as fases tradicionais de um processo de desenvolvimento de sistemas, ou seja: engenharia de requerimentos, análise, modelagem, codificação, testes e liberação. No entanto, é vital que ao término de cada sprint aja uma nova versão do serviço em condições de uso, mesmo que ainda não estejam satisfeitos todos os seus requerimentos fundamentais.

    Como mostrado anteriormente, a construção de um serviço normalmente envolverá o trabalho de dois times distintos: os desenvolvedores dos Frontends das Aplicações e os desenvolvedores dos Serviços propriamente ditos. É crucial que o backlog do Sprint contemple a total sincronização destas duas frentes de trabalho. O gráfico a seguir mostra um zoom de como deve ocorrer o Sprint :


    O processo prevê a realização de scrums diários, breves reuniões que ocorreriam sempre no mesmo local e horário. Nelas o Coordenador afere os progressos obtidos desde o dia anterior, refina a lista de riscos e impedimentos e ajusta o planejamento de atividades do dia. Radical, a proposta original do Scrum sugere que estas reuniões tenham a duração máxima de 15 minutos. O coordenador pode optar por realizar duas reuniões diárias, uma com cada time de desenvolvimento.

    No último dia do sprint realiza-se uma reunião de revisão com a presença do Dono do Serviço, Analista de Negócios e representantes das áreas usuárias. O Coordenador e a equipe de desenvolvimento apresentam as realizações do último sprint. Neste momento o Dono do Serviço e o Coordenador do Projeto revisam o Backlog do Produto, registrando mudanças ou novas solicitações. A partir desta atualização o Coordenador elabora o Backlog do próximo sprint.

    Quando todos os itens do Contrato do Serviço estiverem satisfeitos inicia-se a terceira e última fase do projeto, que na versão original do Scrum é chamada Postgame Phase. Neste momento o Serviço e respectivo Cliente são submetidos ao processo de certificação, que deve garantir a total adequação dos novos artefatos aos Padrões SOA.

    Por fim temos o processo de Publicação, que envolverá o encapsulamento de todos os artefatos gerados e o agendamento da publicação do Serviço.

    Representantes do Comitê Gestor do Programa SOA envolvem-se em três momentos de um projeto:

    • Validando o Contrato elaborado na primeira fase;
    • Acompanhando as Reuniões de Revisão, que no formato padrão ocorrem mensalmente; e
    • Certificando e Publicando a versão final do Serviço.

    O processo Scrum sugere que as equipes de projeto se auto-gerenciem, promovendo a livre interação entre todos os membros. O Coordenador do Projeto, mais que um “controlador”, é um Facilitador. Outra característica marcante do processo é a “blindagem” da equipe, que em seu dia-a-dia fica livre de influências externas. Este desenho valoriza todos os integrantes da equipe e pode representar consideráveis ganhos de produtividade.

    Evolução do Processo

    O Scrum é um modelo organizacional desenhado para a execução de projetos cuja previsibilidade é limitada . Os princípios básicos que levaram ao seu desenvolvimento foram Flexibilidade, Adaptabilidade e Produtividade. A coincidência com os meta-requerimentos fundamentais de uma iniciativa SOA é total. Mas ambas propostas, tanto o Scrum quanto as Arquiteturas Orientadas a Serviços são relativamente recentes. Praticamente não existem referências do uso do Scrum em projetos SOA.

    O trabalho mais recente de Jeff Sutherland descreve a última evolução do Scrum, chamada “Tipo C”. As principais alterações referem-se à adoção de sprints simultâneos e a elaboração de um MetaScrum. Este meta-processo pode ser muito útil na gestão do Programa SOA, como sugerido neste artigo. E a habilidade de gerenciar múltiplos sprints pode ser crucial em uma iniciativa SOA que se encontre em um estágio mais avançado de maturação.

    =================

    3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
    Prentice Hall (PTR) (2005).
    14. “Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects”, Jeff Sutherland
    Artigo (2005)
    16. “Rational Unified Process”, IBM Corp.
    http://www-306.ibm.com/software/awdtools/rup/

    * Na realidade, a versão original do Scrum prevê a existência de um terceiro gestor, não considerado nesta proposta.

  • [SOA # 5] – Processos

    Da mesma forma que SOA não requer nenhuma nova tecnologia, o mesmo vale quando tratamos de processos ou metodologias para gestão de programas e projetos. A corporação pode e deve reaproveitar os processos existentes, principalmente as práticas com benefícios comprovados.

    Mas algumas mudanças podem ser necessárias, visando atender principalmente os meta-requerimentos Agilidade, Flexibilidade e Simplicidade. Um processo burocrático ou resistente a mudanças, como aqueles baseados em modelos waterfall (cascata), é incompatível com tais requisitos. Por outro lado, processos muito “leves” como XP (eXtreme Programming) podem resultar em redundância e retrabalho por não fornecerem uma visão geral da empreitada e por carecerem de atividades gerenciais.

    O equilíbrio entre a agilidade de um processo e robustez de seus mecanismos de administração e controle, alvo de vários estudos e propostas, é crítico para a realização das promessas de uma iniciativa SOA. Por isso trata-se de uma definição que deve ocorrer no âmbito do Programa, logo em seus primeiros momentos.

    Para um processo ser considerado adequado para a implementação de uma SOA ele deve:

    • Promover Agilidade: o que não significa apenas ganho de produtividade dos desenvolvedores. Um processo ágil elimina barreiras e integra atividades visando aumento da qualidade de todos os produtos gerados;
    • Absorver Mudanças: e não combatê-las. Um Serviço em uma SOA deve assimilar e refletir as mudanças que ocorrem em um processo de negócio de forma quase imediata. É vital que o processo saiba tratar tal volatilidade;
    • Respeitar a Arquitetura: ou seja, garantir que todos os participantes de uma iniciativa SOA tenham uma visão do todo, da Arquitetura, seus padrões e princípios;
    • Incentivar o Reuso: valorizando todos os ativos existentes e aqueles produzidos no programa e facilitando sua reutilização e combinação com outros ativos;
    • Facilitar a Comunicação: entre todos os participantes do programa e respectivos projetos e destes com as áreas de negócio.

    ===============

    Gestão do Portfólio de Serviços

    Uma das responsabilidades mais críticas do Comitê Gestor SOA é a administração do portfólio de serviços. A garantia do alinhamento do programa com as estratégias da organização e da satisfação de seus requerimentos são realizadas através de uma correta gestão do portfólio de serviços. Existem no mercado várias ferramentas que apóiam tal atividade, normalmente direcionadas para o acompanhamento de vários projetos. Elas podem ser adaptadas para o gerenciamento de um programa SOA.

    Os idealizadores da ferramenta Balanced Scorecard, Robert Kaplan e David Norton, lançaram recentemente um novo conceito que pode agregar considerável valor à gestão de um programa SOA. É o Mapa Estratégico , que “é a representação visual da estratégia de uma empresa. Sua principal finalidade é demonstrar a Prontidão de determinado ativo intangível para atendimento dos processos internos críticos: gestão de operações, gestão de clientes, inovação e processos regulatórios e sociais. Ele se torna uma visão consolidada das quatro perspectivas do Balanced Scorecard (Financeira, do Cliente, dos Processos Internos e de Aprendizado e Crescimento). Os ativos intangíveis foram estruturados em 3 grandes grupos: Capital Humano, Capital Organizacional e Capital da Informação. De acordo com os estudos conduzidos pelos autores e parceiros ao redor do globo, para o chamado Capital da Informação, o grande objetivo das empresas é a ‘disponibilidade de sistemas de informação, de infra-estrutura e de aplicativos de gestão do conhecimento necessários para suportar a estratégia’” .

    A relativa simplicidade desta ferramenta e a clareza com a qual demonstra as estratégias corporativas e sua relação de dependência com ativos de TI, o Capital da Informação, a tornam bastante adequada para a gestão, em alto nível, do portfólio de serviços. Como um serviço em uma SOA é a representação direta de um processo ou atividade de negócio, a comunicação do comitê gestor SOA com as áreas de negócio é bastante facilitada pelos mapas estratégicos.

    No entanto, serão necessárias várias alterações no formato original da ferramenta. Os ativos de TI são apresentados na obra em 4 grandes grupos: Sistemas Transacionais, Aplicações Analíticas, Aplicações Transformacionais e Infra-Estrutura de Tecnologia. Tal classificação deve ser trocada pelos 4 tipos de serviços (Básicos, Intermediários, Processos e Públicos) mais o Frontend das Aplicações e a Infra-Estrutura tecnológica.

    Uma nova dimensão deve ser criada para indicar a relevância estratégica de determinado serviço. Esta alteração também deveria afetar o modelo original, de forma a possibilitar que sistemas transacionais ou analíticos também possam ser classificados como “Transformacionais”, ou seja, como sistemas que alteram drasticamente um ou mais processos de negócios.

    Outra mudança necessária é na escala de avaliação da prontidão dos ativos. O estudo original apresenta seis níveis de prontidão :

    1. OK. Ativo atende plenamente os requisitos do negócio
    2. Leves Melhorias são necessárias
    3. Novos desenvolvimentos a caminho
    4. Novos desenvolvimentos atrasados
    5. Grandes Melhorias necessárias
    6. Nova Aplicação necessária

    A nova escala deveria refletir o ciclo de vida dos serviços, o que a deixaria da seguinte forma :

    1. Publicado: em Produção;
    2. Classificado: alocado na arquitetura e agendado para publicação;
    3. Certificado: aprovado nos testes de qualidade. Atende todos os requisitos especificados no Contrato do Serviço;
    4. Submetido: em processo de Certificação;
    5. Em Desenvolvimento;
    6. Identificado / Especificado: serviço já foi identificado e modelado – encontra-se na fila para início de sua construção.

    Deve-se lembrar que a principal utilidade desta ferramenta é a comunicação com o corpo diretivo da empresa. Daí a relativa superficialidade da escala de avaliação do grau de prontidão dos serviços. No entanto nada impede que extensões sejam desenvolvidas de forma a enriquecer o relatório e municiar os processos de tomada de decisão do comitê gestor SOA. As alterações mais desejadas talvez sejam aquelas que propiciem:

    • Visibilidade dos prazos de transição entre as etapas do ciclo de vida dos serviços;
    • Opções de aquisição ou desenvolvimento do serviço (compra no mercado, desenvolvimento interno, desenvolvimento terceirizado ou utilização de ativo livre e aberto disponível na Internet); e
    • Estimativas de custos de cada serviço.

    >>>>>>>>>> SOA #6 – MDA (Model Driven Architecture)

    4. “Practical Software Reuse”, Michel Ezran, Maurizio Morisio e Colin Tully
    Springer (2002).
    5. “Gestão Estratégica de Ativos e Portfólios de Projetos de TI”, Paulo F. Vasconcellos
    Artigo publicado em Out/2004.
    6. “Mapas Estratégicos”, Robert S. Kaplan e David P. Norton
    Editora Campus / Elsevier (2004).