Trello и Jira: сравнение с точки зрения разработчика

Опубликовано: 2022-03-11

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

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

Зачем использовать инструмент управления проектами?

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

Диаграмма Trello и Jira, иллюстрирующая причины использования инструмента управления проектами, описанного в разделах ниже.

Расцвет глобальных команд

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

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

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

Сотрудничество

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

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

Управление требованиями проекта

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

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

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

Память и эффективность времени

Самые бледные чернила надежнее самой мощной памяти. - Пословица

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

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

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

Фокус

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

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

Основные характеристики ФМТ

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

Джира

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

Диаграмма, показывающая спринты, эпики и проблемы, приоритеты и контент

Спринты

Есть три слова, которыми я могу описать большую часть своего опыта работы с Jira, и одно из них — спринт . Спринт — это период времени, в течение которого команда работает над достижением определенных целей, которые могут быть тесно связаны или нет. Он полностью гибкий. Спринты Jira обычно длятся неделю, что, на мой взгляд, является оптимальной продолжительностью.

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

Эпики и проблемы Jira

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

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

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

Задачи в Jira — это задачи, которые очень специфичны и не имеют подзадач. Когда что-то, что нужно сделать, очень простое и нет смысла пытаться разбить его на части, это задача. Ошибки — это то, что нужно исправлять — выделение ошибок в отдельную категорию поможет вам понять, насколько вы исправляете, а не насколько продвигаетесь в проекте.

Приоритеты

Коммуникация — важная часть уравнения при работе в глобальной команде, работающей в разных часовых поясах. Работа «вокруг земного шара» — это не метафора, а реальность, в которой живут многие разработчики. Одна из вещей, которую трудно донести до разработчиков, — это уровень приоритета задачи. Представьте себе следующий сценарий с использованием списка дел:

Разработчик видит, что за эту неделю ему нужно выполнить семь задач. Некоторые из них трудны, а некоторые легки. Одна важная задача для менеджера, тем не менее, очень сложна, но для разработчика в списке дел все задачи равны — он может выбрать сначала более простые, оставив критические на конец. Если происходит что-то непредвиденное, и список не завершается, это самая важная задача, которая сокращается или завершается в спешке (вероятно, жертвуя качеством в процессе). Это очень легко решается в Jira с помощью приоритетов , которые позволяют разработчикам понять, что более важно или критично для выполнения.

Контент, Контент, Контент

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

Плюсы и минусы Jira

Jira — очень хорошо зарекомендовавший себя инструмент с множеством функций, которые были включены специально для разработки программного обеспечения. Он предлагает множество интеграций с другими системами и помогает вам поддерживать порядок. Это особенно хорошо для (очень) больших команд.

Jira, будучи функциональной, многофункциональной PMT, может быть несколько сложной для начинающего разработчика. Опыт может быть ошеломляющим — спринты, эпики и задачи могут сочетаться друг с другом. Это особенно актуально, если менеджер — клиент с небольшим опытом разработки программного обеспечения, пытающийся управлять командой разработчиков. Я настоятельно рекомендую Jira для больших команд и больших проектов, разработка которых займет некоторое время (более пары месяцев), а также для опытных менеджеров (клиентов) и разработчиков.

Плюсы

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

Минусы

  • Имеет много функций, поэтому вы можете легко недооценивать программное обеспечение
  • Требуется некоторая подготовка, чтобы воспользоваться всеми его функциями
  • Требуется (или, по крайней мере, очень помогает) понимание гибкой разработки
  • Может быть излишним для небольшого проекта с небольшой командой

Трелло

Trello можно описать простой фразой: «доски с карточками», также известные как Канбан . На первый взгляд, это может быть даже слишком просто для неподготовленного глаза; однако простые вещи могут быть чрезвычайно полезными.

Схема Trello и ее основные функции

