terça-feira, 30 de novembro de 2010

Quase 10 anos de Ágil

bolo

O ágil está chegando no seu 10 º aniversário. Em fevereiro de 2001, um grupo de desenvolvedores se uniram para mudar o mundo de desenvolvimento de software e então nasceu o Manifesto Ágil.

Mas olhando para 10 anos atrás, qual foi impacto da cultura ágil na indústria de software?

A InfoWorld tem algumas citações interessantes de formadores de opinião do movimento ágil no começo.

Então, o que os profissionai

s têm a dizer sobre desenvolvimento ágil de software depois de 10 anos? Algumas respostas:

  • "Eu diria que transformou a indústria."  Ward Cunningham
  • "Teve um efeito bastante significativo sobre a indústria."  Scott Ambler
  • "Eu não tenho uma resposta do som da mordida sobre isso." Kent Beck
  • "Você ainda tem de fazê-lo bem… Você pode fazer ágil ruim. " Ian McLeod
  • "Algumas vezes os desenvolvedores podem chamar de práticas ágeis, quando elas realmente não são."  Damon Poole

Fonte:

“10 Years of Agile – Are We Better Yet? ” by agilescout.com

http://agilescout.com/10-years-of-agile-are-we-better-yet/

Ta-ta for now

segunda-feira, 29 de novembro de 2010

Dicas para os novos desenvolvedores ágeis

team

As dicas para os novos desenvolvedores ágeis foram quase todas extraídas do artigo “Confessions of A New Agile Developer” de Rahul Sharma e a última dica foi baseada no manifesto ágil.

O artigo “Confessions of A New Agile Developer” relata a trajetória de um desenvolvedor e sua equipe na migração da cultura waterfall para ágil. Adotando Scrum, XP e TDD. Onde é citado dificuldades e dicas para migração para ágil.

Algumas dicas para os novos desenvolvedores ágeis:

  • Entre em sintonia com tecnologias de mercado, especialmente ferramentas de testes como: JUnit, EasyMock, Fitnesse, Selenium e etc. Além disso as pessoas devem buscar  soluções melhores, novas formas de melhorias de processos, novas idéias de design e padrões para problemas recorrentes;
  • O livro “Practices of an Agile Developer” de Venkat Subramaniam e Andy Hunt é uma leitura obrigatória para os novos desenvolvedores ágeis;
  • Leituras recomendáveis: "Craftsman series” no site objectmentor.com e o livro “Clean Code” de Robert C. Martin. No começo você não dará prioridade, mas com passar do tempo ajudará bastante;
  • Esteja aberto para planejamentos ou discussões, as pessoas valorizam as suas sugestões. Expresse a sua opinião ou peça ajuda se for necessário, você é uma das partes interessadas no projeto;
  • Os testes não servem apenas para cobertura de código ou medir a qualidade. Eles também oferecem documentação;
  • Automatize tudo no início do projeto;
  • E o mais importante, incorpore o manifesto ágil e os princípios por trás do manifesto. Não pratique uma cultura sem conhecer os princípios, pois vai acabar se tornando algo mecanizado e sem possibilidade de melhoramento.

Fonte:

Artigo “Confessions of A New Agile Developer” by Rahul Sharma:

http://www.infoq.com/articles/agile-confessions-sharma

“Manifesto for Agile Software Development”:

http://agilemanifesto.org/

Ta-ta for now

PO deve participar da reunião diária?

direcao

Sabemos que PO faz parte da equipe Scrum. Se o PO participa da reunião diária tentando redefinir objetivo e escopo, realmente não é uma boa idéia.

No entanto, se o PO realmente respeita a auto-organização da equipe, a sua participação na reunião diária mostrará diariamente a equipe se esta andando na direção certa. Conseqüentemente, evitando o desperdício de ter andando em uma direção errada e ver somente no Review.

Essa participação diária do PO orientando a equipe na direção certa, resulta numa cadência de trabalho hiper-adaptativo. Esse tipo de equipe de alto desempenho depende da capacidade do PO resistir à tentação de agir como um gerente de projeto tradicional.

Fonte:

“Should the Product Owner Attend Daily Scrums?”:

http://agilemethodology.org/should-the-product-owner-attend-daily-scrums/

Ta-ta for now

domingo, 28 de novembro de 2010

