Minha amiga chega ao trabalho e após alguns minutos se dá conta de um fato aterrador: não consegue lembrar se tirou ou não a sanduicheira da tomada. 

Você conhece a sensação, talvez o mais desagradável seja o fato de simplesmente não conseguirmos lembrar. A memória é assim: prega peças para dar sabor à vida, transforma em probabilidades o que poderia ser certeza.

Bem, os riscos fazem parte da nossa vida. Para que um risco exista basta determinarmos qualquer resultado esperado em qualquer ramo da atividade humana.

Acordo pela manhã, abro os olhos e penso: “vou trabalhar”. Pronto! Com essa frase nasceu o risco de eu não trabalhar hoje ou talvez nunca mais.

Riscos existem, podemos lidar com eles, ignorá-los (não saber da sua existência) ou simplesmente aceitá-los e as suas consequências. Ignoramos riscos que não conhecemos e aceitamos riscos que achamos pouco prováveis, como faço com o risco da minha casa ser atingida por um asteróide.

Como vamos lidar com um risco depende de uma equação simples na qual pesamos o quão ruim as coisas serão se esse risco se concretizar, qual a probabilidade desse risco acontecer de fato e por fim, qual o custo que vamos ter em lidar com ele.

Custo da ação < (Bomba / Probabilidade)

Em PT-br: o custo da ação não deve superar o custo da bomba explodir em relação à probabilidade dela explodir.

Os seres humanos que habitam o planeta hoje são descendentes dos seres humanos que souberam aplicar essa equação da melhor forma dado cada momento.

Vou usar a história da minha amiga para descrever o que podemos fazer em relação a um risco, no caso dela o risco da sanduicheira esquentar demais e causar um incêndio.

Read the rest of this post »

A região metropolitana de São Paulo não chega a ser digamos, montanhosa, contudo existem algumas subidas que desafiam quem deseja utilizar a bicicleta como meio de transporte, principalmente para quem gostaria de chegar no ponto B sem suar além da conta.

Um desses desafios é chegar à Avenida Paulista. Em termos relativos ela está lá no alto e não importa por onde você chega: você precisa subir.

Eu sou considerado um ciclista experiente, talvez não pelo tempo que pedalo nas ruas de São Paulo (dois anos), mas pela distância diária e a freqüência, são 30 km todos os dias úteis para ir trabalhar. Minha bicicleta atual está beirando os cinco mil rodados o que me transformaria em termos relativos em um ciclista urbano pleno ou sênior.

Recentemente montamos um grupo de ciclistas geeks, uma galera muito alto astral, do bem que trabalha com informática (sim, isso é possível) e que está começando a pedalar pela cidade de São Paulo.

No nosso primeiro passeio montei uma rota que incluía o caminho que eu considerava “o menos pior” (uma vez que bom não existe) para subir à Paulista.

 Passeamos pela Paulista, vimos as luzes de natal, descemos para o Ibirapuera ver a árvore e voltamos para a nossa avenida querida, foi muito divertido. Fizemos outros passeios depois desse, um na sexta-feira 13 e outro no aniversário de São Paulo.

Na semana passada o pessoal estava louco para fazer um passeio, mas eu não podia por causa de uma dor no joelho. Meus amigos insistiram, falaram que eu era o cara, mas eu sugeri que eles fossem sem mim.

Eles foram, se divertiram, superaram as dificuldades e descobriram um caminho ainda melhor para subir para a Paulista coisa de duas ruas distante do caminho que eu considerava melhor, mas que eu havia ignorado, talvez por simples acomodação.

Como eu prefiro validar as hipóteses ao invés de simplesmente discuti-las,hoje, segunda-feira, mudei o meu caminho, encontrei a rua e subi. Não é que é super leve, mão única e não tem ônibus?

A moral da história é que devemos ter muito cuidado com a palavra “Sênior”. Essa palavra não pode ser tomada como “aquele que sabe mais e que guia os outros”.  Acredito que sênior no nosso ramo tem mais a ver com aquele que aprende mais e aplica o que aprende. O passado só tem importância se ele ajuda no presente.

A inovação está nas mãos daqueles que vão e fazem.

