Tag: Agile

Histórias de Valor e Outros Contos
Bons produtos e projetos não começam com hipóteses. Sua pedra fundamental é o correto entendimento dos objetivos – do valor que devem gerar. Histórias de Valor ajudam a descobrir e descrever essas informações. Elas dão sentido ao roteiro de trabalho (roadmap e backlogs) e facilitam a contagem das realizações e de outras histórias.As Histórias de Valor, como vimos no artigo anterior, usam o formato clássico das Histórias de Usuários:

Como <organização> precisamos <criar algo> para <realizar tais objetivos>

Como finito eu preciso retomar as conversas com a comunidade Ágil para viabilizar algumas turmas da oficina FDP³.

Histórias de Valor tapam um buraco meio desconcertante dos métodos ágeis. Nessas propostas utilizamos dois catalisadores de informações nas interações com clientes e usuários: Histórias de Usuários e Épicos. Recentemente começamos a falar sobre Job Stories. Suas diferenças estão fora do escopo deste artigo¹. O que essas ferramentas não explicam é a motivação para aquele projeto ou produto. Afinal, mirando o todo, qual e quanto valor pretendemos gerar?

Você pode dizer que estamos reinventando rodas. Afinal, já temos ferramentas com esse fim: Business Cases, Project Charters, Documentos de Visão e por aí vai. O grande problema é que esses documentos são de outra era. Repare, são documentos. Por simpáticos que sejam, trazem consigo a pesada bagagem do mundo cascata. É o mesmo problema do termo requisito, por exemplo. Agregar o sobrenome “Ágil” não anula seu histórico. Quando o Scrum chegou com novos nomes – Product Owner, ScrumMaster, Sprints – foi exatamente para evitar qualquer mínimo vínculo com os métodos e modelos que pretendíamos abandonar.

História de Valor não é um documento. É um catalisador. Repito o termo. É importante explicá-lo. Catalisador, segundo nosso dicionário, é “o que estimula ou dinamiza”. Histórias, em métodos ágeis, têm essa finalidade. São o exato oposto dos documentos. Estes servem para encerrar discussões. Histórias estimulam discussões. São dinâmicas. Se prometemos receber mudanças de braços abertos, é importante que nossas ferramentas incentivem e facilitem isso.

Mapa e Bússola

Joi Ito e Jeff Howe, no excelente Whiplash², colocam que nesses novos tempos a bússola é mais importante que os mapas. O mapa é um plano. A bússola, direção. O Manifesto Ágil, em outras palavras, afirma o mesmo desde 2001: “Responder a mudanças mais do que seguir um plano”. Mas as nossas respostas não podem variar como uma biruta. Qual é a nossa bússola? As motivações expressas em cada História de Valor.

Não dispensamos os mapas. Eles seguem importantes. Mas não fazem muito sentido sem a bússola. Jeff Patton presta um serviço ímpar em User Story Mapping (O’Reilly, 2014). Ele repete, sempre que necessário, que um bom mapa de histórias é orientado por resultados. O único defeito do livro é não definir uma forma para a representação desses resultados. Histórias de Valor servem para isso. Com a vantagem de respeitar o padrão utilizado em todo o mapa.

Na Prática

A primeira coisa é não confundir Histórias de Valor com Épicos. Estes são histórias aguardando detalhamento e a inevitável quebra em mais histórias. Épicos podem representar módulos de um sistema ou funções extensas. Histórias de Valor, por outro lado, representam o negócio. Ou, melhor dizendo, um resultado esperado pelo negócio. Se esse resultado depende de uma ou mais funcionalidades – de uma ou mais histórias de usuários ou épicos – não interessa. Aliás, uma história de usuário pode colaborar em diversas Histórias de Valor. Mas ela só pode pertencer a um épico.

Histórias de Valor são o ponto de partida de qualquer produto ou projeto. Pegamos a bússola, descobrimos a direção e só então desenhamos um mapa (ou roteiro – roadmaps, Mapas de Histórias e backlogs). Por óbvio que isso soe, quantas vezes você testemunhou um projeto sendo iniciado a partir de Histórias de Usuários? Essa carroça bem adiante dos bois, infelizmente, é um mal recorrente. E causa principal de nossos problemas.

