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

Мы начали использовать Trello для решения небольших текущих задач (обновить описание услуг на сайте, найти южнокорейского переводчика и т.п.) и очень быстро увидели, что можем вести в нем глобальные долгосрочные проекты. Сейчас мы полностью перенесли в Трелло управление процессом создания видеороликов, большими проектами по локализации и даже проектами по разработке собственных продуктов.

О том, как ребятам из Fog Creek Software удалось сделать такой удивительно простой и одновременно функциональный продукт — в посте Боби Грэйса (Bobby Grace) “How We Make Trello”

Переведено в Alconost Translations.

Осмотритесь: рядом есть что-то крепко привинченное к полу? Спасибо, теперь возьмитесь за это покрепче. Я собираюсь раскрыть карты: вы узнаете, как на самом деле создавался Trello. То, что вы узнаете, может вас шокировать, заставить принять успокоительное и пересмотреть взгляд на вещи. В общем, возможны непредсказуемые последствия. Что ж, если вы прочно закрепились в пространстве, — начнём.

Чтобы понять, как делается Trello, немного разберёмся в том, как он работает. Когда вы заходите на trello.com в браузере, фактически вы запускаете клиентское приложение, которое обращается к API Trello. API — это штука, которая уносит ваш запрос в базу данных и возвращается с запрошенными вами досками и карточками. Вы говорите API: «Привет, я Бобби. Если не жалко, дай-ка мне глянуть на мои доски, когда это будет удобно». И через считанные миллисекунды API отвечает строкой: {user: bobbygrace, boards: [‘44321234432’, ‘44321234433’]}. Клиентское приложение берёт эту строку и превращает её в красиво организованную читабельную информацию, которую вы и видите на экране.

Возможно, вы скачивали наши приложения для iOS, Android, Kindle, Windows 8 и думали: «Вот эти хорошо сделанные программы с высокими рейтингами в магазинах приложений, они что — всего лишь клиенты, которые обращаются к API?». Да. Это всего лишь клиенты. Клиенты повсюду. Вообще-то API Trello — открытый, и если вы знаете, как с ним общаться, вы тоже можете сделать свой клиент.

API Trello хорошо написан, не содержит ошибок и вообще весьма надёжен. По крайней мере, изменения в него вносятся не очень часто. Это означает, что мы можем всё время делать новые клиенты, не нуждаясь в обновлении API. То есть, в любой момент времени может работать много различных версий сайта.

«Это всё замечательно и явно как-то увяжется с заявленной темой дальше по ходу статьи, но вы вообще-то обещали рассказать о том, как делался Trello». Ладно, ладно. К этому мы вернёмся позже, а сейчас я опишу наш рабочий процесс.

Использование Trello для Trello

Неудивительно, что мы используем Trello для работы над Trello. У нас есть доска «Служебный Trello», где размещается всё, над чем мы сейчас работаем по API и сайту. Наши списки выглядят примерно так: «В работе», «Ожидает тестирования/проверки», «Готово к слиянию», пачка списков под свежие релизы, «Входящие ошибки».

Допустим, разработчик хочет исправить ошибку. Все происходит следующим образом:

• Он берёт карточку из списка «Входящие ошибки», назначает себя исполнителем и переносит её в список «В работе».
• Стучит по клавиатуре, как бешеная мартышка, пока не исправит ошибку (ну, или это только я так делаю).
• Создаёт новую ветку в своём репозитории (например: bobby/oops-no-crash) и отправляет её в Kiln, первоклассную распределенную систему контроля версий и проверки кода (кстати, Kiln тоже делаем мы). Я не буду слишком глубоко вникать в работу системы контроля версий, но, говоря простым языком, ветка — это новая версия на основе стабильной основной версии на рабочем сервере. Все, кто знают, как работают системы контроля версий, сейчас кривятся и отмахиваются.
• Разработчик добавляет название ветки в описание карточки (например: «исправлено в bobby/oops-no-crash») и переносит её в список «Ожидает тестирования/проверки».
• Одновременно он отправляет изменения на проверку другому разработчику в Kiln (который вам стоило бы приобрести) и уведомляет нашего отважного тестировщика Али Т., который проверяет эту ветку, чтобы убедиться, что ошибка действительно исправлена.
• Когда все возможные проверки успешно завершены, карточка отправляется в список «Готово к слиянию».
• Наш релиз-менеджер Дуг Патти объединяет эти изменения с официальным репозиторием Build, превращает версию с изменениями в новую и стабильную, готовит релиз и выпускает его в мир. Мы часто шутим, что использование Kinect сделало бы этот шаг увлекательнее. Дуг мог бы просто размахивать руками и кричать: «Деплой! Деплой! Деплой!». К нашему стыду, это сейчас не в приоритете.
• Исправления опубликованы. Шампанское, звон бокалов.

Теперь другой разработчик может вытянуть изменения из официального репозитория Build и объединить их со своей рабочей веткой. И тогда его изменения пройдут описанный процесс как по маслу. Так мы вносим изменения много раз в день.

Уверен, всё сказанное до этого момента звучит разумно, но исправление ошибок — это ещё цветочки. Как насчёт больших новых возможностей, которые хотелось бы протестировать первым делом, — что-нибудь вроде нового оборота карточки?

Как мы делаем и тестируем большие нововведения

Помните, что в репозитории Build лежит стабильная утвержденная версия Trello? Вообще-то существует много стабильных утвержденных версий, и вы можете работать с любой из них. То, что вы видите, — не обязательно то же, что видят другие. Извините, если ваша картина мира начала рассыпаться. Но почему мы так поступаем с вами?

Допустим, мы собрались решить большую проблему в Trello. Проводили исследования, аккуратно проектировали и разрабатывали совершенно новую версию Trello, полностью проверенную и протестированную, — прошли весь этот долгий тщательный процесс, который я сжал в одно предложение. Эта версия, вероятно, всё ещё представляет собой сбивающий с толку, раздражающий бардак с уймой ошибок. Почему? Потому что проектирование — это лишь разумное предположение, а не очевидное решение. Мы не знаем точно, как это работает в реальном мире (концепция, основы которой я для вас пошатнул). Вместо того, чтобы отдавать всем недоделанный продукт, эту версию мы отдаем команде, чтобы понять, что нуждается в исправлении. Так что мы отправляем эту версию в канал «Альфа».

«Канал ЧЕГООО?»

У сайта Trello есть три канала: «Стабильный», «Бета» и «Альфа». Когда вы заходите на trello.com, сервер определяет, на каком вы канале и какую версию вам показать. Большинство — на «Стабильном» канале. Ещё около 20 человек имеют доступ к «Бете», а команда Trello и сотрудники Fog Creek — к «Альфе». Если у пользователя есть доступ к нескольким каналам, ему показывается переключатель.

Таким образом, пока мелкие правки идут в канал «Стабильный», большие изменения, — например, новый оборот карточки или новая страница досок, — отправляются в альфа-канал и вместе с реальными данными используются командой. Когда версия попадает в альфа-канал, мы поднимаем забрала. Начинаются горячие споры. Вскипает гнев. Триумф. Радость. Разочарование. Надежда. И — повтор цикла. Много повторов. Как только замечаете в альфа-канале что-то не то — мы облажались, стреляйте.

И кстати: если нужны изменения в API для нового клиента, они размещаются отдельно ещё до того, как новый клиент попадет в альфа-канал.

Версия дорабатывается в альфа-канале до тех пор, пока не будет готова к выкладке в «Бету». У бета-версии есть заметная кнопка «Обратная связь» и примечание о том, что это ранняя тестовая версия Trello, с просьбой «обратить внимание на новые возможности». Потом мы получаем обратную связь, проходим циклы, дорабатываем… Когда мы почти удовлетворены результатом, мы начинаем понемногу выкладывать эту версию для небольшого процента случайных пользователей стабильного канала. Обычно начинаем с 1% и доходим до 15% за несколько дней. Таким образом мы получаем много отзывов. Мы обращаем внимание на серьёзные ошибки, которые часто встречаются, и снова проходим цикл за циклом.

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

