Information

Founded
Location
Россия
Website
lanit.ru
Employees
over 10,000 employees
Registered
Pull to refresh
Comments 22
в ходе регистрации которых в 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. Для внедрения создается задача соответствующего типа. С ней связываются требования которые надо внедрить в рамках этой задачи. В случае устранения ошибки — тип внедрения — «патч» (внедрение одного требования по базовому сопровождению), в другом случае это может быть «релиз» — внедрение пакета требований.

Подробней — в последующих статьях.
Only those users with full accounts are able to leave comments. Log in, please.