Ricardo Fernandes Luiz

Agile, desenvolvimento de software, gestão, marketing, e tecnologia em geral

O olho do dono que engorda o ROI

with 5 comments

 

Saudações pessoal!!

Nas últimas 2 semanas, tenho tido discussões frequentes com os membros do #SDC da stefanini a respeito das dificuldades que temos enfrentado na adoção de agile em grandes empresas.

Depois de muitas conversas uma das conclusões que chegamos é que  o alto número de intermediários e cargos, e a política de aprovação de orçamentos emperra a adoção de agile em grandes empresas. Infelizmente em grandes empresas lidamos com intermediários que muitas vezes não estão preocupados em maximizar o ROI, e sim em contratar uma empresa que sirva de seguro para seu cargo. Há uma frase do mundo de TI que diz “Ninguém nunca foi demitido por ter contratado a IBM” que frisa bem este espírito, para quem não entendeu significa que quando o projeto não der certo a defesa da pessoa que contratou será “Mas eu contratei a IBM, se eles não resolveram o problema, quem resolveria?”, algo que não aconteceria, por exemplo se este mesmo projeto fosse realizado por uma pequena empresa, a culpa pelo projeto falho cairia sobre o contratante que não soube escolher um bom fornecedor para realizar o seu projeto.

Este contratante que geralmente não é o dono, mas tem um cargo executivo, tem um budget pré-estabelecido para gastar com determinados projetos. Não interessa para ele investir tempo em quanto do escopo será realmente utilizado e qual a prioridade dos itens necessários para o projeto, para ele é muito mais fácil elaborar uma RFP (e aqui temos alguns dos problemas da RFP) informando quais itens a consultoria terá que assumir, e então passar o risco do projeto para a consultoria, que em troca colocará a famosa “reserva de contigência”, popularmente conhecida como gordura, no projeto, para se proteger do risco.

É claro que se isto fosse feito de modo a diminuir o risco para a consultoria a empresa que contrata iria gastar menos. É como contrair um empréstimo, quando a empresa contrai um empréstimo dando garantias como patrimônios que o empréstimo será pago o valor do juros é menor, quanto maior o risco, maior o juros, e consequentemente maior o gasto que a empresa vai ter para ter o mesmo valor de empréstimo.

Mas qual seria o interesse em investir tempo para economizar um valor que ele já tem aprovado para gastar? E o pior, este valor na verdade para ele é um valor virtual, pois não sairá do bolso dele… Será que existe uma forma para grandes empresas quebrarem este paradigma?

Existe um grupo chamado “Beyound Budgeting Round Table” que propõe não só uma nova forma de controle orçamentário, mas também uma nova forma de gestão, já aplicada em empresas como Toyota, Unilever e o banco UBS, entre outros. Para quem quizer se aprofundar um pouco mais segue uma página sobre o que é beyound budgeting da MetaManagement, que através do Niels Pflaeging, representa o Beyound Budgeting no Brasil.

Não sei quanto tempo ainda levará para que presidentes de empresas despertem para este tipo de gestão que é cada vez mais necessário neste mundo tão dinâmico, mas acredito que as empresas que despertarem primeiro terão um diferencial em gestão de custos e investimento em capital humano.

Para finalizar, deixo vocês com a palestra do Niels Pflaeging, e um artigo da HSM.

Written by Ricardo F. Luiz

21/12/2010 at 1:57 am

Vamos jogar tênis ou frescobol?

with 4 comments

Frescobol

Saudações pessoal!

Peço desculpas a todos pela demora no post, mas tive 2 semanas de férias e quando voltei parecia que tinha saído por uns 6 meses… =D Agora que as coisas voltaram para os trilhos volto a ter um tempo para blogar!

Em uma das empresas que prestei consultoria havia uma faixa no andar de desenvolvimento com a seguinte pergunta: “Estamos jogando tênis ou frescobol?”

Esta frase, baseada no texto do Rubens Alves utilizada para refletir os tipos de relacionamentos entre casados também pode ser aplicada no relacionamento entre cliente x fornecedor ou até no relacionamento entre a equipe interna.

