Руководство для начинающих по управлению разработкой программного обеспечения с помощью Kanban и Trello

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

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

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

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

Гибкое управление проектами — широко распространенный метод подхода к современным проектам разработки программного обеспечения. Но что на самом деле означает Agile?

Гибкие проекты принимают частые изменения масштабов и требований как неотъемлемую часть процесса.

Чтобы глубже погрузиться в принципы Agile, я предлагаю прочитать наше Полное руководство по Agile-управлению проектами.

В этом посте мы объясним основы гибкого управления проектами с помощью Канбана.

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

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

Канбан — это не процесс. Это способ управлять любым процессом с минимальными изменениями в установленных операционных действиях команды.

Чтобы применить принципы Канбана в своей работе, вы должны применять два простых правила:

Визуализируйте свой процесс.
Ограничьте незавершенную работу.

Визуализируйте свой процесс

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

Нейроны мозга для нашего зрительного восприятия составляют 30 процентов серого вещества мозга.

Канбан-доска – самый популярный способ визуализации процесса. Канбан-доска — это доска, разделенная по вертикали на несколько столбцов, где каждый столбец представляет одно состояние вашего процесса.

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

To-Do - функция ожидает разработки
Разработка - функция назначена разработчику, и он работает над ней
Обеспечение качества — функция находится на рассмотрении
Развернуто — функция принята и включена в выпуск приложения

Исходя из этого, ваша доска должна иметь следующий макет:

Доска Trello с четырьмя столбцами: «Дела», «Разработка», «Контроль качества» и «Развернуто».

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

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

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

Ограничение незавершенного производства (WIP)

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

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

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

Предполагая, что ваша команда разработчиков состоит из двух разработчиков и инженера по контролю качества, ваша доска может иметь следующие ограничения WIP:

Дела - Неограниченно
Разработка — ограничение в шесть карт (два разработчика, каждый ограничен максимум тремя задачами)
Обеспечение качества - ограничение в три карты (1 инженер по контролю качества ограничен максимум тремя картами)
Развернуто - не ограничено

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

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

Доска Trello похожа на первую, но со вторым столбцом, называемым WIP, и красной линией под названием «WIP LIMIT», нарисованной под третьей карточкой.

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

Используйте Trello для управления доской Канбан

Trello — это веб-приложение для управления проектами Kanban. Это обеспечивает простое сотрудничество в режиме реального времени между членами команды и даже между несколькими командами и проектами.

Чтобы создать доску в Trello, щелкните пункт меню «Создать новую доску…» и установите заголовок для своей доски.

Скриншот создания доски в Trello. Есть одно поле для названия доски.

Вы начнете с пустой доски. Используйте поле «Добавить список…», чтобы создать столбцы для ваших карт Канбан.

Скриншот добавления столбца задач в Trello. Заголовок нового столбца можно редактировать, а под ним есть кнопки «Сохранить» и «X».

Нажав «Добавить карту…» внизу любого из списков, вы легко создадите задачу. Каждая карточка, которую вы создаете, должна представлять задачу, которую будет выполнять член команды.

Карточки в Trello можно настроить разными способами:

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

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

Визуализация — это все в Канбане, поэтому вот как выглядит карточка на доске:

Скриншот предыдущей карты при просмотре на уровне доски Trello с теми же элементами, что и описанные ранее, но совпадающими с деталями более поздней карты.

Просто взглянув на карту, не открывая детальный вид, вы можете увидеть, что:

Задача по настройке репозитория кода GitHub ожидает выполнения в списке дел.
Задание нужно выполнить до 27 января.
У задачи есть описание.
Есть один комментарий к заданию.
Существует контрольный список из двух пунктов, и ни один из них в настоящее время не завершен.
Задача возлагается на пользователя DS, который и возьмется за нее дальше.
Задача относится к группе карт зеленого цвета, что означает, что она требуется перед началом проекта.

Оцените время и сложность разработки

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

Scrum, один из самых популярных принципов Agile, в значительной степени опирается на оценки, основанные на времени или «баллах сложности».

Команда должна потратить значительное время на определение масштаба задачи.

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

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

Команда не тратит время на оценку работы заранее. Разработчик выберет следующий элемент из To-Do; завершить его как можно скорее; и взять другую задачу.

Это не означает, что команда не должна оценивать объем своей рабочей нагрузки.

Вы можете использовать еженедельные или ежедневные звонки для обновления и проверки сроков выполнения.

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

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

Обязательные практики управления

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

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

Организуйте регулярное собрание команды.
Делайте это не реже одного раза в неделю, чтобы просмотреть, что было сделано, а также уточнить и расставить приоритеты в невыполненной работе (список дел), если это необходимо. Таким образом, вся команда будет получать обновления одновременно и делиться идеями. На этих встречах важно, чтобы заинтересованная сторона проекта (клиент, технический директор компании или кто-либо из команды разработчиков продукта, который может принять решение и ответить на вопросы), в конечном итоге предоставила не техническую обратную связь.
Обеспечьте постоянную связь с отдельными членами команды.
Это значительно облегчит повседневную работу каждого. Делайте эти встречи или встречи очень короткими и простыми, достаточно быстрого обновления в вашей любимой программе чата. Полезно проводить ежедневные проверки, которые могут составлять примерно 15-минутные ежедневные встречи с вашей командой. На этой встрече каждый член команды говорит в течение нескольких секунд, заявляя:

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

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

Загрузите свой проект разработки программного обеспечения

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

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

Одним из самых популярных сервисов для управления версиями кода является GitHub. GitHub — это веб-репозиторий Git или системы управления версиями, который предлагает все функции распределенного контроля версий и управления исходным кодом (SCM) Git.

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

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

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

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

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

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

Забрать

Управление проектами — сложная и слишком часто очень напряженная деятельность. Добавление к нему структуры и постоянное отображение статуса проекта и его точность значительно облегчают этот стресс. Использование метода Канбан и принципов Agile в сочетании с правильными инструментами сэкономит вам много времени.

При этом не существует инструмента или методологии, которые компенсировали бы время, которое вы, как менеджер проекта, должны посвятить управлению проектом.

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

Вот простой контрольный список, который поможет вам проверить, правильно ли управляется ваш проект:

Правильно ли визуализируется ваш процесс?
Ограничен ли и сведен к минимуму WIP для каждого члена команды?
Есть ли у вашей команды постоянные запланированные встречи — еженедельные или ежедневные?
Ваша канбан-доска регулярно обновляется?
У вас есть репозиторий кода?
Вы запланировали резервное копирование базы данных?
Настроили ли вы инструменты командного общения и совместной работы?
Отделена ли ваша среда разработки от тестирования, приемки и производства?

Имейте в виду, что этот список далеко не определен и не завершен; Это только начало.

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