Análise do Burndown e suas Categorias

Excelente artigo da infoq sobre análise do Burndown e suas categorias separadas por Kane Mar.

http://www.infoq.com/br/news/2010/02/deciphering-burndown-charts

Postado por Vikas Hazrati , traduzido por Gisela Nogueira

fonte: InfoQ

Bye see you next post

Lei de Parkinson: Uma das cinco doenças de Gerência de Projetos

Vou falar sobre uma doença muito conhecida nos projetos de software, a doença se chama: Lei de Parkinson.

Geralmente a equipe coloca uma maior segurança na estimativa de uma tarefa. Uma pessoa quando recebe uma tarefa, a primeira pergunta  é: “Quanto tempo será necessário para completar a tarefa?”. Devidos as leis de Murphy e a multitarefa as pessoas tendem a colocar uma proteção na estimativa de tempo da tarefa.

Sendo que o prazo estimado nunca vai dar 100% de certeza que vai terminar no prazo, talvez uma oferta 80% a 90% que vai terminar no prazo.

Sabemos que estimativas não são exatas. Mesmo assim nós as exigimos, Por quê? Há uma idéia que se podemos determinar precisamente o tempo para cada tarefa e assegurarmos que cada tarefa seja completada no prazo, então o projeto terminará no prazo, segundo a nossa idéia. Objetivo não é terminar a tarefa no prazo. Mas completar o projeto no prazo.

Isso significa que mesmo que seja possível terminar a tarefa em um prazo de 20 horas e tenha estimativa de 40 horas, a tarefa  será completada em 40 horas. Isso é a Lei de Parkinson: O trabalho se expande para preencher o tempo disponível.

Quem determina o prazo é o Gerente de Projetos, que determina o prazo com as proteções contra problemas que nem sabemos se irá acontecer.

Se o projeto não terminou no prazo e nem ocorreu Murphy é sinal que segurança não esta servindo, mesmo que ocorra um Murphy e termine no prazo, a estimativa não é aceitável.  Vou dar um exemplo: previ que poderiam ocorrer quatro eventos de Murphy, e mesmo assim foi ocupada toda estimativa para completar o projeto e ocorreu apenas um evento de Murphy.  Realmente previ uma estimativa com a doença de Parkinson, onde o trabalho se expandiu para preencher o tempo disponível.

Fonte: http://www.heptagon.com.br/5dgp-2

Bye see you next post

Pensando em Lean

Filosofia Lean

A filosofia Lean fala eliminar desperdício. O desperdício não acrescenta valor nenhum no que fazemos.

• Aprenda enxergar desperdício;
• O desperdício aparece :

1. Quando se deixa algo para trás;
2. Quando faz algo que não server para nada ou sem necessidade;
3. Na atenção que perdemos quando fazemos varias tarefas ao mesmo tempo;
4. No tempo que perdemos esperando algo de alguém;
5. Na movimentação que pode ser evitada;
6. Quando criando-se defeitos;
7. No excesso de controle.

A filosofia diz que devemos aproveitar todas oportunidades para aprender mais. Isto acontece através de feedbacks, interações e integrações.

Decida tardiamente quando tiver mais informações. Isto tem custo, mas é menor do que os trazidos pelas más decisões.

Entregue o quanto antes. Tempo não se recupera.

Aprenda delegar e acredite no potencial das pessoas com quem trabalha.

Procure sempre melhorar suas habilidades de motivação e liderança e estimule o compartilhamento de aprendizado.

Desenvolva a visão do todo.

Não abra mão da qualidade.

Tenha orgulho do que faz ou você pode estar desperdiçando sua vida.

Origem do Lean

W. Edwards Deming (1900-1993):

• Sistema de conhecimento profundo;

Ciclo de Shewhart

• O Sistema de Produção da Toyota:

Taiichi Ohno (1912 - 1990)

Fluxo “Just-In-Time”:

• Complexidade X Economia de Escala;

Automação :

• “Stop-the-Line”.

Shigeo Shingo (1909 - 1990):

Produção sem estoque:

• Trabalho organizado em tarefas pequenas;

Zero Inspeções:

• “Mistake-proof”;

Os valores foram expandidos para outras
áreas:

• Produção Lean;
• Manufatura / Operações Lean;
• Cadeia de Suprimentos Lean Desenvolvimento de Produtos Lean.

Desenvolver software é criar um novo
produto!

• Sempre aparece algo novo.

Problemas com Software

• Requisitos que mudam com freqüência;
• Decisões centralizada;
• Gerenciamento de escopo rígido;
• Desenvolvimento linear;
• Quase sem foco na qualidade do software.
  

Fluxo do Lean

Princípios Lean voltado para software