De acordo com Rubens Alves:

“O tênis é um jogo feroz. O seu objetivo é derrotar o adversário. E a sua derrota se revela no seu erro: o outro foi incapaz de devolver a bola. Joga-se tênis para fazer o outro errar. O bom jogador é aquele que tem a exata noção do ponto fraco do seu adversário, e é justamente para aí que ele vai dirigir a sua cortada – palavra muito sugestiva, que indica o seu objetivo sádico, que é o de cortar, interromper, derrotar. O prazer do tênis se encontra, portanto, justamente no momento em que o jogo não pode mais continuar porque o adversário foi colocado fora de jogo. Termina sempre com a alegria de um e a tristeza de outro.

O frescobol se parece muito com o tênis: dois jogadores, duas raquetes e uma bola. Só que, para o jogo ser bom, é preciso que nenhum dos dois perca. Se a bola veio meio torta, a gente sabe que não foi de propósito e faz o maior esforço do mundo para devolvê-la gostosa, no lugar certo, para que o outro possa pegá-la. Não existe adversário porque não há ninguém a ser derrotado. Aqui ou os dois ganham ou ninguém ganha. E ninguém fica feliz quando o outro erra – pois o que se deseja é que ninguém erre.”

Embora em um projeto todos devessem lutar pelo sucesso do mesmo, da mesma forma que existem os casamentos tênis e frescobol, existem os times / clientes tênis e frescobol:

Cliente frescobol

Aponta os erros de forma construtiva. Ajuda o time a resolver impedimentos e guia o time para atingir os objetivos. Se coloca à disposição para resolver dúvidas, afinal o que mais quer é ter um projeto com qualidade.

Cliente tênis

É o oposto do cliente frescobol, se arma de documentações e evidências, quando existe algum erro, no lugar de buscar a melhoria de forma construtiva usa como justificativa para tirar os problemas dele da reta e jogar o problema para o fornecedor. Tem uma postura “Buy and forget” se ele está pagando para que você resolva o problema não quer ficar explicando, se possível quer explicar uma vez só no início do projeto e chegar só no final para dizer que estava tudo errado…

Times frescobol

Busca a melhoria contínua da equipe. Abraçam o projeto, e ajudam uns aos outros não importando se a ajuda ocuparia uma parte do tempo que poderia ser utilizada na realização da tarefa da pessoa. No lugar de enviar emails avisando que tiveram problemas tomam atitude e tentam resolver os problemas.

Times tênis

Cada um se preocupa com a sua tarefa, não importando se o projeto não dará certo por falta de colaboração, pelo menos “fiz a minha parte”. Se algo dá errado tentam justificar com os erros do cliente, ele provavelmente não soube explicar. Não se preocupam com o sucesso do projeto, se na minha máquina funciona, então não é problema meu.

Cabe a cada um de nós identificarmos este tipo de comportamento e escolhermos se queremos ter times e clientes tênis ou frescobol.

Written by Ricardo F. Luiz

06/12/2010 at 10:24 pm

Publicado em Carreira, Gestão, Reflexões

Retrospectiva Encontro Ágil 2010

with 6 comments

Saudações Pessoal!

Aconteceu ontem em São Paulo a 3ª edição do Encontro Ágil. O formato do evento foi bem interessante por ter debates e open spaces sobre alguns assuntos no lugar de palestras, vou relatar aqui um pouco do que vi sobre o evento.

A primeira sessão que vi foi facilitada pelo Alexandre Magno o assunto era Product Vision Games. Ele demonstrou algumas formas de se fazer uma boa visão do produto, nos reunimos em trios e montamos a visão de um produto. Me reuni com o Carlos Leite da empresa Freeddom, e outra pessoa (que não me lembro o nome =/ ), montamos a visão de um produto que tenho no meu backlog a tempos, um site de troca de livros. Um item interessante que fizemos foi o “velório do produto” que seriam fatores que se não forem levados em conta podem fazer nosso produto não ter sucesso nenhum. Este ponto é interessante pois, em alguns casos podemos decidir que nem vale a pena fazer o produto. Ele sugeriu algumas literaturas, como Innovation Games e a técnica Design Thinking .

