PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Lean

  • Dentro do Buraco

    Dentro do Buraco

    “Não morda o meu dedo, olhe para onde estou apontando.“
    – Warren McCulloch

    “Para o observador casual, definições do problema podem parecer desperdício. É tempo gasto longe do teclado e a educação ocidental nos ensina que estamos enrolando ou sendo improdutivos quando estamos ‘só conversando’. Mas o Lean é cheio de paradoxos como esse.”

    “Muito do Lean é baseado no Pensamento Sistêmico e uma definição de problema bem colocada pode levar o time para além de suas preocupações com a solução – para uma compreensão mais ampla do contexto.”

    “O Lean nos pede para reduzir tensões e inconsistências no sistema. A definição do problema articula um objetivo consistente. São comuns os projetos que sofrem porque seus participantes não estão resolvendo o mesmo problema. Uma definição de problema bem escrita oferece uma visão consistente de direção. Como tal, ela pode ser uma poderosa ferramenta para o time e para a gestão.”

    “Uma boa definição do problema pode funcionar como um catalisador para a auto-organização.”

    “Em uma verdadeira organização Ágil aqueles que são responsáveis pela solução do problema participam da definição do problema. Essa definição deve ajudar a canalizar a energia da organização na direção correta.”

    Lean Architecture | James Coplien e Gertrud Bjørnvig
    Wiley, 2010 – Págs. 68~74

    Eu sabia que não estava sendo original quando escrevi que Histórias – de Valor ou de Usuários – são catalisadoras. Só não lembrava a origem.“Antes de iniciar um sprint de criação-de-valor-para-o-cliente precisamos de um backlog inicial do produto. E para gerar esse backlog nós precisamos da visão do produto. Muitas organizações também acham útil a criação de um roadmap preliminar, definindo uma série de releases incrementais. Chamo as atividades que criam esses artefatos de envisioning ou product-level planning.”

    “O envisioning não deve ser confundido com um pesado e cerimonioso processo de planejamento. No Scrum, nós não acreditamos que podemos (ou devemos) conhecer todos os detalhes de um produto antes de começarmos. Entretanto, nós entendemos que o financiamento de um produto não pode começar sem uma visão; sem um entendimento adequado acerca dos clientes, das features e da solução em alto nível; nem sem uma ideia de quanto o produto vai custar.”

    “Não gastamos muito tempo ou esforço no envisioning porque queremos rapidamente passar do estágio do achismo – quando a gente pensa que conhece as necessidades dos clientes – para as etapas de feedback rápido – para os sprints de criação de valor.”

    Essential Scrum | Kenneth Rubin
    Addison-Wesley, 2013 – Pág. 287

    “O primeiro passo no Scrum é a elaboração da Visão do Produto pelo Product Owner.”

    Scaling Lean & Agile Development | Craig Larman e Bas Vodde
    Cap. 12 – Scrum Primer, por Pete Deemer & Gabrielle Benefield
    Addison-Wesley, 2009 – Pág. 311

    1. Uma VISÃO projeta um futuro onde determinado problema deixa de existir. Uma VISÃO assume o entendimento prévio desse problema.
    2. Ignorar a definição do problema e tratar o envisioning como o “estágio do achismo” (guessing, no original) é frágil e perigoso.
    3. Entender que a elaboração da VISÃO é responsabilidade exclusiva de um PO é detonar, logo de cara, uma boa oportunidade de formar um time de verdade.

    “A diretriz fundamental de qualquer sistema verdadeiramente enxuto consiste em estabelecer e entregar valor definido pelo cliente”.

    “ não devemos gastar esforços ou recursos antes de termos um profundo entendimento do valor definido pelo cliente.”

    Sistema Toyota de Desenvolvimento de Produto | James Morgan e Jeffrey Liker
    Bookman, 2008 – Págs. 45~46

    “A característica organizacional definidora do modelo do Spotify é o conceito de squads com ‘baixo acoplamento e alto alinhamento’. A tese central aqui é que ‘alinhamento permite autonomia – e quanto maior o alinhamento, mais autonomia é possível dar’. É por isso que a empresa passa tanto tempo alinhando todos com objetivos e metas antes de iniciar um trabalho.”

    Tempo Talento Energia | Michael Mankins e Eric Garton
    figurati, 2017 – Pág. 163

    1. A distância que separa a Toyota do Spotify é a mesma que separa o Japão da Suécia. Mas uma coisa elas parecem ter em comum: tempo pra pensar.
    2. Não é curioso que esse tempo para pensar não seja considerado trabalho? Repare na frase destacada no último parágrafo acima. Coplien e Bjørnvig, citados lá no início, já haviam alertado para essa característica bem ocidental de não relacionar esse tipo de conversa com trabalho.

    “Quando você dispara qualquer coisa nova, há forças te puxando para todas as direções. Há coisas que você pode fazer, coisas que você gostaria de fazer e coisas que você precisa fazer. Comece pelo que precisa ser feito. Comece pelo epicentro.”

    Rework | Jason Fried & David Hansson
    Crown Business, 2010 – Pág. 72

    “Tome uma grande decisão sobre sua Visão de forma antecipada e todas as futuras pequenas decisões se tornarão bem mais fáceis.”

    Getting Real | 37signals
    37signals, 2006 – Pág. 43

    “Todo o trabalho com requisitos é precedido por algum tipo de processo de iniciação: alguém tem uma ideia de que algo deve ser desenhado e construído.”

    “Se não formos cuidadosos, a ideia inicial vai colocar todo o processo em um caminho improdutivo do qual nunca vamos nos recuperar. Se os participantes não começarem pensando em conjunto, vamos perdê-los antes de ganhá-los.”

    “Como podemos sintetizar a grande variedade de pontos de partida potenciais em uma plataforma única e sólida para a exploração de requisitos? Uma solução possível é entender cada projeto como uma tentativa de resolver algum problema e então reduzir cada ponto inicial a uma forma comum de descrição do problema.

    “Um problema pode ser definido como: A diferença entre as coisas conforme são percebidas e as coisas conforme são desejadas.”

    Exploring Requirements: Quality Before Design | Donald Gause e Gerald Weinberg
    Dorset House, 1989 – Pág. 49

    “A palavra problema sempre significa algo ruim, como em ‘Houston, temos um problema’ Mas as inovações bem sucedidas sempre envolvem mais atenção ao problema do que às soluções. Einstein um dia disse, “Se eu tiver 20 dias para resolver um problema, gastarei 19 para defini-lo”.

    The Myths of Innovation | Scott Berkun
    O’Reilly, 2007 – Pág. 127

     

    “O problema não é o problema. O problema é a sua atitude em relação ao problema.”

    – Capitão Jack Sparrow

    1. Pois é, terceirizei a argumentação. Parti dos originais e a tradução é livre, provavelmente enviesada e eventualmente desastrada. Por  favor, não morda o meu dedo.
    2. Se você não entendeu minha motivação, por favor, veja o artigo anterior.
    3. Se tem o que acrescentar, por favor, comente!
    4. Aquela foto bem sacada de dentro do buraco é da Alexandra Brovco.
  • O Buraco Comum

    O Buraco Comum

    Não importa se é um bug ou característica programada. O fato é que os métodos e frameworks mais populares – particularmente Scrum e Kanban – tropeçam no mesmo buraco. Apesar de suas imensas diferenças, essas propostas são omissas ou relapsas no mesmo ponto. No distante 1986 Fred Brooks nos alertou¹:

    “A correta definição do que precisa ser feito é a etapa mais difícil do desenvolvimento de sistemas. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.”

    O que fizemos de lá para cá?

    • Distorcemos todos os currículos relacionados com a formação de engenheiros e analistas de sistemas. Enfatizamos o domínio da solução – programação e mais programação – em detrimento do domínio do problema.
    • Mas a Academia, apressada, estava apenas seguindo o mercado. Um mercado que inventou, em meados dos anos 1990, um tal de analista-programador. Isso tem reflexos negativos até hoje. Basta ver a reincidência de um álibi fajuto: “o cliente/usuário nunca sabe o que quer”. Quem aprendeu a perguntar? Quanta ajuda o cliente/usuário tem merecido?
    • De repente, ganhamos Agilidade. Com muitas propostas que parecem ser “do desenvolvedor, pelo desenvolvedor, para o desenvolvedor”. A coisa só piorou.
    • E tocou o fundo do poço quando alguém acreditou que um Business Model Canvas –  uma cortina feita de papel sulfite – seria capaz de esconder aquele imenso buraco.
    • Oras, e se o buraco for apenas uma hipótese? Vamos todos fingir que o buraco não existe; Ou é parte da decoração; Ou é só a opinião de alguém.
    • Por fim, se o tal Upstream Kanban pretende, ainda que parcialmente, tratar do domínio do problema, então ele não pode começar se apresentando como um “processo de triagem”. Que vai da síntese para a análise? Fixando CONWIPs?!?²

    A Acusação Comum

    Um efeito esquisito do movimento Ágil, que contradiz sua intenção de ser Sistêmico, é a percepção generalizada de que tudo o que não é construção é desperdício. James Coplien e Gertrud Bjørnvig reclamam disso em Lean Architecture (Wiley, 2010). Peter Morville, falando de Arquitetura de Informações, relata o mesmo problema (Intertwingled, 2014). E o que dizer da Análise de Negócios? Que ela deu um tiro no pé quando publicou uma Extensão Ágil. Confessou uma culpa que não deveria ter. Pau que nasce torto…

    A acusação ficou chique e mereceu até sigla: BDUF (Big Design Up Front). É importante destacar que a acusação não é vazia. É preciso lembrar o contexto que motivou o Manifesto Ágil. Era comum, naquele tempo, um mal conhecido como Analysis Paralysis. A burocracia emperrava pacas. Projetos entregavam bulhufas.

    A diferença entre o remédio e o veneno é o tamanho da dose. Erramos a mão e criamos outro mal, a Agile Death Spiral. Sprints sem fim ou fins. Pivots mil. Um desastrado foco na eficiência que ignora o primordial: ao fazer a coisa errada do jeito certo, só estamos acelerando rumo ao desastre.

    Entre a cascata congelada no tempo e o pós-moderno ciclone da morte deve haver um caminho.

    Equilíbrio

    A sugestão do Yin-Yang é de Peter Morville, no livro já citado. A imagem combina bem com a matriz apresentada no artigo anterior. Que esteja subentendida a necessidade de iterações. O ícone também informa que há construção nos momentos iniciais. E que não é proibido rever o problema e repensar os planos nos momentos seguintes.Esse equilíbrio bem zen seria perfeito se o alerta do Brooks não continuasse verdadeiro: aquela primeira metade (escura) é a mais crítica para o sucesso de um projeto ou produto. Mas ela não existe no Scrum, por exemplo³. O que nos levou a entender que bastaria puxar para o domínio do problema o mesmo esquema utilizado no domínio da solução. Vêm daí os sprints 0, -1 etc. Essas iterações podem ser úteis para a realização de spikes (experimentos), configuração do ambiente e coisas do tipo. Mas não têm nada a ver com o domínio do problema. O que é conhecido como grooming também não.

    Sprints com duração fixa de uma, duas ou quatro semanas fazem muito sentido nos trabalhos de DESENVOLVIMENTO e ENTREGA. Mas viram camisas de força nos trabalhos de DESCOBERTA e EXPLORAÇÃO. Nesses momentos, é comum a necessidade de cinco ou dez iterações em uma única semana. Marty Cagan, em Inspired (Wiley, 2017) fala em até vinte iterações. Jake Knapp, em Sprint (Intrínseca, 2016), nos mostra um ciclo completo acontecendo em uma semana. Enfim, a variedade aqui é grande. E necessária.

    O Design Thinking nos oferece ampla variedade de métodos e ferramentas para o Domínio do Problema. Não foi por outro motivo que Jonny Schneider, da Thoughtworks, propôs a seguinte combinação:

    • Design Thinking: para explorar o problema
    • Lean: para construir a coisa certa
    • Agile: para construir do jeito certo

    Legal. Mas o Manifesto Ágil não fala em eficácia logo no seu primeiro princípio? As propostas Lean não parecem preocupadas com eficiência? O Design Thinking não tem o que contribuir para o domínio da solução? A ideia do Schneider é promissora. A mensagem “Lean E Agile” ao invés do OU é correta. Mas a divisão de responsabilidades proposta acima não faz o menor sentido. 

    Acho que nós precisamos de outro enfoque, mais amplo e inclusivo. Precisamos de um modelo que incorpore, sem puxadinhos, uma legítima preocupação com o domínio do problema. Que faça a gente “se apaixonar pelo problema, não pela solução“.  Bom tema para o próximo artigo.

    Notas

    1. No artigo No Silver Bullet, transformado em capítulo da edição comemorativa de The Mythical Man-Month (Addison-Wesley, 1995). Este trabalho, lançado originalmente em 1975 (!), acaba de ganhar nova edição em pt-br: O Mítico Homem-Mês (Alta Books, 2018). Parafraseando Brooks: “a longevidade desse livro atesta que a gente continua caindo nos mesmos buracos…”
    2. São algumas sugestões apresentadas por Patrick Steyart em Essential Upstream Kanban.
    3. Que fique claro: não se trata de um bug do Scrum. A omissão é intencional. E só vira um problema se a gente a ignorar. Ou, pior ainda, se a gente esticar o Scrum para cobrir o buraco.
    4. “Se apaixone pelo problema, não pela solução” é uma das dicas de Marty Cagan em Inspired (Wiley, 2017).
    5. hole in the wall é o título da óbvia imagem de hoje.
  • Checkup Ágil

    Checkup Ágil

    Como um médico sádico vou perguntar onde dói e dar repetidas cutucadas ali. Não me leve a mal. Se você está no início de uma Transformação Ágil ou brigando com seus fins e meios, é bom saber o quão saudáveis estão você, seu time e sua organização. Como estão os seus sinais vitais? Aliás, você sabe quais são eles?

    Valor

    O Manifesto Ágil diz que a “nossa principal prioridade é satisfazer o cliente através da entrega adiantada e contínua de software de valor”. Fica por nossa conta descobrir o que significa software de valor. E entender que existem mais valores em jogo: há o VALOR PARA O CLIENTE, claro, mas não podemos ignorar o VALOR PARA O NEGÓCIO e o possível VALOR PARA O TIME. Mais que isso, é crucial entender as relações entre esses valores.

    Apesar das diversas e desastradas manifestações ao contrário¹, VALOR é o nosso mais importante sinal vital. Mas, como vimos, não há um valor único. Muito menos um entendimento compartilhado sobre o que ele significa. Vamos por partes.

    Valor é a medida da importância de algo. Até que ponto aquilo que vale para o seu negócio (departamento ou time) é valorizado pelo seu cliente (ou usuário)? Convenhamos, há poucas chances de acordo ou coincidência. Por isso não devemos confundir VALOR PARA O NEGÓCIO com o VALOR PARA O CLIENTE e/ou USUÁRIO. Cada um puxará a sardinha para o seu lado. Todos repletos de razão.

    O que significa VALOR PARA O NEGÓCIO? Mark Schwartz, em The Art of Business Value (IT Revolution Press, 2016), escreve que o valor para o negócio é “uma hipótese formulada pela liderança sobre a melhor maneira de realizar os grandes objetivos da organização”. Hipótese? Está aqui um terrível legado da moda Lean Startup: parece que tudo virou hipótese. O que tem valor para você é apenas uma hipótese? Duvido. Mas, como comprova o livro do Schwartz, quanto mais pessoas envolvemos, mais esse papo sobre valor fica variado, estranho e difícil.

    Donald Reinertsen (em Managing the Design Factory – Free Press, 1997) tem uma navalha para cortar toda essa variedade: “somos apenas filósofos enquanto não começamos a usar números”. Então, vamos aos números!

    Números

    Como você mede e apresenta o VALOR PARA O NEGÓCIO? Quais números fazem mais sentido? ROI (Retorno sobre o Investimento) e NPV (Valor Presente Líquido), por exemplo, são proxies que se sustentam em previsões. Nós humanos não somos muito bons nisso, em fazer previsões. Segundo Schwartz, “ROI e NPV são o waterfall do mundo financeiro”. Ainda mais importante: o cálculo de ambos, ROI e NPV, exige um numerador que é a representação do valor. Oras, então por que não nos contentamos com ele?

    O uso do Custo do Atraso (CoD – Cost of Delay) é defendido por Reinertsen e Schwartz. Mas ele também depende de uma definição prévia do Valor. Se não sabemos quanto vale, como podemos afirmar ou ao menos prever o custo de seu atraso? Estamos andando em círculos?

    ROI, NPV, CoD e afins representam hipóteses. Carregam incertezas e podem, dependendo do nível de sofisticação, dificultar a comunicação entre os envolvidos em determinada iniciativa. Não pretendemos filosofar. Mas que valor tem uma sequência de cálculos que poucos entendem? É sempre bom relembrar o décimo princípio do Manifesto Ágil: “Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.” Conseguimos exprimir o VALOR PARA O NEGÓCIO de forma simples e direta?

    Histórias de Valor

    Como a Natureba S/A
    nós precisamos de um app que permita que as nossas consultoras registrem e transmitam pedidos em tempo real
    para encurtar o ciclo de vendas em 50% e cortar algo entre R$15M e R$25M dos custos anuais de processamento de pedidos.Como a Webchuteira LTDA
    nós precisamos de um programa de fidelidade vinculado aos sistemas sócio-torcedor dos grandes clubes nacionais
    para aumentar o nosso market share em 40% e o faturamento em, pelo menos, R$100M no próximo ano.Não é curioso que essa proposta simples, derivada do formato clássico das User Stories, seja tão pouco conhecida? Aliás, por favor, não se apegue ao formato. O importante aqui é o que essas histórias nos contam. Conversaremos mais sobre isso no próximo artigo. Porque agora é um bom momento para um autoexame.

    Autoexame

    Você e seu time sabem quanto VALOR estão criando e entregando?

    Se sim:

    • Esse entendimento é compartilhado por todas as pessoas envolvidas?
    • A sequência do roteiro (roadmap e backlogs) reflete nitidamente essa preocupação com a entrega antecipada e contínua de valor?

    Se não:

    • O que diabos está orientando as milhares de decisões que vocês tomam todo santo dia?

    Notas & Esculachos

    1. D’ A Startup Enxuta, de Eric Ries (Leya, 2012), ganhamos essa perigosa e triste mania de achar que tudo é hipótese.
    2. De Jeff Sutherland, cocriador do Scrum, herdamos o peso da promessa do título de seu último livro: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo. O sonho dos tayloristas deveria ser o pesadelo dos agilistas. Afinal, estes se comprometeram com outra arte, a de “maximizar a quantidade de trabalho que não precisou ser feito”.
    3. No Kanban, de David Anderson (Blue Hole, 2010), aprendemos uma “Receita de Sucesso” que só permite conversar sobre VALOR no penúltimo passo de um total de seis. Orientado por uma mentalidade que não tem muito a ver com o trabalho criativo, o último passo da tal receita ainda pede que “ataquemos as fontes de variabilidade”. Não surpreende que o mesmo autor ressuscite agora uma conversa sobre Modelos de Maturidade. O Kurt Cobain vem junto? No carro preto do Ford? Nevermind…
    4. Stickynotes, de Martijn Veening, ilustra este artigo.
  • Vídeo: Imagens da Organização

    Vídeo: Imagens da Organização

    Como você enxerga o seu negócio? E como você o explica? Quais metáforas e analogias te ajudam? Elas são eficazes?

    A sua organização é viável? Como ela estará quando a crise passar? O que lhe diz isso? A contabilidade? Um canvas? Sério?

    Este vídeo mostra um jeito diferente de olhar, desenhar e diagnosticar negócios. Veja como um modelo bem pensado pode trazer novas questões, perspectivas e possibilidades.[videoembed url=”https://youtu.be/Bz3dwRu9Kyk”]

    Observações

    • A aula foi transmitida ao vivo no dia 26/7/2017.
    • Existem algumas pequenas falhas no vídeo. Peço desculpas por isso.
  • 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.

    ?

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

     

  • Sistema de Blindagem Inteligente, Parte II

    Sistema de Blindagem Inteligente, Parte II

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

    ?

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

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

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

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

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

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

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

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

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

    Algumas Referências para a Alternativa #3

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

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

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

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

    Epílogo

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

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

    ?

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

    Lean Architecture

    Autores: James O. Coplien e Gertrud Bjørnvig. Gertrud tem mais de 20 anos de experiência em desenvolvimento de sistemas e é especialista em requisitos Ágeis. James é pioneiro em projetos OO, padrões de arquitetura e desenvolvimento Ágil de software. É autor, dentre outros títulos, de “Organizational Patterns of Agile Software Development” (Prentice-Hall, 2004).

    Editora: Wiley (2010).

    Site: LeanSoftwareArchitecture.com

    Do que se trata: Arquitetura de Software, pensada e construída segundo princípios Lean e Agile.

    Indicado para: Arquitetos, Desenvolvedores e afins. Sim, eu entrei de gaiato no navio (porque há tempos não arquiteto nem programo). Mas gostei do que vi, como testemunho abaixo.

    Contra-indicações: Quem não conhecer o mínimo de OO, arquitetura de software e que tais sentirá uma certa dificuldade. Quem acha que arquitetura é burocracia, BDUF ou conversa pra boi dormir terá dois tipos de reação: espanto (positivo) ou um notável desconforto. Indiferente, acho que ninguém fica.

    Breve resenha: Eu não pego um livro (técnico) que não fale sobre o que precisa ser feito e/ou gerenciamento desde os idos de 2005 e 2006, quando cismei de estudar e falar sobre SOA, Reuso e afins. Acontece que o choque do livro anterior, “Management 3.0“, foi forte demais. Vai demorar para outro livro sobre o tema me abalar tanto. Resolvi mudar de assunto. E decidi que era hora de ver o que o “outro lado” anda fazendo. Não pesquisei muito até decidir pelo livro do Coplien e da Gertrud. Mesmo sabendo que encontraria linhas de código (em Java, C++, Ruby e outras) e conceitos que talvez fossem grandes demais para minha cabecinha.

    O que me chamou a atenção foi exatamente a presença da Gertrud como co-autora, dada sua especialização em requisitos. Desconfiei que não seria um livro tradicional sobre arquitetura de software. E estava certo. Vou arriscar um resumo em um parágrafo:

    Se você é verdadeiramente Ágil, a arquitetura projetada por ti deve saber acomodar mudanças. Não só em tempo de projeto, mas durante todo o ciclo de vida de um sistema. Para tal, desde o início você deve saber distinguir coisas que mudam com menos frequência daquelas que mudam ‘quase todo dia’. Os autores sugerem uma divisão bem simples: O-que-o-Sistema-É é uma parte mais estável, é a forma – o pensamento do usuário; O-que-o-Sistema-Faz é a porção mais dinâmica, mais suscetível a mudanças, é o comportamento – a ação do usuário. O respeito pelo ‘modelo mental do usuário’ e a preocupação em fazer com que todos os elementos da arquitetura sejam representações fiéis deste modelo guiam todo o livro. Os letrados a antenados já devem ter desconfiado que esse papo todo desemboca no uso dos padrões MVC-U (Model-View-Controller-User. Não se incomode, é o mesmo velho MVC demonstrando simpatia pela parte mais importante do problema) e seu novo complemento chamado DCI (Data, Context and Interaction), duas crias de Trygve Reenskaug.

    Resumo dado, tempo para outras considerações. Sim, esse papo de “representação fiel do modelo mental do usuário” rola, sem muito sucesso, desde a segunda metade da década de 1960 (quando surgiu OO). E sim, letrados e antenados não devem ver muito valor no livro. Como eles não são tantos assim, como atestam as aplicações que vemos por aí, o livro deve atrair um bom público. O público nerd, tratado exatamente desta maneira no texto, deve se satisfazer com as dezenas de páginas (de um total de 357) com puro código. Além de três capítulos nomeados “Coding it Up …”, o livro dispõe de seis apêndices tratando um mesmo exemplo em Scala, Python, C#, Ruby, Qi4j (segundo os autores, a melhor forma de implementar DCI em Java) e Squeak. E, como já coloquei, C++ e Java não são ignoradas. Se eu curti esse tanto de código? Olha, deu pra lembrar porque não programo mais. Mas, o código é bonito, elegante.

    Aliás, a proposta como um todo é bonita (e ver Beleza em coisas assim é atestado inconteste de que um pouco de sangue nerd ainda corre nestas veias). Sempre avalio uma sugestão de arquitetura através da tríade vitruviana: firmitas (robustez), venustas (beleza) e utilitas (utilidade / funcionalidade). Os autores, pelo menos na teoria, passam no teste do Vitruvius. E insistem em nos lembrar, pelo menos uma dúzia de vezes, a Lei de Conway.

    Para a turma d’o que precisa ser feito: Além do primeiro capítulo, uma Introdução, outros quatro ‘falam’ com a turma do negócio, analistas, donos de produtos e afins. São eles: “3 – Stakeholder Engagement“, “4 – Problem Definition“, “5 – What the System Is, Part I: Lean Architecture” e “7 – What the System Does: System Functionality“. Vou destacar os pontos que mais me chamaram a atenção.

    Gostei muito da separação incondicional de o-que-o-sistema-É de o-que-o-sistema-FAZ. Quando estudamos um negócio, também devemos ter esse tipo de preocupação. Separamos a Visão da Estrutura da Visão dos Processos, cientes da maior complexidade e volatilidade da segunda. Costumo dizer em meus treinamentos que a Visão dos Processos ocupará, no mínimo, 70% do tempo de um analista de negócios. Acontece que a aplicação tradicional ou indisciplinada de conceitos OO, em determinado momento, mistura tudo. Através do padrão DCI essa separação é sempre respeitada. Entre a estrutura (Data, o D de DCI) e o-que-o-sistema-FAZ (Interaction), sempre há um Contexto. E um Contexto é uma representação fiel de… um Caso de Uso!

    Qual não foi minha surpresa quando vi os autores ‘ressuscitando’ as Especificações de Casos de Uso. Segundo eles, de forma bem direta, o mundo Ágil reinventou a roda com as Histórias de Usuários e todos os seus ‘complementos’ (Mapas de Histórias, Dependências, Restrições, Test Cases etc). Casos de Uso oferecem, segundo os autores, consolidação de todas as informações necessárias para a construção d’o-que-o-sistema-FAZ. Há muito em comum entre a sugestão do livro e o modelo de casos de uso que aplico. Por exemplo: “O Fluxo Principal não deve ter mais que 7 passos!”; “Questões sobre interface do usuário e projeto do sistema são melhor representadas em outras ferramentas, não em casos de uso“. E por aí vai. E vai tão longe que merecerá um artigo específico.

    Por ora, fica minha curiosidade em saber como os desenvolvedores tupiniquins estão vendo a proposta. Fiz uma breve pesquisa no Google e em alguns grupos de discussão e não vi uma única menção ao termo DCI. Como a comunidade Ruby só faz crescer por aqui, pensei que acharia algo. Mas talvez eu não tenha procurado direito. Lá fora as reações são variadas e algumas bem iradas, como mostra esta thread. Aliás, estou para ver o dia em que novas ideias de nossa área não virarão um Fla X Flu.

    Enfim, duas coisinhas que me incomodaram: i) Não há um único diagrama UML no livro. Mesmo que os autores defendam fervorosamente a ‘modelagem com código’, deveriam entender que um ou outro diagraminha poderia facilitar a compreensão de alguns conceitos; ii) SOA morreu? Sinceramente, não esperava ler um livro sobre arquitetura de software escrito em 2010 que praticamente passa em branco pelo assunto. Os autores até justificaram no início do livro a ausência, mas não foram muito convincentes. Ou, de fato, SOA morreu?