Histórias de Valor não são atômicas. Elas podem ser quebradas de forma a representar uma hierarquia de objetivos e metas. É normal que um projeto tenha algo entre cinco e dez Histórias de Valor. Essa organização facilita a elaboração de um Mapa de Histórias. Mais que isso: facilita o monitoramento dos resultados obtidos. E também pode ser registrada na forma de OKRs ou LogFrames. Pense na possibilidade: o Mapa de Histórias é o detalhamento de um ou mais OKRs. Cada entrada no OKR é uma História de Valor.

Hipóteses, de novo…

No artigo anterior critiquei a definição de Valor para o Negócio apresentada por Mark Schwartz em The Art of Business Value (IT Revolution Press, 2016). Ele escreveu 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”. A História de Valor nos livra dessa armadilha. O que escrevemos na frente do para não é uma hipótese. É um objetivo claro e devidamente quantificado³. É o Valor para o Negócio. A hipótese existe, mas está em outro lugar: na descrição do que nós precisamos.

Essas confusões entre o QUE e o COMO e a perigosa mania de tratar tudo como hipótese vão merecer mais conversas. No próximo artigo, a segunda parte de nosso Checkup Ágil, volto a puxar o assunto.

Notas
1. Neste artigo do Fabrício Teixeira há uma bela comparação entre User Stories e Job Stories.
2. Em pt-br esse livro mereceu o terrível título “Disrupção e Inovação” (Alta Books, 2017). Por isso temo pela qualidade da tradução. Falo um pouco mais sobre ele neste artigo.
3. O exemplo com a FDP³ não representa um bom uso da História de Valor porque não se compromete com números. “Algumas turmas” é ambíguo demais para ser aceito em qualquer contexto ou projeto. O exemplo é interesseiro – vendi meu peixe sem meias palavras.
4. A foto utilizada neste artigo foi compartilhada por Martin P. Szymczak no flickr.
maio 9, 2018
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.
maio 7, 2018
Tendências
A mais nova moda é antever modas. É o que diz Gabriel Louback no artigo Nostradamus 2.0 (publicado na edição de junho da Revista da Cultura). Se fôssemos um pouco mais atentos, teríamos percebido a tendência bem antes. Em Reconhecimento de Padrões (Aleph, 2004), por exemplo, William Gibson apresenta uma protagonista que é coolhunter – uma caçadora de tendências. Aliás, Gibson e outros grandes da ficção científica¹ estão entre os melhores antecipadores de tendências que conheço. Será porque eles pavimentam e indicam caminhos? Somos orientados por profecias?

Fábio Gandour, da IBM, afirma que sim: “Tendências não acontecem espontaneamente, são criadas! E, normalmente, você caminha, sem perceber, na direção que pretenderam. Quem não acredita nisso é ingênuo ou tolo“. É disso que trata, enfim, todo o blablablá sobre inovação. Antever uma rota e rogar para que os fregueses sigam, como os ratinhos da fábula, os novos flautistas de Hamelin. Há ciência nessa ficção? Ou é tudo chute?

Acho que sempre teremos uma combinação das duas coisas, de ciência e intuição. Diferente agora é a ênfase no aspecto intencional (racional) da projeção de tendências. Em O Futuro como um Bom Negócio (Campus, 2011), Daniel Burrus e John Mann oferecem boas provocações². Os autores sugerem a classificação de tendências entre fortes e fracas e que o novo desenho – seja de um negócio, produto ou serviço – as tenha como base. Tratando só de tecnologia, por exemplo, temos três tendências fortíssimas que estão conosco desde o início dos tempos (nossos tempos). Todas relacionadas com o aumento exponencial de : i) Poder de processamento; ii) Capacidade de armazenamento; e iii) Largura de banda. Delas derivaram vertentes do avanço tecnológico, como a virtualização, mobilidade, interatividade e convergência, dentre outras.

Mas será um grave erro a projeção de tendências que tome por base apenas os avanços tecnológicos. Peter Drucker, em Desafios Gerenciais para o Século XXI (Pioneira, 1999), fala sobre as “questões quentes de amanhã”. Seu escopo de análise é consideravelmente maior. Trata desde a globalização e o avanço de nações emergentes até a mudança no perfil de TI (do T para o I), passando pelo envelhecimento da população mundial e pela necessidade de um novo tipo de gestão e liderança. Drucker sempre foi um observador privilegiado. Por isso a precisão de suas previsões não surpreende.

Acho que eu poderia listar mais uma dezena de obras seminais sobre o amanhã. Não destacar A Vida Digital (Cia. das Letras, 1995), de Nicholas Negroponte, por exemplo, é quase um pecado. Mas ele, de certa forma, é profecia já realizada. Deve interessar, assim como os livros do Drucker, para que possamos aprender a antever. E é este o ponto. Aliás, é esta a tendência.

E o que nos ensina a antever? Há uma disciplina ou corpo de conhecimentos que ajude pessoas e organizações a antever e desenhar seu futuro?

Notas
1. A lista dos grandes escritores de ficção científica é imensa. Perdemos, no início deste mês, um dos maiores: Ray Bradbury. Poderia listar Julio Verne, Isaac Asimov e outros tantos. Me limitarei a destacar meu favorito, o maior porra-loca de todos: Philip K. Dick. Quem se limita a conhecê-lo através dos filmes inspirados por suas obras (Blade Runner, O Pagamento, O Vingador do Futuro etc) não faz ideia do que está perdendo.
2. Por razões óbvias, há uma provocação que mais me chamou a atenção. Diz mais ou menos assim: Agilidade é coisa da década ou do século passado. Hoje ela não basta. E pode até ser nociva. Hoje precisamos antever e evitar o desperdício de tempo e dinheiro. Mais que isso, precisamos fazer a próxima curva na frente da concorrência.
3. Não deixarei aquelas duas últimas questões sem respostas. Aguardarei seus palpites e um pouco mais de inspiração.
4. Crystal Ball, a fotografia que ilustra este artigo, é de Steve Weaver.
junho 29, 2012
Universos Paralelos: O Samba e o Bebop
É muito pouco provável que alguém do Universo Samba (Negócios) perca dois minutos de sono ou dois fios de cabelo por causa deste artigo proveniente do Universo Bebop (TI). As interfaces fraquinhas e o pouco interesse que um nutre pelo outro – apesar da mútua dependência – tendem a deixar tudo (caduco) como está. Como sou metido a besta e me sobrou um tempinho, vou jogar dois gravetos verdes nessa acanhada fogueira.

Não entendeu nada, né? Eu explico. O artigo em questão compila uma série de reclamações que Steve Denning, autor de The Leader’s Guide to Radical Management (Jossey-Bass, 2010), publicou na revista Forbes. Denning reclama de um certo conservadorismo por parte dos “gerentes” e da “tendência muito antiga de se ignorar ideias novas e ousadas”. Condena, no atacado, a relutância ou desconhecimento dos “gerentes” do que seria o movimento Agile.

Me surpreendi com uma das conclusões de Denning. A de que os “grandes avanços na área de gestão” obtidos através de métodos ágeis não pegaram no mundo dos negócios porque não foram pessoas ou acadêmicos “de negócio” que os criaram. Foram os nerds, segundo suas próprias palavras. Em outro trecho, uma derrapada comprometedora:

“O mundo gerencial continua em estado de negação sobre as descobertas dos métodos ágeis. Você pode explorar as páginas da Harvard Business Review e dificilmente encontrará quaisquer referências, mesmo que indiretas, para as soluções que a filosofia ágil oferece aos problemas gerenciais da atualidade.”

De onde Denning acha que brotaram 80% das ideias que compilamos e etiquetamos como agile, lean etc? Será que ele se lembra que o Scrum, por exemplo, é inspirado em um artigo da mesma Harvard Business Review de janeiro de 1996? E o que dizer dos artigos e do trabalho de Donald Reinertsen, autor de Managing the Design Factory¹ (The Free Press)? Ele aparece na mesma InfoQ e está na edição atual (maio/2012) da edição brasileira da HBR, com o artigo Seis Mitos do Desenvolvimento de Produtos. Qual é o problema? O fato de vários autores (de negócios) não revenderem a marca Agile, apesar de a influenciarem e serem influenciados por ela?

Eu só boto Bebop no meu Samba…

… quando Tio Sam tocar um tamborim”². Esta citação apareceu em um papo que rolou com o amigo Leandro Mendonça. Ele trabalha em outro universo: Publicidade. E tem como uma de suas diversões favoritas ver como a patota de TI reinventa a roda, registra patente e bebemora o feito. O artigo em questão, além de comprovar este ciclo, não contribui em nada para uma mudança da situação. Pelo contrário, parece fechar portas. Veja, por exemplo, as “dez objeções perenes da gestão” apresentadas:
1. “O Agile é apenas para estrelas – Ao ser confrontado com a escolha entre o alto desempenho e a mediocridade, a gerência tradicional escolhe a segunda”.
  pv: Existe mesmo algum gerente que, em sã consciência, faz opção pela mediocridade?
2. “O Agile não se enquadra em nossa cultura organizacional – No mercado dos dias atuais, ou as empresas mudam sua cultura ou morrem. A cultura das empresas deve ser ágil”.
  pv: Não sei de nada, mas desconfio de muitas coisas³. Desconfio, por exemplo, que mudanças impostas, arbitrárias (“deve ser ágil”), são mais efêmeras que bolas de sabão.
3. “O Agile apenas funciona para projetos pequenos – Já existem soluções óbvias para se lidar com projetos grandes…
  pv: Impressionante como “óbvio” constantemente se parece com álibi (“não tenho uma boa resposta”) ou falta de respeito (“você é burro e não perderei meu tempo contigo”).
4. “O Agile requer que as equipes estejam no mesmo lugar – … pode-se usar tecnologias para manter a comunicação aberta e contínua”.
  pv: Nenhum gerente sabe disso. Mal sabem que já inventaram o telégrafo!
5. “O Agile é fraco em processos gerenciais – A não ser que você escolha uma metodologia ágil que já atenda a todos os processos necessários, é importante juntá-la com outra que supra os processos não cobertos”.
  pv: Difícil imaginar resposta pior. Ou o Agile deixou de questionar os “processos necessários e não cobertos”?
6. “O sistema de recompensas individuais de nossa empresa não se encaixa no Agile – É o sistema de recompensas que está errado, não o Agile. Mude o sistema”.
  pv: Mude o sistema e tente explicar para o Zé, que rende quatro vezes mais que o João, porque ambos passarão a receber a mesmíssima recompensa. Em Management 3.0, Jurgen Appelo nos explica que “não há nada inerentemente errado com sistemas de recompensas individuais. Eles só se tornam um problema nas mãos de ingênuos que desconhecem seus riscos”.
7. “O Agile é algo passageiro – Não se trata de uma solução para todos os problemas… O Agile é a solução para um problema particular, ou seja, a reaproximação de uma execução disciplinada com a criatividade e a inovação”.
  pv: A questão, ou, usando os termos do artigo original, a “objeção perene” era outra. Agile é passageiro? Nada, em nenhum dos dois universos, que passe dos onze anos de vida pode ser classificado como “passageiro”. Ele veio para ficar? Meu caro, além da beleza da Catherine Deneuve, da estupidez humana e das embalagens de plástico, o que mais veio para ficar?
8. “Há ideias melhores que o Agile – Em vez de entrar nessa briga, prefira buscar os aspectos comuns entre estes movimentos e junte forças para obter um resultado mais efetivo”.
  pv: Santa saída estratégica pela direta, Batman! Sempre existirão ideias melhores que outras, dependendo do contexto. Como Agile também se apresenta como “cultura” e “filosofia”, talvez valha a pena “entrar na briga” ao invés de fugir ao primeiro desafio apresentado.
9. “Nada de novo aqui – Todos os componentes individuais do Agile já existem há algum tempo. O que é novo é juntar todos estes elementos de uma maneira coerente e integrada”.
  pv: Acho que fui mais corajoso ao afirmar anteriormente que 80% dos componentes do Agile já existiam. O que a resposta acima omitiu foi a origem desses componentes. Não estaria neste reconhecimento uma boa arma para vencer as “objeções perenes” dos gerentes?
10. “Não é uma comparação justa? – Introduzir Agile (de verdade) significa expor todos os truques encobertos que os gerentes, em hierarquias tradicionais, utilizam sobre seus subordinados para manter o poder”.
  pv: E assim Agile vira o sol que vai revelar todos os segredos dos gerentes e, de quebra, dar uma desinfetada no ambiente. Talvez esteja aqui, nesta ingênua acusação, a principal razão pela qual ainda temos muitos gerentes relutantes em relação ao Agile. Caramba, eles foram apontados como os inimigos desde o início. Appelo de novo: “Acredito que o desenvolvimento Agile negligenciou a importância da gestão. Se os gerentes não sabem o que fazer e o que esperar de uma organização Agile, como esperar que eles se envolvam na transição para o desenvolvimento Agile? Qual é a mensagem aqui? Se é apenas ‘não precisamos de gerentes’, então não surpreende o fato de estarmos conversando sobre ‘objeções perenes’”.
