Нет ошибок, просто TODO

  • Эта публикация - перевод статьи. Ее автор - Almad. Оригинал доступен по ссылке ниже:

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

Как и в случае с бухгалтерским эквивалентом, эти инструменты действительно полезны. В то время как мы коллективно научились избегать генеральных директоров MBA, которые управляют компанией только на основе бухгалтерских книг и не обращают внимания на основной бизнес. Я думаю, что мы не научились избегать менеджеров, которые управляют разработкой программного обеспечения только по билетам и игнорируют доставку основного программного обеспечения.

Отслеживание проблем стало индустрией, ее программное обеспечение обрело сознание и начало превращаться в социальную сеть, по-видимому, оптимизируя вовлеченность и время, проведенное в продукте, в противовес помощи в достижении цели. Это часто сочетается с людьми, чья безопасность работы связана с обеспечением того, чтобы проекты были достаточно сложными, чтобы потребовать от менеджера проекта [1] их выполнения, а объем получаемых в результате бумажной работы умопомрачает. Широкое признание этого состояния и привлекло внимание создателей Jira.

Я не могу опровергнуть существование разумно сконфигурированного и быстрого "Jira", но мне еще предстоит это испытать - и я очень старался. На одном из моих заданий мы подтолкнули Trello [2] к пределам, и в ответ ветераны корпорации сильно настаивали на Jira. Я был уверен, что теперь продукт - это совершенно другая вещь, которую я помню. Ну, через несколько месяцев (и некоторые хорошо оплачиваемые, тонко настроенные конфигурации) я увидел ту же пошаговую стратегию бухгалтерского учета, которую я помню.

Это не обвинение в каком-то конкретном продукте, а то, что люди от него просят.

Минимальный скелет

Я думаю, что для решения проблемы требуется относительно немного свойств и относительно мало правил, чтобы сделать обработку эффективной.

Владение

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

Это не «компонентный» атрибут, который мне страстно не нравится. Если «компоненты» создаются инженерами, они часто бывают произвольными, они не выдерживают рефакторинга и со временем могут привести к размыванию обязанностей. Если они созданы владельцами продукта, они соответствуют восприятию клиента и не обязательно внутренней структуре, и необходим уровень перевода. [3]

Назначить одному человеку [4]. Если вы не знаете, кто это, не должно быть владельца, и должен быть четко назначенный человек (мы использовали текущего агента по вызову), чтобы обработать их и назначить соответствующим образом.

Положение в очереди

Это самая важная вещь для проектной организации. Каждая команда должна иметь одну упорядоченную очередь задач . Много хаоса управления проектами возникает, когда у инженера есть несколько очередей на выбор.

Это происходит часто и в непрозрачной форме. Конечно, никто не намеренно разбрасывает задачи. Но на практике есть планирование, которое назначает заявки в приоритетных сегментах (например, высокий, средний, низкий) с нечеткой сортировкой внутри них. Затем приходит высокоприоритетный билет клиента. Затем происходит инцидент. И затем у нас есть внутренний баг-трекер, а также список проблем Github, и мы решили сделать оба сразу. Кроме того, я только что получил письмо от нашего маркетолога о опечатке на нашей странице. Этот абзац кажется запутанным? Именно!

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

Если процесс более сложный, должен быть алгоритм, с которым все должны согласиться. Примером может быть:

  1. Если есть время простоя, это приоритет всех
  2. Если есть инцидент, это главный приоритет для агента по вызову
  3. Моя развернутая проблема ожидает подтверждения
  4. Рассмотренный запрос на ожидание для развертывания
  5. Мой запрос на получение с завершенным обзором кода, который запросил изменения
  6. Выдающийся запрос на ожидание, ожидающий проверки кода
  7. Эскалация клиента получена по электронной почте. Для действительных, создайте инцидент и делегируйте по вызову. Для недействительных, ответьте, извинитесь и предоставьте ссылку поддержки клиентов
  8. Главная проблема в журналах спринта
  9. Любая проблема в очереди «когда у инженеров есть время»

Стейт

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

Я советую начинать с триады «Тодо», «Делать» и «Готово» и добавлять еще только в случае крайней необходимости. Перемещение проблем из одного состояния в другое должно быть связано с явным действием. Если вы добавляете больше состояний, убедитесь, что у вас есть четкое соглашение со всеми, что билет последней стадии имеет наивысший приоритет, если вы не хотите, чтобы все билеты застряли на самой скучной стадии, такой как «проверка».

Распределение задач

Каждый тикет с состоянием должен соответствовать одному развертыванию (которое невелико в среде непрерывной доставки). Если он больше, он должен быть разбит на дополнительный билет, и отношения между этими двумя должны быть записаны.

Анти-паттерны

Вот и все. Если вы действительно масштабируете, вам может понадобиться немного больше ... но меньше, чем вы думаете. Хотя следующие атрибуты являются общими, они определенно не должны.

Приоритет

Не существует абсолютного приоритета проблемы, только относительный приоритет других проблем . Как только вы начинаете определения приоритетов из списка, ничего другого , чем «Самый высокий» является пассивно-агрессивный [5] способов сказать «нет».

Если приоритет просто приписывается списку значений, он очень быстро становится наиболее злоупотребляемым полем. Рано или поздно вы также начнете добавлять дополнительные «по-настоящему высочайшие первоочередные» приоритеты, также известные как «генеральный директор называется».

Необходимо удержаться от соблазна.

Тип билета

