Comentários sobre: Desenvolver software é como dirigir http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/ Escritos sobre tecnologia, programação e lendas. Fri, 30 Oct 2009 17:41:12 +0000 http://wordpress.com/ hourly 1 Por: Fábricas de software - Uma analogia levada longe demais at Mergulhando no Caos http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-67 Fábricas de software - Uma analogia levada longe demais at Mergulhando no Caos Fri, 12 Sep 2008 17:04:48 +0000 http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-67 [...] aqui, mas o Marcos Pereira saiu na minha frente com o primeiro artigo do seu novo blog que discute várias das mais furadas analogias para desenvolvimento de software (e uma das certeiras). Ao invés disso, este artigo vai se deter em apenas uma delas: a das [...] [...] aqui, mas o Marcos Pereira saiu na minha frente com o primeiro artigo do seu novo blog que discute várias das mais furadas analogias para desenvolvimento de software (e uma das certeiras). Ao invés disso, este artigo vai se deter em apenas uma delas: a das [...]

]]> Por: ExpressoJava» Blog Archive » Desenvolver software é como dirigir http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-55 ExpressoJava» Blog Archive » Desenvolver software é como dirigir Tue, 11 Mar 2008 14:14:21 +0000 http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-55 [...] Motor Curiosidade Analogias são uma maneira poderosa de explicar algum conceito: parte-se de um principio já [...] [...] Motor Curiosidade Analogias são uma maneira poderosa de explicar algum conceito: parte-se de um principio já [...]

]]> Por: Vinicius AC http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-15 Vinicius AC Fri, 10 Aug 2007 18:36:37 +0000 http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-15 Olá, Marcos. Essa msg era pra ir por email, mas não encontrei, então vai por aqui. Pode apagar após ler, se quiser. Obrigado por adicionar um link para meu blog. Fico feliz com a divulgação. Vou adicionar o seu também. Começou com um ótimo post. Parabéns! Aguardo o segundo. :-) Olá, Marcos.
Essa msg era pra ir por email, mas não encontrei, então vai por aqui. Pode apagar após ler, se quiser.
Obrigado por adicionar um link para meu blog. Fico feliz com a divulgação.
Vou adicionar o seu também. Começou com um ótimo post. Parabéns!
Aguardo o segundo. :-)

]]> Por: Eduardo Miranda http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-14 Eduardo Miranda Tue, 31 Jul 2007 13:32:54 +0000 http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-14 Esqueci de comentar mais uma coisa: É impressionante como alguns clientes agem de forma irracional em relação ao seu "seguro" quando lidam com fornecedores de software. Eles realmente acreditam, ou fingem acreditar, que como está escrito no contrato, o fornecedor irá cumprir, não interessa o que acontecer no meio do caminho. Isto é como dirigir de olhos vendados, só porque você um seguro de carro. Esqueci de comentar mais uma coisa: É impressionante como alguns clientes agem de forma irracional em relação ao seu “seguro” quando lidam com fornecedores de software.

Eles realmente acreditam, ou fingem acreditar, que como está escrito no contrato, o fornecedor irá cumprir, não interessa o que acontecer no meio do caminho. Isto é como dirigir de olhos vendados, só porque você um seguro de carro.

]]> Por: Eduardo Miranda http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-13 Eduardo Miranda Tue, 31 Jul 2007 13:27:41 +0000 http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-13 Adorei a analogia de dirigir carro. Imagina um cara que treinado, ou "lobotimizado" em CMMI tentando dirigar no estilo "waterfall". Ele traça um plano no mapa, estebelece os riscos, pega a assinatura do cliente e parte para a rua. Cruzando o primeiro moto-boy ele vai ter que congelar o projeto, escrever um change request e revisar o project, pois isto não estava previsto. Eu que não queria cruzar no caminho dele... Brincadeiras à parte, o texto ficou muito legal, parabéns. Adorei a analogia de dirigir carro. Imagina um cara que treinado, ou “lobotimizado” em CMMI tentando dirigar no estilo “waterfall”. Ele traça um plano no mapa, estebelece os riscos, pega a assinatura do cliente e parte para a rua. Cruzando o primeiro moto-boy ele vai ter que congelar o projeto, escrever um change request e revisar o project, pois isto não estava previsto. Eu que não queria cruzar no caminho dele…

Brincadeiras à parte, o texto ficou muito legal, parabéns.

]]> Por: Thiago Leite. http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-12 Thiago Leite. Mon, 30 Jul 2007 00:43:51 +0000 http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-12 Se fôssemos colocar nessa história os seguintes atores: - Carro; - Caminho; - Ponto de chegada. Quem seriam os personagens? Pra mim o carro seria a equipe de desenvolvimento, o caminho toda a fase de construção do software e o ponto de chegada o perfeito funcionamento do software no cliente. Abraço, Thiago Obs: BOm artigo Marcos. Se fôssemos colocar nessa história os seguintes atores:

- Carro;
- Caminho;
- Ponto de chegada.

Quem seriam os personagens?

Pra mim o carro seria a equipe de desenvolvimento, o caminho toda a fase de construção do software e o ponto de chegada o perfeito funcionamento do software no cliente.

Abraço,

Thiago

