Процесс проектирования в робототехнике

Термин инжиниринг происходит от английского engineering, что в переводе означает «сооружать, проектировать, устраивать, затевать, придумывать, изобретать». Я буду подразумевать под этим термином применение практического и научного знания к решению проблемы на основе методики. Какой же методикой действительно пользуются инженеры для решения технических задач?

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

Можно думать об инженерном процессе проектирования как о рецепте выпечки пирога. Это можно сделать множеством различных способов но, как правило, все начинается с теста и заканчивается готовым пирогом. Я приведу лишь один из таких «рецептов» для процесса технического проектирования. Это не единственно правильный вариант процесса, это только один из примеров. Основываясь на этом примере, можно начать самостоятельно исследовать процесс разработки.

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

Вначале, в этом упрощенном цикле разработки, формируется идея (1). Затем эта идея реализуется (2). После того, как идея реализована, производится тестирование готового продукта и его оценка (3). Как правило, во время тестирования и оценки появляются новые идеи, улучшающие продукт, и процесс повторяется вновь. Из-за этого циклического процесса можно сказать, что разработка является итеративным процессом.

Итерация — это действие повторения чего-либо для улучшения процесса и, в конечном счете — достижения своей цели.

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

Давайте рассмотрим один из вариантов процесса инженерной разработки.

Шаг 1 — Определение задачи

На этом этапе необходимо выявить проблему, которую мы пытаемся решить.

Это один из наиболее важных шагов в процессе проектирования. Если мы полностью не понимаем задачу, то как мы можем решить ее успешно? Этот шаг зачастую выполняется неправильно, или не полностью, и в результате получается неправильная разработка. Очень важно определить истинную проблему, которую необходимо решить, а не только симптомы проблемы или ощущение проблемы.

Чтобы подчеркнуть важность этого шага, я расскажу одну интересную историю.

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

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

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

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

Вот некоторые примеры задач, с которыми может столкнуться разработчик и вопросы на которые необходимо найти ответы:

Какова самая эффективная стратегия для игры? Как нам выиграть матчи?
Как роботу набрать максимальное количество очков во время матча? Как нам забить голов больше, чем это смогут сделать наши оппоненты?
Насколько быстро робот должен двигаться?
Как нам ловить мяч?
Насколько быстро робот должен ловить?
Сколько объектов на игоровом поле, робот должен отслеживать?

Эти проблемы и вопросы имеют множество ответов. Одни ответы могут быть лучше, другие хуже. Как разработчику найти «правильное» решение или «правильный» ответ? Здесь уже вступает в игру остальная часть процесса разработки, но пока истинная проблема не определена, то и решена она быть не может!

Шаг 2 — Изучение имеющихся решений

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

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

Шаг 3 — Понимание требований

На этом этапе определяется что будет делать решение, не описывая то, как это будет делаться. Это делается через определение технических требований (спецификаций).

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

Технические требования, обычно, состоят из двух частей:

Ограничения, накладываемые на разработку
Требуемая функциональность

Каковы ограничения? Ограничение может быть определено как условие, удовлетворяющее решению задачи. Каковы функциональные требования? Функциональные требования описывают, насколько хорошо окончательное решение должно работать.

Опять же, технические требования очерчивают, что решение будет делать и насколько хорошо оно это сделает, а не как это будет сделано. Размышление о «как» на данном этапе процесса разработки может быть контрпродуктивным и может задушить творчество. В то же время, разработчик должен держать «как» в глубине души, потому что обязательно должно быть базовое понимание того, что это возможно. (Например, техническое требование о том, что новый ноутбук должен работать непрерывно в течение одного года от одной батареи типа АА не является разумным.)

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

Некоторые технические требования также связаны с имеющимися у разработчика ресурсами. Этот второй набор ограничений не всегда столь очевиден, но не менее, важен для учета в процессе проектирования. Примером таких ограничений может служить то, что «стоимость робота не должна выйти за рамки бюджета проекта» и «робот должен использовать уже имеющиеся у разработчика детали».

Другие самоограничения вращаются возле ограничений команды.

Одним из наиболее важных частей успешной генерации конструктивных ограничений в соревновательной робототехнике является понимание «своего потолка» (ведь, как говорят, выше головы не прыгнешь).

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

Часто команда бывает более успешной, выбрав простую конструкцию и реализовав ее очень хорошо, чем выбрав сложную конструкцию, которую она не способна сделать. Например, рассмотрим две команды, пытающиеся создать роботов, способных забивать футбольный мяч в ворота. Одна команда решает построить простой плуг, чтобы протолкнуть мяч в ворота. Другая команда пытается построить механизм с ногами, чтобы забивать мяч в ворота. Механизм с ногами может показаться лучшим решением, но что, если вторая команда не может на самом деле построить своего кикера (игрока, бьющего по мячу)? В этом случае, самым простым решением было бы выиграть! Вторая команда должна была рассмотреть свою способность завершить проект до того как они приняли проектное решение.