• Elimine Desperdícios;
• Inclua a Qualidade no Processo;
• Crie Conhecimento;
• Adie Comprometimentos;
• Entregue Rápido;
• Respeite as Pessoas;
• Otimize o TODO.

Eliminando desperdício poderemos entregar software funcionando que agregue valor ao cliente.

Elimine Desperdícios

• Trabalho incompleto;
• Processos desnecessários ou a mais;
• Funcionalidades desnecessários ou a mais;
• Troca de tarefas;
• Handoffs;
• Atrasos;
• Defeitos;

Inclua a Qualidade no Processo

• Não deixe os testes para final;
• Ciclos de teste extensos quase sempre gastam  tempo corrigindo defeitos;
• Ao invés de se esforçar para gerenciar defeitos tente evita-lós, Teste de unidade ajudam;
• Prevenindo defeitos com vários tipos de teste:

1. Testes de Aceitação;
2. Testes de Usabilidade;
3. Testes de Unidade;
4. Testes de Resposta, Segurança,
   Escalabilidade.

Crie Conhecimento

• Metáfora: criar x preparar uma receita;
• Incentive o compartilhamento de conhecimento;
• O processo deve sofrer melhoramentos contínuos.

Não existe bala de prata.
Fred Brooks

• Método científico (Plan-Do-Check-Act):

1. Enquadre o problema;
2. Busque pela raiz do problema;
3. Fazer a proposta de uma solução;
4. Implemente a solução;
5. Verifique os resultado;
6. Analise e adapte seus padrões.

• Mito: Predições criam previsibilidade.

Adie Comprometimentos

• Decisões irreversíveis devem ser tomadas o mais tarde possível ;
• Opções reais;
• É preciso definir o momento da decisão quando houver mais informação;
• Flexibilidade mal usada é ruim;
• Um bom líder saberá alocar flexibilidade;
• Mito: Um plano é um comprometimento;
• Design baseado em conjunto:
  Na incerteza, experimente diversas soluções;
  Agende o momento da decisão;
  Sempre haverá uma solução que funciona.

Entregue Rápido

• Competir com base na velocidade traz
  grande vantagem competitiva;
• Utilize sistemas Pull em software;
• Utilize disseminadores de informações:
  Kanban e Meeting.

• Utilize pequenas quantidades de trabalho:
  Limite o trabalho à capacidade;
• Teoria das filas:
  Tempo do ciclo = Tarefas em processo/
  Taxa Média para completa

Lições:
Pequenas quantidades de trabalho andam mais rápido;
Possuir alguns recursos inativos diminui o tempo do
ciclo.

• Tempo gasto esperando na fila é desperdício!
• Objetivo: Reduzir o tempo do ciclo!
  

Respeite as Pessoas

• 3 pilares estão relacionados às pessoas:

   Liderança; 
   Time de trabalho com conhecimento;
   Planejamento e controle baseado em responsabilidade.

• Liderança: 
    Bom conhecimento técnico; 
    Bom conhecimento do cliente.
• Times completos.
• Pessoas são recursos?
• Papel da gerência é distribuir tarefas e
  monitorar?
• Exemplo: Idéia coletadas na Toyota.
• Motivação:
• Propósito;
• Participação;
• Segurança;
• Competência;
• Progresso;

A verdadeira inovação da Toyota é sua
habilidade em usufruir da inteligência dos
trabalhadores comuns. Gary Hamel

• Mova a responsabilidade e o poder de decisão para o nível mais baixo possível;

Otimize o TODO

• Círculo vicioso 1 no desenvolvimento
  de software:

1. Cliente pede nova funcionalidade, para ontem;
2. Desenvolvedor ouve: Termine rápido!
3. consequência: Mudanças feitas de qualquer jeito no
   código;
4. consequência: Aumenta complexidade do código;
5. consequência: Número de defeitos aumenta do código;
6. consequência: Tempo para adicionar funcionalidade
   cresce exponencialmente.

• Círculo vicioso 2 no desenvolvimento de
  software:

1. Equipe de testes sobrecarregada;
2. consequência: Testes depois da codificação, nada agile;
3. consequência: Desenvolvedores não recebem feedback
   imediato, comunicação anda ruim no time;
4. consequência: Desenvolvedores criam mais defeitos;
5. consequência: Equipe de teste sobrecarrega de trabalho.

• É preciso olhar para o processo todo;
• Não adianta remediar sintomas;
• É preciso achar a causa e resolver;
• 5 Porquês.
• Métricas:

1. Medir informação x Medir desempenho;
2. Tenha cuidado:
1. É fácil medir muitas coisas;
2. É fácil medir as coisas erradas;

• Diminua o número de métricas de
  desempenho;
• Meça para cima:
• Medidas no nível mais alto que direcionam para o comportamento correto;
• Medidas a nível de time, não de indivíduos.
• Incentive a colaboração do time.

