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

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

Ставьте под сомнение каждый процесс

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

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

Нанимайте талантливых людей

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

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

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

Отслеживайте работу в историях

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

Для менеджеров по продуктам

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

Дизайнерам

  • Предоставить инженерам активы, ресурсы, прототипы и проекты для использования во время реализации.

Для инженеров

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

Для всех членов команды

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

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

Как сделать так, чтобы куча работы передо мной не поглотила меня и не сожгла?

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

Перемещайте задачи по дорожкам для плавания

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

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

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

По сути, на всех досках задач должны быть плавательные дорожки для «To Do» (Задачи, которые необходимо выполнить), «In Progress» (Задачи, над которыми работают), » Протестируйте «(Задачи, готовые к тестированию)» и «Готово» (Задачи, готовые к выпуску).

Дайте дизайну возможность оставить отзыв

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

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

Обеспечение качества изнутри перед отправкой извне

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

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

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

Сюжетные точки преследуют две ключевые (но разные) цели:

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

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

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

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

Симптомы этой проблемы обычно проявляются, когда вы начинаете слышать, как люди спрашивают: «Когда это будет сделано?» Или «Как вы думаете, сколько времени это займет?» Или «Сколько у вас осталось времени на это?». Это означает, что ваша команда не достигла хорошей каденции или ритма работы. Это НЕ означает, что дизайнеры и инженеры недостаточно много работают, но эта работа не выполняется в постоянном темпе.

Скорость против темпа

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

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

Отдельные оценки заинтересованных сторон от оценок основной группы

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

Оцените, что лучше всего подходит вашей команде

Маленький Средний Большой. Последовательность Фибоначчи. Красный, зеленый, синий. Существует множество различных способов осмысления «сложности» задачи, которые не основываются на количестве времени, необходимом для выполнения.

Сложность. Не время.

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

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

Разрушайте сложные истории

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

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

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

Непрерывная интеграция - необходимость

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

В каждой команде, с которой я работал, где не было процесса CI или плохого процесса CI, возникают одни и те же основные проблемы.

Ежедневные сборки

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

Делайте стойки короткими

Каждый день посвящайте небольшое количество времени обсуждению того, над чем люди работают в той или иной форме. Слишком легко вдаваться в подробные обсуждения не относящихся к делу вопросов. Установите таймер и будьте суровы. Дайте каждому 30 секунд на то, чтобы заговорить, а затем переходите к следующему. Легкий. Просто сделай это. Двигаться дальше.

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

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

Будьте внимательны в отношении целей спринта

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

Стратегия вокруг командного рабочего процесса не имеет отношения к основной команде

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

Сделайте ретроспективы жестким требованием

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

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

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

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

У великих MVP нет кода

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

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

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

Вовлекайте инженеров в процесс проектирования

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

Agile - это не то, что можно подержать, потрогать или увидеть.

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

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

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

Agile - это не то, что можно подержать, потрогать или увидеть. Вы не Agile.

Спасибо за внимание, подробнее здесь: Twitter // Instagram // Blog

Http://www.phillfarrugia.com/2018/03/14/you-are-not-agile/

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

Следите за нашей публикацией, чтобы увидеть больше историй о продуктах и ​​дизайне, представленных командой Journal.