Nunca faça nada até que você está pronto para usá-lo, em software também? [Princípio Toyota] [fechado]
-
02-07-2019 - |
Pergunta
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.
Solução
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"
Outras dicas
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.
É 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
É 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:)