Logo após começaram as sessões de open space, participei da sessão de Lean e Agile, iniciada pelo Christopher Thompson do Lean Institute Brasil . O Thompsom é formado em engenharia naval e tem um grande background de Lean, sua intenção era entender um pouco mais do mundo do software, pois tem sido contratado por várias empresas deste setor, para aplicar uma abordagem lean.

 A sessão foi bem interessante, embora alguns atritos entre alguns membros da comunidade que defendiam seu ponto de vista (alguns mais by the book e outros menos…) Me surpreendi com algumas colocações do Yoshima, acompanho seu blog, e tinha uma visão dele bem mais radical, mas não foi o que demonstrou na discussão… Isto demonstra certo amadurecimento que o mercado nos dá, e que outras pessoas que apenas vendem treinamento, mas não atuam no mercado entregando software não tem. Thompson em certo momento disse que não entendia as desavenças da comunidade do software, ele falou que na indústria as pessoas discutem Lean, Kanban, etc… todas de forma a agregar umas as outras e que no mundo do software ocorrem várias desavenças… Esta é uma triste realidade, que no meu ponto de vista é ocasionada por algumas pessoas mais radicais que não vivem o dia-a-dia do mercado e querem impor algo que não vivem na prática.

Depois participei da sessão “Evoluindo seu time através de coach” facilitada pelo Felipe Rodrigues, ele apresentou algumas técnicas de coach com demonstração. Depois fizemos duplas e realizamos sessões de coach. Acho que me sairia bem como coach  =D, fiz o coach com um desenvolvedor que queria implantar scrum para melhorar a qualidade do código das equipes com quem ele trabalha, acabamos atráves das técnicas de coach chegando a conclusão que ele poderia fazer isso, usando seu círculo de influência de coordenadores, antes mesmo de implantar scrum…

A última sessão que participei foi o painel sobre equipes auto-organizadas, com o Akita, Klaus Wuestefeld e Eduardo Marcel Maçan. A discussão foi bastante ampla, desde quais são os pontos que fazem com que a auto-organização seja tão difícil (como os padrões da educação – para quem ainda não viu, recomendo o  vídeo do Semler sobre o assunto.), se a hierarquia impede a auto-organização, se é possível escalar, etc…

O evento foi bem proveitoso, e acredito que seu formato será adotado nos próximos eventos agile, pois possibilita muita discussão.

Written by Ricardo F. Luiz

07/11/2010 at 3:56 pm

Publicado em Agile, Lean

Sem boas práticas de engenharia não há agilidade

with 5 comments

Saudações a todos!!!

O objetivo deste artigo é despertar alguns times que algumas práticas de engenharia (como um bom design de domínio, refactoring e TDD) são peças fundamentais para que possamos colher os benefícios das metodologias ágeis. Vamos começar voltando um pouco no tempo e explicar como era o mundo antes das práticas ágeis:

Crise do Software

A “crise do software” foi um termo cunhado para descrever as dificuldades enfrentadas no desenvolvimento de software no fim da década de 60. A complexidade dos problemas, a ausência de técnicas bem estabelecidas e a crescente demanda por novas aplicações começavam a se tornar um problema sério. Foi nessa época, mais precisamente em 1968, que ocorreu a Conferência da OTAN sobre Engenharia de Software (NATO Software Engineering Conference) em Garmisch, Alemanha. O principal objetivo dessa reunião era estabelecer práticas mais maduras para o processo de desenvolvimento, por essa razão o encontro é considerado hoje como o nascimento da disciplina de Engenharia de Software.

NATO Software Engineering Conference 1968

Duas décadas depois, em 1986, Alfred Spector, presidente da Transarc Corporation, foi co-autor de um artigo comparando a construção de pontes ao desenvolvimento de software. Sua premissa era de que as pontes normalmente eram construídas no tempo planejado, no orçamento, e nunca caiam. Na contramão, os softwares nunca ficavam prontos dentro do prazo e do orçamento, e, além disso, quase sempre apresentavam problemas.

