Комментарии 23
У нас принято выставлять задаче due date в момент, когда она переводится в статус In Progress. Если же разработчик этого не сделал, ему придёт напоминание в корпоративный мессенджер HipChat. Специальный скрипт раз в два часа:
Зачем так сложно? Достаточно выставлять его равным текущему времени, если разработчик этого не сделал, а дальше его проблемы.
«Explicit better than implicit» :)
Тут получается каламбур, но — у нас явно видно, что значение для чего-то (due date) не установлено. Т.к. это поле предназначено для заполнения вручную, то автоматическое вмешательство может вызвать некий диссонанс — «как это Due date уже прошел? я не помню, чтобы менял его».
Тут получается каламбур, но — у нас явно видно, что значение для чего-то (due date) не установлено. Т.к. это поле предназначено для заполнения вручную, то автоматическое вмешательство может вызвать некий диссонанс — «как это Due date уже прошел? я не помню, чтобы менял его».
Думаю как раз потому, что "дальше его проблемы". Любая автоматизация должна решать проблемы, а не создавать их.
Вы хотите ставить due date == текущему времени? Взял работу и сразу закончил?
Стоит отметить, что автоматическое слияние может не произойти по причине конфликта слияния. В этом случае тикет автоматически переводится в статус Reopen и назначается разработчику, о чём он немедленно получает оповещение в HipChat, а в комментарий тикета добавляется соответствующее сообщение. После разрешения конфликта тикет возвращается в билд.
Не бывает ли проблем на этом этапе? Решение конфликтов может быть проведено некорректно и привнести новые баги. А у вас к этому моменту уже все тесты пройдены…
Слишком много думаете о автоматизации и мало о процессе.
Сходу:
— Open это и есть беклог. Не нужен никакой отдельный беклог. Ассайнить тикеты никто не мешает.
— Лидера уволить и научить разработчиков самим брать тикеты. Когда лидер болеет, работа стоит?
— декомпозиция есть, а стадии нет? Ничего не создаём сложнее кнопки на экране? Спеки не создаём? Как вообще понять, что разработчик уже декомпозирует, а не тикет просто лежит в беклог? (Я знаю. Важный лидер за спинами ходит.)
— Сделать Due Date просто обязательным полем и выкинуть скрипт.
Сходу:
— Open это и есть беклог. Не нужен никакой отдельный беклог. Ассайнить тикеты никто не мешает.
— Лидера уволить и научить разработчиков самим брать тикеты. Когда лидер болеет, работа стоит?
— декомпозиция есть, а стадии нет? Ничего не создаём сложнее кнопки на экране? Спеки не создаём? Как вообще понять, что разработчик уже декомпозирует, а не тикет просто лежит в беклог? (Я знаю. Важный лидер за спинами ходит.)
— Сделать Due Date просто обязательным полем и выкинуть скрипт.
1. Backlog ввели чисто для удобства. Если задача находится в этом статусе, значит лид ее отсмотрел и принял решение прямо сейчас ее не назначать ни на кого. Это можно решать иначе, конечно. Лейблами, например.
2. Я про это вроде как не писал ничего конкретного. В общем случае задачи назначает лид, но и разработчики сами разбирают тикеты вполне успешно. Тут нет жесткой схемы и каждый лид сам отстраивает этот процесс в своей команде.
3. Тут соглашусь с вами. Пожалуй, есть что улучшить. Лид в курсе, да. Ну и мы стараемся делать так, чтобы количество задач висящих на разработчике в один момент времени было очень небольшим. В этом случае, довольно просто понимать чем занят сейчас разработчик, не отвлекая его.
4. В нашем случае, спринт — не совсем спринт в классическом понимании :) Это инструмент недельного (у нас) планирования. Мы коммитимся перед продуктовой командой, что задачи взятые в спринт будут НАЧАТЫ на этой неделе, а значит и Due Date по ним будет определен. Подробно я писал об этом тут. Также Jira предоставляет удобные инструменты для работы со спринтами и в вашу схему они прекрасно ложатся.
2. Я про это вроде как не писал ничего конкретного. В общем случае задачи назначает лид, но и разработчики сами разбирают тикеты вполне успешно. Тут нет жесткой схемы и каждый лид сам отстраивает этот процесс в своей команде.
3. Тут соглашусь с вами. Пожалуй, есть что улучшить. Лид в курсе, да. Ну и мы стараемся делать так, чтобы количество задач висящих на разработчике в один момент времени было очень небольшим. В этом случае, довольно просто понимать чем занят сейчас разработчик, не отвлекая его.
4. В нашем случае, спринт — не совсем спринт в классическом понимании :) Это инструмент недельного (у нас) планирования. Мы коммитимся перед продуктовой командой, что задачи взятые в спринт будут НАЧАТЫ на этой неделе, а значит и Due Date по ним будет определен. Подробно я писал об этом тут. Также Jira предоставляет удобные инструменты для работы со спринтами и в вашу схему они прекрасно ложатся.
Просто попытайтесь проникнуться идеей. Чем больше задач делегированно или автоматизированно — тем больше у руководителя времени вырасти из менеджера- сортировщика в лидера, который думает о развитии продукта и мотивации персонала. Всегда можно найти работника сортировщика, который будет это делать на «достаточно» хорошем уровне и будет рад, что он уже как бы мини-менеджер.
«У нас принято выставлять задаче due date в момент» — положено-ешь, не положено — не ешь. Не знаешь дату — декомпозируй. Знаешь — пиши, работай.
Там еще «разработчик присутствует на рабочем месте». Если мержится и работает — зачем вам разработчик? Не работает — выкинули и встретимся по приходу из отпуска.
Что такое «On Production — Ok» ?? А если не ОК? Где стрелка отката назад? Подозреваю, что востановят прод из бекапа и он всегда будет снова ОК. Значит статус не нужен. Запустился, не упал за 10 мин — Closed. Упадет — новый тикет и root cause. Или ставьте Closed через 2 недели. Вы все равно НЕ ЗНАЕТЕ ок или не ок, пока две недели не пройдет. Зачем лишний статус?
«У нас принято выставлять задаче due date в момент» — положено-ешь, не положено — не ешь. Не знаешь дату — декомпозируй. Знаешь — пиши, работай.
Там еще «разработчик присутствует на рабочем месте». Если мержится и работает — зачем вам разработчик? Не работает — выкинули и встретимся по приходу из отпуска.
Что такое «On Production — Ok» ?? А если не ОК? Где стрелка отката назад? Подозреваю, что востановят прод из бекапа и он всегда будет снова ОК. Значит статус не нужен. Запустился, не упал за 10 мин — Closed. Упадет — новый тикет и root cause. Или ставьте Closed через 2 недели. Вы все равно НЕ ЗНАЕТЕ ок или не ок, пока две недели не пройдет. Зачем лишний статус?
По распределению задач: как я и писал, часто именно разработчики сами и бегут себе задачи, но бывают ситуации, когда только лид знает, что «вот эту вот задачу» надо как можно скорее сделать/начать. Именно к лиду стекает информация из смежных отделов и он лучше ориентируется в приоритетах. Если же у лида нет особых пожеланий, то он так и говорит: «Возьми чо-нить из беклога сам»
По «разработчик присутствует на рабочем месте». Во-первых, у нас принято проверять задачу в проде после того как она выехала. Посмотреть статку, эррор-логи, убедиться, что все работает нормально. Лучше всего это может сделать сам разработчик. Во-вторых, уходя в отпуск, девелопер может проставить в поле тикета ViceDeveloper имя другого разработчика, который в теме, и тогда тикет обычным образом замержится (кажется я забыл написать в статье об этом). В-третьих, лид получает уведомление в HipChat, если тикет его сотрудника скипнулся из-за отсутствия. В этом случае он может попросить релизеров замержить тикет в билд, если фича срочная и не ждет возвращения разработчика. Так что все довольно гибко.
On Production — Ok — значит, что фича проверена на продакшене вот и все. Если не ок, то действуем по обстоятельствам: разбираемся, патчим, открываем новый тикет на исправление и т.п.
По «разработчик присутствует на рабочем месте». Во-первых, у нас принято проверять задачу в проде после того как она выехала. Посмотреть статку, эррор-логи, убедиться, что все работает нормально. Лучше всего это может сделать сам разработчик. Во-вторых, уходя в отпуск, девелопер может проставить в поле тикета ViceDeveloper имя другого разработчика, который в теме, и тогда тикет обычным образом замержится (кажется я забыл написать в статье об этом). В-третьих, лид получает уведомление в HipChat, если тикет его сотрудника скипнулся из-за отсутствия. В этом случае он может попросить релизеров замержить тикет в билд, если фича срочная и не ждет возвращения разработчика. Так что все довольно гибко.
On Production — Ok — значит, что фича проверена на продакшене вот и все. Если не ок, то действуем по обстоятельствам: разбираемся, патчим, открываем новый тикет на исправление и т.п.
Вы не снимали статистику частоты использования скрипта для скрытия комментов от бота?
Мне пока не очень понятна выгода писать в комментарии замечания с ревью в джире. Это дублирование, кажется, информации из почты, с гита. Если после ревью код порядочно переписывается, сильно отличается от первой версии, то не будут ли старые комменты мешать?
Про Due Date тоже не понятно: зачем скрипт, если можно настроить обязательность заполнения поля при переводе на следующий этап? Чем скрипт удобнее?
Мне пока не очень понятна выгода писать в комментарии замечания с ревью в джире. Это дублирование, кажется, информации из почты, с гита. Если после ревью код порядочно переписывается, сильно отличается от первой версии, то не будут ли старые комменты мешать?
Про Due Date тоже не понятно: зачем скрипт, если можно настроить обязательность заполнения поля при переводе на следующий этап? Чем скрипт удобнее?
Нет, статистику не снимали. Знаю только, что продуктовая команда, а также клиентские команды, когда заходят в серверный тикет активно используют эту кнопку. Для них информация от бота никакой пользы не несет.
Дублирование ревью, да, есть такое. Но это удобно, поверьте. Разработчику же самому проще, получив переоткрытый тикет, тут же в последнем комменте увидеть все замечания. Не нужно куда-то дополнительно кликать и т.д. Также это полезно для последующих разбирательств. Например, когда по тикету были сорваны сроки, лид (или другой коллега) заходит и смотрит какие замечания были в том числе и на ревью. Тоже не надо никуда дополнительно кликать, мотаешь себе колесико и анализируешь.
Дублирование ревью, да, есть такое. Но это удобно, поверьте. Разработчику же самому проще, получив переоткрытый тикет, тут же в последнем комменте увидеть все замечания. Не нужно куда-то дополнительно кликать и т.д. Также это полезно для последующих разбирательств. Например, когда по тикету были сорваны сроки, лид (или другой коллега) заходит и смотрит какие замечания были в том числе и на ревью. Тоже не надо никуда дополнительно кликать, мотаешь себе колесико и анализируешь.
Все еще не могу поверить :)
Когда совершается действие с тикетом, обычно об этом узнаю (лично я) из письма (допустим, что никто не написал в чат или не сказал устно). Т.е. мне надо мониторить почту. С гита все замечания по ревью так же приходят на почту. Или я не читаю ящик, не слежу за уведомлениями, а просто жмакаю f5 на доске или тикете через какой-то интервал. Тут, наверно, это удобно.
Интересно еще с какой частотой проходят разбирательства по срокам, в которые не уложились именно из-за ревью.
Когда совершается действие с тикетом, обычно об этом узнаю (лично я) из письма (допустим, что никто не написал в чат или не сказал устно). Т.е. мне надо мониторить почту. С гита все замечания по ревью так же приходят на почту. Или я не читаю ящик, не слежу за уведомлениями, а просто жмакаю f5 на доске или тикете через какой-то интервал. Тут, наверно, это удобно.
Интересно еще с какой частотой проходят разбирательства по срокам, в которые не уложились именно из-за ревью.
Спасибо за статью! Всегда интересно узнать, как этот процесс устроен в других компаниях в таких подробностях)
Возникло несколько вопросов:
— на скрине с тикетом, я вижу одно поле, которое вроде не упоминалось в статье — «approvers», правильно ли я понимаю, что это список тех людей, что могут утвердить то, что таска соответствует описанию и её можно катить в прод? На каком этапе это происходит, есть ли для этого отдельный статус тикета и процесс?
— порядок проведения работ: для меня всегда было скользким моментом, какой же порядок ведения таски предпочесть: т.е. понятно, что после описании и утверждения задачи идёт разработка, а вот как потом разместить последующие шаги? Например, пропусткать ли тестирование и аппрув вперёд review, чтобы не отвлекать на ревью разработчиков, или вообще пропустить вперёд одного продукт-овнера (ну или кто у вас там в approvers), чтобы он понял, что это действительно то, что ему нужно и не тратить время тестировщиков? Собственно, вопрос: из каких именно предпосылок исходили вы, устанавливая именно такой порядок этапов тикета
Возникло несколько вопросов:
— на скрине с тикетом, я вижу одно поле, которое вроде не упоминалось в статье — «approvers», правильно ли я понимаю, что это список тех людей, что могут утвердить то, что таска соответствует описанию и её можно катить в прод? На каком этапе это происходит, есть ли для этого отдельный статус тикета и процесс?
— порядок проведения работ: для меня всегда было скользким моментом, какой же порядок ведения таски предпочесть: т.е. понятно, что после описании и утверждения задачи идёт разработка, а вот как потом разместить последующие шаги? Например, пропусткать ли тестирование и аппрув вперёд review, чтобы не отвлекать на ревью разработчиков, или вообще пропустить вперёд одного продукт-овнера (ну или кто у вас там в approvers), чтобы он понял, что это действительно то, что ему нужно и не тратить время тестировщиков? Собственно, вопрос: из каких именно предпосылок исходили вы, устанавливая именно такой порядок этапов тикета
последующие шаги?
1. Unit test by Developer. (пока не работает — все отдыхают)
2. Ревью кода предусматривает проверку логики. Если есть продукт-овнер, который это делает быстрее разработчиков — пускайте вперед. Если он один на всех и занят — пускайте разработчиков соседей. Или тим-лида. Чистая логика: если работает не так — какая мне разница красивый ли там код.
3. Тестировщики максимально в конце. Желательно набор авто-тестов до того как людей дергать. Маленькая команда, тим лид глупый. Сделали мини ревью(формат только) — и пусть тестировщики разбираются работает или нет.
Нет идеальных процессов. Процесс — либо дает предсказуемый средний результат. Либо закрывает именно ваши проблемы, дырки в скиллах и людях. Документация ниже плинтуса? Раздражает? Введите стадию «Document update» и тд. Делаете код ревью в гите и не бывает такого, что ревью не сделано — можно вообще выкинуть стадию «On review» в Jira.
1. Unit test by Developer. (пока не работает — все отдыхают)
2. Ревью кода предусматривает проверку логики. Если есть продукт-овнер, который это делает быстрее разработчиков — пускайте вперед. Если он один на всех и занят — пускайте разработчиков соседей. Или тим-лида. Чистая логика: если работает не так — какая мне разница красивый ли там код.
3. Тестировщики максимально в конце. Желательно набор авто-тестов до того как людей дергать. Маленькая команда, тим лид глупый. Сделали мини ревью(формат только) — и пусть тестировщики разбираются работает или нет.
Нет идеальных процессов. Процесс — либо дает предсказуемый средний результат. Либо закрывает именно ваши проблемы, дырки в скиллах и людях. Документация ниже плинтуса? Раздражает? Введите стадию «Document update» и тд. Делаете код ревью в гите и не бывает такого, что ревью не сделано — можно вообще выкинуть стадию «On review» в Jira.
Ревью кода предусматривает проверку логики
не только. тут же могут проверяются вопросы безопасности и дальнейшего сопровождения, например. И ревью никак не отменяет проверки результата продуктом, потому что (по идее) он должен проверять не только соответствие описанной логике, но и как это выглядит «вживую» (хотя, такие-то вещи наверное лучше вообще в прототипах проверять?)
Нет идеальных процессов. Процесс — либо дает предсказуемый средний результат. Либо закрывает именно ваши проблемы, дырки в скиллах и людях.
да, собственно, это и хотелось узнать — какие были предпосылки, что конкретно в этой команде выстроился именно такой процесс
Approvers — необязательное поле, которое используется в некоторых командах для фильтрации беклога разными людьми. Т.е. апрув выставляется до разработки. Но есть другой пример использования: в MAPI команде (архитекторы, которые разрабатывают протокол общения клиента и сервера) это поле используется для того чтобы убедится, что все ответственные из клиентских и серверных команд согласны с предложенным протоколом.
Порядок я описал, какой он есть у нас. Тестирование строго после ревью. Так, на мой взгляд, итерация короче. Передавать задачу в другой департамент лучше после того как все работы в своем департаменте закончены.
Порядок я описал, какой он есть у нас. Тестирование строго после ревью. Так, на мой взгляд, итерация короче. Передавать задачу в другой департамент лучше после того как все работы в своем департаменте закончены.
системные архитекторы с помощью специального интерфейса в пару кликов создают тикеты различным командам (клиентским и серверным) для реализации проекта (при этом тикеты корректно заполняются нужными полями и линкуются между собой; это помогает нам эффективно организовать синхронизацию работы команд);
А что потом? Как они отслеживают процесс? И я правильно понял, что это специальный интерфейс сбоку от Jira?
Да, это отдельный интерфейс, который позволяет сразу создать тикеты на все нужные команды. Отслеживать просто: все тикеты линкуются автоматом между собой. Но отслеживать прогресс — это не задача системных архитекторов.
А на жире не смогли такое сделать? Я просто к чему спрашиваю. Начальство все время хочет высоуровневое понимания прогресса по задачам. Эпики это хорошо, но они привязаны к проектам, а выскоуровневые задачи обычно надпроектные. Вот и думаю, что придется что-то свое пилить.
А на жире не смогли такое сделать?
Это сложнее. Jira не предоставляет удобного способа создания каких-либо webview. Большинство встроенных операций представляют из себя стандартные экраны (screen), в которых можно настроить только список полей. Для создания чего-то кастомного, нужно смотреть в сторону плагинов: или писать полностью свои или использовать какие-то готовые. Например, в script runner есть возможность добавлять собственные web элементы в интерфейс, в том числе, можно вызывать dialogs при нажатии на кнопку.
Но последнее, конечно, сложнее, чем сделать простую форму на отдельной странице :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет