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

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

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

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

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

Спайки, которые вошли в моду во время подъема гибкой разработки программного обеспечения (Бек был первым, кто подписал Манифест Agile), спустя два десятилетия все еще являются ценными инструментами для ответов на неоднозначные или затянувшиеся вопросы.

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

Что такое шип?

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

В Code With Engineering Playbook от Microsoft они классифицируют два основных типа всплесков: технические и функциональные.

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

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

Вы можете часто делать скачок до или в начале спринта. Шип состоит из четырех отдельных частей:

  • Вы знаете проблему. И оно мясистое.
  • Вы не знаете решения.
  • Вы исследуете, чтобы попытаться найти лучший подход.
  • Вы сообщаете о том, что нашли.

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

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

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

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

3 шага для создания эффективного спайка

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

1. Определите, на что вы хотите ответить

Относитесь к шипам как к научным экспериментам. Начните с четкой гипотезы.

«Создайте всплеск, чтобы решить только изучаемую проблему и игнорировать все другие проблемы», — объяснил Бек.

Хотя важно определить, почему вы делаете спайк, вам не нужны все ответы, прежде чем вы начнете процесс. В дискуссии на форуме Scrum.org о размерах пиков Даниэль Уилхайт, менеджер по разработке программного обеспечения в страховой компании Bright Health, подчеркнул важность того, чтобы не быть парализованным выбором.

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

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

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

Установка небольшого ограничения по времени — еще один способ внести ясность, — написал Фукуа. Мне нравится устанавливать для них четкую политику… никаких расплывчатых всплесков с расплывчатыми результатами.

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

3. Делайте заметки, чтобы задокументировать то, что вы обнаружите

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

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

Расскажите историю своего спайка через презентацию

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

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

Некоторые пики потребуют более тщательного обсуждения. Но как уместить 48 часов исследований в 20-минутную презентацию?

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

«Короткие сообщения с большей вероятностью будут интерпретированы целиком», — сказал Османи. «Не отклоняйтесь от основной мысли сообщения».

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

  • Кратко переформулируйте проблему, которую вы рассмотрели. Вот почему ты сделал шип. Установите ожидания относительно того, что вы будете освещать в своей презентации, чтобы ваша команда сосредоточилась на задаче. Это также помогает вам сохранять концентрацию, подобно началу спайка.
  • Объясните, как вы пришли к такому выводу. Впустите всех в момент вашего открытия первым. Покажите, как данная часть программного обеспечения или функция могут решить проблему. Затем вернитесь к началу и конкретизируйте потенциальные преимущества или причины, по которым вы остановились на данном стремлении. Не зацикливайтесь на ветвях исследования, которые не принесли плодов. Вот почему вы сделали заметки для приложения (см. ниже).
  • Предложите идею того, что может произойти дальше. Сформулируйте следующие шаги как рекомендацию, оставив время и пространство для вашей команды, чтобы продолжить обсуждение того, что вы начали. Имея четкое представление о том, сколько реально времени может занять проект, ваш менеджер проекта может работать с вами над планированием и установлением сроков.

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

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

«Наличие полных результатов, подробно описанных где-либо, поможет команде доверять результатам», — поясняет Microsoft Code With Engineering Playbook. «Данные можно интерпретировать множеством разных способов, и может потребоваться вернуться к исходным данным для новой интерпретации».

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

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

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

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

Want to Connect?
You can chat with me, Cara Borenstein, on Twitter.