Совместное проектирование в agile командах
Как интегрировать дизайн в agile структуру
Многие команды разработчиков программного обеспечения пытаются эффективно интегрировать дизайн в свои agile процессы. Дизайнеры, которые не работают в тесном контакте с остальной частью своей команды, как правило, создают дополнительную работу для всех (в том числе и для себя) и могут создавать вредные накопления знаний в группе разработчиков продукта.
В Atlassian мы работаем совместно, чтобы включить всю agile команду в процесс проектирования. Обеспечивая участие всех в процессе проектирования, мы получаем несколько точек зрения на проблему и не полагаемся на документацию для обмена идеями. В этой презентации рассказывается, как:
- Вовлекается вся команда в процесс проектирования.
- Интеграция дизайна в agile процесс.
- Получить информацию о клиентах для более быстрого тестирования и идей
Вопросы и ответы
Эти вопросы и ответы варьируются от того, какие инструменты дизайна Atlassian использует, до того, как Atlassian обрабатывает отзывы клиентов.
Вопрос 1: дизайнеры и разработчики всегда разные люди? С HTML5 и современными методами пользовательского интерфейса, трудно ли дизайнерам не иметь базовых навыков кодирования?
Ответ 1: грань между дизайнерами и разработчиками становится размытой. У нас есть дизайнеры из Atlassian, которые имеют инженерный опыт, и другие, которые не могли написать ни строки кода. У нас есть сильные визуальные дизайнеры, информационные архитекторы и фасилитаторы (куратор, методист носитель функций, облегчающих выполнение проекта, - ответственный за планирование и проведение групповой работы, например по определению исходных требований к разрабатываемой системе). У каждого свои сильные стороны, и важно понимать и использовать их в своей команде.
Вопрос 2: Участвуют ли люди, не входящие в группу разработчиков продукта, в семинарах по дизайну, например, в маркетинге?
Ответ 2: Наши семинары включают людей из разных дисциплин, но у каждого есть своя причина. Обычно это бывают представители менеджеров по проекту, инженеринг и дизайн, но мы можем привлечь кого-то из службы поддержки или маркетинга, если они могут добавить другую точку зрения.
Семинары могут проходить в течение нескольких дней, что занимает много времени. Мне нравится делиться повесткой дня заранее, чтобы люди знали, где они могут повысить ценность и где они могут выйти на несколько часов. Тем не менее, вы должны присутствовать в основной группе на протяжении всего времени.
Вопрос 3: Как вы заставили своих людей работать над эскизами, участвовать в рисовании и придумывать идеи? У меня есть ощущение, что ПО и разработчики не хотят заниматься этой работой из-за страха или по другим причинам.
Ответ 3: Уже пугает необходимость делиться идеями с группой, но рисовать на публике может быть еще страшнее! Вот почему мне нравится разбивать большую группу на пары для этого этапа семинара. Это устраняет давление чистого листа бумаги, смотрящего на вас. Это также позволяет людям обмениваться идеями друг с другом и поддерживает импульс.
Я обнаружил, что после участия в одной из этих сессий всем становится комфортно в этом процессе, и им действительно нравится участвовать. Комната всегда наполнена гулом, и происходит много замечательных разговоров.
Также важно, чтобы все знали, что вы не ищете шедевры. Все, что вам нужно, это визуализация их идеи - это может быть набросок интерфейса, диаграмма или просто маркированный список - все, что помогает остальным членам группы достичь общего понимания. Если он запечатлен на бумаге, вы также можете сохранить его для справки после окончания семинара.
Вопрос 4: Как вы получаете новых членов в команде дизайнеров в актуальном состоянии?
Ответ4: У нас есть процесс адаптации для всех новых членов команды разработчиков. Это начинается с введения в дизайн в Atlassian, нашего процесса и того, как мы работаем с остальной командой разработчиков. Мы углубимся в разработанные нами принципы проектирования и покажем примеры их применения на практике. Есть классы учебного лагеря, чтобы узнать больше о наших ресурсах дизайна: использование персон, Atlassian Design Guidelines и Playbook.
Мы также соединяем новых дизайнеров с приятелями в течение первых нескольких недель, чтобы показать им верёвки и облегчить их ответственность.
Еще один способ ускорить работу нового дизайнера - это привести его в мастерскую в течение первой недели. Для них это отличный способ встретиться с командой разработчиков и лично убедиться, как мы работаем вместе. В течение первых нескольких месяцев есть чему поучиться, но семинар - отличное место, чтобы погрузиться и заняться проблемой по частям.
Вопрос 5: Какие методы исследования клиентов вы считаете наиболее полезными? Полевые исследования, наблюдение, юзабилити, другие?
Ответ 5: Я думаю, что все виды исследований клиентов полезны, но разные типы исследований вступают в игру на разных этапах проекта.
Например, в начале проекта вы хотите получить полное представление о проблеме и контексте, в котором работают люди. Для этого очень полезны контекстные запросы - вы посещаете команду по месту работы и говорите о ее процессе, как проблема влияет на них, и как они должны быть более эффективными. Приятно видеть из первых рук, как они пытаются выполнять задачи и с какими разочарованиями они сталкиваются.
Тестирование пользователей и собеседование с клиентами - это отличное решение, когда вы развиваете свои идеи немного дальше. Вы можете получить ценную информацию, наблюдая, как люди проходят через процесс, используя простой прототип, или просто поговорив о предлагаемом решении.
С другой стороны, A / B-тестирование - это отличный способ измерить, насколько эффективно ваше решение.
Вопрос 6: Какие инструменты используют дизайнеры Atlassian?
Ответ 6: Дизайнеры Atlassian используют правильный инструмент для работы. Иногда это старомодная ручка и бумага, а иногда это HTML и CSS.
Для создания высококачественных дизайнов большая часть команды использует Sketch, но мы также используем пакет Adobe. Все элементы пользовательского интерфейса из библиотеки шаблонов Atlassian были созданы как векторные объекты, поэтому собрать базовый макет довольно просто. Для простого прототипирования мы используем InVision или Marvel. Для более сложных взаимодействий мы будем использовать Framer Studio, Origami, Axure или рукописный код.
Мы также проходим тонну пост-заметок и маркеров на доске. :)
Вопрос 7: С какими вызовами вы сталкиваетесь, работая в гибкой структуре?
Ответ 7: научиться отпускать совершенство и вместо этого производить быструю итеративную работу - самый большой вызов. Как дизайнер, вы всегда хотите создавать качественную работу, но вы должны быть в порядке с доставкой чего-то, что на 90%, а затем улучшая это.
Вопрос 8: Вы упомянули несколько способов уменьшить документацию. Какую форму документации вы поддерживаете? Вы исключили всю документацию?
Ответ 8: Мы используем Confluence, чтобы делиться работой и собирать отзывы от более широкой команды. Типичная страница будет содержать некоторый контекст о проблеме, которую мы пытаемся решить, и о значимости, которую предлагает предлагаемое решение. Там будут фотографии эскизов (набросков), макеты высокой точности или ссылки на прототипы, встроенные в страницу, чтобы проиллюстрировать решение. Люди будут добавлять комментарии и вопросы, а дизайнер будет публиковать обновленные проекты по мере продвижения проекта. На самом деле это не «ведение документации», это развивающаяся страница, которая собирает ресурсы дизайна и отзывы.
Вопрос 9: Как вы подходите к распределенному дизайну, когда команда не находится в одном месте?
Ответ 9: Atlassian - это глобальная компания, поэтому с распределенными командами мы сталкиваемся каждый день. В Jira Software у нас есть команды в Сиднее, Гданьске и Сайгоне, и мы всегда ищем способы преодоления разрыва. Технология очень помогает: мы используем Hipchat для видеозвонков и обмена сообщениями, Confluence для публикации, обмена и комментирования работы, а Jira Software - для организации всей работы. Это не идеально, и ничто не может заменить общение лицом к лицу. Когда это возможно, мы стараемся собрать людей в одной комнате для важных частей проекта. В противном случае, хорошим правилом является чрезмерная связь с удаленными товарищами по команде и сделать все возможное, чтобы держать их в курсе.
Вопрос 10: Как вы контролируете и фильтруете «шум», который маскируется как «отзывы клиентов»?
Ответ 10: Мы получаем много отзывов от клиентов, и это здорово! У нас есть инструмент обратной связи, который собирает комментарии пользователей и сохраняет их как задачи в проекте Jira Software. Я провожу первую часть своего дня за чтением последних выпусков с кофе.
Проходя через комментарии, я отмечаю возникающие общие темы или шаблоны и добавляю ярлыки для их группировки. Я могу отфильтровать все отзывы, используя эти ярлыки, чтобы узнать, сколько людей подняло подобную проблему. Затем, после того как шаблон будет создан, я могу передать эту проблему группе разработчиков продукта с конкретными случаями использования, которые мы можем решить.
По материалам Agile Coach "Collaborative design in agile teams"