Ricardo Fernandes Luiz

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

Archive for the ‘Scrum’ Category

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

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

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

Retrospectiva #AgileBrazil 2010

leave a comment »

Saudações pessoal!

Este post está um pouco atrasado, mas não será sonegado! =D

Na semana dos dias 22/06 a 25/06 aconteceu na cidade de Porto Alegre o evento Agile Brazil 2010, que contou com nomes influentes do cenário nacional e mundial de agile. O evento foi muito bem organizado e contou com cerca de 800 participantes.

Auditório Agile Brazil

A abertura do evento foi feita por ninguém menos que Martin Fowler um dos criadores do manifesto ágil. Em geral a apresentação dele não trouxe novidades para quem já acompanha seu blog, mas ouvir ele apresentar pessoalmente suas idéias já é gratificante.

Achei interessante a palestra do David Hussman entitulada “Produtos e Pessoas sobre Processo e Dogma”, a ideia geral da palestra era conhecer não só como implementar uma técnica, mas conhecer o porque implementá-la, assim só utilizamos se faz sentido, e não somente porque alguém falou que se você não usa aquilo você não é ágil ou coisa do tipo…

Participei depois do workshop do Yoshima e Phillip Calçado, “Reconheça! Você não sabe modelar!”, eles passaram a idéia de que modelar não é necessariamente desenhar algum diagrama, quando se cria um protótipo junto com o cliente já estamos modelando.

No final do primeiro dia assisti a palestra da DBServer, eles abordaram como equilibram a utilização de scrum com contratos de preço fixo, fazendo um pré-game de algumas funcionalidades para medir a velocidade do time e ter alguma previsão do quanto o cliente irá gastar a partir de então.

No segundo dia cheguei apenas após o almoço e peguei a palestra “Quando o Scrum passa a atrapalhar” do Guilherme Silveira e da Cecilia Fernandes, da Caelum. A palestra foi um pouco na linha do pensamento do David Hussman, falando que eles passaram a utilizar somente o que achavam necessário do Scrum, de acordo com a cultura deles. Achei interessante que não houve nenhuma manifestação xiita do tipo “Vocês estão usando scrumbut e vão queimar no inferno!” ou algo assim. Talvez porque o nome Caelum seja bem conhecido na comunidade, mas acredito que isto demonstra um amadurecimento da comunidade em não dizer que existem receitas de bolo para tudo.

A palestra de encerramento do Klaus Wuestefeld, também frisou a idéia de evitar receitas de bolo, ele resumiu os valores do XP em dois, que são suficientes segundo ele para motivar a equipe e tornar o trabalho cada vez melhor.

A grande impressão que tive ao final do evento é que a comunidade está menos xiita e mais voltada a busca de resultados práticos, afinal a idéia de que não há uma bala de prata que sirva para todos os projetos está sendo levada mais em conta do que o medo de não usar o scrum by the book, e ser apontado como um “scrumbut”.

Written by Ricardo F. Luiz

26/07/2010 at 2:09 am

Publicado em Agile, Carreira, Scrum

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.