Obs: BOm artigo Marcos.

]]> Por: Passeio pela blogosfera - vida inteligente encontrada « Salada Digital http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-11 Passeio pela blogosfera - vida inteligente encontrada « Salada Digital Sat, 28 Jul 2007 00:39:13 +0000 http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-11 [...] Desenvolver software é como dirigir « On the Next Startup Uma analogia um tanto quanto complicada, mais ainda assim achei legal… isso porque foi o primeiro post do cara, alias é a segunda pessoa usando o mesmo tema para o blog que vejo (e daí?). [...] [...] Desenvolver software é como dirigir « On the Next Startup Uma analogia um tanto quanto complicada, mais ainda assim achei legal… isso porque foi o primeiro post do cara, alias é a segunda pessoa usando o mesmo tema para o blog que vejo (e daí?). [...]

]]> Por: Proteu Alcebidiano http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-10 Proteu Alcebidiano Fri, 27 Jul 2007 15:42:01 +0000 http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-10 Marcos, parabéns pelo novo blog. Pelo que vi, a idéia é ter controle do dinamismo sem perder a dinamicidade. O interessante é como manter uma certa disciplina sendo dinâmico. O trânsito tem regras: cabe a nós obedecê-la para os softwares, que não são regras fixas e não tão constantes assim, mas sabemos que entre todas elas temos algo em comum. Favorecer uma linguagem comum, disciplinar, controlada e flexível é o caminho para colocar ordem no caos. Não enrijecer o caos, vamos caminhar com ele! T+ Glaucio. P.S.: Seria legal perguntar a alguém que manja de sistemas dinâmicos (é aquelas da física mesmo) se nós temos chance de aprender algo com eles dentro do nosso próprio universo. ae Marcos, parabéns pelo novo blog. Pelo que vi, a idéia é ter controle do dinamismo sem perder a dinamicidade.

O interessante é como manter uma certa disciplina sendo dinâmico. O trânsito tem regras: cabe a nós obedecê-la para os softwares, que não são regras fixas e não tão constantes assim, mas sabemos que entre todas elas temos algo em comum.

Favorecer uma linguagem comum, disciplinar, controlada e flexível é o caminho para colocar ordem no caos.

Não enrijecer o caos, vamos caminhar com ele!

T+

Glaucio.

P.S.: Seria legal perguntar a alguém que manja de sistemas dinâmicos (é aquelas da física mesmo) se nós temos chance de aprender algo com eles dentro do nosso próprio universo.

ae

]]> Por: marcospereira http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-9 marcospereira Wed, 25 Jul 2007 18:59:44 +0000 http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-9 Vinicius, mesmo pensamento. Para mim, o prevenir é se preparar para mudar, como é o caso de TDD, por exemplo. Criar um ambiente resiliente, onde a mudança seja acomodada mais facilmente, é bem mais interessante do que se prender a um plano feito quando a verdade era outra, e como bem sabemos, verdade é o que conhecemos em determinado momento. ps.: Legal o teu blog, coloquei na blogroll daqui. Vinicius, mesmo pensamento. Para mim, o prevenir é se preparar para mudar, como é o caso de TDD, por exemplo. Criar um ambiente resiliente, onde a mudança seja acomodada mais facilmente, é bem mais interessante do que se prender a um plano feito quando a verdade era outra, e como bem sabemos, verdade é o que conhecemos em determinado momento.

ps.: Legal o teu blog, coloquei na blogroll daqui.

]]> Por: Vinicius AC http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-8 Vinicius AC Wed, 25 Jul 2007 18:12:38 +0000 http://marcospereira.wordpress.com/2007/07/24/desenvolver-software-e-como-dirigir/#comment-8 Comentando o comentário de Leando (logo acima). Concordo com o ele. Só queria comentar que o "prevenir é melhor que remediar" aplicado a desenvolvimento de software me lembrou o "Responder a mudança é mais importante que seguir um plano". O prevenir pode dar a idéia de que é melhor planejar toda a viagem, antes de partir, e tentar seguir este plano. Isto é ruim, pois não há como saber com segurança em que locais e quantos pedestres, outros carros, buracos, desvios, etc... serão encontrados no caminho. Seguir um planejamento detalhado engessa e inibe adaptações durante o percurso. O remediar é interessante quando aplicado em pequenas e repetitivas doses, soa como adaptar, ou seja, o percurso vai sendo percorrido e os pequenos imprevistos vão sendo remediados com base no feedback da própria viagem. :) Abraços! Comentando o comentário de Leando (logo acima). Concordo com o ele. Só queria comentar que o “prevenir é melhor que remediar” aplicado a desenvolvimento de software me lembrou o “Responder a mudança é mais importante que seguir um plano”. O prevenir pode dar a idéia de que é melhor planejar toda a viagem, antes de partir, e tentar seguir este plano. Isto é ruim, pois não há como saber com segurança em que locais e quantos pedestres, outros carros, buracos, desvios, etc… serão encontrados no caminho. Seguir um planejamento detalhado engessa e inibe adaptações durante o percurso. O remediar é interessante quando aplicado em pequenas e repetitivas doses, soa como adaptar, ou seja, o percurso vai sendo percorrido e os pequenos imprevistos vão sendo remediados com base no feedback da própria viagem. :)
Abraços!

]]>