Взаимодействие отдела проектирования интерфейсов и разработчиков в agile-процессе Юрий Ветров, Юрий Шиляев, Александр Хмелевский

Содержание

Слайд 2

О чем доклад?

Контекст Как и над чем мы работаем внутри компании?
Проблемы Что ставит нам

О чем доклад? Контекст Как и над чем мы работаем внутри компании?
палки в колеса и мешает процессу?
Решения Что позволяет нам выстраивать процесс и избегать проблем?
Выводы Как выстроить процесс еще лучше?

Слайд 3

Как и над чем мы работаем?

Три офиса компании — Москва, Санкт-Петербург и

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

Слайд 4

Проблемы

Частое изменение требований.
Географическая удаленность команд и заказчика.
Полнота и избыточность документации.
Аналитики не всегда

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

Слайд 5

1. Частое изменение требований

Проект разрабатывается долго и за это время может измениться

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

Слайд 6

2. Географическая удаленность

Классическая проблема.
Коммуникация затруднена — сложно оперативно решать вопросы и быстро

2. Географическая удаленность Классическая проблема. Коммуникация затруднена — сложно оперативно решать вопросы
обмениваться информацией.
Заказчик и аккаунт-менеджер — в Москве.
Разработчики и менеджер проекта — в Минске.
Проектировщики — в Санкт-Петербурге.

Слайд 7

3. Полнота документации

Подрядчик и заказчик должны одинаково понимать, какой продукт с какими

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

Слайд 8

4. Неясно, что нужно команде

Проектировщики не всегда знают, над чем сейчас работает

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

Слайд 9

5. Общие инструменты работы

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

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

Слайд 10

6. Принятие решений

Не всегда ясно, кто именно отвечает за тот или иной

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

Слайд 11

7. Демонстрация результатов

Клиент хочет видеть результаты работ как можно чаще.
Клиент хочет видеть

7. Демонстрация результатов Клиент хочет видеть результаты работ как можно чаще. Клиент
наглядные результаты работ — картинки, картинки и еще раз картинки.
Клиенту важно знать, что сейчас делается и сделано ли то, что уже запланировано.

Слайд 12

Решения

Гибкие методики ведения проектов.
Командировки и конференции.
Четко выстроенный процесс проектирования.
Планирование итераций заранее.
Использование общих

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

Слайд 13

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

Переход к итеративному процессу разработки, когда продукт обновляется небольшими порциями раз в
1-2 недели.
Использование agile-практик ведения проектов, которые делают процесс ведения проекта более прозрачным и контролируемым.

1. Частое изменение требований

Слайд 14

1. Частое изменение требований

1. Частое изменение требований

Слайд 15

Не решаема, но и не смертельна.
Заказчик, разработчики и проектировщики находятся в пределах пары

Не решаема, но и не смертельна. Заказчик, разработчики и проектировщики находятся в
часов полета или ночи на поезде.
Сами команды работают вместе и не разделены — проектировщики работают с проектировщиками, разработчики — с другими разработчиками, тестировщиками и менеджером.
Аккаунт-менеджер находится в том же городе, что и клиент.

2. Географическая удаленность

Слайд 16

2. Географическая удаленность

Санкт-Петербург

Минск

Москва

2. Географическая удаленность Санкт-Петербург Минск Москва

Слайд 17

Четко отработан состав документации и процесс работы над ней.
Со временем отказались от

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

3. Полнота документации

Слайд 18

3. Полнота документации

Бизнес-анализ
Видение
Описание целевой аудитории
Сценарии взаимодействия
Перечень функциональности (user stories)
Критерии приемки

Проектирование
Карта сайта
Диаграммы взаимодействия
Структурные

3. Полнота документации Бизнес-анализ Видение Описание целевой аудитории Сценарии взаимодействия Перечень функциональности
схемы страниц (wireframes)

Прототип
Шаблоны страниц
Сборка прототипа и наполнение контентом

