Pivotal Tracker как инструмент в Waterfall-разработке

    На российском рынке аутсорс-разработки не так много компаний, которые используют гибкие методологии разработки (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 в плане разработки.
    • +16
    • 7,3k
    • 6

    CleverPumpkin

    41,00

    Компания

    Поделиться публикацией

    Похожие публикации

    Комментарии 6
    • НЛО прилетело и опубликовало эту надпись здесь
        0
        Да, Trello очень интересный инструмент.
        Мы тоже его используем в своем workflow, но в более менеджерском — продакт-менеджер и дизайнер, например.
        Или продакт-менеджер и заказчик для согласования скетчей.

        Ну и конечно roadmap планирование.
        • НЛО прилетело и опубликовало эту надпись здесь
        0
        Для своих небольших проектов использую Basecamp, тк видел весь лог активности за день и простое управление тасками.
        На работе используем в моб. разработке — Asana, что-то среднее между записной книжкой и Basecamp, быстрый и простой инструмент.

        Trello не понравился, совсем. Возможно для менеджеров, дизайнеров и заказчиков — самое то.
          0
          Дизайнеры любят Basecamp и бумажки на мониторе :)
          С Pivotal у меня проблемы — я просто забываю выставлять эти все параметры там. Хотя программисты рады.
            0
            Не пробовали TargetProcess? Может как минимум то же самое, но более гибок. По-моему на <6 человек в команде бесплатна.

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

            Самое читаемое