finito

Tag: Scott Ambler

  • 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

  • Repensando o Papel do Analista de Negócios

    Mas já? Pois é, como o papel do Analista de Negócios (AN) ainda é relativamente mal definido, não faria mais sentido “pensá-lo”? Acontece que, apesar das incertezas, não estamos falando de nada novo. Li em algum lugar (perdão.. faltará o link-lembrança) que nos EUA já existem mais de 600 mil AN’s! Não tenho como validar o número. Me limito a confrontá-lo com o número de AN’s certificados pelo IIBA: 70. Isso mesmo, só setenta! Mas quem propõe a revisão é Scott Ambler, que participou da revisão da versão 1.6 do BABoK. Entre o pensar e o repensar, vou aproveitar a oportunidade para comentar o artigo do Scott Ambler.

    Para começar, a forma muito legal que o Ambler apresenta o AN:

    Na teoria, a idéia de ter AN’s tradicionais envolvidos em um projeto deve funcionar muito bem, e na prática isso frequentemente acontece. Os melhores analistas são organizados e grandes comunicadores, têm a habilidade de destacar as informações críticas fornecidas pelos stakeholders do meio de toda aquela “poluição informativa” – lançando mão de várias técnicas de modelagem. Para muitas organizações a adição de AN’s claramente aumentou a qualidade dos requisitos e modelos. E também abriu um canal de comunicação entre os “tech weenies” de TI e os “business morons” para os quais o sistema é construído.

    Jóia né? Mas aí apareceram os “poréns”. Comento abaixo cada um deles, na seqüência original:

    1. AN’s não apresentam as habilidades corretas
      pv: Natural, afinal ainda não temos um mínimo ‘corpo de conhecimentos’ consolidado. Como já escrevi antes, considero o BABoK incompleto. Se não há consenso acerca da formação e habilidades requeridas em um AN, como exigir que eles as apresentem?
      AN’s são uma derivação não programada dos Analistas de Sistemas, que por sua vez substituíram (sem querer) os Analistas de Organizações e Métodos (O&M). No entanto, os AN’s não vieram para substituir os Analistas de Sistemas. São um tipo de contraponto aos “analistas-programadores”. Voltam seus olhos para o domínio do problema, enquanto aqueles tratam do domínio da solução.
    2. AN’s podem ter uma influência muito negativa no projeto
      pv: Todo mundo pode, né? Mas, falando sério: insisto que um bom AN tem uma postura pró-ativa. Então, ele deve criticar requisitos. Porém, não deve nunca recusá-los sem consultar os stakeholders. Outra preocupação do Ambler me pareceu descabida: a influência do AN na arquitetura? Oras, ele não desenha a solução. Acho o risco mínimo, se é que ele existe. Já a última parte do alerta é sério: AN’s que não funcionam como canais, mas sim como uma “parede” entre os usuários e os desenvolvedores. O AN facilita o processo de comunicação, mas nunca impede o contato direto. Por exemplo, quando ele organiza e facilita um workshop, desenvolvedores e usuários estão em contato direto.
    3. AN’s podem ficar desatualizados
      pv: Sim, todo mundo fica. Mas o foco do Ambler nesta questão é um tanto estranha: parece que ele considera que todo AN foi um dia um desenvolvedor. Nada mais errado. Um AN pode ter uma formação 90% em negócios, ser formado em administração ou economia, por exemplo. Naquele grande banco que citei em um post anterior, tem gente de Letras! Por outro lado, não vejo problemas em um desenvolvedor se tornar um AN. É tudo uma questão de gosto. E jeito… muito jeito.
    4. AN’s podem ser uma barreira para a comunicação
      pv: Sim, como colocado no tópico 2 acima. Típica situação perde-perde-perde em um projeto. Perdem os usuários, desenvolvedores e os próprios analistas. Infelizmente é mais comum do que a gente imagina. E, tão nociva quanto a barreira, é a “tradução livre”. Explico: o AN começa a contar apenas “boas notícias” para ambos os lados. Por isso a comunicação aberta e o contato frequente entre todos os stakeholders é fundamental para o sucesso dos projetos.
    5. AN’s podem reduzir a influência dos stakeholders
      pv: Sim, mas nem sempre isso é uma coisa negativa. Se ele filtrar as influências negativas, permitindo que a equipe performe, ele estará realizando seu trabalho. Mas é o tipo de ação que deve estar sincronizada com o coordenador do projeto e com a equipe. Se bem combinado, o AN se torna uma espécie de “firewall” para a equipe.
    6. AN’s analisam MUITO
      pv: Até que essa apareceu tarde na lista. É o tal do BDUF (big design up-front). Ou o temor da “analysis-paralysis“. Simplificando: se o AN for jogado em um processo baseado no ciclo “cascata” (waterfall), o risco é real e imediato. Se o processo for iterativo e incremental (de verdade), o risco não existe.
      Aqui cabe um detalhe interessante (e uma brincadeirinha): o AN é o cara que mais trabalha no projeto. Veja o gráfico abaixo . Se ele resolver executar seu trampo “numa tacada só”, só ele vai trabalhar e o projeto se encerrará com uma série de documentos, descrições de casos de uso e protótipos. Ao distribuir suas atividades* entre as diversas etapas e iterações de um projeto, o AN faz bem seu trampo e permite que todos trabalhem.
      * São atividades de um AN: B (Business Modeling), R (Requirements), uma bela fatia do T (Tests) e uma fatiazinha do C (Change Management).

    7. AN’s reduzem o feedback
      pv: Pouco provável, se o AN acompanhar todo o ciclo de desenvolvimento, guiando particularmente os testes e as entregas intermediárias. Ambler insiste nos problemas de comunicação, de certa forma factíveis. Afinal, o AN é outro nó na rede de comunicações. Ou, como diz Karl Wiegers , um cara entre a voz do usuário e os ouvidos do desenvolvedor. Se, ao invés de facilitar as comunicações, o AN emperrá-las, não estará fazendo seu trabalho.
    8. AN’s reduzem as oportunidades para os desenvolvedores melhorarem suas habilidades de comunicação
      pv: Uau.. eu nunca tinha pensado nisso. O Ambler realmente não consegue “tirar o pé da jaca”. Ou, colocando d’uma forma menos agressiva: “não tira o boné de jeito nenhum”. Como eu disse acima, o AN não impede o contato direto dos desenvolvedores com usuários e demais stakeholders. Reduz o número de contatos, é certo. Mas é para o bem do projeto. Prefiro ver de outra forma: os desenvolvedores podem exercitar bem suas habilidades de comunicação (e pugilismo) com os AN’s. E aprender muito com os bons AN’s.
    .:.

    Notas:

    1. Agility and Discipline made Easy: Practices from OpenUP and RUP
      Per Kroll e Bruce MacIsaac. Addison-Wesley (2006).
    2. More About Software Requirements
      Karl Wiegers. Microsoft Press (2006).

    .:.

  • (Requisitos) Levanta aí que eu Coleto daqui

    Seqüência de “Tácitos & Explícitos“.

    Neste artigo vou tratar especificamente das formas como coletamos, descobrimos, inventamos e entendemos requisitos. Karl Wiegers, em “More About Software Requirements” , faz um importante alerta sobre a forma como chamamos esta atividade em um projeto de software. O termo coletar, segundo Wiegers, é enganoso. Nos leva a entender que os requisitos estão lá, estáticos, esperando a hora da colheita. Por isso falei que “coletamos, descobrimos, inventamos e entendemos”. Espero ter passado a correta amplitude do trabalho.

    No post de ontem falei que temos dois grandes grupos de técnicas de aprendizado: a Socialização (interação pessoal) e a Internalização (interação com documentos dos mais diversos tipos). Vamos estruturar as técnicas de levantamento (e descoberta, invenção…) de requisitos nestes dois grupos. Veja o gráfico abaixo :


    As técnicas de socialização, ou seja, aquelas que empregamos para a absorção e troca de conhecimento tácito, são as seguintes: Workshops / JAD, Entrevistas, Observações e Brainstorming. Coloquei o “Fone” ali só para fins ilustrativos (e para possibilitar outro nível de comparação). Cabe uma breve descrição sobre cada técnica:

    • Workshops / JAD: reunião com um número relativamente grande de participantes. É um evento estruturado, possui agenda, duração e temas pré-definidos.
      Um Analista de Negócios (AN) pode ser alocado para planejar e organizar o evento, além de funcionar como um facilitador durante a sua execução. Neste caso é importante que exista outra pessoa (outro AN), registrando as discussões e decisões.
    • Entrevistas: igualmente estruturado (ou seja, com agenda e pauta pré-determinados), é executado com um número menor de pessoas. Sua vantagem em relação aos workshops é uma certa facilidade em se manter o foco das discussões. Mas a falta de pontos de vista divergentes pode ser um fator negativo.
      Novamente o cenário ideal exige a presença de dois AN’s, um conduzindo a reunião e outro registrando os achados.
    • Observações: técnica particularmente importante quando executamos a análise e modelagem do negócio e seus processos. Existem duas variações principais: i) Ativa, quando o AN executa as tarefas de um usuário; e ii) Passiva, quando o AN se limita a observar o trabalho do(s) usuário(s).
    • Brainstorming: polêmica técnica que pode ser útil quando o projeto exigir criatividade, inovação. É complicada sua condução porque não há uma pauta pré-definida. O AN deve cuidar para que as idéias fluam sem nenhum tipo de interferência ou crítica. Sua eficácia depende muito do perfil e do humor dos participantes.

    Todas as técnicas de socialização aparecem no quadrante de alta eficácia e riqueza. Os “agilistas” não erram quando dizem que nada substitui o “tête-à tête”. Um bom AN não se limita, em todos esses eventos, a registrar as conversas. Sinais, gestos e expressões podem ser muito relevantes também. O “mapeamento psicológico e sociológico” dos stakeholders também pode ser executado, de forma implícita e nada intrusiva. Para a execução e condução de todas as técnicas acima exige-se do AN grandes habilidades “sociais” (soft skills): comunicação, negociação, intermediação, e por aí vai.

    Ao contrário das técnicas de internalização, que exigem habilidades bastante distintas. São elas: Código Fonte, Código Executável, Pesquisa e Documentação. O “Email” aparece no gráfico acima apenas para fins de ilustração. Vamos entender um pouco mais sobre cada uma delas:

    • Engenharia Reversa: aparece na figura acima em três formatos, já que cada um deles possui uma classificação diferente.
      Código Fonte: sua análise é a mais rica de todas, já que permite um diagnóstico completo de um dado sistema. Também conhecida como “análise Caixa-Branca”. Dependendo da formação do AN, ele não terá condições de executar este tipo de análise. Dependerá de desenvolvedores.
      Código Executável: ou “análise Caixa-Preta”, mais factível de execução por um AN. Ele usa a aplicação e extrai idéias (casos de uso e requisitos).
      Documentação: deveria figurar em um lugar mais nobre no gráfico. Mas todos sabemos que muito raramente encontramos uma documentação boa (quando encontramos alguma documentação! Atualizada então…)
    • Pesquisas: podem envolver algum tipo de socialização mas, neste caso, entrariam como uma variação dos “workshops” (acima). Estamos tratando aqui de pesquisas onde não há um contato pessoal. As pesquisas são muito úteis quando o usuário não é conhecido ou o número de usuários é grande demais. Existem dois grandes modelos:
      Questionários: pesquisas normais, onde uma população amostral é previamente selecionada. Os questionários podem ser abertos ou fechados (múltipla escolha). Podem nortear o desenvolvimento de um novo produto ou serviço.
      Versões de Testes: ou o “processo Google” de validação, com suas quase eternas versões “beta”. Um produto ou serviço, em versão de testes (ou protótipo), é disponibilizado para um grupo de pessoas pré-selecionado. Suas observações (na maioria voluntárias) são requisitos que devem ser coletados e analisados pela equipe.

    Quero crer que assim ficou clara a diferença entre conhecimento tácito e explícito, e como ambos podem ser importantes em um projeto de software (ou de qualquer natureza). Como eu disse anteriormente, a ênfase no conhecimento tácito (conforme interpretada e proposta por alguns “agilistas”) gera um certo tipo de miopia no projeto.

    Um AN “completo” desenvolve habilidades para selecionar e aplicar as melhores técnicas para cada tipo de projeto. Primeira habilidade obrigatória: humildade para reconhecer determinada limitação e pedir ajuda.

    .:.

    Notas:

    1. More About Software Requirements
      Karl E. Wiegers. Microsoft Press (2006).
    2. Gráfico foi inspirado neste, extraído de
      The Enterprise Unified Process: Extending the Rational Unified Process
      Scott Ambler, John Nalbone e Michael J. Vizdos. Prentice-Hall (2005).
    .:.

  • Help Wanted: Especialistas Generalistas

    Perdão. Não, o finito não está contratando ‘especialistas generalistas’. O help necessário é outro. Preciso de ajuda na definição do termo. Queria entender as certezas que aparecem com certa freqüência em algumas listas de discussão e artigos. Normalmente o pessoal cita um artigo do Scott Ambler. Ele fala em ‘Generalizing Specialists’. Tropicalizado, o termo virou ‘Especialistas Generalistas’. Só a ausência do gerúndio já me deixa encucado. Mas o problema não está só na tradução não. Começa no próprio artigo do Mr Ambler. Ele cita Robert A. Heinlein, um escritor de ficção científica:

    A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

    “Especialização é para insetos!”. O romântico manifesto de Heinlein, em mãos erradas, pode causar um estrago e tanto. Vou surrupiar a réplica de alguém que não tem nada a ver com sci-fi, Peter Drucker :

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

    A organização baseada em informações exige, em geral, muito mais especialistas do que as empresas tradicionais do tipo comando e controle.

    Mixando os dois autores podemos concluir que as empresas baseadas em informações são verdadeiras colméias ou formigueiros, certo? A analogia é interessante, mas não vou brincar com metáforas. Como eu disse em um rendiconti, meu problema é com os ‘especialistas generalistas’. Lá eu disse que um melhor termo seria ‘especialistas não-alienados’: i) Profissionais que reconhecem e respeitam as outras especializações; ii) estão comprometidos com os objetivos do negócio (do projeto); e iii) sabem trabalhar em equipe. Acho que isso não deveria ser um diferencial – em lugar nenhum. É pré-req em qualquer profissão, não?

    Mas a tese de Mr Ambler vai um pouco além. Para ele, ‘reconhecer’ as outras especializações é conhecê-las de fato. Ele chega a sugerir a seguinte trilha de evolução (é só um exemplo fictício, ele diz):

    Não tenho nada contra um profissional buscar outras áreas de conhecimento. Muito pelo contrário. Mas a evolução acima é possível? Se Java, .Net, tecnologias de bancos de dados, metodologias de gerenciamento de projetos e de modelagem fossem congeladas – parassem de mudar e de evoluir, talvez. Mas, definitivamente, não é esse o caso. Alguém que tenha parado de estudar Java há 3 anos seria considerado um especialista hoje? Algumas das áreas de conhecimento citadas por Ambler se entrelaçam. É natural que o especialista em uma delas seja também muito bom em outra. Java e modelagem, por exemplo. Aliás, dependendo da ferramenta, trata-se de uma tarefa só. Um melhor exemplo talvez seja Java e testes, ou Java e deployment. Btw, neste último quesito, muita gente fica devendo. Mas essa é outra história.

    O maior problema com a tese, em minha opinião, é a forma como ela desconsidera a dinâmica que vivemos. Alguém que tenha aprendido Cobol lá nos anos 80 até que poderia se dar bem hoje, com um mínimo de esforço de atualização. Podemos dizer o mesmo em relação ao VB ou Java, por exemplo?

    O fato é que, para ser um especialista hoje em dia, gasta-se muito tempo. As plataformas tecnológicas cresceram muito, para os lados e para cima. A complexidade dos ambientes aumentou exponencialmente. E, pior, ainda são relativamente imaturas. Ou seja, mesmo que o cara não durma e seja um mestre em ‘leitura dinâmica’, é difícil se manter um especialista. O que dizer então de um ‘especialista generalista’ conforme proposto por Ambler? Só se ele já estiver contemplando o uso de um plug como o do Neo em Matrix.

    .:.

    O post ficou longo e, como eu previa, receberá uma seqüência. Quero colocar a questão dos ‘especialistas generalistas’ no contexto dos projetos. Tirando o lado individual, que procurei destacar aqui, trata-se do maior risco. Equipes multi-disciplinares viraram, em alguns lugares, equipes de profissionais multi-disciplinares.

    Sei que a maior parte dos colegas defensores da tese do Ambler são muito bem intencionados. Juan Bernabó, por exemplo, apresenta-a de uma forma muito legal. Mas, infelizmente, não consigo ignorar um tom meio ‘facista’ de alguns. Me desculpem o termo – mas é assim que interpreto. Quando falam de ‘super-desenvolvedores’ que sabem fazer tudo no projeto, e ainda se auto-gerenciam… Sei lá, parece que querem dizer: “o mundo é nosso”. Aliás, achar que dá para ser bom demais em tudo é uma baita falta de respeito com outros especialistas. Mas esse papo fica para a próxima semana.

    .:.

    1. O Advento da Nova Organização
      Peter F. Drucker. Artigo publicado originalmente na edição de jan-fev/88 da Harvard Business Review. Republicado no livro “Gestão do Conhecimento – HBR”, da Editora Campus (2001).

    .:.