PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • Lutas Vãs

    Bela coincidência, me deparar com um artigo na Folha de hoje que cita o mineiro Drummond: “Lutar com as palavras é a luta mais vã”. Meu artigo de ontem parece proclamar essa briga sem sentido. Porque teimou nos termos e definições em detrimento de algo mais concreto e prático. E isso parece me distanciar daquilo que mais busco, das conversas. Na manhã de hoje respondia a um email com meia dúzia de dúvidas práticas. E fulminantemente irritantes. Não pela pessoa que perguntava, mas pela recorrência das questões. São as mesmas perguntas que tento responder desde a primeira edição do {FAN}, no distante junho de 2007. Era o artigo de ontem, pretensão ingênua, se confrontando com a realidade de hoje, uma âncora terrível.

    Mas não desfilarei mais um chororô não, pelo contrário. Utilizarei o caso para justificar as provocações que fiz. Recolocarei as dúvidas que recebi, sem nenhum tipo de edição:

    • Qual é a posição que ele deve tomar em relação aos suportes / análise de sistemas que ele detém, e atividades que deveriam ser executadas de negócio.
    • Como analista de negócio, sendo da área de Ti, e sempre em contato com os stackholders, como ele deverá agir, pois acaba virando referência para problemas de TI (suporte, retorno de atendimentos e outros problemas relacionados a TI)
    • De quem é a responsabilidade de analisar uma rotina que deverá ser implementada num sistema já em produção?
    • Qual artefato deverá ser gerado pelo analista de negócio para a equipe de desenvolvimento.
    • Como o Analista de Negócio, poderá interferir numa solução de sistemas, se a equipe de desenvolvimento desenha uma solução, que segundo eles será melhor para o usuário final.

    Minha resposta, para todas as questões, poderia ter sido uma só: me desculpe, te enganaram. Estão te chamando de “analista de negócios”, talvez porque o termo seja chique e estava, até pouco tempo atrás, na moda. Mas sua dúvidas indicam que você não está fazendo Análise de Negócios. Você e outros 95% dos analistas espalhados por esse Brasilzão afora estão executando serviços de suporte. Talvez fosse mais correto e honesto chamá-la de Analista de Suporte!

    Mas Paulo, você pode retrucar, as duas últimas questões não tratam de suporte. Realmente não, mas reforçam as suspeitas de uma estrutura muito mal desenhada – com responsabilidades mal distribuídas, e a inexistência de algo minimamente semelhante a um processo. Sem meias palavras: é TI demolindo algo que lhe poderia ser bastante benéfico. Algo que convencionamos chamar Análise de Negócios.

    Já escrevi o suficiente sobre o “inferno nosso de cada dia”, sobre as insanas operações de TI. Não vou me repetir. Aliás, vou, mas só uma das provocações de ontem: se a Análise de Negócios pretende continuar existindo em médio e longo prazos, então está na hora de proclamar sua independência em relação à TI. Se seguir submissa e mal interpretada, terá o mesmo destino de várias outras ideias que um dia pareceram legais. Merecerá o mesmo fim que aguarda TI.

     

  • Repensando a Análise de Negócios

    Repensando a Análise de Negócios

    eria muita incoerência de minha parte se, após a palestra que apresentei no BA Brazil, seguisse tocando minha vidinha da mesma maneira. Aquelas provocações motivaram o maior redesenho que o Programa {FAN} já recebeu. O que, por sua vez, pediu por um rejuvenescimento deste {finito}. Não vou roubar seu tempo repetindo o que o programa já diz. Minha intenção neste artigo é outra. Que tal ver a Análise de Negócios de uma forma um pouco mais ampla?

    Relembrando e reforçando as duas provocações que apresentei:

    • Não devemos seguir espalhando por aí que “o importante é que a Análise de Negócios seja realizada, não importa por quem”. Esta colocação, por bem intencionada que seja, gera dois efeitos muito negativos: i) parece diminuir a importância e simplificar (no mal sentido) a Análise de Negócios; e ii) deprecia todos que escolheram a Análise de Negócios como profissão. Pergunta (retórica): na ausência de analistas de negócios, como podem a profissão e respectivo corpo de conhecimentos evoluir?
    • Apesar de dever seu ressurgimento à TI, está chegando a hora da Análise de Negócios decretar sua independência. Por definição, analistas de negócios ajudam uma organização a descobrir e desenvolver soluções para problemas de negócios. Qualquer tipo de problema! Mas…

     

    Definições Destroem

    A definição destrói Não há nada definitivo neste mundo. – Bob DylanNão precisamos ser radicais como Dylan, mas é sempre saudável alguma reflexão sobre definições e nomes. Pense um pouco sobre o termo “Análise de Negócios”. Talvez você perceba, como eu (depois de monte de gente¹), que ele é ruim pra chuchu. Veja o que diz o Houaiss:

    • análise s.f. 1 estudo das diversas partes de um todo 2 investigação; exame
    • negócio s.m. 1 transação comercial 2 local onde se realiza essa transação 3 algo que não se sabe ou não se lembra o nome; qualquer coisa; trem (em mineirês e fora do Houaiss)

     

    Pegando apenas o que nos diz respeito, podemos concluir que Análise de Negócios é “o estudo das diversas partes de um local onde se realizam transações comerciais”. O estudo por si só? Não faz sentido. Ou faz tanto quanto propor “a investigação de um trem“.

    Reforço a definição que sugeri no início do artigo: “analistas de negócios apoiam a descoberta e o desenvolvimento de soluções para problemas de negócios”. Os analistas apoiam – o que significa que suas atividades nunca são um fim em si mesmas. Eles apoiam dois tipos de atividades: de descoberta e  desenvolvimento (de soluções para problemas de negócios). Veja o diagrama abaixo:

    O losango já foi utilizado por vários autores para ilustrar o caminho para a solução de problemas, dentre eles Scott Berkun² e Tim Brown³. Berkun o chamou de “espaço do problema”. A figura indica que nós aumentamos esse espaço – cogitando e validando alternativas de solução – antes de selecionar, desenhar e construir a mais adequada. Brown nomeia as pontas do losango de maneira um pouco diferente. A primeiro seria de divergência – quando criamos escolhas, a segunda de convergência – quando fazemos escolhas. Quase escondo a provocação nas palavras entre parênteses: a análise – o estudo das diversas partes de um todo – é só parte do trabalho! Ela não tem sentido nenhum sem sua cara metade, a síntese. Houaiss:

    • síntese s.f. 1 reunião de elementos diferentes num todo coerente 2 operação intelectual que apreende o todo partindo dos elementos que o constituem 3 exposição abreviada e genérica; resumo

     

    Se a análise é o estudo das partes, a síntese as combina na elaboração de um todo. Não há processo ou método para solução de problemas que não obedeça essa ordem. Exatamente por isso o termo “análise” é tão ruim¹. Não se trata de chatice de dublê de filólogo. Nomes e definições podem ser perigosos ou até mesmo destrutivos. Se não, como explicar que muitas empresas utilizem analistas de negócios apenas em 1/5 das funções sugeridas no diagrama acima?

    Ainda não cheguei ao cúmulo de sugerir a troca do nome da disciplina ou da profissão. Não sou louco o suficiente. Apenas insisto para que a Análise de Negócios seja vista de forma mais ampla. Reparem, ela nem se limita ao losango no modelo acima. Existem outras três áreas, não limitadas aos projetos, que merecem o apoio dos analistas de negócios. São elas:

    • Gestão de Relacionamentos: se os analistas de negócios funcionam como uma ligação entre todas as partes interessadas de um projeto, é natural que se espere deles uma considerável contribuição na gestão de relacionamentos: gerenciamento de expectativas; resolução de conflitos; averiguação da satisfação de clientes e usuários etc
    • Gestão do Conhecimento: uma responsabilidade muito maior do que a danosa e usual percepção de que os analistas devem “documentar tudo”. Existem documentos – existe a necessidade deles, mas há algo muito maior sendo gerado a cada projeto, por menor que ele seja. É conhecimento novo. Algo que, se não for corretamente gerenciado, será desperdiçado.
    • Manutenção da Qualidade: algo que deve ser incorporado em toda e qualquer função. Os analistas de negócios têm condições de zelar não apenas pelo que desenvolvem, mas também pela qualidade de todo o trabalho executado em um projeto e fora dele.

     

    Para Pensar e Repensar

    Você pode estar perguntando, com razão, o que esse papo tem a ver com as duas provocações que abriram este artigo. Tudo:

    • Cabe um mundo inteiro na distância entre analistas de negócios e tiradores de pedidos. A Análise de Negócios lida com domínios cognitivos de maior dificuldade: Solução de Problemas, Análise e Síntese; Pensamento Criativo; Pensamento Sistêmico; Complexidade etc. Entender ou pretender que qualquer outro profissional possa executá-la, mesmo em projetos aparentemente mais simples, é ingênuo e perigoso.
    • Mais importante é entender que a Análise de Negócios não existe sem os analistas. A disciplina definhará se não houver quem a defenda e estude  como uma especialização.
    • Ao propor o modelo acima forço um distanciamento de TI. Até então utilizava disciplinas da Engenharia de Software – Modelagem de Negócios e Requisitos – para mostrar o que os analistas de negócios podem fazer. Elas seguem existindo e continuam importantes para os analistas. Mas devem ser percebidas como itens de uma caixa de ferramentas que precisa ser consideravelmente maior e mais diversificada. Todas as empresas estão carentes de bons solucionadores de problemas. Um time especialista em solução de problemas, qualquer tipo de problema, seria uma cartada e tanto. Você não acha?

     

    Notas

    1.  Esse papo de Análise + Síntese é quase tão velho quanto andar pra frente. Só foi requentado neste artigo porque parece esquecido ou ignorado quando o assunto é a Análise de Negócios. Gerald M. Weinberg, falando para analistas de sistemas em “Redefinindo A Análise e o Projeto de Sistemas” (McGraw-Hill, 1990), já tinha feito o mesmo. Pelo que sei, Weinberg foi o primeiro a destacar o quão ruim é o termo “Análise” e a propor um tal Sintetista. Desta leitura derivei outra provocação: o analista de sistemas falando para o analista de negócios, “eu sou você amanhã”.
      Weinberg teve vários títulos publicados no Brasil mas, salvo engano, estão todos esgotados. Analistas de negócios deveriam ler todos que encontrar nos sebos da vida.
    2. Em “A Arte do Gerenciamento de Projetos“, Bookman (2008).
    3. Em “Design Thinking – Uma Metodologia Poderosa para”, Campus (2010). A editora deu uma bela barbeirada no título, tanto que temo pela  tradução. Se puder, opte pelo original: “Change by Design” (Harper Business, 2009).
    4. A Extensão Ágil do BABoK®, em fase de revisão pública, é muito feliz ao sugerir uma divisão muito parecida com aquela ilustrada pelo losango acima. Só há um termo diferente: Delivery (entrega) ao invés de Desenvolvimento.

     

  • Scaling Lean & Agile Development

    Scaling Lean & Agile Development

    Craig Larman e Bas Vodde

    A quem pode interessar: Todos que estejam levando métodos ágeis e o pensamento Lean para além de um produto, um projeto ou um time. Deve interessar a todos que já rodaram mais de dois experimentos com métodos ágeis, particularmente com o Scrum.

    Porque ler: Larman tem um histórico de livros que fizeram a cabeça de muita gente, aqui e lá fora. São dele “Utilizando UML e Padrões” (Bookman, 2007) e “Agile & Iterative Development: A Manager’s Guide” (Addison-Wesley, 2004). Seus escritos seguem consistentes e didáticos. Mas agora ele parece um pouco mais divertido e direto. Porque sabe que o sucesso de suas sugestões depende de opiniões claras – de conclusões que podem não agradar todo mundo. Este é um dos poucos títulos (sérios) sobre a utilização do Scrum em projetos de médio e grande portes.

    Estrutura & Conteúdo: O livro tem apenas duas grandes partes, Ferramentas de Pensamento e Ferramentas Organizacionais. Cada uma mereceu cinco capítulos. Os autores começam pegando pesado, citando Woody Allen (!) e falando sobre o Pensamento Sistêmico. Quem sempre se sentiu intimidado ou constrangido pelo “A Quinta Disciplina” de Peter Senge (Best Seller, 2009) sentirá imenso alívio ao ler o primeiro capítulo de “Scaling Lean & Agile Development”. Combinado ao pensamento Lean, o Pensamento Sistêmico é apresentado de forma extremamente prática e didática.

    Também merece destaque o segundo capítulo, sobre o Pensamento Lean. Não se trata de um derivado de outros escritos, mas de um trabalho de pesquisa que envolveu interações diretas dentro da própria Toyota no Japão. Não é por nada não, mas a dupla conseguiu explicar em um capítulo o que muita gente não fez em um livro inteiro! Fechando a primeira parte temos os seguinte capítulos: Teoria das Filas, Falsas Dicotomias e Seja Ágil.

    A segunda parte, sobre Ferramentas Organizacionais, apresenta sugestões um pouco mais controversas. Eu gostei demais de boa parte delas, mas sei que algumas pessoas virarão piruetas ao ler, por exemplo, que “organizações ágeis não precisam de Escritórios de Projetos (PMO’s)” (p. 249). Os autores dizem, no mesmo trecho, que pior que um PMO é a sugestão de um Agile PMO. Claro, não deixam de citar o pai da (indesejada) criança: Jochen Krebs, em “Agile Portfolio Management” (Microsoft Press, 2008). Acho que nem preciso dizer que também gostei muito da alternativa sugerida pela dupla para troca de conhecimentos e experiências: as Comunidades de Prática (p. 252).

    Aliás, o livro todo apresenta dois grandes conjuntos de sugestões (experimentos) etiquetados como “Try…” (Tente) e “Avoid…” (Evite). Uma lista com todas as sugestões aparece logo de cara, na terceira página. Todas são apresentadas e justificadas no decorrer do texto.

    Trechos (livremente traduzidos):

    “Evite… pensar que o gerenciamento de filas, kanban e outras ferramentas são pilares do Lean.”

    “Tente… refletir sobre os dois pilares do Lean: Respeito pelas Pessoas e Melhoria Contínua.”
    (N.T.: Reparou que “eliminar desperdício” também não pintou aqui? Acontece que certos “desperdícios temporários” são necessários. Um buffer com itens do backlog do produto, por exemplo).

    “Uma das mais ignoradas e valiosas sugestões do Scrum diz que algo entre cinco e dez porcento de cada Sprint deve ser dedicado pelo time ao refinamento do backlog do Produto.”

    “O último projeto simples foi feito em 1962. Não acredite que exista algum projeto que não envolva aprendizado ou complexidade ou alguma variabilidade e, consequentemente, não se beneficie do desenvolvimento ágil.”

    “Encoraje os especialistas a ensinar, não a fazer.”

    “Se não há conflito aparente então o time está com problemas.”

    “Evite… ferramentas tradicionais de gerenciamento de requisitos.”

    “Evite… organizações matriciais e escritórios de projetos.”

    “Evite… a IBM.”

    Serviço:

    Scaling Lean & Agile Development
    Craig Larman e Bas Vodde
    Addison-Wesley, 2009
    US$ 39,41 na Amazon (em 24/jan/12)
    US$ 15,92 pela versão eletrônica.

    ?

  • Use Case 2.0: Você precisa dele?

    Use Case 2.0: Você precisa dele?

    Ivar Jacobson liberou, agora em dezembro, um pequeno livro eletrônico chamado “Use Case 2.0: The Definitive Guide“. Como ele mesmo alerta, não se trata de uma atualização da ferramenta. Afinal, “casos de uso ainda são casos de uso”. Mas o texto propõe alguns novos elementos – novos artefatos de trabalho. Este artigo pretende avaliar as principais alterações sugeridas comparando-as com alternativas já conhecidas.

    ?

    Apesar de toda a má fama que a acompanha, a ferramenta Caso de Uso continua sendo apresentada por muitos, inclusive este que vos escreve, como a mais eficaz no apoio às atividades de “descoberta e descrição dos requisitos funcionais de um sistema”. Os mal ditos sobre os casos de uso têm origem bem identificada. Em dado momento, entre o final dos anos 1990 e início do novo século, tentaram sofisticar demais a ferramenta. Modelos rebuscados e divisões artificiais e redundantes (fluxo disso, fluxo daquilo…) deram enorme contribuição. A gota d’água veio daquela parte da população que tem preguiça de pensar e adora templates repletos de badulaques. Pronto, estava criada a fama – justíssima, dados os casos criados – de que casos de uso eram muito complicados, de difícil elaboração pelos analistas, incompreensíveis para os usuários, detestados e consequentemente ignorados pelos desenvolvedores e distantes demais dos testers (provavelmente os únicos que, se tivessem a chance, talvez gostassem daquilo. Porque era melhor que nada!)

    O advento do Manifesto Ágil quase nos fez crer que Caso de Uso era coisa do século passado. Mas o que seria do mundo se não fossem os teimosos? Alistair Cockburn nunca abandonou os casos. Nem Ivar Jacobson, o pai da criança que agora nos apresenta essa releitura (escrita a seis mãos com Ian Spence e Kurt Bittner, autores de “Use Case Modeling” – Addison-Wesley, 2002).
    O que ela traz de novo a ponto de merecer o “2.0”? Antes disso, qual a motivação para uma nova versão?

    Os autores defendem que o Caso de Uso 2.0 é: Leve, Escalável, Versátil e Fácil de usar. Fica implícita a intenção de oferecer a versão remoçada da ferramenta como alternativa para as User Stories. Apesar de ilustrarem sua utilização até em um processo baseado no modelo waterfall. A falta de um comparativo entre User Stories e Casos de Uso, a exemplo do que fizeram James Coplien e Gertrud Bjørnvig em “Lean Architecture“ (Wiley, 2010), reduz o impacto da proposta. Mas, afinal, qual é a proposta?

    Jacobson reforça uma mensagem que já apresentava em seus tempos de Rational¹: “casos de uso são a cola de todo o ciclo de vida do processo “. Ou seja, eles “suportam a análise, projeto, planejamento, estimativas, acompanhamento e testes de sistemas”, além da captura de requisitos, é claro.

    Um mapa conceitual nos ajuda a entender todos os elementos da proposta e as relações entre eles. Peço desculpas pela redundância mas vou reescrever as partes que representam as maiores alterações (e, tentarei mostrar, os problemas da proposta).

    Os interessados (stakeholders): i) são as fontes dos Requisitos; ii) estão envolvidos e priorizam Casos de Uso; e iii) se comunicam contando Histórias.

    Até aqui tudo bem, até porque o mapa informa que: iv) Requisitos são capturados na forma de Casos de Uso.  Agora, como falamos aqui no interior, a porca torce o rabo (e a proposta se enrola). Porque é colocado que: v) Casos de Uso são explorados através da narração de Histórias; e vi) seu escopo é gerenciado e endereçado como um conjunto de Fatias de Caso de Uso (Use-Case Slice); que, por sua vez, vii) são identificadas (ou têm sua identificação facilitada) pelas Histórias.

    Essas histórias, a princípio, não têm nada a ver com as conhecidas User Stories (não citadas no e-book). Mas é impossível não perceber a intenção de fazer com que elas sejam elaboradas e tratadas da mesmíssima maneira proposta por Kent Beck (em “Extreme Programming Explained” – Addison-Wesley, 1999) e amadurecida por Mike Cohn (“User Stories Applied” – Addison-Wesley, 2004). Uma História, segundo os autores, pode ser qualquer coisa: requisito funcional ou não funcional, um trecho ou fluxo(s) do Caso de Uso, um requisito especial (?) ou ainda um caso de teste. E elas, genéricas (e versáteis assim), ajudariam na identificação de Fatias de Casos de Uso.

    Essas Fatias, apresentadas como “o elemento mais importante do Caso de Uso 2.0”, justificariam-se porque, segundo os autores, “precisamos de uma maneira de dividir casos de uso em conjuntos menores”. Li e reli o documento e continuo não acreditando que o próprio cara que inventou a ferramenta e seus naturais mecanismos de quebra (extensão) e organização esteja propondo tamanha confusão. Talvez meus neurônios não tenham percebido o fim das férias, sei lá. O fato é que a proposta, particularmente suas Histórias e Fatias, não parece fazer muito sentido.

    Um Caso de Uso é uma maneira mais (ou menos) ESTRUTURADA² de se contar e registrar uma história, um causo. Ele sempre possui um Fluxo Principal (ou Básico), uma sequência natural de interação entre um Ator e um Sistema onde todos os passos são bem sucedidos. Todas as variações ou desvios desta sequência principal são capturados e registrados na forma de Fluxos Alternativos (ou Secundários). Está aqui o primeiro mecanismo natural de ‘quebra’ de um caso de uso. Considero-o natural porque ele reflete a forma do usuário pensar. Uma vez registrado o comportamento mais esperado, como Fluxo Principal, a história se desenrola, por exemplo, em uma sequência de “e se”: “e se o cliente não tiver crédito”, “e se não houver estoque disponível” etc³. Casos de uso são tremendamente eficazes na “descoberta e descrição de requisitos funcionais de um sistema” exatamente porque permitem que uma história seja narrada e estruturada da forma mais natural (e próxima do usuário) possível.

    Por que, então, precisaríamos de outros mecanismos de quebra e organização? Para termos elementos ainda menores, que caibam em uma iteração de duas semanas ou em um post-it? Coplien e Bjørnvig, no capítulo 7 do livro citado acima, já haviam dado a receitinha: “qual é a diferença entre a lista de desvios (Fluxos Alternativos) e uma lista de requisitos, features ou User Stories? Quase nenhuma quando olhamos de perto. Podemos formular cada item da lista na forma de User Stories se isso faz com que a gente se sinta mais Agile“. Bem antes deles, no já distante ano 2000, Alistair Cockburn (em “Writing Effective Use Cases” – Addison-Wesley, 2000) já havia sugerido a derivação de uma Lista de Trabalho a partir de um Caso de Uso e seus diversos fluxos (Work List, págs. 172 – 174). Com itens que cabem perfeitamente em um post-it ou, falando mais sério, “cabem” em iterações (sprints) e facilitam o acompanhamento e gerenciamento de um product backlog ou algo parecido. Enfim, Casos de Uso nunca foram monolitos nem nunca levaram a uma situação “tudo ou nada”. Repito: nunca!

    Casos de Uso também podem ser vistos ou utilizados como uma “cola que une todas as etapas de um processo de desenvolvimento” desde a criação da UML (1995-1997) e dos derivados do Processo Unificado (1998~). Não creio que serão as sugeridas Fatias que farão, agora, a mágica de viabilizar tal visão. Porque a verdade é que nós nunca (ou, para pegar um pouco mais leve) raramente utilizamos Casos de Uso em toda a sua plenitude. O faremos agora que ele ficou um pouquinho mais complicado?

    ?

    Observações:

    1. Lê-se a primeira frase destacada na apresentação “Common Chalenges in Use Case Modeling”, de autoria de Ivar Jacobson e com logo da Rational Software (sem data de publicação).
    2. E é esta propriedade fundamental, o fato do Caso de Uso ser uma história ESTRUTURADA, sua principal diferença em relação a outras propostas, particularmente as User Stories. Um Caso de Uso, por natureza, é um conjunto de requisitos que faz todo o sentido para um usuário ou cliente. Um conjunto estruturado. Um conjunto que “entende” sua relação com os demais componentes da solução. Naturalmente.
    3. Destaquei o primeiro (Fluxos Alternativos) mas não cito acima os demais “mecanismos naturais de quebras” dos Casos de Uso. Porque aqui a porca torce o rabo de vez e, preciso admitir, alguns mecanismos não são tão naturais assim (Extends e Includes devem ter passado pela sua cabeça). Para não deixar o tema no limbo preciso dizer que Cenários (combinações de passos dos fluxos principal e alternativos) e Casos de Testes são derivados ou componentes de um Caso de Uso e representam outras formas de “quebra”. Serão mais ou menos naturais dependendo da forma como são elaborados.
    4. Slice of a Pumpkin Pie, foto que ilustra este artigo, é de autoria de TheCulinaryGeek.

     

  • BA Brazil 2011: Balanço, Reflexos e Reflexões

    BA Brazil 2011: Balanço, Reflexos e Reflexões

    Aconteceu na última semana, em Porto Alegre, a 1ª Conferência Brasileira de Análise de Negócios – o BA Brazil 2011. Transcrevo neste artigo minhas experiências e considerações sobre o evento. E trago para cá conversas e provocações que, acredito, merecem reflexões e debates.

    ?

    Se fosse preciso resumir tudo em uma única palavra ela seria: Show! Show de organização. Show diversificado. Show com lotação praticamente esgotada. O BA Brazil provou a força da comunidade e como o trabalho voluntário move e remove montanhas. Se alguém ainda tem dúvidas sobre a combinação dos termos “planejamento” e “métodos ágeis” ou sobre a utilização dos últimos fora da seara do desenvolvimento de sistemas é porque não viu o BA Brazil. Créditos para o time do IIBA e todos os parceiros que ajudaram a viabilizar o evento. Evito citar nomes para não cometer nenhuma injustiça. Todos estão de parabéns.

    Infelizmente, por problemas de agenda, não pude ver praticamente nada dos dois dias de palestras e espaços abertos. Mas tive tempo suficiente para rever amigos de Brasília, Floripa, Sampa e Rio. E, claro, pude assistir a palestra de abertura ministrada por Shane Hastie. Shane explicou “porque precisamos de Análise em Projetos Ágeis”. Você acha estranho que esse tipo de “explicação” ainda seja necessária? Eu achava. Mas a conversa do Shane foge do lugar comum. E mira dois alvos: também fala sobre métodos ágeis para analistas de negócios. Seu discurso é sereno, objetivo e bem ilustrado. Seria impossível e injusto destacar algum ponto. Prefiro resumir assim: eu queria que mais executivos e agilistas tivessem a oportunidade de ouvir e conversar com Shane. Só isso.

    Eu tive essa oportunidade, em cafés, viagens de táxi e jantares. E as primeiras coisas que você nota em Shane, além do profundo conhecimento dos temas que aborda, são sua humildade e generosidade. Em questão de pouquíssimas horas “viajávamos” pelas necessárias revisões do BABoK®, a sentida ausência dos casos de uso no draft da extensão ágil¹, a corrupção no Brasil (e suas similaridades com a África do Sul, país onde Shane morou por alguns anos), a beleza das mulheres de Porto Alegre, churrasco, caipirinhas (with two you get to the limit of liability!) e nossas experiências profissionais. Não necessariamente nessa ordem.

    Em outro dia, quando compartilhávamos a mesa com Suzandeise Thomé, Luiz Parzianello, Marcelo Neves e Willen Dijkgraaf, chamei a atenção para a forma como Shane destacava sua não concordância com algum tema. Por exemplo: “Arquitetura Corporativa”. Shane desacelera e calibra a dicção, frequentemente soltando um “fundamentally wrrrrrong!”.  Aquele “Wrrrrrong” soa como um trovão. E não deixa a menor dúvida sobre sua posição. O que não significa que a conversa tenha se encerrado, pelo contrário. Está apenas começando!

    Acompanhei de longe a repercussão do restante do evento. Pelos comentários a única conclusão possível é de um retumbante sucesso. E a certeza de que a versão 2012 é só questão de tempo. Que assim seja!

    Reflexões

    Minha palestra aconteceu logo na sequência, ainda na manhã da quinta-feira. Falar logo após a abertura do Shane já era uma responsabilidade e tanto. De carona no presente-provocação sugerido pelo Luiz Parzianello, uma responsabilidade quase insuportável. Quando me convidou, Parzianello sugeriu o título de minha fala: “Para você, o que é Análise de Negócios?”

    Abri o papo confessando a dificuldade em condensar em quarenta e cinco minutos uma resposta que, a primeira vista, deveria ser muito simples e direta. Mostrei que apelei para um oráculo (Bob Dylan?!?) e para o pai dos burros (Houaiss) em uma busca infrutífera por inspiração. Quem leu meu artigo anterior já conhece o final da história. Meu problema não era definir a Análise de Negócios mas sim justificar a definição. E não havia mais nenhuma razão para manter implícitas ou autocensuradas duas provocações:

    1. Há, no meu ponto de vista, exagerada e arriscada ênfase na macrodisciplina  “Análise de Negócios” em detrimento de seus praticantes principais, os Analistas. Algo como: “o importante é que a Análise seja feita, não importa por quem”. Concordo que a área não carece de muros ou testes como aqueles que vemos em Direito, Medicina, Engenharia e afins. Por outro lado, se não existirem profissionais especializados e orgulhosos de sua área, como podem a disciplina e respectivo corpo de conhecimentos evoluir? Não é de hoje que é notória a baixa autoestima dos Analistas de Negócios, particularmente dos tupiniquins. Existem razões mil para tanto – sendo a principal a confusão com “tiradores de pedidos²”. Mas não melhoramos a situação com o discurso vigente. Em suma: se queremos uma Análise de Negócios forte e reconhecida precisamos fortalecer e reconhecer os Analistas de Negócios. Eles não são nada menos que fundamentais para o futuro da disciplina.
    2. Não estava escrito em nenhum slide que utilizei mas acho que falei mais ou menos assim: “Se tivermos legítima preocupação com a Análise de Negócios em médio e longo prazos, então é hora de decretar sua independência de TI“. Reconheci que devemos ser eternamente gratos pelo fato de TI ter ressuscitado e viabilizado a área. Mas é chegada a hora de debater se queremos ou podemos limitar o uso da disciplina exclusivamente em problemas de negócios que envolvam Tecnologia da Informação. Apresento novamente mea culpa. Tenho vinte e cinco anos de vida profissional e sempre trabalhei com TI. Meu trabalho se limita a TI. Mas meu trabalho é só um grãozinho de areia, sem falsa modéstia. Quero crer que o público presente, pelas questões apresentadas, entendeu bem o recado. Até quando sugeriu, para minha concordância, que o Analista de Negócios é o Novo Novo Analista de Organização & Métodos.

    Testando o {FAN}

    Se o {FAN} 2012 precisava ser puxado até o limite, ele conseguiu em PoA. Foram duas turmas, uma delas não programada originalmente. E entre os quase setenta participantes uma diversidade grande, muita sede, muitas dúvidas e bastante colaboração. Ligeiras conclusões:

    • O programa está perigosamente no limite de sua carga horária. Já penso seriamente em uma versão com 20 horas distribuídas em três ou cinco dias. Na próxima semana, em turma fechada e com 24 horas ao meu dispor, farei novo teste.
    • Algumas atividades podem “sujar” mais paredes. A turma via o curso do Shane ao lado e gostava de todos aqueles displays.
    • Aliás, posso contemplar em algumas turmas o trabalho de derivação de casos de uso em histórias e tarefas. E tornar a montagem de diagramas PUCS uma atividade mais interativa, fazendo toda  a sala montar um único diagrama.
    • Preciso rever o último sprint, que acontece logo após um coffee-break. É um tour-de-force com cerca de duas horas de duração e sem nenhuma interrupção – nenhuma atividade prática. É uma longa história que conto, mostrando como os analistas de negócios trabalham em conjunto com o time de desenvolvimento em busca de uma solução. É legal – acho que todos gostam. Mas chego ali estourado, com voz e pernas extenuados. Ok, preciso melhorar minha condição física. Mas acho que é possível quebrar aquela história de forma a torná-la menos cansativa.

    Tks!

    Suzandeise Thomé, Luiz Parzianello e Marcelo Neves, pelo voto de confiança e pela oportunidade. Oferecer tão generoso espaço para um chato e crítico frequente do IIBA é prova incontestável da maturidade e do espírito democrático dos Chapters brasileiros. Vocês sabem, seguirei chato e crítico. Mas seguirei também um fã incondicional do trabalho de vocês. Parabéns!

    Thank you, Mr. Shane Hastie, for your generosity, the shared knowledge and the patience with my bumbling english. 

    Simone Kosmalski, pela hospitalidade, atenção e organização.

    Melissa Trevisan e Marta Py, pelo trabalho, força e confiança.

    Willem Dijkgraaf, pelo apoio e pelo feedback.

    E muito obrigado a todos que tornaram o BA Brazil 2011 possível.

    Observações:

    1. Shane justificou a ausência (de casos de uso na extensão ágil do BABoK®) dizendo que a técnica já está devidamente coberta no BABoK® 2.0. Mas alertei, a ele e ao Parzianello (que também trabalha naquela extensão), que talvez o texto esteja passando a impressão (equivocada) de que no mundo ágil só se trabalha com histórias de usuários. Prometi ser mais específico na leitura crítica que publicarei antes para eles e depois aqui no {finito}.
    2. Perdi a oportunidade de fazer um teste de DNA e tirar dúvidas sobre a paternidade do termo “tirador de pedidos”. Mas aproveito para registrar aqui outra coisa que o Analista de Negócios NÃO é: “traficante de picuinhas!” Qualquer dia compilo todos os “criativos” termos criados para desmerecer e desmotivar o mau uso da profissão.
  • {FAN} 2012

    {FAN} 2012

    Lancei na última semana, em São Paulo, a versão 2012 do {FAN} Formação de Analistas de Negócios. É uma versão especial porque celebra o quinto ano do programa. Aproveitei o impulso do BA Brazil, que acontece daqui a duas semanas em Porto Alegre, para antecipar o lançamento. Apresento neste artigo a estrutura, alterações e extensões da oficina.

    ?

    Não acredito que um dia o núcleo duro do {FAN} seja alterado. Desde o longínquo junho de 2007, quando foi apresentada ao público pela primeira vez, esta oficina está estruturada em torno de duas grandes disciplinas: Modelagem de Negócios e Requisitos. Aprendi depois de um tempo que deveria utilizar uma explicação relativamente simplista para justificar a estrutura: a primeira disciplina nos ajuda a entender um negócio; a outra concentra-se no entendimento das necessidades e restrições de usuários e outros interessados. Cada uma merece 50% da carga horária. A divisão arbitrária – um dia para cada disciplina – tem fins didáticos. Os participantes devem entender que lançam mão de ambas simultaneamente durante toda a sua participação em um projeto. Eles entendem.

    Assim como entendem o fato deste evento não se basear na estrutura proposta pelo BABoK®. É fácil fazer um ‘de-para’ quando necessário. Como o foco da oficina não é a certificação, mas o trabalho prático com a Análise de Negócios, nunca ninguém reclamou. Cito o corpo de conhecimentos oficial quando necessário, seja para destacar algum problema ou boa solução. Tanto que falo até hoje sobre a versão 1.6 e seu bom capítulo sobre “Elicitação” de requisitos.

    Deixo a impressão, até aqui, de que não mudou muita coisa no {FAN}. É que comecei pelo que não mudou. Vamos às alterações. A versão anterior, que utilizei até outubro deste ano, tinha 200 slides no arquivo de apresentação. A nova versão conta com exatos 299! Um acréscimo de praticamente 50% e a mesma carga horária? Como isso seria possível?

    Fiz um levantamento de todos os tópicos que, a partir da interação com os participantes, exigiam improvisos em um quadro branco. Apesar de gostar de toda aquela dinâmica, percebi que perdia um tempo precioso rabiscando. Pior: ficava muito tempo de costas para a plateia. Todos os improvisos que ficaram frequentes mereceram slides. Praticamente todo um novo tópico sobre estimativas, priorização e definição de escopo brotou dessa decisão.

    Eliminei também o ridículo “ditado” de uma especificação de caso de uso que servia como exemplo. Mantenho a apresentação passo-a-passo de um caso, mas agora os alunos ficam livres para prestar atenção no que de fato interessa. Três atividades práticas os deixam rabiscar e abusar do novo modelo que apresentei no artigo anterior.

    E por falar em atividades práticas: são 11 no total. E, a partir de agora, nenhuma é opcional. Elas totalizam cerca de 240 minutos, quatro horas de um total de quatorze. Ou seja, cerca de 30% da oficina é totalmente prática. Parece pouco, mas me lembro dos tempos em que o {FAN} era FAN e tinha apenas 4 atividades. E de sua “pré-história”, quando não havia exercício algum.

    Todos os exercícios são posicionados de forma a reforçar ou demonstrar a parte teórica recém apresentada. E são baseados em um mesmo problema de negócio. Mantenho a estratégia de não fixá-lo nas apresentações ou na apostila. Isso permite que a cada turma eu possa sugerir um novo. Também possibilita que em cursos fechados sejam utilizados projetos reais dos clientes. Na última edição eu ressuscitei o imbróglio do ‘seu’ Moreira – português fabricante de pãezinhos que precisa dobrar a produtividade de seus vendedores. Em PoA eu devo trocar a nacionalidade do preocupado e seu produto: de pão para vinho.

    Outra mudança significativa está no número de ferramentas apresentadas, particularmente no módulo de modelagem. Incorporei novas sugestões, inspirado principalmente por dois trabalhos: Business Model Generation¹ (o ‘canvas’) e Gamestorming². Mantenho o Pensamento Visual como método de modelagem, mas sem a ênfase que ele mereceu nas versões anteriores. Ao ‘esconder’ o método e apresentá-lo apenas no final do primeiro dia eu consegui, por incrível que pareça, facilitar seu entendimento.

    No final do segundo dia também acontece um momento flashback, desta vez revendo todo o evento e demonstrando um método para definição do escopo inicial de um projeto. Conto uma história onde o analista tem dez dias úteis para entender um problema e, junto com o time, tentar descobrir a melhor solução. Funciona realmente como uma grande revisão da oficina, da famosa fotografia 2km X 2cm até o detalhamento de casos de uso. É uma das partes que eu costumava improvisar e que ficou muito melhor com o apoio visual pré-concebido.

    Agora deixei a impressão de que foi tudo perfeito no ‘teste beta’ que executei, o que não é verdade. Peguei uma turma que ficou muito silenciosa (assustada?) no primeiro dia. No segundo, se soltaram e interagiram bem mais, comigo e entre eles. Mas fiquei com a pulga atrás da orelha: a sobra de trinta minutos em cada dia é real? Só terei certeza depois das duas oficinas no BA Brazil. Encontrei um bug mais sério só no segundo dia, o mal posicionamento da atividade #8. Mas foi muito pouco para evento tão extenso. Sorte de principiante? Hehe… pode ser.

    Outro probleminha: a apostila está mais bonita, melhor diagramada. Agora ela tem espaço para a resolução dos exercícios. Não pretendo mais distribuir blocos separados para eles. Acontece que o pessoal ficou com dó da apostila. Muitos não quiseram rabiscá-la. Mesmo com minha promessa de que a versão digital está disponível para download. O que fazer? Ah, se eles vissem como trato meus livros de papel…

    Meio & Mensagem

    Mudanças cosméticas; inserção pontual de ferramentas; maior cuidado com atividades práticas. O {FAN} nunca ficou parado no tempo e em seus quatro anos e meio de vida sempre apostou que podia ser bem melhor. Mas a nova versão traz uma mudança maior, não citada até agora.

    Em meu entendimento, a “onda” em torno da Análise de Negócios passou. Assim como já ficou para trás a “moda” Scrum. É uma aposta que torno pública: vocês verão muitos entusiastas de primeira hora vestindo novas roupas, estampando novas cores e reciclando promessas. Trata-se do melhor momento de todas as ondas. Porque o que fica é o que de fato interessa. O que passou era entusiasmo (e oportunismo) e nada além disso.

    O {FAN} 2012 incorpora esse espírito. Entende que a Análise de Negócios, que a necessidade dela, sempre existiu e sempre vai existir. Mas há um tanto de mea culpa no novo discurso. Motivado, principalmente, pelo advento dos Arquitetos de Negócios. Eles não seriam sugeridos se nós, envolvidos com a formação de analistas de negócios, tivéssemos feito um bom trabalho. Mas é só outra moda. Não deve preocupar.

    Preocupa, isso sim, que os bons analistas de negócios não desanimem. Para isso acho que é fundamental provar sua criticidade no cotidiano de uma organização. Não apenas na solução de problemas de TI. Analistas de negócios não dão manutenção em sistemas! Analistas de negócios não são “tiradores de pedidos”! Analistas de negócios apoiam a descoberta e o desenvolvimento de soluções para problemas de negócios. Qualquer tipo de problema.

    Posicionados a partir da definição acima os analistas de negócios se verão desafiados por domínios cognitivos de maior dificuldade. Não basta a análise – o estudo das diversas partes de um todo (Houaiss). O analista não é nada menos que fundamental na síntese – na destilação da tese proveniente daqueles que têm problemas e da antítese colocada pelos eventuais provedores de soluções. É peça fundamental – meio e mensagem – em um diálogo verdadeiramente produtivo.

    Enfim, o {FAN} 2012 traz uma mensagem otimista embalada em belos desafios. Desenha-se em torno de duas disciplinas que definem as habilidades técnicas que um analista de negócios deve desenvolver. Mas é guiado por um conjunto que, por falta de termo melhor, tenho chamado de Habilidades Essenciais: Solução de Problemas, Análise, Síntese, Gestão do Conhecimento e Aprendizagem Organizacional, Comunicação Corporativa, Pensamento Criativo, Pensamento Sistêmico, Pensamento Visual, Teoria da Complexidade etc. Eu sei, assusta. Mas posso garantir: é apaixonante. Por isso seguirei teimando que essa é uma das melhores profissões do século XXI. Quem sobreviver (à onda), verá.

    Extensões do {FAN}

    Há meses brigo com uma ideia: liberar módulos curtos, com três horas de duração, para apresentação e aprofundamento de tópicos específicos do programa {FAN}. Como é impossível prever sua aceitação, farei testes reais em janeiro do próximo ano. Não exigirei participação prévia no {FAN} tradicional de 14 horas. Esta primeira geração do que estou chamando {FAN Fast} é formada por quatro módulos:

    • Introdução à Análise de Negócios: apresentação da área, seu corpo de conhecimentos & habilidades e as responsabilidades de um analista de negócios em uma organização e em projetos. Tiro curto dirigido a todos que ainda precisam conhecer a função/profissão e saber como tirar melhor proveito dela em suas empresas.
    • Aprendendo Requisitos, Contando Causos e Histórias: aprendizagem, estruturação e desenvolvimento de requisitos de forma prática e direta. Há tempo muita gente tenta contratar apenas o segundo dia do {FAN}, aquele que trata especificamente de requisitos. Este módulo é para eles e todos que queiram mergulhar um pouco mais no tema.
    • Conversando (e Rabiscando) a Gente se Entende: novamente inspirado pelos livros citados acima. Ferramentas práticas que facilitam a comunicação com usuários, clientes e outros interessados. Outras ferramentas, além daquelas apresentadas no {FAN}, serão exercitadas aqui.
    • Trabalhando com Scrum e outros Métodos Ágeis: para analistas e gente de negócios que precisam saber como se comportar (hehe) em projetos guiados pelo framework Scrum ou outros métodos ágeis. O que muda na atuação de um analista? E o que não deveria mudar? Evento prático e divertido que mostra a importância de um analista na formação de um “time de (dono de) produto” e no trabalho com métodos ágeis.

    Todos os módulos são ‘levemente acoplados’. Ou seja, você contrata apenas aquele ou aqueles que te interessar. Não haverão (muitas) referências cruzadas, nem mesmo com o {FAN} tradicional. Nesta primeira leva, apenas uma restrição: os módulos acontecerão durante a semana, em dias consecutivos e em período noturno. Em breve publico as páginas dos eventos e divulgo a agenda.

    Upgrade

    Em 2010 ofereci, de graça, um FAN Upgrade. Foi muito curto e serviu para rever amigos. Passados quase dois anos, hora de agendar uma nova atualização. E ela se dará através da participação no evento tradicional, com 14 horas de duração! Desta vez o evento será pago (assim quem se inscreve realmente participa, né?) Mas terá descontos progressivos. Quanto mais antiga sua participação no FAN, menos você paga. Quem participou das turmas de 2007 e 2008, por exemplo, tem desconto de 50%.

    O Upgrade está agendado em programação especial de férias: acontecerá em São Paulo, nos dias 13 e 14 de janeiro. O site da Tempo Real Eventos já está recebendo inscrições: http://www.temporealeventos.com.br/?area=15

    ?

    Observações:

    1. Business Model Generation – Inovação em Modelos de Negócios
      Alexander Osterwalder – Alta Books (2011)
    2. Gamestorming – A playbook for Innovators, Rulebreakers, and Changemakers
      Dave Gray, Sunni Brown e James Macanufo – O’Reilly (2010)
    3. “Creating Solutions”, de HikingArtist.com, é o título do cartoon utilizado neste artigo.
  • Um Novo Modelo para Casos de Uso

    Um Novo Modelo para Casos de Uso

    Apresento neste artigo um novo modelo para a especificação de casos de uso. Foram dois os empurrões que me trouxeram para esta nova proposta. Vários participantes de meus treinamentos pediram por um modelo que não tivesse apenas fins didáticos. Algo que eles pudessem adotar em seu dia a dia. Além disso, ideias recentes apresentadas por James Coplien, Gertrud Bjørnvig e Ivar Jacobson me fizeram rever alguns pré-conceitos em relação à ferramenta. Mantive boa parte do desenho original – a preocupação com a estruturação dos requisitos – mas incorporei vários novos elementos. Como ainda não tive muitas oportunidades para testar o novo modelo, contarei com seu retorno.

    ?

    Antes de mais nada, os créditos. A principal provocação para o novo modelo veio de “Lean Architecture” (Wiley, 2010), de James Coplien e Gertrud Bjørnvig. O casal, por sua vez, cita os trabalhos de Rebecca Wirfs-Brock (“Designing Scenarios” – Smalltalk Report, nov-dez/1993) e Constantine e Lockwood (“Software for Use: A Practical Guide to Models and Methods of Usage-centered Design” – Addison-Wesley, 1999). Me convenceram da utilidade e necessidade do uso de duas colunas nos fluxos. E provam, em seu livro, como as especificações podem ser ágeis e enxutas. Na semana passada o “pai” dos casos de uso, Ivar Jacobson, publicou um artigo sobre Casos de Uso 2.0. Dele ganhei a confirmação de que casos de uso: i) são tão ágeis quanto você; ii) escalam o quanto você precisar; iii) não tratam apenas de requisitos funcionais; iv) não se limitam a projetos de sistemas; e v) nem aos requisitos – valem em todo o ciclo de vida de um projeto. Usei todas as novas sugestões como complementos ao modelo que utilizava anteriormente e que era fortemente baseado no trabalho de Alistair Cockburn, “Escrevendo Casos de Uso Eficazes” (Bookman, 2008).

    Aos iniciados, letrados e usuários super-avançados de casos de uso e afins, um aviso: o modelo aqui sugerido segue tendo como principal motivação o uso didático. Por isso, talvez o modelo não tenha nenhuma utilidade para vocês. Pensei nos iniciantes e em todos que precisam rever seus (pré)conceitos sobre a ferramenta. Me preocupei, principalmente, com todos que precisam de um tipo de guia (e de limites) enquanto aperfeiçoam sua técnica. Vamos ao que interessa.

    O modelo anterior era muito pequeno (formato A5), o que impedia seu uso em casos ‘de verdade’. O novo modelo foi diagramado em formato A4 paisagem. Frente (acima) e verso (logo mais) podem ser impressos em uma única folha ou em separado, como explicarei mais tarde. A frente condensa todas as informações fundamentais sobre um caso de uso. Vou apresentá-la por partes.

    Cabeçalho

    Segue a preocupação com a identificação da fonte e respectivo ponto de vista (estratégico, tático, operacional ou técnico). Incorporei um sofisticado “controle de versões”. Ele me ajuda a reforçar um grito: “joga o caso no lixo! (tão logo dele tenha brotado algum derivado)”.

    Finalmente me lembrei dos ícones que determinam o nível de detalhamento do caso. Não, prezadas fábricas de software (sic), não contemplei o tal nível “pré-sal” que vocês insistem em pedir. Mas a nova versão da ostra, quero crer, não gerará mais dúvidas nem piadinhas.

    O campo “processo / atividade” serve para referência cruzada com algum diagrama do negócio, de preferência com o PUCS (Process-Use Case Support) ou um diagrama de atividades.

    “Valor”, que talvez ainda seja rebatizado “Benefício”, indica como o cliente ou usuário valoriza o caso em questão. “Custo” é a estimativa de esforço do time de desenvolvimento (expressa em unidades relativas, pontos de casos de uso ou qualquer outra unidade de medida). A possível avaliação benefício/custo pode determinar a “Ordem”, a posição do caso no cronograma (ou, de preferência, no backlog do produto). Daí o espaço “Iteração”, onde deve ser registrado a iteração projetada para o trabalho neste caso. Quem não “itera” pode ignorá-lo, sem problemas.

    Contexto, Pré e Pós-Condições

    Não se trata de um filler, vulgo “encheção de linguiça”. O Contexto nos ajuda a posicionar o caso de uso no projeto, indicando suas relações com outros elementos. É aberto para possibilitar até mesmo o desenho de um pequeno diagrama de casos de uso. Mesmo que fujas dos temidos (e mal compreendidos) extends e includes da vida, você deve achar alguma utilidade para o espaço. Pré e pós-condições não pedem por maiores explicações. Ah, só preciso dizer que elas são um tipo muito especial de Regras de Negócio. Regra do negócio, e não aquele papo de “o usuário tem que estar logado no sistema (sic)”. Pronto, disse.

    Fluxo Principal

    A conversa devidamente explicitada. Eu evitava o modelo com duas colunas por morrer de medo daqueles que acham que, para cada intenção do ator o sistema deve, obrigatoriamente, dar uma resposta. Desperdício imperdoável de tempo que culminava em obviedades assim: Ator: Indentificar Cliente / Sistema: Exibir nome do cliente. Terrível! Mas Coplien e Bjørnvig me convenceram de que, apesar dos mestres do óbvio, este modelo é realmente mais eficaz.

    Ainda assim, o espaço disponível para descrição dos passos do ‘caminho feliz’ segue exíguo para todos aqueles que não acreditam nos limites sugeridos por Coplien (máximo de 7 passos) ou Cockburn (máximo de 9 passos). Só evitei numerá-lo, como no modelo antigo, para deixar o formulário um pouco menos poluído.

    Fluxos Alternativos / Instruções para Testes

    Está aqui o trecho que mais me custou mais tempo. O número de fluxos alternativos pode ser muito grande, dependendo do caso de uso. Mas a questão não era só essa. Queria contemplar também um espaço para um tipo de Caso de Testes. Acho que consegui matar os dois coelhos. O trecho acima aparece na parte da frente do modelo e em metade do verso. Por isso eu disse que o verso pode ser impresso de forma independente. Ele também contempla outras regras de negócios e outros tipos de requisitos. Quando o espaço não for suficiente, basta imprimir ou utilizar mais páginas apenas com o verso do modelo. Aos campos.

    Indicamos o número do passo afetado e o tipo de registro (fluxo Alternativo o Teste). Na sequência, o motivo para o desvio ou então alguma instrução para a execução de testes. Há ainda uma coluna para comentários e outra para a indicação da iteração que deve contemplar a realização deste fluxo alternativo. Esta ideia combina bem com os slices propostos por Ivar Jacobson no referido artigo. Combina ainda mais com as sugestões apresentadas em “Lean Architecture” (em resumo: em um projeto tocado por um método iterativo, os incrementos são fluxos dos casos de uso. Ex: em uma iteração você entrega o fluxo principal, na seguinte dois fluxos alternativos e assim por diante).

    Se a ferramenta é escalável, como confirma Jacobson, o modelinho também deve ser. Daí a diagramação do verso, exibida abaixo.

    ?

    Utilizarei este modelo nas próximas edições de meus treinamentos. Acho que só depois de duas ou três experiências terei noção das alterações necessárias. Ou seja, novidades sobre o tema só no final de novembro. Enquanto isso, se você quiser brincar um pouco com o modelo, faça o download aqui: bit.ly/UCfinito. Claro que estou contando com seu retorno, experiências, críticas e sugestões. Desde já agradeço. Abraços!

    Obs.:

    1. Nunca antes na história deste blog o nome de uma imagem combinou tanto com o conteúdo. “Extracting Knowledge” é de autoria do HikingArtist e foi legalmente surrupiada no Flickr.
    2. Depois de meus canhotos rabiscos, todo o trampo artístico e de diagramação foi do mano Gus Vasconcellos, da Opção Artes Gráficas. Não sei o que seriam de meus rabiscos sem a colaboração dele.
  • Scrum ‘de Raiz’

    Scrum ‘de Raiz’

    Assim como existem o samba e a música sertaneja ‘de raiz’, também existe um Scrum ‘de raiz’: ideias, princípios e práticas que antecederam e deram forma e jeito ao framework como é conhecido hoje. Ajornada antropológica proposta por este artigo tem como principais objetivos: i) Revisitar os pilares do Scrum; e ii) Descobrir se estamos esquecendo alguma coisa importante em nossos trabalhos com ele. Posso adiantar: estamos!

    ?

    O Scrum foi provocado pelo artigo “The New New Product Development Game” publicado na edição de Jan-Fev/1986 da Harvard Business Review (HBR). Escrito por Hirotaka Takeuchi e Ikujiro Nonaka, o artigo descreve o sucesso de empresas como Fuji-Xerox, Honda e Canon no desenvolvimento de novos produtos. Os autores descobriram que as empresas analisadas compartilhavam seis características fundamentais:

    1. Instabilidade intencional: os times de projetos recebem apenas uma diretriz geral, normalmente uma metáfora indicando o tipo de produto que a organização espera receber. Não existem especificações detalhadas ou plano de projeto. Tensão, pressão, ambiguidade e outros efeitos colaterais da prática são compensadas por tolerância aos erros e pela autonomia concedida ao time.
    2. Times auto-organizados: a autonomia, citada acima, é uma das três condições para a criação de um time auto-organizado. Auto-transcendência (equipe parece buscar algo além de seu limite normal) e fertilização cruzada (time é multifuncional e todos aprendem com todos) são as outras duas.
    3. Fases sobrepostas de desenvolvimento: como em um jogo de rúgbi, onde todos correm juntos e passam a bola lateralmente. A metáfora oposta é a corrida de revezamento (desenvolvimento sequencial ou linear), com um participante aguardando a passagem do bastão por outro.
    4. “Multi-aprendizado”: ocorre o aprendizado multiníveis (indivíduo, time e empresa aprendem) e o aprendizado multifuncional (fruto da fertilização cruzada, citada acima. Um especialista é provocado a aprender coisas de outras áreas).
    5. Controle sutil: a autonomia de um time não significa falta de controle, apenas um tipo diferente de gerenciamento.
    6. Transferência do aprendizado: o item 4 acima trata do aprendizado que ocorre entre as partes interessadas de um projeto específico. Aqui se trata do aprendizado interprojetos e também da transferência da e para a organização.

    A derivação da lista acima que hoje conhecemos como Scrum, criada por Jeff Sutherland e Ken Schwaber, parece dar ênfase aos itens 2~5 em detrimento do primeiro e último tópicos. Jim Highsmith, mesmo sem dar nome ao boi, sugere algumas correções (ou avanços) no já comentado “Agile Project Management“. Craig Larman e Bas Vodde, em “Scaling Lean & Agile Development” (Addison-Wesley, 2009) tentam o mesmo. Apesar de valiosas, essas colaborações não são suficientes.

    Enquanto o Scrum era gestado, Takeuchi e Nonaka prosseguiram com suas pesquisas no campo da Gestão do Conhecimento¹. Do segundo a mesma HBR publicou, na edição Nov-Dez/1991, “The Knowledge-Creating Company“. Em 1995 a dupla voltou com outro artigo seminal, “The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation“. Por mais que a estagnação da economia japonesa – que já dura duas décadas – tente provar o contrário, esses artigos não poderiam ter sido ignorados como aparentemente foram (pelos “criadores” do Scrum e demais envolvidos com métodos ágeis). Porque eles recolocam e evoluem os temas tratados no trabalho original de 1986.

    A crítica sem rodeios nem meias palavras ao jeito ocidental – cartesiano e taylorista – de ver as organizações talvez explique o fato desses artigos terem passado em branco. Mas é exatamente nesta crítica que está seu grande valor. O tal ‘jeito ocidental’ vê as empresas como “mecanismos para processamento de informações”. Nonaka explica:

    “De acordo com essa visão, o único conhecimento verdadeiramente útil é o formal e sistemático – dados difíceis² (leia-se quantificáveis), procedimentos codificados, princípios universais. E as métricas-chave para mensurar o valor do novo conhecimento são similarmente difíceis e quantificáveis – crescente eficiência, custos mais baixos, melhor retorno do investimento (ROI).”

    Por outro lado, no modo oriental (ou japonês):

    1. Há reconhecimento e valorização do conhecimento tático;
    2. A questão não se limita a “gerenciar conhecimentos” mas, principalmente CRIAR conhecimentos;
    3. Entende que todos os colaboradores, e não apenas os gerentes e diretores, são potenciais criadores de novos conhecimentos; e
    4. Recursos e atividades são organizados e desenhados de forma a facilitar a criação e transferência de conhecimentos.

    Voltemos a um ponto chave que deixei um tanto solto acima: a área de especialização de Takeuchi e Nonaka é a Gestão (ou Criação) de Conhecimentos. Eles entendem que cada projeto é uma oportunidade única para criação de conhecimentos (leia-se Inovação). Por isso depositam boa parte de suas sugestões nas trocas e transformações de conhecimentos. O Scrum, até certo ponto, reflete bem a mesma preocupação. Através de suas reuniões diárias, de revisão (de iterações ou sprints) e retrospectivas. Mas ele peca ao desconsiderar ou dar pouca importância ao que existe fora do time de projeto.

    Takeuchi e Nonaka descobriram um tipo de organização que chamaram “hipertexto”. Convivência, confronto e troca entre a estrutura hierárquica (sistemas de negócios) e times de projetos (forças-tarefa) dão forma a uma “hiper-rede”. Uma rede que não se desliga nunca! Por que isso é importante e muito diferente do que vemos no Scrum?

    O Scrum instituiu um e apenas um ponto de contato (ou interface) entre negócio (estrutura hierárquica) e time de projeto: o Dono do Produto. Se por um lado esse “mecanismo” simplificou o processo de comunicação, por outro ele destruiu a permeabilidade e transparência que existem na proposta original da dupla japonesa. Repare no diagrama ao lado. Times de projetos e o negócio se comunicam constantemente. E essa comunicação não se dá através de um “ponto focal”. Acontece que os times são de fato multidisciplinares, compostos por pessoas de todas as áreas de negócio envolvidas. Takeuchi e Nonaka chegam a falar de times com 20~30 pessoas e um “núcleo duro” de 5 integrantes. Essas 15~25 pessoas “extras” são gente do negócio atuando na força tarefa. Gente que “leva e traz”, no bom sentido, o conhecimento necessário.

    Por favor, não estou sugerindo que a figura do Dono do Produto é desnecessária e muito menos que ela seja redondamente equivocada. Mas precisamos aceitar que ela é um “ponto único de falha” nesse sistema chamado Scrum. Suas vantagens (particularmente a esperada agilidade na tomada de decisões) não a livra de um risco potencial: a falta de conhecimento.

    Existem ainda outros dois fatores que diferenciam essa proposta do Scrum. Os times, apesar de levemente acoplados, mantêm comunicação constante. Sei que isso começou a ser tratado quando pipocaram questionamentos sobre a escalabilidade do Scrum. Aquele papo sobre “Scrum de Scrums” e coisa e tal. O fato é que esse patch não seria necessário se o desenho original³ fosse preservado. O segundo fator é a “Base de Conhecimentos”: aqui temos todo o conhecimento explícito acumulado a cada projeto. A ênfase no conhecimento tácito (e na comunicação direta entre times de projetos e o negócio) não significa o desmerecimento de tudo o que pode e deve ser explicitado (e documentado).

    Resumindo, eu vejo dois grandes problemas no Scrum que não existiriam caso seguíssemos acompanhando os trabalhos de Takeuchi e Nonaka:

    1. O “sistema” original é completo. Ele entende que quem cria conhecimentos são os indivíduos mas quem os amplifica é a organização. Times de projetos são sintetizadores desse conhecimento. O Scrum não pode ignorar ou tratar de forma simplista essas trocas;
    2. A ênfase em dados “duros” e conhecimento explícito (e mensurável) é a prorrogação de uma mentalidade herdada do século XX, de Taylor, Ford e afins. Um pensamento que desemboca em um absurdo que vi na forma de um cartaz no último Agile Vale realizado em São José dos Campos: “Se o miojo fosse ágil ficaria pronto em um minuto e meio”. O Scrum, lá na sua raiz, nunca prometeu a agilidade pela agilidade. Nunca foi uma questão de fazer de maneira ultra-rápida o mesmo trabalho. A busca cega por eficiência está nos desviando de forma muito preocupante do que é fundamental: fazer a coisa certa!

    ?

    Observações:

    1. Os dois artigos citados, de 1991 e 95, podem ser encontrados em “Gestão do Conhecimento“, de Hirotaka Takeuchi e Ikujiro Nonaka (Bookman, 2008). Aproveito a deixa para recomendar outro livro, mais completo, que apresenta a versão original (em inglês) do segundo artigo: “Knowledge Management: Classic and Contemporary Works“, editado por Daryl Morey, Mark Maybury e Bhavani Thuraisingham (The MIT Press, 2000).
    2. Ana Thorell, tradutora do primeiro livro acima, optou por “difícil” ao traduzir “hard”. Mantive a tradução original mas, logo abaixo, falei de “dados ‘duros’”. Não sei qual ficou pior.
    3. Assim como não sei se Takeuchi e Nonaka têm noção do belo monstro que ajudaram a criar, o tal de Scrum. É importante lembrar, antes que levem a culpa por alguma coisa, que eles não tinham a intenção de criar um framework para gerenciamento de projetos ágeis. Miravam a lua. É importante que nossos tiros, a partir do momento que são cópias ou derivações, não se contentem em atingir apenas o topo da montanha.
    4. “Tree-in-Pot” é o nome do cartoon de hoje. Pra variar, do HikingArtist.

     

  • UMA Resumida e outros Desabafos

    UMA Resumida e outros Desabafos

    Necessária revisão dos últimos artigos publicados. Motivadas por alguns comentários? Sim, mas principalmente pela falta de comentários. Uma breve introdução tentará justificar os “desabafos”. Na sequência, a reapresentação dos últimos artigos utilizando uma perspectiva um pouco diferente.

    ?

    Scientia Interruptus

    Triste verdade: no processo de construção de conhecimento, o {finito} é interrompido em 1/3 do caminho. Porque praticamente não há diálogo algum acontecendo. Agradeço demais as reações, retweets e os poucos comentários que aparecem. Mas eles raramente representam uma conversa construtiva – raramente agregam conhecimento novo. As poucas críticas, particularmente as mais recentes, utilizam um tom e uma agressividade que impedem qualquer tipo de interação civilizada. Ou então simplesmente detonam uma ideia sem propor nada em troca. É o malho pelo gosto do malho, puro e simples. Como esta casa é minha, eu poderia simplesmente eliminá-los. Opto por mantê-los porque não aprovo nenhum tipo de censura¹. Mas também na vã esperança de que reações extremadas incentivem novas discussões. Por enquanto, não funcionou.

    Queria um dia entender todo esse consumo passivo de informações em pleno século XXI, na era da interatividade. Desconfio que minha redação e meu “estilo” não sejam muito convidativos. Desconfio também que alguns temas simplesmente não merecem um dedo de prosa. Erros exclusivamente meus que vivo tentando corrigir. Mas, por enquanto, é apenas isso que tenho: desconfianças. Porque nem retorno sobre elas eu tenho. E não vou fazer “pesquisinhas” porque não acredito nelas. Pesquisa não é conversa. Pesquisas não substituem conversas.

    Meus artigos são teses. Mesmo quando desastrados, são convites para um bate papo. Antíteses são esperadas. Elas não precisam, necessariamente, negar toda a tese apresentada. Mas, obrigatoriamente, deveriam agregar valor – jogar conhecimento novo no ventilador. Só então seria possível uma SÍNTESE, que simploriamente descrevo como uma combinação do melhor da tese com o melhor das “anti-teses”. Por isso falei que o {finito} é interrompido em 1/3 do caminho da criação de bom conhecimento. Ele praticamente morre nas teses. Por exemplo…

    Arquitetura Lean & Ágil

    Uma das duas críticas apresentadas ao último artigo, UMA Modesta Arquitetura, dizia que aquele era papo de “viado, charlatão, chefe com desejo de ser superstar etc”. Mesmo com a melhor das boas vontades eu não conseguiria compor algo novo a partir de tão grosseira reação. Mas esta e outra crítica acertaram em um ponto: aquele artigo ficou longo demais. Apelarei para o outro extremo e tentarei resumi-lo no parágrafo abaixo.

    A arquitetura dos sistemas de uma organização deveria refletir exatamente aquele negócio. Quando olhamos para a arquitetura de um negócio vemos três grandes conjuntos: Objetivos, Estrutura e Processos. Nossos sistemas deveriam respeitar essa organização. Para: i)Viabilizar o uso de um vocabulário comum; ii) Separar aquilo que muda muito (processos) daquilo que muda menos (estrutura); e assim iii) Garantir a agilidade e flexibilidade requeridas em tempos de mudanças e hipercompetitividade. A proposta DCI (Data-Context-Interaction) vai exatamente neste caminho, de separação nítida entre forma e funcionalidades de um sistema. Na distinção entre o que o sistema É e o que o sistema FAZ. Sem saber (ou sem citar), esta proposta também combina com uma leitura recente da Teoria da Complexidade que sugere a separação do que desafia nosso entendimento (estrutura) daquilo que desafia nossa habilidade de prever (comportamento). Três campos (ou domínios) – arquitetura do negócio, arquitetura de software e teoria da complexidade – parecem sinalizar UMA visão unificada. Ainda modesta, mas bastante promissora.

    Gastei três mil e tantas palavras para explicar e detalhar o que descrevo no parágrafo acima. Acho que pequei pelo excesso e pelas redundâncias. Minha intenção única e exclusiva foi mostrar bases e origens de cada uma das três áreas que parecem pedir por uma leitura unificada. Mas este problema, o tamanho do artigo, é quase insignificante quando comparado com uma famosa sugestão contrária ao DCI.

    Intencionalmente deixei de citar uma proposta que parece bater literalmente de frente com as sugestões de Trygve Reenskaug, James Coplien e Gertrud Bjørnvig. O DCI sugere a criação de um “Modelo Anêmico”, um anti-padrão (anti-pattern) arquitetônico documentado por Martin Fowler nos idos de 2003. Ok, tenho certeza de que esta última frase não está correta. Mas eu fiz vista grossa para o escancarado conflito exatamente para receber reações e desafios. Se minha memória não me engana, Coplien também ignora o anti-pattern no livro “Lean Architecture“. Não me interessam mais os debates que acontecem lá fora. Queria ver assunto tão caro em agendas e grupos de discussão tupiniquins. Combustível não falta. Coplien, por exemplo, disse que “SOA is Dead!” Não me preocupa a acusação de charlatanismo. Mas a falta de debate é assustadora.

    Scrum “de raiz”

    A pequena série “Sistema de Blindagem Inteligente” (partes 1 e 2) também mereceu uma crítica. A colega Nara disse não ter visto “nada de extraordinário” em minha proposta. Eu não havia prometido nada do tipo. Mas temo ter desperdiçado a oportunidade de uma boa conversa. Temo que ela tenha entendido que eu propus simplesmente a inversão das prioridades dos times que atendem verticais daquele negócio. Que eles, os times, passariam a dedicar 80% e não 20% do tempo para atender projetos (ou demandas evolutivas). Não foi o que sugeri.

    Citei “organizações ambidestras” e outras referências para sustentar a sugestão de separação radical dos times que deveriam cuidar exclusivamente de projetos. Desta separação radical viria a desejável “blindagem”. Perdi a oportunidade, naquele momento, de citar uma referência que deve fazer muito mais sentido.

    Todos sabemos que o Scrum foi provocado por um artigo de Hirotaka Takeuchi e Ikujiro Nonaka, “The New New Product Development  Game”, publicado na Harvard Business Review de Jan-Fev/1986. Este artigo compila uma série de achados da dupla ao pesquisar o desenvolvimento de produtos em empresas como Fuji-Xerox, NEC, Canon e Honda, dentre outras. Os autores sugerem a adoção de um estilo “rugby” para desenvolvimento de produtos em detrimento do tradicional modo linear (comparado a uma corrida de revezamento). Takeuchi e Nonaka, em outros trabalhos, enriqueceram suas sugestões originais.

    Neste caso nos interessa principalmente a “organização hipertexto”, proposta apresentada originalmente em “The Knowledge-Creating Company” (Oxford University Press, 1995) e reapresentada em “Gestão do Conhecimento” (Bookman, 2009). A organização hipertexto é formada por três níveis: equipe de projetos, sistemas de negócios e base de conhecimentos. Esta “base” seria a síntese do conhecimento proveniente dos sistemas de negócios (hierarquia) e das forças-tarefa (equipes de projetos). Interessante destacar que, para os autores, a distinção entre projetos e o dia a dia seria algo bastante natural. Isso nos idos de 1995. E a gente aqui, correndo atrás de um “sistema inteligente de blindagem”.

    Encerro desconfiado de que o tema “Scrum ‘de raiz’” merece um pouco mais de espaço e atenção. Espero, sinceramente, que você me diga que sim (ou não). E espero, claro, que você não seja tão “binário”. Desde já agradeço. Inté!

    ?

    Observações:

    1. É claro que spams são totalmente censurados. Mas já fui obrigado a barrar outros comentários, infelizmente. Não se dá carona para gente desonesta.
    2. “Three Monkeys“, o cartoon utilizado, foi legalmente surrupiado do HikingArtist.
  • UMA Modesta Arquitetura

    UMA Modesta Arquitetura

    Modesta: moderada, sem afetação, sem exagero.

    Arquitetura¹: concebida com o propósito primordial de organizar espaço para determinada finalidade e visando a determinada intenção.

    Este artigo é uma modesta provocação. E uma tentativa de transcrever a palestra “Arquitetura do Negócio: Enxuta & Ágil” que apresentei no último Agile Vale. É que alguns assuntos pedem para ser espalhados. Se você se interessa por arquitetura corporativa, arquitetura de negócios, arquitetura de software, DDD, DSL, métodos ágeis e pensamento enxuto (lean), talvez encontre algo de útil no meio deste longo texto.

    ?

    Peço sua atenção para a definição de arquitetura acima. Particularmente para os termos espaço, finalidade e intenção. Quando arquitetamos algo, nós “organizamos um espaço para determinada finalidade visando a determinada intenção”. Preciso voltar também para um conceito que já apresentei aqui no {finito}, a Tríade Vitruviana. Ela fixa três critérios fundamentais para avaliação de uma arquitetura:

    • Firmitas: a construção é estável, robusta e sustentável;
    • Utilitas: a arquitetura é funcional; e
    • Venustas: é bela.

    A área de TI gosta de adotar termos de outras áreas de conhecimento. Seria legal se, além dos nomes, adotássemos também os conceitos básicos. Já tem um tempinho que acolhemos o termo “arquitetura”. Recentemente, passamos a falar bastante sobre Arquitetura Corporativa. Acho que indicamos que através dela “organizamos espaço para determinada finalidade e visando a determinada intenção”. Qual espaço?

    TI organiza dois espaços, a saber: i) Arquitetura Tecnológica – hardware, infraestrutura de rede e software básico. Significa o que a organização possui; ii) Arquitetura de Informações – bases de dados e repositórios de informações não estruturadas. Indica o que a organização sabe. Esses espaços são organizados “para determinada finalidade”. Qual finalidade?

    TI atende a ou oferece um sem número de finalidades, de funcionalidades. O faz através de sua Arquitetura de Sistemas, que representa todas as aplicações, ou seja, o que a organização faz. E faz esse tanto de coisa porque está “visando a determinada intenção”. Que intenção?

    Chegamos naquela parte da tal Arquitetura Corporativa que justifica tudo, inclusive a própria existência de TI. É a Arquitetura do Negócio, aquela que explica a intenção – para quem e porque a organização faz (oferece sistemas), sabe (informações) e possui (aquele tanto de ferro e software básico). No longínquo mundo ideal, não deveria haver um único centavo gasto em qualquer das três camadas inferiores que não fosse rastreável até a arquitetura do negócio, comprovando um benefício real e mensurável. Sendo assim, é factível supor que tudo começa (e deveria terminar) aqui, na Arquitetura do Negócio. Do que ela consiste?

    Todo e qualquer negócio, independente do porte ou ramo de atividade, é formado por quatro elementos básicos: Objetivos, Recursos, Processos e Regras. Mas estamos falando de Arquitetura do Negócio, o que nos leva novamente para a preocupação de “organizar espaço para determinada finalidade visando a determinada intenção”. O espaço que organizamos é a estrutura da empresa – as pessoas, instalações, móveis, veículos, enfim, todos os seus recursos². A finalidade é representada por todo o seu conjunto de processos, por toda a sua parte dinâmica. Finalmente, a intenção é o grupo de objetivos da organização. Colocando de outra maneira: organizamos os recursos (espaço) de uma empresa de forma que os permita executar ou viabilizar a execução de processos (finalidade) visando a alcançar determinados objetivos (intenção).

    Ao representar a arquitetura de um negócio, mesmo sem querer, sempre utilizamos três visões ou combinações entre elas. A visão do negócio trata dos objetivos, da intenção. A visão da estrutura nos mostra os recursos, o espaço. E a visão dos processos nos dá a finalidade. As representações podem ser ultrasofisticadas ou de uma simplicidade risível. Não é minha intenção debatê-las aqui, agora. Mas, para fins ilustrativos, entenda que um organograma é parte da visão da estrutura, enquanto um fluxograma pode compor a visão dos processos. Balanced Scorecards ou simples listas de objetivos representam a visão do negócio. O que nos interessa neste ponto é a “organização do espaço para determinada finalidade visando a determinada intenção”. Hora de agitar o coreto.

    Muito falamos sobre a dinâmica, a velocidade das mudanças, e a complexidade do atual mundo dos negócios. O que muda tanto? E o que é complexo? Será que tudo?

    Jurgen Appelo, no livro “Management 3.0” e falando sobre a teoria da complexidade, sugere um modelo para estudos: o modelo da Estrutura-Comportamento³. Ele escreveu que nos equivocamos quando intercambiamos os termos “complexo” e “complicado”. E afirma que o que é complexo não é passível de simplificação. Me esforçarei para deixar o papo menos maluco (e menos abstrato).

    Quando tratamos de uma estrutura, o que está em jogo é nossa habilidade para entendê-la. Portanto, uma estrutura pode ser simples ou complicada. Neste sentido um casamento, por exemplo, é uma estrutura simples. Ele envolve, na teoria e em seu início, apenas dois elementos. Por outro lado, uma empresa ou uma cidade possuem uma estrutura complicada – difícil de entender.

    Em outra dimensão está o comportamento e o que é exigida é nossa capacidade de prevê-lo. Um relógio, por complicado que seja (em sua estrutura), tem comportamento bastante previsível. Dizemos que seu comportamento é ordenado. Diferente do casamento, que apesar da estrutura simples, pode resultar em comportamentos bastante complexos. Nesta dimensão temos ainda uma terceira “ordem de grandeza”, o caos. O trânsito de nossas grandes cidades, por exemplo, tem comportamento caótico – ele é praticamente imprevisível. E, só para fechar o exemplo, a estrutura destinada para esse mesmo trânsito não tem nada de simples. Ela é complicada. Uma estrutura é passível de simplificação. Já o comportamento, com certa dose de boa-fé, poderia ser linearizado (o que é complexo ou caótico poderia ser ordenado).

    Coreto devidamente agitado? E o que esse papo sobre complexidade tem a ver com arquitetura? Tudo!

    A “estrutura” do papo acima é o espaço que organizamos. Voltando para a arquitetura do negócio, trata-se exatamente da visão da estrutura, de todos os recursos utilizados por uma organização. E a dimensão do comportamento representa a finalidade da arquitetura, as ações que ali devem ocorrer. No domínio (!) do negócio, refere-se à visão dos processos.

    Um negócio, qualquer negócio, é um Sistema Adaptativo Complexo. O modelo proposto por Appelo nos ajuda a estudá-lo. Sistemas de informação são igualmente adaptativos e complexos. O modelo “Estrutura – Comportamento” nos ajudaria a arquitetá-los? No mínimo, como tentarei mostrar abaixo, justificaria uma “nova” maneira de pensar.

    Quando falamos, geralmente reclamando, sobre a dinâmica dos negócios, devemos entender que o grande volume de mudanças ocorre na dimensão comportamental, ou seja, nos processos. Posso apelar para Pareto? Então vamos fixar que 80% das “mudanças organizacionais” (sic) referem-se às alterações na forma de trabalhar, nos processos de negócios. O restante significa, de fato, alteração na estrutura (demissões, remanejamentos, fusões & aquisições etc).

    Acima eu escrevi que também vivemos reclamando da complexidade dos negócios. Novamente o modelo proposto pelo Appelo nos ajuda a separar o joio (estrutura, no máximo complicada) do trigo (processos, de fato complexos ou até mesmo caóticos). Fiquei com vontade de usar outra metáfora.

    Ao desenhar sua casa, você separou generoso espaço (!) para montar seu sonhado home office (finalidade!). Mobiliou-o com tudo de bom e do melhor e ficou realmente mais produtivo (intenção!) naquela zona (no bom sentido) de conforto (no melhor sentido possível). Mas eis que vem a notícia de um filhinho não planejado e lá se vai o querido escritório de volta para a garagem. Aquele generoso espaço ganhará nova finalidade. Ele mudou? A menos que você tenha derrubado paredes e redimensionado outros cômodos, você não mexeu no espaço – na estrutura da casa. Foi só a finalidade daquele espaço que mudou.

    Uma estrutura, mesmo quando mal e porcamente concebida, é mais estável que o comportamento. Ou, colocando de outra forma, a estrutura é menos instável que os processos. Então, por que será que nossos sistemas de informação raramente refletem essa separação? Até que ponto nossa indisciplinada mistura de forma (espaço) e funcionalidade (finalidade) é responsável pelos altíssimos custos de manutenção e pela dificuldade de adaptação dos sistemas ditos “legados”? Prometo parar por aqui com as questões retóricas. O que vem a seguir é uma proposta para pensar arquitetura de sistemas de uma maneira diferente.

    Arquitetura Enxuta & Ágil

    Se não ficou claro, apesar (ou exatamente por causa) de minha verborragia, nosso objetivo é fazer com que um sistema reflita e respeite a separação entre estrutura e comportamento. Vamos diferenciar o que o sistema é do que o sistema faz.

    Já tem um tempinho que utilizamos classes para representar coisas do mundo real. Apesar de chamarmos isso de “Orientação a Objetos”, o fato é que nossa programação é mesmo orientada a classes. Não importa. Aprendemos nas escolas da vida que um objeto deveria encapsular sua estrutura (atributos) e comportamento (métodos). Temos outro probleminha aqui. Se desejamos representar elementos da estrutura do negócio, então deveríamos esquecer todo esse papo de encapsular comportamento. Essas classes e respectivos objetos que definem o que o sistema é devem ser ignorantes em relação a tudo o que se refira a ação. Quando muito, sabem um CRUDzinho básico. O cliente Mané, por exemplo, não sabe o que é comprar livro ou colocar livro no carrinho de compras. O Mané não sabe nada! Mas pode aprender!!

    Todas as ações, serviços ou funcionalidades, compõem o que o sistema faz. No diagrama ao lado, todas essas interAÇÕES são representadas por papéis (roles). Existem dois tipos: aqueles que sabem o que fazer (methodful roles) e aqueles que só fingem que sabem (methodless roles). A distinção entre os papéis que sabem (methodful) daqueles que fingem saber (methodless) é muito importante. Os últimos funcionam apenas como interfaces. E nós esperamos que as interfaces sofram bem menos alterações do que os métodos propriamente ditos. Novamente a intenção é separar nitidamente aquilo que muda com mais frequência daquilo que pouco se altera no decorrer do tempo. Mas, afinal de contas, do que tratam esses papéis? Simples, são eles que sabem comprar livro ou colocar livro no carrinho de compras, por exemplo.

    Pronto! Agora temos atores (classes e objetos dispostos no lado esquerdo do diagrama) e papéis. Falta dar-lhes um roteiro.

    Peraí Paulo: ou seu exemplo não é lá essas coisas ou então o papo é bem furado mesmo. Afinal, comprar livro ou colocar livro no carrinho de compras não são ações extremamente simples?

    Ações ordenadas ou bastante previsíveis, você quis dizer, certo? Vamos lá: imagine que nosso querido Mané, apresentado ali em cima, seja um cliente preferencial. Como tal, ele tem direito a descontos em todas as compras. Quando ele vê um livro, já sabe seu preço normal e o desconto que merecerá. Ao mesmo tempo, a loja já sabe que o Mané prefere pagar com cartão de crédito. O que significa, além de outras coisas, um prazo menor de entrega. Já o cliente (objeto) José é bem diferente: mal se identificou (a loja ainda não sabe nada sobre suas preferências) e está prestes a fazer sua primeira compra. Os ROTEIROS que Mané e José seguirão são consideravelmente diferentes. Apesar de ambos apenas desejarem comprar o último best-seller da Bruna Surfistinha.

    Ok, o exemplo continua meia-boca. Mas espero que você tenha entendido o fundamental: interAÇÕES bem distintas acontecerão em ambos os casos. Os atores José e Mané desempenharão papéis diferentes.

    Primeiro ponto, aquele que ficou aberto seis parágrafos acima: como Mané e José “aprenderão” a comprar livro ou colocar livro no carrinho de compras? Primeira “mágica”: aquele conhecimento (comprar ou colocar) será INJETADO nos dois clientes (objetos). O termo injetado é muito bom. Lembra-se como Neo, no filme Matrix, aprendeu a lutar kung-fu? Pois é, o conhecimento foi injetado na nuca! É mais ou menos o que estamos fazendo aqui, ensinando (em tempo de execução!) um elemento da estrutura a executar determinada ação.

    Não disponho de tempo, espaço e nem competência para entrar em detalhes técnicos desta sugestão. Só me cabe dizer, por enquanto, que tal “mágica” é possível tanto em linguagens OO mais antigas (como C++) quanto em modernosos dialetos mais dinâmicos (como Ruby). Já já te falo onde encontrar exemplos de código, se isso te interessa.

    De interesse mais geral deve ser nosso segundo ponto, gritado quatro parágrafos acima: o ROTEIRO. Agora ele merecerá outro nome, um pouquinho mais técnico: Caso de Uso. Estranho como algumas pessoas perdem o sentido da palavra “caso”. Gosto de provocá-las usando um termo caipirão, “causo”. Um “causo” é uma história curta, enxuta. Para nós, é uma história de interAÇÕES, sobre o USO de alguma coisa, sobre FUNÇÕES executadas. Portanto, nosso roteiro (ou script) é redigido na forma de uma especificação de caso de uso. E, em tempo de execução, este mesmo roteiro se transforma em um objeto. Objeto que tem um nome bem especial: CONTEXTO. Mané e José, nossos honoráveis clientes (objetos), desempenharão alguns papéis diferentes e outros semelhantes dependendo do Contexto.

    Tempo para uma breve releitura. Você ainda está aqui? Puxa, muito obrigado. Vamos lá:

    Mané e José mudarão muito pouco no decorrer do tempo. Alguns de seus atributos, como endereço ou telefone, podem ser alterados. Sua idade, com certeza, mudará a cada ano. Mas isso não significará nenhum tipo de mudança em sua forma. Já os papéis, as interações ou processos de negócios, podem sofrer mudanças com grande frequência. A porção mais volúvel de um negócio, suas regras, estariam praticamente todas concentradas nos papéis com real conhecimento (methodful roles). Assim, ao contrário do que vemos em grande parte dos sistemas de hoje (ou seria de ontem?), as mudanças ficam concentradas em um só lugar. Elas não gerarão impactos em um sem número de classes e outros elementos. Neste desenho, podemos agregar novas funcionalidades sem gerar praticamente nenhum impacto nos elementos já constituídos. Um novo cenário em um caso de uso é só isso, um novo roteiro – que costura e direciona como os atores desempenharão seus papéis em um novo contexto.

    Hora de dar nome e crédito à proposta apresentada acima. DCI, de Data, Context and Interaction, é o nome da criança. Criança mesmo, que mal tem cinco anos de vida. A primeira parte, Data (Dados), representa a estrutura (o espaço). Já as Interações representam as finalidades, a arquitetura funcional. E o Contexto, por fim, junta tudo. Este paradigma foi sugerido por Trygve Reenskaug, sujeito que tem em seu currículo outro padrão arquitetônico, amplamente conhecido e aceito: o MVC (Model-View-Controller). Já havia apresentado o tema aqui, quando comentei o livro “Lean Architecture“, de James Coplien e Gertrud Bjørnvig. Para você que quer ver e experimentar um pouco de código, creio que este livro seja o melhor ponto de partida.

    UMA Arquitetura

    Muito provavelmente é pura burrice de minha parte, mas quando vejo (de soslaio) altos papos sobre DDD (Domain-Driven Design), DSL’s (Domain-Specific Language) e afins, enxergo pouco ou nenhum NEGÓCIO. Eu sei, os conceitos são amplos demais e não pretendem apenas tratar de sistemas para negócios. Mas eu desconfio que um pouquinho de proximidade não faria mal nenhum, muito pelo contrário. Por isso o DCI, particularmente da forma como foi trabalhado por Coplien e Bjørnvig, me chamou tanto a atenção. Percebi ali uma nítida preocupação com o domínio, a complexidade e a dinâmica dos negócios. Mais que isso, vi naquela proposta uma extensão lógica e natural – o que tentei demonstrar aqui. Arquitetura do negócio e de sistemas podem ser vistas como UMA única arquitetura. É certo que estou sendo tendencioso e otimista demais. Se DCI demorar tanto quanto o MVC para “pegar”, com certeza não estarei por aqui para ver o resultado. O MVC é de 1978!

    Mas eu sou um incurável otimista. Ao testemunhar como ideias “agile” e “lean” se espalham, fico na esperança de ver mais conversas práticas e pragmáticas ganharem espaço nas agendas de todos os envolvidos com sistemas de informação. Preciso achar espaço para registrar uma preocupação. Será aqui mesmo: não basta ser “ágil” pra caramba e entregar na metade do tempo aquele maravilhoso produto, realizando um pseudo e imediatista valor. Teu ROI (sic), prezada(o) leitora, derretará mais rápido que bolsa de valores em tempos de crise se:

    1. Teu rebento, aquele produto, exigir mudanças estruturais toda vez que o negócio evoluir;
    2. O tempo tornar seu produto ilegível e incompreensível para os olhos de outrem;
    3. Seu produto pedir por duas ou três iterações toda vez que um novo cenário ou papel for necessário.

    É curioso e divertido acompanhar como a combinação dos termos “agile” e “lean” tem evoluído. Enquanto algumas dicotomias caem por terra, surgem novos confrontos e contradições. Coplien e Bjørnvig não hesitaram ao colocar várias lenhas nesta estimulante fogueira. Por exemplo:

    • Pensar antes não significa FAZER antes. E se você é realmente “lean”, você PENSA antes de fazer;
    • Pensar arquitetura != BDUF (Big Design Up Front).
    • Esse papo de postergar uma decisão para o último momento (responsável) é perigoso. Porque é difícil descobrir que momento é esse. Mais lógico é decidir na hora em que a decisão é realmente necessária e pronto.
    • Lean é baseado em “uma cultura de parar ou desacelerar de forma a obter qualidade no primeiro momento e maior produtividade no longo prazo.” (Jeffrey Liker, em “The Toyota Way” – McGraw-Hill, 2004);
    • Pensar “lean” é ver o todo – daí minha preocupação que acabou tornando este artigo um recorde pessoal (2.730 palavras até aqui!). Tentei mostrar como Arquitetura do Negócio e Arquitetura de Sistemas compartilham fundamentos (Espaço, Finalidade) e, principalmente, Intenção;
    • Pensar “lean” é ser sustentável – é ter sincera preocupação com o amanhã, com a evolução de um sistema que responde sem ressalvas nem soluços à dinâmica do negócio;
    • E ser “ágil”, nos ensina o Manifesto, é “responder a mudanças” (além de outras coisas, claro);
    • “TDD (Test-Driven Development) pode deteriorar a arquitetura”; e
    • Como sou um chato incorrigível, vou citar até uma lenha aparentemente menor: o que é mais fácil administrar e entregar, 300 e tantas histórias (User Stories) ou 20 e tantos casos de uso?

    ?

    Céus, quase três mil palavras e você ainda está aqui? Espero que de fato aproveite alguma coisa no meio de tanta prosa. Sabe o que é pior? A sensação de mal ter explorado todas as possibilidades do tema. Pior ainda? Aceitar o fato de que minha contribuição não irá muito além disso aqui. Não vou codificar exemplos e é pouco provável que eu participe, mesmo que como observador, do desenho de uma arquitetura conforme sugerida por Reenskaug, Coplien e Bjørnvig. Resta te pedir que me avise sempre que perceber qualquer coisa parecida passando por perto, ok? Tks!

    Observações:

    1. Trecho da definição de arquitetura proposta por Lúcio Costa e surrupiada da Wikipédia.
    2. Não é lá muito “ágil” esse negócio de chamar pessoas de recursos. É feio, eu admito. Mas, por favor, entenda que no frio da teoria uma pessoa pode ser sim um RECURSO utilizado por uma empresa para determinada finalidade e visando a determinada intenção. O que deveria de fato importar é que a empresa não trate uma pessoa da mesma maneira como trata uma mesa ou um carro enguiçado. Mas tem gente que gosta de briga e não será um recurso nunca! Nem no melhor sentido da palavra.
    3. Por uma questão de brevidade (haha!) me limitei a citar o modelo Estrutura-Comportamento proposto por Jurgen Appelo. Saiba que ele compara sua sugestão com dois modelos um pouco mais conhecidos, o Cynefin proposto por David Snowden e o modelo da Concordância & Certeza (Agreement & Certainty) proposto por Ralph Stacey. Jurgen insiste para que recebamos todas essas propostas sempre com um pé atrás: “todas estão erradas… mas algumas são úteis”.
    4. “Spil-skitse-tegning” é o cartoon que aparece lá no longínquo topo do artigo. Pra variar, é do HikingArtist.
    5. Ah sim, caso interesse, está aqui a apresentação utilizada no Agile Vale 2011. Como alertei a amiga Simone, ela deve ser ininteligível se não acompanhada da prosocopeia acima.