Fonte:http://www.agilcoop.org.br

e www.youtube.com/watch?v=FsKghWVmyQo

Bye see you next post

Pomodoro uma pequena revisão

Segundo Francesco Cirillo é uma técnica de melhoria. Melhorando a concentração e eficiência, sem estresse ou pressão, a idéia é fazer com que nossa mente trabalhe da melhor maneira possível.

O pomodoro pode ser usado adultos, crianças, estudantes e equipes.

O nome pomodoro surgiu porque Francesco Cirillo é de origem Italiana e usou a técnica com relógio de cozinha em formato de tomate para melhorar seu processo de estudo na faculdade.

Material

Papel,  lápis e cronometro ou relógio para marcar o tempo.

Listas

Lista de atividades;

Registro de atividades;

Lista de atividade não planejadas.

Passos fundamentais

• Pegar uma atividade da lista de atividades;
• Definição da atividade a ser realizada com tempo de 25 minutos; 
• Dedicar-se para a atividade até que o temporizador feche os 25, em seguida, marcar um "x"  no registro de atividades. Isso representa que um pomodoro feito.
• Pausa curta de 5 minutos. Pelo um estudo da Universidade de Nova York esta pausa pode ajudar na memorização. Faça uso de chá, água, suco, meditar, falar sobre outros assuntos ou até mesmo contar uma piada será mais saudável.
• A cada quatro "Pomodoros", dê uma pausa maior.

Após terminar todos os pomodoros de um atividade, partir para nova tarefa da Lista de atividades e registrar nova linha em Registro de atividades. O ciclo de pomodoros recomeça.

As tarefas que utilizam mais de 7 pomodoros deveram ser divididas.  As interrupções ocorridas durante o pomodoro são colocadas numa fila que será representa por lista de atividade não planejadas(na vida real nem sempre dá para fazer uma atividade sem interrupções). Essa fila é tratada quando o pomodoro terminar. Nas ocasiões em que a interrupção não pode ser inserida na fila(lista de atividade não planejadas), o pomodoro é parado e invalidado. Francesco Cirillo cita que o próximo pomodoro sempre superará as suas expectativas.

Hoje vi uma matéria que citava o uso de pomodoro num colégio e desempenho dos alunos melhorou.

Acredito que pomodoro é uma técnica que acrescentará muito na metodologia ágil.

Fonte:  http://www.pomodorotechnique.com/

e http://cirillosscrapbook.wordpress.com/

Aniversário do Manifesto Ágil

Manifesto Ágil foi iniciado por especialistas de software experientes que questionavam práticas tradicionais da Engenharia do Software e Gerencia de Projetos.

Em fevereiro de 2001 dezessete especialistas de software assinaram o manifesto ágil em Snowbird Utah, foram eles:

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

Evolução de nove anos foi incrível, hoje várias empresas adotam o agile e pedem como requisito para contratar um profissional.

Até primeira versão do XP que era mais rígida ficou mais flexível na segunda versão.

Bye see you next post

Benefícios de Estimativas por Pontos

Fonte: youtube e http://www.tvagile.com/2010/02/05/benefits-of-point-estimation/

Bye see you next post

Relembrando Gestão Ágil de Riscos

Gestão ágil de risco foi postada Vikas Hazrati e  traduzida por Victor Hugo Germano em 02 fevereiro de 2009.

Mike Cottmeyer sugere neste artigo que metodologias ágeis são melhores para identificar e mitigar riscos. E cita também três categorias para riscos.

Em contrapartida, Jurgen Appelo diz que com maior freqüência,  existe uma falta de foco em riscos nos projetos Ágeis

James Shore complementa que um gerenciamento de riscos eficiente pode ajudar uma equipe a fazer comprometimentos sólidos. Ele sugere a utilização de ferramentas como Multiplicadores de Riscos e Gráficos Burn-up para gerenciar riscos específicos do projeto.

Acrescentando que os multiplicadores são sugeridos para  processos rígidos onde a velocidade do time é constante e as estórias estão "prontas" no final da iteração.

Sendo assim através dos multiplicadores a gerência de riscos é parte integral de projeto ágil ou tradicional.

Artigo:

http://www.infoq.com/br/news/2009/02/agile-risk-management

 

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

Bye see you next post

O que é FDD?

É uma metodologia ágil para gerenciamento e desenvolvimento de software.

Origem do FDD

FDD nasceu num projeto em Cingapura(1997 e 1999) partir da análise, design e POO desenvolvida por Peter Coad nas décadas de 1980 e 1990 e das técnicas de gerenciamento iterativo, incremental e enxuto de projetos utilizadas por gerente de projetos Jeff De Luca.