Vamos começar com uma história, mas dessa vez real:

Era uma quente terça-feira de verão em 2011. Estou em uma sala de reuniões em um edifício da av. Paulista. O evento, ou melhor, a cerimônia é a review da sprint sete de um projeto para uma instituição financeira. Na review o time de desenvolvimento apresenta o resultado do trabalho da última sprint (período de tempo dedicado ao desenvolvimento de uma parcela definida do sistema) para os clientes. Éramos onze pessoas à mesa, divididos da seguinte forma:

• Cliente: 
  • Uma gerente de projetos
  • Dois especialistas em sistemas do cliente
  • Três clientes finais (quem vai usar o produto)
• Fornecedor: 
  • O Scrum Master
  • Eu (agile BA/PO/whatever)
  • Três desenvolvedores (o time tem seis, mas como a review foi no cliente e não temos uma perua, não trouxemos o time todo). 

A mesa estava assim:

O primeiro fato interessante foi que os clientes (verdes) e os desenvolvedores (vermelhos) se sentaram frente a frente sem estímulo algum da nossa parte. 

Os desenvolvedores começaram a sua apresentação, iam passeando entre telas que atendiam aos padrões de layout do cliente, realizando operações que haviam sido selecionadas na última planning quando de repente uma faísca se acendeu e os clientes finais começaram a fazer perguntas e comentários e a conversa começou a rolar solta. Fiquei assistindo.

Notei que nós, “os cinzas”, que costumávamos dominar essas reuniões, ditar ritmo e assunto, estávamos quietos e só abríamos a boca quando era realmente útil para a discussão.

Notei também que o vocabulário usado pelos desenvolvedores era totalmente orientado ao negócio, não havia necessidade de tradução.

A coisa ficou realmente interessante quando o cliente final lembrou-se de necessidades importantes que estavam foram da sprint e, conseqüentemente fora a release que se aproximava.

Sabemos que isso acontece, nem todo o planejamento do mundo consegue evitar mudanças. As metodologias de gerenciamento de projetos lidam com a mudança de diferentes formas. No caso do Scrum, quando algo importante para a release é descoberto, simplesmente atrasamos a release, mas claro que ninguém gosta de atrasar uma release, se for feito, que seja o mínimo possível (uma sprint). 

A base do meu trabalho de Agile BA/PO/whatever é entender tanto do negócio quanto de como o sistema está sendo construído e em condições normais me debruço junto ao cliente final para descobrir uma forma de atender à necessidade da forma mais barata, ou seja, aproveitar ao máximo os serviços já existentes no sistema.  O que fiz nesse caso? Muito pouco.

O time de desenvolvimento fez uso do conhecimento do negócio e os clientes finais fizeram uso do seu conhecimento do sistema e chegaram às soluções em tempo recorde e com muita eficácia.

Nós “os cinzas” ficamos, novamente, só dando úteis pitacos aqui e ali e é claro, sobrou para o analista de negócios atualizar a documentação (que parece cada vez menos necessária em um ambiente assim, sendo útil apenas para a construção do manual do usuário e para apoiar o QA externo). 

 

 

O mais interessante foi que se estamos falando da sprint sete e nossas sprints têm dez dias úteis. Falamos em aproximadamente 105 dias corridos, três meses e pouco.

Deixando de lado o fato extraordinário de se entregar uma quantidade considerável de funcionalidade em um período inferior a cinco meses dentro de critérios rigorosos de arquitetura e layout do cliente, e pasmem - em outsourcing - nosso uso do Scrum teve outro mérito impressionante: Em muito pouco tempo temos um time de seis desenvolvedores capazes tanto de entregar a solução técnica quanto de compreender e atuar sobre o domínio do problema.

Eu gostaria de poder mensurar financeiramente o valor disso, pois além dos ovos de ouro (código rodando), desenvolvemos a galinha dos ovos de ouro (o time).

Read the rest of this post »

Opa, antes de qualquer coisa, sim, eu fui GP, cheguei perto de ser PMP (me amarrava em Pilotar Microsoft Project), passava o dia perguntando "tá pronto?" e critiquei muito o agile assim que conheci até que a minha opinião foi moldada pela realidade dos projetos dos quais participei e dos produtos que gerenciei.

