Comments 32
в ходе регистрации которых в JIRA вновь уточняются приоритет и сроки реализации требований
Вот этот момен и является ключевым — кто и на основе какой методики указывает сроки. Чтобы сроки не срывать — их нужно правильно вычислить. Но кто это сможет сделать?
1. Если переложить на разработчика, то нарушается принцип интересов. Начинающий не понимает, что детали не видны издалека и поставит мало времени — потом его же будут наказывать за медленную работу (а работа может быть не медленной — просто нет навыков планирования). Если разработчик опытный — то ему не выгодно быть врагом себе и он выставит срок с большим запасом, понимая что многие детали проявятся в процессе работы.
Пример. Задача объективно решается день. Один оценил ее в 2 дня и выполнил за полтора дня — молодец. Второй оценил в 4 часа и выполнил за день. Кто из двух работал лучше? И какая методика проверки?
В теории можно дать одну и ту же задачу двум разработчикам и посмотреть кто выполнит быстрее. Но! Кроме скорости выполнения есть еще и качество — кто будет его оценивать?
2. Если оценивают не разработчики — то по какой методике? Метод функциональных точек? Что еще? Как оценить, не понимая деталей работы?
Вот бы о моём сне кто-то так же заботился По факту вы добились ожидаемого результата за счет внедрения уточнения требований, что-то среднее между анализом по PMBoK и грумингом историй. Прямо вплотную подошли к test driven development вот тут: "В идеале, задачи на тестирование должны быть сформированы до регистрации задач на разработку", а это прямой путь к заветной разработке без багов. Не хотите ли заняться шмерцингом информации у нас в Монровии?
Что касается груминга — он довольно подробно описан как на Хабре, так и в документах по agile, раньше назывался backlog grooming, сейчас backlog refinement и это один из основных артефактов, который очень полезен и тогда, когда наш agile совсем не agile.
Я за 10 лет работы ПМ ни разу не видел компании, где бы PMBoK был в чистом виде, но ряд банков был очень близок. В этом нет ничего плохого, главное, что это работало. Как, наверное, и с любой методологией.
Однако наше еженедельное совещание, как правило, не имеет цели обсуждения пользовательских историй. Так же список требований в нашем проекте — это не список пользовательских историй. Наш список требований выстраивается на основе требований ТЗ, замечаний протоколов испытаний и показов, зарегистрированных инцидентов. Обсуждение требований с ответственными разработчиками в рамках предложенной концепции строится по другому — на основе согласования ими проектных решений с использованием механизма подзадач.
В данном случае гораздо интереснее механизмы повышения вовлечённости. Разрабы, как правило, очень не любят в документирование.
В дальнейшем, ответственный исполнитель формирует все необходимые задачи (на анализ, разработку и тестирование), связанные с данным требованием, назначает для них исполнителей (по согласованию с руководителем проекта) и осуществляет контроль выполнения этих задач.
А можно поподробнее, почему нельзя было использовать подзадачи Jira — ну т.е. создать задачу, а в ней подзадачи «анализ», «разработка», «тестирование»?
Задача на разработку создаётся ответственным за требования после того, как завершён анализ. А как тестировщик узнаёт, что разработка задачи завершена и он может приступать к работе по своей задаче тестирования?
Вопросы:
- как фиксируются (передаются разработчикам) найденные ошибки при тестировании?
- выполненные требования внедряются по отдельности (по своим задачам внедрения) или выпускается общая версия?
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.
А почему так категорично про госконтракты?
В моём опыте есть несколько примеров абсолютно аналогичных проблем в контрактах с крупными коммерческими компаниями.
Это наводит на мысль, что описанные проблемы связаны скорее с большим количеством заинтересованных лиц.
Полностью согласен. Просто в статье отражен личный опыт. Однако общение с коллегами, и не только в нашей стране, показало, что все эти проблемы возникают на крупных проектах с большим количеством стекхолдеров.
JIRA как средство от бессонницы и нервных срывов