Типом обычно является список, содержащий значения, такие как «Улучшение», «Ошибка», «Задача» и «Документация». Мой вопрос будет таким: почему вы хотите иметь эту информацию и для чего она будет использоваться?

Поле «Тип» привело к одному из самых непродуктивных обсуждений в моей жизни. Поговорка «это не ошибка, это особенность» означает, что я, вероятно, не одинок. Мы все вместе не должны заботиться. Когда люди кричат ​​«это ошибка», это не имеет значения, чем это вызвано. Это крик существенного несоответствия ожиданий. Команда должна работать над ее устранением, независимо от того, было ли это вызвано тем, что разработчик отклонился от заданного намерения или из-за первоначального намерения пошло не так.

Наиболее значимые толчки в этой области я испытал из:

  • Перфекционисты, которые любят медлить, сортируя вещи. Хотя я поддерживаю всех в увлечениях, жаль, что команда страдает из-за этого. Найдите способ договориться о полезности и помогите перфекционистам справиться с несовершенствами. Я рекомендую купить им портативный сад дзен, чтобы компенсировать это.
  • Менеджеры высшего уровня, которым нравятся круговые диаграммы. Это часто для сравнения качества команд путем сравнения количества дефектов, которые они создают. Остается только привязать к нему свои бонусы, и вы можете сделать «это особенность, а не ошибка», сказав гимн вашей официальной компании 6 . В менее нефункциональном и более обоснованном случае необходимо оценить «сколько усилий мы тратим на содержание, а не на разработку новых вещей», что я считаю допустимым в определенных обстоятельствах, но тогда «поддержание» и «новое» должны быть типами заявок ,
  • Клиенты. «Ошибка» означает «высокий приоритет» или «ваша ошибка, исправьте ее и даже не пытайтесь выставить нам счет».

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

Версия ПО

Отслеживание версии имеет смысл для поставляемых библиотек и локальных пакетов. Нет смысла в непрерывно поставляемых SaaS.

Для оценки того, имеет ли смысл отчет об ошибке, обычно достаточно отчетной даты.

Строгость

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

Рассмотрим опечатку в тексте на странице. Как вы справляетесь с этим, когда он находится в середине страницы? Когда это в основной призыв к действию на целевой странице? Когда это исправлено тривиально и когда требуется одобрение пяти человек и доступ к сторонней системе?

Обычно это дублирует приоритет.

Тип тикета

Самое сложное - это проблема гигиены. Сказать «нет» сложно, но без него система вопросов становится неуправляемым беспорядком. Система должна быть разработана таким образом, чтобы поощрять закрытие проблем агрессивно и легко. В конечном счете, это является привлекательным моментом для правления Kanban: цель состоит в том, чтобы иметь как можно меньше времени для того, чтобы проблема была открыта и чтобы стимулировать агрессивное сокращение очереди.

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

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

Есть один хороший аргумент в его пользу: программное обеспечение постоянно меняется и, следовательно, старые проблемы могут быть недействительными. Чтобы поместить их в спринт, их нужно проверить - в некоторых случаях это на самом деле больше работы, чем сама проблема.

Отказ - разумный ответ, чтобы иметь базу данных вместо трекера.

Отделение внутренней поддержки

Для того, чтобы это работало, должна быть отдельная система для обработки вопросов для команды разработчиков из остальной части компании [7].

Это очень важно для культуры общения. То, что я видел в качестве альтернативы, - это написать сообщение случайному инженеру или руководителю их команды, что приведет к злоупотреблениям. Важно сделать этот канал более отзывчивым и надежным, чем любой другой отдельный почтовый ящик.

Другой альтернативой является открытие плохо определенных билетов для разработки. Эта дорога ведет к болоту. Легко преодолеть способность команды сортировать все билеты, и в этот момент вся очередь будет проигнорирована, и вы получите Ticket Swamp на стероидах.

Спасибо Стивену Мизеллу за редактирование и отзывы.


  1. Для справки, я действительно когда-то работал с отличным менеджером проекта. Его определяющей чертой было понимание того, что он - масло, которое заставляет колеса вращаться, а не самое большое и самое важное колесо в центре. Это, конечно, сделало его одним из самых уважаемых коллег. У меня были проблемы, повторяя этот незабываемый опыт. На более серьезной ноте меня попросили подтвердить это и, конечно же, все, что я могу сделать, это неподтвержденные доказательства. И все же я верю, что на самом деле это свойство любой должности: люди редко хотят, чтобы их работа исчезла. В тот момент, когда вы создаете вакансию, она имеет тенденцию метастазировать. Создайте специальную позицию ниндзя $ технологии и наблюдайте 
  2. В основном это эквивалент доски для постов с вертикальными полосами 
  3. Они должны идеально совпадать, но они часто отклоняются в долгосрочной перспективе 
  4. Для более крупных команд это может быть учетная запись команды, но в этом случае ответственность за регулярный просмотр всех принадлежащих команде билетов и их делегирование лежит на руководителе команды 
  5. В американском английском это называется «вежливый» 
  6. Кажется абсурдом? Ну, я также видел, что «сюжетные линии абстрактны, специфичны для команды и несравнимы, поэтому давайте разместим таблицы выкатов всех команд на этом большом дисплее в коридоре, вы знаете, очевидно, только чтобы команды знали, как они стоя, никакой другой скрытой повестки дня не подразумевается »полностью ↩︎
  7. Даже создатели Jira признают эту необходимость, следовательно, Jira-SD