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

Кто-нибудь имеет опыт использования программного обеспечения для отслеживания ошибок / отслеживания проблем, такого как bugzilla, mantis или JIRA, не только для ошибок или задач, но и для инициирования и ведения обсуждений, которые в конечном итоге приводят к решению?

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

Другие разработчики могут оставить свои комментарии, если они захотят, и, в конце концов, проблема закрывается как «принятая» или «отклоненная».

Преимущества, которые я вижу в этом:

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

Недостатки:

• Сильный запах золотого молотка: программное обеспечение для отслеживания проблем обычно используется для отслеживания действий элементов
• Организационные накладные расходы могут быть непропорциональными: вместо небольшого неформального разговора нужно изложить свои идеи в письменной форме.

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

В нашей реализации Jira есть категория «Риск», поэтому мы используем Jira для отслеживания элементов, которые не могут быть выполнены, но в какой-то степени способны поставить под угрозу программное обеспечение. Обсуждение предмета отслеживается, и как только риск исчезает (или уменьшается), проблема закрывается. Пример, который вы привели, может легко перейти в категорию риска.

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

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

В начале я бы сказал, что это действительно отличная идея. Хотя мы не используем его точно в указанном порядке, имеет смысл использовать его для целей отслеживания. В нашем случае длинная ветка электронной почты - больше как форум / список рассылки.

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

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

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

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

3. Большинство решений должны быть действенными. Это может быть трудно избежать противоречий; но тот факт, что решения не являются действенными и только субъективными, означает, что существуют возможности для будущих (неправильных) интерпретаций.

4. Важно классифицировать уровень и объем решения. Самое главное, мы должны определить, обсуждаем ли мы конкретную проблему проектирования или конкретный аспект кода, аспект процессов или эти вопросы связаны с планированием проекта и отслеживанием? Очень часто, когда проблемы возникают из производственного кода - все они применимы, но мы должны уметь различать все различные аспекты и независимо, чтобы иметь возможность эффективно управлять этими решениями.

5. Иногда решения могут быть о том, используем ли мы определенные системы или роли и обязанности для отдельных лиц; Это может быть трудно поставить эти решения вместе с кодированием конкретных решений на форуме типа доски объявлений.

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

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

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

FogBugz это путь. Это платно. Новейшие функции делают внедрение гибкой методологии еще проще.

Более простой и бесплатный способ - Асана.

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