Dessa forma, entendo que as pessoas mudem, que as organizações mudem (afinal, estou trabalhando em uma fábrica de software que deseja realmente ser o mais agile que esta triste condição permitir), contudo, a forma com a qual o PMI "abraçou" o agile foi extremamente arrogante. 

O instituto parece ter passado por todas as fases do luto, permanecendo, claro, anos e anos na primeira, a "negação". Acredito que a raiva, a barganha, a depressão e a aceitação se deram de forma velada. O próximo passo público foi a apropriação. Agile é do PMI agora. Eles dizem quem está capacitado.

"PMI will validate a practitioner’s ability to understand Agile principles and concepts."

Acho que ninguém falou que os princípios ágeis quando aplicados diminuem fortemente a necessidade de alguém que se intitule gerente de projetos. Duvido que o pessoal que luta tanto por reconhecimento vá aceitar trabalhar para eventualmente desaparecer (o objetivo supremo de um bom facilitador de times ágeis).

A impressão é que a competência do PMI não está em gerenciar projetos e sim em ser uma máquina de certificar. Acredito que o próximo passo seja certificações em física quântica.

Mais informações sobre a certificação aqui.

Tenho uma amiga #BA #PADAWAN que volta e meia me desafia com questões que afetam o seu dia a dia de Analista de Negócios iniciante. Segue abaixo um pedaço da conversa de hoje:

 

#BA #PADAWAN: então, como combinei q seria mais inconveniente, queria saber se você n tem ai algum modelo de cronograma pra me ajudar... vou fazer aquele projeto de rastreamento de requisito e meu gerente quer um cronograma,  e um outro de estudar para tirar certificação uml.

Read the rest of this post »

“Uma visão sem ação não passa de um sonho.
Ação sem visão é só um passatempo.
Mas uma visão com ação pode mudar o mundo”.

- Joel Barker

Nada melhor para entender “qualé” da extensão ágil do BABOK 2.0 do que contato direto com um dos seus responsáveis, no caso o Luiz Claudio Parzianello (@lcparzianello).

Tive a oportunidade de interagir com o Luiz em duas ocasiões. A primeira foi na sexta passada quando ele palestrou no @PensandoLean realizado pela @Oncast, um evento muito bem bolado e realizado, que envolveu um curso de dois dias (do qual me arrependo fortemente de não ter participado) e um fórum cheio de palestras de peso, com a do próprio Luiz e de Mary e Tom Poppendieck, “os caras” do Lean Software Manufacturing.

A segunda ocasião foi aqui em Porto Alegre onde estou passando o feriadão. Uma feliz coincidência. Nos encontramos para uma conversa rápida na qual pude tirar algumas dúvidas a respeito da extensão ágil do BABOK que está me intrigando faz algum tempo.

Depois de trocar algumas ideias, chegamos à conclusão que a extensão ágil do BABOK tem funções distintas dependendo de quem a lê.

Fazendo o Analista de Negócios pensar na entrega (Deliver)

O Luiz prega algo que costuma passar batido pelos analistas de negócios: “a forma com a qual a solução é entregue é de total interesse do negócio”.

Tendemos a nos adaptar ao ambiente no qual estamos trabalhando, pensar nos requisitos de todos os níveis, em entender o problema, mas esquecemos de nos preocupar com a maneira com a qual a solução é entregue e como isso afeta o negócio.

Um esforço de análise de negócios que possa soar como ideal, no qual uma solução é definida com uma excelente análise do problema cai por terra se esta solução não for entregue em tempo e adaptada às mudanças naturais no ambiente de negócios.

Se pensarmos em questões como time to market e aprendizado organizacional, vamos notar que projetos cascata trazem um enorme risco inerente, principalmente pelo fato de termos um enorme lapso de tempo entre a concepção do projeto e a primeira entrega da solução ou parte dela. Só isso já deveria acender uma luz vermelha no painel de controle do AN.

Ou seja, o analista de negócios deve entender de metodologias ágeis, entender como funcionam projetos iterativos e de entrega contínua. Como bom profissional de negócios, vale a pena entender que o agilismo é filho da produção enxuta, do “Lean”, algo que nós administradores de empresas conhecemos bem desde meados dos anos 90, ou seja, nada radical ou absurdo e origem de muitos sucessos na indústria.

Por fim, descobrir sem entregar, é como visão sem ação (ou com ação muito mal feita). Não passa de sonho.

Fazendo o Agilista pensar em descobrir (discovery)

Já fiz uma sátira aqui no blog fantasiando que o Scrum foi definido em um bar e que quando alguém questionou de onde viriam os requisitos, alguém alcoolizado veio com a ideia do Product Owner e o pessoal se deu por satisfeito, bebeu mais e dormiu com a consciência limpa. Ahh, começaram a entregar software na semana seguinte. Algo que não deixa de ser impressionante.

Agora, falando sério, de onde vem “o que deve ser feito”? Um product backlog não cai do céu, e poucos POs devem ter a capacidade de psicografar requisitos direto do além.

O backlog, ou o termo que prefiro usar, o roadmap do produto que está sendo entregue nasce de um roadmap de alto nível, o roadmap do negócio dentro do qual este produto está inserido. O Luiz tem um slide que deixa isso muito claro, inclusive apresentando como a estrutura da estória do usuário faz com que esses dois roadmaps convergirem de forma genial.

E o quê orienta o roadmap do negócio? Simples, algo chamado estratégia.

Ou seja, se o agilista realmente deseja cumprir a sua missão de entregar valor, precisa entender de negócios, melhor, precisa entender de análise de negócios. Vale a pena abrir um pouco de espaço para ela no meio das discussões de assuntos legais como TDD, pareamento e integração contínua.

Apenas entregar transforma aquele gráfico do Scrum em uma montanha russa na qual o único objetivo é se divertir.

Por fim, entregar sem descobrir é como ação sem visão (ou com visão mal feita). Não passa de passatempo.

Conclusão

Ainda não sabemos se em contextos ágeis teremos a figura do Analista de Negócios, se chamaremos ele de PO dependendo do momento ou mesmo se conseguiremos ter a figura do product champion, mas está claro que descoberta e entrega devem parar de ignorar uma a outra. Projeto algum é completo sem uma delas.

Talvez o slogan da extensão ágil do BABOK deva mudar de “bring Business Analysis & Agile together!” para “bring discovery and deliver together!”.

 

 

 

Hoje fui brindado com duas aberrações. A primeira foi a propaganda política obrigatória que dispensa comentários e a segunda foi uma apresentação que o #PMI montou sobre #AGILE.

Não deixe de ver (isso e o Tiririca no horário político): http://www.pmi.org/Resources/Pages/Agile.aspx * o material foi removido pelo PMI

Não deixe de ler também "Uma humilde resposta ao posicionamento do PMI sobre Agile" do Ricardo Serradas:
http://blog.ricardoserradas.net/2010/08/18/uma-humilde-resposta-ao-posicionam...

Quando vi a apresentação, a primeira analogia que me veio à cabeça foi: bula de remédio. Você conhece bula de remédio? Já leu alguma pra valer ou sua mãe/esposa sempre cuidou dessa parte da sua vida?

Bem, uma bula de remédio costuma ter alguns conteúdos padrão como a posologia, que indica para quê o remédio serve, modo de usar (mantenha longe das mucosas...), contra-indicações, que indicam quando o remédio não deve ser usado e, por fim, os efeitos indesejados, ou "possíveis efeitos colaterais", a parte escrita para que você não possa processar o laboratório se der zica.

Aliás, essa parte dos "possíveis efeitos colaterais" é sem dúvidas a mais engraçada e assustadora da bula. Ali o pessoal exerce a criatividade. Se houver uma chance em um milhão de você ficar verde se tomar o remédio, isso estará escrito ali. Existem casos que calmantes possuem "insônia" como possível efeito colateral.

Read the rest of this post »

Hoje acordei com um desafio pela frente. Tinha que tirar os pontos da minha cirurgia de apendicite realizada há duas semanas. Bom, para o pessoal da saúde ou para quem já foi para a faca, ter receio desse procedimento é infundado, mas confesso que não acho nada agradável a ideia de ter fios pretos da sua barriga, em suma, estava desconfortável com a tarefa.

Meu desconforto deve ter origem em outra cirurgia que fiz quando era guri, lá em 89. Na memória embaçada tenho um corte grande (proporcionalmente falando) que levou muito tempo para sarar com pontos internos que não apareciam, havia só um nó em cada ponta. O médico cortou um nó e com uma pinça foi puxando pelo outro. Foi tudo de uma vez, mas foram os oito ou dez segundos mais longos da minha curta vida. Foi uma satisfação ficar tantos anos sem ter que ir para a faca novamente.

Recentemente acordei com um desafio pela frente. Tinha que discutir com um fornecedor um sistema de TI para o meu negócio. Bom, para quem é da área de TI ou para quem já tem vários sistemas informatizados na sua empresa, ter receio dessa reunião é infundado, mas confesso que não acho nada agradável a ideia de depender de um monte de caixinhas cheias de fios azuis e comandos esquisitos para as minhas operações, em suma, estava desconfortável com a tarefa.

Meu desconforto deve ter origem em outro sistema com o qual me envolvi quando era gerente lá em 98. Na memória embaçada tenho um corte grande na produtividade do meu departamento, um sistema que demorou muito para ficar pronto, que não ajudava tanto quanto eu gostaria e que volta e meia parava de funcionar por causa de coisas internas que não apareciam. Pior, eu não podia mais voltar ao processo anterior. Era um nó só. Quem já havia demorado para entregar e havia entregue um sistema ruim, depois de muita reclamação veio, fez uma análise completa e levou meses para trazer uma solução que ainda assim não resolveu tudo. Foram os oito ou dez meses mais longos da minha vida. Foi uma satisfação ficar tantos anos sem ter que ir para a fábrica de software novamente.

Read the rest of this post »

Ontem foi divulgada a versão draft da introdução da extensão ágil do BABOK que pode ser baixada aqui: http://iiba.info/AgileBABOK1. Achei muito interessante a atitude dos responsáveis de liberar o draft da introdução assim que pronto, digamos que isso tem tudo a ver com a ideia de entregas parciais orientadas a entregar antes o que tem mais valor.

Onde está o valor da introdução? Para mim está em finalmente saber "qualé" a da extensão ágil, algo que eu estava apenas especulando antes da "release".

Falando do "qualé", eu posso dizer que a extensão ágil poderia ser chamada de "um tempero ágil no BABOK", ou seja, a extensão pega todas as áreas de conhecimento do BABOK e as analisa de um ponto de vista ágil. Por que isso é necessário? Porque existe uma enorme tendência de interpretarmos a análise de negócios como uma fase em um projeto cascata. Realmente é muito difícil ler o BABOK sem tender a isolar essas atividades em algum momento inicial do projeto, mesmo quando se fala em gerenciamento e comunicação dos requisitos, que é algo que ocorre durante o projeto todo, parece que estamos pensando no famigerado "gerenciamento de mudanças".

Se não houvesse esse "viés" na compreensão do BABOK, acredito que seria justificável também uma extensão cascata do BABOK, já pensou?

Existe um título dentro da introdução que achei muito bom, "Agile Thinking for Business Analysts" (algo como "Pensamento Ágil para Analistas de Negócios"), essa parte do texto repete de forma mais específica a parte do BABOK que já fala sobre as diferenças entre "change-driven" e "plan-driven", algo que elogiei anteriormente por achar que esses dois nomes são mais genéricos e trazem menos "ranso" consigo do que waterfall e agile.

Até aí digamos que não existe nada muito novo e pouco conhecimento prático é apresentado, contudo, quando chegamos ao "Agile Manifesto Applied to Business Analysis" (algo como "Manifesto Ágil Aplicado à Análise de Negócios") a coisa começa a fica mais pragmática e útil. O impacto de cada item do manifesto ágil é rapidamente descrito (e, espero que posteriormente aprofundado). Tomo a liberdade de traduzir (meio nas cochas) esses parágrafos aqui:

Indivíduos e interações sobre processos e ferramentas: A análise de negócios ágil tira o foco de processos e templates restritos e o coloca em auxiliar o time de entrega a identificar e implementar valor para o negócio.