Дизайн и исследования

Хотелось бы на минутку задержаться на упомянутом ранее этапе дизайна и исследований. Мы пользуемся доской планирования продукта, где храним карточки о проблемах. Карточки мы называем так: «Не могу найти эту функцию» или «Хочу сделать так-то, но не могу». Есть несколько источников таких проблем:

• информация об ошибках от пользователей, которую мы получаем через FogBuzz — систему обработки ошибок мирового класса (примечание: FogBuzz тоже делаем мы, и да — вам стоит ее купить);
• неудовлетворённость команды разработчиков;
• личные беседы с пользователями Trello, которые проводит наш специалист по клиентскому счастью Бен. Я не знаю, как точно называется его должность.

Мы используем всю эту обратную связь как материал для исследования. Мы проводим множество внутренних опросов и юзабилити-тестов. Ещё мы смотрим на анонимные данные об использовании сайта в Google Analytics, чтобы понять, какими функциями действительно пользуются люди. В конце концов, мы надеемся понять: как люди сейчас используют Trello, как они хотят, чтобы что-то работало, чем они не пользуются и с чем у них возникают самые серьёзные проблемы.

Эта информация и несколько возможных решений учитываются на обороте каждой карточки. Когда мы принимаемся за определенную проблему, я беру её карточку, делаю несколько бумажных эскизов на основе предложенных решений, затем — пару грубых макетов и схем в Sketch (примечание: Sketch делаем не мы, но купить его всё равно стоит). В ходе работы я постоянно публикую схемы и скриншоты на соответствующей карточке в Trello и таким образом получаю постоянную обратную связь от команды. Зная, что интерфейс в результате может кардинально измениться, много времени на детализацию макетов я не трачу. В любом случае, мы можем быстро поменять всё в коде. Вот пример макета нового оборота карточки. Комментарии указывают на важные нововведения. Этот макет подробнее других, потому что описывает важные элементы графического дизайна.

Следующий шаг перед разработкой прототипа — дать проекту кодовое имя. Это очень важно и чаще всего очень весело. Новая страница досок носила кодовое имя «Окраина», потому что относилась ко всему за пределами основной доски. Проект по созданию нового оборота карточки назывался «Пончик с вареньем», потому что внутри (карточки) было даже вкуснее, чем снаружи. Когда мы добавили возможность использовать несколько клиентов, она была названа «Гидра» — в честь мифического многоголового чудовища. Сейчас мы работаем над поиском. Это называется «Катание на сене» и, по-моему, отсылает к поиску иголки в стогу сена. У команды iOS тоже есть кодовые имена проектов. Когда они работали над качеством прокрутки, проект назывался «Хоббит» — в честь масштабного фильма с детализированной, почти живой картинкой высокого разрешения. Кодовые названия важны как опорные точки. Так же мы называем наши ветки: bobby/borderlands выглядит гораздо лучше, чем bobby/new-boards-page-starred-boards-other-stuff-too.

Теперь, когда всё названо и прототипировано, мы запускаем разработку в канал «Альфа» и начинаем цикл. Внедрение. Запуск. Шампанское. Туш.

Наш рабочий процесс прошел долгий путь, во многом благодаря усилиям Дуга и возможности использовать несколько рабочих клиентов одновременно. Может быть, Дуг напишет об этом что-то более техническое. Должен сказать, что рабочие процессы у команд iOS и Android отличаются; они не менее интересны, но здесь не описаны. Иэн говорит, что процесс сборки для iOS — это «cmd+B», но да, вы же понимаете, что это не совсем то, о чём я.

Вот и всё. Надеюсь, получилось достаточно информативно. Можете раскритиковать меня в твиттере.

Автор: alconost

Источник