На российском рынке аутсорс-разработки не так много компаний, которые используют гибкие методологии разработки (Agile). Всем привычна работа по каскадной модели (Waterfall). Это же относится и к сектору мобильной разработки.

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

Мы занимаемся аутсорс-разработкой мобильных приложений, хотя используем у себя Agile-инструмент — Pivotal Tracker (далее в тексте — PT). Именно об опыте его использования я хочу рассказать вам в этой статье.

Что нам было нужно?

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

В конечном счете мы пришли к тому, что у сущности должны быть следующие значения:

• название
• исполнитель
• владелец (постановщик задачи)
• тэг (для категоризации)
• лейбл (для того, чтобы отнести сущность к определенной версии продукта)
• сабтаски

А также к каждой сущности должна быть возможность добавить комментарий (и вести комфортное обсуждение) и разные состояния (не начал, начал, закончил, доставил и т.п.).

Что можно попробовать?

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

Сразу скажу, что месту бумаге в нашем workflow нет, все инструменты только на компьютере. В основном сейчас больше сервисов предоставляется по модели SaaS, но есть и решения, которые можно установить у себя на сервере.

Basecamp

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

Задача может быть в определенном списке, у нее может быть исполнитель, может быть срок. Я знаю людей, которые для того, чтобы отнести таск к определенной версии продукта (Версия 1.0) писали в названии таска необходимую версию (“Голосование за рейтинг [3.4]), а списки использовали для определения статусов задачи (“Запланировано”, “В процессе”, “Завершено”).
Возможно для простых проектов — один менеджер и один разработчик — Basecamp может подойти, но система рушится, когда в проекте 2-3 разработчика, тестер и менеджер проекта.

Redmine

Известная платформа, которую любят многие разработчики. Устанавливается на сервере, легко кастомизируется, имеет в наличие много модулей. Для задач менеджер-разработчик-тестер кажется громоздкой. Интерфейс аскетичен, а при наличии “Apple головного мозга” использование такого инструмента будет огорчать =)

Jira

Монстр от компании, которая съела всех животных в инструментах разработки ПО. Кастомизируется, масштабируется — иногда запутано и дорого, но многим очень нравится.

GitHub Issues

Многие (в том числе и компании) хранят код в репозиториях Github. Удивительно, но многие не знают, что там есть свой трекер задач. Впрочем, он интересен также тем, что Issues могут быть завязаны с коммитами — сделал пуш и таски закрылись (если в комменте указал их ID соответственно).

Другие

Знаю, что в некоторых кругах популярен TFS, но простите — я даже боюсь смотреть туда )
Ребята из Тематические Медиа советовали взглянуть на Asana, но тоже как-то не прижилось.

Почему Pivotal Tracker?

Ценообразование

PT не бесплатный продукт, он стоит вполне вменяемых денег и работает по модели SaaS.
За $100 в месяц вы получите возможность создания неограниченного количества проектов и 25 участников в них.

Основное

PT может интегрироваться с Google Apps, тогда приглашение сотрудников в проекты становится проще, а к таскам можно сразу прикреплять документы из Google Drive (например с описанной логикой).

У PT много интересных и скрытых возможностей, практически все описано в длинном хэлпе — www.pivotaltracker.com/help.

Общие правила

Мы не используем понятие user-story как оно есть на самом деле. У нас это просто таск/задача.

В PT есть 4 типа тасков — feature, bug, chore и release. Мы используем эти типы так:

Feature — основые задачи по изменению или улучшению функциональности
Bug — номер бага в Crashlytics, либо краткое описание бага
Release — наименование версии билда (альфа, бэта и rc)
Chore — задачи для менеджера непосредственно связанные с разработкой или релизом

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

Зеленый лейбл это тэг — мы используем его для указание разделов, к которым применима данная фича (например, blog view).

В каждом таске можно вести обсуждение с упоминанием других членов команды (им прилетит нотифай), можно добавлять любые файлы (чаще всего это скриншоты, например к UI-багу), можно вести сабтаски (удобно при pixel-perfect доработках).

Все эпики (epics) изначально хранятся в отдельной вкладке. Вы всегда можете открыть эпик с какой-то старой версией приложения и посмотреть, когда определенная фича была реализована, а также легко планировать roadmap для будущих версий. Каждый эпик имеет свой уникальный номер, как и таск — всегда можно дать на него прямую ссылку.

Интерфейс в PT представляет собой панели: основные — backlog, icebox, current. Мы используем только панель icebox (для хранения идей и тех тасков, которые не входят ни в одну версию пока) и backlog (лента утвержденных тасков), а также панели, которые вызываются через эпики — они отображают таски только к выбранной версии. На первый взгляд тому, кто этим не пользоваться, все покажется очень странным — но потом ты настолько привыкаешь к этой системе, что на другую смотреть просто не сможешь никогда.

Непосредственно workflow

Менеджер имеет на руках ТЗ и roadmap по версиям. Начинается процесс создания тасков. Каждый таск обязательно сопровождается эпиком (если это разработка с нуля, то версия обычно 1.0) и лейблом по разделу (мы используем лейбл как экран, т.е. экран команды это “team”, экран матча это “match”). Все таски попадают в Icebox.

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

У каждого таска есть уровень сложности — это некое абстрактное значение в поинтах (оно применяется для подсчета velocity, но мы это не используем). Впрочем, без установки этого значения задачку не стартовать. После того, как разработчик приступает к задаче, он нажимает Start. По завершению таска разработчик нажимает Finish. Следующий возможный стейт таска это Delivered. Это происходит когда разработчик доставляет таск в сборку.

Мы делаем пятничные сборки, в них как раз и попадают уже завершенные таски. Делая сборку, разработчик отмечает те таски, которые попадут в сборку и которые можно принимать менеджеру проекта. Менеджер может принять таск, если считает что задача сделана как надо и функционирует, а может сделать реджект, указав причину. После реджекта таск имеет стейт Rejected (кнопка — Restart) и к нему можно приступить снова.

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

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

Когда таск доставлен и принят, то он становится зеленым и задача закрыта.
Разработчики любят указывать в коммите в GitHub ID таска, тогда при пуше таск автоматически финишируется.

Особенности

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

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

У Pivotal Tracker есть отличные iPhone/iPad приложения (пока правда без адаптации к iOS7), также есть сторонние клиенты под Android. Есть интеграция со всеми внешними сервисами — GitHub, Campfire, FlowDock, HipChat, Zendesk и т.п.

Мы не предоставляем доступ в Pivotal заказчику, но в случае такого требования в трекере есть возможность пригласить “наблюдателя” с правами “read only”.

Заключение

Наши друзья из Aviasales также используют этот инструмент как в серверной разработке (правда потихоньку соскакивают с него, т.к. переходят на полный Scrum), так и в отделе мобильной разработки. Друзья из Bambk используют Pivotal для серверной разработки. Мы все очень довольны, что такой инструмент существует на рынке и предоставляет действительно те возможности, которые нам требуются. Внедрить использование Pivotal Tracker может как небольшая команда стартапа, так и серьезная команда крупного продуктового проекта или аутсорс-разработки.

В комментариях я предлагаю рассказать какой таск-менеджер для разработки выбрали вы и почему.
Также готов ответить на вопросы по нашему workflow в Pivotal Tracker в плане разработки.

Автор: Mofas

Источник