Software rodando sobre documentação abrangente: As práticas ágeis reconhecem que existe pouco valor intrínseco nos produtos internos e transitórios que não serão referenciados após a implementação. O foco da análise de negócios ágil não está em entregar documentos perfeitos para o time, mas em ajudar o time a entregar soluções rodando, baseadas na entrega incremental ou just-in-time (JIT) de requisitos.

Colaboração do cliente sobre a negociação de contratos: Tradicionalmente, um foco chave da análise de negócios está em conseguir a aprovação do cliente e assinaturas em documentos de requisitos. A análise de negócios ágil atua sobre essa questão produzindo o mínimo de documentação que é entregue o mais tarde possível dentro do projeto. Não é apenas a colaboração do cliente que é enriquecida, a colaboração entre todas as partes aumenta. O relacionamento com o cliente é baseado na cooperação, não na passagem de bastão entre fases, e a análise de negócios é crítica na facilitação da cooperação e na garantia de que existe comunicação suficiente.

Responder à mudança sobre seguir um plano: Em projetos tradicionais cascata, um esforço para criar um grande desenho já de início (big design up-front) é convertido em um plano e o time deve seguir o plano - mesmo quando o tanto o cliente quanto o time concordam que a sua compreensão dos requisitos sofreu mudanças. Praticantes de agilismo adiam o comprometimento com o próximo trabalho a ser executado até o "último momento responsável" e oferece visibilidade e transparência para o cliente que permitem que ele tome decisões sobre o que construir e quando. A análise de negócios ágil requer o estabelecimento de um framework forte que garanta que o time de desenvolvimento permaneça focado no valor e sempre capaz de responder às mudanças.

Ao ver o título "Business Analysis for Agile Practitioners" (algo como "Análise de Negócios para Praticantes do Agilismo") eu pensei que encontraria os argumentos que eu mesmo usaria para justificar a minha existência em contextos ágeis, contudo, esta parte fala sobre itens que auxiliam o analista de negócios a se encaixar nesse contexto, como "o momento da análise de negócios ocorrer", "a natureza da análise de negócios" e o "nível de compromentimento", o que também é útil.

Voltando ao pragmatismo e à utilidade, o título "Agile Practices for Business Analysis" (algo como "Práticas Ágeis para Análise de Negócios") faz um pequeno resumo sobre como fica cada área de conhecimento do BABOK de uma ótica (ou com tempero) ágil. Aqui dou ênfase novamente para a área de conhecimento que não pode morrer nunca, independente do contexto, a elicitação de requisitos.

Em "Business Analysis in the Life of an Agile Practitioner" (algo como "A Análise de Negócios na Vida de um Praticante Ágil") temos uma visão rápida, mas útil, dos papéis responsáveis por executar atividades da análise de negócios dentro do contexto ágil.

Em uma análise rápida, com base no que li, acredito que a maior diferença, ou impacto, ou valor trazido por avaliar a análise de negócios de um ponto de vista ou tempero ágil é o fato de que nesse contexto, as atividades de análise de negócios não são de propriedade de um único profissional, de um único salvador da pátria ou ser iluminado.

Como isso vai afetar a visão de analista de negócio como profissional, os esforços do IIBA para conseguir reconhecimento para essa personagem, só o futuro dirá, contudo, digamos que nos ambientes ágeis, a análise de negócios sai do mindset comum de quem quer definir um escopo de atuação representado por apenas um profissional (como acontece com o gerente de projetos).

Só sei que acabei de participar como PO de uma reunião junto ao time de desenvolvimento e que poder compartilhar o fardo da análise de negócios é muito bom.

 

Leia também: BA = PO?

 

 

 

Apesar de discordar dessa afirmação, existem boas razões para que os profissionais considerem que o Analista de Negócios é o Product Owner e vice-versa. Faz um tempo que quero escrever sobre o assunto para a comunidade de analistas de negócios, mas como meu mapa astral mostrou, sou tanto prático quanto teórico, então esperei colocar a mão na massa do lado PO da equação, já que tenho vivido apenas do lado BA nos últimos anos.

 

Read the rest of this post »