Построить один, чтобы выбросить против эффекта второй системы

15

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

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

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

Я полагаю, что эти «хорошие практики» были впервые представлены в оригинальной книге Фреда Брукса «Мифический человеко-месяц ».

Я знаю, что некоторые из этих проблем решаются с помощью Agile-методологий, но в глубине души проблема остается в принципах; например, мы не будем вносить важные изменения в дизайн за 3 спринта, прежде чем начать работу.

m3th0dman
источник
3
Лично я думаю, что вам нужно три - один, чтобы понять основы проблемы, два, чтобы понять продвинутые вещи и третий, чтобы понять это правильно.
Уайетт Барнетт
5
@Wyatt: в моем случае правильное число, чтобы «сделать все правильно», это n + 1, n - текущая итерация
mattnz

Ответы:

23

Создание того, что нужно выбросить, происходит из-за того, что вы «не знаете, чего не знаете» с самого начала, поэтому по ходу дела вы узнаете, что должны были сделать в начале.

Второй системный эффект происходит от «теперь зная, что вы не знали, но не зная, что вы все еще не знаете», то есть второй системный эффект приходит от попытки построить большую, блестящую, более сложную систему, чем первая, без знания нужно с самого начала - очень похоже на то, что происходит с первой системой.

Поэтому второй системный эффект не является противоречием. Создание второй системы с той же функциональностью, что и первая, (насколько мне известно) никогда не завершалось. Вторая система всегда должна быть «лучше», поэтому более сложной, поэтому ожидаются проблемы, по существу аналогичные первой, - которые следует отбросить.

Так что создайте один, чтобы выбросить, выбросить его и построить его снова без увеличения объема, и у вас не будет второй проблемы с системой. (Это обычно делается на планетах с фиолетовым небом, розовым морем и летающими свиньями.)

mattnz
источник
Разве «первая система, которая будет выброшена», не является прототипом? Если это так, насколько я знаю, прототип обычно не обладает полной функциональностью, присущей продукту тендера; или, по крайней мере, в контексте одноразового прототипа.
m3th0dman
Вот почему вы должны серьезно рефакторинг в более поздних спринтах, отбрасывая ваши первоначальные попытки решить проблему, так как новые требования обнаруживаются в резерве вашего продукта.
Джоери Себрехтс
@Joeri Sebrechts Рефакторинг не означает отказ от первой системы; также вы не можете рефакторинг неправильных требований или плохой архитектуры ...
m3th0dman
Единственное, что я должен добавить к этому ответу, просто для ясности, это то, что вторая система относится ко второй производственной системе.
Томас Оуэнс
0

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

Управление качеством - сделай правильно с первого раза! Никогда не используйте временные взломы или временные компромиссы. Там не должно быть никаких переделок. Все ресурсы используются эффективно, и все, что вы делаете, является правильным вкладом в проект.

Анализ осуществимости - выявление потребностей бизнеса. Создайте экономическое обоснование для проекта.

План проекта - Четко определите свою начальную область, спланируйте, как будет доставлено решение, создайте базовую линию, придерживайтесь плана. Не тратьте время на то, что не находится на критическом пути.

Разработка требований - выявление бизнес-требований (т.е. захват бизнес-процессов и определение того, какие бизнес-операции должны поддерживаться компьютеризированной системой, перевод бизнес-операций 1: 1 в варианты использования системы). Подтвердите и подтвердите! (Правильно ли мы строим? Правильно ли мы строим?) Все требования должны быть связаны с первоначальной потребностью бизнеса.

Разработка программного обеспечения - преобразование вариантов использования и модели предметной области в дизайн компонентов и архитектуру решения. Все компоненты должны быть связаны с требованиями RE.

Реализация - код программного обеспечения, как в проекте. Весь код должен быть связан с компонентами из SD.

Валидация - модульное тестирование, интеграционное тестирование, производительность, ... (теперь необходимо протестировать все варианты использования от RE)

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

Посмотрите эти условия, чтобы создать лучшее программное обеспечение и понять его с первого раза:

  • Анализ осуществимости (особенно, как построить бизнес-кейс)
  • Управление проектом (особенно План проекта и Реестр рисков с уменьшением риска)
  • Разработка требований (выявление, анализ, спецификация, проверка)
  • Разработка программного обеспечения (UML и разработка программного обеспечения на основе компонентов)
  • Построение программного обеспечения (шаблоны проектирования, фреймворки, защитное программирование)
  • Проверка программного обеспечения (модульное тестирование, UAT и т. Д.)

источник
1
При изменении требований всегда будет необходимость доработки. Но в хорошо спроектированных системах эти переделки могут выполняться постепенно и чисто, не затрагивая несвязанные детали.
JesperE
Мечтать. Вы ожидаете, что клиент заранее знает, что он хочет / нуждается. Этого не происходит; Вот почему у нас есть гибкие методы.
Восстановить Монику - М. Шредер
Другими словами, изменения должны происходить только тогда, когда меняется бизнес-процесс компании, а это случается не так часто.