Posts Tagged ‘agile’

Kanban Yoshima

30 de julho de 2010

Nessa apresentação o Rodrigo Yoshima apresentou o Kanban como ele se encaixa no quadro geral das metodologias ágeis que utilizamos hoje em dia.

O vídeo foi gravado durante o evento da Noite Ágil na Caelum em São Paulo.

Anúncios

Agilidade no mundo real: Brasil 2010

28 de junho de 2010

Semana passada aconteceu o Agile Brazil 2010 em Porto Alegre.

O evento trouxe especialistas e relatos de experiências de todos os cantos do Brasil para mostrar o que está acontecendo com o mercado e o futuro caminho a ser trilhado.

A Cecilia Fernandes e eu mostramos como a remoção de práticas do Scrum em favor a princípios do Lean acabaram por tornar uma das equipes internas mais produtiva e capaz de entregar ainda mais valor. Alguns sugerem que chamemos o que fazemos nessa equipe (e em mais uma, menor, de 2 pessoas) de Kanban, e acredito que esteja bem próximo, mas prefiro me segurar ao lema de não nos atrelar a um método específico, mas sim aos princípios.

Em breve algumas palestras e entrevistas estarão online no site do infoq, no blog da Caelum e por aqui.

Como empresa de treinamento é fundamental para nós tentarmos novos caminhos antecipadamente e esses 2 anos de mudanças, idas e vindas de scrum e lean, lean e scrum, além da onipresença de práticas do xp, é o que faz tudo valer a pena.

A seguir, algumas conversas rápidas com o Rafael Rosa, Lucas Cavalcanti e Philip Calçado durante o evento:

Restrições são boas mas restrições são ruins

24 de junho de 2010

Junto com a Cecilia Fernandes, semana passada tive a oportunidade de apresentar nossa experiência com lean, o que aprendemos, as dificuldades e as vantagens.

A idéia foi demonstrar como as restrições eram vistas muito tempo atrás no desenvolvimento de software, como quebramos ela ao criar nossos próprios métodos “unified”, como adotamos agile através de xp e scrum e quebramos essas restrições novamente através de Lean. O ponto chave está na regra de que agilidade se baseia na inspeção e adaptação para atingir um objetivo, inclusive do próprio método.

No espírito da noite ágil, proposta pelo André Pantalião, a realidade de algumas equipes foram demonstradas e discutidas, junto com suas visões e problemas. Foi uma ótima oportunidade para muita troca de informações e discussão sobre os assuntos.

Em breve teremos outro encontro da noite ágil em São Paulo, anunciaremos nas listas de agile e no meu twitter.

Dois vídeos já estão disponíveis, “Restrições são boas mas restrições são ruins” e “O papel de QA em equipes ágeis”, incluindo as sessões de discussões e conversas logo após as mesmas:

Em breve teremos as outras duas apresentações online também.

Post no blog da caelum: evite tantas reuniões

28 de abril de 2010

Continuando a série de problemas práticos encontrados na maneira de
pensar quando adotamos metodologias ágeis, uma situação que afeta
muito a produtividade de Product Owners e Scrum Masters (ou
líderes/papéis similares em qualquer metodologia) é a falta de
produtividade dos dois devido a quantidade de projetos que lidam.

Este post que escrevi está no blog da Caelum.

Líderança: permitindo o crescimento de sua equipe

23 de março de 2010

O que significa ‘liderar’?

A palavra liderar vem de levar e em contextos diferentes durante a história, apresentou maneiras diferentes de se “levar” algo a algum lugar. Generais levavam seu exército e, portanto, eram seus líderes. E no desenvolvimento de software, quem lidera sua equipe?

Meus desenvolvedores não tem vontade de se desenvolver

Uma realidade triste que encontramos no mercado é o caso onde os desenvolvedores não tem interesse em se desenvolver. Não sentem vontade de crescer.

E muitas vezes os líderes se questionam da qualidade de seus desenvolvedores, afinal, eles forneceram a tecnologia e o espaço para eles aprenderem. O líder deu o queijo e a faca na mão de sua equipe, que não fez nada.

O que é liderar desenvolvedores

Vindo de uma família de educadores onde pai, mãe, avó (entre outros) foram professores, pedagogos, padres etc, senti desde cedo as dificuldades de permitir o crescimento de alguém.

No mundo da educação, que envolve o desenvolvimento dos indivíduos, ser um professor, um líder, não é dar a ferramenta ou ensinar o meio.

Ensinar é deixar claro a necessidade.

Como líder, não quero dar o queijo nem a faca para minha equipe. Quero ensiná-los a ter fome.

Como desenvolvedor, não quero queijo, nem faca, quero ter fome. Sem fome, não faço nada.

Ainda mais em uma época onde informações e ferramentas são abundantes e a memória externa (internet, pen drives e afins) é mais prática que a nossa memória interna, não precisamos um “líder” que saiba o que é melhor fazer, e que me mostre o caminho, precisamos de um líder que nos dê paixão para fazer.

Ensino

Essa tem sido a base do nosso método de ensino na área de desenvolvimento de software e agilidade, que tem mostrado resultados com o passar do tempo. Ensinar os alunos a terem vontade é muito mais valioso do que ensiná-los a usar uma ferramenta qualquer.

A ferramenta somos capazes de aprender praticando, mas o interesse surge pois outra pessoa nos incitou.

Interesses distintos

Na prática, não adianta escolher como líder de seus desenvolvedores alguém cujo pensamento difere muito dos mesmos, a não ser que o carisma dele seja suficientemente encantador para conquistá-los. Sendo curto, não adianta colocar um PO com foco forte ao ROI e carisma zero para liderar uma equipe de desenvolvedores motivada a aprender a utilizar tecnologia de ponta.

Um PO líder poderia levar a equipe a um resultado, mas não serve como modelo para crescimento da mesma, não lidera a mesma para um aumento de produtividade, qualidade ou motivação.

Interesses distintos e baixo carisma não o fazem ser seguido – e muitas vezes o faz ser odiado. É fácil encontrar equipes onde o líder tem pensamento diferente e carisma baixo entre seus colegas e, por vezes, ser visto como inimigo dos desenvolvedores.

Encontrar alguém que saiba lidar com seres humanos, além de seguir o caminho que sua empresa deseja trilhar, é fator fundamental para o sucesso de seu líder.

Resumindo

Liderar não é saber o que é melhor, conhecer mais ou mandar, não é coordenar o trabalho, não é dizer o que dá valor, mas ensinar alguém a ter fome.

Ser, na visão da equipe, um modelo de trabalho a seguir.

Filtros REST em Rails e Java

18 de março de 2010

Para aqueles que gostariam de ver somente o conteúdo relativo as notícias de gerenciamento ágil, assinem o feed da categoria agile.

Para quem gostaria de assinar o feed completo, utilize o feed principal.

Muitas aplicações web possuem páginas de relatórios com campos para filtragem. O exemplo mais famoso é o caso onde o usuário pode configurar a data inicial e final para filtragem de dados.

FIltragem de dados

Mas o que acontece quando o usuário clica em qualquer link desse relatório, ou de relatórios consecutivos que aparecem após o mesmo? A data se perde. Em situações genéricas, o filtro se perde.

Vou exemplificar três maneiras de implementar tal funcionalidade.

Armazenar na sessão

É muito comum ver aplicações onde na primeira tela somos responsáveis por escolher, por exemplo, com qual unidade, centro de custo ou contrato desejamos trabalhar e, a partir de então, com tal valor armazenado na sessão no lado do servidor, temos acesso a URIs como http://www.projeto.com.br/clientes que retornaria a lista de clientes de uma unidade.

O que acontece se desejo trabalhar com clientes de duas unidades ao mesmo tempo, em abas distintas? Tenho que mudar de unidade a cada clique que executo com clientes de unidades diferentes.

Além disso, caches públicos como proxies entre o servidor e o cliente não terão o mesmo ganho de desempenho com URIs identificadoras de recursos reais.

O load-balancing também se torna custoso pois a sessão fica presa a uma máquina ou deve ser replicada em determinados momentos.

Tudo isso acontece pois sua aplicação é stateful, quebrando uma das regras da arquitetura REST.

O escopo flash é uma solução que cai nessa categoria.

Parâmetros do request

Outra solução é quando as características do filtro são passadas por parâmetros em uma URI do acessada através de GET.

parametros get

Nesse caso, podemos sobrescrever o método utilizado para definição de links para sempre adicionar os parâmetros de filtagem (url-rewriting):


  # remembers the starting and end date on all links
  def url_for(options = {})
    options[:start_date] = params[:start_date]
    options[:end_date] = params[:end_date]
    super(options)
  end

  public String urlFor(Class resource, String method) {
     return "/" + resource.getName() + "&start_date=" + params("start_date") + ...;
  }

Note que em ambos os casos é possível criar um componente que decide se o parâmetro de filtragem deve ou não ser adicionado.

Com um único método (monkey patch no Rails ou definição de tag no Java) somos capazes de resolver o problema em todos os links de um sistema.

Note que com essa abordagem, não existem os problemas de sessão apresentados anteriormente.

Armazenar um cookie no client

Aqui, como na solução baseada em sessões, existe o problema do trabalho em unidades distintas em diversas abas.

Uma vez que o cookie registrou informações relativas ao estado do cliente no processo definido no servidor, as próximas requisições irão levar em consideração tal informação, em todas as abas.

Novamente perdemos escalabilidade e, se usado em conjunto com sessões, temos um fator a mais negativo no load balancing.

REST

A segunda solução é a única que se aproxima mais de uma arquitetura REST: o servidor não mantém estado e a URI identifica um recurso, onde, por exemplo, open search pode ser utilizado para o sistema de filtragem.

O segredo está em deixar o cliente através de recursos identificados por URIs, ser guiado pelo servidor, e nenhum dos dois armazenem informações relativas ao estado atual de um processo. Os recursos e seus links ditam o processo (HATEOAS).

Note que de todas as soluções, ela foi a mais simples de trabalhar e com mais vantagens.

Além disso, não foram usados cookies que quebram a transparência para layers intermediários.

Fuja de cookies e de sessões, viva uma vida mais rest.

Pontos de bugs contam na velocidade?

15 de março de 2010

Após definir um método objetivo de avaliação de valor para histórias técnicas, onde defendo que qualquer história técnica de tamanho razoável pode ser descrita como algo que agrega valor ao produto; o Alex da Locaweb levantou outra dúvida clássica que surge no workshop de POs: corrigir bugs possui algum valor ou conta na velocidade da equipe?

Não

A abordagem tradicional por equipes que adotam Scrum é de definir que a correção bugs não são pontuados e não contam na velocidade. Ferramentas de controle de sprint valorizam esse tipo de abordagem.

O pivotal pode ser configurado para contabilizar, mas não é recomendado pela ferramenta.

O gráfico de velocidade reflete a esperança de quanto valor em funcionalidades novas e modificações a equipe entrega.

A desvantagem está no momento da definição de um sprint backlog, que os desenvolvedores não sabem se atenderão ou não a média por causa dos bugs que entram.

Exemplo prático: se sua empresa possui um legado com grande número de chamados atendidos pela equipe, é comum se desmotivarem, pois entregam poucos pontos. Grande parte do esforço vai para corrigir bugs – sem valor. Como as metodologias ágeis dizem, o problema da qualidade de código legada grita.

