Como andam os contratos em agile por aqui?
0 views
Skip to first unread message
Vinicius Assef
Sep 24, 2009, 2:14:40 PM9/24/09
to agil...@googlegroups.com
Pessoal, em todos os lugares que leio e com praticamente todas as
pessoas que converso, um assunto sempre recorrente são os contratos de
escopo aberto.
pessoas que converso, um assunto sempre recorrente são os contratos de
escopo aberto.
Qual é a experiência de vocẽs aqui no ES? (os de fora tbm podem
contribuir, viu? rsrs)
Quem tem tido sucesso? Quem tem tido fracasso e por que?
Conta aí.
--
[ ]s
Vinicius Assef.
http://aprenda-python.blogspot.com
"Matar o tempo não é assassinato, é suicídio."
Denis Ferrari
Sep 28, 2009, 3:55:34 PM9/28/09
to Agile ES
Por que não fazemos um podcast discutindo os benefícios de cada modelo
de contratação?
Denis Ferrari
desenvolvimento.denisferrari.com
On 24 set, 15:14, Vinicius Assef <vinicius...@gmail.com> wrote:
> Pessoal, em todos os lugares que leio e com praticamente todas as
> pessoas que converso, um assunto sempre recorrente são os contratos de
> escopo aberto.
>
> Qual é a experiência de vocẽs aqui no ES? (os de fora tbm podem
> contribuir, viu? rsrs)
>
> Quem tem tido sucesso? Quem tem tido fracasso e por que?
>
> Conta aí.
>
> --
> [ ]s
> Vinicius Assef.http://aprenda-python.blogspot.com
de contratação?
Denis Ferrari
desenvolvimento.denisferrari.com
On 24 set, 15:14, Vinicius Assef <vinicius...@gmail.com> wrote:
> Pessoal, em todos os lugares que leio e com praticamente todas as
> pessoas que converso, um assunto sempre recorrente são os contratos de
> escopo aberto.
>
> Qual é a experiência de vocẽs aqui no ES? (os de fora tbm podem
> contribuir, viu? rsrs)
>
> Quem tem tido sucesso? Quem tem tido fracasso e por que?
>
> Conta aí.
>
> --
> [ ]s
Vinicius Assef
Sep 28, 2009, 4:19:11 PM9/28/09
to agil...@googlegroups.com
Denis, boa ideia, mas minha era saber como anda esse cenário prático
no Espírito Santo.
Pela ausência de relatos, podemos concluir que ninguém está vendendo
contratos ágeis por aqui?
"Visão sem ação, é um sonho acordado. Ação sem visão é um pesadelo." -
Provérbio Japonês
2009/9/28 Denis Ferrari <denis....@gmail.com>:
no Espírito Santo.
Pela ausência de relatos, podemos concluir que ninguém está vendendo
contratos ágeis por aqui?
"Visão sem ação, é um sonho acordado. Ação sem visão é um pesadelo." -
Provérbio Japonês
2009/9/28 Denis Ferrari <denis....@gmail.com>:
Denis Ferrari
Sep 28, 2009, 4:53:22 PM9/28/09
to Agile ES
Sei de poucas pessoas trabalhando com contratos de escopo variável.
O que tenho visto são empresas que adaptam o ágil para funcionar no
modelo antigo de contratação (ou tentam), ou seja, modificam a
produção e não a venda.
Acho que agora é o momento de mudar a cabeça dos contratantes, tenho
feito isso com meus clientes, porém, consegui isso baseado numa
relação de confiança. DIficilmente consegiuria a mesma abertura com
outras empresas ou com o governo.
O momento é propício para se fomentar os valores e uma nova forma de
contratação de software, afinal, várias empresas agora dizem que são
ágeis.
Abraços!
Denis Ferrari
desenvolvimento.denisferrari.com
On 28 set, 17:19, Vinicius Assef <vinicius...@gmail.com> wrote:
> Denis, boa ideia, mas minha era saber como anda esse cenário prático
> no Espírito Santo.
>
> Pela ausência de relatos, podemos concluir que ninguém está vendendo
> contratos ágeis por aqui?
>
> --
> [ ]s
> Vinicius Assef.http://aprenda-python.blogspot.com
O que tenho visto são empresas que adaptam o ágil para funcionar no
modelo antigo de contratação (ou tentam), ou seja, modificam a
produção e não a venda.
Acho que agora é o momento de mudar a cabeça dos contratantes, tenho
feito isso com meus clientes, porém, consegui isso baseado numa
relação de confiança. DIficilmente consegiuria a mesma abertura com
outras empresas ou com o governo.
O momento é propício para se fomentar os valores e uma nova forma de
contratação de software, afinal, várias empresas agora dizem que são
ágeis.
Abraços!
Denis Ferrari
desenvolvimento.denisferrari.com
On 28 set, 17:19, Vinicius Assef <vinicius...@gmail.com> wrote:
> Denis, boa ideia, mas minha era saber como anda esse cenário prático
> no Espírito Santo.
>
> Pela ausência de relatos, podemos concluir que ninguém está vendendo
> contratos ágeis por aqui?
>
> --
> [ ]s
> "Visão sem ação, é um sonho acordado. Ação sem visão é um pesadelo." -
> Provérbio Japonês
>
> 2009/9/28 Denis Ferrari <denis.sis...@gmail.com>:
> Provérbio Japonês
>
Renato Willi
Sep 29, 2009, 12:00:19 AM9/29/09
to agil...@googlegroups.com
Vinícius,
Como começamos a conversa quando você ainda estava por aqui, temos visto cada vez mais que o caminho não é vender agilidade, mas outros valores "agregados" ou resultantes de se trabalhar com met. ágeis.
Por exemplo: "ROI", "sustentabilidade", "software mais manutenível ou de longa vida", "alta qualidade", "menos bugs", "ganhos de escala", "software com testes automatizados", "documentação útil, funcional e atualizada", etc.
São coisas que atraem a atenção dos gestores sem gerar tanta polêmica quanto a que é gerada em torno de metodologias ágeis.
Porém, o que ainda é mais apelativo ainda é diminuição de custos e/ou aumento de produtividade. Mas como medir isso?
[]s
Willi
2009/9/28 Denis Ferrari <denis....@gmail.com>
Vinicius Assef
Sep 29, 2009, 12:56:20 PM9/29/09
to agil...@googlegroups.com
Willi, sem dúvida que é isso mesmo.
No final das contas, o cliente quer um produto bom o bastante para
resolver os problemas dele, que esteja pronto num tempo aceitável,
dentro do orçamento disponível e que não fique obsoleto logo, para que
o investimento valha a pena. Independente do método de trabalho do
fornecedor.
Vejo que uma das grandes diferenças da agilidade é a participação do
cliente como PO real (de verdade, atuante mesmo!).
No entanto, penso que dizer que com "nosso" método de trabaho teremos
mais qualidade ou manutenibilidade, seja algo meio curioso. Veja, se
nossa equipe trabalhar com os métodos convencionais teremos menos
qualidade e faremos códigos menos propensos a manutenção? Ou com menos
cobertura de testes? :-/
Essas seriam perguntas que eu, se fosse o cliente, logo faria para meu
fornecedor que quer me convencer de "algo novo".
Como continuar a conversa a partir daí?
"Persiga seu sonho, não seus oponentes." - Flawless
2009/9/29 Renato Willi <renato...@gmail.com>:
No final das contas, o cliente quer um produto bom o bastante para
resolver os problemas dele, que esteja pronto num tempo aceitável,
dentro do orçamento disponível e que não fique obsoleto logo, para que
o investimento valha a pena. Independente do método de trabalho do
fornecedor.
Vejo que uma das grandes diferenças da agilidade é a participação do
cliente como PO real (de verdade, atuante mesmo!).
No entanto, penso que dizer que com "nosso" método de trabaho teremos
mais qualidade ou manutenibilidade, seja algo meio curioso. Veja, se
nossa equipe trabalhar com os métodos convencionais teremos menos
qualidade e faremos códigos menos propensos a manutenção? Ou com menos
cobertura de testes? :-/
Essas seriam perguntas que eu, se fosse o cliente, logo faria para meu
fornecedor que quer me convencer de "algo novo".
Como continuar a conversa a partir daí?
"Persiga seu sonho, não seus oponentes." - Flawless
2009/9/29 Renato Willi <renato...@gmail.com>:
Renato Willi
Sep 29, 2009, 7:04:49 PM9/29/09
to agil...@googlegroups.com
Acho que da forma convencional teremos mais custos, boas chances de menor qualidade (tudo isso por não ter testes automatizados, e necessitarmos de uma pessoa executando os testes, sujeitando-os a erros humanos), teremos mais lentidão na resolução das mudanças (processo burocrático) e mais lentidão na manutenção, pois a documentação seria exterior ao código.
Denis Ferrari
Sep 29, 2009, 11:25:03 PM9/29/09
to agil...@googlegroups.com
Boa noite Pessoal,
Concordo com o Renato. Alguns comentários:
O trabalho de divulgação da
metodologia ágil tem que se basear nos valores e não nas técnicas. A forma
de trabalho pode ser qualquer uma, desde que atenda ao manifesto.
Tenho apresentado para os clientes os valores e como "conseqüência"
deles proponho uma forma diferente de trabalho. Procuro mostrar os benefícios
de se trabalhar de uma forma diferente da "indústria de software"
convencional.
O momento atual é seguinte:
agilidade está na boca da maioria das empresas de desenvolvimento, porém,
poucas empresas estão prontas pra ela (6 sprints de análise e por aí vai).
Os clientes precisam entender o porquê essa forma dessa forma diferente de
trabalhar funciona, e não achar que é mais uma solução empacotada de
desenvolvimento de software que vai acabar com todos os problemas.
Ainda acredito que temos um longo caminho pela frente em mudar a cabeça dos
clientes, dos desenvolvedores, dos gerentes e dos empresários. Ninguém disse
que seria fácil e nem do dia pra noite. :)
Abraços!
2009/9/29 Renato Willi <renato...@gmail.com>
Vinicius Assef
Sep 30, 2009, 8:22:53 AM9/30/09
to agil...@googlegroups.com
Willi, em parte respondeu sim.
Estou formatando melhor esses argumentos aqui na minha cabecinha dura. rsrs
E faço o papel de advogado do diabo antes de tentar convencer outras
pessoas do *real* benefício de uma mudança.
Eu já estou convencido, porque trabalho com desenvolvimento e vejo o
ganho que essa forma pode trazer. Mas para quem não mete a mão na
massa, só no dinheiro, preciso de argumentos fortes, certo? ;-)
Acho que é o meu lado comercial falando alto novamente. rsrs :-P
Pontos a favor da nossa argumentação quando vc fala sobre lentidão nas
mudanças e custo adicional de documentação. Isso, seguindo o processo
RUP. No entanto, o que vemos em muitas empresas é apenas uma "falação"
sobre RUP. Usar mesmo, nada!
No entanto, ponto contra quando fala-se em testes automatizados. Nada
diz que com modelos em cascata, não podemos usar testes automatizados.
"A melhor maneira de prever o futuro é criá-lo."
2009/9/29 Renato Willi <renato...@gmail.com>:
Estou formatando melhor esses argumentos aqui na minha cabecinha dura. rsrs
E faço o papel de advogado do diabo antes de tentar convencer outras
pessoas do *real* benefício de uma mudança.
Eu já estou convencido, porque trabalho com desenvolvimento e vejo o
ganho que essa forma pode trazer. Mas para quem não mete a mão na
massa, só no dinheiro, preciso de argumentos fortes, certo? ;-)
Acho que é o meu lado comercial falando alto novamente. rsrs :-P
Pontos a favor da nossa argumentação quando vc fala sobre lentidão nas
mudanças e custo adicional de documentação. Isso, seguindo o processo
RUP. No entanto, o que vemos em muitas empresas é apenas uma "falação"
sobre RUP. Usar mesmo, nada!
No entanto, ponto contra quando fala-se em testes automatizados. Nada
diz que com modelos em cascata, não podemos usar testes automatizados.
"A melhor maneira de prever o futuro é criá-lo."
2009/9/29 Renato Willi <renato...@gmail.com>:
Renato Willi
Sep 30, 2009, 1:31:39 PM9/30/09
to agil...@googlegroups.com
(Respondendo rapidamente...)
Achar os erros (e mudanças) tarde (após a codificação), acaba sendo caro de corrigir, ainda mais se você já não tiver feito testes desde o começo. Começa a quebrar coisa em todo lado - o castelo de cartas rui.
O ideal é fazer o que tem que ser feito no momento em que a equipe achar que tem que ser feito, sem uma ordem pré-definida ou dividida discretamente. Um monte de código "pronto" sem teste não passa de um gigantesco abacaxi cheio de "débitos técnicos". esses débitos cobrarão seus juros depois.
Por isso que uma das boas práticas é fazer o teste até antes mesmo do código: assegura que o código estará "apoiado" e favorece o foco do desenvolvedor em resolver só o necessário (temos uma grande tendência em viajar na maionese, perder o foco, fazer mais que o necessário e tudo isso é desperdício).
[]s
Willi
2009/9/30 Vinicius Assef <vinic...@gmail.com>
Denis Ferrari
Sep 30, 2009, 5:03:54 PM9/30/09
to agil...@googlegroups.com
Renato,
Sobre TDD...
http://aprenderaspx.wordpress.com/2009/09/29/palestra-sobre-tdd-na-faesa/
Sou praticante e defensor do TDD, porém, ele não garante o sucesso do projeto, só aumenta a probabilidade do mesmo junto com outras técnicas.
O problema da Cascata não é só o fato de fazer os testes no final, é uma série de valores errados.
Como você mesmo disse, TDD é uma das boas práticas, porém, só TDD não garante nada.
Sobre TDD...
http://aprenderaspx.wordpress.com/2009/09/29/palestra-sobre-tdd-na-faesa/
Sou praticante e defensor do TDD, porém, ele não garante o sucesso do projeto, só aumenta a probabilidade do mesmo junto com outras técnicas.
O problema da Cascata não é só o fato de fazer os testes no final, é uma série de valores errados.
Como você mesmo disse, TDD é uma das boas práticas, porém, só TDD não garante nada.
2009/9/30 Renato Willi <renato...@gmail.com>
Renato Willi
Sep 30, 2009, 5:15:56 PM9/30/09
to agil...@googlegroups.com
Concordo Denis. Acho que não afirmei que só TDD garantiria sucesso, mas se de alguma forma dei a entender isso - esqueçam! :)
2009/9/30 Denis Ferrari <denis....@gmail.com>
Reply all
Reply to author
Forward
0 new messages