TOC em Cores

“Assim como a transição da fotografia em preto e branco para a em cores é tão profunda,
a transição da modelagem em preto e branco para a em cores é impressionante.”

Coad, Lefebvre, De Luca

Corria o ano de 2003. Eu já estava pesquisando e praticando metodologias ágeis para desenvolvimento de software desde 1999, mas desde 1992 eu utilizava a Programação Orientada por Objetos na minha prática de desenvolvimento de software. O próximo passo natural naquela época era, claramente, começar a estudar técnicas de Análise e Projeto Orientados por Objetos, para aplicar uma mentalidade única em todo o ciclo de vida do desenvolvimento. Eu experimentei diversas metodologias, com diferentes graus de sucesso e satisfação.

Foi em 2003 que eu descobri a FDD – Feature Driven Development (Desenvolvimento Guiado por Funcionalidades), uma metodologia completa para a Gestão Ágil de Projetos e desenvolvimento de software. A FDD é uma mistura muito inteligente de um método sólido de Engenharia de Software orientado por objetos, conhecido como “O Método Coad”, cujo nome é devido a Peter Coad, e de uma prática de sucesso para gerenciamento de projetos desenvolvida por Jeff De Luca, um gerente de projetos australiano.

Mas o que a FDD tem a ver com a TOC? Para mim, muito! Primeiro, foi nessa mesma época que eu fui apresentado à TOC (Theory of Constraints, Teoria das Restrições) por John Mac Felsing, co-autor do livro “A Practical Guide to Feature Driven Development”, a bíblia da FDD. Mas o ponto onde quero chegar neste artigo está relacionado a uma técnica que, embora não seja obrigatória ou exclusiva da FDD, faz muito sentido e é extremamente útil: a UML em Cores.

Peter Coad foi (bom, em minha opinião ainda é) um modelador, arquiteto e estrategista de sistemas muito talentoso. Ele desenvolveu algumas metodologias de desenvolvimento de software orientado por objetos, incluindo processos, guias e notações gráficas, durante as décadas de 1980 e 1990. Ele também desenvolveu ferramentas CASE (Computer Aided Software Engineering, Engenharia de Software Auxiliada por Computador) para agilizar e automatizar as atividades de modelagem de uma equipe de projeto. Sua última e mais conhecida ferramenta de modelagem é o Together, agora um produto da Borland, desde a aquisição da TogetherSoft (empresa de Peter) em 2002.

Após décadas de experiência em modelagem, em domínios de negócios bastante diferentes, ele foi contratado em 1997 como o Arquiteto-Chefe para um projeto desafiador em Cingapura, onde ele propôs e testou a técnica da UML em Cores. Entretanto, mais do que colorir a UML, Coad também propôs o uso de arquétipos e descreveu suas propriedades, comportamentos e relacionamentos comuns.

Depois de obter mais experiência tanto com os modelos de software quanto com as árvores da TOC, eu tive a idéia de aplicar a técnica das cores aos Processos de Raciocínio da TOC, vindo daí o título “TOC em Cores”.

Por que usar cores?

Deixarei que Peter e seus colegas respondam esta pergunta para nós. As citações vêm do “Livro Colorido” e os destaques são meus:

“Preto e branco comunicam informação básica. A cor estende a mão e agarra você.”

“Em setembro de 1997 nós começamos a construir modelos com as quatro cores das notinhas Post-It: rosa, amarela, verde e azul – uma para cada arquétipo. Os desenvolvedores e especialistas no domínio, iniciantes na construção de modelos na equipe, comentaram várias vezes ao longo do caminho: ‘Mas como vocês conseguiam criar modelos sem usar as cores?’ Isto chamou nossa atenção! Então nós desenvolvemos esta técnica na prática, publicamos os resultados iniciais e apresentamos esta abordagem num tutorial da OOPSLA ’97. Como é frequentemente o caso, a prática veio antes da teoria. Ao vermos estas idéias funcionarem tão bem na prática, começamos a investigar a cor e por que ela parece ter um efeito tão profundo na construção de modelos melhores.”

“A cor nos fornece uma maneira de codificar camadas adicionais de informação. O uso sábio da cor aumenta a quantidade de conteúdo que podemos expressar.”

“E o mais importante é que se pode usar a cor para adicionar camadas de novo conteúdo aos modelos. Essas camadas são visíveis à distância, de modo que a 'grande figura' do conteúdo do modelo possa ser enxergada mesmo antes de se começar a ler os detalhes. Nós chamamos esse efeito de 'camadas espaciais', significando que um modelo é capaz de entregar uma visão geral e uma detalhada, todas dentro de si mesmo, sem precisar quebrar o contexto visual, como acontece ao pular para alguma outra representação. A cor torna possíveis as camadas espaciais.”

A partir do que tenho visto na minha prática de consultoria, quando pregamos as árvores coloridas na parede podemos facilmente ver a figura completa, e a equipe pode falar sobre ela com muito mais confiança.

“Esses são os usos fundamentais da cor na concepção da informação: rotular (cor como um nome), medir (cor como quantidade), representar ou imitar a realidade (cor como uma representação), e avivar ou decorar (cor como beleza).”

Tenho usado as cores ao construir as árvores da TOC por todas essas razões:

• Rotular: cada cor é uma dica para o modelador e para o leitor, como um arquétipo ou estereótipo (qual é o tipo de cada entidade no diagrama). Essa é uma valiosa informação extra;

• Medir: as cores podem comunicar uma idéia da importância ou prioridade, como no caso das causas raízes e principais EID’s (Efeitos Indesejáveis) na ARA (Árvore da Realidade Atual, veja mais à frente). Outra maneira como as cores ajudam a medir é a contagem visual que elas proporcionam imediatamente (ex., temos 3 causas raízes rosas);

• Imitar a realidade: melhorando a analogia da “árvore”, veremos que as cores tentam simular as folhas, raízes e troncos das árvores; também temos o “sinal de parada” (um octógono vermelho), a injeção (medicamento numa seringa), etc.;

• Decorar: claro, isso vem como um bônus.

Quantas cores?

“Duas ou três cores são geralmente suficientes; cinco já é demais. Combinações de quatro cores devem ser selecionadas com grande cuidado: nada parece pior do que muitas cores, particularmente quando elas carecem de elementos comuns.” [Hideaki Chijiwa]

Sabendo que as notinhas Post-It da 3M geralmente vêm em pacotes de 4 cores (é claro, existem os pacotes com apenas uma cor também), este é, em geral, o número máximo de cores usado na construção de modelos (as árvores, na TOC).

Quais cores?

“O sistema de percepção primária, proposto primeiramente por Leonardo da Vinci, define as cores primárias como vermelha, amarela, azul e verde. Essas são as primárias de percepção, aquelas cores que não aparentam possuir nenhuma outra cor nelas.”

“Podemos atenuar estas cores adicionando um pouco da cor branca nelas. Isto torna o texto colocado nelas mais fácil de ler. Então, para os quatro arquétipos, podemos usar rosa, amarela pastel, azul pastel e verde pastel.”

Isto é muito importante: use apenas os tons pastéis (leves) das cores, e não os tons puros (fortes), senão suas árvores ficarão muito coloridas e podem irritar os leitores!

Ao construir a ARA (Árvore da Realidade Atual), eu uso as cores para representar:

• Verde: os EID’s mais visíveis (as folhas da árvore);

• Rosa: as causas raízes (as raízes da árvore);

• Amarela: os EID’s intermediários (o tronco e os galhos da árvore);

• Azul: raramente usada, mas se alguma outra informação for necessária, eu uso uma caixa azul para mostrá-la (alguma premissa, por exemplo).

A figura a seguir mostra como fica uma ARA colorida, num exemplo típico para um ambiente de desenvolvimento e manutenção de software.

Notas:

• As árvores neste artigo podem não estar completas ou precisas, pois podem precisar de uma análise mais profunda com as Categorias de Reservas Legítimas (CRL). Seu propósito é meramente ilustrativo.

