Dois anos é muito tempo... pode ser num próximo projeto ou naquele mesmo! Logo, agrega sim

 

Não o que você mesmo disse, mas tudo bem. Eu estou aguardando algum exemplo objetivo de melhoria até hoje. Ainda não ouvi um argumento convincente de que isto acontece na prática, de forma eficiente.

Só acho estranho vc querer o mais simples por ser simples e não por achar que é melhor que o complexo

Não vou comentar o seu "desentendimento". Começo achar que você não entende meus argumentos por conveniência, quando quer. Portanto, acho melhor parar por aqui.

 

Não vou comentar esta afirmativa.

2009/6/20 Peter P. Lupo <peterplupo@...>

"Seus próprios exemplos vão de encontro a esta alegação. Qual o valor agregado para o cliente adicionando uma métrica que só vai servir para melhorar o seu processo daqui há dois anos?"

Dois anos é muito tempo... pode ser num próximo projeto ou naquele mesmo! Logo, agrega sim. E se o próximo projeto for pra outro cliente, não tem probéma, vc está cuidando da sua organização. Se vc acha que ela não precisa melhorar, é com você. Direito seu.

"Se eu consigo desenvolver um software que atende meu 100% meu cliente com um processo mais simples é este que vou escolher, ponto final."

Como eu disse, direito seu. Só acho estranho vc querer o mais simples por ser simples e não por achar que é melhor que o complexo. Se vc achasse (suposição) que ele é pior que o complexo, ainda assim iria escolher o simples, pq é simples. Entendi seu ponto de vista. Só não me faz sentido.

Abraço!

Peter P. Lupo
Undergraduating in Computer Science DCC/UFRJ
MPS.BR Authorized Implementation Practitioner
Sun Certified Java Associate
http://sites.google.com/site/pplupo
Cell. +55 (021) 81742487

2009/6/20 Eduardo Miranda <dudamir@...>

Seus próprios exemplos vão de encontro a esta alegação. Qual o valor agregado para o cliente adicionando uma métrica que só vai servir para melhorar o seu processo daqui há dois anos?

 

Pois bem, você está agregando ZERO valor e ainda está cobrando dele o custo do seu "processo de melhoria de processo".

 

Se você não vai utilizar nem bluetooth, nem camera, o valor agregado é ZERO, portanto eu não pago nem 0,01 a mais.

 

Metáforas muitas vezes confudem ao invés de ajudar.

 

Já tentaram comparar processo com uma atividade de pintar parede, agora é como comprar celular.

 

Desculpe, mas é muito mais fácil entender o meu ponto explicando com o que a gente entende, ou deveria entender, melhor.

 

Se eu consigo desenvolver um software que atende meu 100% meu cliente com um processo mais simples é este que vou escolher, ponto final.

 

 

2009/6/20 Peter P. Lupo <peterplupo@...>

Sim, o mais simples no seu exemplo gera menos valor agregado, apesar de também gastar menos. Não significa dizer que ele é melhor que o mais complexo. Só que ele é mais adequado em determinadas situações e pode ser menos adequado (ou inadequado) em outras, já que simplificações muitas vezes acarretam perdas.

Vc compraria um telefone celular por 450 reais quando vc pode ter um que faz as mesmas coisas e ainda tem bluetooth ou câmera ou qq outra coisa que te interesse por 455 só pq o outro é mais simples e 5 reais mais barato?

Simplicidade também tem seu preço.
Nem toda complexidade é cara.

Abraço!

Peter P. Lupo
Undergraduating in Computer Science DCC/UFRJ
MPS.BR Authorized Implementation Practitioner
Sun Certified Java Associate
http://sites.google.com/site/pplupo
Cell. +55 (021) 81742487

2009/6/19 Eduardo Miranda <dudamir@...>

Então o processo mais simples não atende/resolve o problema. Não seria uma questão de ser inadequado, ao invés de melhor/pior?

 

Vou escolher o processo mais complexo pois ele é o único que me atende.

 

2009/6/19 Peter P. Lupo <peterplupo@...>

Concordo.

Mas o argumento se mantém. Ainda mais se vc mantiver o valor agregado extra-processo constante nas duas situações pela sanidade da discussão. hehehe...

