quinta-feira, 16 de dezembro de 2010

Apoio ao Manifesto do Software Artesanal

artesanato

O Cantinho do Agile assinou e esta apoiando o manifesto do software artesanal. Podemos dizer que o desenvolvimento de software é um meio termo entre arte e ciências exatas, ou seja, desenvolvimento de software é mais próximo do artesanato.

O aspirante artesão busca elevar o nível de desenvolvimento de software na prática e ajuda a comunidade aprender sobre o desenvolvimento de software artesanal.

Os valores do manifesto do software artesanal são:

“Não só o trabalho de software, mas também software bem trabalhado

Não só responder à mudança, mas também constante agregação de valor

Não somente os indivíduos e interações, mas também uma comunidade de profissionais

Não só a colaboração do cliente, mas também parcerias produtivas”

Na busca dos itens do lado esquerdo, encontramos itens indispensáveis do lado direito.

Software bem trabalhado, agregação de valor, comunidade de profissionais e parcerias produtivas buscam o melhoramento do desenvolvedor de software e do processo de desenvolvimento do produto de software. Conseqüentemente o cliente receberá um produto com mais valor e qualidade.

Sendo assim, o manifesto do software artesanal contribui para cultura ágil de desenvolvimento de software.  E se analisarmos o manifesto de software artesanal, notamos uma continuação do manifesto ágil.

Desenvolvedor, tome uma atitude para ser um desenvolvedor melhor, seja um artesão de software.

Obs.: A autora, representada por Nina Rosa Madeira, assinou o manifesto do software artesanal.

Fonte:

“Manifesto for Software Craftsmanship”:

http://scmanifesto.heroku.com/

Ta-ta for now

quarta-feira, 15 de dezembro de 2010

Os Quatros Objetivos do Manifesto Ágil

goal

Os quatros objetivos do manifesto ágil:

Objetivo: Indivíduos e interação entre eles mais que processos e ferramentas:

  • Cliente e desenvolvedores devem trabalhar juntos diariamente no projeto;
  • Conversa face a face é método mais eficaz para transmitir informações para dentro da equipe;
  • Todos envolvidos (equipe e cliente) devem manter um ritmo sustentável;
  • As melhores arquiteturas, requisitos e projetos nascem de equipes auto-organizáveis.

Objetivo: Software funcionando mais importante que documentação abrangente:

  • Maior prioridade é satisfazer o cliente com entrega antecipada e contínua de software com valor;
  • Entregar software funcionando freqüentemente em poucas semanas;
  • Software de trabalho é a medida primária de progresso;
  • Atenção contínua a excelência técnica e bom design melhoram o software;
  • Soluções simples.

Objetivo: Colaboração com o cliente mais que negociação de contratos:

  • O cliente é um membro da equipe;
  • Cliente e desenvolvedores devem trabalhar juntos diariamente ao longo do projeto.

Objetivo: Responder a mudanças mais que seguir um plano:

  • A cultura ágil se adapta a mudança;
  • Em intervalos regulares a equipe reflete sobre como se tornar mais eficaz, fazendo os ajustes necessários.

O que significa os princípios do manifesto ágil no processo de desenvolvimento?

  • Indivíduos e interação entre eles mais que processos e ferramentas: a equipe de desenvolvimento tem o controle do processo de desenvolvimento, plataformas e metodologia;
  • Software funcionando mais importante que documentação abrangente: Dar ao cliente o acesso permanente ao sistema, que é atualizado com freqüência;
  • Colaboração do cliente mais que negociação de contrato: Coloque o cliente na sua equipe. As histórias dos clientes, interações curtas com cliente e verifique se a aplicação está sempre acessível ao cliente;
  • Responder a mudanças mais que seguir um plano: Abrace a causa da mudança durante o processo de desenvolvimento de software. Ela irá ocorrer estando preparando ou não.

E como começar?

A integração contínua tem rápido ROI:

  • Inicie com controle de versão;
  • Automatização do deploy;
  • Testes automatizados.

Investir em pessoas dá maior retorno de investimento (ROI):

  • Livros;
  • Conferências;
  • Treinamentos;
  • Ambiente de trabalho bom e ritmo sustentável de trabalho.

Fonte:

http://www.manifestoagil.com.br/principios.html

e

http://www.evenamonkey.com/AgileIntroduction

Ta-ta for now

sábado, 11 de dezembro de 2010

Algumas semelhanças entre Scrum e Kanban

gemeos

Baseado no artigo “What is Best, Scrum or Kanban?” de Tomas Björkholm, relatarei algumas semelhanças entre Scrum e Kanban:

  • Priorização (opcional para Kanban);
  • Auto-organização da equipe: É quando a equipe sabe como resolver os problemas, remover obstáculos e otimizar seu processo;
  • Transparência: É mostrar o que você fez, estado atual e que fará na próxima etapa;
  • Inspecão e adaptação: É melhorar o seu produto e processo baseado em fatos;
  • Puxar o trabalho;
  • Boa comunicação e colaboração.

Fonte:

“What is Best, Scrum or Kanban?” by Tomas Björkholm:

http://www.agilejournal.com/articles/columns/column-articles/1737-what-is-best-scrum-or-kanban

Livro Kanban and Scrum - making the most of both  by Henrik Kniberg and Mattias Skarin:

http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf

Ta-ta for now

sexta-feira, 10 de dezembro de 2010

Apoio ao Manifesto da Refatoração

refactor

Pessoal, peço o apoio para o manifesto da refatoração. Pela causa de um código melhor e longa vida ao seu produto:

http://www.refactoringmanifesto.org/

Fonte:

http://www.refactoringmanifesto.org/

Ta-ta for now

segunda-feira, 6 de dezembro de 2010

O Papel do Analista de Negócios Ágil

ba

O papel do analista de negócios é facilitar a comunicação sobre o produto de software entre o cliente e a equipe. Tipicamente, o analista de negócios tem um grande conhecimento do produto de software em discussão e poderá extrair as funcionalidades exigidas pelo cliente. Sendo assim, a principal função do analista de negócios é facilitar a comunicação e a compreensão.

O analista de negócios ajudará também a traduzir as necessidades do cliente em uma linguagem mais técnica para os desenvolvedores.

A cultura ágil encoraja o analista de negócios a fazer a dissociação da amplitude da solução a partir da profundidade da solução, ou seja, usando metodologia ágil o analista escreverá requisitos dirigidos por iteração.  Isso significa que o cliente receberá valor a cada iteração (2 ou 3 semanas) e não precisará esperar meses ou anos para receber o produto de software finalizado, as vezes com vários problemas.

“The Agile Business Analyst” by Mike Cottmeyer, V. Lee Henson

http://www.infoq.com/articles/agile-business-analyst-role

Ta-ta for now

O Analista de Negócios e a Equipe Ágil

team

O analista de negócios é um membro da equipe ágil. Sendo que analista de negócios geralmente é convidado para facilitar a comunicação sobre o produto de software entre equipe e cliente. Suas principais funções são facilitação da comunicação e compreensão.

Outra função importante do analista de negócios é envolver a equipe na criação das especificações, ajudando a criar um ambiente de alta confiança e colaboração. O analista de negócios poderá ajudar a equipe: 

  • A focar nos objetivos da interação;
  • No entendimento dos requisitos em um baixo nível de detalhamento.

No caso do cliente desempenhar o papel de analista de negócios é necessário apoio de outro analista de negócios. Porque na realidade sabemos que um cliente não terá 100% do seu tempo disponível para a equipe e necessitará de um apoio na especificação das funcionalidades.

Caso o cliente não possa a participar do desenvolvimento do produto de software, o analista de negócios assume o papel de cliente proxy. Neste papel, o analista é convidado a entender as necessidades do cliente e a traduzir essas necessidades à equipe. Este modelo apresenta risco, porque o cliente não está diretamente envolvido com toda equipe. O analista de negócios poderá diminuir esse risco, através do incentivo ao cliente a participar do desenvolvimento do produto de software.

“The Agile Business Analyst” by Mike Cottmeyer, V. Lee Henson

http://www.infoq.com/articles/agile-business-analyst-role

Ta-ta for now

domingo, 5 de dezembro de 2010

Receita para o Fracasso de um Produto

pao mofado 

A lista a seguir são erros comuns na aplicação do Scrum. Todos eles influenciam negativamente no sucesso do produto:

  • Espalhar o papel do PO para várias pessoas;
  • Construir um produto que agrade a todos e tenha uma infinidade de recursos, ou seja, um produto comercializável ao máximo;
  • Dizer sim a todas as necessidades. Você não quer decepcionar os interessados e colocar em risco o sucesso do produto;
  • Capturar e detalhar todos os requisitos do backlog antes da primeira interação. Isso diminui os riscos e proporciona um planejamento eficiente;
  • Não se incomode com a priorização;
  • Não se preocupe com o feedback do cliente sobre o produto. Afinal, você sabe o que é melhor para seu cliente;
  • Domine o mercado na calada da noite e surpreenda os concorrentes e os clientes;
  • Quando surgir alguma necessidade, adicione mais recursos e corte qualidade. Os clientes adoram produtos complexos. Não se preocupe com débito técnico. Visualize como uma oportunidade para criar um novo produto para futuro;
  • O Scrum Master deve atuar como um gerente de projeto rígido, que faça a equipe trabalhar num ritmo duro. Ritmo sustentável é para os fracos.

Não siga a lista de erros acima, pois as conseqüências serão:

  • A criação de produtos inúteis para seus clientes;
  • E a falência do seu negócio.

Fonte:

Artigo “How to Create Products that Customers Hate” by Roman Pichler:

http://www.romanpichler.com/blog/agile-product-management/how-to-create-products-that-customers-hate/

Ta-ta for now

sexta-feira, 3 de dezembro de 2010

O Guia do gestor para adoção da metodologia ágil by Mike Cottmeyer

Mostra como as equipes trabalham juntas para entregarem os projetos mais complexos e portfólios. Mike vai expandir o conceito de equipe para incluir capacidades e mostrar como os recursos podem ser organizados para melhorar toda a cadeia de valor da empresa. Em cada etapa do processo de adoção, Mike irá mostrar como escolher as políticas, práticas e métricas que criam aprendizado e conduzem a mudança organizacional sustentável:

http://www.vimeo.com/10582725

Fonte:

“The Manager's Guide to Agile Adoption” by  Mike Cottmeyer:

http://www.vimeo.com/10582725

Ta-ta for now

quinta-feira, 2 de dezembro de 2010

Gerente 2.0

bernadinho

1) Estratégia: O Gerente 2.0 terá como alvo os valores e processos, como no Lean. Assim, o gerente focará em:

  • Eliminar o desperdício;
  • Estimular a qualidade em processos e sistemas;
  • Criar uma cultura de respeito para todas as pessoas;
  • Valor do cliente;
  • Melhorar o todo.