Nesse caso, sugiro separar um número de bugs a serem corrigidos para que seu produto não fique parado no tempo, somente corrigindo débito técnico. Algo comum é definir uma hora por dia no início/final do expediente para ser gasto com bugs e chamadas.
O importante é adotar alguma prática para reverter a situação!

Sim

Ao definir que um bug possui “X” de valor, o time sabe quanto consegue uma previsão, por sprint, do quanto pode se comprometer, agrupando bugs e histórias de uma só maneira.

A desvantagem: ao medir o valor de histórias entregue, o gráfico indica uma falsa noção de velocidade de histórias novas.

Note que a velocidade entregue é real, mas indica quantos bugs e histórias novas sua equipe é capaz de entregar; não somente histórias.

Revezar entre as abordagens?

Os dois métodos apresentam uma velocidade média que pode ser utilizada enquanto aquela abordagem permanecer, o mais importante é não mudar de abordagem e desejar manter tal métrica como real, pois não é.

Parcialmente

Uma solução intermediária está em contabilizar os pontos dos bugs no momento de estimar o que será comprometido e não contabilizá-los no momento de dizer a velocidade para o cliente.

A métrica diz agora o quanto o cliente espera receber de valor de histórias e a equipe sabe quantos bugs espera corrigir.

Nessa situação adotamos, sem perceber, duas pontuações diferentes, mas com a desvantagem que a maioria das ferramentas online não são capazes de tratar.

Mais uma abordagem: dois tipos de pontuação

Cerca de dois anos atrás em uma conversa com o Alexandre Magno, lembro de termos comentado da diferença de valor e dificuldade.

Enquanto muitos projetos conseguem sobreviver com uma única medida, em produtos com entregas contínuas (desculpe pelo uso da palavra produto aqui), uma opção é manter uma medida de valor, que o Product Owner julga e outra que de dificuldade que a equipe define.

A equipe sabe quanto espera entregar em histórias e bugs e o PO o quanto espera receber de valor de histórias, de bugs ou de ambos. O melhor dos dois mundos.

O custo disso está no pouco suporte encontrado por ferramentas de visualização e controle de iterações.

Com isso, o PO coleciona com o passar do tempo, estatísticas em relação ao valor de uma história/bug e sua dificuldade esperada.

Lean/Kanban

Em “projetos de longa duração”, juntando a prática de duas medidas e Lean/Kanban, conseguimos gerar estatísticas e calcular o tempo esperado para a enésima história do backlog entrar em produção, em dias esperados:

Dn = Somatoria(de 1 ate n) Esperança(Valor, DificuldadeEsperada(Valor))

Todas as contas são baseadas em estatísticas e dão previsões. Como qualquer média, existe um desvio padrão e uma amostra mínima que consideradas, permitem alcançar uma margem de erro desejada.

A mesma média pode ser alcançada, com um cálculo um pouco mais complexo, em processos baseados em sprints.

E você, como está lidando com bugs em seus projetos?

Tarefas técnicas possuem valor para o product owner?

9 de março de 2010

Na última turma de Agile e Scrum que ministrei, assim como nos diversos projetos que atuei desde 2005 com alguma metodologia ágil (xp, scrum ou lean), a questão das tarefas técnicas e seu valor para o cliente sempre apareçe.

Sonhando sobre o assunto, como de costume, encontrei uma resposta mais objetiva, menos subjetiva do que a abordagem tradicional, o clássico sim ou não.

O objetivo do PO

Como PO, o mais importante é a entrega de um produto que adicione valor ao que meu cliente utilizará, permitindo ganhar mercado contra meus concorrentes ou cobrar um valor mais alto pelo meu produto ou serviço.

Toda e qualquer história que não tenha como resultado final – direto ou indireto – aumentar o retorno do produto para minha empresa não possui valor.

E é esse o conceito objetivo que utilizamos na hora de aceitar e priorizar histórias técnicas: se ela não permite um retorno nesse instante ao meu produto, ela pode ser postergada.

Visto o último post que indica a importância da priorização adequada em relação ao retorno ganho, a execução de histórias técnicas sem retorno ao negócio poderiam atrasar ainda mais o sucesso do último.

Exemplo 1: Requisitos não funcionais

Quando tratamos de requisitos não funcionais, como por exemplo escalabilidade, foque em objetivos claros. Exemplificando, se os seus desenvolvedores indicam a necessidade de migrar seu banco de dados relacional para uma estrutura baseada em documentos pois o mesmo “agüenta mais usuários”, peça uma meta mais objetiva.

Primeiramente, a necessidade de atender mais usuários deve surgir de seus clientes, reclamando por mais performance em picos de uso, ou de você mesmo – prevendo um aumento de seus clientes em uma futura propraganda do sistema, por exemplo.

Supondo que o pedido surgiu de uma necessidade do produto, agora está na hora dos desenvolvedores criarem um spike – uma experiência para medir o possível sucesso de tal abordagem – e então retornarem com uma média esperada de melhora na escalabilidade do sistema (ou em outro requisito não funcional qualquer).

Tanto o spike, quanto a execução da tarefa técnica, com uma avaliação objetiva de seu sucesso (i.e. atender a X page views por segundo, respondendo em menos de 5 segundos), são histórias para seu backlog, pois ambas agregam valor a seu produto: se você não executá-las, seus possíveis e atuais clientes migrarão para os concorrentes.

Exemplo 2: Outras histórias técnicas

Por vezes as histórias técnicas que surgem não estão ligadas a requisitos não funcionais. Um exemplo é a instalação de um servidor de homologação e processo de homologação e deploy contínuo no estilo devops, fugindo do estilo tradicional, menos ágil, de operações. O que fazer?

Novamente, a equipe de desenvolvimento deve mostrar para o PO que tal história possui valor, e o PO priorizar de acordo com o valor mostrado.

O argumento a ser utilizado, no exemplo acima, estaria relacionado a velocidade de entrega de valor. Se a média dos últimos sprints tem sido de 20 pontos devido a bugs que são encontrados somente em produção, pois a máquina dos devs e de homologação está muito diferente das configurações reais, deixe claro que essa média poderá aumentar, uma vez que os bugs invalidadores de história serão encontrados antes e, com o passar dos sprints, X pontos que são utilizados agora para implementar tal processo serão retornados.

Existe valor na história técnica?

Em suma, histórias técnicas podem entrar no Backlog de maneira benéfica para seu produto, mas não se deve aceitar qualquer história. Ela deve ser julgada e priorizada de acordo com o valor que a mesma agrega ao seu negócio, e é responsabilidade dos desenvolvedores – seus clientes técnicos – mostrarem tal valor para o PO.

É importante ressaltar que qualquer tipo de debito técnico grande pode ser explicado de uma maneira que adicione valor ao produto, pois diminui a velocidade de entrega de retorno. Mas se o débito for muito pequeno, ele pode ser executado dentro do sprint, no dia a dia.

Exemplo 3: E na Caelum?

Em projetos internos da Caelum, temos uma preocupação que é incomum as empresas de desenvolvimento. A transferência de conhecimento entre instrutores e consultores tem que ser realçada, assim como o estudo de novas tecnologias e práticas de desenvolvimento.

Sendo assim, histórias envolvendo o aprendizado entregam valor direto para nosso negócio e acabamos por aceitá-las ou até mesmo colocá-las dentro do backlog.

Não se isole do resto de sua equipe

Os dois lados, PO priorizando valor, e desenvolvedores que priorizam qualidade, devem ser capazes de entender a necessidade do outro: não existe equipe auto gerenciável onde PO e desenvolvedores são inimigos, ambos fazem parte da mesma equipe.

PO, você anda colocando histórias de qualidade, spikes etc em seu backlog?

E você desenvolvedor, anda deixando claro para seu PO o retorno que o mesmo obtém ao priorizar tais tarefas e o comprometimento com um resultado objetivo?