• Usei a versão de Bill Dettmer dos Processos de Raciocínio, como definidos em seu livro “Breaking the Constraints for World Class Performance”.

Figura 1: Uma ARA em cores (clique para ampliar)

Podemos rapidamente captar quais são os principais EID’s (as folhas) e as causas raízes (as raízes) desta árvore. Os EID’s intermediários (e geralmente menos conhecidos ou visíveis) também são mostrados, claro. Esse método funciona muito bem quando estamos construindo ARA’s com um grupo de pessoas, usando as notinhas Post-It grudadas num papel de flipchart. As setas são desenhadas no papel com um marcador permanente, depois que o grupo alcançou um consenso sobre a ordem de causa e efeito.

Mas como sabemos quando um EID será verde, amarelo ou vermelho? Com certeza, não sabemos isso de antemão. Eu uso o seguinte processo:

1. Inicialmente, escreva todos os EID’s em notinhas amarelas e cole-as no papel.

2. Após a análise lógica e o consenso do grupo, reordene as notinhas seguindo a regra “causas embaixo, efeitos em cima”, e então desenhe as setas.

3. Para cada EID que não tiver nenhuma seta (ou alguma significativa) apontando para ele, copie-o numa notinha rosa e substitua sua versão amarela no papel. Esta é uma raiz.

4. Para cada EID que não apontar para nenhum outro EID, ou que seja apontado por muitos outros EID’s, ou que seja um problema bem conhecido no contexto sob análise, copie-o numa notinha verde e substitua sua versão amarela no papel. Esta é uma folha.

5. Se houver qualquer outro tipo de informação que você queira apresentar junto com a ARA (premissas, comentários, etc.), você pode usar uma notinha de qualquer outra cor, como a azul.

Nuvens em Cores

Eu geralmente desenho um diagrama de Evaporação de Nuvens (EN) diretamente no papel de flipchart ou no quadro branco, sem usar as notinhas Post-It. Entretanto, se alguém me pedisse para usar as notinhas coloridas, eu usaria verde para a meta (A), amarela para as condições necessárias (B e C), e rosa para as ações/desejos conflitantes (D e D’). As injeções seriam escritas em azul. As premissas poderiam ser escritas diretamente acima ou abaixo das setas, sem caixas.

Figura 2: Uma EN em cores (clique para ampliar)

ARF em Cores

Para a ARF (Árvore da Realidade Futura), o mesmo esquema básico de cores é utilizado: rosa para as causas raízes, verde para as folhas e amarela para os outros EID’s e ED’s (Efeitos Desejáveis). A principal diferença aqui é em relação à cor azul: ela é usada para representar as injeções propostas e os ED’s previstos.

A figura a seguir mostra uma ARF proposta para a ARA anterior.

Figura 3: Uma ARF em cores (clique para ampliar)

Ao modelar com uma ferramenta de software (o PowerPoint foi usado para construir estes diagramas), eu diferencio as injeções dos ED’s previstos com um formato diferente da caixa (as injeções são retângulos com os cantos retos). Com as notinhas Post-It, eu escrevo “INJ” no canto da notinha azul para marcar uma injeção.

RN em Cores

A RN (Ramificação Negativa) é, na verdade, um complemento da ARF, geralmente construída depois que alguém expressa um risco em potencial na solução proposta. Por isso, esse risco é um “sinal vermelho” de aviso, e é escrito numa notinha rosa. As injeções, como sempre, são azuis. Eu uso verde para marcar um estado ou efeito desejável, e amarelo para os outros fatos da vida ou estados.

Figura 4: Uma RN em cores (clique para ampliar)

APR em Cores

A APR (Árvore de Pré-Requisitos) é tratada diferentemente das anteriores, porque ela é um tanto quanto diferente mesmo. Basicamente temos obstáculos, ações e o objetivo.

Comecemos com o objetivo: é uma caixa azul solitária no topo do papel (porque, geralmente, é uma injeção que vem da ARF). Um obstáculo é desenhado como uma “placa de pare” (que é um octógono vermelho) e, portanto, é rosa. As ações, muito similares ao sinal de “siga” do semáforo, são verdes.

