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