Pull to refresh

Comments 32

в ходе регистрации которых в JIRA вновь уточняются приоритет и сроки реализации требований

Вот этот момен и является ключевым — кто и на основе какой методики указывает сроки. Чтобы сроки не срывать — их нужно правильно вычислить. Но кто это сможет сделать?

1. Если переложить на разработчика, то нарушается принцип интересов. Начинающий не понимает, что детали не видны издалека и поставит мало времени — потом его же будут наказывать за медленную работу (а работа может быть не медленной — просто нет навыков планирования). Если разработчик опытный — то ему не выгодно быть врагом себе и он выставит срок с большим запасом, понимая что многие детали проявятся в процессе работы.

Пример. Задача объективно решается день. Один оценил ее в 2 дня и выполнил за полтора дня — молодец. Второй оценил в 4 часа и выполнил за день. Кто из двух работал лучше? И какая методика проверки?

В теории можно дать одну и ту же задачу двум разработчикам и посмотреть кто выполнит быстрее. Но! Кроме скорости выполнения есть еще и качество — кто будет его оценивать?

2. Если оценивают не разработчики — то по какой методике? Метод функциональных точек? Что еще? Как оценить, не понимая деталей работы?
Вы правы, оценка сроков — ключевой момент. На мой взгляд лучше всего описал пути решения этой проблемы Стив Макконнелл в книжке «Сколько стоит программный проект» — не хотелось бы его пересказывать. Как эти рекомендации используются нами на практике (с учетом статистики накапливаемой в JIRA) — предполагается раскрыть в следующей статье.

Вот бы о моём сне кто-то так же заботился По факту вы добились ожидаемого результата за счет внедрения уточнения требований, что-то среднее между анализом по PMBoK и грумингом историй. Прямо вплотную подошли к test driven development вот тут: "В идеале, задачи на тестирование должны быть сформированы до регистрации задач на разработку", а это прямой путь к заветной разработке без багов. Не хотите ли заняться шмерцингом информации у нас в Монровии?

Многие считают что PMBoK можно применить в компании в чистом виде (забывая об уровнях зрелости управления, до которых еще надо дорасти). С другой стороны, несмотря на все плюсы пользовательских историй — это тоже не вариант для стратегии документирования требований на госпроектах. Подход описанный в статье — это скорее рассказ об опыте перехода на первый уровень CMM. Поскольку не знаю монровийского, не могу прокомментировать слова «груминг» и «шмерцинг»…
:-) Виноват, не «Монровия», а «Моровия». Это из классического труда Тома де Марко по управлению проектами «Deadline», где разбираются и вопросы, затронутые Вами в статье (замечу, просто отличной) и ряд нескольких других. Если ещё не читали эту книгу — очень рекомендую, написано хорошо, переведено тоже неплохо и без административной ерундистики.
Что касается груминга — он довольно подробно описан как на Хабре, так и в документах по agile, раньше назывался backlog grooming, сейчас backlog refinement и это один из основных артефактов, который очень полезен и тогда, когда наш agile совсем не agile.

Я за 10 лет работы ПМ ни разу не видел компании, где бы PMBoK был в чистом виде, но ряд банков был очень близок. В этом нет ничего плохого, главное, что это работало. Как, наверное, и с любой методологией.
«Роман об управлении проектами» уже давно лежит в моей папке книг для обязательного прочтения. Спасибо за напоминание — надо обязательно прочитать. Что касается backlog grooming — предпочитаю называть простые вещи по русски… Например «еженедельное совещание проектной команды». А то порой после общения с особо «продвинутыми» заказчиками трудно понять «олд бич» — это разновидность кнута или регулярная напасть или пляж или совсем что-то другое… :))
Однако наше еженедельное совещание, как правило, не имеет цели обсуждения пользовательских историй. Так же список требований в нашем проекте — это не список пользовательских историй. Наш список требований выстраивается на основе требований ТЗ, замечаний протоколов испытаний и показов, зарегистрированных инцидентов. Обсуждение требований с ответственными разработчиками в рамках предложенной концепции строится по другому — на основе согласования ими проектных решений с использованием механизма подзадач.

В данном случае гораздо интереснее механизмы повышения вовлечённости. Разрабы, как правило, очень не любят в документирование.

Один из механизмов вовлечения программистов — это то что при описанном подходе от них фактически не требуется документирования (окромя краткого отчета по задаче (1-2 предложения) + несколько скриншетов (при необходимости) — с учетом что на программиста в день падает не более 3 задач — время по их отчетности занимает не более 3 минут). В настоящее время мы планируем перенести этот опыт еще на два проекта, поэтому я пишу вторую статью (фактически как неформальный регламент для новых адептов). В ней я постараюсь раскрыть основные особенности организации всего этого процесса по каждому виду задач (и в числе прочего — детально будет описано что требуется от исполнителей в части документирования).
В дальнейшем, ответственный исполнитель формирует все необходимые задачи (на анализ, разработку и тестирование), связанные с данным требованием, назначает для них исполнителей (по согласованию с руководителем проекта) и осуществляет контроль выполнения этих задач.