Дизайн
Дизайн-макеты ключевых страниц
Типовые элементы интерфейса

Слайд 19

Работы по проектированию и дизайну планируются заранее — как минимум на одну

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

4. Неясно, что нужно команде

Слайд 20

4. Неясно, что нужно команде

Итерация №1
Проектирование модуля №2
Разработка модуля №1

Итерация №2
Проектирование модуля

4. Неясно, что нужно команде Итерация №1 Проектирование модуля №2 Разработка модуля
№3
Разработка модуля №2

Слайд 21

Команда активно использует offline инструменты:
Taskboard — для постановки задач.
Маркерные доски и флип-чарты

Команда активно использует offline инструменты: Taskboard — для постановки задач. Маркерные доски
— для планерок и митингов.
Внедрен единый менеджер задач — онлайновый сервис «Acunote».
Используется система баг-трекинга.
Все документы, файлы и код проходят через систему контроля версий.

5. Общие инструменты работы

Слайд 22

5. Общие инструменты работы

5. Общие инструменты работы

Слайд 23

Четко очерчены сферы ответственности каждого участника проекта — кто, когда и за

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

6. Принятие решений

Слайд 24

6. Принятие решений

Бизнес-требования и цели

Решения

Проблемы

Задачи и процесс

Ограничения

Требования

Оплата работ

Продукт

Видение проекта

Служба поддержки

Менеджер

Аналитики

Клиент

Команда

Проблемы

Уточнения

6. Принятие решений Бизнес-требования и цели Решения Проблемы Задачи и процесс Ограничения

Слайд 25

Прозрачность перед клиентом:
открытый клиенту таск-менеджер и баг-трекер;
демо-сервер, на котором можно увидеть и

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

7. Демонстрация результатов

Слайд 26

7. Демонстрация результатов

1

Прозрачность
Таск-менеджер
Баг-трекер
Демо-сервер

2

Демонстрация результатов
Презентация вех
Интерактивный прототип и дизайн
Регулярная отчетность

7. Демонстрация результатов 1 Прозрачность Таск-менеджер Баг-трекер Демо-сервер 2 Демонстрация результатов Презентация

Слайд 27

Выводы

Продолжаем внедрение гибких методик разработки.
Ищем баланс между чистыми концепциями agile и user-centered

Выводы Продолжаем внедрение гибких методик разработки. Ищем баланс между чистыми концепциями agile
design.
Работаем над скоростью работы отдела проектирования.

Слайд 28

1. Дальнейшее внедрение agile

Процесс внедрения agile небыстрый и непростой — нужно здорово

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

Слайд 29

2. Баланс между agile и UCD

Agile предполагает как можно более ранний старт

2. Баланс между agile и UCD Agile предполагает как можно более ранний
разработки. Но не всегда известна концепция проекта, чтобы можно было начинать работы — нужно сперва проработать ее.
User-Centered Design предполагает как можно большую проработку интерфейса перед началом разработки. Но не всегда есть смысл продумывать все мелочи заранее. Работы разбиваются на два или три этапа, в зависимости от проекта: проработка концепции, проектирование основных процессов и детальное проектирование интерфейса.

Слайд 30

3. Ускорение проектирования

Перенос части работ по проектированию из предварительных работ в поддержку —

3. Ускорение проектирования Перенос части работ по проектированию из предварительных работ в
проектирование функций делается по запросу команды.
Автоматизация части работ — ускорение отрисовки схем страниц, использование CSS-фреймворков для сборки интерактивного прототипа.
Стандартизация документов и процесса проектирования. Скорость работы отдела важна как для команды разработки, так и для быстрой оборачиваемости в самом отделе.
Имя файла: Взаимодействие-отдела-проектирования-интерфейсов-и-разработчиков-в-agile-процессе-Юрий-Ветров,-Юрий-Шиляев,-Александр-Хмелевский.pptx
Количество просмотров: 295
Количество скачиваний: 0