A primeira descrição oficial dos processos foi publicada no livro "Java Modeling in Color with UML", por Peter Coad, Eric Lefebvre e Jeff De Luca, em 1999.

O livro de referência é "A Practical Guide to Feature-Driven Development", por Stephen Palmer e John Mac Felsing, publicado em 2002 pela Prentice-Hall, compondo uma série editada pelo próprio Peter Coad.

Fases do FDD

• Concepção & Planejamento: Pensar um pouco antes de fazer ( Tempo 1 a 2 semanas) ;
• Construção: Fazer de forma iterativa (Possibilidade de iterações de 2 semanas).

Os cinco processos FDD definidos e integrados:

1. Desenvolver um Modelo Abrangente: Pode envolver desenvolvimento de requisitos, análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção;
2. Construir uma Lista de Funcionalidades: decomposição funcional do modelo do domínio, em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o produto a ser construído (lista de espera do produto);
3. Planejar por Funcionalidade: Abrange a estimativa de complexidade e dependência das funcionalidades, levando em consideração a prioridade e valor para o cliente. O resultado é um plano de desenvolvimento com os pacotes de trabalho na seqüência apropriada para a construção;
4. Detalhar por Funcionalidade: Dentro de uma iteração de construção a equipe detalha os requisitos e outros artefatos para a codificação de cada funcionalidade e testes. O projeto para as funcionalidades é inspecionado. O resultado é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos.
5. Construir por Funcionalidade: Cada esqueleto de código é preenchido, testado e inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código com qualidade e potencial para ser usado pelo cliente.

http://pt.wikipedia.org/wiki/Feature_Driven_Development

 

Fonte:

http://heptagon.com.br

e

http://www.featuredrivendevelopment.com/

e

http://pt.wikipedia.org/wiki/Feature_Driven_Development

Bye see you next post

Pequena Introdução ao TDD – Desenvolvimento Dirigido por Teste

O que é TDD?

Ciclo com passos de bebê:

• Escrever um teste que falha;
• Fazer um teste que passe;
• Refatore.

Prioridade do Teste

• Conhecer design;
• Testar;
• Implementar;
• Boa notícia: pressão, estresse e falta de tempo não deixam os testes para trás.

Considerações finais sobre TDD:

• Design evolui com o conhecimento adquirido com projeto;
• Desenvolvimento com passos de bebê;
• Expressa a boa intenção do programador em relação aos testes;
• Serve de documentação.

Sobre código o que podemos dizer:

• Nome dos teste definem o comportamento esperado;
• Sem duplicação;
• Alta cobertura;
• Previne código inútil;
• Alta qualidade do código.

Refatoração são seguras com testes automatizados;

Fonte: http://www.agilcoop.org.br

Bye see you next post

Por que alguns programadores não gostam de escrever testes automatizados?

Culturalmente alguns programadores acham que não precisam escrever testes automatizados. Este pensamento vem desde formação até vida profissional.

Quebrar um paradigma de formação é difícil, mas não é impossível.

Como trato de assuntos ligados a metodologia ágil, falarei dos testes automatizados e benefícios aos programadores e clientes.

Os testes automatizados são uma maneira de garantir maior qualidade de código, sendo assim os clientes e os programadores ganham. O cliente ganhará um produto com maior qualidade e o programador terá maior qualidade de código.

Problemas sem testes automatizados:

• Muito tempo na depuração;

• Erros encontrados tardiamente;

• Dificuldade em relação à repetição testes;

• Demorado;

• Cansativo;

• Executado poucas vezes.

Benefícios dos testes automatizados:

• Segurança para mudanças externa e de código;

• Aumento do tempo de vida útil do software;

• Testes executados a qualquer momento;

• Encontram erros;

• Aumentam a velocidade de programação.

E como deve ser o código do teste?

O código do teste merece o mesmo cuidado que o código do sistema.

O código do teste passa por manutenção. Também poderá conter erros, deverá ser legível e simples.

Tipos de testes

O programador é responsável pelos testes unitários, que possuem as seguintes características:

• Encontram muitos erros;

• Tipo focando na funcionalidade (caixa-branca).

Os demais testes são:

• Aceitação;

• Interface  do usuário;

• Mutação;

• Desempenho;

• Estresse;

• Segurança;

• Integração.

Os demais testes o programador poderá fazer, mas conforme conhecimentos e experiências precisarão ou não do apoio dos seguintes profissionais:

• Analista de teste;

• Pessoal da infraestrutura ou arquiteto.

Colegas programadores, com os testes automatizados vocês somente terão a ganhar na execução do seu trabalho e na formação profissional. Tendo uma visão focada no negócio.

“Qualquer funcionalidade que não possui testes automatizados simplesmente não existe.” Kent Beck

Fonte: http://www.agilcoop.org.br

Ta-ta for now