Abraço!

Peter P. Lupo
Undergraduating in Computer Science DCC/UFRJ
MPS.BR Authorized Implementation Practitioner
Sun Certified Java Associate
http://sites.google.com/site/pplupo
Cell. +55 (021) 81742487

2009/6/19 Eduardo Miranda <dudamir@...>

Valor agregado pelo processo, não o valor total agregado.

 

Você concorda que o produto final não é resultado apenas do processo?

2009/6/19 Peter P. Lupo <peterplupo@...>

Neste caso, como vc pode dizer qual é o melhor?
E se o cliente quiser/precisar de um valor 12? Vc vai ter que encarar o custo 3, certo? Volto à questão do que é mais adequado.

Abraço!

Peter P. Lupo
Undergraduating in Computer Science DCC/UFRJ
MPS.BR Authorized Implementation Practitioner
Sun Certified Java Associate
http://sites.google.com/site/pplupo
Cell. +55 (021) 81742487

2009/6/19 Eduardo Miranda <dudamir@...>

IBP = A / B

 

A = 12

B = 3

IBP = 4

 

A = 8

B = 2

IBP = 4

Custos diferentes com retornos iguais.

2009/6/19 Peter P. Lupo <peterplupo@...>

Na medida em que duas atividades, uma simples e outra complexa, apresentam o mesmo resultado, entendo que a complexa gaste mais, logo o valor/custo desta é menor.
Daí que tirei que sua fórmula calcula complexidade.

Abraço!

Peter P. Lupo
Undergraduating in Computer Science DCC/UFRJ
MPS.BR Authorized Implementation Practitioner
Sun Certified Java Associate
http://sites.google.com/site/pplupo
Cell. +55 (021) 81742487

2009/6/18 Eduardo Miranda <dudamir@...>

Peter você acha que esta fórmula só calcularia a complexidade do processo?

 

Valor agregado ao cliente / custo agregado pelo processo.

 

Eu estou simplesmente calculando o retorno do que se gasta com o processo. Talvez eu tenha subentendido uma coisa:

Valor agregado ao cliente (pelo processo) / custo agregado pelo processo.

Todos os argumentos continuam valendo.

2009/6/18 Peter P. Lupo <peterplupo@...>

Eduardo, reli seus e-mails e entendi melhor o seu ponto.

O seu IBP é ótimo para comparar COMPLEXIDADE de processos simples X complexos, pq critica exatamente as atividades não relacionadas com geração de valor direto na própria medida.
Quanto menos atividades que não agregam valor direto, maior o IBP. Quanto menos estas atividades custarem, maior o IBP.
Isto não significa que um processo simples é melhor que outro menos simples. Indica apenas que o IBP de um processo simples é maior que o IBP de um processo menos simples, percebeu?
Seu IBP seria melhor chamado ISP, Índice de Simplicidade do Processo. Aí fica óbvio que o ISP de um processo mais simples é melhor que o ISP de um processo menos simples. Mas não prova que um é melhor que o outro.
Quando vc chamou de "Índice de Bonzisse do Processo" vc implicitamente já colocou que um mais simples é melhor que um mais complexo, que é justamente o cerne da discussão.

Num projeto arriscado, um pouco de planejamento para tentar visualizar os riscos e escolher uma tecnologia adequada, mostrar para o cliente determinados planos de contingência onde a ação dele será necessária caso o risco se concretize e coisas assim pode demonstrar maturidade, aumentar a confiança da equipe, do cliente e reduzir os riscos de um projeto falhar. O ISP de um processo com esta atividade é certamente menor que o IBP/ISP de um processo igual sem esta atividade. Não significa necessariamente ser melhor.
De fato, ao longo de vários projetos arriscados, eu me arriscaria a dizer que a organização PODE ficar com má fama (de não conseguir concluir seus projetos, por exemplo, ou de sempre apresentarem problemas) ou até falir por arcar excessivamente com gastos não planejados e/ou falta de clientes.

Abraço!

Peter P. Lupo
Undergraduating in Computer Science DCC/UFRJ
MPS.BR Authorized Implementation Practitioner
Sun Certified Java Associate
http://sites.google.com/site/pplupo
Cell. +55 (021) 81742487