Следующая группа технических требований возникает из функциональных требований для робота. Это то, что робот должен быть способен делать. Например: робот может следить за 10 игровыми объектами, робот может поднять мяч на один метр, и так далее.

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

Ранжирование технических требований

Спецификации не равны - некоторые из них более важны для разработки, чем другие. Разработчик должен думать о том, что является наиболее важным, и почему. Технические характеристики часто ранжируются некоторым способом для обозначения их важности. Приведу пример:

C — желаемое требование. Не особо важно, но было бы неплохо, если это возможно .

B — преимущественное требование. Важно, но проект сможет и обойтись без этого.

A - необходимое требование. Критично для проекта, обязательно должно быть включено.

Не обязательно применять именно эту систему обозначений. Также можно использовать цифровой код (3-2-1), или какой-либо еще для обозначения важности технического требования для проекта.

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

При создании спецификаций можно перечислять несколько схожих характеристик с разным рейтингом, чтобы показать различные степени важности. Например:

Робот может отслеживать 5 игровых объектов - A
Робот может отслеживать 10 игровых объектов — B
Робот может отслеживать 15 игровых объектов — C

Шаг 4 — Представление идеи

На этом шаге идея формулируется, представляется, или понимается, конечный результат.

Сейчас инженер знает, что решение должно делать. Теперь осталось определить как это должно быть сделано.

«Набросок на салфетке». Эта фраза относится к привычке записывать идеи, где и когда бы они ни приходили вам в голову.

Мы делаем практически то же самое, когда сталкиваемся с проблемой или принимаем решение: мы думаем об альтернативных вариантах действий, даже если это делается подсознательно. Документирование этого интуитивного действия может помочь при решении сложных инженерных задач.

Это шаг, требующий немного творчества. Инженерам часто задают вопросы: «Как вы пришли к этому?», «Откуда вы черпаете идеи?». Идеи приходят отовсюду. Вдохновение может прийти откуда угодно!

Ключевые слова здесь: воображать и думать. Разработчику нужно провести мозговой штурм различных вариантов для выполнения технических требований. Нужно искать вдохновение везде. Необходимо «заимствовать из лучшего, затем изобрести все остальное». Хороший разработчик смотрит на окружающий мир, пытается искать решения, адаптируя их к своей проблеме. Инновация также важна в начале процесса проектирования. Необходимо искать баланс между «думать, выйдя за рамки» и «использовать уже реализованные конструкции».

Зачастую, дать хорошую концепцию может объединение двух идей или же компромисс между двумя различными предложениями. Опять же, усовершенствования и инновации в начале процесса дают даже лучшие результаты позднее в процессе.

Важно не останавливаться на заурядных концепциях и стремиться найти правильное решение. Часто это правильное решение само себя обнаруживает. Разработчики часто говорят: «Я чувствую, что это хорошее решение». Правильное решение будет просто казаться элегантным. К сожалению, не всегда это легко, и элегантность не всегда так очевидна.

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

Вернусь к соревновательной робототехнике. Здесь необходимо создавать целый ряд концепций. Команды разработчиков должны генерировать концептуальные стратегии, концепции для системы в целом, и концепции для отдельных подсистем и механизмов. Некоторые из этих систем будут зависеть и влиять друг на друга. Стратегия команды повлияет на общий дизайн системы, что в свою очередь влияет на различные подсистемы, а каждая из подсистем также влияет на общую систему.

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

Мозговой штурм

Этот этап в процессе инженерной разработки требует большого творческого потенциала и генерации ряда вариантов решения задачи. Для достижения этого используется инструмент, известный как мозговой штурм. Мозговой штурм — это упражнение, в котором группа людей работает совместно для генерации большого количества идей.

Некоторые важные правила:

При проведении мозгового штурма, необходимо сосредоточиться на количестве генерируемых идей, а не на их качестве. Идея здесь в том, что большое количество идей наверняка даст немного действительно хороших. Критиковать любые идеи на этом этапе категорически не рекомендуется.
Запасные суждения. Во время мозгового штурма нет плохих идей, потому что даже самые диковинные концепции могут вдохновить кого-то еще на то, чтобы придумать нечто великое. Сумасшедшие идеи могут быть улучшены и развиты в течение совместного процесса и стать вполне реализуемыми идеями.
Все должно быть записано. Необходимо документировать все идеи, появившиеся в ходе мозгового штурма.

Шаг 5 — Разработка прототипов

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

Нет необходимости макетировать все идеи. Макетировать нужно то, что хотелось бы чтобы работало.

В процессе прототипирования не всегда обязательно создается физический образец какого-либо устройства. Очень часто достаточным бывает численное моделирование или симуляция процессов и работы различных устройств и механизмов.

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

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

Шаг 6 — Выбор идеи

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

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

При выборе концепции в проектной группе, заманчиво провести голосование. Тем не менее, голосование является ничем иным, как необоснованным мнением, а оно ничего не стоит в инженерном обсуждении. Когда дело касается проектных решений, то лучше использовать объективизм и принимать логическое решение через консенсус (общее согласие). Важно стараться давать количественную оценку, насколько это возможно. Не следует просто говорить что что-то «лучше». Более правильным будет сказать сказать, что это на «14,8% легче», а затем доказать, почему это делает решение лучшим.

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

Инструмент принятия решений

Одним из инструментов, помогающим на этапе выбора концепции в процессе разработки является таблица взвешивания технических задач (WOT, Wieghted Objective Table), которую иногда называют матрицей принятия решений. Матрица принятия решений может использоваться, чтобы помочь разработчику выбирать между вариантами, основываясь на оценках по нескольким критериям. Матрица принятия решения является очень эффективным средством, потому что позволяет сравнивать альтернативы окончательного решения, основываясь на наибольшей важности.

Шаг 7 - Планирование

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

Хорошей идеей является создание 3D-модели робота в какой-либо CAD-системе. Этот процесс может занять достаточно много времени, но эта работа окупится в процессе производства.

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

Шаг 8 — График работ

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

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

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

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

Очень ценная наука, позволяющая понять, как оптимизировать шаги для оптимального достижения целей называется «Линейное программирование».

Шаг 9 — Представление предложения

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

Целью обзора проекта является не просто его утверждение. Это мероприятие также позволяет убедиться в том, что в разработке нет проблем, или же не осталось мест, в которых разработка не может быть улучшена. В процессе проектирования появляется несколько альтернативных концепций и одна из них выбирается. Одной из ключевых частей в презентации разработки является объяснение, почему был сделан именно такой выбор. «Почему ты это сделал, это так, а не сдалал этак?» Обзор должен гарантировать, что разработчик «внимательно отнесся к проблеме», что были исследованы различные альтернативы. Представление должно показать, что конструкция хорошо продумана, а не является первым, что пришло в голову.

Пример общих вопросов для обзора разработки:

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

Анализ выгод и затрат

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

«Затраты» не всегда относятся к деньгам. Затраты относятся к ресурсам, которые должны быть привлечены. Это может быть время, человеческие ресурсы, деньги, рабочая площадь, вес, и многое другое. Это может также относиться к позициям, которые должны быть принесены в жертву для того, чтобы реализовать элемент. Например, «если мы сделаем 2 шарнирный манипулятор, то у нас на роботе не останется места для приема мяча».

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

Эти соображения всегда необходимо держать в уме в процессе разработки.

Шаг 10 — Реализация

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

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

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

Шаг 11 — Тестирование

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

А что если разработка не признается приемлемой? В этом случае необходимо найти способ, чтобы сделать ее приемлемой! Необходимо придумать план улучшения, чтобы получить решение на должном уровне. Может быть придется даже начать все сначала, создав полностью новый план.

После того, как решение было реализовано, проведен его анализ, и разработка признана приемлемой, процесс проектирования будет завершен.

В соревновательной робототехнике тестирование может происходить и во время соревнований. Во время матча, очевидно, будет видно насколько хорошо робот работает! Однако, это не очень хорошая ситуация. Большинство разработчиков предпочли бы знать, насколько хорошо их робот будет работать, прежде чем он выходит на поле. Именно поэтому, в идеале, нужно завершить робота имея временной запас, чтобы была возможность проверить и улучшить его. Непрерывное совершенствование является ключом к успеху. В предварительном плане должно быть отведено место для тестирования и адаптации перед соревнованиями.

Шаг 12 - Итерация

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

Итерация осуществляется не только в конце процесса, но и на каждом его шаге.

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

Чем больше число итераций проходит проект, тем лучше будет конечный результат. Так когда же разработчик должен прекратить итерации?

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

Некоторые разработчики тратят больше времени, пока не решат что работа завершена, чем другие, потому что они стремятся к совершенству. К сожалению, в реальном мире не всегда возможно достичь совершенства. В повседневной жизни, если работа не завершена в срок, то она может потерять весь смысл, а второго шанса может не быть.

Мне очень нравится фраза: