Ответ “да” по всем пунктам Там где идет разработка (а это фазы с 3 по 5), идет и тестирование. Выпуск новых версий оговаривается в регламенте работ, но обычно это конец каждой итерации.

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

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

Схема, как сказал выше Юра Шиляев, в первую очередь заточена на выполнение задачи клиента. То что нам самим удобнее работать по гибким методикам — это наше личное дело, клиенту вообще об этом знать необязательно. И я именно поэтому выделил перед графиком список заинтересованных лиц и того, что их интересует в первую очередь.

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

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

Соответственно, на этапе альфы заказчику смотреть особого нечего, к нему мы обращаемся скорее за консультациями. На этапе беты мы начинаем регулярно показывать продукт, продолжаем консультироваться, совместно с клиентом решаем возникающие нестыковки и если нужно — меняем требования. Но изменения эти обычно не критичные — все уже показано и отработано в интерактивном прототипе. После беты начинается полный agile — клиент начинает реальную работу с продуктом, понимает что работает, а что нет. Причем не абстрактно, “посмотрел-подумал”, а по результатам работы команды поддержки или редакции. Ну и функционал добавляется уже из списка того, что мы задумали на втором этапе не по четкому плану, а на основе приоритетности.

То есть:

Этап 1
Для заказчика: свободное плавание
Для отдела проектирования: свободное плавание
Для отдела разработки: свободное плавание

Этап 2
Для заказчика: водопад
Для отдела проектирования: водопад
Для отдела разработки: свободное плавание

Этап 3
Для заказчика: водопад
Для отдела проектирования: водопад
Для отдела разработки: agile

Этап 4
Для заказчика: agile с ограниченным влиянием
Для отдела проектирования: agile
Для отдела разработки: agile

Этап 5
Для заказчика: agile
Для отдела проектирования: agile
Для отдела разработки: свободное agile

Узнать очень просто. Надо выпустить минимально-полезный релиз видео-хостинга и очень внимательно слушать пользователей. Это наиболее верный способ развития любой системы. Конечно, можно возразить, что пользователи сами не знают чего хотят. Да, так тоже бывает, но процент таких фич относительно невелик (может около 20% если по нашей системе судить). Фидбек (быстрый!) реальных юзеров - это одна из основ аджайл процессов (если не самая важная).

>>Ну и многие попрекают тем, что, мол, “у вас неправильный agile”.

Повторю в третий раз. ИМХО! подача материала в статье мне не нравится и создает превратное впечатление без сопроводительных комментов которые тут появились благодаря нашей дискуссии
А в сетрификации скрам мастеров нет ничего плохого в принципе, скрам вообще процесс более коммерциализованный чем остальные известные аджайл процессы. Люди просто деньги зарабатывают неся знания в массы. Имеют право.

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

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

>>Да у нас не “чистый” agile, если рассмотреть процесс с самого верха.

Не понимаю такого термина. Что значит чистый аджайл?

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

Ничего не имею против вех и каких-то деливери дэйтс. Тут же все просто. Кастомер ставит приоритеты, команда колбасит фичи по этим приоритетам, чего-то к деливери дэйт выпускает. Каждая итерация обычно заканчивается демонстрацией кастомеру. И в начале каждой итерации приоритеты могут поменяться по бэклогу. Фишка в том, что продукт готов к выпуску всегда (в идеале каждый день! - голубая мечта кастомера). И кастомер воле менять функциональность в любое время.

Мне интересно, как у вас сделано управление изменениями и как кастомер участвует в проекте.

Что ты так набросился: agile не agile? Да у нас не “чистый” agile, если рассмотреть процесс с самого верха. Введение таких понятий как альфа, бета и проч. обусловлено не нашим недопониманием agile, а пониманием и знанием российских клиентов. Всегда нужно ставить достижимые цели и к ним бежать. Если вспомнить из самого agile, то это один из этапов двухуровнего планирования.
Мы можем, конечно, сейчас рассуждать о чистом agile… Но иногда наши заказчики должны предоставить инвестору какой-то материал в назначенный срок. И этому инвестору все равно по какой методике там что разрабатывается. У него в календаре отмечено, что ему будут показывать его проект и он ждет, чтобы его смотреть. Поэтому вольно или не вольно, а некоторые вехи мы будем ставить.

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

Духом agile мы как раз-таки прониклись — это, в-общем-то, самое важное что есть в методологии. Но дух — не значит “четкое и дотошное следование всем практикам”. Я объяснил в предыдущем комментарии, почему при работе над многими продуктами не подходит чистый эджайл. На эту тему есть и более авторитетная и долгая дискуссия между Аланом Купером и Кентом Беком, одними из ключевых личностей в проектировании и разработке (оригинальный линк недоступен, но работает из web.archive.org). Это я к тому, что между чистым agile и чистым проектированием есть конфликт интересов и он будет всегда. Тот процесс, что описан в материале, старается этот конфликт сгладить.

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

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

>>Любопытно, а зачем вам аджайл если разницы нет?

Он удобнее и комфортнее Но не во всем.

>>Кстати в аджайл сертификации нет, это не CMM.

Сертификации самого процесса нет, но есть программы сертификации скрам-мастеров, которые нравятся далеко не всем. Ну и многие попрекают тем, что, мол, “у вас неправильный agile”. Ну как гибкая методология может быть правильной, т.е. стандартизированной? Речь может идти только о более или менее эффективном использовании. Что вы и сами понимаете

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

По пунктам пару комментов.

>>Бета в нашем случае — минимальный набор функций, который нужен для того чтобы продукт был целостным.

Целостный продукт понятие очень относительное. Продукт должен быть готов к релизу в конце каждой итерации и заказчик имеет право сказать “Ребята, давайте через 2 недели выпустим продукт на рынок для пробы с тем что есть сейчас”. И команда должна без вопросов уметь это сделать. Бизнес изменчив, и зачастую (практически всегда!) лучше выпустить продукт с минимальной функциональностью, который дорабатывать и улучшать с релизами 1-2 месяца.

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

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

Очень плохо что аналитика и дизайн не являются частью команды (по крайней мере это то, что вы сказали). Или вы просто выразились неточно?

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

+1

>>Ну и в-последних, нам важно выпускать интересный проект качественно и в срок. Будет он сделан по agile-методикам или по жесткому плану — какая разница, если результат всех устраивает?

Любопытно, а зачем вам аджайл если разницы нет?

>>Но великого смысла дотошно следовать правилам agile не вижу — если только сертификация нужна.

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

Вы прочитали мой текст и комментарий? Или для вас водопад — красная тряпка, которую нужно в любом проявлении найти и уничтожить? Разработка начинается на третьем этапе и с этого момента не прекращается. Т.е. да, по сути 3-4-5 — одна стадия. Причем на третьем этапе это скорее подготовительные работы — до тех пор пока нет детально проработанной концепции, делать “очередной видео-хостинг” бессмысленно. Разбивка этих этапов сделана исходя из удобства построения договорных отношений с клиентом и успевания в ключевые вехи.

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

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

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

Ну и в-последних, нам важно выпускать интересный проект качественно и в срок. Будет он сделан по agile-методикам или по жесткому плану — какая разница, если результат всех устраивает? Сейчас нам удобнее работать по гибким методикам. Но великого смысла дотошно следовать правилам agile не вижу — если только сертификация нужна.

У вас есть свой опыт, судя по вашему продукту Target Process (мне он понравился плюс мои коллеги его сейчас используют) — очень хороший. Но вы его зачем-то переносите на остальные команды и проекты. А жизнь — она богаче

Кстати говоря, ответ вот на такой вопрос во многом прояснит картину. У вас в стадии сейлс есть вот что.

>>Отдел разработки
>>Предварительная оценка сроков, трудозатрат и рисков проекта.

Как это делается? Вообще как заказчик заключает договор? Как вы оцениваете трудозатраты?