Qualidade de Software | Planejamento e estimativas ágeis
Slides utilizados em aula na disciplina Qualidade de Software do Instituto de Ciências Exatas e Informática - Sistemas de Informação. Pontifícia Universidade Católica de Minas Gerais - Unidade Barreiro, 1º Semestre 2015.
projeto de desenvolvimento de software. Planos de guiam nossas decisões de investimento. Por exemplo, poderíamos iniciar um projeto específico se estimássemos que ele demoraria seis meses e R$ 1 milhões, mas rejeitaríamos o mesmo projeto se nós soubéssemos que levaria dois anos e custaria R$ 4 milhões. Planos ajudam a saber o que precisa estar disponível para ser utilizado em um projeto durante um determinado período. Planos permitem saber se um projeto está no caminho certo para oferecer a funcionalidade que os usuários precisam e esperam. Por que planejar?
muitas vezes errados. As equipes geralmente responder a isso indo até um dos dois extremos: 1. ou não fazem nenhum planejamento; 2. ou eles colocaram tanto esforço em seus planos que eles se convenceram de que os planos devem estar certo. Por que planejar?
as questões mais básicas, tais como: "Quando o produto vai estar pronto?" ou "Será que podemos agendar a entrega do produto para junho?" Por que planejar?
qualquer plano pode ser "certo". Por que planejar? O plano pode ser mais aprofundado, mas isso não significa necessariamente que será mais preciso ou útil. — Mike Cohn
Boehm (Conhecido também por ter proposto a métrica COCOMO e o modelo espiral) chamou a primeira versão do que Steve McConnell (1998) mais tarde chamado de "cone de incerteza". A figura abaixo mostra o fator de incerteza em vários estágios durante o desenvolvimento sequencial (waterfall). Por que planejar?
a definição inicial do produto o cronograma pode variar de 60% a 160%. Em outras palavras, se um projeto nesta fase é estimado para durar 20 semanas ele pode variar entre 12 e 32 semanas.
a precisão progressiva das estimativas. No entanto, ao invés de ver o cone de incerteza como simétrica, eles vêem como assimétrica. Eles sugerem a criação de um pedido inicial de estimativa de magnitude, que pode variar de +75% a -25%. O próxima estimativa a ser criada é a estimativa orçamental, com uma variação de +25% a -10%,. Por fim, a estimativa final e definitivo varia no intervalo de +10% e -5%. Por que planejar?
como o planejamento de campanhas de marketing, agendamento de atividades de lançamento de produtos, treinamento de usuários internos, e assim por diante. Estas são necessidades importantes e a dificuldade de estimar um projeto não nos exime de fornecer um plano ou cronograma que a organização pode usar para esses fins. No entanto, além dessas necessidades superficiais, há uma razão muito mais fundamental para assumir o trabalho duro de estimar e planejamento. Por que planejar?
um prazo ou cronograma apropriado. O planejamento é uma tentativa de encontrar uma solução ótima para a questão central de desenvolvimento de produtos: O que devemos construir? Para responder a esta questão, a equipe considera funcionalidades requeridas, recursos e cronograma. No início de um projeto é definido que um produto deve conter um conjunto específico de funcionalidades para ser lançado em 31 de agosto. Mas, em junho, pode-se decidir que uma data um pouco mais tarde com um pouco mais de funcionalidades será melhor. Ou pode-se decidir que um pouco mais cedo, com um pouco menos funcionalidades vai ser melhor. Por que planejar?
redução de incertezas; • Proporciona melhoria na tomada de decisão; • Permite estabelecer uma relação de confiança com o cliente; • Transmite expectativas. Por que planejar?
ideias sobre os riscos do projeto. Alguns projetos são tão arriscados que pode-se optar por nem sequer dar inicio uma vez que descobrimos os riscos envolvidos. Outros projetos podem conter elementos cujos riscos podem ser contidos pela preocupação precoce. Por exemplo, suponha que você tem que estimar quanto tempo vai demorar para integrar o novo projeto com um sistema de mainframe legado existente de que você não sabe nada. Isto irá expor o processo de integração como um risco potencial. A equipe do projeto pode optar por eliminar o risco logo de inicio gastando tempo aprendendo sobre o sistema legado. Ou o risco pode ser observado e a estimativa ser aumentada por causa dele ou ainda a estimativa pode ser expressa por um intervalo devido a incerteza e risco. redução do risco
risco de desenvolver o produto errado. No entanto, este risco é inteiramente ignorado na maioria dos projetos. Uma abordagem ágil para o planejamento pode reduzir drasticamente (e esperemos que elimine) este risco. Os estudos frequentemente citados (Standish 2001) definem um projeto bem sucedido quando é finalizado a tempo, dentro do orçamento e com todos as funcionalidades originalmente especificadas. redução de incertezas
risco de desenvolver o produto errado. No entanto, este risco é inteiramente ignorado na maioria dos projetos. Uma abordagem ágil para o planejamento pode reduzir drasticamente (e esperemos que elimine) este risco. Os estudos frequentemente citados (Standish 2001) definem um projeto bem sucedido quando é finalizado a tempo, dentro do orçamento e com todos as funcionalidades originalmente especificadas. redução de incertezas
risco de desenvolver o produto errado. No entanto, este risco é inteiramente ignorado na maioria dos projetos. Uma abordagem ágil para o planejamento pode reduzir drasticamente (e esperemos que elimine) este risco. Os estudos frequentemente citados (Standish 2001) definem um projeto bem sucedido quando é finalizado a tempo, dentro do orçamento e com todos as funcionalidades originalmente especificadas. redução de incertezas Esta é uma definição perigosa porque ela falha em reconhecer que uma funcionalidade que parecia boa no início do projeto pode não valer a pena o seu custo de desenvolvimento quando a equipe começa a trabalhar nela. — Mike Cohn
é que uma organização pode decidir se um determinado projeto vale a pena fazer se ela não tem estimativas do valor ou de custo do projeto? Além decisões sobre se deve ou não iniciar um projeto, estimativa nos ajudar a ter certeza de que estamos trabalhando nos projetos mais valiosos. Suponha que uma organização está considerando dois projetos: • Um é estimado para ganhar R$ 1 milhão e • O segundo é estimado para ganhar R$ 2 milhões. melhora na tomada de decisão
a fim de determinar se esses projetos valem a pena serem feitos. Será que os projetos vão demorar tanto que eles vão perder uma janela de mercado? Será que os projetos vão custar mais do que eles vão produzir de receita? Em segundo lugar, a organização precisa de estimativas e de um planejamento para que ela possa decidir qual projeto levar adiante. A empresa pode decidir fazer um dos projetos, ambos os projetos, ou nenhum deles se os custos são elevados. melhora na tomada de decisão
seria contratar um bom programador e permitir que ele se torne um especialista em administração de banco de dados, e assim por diante para poder desenvolver o sistema em dez ou vinte anos. Raramente podemos esperar vinte anos por um sistema e por isso, desenvolvemos em equipe. Uma equipe de trinta pessoas pode passar um ano desenvolvendo o que um programador solitário poderia ter feito em vinte. O custo de desenvolvimento vai ser maior, mas o valor de ter a aplicação 19 anos antes justifica o aumento do custo. melhora na tomada de decisão
de confiança entre os desenvolvedores e os clientes do produto. Estimativas confiáveis permitem a entrega responsável. Um cliente precisa de estimativas para tomar decisões de priorização e escolhas. As estimativas também ajudam um cliente a decidir o quanto de uma funcionalidade deve ser desenvolvida. Ao invés de investir vinte dias e desenvolver tudo, talvez dez dias de esforço vai render 80% do benefício. Os clientes são relutantes em fazer esses tipos de decisões de no início de um projeto, a menos que as estimativas dos desenvolvedores sejam confiáveis. relação de confiança com o cliente
possa vir a acontecer ao longo de um projeto. Um bom plano não garante um conjunto exato de funcionalidades em uma data exata a um custo especificado. Um plano, no entanto, deve comunicar e estabelecer um conjunto de expectativas iniciais. Muito frequentemente um plano é reduzido a uma única data e todas as suposições e expectativas que levaram a essa data são esquecidas. Suponha que um projeto foi estimado para ser desenvolvido em sete meses mas não forneceram nenhuma explicação de como chegaram neste tempo. Sem informações adicionais você não tem como determinar se foi gasto tempo suficiente nesta estimativa e pode se questionar se esta estimativa é realista. expectativas
planejamento. No planejamento ágil é balanceado o esforço e investimento no planejamento pois sabemos que vamos rever o plano ao longo do curso do projeto. Nós não queremos mudar o plano apenas por uma questão de mudança, mas nós queremos mudar porque a mudança significa que aprendemos alguma coisa ou que queremos evitar um erro. Podemos ter aprendido que os usuários querer mais uma funcionalidade a outra ou que a usabilidade é mais importante do que havia sido pensado ou que a programação na linguagem escolhida leva mais tempo do que calculado. O impacto financeiro de cada uma dessas alterações pode ser avaliada e pode alterar o plano e cronograma. planejamento ágil
que o planejamento se torna mais importante do que o plano. Só porque os planejamentos são modificáveis não significa que as datas são alteradas. Isso pode ou não ser feito. Mas se nós aprendemos que estávamos errados sobre algum aspecto do produto e é preciso fazer algo sobre isso, então o plano precisa mudar. Há muitas maneiras que podemos mudar o plano sem alterar a data. Pode-se deixar uma funcionalidade de fora, pode-se reduzir o escopo de uma funcionalidade ou possivelmente adicionar novas pessoas ao projeto. planejamento ágil
projeto em seu início e por isso é importante não executar todo o planejamento de um projeto no início. O planejamento ágil é espalhado uniformemente por toda a duração de um projeto. O planejamento do release define o ponto de partida que é seguido por um número de iterações de planejamento que é repetido quantas vezes forem necessárias em um projeto. planejamento ágil
uma resposta do produto final que deve ser construído. Ou seja: • Quais recursos o produto deve ter? • Em que prazo e com quais e quantas funcionalidades? O planejamento ágil permite saber isso, reduzindo o risco, reduzindo a incerteza sobre o que o produto deve ser ou ter, através do apoio a uma melhor tomada de decisão, estabelecendo confiança com o cliente e transmitindo as expectativas.
planejamento é que elas se concentram na conclusão das atividades em vez da entrega das funcionalidades. Um aliado tradicional a gestão de projetos é o gráfico Gantt que identifica as atividades que serão realizadas.
atividade é que os clientes não obtêm valor a partir da conclusão das atividades. Funcionalidades funcionando são a unidade de valor do cliente. O planejamento deve, portanto, estar no nível de funcionalidades e não atividades. Outros problemas ocorrem porque os planejamentos baseados em atividade muitas vezes levam a projetos que extrapolam o cronograma. Quando o cronograma é extrapolado algumas equipes tentam poupar tempo, reduzindo de forma inadequada a qualidade. Algumas das razões por que o planejamento baseado em atividades levam aos atrasos no cronograma incluem: • Atividades não terminam mais cedo; • O atraso é transmitido para o restante do planejamento; • As atividades não são independentes.
tempo para completar uma atividade quanto for permitido. Se há um gráfico de Gantt pendurado na parede que diz que uma atividade está prevista para cinco dias, o programador atribuído a realizá-la em geral garantirá que a atividade tem o total de cinco dias. Ele pode fazer isso adicionando algumas coisas extras se parecer que ela vai terminar mais cedo. Ou seja, ela pode dividir o tempo entre a atividade e pesquisas de novas tecnologias que ele pensa que podem ser útil. O que ele não vai fazer muitas vezes é terminar a atividade mais cedo. Quando um gráfico de Gantt mostra que uma atividade está prevista para cinco dias, dá permissão implícita para o desenvolvedor para gastar cinco dias para concluí-la. atividades não terminam mais cedo
tabelas ao banco de dados criar as classes DAO testar desenvolver a interface A atividade de teste será iniciada antes somente se as três atividades anteriores terminarem antes.
tabelas ao banco de dados criar as classes DAO testar desenvolver a interface Para a atividade de teste atrasar basta apenas uma das atividades anteriores atrasar.
independentes umas das outras. Por exemplo, se está sendo desenvolvida uma aplicação e a primeira janela atrasa a metade do tempo estimado, há uma boa chance de que cada uma das telas restantes também vai demorar mais tempo do que o planejado. Quando alguém atrasa no primeira entrega de itens semelhantes é comum ouvir a seguinte resposta: "Sim, eu extrapolei o prazo, mas nas próximas vezes isso não vai acontecer." Esta situação decorre da crença de que o conhecimentos adquiridos a partir da conclusão pela primeira vez permitirá que as atividades restantes que são similares serão concluídas mais rapidamente. O conhecimento real que se deve tirar de uma situação como esta é que quando uma atividade demora mais tempo do que o planejado, todas as atividades similares também são propensas a levar mais tempo do que o planejado. atividades não são independentes
de multitarefa e descobriram que o tempo que uma pessoa gasta efetivamente no desenvolvimento de algum trabalho cai rapidamente a medida que a pessoa começa a trabalhar em mais do que duas tarefas.
em que você realizou. Qual papel o planejamento teve no sucesso destes projetos? Muitas empresas confundem estimativas com compromissos. Assim que uma equipe expressa uma estimativa, eles são forçados a se comprometer com ela. Onde você trabalha ou já trabalhou isso acontece ou acontecia? As estimativas eram ou são implicitamente tratadas como datas reais de entrega? Quais problemas resultam quando o planejamento é baseado em atividades ao invés de funcionalidades entregues? exercícios
ao invés de processos e ferramentas; • Software funcionando ao invés de documentação abrangente; • Colaboração do cliente ao invés de negociação de contratos; • Responder a mudanças ao invés de seguir um plano. uma abordagem ágil
ao invés de processos e ferramentas; • Software funcionando ao invés de documentação abrangente; • Colaboração do cliente ao invés de negociação de contratos; • Responder a mudanças ao invés de seguir um plano. uma abordagem ágil Com uma compreensão das quatro declarações de valores ágeis, podemos voltar nossa atenção para o que uma equipe ágil se parece na prática.
os integrantes se vejam como uma equipe destinada a um objetivo comum. A equipe ágil de sucesso deve ter uma mentalidade de “estamos todos juntos nessa”
fases. Dependendo do processo ágil que for utilizado, pode-se trabalhar no design, modelagem, ou outras fase já bem no início do projeto. Mas, uma vez que o projeto tenha começado a sério, todo o trabalho (requisitos, design, codificação, testes e assim por diante) acontece simultaneamente dentro de cada iteração.
uma garantia de que ele irá acontecer. Na verdade, ele é apenas um palpite dado naquele instante. Muitas coisas podem acontecer e invalidar o plano elaborado. Por exemplo: • Um membro da equipe pode decidir sair da empresa; • As tecnologias escolhidas podem funcionar melhor ou pior do que esperado; • Os usuários podem mudar suas ideias com relação as funcionalidades solicitadas; • Concorrentes podem nos forçar a entregar a solução mais rápido, etc. Equipes ágeis visualizam cada mudança como tanto uma oportunidade e necessidade de atualizar o planejamento a fim e refletir melhor a realidade. times ágeis inspecionam e adaptam
estende bem além do horizonte do planejador e não inclui tempo para fazer ajustes. Equipes ágeis conseguir isso através do planejamento em três horizontes distintos que são release, iteração, e no dia atual. As relações entre estes (e outros) horizontes de planejamento podem ser vistos na figura abaixo: planejamento multinível
os três níveis mais aninhados do planejamento. O planejamento do release considera as histórias de usuários ou temas que serão desenvolvidos para uma nova versão de um produto ou sistema. O objetivo do planejamento de release é determinar uma resposta adequada às questões de escopo, cronograma e recursos para um projeto. O planeamento de um release ocorre no início de um projeto, mas não apenas no início. Um bom plano de release é atualizado ao longo do projeto (geralmente no início de cada iteração) para que ele sempre reflita as atuais expectativas sobre o que será incluído na versão. planejamento do release
conduzido no início de cada iteração. Com base no trabalho realizado na iteração anterior, o product owner identifica para a equipe as funcionalidades de maior prioridade que a equipe deve implementar na nova iteração. Uma vez que estamos olhando para um horizonte mais próximo comparado ao do release, os componentes do plano podem ser menores. Durante o planejamento da iteração falamos sobre as tarefas que serão necessárias para transformar um requisito em uma funcionalidade funcionando e testada. planejamento da iteração
usam alguma forma de standup meeting para coordenar o trabalho e sincronizar os esforços diários. Embora possa parecer excessivo considerar esse planejamento no sentido formal, as equipes definitivamente fazem, avaliam e reveem os seus planos durante estas reuniões. Durante as reuniões diárias, as equipes restringem o horizonte do planejamento para não mais do que no dia seguinte quando eles se encontrarão novamente. Devido a isso, eles se concentram sobre a programação das tarefas e na coordenação das atividades individuais que levam até a conclusão de uma tarefa. planejamento diário
expressar o tamanho total de uma história de usuário, funcionalidade ou outra unidade de trabalho. Quando nós estimamos com story points nós atribuímos um valor de ponto para cada item. O valor bruto que atribuímos não é importante. O que importa são os valores relativos. Uma história que é atribuído com dois deve ser o dobro de uma história que é atribuída com um. Ela também deve ser dois terços de uma história que é estimada como três story points. Uma estimativa em story points é uma combinação da quantidade de esforço envolvido no desenvolvimento da funcionalidade, da complexidade do seu desenvolvimento, do risco inerente a ela, e assim por diante.
é selecionar a história que espera-se ser a menor das histórias que deverão ser desenvolvidas e a ela atribuí-se o valor de 1 story point. A segunda abordagem é, selecionar uma história que parece de médio porte e dar a ela um número em algum lugar no meio do intervalo que você espera usar. Uma vez que você arbitrariamente atribuí um valor de story points para a primeira história, cada história adicional é estimada comparando com a primeira história ou a quaisquer outras que já foram estimadas.
points pode funcionar, é necessário introduzir um novo conceito: velocidade. A velocidade é uma medida da taxa de progresso de uma equipe. Ele é calculado pela soma do número de story points atribuídos a cada história de usuário que a equipe completou durante a iteração. Se a equipe completou três histórias cada estimadas em cinco story points, então sua velocidade será de quinze. Se a equipe completou duas histórias de cinco pontos a sua velocidade será dez.
iteração, o nosso melhor palpite é que eles vão completar dez story points na próxima iteração. Uma vez que story points são uma estimativa de tamanho relativo, então eles conseguirão terminar uma iteração de duas histórias estimadas em 5 story points cada ou cinco histórias estimadas em dois story points cada. Assim, uma estimativa do tamanho pode ser transformada em uma estimativa de duração.
Brasil? • Quantos barbeiros existem em Belo Horizonte? • Quantos quilos de feijão são vendidos no Brasil a cada ano? • Quantas bolas de golfe vai caber dentro de um Boeing 747?
mais perto da esquerda no eixo do esforço. Eles reconhecem que não podemos eliminar a incerteza das estimativas mas eles abraçam a idéia de que pequenos esforços são recompensados com grandes ganhos. Mesmo que eles aceitem estimativas menos precisas, as equipes ágeis pode produzir planos mais confiável, porque eles entregam pequenos incrementos totalmente testado e integrado.
uma vídeo locadora, segundo os requisitos abaixo: • Uma pequena locadora de vídeo possui ao redor de 2.000 fitas de vídeo, cujo empréstimo deve ser controlado. Cada fita possui um numero de identificação. Para cada filme, é necessário saber seu título e sua categoria (comédia, drama, aventura, ...). Cada filme recebe um identificador próprio. Para cada fita é controlado que filme ela contém. • Os clientes podem desejar encontrar os filmes estrelados por seu ator predileto. Por isso, é necessário manter a informação dos atores que estrelam em cada filme. Para cada ator os clientes as vezes desejam saber o seu nome real, bem como a data de nascimento. • A locadora possui muitos clientes cadastrados. Somente clientes cadastrados podem alugar fitas. Para cada cliente é necessário saber o seu nome e o sobrenome, o seu telefone e o seu endereço. Além disso, cada cliente recebe um numero de associado. Finalmente, desejamos saber que fitas cada cliente alugou num dado instante. exercícios Exercício original: http://www.ic.unicamp.br/~rtorres/mo410A_12s1/exec03.pdf
emiranda
hugaomarques
harunakano
gmoriki
naradai
signer
oracle4engineer
irocho
tosseto
psj59129
matleenalaakso
codeforeveryone
tammyeverts
panda_program
keathley
aarron
jponch
jnunemaker
tmm1
malarkey
bcantrill
destraynor
lara
zenorocha
