Software Estimation - A Step Closer to the Silver Bullet
•
0 likes•935 views
Este documento discute técnicas e conceitos para estimativas de software, incluindo: (1) Contar tarefas e histórias de usuário para calcular estimativas iniciais; (2) Calibrar estimativas usando dados históricos de projetos anteriores; (3) Estimativas individuais por especialistas e em grupo para obter vários pontos de vista.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (12)
Similar to Software Estimation - A Step Closer to the Silver Bullet
Similar to Software Estimation - A Step Closer to the Silver Bullet (20)
More from João Pedro Martins
More from João Pedro Martins (8)
Software Estimation - A Step Closer to the Silver Bullet
- 1. SoftwareEstimationAStepClosertotheSilverBullet JoãoPedroMartins http://www.sharepointpt.org/ 27ª Reunião - 13/04/2013
- 3. OMétodo DEVELOPER.COM“PROJECTESTIMATIONGEOMETRY”(2007) 5. Estimar 4. Decompor 3. Considerar tarefas produtivas - spec, dev, test 2. Comparar com projectos semelhantes 1. Avaliar complexidade global (“feeling”) Somar e multiplicar por 2,6x
- 4. agenda Definição Como fazemos Conceitos Técnicas ideias, questões, troca de experiências
- 5. 2. A preliminary calculation of the cost of a project (Source: The American Heritage Dictionary, Second College edition, 1985) 1. A tentative evaluation or rough calculation Estimativa–Umadefinição 3. A judgment based upon one’s impressions; opinion Objectivo ≠ Compromisso ≠
- 6. Bons planos dependem de boas estimativas EstimarvsPlanear CONCEITOS Estimativas são a base de planos. Mas podem ser diferentes! Cronograma Priorizar Histórias Planear Sprints Planear Releases Backlogs Work Breakdown Structure Planear Parcial Processo orientado a objectivos Estimar Processo Analítico Imparcial
- 7. Umaquestãodeprobabilidades ¾ projectos excedem estimativas A cada estimativa está sempre associada uma probabilidade
- 8. A good estimate provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets Estimativas,planeamentoecontrolo CONCEITOS
- 9. [The common definition of estimate is] “The most optimistic prediction that has a non-zero probability of coming true”… Accepting this definition leads irrevocably toward a method called what’s-the-earliest-date- by-which-you-can’t-prove-you-won’t-be-finished estimating. -Tom DeMarco Ovalordeumaestimativaprecisa CONCEITOS sobre-estimar subestimar vs
- 10. …thesadtruth The Standish Group, “Chaos Report” “The Rise and Fall of the Chaos Report Figures” (IEEE Software 2010)
- 11. Asorigensdaincertezanasestimativas CONCEITOS Imprecisões no processo de estimativa Dinamismo no projecto Informação sobre o projecto Informação sobre a organização Diferenças na produtividade individual Inexperiência nas tecnologias ou processos a usar
- 12. ConedaIncerteza BARRYBOEHM&STEVEMCCONNEL Represents the best case accuracy of an estimate Representa a Variabilidade em Esforço, Custo e Funcionalidades 30%
- 13. 1.ContarCalcular DEPOISDATEMPESTADE… Calcular Contar Relacionado com tamanho do âmbito Fácil de contar Converter contagem em estimativas * d = Usar dados de histórico
- 14. Contar(exemplo)
- 15. 2.Calibraçãocomdadosdehistórico Ser consistente Durante sprints ou logo após projectos! % Esforço/fase Esforço/história Esforço/complexidd Esforço/página Defeitos/complexidd Duração/esforço Esforço/LOC’s Dados da Indústria Empresa Projecto Uso tem correlação inversa com desvios >< Start Small & Start Today 12-4-13
- 17. 3.EstimativaIndividual porEspecialistas Estimador é quem for desenvolver Mais usado Mais falível 83% analogia informal Medir % Erro 𝒓𝒆𝒂𝒍 − 𝒆𝒔𝒕𝒊𝒎𝒂𝒅𝒐 𝒓𝒆𝒂𝒍 Checklist de apoio estimativa Estimar em intervalos 𝟐, 𝟑, 𝟓 Decompor e Recompor
- 18. 4.EstimativaporGruposdeEspecialistas Pontos complexida- de (ou horas) Especialmente útil no início processos Calibrado contra história + simples Estimar Discutir Consolidar ≠média Planning Poker Envolver 3-5p na estimativa
- 19. 5.DecomporeRecompor Granularidade conforme estado projecto Decompor tarefas Estimar Recompor Work Breakdown Structure Lei dos Grandes Números ∞
- 20. 6.Analogia(comexperiênciapassada) Comparar para cada dimensão com projecto passado (%) Obter métricas de projecto passado Pode ser impreciso por inconsistências Decompor tarefas Por WBS, área funcional, etc. Calcular com base na comparação Identificar projec- to semelhante
- 21. Analogia(exemplo) Cenário Esforço Estimado (d) 1. Alocação full-time até Data X (previsão 80% âmbito) 1200 2. Alocação full-time até Data X+Y (prev. 100% âmbito) 1820 3. Projecto Indústria A - Sprint mais complexo 1310 4. Projecto Indústria A - Todos os Sprints 978 5. Projecto Indústria B – esforço 3371 6. Projecto Indústria B – capacidade 1650 7. Projecto Indústria C 3336 8. Projecto X – Amostragem Épico 2224 9. Projecto X – Amostragem Tema 2186 Cenário Informação Esforço Estimado (d) Todas as estimativas Intervalo Estimativas 978-3371 (σ 820d, 345% var) Média de estimativas 2008 Aplicação de cone de incerteza “padrão” (0,6 a 1,6x) *assumindo ponto central = estimativa correcta 1935 Excluindo 2+ pess/opt Intervalo Estimativas 1310-2224 (σ 341, 170% var) Média de estimativas 1837 Aplicação de cone de incerteza “padrão” (0,6 a 1,6x) 1675
- 23. ConclusõeseTPC 3- Criar template p/ estimativa (ch.10) 1- Comprar 2- Ler avidamente 4 - Criar template p/ dados histórico Planning Poker Minimizar Subjectividade Engº Software
- 24. ideias,questões,trocadeexperiências Quetécnicasusam? Queobstáculossentem? Existeinterferência deGestão?Como? Quaisasmaioresdificuldadesactuais?
- 25. Obrigado! João Pedro Martins CTO @ |create|it| 96 782 5537 mail/msn: jota@create.pt blogit.create.pt/blogs/joaomartins/ @lokijota Hugo Lopes COO @ |create|it| 96 417 6630 mail/msn: hugo.lopes@create.pt
- 26. 27 Referências Livros http://www.amazon.co.uk/Software-Estimation-Demystifying-Black- Art/dp/0735605351(SteveMcConnell) http://www.amazon.co.uk/Agile-Estimating-Planning-Robert-Martin/dp/0131479415 (MikeCohn) Estudos http://sunset.usc.edu/csse/event/2008/cocomoicm08/presentationByDay/Tues_Oct2 8/4_CIIForum08-YANG.ppt http://it.toolbox.com/blogs/enterprise-solutions/effort-distribution-across-the- software-lifecycle-6304 http://www.cs.vu.nl/~x/chaos/chaos.pdf(ControvérsiasobreChaosReport) Blogs http://blogs.construx.com/blogs/stevemcc/default.aspx http://scrum.jeffsutherland.com/ http://www.jrothman.com/blog/mpd/ /43
Editor's Notes
- “O tipo que não faz apresentações com visual studio. Tenho uma demo espectacular baseada em Excel.” Explicar que foi feito a pedido de um cliente, que depois foi melhorada para a Netponto e teve mais revisões agora para SharePoint. A sensação que eu tive quando terminei foi, “eu gostava de ter aprendido isto quando acabei o curso do técnico em 95. Isto falta na formação de um engenheiro de software”. Perguntar: Quem é que daqui faz estimativas? Já algumas vez leram algum livro de técnicas de estimativas? Que metodologias é que usam? Lei das estimativas #1 – nunca vamos aceder nas estimativas a 100%. O que pretendo mostrar é um conjunto de técnicas para reduzir o erro de estimativas, e convencer-vos de que isto é mesmo importante para qualquer engenheiro de software.
- Sou CTO e Arquitecto na Create It, faço muitas estimativas. Apresentação sumária da empresa. Ano de fundação e idade, número de pessoas, áreas estratégicas de aposta tecnológica.
- Há uns anos atrás encontrei no Developer.com um artigo sobre técnicas de estimativas que achei muito instrutivo, e que depois recuperei para a apresentação. 1- avaliar complexidade: parece simples? Complexo? É um site simples? tem integração? 3- pegar em tarefas produtivas, que são o trabalho de um engenheiro de software. Depois somar tudo, e multiplicar por 2,6. Este artigo chamou a atenção porque temos um cliente que trabalhamos desde o início da empresa, para quem este factor era 3, com erro inferior a 10%. Ultimamente já não medimos isto, mas acredito que seja semelhante. Aprendemos com o tempo que todas as outras tarefas, desde GP, a instalações, estabilização, análise, etc. era 2,6x este tempo. http://www.developer.com/mgmt/article.php/11085_3698696_2/Project-Estimation-Geometry.htm
- Definção e Conceitos, a parte de glossário e ideias base, depois dar-vos as ferramentas para fazer GP, e depois dizer-vos de como fazemos. É importante referir que se trata daquilo que para nós funciona, não pretende ser uma receita universal, e é muito inspirado no livro do mike cohn – agile estimation and planning para quem está mais em scrum, e o livro do steve mcconnel que vale o seu peso em ouro.
- (passar logo os 4 primeiros slides) Isto é o que diz o dicionário. Temos tendência a ver como um Objectivo, ou pior ainda, que um Compromisso. Uma Estimativa é algo que tem um PROBABILIDADE de ser cumprida. Não devem deixar que especialmente a Gestão de Projectos veja uma estimativa como um compromisso.
- Estimar é um processo analítico que deve procurar ser preciso. Planear é pegar na estimativa e colocar num calendário para dizer quando vai estar pronto, orientado a Objectivos, a datas. Uma vez tive um projecto para tv interactiva que era um canal de astrologia, e se não fosse para o ar em março já só podia ser em Setembro porque as estrelas não traziam bons augúrios.
- ¾ dos projectos excedem. Têm essa noção? Os bonecos são do livro do mmconnel. Imagem topo 1 - Temos tendência a ver uma estimativa assim, como uma linha vertical. Topo 2 – isto seria mais razoável, como um anormal em torno de um valor mais provável. Topo 3 – mas existe um valor mínimo, certo? E na prática as tarefas podem alongar-se muito para o futuro, pelo que na realidade temos algo como isto. Convém ter este gráfico de probabilidades presente, porque geralmente é disto que temos nos projectos. A figura de baixo mostra outra forma de representar o gráfico de cima. A barra vertical representa o ponto nominal: 50% de chance de projecto terminar melhor, e 50% chance de terminar pior. “median outcome” A figura de cima mostrava a probabilidade de entregar numa determinada data. A segunda mostra a probabilidade de entregar em cada data ou mais cedo. “The probability of a sw project delivering on or before a particular date (or less than or equal to a specific cost or level of effort) ALL SINGLE POINT ESTIMATES ARE ASSOCIATED WITH A PROBABILITY, EXPLICITLY OR IMPLICITLY
- Todos conhecemos estes triângulos, são muito parecidos. O 2º é proposto por uma senhora chamada johanna rothman, a forma de ler é imaginar que mexemos no ponto central e vemos as implicações nas várias dimensões. São gráficos na prática equivalentes. http://www.jrothman.com/blog/mpd/2003/04/describe-project-tradeoffs-project-constraints-and-project-requirements.html Quando fazemos uma estimativa, e no exemplo estão ali 20 meses, e depois fazemos um planeamento com base nela, temos de levar em consideração todos os vários factores que ali estão, os imponderáveis, e mesmo com tudo isto, temos de conseguir dar nos mesmos 20 meses que estimámos. Olhando para isto, é muito fácil ver que vamos parar nos tais ¾ de projectos com atrasos. Não me parece que a maioria de nós pense nestas coisas quando faz estimativas. Isto a mim parece-me quase impossível! O quadrado final é só no sentido de a estimativa dever informar a gestão de projecto para a permitir tomar boas decisões tanto no início como no decorrer do projecto.
- O Tom DeMarco é um dos autores do peopleware, e vou-vos dar tempo para ler. Ou seja, assumimos como probabilidade o valor mais curto em que acreditamos que pode ser possível. Isto deve ser a visão mental de que O que é pior? Sobre-estimar ou sub-estimar? Sub-estimar implica que no decorrer do projecto vamos cortar em tudo o que pudermos para tentarmos que caiba no valor que o cliente contratou! A penalização é não linear, em número de defeitos, noitadas, cortar em documentação, etc. Com sobre-estimativa, o erro é linear, tem a ver com a dimensão da equipa x o tempo que está alocada. Aplica-se aqui a lei de Parkinson: Se souber que tenho de fazer uma apresentação para amanhã, vou focar-me nisso a 200%. Se souber que é para daqui a um mês, se calhar entretenho-me com outras coisas e vou fazendo muito mais devagar e de forma menos produtiva, vamos usar o tempo todo disponível.
- Standish – recolhem métricas de centenas de projectos. Late/Overbudget mas acabou. Assustador que 20% não acabem, e que acabados com sucesso sejam ~30%. O Standish não publica as regras de como contabiliza, por isso não é claro se a introdução de um novo requisito a pedido do cliente, que é estimado e implementado no que foi estimado, resulta num verde ou num azul. We obtained data from Todd Little of Landmark Graphics, which he reported in IEEE Software, consisting of 121 software development projects carried out from 1999 to 2002. Little provided 923 distinct forecasts that predict these 121 projects’ duration. Se se investigar sobre este 2º relatório, vão provavelmente encontrar este outro artigo muito interessante, que olha criticamente para os dados do chaos report, e que apresenta dados como estes. Na horizontal é do início ao fim do projecto, na vertical é o forecast/actual. Como estão valores abaixo de 1, significa que na grande maioria dos casos o actual é maior que o previsto. Ou seja – geralmente, subestimamos.
- 1 – sabemos pouco 2- sabemos pouco sobre a nossa organização. Quem vai fazer, quem está de férias, quem vai poder fazer o projecto 3- alteração de requisitos 4 – Há vários métodos de estimativa, por exemplo estruturado e não estruturado, que têm erros como 210 ou 170% (referidos no mcconnel), e o processo que seguem tem erros diferentes associados. 1-4 são os mais importantes
- Isto é a materialização da regra #1 de estimativas, de que nunca podemos acertar. Explicar a imagem de fundo é o trajecto de uma tempestade tropical, desde onde começa até aos próximos dias. À medida que se afasta deixamos de saber ao certo onde está. Quando mais longe está, mais a incerteza. Houve dois senhores (mencionados no topo) que aplicaram isto à eng de software. Quando estamos no início do projecto, o erro de estimativas pode ser de 0,25 a 4x. Quando avançamos no tempo, reduz o erro para o esforço que falta. A partir dos 30%, a taxa de erro já está em valores relativamente baixos, só é preciso chegar ali pouco à frente da especificação de requisitos. Voltando aos dados do outro estudo, que no slide anterior eram para um único projecto, este tem os dados de todos os projectos, e… parece haver aqui uma relação. Notar que há muitos erros por cima e muitos erros por baixo. Barry Boehm’s now-famous cone of uncertainty Variability in the Estimate of Project Scope (effort, cost, features) http://en.wikipedia.org/wiki/Cone_of_Uncertainty
- 1º contar e 2º calcular. Tenham isto sempre presente. Mais usado quando estamos no início de projectos. Contar: alguma coisa que esteja relacionado com a dimensão do projecto. Páginas, sistemas a integrar, requisitos, etc. Fácil de contar. Calcular: multiplicar as contagens por uma estimativa unitária. E para determinar o D? este é um dos dados mais importantes. Se os vossos GP não têm, deviam ter. ---- Contar size, features . Usar desde o início ao fim do processo. (early-end) Calcular size, effort, schedule, features (early-middle) Pode usar-se do início ao fim do processo, com granularidade evolutiva. Tips Count if at all possible. Compute when you can’t count. Use judgement alone as a last resort. Look for something you can count that is a meaningful measure of the scope of work in your environment Collect historical data that allows you to compute na estimate from a count Don’t discount the power of simple, coarse estimation models such as average effort per defect, average effort per web page, average effort per story, project management to development time Avoid using expert judgement to tweak an estimate that has been derived through computation. Such “expert judgement” usually degrades the estimate’s accuracy. Count Find something to count that is highly correlated with the size of the software you’re estimating Find something to count that is available sooner rather than later in the development cycle … that will produce a statistically meaningful average (at least 20 things to count) Understand what you’re counting (usar mesmos critérios de informação de histórico) … you can count with minimal effort Computation Use it to convert counts to estimates Use historical data if available (ex: nº médio de horas por requisito, par dev/testes, etc.; esforço médio por use case; esforço médio por report; esforço médio por história; defeitos por linha de código, etc.) [Expert] Judgement Use only as a last resort Least accurate Never use it instead of computation + historical data. Subjective, biased “Feeling de quanto vai demorar”
- 30 ou 40 páginas disto, sem descrições textuais. Como é que estimamos isto? (perguntar) Contei as caixas, e contei as transições (integrações). Cx = 1, Tx = 2, somei em pts complexidade, assumi que 1 ponto = 3 dias, e foi só multiplicar. As partes de gestão foram de estimadas de uma forma mais tradicional. Isto deu-nos uma estimativa ainda com um erro relativamente grande, mas foi a estimativa possível. Viemos a ganhar este projecto, e acabámos por constatar que 3d tinha sido optimista, que seriam mais 4d na realidade. D, foi um valor sem histórico, foi “feeling”, e errou.
- Recolher isto não é trabalho vosso, mas de um GP. A desafiar seria começar na 2ª-feira, criar um Excel e começar a recolher estes dados. Ser consistente – medir sempre a mesma coisa. Ao medir velocidade, por exemplo, usar valores unitários por pessoa por causa da dimensão da equipa. Callibration with Industry-average data - Menos qualidade, início projectos Organizational data - Mais qualidade que anterior, usar início projectos Project-specific data - Mais qualidade, usada mais tarde nos projectos Callibration Used to convert counts to estimates – LOC’s to effort, stories to calendar time, etc. Callibration using data makes up the second piece of the “count, then compute” approach Permite aumentar a precisão de uma estimativa O seu uso está negativamente correlacionado com cost+schedule overruns Tips Use historical data as the basis for your productivity assumptions. Your org’s past performance is your best indicator of future performance. Use historical data to help avoid politically charged estimation discussions arising from assumptions like “my team is bellow average” Start collecting small, be sure you understand what you’re collecting, and collect the data consistently Collect asap after the end of the project As a project is underway, collect historical data on a periodic basis so that you can buikd a data-based profile of how your projects run Use data from your current project to create highly accurate estimates for the remainder of the project If you dont have it, start collecting it as soon as possible What to collect? If you are starting: Size (locs?) Effort (staff months) Time (calendar months) Defects (classified by security) E ainda: histórias ou pontos de complexidade por unidade de tempo e dimensão d eequipa
- Ascending trend for Code Descending trend for Test Projectos chineses feitos para clients chineses Trans = Operacionalização. Estes valores são pouco intuitivos, não são?
- São dados de projectos chineses.
- “Se virem o House, ele falha 3 ou 4x antes de acertar. Ele pode ser um génio, mas não é assim que queremos gerir os nossos projectos.” Para reduzir o erro do método: Quem estima é que desenvolve Intervalos [* isto surgiu de uma conversa com uma pessoa da MS]. Isto vai servir para uma ponderação. O Mc sugere dar 4x o peso ao valor provável, calcular a média ponderada, e depois somar um factor associado ao desvio padrão. Só o passar a usar isto, vai dar um salto enorme à qualidade das vossas estimativas Checklist - pode ser o próprio template de estimativa Medir % de Erro para poder melhorar o processo Decompôr e Recompôr (outra técnica que vou descrever mais à frente) Técnicas Use of estimation checklist (a template!) Estimating task effort in ranges (best case, worst case, most likely case) Comparing task estimates to actuals Método mais usado na prática de longe 83% dos estimadores usam “informal analogy” as their primary estimation techniqut Mas o judgement é o método mais falível. Há estudos que até dizem que conhecer a experiência na actividade não aumenta a precisão da estimativa. Então o que fazer? Decompôr, mesmo quando não conhecemos bem as tarefas (ex: “migração de dados”) Estimar em ranges Expected = (best + likely*4 + worst)/6 ou até Expected = (best + likely*3 + 2*worst)/6 Checklists Estão cobertas todas as áreas de funcionalidade? Todos os tipos de tarefas? foi estimado por quem vai desenvolver? Etc. Comparar com actual Magnitude of Relative Error (MRE) = (actual-estimated)/actual. Quanto maior, pior. Tips To create task-level estimates, have the people who will actually do the work create the estimates Use na estimation checklist to improve your individual estimates. develop and maintain a personal checklist to improve estimation accuracy. Compare actual performance to estimated performance so that you can improve your individual estimates over time And set up a feedback loop to improve your process
- É um refinar da abordagem anterior. A teoria diz 3-5 com perfis diferentes. Na prática fazems com 2p em fase comercial, e a dimensão da equipa técnica durante projecto. No Planning poker calibra-se, 1=tarefa mais simples. Pontos complexidade (product backlog) ou horas (sprint backlog). http://www.codinghorror.com/blog/2007/10/lets-play-planning-poker.html http://msdn.microsoft.com/en-us/library/hh765979(v=vs.110).aspx Tipos: Group reviews Cada membro estima tudo por si e depois compara-se e chegam-se a consensos (não é calcular médias!) Quantos? 3-5 com diferentes backgrounds. Wideband delphi Processo estruturado mais pesado e moroso, com anonimidade nas estimativas, votos Planning Poker is a form of the estimation technique known as Wideband Delphi Useful for early in a project or for estimating large unknowns Planning Poker (muito usado em agile) Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again. Mike Cohn summarizes story points best: “Story points are a unit of measure for expressing the overall size of a user story, feature or other piece of work. ” Story points tell us how big a story is, relative to others, either in terms of size or complexity. Mike often refers to “dog points” when helping teams understand the concept of relative sizing. A 2-point (small) dog would be a Chihuahua. A 13-point (big) dog would be a Great Dane. With those two guides in mind, it’s fairly easy to size the other dog breeds relative to a Chihuahua or Great Dane. A Beagle, which is about twice as big as a Chihuahua, might be a 5. A Labrador, which is bigger than a Beagle but smaller than a Great Dane, might be an 8. When you are first learning to use story points, your team will need to establish your own fixed comparison points. To do this, choose a story from your product backlog you can all agree is small (either in terms of size or complexity) and one you all agree is huge. I like having my small story be a two-point story because, if I need to go smaller (say I discover a Toy Chihuahua), I can. If I limit my smallest known story to a one-point story and I need to go smaller, I’m in trouble. The other stories can then be sized relative to these. Story points are relative values, not fixed. There is no direct correlation between hours and points. For example, we cannot say with any degree of certainty that a two-point story is equal to 12.2 hours because stories in the two-point range will vary greatly in how many actual hours it takes to complete them. Similarly, you cannot compare one team’s story points with another’s with any degree of certainty. Story points are created by and are specific to the team that estimated them, will likely include a degree of complexity that is understood only by the team, and are not absolute. Because planning poker expresses estimates in points, it is ideally suited for estimating the product backlog. The sprint backlog, however, should be estimated in hours. That being said, planning poker can and has been used successfully to estimate sprint backlogs; the numbers on the card, though, become hours, rather than points. So, simple rule – Product backlog estimates are in points. Sprint backlog estimates are in hours. You can use planning poker at the beginning of any project and throughout its lifecycle as new information reveals itself, priorities change, and clarity surfaces.
- Lei dos grandes números – se somar muitos factores pequenos, o valor de média vai acabar por estabilizar. Por exemplo com dados, estabiliza ali perto do 3,5 . Nas estimativas, partindo, por vezes erramos p cima e outras p baixo, e os efeitos cancelam-se. Decompôr uma tarefa em tarefas mais pequenas, estimá-las, e depois recompô-las numa estimativa agregada. Prática frequente. (statistical) Law of large numbers If you create one big estimate, the estimate’s error tendency will be completely on the high side or completely on the low side. But if you created several smaller ones, some estimates will be on the high side and others on the low side, and errors will tend to cancel each other to some degree. This works in theory and in practice. E devemos estimar com que granularidade? Olhando para a escala do cone de incerteza, faz sentido que à medida que avançamos no projecto estimemos a uma granularidade menor porque sabemos mais Use a generic software-project WBS to avoid ommiting common activities (já temos na nossa template) TPC: ir para casa, ler o capítulo 10 e criar a vossa template de estimativas
- Accuracy: medium Criar estimativas para um projecto por analogia com um projecto semelhante no passado Para melhorar qualidade, essencial partir esta analogia por área (ex: WBS, área funcional, etc.), com pelo menos 5 categorias. Passos: Get detailed size, effort, and cost results for a similar previous project Compare the size of the new project to a similar past project (ex: nº tabelas bd, nº páginas, regras, gráficos, reports, etc.) e com isto determinar factores de multiplicação Build up the estimate for the new project’s size as a percentage of the old project’s size Create and effort estimated based ont he size of the new project compared to the previous project Check for consistent assumptions Fontes de inconsistência: Se os projectos forem de tamanhos muito diferentes não se aplica a analogia Diferentes tecnologias Dimensão da equipa Tipo de aplicação a construir Tip - Do not address the uncertainty by biasing the estimate. Address uncertainty by expressing the estimate in uncertain terms. (intervalos de estimativa)
- 457 histórias * 2 pessoas * 5 minutos por história = 9 dias de planning poker Caracterizar o pedido – foi fornecida muita informação, muito detalhe, alguns screenshots. Explicar porque foi impossível fazer estimativa detalhada. Conclusão – com este intervalo não temos condições para ir ao projecto. Apresentámos estes dados ao cliente, explicámos porque não podíamos estimar detalhadamente, propusemos um modelo alternativo, e o cliente adjudicou. Quando fiz a apresentação do netponto ía no sprint 14, agora vai no 27.
- O Excel da demo está todo no capítulo 10 do Livro do Software Estimation. É só copiar as fórmulas.
- Nos próximos projectos em que estejam, olhem à vossa volta e tentem perceber o que funciona bem, o que funciona mal, os que vos faz correr e aos vossos pares E leiam o peopleware.
- http://www.jrothman.com/blog/mpd/2011/11/estimating-the-unknown-dates-or-budgets-part-1.html 1.Never, ever, ever provide a single date for a project or a single point for a budget without a range or a confidence level.