Percebam o meu problema, vc´s estão cobertos de razão, estimar sem
base histórica é advinhação e chutômetro, isso é indiscutível.

Por favor, me permitam contar um pequeno histórico para
contextualizar. Existiam dois recursos, antes de eu ser alocado no
projeto, e acreditem, há quase dois anos, eles vinham dando prazos,
que eram quebrados constantemente. Os dois foram promovidos ao
mercado, e eu cheguei dois meses depois, herdando um código, como
diria nosso querido ex-ministro Magri, imexível, e acrescento,
instável, não documentado, com cursores para triggers, entre outros
absurdos.

Infelizmente isso tem se tornado mais normal e frequente comigo,
herdar bombas para refazê-las de forma descente, foi assim na
Petrobrás, Embratel, Accenture, e agora de novo :-(

Então expus pra diretoria a situação real do projeto, me embasando em
artigos técnicos e bom censo, e eles viram que perderam de fato dois
anos e que íamos fazer da maneira certa, só que dessa vez, não pode
haver um furo na estimativa, por que, trazendo para o contrato que
irá ser assinado, este não permite aditivos, se estourar o prazo, vou
trabalhar voluntariamente até acabar.

Pra ajudar, nesse meio tempo, eles contrataram um "recurso" que está
mais preocupado com o resultado da bolsa de valores do que com o
projeto.

Sinuca de bico hein? Por um lado eu quero muito que esse projeto
termine bem, mas entra a minha parte racional e me diz
constante "veja só onde vc se meteu".

Desconsidero a frase "de bom conselho o inferno está cheio", antes
conto com a experiência dos senhores da lista.

--- Em scrum-brasil@yahoogrupos.com.br, "Rodrigo Yoshima"
<rodrigoy@...> escreveu
>
> Marcio, a melhor métrica no primeiro Sprint é Toyotizar.
Simplesmente
> pergunte para a equipe:
>
> "Das primeiras estórias que temos no nosso backlog priorizado, o que
> vocês conseguem me entregar até o final do sprint?"
>
> Faça a equipe chegar num acordo, some os pontos dessas estórias e
você
> terá a primeira estimativa de velocidade. O problema que vejo com
APF
> e UCP é exatamente este. Geralmente é aplicado uma "base histórica
> duvidosa" para se chegar na estimativa de tempo e a equipe como um
> todo sequer participou no processo. A equipe não faz a métrica
> acontecer se ela própria não concorda com ela.
>
> Não me lembro direito o termo que o Schwaber usa, acho que é
> "self-commitment". Mas uma das regras do contrato do Scrum é que a
> Equipe dá o prazo. É isso que faz a métrica ágil do Cohn funcionar.
>
> Abraços!
>
> Rodrigo Yoshima
> ASPERCOM
> 2008/7/12 Marcio Garcia <marcio.mangar@...>:
> > Ola Marcello!
> >
> > No projeto que estou trabalhando aqui na empresa, estamos
utilizando as
> > Estimating Meetings para ter uma idéia de quando o projeto
acabará.
> >
> > O problema dessa abordagem, que já enfrentamos, é definir a
velocidade do
> > time.
> >
> >
> > Alguem da lista ve algum problema nessa abordagem?
> >
> >
> >
> > 2008/7/12 Marcello Felipelli <marcello.v.felipelli@...>:
> >>
> >> Tales,
> >>
> >> Eu vou pesquisar mais sobre wideband delphi, se vc me sugerir
> >> materiais de estudo, ficaria extremamente grato.
> >>
> >> Obrigado!
> >>
> >> Marcello
> >>
> >> --- Em scrum-brasil@yahoogrupos.com.br, Clavius Tales (Fortes
> >> Informática) <tales@> escreveu
> >>
> >> >
> >> > Oi, Marcello.
> >> >
> >> > UCP tem uma lógica geral razoável, mas peca em um ponto
essencial:
> >> classificar todos os casos-de-uso apenas em Pequeno, Médio ou
Grande.
> >> Essa granularidade, altíssima, é obviamente ridícula. Além disso,
> >> peca também nos tais Fatores de Ajuste, ao aplicá-los
> >> igualitariamente a todos os casos-de-uso, coisa que em geral
> >> acontece, mas nem sempre. De qualquer forma, se pode tirar
algumas
> >> idéias interessantes do modelo e fazer adapatações.
> >> >
> >> > APF a princípio parece melhor que UCP, mas requer detalhamento
> >> excessivo no início do projeto, além de cair nos mesmos erros de
UCP.
> >> >
> >> > Os agilistas normalmente preferem wideband delphi com algumas
> >> adaptações. Não consigo imaginar nada melhor que isso.
> >> >
> >> > Um abraço.
> >> >
> >> > Tales
> >> >
> >> > ----- Original Message -----
> >> > From: Marcello Felipelli
> >> > To: scrum-brasil@yahoogrupos.com.br
> >> > Sent: Wednesday, July 09, 2008 8:59 AM
> >> > Subject: [scrum-brasil] Como fazer para estimar projetos que
não
> >> sejam de escopo aberto
> >> >
> >> >
> >> > Bom dia!
> >> >
> >> > Estou trabalhando em um projeto que ainda utilizou técnicas e
> >> recursos
> >> > "tradicionais" no mercado. O que estamos fazendo aqui: Fazendo
o
> >> > levantamento de processos e seus casos de uso, especificando-
os e
> >> com
> >> > uma ferramenta case modelando o banco de dados. Isso, no que
> >> tange a
> >> > contratos com o cliente, foi feito da seguinte forma: 1º um
> >> contrato
> >> > com o objetivo de fazer a análise do negócio e entregar a
> >> documentação
> >> > acima, de forma que qualquer empresa ou o próprio cliente
> >> possa "em
> >> > tese" desenvolver o sistema. Um segundo contrato seria assinado
> >> com
> >> > base no resultado do primeiro.
> >> >
> >> > A ferramenta case que utilizo é o Enterprise Architect, e ele
> >> calcula
> >> > a estimativa de desenvolvimento com base em Use Case Points,
onde
> >> voce
> >> > pode alterar os fatores que compõe o cálculo dessa estimativa,
> >> > conforme a complexidade, linguagem de programação, arquitetura
da
> >> > solução, entre outros. Existe uma "base científica" para o uso
> >> dessa
> >> > forma de estimar, que leva em conta o número de transações, por
> >> exemplo.
> >> >
> >> > Utilizando Scrum como eu faria o planejamento sem ser baseado
> >> única e
> >> > exclusivamente na minha experiência? E se eu não for tão
> >> experiente
> >> > assim e sub-estimar os pontos? Pode acontecer a mesma coisa por
> >> UCP,
> >> > mas tem bastante material pra tentar evitar erros.
> >> >
> >> > Enfim existe algum fator ou base para realizar estimativas
> >> confiáveis
> >> > para demonstrar ao cliente e fazer um contrato de preço
fechado,
> >> ou
> >> > somente se aplica a contratos de escopo aberto?
> >> >
> >> > Por favor, me perdoem quanto a possíveis erros de português.
> >> >
> >> > Sds
> >> >
> >> > Marcello Felipelli
> >> >
> >>
> >
> >
> >
> > --
> > // MARCIO GARCIA - blog.mangar.com.br
> > SCJP SCWCD SCBCD SCEA CSM
> > F +55 11 8671 7148
> >
>