Custo das mudanças

Uma das consequências de tentarmos igualar metodologias de desenvolvimento de software a metodologias de engenharia tradicionais (como construção civil) é a visão de que o custo de modificar o programa aumenta exponencialmente ao longo do tempo, conforme gráfico abaixo:

Acolhendo as mudanças

A partir da metade dos anos 90 começaram a surgir discussões sobre se a forma faseada acima (cascata), como ocorre na construção civil era realmente o melhor modelo para o desenvolvimento de software. As metodologias ágeis de desenvolvimento surgiram exatamente para permitir maior flexibilidade no processo de desenvolvimento de sistemas e minimizar o custo de mudanças ao longo dos projetos, fazendo com que o gráfico acima fique mais próximo do apresentado abaixo:

Mas afinal de contas, como isto é possível? Como podemos adicionar mudanças ao software sem implicar em altos custos para o mesmo? A reposta a esta pergunta é o título do artigo: Aplicando boas práticas de engenharia!

Muitos times adotam scrum, mas deixam de lado as boas práticas de engenharia que são necessárias para que seja possível acolher as mudanças ao longo do projeto como pregam as metodologias ágeis. Este tipo de problema já foi discutido por Martin Fowler e James Shore . E meu objetivo com este post é despertar estes times para o estudo de práticas de engenharia como refatoração, boas práticas de design de domínio e TDD .

Se você usa scrum (O que é scrum?) , mas não utiliza estas práticas, sugiro que comece com urgência a estudar estes assuntos.

Um bom caminho para iniciar são os 3 livros abaixo:

Extreme Programming Explained

Clean Code

Domain Driven Design

Written by Ricardo F. Luiz

18/10/2010 at 7:30 pm

Publicado em Agile, Scrum, XP

Não à ditadura do desenvolvimento

with 12 comments

 

Saudações pessoal!

Como sabem sou da área de desenvolvimento de software, mas neste post farei o papel do advogado do diabo  =D

Vou começar com uma analogia:

Você está morrendo de fome e depois de andar um pouco entra no primeiro restaurante que encontra, sua vontade é de comer um hamburguer, na verdade você até gostaria de um prato melhor, mas a fome é tanta que a velocidade de ter um hamburguer torna o prato mais interessante que você pode imaginar…

Você não sabe, mas quem vem atender é um dos melhores chefs do mundo, estudou por anos com os melhores chefs e aprendeu as mais variadas receitas, conhece todas as tendências da culinária e faz com maestria os mais refinados pratos, ele ouve o pedido diz que fica pronto em 10 minutos e vai para a cozinha.

Quando começa a pegar os ingredientes pensa: “Não! Ele não vai querer um hamburguer! Ninguem mais esta comendo este tipo de comida hoje em dia! É comprovado que faz mal a saúde a longo prazo! Ele quer satisfazer a fome, eu entendi isto e vou fazer de uma forma melhor, vou preparar um Blanquette de veau , (digamos que o preço do prato seja o mesmo) vou levar apenas 10 minutos a mais e além de satisfazer a fome dele, ele terá um prato saudável, com mais vitaminas e que os mais variados chefs recomendam.”

O chef volta e o cliente já revoltado pelo prato ter demorado mais do que ele esperava olha e vê que não é o que ele queria, manda ele voltar para a cozinha e fazer o hamburguer que havia pedido.

O chef perplexo argumenta “Não é possível, o prato é bem melhor, mais saudável, por que você vai querer um hamburguer? Agora que fiz um prato melhor vou ter que refazer de uma forma pior?”

Você fica com tanta raiva que não quer mais argumentar tudo o que quer é o maldito hamburguer.

Parece engraçado, mas no mundo do desenvolvimento isto às vezes acaba acontecendo. Estudamos tanto a melhor forma de fazer um software, que às vezes acabamos sequer perguntando ao cliente se é realmente isto que ele quer.

