Кто из нас не был в ситуации, когда, открывая список задач в трекере, впору было схватиться за голову от кучи разношерстных записей и слов и сразу появлялось желание закрыть список обратно?
Сегодня я расскажу, как можно удобно структурировать подобные списки, и что дает такое структурирование. Другими словами, как лучше пользоваться категориями задач (тикетов) в системах управления проектами.
Что же такое на самом деле фича, чем отличается от патча, какие бывают еще категории, как выбрать из них нужную и правильно описать задачу, чтобы люди быстро и точно поняли, что от них хотят?
Категории задач вообще удобны для фильтрации задач в общем списке или в оперативном плане, т.е. списке задач до ближайшего релиза. Кроме того, их можно использовать как одну из аналитик при просмотре различной статистики, например, затраченного времени.
Логично подумать, какие именно категории задач выделить. Конечно же, существуют общепринятые категории задачи, такие как «баг», и я немного побуду Кэпом, рассказывая про них, однако далеко не все сотрудники (как я убедился на практике) правильно используют категории. И если вы уже знаете то, что написано ниже, просто расскажите об этом тем, у кого не такой большой опыт работы с системами управления проектами.
Замечу, что набор категорий задач все равно индивидуален для каждой команды, и рассказ пойдет о том, как их применяем мы.
1) Баг (англ. bug — ошибка) — обнаруженная ошибка в приложении, ситуация, в которой приложение работает неверно или вообще падает.
Название: содержит короткое, по возможности информативное описание ошибки.
Важность наглядного названия трудно переоценить, ведь в списке задач и оперативном плане (списке задач для текущей версии) мы видим только название, и ничего больше.
Описание: содержит шаги, необходимые для воспроизведения ошибки на локальном компьютере, описание ошибочного поведения приложения (as-is), описание корректного поведения (to-be), и мысли/рекомендации по устранению ошибки.
Можно прикладывать скрины ошибки, StackTrace исключений и т.д.
Пример:
Название:
Неверно показывается карта на вкладке «Карта».
Описание:
Steps: авторизуйтесь, зайдите на вкладку истории, нажмите f5, перейдите на вкладку «карта».
As-Is: карта недогрузилась, некоторые участки экрана серые. Скриншот прилагается.
To-Be: карта должна отображаться на весь размер вкладки.
Примечание: возможно, дело в порядке вызова layout().
<Приложенный скриншот>.
2) Фича (англ. feature — фишка) — новый UseCase приложения. т.е. функциональность, обособленная функция для конечного пользователя, которой еще нет в приложении.
Название: содержит короткое и однозначное название функции.
Описание: детальное описание того, как выглядит эта функция с точки зрения пользователя, и мысли/рекомендации по реализации.
Обычно фича — Это добавление новой функциональности, а не изменение старой. В отличие от фичи улучшение того, что есть, в большинстве случаев называется «патч». Каждая новая фича берет свое начало из спецификации (ТЗ) проекта, другими словами, принцип ее работы должен быть описан в Вики. Можно приложить ссылку на статью в Вики (спецификации хранятся как набор страниц в отдельной категории).
Пример:
Название: Возможность менять видимость в мобильном клиенте
Описание: Возможность менять видимость в группах пользователя в мобильном клиенте. После авторизации пользователь может выбрать группу, посмотреть текущие настройки видимости (видим/невидим), изменить настройки. Уведомлять об успешном/неудачном завершении операции.
На сервере использовать метод класса ProfileService: void setVisible(Long groupId, boolean visible) throws SomeException.
На клиенте расширить форму FormGroupsList, добавить новую команду.
3) Патч (англ. patch — заплатка) — улучшение или незначительное исправление существующей функциональности.
Название: содержит короткое описание того, что и где нужно улучшить.
Описание: содержит более детальное описание той части приложения, которая подвергнется изменениям. Это могут быть изменения поведения (со ссылкой на спецификацию проекта), правки текста, расположения визуальных компонентов. Новая функциональность при выполнении патча не добавляется. Обычно используется при изменении требований заказчиком, или же обнаружении недоработок в приложении, не относящихся к багам.
Пример:
Название: Исправить положение виджетов в форме заказа.
Описание: Вкладка управления заказами, форма заказа. Необходимо исправить заголовок на <...>, поставить поле адреса над полем телефона, сделать подписи к полям сверху, а не слева.
<Обновленный рисунок дизайнера>.
4) Поручение — некоторое действие, не связанное с разработкой проекта. Например, перенастроить DNS, развернуть новую службу на сервере, поправить конфиги одной из библиотек, дополнить документацию и т.д.
Название: описание действия.
Описание: в произвольной форме. Главное, чтобы было понятно, что нужно сделать.
5) Событие. Эту категорию задач пришлось ввести из-за того, что мы хотели устроить полный учет времени, затраченного на проект. И, с нашей точки зрения, встречи с заказчиком, пользователями, различные мероприятия, которые мы использовали для пиара (напр.StartupPoint) и подготовка к ним, должны были входить в учет времени.
Название: название события.
Описание: Описание либо ссылка на него и ссылки на связанные подзадачи. После завершения события сюда добавляются его итоги. Это полезно, когда нужно донести результаты события членам команды, либо если вы хотите хранить хронологию встреч.
В заключение скажу, что мы используем Redmine (это свободное ПО), который помимо управления тикетами содержит тайм-менеджмент, версионирование, вики, форум, интеграцию с системами контроля версий, хранилище документов, роли пользователей и довольно гибко настраивается.
Сегодня я расскажу, как можно удобно структурировать подобные списки, и что дает такое структурирование. Другими словами, как лучше пользоваться категориями задач (тикетов) в системах управления проектами.
Что же такое на самом деле фича, чем отличается от патча, какие бывают еще категории, как выбрать из них нужную и правильно описать задачу, чтобы люди быстро и точно поняли, что от них хотят?
Категории задач вообще удобны для фильтрации задач в общем списке или в оперативном плане, т.е. списке задач до ближайшего релиза. Кроме того, их можно использовать как одну из аналитик при просмотре различной статистики, например, затраченного времени.
Логично подумать, какие именно категории задач выделить. Конечно же, существуют общепринятые категории задачи, такие как «баг», и я немного побуду Кэпом, рассказывая про них, однако далеко не все сотрудники (как я убедился на практике) правильно используют категории. И если вы уже знаете то, что написано ниже, просто расскажите об этом тем, у кого не такой большой опыт работы с системами управления проектами.
Замечу, что набор категорий задач все равно индивидуален для каждой команды, и рассказ пойдет о том, как их применяем мы.
Баг
1) Баг (англ. bug — ошибка) — обнаруженная ошибка в приложении, ситуация, в которой приложение работает неверно или вообще падает.
Название: содержит короткое, по возможности информативное описание ошибки.
Важность наглядного названия трудно переоценить, ведь в списке задач и оперативном плане (списке задач для текущей версии) мы видим только название, и ничего больше.
Описание: содержит шаги, необходимые для воспроизведения ошибки на локальном компьютере, описание ошибочного поведения приложения (as-is), описание корректного поведения (to-be), и мысли/рекомендации по устранению ошибки.
Можно прикладывать скрины ошибки, StackTrace исключений и т.д.
Пример:
Название:
Неверно показывается карта на вкладке «Карта».
Описание:
Steps: авторизуйтесь, зайдите на вкладку истории, нажмите f5, перейдите на вкладку «карта».
As-Is: карта недогрузилась, некоторые участки экрана серые. Скриншот прилагается.
To-Be: карта должна отображаться на весь размер вкладки.
Примечание: возможно, дело в порядке вызова layout().
<Приложенный скриншот>.
Фича
2) Фича (англ. feature — фишка) — новый UseCase приложения. т.е. функциональность, обособленная функция для конечного пользователя, которой еще нет в приложении.
Название: содержит короткое и однозначное название функции.
Описание: детальное описание того, как выглядит эта функция с точки зрения пользователя, и мысли/рекомендации по реализации.
Обычно фича — Это добавление новой функциональности, а не изменение старой. В отличие от фичи улучшение того, что есть, в большинстве случаев называется «патч». Каждая новая фича берет свое начало из спецификации (ТЗ) проекта, другими словами, принцип ее работы должен быть описан в Вики. Можно приложить ссылку на статью в Вики (спецификации хранятся как набор страниц в отдельной категории).
Пример:
Название: Возможность менять видимость в мобильном клиенте
Описание: Возможность менять видимость в группах пользователя в мобильном клиенте. После авторизации пользователь может выбрать группу, посмотреть текущие настройки видимости (видим/невидим), изменить настройки. Уведомлять об успешном/неудачном завершении операции.
На сервере использовать метод класса ProfileService: void setVisible(Long groupId, boolean visible) throws SomeException.
На клиенте расширить форму FormGroupsList, добавить новую команду.
Патч
3) Патч (англ. patch — заплатка) — улучшение или незначительное исправление существующей функциональности.
Название: содержит короткое описание того, что и где нужно улучшить.
Описание: содержит более детальное описание той части приложения, которая подвергнется изменениям. Это могут быть изменения поведения (со ссылкой на спецификацию проекта), правки текста, расположения визуальных компонентов. Новая функциональность при выполнении патча не добавляется. Обычно используется при изменении требований заказчиком, или же обнаружении недоработок в приложении, не относящихся к багам.
Пример:
Название: Исправить положение виджетов в форме заказа.
Описание: Вкладка управления заказами, форма заказа. Необходимо исправить заголовок на <...>, поставить поле адреса над полем телефона, сделать подписи к полям сверху, а не слева.
<Обновленный рисунок дизайнера>.
Поручение
4) Поручение — некоторое действие, не связанное с разработкой проекта. Например, перенастроить DNS, развернуть новую службу на сервере, поправить конфиги одной из библиотек, дополнить документацию и т.д.
Название: описание действия.
Описание: в произвольной форме. Главное, чтобы было понятно, что нужно сделать.
Событие
5) Событие. Эту категорию задач пришлось ввести из-за того, что мы хотели устроить полный учет времени, затраченного на проект. И, с нашей точки зрения, встречи с заказчиком, пользователями, различные мероприятия, которые мы использовали для пиара (напр.StartupPoint) и подготовка к ним, должны были входить в учет времени.
Название: название события.
Описание: Описание либо ссылка на него и ссылки на связанные подзадачи. После завершения события сюда добавляются его итоги. Это полезно, когда нужно донести результаты события членам команды, либо если вы хотите хранить хронологию встреч.
В заключение скажу, что мы используем Redmine (это свободное ПО), который помимо управления тикетами содержит тайм-менеджмент, версионирование, вики, форум, интеграцию с системами контроля версий, хранилище документов, роли пользователей и довольно гибко настраивается.