За чем в первую очередь необходимо следить при итеративной разработке
За чем в первую очередь необходимо следить при итеративной разработке
Проект, в котором применяется итерационная разработка, имеет жизненный цикл, состоящий из нескольких итераций. Итерация включает приблизительно последовательный набор задач бизнес-моделирования, требований, анализа и проектирования, реализации, тестирования и развертывания в различных пропорциях, в зависимости от расположения итерации в цикле разработки. Итерации на начальном этапе и этапе уточнения фокусируются на управлении, требованиях и проектировании; итерации на этапе построения фокусируются на проектировании, реализации и тестировании; а итерации на этапе внедрения фокусируются на тестировании и развертывании. Итерациями следует управлять как timeboxed, то есть расписание итерации следует считать фиксированным и управлять областью содержимого итерации, чтобы она соответствовала этому расписанию.
Зачем нужна итерационная разработка?
В начальном проекте по отношению к его ключевым требованиям с большой вероятностью будут содержаться ошибки. Позднее обнаружение дефектов проекта приводит к дорогостоящим затратам и, в некоторых случаях, даже к прекращению проекта.
Любой проект влечет за собой определенные риски. Чем раньше в жизненном цикле можно проверить отсутствие рисков, тем более точно можно выполнять планирование. Многие риски не удается обнаружить до тех пор, пока не будет предпринята попытка интеграции системы. Невозможно предугадать все риски, независимо от опыта коллектива разработчиков.
В водопадном жизненном цикле невозможно убедиться в отсутствии рисков на ранних этапах жизненного цикла.
В итерационном жизненном цикле вы на основании списка ключевых рисков выбираете инкремент для разработки в итерации. Поскольку в итерации создается протестированный исполняемый продукт, то можно проверить, были ли в результате снижены риски или нет.
Преимущества итерационного подхода
Итерационный подход в целом имеет преимущество перед линейным или водопадным подходом по целому ряду причин.
Однажды заказчик сказал: «При водопадном подходе все выглядит прекрасно практически до конца проекта, иногда вплоть до середины интеграции. А затем все распадается. При итеративном подходе очень трудно долго скрывать правду.»
Руководители проектов часто оказывают сопротивление итерационному подходу, считая его бесконечным. В Rational Unified Process итерационный подход полностью управляем; планируется число, продолжительность и цели итераций. Определяются задачи и ответственности участников. Собираются объективные показатели выполнения. От одной итерации к следующей существует некоторый объем повторяющихся действий, однако это также тщательно контролируется.
Снижение рисков
Итерационный подход позволяет снизить риски раньше, поскольку многие риски обнаруживаются только во время интеграции. При развертывании ранней итерации вы проходите через все разделы, изучая многие аспекты проекта: инструменты, готовое программное обеспечение, навыки сотрудников и так далее. Предполагаемые риски могут не подтвердиться, в то время как могут быть обнаружены новые, неожиданные риски.
Внесение изменений
Итерационный подход позволяет учитывать изменения в требованиях, поскольку обычно они будут изменяться по мере работы над проектом.
Итеративный жизненный цикл обеспечивает управление путем внесения тактических изменений в продукт. Например, для того чтобы составить конкуренцию существующим продуктам, вы можете принять решение выпустить продукт с ограниченным набором функций раньше, для того чтобы опередить действия конкурента, либо можно адаптировать другого вендора для данной технологии.
Итерации также поддерживают технологические изменения по мере продвижения работы над проектом. Если какая-либо технология изменяется или становится стандартом при появлении новой технологии, то это может дать проекту определенные преимущества. Это в особенности относится к изменениям платформы и изменениям инфраструктуры на более низких уровнях.
Достижение более высокого качества
Итерационный подход позволяет получить более устойчивую архитектуру, поскольку ошибки исправляются на протяжении нескольких итераций. Первые дефекты обнаруживаются уже в первых итерациях продукта. Обнаруживаются узкие места в производительности, которые можно исправить сразу, а не непосредственно перед доставкой.
Итерационная разработка, в отличие от выполнения тестов в конце проекта, позволяет протестировать продукт более тщательно. Наиболее важные функции можно протестировать в нескольких итерациях.
Обучение и улучшение
Разработчики могут обучаться по мере продвижения работы, и различные умения и специализации более полно используются в течение всего жизненного цикла.
Тестеры, вместо длительного ожидания, в течение которого они только строят планы и оттачивают свои навыки, начинают выполнять тестирование раньше, раньше начинается создание технической документации и так далее. При оценке ранних итераций можно обнаружить необходимость в дополнительном обучении или помощи извне.
Также можно улучшить сам процесс. Оценка в конце итерации не только дает обзор состояния проекта с точки зрения планирования продукта, но также позволяет проанализировать, что необходимо изменить в организации и проекте для улучшения работы в следующей итерации.
Увеличение возможностей повторного применения
Итерационный жизненный цикл облегчает повторное применение. Облегчается идентификация стандартных компонентов, если они разрабатываются или реализуются по-отдельности, по сравнению с идентификацией всей общности.
Идентификация и разработка многоразовых компонентов является сложной задачей. Обзоры проекта в ранних итерациях позволяют архитекторам программного обеспечения обнаружить возможность потенциального повторного применения, и в последующих итерациях они могут далее разрабатывать и развивать этот стандартный исходный код.
Применение итерационного подхода облегчает использование преимуществ коммерческих готовых продуктов. На протяжении нескольких итераций можно выбрать такие продукты, интегрировать их и убедиться, что они соответствуют данной архитектуре.
© Copyright IBM Corp. 1987, 2006. Все права защищены..
BYTEX BLOG
Модели разработки и тестирования ПО: Итеративная модель
Жизненный цикл итеративной модели не начинается с полной спецификации требований. Вместо этого разработка стартует с определения и внедрения части программного обеспечения, которая затем может быть пересмотренa для выявления дальнейших требований. Затем процесс повторяется, создавая новую версию программного обеспечения для каждого цикла модели.
Итеративная модель жизненного цикла ПО состоит из повторения следующих четырех фаз:
Для каждого цикла модели необходимо принять решение, будет ли программное обеспечение, созданное циклом, отброшено или сохранено в качестве отправной точки для следующего цикла (иногда называемого инкрементным прототипированием). В конце концов, будет достигнута точка, когда требования будут завершены, и программное обеспечение может быть выпущено, или становится невозможным улучшить программное обеспечение для соответствия требованиям, из-за чего может потребоваться старт с чистого листа.
Итеративную модель можно сравнить с производством программного обеспечения путем последовательного приближения. Проводя аналогию с математическими методами, которые используют метод последовательного приближения для достижения окончательного решения, преимущество таких методов зависит от того, насколько быстро они его достигают.
Ключом к успешному использованию итеративного жизненного цикла разработки программного обеспечения является тщательная проверка требований и каждой версии программного обеспечения в соответствии с этими требованиями в каждом цикле модели.
Первые три фазы типичной итеративной модели на самом деле являются сокращенной формой последовательной V-модели или каскадной модели. Каждый цикл модели производит программное обеспечение, которое требует тестирования на уровне мелких элементов для интеграции программного обеспечения, для системной интеграции и одобрения. По мере того как программное обеспечение развивается через последовательные циклы, тесты должны повторяться и расширяться для проверки каждой новой версии.
В чем разница между Инкрементальной моделью и Итеративной?
При инкрементальном подходе используется определенное количество шагов, и развитие идет от начала до конца по линейному пути прогрессии.
Инкрементальное развитие осуществляется поэтапно, начиная с проектирования, внедрения, тестирования/проверки, технического обслуживания. Они могут быть разбиты далее на подэтапы, но большинство инкрементных моделей следуют тому же шаблону. Каскадная модель — это традиционный подход к постепенной разработке.
В Итеративном подходе нет определенного количества шагов. Разработка скорее выполняется в циклах.
Итеративная разработка в меньшей степени завязана на отслеживании прогресса отдельных функций. Вместо этого основное внимание уделяется созданию рабочего прототипа в первую очередь и добавлению функций в течение циклов разработки, где шаги «Приращение развития» выполняются для каждого цикла. Гибкое моделирование — типичный итеративный подход.
Вигерс, ты не прав! Ещё раз об итеративной и инкрементальной разработке
Наверное, всякий, кто когда-либо пытался осознать специфику различных подходов к разработке программного обеспечения, задавался вопросами: в чём отличие между итеративной и инкрементальной разработкой? Agile – итеративный? RUP – инкрементальный?
Под катом очередное рассуждение на эту тему и заочный спор с Карлом Вигерсом.
В 3-м издании книги Карла Вигерcа «Разработка требований к программному обеспечению» есть иллюстрация, демонстрирующая распределение усилий по работе с требованиями на протяжении проектов с разным жизненным циклом разработки (SDLC). 
Итак, картинка разделяет Agile и итеративные подходы. Корректно ли это?
«Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки…»
Значит, если в рамках спринта в гибком Scrum’е или итерации в RUP Вы перерабатываете результаты предыдущего этапа и одновременно реализуете новые части продукта, Ваша разработка и итеративна, и инкрементальна.
Ниже изображение, поясняющее разницу между итеративной и инкрементальной разработкой на примере создания портрета Карла Вигерса.
Вывод
Разделять гибкие и итеративные подходы некорректно. Вигерс, ты не прав!
Итеративная разработка программного обеспечения
Итеративная разработка ПО — это процесс создания программного обеспечения, который осуществляется небольшими этапами, в ходе которых ведется анализ полученных промежуточных результатов, выдвигаются новые требования и корректируются предыдущие этапы работы.
Жизненный цикл проекта при итерационной разработке разбит на последовательность итераций, каждая из которых, по сути, является проектом в миниатюре, то есть включает в себя все процессы разработки ПО (сбор и анализ требований, составление спецификаций, непосредственную реализацию, тестирование и запуск), но в рамках одной итерации разрабатывается не весь проект, а только его версия или отдельная часть.
Как правило, цель каждой итерации — это получение версии ПО, включающей в себя как новые или преработанные возможности, реализованные в ходе текущей итерации, так и функциональность всех предыдущих итераций. Результат же финальной итерации содержит всю требуемую функциональность продукта.
Бюджет и сроки, необходимые для реализации финальной версии обычно изначально не устанавливаются, так как не определяется общий объём работ и требования формируются по ходу реализации.
Итеративная, итерационная, инкрементная и эволюционная разработка — фактически, это синонимы.
Итеративность (iteration, «повторение») в данном случае означает подход, основаный на выполнении задач в рамках «мини-проектов», инкрементность (increment «увеличение») означает последовательное добавление функционала к разрабатываемому продукту, а эволюционность (evolutio, «развёртывание») — процесс развития продукта, напоминающий естественное развитие биологических видов.
Водопадная и итеративная модели разработки
Метафорически сравнение водопадной и итеративной моделей разработки часто описывают на примере разработки транспортного средства.
В случае с «водопадом» сначала описываются требуемые характеристики автомобиля, затем по этим требованиям разрабатывается проектная документация. После составления проектной документации собираются отдельные узлы автомобиля и происходит их взаимная интеграция. Результат сборки тестируется на соответствие проектной документации и после это созданный автомобиль передается заказчику. Все эти этапы занимают достаточно продолжительное время, а пригодный для использования продукт заказчик получает только в самом конце.
В случае с итеративным подходом всё несколько иначе. Изначально ставится задача разработки транспортного средства. И результатом первой итерации может быть вариант такого транспортного средства — например, самокат. Для него не нужен двигатель внутреннего сгорания и собрать его можно в десятки раз быстрее, чем автомобиль. Да, самокат проигрывает автомобилю по очень многим характеристикам, но он всё же более эффективен для передвижения, чем хождение пешком. Результатом второй итерации может быть уже самокат с электродвигателем. На третьей итерации — у самоката могут быть увеличены колеса и он превратится в электровелосипед. На четвертой — электровелосипед может быть оснащён ДВС и станет мотоциклом.
По сути, с каждой итерацией повышаются функциональные возможности. И пока сторонники водопада ждут готовность создаваемого автомобиля, любители итерационного подхода уже пользуются транспортным средством. И вполне может быть, что получившийся в итоге мотоцикл — более правильный бизнес-результат.
Основные преимущества итеративной модели разработки
Снижение рисков — раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта; большая фокусировка на основных задачах; динамическое формирование требований и управление ими.
Организация эффективной обратной связи проектной команды с потребителем, создание продукта, реально отвечающего его потребностям.
Быстрый выпуск минимально ценного продукта (MVP) и возможность вывести продукт на рынок и начать эксплуатацию гораздо раньше.
Основные недостатки итеративной модели разработки
Проблемы с архитектурой и накладные расходы — при работе с хаотичными требованиями и без проработанного глобального плана архитектура приложения может пострадать, а на её приведение к адекватному виду могут потребоваться дополнительные ресурсы. По сути, за возможность менять требования в ходе создания продукта, приходится так или иначе расплачиваться.
Нет фиксированного бюджета и сроков, а также нужна сильная вовлеченность Заказчика в процесс — для некоторых Заказчиков это неприемлемые условия сотрудничества с разработчиком, им лучше подойдёт водопадная модель.
Резюме
Итеративная разработка отлично подходит для больших проектов, для проектов с неопределенными требованиями и для программных продуктов, которые носят инновационный характер и основаны на бизнес-гипотезах, требующих проверки.
Итеративная разработка — это оптимальный выбор:
Водопадная модель разработки
Водопадная модель разработки программного обеспечения — это процесс разработки, в котором все необходимые этапы проходят строго последовательно.
Разработка ПО по водопадной модели начинается со сбора и анализа требований, затем следует фаза проектирования и прототипирования. После завершения полного проектирования начинается этап программной реализации. После завершения этапа программирования разработанный продукт тестируется на соответствие требованиям. Затем осуществляется интеграция и запуск, после чего проект переходи в фазу поддержки и сопровождения.
Разработка ПО на основе водопадной модели эффективна при полном и детальном понимании целей и задач проекта. Благодаря работе по строгой спецификации, эта модель позволяет строго зафиксировать бюджет и сроки проекта.
Понятие итеративных процессов (с примерами)
Итеративный процесс — это одно из тех понятий (наряду с Agile), которые ассоциируются в большей степени с разработчиками. Однако, так или иначе, с этим явлением сталкивается большинство коллективов, ведь метод итеративных процессов помогает снизить риск, обеспечивать эффективность, а также более гибко и динамично решать проблемы.
Если вы хотите попробовать применить метод итеративных процессов, эта статья — для вас. В ней мы расскажем, как определить итеративные процессы и реализовать их в работе вашего коллектива.
Что такое итеративный процесс?
Итеративный процесс — это практика создания, проработки и совершенствования проекта, продукта или инициативы. Коллективы, применяющие метод итеративных процессов в разработке, создают, тестируют и исправляют свой продукт до тех пор, пока не будет получен нужный результат. Метод итеративных процессов, по сути, представляет собой метод проб и ошибок, который постепенно приближает проект к его конечной цели.
Итеративные процессы — это фундаментальная часть бережливых методов и управления проектами по системе Agile, но их можно применять в любом коллективе, а не только в Agile-командах. В рамках итеративных процессов вы постоянно совершенствуете дизайн, продукт или проект до тех пор, пока вы и ваши коллеги не будете удовлетворены конечным результатом проекта.
А что же такое неитеративный процесс?
В случае неитеративного процесса вы и ваша команда работаете вместе над разработкой конечного продукта. При этом вы необязательно пробуете новые идеи. Как правило, для неитеративных процессов требуется больше времени на этапе разработки концепции и создания продукта, чтобы на этапе тестирования всё работало так, как и было задумано.
Самый распространённый пример неитеративного процесса — это каскадная модель. В каскадной модели вы и ваша команда определяете этапы проекта до начала проекта. Каждый новый этап начинается после полного завершения предыдущего. Требования и ресурсы обычно фиксируются до начала проекта, и сотрудники по возможности стараются не менять план проекта.
Допустим, вы работаете с дизайнерским агентством над созданием электронной книги. Сначала необходимо предоставить полный текст этой книги. Затем дизайнерское агентство возьмёт этот текст и на его основе создаст варианты оформления. И в завершение ваша команда выполнит техническое редактирование электронной книги, чтобы всё было в порядке с точки зрения форматирования и вёрстки. Это пример каскадной модели, поскольку каждый очередной этап начинается после завершения предыдущего (нельзя приступить к вёрстке электронной книги, пока не будет разработан её дизайн).
В зависимости от того, чем занимается ваша команда и над какими проектами работает, неитеративные процессы могут представлять сложность, поскольку они не дают времени на повторную отработку и постоянное улучшение. Поскольку инженерные разработки сопряжены с неопределённостью, вместо неитеративных процессов разработчики обычно применяют итеративный метод. При этом он подходит коллективам и других типов.
Есть ли разница между инкрементным и итеративным подходом?
В большинстве коллективов понятия инкрементного проектирования и итеративных процессов используются как взаимозаменяемые, да и на практике они зачастую идут рука об руку. Но между этими двумя понятиями есть отличие.
В случае итеративного процесса ваша команда занимается проработкой и совершенствованием проекта на основе обратной связи или новой информации. Итеративный подход основан на принципе проб и ошибок: в результате этих постоянных изменений проект со временем становится всё лучше.
При инкрементном проектировании, которое иногда называют инкрементной разработкой, вы добавляете новые функции и усовершенствуете продукт на базе исходной версии или первого полученного результата. В случае инкрементного проектирования команда целенаправленно создаёт базовую версию продукта, чтобы как можно скорее выпустить его (как это было, например, в старой мантре Facebook: «двигайся быстрее, сокрушая всё на своём пути»). Затем разработчики дорабатывают и улучшают исходную версию, навешивая на неё новые элементы и функции. Этот процесс продолжается до тех пор, пока конечный продукт не будет обладать всем необходимым функционалом.
В большинстве коллективов, применяющих итеративный подход, используется инкрементное проектирование. Хорошие итеративные процессы также являются и инкрементными, позволяя постоянно улучшать первоначальную версию продукта. А хорошее инкрементное проектирование, в свою очередь, является итеративным, поскольку вы должны быть готовы реагировать на отзывы клиентов и вносить необходимые изменения.
Пример метода итеративных процессов
Инженерные разработки
Многие разработчики применяют итеративный подход для разработки новых функций, исправления ошибок и A/B-тестирования новых стратегий. Зачастую разработчики создают несколько итераций, которые, по их мнению, являются одинаково перспективными, а затем тестируют их на пользователях. Они фиксируют все плюсы и минусы, а затем продолжают работу с наиболее удачным вариантом.
Разработка продуктов
Возможно, вы удивитесь, но в большинстве случаев разработка продуктов очень итеративна. Вспомните какое-нибудь персональное устройство, которое вы покупали для себя. Скорее всего, у него уже была какая-то предыдущая версия, существовавшая до вашей покупки, а возможно, появилась и более новая версия после. Вспомните, как развивались мобильные телефоны на протяжении многих лет. Как с течением времени наушники становились всё более компактными и портативными. И как менялись холодильники одних и тех же марок, подстраиваясь под растущие потребности покупателей. Всё это — примеры итеративных процессов.
Маркетинг
Разные маркетинговые компании используют итеративные процессы в разной степени. Но маркетинг сам по себе в некотором смысле имеет итеративный характер. Например, специалисты по маркетингу могут тестировать различные рекламные тексты, чтобы выяснить, какой вариант получает больший отклик, или распространить две версии текста для рассылки, чтобы сравнить их показатели кликабельности. Кроме того, специалисты по маркетингу брендов могут использовать итеративные процессы для понимания того, какие визуальные образы лучше всего действуют на целевую аудиторию.
Продажи
Хотя большая часть работы, выполняемой отделом продаж, не является итеративной, для выполнения некоторых их задач может подойти итеративный подход. Например, отдел продаж может использовать итеративный подход для целей массовой рассылки. То есть осуществляется рассылка электронных писем с несколькими вариантами темы, а затем проводится анализ результата. Затем можно использовать самые удачные варианты темы, дающие максимальный результат.
Пять шагов итеративного процесса
Итеративный процесс может быть полезен на протяжении всего жизненного цикла проекта. В итеративном процессе ваши цели и требования принимаются в качестве отправной точки проекта. После этого команда будет производить тестирование, разработку прототипов и итерацию для достижения максимально эффективного результата. Для этого необходимо соблюдать нижеследующие правила.
1. Составление плана и требований
На этом шаге итеративного процесса определяется план проекта, а также выполняется согласование с общими целями проекта. Именно в этой точке проекта формулируются все самые значительные требования, от выполнения которых зависит успешность реализации проекта. Без этого действия итерация может не достичь своей цели.
2. Анализ и проектирование
На этом шаге вы с вашей командой занимаетесь бизнес-потребностями и техническими требованиями своего проекта. Если на первом шаге определялись цели, то на втором вы продумываете проект, который в конечном счёте поможет достичь этих целей.
3. Реализация
На третьем шаге создаётся первая итерация продукта реализации проекта. Данная итерация основывается на результатах анализа и проектирования и помогает достичь конечной цели проекта. Уровень детализации и время, затрачиваемое на эту итерацию, зависит от проекта.
4. Тестирование
После получения первой итерации производится её тестирование наиболее подходящим способом. Например, если вы работаете над улучшением веб-страницы, вам следует произвести A/B-тестирование относительно текущей версии веб-страницы. Если вы создаёте новый продукт или функцию, можно протестировать удобство их использования на потенциальных клиентах.
Помимо тестирования среди пользователей, также необходимо привлечь заинтересованные стороны проекта. Попросите их оценить итерацию и предоставить обратную связь.
5. Рассмотрение и оценка результата
После тестирования производится оценка успешности итерации и согласование необходимых изменений. Достигает ли эта итерация цели проекта? Почему? Если требуются изменения, можно возобновить итеративный процесс и начать со второго шага, создав следующую итерацию. Помните, что первоначальный план и цели должны быть одинаковыми для всех итераций. Продолжайте работу на основе предыдущей итерации, пока не добьётесь желаемого результата.
При повторном запуске итеративного процесса позаботьтесь о том, чтобы все руководствовались теми же целями проекта, что и раньше. Итеративный процесс может длиться неделями или месяцами в зависимости от количества итераций, через которые вам приходится пройти. Если всякий раз при повторном запуске итеративного процесса итерация будет сосредоточена на целях проекта, вы сможете всегда держать свои ориентиры в поле зрения.
Плюсы и минусы итеративного процесса
Итеративная модель не универсальна для всех коллективов и проектов. Ниже приводятся основные плюсы и минусы итеративного процесса для вашей команды.
Повышенная эффективность. Поскольку итеративный процесс представляет собой метод проб и ошибок, зачастую он помогает достичь желаемого результата быстрее, чем неитеративный процесс.
Расширенные возможности для совместной работы. Вместо работы по заранее определённому плану и техническому заданию (создание которых также занимает много времени), ваш коллектив активно выполняет совместную работу.
Высокая адаптивность. Получая новые данные на этапах реализации и тестирования, вы можете корректировать итерацию с учётом поставленных целей, даже если для этого придётся делать что-то такое, чего вы не планировали в начале итеративного процесса.
Высокая экономичность. Если вам понадобится изменить объём проекта, на выполнение этого процесса уйдёт минимум времени и усилий.
Возможность параллельной работы. В отличие от неитеративных методов, таких как каскадная модель, итерация не всегда зависит от завершённости предшествующей работы. Участники команды могут работать над несколькими элементами проекта одновременно, сокращая тем самым общую продолжительность проекта.
Сниженный риск на уровне проекта. В случае итеративного процесса риски выявляются и устраняются в ходе каждой итерации. Вам не приходится иметь дело с крупными рисками в начале и конце проекта: вы постоянно работаете над устранением рисков низкого уровня.
Более надёжная обратная связь с пользователями. Когда пользователи имеют возможность взаимодействовать с итерацией или просматривать её, они могут сообщать вам, что в ней работает правильно, а что нет.
Повышенный риск разрастания объёма. В силу экспериментального характера итерационного процесса ваш проект может начать развиваться неожиданным образом и выйти за пределы первоначального объёма.
Негибкое составление плана и требований. Первым шагом итеративного процесса является определение требований проекта. Изменение этих требований в рамках итеративного процесса может нарушить ход работы и привести к созданию итераций, не отвечающих целям проекта.
Неопределённые сроки. Поскольку команда создаёт, тестирует и корректирует итерации до тех пор, пока не добьётся нужного результата, определить чёткие сроки этого процесса не представляется возможным. Кроме того, длительность тестирования различных элементов может отличаться, что также отражается на общей продолжительности итерационного процесса.
Метод проб и ошибок
В конечном итоге любой коллектив может извлечь для себя что-то полезное из итеративного процесса. По возможности подходите к работе с позиции проб и ошибок. В случае сомнений проявляйте гибкость и обращайтесь за помощью к коллегам. И независимо от того, применяете ли вы итеративный метод, обязательно стремитесь к постоянному совершенствованию своей работы.