Чем обусловлен итерационный характер проектирования
Вигерс, ты не прав! Ещё раз об итеративной и инкрементальной разработке
Наверное, всякий, кто когда-либо пытался осознать специфику различных подходов к разработке программного обеспечения, задавался вопросами: в чём отличие между итеративной и инкрементальной разработкой? Agile – итеративный? RUP – инкрементальный?
Под катом очередное рассуждение на эту тему и заочный спор с Карлом Вигерсом.
В 3-м издании книги Карла Вигерcа «Разработка требований к программному обеспечению» есть иллюстрация, демонстрирующая распределение усилий по работе с требованиями на протяжении проектов с разным жизненным циклом разработки (SDLC). 
Итак, картинка разделяет Agile и итеративные подходы. Корректно ли это?
«Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки…»
Значит, если в рамках спринта в гибком Scrum’е или итерации в RUP Вы перерабатываете результаты предыдущего этапа и одновременно реализуете новые части продукта, Ваша разработка и итеративна, и инкрементальна.
Ниже изображение, поясняющее разницу между итеративной и инкрементальной разработкой на примере создания портрета Карла Вигерса.
Вывод
Разделять гибкие и итеративные подходы некорректно. Вигерс, ты не прав!
. Организация итерационного процесса проектирования на уровне этапов при нисходящем проектировании
Обычно процессы нисходящего и восходящего проектирования сочетаются, реализуя важнейший принцип проектирования сложных ТС — итерационность. Этот принцип обуславливает последовательное приближение к оптимальным результатам путем многократного повторения выполнения проектных процедур. Причем если на очередном этапе проектирования результат не достигается, то проводится повторное выполнение проектных процедур предыдущих этапов.
На каждом иерархическом уровне итерационный процесс проектирования представляется как решение совокупности задач анализа и синтеза. Этот процесс можно проиллюстрировать схемой, приведенной на рис.1.7.
Разработка очередной подсистемы по ТЗ, предъявленному от предыдущего уровня проектирования, начинается с синтеза структуры. Исходный вариант структуры генерируется, а затем оценивается с позиции удовлетворения условий работоспособности.
Для каждого варианта структуры разрабатывается модель объекта (математическая или физическая). Модель должна быть адекватна ПО в отношении основных параметров. Численные значения параметров элементов модели устанавливаются на основании предварительных расчетов или интуиции и опыта инженера.
Далее для каждого варианта структуры предусматривается оптимизация параметров путем многократного анализа. Если для очередного варианта достигнуто выполнение условий работоспособности с заранее оговоренным запасом, то задача синтеза считается решенной. Результаты проектирования оформляются в виде необходимой технической документации и ТЗ на разработку следующей подсистемы.
Если условия работоспособности не выполняются, то изменяются управляемые параметры, и модель анализируется при новых значениях параметров. Если перебор многих параметров не приводит к успеху, то проверяют адекватность модели и при возможности корректируют ее, а в противном случае производят генерацию новой структуры.
Если перебор многих вариантов структуры не приводит к успеху, то ставится вопрос о пересмотре ТЗ, что влечет за собой, как правило, возвращение к предыдущему уровню проектирования и пересмотр принятых на нем решений. В связи с итерационным характером проектирования процедуры по приведенной схеме могут выполняться многократно.
Итерационное проектирование на проектах внедрения
В последнее время на проектах внедрения возникает все больше специфичных задач, решение которых вызывает определенные сложности: отсутствуют «лучшие практики», нет четких требований к результату, до конца не ясна целесообразность автоматизации.
Сибгатуллин Айрат, руководитель проектов DIRECTUM
В последнее время на проектах внедрения возникает всё больше специфичных задач, решение которых вызывает определенные сложности: отсутствуют «лучшие практики», нет четких требований к результату, до конца не ясна целесообразность автоматизации. Уверен, у каждого найдутся подобные примеры. Их объединяет одно: речь идет об уникальных процессах организаций со сложной методологией или процессах, которые существуют только «на бумаге» или «в головах». Данная статья посвящена нашему опыту реализации подобных проектов.
Стандартный проект внедрения состоит из 4-х этапов: исследование, проектирование, настройка и опытная эксплуатация. Глубоко убежден, что самым важным в данной цепочке является проектирование. На сколько грамотно и всесторонне будет составлено проектное решение, во многом зависит успех внедрения.
Но давайте подумаем, возможно ли в условиях высокой неопределенности в требованиях к информационной системе предельно точно описать как она будет работать в итоге. Описать можно, но в подавляющем большинстве случаев, после настройки и опытной эксплуатации вы получите совершенно иную систему. Это результат уточнения и появления новых требований, осознания того, что как оно написано в документе, должно работать иначе. Здесь критики могут возразить, что проектные решения для того и пишутся, чтобы не возникало подобных ситуаций. И я с ними соглашусь.
Но кому нужна полуработающая система, даже если сделана полностью по документации? Выход видится в более тщательной проработке документа, но подчас это потребует столько времени и денег, сколько есть на весь проект, а это неприемлемо.
Быть гибким
Анализируя данную проблему, я прихожу к выводу, что необходимо изменить сам подход к проектированию информационной системы без существенного увеличения его трудоемкости. На нескольких проектах мы применили итерационное проектирование, совместив этапы проектирования и настройки воедино. Эта методология базируется на принципах методик Agile и Scrum, но адаптирована нами под проекты внедрения ИС.
Итак, у нас есть «сложная задача», поставленная заказчиком. Первое, что необходимо выполнить – это удостовериться, что заказчик готов работать в нестандартном режиме. Он предполагает следующие особенности:
● Итоговый результат может существенно отличаться от первоначального представления заказчика, что является прямым следствием уточнения и изменения требований к системе.
● Не все требования и пожелания заказчика будут реализованы. Ограничения по срокам и бюджету позволят реализовать наиболее важные и приоритетные задачи, но в ущерб менее значимым пожеланиям.
● Значительное сокращение объема проектной документации. Для ряда организаций отсутствие проектных документов недопустимо, т.к. разработка подробного проектного решения является основным требованием при внедрении информационных систем.
● Проектирование и разработка будут вестись параллельно и небольшими итерациями. Результаты будут передаваться заказчику частями, а не полноценной функционирующей системой.
● Большая нагрузка на специалистов заказчика в течение всего проекта. Оценка получаемых результатов, принятие решений и корректировка требований требует значительного времени не только ИТ-специалистов, но и всех участников, задействованных во внедрении (ключевых пользователей и руководителей).
Ищем бизнес-ценности
В результате первоначального исследования должно сформироваться четкое понимание того, чего предстоит достичь. Можно долго и мучительно описывать процессы в формате «как есть» и «как будет», но в будущем они будут мало полезны, т.к. усилия будут сконцентрированы не на проектных документах, а на работающей системе. Поэтому более правильным будет фиксация требований сразу в журнал пожеланий в формате «как должно быть» и «почему». Это будет основной документ (и возможно единственный), с которым предстоит далее работать. Во многом он будет напоминать классический бэклог по Scrum.
Расставляем приоритеты
Основная проблема в дальнейшей работе состоит в том, что количество пожеланий с высоким приоритетом может быть достаточно большим. Поэтому у руководителя проекта и команды могут возникать сложности с тем, какие пожелания взять в работу в первую очередь, а какие оставить на потом. Для решения этой проблемы, удобно распределить пожелания по функциональным блокам. Это относительно независимые элементы будущей системы, дающие определенную бизнес-ценность для заказчика. Оптимальное их количество блоков – до 10.
Совместно с заказчиком выбираем те блоки, которые обеспечат ему наибольшую ценность системы. Именно их необходимо взять в работу в первую очередь. Во-первых, без их реализации ценность других блоков для бизнеса исчезнет. Во-вторых, заведомо известно, что на получение приемлемого результата может понадобится несколько итераций, а значит и больше времени. В бэклоге блоки удобно помечать цветами по принципу светофора: «красным», «желтым» и «зеленым». На первых итерациях полностью забываем про «желтые» и «зеленые» блоки и концентрируемся на важном.
Таким образом, мы получили несколько независимых бэклогов, которые могут быть распределены между несколькими командами проекта и реализовываться параллельно даже в рамках одной итерации.
Размер итерации
Существует много взглядов на длительность одной итерации. Мы пробовали продолжительность от одной недели до месяца. В первом случае, этого оказалось слишком мало и за этот срок не удавалось получить более-менее готовый результат для демонстрации заказчику. Во втором случае, команда начинала увлекаться, делая функциональность, от которой после демонстрации пришлось отказываться. Оптимальной оказалась длительность в 2 недели. Важно, что ни под каким предлогом мы не уменьшаем и не увеличиваем этот размер на протяжении всего проектирования. С одной стороны, это постоянно держит команду в тонусе, с другой – дает возможность планировать работы с горизонтом до 2-3 месяцев.
Более того, руководитель проекта получит важную информацию о планируемом количестве итераций, зная длительность этапа проектирования и длину одной итерации. Хорошо, когда оно совпадает с количеством функциональных блоков: с каждой новой итерацией в работу берется новый функциональный блок. В ином случае, предстоит брать на одну итерацию по несколько блоков, а это означает повышенную нагрузку на команду или необходимость привлечения дополнительных специалистов.
Оценка ресурсов
Слабое место итерационного подхода заключается в том, что без проектных решений бывает достаточно сложно оценить трудоемкость разработки. Если для внутренних проектов, выполняемых собственными специалистами организации это не столь критично, то для коммерческих проектов это ключевое ограничение. Более того, на таких проектах бюджет определяется еще на стадии пресейла и руководитель проекта сразу попадает в ограничение бюджета и ему важно не выйти за его рамки в процессе выполнения итераций. При выполнении расчета можно исходить из следующих известных данных и допущений:
● Обычно заранее известно, сколько специалистов привлекается на проект. Допустим два аналитика, два разработчика и один руководитель проекта;
● Итерационное проектирование требует полного погружения аналитиков и разработчиков на весь период. Исходим из того, что 90% своего времени они будут погружены в проект, а руководитель проекта на 50%;
● В неделе 40 рабочих часов;
● По первоначальной оценке потребуется 6 двухнедельных итераций;
Нехитрыми математическим расчетами получаем, что команде в этих условиях потребуется около 2000 чел/ч. Становится ясным, достаточно ли выделенного бюджета или требуется его переоценка. В случае возникновения резерва, у руководителя проекта появляется возможность направить ее на непредвиденные издержки или увеличить количество итераций.
Состав итерации
Условно, на любой итерации выполняются два вида работ: аналитика и разработка. При планировании работ мы обычно исходим из принципа равномерной загрузки команды. Но в силу быстротечности итерации этого достичь практически не получается: есть пиковые загрузки, а есть периоды «расслабления» у каждого участника. Поэтому важно спланировать итерацию таким образом, чтобы пики загрузки аналитика и разработчика по одному блоку работы не совпадали.
Методом проб и ошибок, мы пришли к выводу, что итерация должна начинаться с разработки. Поэтому к этому времени должны быть завершены основные аналитические работы. Это значит, что они начинаются еще в ходе выполнения разработки предыдущей итерации, когда загрузка разработчиков максимальна, а на их поддержку (уточнение требований, тестирование) требуется минимум времени аналитика (цифры в ячейках плана-графика означают уровень загрузки специалиста по 10-бальной шкале).
В первые дни итерации, разработчик и аналитик работают совместно над окончательным уточнением требований и постановки задачи на разработку. Далее начинается активный период разработки, на которой аналитик оказывает небольшие консультации разработчику и выполняет тестирование промежуточных результатов. Со второй недели итерации, аналитик приступает к аналитическим работам на следующую итерацию либо по текущему блоку работ, либо другому, согласно приоритетов плана-графика. За два дня до окончания итерации проводится демонстрация результатов заказчику. Получив обратную связь команда принимает решение о том какие замечания заказчика можно исправить до конца итерации, а какие передаются на следующую итерацию. Далее наступает следующая итерация.
Исход итераций
Любая итерация завершается демонстрацией системы. На первой итерации демонстрируется реализация ключевых пожеланий самого сложного блока. В этот момент от заказчика поступает множество замечаний о том, что «все не так» и «все должно быть иначе». И это нормально! Именно для этого мы затеяли итерации, чтобы корректировать свою работу с заказчиком с первых дней проекта. Скорее всего, придется выкинуть все, что было сделано за две недели и на следующей итерации сделать по-другому. В этот момент важно помнить о том, что в следующую итерацию необходимо взять еще один функциональных блок. Стоит дать слабину и сдвинуть его на следующую итерацию, как у вас «поплывет» весь первоначальный план. Даже при острой нехватке ресурсов, работы по блоку начать необходимо, по крайней мере взяв меньше пожеланий из бэклога. В результате на второй демонстрации заказчик получит дополнительный результат и увидит прогресс.
Обычно самыми сложными бывают первые две-три итерации, в ходе которых рождается основная архитектура системы, ее скелет. На сколько полно она будет соответствовать ожиданиям заказчика, во многом будет влиять исход всего проектирования и проекта. Может случиться и обратное: команда проекта и заказчик приходят к пониманию, что работы зашли в тупик – работы следует прекращать. Мы пришли к этому выводу на ранних этапах, а не в процессе тестовой эксплуатации, когда уже понесены значительные затраты. Как бы странно не звучало, но это тоже результат. Но если удалось успешно завершить первые итерации, то с большой долей вероятности остальные пройдут гладко.
Поскольку результатом каждой итерации являлся прототип, то последнюю итерацию следует выделить на доведение этого прототипа до полноценной системы, готовой к проведению тестовой эксплуатации. В этот момент проводится окончательная проверка полученной системы требованиям технического задания. В случае выявления несоответствий обязательно их зафиксировать и согласовать с заказчиком.
Несмотря на то, что мы сознательно минимизировали объем документирования, полностью от него отказаться невозможно. По крайней мере потребуется документирование полученной системы в виде инструкций пользователей и общего описания функционирования системы. Этого бывает вполне достаточно для начала тестовой и опытной эксплуатации.
Результаты
Итак, в результате итерационного проектирования мы получили тот же набор результатов, что и при последовательном выполнении сначала проектирования, а потом настройки системы. Опыт проектов, реализованных нами по данной схеме, показывает, что качество системы при этом значительно повышается. Оно оценивается в количестве дефектов и пожеланий, возникающих в процессе опытной эксплуатации: чем их меньше, тем выше качество.
Итерационный подход мы начали применять на проектах с труднопредсказуемым положительным результатом с целью уложиться в установленный бюджет. Не скажу, что мы вышли «в ноль», но удалось удержать превышение в рамках 5-10%, что вполне приемлемо и компенсируется на этапе внедрения за счет меньшего количества пожеланий. В действительности оказалось, что ничего не мешает применять итерационный подход и на типовых проектах. Сокращение трудоемкости при этом достигает 40% при одновременном повышении качества продукта.
Выученные уроки
К сожалению, многие важные и тонкие моменты, о которых хотелось бы рассказать, оказались за рамками данной статьи. Поэтому в качестве резюме хотелось бы зафиксировать уроки и мысли, которые мы получили, применяя итерационные методы на проектах. Возможно они дадут дополнительную пищу для дальнейших размышлений.
● Плодотворная работа в итерационном режиме возможна при наличии партнерских отношений и доверия между заказчиком и исполнителем, возникших только после успешной реализации предыдущих проектов.
● Отказываясь от проектных решений, остаются размытыми рамки проекта. Бывает сложно определить, входит ли новое замечание заказчика в первоначальные договоренности или нет.
● Квалификация руководителя проекта должна быть достаточно высокой, чтобы не потеряться в логике итераций и обеспечить контроль над ходом работ как своей команды, так и специалистов заказчика.
● Вовлечение специалистов заказчика к работам с первых итераций, значительно снижает риски их сопротивления системе в процессе опытной эксплуатации.
● Итерационное проектирование дает хорошую возможность начать опытную эксплуатацию функционала, реализованного на первых итерациях, не дожидаясь завершения всего проектирования.
● Заранее обсуждать с заказчиком судьбу пожеланий, которые не будут реализованы в проекте, несмотря на то, что они зафиксированы в бэклоге.
Большая Энциклопедия Нефти и Газа
Итерационный характер
При нисходящем проектировании в предшествующих процедурах приходится задаваться ориентировочными значениями данных, истинные значения которых становятся известными только после выполнения последующих процедур. Это обстоятельство обусловливает итерационный характер процесса проектирования с возвратами от последующих этапов к предыдущим, что, естественно, существенно увеличивает затраты на проектирование. [31]
Необходимо отметить, что в компьютерной оптике перспективным методом исследования является вычислительный эксперимент, в котором ключевую роль играет компьютер. Процесс создания элементов компьютерной оптики носит сложный итерационный характер и на компьютер возлагается также функция обеспечения диалога с проектировщиком, технологом и исследователем. [35]
В САПР проблема целостности данных оказывается более трудной для решения, чем в большинстве других систем, поскольку проектирование является процессом взаимодействия многих проектировщиков, которые не только считывают данные, но и изменяют их, причем в значительной мере работают параллельно. Из этого факта вытекают следствия: во-первых, итерационный характер проектирования обычно приводит к наличию по каждой части проекта нескольких версий, любая из них может быть принята в дальнейшем в качестве основной, поэтому нужно хранить все версии с возможностью возврата к любой из них; во-вторых, нельзя допускать использования неутвержденных данных, поэтому проектировщики должны иметь свое рабочее пространство в памяти и работать в нем автономно, а моменты внесения изменений в общую базу данных должны быть согласованными и не должны порождать для других пользователей неопределенности данных. [36]
На этом этапе в динамике реального функционирования управляющей системы уточняются характеристики процессов управления и выявляются все ранее не учтенные особенности внешних объектов в реальном масштабе времени. Объем работ на данном этапе существенно определяется качеством и полнотой отладки на предыдущих этапах, и процесс носит итерационный характер с возвратом на предыдущие этапы вплоть до повторной автономной отладки откорректированных алгоритмов. [45]
Планируй задачи с умом: разница каскадного и итерационного подходов
Существует два основных подхода к планированию и организации командной работы: итерационный и каскадный. Как понять, какой подойдёт к конкретной ситуации? Действительно ли существует строгое деление?
В мыслительной деятельности у человека возникают три основные проблемы, из-за которых приходится использовать «внешние» (по отношению к своей голове) инструменты:
1. Человек всё время что-то забывает. Поэтому мы записываем информацию. Вытаскиваем её из ненадежного хранилища – памяти, а затем передаём в более надёжное – на бумагу, компьютер.
2. Человек часто ошибается. Прикидывая в уме, мы можем учесть только самые очевидные противоречия. Риск ошибки резко возрастает с увеличением объёма информации. Записывая, мы визуализируем её. А в видимых образах ошибки и нестыковки найти легче.
3. Человек чего-то не знает в нужный момент. Это распространённая проблема коммуникации. Зафиксированная, структурированная, непротиворечивая информация не представляет ценности, если она вовремя не достигла адресата.
Планирование и организация командной работы – это обязательный процесс для предприятия. Перечисленные проблемы характерны и для планирования как вида мыслительной деятельности.
Итак, есть проблемы, значит, нужен инструмент для их решения. Компания, которая подбирает такой инструмент, должна учесть специфику своих проектов. Ключевые вопросы при выборе:
Из-за разнообразия сочетаний этих факторов образовался целый спектр методик и подходов к планированию. На одном конце – каскадный, характерный для авторитарных стилей управления и сложных долгосрочных проектов с участием крупных корпоративных или государственных заказчиков. На другом – итерационный подход, снискавший популярность своей демократичностью в ИТ-сфере, где актуальна быстрая доставка ценности заказчику.
Яркий пример системы, реализуемой по каскаду, – строительство дома. Такой проект планируют сразу с детализацией по используемым машинам, оборудованию, материалам, местам их размещения, скорости расходования.
Порядок работ при строительстве строгий. Невозможно ставить стены, не подготовив фундамент. И бессмысленно заниматься крышей, не имея стен.
Подобные проекты не терпят радикальных изменений. С началом работ остаётся возможность корректировать только сроки задач, количество и перечень выделяемых ресурсов. Состав и порядок самих задач изменить невозможно.
В качестве инструментов применяются диаграммы Ганта, сетевые графики и ПО, которое поддерживает такой способ визуализации.
Пример – внедрение ИТ-проекта. Распространенная практика – выбирать фиксированный период планирования. Основание – по срокам, освоению ресурсов и достижению цели.
Из общего пула проекта набирается несколько задач, которые гарантированно будут выполнены к концу итерации. Большой разницы нет, что именно взять в работу, решение принимается коллективно с учётом пользы для заказчика.
Итерационный подход – это ответ на постоянные изменения. Мы «слушаем» среду (в нашем примере это обстановка у заказчика) и можем менять в проекте буквально всё прямо по ходу выполнения, вплоть до целей. Единственное исключение – ограничения накладываются на изменения внутри самой итерации. Корректировать и что-то переоценивать допустимо только между итерациями.
Популярный инструмент для подобных проектов – это канбан-доски и ПО на их основе: системы отслеживания ошибок (bag tracking system) и системы отслеживания проблем (trouble ticket system, issue tracking system).
Сведём полученные сведения в сравнительную таблицу:
Конечно, такое деление условно. И в действительности мы наблюдаем, что «чистых» каскадов и итераций не бывает: элементы одного подхода встречаются в другом. Это неудивительно, так как объект планирования остается один и тот же – выполняемая задача и её место среди других задач. Разница в методах планирования не создаёт отличия в существенных признаках (метаданных) самих работ.
Так, итерации в каскадной модели встречаются и внутри отдельного этапа, и при переходе с одного этапа на другой. Каждый артефакт, будь то физическое изделие или электронный документ, может быть подвергнут критике и последующей переделке.
В свою очередь, каскадные элементы в итеративном подходе выражаются в порядке работы со взятыми в итерацию задачами. Порядок этот почти всегда одинаковый: сформулировал требования => спроектировал => сделал => проверил => сдал заказчику.
Поэтому мы ожидаемо встречаем и каскады, и итерации, и их сочетания внутри деятельности одного предприятия.
Вспомним пример со строительством здания. Как уже указывалось, это каскад и инструменты с диаграммами Ганта.
Застройщик редко строит единственное здание. Поднимаемся на уровень выше – это кварталы, микрорайоны. Строительство микрорайона – это множество отдельных проектов: на каждый дом, на каждый вид магистральных коммуникаций, на дороги и благоустройство. Они друг с другом связаны, порядок важен, поэтому для планирования подходит каскадная модель с визуализацией порядка выполнения.
Поднимаемся ещё на уровень выше. Здесь видим, что кроме наружных, коммерческих, проектов у компании есть и внутренние, например, по развитию бизнеса, открытию филиала или инженерного центра. Формируется портфель проектов, каждый из которых независим от других. Для управления портфелем подходят канбан-доски.
Вернемся на уровень отдельного здания. Пусть в нашем случае это будет многоквартирный дом. Если представить, что отделка и подготовка каждой квартиры – это независимый проект, тогда весь дом – это портфель проектов, управлять которым удобно с помощью канбан-досок.
С другой стороны, здание – это сложное сооружение, насыщенное большим количеством инженерных систем (отопление, вентиляция, кондиционирование, водоснабжение, канализация, силовое электроснабжение, сети связи, пожарная сигнализация). Системы связаны друг с другом, поэтому планировать работы с ними удобно по каскадной модели.
На сегодня сложность проектов такова, что только одной методологией и только одним инструментом уже не обойтись. Нужна связка решений, желательно реализованных на одной платформе с бесшовной интеграцией. Это позволит планировать и организовывать работы, глядя на проект с разных точек зрения одновременно.