У моего блога две ключевые темы — проектирование и управление проектами. Первая — потому что моя основная работа состоит как раз в продумывании и документировании пользовательских интерфейсов. Вторая — поскольку я руковожу и развиваю отдел проектирования в нашей компании. Ну и в довесок управляю первым этапом тех проектов, где требуется проработка UI. Наверное, поэтому в блоге мало “чистых” материалов по проект-менеджменту — обе темы переплетаются в работе так, что не развязать. И одна из самых актуальных для меня сейчас вещей в рамках этого переплетения — шлифовка процесса работы отдела так, чтобы он гладко стыковался с разработкой.
Про выстраивание процесса проектирования с учетом интересов команды разработки я недавно писал. В третьей части материала как раз говорится о том, как мы пытаемся решать проблему сроков. Эту же темы мы с коллегами поднимали в апрельском выступлении на конференции РИТ-2008.
Если вкратце, то вся работа разбивается на три части — концепция, интерактивный прототип и поддержка спецификации. Для каждой из них в идеале заключается свой договор, идущий по разным методикам. Концепцию удобнее прорабатывать по классической схеме с четким календарным планом. Интерактивный прототип бывает проще создавать в agile-процессе. Правда, такой подход годится не для всех проектов — в основном там, где важнее функциональные, а не потребительские качества продукта. Поддержку спецификации удобнее вести по чистому agile, но иногда удобнее иметь готовый пакет документации сразу, сделав все одним махом без всяких итераций.
Хочется расписать эту схему подробнее. Для начала важно понять, что вообще важно во всем этом деле заинтересованным лицам проекта — заказчику, разработчикам, проектировщикам:
- Клиента интересует скорость выхода продукта на рынок. Важно узнать, когда и какие ключевые даты запланированы у него — официальный запуск самого продукта, отчетные точки для инвесторов, рекламные кампании и т.п. Это позволит гибче и лучше спланировать работы по проекту.
- Крупные проекты обычно ведутся в условиях постоянного изменения требований. А значит разработчикам нужен такой процесс работы над проектом, который не заставит их отвечать за ошибочное планирование, съедающее нервы и внеурочные часы. Планы бывают чересчур оптимистичны не от недостатка квалификации — часто бывают нужны серьезные предварительные технологические исследования и испытания для того чтобы оценить трудоемкость функциональности. Которые здорово затягивают старт работ и, соответственно, выход на рынок.
- Всех троих волнует качественная и глубокая проработка потребительских качеств продукта — в основном это касается интерфейса. Клиенту нужен успешный продукт; проектировщикам — интересный проект, за который потом не будет стыдно; разработчикам — стройная и целостная система, которая не расползется по швам с последующей тонной доделок.
- Для обеспечения таких качеств важна полная и в то же время легко читаемая и поддерживаемая спецификация требований к продукту, своевременно обновляемая. Разработчикам она даст основу для планирования и уверенность в том, что они работают над тем, что нужно; проектировщикам — возможность проследить за качеством системы.
- Проектную команду, не связанную непосредственно с разработкой, интересует равномерная загрузка. В первую очередь это касается проектировщиков. В идеале, конечно, они должны быть доступны по первому зову. Но если речь идет не о полностью посвятившей себя проекту компании, а о коммерческой организации, которая предоставляет услуги по проектированию, нужно планировать работу так чтобы и успевать все без авралов, и без дела не сидеть.
Определяющий здесь — первый пункт. Исходя из задач клиента мы определяем ключевые вехи, которые говорят что к “такому-то числу должно быть готовы такие-то вещи”. Под них строится и весь процесс работы. Он может отличаться в каждом конкретном случае, но в целом придерживается следующей схемы. Которая при этом удовлетворяет и остальным пунктам списка:
Этап 1. Pre-Sale
1-2 недели (хотя случается и полгода, и год)
Отдел проектирования
Предварительный анализ проекта, описание объема работ, оценка сроков и стоимости работ.
Документы
- коммерческое предложение;
- договор на проработку концепции.
Отдел разработки
Предварительная оценка сроков, трудозатрат и рисков проекта.
Документы
- нет формализованных документов.
Этап 2. Сбор требований и проработка концепции
2-4 недели
Отдел проектирования
Бизнес-анализ и сбор требований. Планирование работ по детальному проектированию.
Документы
- видение проекта;
- описание целевой аудитории;
- краткие сценарии взаимодействия;
- перечень функциональности;
- карта сайта;
- черновые структурные схемы страниц;
- договор на детальное проектирование бета-релиза;
- перечень функциональности бета-релиза;
- перечень функциональности финального релиза;
- устав проекта.
Отдел разработки
Выбор технологической платформы, планирование работ, сбор команды.
Документы
- план работ по разработке;
- оценка рисков;
- эксплуатационные требования;
- договор на разработку альфа-релиза.
Этап 3. Интерактивный и функциональный прототип (альфа-релиз)
1-2 месяца
Отдел проектирования
Детальное проектирование и дизайн интерфейса, создание интерактивного прототипа, сбор требований. Описывается функциональность, которая должна войти в бета-релиз.
Документы
- структурные схемы страниц;
- дизайн-макеты страниц;
- интерактивный прототип;
- атрибуты и методы сущностей;
- критерии приемки функциональности;
- договор на детальное проектирование финального релиза.
Отдел разработки
Разработка альфа-релиза продукта (ядро + модули без дизайна) по договору с фиксированной ценой и сроками.
Документы
- функциональный лист (backlog);
- отчетность о ходе проекта;
- доработка существующих документов;
- договор на agile-разработку.
Этап 4. Бета-релиз
1,5-3 месяца
Отдел проектирования
Детальное проектирование и дизайн интерфейса, доработка интерактивного прототипа. Описывается функциональность, которая должна войти в финальный релиз. Также ведутся доработки документации по запросу команды разработки.
Документы
- структурные схемы страниц;
- дизайн-макеты страниц;
- интерактивный прототип;
- руководство по стилю интерфейса.
Отдел разработки
Разработка и отладка бета-релиза продукта по agile-договору.
Документы
- план тестирования;
- отчетность о ходе проекта;
- доработка существующих документов.
Этап 5. Финальный релиз
2-6 месяцев
Отдел проектирования
Доработки документации по запросу команды разработки.
Документы
- доработка существующих документов.
Отдел разработки
Разработка и отладка финального релиза продукта по agile-договору.
Документы
- сопроводительная документация к проекту;
- доработка существующих документов.
План может варьироваться в зависимости от того что это за проект, есть ли наработки в этой предметной области у нас или клиента, более важны здесь функциональные или потребительские качества продукта. Важно, что он определяет скорее принцип работы, чем конкретную последовательность действий. И этот принцип позволяет найти компромисс между скоростью выхода на рынок и качеством проработки продукта.
Есть здесь один спорный вопрос по поводу того, нужно ли продолжать активное проектирование после сдачи интерактивного прототипа. Точнее, проблема даже глубже — нужно ли вести проектирование по agile, если разработка идет по гибким методикам? Я уверен, что как минимум ключевую функциональность нужно детально спроектировать до начала ее окончательного внедрения. После чего вести ее поддержку и обновление. Важно ведь не только красиво расставить кнопки в форме, но и понять, нужна ли вообще вот эта конкретная форма — в этом модуле или проекте в целом. Но это отдельная тема. Которую, наверное, я также скоро распишу.
P.S. Общий вид диаграммы Ганта на основе описанного выше графика. Так он смотрится куда нагляднее.
P.P.S. Отмечу соавторство Юры Шиляева — он руководит минским офисом разработки нашей компании и именно с ним мы доводим эту схему до ума в ходе работы над проектами.
18 comments
А чего таблицу убрал? 🙂
Таблица в мой темплейт дизайна плохо встраивается — правая часть обрезается. Я ее сохранил для потомков 🙂 В смысле, когда все-таки доделаю нормальный темплейт, верну таблицу.
Agile development и диаграмма Ганта несовместимые вещи. Если есть итеративная разработка, диаграма не нужна. Совсем.
>>Интерактивный прототип бывает проще создавать в agile-процессе. Правда, такой подход годится не для всех проектов — в основном там, где важнее функциональные, а не потребительские качества продукта.
В корне не согласен. Почему вы считаете что аджайл не совместим с потребительскими качествами? Мне это сранно слышать. Потребительские качества это что? Качество? Дизайн классный? Как это может быть не совместимо с гибкой разработкой? Поясните плиз.
Честно говоря я не совсем понял, где в вашем процессе итерации. Вижу фазы, вижу много документов (они правда все нужны заказчику? он правда хочет чтобы вы на них тратили свое время = его деньги?).
Несколько вопросов.
Тестирование включено во все фазы? (ну, уберем пресейлс пожалуй)
В конце каждой итерации у вас выпускается версия продукта?
Клиент может вносить изменения в проект по ходу без особой мороки?
Если ответы нет, то на мой взгляд у вас практически чистый вотерфол.
Миша,
Сразу отмечу, про то что статья описывает процесс, стоящий немного выше agile. В рамках каждого этапа (кроме 1 и 2 — здесь никакой разработки не ведется) идет гибкая разработка с 2-недельными итерациями, в конце каждой из которых выкатывается новый релиз продукта. Есть там и тестирование, и возможность клиента вносить изменения, и скрам-митинги, и ретроспективы и прочие полезности.
Этапы здесь обозначают ключевые вехи работы над проектом (например, запуск беты 15 сентября, релиз модуля “Конкурсы” к новогодним праздникам). Вы ведь не будете отрицать, что они есть и в каскадной, и в гибкой разработке? 🙂 И для ключевых вех диаграмма Ганта — вполне себе отличный инструмент показать общую картинку. Хотя для постановки конкретных задач она, естественно, годится плохо.
По поводу потребительских качеств — это ведь не только красивый и аккуратно прикрученный дизайн. Речь идет о создании успешных продуктов на высококонкурентном рынке. Вот, например, запускаете вы очередной видео-хостинг. В случае чистого agile мы определяем функционал, разрабатываем и выкатываем его. По ходу работ отдел проектирования поставляет дизайн и интерфейс. В итоге все получилось аккуратненько и чистенько, работает без ошибок, уложились в бюджет и сроки. Но вот вопрос — кому нужен очередной видео-хостинг?
Разбивая проект на описанные в материале этапы, мы как раз стараемся решить эту проблему. В большинстве крупных проектов, над которыми мы сейчас работаем, мы не просто разрабатываем и проектируем некий сервис, но еще и берем на себя часть продукт-менеджмента, в зависимости от ситуации большую или меньшую. Поэтому на первых двух этапах речи о разработке вообще не идет — мы определяем, что это за продукт, для кого и зачем, как он привлечет людей.
Поэтому вопрос тут в том, в какой момент отдел проектирования может начать работать в режиме поддержки команды разработки, а не предварительного определения сути проекта. Мы по этому поводу часто и долго спорим отделами, нужно ли на четвертом этапе сделать интерфейс “впрок” или проектировать его по мере внедрения. Но то что первые три этапа проектирования должны быть вне agile — в этом я уверен.
Конечно, если вы делаете интранет-систему или закрытое веб-приложение для проведения тендеров — тут можно и нужно проектировать по agile. Т.е. лояльность пользователей и их привязка к продукту у вас заранее обеспечены и более важна скорость запуска продукта. Ничего страшного, если через месяц придется частично переделать интерфейс — главное, что люди смогли скоро после начала работ выполнять в системе свои задачи. Если же пользователям “есть куда уйти” — будет очень трудно добиться чего-то серьезного, проектируя в чистом agile.
Резюме из всего вышесказанного одно – у вас вотерфол. Аджайл не применим только к фазе 1, все остальное ОТЛИЧНО можно делать итерациями.
Кстати, в большинстве аджайл процессов нет такого понятия как альфа релиз или бета релиз. Есть просто релиз с польностью готовой, оттестированнной функциональностью, который демонстрируется кастомеру. Эти стадии (3-4-5) не имеют смысла отдельно, это все одна стадия.
Кстати говоря, ответ вот на такой вопрос во многом прояснит картину. У вас в стадии сейлс есть вот что.
>>Отдел разработки
>>Предварительная оценка сроков, трудозатрат и рисков проекта.
Как это делается? Вообще как заказчик заключает договор? Как вы оцениваете трудозатраты?
Миша,
Вы прочитали мой текст и комментарий? Или для вас водопад — красная тряпка, которую нужно в любом проявлении найти и уничтожить? 🙂 Разработка начинается на третьем этапе и с этого момента не прекращается. Т.е. да, по сути 3-4-5 — одна стадия. Причем на третьем этапе это скорее подготовительные работы — до тех пор пока нет детально проработанной концепции, делать “очередной видео-хостинг” бессмысленно. Разбивка этих этапов сделана исходя из удобства построения договорных отношений с клиентом и успевания в ключевые вехи.
Бета-версия не обязательно значит “кривая” и “корявая”. Версии отличаются набором функционала и степенью отполированности в мелочах. Бета в нашем случае — минимальный набор функций, который нужен для того чтобы продукт был целостным.
По поводу внутренней структуры. Для крупных проектов создаются выделенные команды, в которую входят разработчики, тестировщики и менеджер. Проектирование, аналитика и дизайн делается обособленным отделом. Соответственно, заключается сразу несколько договоров. Я среди документов указал в статье, какие и где именно. Прочитайте, пожалуйста, не по диагонали 🙂
По поводу этапа продаж. Здесь разработчиками даются грубые оценки — плюс минус пара лаптей. В дальнейшем все это уточняется, но клиенту и нам самим важно знать порядок сроков и сумм. Плюс если нужно — заранее проработать потенциальные issues. Договор на этот этап не заключается — он для заказчика бесплатный. По остальным договорам — опять же, отошлю к самой статье.
Ну и в-последних, нам важно выпускать интересный проект качественно и в срок. Будет он сделан по agile-методикам или по жесткому плану — какая разница, если результат всех устраивает? Сейчас нам удобнее работать по гибким методикам. Но великого смысла дотошно следовать правилам agile не вижу — если только сертификация нужна.
У вас есть свой опыт, судя по вашему продукту Target Process (мне он понравился плюс мои коллеги его сейчас используют) — очень хороший. Но вы его зачем-то переносите на остальные команды и проекты. А жизнь — она богаче 🙂
Окей, я к чему клоню. Если называть пост с употреблением слова agile, то тему надо раскрывать лучше. Из того что написано в статье совершенно не вытекает что у вас НЕ вотерфол. Если бы в тексте не было так много отсылок и упоминаний аджайл, я бы ничего против не имел. А так эти фазы непонятно зачем. И кстати можно подумать что с окончанием третьей фазы разработка заканчивается.
Лично мне кажется что вы духом аджайл пока не прониклись, отсюда подобная трактовка. Как бы это сказать, у вас процесс изложен в духе вотерфол. У читателей может возникнуть (и возникает) неверное понимание ваших процессов.
По пунктам пару комментов.
>>Бета в нашем случае — минимальный набор функций, который нужен для того чтобы продукт был целостным.
Целостный продукт понятие очень относительное. Продукт должен быть готов к релизу в конце каждой итерации и заказчик имеет право сказать “Ребята, давайте через 2 недели выпустим продукт на рынок для пробы с тем что есть сейчас”. И команда должна без вопросов уметь это сделать. Бизнес изменчив, и зачастую (практически всегда!) лучше выпустить продукт с минимальной функциональностью, который дорабатывать и улучшать с релизами 1-2 месяца.
Основная цель гибких процессов выпустить продукт как можно раньше, чтобы люди начали его юзать и давать реальный фидбек.
>>По поводу внутренней структуры. Для крупных проектов создаются выделенные команды, в которую входят разработчики, тестировщики и менеджер. Проектирование, аналитика и дизайн делается обособленным отделом.
Очень плохо что аналитика и дизайн не являются частью команды (по крайней мере это то, что вы сказали). Или вы просто выразились неточно?
>>По поводу этапа продаж. Здесь разработчиками даются грубые оценки — плюс минус пара лаптей. В дальнейшем все это уточняется, но клиенту и нам самим важно знать порядок сроков и сумм
+1
>>Ну и в-последних, нам важно выпускать интересный проект качественно и в срок. Будет он сделан по agile-методикам или по жесткому плану — какая разница, если результат всех устраивает?
Любопытно, а зачем вам аджайл если разницы нет? 😉
>>Но великого смысла дотошно следовать правилам agile не вижу — если только сертификация нужна.
Кстати в аджайл сертификации нет, это не CMM. Дотошно следовать правилам не надо, надо затачивать процесс под конкретные условия работы, что вы и сделали. Если все довольны – значит все классно 🙂
Миша,
Мне кажется, agile — не патентованный трейдмарк и каждый волен использовать и подстраивать его так, как ему удобнее. Главное не терять сути методологии, а у нас она живет и здравствует 🙂 Повторюсь — материал описывает более крупный процесс, чем гибкая разработка. Поэтому конкретно про определение agile и других терминов здесь ничего нет — для этого есть отдельные статьи. Ну или читатели сами найдут, где почитать про это.
Духом agile мы как раз-таки прониклись — это, в-общем-то, самое важное что есть в методологии. Но дух — не значит “четкое и дотошное следование всем практикам”. Я объяснил в предыдущем комментарии, почему при работе над многими продуктами не подходит чистый эджайл. На эту тему есть и более авторитетная и долгая дискуссия между Аланом Купером и Кентом Беком, одними из ключевых личностей в проектировании и разработке (оригинальный линк недоступен, но работает из web.archive.org). Это я к тому, что между чистым agile и чистым проектированием есть конфликт интересов и он будет всегда. Тот процесс, что описан в материале, старается этот конфликт сгладить.
Насчет целостности продукта — повторюсь, кому нужен очередной видео-хостинг? Пускай даже работающий лучше всех остальных. Вот видео-хостинг, привязанный к некому реально существующему комьюнити и облегчающий ему жизнь — уже теплее. Как вы узнаете, что важнее для этого конкретного, не абстрактного видео-хостинга — возможность видео-ответов и просмотра детальной статистики или функция записи флеш-презентации на CD с несколькими роликами сайта? Стабильно работающая система — еще не значит продукт.
То что аналитика и разработка — разные команды — это действительно несет много проблем, с которыми с переменным успехом боремся. Но и плюсов для компании в целом это несет огромное множество. Тут уж как есть, так есть.
>>Любопытно, а зачем вам аджайл если разницы нет?
Он удобнее и комфортнее 🙂 Но не во всем.
>>Кстати в аджайл сертификации нет, это не CMM.
Сертификации самого процесса нет, но есть программы сертификации скрам-мастеров, которые нравятся далеко не всем. Ну и многие попрекают тем, что, мол, “у вас неправильный agile”. Ну как гибкая методология может быть правильной, т.е. стандартизированной? 🙂 Речь может идти только о более или менее эффективном использовании. Что вы и сами понимаете 🙂
Миша, привет.
“Узнаю брата Колю!” (С) ;)))
Что ты так набросился: agile не agile? Да у нас не “чистый” agile, если рассмотреть процесс с самого верха. Введение таких понятий как альфа, бета и проч. обусловлено не нашим недопониманием agile, а пониманием и знанием российских клиентов. Всегда нужно ставить достижимые цели и к ним бежать. Если вспомнить из самого agile, то это один из этапов двухуровнего планирования.
Мы можем, конечно, сейчас рассуждать о чистом agile… Но иногда наши заказчики должны предоставить инвестору какой-то материал в назначенный срок. И этому инвестору все равно по какой методике там что разрабатывается. У него в календаре отмечено, что ему будут показывать его проект и он ждет, чтобы его смотреть. Поэтому вольно или не вольно, а некоторые вехи мы будем ставить.
>>Насчет целостности продукта — повторюсь, кому нужен очередной видео-хостинг? Пускай даже работающий лучше всех остальных.
Вот видео-хостинг, привязанный к некому реально существующему комьюнити и облегчающий ему жизнь — уже теплее. Как вы узнаете, что важнее для этого конкретного, не абстрактного видео-хостинга — возможность видео-ответов и просмотра детальной статистики или функция записи флеш-презентации на CD с несколькими роликами сайта? Стабильно работающая система — еще не значит продукт.
Узнать очень просто. Надо выпустить минимально-полезный релиз видео-хостинга и очень внимательно слушать пользователей. Это наиболее верный способ развития любой системы. Конечно, можно возразить, что пользователи сами не знают чего хотят. Да, так тоже бывает, но процент таких фич относительно невелик (может около 20% если по нашей системе судить). Фидбек (быстрый!) реальных юзеров – это одна из основ аджайл процессов (если не самая важная).
>>Ну и многие попрекают тем, что, мол, “у вас неправильный agile”.
Повторю в третий раз. ИМХО! подача материала в статье мне не нравится и создает превратное впечатление без сопроводительных комментов которые тут появились благодаря нашей дискуссии 😉
А в сетрификации скрам мастеров нет ничего плохого в принципе, скрам вообще процесс более коммерциализованный чем остальные известные аджайл процессы. Люди просто деньги зарабатывают неся знания в массы. Имеют право.
>>Ну как гибкая методология может быть правильной, т.е. стандартизированной?
Никак не может, я же в предыдущем комменте по этому поводу высказался. Нет стандартов, есть пару основополагающих принципов и пару десятков бест-практик которые надо настраивать под конкретную команду и конкретный проект.
>>Да у нас не “чистый” agile, если рассмотреть процесс с самого верха.
Не понимаю такого термина. Что значит чистый аджайл?
>>Но иногда наши заказчики должны предоставить инвестору какой-то материал в назначенный срок. И этому инвестору все равно по какой методике там что разрабатывается. У него в календаре отмечено, что ему будут показывать его проект и он ждет, чтобы его смотреть. Поэтому вольно или не вольно, а некоторые вехи мы будем ставить.
Ничего не имею против вех и каких-то деливери дэйтс. Тут же все просто. Кастомер ставит приоритеты, команда колбасит фичи по этим приоритетам, чего-то к деливери дэйт выпускает. Каждая итерация обычно заканчивается демонстрацией кастомеру. И в начале каждой итерации приоритеты могут поменяться по бэклогу. Фишка в том, что продукт готов к выпуску всегда (в идеале каждый день! – голубая мечта кастомера). И кастомер воле менять функциональность в любое время.
Мне интересно, как у вас сделано управление изменениями и как кастомер участвует в проекте.
Michael,
Эко у вас все просто 🙂 А представьте, что этот видео-хостинг запускает крупная телекомпания, которая собирает под это дело мощную редакцию, планирует рекламу и вообще какую-то отдачу от всего этого дела. Тоже запускать по чуть-чуть и пуст деньги утекают, а конкуренты догоняют, пока мы не найдем золотое руно? 🙂
Схема, как сказал выше Юра Шиляев, в первую очередь заточена на выполнение задачи клиента. То что нам самим удобнее работать по гибким методикам — это наше личное дело, клиенту вообще об этом знать необязательно. И я именно поэтому выделил перед графиком список заинтересованных лиц и того, что их интересует в первую очередь.
Если говорить об изменениях, то мы специально строим процесс так, чтобы бета-релиз был таким достаточно целостным пакетом, где серьезные изменения не требуются. Т.е. на первых трех этапах мы достаточно глубоко прорабатываем ключевой функционал, изучаем риски и экспериментируем для того чтобы потом вопросов по нему возникало мало. В проектировании это чистый водопад, в разработке — итерационность, но в качестве product owner выступает скорее отдел проектирования.
Т.е. мы, грубо говоря, разбиваем один большой проект на несколько. Первый из них — альфа — делается в плане вовлечения заказчика в процесс почти в полном водопаде. Бета — уже теплее, а остальное — по полностью гибким методикам, включая и работу отдела проектирования.
Соответственно, на этапе альфы заказчику смотреть особого нечего, к нему мы обращаемся скорее за консультациями. На этапе беты мы начинаем регулярно показывать продукт, продолжаем консультироваться, совместно с клиентом решаем возникающие нестыковки и если нужно — меняем требования. Но изменения эти обычно не критичные — все уже показано и отработано в интерактивном прототипе. После беты начинается полный agile — клиент начинает реальную работу с продуктом, понимает что работает, а что нет. Причем не абстрактно, “посмотрел-подумал”, а по результатам работы команды поддержки или редакции. Ну и функционал добавляется уже из списка того, что мы задумали на втором этапе не по четкому плану, а на основе приоритетности.
То есть:
Этап 1
Для заказчика: свободное плавание
Для отдела проектирования: свободное плавание
Для отдела разработки: свободное плавание
Этап 2
Для заказчика: водопад
Для отдела проектирования: водопад
Для отдела разработки: свободное плавание
Этап 3
Для заказчика: водопад
Для отдела проектирования: водопад
Для отдела разработки: agile
Этап 4
Для заказчика: agile с ограниченным влиянием
Для отдела проектирования: agile
Для отдела разработки: agile
Этап 5
Для заказчика: agile
Для отдела проектирования: agile
Для отдела разработки: свободное agile
Несколько вопросов.
Тестирование включено во все фазы? (ну, уберем пресейлс пожалуй)
В конце каждой итерации у вас выпускается версия продукта?
Клиент может вносить изменения в проект по ходу без особой мороки?
Таир,
Ответ “да” по всем пунктам 🙂 Там где идет разработка (а это фазы с 3 по 5), идет и тестирование. Выпуск новых версий оговаривается в регламенте работ, но обычно это конец каждой итерации.
Ну и с изменениями проблем нет — чисто технические вносятся в план на ближайшие итерации. Те, что касаются интерфейса и дизайна, сперва прорабатываются отделом проектирования. Если нет противоречий с концепцией продукта — после этого идут в разработку. У всех задач (и запланированных заранее, и новых, которые и есть те самые изменения) есть приоритетность и критичность, так что исходя из этих двух параметров становится понятно, делать эти изменения сразу или откладывать на потом.