А можно поподробнее, почему нельзя было использовать подзадачи Jira — ну т.е. создать задачу, а в ней подзадачи «анализ», «разработка», «тестирование»?
Прежде всего это связано с тем, что в большинстве случаев задачи исполнителям назначаются в интересах решения нескольких требований. Например, задача типа «анализ» как правило формируется на несколько взаимосвязанных требований. Задачи по программированию так же могут выполнятся в интересах реализации нескольких требований (например несколько требований по безопасности решаются одним программным модулем). В рамках одного тестового задания могут проверятся несколько требований заказчика (и возможно несколько программных доработок). Подзадача JIRA всегда связана только с одной задачей и поэтому в рамках данного подхода ее предлагается использовать только в качестве вспомогательного инструмента.
Понятно. А как все вместе выглядит в UI Jira, можно глянуть пару скриншотов? Например, задачи, которые соответствуют картинке, как выглядит их список(?), как они связываются между собой? В Jira не работал, поэтому трудно представить.
image
Об этом повествует раздел «Канбан-доска наизнанку». Там как раз и написано, что среди многочисленных плагинов JIRA для решения задачи процессного управления проектом мы не нашли подходящий плагин. Наиболее близкий по идеологии из найденных плагин Dependency Map for Jira (скриншеты смотрите по ссылке), однако он тоже нам не понравился. После чего мы сделали собственный дашборд на основе данных сбор которых обеспечила JIRA (скриншет смотрите в статье).
С дашборд (как он выглядит) все понятно, хорошо задумано. Вопрос в следущем — требования и задачи прямо в этом дашбоард создаются?
Требования создаются с использованием стандартных инструментов JIRA. Дашборд обеспечивает мониторинг и навигацию по проекту.
Я правильно понимаю, что все задачи и требования находятся в Jira в одном списке? Т.е. создаем в Jira требования, потом там же создаем задачи на анализ, документацию и проч., связываем все это, далее переходим в дашборд «Канбан-доска наизнанку»?
Подзадачи в Jira плохо планируются, у них нет понятия спринта отдельно от задачи. Вообще подзадачи в Jira это только если ты хочешь что-то очень мелко разбить в рамках одного-двух дней
Подскажите, используется ли какая-то система уведомлений по взаимосвязанным задачам? Как происходит передача задачи в разработку, а затем в тестирование?
Задача на разработку создаётся ответственным за требования после того, как завершён анализ. А как тестировщик узнаёт, что разработка задачи завершена и он может приступать к работе по своей задаче тестирования?
В настоящее время за этим следит аналитик ответственный за реализацию требования. Поскольку он является автором всех задач на разработку то JIRА посылает ему уведомления при изменении статуса этих задач, после чего он должен принять решение о передаче задачи на тестирование или наоборот, об откате задачи на разработку после тестирования. В реальности ответственный аналитик регулярно просматривает описанный дашборд. Для фильтрации требований по разным критериям сделан соответствующий фильтр (можно отфильтровать требования по которым выполнены все задачи на разработку а задачи на тестирование — не назначены). Кроме того этот же дашборд служит выявления задач разработки, тестирования и документирования в статусе ожидание (желтые пятна на дашборде). Если такие пятна появились в отношении перечисленных задач — это внутренние проблемы на проекте — их надо срочно разруливать. Некоторые положения описанные в данной статье уже претерпели изменения (например, добавлен еще один — начальный- статус задач «оценка»). В ближайшее время предполагается в рамках серии статей опубликовать подробное описание всех процессов связанных с предложенным подходом с учетом высказанных замечаний и пожеланий (не только на habr), так что задавайте больше вопросов.
Понятно, спасибо!
Вопросы:
  • как фиксируются (передаются разработчикам) найденные ошибки при тестировании?
  • выполненные требования внедряются по отдельности (по своим задачам внедрения) или выпускается общая версия?
1. в случае ошибки:
1.1. задача на тестирование переводится в статус «ожидание» по причине «ожидание решения связанных задач/подзадач», при переходе к тестовому заданию прикладывается протокол выявленных ошибок, логов и т.п.
1.2. если это действительно ошибка соответствующая задача на разработку откатывается в статус «запланирована» (переход № 8) резолюция — «возвращена»,
1.3. если при тестировании выявлено что задача на разработку выполнена корректно, но в ней не учтено требования тестового задания (например в тестовом задании сказано что надо отсортировать список, а функция сортировки не была затребована в задаче на разработку) — создается новая задача на разработку связанная с соответствующим требованием и тестовым заданием.
В настоящее время прорабатывается вопрос использования плагина Automation for Jira для перевода задачи типа «тестирование» в статус «запланировано» в случае когда все связанные с ней задачи на разработку переведены в статус «выполнено».