Простота — мощная концепция. Это одна из причин, почему iPhone и Mac стали такими популярными, поскольку их операционная система была простой и приятной в использовании. В то время как Jira чувствует, что у вас есть все, о чем вы только можете подумать, Trello чувствует, что у вас достаточно, чтобы помочь вам. Никаких эпиков, историй, спринтов — вы просто работаете с картой и перемещаете ее по разным этапам (столбцам).

Имея в виду, что все это существует и в Jira, я объясню несколько функций, которые больше всего выделяются в Trello.

Этапы

Trello упрощает определение этапов — просто создайте столбец и начните его использовать. Наиболее распространенными из них являются To Do, Doing, Review и Done. Из-за своей простоты вы можете добавить другие столбцы, такие как «В ожидании» (Jira тоже может это сделать, но кажется, что они потеряны, если вы не будете явно искать эти проблемы) или создать столбцы для разных частей системы, такие как Todo Front-end. или Todo Back-end. Это отлично, когда команда и проект небольшие, например, простой веб-сайт, виджет или расширение, где не так много участников или задач, которыми нужно управлять одновременно.

Члены

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

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

Очень наглядно

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

Визуальное представление представления канбан-доски Trello

Это то, чего нет у Jira (по крайней мере, я не видел, чтобы это использовалось в реальном проекте). Поскольку изображение может сказать больше, чем слова, вы можете легко увидеть, что происходит, не открывая каждый билет.

Кроме того, красочные теги Trello можно использовать для добавления дополнительной информации без необходимости разворачивать карточку. При хорошей организации эти канбан-эквиваленты этикеток Post-It могут оказаться очень полезными и избавят вас от множества ненужных кликов.

Информационная перегрузка

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

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

Геймификация

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

Каждый раз, когда билет перемещается с одного этапа на другой, происходит выброс адреналина (или дофамина). Поскольку вы не можете переместить карточку на другой этап, не перетащив ее в Trello (тогда как в Jira проще всего просто изменить статус задачи), вы получаете физическую связь с вашим прогрессом. В какой-то момент, даже не осознавая этого, вам хочется соревноваться с самим собой, чтобы решить больше задач в этот день, чем накануне (надеюсь, я не одинок здесь с этим чувством), или вам просто хочется бороться за то, чтобы сделать колонку задач. опорожнять как можно быстрее. Сегодня многие программные продукты используют геймификацию, чтобы увеличить вовлеченность, такую ​​как просмотры и лайки на большинстве социальных платформ — этот механизм вознаграждения за действие — это то, что удерживает людей на платформах.

Хорошее и плохое

Я до сих пор поражен тем, насколько радостным кажется использование Trello, и, конечно же, его простота имеет решающее значение для этого опыта. Задачи, как правило, меньше — хотя вы выполняете ту же работу, лучше переместить три задачи в столбец «На проверку», чем изменить статус одной истории Jira на «Готово». (Я чувствую, что коэффициент конверсии одной истории Jira равен примерно трем карточкам в Trello.)

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

Плюсы

  • Низкий порог входа — вам не нужен опыт
  • Простой интерфейс
  • Чрезвычайно наглядно — вы сразу понимаете идею
  • Идеально подходит для небольших проектов и небольших команд

Минусы

  • Неудобный UI/UX для добавления большого количества деталей к задаче.
  • Не так хорошо переводится на мобильные устройства, так как физически требуется больше места для отображения канбан-доски.
  • Не умеет (по крайней мере, интуитивно) расставлять приоритеты задач

Должен ли я использовать инструмент управления проектами?

Да, я думаю, что в сегодняшней типичной ситуации, когда менеджер или владелец бизнеса не может ответить на вопросы 24/7, вам действительно следует подумать об использовании инструмента просто как о способе иметь репозиторий, в котором записано все необходимое. четким образом. Это поможет вам избежать путаницы или пропущенных элементов, потому что они были забыты в разговоре по Skype или скрыты под сотнями электронных писем. Если ваш проект меньше, например сайт для хобби, PMT может оказаться излишним.

Какой из них я должен использовать?

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

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