No Scrum nunca vi algo referente a custo de um projeto para analisar a viabilidade, existe algum?
Acredito que vá bem de contra ao conceito de fazer por sprint(e cobrar por eles)
Como voces fazem para ter um custo caso tenham uma proposta para um projeto Scrum?
Abraços
ffranceschi , tudo bom ?
na minha empresa eles fecham por quantidade de horas. a medida que vão sendo realizados os sprints o escopo vai se adequando a quantidade de horas aprovadas.
voce pode estudar também uma forma de calcular seus sprints usando ponto de função caso pense em uma cobrança por sprint.
att…
Oi kdoigor, obrigado pela resposta!
Tenho algumas duvidas:
Abraços
sim, as horas são “horas”. Estimativas são apenas… estimativas.
exatamente. sabe pq? simplesmente pq não importa!
em projetos de software tipicamente temos a seguinte utilizacao de funcionalidades:
Sempre 7%
Frequentemente 13%
Às vezes 16%
Raramente 19%
Nunca 45%;
por isso nos concentramos em encotrar os 20% que pelo principio de pareto geram 80%+ do valor.
Assumindo que não sabemos ao certo todos os requisitos, o prazo é móvel. De qualquer forma, para facilitar, os meus orçamentos sempre são em iterações:
“Este projeto planejamos 10 iterações de 2 semanas com 6 pessoas”
Essa é a maneira que trabalhamos com projetos aqui na Aspercom. O custo da iteração é uma métrica importante. Graças a Deus projetos de software são simples com relação a custo. Geralmente as despesas com pessoal e mais posição de trabalho já fecham a conta.
Trabalhamos com projetos de escopo negociável: Renegociamos a cada mês o escopo, o Backlog é a maior autoridade com relação ao andamento do projeto, damos uma previsibilidade sobre quantas iterações ainda temos para finalizar o projeto (baseada em story points e velocidade). O benefício para o cliente é que ele não paga qualquer gordura e recebe a solução ao fim de cada iteração com qualidade constante.
@orlandocn
Concordo com vc sobre as informações sobre a estatística que passou (vi em uma palestra na TDC)
mas a minha realidade aqui é um pouco diferente… (explicarei abaixo)
@rodrigoy
Ae Rodrigo pokerman blz?
Voce conhece um pouco mais da realidade onde trabalho já que tivemos curso com voce (inclusive gerentes de outras areas e a diretoria participaram e gostaram bastante, muito bom), mas agora estamos com um problema sobre estudo de viabilidade de projeto. Temos o software “pronto”, mas pra alguns clientes é necessárias particularidades que estão sendo tratadas como projetos a parte. Cada um desses projetos tem um escopo fechado (acredito que esse chega o problema) e precisamos dar um custo é um prazo pra esse projeto, para o nosso PO possa decidir se é viavel ou não o projeto, assim poder tomar qualquer decisão.
Pelo que entendi, voce estimar seu backlog todo antes (BDUF), conseguindo chegar num “prazo” e custo (os dois variando com o escopo), mas o tempo de estimativa desse backlog, voce deve incluir no custo do projeto tb certo?
Agradeço as respostas!
Abraços
Fernando Franceschi
Então, no meu penúltimo projeto tínhamos uma “metodologia” de custos bem parecida com isso. E não usávamos Scrum, XP e nada disso. Na verdade era usada (tentávamos) usar a metodologia do cliente (um Waterfall safado fantasiado de RUP).
O que foi feito foi dividir todo o projeto em projetos menores, de 2 a 8 semanas, e quem definia o escopo deste projeto era o cliente.
Cada subprojeto era estimado, entregue e cobrado separadamente. E teoricamente o cliente podia a qualquer momento abortar o projeto sem perder o que já tinha recebido.
Esta foi uma forma de sermos “ageis” dentro do processo Waterfall do cliente.
Vale deixar registrado que este “processo” não foi desenhado pensado em ser agile, e não tínhamos nenhuma pratica agile. Mas de alguma forma eramos ageis. Na verdade este agile de bandeira branca foi uma conclusão em comum entre fornecedor e cliente para reduzir os riscos de um projeto arriscado e critico.
ffranceschi
respondendo as suas perguntas:
cara na minha empresa o problema é a parte de vendas, é um outro pessoal que vende e vc nunca sabe o que eles vendem e a gente tem q tentar encaixar o que dá no valor da venda.
o grande lance é o forte envolvimento com o cliente, por questões de escopo e até futuros contratos no mesmo ou em outro projeto. ele ta pagando, ele manda o que prioriza ou não e ai vc encaixa no sprint.
att,
[quote=ffranceschi]
No Scrum nunca vi algo referente a custo de um projeto para analisar a viabilidade, existe algum?
Acredito que vá bem de contra ao conceito de fazer por sprint(e cobrar por eles)
Como voces fazem para ter um custo caso tenham uma proposta para um projeto Scrum?
Abraços[/quote]
Voce tem um problema em estimar o custo (quanto dinheiro vc precisa investir até está pronto) ou em definir o preço ( quanto dinheiro pedir do cliente) ?
Suponho que como vc não é gerente seu problema não é definir o preço e sim estimar o custo.
Primeiro vc tem que saber o que é custo. De onde ele vem ? Vem do tempo que os desenvovledores/ gerentes /fachineiros /etc… taballham para o projeto, mais da energia que é consumida, mais taxas de iptu e outras coisas que vc tem que pagar enquando usa o edificio onde trabalha, etc…
Hum… acho que não é isso que vc quer saber… vc quer saber o bom e velho “quando tempo vai demorar” . Certo ?
Se vc já tem o escopo “fechado” (estou entendo como delimitado e não como “escrito na pedra”) e se vc já estimou os story points das estorias e sabe a velocidade da sua equipa (Sabe?) então vc só precisa saber quantos sprints vai precisar.
Digamos que vc tem 3000 pontos e a sua equipa tem velocidade de 60 pontos por sprint. E que seu sprint é de 3 semanas.
Vc irá precisa no minimo de :
3000 / 60 = 50 sprints
50 * 3 semanas / sprint = 150 semanas
Agora, lembre-se que vc está estimando. Leve em consideração o cone de incerteza. Tenha em atenção que irá precisar se sprints apenas para corrigir bugs (jogue 1 sprint destes a cada 4 sprints normais, que no caso dá mais ou menos 12 sprints).
VC vai chegar em , digamos, 200 semanas. Agora passe isso para horas, 200 semanas X 5 dias x 8h = 8000h
É só um exemplo. Substitua pelos valores reais. Não ha nenhum mistério.
coisas que podem afetar a estimativa é principalmente o tamanho do backlog e a velocidade efetiva da equipa.
Se forem aceites mais coisas no backlog no meio do projeto isso ,claro, aumentará o tempo necessário.
Se a equipa mudar (pessoas que saem, entram, etc…) isso afetará a velocidade e portanto os sprints necessários e por consequencia o tempo.
Na realidade o scrum master é que deve ajudar o product owner a fazer estes calculos, não a equipa. A equiap já fez sua parte estimando os story points.
Se vc quiser refinar mais e diminir o risco, vc pode tentar partir as estorias mais complexas em tarefas realizáveis e estimar essas tarefas e verificar que o numero de horas é compativel com os SP que foram outorgados. Ah! ,claro, estou partindo do principio que os SP foram dados no estilo planning poker. Se não foram, refaça as estimativas usando essa técnica.
Outra opção é fornecer estimativas de story points já com um desvio associado. Em vez de dizer a estoria A são 13 pontos, diga “a estoria A deve ser entre 5 e 20” pontos.
Para mais detalhes leia Agile Estimation and Planning
Realmente bem interessante o livro, alias, eu comprei ele há 1 mes atras na amazon, e ele tá pra chegar no começo do mes que vem…
[offtopic]
Quem quiser organizar os livros tem um site bem legal… http://www.shelfari.com , O meu é http://www.shelfari.com/ffranceschi
[/offtopic]
@kdoigor, @peczenyj , @sergiotaborda
O que não vejo como escapar, é “analisar” TODO o projeto para depois passar uma quantidade de horas (alguem ve outra forma?). Acredito que essa estimativa, tem grandes chances de dar errado, já que sempre existirão mudanças.
Abraços
Do ponto de vista ágil, este artigo coloca uma visão interessante http://blog.dtisistemas.com.br/como-orcar-um-projeto-agil-2/.