2. Для внедрения создается задача соответствующего типа. С ней связываются требования которые надо внедрить в рамках этой задачи. В случае устранения ошибки — тип внедрения — «патч» (внедрение одного требования по базовому сопровождению), в другом случае это может быть «релиз» — внедрение пакета требований.

Подробней — в последующих статьях.

Приветствую!@aimfirst, уточните, пожалуйста, как ваши разработчики определяют какую задачу надо брать в работу? По канбану (верхний таск)? Как боретесь с тем, что берут в работу не то что сверху? Не думали-ли вы над тем, чтобы в Jira сделать кнопку, которая будет "выдавать и сразу запускать" таск в работу? Чтобы разработчик не терял время на выбор таски и у него небыло соблазна взять таск "что по легче".

Все идет от требований. Вся система разбита на подсистемы, на каждую подсистему назначен ответственный аналитик. В зависимости от того к какой подсистеме относится входящее требование, ответственный аналитик берет на себя руководство реализацией требования и отвечает за его реализацию вплоть до сдачи заказчику. Аналитик в числе прочего отвечает за своевременное назначение задач на разработчика и контроль своевременности выполнения. В случае назначения нескольких задач на разработчика он сам определяет какую задачу он будет делать сегодня. Последовательность выполнения выбирает сам исполнитель. Однако, на проекте согласованы наиболее общие правила определения приоритета задач. Каждый сотрудник знает что инциденты надо решать в первую очередь, но при наличии других задач нельзя тратить на них более 50% рабочего времени (если не было других указаний). Задача которая выполняется в интересах нескольких требований имеет приоритет над задачей в интересах меньшего числа требований. Кроме того, сделан еще один дашборд который позволяет осуществлять балансировку задач сотрудника в зависимости от требуемых сроков, изменения приоритетов задач и привлечения разработчиков для выполнения задач в интересах разных аналитиков/проектов (планирую подробно описать этот дашборд в одной из следующих статей - честно говоря хочется попробовать сделать плагин для JIRA, а потом писать статью). С помощью этого дашборда так же осуществляется контроль того, чтобы сотрудник не был загружен задачами более чем на 80%. В случае возникновения конфликтов - в расстановку приоритетов включается РП.

Т.е. ваши аналитики, кроме анализа и тестирования, решают когда и какому исполнителю выполнять таски?

Когда - решает исполнитель. А вот к какому сроку - аналитик (при необходимости согласовывает с РП). Аналитик планирует и регистрирует в JIRA всю цепочку задач по реализации требования, определяет плановую трудоемкость, затем согласовывает сроки в зависимости от загрузки привлекаемых исполнителей. После этого задачи передаются в работу. Последовательность выполнения задач определяет определяет ответственный исполнитель. Главное - успеть к сроку.

Интересная система, не бесспорная, но явно хорошо работающая в рамках ваших ограничений. Спасибо за статью!

Два года назад, когда я писал эту статью по этой схеме перешла работать одна проектная группа. Сегодня по этой схеме работает уже шесть проектных групп. За это время в рамках этого подхода родилось еще несколько дополнительных дашбордов позволяющих:
-  оценить текущую степень выполнения пула задач по реализации выбранного пула требований (с учетом неопределенности их выполнения);
-  планировать работы с учетом привлечения сотрудников на нескольких проектах с превентивным отображением рисков срыва задач по 5 различным критериям;
-  формировать план работ по выбранному пулу требований с расчетом трудоемкости и стоимости этих работ (с учетом тарифных ставок);
-  формировать аналитический отчет по выполненным работам по отдельному сотруднику с учетом финансовой эффективности (в т.ч. позволяющий оценить насколько сотрудник соответствует занимаемой должности).
Надеюсь найти время, чтобы рассказать об этих наработках в ближайших статьях.

Спасибо за статью, а подскажите, вы пользуетесь серверной JIRA или облачной? Не уверен, что на облачной JIRA можно свои плагины для дашбордов делать.

На облачной JIRA можно делать свои плагины. Как это делать описано на сайте Atlasian. Другое дело, для того чтобы такой плагин выставить на маркетплейс для всеобщего использования, надо вложить в 10 раз больше усилий, чем чтобы этот плагин написать. Мы пользуемся серверной JIRA в базовой версии и я не пишу плагины. Я просто пишу свои нехитрые инструменты для оперативного управления проектом, которые подключаются напрямую к БД JIRA. Описание БД JIRA тоже можно найти на сайте Atlasian.

А почему так категорично про госконтракты?

В моём опыте есть несколько примеров абсолютно аналогичных проблем в контрактах с крупными коммерческими компаниями.

Это наводит на мысль, что описанные проблемы связаны скорее с большим количеством заинтересованных лиц.

Полностью согласен. Просто в статье отражен личный опыт. Однако общение с коллегами, и не только в нашей стране, показало, что все эти проблемы возникают на крупных проектах с большим количеством стекхолдеров.

Sign up to leave a comment.