PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Engenharia de Software

  • Scrum ‘de Raiz’

    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.

     

  • Análise de Negócios – 4 Anos Depois

    Análise de Negócios – 4 Anos Depois

    Há quatro anos iniciava meu mergulho na Análise de Negócios, estudando o mercado e desenvolvendo o programa de treinamento que seria lançado em junho/07. Muita coisa parece diferente agora, particularmente a difusão da disciplina. Infelizmente, muita coisa parece inalterada ou ter mudado para pior. Neste artigo pretendo discutir alguns problemas que impedem o uso pleno e eficaz da Análise de Negócios pelas organizações.

    ?

    Naquela época algumas pessoas diziam que o bafafá sobre Análise de Negócios não passava de uma moda. Sempre admiti que a disciplina vivia seu momento, algo semelhante ao que havia acontecido com o Gerenciamento de Projetos a partir da segunda metade da década de 1990. E completava: “antes tarde do que nunca”. Porque já tinha muito tempo que diversas fontes, ao analisar as razões de tantos fracassos em projetos de TI, apontavam o mau entendimento de um problema e questões de comunicação entre times técnicos e de negócio como algumas das principais causas de tanto insucesso.

    Surrupiei e uso desde então uma colocação que Fred Brooks fez em seu artigo “No Silver Bullet” (publicado originalmente em 1987 e disponível como capítulo adicional do livro “O Mítico Homem-Mês“, Campus – 2009):

    “A precisa definição sobre o que precisa ser feito é a parte mais difícil da construção de um software. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.“

    A Análise de Negócios, por definição, ataca exclusivamente¹ a “parte mais difícil da construção de um software”. Por isso eu dizia e repito: “antes tarde do que nunca”. Que a disciplina tenha vindo para ficar. Ou, melhor dizendo, que a “moda” (assim, entre aspas) tenha vindo para ficar. Porque a disciplina está conosco há um tempão.

    O problema é que sua presença não era percebida como sendo uma disciplina, um único corpo de conhecimentos. No RUP, por exemplo, surgia em dois lugares: Modelagem de Negócios e Requisitos. Em outras propostas e métodos dava sua cara sob o disfarce de “<verbo> Requisitos” (Levantamento (sic) de Requisitos, Coleta (10x sic) de Requisitos, Gerenciamento de Requisitos  etc). Esta ligação direta, Análise de Negócios -> Requisitos, é tão comum e pouco questionada que contamina não só a forma como muitas empresas interpretam e usam a disciplina, marca também os mais graves enganos do BABoK.

    Por incrível que possa parecer, muitas empresas (algumas bem grandinhas) entendem que o analista de negócios é aquele cara que senta na frente de um usuário e anota tudo o que ele pedir. Não são analistas de negócios, são “tiradores de pedidos”. É fácil identificar empresas com tal grau de miopia: basta pegar a média de idade e de tempo de casa de seus analistas. Em outras (poucas) organizações tive a surpresa e felicidade de encontrar analistas com mais de 20 anos de casa². É nítida a mensagem que elas passam: “essas pessoas conhecem como pouquíssimas a organização, por isso elas têm melhores condições de analisar nosso negócio”.

    A atenção exclusiva ao incêndio nosso de cada dia – às operações insanas tocadas por times pequenos tentando segurar diversos sistemas bichados – anula qualquer benefício que a Análise de Negócios pode trazer.

    Como em toda “moda”, há aqueles que compram sem saber o que estão comprando. Nem sabem se precisam daquilo. “Como o vizinho da grama mais verde está usando analistas de negócios, então eu também quero”. Não são poucos os profissionais que me procuram reclamando que foram contratados como AN’s mas que só fazem o trabalho de analistas de sistemas ou de suporte. Na realidade, como já chorei por aqui, a atenção exclusiva ao “incêndio nosso de cada dia” – às operações insanas tocadas por times pequenos tentando segurar diversos sistemas bichados – anula qualquer benefício que a Análise de Negócios poderia trazer. Cheguei a pensar no seguinte título: “Parem de Contratar Analistas de Negócios!“. Mas acho que soaria alarmista demais… e incompleto. Quem dera o problema fosse “só” esse.

    A alta rotatividade de profissionais – tema que tenho debatido no GRAFFiTi (1,2) – é particularmente nociva quando atinge analistas de negócios. Sei de empresas que perderam mais da metade de seu time de AN’s em menos de dois anos. Desenvolver as habilidades técnicas de um AN é relativamente rápido e barato. O mesmo não pode ser dito sobre o Conhecimento do Negócio. Dependendo das experiências anteriores do analista – se já atuou naquele ramo de atividades, por exemplo – pode ser demorada e custosa a aquisição deste conhecimento. É difícil justificar a adoção de uma política de retenção específica para AN’s. Mas as empresas precisam entender que cada AN perdido (ou demitido) pode ser um desperdício que não se recupera em 12 meses.

    O que mais me angustia é a sensação de que boa parte dos participantes de meus treinamentos não poderá utilizar ou praticar muito do que aprendeu (ou que eu espero que ele tenha aprendido). Por quê? Porque a Análise de Negócios é apenas uma peça do complexo quebra-cabeças chamado “Desenvolvimento de Sistemas”. Como desenvolver requisitos de maneira iterativa e incremental se a empresa ainda está casada (através de muito papel passado) com o modelo Waterfall? Por isso algumas de minhas sugestões sempre são recebidas da mesma maneira: “meu ‘chefe’ (sic) deveria estar aqui ouvindo isso”. AN’s trabalhando em duplas? AN’s dedicados a apenas um ou no máximo dois projetos? Esquece…

    As empresas vivem aturdidas e um tanto perdidas. Significa dizer que seus objetivos nem sempre ou quase nunca são conhecidos (ou entendidos). Jogue na mesma cumbuca departamentos de TI que, de tanto não entregar, desaprenderam a dizer “não” ou perderam o direito de dizê-lo. Pronto: está criado o ambiente maluco de gente que acredita (na marra) que é possível atender e entregar 20 ou 10 projetos simultâneos.

    Mais triste é saber que a Boa Análise de Negócios, se bem aplicada, ajudaria a reduzir essa sensação de não saber o que fazer. Ajudaria tanto a área de TI quanto a organização como um todo. Acontece que são raríssimas as organizações que percebem a disciplina desta forma. As outras, mesmo que percebessem, agora veriam uma área repleta de “tiradores de pedidos” com rostos assustados.

    ?

    Não queria abrir a temporada de artigos em tom tão pessimista. Mas eu entendo que é minha obrigação publicar esse tipo de alerta. Espero já ter esgotado as principais notícias ruins acima. Porque sei que também é minha obrigação tentar dar algumas dicas que ajudem as organizações a combater o mau uso da Análise de Negócios. Ou, colocando de forma mais positiva, tentarei mostrar como é o bom uso da Análise de Negócios. Inté!

    Observações:

    1. Antes que atirem pedras: eu escrevi acima que a “análise de negócios, por definição, ataca exclusivamente ‘a parte mais difícil da construção de um software’”. Claro que estou falando da Análise de Negócios aplicada *exclusivamente* em projetos de software.
    2. Por favor, entenda que não estou defendendo que todo AN deve ter 10 ou 20 anos “de casa”. Apenas ilustrei um caso extremo e bastante específico. Por outro lado reforço sim que uma empresa que leve a sério a Análise de Negócios deve ter um bom número de analistas com considerável experiência naquela organização ou mercado. O que chamo de “considerável experiência”? No próximo artigo a gente conversa sobre isso.
    3. A imagem utilizada, “4“, foi liberada por rosmary com licença Creative Commons (by).

  • Museu de Grandes Novidades

    Finalmente encerro a série de artigos onde tentei transcrever a palestra “O Futuro Não é Mais como Era Antigamente“. Este trabalho foi desenvolvido para o Seminário Engenharia de Software promovido pela Tempo Real Eventos. Para minha surpresa ele foi encomendado por algumas empresas, o que resultará em sua promoção para o status de Produto. Não do finito, mas de seu co-irmão que está brotando das cinzas com renovados propósitos. Assunto para outra hora.

    Hoje quero falar sobre o terceiro e último módulo daquela palestra, sobre o nosso “Museu de Grandes Novidades”. O primeiro módulo falava de pessoas e times e foi registrado aqui nos artigos “O Clube da Esquina Globalizada” e “O Cubículo Global“. O segundo tratou de tecnologias e arquitetura corporativa, tema que mereceu duas entradas: “(Pensando Alto sobre) Arquitetura Corporativa” e “Arquitetura do Negócio“. O prato quente é servido no final e o tal “Museu” foi a figura selecionada para puxar assunto sobre processos (metodologias) e projetos. Sim, eu esperava reações ruins entre as boas e indiferentes: “No size fits all!” Aliás, quem abre o tema com o slide abaixo não pode esperar coisa muito diferente, né?

    O “outras relíquias” do título indica a existência de um slide anterior. Verdadeira jóia: a certidão de nascimento do modelo ‘Cascata’. Mas, peraí: queria eu requentar debate tão chato e batido? Não era a intenção. E tento aplacar ânimos dizendo se tratar de um ‘Museu’, não de uma lixeira. Guardamos em um museu coisas que merecem ser vistas, lembradas e estudadas. Mostramos em um museu peças que têm valor. Preciso reforçar a questão que repeti várias vezes na palestra e que rotulei como ‘retórica’ (só pra tentar provar o contrário): nossas teorias (sobre engenharia de software) resistem ao confronto com as pessoas e tecnologias de hoje? Quantas ou quais sobreviveriam de fato? Minha cara e meu caro, se eu tivesse a resposta não estaria aqui, gastando o seu e o meu tempo.

    Também não se trata da elucubração isolada de um mineiro de Varginha que desfila lorotas nas horas vagas. O SEMAT (Software Engineering Method and Theory), que tem entre seus signatários algumas das pessoas que mais contribuíram com a área em todos os tempos, afirma com todas as letras em sua “chamada para a ação” que aquilo que conhecemos (conhecemos?) sobre engenharia de software encontra-se num perigoso e escuro mato sem cachorro porque:

    • Está repleta de modas e tendências, coisa que não combina com *engenharia*;
    • Está carente de uma base teórica forte e amplamente aceita;
    • Está abarrotada de métodos e variações com diferenças pouco compreendidas e artificialmente aumentadas;
    • Está pobre-pobre-pobre-de-marré-marré-marré em termos de avaliações e validações. Cada um fala que seu “método” funciona e pronto; e
    • Há uma divisão entre práticas da indústria e pesquisas da academia.

    Não consigo pensar em nenhuma outra área do conhecimento humano que tenha passado por algo semelhante. Repare bem: um grupo de pessoas que escreveu os livros e nos ensinou engenharia de software nos últimos 40 anos concordou com um diagnóstico nada favorável do nosso estágio atual. Repare também que entre os signatários existem representantes de todas as “escolas” relevantes, da extrema-direita até a extrema-esquerda. Hã.. ok. Alguns caras da extrema-esquerda que inicialmente concordaram com o diagnóstico tiraram o time de campo quando viram que o papo centro-direitista não os agradaria nem um pouco. Não importa. E também não creio que o SEMAT, pelo andar da carruagem, gere algum resultado. Mas o estrago está ou deveria estar feito. Ou alguém não concorda com o diagnóstico apresentado?

    .:.

    Definitivamente, minha intenção não é promover o bilionésimo papo besta sobre “cascateiros X agilistas”. Acontece que, tanto no evento aberto quanto em um fechado, teve gente que se sentiu pessoalmente atacada pelo conteúdo e, desconfio, pelo tom utilizado.

    Uma pessoa que participou da edição fechada desta palestra no último dia 9/11 manifestou enorme descontentamento com o evento. Detalhe: ela registrou sua insatisfação na forma de um comentário no último artigo publicado. Outros detalhes: utilizando nome falso, insinuando uma insatisfação geral e, indevidamente, registrando um link para o site da empresa contratante. Empresa que solicitou a remoção do comentário ou, no mínimo, do link que a identificava. Nunca cogitei a censura ao comentário (blog que é blog não modera nem censura). Mas, claro, retirei a referência para a empresa. Pela atenção, pelo time e pela rapidez na resposta, a empresa não merecia ver seu nome associado a comportamento tão feio e desonesto.

    Já fui atacado de quase tudo quanto é jeito pelas ideias que defendo e pelo que critico. Na grande maioria das vezes o ataque ou resposta, mesmo os mais agressivos, não é covarde. Não é anônimo. É o mínimo que se espera, certo?

    .:.

    Já escrevi por aqui que esta palestra é uma coletânea de temas que, por vários motivos, repousavam em minha gaveta. Pra ser sincero, não acreditava na viabilidade dos temas (em termos econômicos e políticos, hehe). Estouro champanhe quando erro assim. Além da apresentação para quase 100 profissionais de uma mesma empresa, ontem tive a chance de levar o mesmo papo para um território que parecia ser, no mínimo, inusitado. Ganhei um belíssimo presente da Profa. Renate Landshoff: a oportunidade de apresentar “O Futuro não é mais…”  para duas turmas do curso de graduação em Biblioteconomia da FESPSP (Fundação Escola de Sociologia e Política de São Paulo). Além da bela e antenada turma, contei com a enriquecedora presença de Sérgio Storch. Não vou tentar explicar agora o exótico mashup que se desenha. Mas algumas pistas você encontrará neste artigo da Profa. Renate (e respectivos comentários).

    “Beans“, a foto utilizada neste artigo, é de autoria de Naomi Ibuki e foi obtida no Flickr.

  • Scrum kanbanbanban balangandã

    Conclusão do papo iniciado em “Scrum praticundum burungundum“¹. Naquela primeira parte tentei ilustrar a crescente adoção do Scrum em Pindorama. O texto de hoje se ocupará dos principais problemas enfrentados, possíveis causas e soluções. É necessário lembrar que minhas conclusões não estão baseadas em uma pesquisa estruturada. Elas são fruto de conversas e consultas informais.

    .:.

    O Scrum, pequeno e simples que é, não deveria ter significados diferentes para as pessoas. Quando alguém me diz que está adotando o Scrum, minha primeira pergunta é: “Scrum e?…” Muitos interlocutores não entendem a questão. Ignoram o fato de o Scrum orientar apenas o processo de gestão de um projeto. Uma parte deles está de fato adotando derivações ou até mesmo o XisPê (eXtreme Programming). Outra parte descobre depois de um tempinho que “tá faltando um monte de definição”. Alguns deixam que a equipe técnica selecione suas práticas favoritas ou que trabalhem como os Allman Brothers, em puros e longuíssimos improvisos. Nada disso se configura um problema se combinado previamente. No entanto, no mínimo para não falar besteiras, é bom saber o que vem do Scrum e o que foi importado de outros lugares.

    Um dos exemplos de “práticas importadas” são as User Stories (ou histórias de usuários). O Scrum não diz como deve ser explicitado o backlog do produto nem como devem ser redigidas as necessidades dos usuários. Autores como Jim Highsmith, Mike Cohn e Roman Pichler² manifestam sua preferência pelo padrão User Story. Sua natureza evolutiva “combina” melhor com o Scrum e com métodos ágeis em geral. Acontece que muitos acreditam que esta seria a única maneira de registrar os requisitos do negócio ou dos usuários, o que não é verdadeiro.

    Mas o que realmente importa é a necessidade de *completar* o Scrum com práticas de engenharia. E aqui deveríamos ver variações mil. Por quê? Oras, organizações, equipes e projetos têm necessidades e restrições bastante específicas. O chapéu Scrum, largo e leve que é, pode caber em qualquer cabeça. Mas seu complemento demanda cuidado. Um zelo que tem faltado em algumas implementações.

    E por falar em implementação. Qual a melhor estratégia? Implantar o Scrum em toda a organização em uma tacada só ou, como um bom e legítimo mineiro, promover uma adoção gradual (comendo quieto e pelas beiradas)? Sou mineiro. E quanto mais conservador ou desestruturado for o ambiente, mais lento é o ritmo que recomendo. Aposto nos hábitos e gostos que são desenvolvidos de maneira natural e orgânica, sem imposições. Deveríamos acreditar mais no potencial das boas ideias que são incorporadas – aprendidas de verdade – através de bons exemplos. Mesmo em organizações que precisam ou merecem radicais safanões, é complicada a implantação do tipo big-bang. Só o exorcismo do espírito Waterfall (cascata), que assombra por anos ou décadas, já é um trabalho e tanto. Representa uma mudança que raríssimas vezes pode ser classificada como simples ou sem traumas. Resumindo: é mais fácil adotar o Scrum de maneira gradual. Poucos casos, como o da Salesforce.com documentado por Mike Cohn em “Succeeding with Agile” (Addison-Wesley, 2010), justificam outra estratégia.

    E por falar em cascata. Não é que tem gente que fala que tá usando o Scrum mas manda um analista lá no cliente para “levantar *todos* os requisitos”? Gente que depois compila isso tudo numa proposta com escopo, preço e prazo fechados? Isso sim pode ser julgado como pecado mortal – um crime premeditado. Mas, guarda o fósforo menino! Não é questão de jogar hereges na fogueira. Uma das perguntas mais frequentes que ouço é exatamente sobre isso: como um prestador de serviços vende um projeto baseado no Scrum? O assunto é tão espinhoso e controverso que merecerá um artigo (ou série) só para ele.

    Outro ponto que facilmente se converte em discussão é o autogerenciamento pelo time do projeto. Existem duas interpretações principais: i) o time cuida de tudo e decide tudo; ii) “autogerenciamento não significa falta de liderança mas um estilo diferente de liderança”, escreveu Jim Highsmith na segunda edição de “Agile Project Management“ (Addison-Wesley, 2010). Sou ignorante pra burro (hehe) e conheço pouquíssimos casos da história da humanidade que comprovem a viabilidade da primeira opção. Pra citar assim, de cabeça, só o caso da Democracia Corinthiana, que durou cerca de dois anos (1982-83). Ainda assim, garanto que a leitura da última frase lhe trouxe lembranças do Dr. Sócrates, Casagrande e Vladimir.

    Henrik Kniberg e Mattias Skarin colocam em “Scrum e Kanban – Obtendo o Melhor de Ambos” (InfoQ, 2009) que “o Scrum é suficientemente minimalista tal como é, se você remover coisas e continuar chamando isso de Scrum a palavra ficará sem sentido e confusa”. Porém, nada nos impede de “colocar coisas” no Scrum. Parece ser o que fez Jim Highsmith no livro  já citado. Ele coloca a figura de um líder de projetos. Estranhamente, sem usar o termo Scrum. Sei lá se por respeito ou qualquer outro motivo. Também precisamos considerar um aspecto cultural: o brasileiro parece gostar de líderes e de ser liderado. Não é o caso de discutir se isso se dá por preguiça, submissão ou letargia (que é a preguiça chique). Ou é (o caso de discutir isso)? Sei lá.

    Outra pergunta de meu informal check-list: “Você confia em seu PO? Ele tem a palavra final sobre o escopo do projeto?” Espanta o número de vezes que ouço um “não” como resposta. Um “não” que algumas vezes nem tem noção do tamanho de engano que representa. Se há um termo muito feliz³ criado no Scrum é Product Owner (PO) – *Dono do Produto*. “Dono” dispensa explicações. Quando um dono não tem palavra final então ele não é dono de nada. Não existe meio dono.

    Existe um dito popular que ensina que é “o olho do dono que engorda o boi”. Adaptado para nosso caso, podemos dizer que é “o olho do PO que garante a entrega do produto”. E o que dizer dos PO’s indisponíveis, daqueles que não têm tempo para olhar o boi?

    E que dizer dos PO’s que não são do negócio? O que dizer dos PO’s?

    Outro dia eu digo. Inté!

    .:.

    Observações:

    1. Sigo firme na tradição dos títulos ridículos. Mas desta vez escondi ali uma provocação. Se surtiu efeito eu não vi. Chamei o artigo anterior de “Scrum praticundum burugundum”. A rima (!) só é possível se a pronúncia estiver errada. É  que eu ouço “ScrUm” com mais frequência que  “ScrÃm” (ou “Scrammm”). Fecho a provocação (mas não a tradição dos títulos ridículos) com o “Scrum kanbanbanban balangandã” de hoje.
      E não, (ainda) não tenho a intenção ou condição de falar sobre o Kanban. Dele só aproveitei a rima mesmo. Se o tema lhe interessa, aquele livro aberto e gratuito citado é uma boa dica.
    2. No próprio texto já referenciei os trabalhos de Highsmith e Cohn. Faltou citar o livro do Roman Pichler, “Agile Product Management with Scrum” (Addison-Wesley, 2010). Um dos poucos dirigidos especificamente para PO’s.
    3. Não sei se você sabe, mas os termos criados para o Scrum são intencionalmente “infelizes” ou “ruins”. Ruins no sentido de serem bastante diferentes daqueles utilizados tradicionalmente: Product Backlog, ScrumMaster, Product Owner, Sprint Backlog… A sacada do vocabulário original e radical é boa porque evita confusões. Bom, deveria evitá-las…
    4. “Battle against Time”, a bela foto que ilustra o artigo, é do Joakim Jardenberg.

  • Scrum praticundum burungundum

    A crescente adoção do Scrum por empresas tupiniquins chega a ser surpreendente. Seu uso por pequenas e médias empresas da indústria digital é facilmente justificável. Mas quando vemos grandes negócios – de áreas não relacionadas diretamente com TI – adotando aquele framework ágil para gerenciamento de projetos, devemos entender que algo importante está acontecendo.

    Este artigo é o primeiro de uma pequena série que tem a intenção de ilustrar um pouco o estágio atual de uso do Scrum no Brasil. Nesta primeira parte, um breve panorama – uma fotografia com 2km de extensão por 2cm de profundidade. Na sequência escreverei sobre os probleminhas que tem sido reportados com mais frequência em relação ao uso do Scrum. Questões relativamente pequenas, mas com potencial para batizar o mais novo integrante da família das boas ideias que fracassaram.

    .:.

    O Scrum, na forma como o conhecemos hoje, está quase completando 20 anos de existência. Partiu de ideias e experiências da dupla Takeuchi e Nonaka¹. Mas adquiriu corpo e alma nos trabalhos e escritos pioneiros de Ken Schwaber e Jeff Sutherland². Ganhou trilha e impulso para o mainstream com a publicação do Manifesto Ágil. Dentre as diversas propostas de métodos e processos ágeis, o Scrum se destaca por ser o único que se preocupa exclusivamente com os aspectos gerenciais de um projeto. Por não incorporar nenhuma prática de engenharia, o Scrum possibilita sua combinação com diversas outras propostas, do RUP (Rational Unified Process) ao XisPê (eXtreme Programming), passando pela galáxia que existe entre eles.

    O que vou colocar no próximo parágrafo não tem a força de uma pesquisa estruturada. Por outro lado, a população amostral é suficientemente grande (2000+) para garantir que eu não esteja viajando ou forçando a barra.

    Nas primeiras turmas do FAN, no já longínquo 2007, apenas 5% dos participantes, em média, levantavam a mão quando eu perguntava: “Quem *conhece* o Scrum?” Na última edição do evento em São Paulo, no final de setembro, mais de metade da sala respondeu positivamente. E esta é a média de todas as turmas que encontrei neste ano, em São Paulo, Belo Horizonte e outras praças. Claro que não posso concluir que a adoção do Scrum no Brasil aumentou 1000% em três anos. Mas, pensando bem, desconfio que foi algo com tal magnitude que aconteceu. Aliás, está acontecendo.

    Testemunhei algo parecido, em menor escala, entre os idos de 1998 e 2000 e pedrinha. A moda e elixir para todos os males dos projetos de software de então era o RUP. Foi adotado por grandes empresas, como Petrobras e BankBoston, e estava nas bocas e agendas de todo mundo minimamente antenado com a área. Algum tempo depois, em empresas diferentes e distantes, vi reações parecidas: “Não fala de RUP que me dá urticárias!” Não vale o espaço e muito menos o seu tempo o diagnóstico sobre o que aconteceu com aquele incomensurável corpo de boas ideias (pobres estratégias e falsos evangelistas).
    {Mas merece nosso tempo a preocupação de que algo semelhante aconteça com o Scrum. Neste artigo, publicado em setembro/2009, eu falo um pouco sobre isso.}

    Antes, porém, vale a pena ilustrar um pouco mais a crescente adoção do leve processo de gestão que sugere a divisão das partes interessadas entre “porcos” e “galinhas”. Como já coloquei, não é difícil justificar o uso do Scrum por pequenas e médias empresas prestadoras de serviços de TI. Elas não puderam saborear adequadamente o RUP porque ele era um produto (leia-se: seu uso significava, na maioria das vezes, um pesado investimento em ferramentas que ‘viabilizariam’ o uso do método). Agora, elas ganharam um método que não cobra royalties nem força o uso de (dispendiosas) ferramentas. E, talvez um ponto mais importante: elas ganharam um método cuja implantação é relativamente fácil, rápida e barata. Ou seja, um sonho.

    Surpreendente é o fato de algumas grandes empresas também apostarem no Scrum. Inclusive empresas de ramos que têm a péssima fama de serem conservadoras e burocráticas – pelo menos no que se refere a TI – como bancos e seguradoras. Entre tudo o que é sinalizado em movimentações deste tipo, parece nítida uma grande insatisfação com processos, padrões e metodologias utilizados até então.

    No primeiro semestre apresentei duas palestras para um dos maiores bancos do Brasil. Fui convidado para “provocar” e apresentar “tendências”. A segunda palestra foi motivada pelo “burburinho” gerado na primeira. E foi dirigida para gerentes e afins. Ao justificar o encontro, um dos principais executivos da área disse: “Precisamos de novas ideias”. Em outro momento, nas entrelinhas de uma nova intervenção do mesmo executivo, havia uma mensagem bem direta: “Não dá pra continuar trabalhando da forma como fazemos hoje”.

    Há tempos, esta e diversas outras empresas acreditam que os problemas de comunicação entre áreas de negócios e TI podem ser combatidos com mais documentos, assinaturas, change requests e coisas do tipo. Ao final do evento aquele mesmo executivo brincou concluindo que “cada dez minutos de boa conversa pode eliminar a necessidade de dez páginas de papel”. Para todas as empresas que chegaram neste ponto, e não são poucas³, o Scrum apresenta possibilidades maravilhosas. É difícil ignorar o canto da sereia que cobra tão pouco pelo muito que promete.

    O movimento no mundo dos negócios tem reflexos no universo da educação. Agora, além dos tradicionais cursos relacionados com Scrum e similares, passaremos a ver apostas mais ambiciosas e, de certa forma, mais abrangentes. Um curso de extensão da Universidade Federal de São Carlos (UFSCar), que neste ano fez uma experiência com um método “genérico” baseado no modelo iterativo e incremental, adotará o Scrum para a turma de 2011. Os Donos dos Produtos (Product Owners, ou simplesmente PO’s) já foram nomeados – são funcionários da Universidade – e os projetos já foram definidos. Assim como a grade com a distribuição das disciplinas. É o tipo de experiência com potencial para espalhar ainda mais a “novidade” Scrum. Realizada por uma entidade com o nome e peso da UFSCar, pode significar um impacto ainda maior.

    .:.

    Observações:

    1. Desconfio que Takeuchi e Nonaka nem prestem muita atenção em sua distante “criatura”. Na realidade eles apenas inspiraram a criação do Scrum. O que eles devem realmente lamentar é o fato de outras grandes descobertas e experiências suas não ganharem o impulso “pop” que o Scrum experimenta hoje. A dupla – que digo parecer dupla sertaneja ‘de raiz’ de Piracicaba – publicou alguns dos trabalhos mais relevantes da mal interpretada disciplina conhecida como Gestão do Conhecimento. Vou citar três: “Gestão do Conhecimento“, compilação de artigos organizada pelos dois (Bookman, 2008); “Theory of Organizational Knowledge Creation” e “Reflection on Knowledge Management from Japan“, artigos publicados na obrigatória coletânea “Knowledge Management – Classic and Contemporary Works” (MIT Press, 2000).
    2. De Ken Schwaber: “Agile Project Management with Scrum” (MS Press, 2004) e “Enterprise and Scrum” (MS Press, 2007).
      De Jeff Sutherland: Scrum Log (desde 2002).
    3. Essa coisa que diz que escrever mais é a solução gera situações cômicas. Em uma turma fechada do FAN no Rio de Janeiro, eu explicava os cinco níveis de detalhamento que uma especificação de casos de uso pode ter. Mostrava aqueles cinco ícones sugeridos por Alistair Cockburn em “Escrevendo Casos de Uso Eficazes” (Bookman, 2006). Quando terminei a explicação um aluno falou: “Pra gente, que trabalha com fábricas de software, isso aí não vai funcionar não. Faz o seguinte: depois da ‘ostra’ (o nível mais baixo) vamos colocar mais um ícone. Sete mil metros abaixo do nível do mar. Coloca o símbolo da Petrobras e vamos chamar isso aí de ‘Nível Pré-Sal’. Só assim as fábricas fazem o que a gente precisa”.
      Triste conclusão de outro participante: “Nem assim funciona…”
    4. A foto utilizada, “Vertical Scrum“, foi tirada pelo Jurvetson.

  • O Cubículo Global

    Parte 1.1 da palestra “O Futuro não é mais como era Antigamente“. Tanto no evento quanto no artigo anterior, “O Clube da Esquina Globalizada“, não explorei como queria este ponto, que trato genericamente como o “cubículo global”. Espero preencher a lacuna com este artigo. Lembrando que a palestra é sobre Engenharia de Software e minha (retórica) questão é: nossas teorias, métodos e práticas resistem ao confronto com as pessoas e tecnologias de hoje?

    .:.

    Surrupiei o título de um artigo da ZapThink. O “Cubículo Global” seria uma das cinco “supertendências” da TI corporativa. O texto da ZapThink reconhece que se trata de uma tendência “com mais de 100 anos de idade”. Afinal, desde a invenção dos telégrafos e telefones o trabalho remoto e a colaboração à distância se tornaram possíveis e viáveis. Os avanços tecnológicos possibilitaram que colaboradores espalhados ao redor do globo trabalhem como se estivessem em uma mesma sala. Mas a tecnologia, neste ponto, serviu apenas para pavimentar o caminho para uma mudança maior e mais significativa. Uma grande mudança cultural está acontecendo, à revelia das organizações, e seu impacto na área de conhecemos como Engenharia de Software não pode ser desprezado.

    De todas as grandes e muito bem vindas provocações colocadas por Don Tapscott e Anthony Williams em “Wikinomics – Como a Colaboração em Massa pode Mudar o seu Negócio” (Nova Fronteira, 2007), existe uma que deveria ser lembrada diariamente pelas empresas: por mais talento que você contrate e retenha, sempre haverá mais inteligência lá fora do que aí dentro.

    Muito se fala sobre uma guerra de talentos, sobre a necessidade de uma empresa formar e tentar segurar pessoas que fazem a diferença em um mundo de hipercompetição. É claro que este tema merece a posição que ocupa na agenda das organizações. O problema, particularmente quando falamos sobre desenvolvedores, é que a cada dia eles têm mais motivos para estar fora. Não estou dizendo que todos os desenvolvedores se tornarão freelancers ou microempresários. Mas parece inevitável que um contingente de alguns dos melhores talentos da área decrete sua independência. De maneira aparentemente irreversível.

    Em primeiro lugar, de todos os trabalhadores do conhecimento, ninguém parece se incomodar mais com o “gap cultural” diagnosticado por Domenico De Masi¹ do que os desenvolvedores. Para entender: este gap é um fenômeno que “constrangeu os atuais knowledge workers, os trabalhadores do conhecimento, a se organizarem segundo os velhos princípios industriais”. O desenvolvimento de sistemas requer criatividade. É interessante notar que em doses cada vez maiores. O que torna legítima a insatisfação de seus praticantes com muitos processos e “metodologias” que lhes são impostos. Comando e controle não combina com criatividade. Mas esta é apenas uma parte do gap.

    Vários desenvolvedores têm em suas casas, bolsos e mochilas mais tecnologia, ou tecnologias mais modernas e atraentes do que aquelas utilizadas pelas empresas. E é indissociável do programador a vontade de trabalhar com o que é novo e desafiador. Me mostre um programador “conservador” e eu te mostrarei um cara que não hesitará em mudar de profissão na primeira oportunidade.

    Empresas que têm software n’alma (e no núcleo de seu negócio) sabem que os “velhos princípios industriais” seriam seríssimos impedimentos para seu sucesso. É por isso que na Google, Microsoft e em outras empresas notáveis há um zelo extremo com o ambiente de trabalho. Videogames e quadras de jogos, salas de “descompressão”, restaurantes e lanchonetes, salas de reunião e mobiliário. Tudo é pensado e desenhado para atrair e reter as melhores pessoas. Nem vou falar sobre remuneração. Mas sua vagas são limitadas. O que farão as centenas de milhares ou milhões de desenvolvedores que elas não contratam?

    Alguns já viram na App Store da Apple e no Marketplace da Google a resposta. Alguns? Só a loja da Apple já contabiliza mais de duzentas mil aplicações e cinco bilhões de downloads. O lançamento do iPad e a dinâmica da Apple fazem crer que essas curvas estão longe da estabilização. Tendo em vista que cada aplicação tem um mercado potencial de milhões de usuários ao redor da Terra, não é exagero supor que uma aplicação bem sucedida pode significar a aposentadoria para um desenvolvedor. Claro, para a maioria isso não passará de um sonho. Mas muitos tentarão a sorte. Aliás, já estão tentando.

    O Melhor dos Mundos

    No artigo anterior citei pesquisa da FGV que fala em um déficit de 800 mil profissionais só no Brasil. Acima cogito a possibilidade de uma debandada de outros tantos talentos. Como ficarão as empresas, tenham elas o software como atividade fim ou não?

    Não vejo mudanças muito significativas no curto prazo. O brasileiro, apesar da fama dizer o contrário, é muito conservador. Particularmente quando se trata de TI. Mas é possível projetar (ou seria torcer por?) um panorama bem diferente em um horizonte de três ou quatro anos. Organizações vão querer contar com aqueles reconhecidos talentos em projetos pontuais. Aquelas que têm o software como seu negócio central criarão redes de colaboradores virtuais. A localização física deles não terá importância nenhuma. Relevantes serão seus conhecimentos especializados e, em diversos casos, os ativos de software que cada um possuir. Uma equipe pode ser formada por um desenvolvedor de Blumenau, outro de San Francisco e um designer de Pádua, na Itália. Localmente ela só precisará de alguém que faça a ponte com o(s) cliente(s) e usuários. Isso soará bobo e romântico para alguns (Pádua?!?) e como notícia velha para outros que já trabalham assim não é de hoje². O que projeto é o crescimento considerável deste tipo de arranjo produtivo. Grandes fábricas desantenadas terão que concorrer com redes de oficinas (ou boutiques) especializadas. Vários componentes das redes serão empresas de uma pessoa só.

    Empresas que não têm o software como atividade fim terão mais opções de compra. A era dos projetos mastodônticos e milionários vai tarde mas vai. Já foi! Assim como a era das arquiteturas fechadinhas e repletas de ângulos retos. Tudo isso abre espaço para a participação de pequenos mas talentosos agentes criativos que nas horas vagas tentam a sorte nas roletas da App Store, Google Marketplace e afins. Para o comprador é um tipo de paraíso porque ele conta com um talento comprovado e sem o tradicional “overhead” daquelas empresas de RH que se disfarçam de solucionadoras de pepinos de TI. Para o pequeno agente criativo é também um paraíso porque ele não precisa fingir que acredita nem se submeter aos processos e juras daquelas tradicionais empresas de RH que fingem saber tudo de TI. Ele vende direto, pode colocar preço em seus produtos e serviços e seguir seus processos e práticas sem depender de nenhum amém. Amém? Inté!

    .:.

    Observações:

    1. “Criatividade e Grupos Criativos“, Sextante, 2002. Há tempos não citava este trabalho por aqui. É um tijolão de quase 800 páginas que deveria ser lido por tudo mundo que quer falar sobre inovação e criatividade. Pena que De Masi só seja lembrado pelo “ócio”… Beócios!
    2. Tem uns 4 anos que uma grande empresa multinacional me contratou para avaliar a adequação de uma aplicação aos seus processos. Me escolheu exatamente porque fazia pouco tempo que eu a havia estudado (analisado seu negócio). A empresa que queria vender a solução teve que me dar acesso a uma versão completa da solução e também ao código fonte. Eu tinha aqui os mapas dos processos que eu mesmo havia desenvolvido. Em pouco mais de 3 dias elaborei todo o trabalho. Sem ver a cara de ninguém. Só precisei sair de casa, daqui de Varginha, pra colocar a NF no Correio. Hoje, com as notas eletrônicas, nem isso seria necessário. Só desfilei o lero-lero para ilustrar um pouco mais a afirmação: a localização do trabalhador do conhecimento é irrelevante em um número cada vez maior de situações.
    3. “Another day at the office” é o nome do Cartoon utilizado hoje, do HikingArtist.

  • O Clube da Esquina Globalizada

    Esta é a primeira das três partes da palestra que apresentei no último sábado, “O Futuro não é mais como era Antigamente“. Publicarei todas aqui, antes que voltem para o segundo plano de minha gaveta. Hoje escrevo sobre pessoas e equipes. O artigo foi bem contaminado por um tema que ganha espaço até em agenda de candidato, o “apagão” de mão de obra qualificada.

    .:.

    Nossa história se inicia com um grande apagão. Lá nos idos de 1950 e início da década de 1960, quando agências do governo dos EUA e algumas pouquíssimas empresas começaram a apostar no potencial do “cérebro eletrônico”, aconteceu a Crise do Software 1.0: milhões foram gastos naquelas engenhocas mastodônticas antes que sentissem falta de um componente essencial: gente. Particularmente daquele tipo que depois receberia a genérica alcunha “programador¹”. Qualquer projetinho de meia tigela demandava dezenas e até centenas de profissionais. Acontece que poucos projetos daquela época eram pouco ambiciosos. Só o SAGE (Semi Automatic Ground Environment), da Força Aérea, contou com 700 programadores e 1400 profissionais de suporte. Época legal, em que cada linha de código chegava a custar assombrosos US$ 50.

    A grana, melhor dizendo, o potencial de faturamento chamou a atenção de muita gente. Começaram a brotar as “software houses” independentes. O desenvolvimento de sistemas deixava de ser uma exclusividade dos produtores de ferro (IBM, Burroughs, RCA etc). Mas como faltava gente. Os dois anúncios que você vê ao lado se preocupavam só com isso: atrair talentos. O simpático Dr. Bauer, da Informatics Inc., cravou a sua “segunda lei” no clássico reclame²: “o talento vai para onde está a ação“.

    Mas os anúncios não eram suficientes. E as empresas lançaram mão das estratégias mais agressivas para encontrar “talentos”. Montavam escritórios e quiosques em grandes cidades só para achar pessoas que poderiam ser “convertidas” em programadores. Os recrutadores eram orientados a dedicar especial atenção para: professores de matemática e, olha que jóia, professores de música!

    A estratégia funcionou. Em paralelo, universidades e escolas nasceram ou criaram cursos para formar gente que deveria atender toda aquela demanda pós-moderna.

    Até que, num belo dia, o mundo ficou chato (no sentido de ter uma superfície plana). E dos lugares mais improváveis surgiam programadores que prometiam executar o mesmo trampo de seus similares ocidentais por 1/10 do preço ou menos. Quem já teve o prazer de ler “O Mundo é Plano“, de Thomas L. Friedman (Objetiva, 2005), aprendeu que a Globalização 3.0 não afetou apenas os desenvolvedores de sistemas. Ninguém está isento do achatamento do mundo. E todo mundo pode aproveitá-lo. Acontece que a pancada no mercado do software, além de ter sido a primeira, foi também a mais sentida. “The New Face of the Silicon Age”, artigo publicado na Wired em fevereiro de 2004, mostra bem o tamanho do estrago.

    Os Pecados do Lado de Baixo do Equador

    O alegre povo de Pindorama, com um certo atraso, sacou: “tem bagulho bom aí!” (e João de Santo Cristo ficou rico a acabou com todos desenvolvedores da Índia). Bem, não foi bem assim. Poderia ter sido, não fôssemos tão viciados no auto-engano. A edição da EXAME aí ao lado, de 25/jun/2003, cravava na capa: “Descobrimos um segredo: o Brasil produz tanto software quanto a Índia.” Pouco tempo depois, em 17/mar/2004, a mesma revista jogou uma ducha d’água fria: “A Índia dá aula ao Brasil” (negrito e vermelho da versão original). Segredinho sem vergonha esse, hem?

    Jogamos tantas fichas em apostas bobinhas (CMMI, MPS.br e cartórios afin$) que agora assistimos bondes a nos ultrapassar. EXAME, em 30/jun/2010: “Rivais Além do Futebol – No setor de tecnologia, os empreendedores da Argentina estão melhor que os brasileiros na corrida da globalização.”

    Vou poupá-los do chororô sobre uma estratégia para o software tupiniquim. Quem se interessar pelos meus R$ 0,02 sobre o tema pode ler uma pequena série que publiquei em dezembro de 2007 no abandonado Graffiti. O ponto aqui é outro.

    É a Educação, Estúpido!

    O que Índia, China, Coréia do Sul e outros emergentes da indústria digital têm em comum é a preocupação com educação. O tema sempre aparece na pauta de nossos políticos. Mas aparece assim, como um tópico em um slide que apresenta suas “prioridades”. Até hoje não vi ninguém ir além do óbvio (mais escolas, professores melhor preparados e mais bem pagos etc etc). Como sou um dos menos indicados a tratar o tema com a profundidade e seriedade que ele merece, me limitarei a propor dois ou três novos “slides”, com questões mais específicas:

    • No último dia 12/ago a FGV assustou um tanto de gente com um número: “Até 2014, haverá um déficit de 800 mil vagas no setor“. Como não tem muito tempo que esse número era 200 mil, minha desconfiança é alta. Tanto que na palestra perguntei: “Será que estão confundindo a gente com atendentes de telemarketing de novo?” Não importa (muito). O fato é que há sim um “apagão”. E como suprir tamanha demanda de forma rápida? Com cursos técnicos! Em 2 anos é possível formar um batalhão de bons desenvolvedores. Repito o que disse o mineiro Adail Retamal em um seminário há 3 anos: “Programação se aprende em curso técnico, não na faculdade“.
    • Não tenho números oficiais, mas há tempos sabemos que cerca de metade da patota que inicia um curso (técnico ou superior) não o conclui. Alguém já se ocupou em descobrir as razões de tanta desilusão? Será que a distância entre nosso instigante cotidiano digital e os ângulos retos e empoeirados de nossas escolas não é uma boa explicação?
    • Se eu tivesse grana montaria uma escola com uma grade antenada. Uma base comum, formada por mínimas certezas e teorias fortes, seria obrigatória para todos. Depois, um cardápio multidisciplinar estaria à disposição de designers, engenheiros, líderes, analistas etc. Não me preocuparia em ter o crivo do MEC, PMI, IIBA nem nada do tipo. Uma escola de pensamento independente. Acho que seria uma revolução.
    • A formação de mão de obra qualificada é responsabilidade exclusiva de governos? É estranho o pensamento de alguns de nossos capitalistas de TI. Aqueles que têm real consciência da criticidade das pessoas para seu negócio devem se mexer. Quem quer talento hoje deve se preocupar em formá-lo. Duas dicas: i) Faça com que 4 ou 8 horas da jornada semanal seja utilizada exclusivamente em atividades de aprendizado; ii) Incorpore a segunda lei do Dr. Bauer: “O talento vai para onde a ação está“. Ação, pra quem não entendeu, é projeto que dá tesão.

    Observações:

    1. É preciso dizer que naquela época a tarefa de programação era dividida entre diversas funções, do pensador de algoritmos ao perfurador de cartões.
    2. Sorte nossa que o anúncio, lá no rodapé (p.s.), mata a curiosidade. A “primeira lei” do Dr. Bauer é a seguinte: “se o programa tem um bug, o computador o encontrará”. Grande Dr. Bauer. Mal sabia que sua primeira lei viraria mantra-desculpa de tester preguiçoso…
    3. A parte pré-histórica aqui narrada foi surrupiada do grande livro “From Airline Reservations to Sonic the Hedgehog – A History of the Software Industry”, de Martin Campbell-Kelly (The MIT Press, 2003).
    4. O cartoon, “Fitting into the system“, foi surrupiado de HikingArtist.com. Os dois anúncios que ilustram este artigo foram publicados no livro citado acima. E as capas da EXAME e da Wired são propriedade de suas editoras.
    5. O “Clube da Esquina” é do Milton e de todos os Mineiros; “O Pecado ao Sul do Equador” é do Chico; e o “Bom Bagulho”, do Renato Russo.

  • Agile Project Management

    Autor: Jim Highsmith é um consultor e escritor, especialista em engenharia de software e gerenciamento de projetos. Além do livro apresentado aqui, escreveu também “Adaptive Software Development” (Addison-Wesley, 2000), dentre outros. Foi co-autor do Manifesto Ágil.

    Editora: Addison-Wesley | The Agile Software Development Series. Primeira edição de 2004. Esta entrada é sobre a segunda edição, publicada em 2010.

    Do que se trata: Criação de produtos inovadores através do APM – Agile Project Management, ou Gerenciamento Ágil de Projetos. Apesar da intenção de atender um público mais amplo, é claro que Highsmith concentra-se no desenvolvimento de software.

    O autor sugere um Agile Enterprise Framework composto por 4 camadas:

    • Governança do Portfólio
    • Gerenciamento de Projetos
    • Gerenciamento de Iterações
    • Práticas Técnicas

    O livro só não cobre a última camada, que pode ser composta por práticas sugeridas em frameworks como XP (eXtreme Programming), OpenUP etc.  Highsmith defende que a estrutura proposta “facilita a construção de métodos ágeis híbridos que atenderiam necessidades específicas de uma organização”.

    O destaque para o Gerenciamento de Iterações não é novo, mas Highsmith coloca o tema em um novo patamar. O Planejamento Avançado de Releases é uma das principais atualizações desta segunda edição. As outras são: Valores Ágeis; Escalando Projetos Ágeis; Governança de Projetos; e Medição de Performance.

    A quem se destina: Líderes de projetos.

    Mas também pode ser muito útil para:

    • Gerentes de projetos insatisfeitos com sua situação atual;
    • Gerentes de produtos cobrados por inovação, qualidade, valor, agilidade…
    • Qualquer um que queira conhecer o Mundo Ágil de maneira ampla e sem dogmas ou extremismos. É particularmente indicado para executivos e gerentes.

    Prós:

    • Isenção. Highsmith não defende nada específico como Scrum, XP ou FDD, por exemplo. E justifica sua posição lembrando que um dos princípios  do desenvolvimento ágil é a adaptação para diferentes situações.
    • É esta isenção que possibilita que Highsmith critique alguns caminhos e descaminhos do Mundo Ágil.
    • O livro é muito bem estruturado e ilustrado. O que torna a leitura das 370+ páginas um estudo agradável.

    Contras:

    • As alterações em relação à primeira edição são muito grandes. Desconfio que o “segunda edição”, apresentado em letras garrafais na capa, faça com que muitos que conheceram a primeira edição ignorem este lançamento. Não deveriam.
    • Aliás, que capinha mais feia, hem?

    Destaques Aleatórios:

    • “Qualquer um que pratique o desenvolvimento ad hoc sob o disfarce ‘ágil’ é um impostor.” (pág. 9)
    • “Olhando de fora, um time gerenciado e um time liderado podem parecer a mesma coisa. Dentro eles são muito diferentes.” (pág. 48)
    • “Princípios guiam práticas. Práticas instanciam princípios. Não dá para separá-los”. (pág. 86)
    • “Todo projeto deve ter um time de desenvolvimento e um time de produto. O grupo de desenvolvimento deve ser liderado pelo líder do projeto e o grupo de produto pelo gerente do produto (que no Scrum é chamado Dono do Produto).” (pág. 119)
    • “O reconhecimento de que a iteração 0 (zero) não entrega valor para o cliente pressiona o time a mantê-la breve”. (pág. 147)
    • “… ‘Como você consegue estimar o desconhecido?’ A resposta é: ‘Você não consegue’. Quando há o desconhecido você está chutando, não estimando – e isso é o melhor que podemos fazer. É por isso que tempo e custo são vistos como restrições, e não estimativas, em projetos ágeis.” (pág. 153)
    • “A falta de um bom planejamento de releases é endêmico em partes da comunidade ágil”. (pág. 157)
    • “Existem duas estratégias fundamentais para o gerenciamento de mudanças – antecipação e adaptação – e o bom design leva ambas em consideração.” (pág. 218)
    • “Muita gente, inclusive algumas da comunidade ágil, pensa que o gerenciamento ágil de projetos significa menos gerenciamento. Em minha experiência, o gerenciamento ágil pode ser diferente, mas com certeza não demanda menos tempo.” (pág. 225)
    • “O intercâmbio de pessoas é muito mais eficaz que o intercâmbio de papelada.” (pág. 283)
    • “Os relatórios do Standish Group NÃO são bons indicadores da pobre performance do desenvolvimento de software, eles SÃO bons indicadores das sistêmicas falhas de nossos métodos de planejamento e medição.” (pág. 334)
    • “Quem nunca cancela projetos nunca corre riscos. Quem não corre riscos não sobrevive. não é fracasso, é bom gerenciamento.” (pág. 334)
    • “Previsibilidade ou agilidade: escolha uma.” (pág. 336)

    Trilha de Estudo:

    • Como prometido, uma trilha curta (em número de títulos). Esta entrada completa a anterior, “Agile Product Management with Scrum“, de Roman Pichler. Diz aí, você precisa de 2 dias, 2 semanas ou 2 meses para estudar ‘isso tudo’? Inté!

  • Morte e Vida UML

    Há exatamente um ano Ivar Jacobson “media a temperatura” da UML. Como um de seus criadores, Jacobson fez uma leitura honesta da moda (“espalhou como fogo em mato seco”), desilusão, críticas de acadêmicos e agilistas e do ressurgimento da UML. Concluiu pedindo um uso mais “esperto” (smart) da linguagem. Conclusão vaga e marketeira: ele mantém o “Smart Blog” que vende um “Smarter Way”. Muito smart e ambíguo para o meu gosto.

    O que não desvaloriza seu diagnóstico objetivo e claro do momento atual da UML. Sim, a UML ganha uma segunda vida. Ou deveríamos dizer segunda chance? Até a Microsoft, que parecia ter sugerido de forma um tanto ingênua que DSL’s (Domain-Specific Languages) seriam alternativas à UML, agora destaca seu amplo suporte como um diferencial da nova versão do Visual Studio¹. São diversos os sinais que indicam um tipo de renascimento da UML. O que fazer para evitar um novo ciclo de desilusões e abandono?

    Deveríamos começar por uma isenta avaliação de tudo o que fizemos de errado na primeira onda. Em primeiro lugar há nossa irritante mania de viver colocando a carroça na frente dos bois. A adoção da UML significou, para várias organizações, a aquisição de ferramentas caríssimas. Os fornecedores dessas ferramentas, cumprindo bem o seu papel, prometiam maravilhas. Particularmente em relação ao aumento da produtividade dos desenvolvedores. Ignoravam ou faziam vista grossa para um contexto mais amplo. A incorporação da UML normalmente fazia parte de um plano maior: a implantação de novos métodos de trabalho. Numa cumbuca mais sortida que feijoada baiana fica difícil apontar responsáveis diretos por ganhos ou perdas. E a UML acabou pagando muito mais do que devia. Tanto que até hoje encontramos pessoas que acham que UML é uma “metodologia”.

    Ensinar UML através de uma ferramenta é como ensinar matemática com calculadoras: um grande e sério erro.

    Desconfio que a raiz do problema está na forma como UML é ensinada e aprendida. O ensino da UML através de uma ferramenta, qualquer ferramenta, é um grande erro. Tão sério quanto ensinar matemática com calculadoras. Os alunos não têm a chance de perceber a UML como ela é, como uma Linguagem. E as limitações das ferramentas, que não são poucas, acabam interpretadas como limitações da linguagem.

    Por exemplo, não é raro encontrar pessoas que dizem que o desenho ao lado é um erro. Para elas a UML seria um simples padrão de notação. E, como tal, estaria restrita às figurinhas oferecidas nas ferramentas. Considero este o mais sério e comprometedor problema que temos com a UML. Uma limitação que nos leva a utilizá-la da mesma maneira que um compositor de funk carioca utiliza a língua portuguesa.

    Como toda linguagem, do português ao C#, a UML é viva. É extensível. Podemos e devemos adaptá-la às nossas necessidades. Mas fizemos um serviço tão ruim neste ponto que existem aqueles que acham que a possibilidade de criar extensões como a EPBE (Eriksson-Penker Business Extensions) é gambiarra ou correção de bugs, não uma característica projetada da linguagem.

    Ao ensinar UML devemos abandonar toda e qualquer ferramenta automatizada. Lápis e páginas de caderno são tudo o que precisamos para ensinar e aprender UML. Um profissional que domine bem os conceitos da linguagem saberá tirar mais valor de qualquer ferramenta que lhe seja oferecida. E assim, talvez, aquelas promessas maravilhosas dos fornecedores de ferramentas se realizem.

    Grande Demais, Complexa pra Chuchu

    Não deveríamos ensinar português através da gramática e sim com Chico Buarque e Machado de Assis.

    São outras críticas comuns, que aparecem principalmente no discurso de alguns agilistas. Toda linguagem é naturalmente complexa. Ou, melhor colocando: toda gramática², em sua plenitude, é naturalmente complexa. O fato é que pouquíssimos de nós dominamos a gramática da língua portuguesa, por exemplo. Mas isso não impede que utilizemos a língua das mais diversas maneiras em nosso dia a dia. O mesmo precisa ser dito sobre a UML. Ninguém precisa conhecer de cor e salteado toda a especificação e o metamodelo da UML, sua gramática, para poder utilizá-la. Aliás, se quisermos espantar fregueses, basta apresentar a UML desta forma.

    A UML é grande por necessidade, não por pura encheção de linguiça. E parece complexa para todos que não entendem ou não aceitam sua proposição original, de ser uma Linguagem Unificada de Modelagem. Ela é perfeita? Claro que não – fomos nós humanos que a criamos. É boa? Sim, eu diria excelente. Mas talvez esteja aqui seu grande problema: não há nada que possa ser comparado à UML. Lá em meados dos anos 90 tínhamos dezenas de propostas de padrões de notação. A UML veio para acabar com aquela baderna. Mas seu sucesso e consequente aceitação universal – um tipo de monopólio – criou este problema. Ela não é pior nem melhor nem maior nem mais complexa que ninguém simplesmente porque não temos com o que comparar.

    UML não é Chacrinha

    O Chacrinha dizia que tinha vindo para “complicar, não para explicar”. O maior objetivo da UML é o oposto. E, de novo, tenho que apelar para o “L” de UML: toda linguagem criada pelo homem tem esse único objetivo, facilitar a comunicação. Mas não são poucas as organizações que destruíram esse propósito quando instituíram que UML era “padrão de documentação”. Quando passaram a exigir que esse ou aquele diagrama fossem elaborados com o único propósito de documentar determinado trecho de um projeto. Nada pode ser mais nocivo e criar mais antipatia a uma proposta do que a percepção de obrigatoriedade descerebrada ou insensata. Por isso não são poucos os que fazem cara de nojo quando ouvem as letrinhas U-M-L. Passa da hora de devolvermos à UML suas proposições originais: explicar, e não complicar; Facilitar a comunicação e interação, e não substituí-las.

    Confesso que a ficha do péssimo uso que fazemos da UML só caiu quando comecei a participar de alguns fóruns e a apresentar meus eventos para analistas de negócios. Cheguei a acreditar na realização da profecia sugerida na capa da Software Development de abril de 2001, apresentada acima. Mas aí vieram o artigo do Jacobson, debates mais ricos, empresas interessadas na ressurreição da UML e a onda do Pensamento Visual. Taí, a UML realmente tem sua segunda chance. Ou eu deveria dizer que nós temos uma segunda chance?

    .:.

    Observações:

    1. Na revista INFO de junho/2010 tem um anúncio do Visual Studio, apresentado na forma de uma entrevista com o gerente de produtos da Microsoft Brasil, Sr. Rodrigo de Carvalho. A primeira pergunta é: “Por que clientes devem migrar para a nova versão do Visual Studio 2010?”. Resposta: “Por várias razões, mas destacaria: suporte à modelagem UML…“. Sim, ele começou pelo suporte à UML. Quem conhece o histórico das idas e vindas da MS em relação à UML entenderá o meu destaque aqui.
    2. Gramática, segundo o Houaiss, é um “conjunto de regras que determinam o uso correto de uma língua”.
      Não exagero quando trato a especificação da UML como um tipo de gramática. E reitero objetivando a aceitação de que UML é de fato uma língua. E que, como tal, ela deve nos ajudar a atender três grandes objetivos: i) Organizar o conhecimento; ii) Representar o conhecimento; e iii) Trocar conhecimentos.

  • Iterativo & Incremental: O Segundo Fator

    Semana passada sugeri uma forma alternativa de apresentar e justificar a adoção de um ciclo de vida para projetos baseado no modelo Iterativo & Incremental. Deveríamos enfatizar a certeza de que todos cometerão erros em detrimento do destaque dado às inevitáveis mudanças.

    Faltou dizer que muito do que chamamos de mudanças são na realidade erros. Usuários e clientes não são obrigados a aprovar o primeiro produto que recebem, por precisas e assinadas que sejam atas, especificações de casos de uso ou afins. Há mais mistérios entre requisitos e o produto final do que imagina nossa vã filosofia. E essa distância sempre exigirá, em alguma medida, um processo de tentativa e erro. Esse tipo de mudança é sim um erro. Muitos não gostam da palavrinha ou de admitir que erram. Mas deveríamos classificar melhor aquilo que chamamos de erros e mudanças. Papo para outra hora.

    Porque hoje eu gostaria de destacar um segundo fator que justifica a adoção do modelo Iterativo & Incremental: as pequenas vitórias. Assim como é indiscutível que o ser humano erra, também é indissociável de nossa natureza a necessidade de motivação – de uma recarga quase diária de nossas baterias. Em projetos não bastam seus objetivos, por nobres e ambiciosos que sejam, nem eventuais compensações financeiras. Imagine um campeonato de futebol, curto como uma Copa do Mundo ou longo (e cansativo) como o Brasileirão. Os times e jogadores comemoram cada vitória e cada gol. No vôlei, um jogo definido após dezenas de pontos, cada um deles é comemorado. Cada gol ou ponto é uma pequena vitória. Elas são tão cruciais para uma equipe de projetos como são para os jogadores.

    Em projetos tocados segundo moldes convencionais, particularmente no popular “cascata”, há pouco espaço para comemorações intermediárias. Por mais que equipe e coordenadores soltem foguetes para um documento de visão bem escrito ou uma coleção de especificações e modelos “nota 10”, o fato é que não há torcida nem usuários ou clientes compartilhando aquele momento e muito menos incentivando-o. É como uma vitória em treino, fechada e sem valor.

    A vitória que conta, por menor que seja, tem participação direta do público externo – dos usuários e clientes. E eles sabem que documentos e modelos não valem como gols e pontos. Ou seja, não substituem o produto final.

    Um projeto guiado pelo modelo Iterativo & Incremental supõe a comemoração de várias pequenas vitórias. Admite sim alguns revezes, como vimos no artigo anterior. Mas, exatamente por conta deste fator, torna a vitória final mais factível. Cada entrega, iteração ou gol é motivo para celebração. E isso ajuda a renovar o ânimo do time. No contexto de projetos há outros efeitos colaterais bastante benéficos, sendo o principal deles o aprendizado. O time tem a chance de rever seus erros e acertos, o que possibilita uma melhor preparação do próximo ataque, jogo ou iteração.

    Imagine um zero a zero arrastado e chato. Pior ainda, decidido nos pênaltis. Compare com uma sonora goleada, um jogo aberto e bonito de se ver, com placar final de 5 a 3. Qual você prefere?

    .:.

    “Goal“, a foto utilizada neste artigo, é do Jonas B.