Você pode pensar, eu sou de TI, portanto sei o melhor para o meu cliente, assim como o chef pensou, porém tenho a mesma opinião expressada pelo Kent Beck no livro Programação Extrema Explicada, capítulo 14: “Mesmo que a escolha de uma tecnologia pareça ser em princípio uma decisão técnica, ela é na verdade uma decisão de negócios, mas que deve ser levado em conta informações do Desenvolvimento. O cliente precisará viver com um fornecedor de um banco de dados ou uma linguagem por muitos anos e ele precisa sentir-se confortável com a relação tanto a nível de negócios quanto no nível técnico. Se um consumidor me diz: ‘Nós queremos este sistema, e você precisa usar este banco de dados relacional e esta IDE Java’, minha função é apontar as consequências dessas decisões. Se eu penso que um banco de dados orientado a objetos e C++ é a melhor escolha, eu faço as estimativas do projeto dos dois jeitos, E então as pessoas de negócios podem tomar uma decisão de negócios.”

É nosso dever argumentar sobre um benefício que outra alternativa teria, no entanto se o cliente mesmo assim querer um hamburguer, faça o hamburguer! Não fique preso ao que os demais chefs apontam como tendência, ou o que eles vão pensar se souberem que você fez um hamburguer. Além de mostrar que você entende do seu mercado, vai satisfazer seu cliente e quem sabe faze-lo voltar outro dia para apreciar o Blanquette de veau .

Written by Ricardo F. Luiz

17/09/2010 at 3:31 am

Publicado em Carreira, Gestão, Reflexões

Sucesso = Paixão

with one comment

Saudações pessoal!

Recentemente li uma edição da revista super interessante com uma reportagem que falava sobre o que tornavam algumas pessoas melhores em algumas áreas do que outras. Seria a genética? Ou simplesmente a dedicação?

Geralmente citamos frases como “esta pessoa nasceu com dom para isto” . Este pensamento nos tira a culpa de não sermos tão bons quanto elas, afinal se não temos o tal gene para chutar a bola tão bem quanto o Ronaldinho, não é culpa nossa, certo?

Mas este é o oposto do que diz os estudos (“Cambridge Handbook of Expertise and Expert Performance”) de Anders Ericsson, um dos mais renomados pesquisadores nesta área.

As horas de treino são muito mais fundamentais do que qualquer outro fator genético. Ele usa como exemplo Mozart (que aos 6 anos já se apresentava para reis e frequentemente é usado como exemplo dos que defendem que o dom faz parte da genética). Porém seu pai era músico e o fazia treinar desde os 3 anos de idade. E sua primeira obra avaliada como realmente genial pelos músicos foi feita aos 21 anos de idade, com aproximadamente 15 anos de treino.

E partindo deste ponto podemos chegar a outra conclusão. Ser realmente apaixonado pelo que fazemos é o que realmente faz com que sejamos bons nisto.

Quando vejo profissionais de destaque na minha área (TI) são pessoas que geralmente treinam (escrevem código, lêem artigos, participam de palestras) após o trabalho, e dedicam grande parte de seu dia ao assunto não se limitando ao horário de trabalho 9:00 – 18:00. Se você não tem gosto pela área não estará disposto a gastar horas com isto e nunca chegará no nível deles.

Ano após ano, vejo muitas pessoas ingressarem na área de informática, simplesmente pelo número de vagas ofertadas ou pelo salário acima da média das demais áreas, no entanto muitas dessas pessoas não tem o menor gosto pela área. Qual a chance de ser um profissional destacado se você sequer tem um grande interesse pela área? Se você faz parte destes profissionais, faça um favor para si mesmo, procure algo que realmente gosta, e veja o que as pessoas que são destaque nesta área fazem, estude e treine bastente e em algum tempo você ganhará tão bem sendo um bom profissional de uma área que não paga tão bem, quanto sendo um profissional ruim de uma área que paga bem.

Matérias relacionadas:

No talento, esforço vale mais que genes

A Criação de Astros

Written by Ricardo F. Luiz

07/09/2010 at 5:30 pm

Publicado em Carreira

Planejando suas iterações com o TFS 2010

with 2 comments

