Nunca faça nada até que você está pronto para usá-lo, em software também? [Princípio Toyota] [fechado]

Question

Eu estava ouvindo um podcast . Onde falou sobre os princípios Toyota estava usando:

Nunca faça nada até que esteja pronto para usá-lo.

Eu acho que isso nos diz para olhar em outros lugares, para saber o que outras práticas já são conhecidos há anos.

Answer 1

pode se candidatar à construção de software, mas não tenho certeza de que faz se candidatar

Se considerarmos os cinco elementos em um " toyota -WAY de tomada de decisão ", com base no princípio de que 'como você chegar à decisão é tão importante quanto a qualidade da decisão':

[humor modo ON]

• Descobrir o que realmente está acontecendo, incluindo gembutsu genbutsu.

  A não ser que em algum momento, se faz finalmente entender o que está acontecendo quando o cliente explicar-nos no final do projecto;)

• causas subjacentes Entendendo que explicam superfície aparências-perguntando “Por quê?” cinco vezes.

  Claro, mas o cliente não é suficiente disponível durante o projeto;)

• De um modo considerando soluções alternativas e desenvolver uma lógica detalhado para a solução preferida.

  Muito tarde, os programadores são já codificação como loucos:)

• Obtenção de consenso dentro da equipe, incluindo os funcionários da Toyota e parceiros externos.

  Opa esse programador já está re-escrever o sistema de autenticação mesmo que o antigo estava funcionando bem

• Usando veículos de comunicação muito eficiente para fazer uma a quatro, de preferência um lado de uma folha de papel.

  Você ouviu "morte por PowerPoint"? Isso nem sempre é o nosso ponto forte;)

[Modo de humor OFF]

A sério, como indicado pelas respostas anteriores, a filosofia Agile faz endereço de alguns dos inquilinos fundamentais deste princípio Toyota.

E isso pode ser um pouco mais rico que apenas "yagni", como descrito no livro " A forma Toyota"

Answer 2

Mais ou menos, sim. Esta é uma parte essencial do ágil filosofia .

Basicamente, flexibilidade favor e rapidez de resposta ao longo do grande projeto de especificações da frente e de difícil manejo. Uma das melhores maneiras de fazer isso é apenas o suficiente de construção para atender às suas necessidades atuais, porque você nunca sabe quando eles estão indo para a mudança.

Answer 3

É notícia velha um pouco. É muitas vezes chamado de "yagni" ( "Você Arent' indo precisá-la" em não-idomatic Inglês) e abreviado YAGNI .

Os problemas associados com a implementação de um recurso quando você não precisa dele:

• a implementação leva tempo longe de desenvolver características que são necessários
• o recurso é difícil de documento e teste, pois se você não precisa dele, quem sabe o que é suposto fazer exatamente?
• manter o recurso vai levar tempo adicional
• o recurso adiciona código extra, o que complica a base de código
• o recurso pode ter um efeito de bola de neve, pelo que sugere outros recursos que você pode, então, pretende adicionar, mesmo que eles não são necessários

Answer 4

É uma prática boa ágil para pensar assim. Há também algo chamado Teste-Driven-Development, que ajuda a obter software sem bugs (quase), mas também tem esse efeito colateral que nada é implementado que você não usar.

Um exemplo é você próprio classe de coleção. Se você só está precisando de um método Add, e um método ToArray, então por que usar o tempo para implementar o Remover e Contagem métodos?

Então, sim. Siga esse princípio:)