Eliminando os Desperdícios

waste

O desperdício poderia ser definido como algo que não acrescenta valor ao cliente. Qualquer coisa que não seja necessária é desperdício: recurso desnecessário, funcionalidade desnecessária, comunicação ruim e burocracia.

Para reduzir o desperdício é necessário primeiro um processo de identificação. Geralmente o gerente de projeto ou função similar é o identificador do desperdício. Sendo que os desperdícios são códigos abandonados, atraso da equipe por causa da dependência de outra e funcionalidades desnecessárias.

Toda vez que desperdício é identificado, deverá ser eliminado. O gerente de projeto estabelece um procedimento para aprender e melhorar com o desperdício. O processo de eliminação de todo desperdício deverá ser constante, ou seja, repetido até que cada processo seja tão eficiente quanto possível.

Fonte:

“Lean Software Development” by  Ali Mushtaq:

http://technology.ezinemark.com/lean-software-development-7d2c9a7476e.html

Ta-ta for now

sábado, 27 de novembro de 2010

Scrum Master

superman.jpg]

O Scrum Master é um facilitador para o PO e a equipe. Sendo que não tem autoridade administrativa e não pode comprometer o trabalho em nome da equipe.

O melhor Scrum Master é um jogador da equipe de verdade, que tem a satisfação tanto de facilitar o sucesso da equipe como seu próprio.

O Scrum master deve ser aberto ao entregar o controle para o PO e a equipe, afinal a equipe é auto-organizável. Por causa disso, o gerente de projeto tradicional não costuma fazer um grande Scrum Master.

Mas afinal, o que faz um Scrum Master? O Scrum Master é um removedor dos obstáculos que atrapalham a equipe em busca da meta da iteração. Resumindo, o Scrum Master é um facilitador da produtividade.

Por exemplo, caso estrague a máquina de um desenvolvedor da equipe, será o Scrum Master que providenciará uma nova máquina junto ao suporte da empresa. Na realidade o Scrum Master enfrentará cenários infinitos.

Mas o trabalho do Scrum Master não é apenas voltado para equipe, ele também é responsável por ajudar o PO a maximizar a produtividade. Podendo ajudar a manter o backlog e plano de liberação, assim mantendo o PO informado sobre os êxitos da equipe.

Fonte:

“The ScrumMaster Role”:

http://scrummethodology.com/the-scrummaster-role/

Ta-ta for now

terça-feira, 23 de novembro de 2010

Um Exemplo de BDD com Easyb no Eclipse

bdd

O desenvolvimento dirigido a comportamento(BDD) foca no comportamento do sistema. Sendo que desenvolvimento é de fora para dentro. Iniciando de fora com identificação dos resultados do negócio e então descendo para o conjunto de recursos que permita atingir os resultados. Cada recurso é capturado como uma estória, que define o âmbito do recurso juntamente com os seus critérios de aceitação.

Estrutura da Estória

Título (descrição da estória)

Como [pessoa]

Eu gostaria de  [funcionalidade]

Para que [benefícios]

Exemplo:

Titulo: Calculadora Básica

Como um usuário da calculadora

Eu gostaria de fazer as quatro operações básicas

Para que erros não atrapalhem os demais cálculos

Estrutura do Cenário

Cenário: Título

Dado algum contexto inicial,

E mais de contexto,

Quando um evento ocorre,

Então verifique alguns resultados,

E outros resultados,

Exemplo:

Cenário: Multiplicação

Dado Que tenho uma calculadora

Quando Eu entro com 3 e 5

E Clico =

Então Então vejo 15

A estória deve ser o produto de uma conversa que envolve o cliente, a equipe e demais participantes do projeto.

Exemplo de um Cenário Usando Easyb

Easyb é um framework de desenvolvimento dirigido a comportamento para a plataforma Java(groovy). Usei na IDE Eclipse Galileu e a linguagem dinâmica groovy.

O cenário Multiplicacao.story:

import bddcalculadora.Calculadora

scenario "Multiplicação", {

given "Que tenho uma calculadora", {

calculadora = new Calculadora()

}

when "Eu entro com 3 e 5", {

calculadora.valorA=3

calculadora.valorB=5

}

and "Clico =", {

resultado = calculadora.multiplicar();

}

then "Então vejo 15", {

resultado.shouldBe 15

}

}

Saída do cenário Multiplicação:

clip_image002

A Estrutura do projeto calculadora:

clip_image003

Para rodar easyb no eclipse a configuração pode ser via plug-in, maven e ant:

http://www.easyb.org/running.html#eclipse

No projeto calculadora estou usando o ant.

Veja que as lib’s necessárias são três e estão disponíveis no link:

http://www.easyb.org/index.html

Um artigo muito bom que foi minha inspiração para usar easyb: “BDD - Behavior-Driven Development!” de Rodrigo Branas http://onca.st/blog/?p=953

Vídeo sobre BDD em java usando easyb:

 

Fonte:

“BDD - Behavior-Driven Development!” by Rodrigo Branas:

http://onca.st/blog/?p=953

“What's in a Story?” by

[This article has been translated into Korean by HongJoo Lee .]!:

http://blog.dannorth.net/whats-in-a-story/

“Easyb”:

http://www.easyb.org/index.html

Vídeo “BDD in Java with easyb”

www.youtube.com/watch?v=GIqA4c-RvFQ

Ta-ta for now

quinta-feira, 18 de novembro de 2010

segunda-feira, 15 de novembro de 2010

12 Exercícios para Buscar a Retrospectiva

flip-chart 

Durante Agile Open Belgium, Nick Oostvogels, demonstrou uma sessão de exercícios para buscar a retrospectiva, focando as melhorias e evitando uma possível reunião chata.

O objetivo é demonstrar que as melhorias propostas na retrospectiva serão realizadas.

Os 12 exercícios para buscar a retrospectiva:

1. Os membros da equipe respondem as seguintes perguntas no final do Sprint:

    • O que foi bom?
    • O que pode ser melhorado?

    No final, teremos uma lista de melhorias. Através desta lista serão priorizadas as melhorias com a votação da equipe.

    2. Criando uma linha do tempo

    • Este exercício é feito antes da busca por melhorias. Ele é usado para fazer toda a equipe concentrar-se no mesmo período e voltar para a mentalidade do Sprint.

      • O que aconteceu do inicio até final do Sprint?
      • Qual prazo?
      • O que trabalhamos?

      3. Concentre-se em um problema

      Caso algo importante realmente deu errado, você pode querer concentrar-se toda a retrospectiva sobre a definição de ações para impedir que isso aconteça novamente.

      4. A estrela do mar

      Uma variação do exercício 1. Usamos cincos categorias:

        • Começar a fazer;
        • Parar de fazer;
        • Continuar fazendo;
        • Mais;
        • Menos.

        As sutis diferenças entre as categorias de ajudar a equipe a pensar de forma diferente.

        5. Desenhe uma linha de tendência emocional

        Você precisa de um cronograma para começar. Cada membro da equipe desenha uma linha de tendência, que representam os seus sentimentos durante o Sprint.

        A linha para cima significa que membro da equipe esta feliz. A linha para baixo significa que membro da equipe esta frustrado.

        6. Esvazie a caixa de entrada

        Caso sua equipe tem dificuldade para lembrar-se de coisas no final do Sprint, você poderá pendurar uma caixa de cartão na sala da equipe. Isto é usado para coletar idéias para as melhorias.

        Na retrospectiva, a caixa é esvaziada e cada nota é discutida e as ações são definidas.

        7. A dança da linha

        Quando sua equipe está dividida entre duas opções para melhorar, você pode usar essa técnica para chegar a uma decisão: Desenhar uma linha no chão e marcar uma extremidade com a opção n º 1 e marcar a outra extremidade com a opção n º 2.

        Em seguida, pedir para cada membro da equipe escolher o lugar na linha que representa a sua preferência.

        A opção da maioria é a escolhida.

        8. Check-in

        No início da retrospectiva, escrever uma pergunta em um flip chart e pedir para cada membro da equipe responder.

        Isso ajuda a quebrar a timidez da equipe.

        9. Uma sondagem

        Se você quiser ter uma idéia sobre os sentimentos da equipe em um determinado tópico. Por exemplo, a qualidade do código, você poderá usar uma sondagem anônima.

        Primeiro anote a escala em um flip chart. Ex. 1 = muito ruim, 4 = muito bom.

        Cada membro da equipe expressa seu sentimento sobre assunto através do post-it. Dobre-o e solte-o em um chapéu.

        A soma de todos os números é dividida pelo número de participantes. O resultado será um número entre 1 e 4.

        Isso lhe dá o sentimento geral sobre a qualidade do código no momento. Você pode repetir a mesma pesquisa depois de algum tempo, para analisar a evolução.

        10. Dar flores

        Cada membro da equipe recebe uma flor e poderá dar a um colega por admiração ao seu trabalho. Uma ótima forma de unir a equipe.

        A equipe pode trocar a flor por outra premiação. Por exemplo, premiar o trabalho do colega com bombom.

        11. Atribuir pontos de ação

        Antes de deixar a reunião, fazer com que todos os pontos de ação tenham seus respectivos donos. Os pontos de ação devem ser visíveis e priorizados.

        12. Convidar o cliente

        Se cliente está envolvido intimamente com uma equipe, convidá-lo para a retrospectiva possivelmente acrescentará valor.

        Afinal, estamos focando na melhoria de todo o fluxo de valor, não somente no trabalho da equipe.

        Fonte:

        “12 retrospective exercises” by Nick Oostvogels

        http://noostvog.wordpress.com/2010/06/17/12-retrospective-exercises/

        Ta-ta for now

        terça-feira, 2 de novembro de 2010

        Ritmo de Trabalho Semanal Sustentável

        zebra

        O ritmo de trabalho semanal sustentável evita o cansaço mental e físico das pessoas. É o chamado ritmo inteligente de trabalho.

        Cenário do ritmo de trabalho não sustentável na TI

        Para entregar um produto de software no prazo ou diminuir o atraso na entrega, geralmente os integrantes da equipe fazem horas extras, viram madrugadas e trabalham nos finais de semanas. Resumindo, um ritmo intenso de trabalho, que geralmente esta acima do limite da equipe.

        Efeitos colaterais do ritmo de trabalho não sustentável na TI

        Desenvolver um produto de software com erros é um efeito colateral do ritmo de trabalho não sustentável. O cansaço, o sono, a falta de atenção conduz a desenvolver um software com erros.

        O outro efeito colateral é uma equipe doente. Uma equipe é composta por seres humanos, quem tem necessidades básicas como repousar e comer.

        E como trabalho semanal sustentável poderá ajudar no desenvolvimento do produto de software?

        O trabalho semanal sustentável é forma inteligente de trabalho que evita déficit de atenção da pessoa por causa do cansaço.

        Se for mantido um ritmo de trabalho semanal sustentável para equipe, os erros tendem a diminuir no desenvolvimento do produto de software. Outra tendência é manter um ritmo quase constante de desenvolvimento do produto de software, isso acontece porque equipe esta no seu limite sustentável. Evitando faltas dos integrantes da equipe por causa de doenças ligadas ao cansaço. 

        O ritmo de trabalho sustentável é mesmo trabalho energizado do extreme programming.

        Fonte:

        “Livro Scrum e XP direto das Trincheiras” by Henrik Kniberg

        http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches

        “Extreme Programming” by  Vinícius Manhães Teles

        http://improveit.com.br/xp

        Ta-ta for now

        segunda-feira, 1 de novembro de 2010

        Integração Contínua

        ic2

        O que é integração contínua?

        É a integração do trabalho da equipe frequentemente ao dia. Sendo que teremos ao final de cada integração a garantia de código consistente.

        Segundo Martim Fowler, a integração contínua é:

        “Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho freqüentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.” Martin Fowler

        O processo da integração contínua

        • Executar freqüentemente: Build automático, testes, analise estática de código, estimativas e métricas.
        • Disponibilizar o último executável;
        • Informar a equipe sobre o estado atual do projeto. Isso significa que a cada build e bateria de testes, a equipe será informada automaticamente se algum teste quebrar. Assim, a equipe poderá providenciar o conserto o mais rápido possível do problema.

        Dicas de ferramentas para integração contínua

        Fonte:

        “Integração continua com Hudson” by  Leandro de Morais Nunes

        http://www.slideshare.net/LeandroNunes85/integrao-contnua-com-hudson-2036503

        “Continuous Integration” by por Martin Fowler

        http://www.martinfowler.com/articles/continuousIntegration.html

        Ta-ta for now