I_D>Мысли здравые, но изложены исходя из наличия только двух ролей: заказчик и разработчик. На практике ролей куда больше: заказчик, разработчик, тестировщик, менеджер проекта, ведущий разработчик, ведущий тестировщик.
На мой взгляд концептуально роли две: тот, кто дает работу и тот, кто ее выполняет. Остальное — частности.
I_D>В такой конфигурации workflow неизбежно будет другим, верно?
Workflow — это то, как задачи курсируют между участниками. К самой механике курсирования задач, ИМХО, не имеет отношения.
I_D>Ещё смутило то, что предлагается задачу из Resolved переводить сразу в Closed. Багзилла ещё в 2000 году знала, что задача сначала должна быть Verified (причём в моём случае — сначала verified на staging, только после этого — verified на staging. К слову, не вижу способы разграничить эти состояния кроме как через поле status, с другой стороны — не хочется городить кучу дополнительных статусов)
ИМХО, не стоит усложнять базовые процессы. Если мы хотим, чтобы какие-то задачи были отдельно верифицированы — то пишем расширение для системы управления задачами, которое по нажаию на кнопочку будет создавать зависимую задачу на верификацию и назначать на кого надо. Собственно, в этом и заключается настройка workflow — написание правил как и куда курсируют задачи, какие задачи что порождают, в каких ситуациях задачи закрывать можно а в каких нельзя. Базовая же механика жизни одной задачи — это строительный кирпич процесса. ИМХО, кирпичи лучше не перегружать — неустойчивые конструкции получаются, сам видел. Миллион полей, все бибикает и не работает
>>При изменении состояния задачи не рекомендуется менять ни заказчика, ни исполнителя. Многие пользователи ошибочно устанавливают Assignee на того же человека, что и Reporter при установке состояния задачи в Resolve. Это рушит описанную выше логику работы и всячески препятствует «однокликовой» работы с задачами.
Описанная выше логика работы, насколько я видел, решается порождением дополнительных задач, а не модификацией существующих. Потому что, как я уже говорил, бытует мнение что задача — это строительный кирпич, и не по феншую перегружать его лишними сущностями.
I_D>Как быть с тем, что большинство систем управления задачами позволяют подписаться на уведомления только в 2 конфигурациях: а) на все задачи вообще, б) на задачи, у которых подписчик внезапно стал Assignee?
Писать расширения. Универсальных всемогуторов сейчас нема, все системы предназначены для допиливания под конкретного пользователя, из которобки они делают только базовые вещи. Благо, написать уведомлялку ля той же джиры последних версий — это [b]несколько строчек[/b/ на Java.
I_D>Как быть с тем, что над задаче на разных этапах работают совершенно разные люди: сначала оценивающий её целесообразность проджект-менеджер, потом распределяющий задачи лид-девелопер, потом кодер, потом проверяющий её тестировщик, и только затем она возвращается репортеру?
Автоматической генерацией и модификацией задач. Все так делают. В пользовательском интерфейса — кнопки вида "сделать курто" и "сделать зашибись", нажатие на них проводит какие-то операции над задачами в соответствии с принятой в компании практикой.
I_D>На практике используется и тот, и другой способ. Какой из них в вашей практике оказался более подходящим и почему?
Как это делается в JIRA у нас. Задача имеет следующие состояния, обозначаемые статусами:
1. Opened: задача создана, назначены исполнитель, ревьюер (опционально) и тестер. Отсюда возможны переходы в In Progress или Resolved.
2. In Progress: исполнитель работает над задачей. Из этого состояния возможны переходы в Opened/Reopened (исполнитель приостановил работу над задачей) или Resolved.
3. Resolved: исполнитель закончил работать над задачей. Отсюда возможны переходы в Integrated или Reopened (например, если результаты работы не прошли ревью).
4. Integrated: спец по интеграции интегрировал commit-ы VCS, связанные с данной задачей, в очередную тестовую версию продукта. Из этого состояния возможны переходы в Reopened или Closed.
5. Reopened: результаты не прошли тестирование, требуется опять поработать над задачей. Отсюда возможен переход в In Progress или Resolved.
6. Closed: результаты успешно прошли тестирование.
Переходы между состояниями сопровождаются заполнением множества полей (comments, release notes, steps to repeat, и т.д.). Вся переписка по электропочте, где в заголовках присутствует идентификатор и наименование задачи, также пристегивается к тикету. Reopened сделан отдельным состоянием, чтобы менеджменту были видны случаи, когда приходилось возвращаться к работе над данной задачей.
Здравствуйте, Илья., Вы писали:
>>Обеспечить прохождение любой задачей всех нужных этапов — утверждения, уточнения, тестирования, выкладки — а не только разработки (всем известны ситуации, когда на production server выкладываются непротестированные изменения или давно готовые вещи не деплоятся месяцами, т.к. о них забыли — всё из-за бардака в управлении задачами) G>>Может и неверно, но в моей практике ни разу не требовалась никакая другая информация для анализа кроме пофикшено/не пофикшено. И>Проверено/непроверено, задеплоено/незадеплоено?
Ну для такой схемы должно быть достаточно двух терминальных состояний.
есть Change Request/Defect Report. у него есть workflow (упрощенно): Reported->in development->testing-> дальше варианты переходов: ->fixed->deployed, ->not fixed и тут либо переход в reported, либо создание нового тикета и простановка этому статуса not fixed, это как вам удобнее будет. ну и aborted можно сделать из любого состояния.
таким образом сочетание состояния и fix version отвечает на все вопросы: какие тикеты успешно и не очень протестированы, какие доставлены, какие надо доставить в следующей версии, какие отправлены обратно на разработку, утверждены (переведены из reported в in dev), ну и надо сделать ответвления для уточнения.
Контора разрабатывает, эксплуатирует и поддерживает веб-проекты. Сейчас пытаемся формализовать и упорядочить этот процесс. В процесее обдумывания workflow возник вопрос.
Задача (будь это разработка фичи, баг или исследования) может быть решёна несколькими способами. Fixed, Rejected, By design, Won't fix и так далее — всё это с точки зрения workflow — способы решения задачи. При этом они достаточно сильно отличаются, чтобы эти отличия хранить и учитывать в статистике.
В процесс управления проектом этот этап можно встроить двумя способами:
1) Создаётся несколько статусов: Resolved (Fixed), Resolved (By design), Rejected и так далее. Достоинство — более прозрачная фильтрация, поиск и статистика по статусам, нет риска записать отклонённые и исправленные в одну категорию.
2) Создаётся один статус Resolved и дополнительное поле "каким образом сделано", которое может принимать значения Fixed, By design, Rejected и так далее. Достоинство — более прозрачный workflow, достаточно настроить один раз для одного статуса, а не пяти-шести.
На практике используется и тот, и другой способ. Какой из них в вашей практике оказался более подходящим и почему?
Мысли здравые, но изложены исходя из наличия только двух ролей: заказчик и разработчик. На практике ролей куда больше: заказчик, разработчик, тестировщик, менеджер проекта, ведущий разработчик, ведущий тестировщик.
В такой конфигурации workflow неизбежно будет другим, верно?
Ещё смутило то, что предлагается задачу из Resolved переводить сразу в Closed. Багзилла ещё в 2000 году знала, что задача сначала должна быть Verified (причём в моём случае — сначала verified на staging, только после этого — verified на staging. К слову, не вижу способы разграничить эти состояния кроме как через поле status, с другой стороны — не хочется городить кучу дополнительных статусов)
>При изменении состояния задачи не рекомендуется менять ни заказчика, ни исполнителя. Многие пользователи ошибочно устанавливают Assignee на того же человека, что и Reporter при установке состояния задачи в Resolve. Это рушит описанную выше логику работы и всячески препятствует «однокликовой» работы с задачами.
Как быть с тем, что большинство систем управления задачами позволяют подписаться на уведомления только в 2 конфигурациях: а) на все задачи вообще, б) на задачи, у которых подписчик внезапно стал Assignee?
Как быть с тем, что над задаче на разных этапах работают совершенно разные люди: сначала оценивающий её целесообразность проджект-менеджер, потом распределяющий задачи лид-девелопер, потом кодер, потом проверяющий её тестировщик, и только затем она возвращается репортеру?
Здравствуйте, Илья., Вы писали:
И>Ну и самое главное — в статье описан только один из возможных подходов. И>Ни слова не сказано о том, чем этот подход лучше второго возможного подхода.
А почему второй должен быть лучше третьего? Подходов уйма. Берите за основу и допиливайте под ваши нужды.
Здравствуйте, Илья., Вы писали:
И>Потому, что тред создан только и исключительно для того, чтобы собрать мнения коллег о преимуществах и недостатках каждого из подходов. И>Вопрос из первого поста, с которого началось обсуждение — "Какой из них в вашей практике оказался более подходящим и почему?".
ok.
И>Потому, что тред создан только и исключительно для того, чтобы собрать мнения коллег о преимуществах и недостатках каждого из подходов. И>Вопрос из первого поста, с которого началось обсуждение — "Какой из них в вашей практике оказался более подходящим и почему?".
Как я уже написал выше в развернутом ответе, считаю что оба ваших варианта имеют системную ошибку — вы модифицируее поведение задач. Я же на основании некоторого опыта считаю что задачи — это строительные блоки, и модифицировать их не надо. Успешные системы управления, которые я видел, строились на автоматизации порождения задач и их модификации, а не на добавлении в задачи миллиона свойств, статусов и хитрых правил переходов между ними.
Все это, естественно, мое ИМХО и я могу ошибаться. С интересом выслушаю контраргументы .
Здравствуйте, Ilya_D., Вы писали:
I_D>Контора разрабатывает, эксплуатирует и поддерживает веб-проекты. Сейчас пытаемся формализовать и упорядочить этот процесс. В процесее обдумывания workflow возник вопрос.
I_D>Задача (будь это разработка фичи, баг или исследования) может быть решёна несколькими способами. Fixed, Rejected, By design, Won't fix и так далее — всё это с точки зрения workflow — способы решения задачи. При этом они достаточно сильно отличаются, чтобы эти отличия хранить и учитывать в статистике.
I_D>В процесс управления проектом этот этап можно встроить двумя способами:
I_D>1) Создаётся несколько статусов: Resolved (Fixed), Resolved (By design), Rejected и так далее. Достоинство — более прозрачная фильтрация, поиск и статистика по статусам, нет риска записать отклонённые и исправленные в одну категорию.
I_D>2) Создаётся один статус Resolved и дополнительное поле "каким образом сделано", которое может принимать значения Fixed, By design, Rejected и так далее. Достоинство — более прозрачный workflow, достаточно настроить один раз для одного статуса, а не пяти-шести.
I_D>На практике используется и тот, и другой способ. Какой из них в вашей практике оказался более подходящим и почему?
Задай сначала себе вопрос, а зачем надо различать эти статусы. Если просто для порядка, то может можно вообще обойтись одним статусом и комментом в тикете.
А если собирать какую-то статистику и как-то анализировать, то сначала стоит понять какую статистику и как анализировать и потом выбрать тот путь который позволить эту статистику на этой конкретной системе баг-трекинга собрать проще.
А еще есть третий вариант. Из описания создается ощущение, что у вас один тип тикетов с кучей терминальных состояний, чаще логичнее и удобнее сделать несколько типов тикетов (баг, фича, дизайн, ресерч...) и тогда окажется, что у каждого из них по два терминальных состояния fixed/not fixed. А то и вообще одно бывает, например у ресерча.
Здравствуйте, genre, Вы писали:
G>Задай сначала себе вопрос, а зачем надо различать эти статусы.
Странный вопрос. Зачем вообще придуманы системы отслеживания дефектов и управления задачами? Ты смог бы работать в команде на 10 человек без багтрекера? В моём случае цели следующие:
а) Не забыть о задачах, которые нужно сделать (если задачи ставятся через e-mail, это проще простого)
б) Приоритезировать множество задач, которые ставятся в разное время разными людьми
в) Обеспечить прохождение любой задачей всех нужных этапов — утверждения, уточнения, тестирования, выкладки — а не только разработки (всем известны ситуации, когда на production server выкладываются непротестированные изменения или давно готовые вещи не деплоятся месяцами, т.к. о них забыли — всё из-за бардака в управлении задачами)
г) Дать менеджеру проекта/ведущему разрабочтику инструмент распределения задач между разарботчиками
д) Минимально затратный способ дать заказчику/постановщику задачи способ узнать о её готовности задачи
е) Дать разработчику и тестировщику эффективный инструмент взаимодействия (очевидно, что багтрекер эффективней "испорченного телефона" устного общения или электронки)
ж) Дать менеджменту инструмент, показывающий степень готовности проекта к релизу: процент, число и состав реализованных фич, процент исправленных багов, процент неисправленных багов, критичность неисправленных багов, скорость разработки и и т. д. и т.п.
G>А если собирать какую-то статистику и как-то анализировать, то сначала стоит понять какую статистику и как анализировать и потом выбрать тот путь который позволить эту статистику на этой конкретной системе баг-трекинга собрать проще.
Спасибо, Капитан Очевидность.
G>А еще есть третий вариант. Из описания создается ощущение, что у вас один тип тикетов с кучей терминальных состояний
Это неверное ощущение. Разделение на трекеры/категории (в терминологии Redmine/FogBugz) нами используется.
G>чаще логичнее и удобнее сделать несколько типов тикетов (баг, фича, дизайн, ресерч...) и тогда окажется, что у каждого из них по два терминальных состояния fixed/not fixed.
Здравствуйте, Eye of Hell, Вы писали:
EOH>Все это, естественно, мое ИМХО и я могу ошибаться. С интересом выслушаю контраргументы .
Задача: не допустить выкладки на боевой сервер изменений, не прошедших тестирование (или, допустим, SEO-оптимизацию).
В случае традиционного workflow на основе статустов это обеспечивается невозможностью перевести тикет из "in progress" или "resolved" сразу в "closed".
В случае предлагаемого workflow на основе подзадач это обеспечивавается невозможностью закрыть тикет, у которого есть открытые подзадачи.
Чем обеспечивается создание подзадач на тестировние, SEO-оптимизацию и другие этапы работы? В какой момент и кем будут создаваться такие подзадачи?
И>Чем обеспечивается создание подзадач на тестировние, SEO-оптимизацию и другие этапы работы? В какой момент и кем будут создаваться такие подзадачи?
Автоматически либо скриптами. В успешных системах, которые я видел, в системы контроля задач (jira, trac, redmine) добавляли пользовательские кнопки, специфичные для процессов, принятых в данных компаниях. Тоесть человек смотрит тикет, и у него под тикетом две кнопки — "отправить на доработку" и "отправить на тестирование". Нажатие на эту кнопку выставляет нужные статусы, создает если нужно подзадачи, модифицирует их, убивает и так далее.
По моему опыту могу сказать, что морда системы, обращенная к большинству пользователей, должна быть максимально простой. Внимательно наблюдал как пытались в крупных компаниях допиливать системы до того, что вы хотите — куча состояний, статусов и правил перехода между ними. В результате это приводило к тому, что народ тривиально не могу все это запомнить, инструкций становилось слишком много, и в результате затея тихо саботировалась. Если же выполнение энфорсили сверху — то просто падала производительность. Сильно.
Именно поэтому, на мой взгляд, большинство представленных сейчас на рынке систем не поддерживают особо хорошо миллионы статусов, состояний и транзакий — принято считать, что best practice — это использовать задачи как строительные блоки, а поверх них для сложных процессов делать свои, специфичные для компании кнопки. По крайней мере это то, что я видел, что советовали консультанты Jira, и что хоть как-то работало. Остальные варианты работали в диапазоне от "плохо" до "никак".
EOH>Нажатие на эту кнопку выставляет нужные статусы
ОК, это стандартный функционал.
EOH>создает если нужно подзадачи, модифицирует их, убивает и так далее.
А вот такое допиливание системы уже требует весьма и всеьма существенных реусурсов (на чём там Redmine написан, на Ruby? у нас ни одного разработчика под Ruby никогда не было)
EOH>По моему опыту могу сказать, что морда системы, обращенная к большинству пользователей, должна быть максимально простой. Внимательно наблюдал как пытались в крупных компаниях допиливать системы до того, что вы хотите — куча состояний, статусов и правил перехода между ними.
Мне представляется, предлагаемое Вами допиливание скриптов для автоматического создания подзадач, их модификации и т.д. требует едва ли не больших усилий.
Кстати, сразу вопрос — что должно меняться в тикете после того, как пользователь нажал "отправить на тестирование" и у тикета создалась подзадача "протестировать"? Исходя из того, что задача должна закрываться не раньше, чем закрыты все её подзадачи.
EOH>В результате это приводило к тому, что народ тривиально не могу все это запомнить, инструкций становилось слишком много, и в результате затея тихо саботировалась.
Настройка не никаких инструкций и запоманания. Она предполагает разные права у разных ролей. И захочешь криво сделать — не сможешь. Если брать категории bug и feature: разработчик может перевести in progress только в resolved; тестировщик может перевести resolved только в verified, а с in progress вообще ничего сделать не может. Энд-юзеры вообще не видят большинства полей тикета, не говоря уже о смене статуса. Возможно, здесь есть подводные камни, но я их не вижу.
Здравствуйте, Илья., Вы писали:
G>>Задай сначала себе вопрос, а зачем надо различать эти статусы. И>Странный вопрос. Зачем вообще придуманы системы отслеживания дефектов и управления задачами? Ты смог бы работать в команде на 10 человек без багтрекера? В моём случае цели следующие:
Не, я спросил другое. Не зачем придуманы баг-трекеры, а зачем вам нужно различать столько терминальных статусов.
G>>А если собирать какую-то статистику и как-то анализировать, то сначала стоит понять какую статистику и как анализировать и потом выбрать тот путь который позволить эту статистику на этой конкретной системе баг-трекинга собрать проще.
И>Спасибо, Капитан Очевидность.
не за что. это был как-бы намек, что если ты хочешь получить более полезный ответ, то может стоит рассказать какую статистику ты хочешь получить? Хотя бы вкратце.
G>>чаще логичнее и удобнее сделать несколько типов тикетов (баг, фича, дизайн, ресерч...) и тогда окажется, что у каждого из них по два терминальных состояния fixed/not fixed. И>Неверно.
Может и неверно, но в моей практике ни разу не требовалась никакая другая информация для анализа кроме пофикшено/не пофикшено.
И>Мне представляется, предлагаемое Вами допиливание скриптов для автоматического создания подзадач, их модификации и т.д. требует едва ли не больших усилий.
В целом да. Сложные процессы требуют неких усилий для автоматизации. Это суровая мя жизни .
И>Кстати, сразу вопрос — что должно меняться в тикете после того, как пользователь нажал "отправить на тестирование" и у тикета создалась подзадача "протестировать"? Исходя из того, что задача должна закрываться не раньше, чем закрыты все её подзадачи.
Да ничего — у него появляется подзадача, назначенная на отдел тестирования. Соответственно, если я правильно понимаю ваш процесс, то большая задача может быть закрыта только если у него есть закрытая подзадача, назначенная на отдел тестирования. В состоянии Resolved->Fixed (или Resolved/Tested, если менять названия в workflow по умолчанию).
И>Настройка не никаких инструкций и запоманания. Она предполагает разные права у разных ролей. И захочешь криво сделать — не сможешь. Если брать категории bug и feature: разработчик может перевести in progress только в resolved; тестировщик может перевести resolved только в verified, а с in progress вообще ничего сделать не может. Энд-юзеры вообще не видят большинства полей тикета, не говоря уже о смене статуса. Возможно, здесь есть подводные камни, но я их не вижу.
Как уже писалось выше, я не могу сравнить ваши два подхода, так как ваша задача, по моему мнению, чуток выходит за их рамки. Я делаю так, как написал в своей статье — Status: Resolved, Resolution: Fixed/Wontfix/Incomplete итд. Делаю так потому, что это дефолтный, описанный во всех книгах и рекомендованный авторами Jira подход для простых случаев. Но у меня лично — команда маленькая, менье десяти человек. Процессы простые. А у вас, на мой взгляд, оно посложнее будет.
Здравствуйте, genre, Вы писали:
G>не за что. это был как-бы намек, что если ты хочешь получить более полезный ответ, то может стоит рассказать какую статистику ты хочешь получить? Хотя бы вкратце.
Почему ты считаешь, что сбор статистики — моя первочередная задача? Это не так. Cбор статистики — побочная задача. Основаная — вот:
>Обеспечить прохождение любой задачей всех нужных этапов — утверждения, уточнения, тестирования, выкладки — а не только разработки (всем известны ситуации, когда на production server выкладываются непротестированные изменения или давно готовые вещи не деплоятся месяцами, т.к. о них забыли — всё из-за бардака в управлении задачами)
G>Может и неверно, но в моей практике ни разу не требовалась никакая другая информация для анализа кроме пофикшено/не пофикшено.
Здравствуйте, Ilya_D., Вы писали:
I_D>На практике используется и тот, и другой способ. Какой из них в вашей практике оказался более подходящим и почему?
В трекере JIRA есть встроенное поле, обозначающее способ и факт закрытия задачи, называется "Resolution". Если оно не пусто, и там хоть что-то написано, то задача закрыта. Статусы тоже есть, и обычно, в workflow JIRA обходятся одним статуcом, обозначающим, что задача закрыта.
Это — удобно. И JIRA — самый популярный в мире трекер, из тех, за которые люди готовы платить деньги. Делай выводы.
Здравствуйте, Ilya_D., Вы писали:
I_D>На практике используется и тот, и другой способ. Какой из них в вашей практике оказался более подходящим и почему?
Со времен багзиллы status и resulution это отдельные вещи. Статус определяет какая роль отвечает за баг, а resolution определяет что с багом нужно сделать (было сделано). Разумеется можно обойтись одними статусами, но их придется наплодить кучу и workflow получится переусложненным.
.
