Никогда ничего не делайте, пока не будете готовы использовать это, в том числе и в программном обеспечении?[Принцип Toyota] [закрыт]

Question

я слушал подкаст.Где они говорили о принципах, которые использовала Toyota:

Никогда ничего не делайте, пока не будете готовы это использовать.

Я думаю, это подсказывает нам поискать в других местах, узнать, какие другие практики известны уже много лет.

Answer 1

Это может применим к созданию программного обеспечения, но я не уверен в этом делает применять

Если мы рассмотрим пять элементов в «Toyota-способ принятия решений«, основанный на принципе, что «то, как вы приходите к решению, так же важно, как и качество решения»:

[режим юмора включен]

• Выяснение того, что происходит на самом деле, включая генчи гембуцу.

  Вот только когда-нибудь наконец-то понимаешь, что происходит, когда клиент объясняет нам в конце проекта;)

• Понимание основных причин, которые объясняют поверхностные явления - будьте «Почему?» в пять раз.

  Конечно, но клиент недостаточно доступен во время проекта;)

• Широкое рассмотрение альтернативных решений и разработка подробного обоснования предпочтительного решения.

  Поздно, программисты уже кодят как сумасшедшие :)

• Достижение консенсуса внутри команды, включая сотрудников Toyota и внешних партнеров.

  Упс, этот программист уже переписывает систему аутентификации, хотя старая работала нормально

• Использование очень эффективных средств коммуникации для выполнения от одного до четырех, предпочтительно одной стороны одного листа бумаги.

  Вы слышали «смерть от Power Point»?Это не всегда наша сильная сторона ;)

[режим юмора ВЫКЛ]

Серьезно, как говорилось в предыдущих ответах, философия Agile действительно затрагивает некоторые основные принципы этого принципа Toyota.

И это может быть немного богаче, чем просто «Тебе это не понадобится», как описано в книге «Тебе это не понадобится».Путь Тойоты"

Answer 2

Типа, да.Это основная часть гибкая философия.

По сути, отдавайте предпочтение гибкости и скорости реагирования, а не масштабному проектированию и громоздким спецификациям.Один из лучших способов сделать это — построить достаточно, чтобы удовлетворить ваши текущие требования, потому что никогда не знаешь, когда они изменятся.

Answer 3

Это немного старая новость.Его часто называют «Тебе это не понадобится» («Тебе это не понадобится» на неидоматическом английском языке) и сокращается. ЯГНИ.

Проблемы, связанные с реализацией функции, когда она вам не нужна:

• реализация отнимает время у разработки необходимых функций
• эту функцию сложно документировать и тестировать, поскольку, если она вам не нужна, кто знает, что именно она должна делать?
• поддержание этой функции займет дополнительное время
• эта функция добавляет дополнительный код, усложняя кодовую базу
• эта функция может иметь эффект снежного кома, в результате чего она предлагает другие функции, которые вы, возможно, захотите добавить, даже если они не нужны.

Answer 4

Думать именно так — хорошая гибкая практика.Существует также нечто, называемое «Разработка через тестирование», которое помогает вам получать программное обеспечение без ошибок (почти), но также имеет побочный эффект, заключающийся в том, что НИЧЕГО не реализовано, что вы не используете.

Пример: у вас есть собственный класс коллекции.Если вам нужны только метод Add и метод ToArray, то зачем тратить время на реализацию методов Remove и Count?

Так что да.Следуйте этому принципу :)