Neste post apresentarei como planejamos uma sprint utilizando o TFS 2010 com o template MSF for Agile 5.0

Vou admitir que você já tenha criado o team project com o template MSF for Agile 5.0

O primeiro passo que devemos realizar é a construção do Product Backlog.  O product backlog é formado por uma lista de User Storys que devem ser priorizadas do maior para o menor valor para o cliente, com a finalidade de planejarmos e entregarmos primeiro as funcionalidades de maior valor. Você pode ler mais sobre como criar um bom Product Backlog aqui. Segue link para saber mais sobre o que é scrum?

Dentro da pasta “Shared Documents” do seu Project Portal existe uma planilha chamada “Product Planning”, conforme figura abaixo:

 

Na primeira aba da planilha será apresentada a lista de User Storys, conforme abaixo:

 Product Backlog

Você pode cadastrar as User Storys diretamente na planilha e clicar no botão Publish, para as alterações serem efetuadas no TFS. Cada User Story deve ser medida em Story Points pelo time e deve ser selecionada a iteração a qual pertence em “Iteration Path”. Você também pode criar as User Storys no Project Portal clicando em New Work Item / User Story.

Na segunda aba da planilha “Product Planning” temos a configuração das iterações, nela informamos qual é a data de início e fim de cada iteração e o tamanho do time. É exibido um gráfico com a velocidade do time, conforme abaixo:

 Product Planning

Temos ainda a aba Interruptions onde podemos configurar feriados e dias não trabalhados da equipe. Aqui configuramos as interrupções de todo o time, também temos como configurar uma interrupção de um membro específico do time dentro da planilha de planejamento da sprint que será explicada a seguir.

O próximo passo é o planejamento da iteração. Na sprint planning o time deve quebrar as User Storys em tarefas e estimá-las em horas.

No TFS para criar a Task você deve selecionar a User Story e clicar no botão “Add New Linked Work Item”, selecione no campo Link Type a opção Child, e escreva um título para a Task.

 

Você deve preencher os campos “original estimate”, “remaining” e “completed” com a estimativa original em horas, o número de horas que faltam e o tempo completo, respectivamente. Como a tarefa acaba de ser criada o “original estimate” e o “remaining” serão iguais e o completed será 0. Assim que concluirmos a tarefa devemos mudar o estado para “closed” e preencher o campo remaining com 0 e o completed com o número de horas que a tarefa levou para ser concluída. Você deve ainda selecionar em Iteration, em qual interação esta tarefa estará.

Depois de estimarmos todas as tarefas que irão na próxima sprint você deve configurar a planilha “Iteration Backlog.xlsm” ela deverá ficar dentro da pasta shared documents\”Sua iteração”. Você pode copiar esta planilha da pasta “Documents \ Samples and Templates \ Document Template – Iteration Backlog.xlsm”

 

Abrindo a planilha na primeira aba “Iteration Backlog” temos todas as tarefas que foram cadastradas para a iteração atual.

 

Na segunda aba “Settings”, configuramos  a data de início e fim da iteração.

 

Na aba iterruptions podemos definir interrupções específica do membro do time.

 

Na terceira aba “Capacity” temos uma visão gráfica da alocação do time. Podemos configurar quantas horas cada membro do time poderá destinar a iteração e assim termos uma visão se será possível terminar os itens selecionados dentro da sprint.

 

Quando algum membro do time estiver com muitas tarefas, podemos voltar na aba Iteration Backlog e mudar o campo “Assigned To” para um membro do time que tiver horas ociosas, mostradas em verde.

 

O objetivo deste gráfico é mostrar se o estimado está dentro do possível, durante a sprint caso o time sinta necessidade poderão ser alteradas as pessoas que irão executar as tarefas. Com as tarefas balanceladas o time pode dar início a sprint. Alterando as tarefas para “closed’ quando forem concluídas e o campo completed work com o número total de horas gastas na tarefa e o remaining work para 0.

Written by Ricardo F. Luiz

11/08/2010 at 1:00 am

Publicado em Agile, MSF Agile, Scrum, TFS, VSTS 2010

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.