2009/6/18 gustavo rezende <nsigustavo@...>

nao sou moderador do grupo, mas seria bom fazer  forks para discutir.
Pq o papo jah esta bem longe do titulo do e-mail.
Entretanto, esta bem legal...
continuem...


pra enriquecer o papo:

http://www.dtsato.com/blog/2007/06/23/metricas-vs-metricas-e-uma-propaganda-no-final/
http://blog.aspercom.com.br/2009/05/08/reuniao-diaria-cobranca

2009/6/17 Luiz Esmiralha <esmiralha@...>

Eduardo,

Eu não falei que todas as métricas são falhas. Certamente, cada processo/contexto possui métricas adequadas a ele. O trabalho da equipe é identificar que métricas são adequadas para seu projeto, pois medir a coisa errada pode ajudar a piorar o processo.

Abraço,
Luiz

2009/6/17 Eduardo Miranda <dudamir@...>

Luiz,

 

Todas as métricas são "falhas", portanto você não utiliza nenhuma. Um pouco radical, mas válido.

 

Então, como você evolui/muda/melhora seu processo? O que faz você identificar algo a tirar ou acrescentar?

 

 

2009/6/17 Luiz Esmiralha <esmiralha@...>

Eduardo,

Entre métricas falhas e nenhuma métrica, eu prefiro nenhuma métrica. A
métrica falha faz você gastar seu precioso tempo com algo que não
agrega valor nenhum e tomar decisões erradas achando que está muito
bem embasado por uma métrica. Números nos dão confiança e essa
confiança leva você a insistir em um erro. O gerenciamento por
métricas é algo potencialmente MUITO perigoso.

Abraço,

Luiz