Ao construir uma APR com notinhas Post-It em grupo, comece colando o objetivo em azul no topo do papel de flipchart. Depois, peça ao grupo os obstáculos em rosa Finalmente, peça pelas ações em verde, que superarão os obstáculos. Coloque as ações em ordem lógica e cronológica, desenhe as setas de conexão e, voilà, você tem uma mini-rede de projeto para ser executada, usando a Gestão de Projetos pela Corrente Crítica, claro.

A figura a seguir mostra uma APR para uma das injeções da ARF anterior.

Figura 5: Uma APR em cores (clique para ampliar)

AT em Cores

A AT (Árvore de Transição) é outra forma de comunicar o plano proposto, como na APR. O foco da AT é explicar o porquê, junto com o que fazer. Aqui eu apresento o mesmo conteúdo da APR, agora traduzido numa AT.

Como fizemos na ARA e ARF, o objetivo/folha mais visível é escrito numa notinha verde e colocado no topo do papel. As condições iniciais, geralmente EID’s, são escritas em notinhas rosas. E então temos uma série de trios, compostos por um estado, uma necessidade e uma ação. Os estados desejados intermediários são escritos em notinhas verdes , as ações (injeções) são azuis e as necessidades são amarelas.

Figura 6: Uma AT em cores (clique para ampliar)

Conclusão

Espero que esta breve explanação, sobre como eu tenho usado as cores ao construir as árvores da TOC, lhe seja útil em suas aventuras futuras.

A tabela abaixo resume como as cores são usadas com cada árvore.

Na minha experiência, o uso das cores nos meus modelos, tanto de sistemas de software quanto de árvores da TOC, ajudou-me a melhorar o processo de raciocínio e a comunicação com as outras pessoas. Como conseqüência, o tempo e o esforço exigidos para construir os diagramas são menores e, impressionantemente, a qualidade é bem superior.

Eu usei PowerPoint para desenhar as árvores deste artigo, mas sei que não é a melhor ferramenta para este trabalho. Basicamente você pode usar qualquer outra ferramenta de desenho disponível. Também usei Visio, Transformation Logic Tree (TLT) e Flying Logic.

Infelizmente a última versão do TLT que usei (Beta 0.8.8) ainda não suporta cores nas caixas. Portanto, eu uso o TLT para desenhar uma árvore e depois a copio e colo no PowerPoint, para aplicar as cores apropriadas. Não é um trabalho muito eficiente, mas eu posso conviver com isso enquanto espero pelo suporte às cores no TLT.

A ferramenta Flying Logic também é bastante interessante. Ela espalha as entidades automaticamente pela tela e tem um visual bem bonito. Ela também oferece a possibilidade de testar a lógica das árvores.

Quero agradecer muito ao Peter Coad e seus colegas por inventarem a técnica da UML em Cores, e espero que muitos de vocês, na nossa comunidade de TOC, levem esse trabalho embrionário muito mais além do que foi apresentado aqui.

Agora, pegue suas notinhas Post-It e comece a colorir suas árvores!

Heptabraço!

Sobre o Autor

Adail Muniz Retamal é Diretor Executivo da Heptagon TI Ltda (www.heptagon.com.br), uma empresa brasileira dedicada à consultoria, treinamento, coaching e mentoring em TOC e metodologias ágeis para desenvolvimento de software. Ele é formado em Engenharia Eletrônica (1993), mas desde 1983 tem atuado na área de software como desenvolvedor, analista, arquiteto, gerente de projetos e instrutor. Foi o fundador e é o moderador do TOC-Brasil, um grupo de discussão em português no Yahoo para a comunidade de TOC, e do GUFDD, um grupo de discussão em português no Yahoo para a comunidade de FDD. Adail pode ser contatado em "adail at heptagon.com.br".

Este artigo pode ser copiado, traduzido e publicado apenas em sua totalidade, incluindo esta nota. O autor apreciará uma notificação para acompanhar onde ele foi publicado.

Siglas Usadas

• David Anderson
• Goldratt Marketing Group em sua TOC Update Newsletter - Outubro/2008