Não estou isentando os gerentes de nada. Quem sou eu para isentar alguém de qualquer coisa? Existem sim os gerentes relutantes e ignorantes e muitos deles seguirão existindo, não importa o que façamos ou quanto gritemos. Mas passou da hora da gente, dos que acreditam na proposta Agile, assimilarmos um velhíssimo dito chinês, aquele que ensina: “quando apontar o dedo para alguém, repare para onde apontam três dedos”. É de quem vende uma ideia, de quem propõe uma mudança, o ônus da prova. Show me the money!, dizem os caras de negócios. Enquanto não provarmos nossas teses com fatos, números e valores, estaremos apenas e simplesmente (simploriamente?) filosofando.

Os caras não colocarão bebop no samba deles enquanto não pegarmos nos tamborins, mora?

Notas
1. São raros os trabalhos do mundo Agile que souberam equilibrar, como Reinertsen neste livro, as preocupações com Organização, Processos e Produto (Arquitetura do). Uma honrosa exceção é Agile Project Management, de Jim Highsmith. Reparem como nossos papos andam monotemáticos: processo, processo, processo… Scrum, Kanban, baranga-dã… Outra diferença fundamental do trabalho de Reinertsen, já demonstrada anteriormente em Desenvolvendo Produtos na Metade do Tempo (Futura, 1997), é a preocupação com a Economia – com a grana que o produto pode gerar e com os custos que o projeto deve suportar.
2. Foi Jackson do Pandeiro quem escreveu “Chiclete com Banana” e desafiou Tio Sam a pegar um tamborim. Foram Leandro Mendonça e Pedro Braga que me deram esse presente. Ou será que surrupiei a ideia indevidamente?
3. Foi Guimarães Rosa quem originalmente disse não saber de nada mas desconfiar de muita coisa.
4. Tamborim, a imagem utilizada, é de Schröedinger’s Cat.
maio 31, 2012
Eu Quero Ser Gerente Quando Crescer

Você já ouviu uma criança manifestar o desejo de ser gerente? Eu não. Mesmo os filhos de gerentes bem sucedidos não parecem se interessar pela posição da mãe ou pai. Talvez porque eles, durante toda a semana de trabalho, cheguem em casa estafados e aborrecidos. Também pode ser porque raramente apareça em um desenho animado ou filme infantil um gerente ou chefe que não seja pintado como um vilão, mau caráter, interesseiro e desumano. Acho que não veríamos com bons olhos uma criança que desejasse tal papel. O que será que aconteceu com a grande profissão do século XX?

O gerente é uma invenção da era industrial, um mal necessitado pelos verdadeiros donos de negócios que precisavam ganhar escala. Deveriam funcionar como clones parciais e especialistas do manda-chuvas. Um especialista em vendas, outro em finanças e assim por diante. Os gerentes ocupam a camada intermediária de uma organização, entre o topo e os peões. Na teoria, e quase só na teoria, eles defenderiam o ponto de vista tático. Ou seja, trabalhariam com um horizonte de médio prazo. Quem está acima deles enxergaria mais longe. Quem está na base cuida do dia a dia, provavelmente sob os auspícios e chicotes de um supervisor ou líder técnico – um outro nível de gerente que vive a mirar o andar de cima com desejos inconfessáveis.

A necessidade de uma organização hierárquica criou na marra uma separação que não fazia sentido no século 18 assim como parece não fazer no século 21. Cérebro e mãos foram apartados artificialmente. Tanto que Henry Ford vivia reclamando que “quando contratava duas mãos, o cérebro vinha junto”. À base de pirâmide não era permitido pensar. Seus ocupantes deveriam apertar porcas e deixar todo o trampo intelectual para quem estivesse acima. E assim a posição do cérebro – do gerente – mesmo que limitada, virou objeto de desejo de todos que tivessem um mínimo de ambição. Não era só o maior salário. Era sobretudo o status, o inequívoco sinal de ascensão social.

Muita demanda, ofertas teoricamente limitadas. Neste jogo político, assim como em governos com inflada base de apoio, inventam-se cadeiras e postos. E o meio da pirâmide inchou para todos os lados. Na linha do tempo estamos entre os anos 1950 e 1980 (lá fora) ou 2000 (aqui no Brasil). Pois é, tem duas ou três décadas que olhamos para este meio de campo e perguntamos: precisamos de tantos gerentes assim? Aqueles que já passaram da página três têm outra questão: precisamos mesmo de gerentes?

G de Gerente, G de Gargalo

Se os proponentes dos métodos ágeis adoram falar que gerentes não são mais necessários, não deve surpreender a ninguém o fato deles – os gerentes – serem tão pouco receptivos à ideia. Com outras palavras, é isso que diz Jurgen Appelo em Management 3.0, publicado em 2011. Desconfio que também sejam eles, os gerentes, os responsáveis pelo bloqueio do principal requisito das iniciativas BPM: a organização por processos. Não por ação, mas por omissão. Afinal, como aceitar e trabalhar por um modelo que não dê uma atribuição minimamente respeitável para os gerentes? Como acatar uma sugestão que, em sua origem, significou a extinção de diversas cadeiras de gerentes?

Que sejam sabotadas, sutilmente, as propostas de mudanças nada sutis. E provemos nosso valor mergulhando, com todo o tempo e saúde de que dispomos, nas questões do dia a dia. Pagamos para ver quem sabe mais do que a gente. Queremos ver quem nos tira daqui.

Não espere que um gerente confesse o parágrafo anterior. E não caia na armadilha da generalização. Os gerentes não são ruins por natureza. Mas estão, neste ponto da história, defendendo sua sobrevivência. Nada mais natural. Nada mais humano.

Mas, e daí? Devemos aceitar que os gerentes, assim como várias outras invenções do século XX, devem ser riscados do mapa? Eles são de fato supérfluos nos tempos da economia do conhecimento e do autogerenciamento?

G de Gratificante

Peter Drucker, ao tratar a organização por processos, sugeriu que os departamentos funcionais seguiriam existindo. Não mais com responsabilidades sobre as funções executadas, mas como formadores e provedores de especialistas. Tom DeMarco e Thimoty Lister, em Peopleware, cruzaram caminho semelhante: “o centro de aprendizagem mais natural para a maioria das organizações reside naquela mal falada instituição, na camada intermediária. Isso bate com nossa observação de que as mais bem sucedidas organizações que aprendem possuem um forte time de gerenciamento”.

Os gerentes não cuidariam apenas de ensinar, mas principalmente de montar e manter um ambiente onde o aprendizado acontece. Será que basta? Claro que não, como demonstra Henry Mintzberg em Managing – Desvendando o Dia a Dia da Gestão (Bookman, 2010). Seu modelo de gestão, ilustrado ao lado, sugere a existência de três planos e duas atividades principais vinculadas a cada um deles: Plano das Informações (comunicar e controlar), Plano das Pessoas (liderar e fazer conexões) e o Plano das Ações (executar e negociar). Repare também que o modelo indica três zonas de atuação: dentro da unidade de negócio, com o resto da organização e fora da organização.

Não é curioso como Mintzberg parece ignorar ou desconsiderar as sugestões anteriores, de ensinar e prover um ambiente que estimule a aprendizagem? Me arrisco a sugerir a existência de um quarto plano, central, o Plano da Aprendizagem Organizacional. Que também teria duas atividades principais (promover e difundir) e três dimensões (a unidade, a organização e o lado de fora da organização). Creio que este quarto plano responderia as críticas apresentadas por Jurgen Appelo em seu livro (sobre a falta de preocupação, no modelo de Mintzberg, com o Desenvolvimento de Competências e a Melhoria Contínua).

Não se engane, o modelo seguiria errado. Assim como é equivocada (e simpática) a Martie – monstrinho que representa o modelo Management 3.0 sugerido por Appelo. Porque, como confessa seu próprio criador: “todos os modelos estão errados. Mas alguns são úteis”. O bom gerente desconfia disso. O excelente tem certeza, por isso estuda todos os modelos e tenta colocá-los em prática. Não apenas em busca de paz de espírito e disponibilidade para seus filhos, mas porque ele sabe que seu principal trabalho é fazer com que outras pessoas trabalhem e evoluam. Sua responsabilidade é imensa. Por isso o papel do gerente pode ser tão gratificante.

Nada disso fará com que seus filhinhos manifestem a vontade de ser gerentes quando crescerem. Não importa. Eles também nunca dizem que serão otorrinolaringologistas.

abril 19, 2012
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.

?

janeiro 25, 2012
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.
janeiro 11, 2012
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.
novembro 29, 2011
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.
outubro 11, 2011
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.
setembro 29, 2011