2009/6/16 Eduardo Miranda <dudamir@...>
>
>
> Não existe, mas se você quer melhorar seu processo é preciso ter algum índice, ou vários, para medir se você melhorou mesmo, por mais falha que seja a métrica. Concorda?
>
>
>
> 2009/6/16 Luiz Esmiralha <esmiralha@...>
>>
>>
>> Pessoal,
>>
>> O problema é que o IBP não existe, não é? Será que adianta dar
>> continuidade a uma discussão baseada em um conceito imaginário? Não
>> será mais produtivo as pessoas apresentarem suas experiências com
>> processos complexos e as pessoas que têm experiência com processos
>> mais simples mostrarem como resolveram os mesmos problemas de forma
>> mais simples?
>>
>> Abraços,
>> Luiz
>>
>> 2009/6/16 Eduardo Miranda <dudamir@...>:
>>
>> >
>> >
>> > Obrigado por tirar minha frase completamente do contexto ...
>> >
>> > Mas se você tirar os testes e ele manter o mesmo "IBP", então ele
>> > está melhor que antes, só para voltar ao contexto.
>> >
>> > 2009/6/16 Peter P. Lupo <peterplupo@...>
>> >>
>> >>
>> >> Eu não disse que simples é pior ou melhor que complexo. Disse que se quer
>> >> na intenção de se melhorar é que se deve conseguir o simples naturalmente ao
>> >> invés de buscar o simples por que é melhor simplificar.
>> >> Simplificar por simplificar sem saber onde pode trazer prejuízos.
>> >>
>> >> "Ou seja, um processo simples é sempre melhor que um mais complexo."
>> >> Tirar atividades importantes simplifica e não necessariamente vai te dar
>> >> algo bom. Um processo sem testes por exemplo é mais simples. Um sem reuniões
>> >> de acompanhamento, sem standup meetings no xp, por exemplo, pode te trazer
>> >> problemas. E é mais simples.
>> >>
>> >> "O objetivo final de se ter um processo é melhorar a sua produção, e não o
>> >> seu processo." - Concordo, mas acho que a discussão não era bem esta. :-)
>> >>
>> >> Abraço!
>> >>
>> >> Peter P. Lupo
>> >> Undergraduating in Computer Science DCC/UFRJ
>> >> MPS.BR Authorized Implementation Practitioner
>> >> Sun Certified Java Associate
>> >> http://sites.google.com/site/pplupo
>> >> Cell. +55 (021) 81742487
>> >>
>> >>
>> >> 2009/6/15 Eduardo Miranda <dudamir@...>
>> >>>
>> >>>
>> >>> O primeiro ponto é: Um processo simples será sempre superior a um
>> >>> processo complexo.
>> >>>
>> >>> Vamos para um mundo imaginário onde se calcula facilmente o índice de
>> >>> bonzisse do processo (IBP) através de uma conta simples: Valor agregado ao
>> >>> cliente / custo agregado pelo processo.
>> >>>
>> >>> Dois ótimos processos tem um IBP equivalente, só que um é mais simples
>> >>> que o outro. Qual você escolheria? O mais simples, porque tem menos custo
>> >>> fixo e variável, porque é mais fácil de evoluí-lo, etc.
>> >>>
>> >>> Existem outros dois processo muito ruins, também com IBP equivalente, um
>> >>> simples, outro complexo. Qual você escolheria? O mais simples, porque seria
>> >>> mais fácil mudá-lo para tentar consertá-lo.
>> >>>
>> >>> Ou seja, um processo simples é sempre melhor que um mais complexo.
>> >>> O segundo ponto é: O objetivo final de se ter um processo é melhorar a
>> >>> sua produção, e não o seu processo. Quando discussões sobre o processo
>> >>> passam a dominar as conversas do time, isto está errado. Não afirmei que não
>> >>> devemos pensar no processo, apenas que devemos saber a medida correta.
>> >>>
>> >>> Assim como processos mais tradicionais e pesados (por favor não quero
>> >>> reiniciar a discussão!) têm uma tendência a serem mais "pensados", algumas
>> >>> empresas têm times grandes e caros, só para manter, controlar e melhorar o
>> >>> processo, alguns projetos que adotam o Agile, também têm uma tendência de
>> >>> pensar, e discutir, demais o processo. Talvez pela euforia do novo, talvez
>> >>> porque não temos nada melhor para fazer :)
>> >>>
>> >>>
>> >>>
>> >>> 2009/6/13 Peter P. Lupo <peterplupo@...>
>> >>>>
>> >>>>
>> >>>> Nossa... eu n ão sei o que o yahoo fez com a formatação deste e-mail mas
>> >>>> as suas respostas vieram como se fossem uma coluna ao lado do meu e-mail
>> >>>> sendo que uma linha ficou misturada no meu texto... fui só eu que recebi
>> >>>> assim?
>> >>>>
>> >>>> Não estou dando voltas semânticas. Acho que vc não entendeu o que eu
>> >>>> quis dizer. Aliás, acredito que processos simples sejam mais "vendáveis".
>> >>>>
>> >>>> Quanto a segunda parte, certamente há um grupo de pessoas responsáveis
>> >>>> por avaliar e implementar as mudanças e dependendo do volume de mudanças
>> >>>> pode ser que não tenham descanso. Pq não? É ótimo ter sugestões de melhoria,
>> >>>> não é? Só quis dizer que as pessoas que fazem isto não são as que estão
>> >>>> produzindo. As que estão produzindo estão produzindo e pensando em como
>> >>>> fazer melhor seu trabalho para fazer sugestões, certo?
>> >>>>
>> >>>> Abraço!
>> >>>>
>> >>>> Peter P. Lupo
>> >>>> Undergraduating in Computer Science DCC/UFRJ
>> >>>> MPS.BR Authorized Implementation Practitioner
>> >>>> Sun Certified Java Associate
>> >>>> http://sites.google.com/site/pplupo
>> >>>> Cell. +55 (021) 81742487
>> >>>>
>> >>>>
>> >>>> 2009/6/12 Eduardo Miranda <dudamir@...>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> 2009/6/12 Peter P. Lupo peterplupo@...
>> >>>>>>
>> >>>>>>
>> >>>>>> "Eu quero ter um processo simples porque ele é simples, na verdade
>> >>>>>> acho que tão mais simples o processo, melhor."
>> >>>>>> Então vc quer um simples por acreditar que ele é melhor, logo vc quer
>> >>>>>> um processo bom. Se vc acreditasse no inverso, iria querer um complexo, mas
>> >>>>>> ainda ia querer um processo bom.
>> >>>>>
>> >>>>> Por favor não tente dar voltas semânticas na minha opinião. Eu quero um
>> >>>>> processo simples porque meu objetivo é desenvolver e entregar software de
>> >>>>> qualidade, quanto menor o ruido, melhor. Se meu objetivo fosse vender
>> >>>>> processo, talvez eu achasse que um processo complexo fosse melhor.
>> >>>>>>
>> >>>>>> "Processo não é início, nem fim, é o meio utilizado para produzirmos
>> >>>>>> algo de qualidade e ofecerecermos aos nossos clientes valor agregado, ponto
>> >>>>>> final."
>> >>>>>> Eu não disse que um processo simples é início ou fim por si só. Eu
>> >>>>>> falei que simplificar pode ser um dos passos para se melhorar um processo,
>> >>>>>> não o único, mas talvez uma forma de iniciar uma sequência de melhorias.
>> >>>>>>
>> >>>>>> Concordo com você que processo não é início nem fim.
>> >>>>>>
>> >>>>>> "Adorei escutar de um "agilista fanático" que se impressou ao chegar a
>> >>>>>> uma fábrica que implementava lean manufacturing e não encontrar ninguém
>> >>>>>> discutindo processo, ninguém na frente do quadro branco contemplando que
>> >>>>>> bonito é o Kanban. O que ele viu foi um monte de gente produzindo! Que
>> >>>>>> interessante ..."
>> >>>>>>
>> >>>>>> Este agilista também nunca me viu tomando banho, mas eu tomo! ;-)
>> >>>>>> Bom, te garanto que quando alguém sugere uma melhoria na forma de
>> >>>>>> produzir, alguém analisa a proposta e faz as modificações necessárias para
>> >>>>>> implementá-la se for o caso.
>> >>>>>
>> >>>>>
>> >>>>> Eu não disse que não existem melhorias no processo, apenas disse que
>> >>>>> ninguém fica masturbando o processo ao invés de produzir, que é o objetivo
>> >>>>> final da empresa (acredito que vc já tinha entendido isto, mas fiz questão
>> >>>>> de explicar melhor)
>> >>>>>>
>> >>>>>> Abraço!
>> >>>>>>
>> >>>>>> Peter P. Lupo
>> >>>>>> Undergraduating in Computer Science DCC/UFRJ
>> >>>>>> MPS.BR Authorized Implementation Practitioner
>> >>>>>> Sun Certified Java Associate
>> >>>>>> http://sites.google.com/site/pplupo
>> >>>>>> Cell. +55 (021) 81742487
>> >>>>>>
>> >>>>>>
>> >>>>>> 2009/6/12 Eduardo Miranda <dudamir@...>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Peter,
>> >>>>>>>
>> >>>>>>> Eu quero ter um processo simples porque ele é simples, na verdade
>> >>>>>>> acho que tão mais simples o processo, melhor. Processo não é início, nem
>> >>>>>>> fim, é o meio utilizado para produzirmos algo de qualidade e ofecerecermos
>> >>>>>>> aos nossos clientes valor agregado, ponto final.
>> >>>>>>>
>> >>>>>>> Adorei escutar de um "agilista fanático" que se impressou ao chegar a
>> >>>>>>> uma fábrica que implementava lean manufacturing e não encontrar ninguém
>> >>>>>>> discutindo processo, ninguém na frente do quadro branco contemplando que
>> >>>>>>> bonito é o Kanban. O que ele viu foi um monte de gente produzindo! Que
>> >>>>>>> interessante ...
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 2009/6/12 Peter P. Lupo <peterplupo@...>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Sigmar,
>> >>>>>>>>
>> >>>>>>>> Vou responder os itens do seu e-mail de baixo pra cima.
>> >>>>>>>> Em primeiro lugar, qnto a piadinha da assinatura, não precisa pedir
>> >>>>>>>> desculpa... eu ri um bocado aqui... :-P O e-mail já teria valido pela piada,
>> >>>>>>>> mesmo que não fosse bom (mas é).
>> >>>>>>>> O mundo tá cheio de títulos e certificações. Pra quem acha
>> >>>>>>>> importante, tá aí na assinatura. É por isso q as pessoas assinam PMP ou
>> >>>>>>>> Certified Scrum Master Jedi ou qq coisa assim. É por isso q as empresas se
>> >>>>>>>> avaliam em CMMI E MPS.BR ao mesmo tempo, pq querem os dois. C'est la vie. O
>> >>>>>>>> jogo tem regras, né? ;-)
>> >>>>>>>> Pra quem acha que não é importante, é só ignorar. O principal é
>> >>>>>>>> saber reconhecer que os conhecimentos e experiências são muito diferentes de
>> >>>>>>>> uma pessoa pra outra e enquanto uma pode entender ou conhecer melhor um
>> >>>>>>>> tópico, outro pode saber mais de outro tópico, então ninguém é melhor que
>> >>>>>>>> ninguém de forma geral e ninguém é melhor que todos juntos.
>> >>>>>>>> Eu acho no mínimo interessante saber a formação das pessoas na área
>> >>>>>>>> em que se está discutindo, pra ver pra que lado ela orientou seus estudos ou
>> >>>>>>>> em que teve mais experiência. Principalmente quando a pessoa participa pouco
>> >>>>>>>> da lista (como eu), não se sabendo muito dela a priori.
>> >>>>>>>>
>> >>>>>>>> Além do mais, eu tenho assinatura desde a época de Trumpet Winsock,
>> >>>>>>>> Blue Wave, cliente de telnet e BBS. É claro que naquele tempo era
>> >>>>>>>> basicamente um headline escolhido aleatoriamente numa lista. :-P
>> >>>>>>>>
>> >>>>>>>> Concordo com o que vc falou. Quem não quer fazer seu trabalho bem
>> >>>>>>>> feito? Geralmente quando algo impede alguém de fazer seu trabalho bem feito
>> >>>>>>>> é pq tem gente mandando no trabalho do outro, pq se mandasse só no seu, não
>> >>>>>>>> faria nada que notasse que iria prejudicar.
>> >>>>>>>> Se faz é por falta de percepção ou por motivações maiores, como um
>> >>>>>>>> título/selo ou seja o que for.
>> >>>>>>>>
>> >>>>>>>> Quanto ao Lean não ter emplacado nos EUA, eu concordo com o que ouvi
>> >>>>>>>> o David Card dizer numa palestra: Vc pode treinar pra correr a maratona e
>> >>>>>>>> ficar "lean", vai ter mais disposição, mais energia, vai ficar mais forte,
>> >>>>>>>> etc. Ou vc pode fazer um regime. O problema das empresas é que querem adotar
>> >>>>>>>> lean fazendo regime e ter os benefícios do maratonista.
>> >>>>>>>>
>> >>>>>>>> A Toyota implementou um ciclo de melhoria contínuo e o processo de
>> >>>>>>>> produção foi melhorando. É muito diferente de vc sair "simplificando" as
>> >>>>>>>> coisas e achar que vai terminar com o melhor processo que poderia só pq saiu
>> >>>>>>>> simplificando.
>> >>>>>>>>
>> >>>>>>>> Não é que eu ache ruim simplificar. Muito pelo contrário. Só que
>> >>>>>>>> este não é o fim, é o início. Ninguém quer ter um processo simples pq ele é
>> >>>>>>>> simples. Se quer um processo bom, em primeiro lugar. Assim, simplificar pode
>> >>>>>>>> ser o início, a partir do qual as melhorias serão feitas e o processo é
>> >>>>>>>> aprimorado até que se obtenham os benefícios. Também é possível melhorar até
>> >>>>>>>> ficar simples. Enfim, a meta é ter algo bom e não ter algo simples.
>> >>>>>>>> Geralmente acaba ficando simples pq complexo é ruim *rs*
>> >>>>>>>>
>> >>>>>>>> Acho que este é o grande erro de interpretação na adoção do Lean.
>> >>>>>>>>
>> >>>>>>>> Por último, se me recordo corretamente (não fui procurar), acho que
>> >>>>>>>> a discussão se originou quando alguém perguntou pois precisava se referir a
>> >>>>>>>> metodologias não Ágeis num texto acadêmico, monografia ou qq coisa assim,
>> >>>>>>>> então pelo menos pra quem iniciou a discussão tinha uma utilidade bem
>> >>>>>>>> definida.
>> >>>>>>>>
>> >>>>>>>> Peter P. Lupo
>> >>>>>>>> Undergraduating in Computer Science DCC/UFRJ
>> >>>>>>>> MPS.BR Authorized Implementation Practitioner
>> >>>>>>>> Sun Certified Java Associate
>> >>>>>>>> http://sites.google.com/site/pplupo
>> >>>>>>>> Cell. +55 (021) 81742487
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> 2009/6/12 Sigmar Siqueira <sigmar.siqueira@...>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> O título da discussão não deveria mudar (talvez o grupo de
>> >>>>>>>>> discussão também)?
>> >>>>>>>>> Como é que se classifica se uma metodologia, framework, etc... é
>> >>>>>>>>> ágil ou não? Agile Certifier Alliance?
>> >>>>>>>>> Sem querer menosprezar a opinião de ninguém, acho essa discussão
>> >>>>>>>>> inútil.
>> >>>>>>>>> Todos os lugares onde vi implantarem RUP deram errado (eu vi
>> >>>>>>>>> poucos), em todos eles, garanto, que pode colocar qualquer coisa, que vai
>> >>>>>>>>> dar merda. Vejo algumas implantações de Scrum que estão dando errado,
>> >>>>>>>>> garanto também, se colocar qualquer coisa lá, vai dar errado também.
>> >>>>>>>>> O problema nas empresas nunca foi falta de metodologia. Não existia
>> >>>>>>>>> XP antes, então era o caos, agora existe, estão todas salvas. Desde que a
>> >>>>>>>>> computação existe, sempre existiu empresa com processo cagado e  empresa com
>> >>>>>>>>> processo bacana. A Engenharia de Software não tem dono, não é sinônimo de
>> >>>>>>>>>  PRESSMAN e evolui. As empresas "bacanas" evoluem junto. As cagadas
>> >>>>>>>>> continuam cagadas.
>> >>>>>>>>> Quem já leu o The Mythical Man-Month? Livro da década de 60. Agile?
>> >>>>>>>>> Kent Beck nem era nascido :) Citaram o Larman e o livro "Agile and Iterative
>> >>>>>>>>> Development: A Manager's Guide", viram no livro que ele fala do EVO?
>> >>>>>>>>> Metodologia da década de 70, eu acho. As pessoas se viravam, desde muito
>> >>>>>>>>> tempo atrás. A maioria das empresas de hoje nasceram depois disso tudo e
>> >>>>>>>>> continuam cagadas.
>> >>>>>>>>> Pode vir onda, tsunami, furacão 2000, o problema é organizacional,
>> >>>>>>>>> não técnico.
>> >>>>>>>>> Enfim, dizer que RUP não funciona porque não emplacou? Me diz ai o
>> >>>>>>>>> que é que funciona então, o que foi que emplacou até hoje?
>> >>>>>>>>> Na indústria, o processo lean de produção, foi revolucionário.
>> >>>>>>>>> Muito bem representado pela indústria automobilística, no modelo tailorista,
>> >>>>>>>>> a  ford e a GM (atual falida) e as japonesas Toyota e Honda, no modelo lean.
>> >>>>>>>>> Quem levou a melhor? Até semana passada, o lean não tinha emplacado na GM.
>> >>>>>>>>> Mas a mudança não foi só na metodologia, mudou tudo, cadeia de
>> >>>>>>>>> produção, logística, esquema organizacional, a indústria no geral. O Deming
>> >>>>>>>>> (pai do PDCA), que iniciou o lean no Japão, era americano. Foi mandado pro
>> >>>>>>>>> Japão, no pós guerra, pra ajudar na reconstrução da indústria japonesa.
>> >>>>>>>>> Ajudou tão bem, que f. com a americana. Dizem que ele não conseguiu nos EUA
>> >>>>>>>>> porque lá já estava tudo estabelecido, no Japão estava tudo destruído mesmo,
>> >>>>>>>>> puderam remodelar tudo. O lean não emplacou nos EUA como emplacou no Japão.
>> >>>>>>>>> Até hoje!
>> >>>>>>>>> Na minha opinião, se botar metodologia ágil nas empresas e não
>> >>>>>>>>> mudar mais a fundo a organização e a própria indústria de software, não vai
>> >>>>>>>>> emplacar. Trabalho numa equipe que usa Scrum (não usa XP, foi mal), empresa
>> >>>>>>>>> de grande porte, multinacional, etc... e os empecilhos para seu uso são
>> >>>>>>>>> sempre organizacionais. Os técnicos a gente tira de letra. Se fosse RUP,
>> >>>>>>>>> teriamos os mesmos problemas,e a parte técnica, ia se resolver facinho.
>> >>>>>>>>>
>> >>>>>>>>> Sigmar Siqueira
>> >>>>>>>>> Scrum Team Member Fucked Authorized Implementor
>> >>>>>>>>>  |
>> >>>>>>>>> \/
>> >>>>>>>>> ps: foi mal Peter, não resisti :)
>> >>>>>>>>>
>> >>>>>>>>> 2009/6/11 Peter P. Lupo <peterplupo@...>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> Tales, quando falei de institucionalizar, quis dizer trazer o
>> >>>>>>>>>> conhecimento para a organização em oposição a deixá-lo nas cabeças das
>> >>>>>>>>>> pessoas. Nenhuma das iniciativas no post do seu blog caminha nesta direção,
>> >>>>>>>>>> que me parece oposta ao Agile a partir do momento em que para se
>> >>>>>>>>>> institucionalizar (no sentido em que falei) o processo de desenvolvimento,
>> >>>>>>>>>> este deve ser documentado e seguido, fazendo um processes over people (em
>> >>>>>>>>>> oposição ao people over process do manifesto).
>> >>>>>>>>>>
>> >>>>>>>>>> Entendo o que vc quis dizer com evolucionário e revolucionário e
>> >>>>>>>>>> acho que concordo. :-)
>> >>>>>>>>>>
>> >>>>>>>>>> Abraço!
>> >>>>>>>>>>
>> >>>>>>>>>> Peter P. Lupo
>> >>>>>>>>>> Undergraduating in Computer Science DCC/UFRJ
>> >>>>>>>>>> MPS.BR Authorized Implementation Practitioner
>> >>>>>>>>>> Sun Certified Java Associate
>> >>>>>>>>>> http://sites.google.com/site/pplupo
>> >>>>>>>>>> Cell. +55 (021) 81742487
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> 2009/6/11 Clavius Tales (Fortes Informática)
>> >>>>>>>>>> <tales@...>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Oi, Peter.
>> >>>>>>>>>>>
>> >>>>>>>>>>> ----- Original Message -----
>> >>>>>>>>>>> From: Peter P. Lupo
>> >>>>>>>>>>> To: xprio@yahoogroups.com
>> >>>>>>>>>>> Sent: Monday, June 08, 2009 11:50 AM
>> >>>>>>>>>>> Subject: ** POSSIVEL SPAM ** Re: [xprio] Qual o nome da
>> >>>>>>>>>>> metodologia não agil? (SOLUCIONADO)OLUCIONADO)
>> >>>>>>>>>>> Estes modelos e frameworks não são feitos para burocratizar. São
>> >>>>>>>>>>> feitos para (entre outras coisas) "institucionalizar", o que são coisas BEM
>> >>>>>>>>>>> diferentes.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Sobre institucionalizar, dá uma olhada nisso aqui:
>> >>>>>>>>>>> http://blogue.claviustales.com.br/2009/05/01/governanca-agil/. Abaixo as
>> >>>>>>>>>>> certificações a la CMMI.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Por último, não há tanta novidade assim em metodologias Ágeis
>> >>>>>>>>>>> quanto se pensa. A novidade é trazer tudo junto, em frameworks simples de se
>> >>>>>>>>>>> aplicar onde as deficiências de uma técnica são amparadas por outra. De
>> >>>>>>>>>>> resto, são práticas antigas reformadas com outros nomes.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Do ponto de vista das práticas, é um processo evolucionário,
>> >>>>>>>>>>> concordo. Do ponto de vista do mind-set, é revolucionário, sim.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Um abraço.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Tales
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>> Sigmar Siqueira
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>
>