Мы все прекрасно понимаем, что не существует универсальной системы управления проектами, которая бы подходила для всех случаев. Выбор системы целиком и полностью зависит от Ваших нужд. Если вы не нуждаетесь в репозитариях, и для общения Вам достаточно комментариев в тикетах, а работаете Вы над проектром по «гибким» методологиям, то возможно одним из лучших вариантов будет — Pivotal Tracker.
Пост в первую очередь предназначен для тех, кто не знаком с Pivotal Tracker, или тех кто считает его сложным и непонятным.
Интерлюдия
«Pivotal Tracker is a story-based project planning tool.»
Pivotal предусмотрен для проектов разрабатываемых по «гибким» методологиям, является полностью бесплатным и написан на Ruby on Rails.
Ключевое понятие системы Pivotal — «Velocity». У этого понятия, я думаю, найдутся противники, защитники и ярые поклонники. Я же стараюсь предерживаться нейтралитета.
Velocity — это среднее число point приходящееся на итерацию, оно рассчитывается по недавно завершенным итерациям. В настройках проекта можно выставить по скольким итерациям будет высчитываться Velocity.
Point — это относительная мера «усилий» необходимых для закрытия тикета. Для пользователей ранее не знакомых с подобными терминами, понятие может показаться очень размытым, его можно воспринимать как сложность тикета или объема работ.
Допустим, в недельной итерации Velocity равно 10. В этом случае сумма поинтов у тикетов в текущей итерации не должна превышать 10, иначе они начнут падать в бэклог. Если же Velocity исчерпано и закрыты все тикеты, но при этом есть возможность на данной итерации сделать еще несколько тикетов, то их можно просто вернуть из бэклога, нажав на одном из тикетов старт и он автоматически падает в Current, если даже на него не хватает Velocity.
Points могут выставляться в одном из следующих видов:
- Linear (0, 1, 2, 3)
- Powers of 2 (0, 1, 2, 4, 8)
- Fibonacci (0, 1, 2, 3, 5, 8)
Интерфейс
Практически вся работа над проектом сводится к работе с главной страницей проекта. В этом есть два основных преимущества:
- нет больше нудных перезагрузок страницы;
- всю работу на проекте можно оценить одним взглядом, а не бегать по страницам держа все в голове.
На главной странице содержатся stories, или по-другому тикеты.
Пример story: 'A user should be able to add a product to their shopping cart'.
Полагаю, данное понятие особенно понравится любителям BDD. Но в принципе stories можно рассматривать как тикеты, потому что понятие story на практике применимо не везде.
Как мы видим, здесь четыре стопочки «Done», «Current», «Backlog», «Icebox».Любую из них мы можем скрыть и показать в любой момент.
Icebox — это то куда попадает тикет после создания, и хранится там, пока Вы не начинаете над ним работать, перемещая его в Current.
Current — это список текущей итерации (длина итерации выбирается в неделях). Если тикеты не умещаются в текущей итерации то они автоматически попадают в Backlog.
Backlog — если количества Velocity (по дефолту 10 на одну неделю) не хватает на все тикеты текущей итерации, то оставшиеся тикеты падают в эту стопку.
Done — это та стопка куда попадают закрытые тикеты после завершения текущей итерации
Тикеты можно перемещать между стопками(всеми кроме Done). Понятно, что мы не можем уже стартанувший тикет положить в Icebox, или положить в Backlog, то на что хватает Velocity в текущей итерации(Current).
На этой же странице можно показать колонки с Releases, My Work, Charts, Project History, Charts, Labels(tags or compponents).
Stories (tickets)
Тикеты могут выступатьв роли Feature, Bug, Chore, Release.
У всех этих типов могут быть следующие поля:
- Labels (tags)
- Owner
- Description
- Attach file
- Comments
Feature — это feature. Помимо общих полей они могут иметь еще и оценку в Points.
Bug — это bug, что тут говорить.
Chore — это тикет в котором необходимо реализовать функциональность, которая необходима для разработчика, но не просматривается заказчиком. Это может быть или рефакторинг, или тестирование, или что-либо еще.
Release — это просто тикет-флажок, который служит для отметки места, на котором необходимо сделать релиз. Помимо общих полей имеет поле Deadline, с датой сдачи релиза.
У Feature и Bug есть несколько состояний: Not yet started, Started, Finished, Delivered, Accepted, Rejected.
У Release есть только Not yet started, Accepted, а у Chore есть Not yet started, Started, Finished.
Приоритеты тикетов изменяются очень просто, достаточно просто перенести тикет на новую позицию drag & drop.
Заключение
Не вижу смысла полностью описывать функционал Pivotal Traсker, главное что я хотел показать — это подход, который применяется в данном трекере, крайне удобный для «гибкой» разработки, когда не нужно оценивать итерацию в часах, а достаточно оценить примерный объем работ и сложность, а также интерфейс, который я считаю очень удобным. Если что-то из этого я сделал, то уже хорошо. Надеюсь ваше время было потрачено не зря.
Ссылки: Getting Started, FAQ
