- PVSM.RU - https://www.pvsm.ru -
Прошлой осенью, вернувшись из отпуска, я обнаружил, что Дехана, наш Product Manager в UserVoice [1], заменила мой любимый «Roadmap» в Google Docs на доску Trello [2].
Моя первоначальная реакция на такие перемены была отнюдь не положительной. Проблема заключалась не в самом Trello, а в том, как мы им пользовались. Trello – это ОЧЕНЬ открытый проект. Не существует единственного “правильного” способа работы в Trello, поэтому, чтобы чувствовать себя в нем как дома, вам потребуется время для настройки «под себя».
Итак, после долгих экспериментов, нам, кажется, удалось получить полностью устраивающую нас систему работы, и мы решили, что стоит поделиться ею со всеми. Этот пост будет длиннее, чем обычно, и если вы далеки от темы веб-разработки, он может показаться вам немного скучным. Если вы решите сразу перейти к части поста, посвящённой полученным урокам, я, несомненно, расстроюсь, но обижаться не стану.
Наш процесс разработки объединяет в себе 6 различных досок Trello. Центральным звеном является доска Current Development («Текущая разработка»). Основной целью других досок является снабжение карточками, которые представляют собой улучшения или баги (см. ниже), доски Current Development, а конкретно ее колонки Next Up («Следующее»). Список Next Up — это наш единственный список, задачи в котором рассортированы по приоритету. Разработчики и проектировщики заглядывают в него, когда они готовы приступить к работе над новой карточкой.
Однако прежде чем мы детально рассмотрим функции всех наших досок, давайте поговорим о «кровяных тельцах» в нашей «кровеносной системе» разработки: о карточках Trello.
Каждая карточка представляет собой одну из пользовательских историй. Это может быть улучшение, задача для переработки либо баг.
Карточки с улучшениями возникают как простая идея, длиной в 1-2 предложения. Однако перед тем как их можно будет отправить в разработку, они увеличиваются в объеме и теперь включают ссылку на Google Doc с детально расписанной спецификацией, набором схем интерфейса (wireframe) или грубых макетов.
Мы используем понятие «спецификация» (spec) в достаточно широком смысле. Это не те спецификации, которые приходят вам на ум, когда вы вспоминаете работу над курсовой в универе или работу в той дрянной консалтинговой компании сразу после его окончания. В нашем случае спецификации подробно раскрывают пользовательскую историю: почему (с точки зрения бизнеса) мы за неё берёмся, чего мы надеемся добиться, и, по возможности, включают некоторые заметки на тему её предполагаемой реализации (хотя этот пункт остаётся на усмотрение разработчиков; он может помочь, но не является обязательным). Хорошие спецификации также содержат ссылку на первоисточник и на связанную идею на нашем форуме UserVoice.
Если карточка описывает баг, то в ней содержатся шаги, помогающие его воспроизвести (хорошо, если добавлен ещё и скринкаст), и ссылка на тикет в UserVoice Helpdesk [3], где данный баг был изначально описан.
Ссылка на одну из наших реальных спецификаций [4]
Доска Current Development – это доска, на которой «творится история». На ней расположены следующие колонки:
Кроме всего прочего мы используем три ярлыка, которые можно прикрепить к карточкам:
Довольно просто, правда? Такой подход к разработке очень похож на систему Канбан. Теперь давайте разберемся, как карточки попадают на эту доску.
Новые карточки могут появляться из 4-ёх различных досок:
На этой доске 3 списка:
Доска «Планирование» – это доска, на которой я вместе с нашими PM’ом и руководителем по UX проводим большую часть времени. Она включает следующие колонки:
На любой другой доске, кроме Planning, карточки всегда перемещаются исключительно справа налево. Но на этой доске карточки нередко переходят из Design или Ready назад в колонку Spec (иногда неоднократно), прежде чем они, наконец, попадут на доску Current Development.
У нас всего несколько еженедельных совещаний:
Утро понедельника – совещание по продукту (30 минут)
Утро пятницы – совещание по обзору входящих идей (30 минут)
Пятница после полудня – совещание по планированию (1 час)
Каждое утро – Стендап (10 минут)
Вот и все наши «официальные» регулярные совещания, однако стоит упомянуть, что нередко мы вместе с Руководителем по UX и PM’ом проводим импровизированные трёхчасовые совещания, на которых подробно обсуждаем вопросы проектирования и дизайна, разбирая несколько карточек с доски «Planning».
Эти импровизированные обсуждения вопросов дизайна обычно проводятся ближе к концу недели (четверг/пятница), когда становится ясно, что существуют разные мнения касательно карточек, над которыми мы работали всю неделю. Для меня это одни из наиболее продуктивных и интересных совещаний из тех, что мы проводим. Внешне они могут показаться малопродуктивными, так как часто после обсуждения мы возвращаемся к тому, с чего начали. Но на самом деле это признак того, что мы действительно хорошо осознаём все плюсы и минусы выбранного нами пути: мы принимаем решение осознанно, а не вслепую и второпях.
Всегда @обращайтесь к кому-нибудь в комментариях к карточке, если вы действительно хотите получить ответ
Если вы пишете комментарий к карточке, не обращаясь ни к кому конкретно, это значит, что вы написали его как примечание для самого себя на будущее. Если вы хотите, чтобы на ваш комментарий кто-то обратил внимание, укажите, кто это должен быть с помощью символа @ в Trello.
Единый список задач по приоритетам для рабочей группы
Первоначально у нас были колонки карточек, расположенных по приоритету, для каждой отдельной области применения продукта (admin-консоль, виджеты [8], iOS [9], веб-портал, электронная почта). Это могло бы сработать, если бы у нас были отдельные рабочие группы для каждой подсистемы, но их у нас нет. Привело это лишь к путанице по поводу того, какая же задача действительно должна быть следующей. Также было крайне неудобно определять и следить за тем, над чем именно команда работает в данный момент. (Совет: если вы замечаете, что часто используете горизонтальный скроллбар Trello, значит, вы что-то делаете неправильно).
Не используйте отдельную систему для багов
Первоначально мы оставили в работе наш предыдущий баг-трекер, а Trello стали использовать для разработки новых функций. Это вызвало проблемы по тем же причинам, по которым не сработало большое количество колонок: как только мы начинали использовать больше одого списка, любое распределение по приоритетам переставало работать.
Ограничьте количество времени на решение проблем с багами
Мы добились этого, установив лимит на количество багов, которые еженедельно можно добавлять в колонку Next Up. Вначале такое решение приняли немного неоднозначно, однако в дальнейшем оно помогло предотвратить кучу споров на тему, стоит ли рассматривать тот или иной баг. Теперь команда по работе с клиентами наделена правом (а может, обременена) выбора стоящих карточек. Это своеобразная версия «Голодных игр» в сфере разработки.
Добавляйте и сортируйте карточки в колонке Next Up только 1 раз в неделю
Это поможет не превратить список Next Up в постоянно растущую песчаную дюну. После того как в понедельник утром представлены новые проекты, вы точно знаете, на каком месте в очереди они будут находиться всю оставшуюся неделю. Вам не нужно беспокоиться о том, что проект, которым вы хотели заняться, окажется в конце очереди (и вы не сможете осуществить задуманное) посередине недели.
Хорошие спецификации скорее рассказывают историю, чем являются пошаговым рецептом
Чтобы все работали над проектом с полной отдачей, они должны чётко понимать, зачем это делают. Поэтому так важно разъяснить проблемы пользователей (или бизнеса) разработчику, которому предстоит их решать.
Не пытайтесь делать предварительную оценку сроков проекта
Раньше, когда мы работали спринтами, мы тратили ОЧЕНЬ много времени (почти целый день на 2-хнедельный спринт) на предварительную оценку и планирование в тщетных попытках провести черту и сказать: «Мы разберёмся вот с этими карточками в течение двух ближайших недель». Мы проделывали большую работу и все равно почти всегда ошибались, поэтому мы перестали бороться с неопределённостью.
Старайтесь отмечать свои успехи
Важно понимать, что несделанная работа есть всегда. Каждую неделю мы создаем отдельную колонку для карточек, которые запускаются в эксплуатацию, чтобы было понятно, чего мы достигли на этой неделе. Также мы используем фотографии всех, кто успешно завершил выполнение задачи, на наших совещаниях по понедельникам.
Я надеюсь, эта статья была вам полезна. Выражаю заслуженную благодарность: Dejana Bajic (PM), Joshua Rudd (Руководитель по UX) и Jonathan Novak (Ведущий разработчик), — за создание этого надежного процесса.
Полезные ссылки от переводчика:
«Руководство по продуктивной работе в Trello. Полезные расширения и настройки» [10]»
«How do you use Trello for agile development? [11]» — Quora-тред
«Five Tips for Using Trello for Scrum [12]»
Автор: YuraYu
Источник [13]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/28567
Ссылки в тексте:
[1] UserVoice: http://www.uservoice.com/
[2] Trello: http://trello.com/
[3] UserVoice Helpdesk: http://www.uservoice.com/helpdesk/
[4] Ссылка на одну из наших реальных спецификаций: https://docs.google.com/a/uservoice.com/document/d/1lojmnN9fZiGUt4eC5rOQqFEV86C33QqAiE3haIeuKH4/edit
[5] форум обратной связи с пользователями UserVoice: http://www.uservoice.com/feedback
[6] Our critical issue escalation process: http://community.uservoice.com/blog/off-hours-critical-issue-escalation-process/
[7] как, с нашей точки зрения, должна работать обратная связь с пользователями: http://www.uservoice.com/blog/entries/why-customer-feedback-is-important/
[8] виджеты: http://www.uservoice.com/widget/
[9] iOS: http://www.uservoice.com/iphone/
[10] Руководство по продуктивной работе в Trello. Полезные расширения и настройки»: http://betteri.ru/post/rukovodstvo-po-produktivnoy-rabote-v-trello-poleznye-rasshireniya-i-nastroyki.html
[11] How do you use Trello for agile development?: http://www.quora.com/Trello/How-do-you-use-Trello-for-agile-development
[12] Five Tips for Using Trello for Scrum: http://www.civicactions.com/blog/2012/oct/10/five_tips_for_using_trello_for_scrum
[13] Источник: http://habrahabr.ru/post/171503/
Нажмите здесь для печати.