2) Liderança: O gerente poderá assumir a responsabilidade de organizar as pessoas, os recursos(financeiros), as entrevistas, os comentários e as avaliações. Também poderá realizar as tarefas de Coach ou Scrum Master, mas terá dificuldade de manter a confiança. No caso do Coach é melhor um profissional de fora da empresa, que possa analisar organização de forma neutra. Já o Scrum Master é aconselhável alguém da equipe, que conheça a equipe.

3) Operacional: As tarefas operacionais do Gerente 2.0 não diferem dos outros gerentes. No entanto, a comunicação tem valor importantíssimo para Gerente 2.0. Sendo assim, a escolha de uma ferramenta adequada é importante.

Em geral, o Gerente 2.0 será responsável pela criação de valores que estimulem as pessoas. Ele também será responsável pela aplicação da cultura ágil, ajudando a equipe na identificação das práticas adequadas.

Apesar da equipe ágil ser auto-organizável, não exclui o gerenciamento.

Fonte:

“Manager 2.0 - part 2” by AgileCollab:

http://www.agilecollab.com/manager-20-part-2

Ta-ta for now

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

        quarta-feira, 27 de outubro de 2010

        Mantenha seu código limpo como sua casa

        cozinha suja

        Resolvi escrever esse post para falar de código limpo (clean code).

        Já pensou uma casa tão suja e desorganizada que você não consegue entrar na cozinha ou pegar uma roupa no armário. Até diarista pediu aumento devido à bagunça.

        Um sistema cresce e seu código também. O crescimento sem cuidado leva a um código enorme (nada enxuto), não legível e bagunçado. O pesadelo dos desenvolvedores.

        O código deve ser limpo como sua casa. Limpezas frequentes são altamente recomendáveis.

        Sugestões para manter o código limpo:

        • Controle do tamanho dos métodos, funções, classes e sistemas;
        • Use nomes significativos para funções e métodos, evitando os comentários. Código com excesso de comentários não são legíveis;
        • Use nomes significativos nos testes unitários. Os testes unitários comentam os métodos que testam.
        • Teste de integração;
        • Trate exceções;
        • Construa um software para suportar concorrência. No ambiente web é importantíssimo;
        • Padronização de código e indentação para todas as equipes. Para indentação existem  IDE’s que fornecem recursos de formatação automática;
        • Regra do escoteiro: Deixe área do acampamento mais limpa do que quando você a encontrou. Para código a mesma regra: não limpe somente seu código, limpe dos outros também. Quando encontrar código ruim, melhore com os seguintes passos:
          • Testes unitários;
          • Refatorar;
          • Commit.

        Uma excelente leitura  é o livro “Clean Code” escrito por “Robert C. Martin”.

        Fonte:

        Dev in Sampa 2010 – Código Limpo – Hugo Corbucci (outro ângulo):

          Uma excelente leitura  é o livro “Clean Code” escrito por “Robert C. Martin”.

          Fonte:

          Dev in Sampa 2010 – Código Limpo – Hugo Corbucci (outro ângulo):

          http://www.blip.tv/file/4024593

          Bye see you next post

          sábado, 23 de outubro de 2010

          segunda-feira, 18 de outubro de 2010

          QA e Equipe Ágil

          testeranddeveloper

          Apesar do titulo do artigo demonstrar que QA é separado da equipe ágil, digo que idéia é inversa. Sabemos que uma equipe ágil é multidisciplinar e o papel do QA é importante para garantia de qualidade de teste.

          TDD e ATDD

          O TDD antecede o comportamento do código e O ATDD (Teste de Aceitação) antecede o comportamento do software (Webinar: O ciclo ATDD + TDD por Scrum Amazônia, Paulo Igor e Heitor Roriz).

          O QA achou que não tinha papel no Extreme Programming

          Em STAREAST 2008, numa palestra “Testing Lessons from Extreme Programmers, Elisabeth Hendrickson” os testadores diziam que no Extreme Programming (XP) não tinham um papel definido. A equipe XP praticava tanto TDD como ATDD de modo eficaz.

          Mais adiante veremos que o QA tem papel fundamental numa equipe ágil

          Por que é importante o QA numa equipe ágil?

          Os Analistas, projetistas e programadores usarão o TDD e o ATDD para desenvolver o produto.

          Porém a visão de um profissional de QA (Engenheiro e Analista de teste) ajudará a melhorar arquitetura e plano de caso de teste.

          Imagine apresentar para o cliente um teste de aceitação usando selenium (excelente software) e os resultados saírem na janela do JUnit numa IDE de desenvolvimento. Realmente não ficará apresentável para cliente, mas para garantir a qualidade  do produto dentro da equipe técnica tudo bem.

          O mais correto é a integração do código de teste de aceitação com uma ferramenta de gerenciamento de caso de teste, por exemplo, ferramenta Testlink. Esta ferramenta será responsável pela geração do relatório de resultado do teste de aceitação que será apresentado para cliente.

          Em suma, a união de analistas, projetistas, desenvolvedores e QA têm grau elevado de importância para desenvolvimento do produto orientado a teste com qualidade.

          O papel do QA no TDD

          tdd 

          É recomendável que QA participe dos testes unitários. Aprendendo e ajudando os demais membros da equipe ágil.

          O teste unitário antecede o comportamento do código, porém é focado na funcionalidade.

          O Teste de desempenho poderá aproveitar o teste unitário, um exemplo é uso do JUnit junto ao JUnitPerf. Podendo simular: usuários, interações e tempo.

          O Teste de desempenho é mais uma garantia de qualidade para toda equipe.

          O papel do QA no ATDD

          atdd

          Aqui o papel do QA é fundamental. Na elaboração de plano de caso de teste de aceitação, integração da ferramenta de teste de código (exemplo: selenium) com gerenciador de caso de teste.

          É necessário um plano de caso de teste para escrever o teste de aceitação no código, e ninguém melhor que QA para escrever plano de caso de teste.

          E QA será também apresentador do resultado do teste de aceitação para cliente.

          Eis a questão(Shakespeare):

          Do que adianta teste de aceitação sem um bom plano de caso de teste?

          Fonte:

          http://sembugs.blogspot.com/2010/10/integracao-selenium-e-testlink.html

          e

          Webinar O ciclo ATDD + TDD by Scrum Amazônia, Paulo Igor e Heitor Roriz:

          http://www.slideshare.net/Pigor/palestra-tddcompleta-5460534

          e

          video.google.com/videoplay?docid=-3903817398443328799#

          Bye see you next post

          domingo, 17 de outubro de 2010

          Teste de Aceitação no Eclipse IDE usando Selenium

          testing

          O ATDD nada mais é que o teste aceitação. Aqui no post foi criado um teste de aceitação via código usando Eclipse IDE Galileu, sem integração com Testlink ou outros. Apenas usamos Selenium RC(com api’s server e client) e JUnit 4. 

          O Teste foi feito no Blog Cantinho do Agile - label Agile:

          http://cantinhodoagile.blogspot.com/search/label/Agile/

          Foram testados textos e um link no post: Checklist para definição de feito.

          Api’s necessárias no Java Build Path do Eclipse IDE:

          javabuildpath

           

          selenium-server.jar 1.0.3

          selenium-java-client-driver-.jar 1.0.1

          Jdk 6

          JUnit 4.jar: Vem no Eclipse IDE Galileu.

          Código do teste de aceitação no blog Cantinho do Agile – label Agile:

          import junit.framework.TestCase;

          import org.junit.Test;
          import org.openqa.selenium.server.SeleniumServer;

          import com.thoughtworks.selenium.DefaultSelenium;
          import com.thoughtworks.selenium.Selenium;

          public class CantinhodoAgileTest extends TestCase {

              Selenium selenium;
              SeleniumServer servidor;

              public void setUp() throws Exception {
                  servidor = new SeleniumServer();
                  servidor.start();

                  selenium = new DefaultSelenium("localhost", 4444, "*firefox",
                          "http://cantinhodoagile.blogspot.com/search/label/Agile/");
                  selenium.start();
              }

              @Test
              public void testChecklistDefinicaoFeito() throws Exception {
                  selenium.open("/");
                  assertTrue(selenium.isTextPresent("Checklist para definição de feito"));
                  selenium.click("link=Checklist para definição de feito");
                  assertTrue(selenium
                          .isTextPresent("Os dez itens do checklist para definição de feito são:"));
              }

              public void tearDown() throws Exception {
                  selenium.stop();
                  servidor.stop();
              }

          }

          Note que servidor Selenium é iniciado e finalizado pelo código. Também temos a Classe Selenium(representada pelo objeto selenium) que é responsável pela realização das verificações junto ao JUnit.

          No exemplo o navegador web é Firefox e a porta 4444.

          Resultado do Teste de Aceitação:

          Comecei quebrando o teste até fazer passar e logo após fui melhorando:

          junit4 

           

          O teste foi apenas um simples exemplo de como fazer teste de aceitação no Eclipse IDE usando Selenium.

          Porém recomendo uma integração da equipe de analise e projeto com QA para elaboração de planos de casos de testes. E uma integração do código de teste de aceitação com uma ferramenta de gerenciamento de caso de teste e execução.

          Um bom exemplo seria integração do Selenium com Testlink. Dois excelentes artigos sobre integração de autoria de Elias Nogueira são:

           Integração Selenium e Testlink 

          ou

          Integração Selenium e Mantis

          Uma ferramenta de gerenciamento de caso de teste proporciona uma visualização amigável e de bom entendimento para o cliente do teste de aceitação. Por exemplo, com uso de relatório.

          Ferramentas e Api’s necessários para executar o exemplo:

          1)Selenium RC http://seleniumhq.org/download/

          • Um servidor que executa automaticamente e mata o navegador e atua como um proxy HTTP para solicitações web a partir dele;
          • Disponibiliza biblioteca cliente para a linguagem de programação usada, no caso do exemplo a biblioteca cliente é para java.

          2)JUnit http://www.junit.org/

          Obs.: É possível pegar uma versão mais avançada do JUnit.

          3)Java JDK http://www.oracle.com/technetwork/java/javase/downloads/index.html

          Obs.: É possível pegar uma versão mais avançada do JDK.

          4)Eclipse IDE http://www.eclipse.org/downloads/

          Obs.: É possível pegar uma versão mais avançada do Eclipse IDE.

          Fonte:

          http://seleniumhq.org/projects/remote-control/

          http://sembugs.blogspot.com/2010/10/integracao-selenium-e-testlink.html

          Webinar O ciclo ATDD + TDD by Scrum Amazônia, Paulo Igor e Heitor Roriz:

          http://www.slideshare.net/Pigor/palestra-tddcompleta-5460534

          Bye see you next post

          sexta-feira, 15 de outubro de 2010

          Checklist para definição de feito

          done

          Os dez itens do checklist para definição de feito são:

          • Códigos produzidos. Os Todo’s com códigos completados;
          • Códigos comentados. Check-in e rodar em comparação a versão atual no controlador de versão;
          • Avaliação em pares(pair programming) e/ou padrão de desenvolvimento por reunião;
          • Construir sem erros;
          • Testes unitários construídos e passagens pelos testes com sucesso;
          • Deploy do sistema no ambiente de teste e passagem com sucesso do sistema nos testes;
          • Passagem com sucesso nos testes de aceitação do cliente e requisitos cumpridos;
          • Qualquer construção ou implantação de mudanças ou configuração implementada ou documentação;
          • A documentação relevante ou diagramas produzidos;
          • Horas restantes passam para “zero” e a tarefa é fechada.

          Fonte: http://www.agile-software-development.com/2007/07/definition-of-done-10-point-checklist.html

          Bye see you next post

          terça-feira, 28 de setembro de 2010

          Exemplo de 5 Porquês

          5-whys 

          Muitas vezes a resposta do primeiro "por que" irá pedir outro "por que" e assim por diante, daí o nome da estratégia 5 Porquês.

          Um exemplo da análise dos 5 Porquês aplicado no método scrum:

          Por que o nosso PO esta infeliz? Porque não liberamos o acordado do Sprint como prometemos.

          Por que fomos incapazes de cumprir o acordado do Sprint? As estórias demoraram mais no desenvolvimento do que imaginávamos.

          Por que demorou tanto tempo? Porque subestimamos a complexidade e a incerteza das estórias.

          Porque nós subestimamos a complexidade e a incerteza? Porque não temos critérios de aceitação de associar a cada estória. Nossas estórias não estavam num nível adequado de detalhe e não fizemos de forma realista o tamanho de cada estória, antes de se comprometer com acordado do Sprint.

          Por que não podemos fazer isso? Porque os superiores estavam com mentalidade de planejamento cachoeira, como resultado a equipe sentiu a pressão para trabalhar mais rápido e pulou etapas. É evidente que precisamos rever a nossa abordagem:

          • Para escrever estórias;
          • Dimensionar estórias;
          • Para fazer estimativa de duração e se comprometer com entrega do Sprint;
          • E obter o apoio dos superiores.

          "O presente nunca é o nosso objetivo: o passado e o presente são os nossos meios: Só o futuro é nosso objetivo."  Blaise Pascal

          Obs.: O acordado do Sprint são tarefas do Sprint Backlog.

          Fonte: http://www.agilejournal.com/articles/columns/column-articles/2863-agile-software-development-past-present-future

          Bye see you next post

          sexta-feira, 24 de setembro de 2010

          Calculando Velocidade Estimada do Sprint com Fator de Foco

          tiger

            Fator de Foco

            É uma estimativa de como a equipe é focada. Um fator de foco baixo pode indicar muitas interferências ou estimativa de tempo otimista da equipe.

            Exemplo:

            O último Sprint terminou com 22 pontos por estória.  E a equipe composta por Fernando, Carlos, Alberto, Luís e Maria que trabalharam 2 semanas(10 dias úteis) chegando um total 45 homens-dia.

            Fator de foco do último Sprint= Velocidade real do último Sprint/ homens-dia disponível do último Sprint

            49% = 22 pontos por estória /45 homens-dia

            Fator de foco do último Sprint =  49%(arrendamento)

            Agora que tenho o fator de foco do último Sprint, posso estimar a velocidade do próximo Sprint de 2 semanas(10 dias úteis). Sendo que equipe é composta das mesmas 5 pessoas do último Sprint na seguinte situação:

            • Fernando tem disponibilidade de 50%, porque esta envolvido  5 dias com manutenção de outro projeto da empresa;
            • Carlos tem disponibilidade de 10 dias;
            • Alberto tem disponibilidade de 10 dias;
            • Luís tem disponibilidade de 8 dias, outros 2 dias estará de folga;
            • Maria tem disponibilidade de 10 dias.

            Pessoas(equipe)

            Dias Disponíveis

            Fernando

            5

            Carlos

            10

            Alberto

            10

            Luís

            8

            Maria

            10

             

            43 Homens-dia disponíveis para próximo Sprint

            Velocidade estimada próximo Sprint = homens-dia disponível próximo Sprint X Fator de foco do último Sprint

            21 Pontos por Estória= 43 Homens-dia disponível próximo Sprint x 49% Fator de foco do último Sprint

            Velocidade estimada para o próximo Sprint é de 21 pontos

            por estória. A equipe adicionará estórias ao Sprint até atingir uma soma de aproximadamente 21.

            Exemplos:

            sprint

            21pontos

            Se equipe for nova e não tiver nenhuma estatística como referência, então é indicado pesquisar o fator de foco de outras equipes em circunstâncias similares.

            Caso não tenham outras equipes para pesquisar, suponha o fator de foco. O suposição será usada somente no primeiro Sprint, logo após tendo estatísticas poderá medir e melhorar continuamente seu fator de foco e a velocidade estimada.

            Casos de Ajuste no Fator de Foco

            Se último Sprint foi ruim, porque quase toda da equipe esteve doente por uma semana(exemplo: gripe), então pode ser seguro

            assumir que esta falta de sorte não acontecerá e assim estimar

            um fator de foco alto para o próximo Sprint.

            Se a equipe instalou um rápido sistema de build contínuo,

            provavelmente poderá aumentar o fator de foco devido a isto.

            Se uma nova pessoa integra a equipe o fator de foco do Sprint precisa ser reduzido devido ao treinamento.

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

            Bye see you next post

            quarta-feira, 22 de setembro de 2010

            Gráficos Burndown e Burnup no Scrum

            Gráfico Burndown

            burndownchart

            Um gráfico burndown mostra o quanto resta de iteração do Sprint. É usado como principal ferramenta de acompanhamento da iteração.

            O eixo de X representa os dias do Sprint. Já o eixo Y representa as tarefas.  Geralmente representada em horas ou dias ou pontos de histórias.

            O burndown de release mostra quantos pontos de história restam no product backlog depois de cada Sprint.

            Com burndown podemos saber se estamos atrás ou à frente do cronograma, para que possamos tomar providências o quanto antes e adaptar.

            Gráfico Burnup

            is2_burnupR215

            Um gráfico burnup pode mostrar mais informações do que um gráfico burndown, porque tem uma linha que mostra quanto o trabalho está no projeto como um todo (o escopo de trabalho) .

            O gráfico burnup apresenta trabalho entregue até atual momento para prever se a data de lançamento será cumprida.

            Resumindo, temos informações de quanto a equipe esta trabalhando para final do Sprint.

            Fonte:

            http://www.infoq.com/br/minibooks/kanban-scrum-minibook

            https://rally1wiki.rallydev.com/display/rlyhlp/Release+Burnup+Chart

            http://blog.locaweb.com.br/archives/3177/scrum-entidades-do-scrum/

            Bye see you next post

            terça-feira, 21 de setembro de 2010

            Livro Kanban e Scrum - obtendo o melhor de ambos

            ebook

            Livro Kanban e Scrum  de Henrik Kniberg e Mattias Skarin esta disponível para download para quem é cadastro na infoqbr, quem não for basta realizar o cadastro. Uma cortesia Henrik Kniberg e InfoQ.com/br:

            http://www.infoq.com/br/minibooks/kanban-scrum-minibook

            Tem versões traduzidas para os seguintes idiomas:

            • Francês;
            • Japonês;
            • Espanhol;
            • Italiano.

            Fonte: http://www.infoq.com/br

            Bye see you next post

            segunda-feira, 20 de setembro de 2010

            Qualidade de sistemas feitos com métodos ágeis

            triangulo 

            Os tipos de qualidade:

            Interna: Tem profundo efeito na manutenibilidade do sistema, mas não são visíveis pelos usuários.

            Exemplo: Consistências, testes, código legível para leitura e refatoração.

            Externa: Tudo que é percebido pelos usuários.

            Exemplo: interface não intuitiva.

            É possível um sistema com alta qualidade interna e baixa qualidade externa. Porque temos fundações de qualidade.

            Porém um sistema de baixa qualidade interna não terá qualidade externa.

            A qualidade interna não é negociável. Sendo responsabilidade da equipe manter a qualidade, que nunca será negociável.

            A qualidade externa, segundo o autor é considerada parte do escopo. Sendo de responsabilidade do product owner a qualidade externa, por exemplo, lançar uma versão de interface deselegante e posteriormente uma versão melhorada.

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

            Bye see you next post

            domingo, 19 de setembro de 2010

            Erros clássicos do desenvolvimento de software

            mistake

            Erros relacionados as pessoas:

            • Motivação prejudicada;
            • Pessoal técnicamente fraco;
            • Profissionais não controlam seus próprios problemas;
            • Profissionais heróis geralmente fazem mal;
            • Adicionar pessoas ao projeto atrasado;
            • Escritórios lotados;
            • Atrito entre desenvolvedores e clientes;
            • Expectativas irrealistas;
            • Falta de patrocínio ao projeto de software: O patrocínio ao projeto de software é necessário para muitos aspectos de desenvolvimento rápido, incluindo planejamento realista, controle de mudanças e a introdução de novas práticas de desenvolvimento;
            • Falta de interessados em comprar o software;
            • Falta de colaboração do usuário ao projeto;
            • Política colocado sobre a substância;
            • Pensamento positivo: É fechar os olhos esperando que algo funcione, quando não tem nenhuma base razoável para pensar que sim. O pensamento positivo no início do projeto leva a grandes ampliações no final do projeto. Isto prejudica o planejamento significativo e pode estar na raiz dos problemas de software mais do que todas as outras causas combinadas.

            Erros relacionados ao processo:

            • Estimativa de tempo excessivamente otimista;
            • Insuficiência de gestão de risco;
            • Prestador de serviço falha;
            • Planejamento insuficiente;
            • O abandono do planejamento sobre pressão;
            • O tempo perdido durante o fuzzy front end:  O fuzzy front end é o tempo antes do início do projeto, o tempo normalmente gasto no processo de aprovação e de orçamento;
            • Shortchanged upstream atividades: São projetos que estão com pressa para cortar as atividades que não são essenciais: Análise de requisitos, arquitetura e design que não produzem diretamente o código;
            • Desenho inadequado;
            • Garantia de qualidade Shortchanged: São projetos que estão com pressa em cortar custos, eliminando design, revisões de código, eliminando o planejamento de testes e realizando somente testes superficiais;
            • Os controles de gestão insuficientes;
            • Convergência prematura ou com muita freqüência;
            • Omitir tarefas necessárias a partir de estimativas;
            • Planejamento para apanhar depois;
            • O código de programação como o inferno.

            Erros relacionados à forma como o produto é definido:

            • Requisitos gold-plating: Alguns projetos têm mais requisitos  do que necessitam;
            • Fluência de recursos;
            • Desenvolvedor gold-plating: Desenvolvedores são fascinados por novas tecnologias e às vezes são ansiosos para experimentar novos recursos da linguagem, ambiente ou para criar a sua própria implementação. Isto poderá manchar o produto senão é necessário;
            • Push me, pull me de negociação;
            • O desenvolvimento orientado a investigação.

            Os erros remanescentes tem haver com uso e abuso da tecnologia:

            • A síndrome de Silver-Bullet: Houve muita confiança sobre os benefícios das tecnologias utilizadas (gerador de relatório, projeto orientado a objeto, etc.) e  poucas informações sobre como elas ajudariam neste ambiente de desenvolvimento em particular;
            • Poupanças superestimadas de novas ferramentas ou métodos: Organizações raramente melhoraram sua produtividade em saltos gigantes, não importando quão bom ou quantas novas ferramentas ou métodos que adotam;
            • Ferramentas de comutação no meio de um projeto:  Esta é uma velha espera que quase nunca funciona. Às vezes, pode fazer sentido para atualização incremental na mesma linha de produtos, a partir da versão 3 para a versão 3.1 ou às vezes até a versão 4. Mas a curva de aprendizado, retrabalho e erros inevitáveis feita com uma ferramenta totalmente nova, geralmente anula qualquer benefício quando está no meio de um projeto;
            • A falta de controle automatizado do código fonte:  A falha no uso de controle automatizado do código fonte expõem projetos aos riscos.

            Fonte: 

            Classic Mistakes Enumerated 1996 by Steven C. McConnell http://www.stevemcconnell.com/rdenum.htm

            Bye see you next post

            terça-feira, 14 de setembro de 2010

            Três coisas que você pode fazer para tornar o software melhor by Luigi R. Viggiano

            image_6

            Pensamento top-down

            Quando escrever seu código não iniciar a partir da implementação, iniciar a partir do código do cliente. Hoje em dia é popular falar sobre TDD e como escrever código de teste levando ao um projeto melhor. Da mesma maneira você pode escrever seus serviços de back-end a partir do front-end. O design interno deve emergir de casos de uso e não vice-versa. Assim, testes de software precoce não são apenas as unidades de aplicações mais confiáveis, são importantes e levam um código melhor: fácil de entender, aumentar e manter.

            Escrever código legível

            Deixe que o código seja auto-explicativo. Se notar que esta escrevendo muitos comentários para explicar um algoritmo, provavelmente significa que seu código não é legível. O comentário no código fonte é a documentação para desenvolvedor, mas se código é compreensível por outro desenvolvedor é a melhor documentação. Não coloque "debug" em todos os lugares, registrando ! = Depuração.

            Manipulação de exceção

            É a fonte de muitos erros: capturar uma exceção e deixar outra passar completamente. Evite o "catching-and-rethrowing"  e exceção de deglutição. Existem vários artigos sobre o que não se deve fazer, um bom artigo: Exception Handling Antipatterns. Verifique se o seu software avisa quando acontece algum problema e não só funcione bem quando tudo vai bem. Isso reduzirá a necessidade de procurar problema no arquivo de log.

            Fonte: http://en.newinstance.it/2010/04/16/top-3-things-to-do-to-make-better-software/

            Bye see you next post

            sexta-feira, 10 de setembro de 2010

            Breve tutorial sobre jmeter

            Introdução ao jmeter através de um breve tutorial introdutório em duas partes:

             

            Fonte: www.youtube.com/watch?v=8jpXFjcHuhc

            Bye see you next post

            domingo, 5 de setembro de 2010

            Alcançar a agilidade do negócio

            chess

            Baseado no artigo “An Overview of Lean-Agile Methods” por Alan Shalloway.

            Alcançar a agilidade do negócio: Por onde começar?

            Depende de onde você está e onde quer ir. Alan Shalloway comenta que experiência de começar adoção agile num projeto piloto da equipe não é uma boa opção. Não concordo, pois acredito que projeto piloto pode ajudar bastante, mesmo após treinamento.

            Como um motor de carro, o método da equipe não pode ser o problema. Mesmo que necessite melhorar, você sempre estará em melhor situação olhando para todo contexto no qual o desenvolvimento de software é feito e escolher o que melhorar. Aqui estão duas recomendações:

            • Olhar para o fluxo de valor inteiro. Onde estão os desafios, o que precisa melhorar? Isso não significa que você está empenhado em mudar mais a equipe, mas fornecerá uma percepção que garantirá o progresso da equipe. Felizmente colhendo frutos como progresso empresarial e a agilidade do negócio.
            • Deixem as equipes envolvidas escolherem entre Scrum e Kanban. Elas sabem intuitivamente o que é melhor. Partindo do respeito aos meios que lhes permitem escolher como fazer o seu trabalho no contexto do negócio.

            Fonte: http://www.agilejournal.com/articles/columns/column-articles/3222-an-overview-of-lean-agile-methods

            Bye see you next post

            sábado, 4 de setembro de 2010

            O Pensamento Enxuto na Análise de Negócios

            Testes de Desempenho com JUnitPerf + JUnit

            tech_loadres

            O JUnitPerf destina-se a ser utilizado especificamente nas situações de desempenho quantitativo ou requisitos de escalabilidade.

            O teste do JUnit é usado junto ao JUnitPerf para verificar o desempenho. Aqui estou usando a classe de teste FoneFisicaTest, que já tinha falado num outro artigo:

            public class FoneFisicaTest extends TestCase{
                private FoneFisicaBusinessRules testFoneFisica;
                public FoneFisicaTest(String testName){
                    super(testName);
                }

                public void setUp() {
                    ApplicationContext factory = new ClassPathXmlApplicationContext("contextApplication.xml");
                    this.testFoneFisica = (FoneFisicaBusinessRules) factory.getBean ("foneFisicaBusinessRules");
                }

                @Test
                public void testBuscaFone() {
                    FoneFisica f = testFoneFisica.buscarFone(3);
                    assertNotNull(f);

                }

                @Test
                public void testCriarFone() {
                    boolean b = testFoneFisica.criar(3, "6666665");
                    assertTrue(b);

                }

            }

            Para usar o JUnitPerf basta baixar o JUnitPerf.jar e o JUnit.jar (versão 3.5 para cima) e colocá-los no classpath, no meu caso estou usando Eclipse IDE e coloquei no buildpath. Em outras IDE’s deve ser algo parecido.

            Link’s para os jar’s:

            http://clarkware.com/software/JUnitPerf.html#download

            http://www.junit.org/

            JUnitPerf

            LoadTest é um decorador que executa um teste com um número  de usuários simultâneos e iterações.

            TimedTest é um decorator que pega tempo do execução do teste JUnit. Caso o tempo seja maior que o permitido, dispara uma exceção AssertionFailedError.

            JUnit

            RepeatedTest é um decorador que executa um teste repetidamente.

            Exemplo:

            Para criar um teste de carga de 10 usuários simultâneos, sendo que cada um executará 20 vezes o serviço testCriarFone com um atraso de 1 segundo entre adição de usuários, temos o seguinte código:

            public static Test suite() {

                    int usuarios = 10;
                    int iteracoes= 20;
                    Timer tempo = new ConstantTimer(1000);
                    Test testCase = new br.com.madeira.pessoa.testeunit.FoneFisicaTest(
                            "testCriarFone");
                    Test repeatedTest = new RepeatedTest(testCase, iteracoes);
                    Test loadTest = new LoadTest(repeatedTest, usuarios, tempo);

                    return loadTest;
                }

            Resultado:

            desempenho

            Tempo de teste não chegou 1 segundo e não disparou a exceção. Grifei em vermelho o tempo do teste que é de 0,671 s.

            Agora outro teste:

            10 usuários simultâneos e 1000 milisegundos de tempo:

            public static Test suite() {
                    int usuarios = 10;
                    long tempo = 1000;
                    Test testCase = new br.com.madeira.pessoa.testeunit.FoneFisicaTest(
                    "testCriarFone");
                    Test timedTest = new TimedTest(testCase, tempo);
                    Test loadTest = new LoadTest(timedTest, usuarios);

                    return loadTest;
                }

            Resultado :

            desempenho2

            Não passou no teste de desempenho.

            Agora vamos tentar aumentar o tempo para 1400 milissegundos e 10  usuários simultâneos:

            public static Test suite() {
                    int usuarios = 10;
                    long tempo = 1400;
                    Test testCase = new br.com.madeira.pessoa.testeunit.FoneFisicaTest(
                    "testCriarFone");
                    Test timedTest = new TimedTest(testCase, tempo);
                    Test loadTest = new LoadTest(timedTest, usuarios);

                    return loadTest;
                }

            Resultado:

            desempenho3

            Passou no teste, provavelmente o gargalo estava na concorrência. E pode ser também um problema de banco de dados e/ou da aplicação. No caso estou usando banco de dados Mysql.

            O JUnitPerf tem licença BSD é mantido pelo Clarkware Consulting.

            Mais informações:

            O blog do professor Edgard Davidson com farto conteúdo e vídeo:

             http://edgarddavidson.com/?p=542

            e

            Clarkware Consulting

            http://clarkware.com/software/JUnitPerf.html

            Nunca esqueça que primeiro de fazer quebrar o teste e depois funcionar.

            Obs.: A visualização do teste de desempenho é mais detalhada no Netbeans, apesar de gostar mais do Eclipse tenho que reconhecer os méritos do Netbeans.

            Fonte:

             http://edgarddavidson.com/?p=542

            e

            http://clarkware.com/software/JUnitPerf.html

            Bye see you next post

            quinta-feira, 26 de agosto de 2010

            Aplicativos para Pomodoro

            pomodoro

            Pomodoro em italiano significa tomate. Um relógio de cozinha em formato de tomate usado para medir trabalho de 25 minutos e a pausa de 5 minutos.

            Os adeptos a técnica pomodoro elaboraram temporizadores ou aplicativos para PC, laptops e dispositivos móveis.

            Alguns aplicativos dispositivos móveis:

            Pomodoro Timer para iPhone pago $0.99:

            http://itunes.apple.com/app/pomodoro-timer/id325610693?mt=8

            Pomodoro Timer para Android:

            http://www.androidzoom.com/android_applications/productivity/pomodoro-timer_bfil.html

            Alguns aplicativos PC e notebook:

            Pomodoro 0.31 para Mac: http://www.baixaki.com.br/mac/download/pomodoro.htm

            Pomodori para Mac:

            http://reborg.github.com/pomodori/

            Focus Booster(windows, mac e linux):

            http://www.focusboosterapp.com/ 

            Pomodairo 1.7  e Dexpot para windows.

            Pomodoro Timer feito em java(multiplataforma):

            http://wiztools.googlecode.com/files/pomodoro-timer-ui-1.0.jar

            Fonte:

            http://groups.google.com.br/group/ensinar/browse_thread/thread/9725368eb1015a75

            e

            http://www.dukeville.com/blog/2010/8/11/pomodoro-technique.html

            Bye see you next post