Поделитесь опытом: ведете-ли вы логирование рабочего времени сотрудников в JIRA? Если да — есть ли лайфхаки в этой области? Если нет — как планируются/учитываются трудоемкость/трудозатраты сотрудников проектной группы?
Спасибо за оценку. Объемность статьи выросла сама собой из-за стремления не забыть мелочи. Я использую эти статьи как неформальный регламент проектной команды. По мере написания статьи, я просто вставлял в нее ответы на вопросы, которые возникали у моих коллег по мере внедрения JIRA. В то же время, действия указанные в статье реализуются по необходимости, т.е. не носят обязательного характера. Поэтому ресурсы, для поддержания этой модели на практике не такие затратные, как может показаться на первый взгляд.
Если для Вас тут слишком много «водищи», вероятно у вас есть несколько вопросов на которые вы надеялись получить ответ? Или у вас успешно и давно применяется BPM?
Welcome, добавьте «мяса»)
1. в случае ошибки:
1.1. задача на тестирование переводится в статус «ожидание» по причине «ожидание решения связанных задач/подзадач», при переходе к тестовому заданию прикладывается протокол выявленных ошибок, логов и т.п.
1.2. если это действительно ошибка соответствующая задача на разработку откатывается в статус «запланирована» (переход № 8) резолюция — «возвращена»,
1.3. если при тестировании выявлено что задача на разработку выполнена корректно, но в ней не учтено требования тестового задания (например в тестовом задании сказано что надо отсортировать список, а функция сортировки не была затребована в задаче на разработку) — создается новая задача на разработку связанная с соответствующим требованием и тестовым заданием.
В настоящее время прорабатывается вопрос использования плагина Automation for Jira для перевода задачи типа «тестирование» в статус «запланировано» в случае когда все связанные с ней задачи на разработку переведены в статус «выполнено».
2. Для внедрения создается задача соответствующего типа. С ней связываются требования которые надо внедрить в рамках этой задачи. В случае устранения ошибки — тип внедрения — «патч» (внедрение одного требования по базовому сопровождению), в другом случае это может быть «релиз» — внедрение пакета требований.
В настоящее время за этим следит аналитик ответственный за реализацию требования. Поскольку он является автором всех задач на разработку то JIRА посылает ему уведомления при изменении статуса этих задач, после чего он должен принять решение о передаче задачи на тестирование или наоборот, об откате задачи на разработку после тестирования. В реальности ответственный аналитик регулярно просматривает описанный дашборд. Для фильтрации требований по разным критериям сделан соответствующий фильтр (можно отфильтровать требования по которым выполнены все задачи на разработку а задачи на тестирование — не назначены). Кроме того этот же дашборд служит выявления задач разработки, тестирования и документирования в статусе ожидание (желтые пятна на дашборде). Если такие пятна появились в отношении перечисленных задач — это внутренние проблемы на проекте — их надо срочно разруливать. Некоторые положения описанные в данной статье уже претерпели изменения (например, добавлен еще один — начальный- статус задач «оценка»). В ближайшее время предполагается в рамках серии статей опубликовать подробное описание всех процессов связанных с предложенным подходом с учетом высказанных замечаний и пожеланий (не только на habr), так что задавайте больше вопросов.
«Роман об управлении проектами» уже давно лежит в моей папке книг для обязательного прочтения. Спасибо за напоминание — надо обязательно прочитать. Что касается backlog grooming — предпочитаю называть простые вещи по русски… Например «еженедельное совещание проектной команды». А то порой после общения с особо «продвинутыми» заказчиками трудно понять «олд бич» — это разновидность кнута или регулярная напасть или пляж или совсем что-то другое… :))
Однако наше еженедельное совещание, как правило, не имеет цели обсуждения пользовательских историй. Так же список требований в нашем проекте — это не список пользовательских историй. Наш список требований выстраивается на основе требований ТЗ, замечаний протоколов испытаний и показов, зарегистрированных инцидентов. Обсуждение требований с ответственными разработчиками в рамках предложенной концепции строится по другому — на основе согласования ими проектных решений с использованием механизма подзадач.
Об этом повествует раздел «Канбан-доска наизнанку». Там как раз и написано, что среди многочисленных плагинов JIRA для решения задачи процессного управления проектом мы не нашли подходящий плагин. Наиболее близкий по идеологии из найденных плагин Dependency Map for Jira (скриншеты смотрите по ссылке), однако он тоже нам не понравился. После чего мы сделали собственный дашборд на основе данных сбор которых обеспечила JIRA (скриншет смотрите в статье).
Прежде всего это связано с тем, что в большинстве случаев задачи исполнителям назначаются в интересах решения нескольких требований. Например, задача типа «анализ» как правило формируется на несколько взаимосвязанных требований. Задачи по программированию так же могут выполнятся в интересах реализации нескольких требований (например несколько требований по безопасности решаются одним программным модулем). В рамках одного тестового задания могут проверятся несколько требований заказчика (и возможно несколько программных доработок). Подзадача JIRA всегда связана только с одной задачей и поэтому в рамках данного подхода ее предлагается использовать только в качестве вспомогательного инструмента.
Один из механизмов вовлечения программистов — это то что при описанном подходе от них фактически не требуется документирования (окромя краткого отчета по задаче (1-2 предложения) + несколько скриншетов (при необходимости) — с учетом что на программиста в день падает не более 3 задач — время по их отчетности занимает не более 3 минут). В настоящее время мы планируем перенести этот опыт еще на два проекта, поэтому я пишу вторую статью (фактически как неформальный регламент для новых адептов). В ней я постараюсь раскрыть основные особенности организации всего этого процесса по каждому виду задач (и в числе прочего — детально будет описано что требуется от исполнителей в части документирования).
Многие считают что PMBoK можно применить в компании в чистом виде (забывая об уровнях зрелости управления, до которых еще надо дорасти). С другой стороны, несмотря на все плюсы пользовательских историй — это тоже не вариант для стратегии документирования требований на госпроектах. Подход описанный в статье — это скорее рассказ об опыте перехода на первый уровень CMM. Поскольку не знаю монровийского, не могу прокомментировать слова «груминг» и «шмерцинг»…
Вы правы, оценка сроков — ключевой момент. На мой взгляд лучше всего описал пути решения этой проблемы Стив Макконнелл в книжке «Сколько стоит программный проект» — не хотелось бы его пересказывать. Как эти рекомендации используются нами на практике (с учетом статистики накапливаемой в JIRA) — предполагается раскрыть в следующей статье.
Welcome, добавьте «мяса»)
1.1. задача на тестирование переводится в статус «ожидание» по причине «ожидание решения связанных задач/подзадач», при переходе к тестовому заданию прикладывается протокол выявленных ошибок, логов и т.п.
1.2. если это действительно ошибка соответствующая задача на разработку откатывается в статус «запланирована» (переход № 8) резолюция — «возвращена»,
1.3. если при тестировании выявлено что задача на разработку выполнена корректно, но в ней не учтено требования тестового задания (например в тестовом задании сказано что надо отсортировать список, а функция сортировки не была затребована в задаче на разработку) — создается новая задача на разработку связанная с соответствующим требованием и тестовым заданием.
В настоящее время прорабатывается вопрос использования плагина Automation for Jira для перевода задачи типа «тестирование» в статус «запланировано» в случае когда все связанные с ней задачи на разработку переведены в статус «выполнено».
2. Для внедрения создается задача соответствующего типа. С ней связываются требования которые надо внедрить в рамках этой задачи. В случае устранения ошибки — тип внедрения — «патч» (внедрение одного требования по базовому сопровождению), в другом случае это может быть «релиз» — внедрение пакета требований.
Подробней — в последующих статьях.
Однако наше еженедельное совещание, как правило, не имеет цели обсуждения пользовательских историй. Так же список требований в нашем проекте — это не список пользовательских историй. Наш список требований выстраивается на основе требований ТЗ, замечаний протоколов испытаний и показов, зарегистрированных инцидентов. Обсуждение требований с ответственными разработчиками в рамках предложенной концепции строится по другому — на основе согласования ими проектных решений с использованием механизма подзадач.