PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Engenharia de Software

  • Iterativo & Incremental: Um Convite aos Erros

    Entre todos os mistérios que rondam nossa área há um difícil de explicar e justificar: qual a razão de tanta resistência na adoção de um ciclo de desenvolvimento que seja iterativo e incremental?

    Nos últimos três anos, só por conta do FAN, pude falar com mais de dois mil profissionais e estive pessoalmente em dezenas de empresas. Sei que não tem valor de pesquisa, mas foi fácil concluir que pelo menos 95% deles ainda trabalham baseados em um modelo “cascata” (ou Waterfall) de desenvolvimento¹. Se considerarmos que já tem quase duas décadas que vários autores, metodologistas, empresas e consultores recomendam a adoção de outro modelo, qual a razão da incontestável predominância da “cascata”?

    Não, este (pequeno) artigo não tem a menor intenção de reativar o debate ou destacar prós e contras de cada proposta. Aliás, se você quiser uma boa justificativa *econômica* para adoção do modelo iterativo & incremental, deveria ler este texto do José Paulo Papo. Minha preocupação aqui é outra.

    Comumente apresentamos o modelo iterativo e incremental, independentemente do sabor (RUP, XP, Scrum, OpenUP…), como um remédio para as inevitáveis mudanças. Esse discurso costuma encontrar dois tipos de reflexos:

    1. (Ainda) existem aqueles que acreditam que mudanças ocorrem exclusivamente porque o entendimento do problema não foi bem realizado. São os mesmos que, infelizmente, acreditam que a Análise de Negócios é a resposta definitiva para especificações (sic) mal feitas. O que vemos neste cenário é mais gente gastando mais tempo e dinheiro para escrever mais. Deveríamos escrever melhor, estruturar melhor as informações aprendidas e colaborar, conversar mais. E não escrever mais e de maneira mais detalhada².
    2. “Os requisitos são estáveis e temos uma ótima compreensão do problema que iremos sanar. Podemos trabalhar em ‘cascata’”. É um reflexo parecido com o anterior mas com uma diferença: há realmente a sensação de que o solo pisado é de fato conhecido. Esta é uma das justificativas que encontro com maior frequência para a não adoção de um modelo iterativo e incremental.

    Percebendo os dois reflexos alterei minha maneira de apresentar e “vender” o modelo iterativo e incremental. Transcrevo abaixo o que costumo falar nos treinamentos e consultorias:

    O que é bonito no modelo iterativo & incremental é que ele reconhece um fato que nunca mudaremos: somos humanos. Ou seja, nós vamos cometer erros. Vários! Ao adotar este modelo estamos dizendo para nossos usuários e clientes: “Nós vamos errar, caríssimos, todos nós. Às vezes será um problema de interpretação de seus requisitos e histórias. Outras tantas vocês errarão, na explicação ou apresentação das próprias necessidades. E, precisamos admitir, muitas vezes as funcionalidades entregues não os atenderão pelos mais diversos motivos. Não importa. Aliás, não importa desde que o modelo de desenvolvimento adotado reconheça essa verdade: somos humanos e vamos errar”.

    Esse discurso gera duas respostas muito positivas: i) desarma aqueles que ficam louquinhos por um debate; ii) facilita a compreensão por todos que nunca trabalharam de outra maneira que não seja a “cascata” ou o “caos absoluto”. São bastante perceptíveis também as carinhas de surpresa que surgem com a repetição de uma palavrinha: Erro.

    Criamos uma cultura que combate e pune erros. Mesmo em ambientes que se dizem “inovadores” o erro ainda é mal visto. As pessoas vivem com medo de errar. Imagine então o desafio de dizer, antes mesmo do início de um projeto, que erros acontecerão. Mas é fato: erramos. Pra caramba!

    Clientes e usuários costumam gostar muito dessa transparência, dessa sinceridade. Estranham porque ela não é muito comum em nosso mercado. Mas aceitam o modelo e o consequente desafio com mais facilidade³. Daqui para a adoção de outras práticas mais modernas é “um tirinho”.

    .:.

    Observações:

    1. Num belo dia um cliente pediu que eu pulasse essa parte do curso: “A gente já desenvolve assim”. Obedeci. Mas depois o treinamento caminhou na base de soluços. Descobri o problema e o susto que curou o soluço: “É que nossas iterações duram algo entre 3 e 4 meses”. Ou seja, eles não desenvolviam de forma iterativa e incremental. Era outra coisa.
      Um outro freguês, agora numa turma aberta, disse que usa Scrum mas que tem que levantar todos os requisitos no início do projeto. Ou seja, não era Scrum. Também era outra coisa qualquer que nem merece nome.
    2. Era uma vez uma empresa que terceirizava todo o trampo de codificação para “fábricas de software” (sic). Eu apresentava para eles os 5 ícones recomendados pelo Cockburn (“Escrevendo Casos de Uso Eficazes”, Bookman. 2006) para indicar o nível de detalhamento de uma especificação de caso de uso. Eles disseram que, para trabalhar com fábricas, os 5 não seriam suficientes. Pediram a criação de outro, abaixo da “ostra”. Sugeriram a colocação da logomarca da Petrobras. E explicaram: “É o nível ‘pré-sal’, sete mil metros abaixo do nível do mar! Só assim o pessoal da fábrica entende.” Repito: não é escrever mais. Não deveria ser…
    3. Era outra vez, lá pelos idos de 2001 ou 2002, eu tocava um projetão. ÃO mesmo, em porte e complexidade. Sabe-se lá porque ($$$) topamos que o cliente “espelhasse” toda nossa estrutura gerencial. Para cada líder de nosso lado, eles colocavam um líder do lado de lá. Um mês de lua-de-mel. Um mês de “briguinhas”. E no terceiro mês a pérola: “Para com esse negócio de iterativo e incremental – queremos que seja cascata”.
      Juro, não é cascata não. Contei a história aqui só para dizer que a palavra “facilidade”, escrita ali no último parágrafo, deve ser interpretada com a devida precaução.
    4. “Funny“, a foto utilizada acima, é da Tanakawho. Sempre ela!

  • {finito} 2010

    Resoluções retardatárias? Pois é, meu planejamento atrasou um pouco. O ano começou diferente dos anteriores, com turma fechada do FAN acontecendo em Sampa. E a maioria das minhas ideias para 2010 requer um tempo de maturação e até versões ‘beta’. Como de costume, vou escancarar aqui algumas delas. Para quê? Uai, o feedback antecipado de potenciais usuários e clientes é sempre bem-vindo, certo?

    O Blog

    Alguns costumes e manias não resistem a um bom teste unitário. Sei lá porque um dia decidi que publicaria aqui apenas artigos mais trabalhados que, invariavelmente, também são longos (quase sempre com mais de 1000 palavras). Artigos assim costumam demandar algo entre uma e quatro semanas de elaboração. Não de redação e edição, claro, mas de pesquisa e compilação. O problema com este enfoque é que deixo de falar sobre um monte de assuntos que, desconfio, também interessariam aos leitores fiéis ou ocasionais. Portanto, aguardem mais e menores blues, digo posts. O que não significará o fim daqueles verborrágicos, para tristeza dos apressados.

    Outro velho projeto que deve finalmente vingar é a criação de outras seções aqui no finito. Duas aparecem no topo do blog backlog: 1) Bibliografia Comentada, com dicas de leitura e trilhas de estudo; e 2) Bate-papo com profissonais da área e usuários. Penso na transcrição totalmente sem edição de prosas facilitadas por IM’s e afins. O primeiro convidado parece não ter gostado muito da ideia mas insistirei. As duas novas seções pretendem trazer vozes e pontos de vista distintos deste que aqui rabisca.

    Cursos e Palestras

    Não foi o que planejei 4 anos atrás, quando iniciei a carreira solo. Mas os Cursos e Palestras se transformaram em minha vaca leiteira – no Lucro e não no Troco¹. Ao invés de nadar contra a maré, é preferível que eu reforce minhas ofertas. Principalmente para tentar me distanciar do oceano vermelho de sangue que caracteriza esse mercado. Gosto do modelo utilizado no FAN – eventos curtos e práticos. Mas a estabilidade dos times que estão ganhando é uma perigosa ilusão. Está aqui o desafio que mais tem ocupado meu tempo nas últimas semanas.

    Devo lançar simultaneamente, ainda neste primeiro trimestre, dois novos eventos. Serão dirigidos para públicos diferentes mas vão compartilhar o mesmo formato e nome: “O Jogo dos 7 Erros“. Um será voltado para líderes de projetos e outro para meu público-xodó, os analistas de negócios. O formato é de um jogo realmente. Cada erro merecerá uma hora. Os exercícios tomarão metade do tempo. O restante será utilizado na apresentação do erro, casos e para o debate com a turma. Como o formato é muito novo os eventos serão lançados como ‘beta’ e terão preços especiais. Aliás, tudo será novo e o teste é mais que necessário. Inclusive ou principalmente do material didático. As primeiras turmas devem acontecer em São Paulo.

    As novas ofertas não significam que o FAN irá para escanteio, pelo contrário. Novas turmas serão abertas, a partir de abril, em São Paulo e Brasília.

    Serviços

    É curioso como meus “patinhos feios” atraem atenção quando apresentados de maneira menos formal. Particularmente o conjunto de serviços que identifico como Administração de Ativos. Ou seja: erro feio na mensagem que transmito aqui e no material de marketing que desenvolvi. Duas providências: 1) Alterar a apresentação “formal” dos serviços; e 2) Lançar, no segundo semestre, eventos que mostrem de maneira mais clara a importância de alguns temas, particularmente a Administração de Ativos e a Engenharia de Processos. Pacotes de treinamento + consultoria devem ser a melhor resposta. Mas eu tratei de deixar bem baixas minhas expectativas para 2010.

    E o livro, sai ou não sai?

    Transparência é jóia e dá retorno. Mas também pode te deixar assim, sem ter onde esconder a cara quando alguma coisa não vai bem. Hoje eu entendo porque Nicholas Negroponte e Louis Gerstner resolveram nunca mais escrever depois de lançarem seus primeiros livros. “É o Negócio, Beócio!” é de longe o pior projeto que já assumi em minha vida. E eu tratei de torná-lo cada vez pior, prometendo prazos mesmo quando não era cobrado por isso. Acabei por transformá-lo em um verdadeiro pesadelo quando deixei os alvos ficarem móveis. Justo eu, que insisto com os 4 ventos que um projeto não pode dar certo se não tem objetivos bem claros.

    Pois bem, o livro já foi escrito 4 vezes. Acho que já contei isso aqui. Duas versões não mereceram a luz do sol e foram direto para o lixo (shift+del mesmo). Alguns capítulos da última versão foram publicados. Mas, apesar do feedback relativamente favorável, alterei a estrutura e me perdi novamente. Tudo fica um tanto surreal quando me lembro que em apenas 4 meses, no longínquo 2007, eu escrevi uma versão quase completa. Hoje tenho a sensação de estar muito próximo da estaca zero.
    E olha que até capa(s) ele já tem²!

    Inicialmente o livro seria um “Guia para a Formação de Analistas de Negócios”. Quando comecei a aceitar que este deve ser também o meu último livro resolvi que ele podia ser um pouco mais abrangente. Ambiguidade é risco. E aquele “pouco” da penúltima frase virou um imenso problema. O lado bom do desabafo aqui é que, além de tirar um grande peso de meus ombros, dá ânimo para pegar no trampo de novo.

    Epílogo?

    Que nada! Prólogo para um 2010 que promete. Mas antes de começar eu preciso agradecer a todos que fizeram de 2009 um ano bem legal e produtivo: Leitores do finito, participantes do FAN e do grupo AN.br, clientes, parceiros e amigos. Espero que tenhamos boas desculpas para novos encontros.

    Observações

    1. Lucro | Troco | Truco é uma versão tropicalizada daquele esquema “70% 20% 10%” que seria utilizado pela Google. Dedico 70% do meu tempo em ofertas que representam meu negócio principal, o Lucro. O Troco, que ocupa 20%,  é aquela receita básica e normalmente pequena que serve para pagar despesas fixas. E o Truco é uma ideia maluca qualquer que só merecerá mais de 10% do tempo quando mostrar potencial para virar Lucro ou Troco. Junto com o esquema Conteúdo -> Conversas -> Transações, este conceito dá forma ao núcleo do modelo de negócios do finito.
      Pois é, formalizei lá em cima que Cursos e Palestras passam a merecer 70% do meu tempo. Pelo menos até o início do 2º semestre.
    2. As capas foram desenvolvidas pela Sabiá. Me apresentaram 6 sugestões e até hoje o máximo que consegui foi eliminar duas. É provável que o livro saia com 2 capas oficiais, uma para descolados e outra para… hmm… menos descolados, hehe…
    3. O finito ganhou chaves?!? {finito}
      Têm algum significado?

  • O Novo Gerente de Projetos

    Quase cometi um “O Mundo Ágil precisa de Gerentes de Projetos?“. Não o fiz porque, além de apelativo, o título remeteria ao artigo anterior, quando repeti a mesma pergunta para falar sobre analistas de negócios. Se naquele texto eu apresento uma conclusão, agora meu objetivo é apresentar alguns cenários e provocações. Na realidade, vou apenas compilar e repassar uma série de ‘achados’ que devem nos ajudar a debater e, se for o caso, definir um novo Gerente de Projetos. Soou pretencioso, né? Repare que a intenção é ajudar a definir, ok? São meus R$ 0,02.

    Antes de qualquer coisa: por que precisaríamos de um novo gerente de projetos? Algumas respostas: 1) O Mundo Mudou; 2) Os Fracassos são Constantes; e 3) Os Gerentes Vivem Sobrecarregados e Criticados. Se você não acredita nessas motivações ou acha que elas não são suficientes para justificar esse papo todo, então poupe seu tempo. Caso contrário, espero não chateá-lo com a série de 3 ou 4 partes que se inicia aqui. Sim, precisarei de uma série para desfilar alguns ‘achados’. Vamos lá.

    Gerentes de Projetos Vivem Sobrecarregados e Criticados

    E as causas são conhecidas. Em TI, insistimos em gerentes de projetos (GP’s) que também devem apresentar bons conhecimentos de determinadas tecnologias. Ou seja, muitos esperam que o GP seja também uma espécie de arquiteto. Ou, no mínimo, que ele consiga orientar ou validar o trabalho técnico desenvolvido. Isso sem isentá-lo de todas as tarefas administrativas. Não é a primeira vez que toco neste ponto e não pretendo explorá-lo em maiores detalhes. Me limitarei a citar Fred Brooks (“O Mítico Homem-Mês”, Campus, 2009): “Pensadores são raros. Executores são raros. Pensadores-executores são raríssimos”.

    Outra causa do excesso de trabalho é o microgerenciamento. Não importa se a “culpa” é do profissional ou do processo utilizado. Ou mesmo da falta de um. O fato é que, a partir de determinado porte, é simplesmente impossível microgerenciar um projeto. Claro, considerando uma jornada de trabalho de 8 horas por dia.

    Mas o efeito mais importante do microgerenciamento é outro: a insatisfação da equipe. Projetos de TI são tocados por “trabalhadores do conhecimento” – profissionais que gostam e precisam de espaço e autonomia para desempenhar bem suas funções. Temos aqui um típico exemplo de relação “perde – perde”.

    Aquilo que chamo de “Mundo Ágil”, o conjunto de propostas derivadas do Manifesto Ágil, endereça essas questões de diversas maneiras.  Tem poucos dias, por exemplo, Tobias Mayer escreveu em seu Twitter que: “Projetos ágeis não precisam ser ‘gerenciados’. Eu gostaria que este oxímoro fosse banido de nosso vocabulário”. Sua ‘revolta’ foi motivada por este anúncio, que fala de certificação em gerenciamento de projetos ágeis.  Só para clarear: oxímoro é uma figura de linguagem que coloca dois termos antagônicos, contrários, em uma mesma expressão. Tobias considera então que “gerenciamento” e “projetos ágeis” devem ser como água e óleo. Desconfio que ele quer dizer outra coisa: projetos ágeis não precisam de gerentes.

    A implementação mais comum deste conceito de “não-gerenciamento” é o “autogerenciamento”. A equipe se gerencia, sem nenhum tipo de interferência externa. Não há ingerência, já que todos podem falar sobre o trabalho de todos. Na realidade, em dada situação, algum membro da equipe pode assumir a responsabilidade por uma tomada de decisão. Mas o gerenciamento é uma responsabilidade de todos.

    Ainda no Mundo Ágil, mas em um pólo bem diferente de Tobias e outros, está Jim Highsmith. Na segunda edição de “Agile Project Management” (Addison-Wesley, 2010) ele quebra o termo “autogerenciamento” para clarear alguns pontos. Ele defende que uma equipe seja auto-organizada. Isso estaria no ‘core’ do APM (Agile Project Management) e a sua viabilização seria uma das principais responsabilidades de um Líder (ele não usa os termos gerente ou coordenador de projetos).

    Ainda segundo Jim, existem também os times “autodirigidos”, aqueles que independem de um líder. Em inglês ele usa o termo Leaderless. Para ele, esse tipo de estrutura “vai contra várias pesquisas que mostram que o sucesso em projetos e organizações dependem de bons líderes”. Algumas páginas adiante, mais precisamente na 60, Jim ‘desce o malho’: “Equipes auto-organizadas estão no núcleo do gerenciamento ágil, mas os conceitos estão corrompidos em setores da comunidade ágil. Apesar de ser um bom termo, ele tem sido, infelizmente, confundido com anarquia”. E prossegue: “É fácil combater os gerentes fracos e defender sua eliminação. Muito mais difícil é trabalhar com as organizações para que elas alterem seu estilo de liderança de forma a suportar um ambiente ágil”.

    Melhores líderes e um melhor estilo de liderança  não significam, na visão de Jim, que uma equipe não possa se auto-organizar e autogerenciar. Seria tudo uma questão de equilíbrio: “Auto-organização significa que, na medida do possível, a tomada de decisões é delegada para os times”. E explica: “Mesmo que líderes ágeis devam ser ‘light’ em termos de decisões ‘top-down’, eles devem ser ‘heavy’ na articulação de objetivos, facilitação de interações, melhoria da dinâmica da equipe, suporte a colaboração e incentivo da experimentação e inovação”.

    Não me parece uma coincidência o fato da lista acima guardar várias semelhanças com aquela apresentada no artigo anterior, que tratava das responsabilidades de um Dono do Produto em um projeto guiado pelo Scrum. Vale lembrar: o Scrum é uma metodologia que, em certo sentido, se propõe Leaderless. As responsabilidades sobre o gerenciamento são compartilhadas pelo ScrumMaster, Dono do Produto e Time.

    Acontece que, em vários trabalhos mais recentes (como “Product Management with Scrum”, de Roman Pichler – Addison-Wesley, 2010), a função do Dono do Produto está sendo apresentada de tal maneira que chega a ser estranho o fato dele não ser tratado como um Líder. De uma forma ou de outra, os autores são claros em um ponto: trata-se da função mais crítica e difícil em uma iniciativa guiada pelo Scrum.

    Por fim, gostaria de destacar algumas possibilidades apresentadas por Phillip “Shoes” Calçado no papo que tivemos sobre o último artigo: “Cada projeto tem necessidades específicas. Como analogia, em alguns projetos precisamos de alguém 100% do tempo atuando como gerente de projetos e ainda de um gerente de iteração. Em outros projetos apenas o gerente de iteração pode fazer PM e IM. E em outros um desenvolvedor ou BA sênior pode facilmente fazer o seu papel e ainda cuidar de gerência de projetos.”

    Queria apenas acrescentar que essa divisão entre gerenciamento de projetos e gerenciamento de iterações é totalmente compatível com o framework proposto por Jim Highsmith no livro citado acima. Aliás, “Agile Project Management – Second Edition” é uma compilação de práticas estruturada em torno de 3 das 4 “camadas” que formam o que Jim chama de “Agile Enterprise Framework”. As quatro “camadas” são: Governança do Portfolio, Gerenciamento de Projetos, Gerenciamento de Iterações e Práticas Técnicas. Apenas essa última camada, formada por práticas de engenharia, não está no escopo do livro.

    Como eu disse lá em cima, (ainda) não apresentarei conclusões. Na próxima parte da série falarei sobre “Fracassos”. Inté.

    .:.

    Observações

    A imagem utilizada, flikr0629, é de flikr e foi surrupiada no Flickr. Simples assim.

  • O Mundo Ágil precisa de Analistas de Negócios?

    Na realidade, a dúvida mais frequente em nossos papos e debates é: Como o Analista de Negócios (AN) se ‘encaixa’ em um projeto guiado por um método ágil? Acontece que possíveis respostas para essa questão obrigatoriamente nos levam para a pergunta do título: Projetos ágeis precisam de AN’s? Temo que não são poucos os que responderiam com um rápido e sonoro: Não!

    E não é muito difícil entender suas razões. Primeiro, como Roman Pichler lembra em “Agile Product Management with Scrum”¹, nenhum livro “clássico” derivado do Manifesto Ágil cobre aquelas etapas iniciais de um projeto que podem se beneficiar da atuação de um AN. Ken Schwaber, em “Agile Project Management with Scrum” (2004), Kent Beck, “Extreme Programming Explained” (1999) e “Crystal Clear” (2005) de Alistair Cockburn – todos partem de uma visão ou pauta* (Product Backlog) previamente definidos. Pouco ou nada falam sobre aquele momento em que equipe e organização definem ou, melhor dizendo, começam a definir o que precisa ser feito.

    Pichler não cita, mas “Agile Project Management – Second Edition” (2010) de Jim Highsmith e até “Utilizando UML e Padrões” (2008) de Craig Larman apresentam a mesma restrição. Este último não o faz de maneira explícita, como é comum em obras baseadas no Processo Unificado (PU). Mas isso é assunto para outro artigo. O que nos interessa aqui é a confirmação de que não só o AN, mas a própria Análise de Negócios é em parte ignorada por pessoas e obras que ajudaram a fundar, definir e consolidar o Movimento Ágil.

    Por favor, não entenda que a análise de negócios é apenas uma fase no início de um projeto. Utilizada corretamente em um modelo de ciclo de vida iterativo e incremental, ela existirá durante todo o projeto. E até depois dele. O que tento destacar aqui é que, nas fases iniciais de um projeto, a análise de negócios é caríssima. E o é porque é ela que ajuda a definir uma clara visão dos objetivos do negócio ou do produto. E, como diz Jim Highsmith², “na ausência desta clara visão, a natureza exploratória de um projeto ágil resultará numa espiral infinita de experimentações”. No popular: “para quem não sabe para onde vai, qualquer caminho serve”.

    Não é minha intenção tentar explicar essa grave omissão. Já ouvi muitas pessoas dizendo que a Análise de Negócios seria, por si só, um projeto específico. Não concordo. Todo projeto de software depende, mesmo que em graus diferentes, de um conjunto de métodos e práticas que: 1) ajudam a definir o que precisa ser feito; e 2) ajudam a garantir que o que está sendo feito realmente atende aos objetivos fixados (e respeita as restrições colocadas). A esse conjunto foi dado o nome “Análise de Negócios”. E eu não entendo como um projeto para a construção ou implantação de um sistema de informação poderia prescindir dele.

    Um segundo motivo pelo qual os AN’s parecem “ignorados” pelo Mundo Ágil é a forma como este, em seus vários sabores e formas, conclama e exige uma participação mais efetiva dos usuários e demais partes interessadas que não fazem parte do “time de construção”.

    Na proposta conhecida como eXtreme Programming (XP ou XisPê), por exemplo, uma prática requer o usuário literalmente sentado ao lado dos desenvolvedores. Costumo brincar que, quando um bom AN se deparar com um usuário que tenha total disponibilidade para ficar alimentando um projeto com seus requisitos, deveria recomendar sua sumária demissão. É brincadeira. Mas procura iluminar um ponto crítico: quem, nos dias de hoje, pode abandonar seus afazeres cotidianos durante todo um projeto? É claro que se trata de uma prática de difícil aplicação. Assim como deve ser óbvio que, quando possível e em determinados tipos de (pequenos) projetos, ela deve ser adotada. Não questiono sua eficácia. Apenas desconfio de sua viabilidade.

    O Scrum é outra proposta derivada do Mundo Ágil, que se caracteriza ultimamente pelos altíssimos índices de popularidade. Ele concentra suas sugestões nos aspectos gerenciais de um projeto. E define a existência de 3 “entidades” principais na comunidade de um projeto: o ScrumMaster, o Time e o Dono do Produto (Product Onwer). Este seria o representante de todos os usuários e teria, segundo Ken Schwaber (um de seus “criadores”), duas grandes responsabilidades: 1) Maximizar o ROI (Retorno sobre o Investimento); e 2) Gerenciar a Pauta (Product Backlog). Roman Pichler, no mesmo título citado anteriormente, sugere uma revisão das duas principais preocupações que devem guiar o Dono do Produto. Elas seriam: 1) Definir a Visão; e 2) Entregá-la!

    Repare como a sugestão de Pichler se encaixa perfeitamente na definição da análise de negócios que apresentei acima: 1) Ajudar a definir o que precisa ser feito; 2) Ajudar a garantir que a entrega realmente satisfaz os objetivos colocados. A mudança está apenas no tom, no tamanho da responsabilidade: o Dono do Produto realmente define a visão e é o principal responsável por entregá-la**. A análise de negócios ajuda.

    Então podemos dizer que o Dono do Produto (DP) elimina a necessidade de um Analista de Negócios (AN)? Em minha opinião, quase nunca! Citarei Pichler novamente, listando aquelas que seriam as responsabilidades de um DP:

    • Pesquisa de mercado;
    • Planejamento do Produto;
    • Análise de Negócios (!);
    • Gerenciamento da Pauta (Product Backlog);
    • Descoberta, Descrição e Priorização de Requisitos;
    • Gerenciamento de Versões (Releases);
    • Acompanhamento da evolução do projeto;
    • Gerenciamento do orçamento;
    • Relacionamento com clientes, usuários e outras partes interessadas; e
    • Participação nas Reuniões Scrum.

    Gerentes de projetos devem ficar um tanto “encafifados” com a listinha acima. Mas outro dia eu falo com eles. A questão aqui é: até que ponto é possível que apenas uma pessoa realize (bem!) todas as atividades listadas acima? Repare ainda como questões operacionais, táticas e estratégicas são misturadas, causando a falsa impressão de que seriam equivalentes. E lembre-se que existem pessoas que ainda cogitam a utilização de um DP que não tem 100% de disponibilidade de tempo para o projeto!

    Não é por acaso que vários trabalhos recentes – dentre eles o já citado Pichler e também “Scrum Product Ownership”³, de Bob Galen (2009) – afirmam que o trampo do DP é “o mais pesado em um projeto Scrum” (Galen). Portanto, não deve causar espanto nem revolta o fato de alguns autores começarem a sugerir uma Equipe do Dono do Produto. Pichler chega a citar um exemplo mostrando uma equipe formada por “dois analistas de negócios, um arquiteto chefe e um assistente de projeto”, além do próprio DP, é claro.

    É importantíssimo salientar que o DP continua sendo uma única pessoa. O que muda com a sugestão acima é a aceitação de que o DP não dá conta sozinho de tudo o que ele precisa fazer. Mesmo em projetos considerados pequenos. Sendo assim, ele sempre poderá montar um time próprio. Sinceramente, eu não entendi o que um “arquiteto chefe” fez naquele exemplo do Pichler. Mas, tendo em vista a lista de responsabilidades acima, é muito fácil supor a ajuda que AN’s podem dar para os DP’s. Sendo mais direto: todo o trabalho operacional listado (descoberta e descrição de requisitos; análise de negócios de uma maneira geral; pesquisas e parte do relacionamento com outras partes interessadas) pode ser atribuído exclusivamente para AN’s. Além, claro, do apoio na execução de atividades de caráter tático (como o gerenciamento da pauta).

    Eu entendo e até tento compartilhar o temor que muitos demonstram quando veem uma sugestão como essa. Mais pessoas, mais intermediários, podem comprometer a qualidade da comunicação. Nunca vou dizer que esta não é uma preocupação relevante. Acontece que os problemas causados por um DP sobrecarregado podem ser consideravelmente piores. Imagine, por exemplo, o início de uma iteração sem uma pauta fechada; ou então com uma pauta repleta de requisitos (ou histórias) incompletos, ambíguos ou mal estruturados e porcamente priorizados.

    Se ambos os cenários, comunicação e sobrecarga, são ruins e indesejáveis, mas devemos escolher um, qual seria melhor administrado? Qual representa menores riscos?

    Conclusões (?)

    Reparou nas datas de publicação das obras citadas? Pensou na base histórica que temos desde o dia 13 de fevereiro de 2001, data de ‘nascimento’ do Manifesto Ágil? Desconfiou que a consolidação de nossos métodos de experimentação (desenvolvimento) é também uma experiência? Por isso tasquei um ‘?’ ali no subtítulo. Porque conclusões, nesta altura do campeonato, ainda são muito perigosas. E relativamente frágeis. Daí a quantidade de debates e embates que vemos por todo canto. De um lado, ainda vemos muita resistência em mudar (o que configura uma boa piada). De outro, muitas vezes, a falta de humildade para admitir que ainda estamos todos aprendendo.

    Por isso, caros AN’s (e GP’s), não é preciso ter medo do ‘monstrinho’ Ágil. Todo projeto seguirá apresentando necessidades e consequentes atividades, independentemente do processo, metodologia ou ‘modinha’ utilizada. Todo projeto seguirá tendo uma etapa onde definimos o que precisa ser feito. Assim como todo projeto seguirá precisando de líderes.

    O que não pode significar, de forma alguma, que você AN (ou GP) possa baixar a guarda e ignorar tendências fortes, verdadeiras, viáveis e inevitáveis como o Movimento Ágil. E o SEMAT (?). E o Flu? E 2012?? E o Flamengo e a Terezinha???

    Desconfianças (!)

    Foi um bom mineiro, Guimarães Rosa, quem disse: “Sei de nada não… Mas desconfio de muita coisa”. Quem dera eu tivesse as desconfianças do Rosa. As minhas, no assunto em questão, são:

    • Não vejo mais com bons olhos a alocação de um AN para desempenhar o papel de Dono do Produto. Cheguei a sugerir isso algumas vezes. Peço desculpas e retiro minha sugestão. O DP deve ser de fato uma pessoa do negócio (ou, em algumas situações, o Gerente do Projeto).
    • Em projetos guiados pelo Scrum, o AN deve fazer parte do Time do Dono do Produto. Em muitos projetos, bastará 1 (um) AN. Seu par, na maioria das atividades, será o próprio DP ou um integrante do Time.
    • Corpos de conhecimentos vão incorporar cada vez mais práticas ágeis. Não adiantará muita coisa se seus espíritos (Princípios) não forem seriamente questionados.
    • AN’s (e GP’s) que já se deparam com projetos ágeis ou desconfiam (ou desejam!) que eles estejam em seu horizonte próximo, deveriam priorizar o estudo de obras como aquelas listadas abaixo, em detrimento até mesmo do BABoK (por razões já explicadas aqui).
    • Opa, quase me esqueci. A resposta é: Sim, o Mundo Ágil precisa de Analista de Negócios.

    Bibliografia

    1. Agile Product Management with Scrum
      Roman Pichler. Addison-Wesley (2010).
      Obs.: Tomei por base uma versão preliminar do livro, um Rough Cut. Seu lançamento está previsto para 5/mar/10.
    2. Agile Project Management – Second Edition
      Jim Highsmith. Addison-Wesley (2010).
      Obs.: Já disponível.
    3. Scrum Product Ownership
      Bob Galen. Draft v1.3 (2009).
      Obs.: A versão final, independente, já está disponível via Lulu.

    Observações:

    A foto utilizada neste artigo, “Danger: Keep Clear“, é do PSD, surrupiada legalmente no Flickr porque liberada como Creative Commons (by).

    * A sugestão do termo “Pauta” como alternativa para “Product Backlog” deve ser creditada para o colega Leandro Mendonça. Muito obrigado, meu caro. Tenho testado o termo com um surpreendente índice de aceitação.

    ** Antes que me batam: O DP é o principal responsável pela entrega no sentido de que ele deve ser accountable (aah! palavrinha maldita). No popular: é o dele que estará na reta em caso de problemas com a entrega do projeto. Ok? Então guardem as facas, please!

  • O Problema com Harry*

    Harry era um coordenador de projetos. Vivia para resolver problemas. O último foi insolúvel: Harry bateu as botas; foi dessa para uma melhor; tá mortinho da silva. Ninguém percebeu ainda. Ele está em seu cubículo, silencioso como quase sempre. Debruçado sobre o teclado, parece dormir. A tela do micro exibe o gráfico Gantt que ele atualizava quando morreu.

    Jenifer apareceu para confirmar a reunião das 10. Notou que algo estava errado só na quarta vez que chamou Harry, tocando seu ombro. Pela temperatura do pescoço sacou que o cara estava realmente morto. Lembrou-se imediatamente da rodinha que se formou em torno da máquina de café logo após a reunião do dia anterior. Sentiu um frio na espinha quando recordou a jura que fez para meia dúzia de testemunhas: “Ainda mato esse $%&”. Deixou o cubículo se certificando de que ninguém havia reparado sua presença ali.

    Jenifer é analista de negócios. Os 5 meses e 18 dias de convívio com Harry foram, segundo suas próprias palavras, “um inferno”. Se arrependeu de ter sugerido a adoção de um modelo iterativo e incremental para o desenvolvimento do projeto. “Melhor seria ter ficado aqui apenas um mês, escrito do jeito que desse todos os casos de uso e me mandado para outro projeto”. Harry lhe roubou a ideia e fez um curso de 8 horas de ScrumMaster. Voltou com o certificado e algumas conclusões: “A ideia do Scrum é muito boa. Só não curti muito esse papo de ScrumMaster, Product Owner e coisa e tal. Vamos adotá-lo, mas eu seguirei sendo GP. E tenho dito!”

    Harry fazia questão de participar de todas as reuniões com o cliente. Jenifer funcionava mais como sua secretária do que como analista de negócios.

    TheTroubleWithHarry

    Arnie é um dos três programadores plenos (pero no mucho) alocados no projeto. Com espinhas no rosto e bonequinhos japoneses em sua mesa, vivia irritado com Harry. Reclamava do “clima opressivo” do projeto. Não suportava mais as 4 horas extras diárias e as manhãs de sábado trabalhando, coisa que Harry chamava de “esforcinho extra”. Algo que ele compensaria, dependendo do sucesso do projeto, “com uma bela feijoada no Bar Brahma. Por minha conta!”, prometia o falecido.

    Arnie nunca manifestava suas opiniões para o coordenador – tremia de medo dele. Aos pares sempre acusava as sugestões “malucas” e o risível domínio técnico de Harry: “O cara sabe de Java tanto quanto eu manjo de culinária peruana”. As piadinhas de Arnie nunca mereciam uma risada espontânea, mas todos os programadores concordavam com suas críticas.

    Passou pelo cubículo do Harry para perguntar, pela terceira vez, se a data de encerramento da iteração realmente mudaria. Todo mundo achava aquilo uma loucura e Harry nunca era conclusivo. A verdade é que nenhuma iteração até aquele momento havia respeitado o plano original (que previa ciclos de 30 dias). Arnie tremeu muito quando percebeu que seu silencioso interlocutor estava mortinho. Agachou e elaborou 100 planos para escafeder-se sem ser notado. Saiu engatinhando e entrou no cubículo ao lado, da gata Jenifer, simulando a busca pela lente de contato que ele nunca usou. Nem notou as cruzadas pernas torneadas de tão nervoso que estava.

    Eis que chega o Capitão, bufando. É o gerente da área comercial e já avisou que não toleraria mais reclamações do cliente. Esperava desde a noite anterior por uma versão atualizada do arquivo do ‘project’. O cliente falou que não pagaria mais nenhuma parcela se não visse uma “evolução” do projeto. Harry e Capitão acordaram que o envio do ‘project’ talvez funcionasse como calmante. Não sem antes discutirem, por 3 horas e 17 minutos, sobre os problemas do projeto. Harry dizia que o cliente não sabia o que queria. E reclamava que sua equipe era muito “júnior”. Capitão, entre um tapa e um murro na mesa, lembrava que nunca vira, em 30 anos de carreira, um projeto de software sem problemas. No ápice do papo, lá pelas 8 da noite, gritou para quem quisesse ouvir: “Se esse projeto não der lucro eu te mato, safado!”

    Boa parte da remuneração do Capitão vinha de um naco do lucro de cada projeto comercializado. Ou seja, há tempos ele vivia com a corda no pescoço, contas penduradas e um salário mínimo. A empresa resolveu que comissões ‘normais’ estavam apenas contribuindo para o aumento do prejuízo dos projetos. E concluiu que a participação nos lucros incentivaria maior colaboração da área comercial nos projetos, “gerenciando relacionamentos. Afinal, esses técnicos são muito ruins de papo”. Capitão bufou, acatou e enviou o currículo atualizado para 47 empresas.

    Capitão gritou uma, duas, três vezes. “Não é possível que agora esse @#$ resolveu dormir aqui!”. Com um safanão fez a cadeira girar, o que mostrou meia face do pobre coitado e morto Harry. O olho esbugalhado dizia tudo.

    Jenifer e Arnie aproveitaram o escândalo para dar e livrar suas caras: “Capitão, você matou o Harry?” A pergunta saiu em uníssono e em volume suficiente para ser ouvida em todo o andar. Logo estavam todos ali, pescoços sobre as divisórias do cubículo, rostos de espanto e comentários inteligentes sem champanhe nem cicuta. “Jura? O Capitão matou o Harry?”

    Ninguém gostava do Harry. “Mas matar o cara! Meldels… onde vamos parar?” As meninas choravam um choro nervoso. Os rapazes, com seus modernos celulares, espalhavam a nova para toda a agenda de contatos. Ninguém sabia o que fazer. Capitão estava estático, catatônico, com cara de bobo. Jenifer e Arnie ainda o fitavam, acusadores e aliviados.

    O ramal do Harry tocou. Identificador de chamadas: “Amorzinho”. Todos que estavam próximos trocaram olhares, esperando que um herói tomasse a iniciativa de atender ao chamado. Ninguém teve coragem e depois do 13º toque o telefone silenciou. Para tocar de novo 30 segundos depois. Identificador de chamadas: “Esse cara não tem mãe”.

    “Xi… agora é o freguês”, disse alguém.

    Capitão atendeu, mandando bala: “Ô Xerife, você sabe que mora eu meu coração, não?”. Silêncio constrangedor de dois minutos e meio. Todos sacaram que o Xerife, o cliente, desfilava seu repertório de impropérios nos acostumados ouvidos do Capitão. Do nada, o gerente comercial resolveu mudar o rumo da conversa: “Querido, por favor, me diz uma coisa: você mandou matar o Harry? Porque, veja bem, se foi você, eu gostaria que você soubesse que todos aqui consideraram a decisão mais acertada para que finalmente a gente possa estar providenciando a otimização de nosso processo orientado ao…” tum, tum, tum…

    Epílogo

    Foi no velório que todos ficaram sabendo que Harry não foi assassinado. Sofreu uma parada cardíaca fulminante. “Também”, disse Jenifer, “o cara se alimentava mal e não fazia exercício nenhum! Não aguentava um lance de escadas”. Arnie lembrou que havia dois meses que Harry parou de fumar: “Não adiantou nada.” “Pudera, o cara tava mascando 60 chicletes de nicotina por dia!”, assuntou outro. Capitão consolava o Amorzinho dizendo que Harry era o melhor coordenador de projetos que ele conheceu em 30 anos de carreira. “Pena que não suportou a pressão”.

    E Harry não conseguiu o que queria quando veio para a “Top Down**”, com o diabo ter. Ele queria era falar pro Presidente pra montar um PMO e ajudar toda essa gente que só faz sofrer…

    .:.

    * O drama acima foi levemente inspirado num dos melhores filmes pouco conhecidos do Mestre Hitchcock, “The Trouble with Harry” (1955), que aqui em Pindorama é tratado como “O Terceiro Tiro”. As imagens utilizadas neste artigo foram indevidamente surrupiadas da Internet.

    ** A “Top Down” é uma software house de última geração fincada no meio do potencial vale do silício tupiniquim, leia-se Vale do Anhangabaú. Sediará outros dramas, com certeza. Infelizmente, sem nosso querido Harry.

    Atualização em 3/Fev/10: As três batidas na madeira, dadas abaixo, não adiantaram muito. Eu deveria ter verificado anteriormente a coincidência com nomes, principalmente com a empresa. É preciso dizer que a Top Down do artigo acima, agora definitivamente fechada, não tem nada a ver com a empresa homônima sediada no Rio de Janeiro. Foi uma infeliz coincidência mesmo. E pelo meu descuido peço desculpas. Agora vou ter que inventar um novo nome para as futuras aventuras da trupe desenvolvedora.

    Lembrete: salvo engano, ontem foi o Dia dos Gerentes de Projetos. Eu não ia homenagear-nos (ainda me considero um) com um artigo sobre as “maravilhas” da última versão do PMBoK, né? Fica para uma data mais propícia (ou menos perigosa).

    Aviso: a história acima é pura ficção e bobagem. Qualquer semelhança com fatos, empresas ou pessoas de verdade deve ser mera coincidência. (3 batidas na madeira)

  • Fred Brooks no Brasil

    Minha caixa postal amanheceu repleta de mensagens de amigos avisando: Brooks estará no Brasil na próxima quarta-feira, 21/out! A preocupação dos colegas tem uma única explicação: eles sabem que sou fanzaço do cara. Não só de sua obra prima, “O Mítico Homem-Mês” (lançada originalmente em 1975 e finalmente disponibilizada em PT-br), mas também de seus artigos que seguiram, particularmente “No Silver Bullet” (1987. Este e outros artigos aparecem na edição do livro lançada pela Elsevier-Campus).

    Seguem os convites:

    Se você quiser entender um pouquinho mais a importância do cara, veja a série de artigos que publiquei aqui no finito em 2006. Se gostar, não deixe de comprar o livro. Se comprar o livro, lembre-se de uma provocação do Brooks:

    Eles falam que o livro é a Bíblia da Engenharia de Software… é por isso que todo mundo o lê mas ninguém o usa!

    A gente se vê num dos dois eventos acima. Inté!

  • Crise no Mundo Ágil. Que Crise?

    Sabe aquela sua colega que parece ser a única num raio de 500km que conhece e gosta de uma obscura banda de rock belga? Lembra-se como ela se revoltou e desgostou quando a banda assinou contrato com uma grande gravadora? É o mesmo caso daquele amigo que era fanzaço de um diretor de cinema chinês, mas desistiu da idolatria quando o cara resolveu fazer um filme em Hollywood: “O cara se vendeu”. Todos conhecemos gente assim, que gosta de coisas muito diferentes, distantes do universo pop(ular). Pessoas que se sentem traídas quando seus modelos ou ídolos tentam falar para um público maior, tentam atingir mais pessoas.

    Desconfio que algo muito parecido esteja acontecendo agora, naquele universo que surgiu após o big-bang do Manifesto Ágil. Dois excelentes artigos, de José Paulo Papo e Rodrigo Yoshima, ajudaram a alimentar minhas suspeitas. Além de um bate papo bem legal que rolou sobre a possível morte do RUP (Rational Unified Process) no grupo UML-BR.

    O Yoshima está certo: RUP e Agile compartilham hoje uma mesma tendência. Mas seria a de morrer? Márcio Tierno, o MT, fez um diagnóstico diferente ao falar especificamente sobre o estado atual do RUP:

    Acho que o RUP, pior do que estar morto, entrou para o mainstream. Hoje um cliente ou usa um processo waterfall ou usa um processo *pretensamente* baseado no RUP.

    E entrar para o mainstream significa ter sua evolução freada. Ninguém entendia direito o RUP. Poucos dos que o “adotaram” em suas empresas se deram ao trabalho de ler a última versão e entender. Os “metodologistas” das empresas sempre gostaram do RUP exclusivamente pelos artefatos, pela sensação de controle e pelo tamanho. Jamais pela iteratividade.

    Surrupiei do Google Trends alguns dados que de certa maneira confirmam as palavras do MT e solidificam minhas suspeitas. Veja os gráficos abaixo:

    Tendências para RUP, Agile e Scrum no mundo

    Tendências só no Brasil

    Azul = RUP | Vermelho = Agile | Laranja = Scrum

    O primeiro gráfico abrange o mundo todo. O segundo levou em consideração apenas as buscas e notícias realizadas no Brasil. O Google Trends faz exatamente isso: mostra a quantidade de buscas pelos termos. Não pode ser considerado ao pé da letra, afinal Scrum e Agile significam outras coisas para outras pessoas. O que não tira totalmente o valor do indicativo de tendências.

    E o que os gráficos nos mostram? Uma queda constante porém gradual no interesse pelo RUP e um crescimento vertiginoso nas buscas pelo termo “agile”, particularmente aqui no Brasil. Seria isso um indicativo de morte? Só para aqueles que, como os fãs de bandas e diretores obscuros, gostariam de permanecer num grupo pequeno e muito restrito.

    Eu entendo e compartilho o que acredito que sejam as principais preocupações do MT e do Yoshima. Ao se transformarem em artigos pop – ou “carne de vaca”, para usar um termo bem nosso – RUP e Agile saem do controle. Do nosso controle. E não serão poucos os que irão distorcer, desfigurar e desmontar os valores e princípios que caracterizam e definem essas propostas. Aliás, preciso confessar, eu sou um deles. Tanto que já fui criticado, aqui mesmo no finito, por chamar de “bullshitagenzinhas ágeis” algumas das práticas sugeridas. Falei de práticas, não de princípios e valores. Mas isso não importa. O que importa aqui é saber se é mesmo o caso de decretar a morte do RUP ou do Agile.

    Se o RUP é muito mal utilizado, e de fato é, boa parte da culpa é dos seus criadores e evangelistas. Já mostrei por aqui como o RUP foi uma verdadeira metamorfose ambulante desde o seu lançamento. Alteraram sem pudor seus princípios, causando confusão. O artigo do José Papo mostra que agora a versão 7.5 tem um “Agile Core”. Não estou dizendo que o RUP não deveria evoluir. Estou afirmando que a evolução foi mal conduzida (parece improviso) e muito mal comunicada. O que não isenta, claro, os cabeças de pamonha que fizeram dele uma cascata iluminada.

    O universo Agile pode e vai sofrer com problemas semelhantes. Cabeças de pamonha estão longe da extinção. Mas o caso aqui é diferente. Os valores e os princípios consolidados no Agile Manifesto permanecem os mesmos desde o dia 13 de fevereiro de 2001. E eles não sofrem com um dono nem com as pressões comerciais que este faria.

    Esqueçamos por alguns minutos os Pamonhas e suas cascatas e contratos a preço fechado. Cabe aqui uma autocrítica por todos aqueles que defendem o manifesto:

    • Será que estamos sendo didáticos o suficiente?
    • Não somos impacientes demais para explicar, por exemplo, por que uma iteração não é uma mini-cascata?
    • Será que, ao invés de explicar, não estamos detonando demais o “outro lado”. Vide meu termo acima: Pamonha!
    • Não estamos sendo religiosos e puristas demais?

    Meu maior temor é que os agilistas de hoje se comportem como os cascateiros de ontem. Não concordo com o MT quando ele diz que “mainstream significa evolução freada”. Oras, se no contexto de um projeto estimulamos (ou forçamos) a participação de todos, exatamente para gerar mais ideias e inovações, por que numa escala maior esta mesma prática seria nociva – por que ela geraria o efeito contrário?

    Se de fato nós acreditamos que RUP e Agile são as respostas para melhores projetos, não faz o menor sentido o medo de que essas propostas se transformem em suculentas “carnes de vaca”. Ou nós queremos seguir como os raros fãs de obras cult que ninguém conhece?

    .:.

    A foto utilizada neste artigo, “We Love Crisis”, é de Daquella Manera (Daniel Lobo), fotógrafo profissional que disponibiliza alguns de seus trabalhos como Domínio Público.

  • No Fundo do Poço

    Quando vivemos em tempos de abundância de crises, é natural que algumas delas passem totalmente desapercebidas. Ponto minúsculo e silencioso no radar não chama atenção. Mas ele será lembrado quando o estrago já estiver feito. Há uma crise na relação entre empresas e seus fornecedores de serviços de desenvolvimento e manutenção de sistemas. É fato, esse relacionamento nunca foi harmonioso. Mas parece que estamos chegando no fundo do poço – naquele momento em que, mais do que debatida, a relação deveria ser totalmente revista.

    Tentarei ilustrar a situação com uma breve história.

    .:.

    Era uma vez uma empresa de médio para grande porte repleta de sistemas. Como é tradicional, a parte “feijão com arroz” do negócio (processos de apoio – financeiro, contábil, RH…) foi informatizada com um pacote ERP; A parte “filé com fritas” (processos primários – vendas, atendimento…) é um combinado de módulos desenvolvidos internamente com algumas soluções de terceiros. Antenada por necessidade, a empresa em questão, que chamaremos de ACME, já usa mas pouco abusa de conceitos modernos como SOA, BPM e BI.

    Assim como acontece em praticamente todas as organizações ao redor do globo, a “Arquitetura Corporativa” da ACME assemelha-se ao retrato do inferno devidamente registrado por uma câmera de 12 megapixels. Consequência natural de anos e anos de projetos “para ontem”, adoção de caixinhas mágicas, fornecedores famintos e voluntariosos e algumas pitadas de modismos. A receita pode variar um pouquinho de empresa para empresa, mas o prato parece ser sempre o mesmo. E é indigesto.

    A demanda por manutenção (80%) e novas aplicações (20%) é sempre maior que a capacidade instalada. Fornecedores devidamente homologados adoram essa parte. Afinal, “fábricas de software” (sic) foram inventadas para isso mesmo, certo?

    Software é um elemento vital para a ACME. Aliás, deve ser para 80% das empresas. Mas ele ainda não é visto como ativo, como conhecimento. Software é contabilizado como despesa. E é tratado como tal: um mal necessário. Então a ACME brinca de fazer de conta que mantém o cérebro e terceiriza membros, mais precisamente os braços. Traduzindo: uma equipe interna definiria o que precisa ser feito; o “como” e respectiva construção seriam executados por “parceiros”. (Há palavra mais maldita que essa em nosso mundo?)

    Acontece que o cérebro é pequeno e fica cada vez menor. Para cada neurônio disponível para “coletar requisitos” (sic), existem dezenas ou centenas de usuários putos da vida, atrasados, indecisos e com hora marcada no psicólogo. Quando muito, uma reunião(zinha) de 1 hora é tudo o que o neurônio tem para entender o que o usuário quer. Desse entendimento nasce um briefing. E dele extrai-se um “cheiro” que, como num passe de mágica, vira compromisso de prazo e custo. Tudo acontece tão rápido que o neurônio nem tem tempo de suspirar.

    Com um olho na fila de usuários que aguardam sua vez de choramingar requisitos, o neurônio repassa para o parceiro selecionado por um critério qualquer aquele conjunto de parágrafos desconexos apresentados anteriormente como briefing. Sim, a escassez de neurônios é tamanha que cabe ao parceiro “fechar o escopo” (sic). Com um pouco de insistência e um tanto de sorte o parceiro consegue um ou dois encontros com usuários para desenvolver “casos de uso”. O papo é menos belicoso que aquele entre usuários e neurônios porque o parceiro é “de fora”. Mas, talvez para mitigar riscos de rusgas, o parceiro sempre manda um analista diferente. O rodízio deve seguir a lógica do namoro de jogador de futebol. Mas os usuários já se cansaram de dizer que “eu já expliquei isso antes…”

    Tão logo o parceiro se manifeste satisfeito com as informações coletadas (implicitamente ele tá de saco cheio daquelas idas e vindas), tem início um hiato de duração indeterminada (apesar do cronograma assinado).

    É marcado para um belo dia (e precisa ser belo mesmo – porque, se ameaçar chover, o parceiro nem tira o carro da garagem) a apresentação do projeto. Dependendo da cara (e do bolso) do sponsor, o evento tem lá suas regalias. Na maior parte das vezes, é só um encontro do parceiro com alguns usuários e um cafezinho. O neurônio autor do briefing é convidado a participar. Claro, se ele ainda estiver na folha de pagamentos da ACME.

    O encontro é tenso. Já começa nervoso. E os usuários não colaboram com o clima: “Nossa, atrasou tanto desta vez, né?”

    Num caso específico a apresentação começou por uma parte bem complicada do projeto: uma tela de cadastro de clientes. O usuário do departamento de marketing mal esperou a tela acabar de ser “renderizada” (sic) e já reclamou: “Nossa logomarca sofreu pequenas alterações há 6 meses. Adequação para a nova realidade Web 2.0 e patati patatá…”. Foi interrompido. O parceiro falou que ninguém avisou. “Mas é uma pequena alteração besta…”, disse, tentando encerrar o assunto. Afinal, o importante era o conteúdo! O cara do marketing não concordou, mas silenciou.

    Para testar o conceito de usabilidade o parceiro pediu que um outro usuário, sem nenhum treinamento, fizesse o cadastro de um cliente. Claro, ele escolheu a menininha mais bonitinha que estava na sala. E quase pegou em sua mão para guiar o mouse na direção do botão “Incluir”. “Por que esse botão tem a cor diferente dos outros?”, questionou a bela. Não mereceu resposta, mas seguiu em sua nobre tarefa.

    Até que, após digitar nome, CPF e logradouro do namorado (para infelicidade do parceiro), se deparou com uma combo box onde ela deveria selecionar a Unidade da Federação. Clicou na setinha e viu uma lista mais ou menos assim: SP, BA, MG, RJ, DF, RS, SC, AC, RR, PA, MS, AM…

    Não se sabe quem disparou primeiro, se o neurônio, a bela ou o cara de marketing. Talvez tenha sido um coro: “Caramba, por que a lista não está ordenada?”

    O parceiro engoliu seco e sacou da mochila importada um calhamaço manchado e cheio de dobras que apresentava na capa a logomarca da ACME (desatualizada) e o nome do projeto. Passou pelas (33) páginas do caso de uso em questão – de trás para frente e de frente para trás – e cravou: “Não tá escrito aqui que a lista deveria ser ordenada. Isso é mudança de escopo!”

    .:.

    A história acima é uma ficção baseada em fatos reais. Só as trechos mais exagerados são verdadeiros.

    A foto utilizada, “Lift Shaft Within the Old Town Hall Tower”, foi devidamente surrupiada de lostajy. Ela foi liberada com licença Creative Commons.

  • D.E.V.A.G.A.R.

    Como apresentei no post anterior, DEVAGAR é um acrônimo para um conjunto de princípios que deveriam nortear um processo de desenvolvimento ‘business-centric’. Confesso, não deixa de ser uma provocação. E um contra-ponto ao ABCDEF que, segundo seus autores, seria ‘business-centric’. Na minha opinião, mais que ‘business-centric’, aquele conjunto de princípios – que, aliás, é muito legal – é mais ‘agile-manifesto-centric’ ou, em outras palavras, ‘developer-centric’.

    Mas, mais do que criar polêmica (essa cansa), eu queria descrever com mais detalhes os 7 princípios que compõem o DEVAGAR:

    D)emonstrar Valor de maneira Iterativa
    Deveria ser, Iterativa & Incremental. Parece frescura, mas faz diferença. Iterare, no latim, significa repetir. Aqui indicamos que repetimos diversos passos (no processo de desenvolvimento), mas a cada repetição nós agregamos real valor. Numa leitura “ágil”, é o mesmo que dizer “entregamos software rodando” em cada ciclo (ou iteração). Não curto o radicalismo: nas primeiras iterações, ou exclusivamente na 1ª iteração, software rodando pode ser menos importante que uma boa compreensão do negócio. Da mesma forma que ele pode ser muito importante para a equalização de visão entre todos os stakeholders. Mais do que um processo, o que determina o Real Valor a ser entregue em uma iteração é o projeto. E cada projeto é único. Mensagem mais importante (para o negócio e seus usuários): se uma iteração se encerra e você não consegue perceber o Valor, algo errado aconteceu. E é verdade: software rodando tem muito mais valor que uma série de modelos UML ou afins.

    E)ntender (e Melhorar) o Negócio
    É difícil aceitar que um projeto seja tocado sem que boa parte da equipe tenha uma mínima compreensão sobre o negócio que está sendo automatizado. É difícil entender a razão para tal alienação ser tão comum em nossa área. Mas o princípio aqui vai além: além de uma boa compreensão do negócio e dos projetos afetados pelo projeto, um processo ‘business-centric’ incentiva a busca por melhorias.

    V)alorizar os Ativos de Software
    Está aqui um princípio que, salvo engano, não vi formalizado em nenhuma proposta de processo. Ele deveria ter dois efeitos:

    1. Garantir a qualidade do software que está sendo produzido. Se bem empacotada (documentada e difundida), a aplicação ganha sobrevida. Vale apelar para um velho chavão: ativos de software, ao contrário dos ativos físicos, ganham mais valor quanto mais são utilizados. Todo software (de negócio) deveria ser construído para durar… muito.
    2. Dar sobrevida aos ativos existentes (também conhecidos como sistemas legados). Trata-se de um dos principais alvos das iniciativas SOA. Mas, hoje em dia, serão raros os projetos que não estabeleçam um mínimo relacionamento com software existente. Combater a síndrome NIH (Not Invented Here) e dar valor para aplicações (conhecimentos!) existentes é uma boa prática.

    A)daptar o Processo
    Taí um princípio que, se adotado pela (IBM) Rational desde o início (do RUP), teria evitado uma série de problemas. Se todo projeto é único, como acreditar em um único processo? Toda organização possui e vive seus valores e costumes. Algumas sobrevivem a eles (hehe.. brincadeirinha). Essa base, mais um conjunto de princípios (ou boas práticas, como as descritas aqui), dá forma à um meta-processo. Um framework que seria posteriormente adaptado para cada tipo de projeto e também para cada projeto.

    No nível mais baixo (um projeto), quatro variáveis principais afetam a configuração de um processo: O Negócio (sua estratégia, processos, departamentos e pessoas afetados); o Tipo de Aplicação (Transacional, Analítica ou Utilitária); a Tecnologia e o perfil da Equipe. Claro, várias outras questões (regulatórias, SOX, Bacen, Basiléia… por exemplo) também podem gerar considerável impacto no desenho dos processos de desenvolvimento e gerenciamento do projeto.

    G)erenciar Requisitos (e Mudanças)
    Vira e mexe, há tempos, o dado pipoca por aí: requisitos (e mudanças) estão de alguma forma relacionados com 80% dos problemas dos projetos que fracassam. Como eles (os projetos fracassados) não são poucos, é inaceitável que este princípio não conste de um processo para desenvolvimento de software. Pode parecer chatice (de certa forma o é), mas “balancear prioridades dos stakeholders” não é o termo adequado. Parece até “forçada de barra” para arrumar uma letra B (e assim compor o perfeito ABCDEF). E por falar nisso, gerenciar requisitos não significa lotar paredes com post-its coloridos.

    A)tacar os Riscos
    Assim como os requisitos, o mau gerenciamento de riscos também está entre as principais causas das falhas em projetos de software. Como Grady Booch já falava em 96 , “se você não atacar os riscos, eles o atacarão”. O verbo é este mesmo: Atacar (a redação de um princípio deve ser clara e direta). E é equivacada a impressão de que riscos são questões exclusivas de arquitetura. Um bom entendimento do negócio (princípio #2 acima), significa também a descoberta de riscos e até uma possível antecipação de mudanças. Aliás, os riscos de negócio são mais perigosos que os riscos de arquitetura (por mais que algumas péssimas aplicações tentem nos provar o contrário).

    R)espeitar os Usuários
    É chato que algo assim tenha que aparecer numa lista de princípios. Mas, infelizmente, se fez necessário. É bom que seja o item de fechamento da lista. Força a revisão de muitos fatores que podem ter ficado implícitos. Por exemplo: vamos ouvir e gerenciar todas as expectativas dos usuários. Mas não fugiremos da responsabilidade de sugerir melhorias, ou de alertá-los sobre riscos em potencial. Respeitaremos a inteligência e o tempo dos usuários estudando seu negócio, falando sua língua. E, mais importante, nos comprometendo com seus objetivos de negócio.

    Por tudo isso eu gostei do DEVAGAR. “DEVAGAR & SEMPRE”, como naquela fábula da tartaruga. Taí, já arrumei até mascote para o ‘business-centric’…

    .:.

    Notas:

    1. Os princípios desenham o perfil de um processo. Quanto mais genéricos forem, mais maleável é o processo. Por isso é preciso ter muito cuidado com processos que se apresentam como de uso geral, mas apresentam princípios que, de certa forma, são ‘intrusivos’. Reparem: trata-se de uma crítica que se aplica à listinha DEVAGAR acima. Com certeza ela não atenderá qualquer tipo de negócio. O que dizer então de projetos?
      O mais importante é ter um bom ponto de partida. E ninguém pode ensiná-lo melhor do que seu próprio negócio.
    2. Object Solutions – Managing the Object-Oriented Project
      Grady Booch. Addison-Wesley (1996).

    .:.

  • Business-Centric

    Quem participa do ótimo grupo UML-BR (Yahoo!Groups) deve ter visto uma discussão em torno da liberação da versão 1.0 do OpenUP. Em determinado momento, ainda lá nas primeiras mensagens, o debate virou “Architecture Centric X Business Centric”. Enquanto o RUP estaria mais para o primeiro, o OpenUP seria uma representação do segundo. Não é uma definição amplamente aceita. O RUP vem alterando seus princípios desde sua criação. Tanto que no verbete RUP da Wikipedia ele também é apresentado como “business centric”.

    Para entender: quando lançado, eram apresentados como princípios (ou grupos de melhores práticas) do RUP :

    1. Desenvolver software de maneira iterativa
    2. Gerenciar Requisitos
    3. Utilizar arquiteturas baseadas em componentes
    4. Modelar o software
    5. Verificar continuamente a qualidade dos artefatos gerados
    6. Controlar mudanças

    Com o tempo os princípios foram mudando. Em determinado momento, o “espírito do RUP” consistia em :

    1. Atacar os grandes riscos o quanto antes, continuamente
    2. Entregar valor para o cliente
    3. Direcionar seus esforços para gerar software executável
    4. Assimilar mudanças o quanto antes no projeto
    5. Definir uma arquitetura o quanto antes
    6. Construir o sistema com componentes
    7. Trabalhar como uma equipe
    8. Fazer da qualidade um modo de vida

    A pressão do “Agile Manifesto” e por um processo menos “pesado” continuou, o que nos trouxe para o mais novo conjunto de princípios que, segundo Per Kroll e Bruce MacIsaac , norteiam tanto o RUP quanto o OpenUP. São eles:

    • A)daptar o Processo;
    • B)alancear Prioridades dos stakeholders;
    • C)olaboração entre os times;
    • D)emonstrar valor de maneira iterativa;
    • E)levar o nível de abstração; e
    • F)ocalizar continuamente a qualidade.

    Este último conjunto seria, segundo seus criadores, “Business-Centric”, enquanto os dois anteriores, particularmente o primeiro, seria nitidamente “Architecture-Centric”. No grupo de discussão, respondendo ao Marcio Tierno e Rodrigo Yoshima, eu falei que não concordava com o rótulo “Business-Centric”. É um rótulo adotado pelos próprios criadores da lista de princípios. Se fosse um rótulo colocado por gente de fora, um consenso, tudo bem. Mas ao batizar suas idéias e sugestões de práticas de “business-centric”, os autores, imho, pesaram a mão. Eu disse que a lista parece mais “Agile-Manifesto-Centric”, enquanto o Tierno sugeriu “User-Centric”. Mas a crítica não basta.

    Desde então ando pensando em quais seriam os princípios de um processo “Business-Centric” de verdade. Meus 7 cents:

    • D)emonstrar valor de maneira iterativa
    • E)ntender (e Melhorar) o negócio
    • V)alorizar ativos de software
    • A)daptar o processo
    • G)erenciar requisitos (e mudanças)
    • A)tacar os riscos
    • R)espeitar os usuários

    Ops… D.E.V.A.G.A.R…. não deve pegar muito bem. Talvez com sobrenome: “Devagar e Sempre!” hehe..

    Mas, apesar do nome, gostei da idéia. No próximo post falo um pouco mais sobre cada princípio.

    .:.

    Bibliografia:

    1. The Rational Unified Process – An Introduction
      Phillipe Kruchten. Addison-Wesley (2000 – 2ª Edição).
    2. The Rational Unified Process Made Easy
      Phillipe Kruchten e Per Kroll. Addison-Wesley (2003).
    3. Agility and Discipline Made Easy – Practices from OpenUP and RUP
      Per Kroll e Bruce MacIsaac. Addison-Wesley (2006).
    .:.