[БЕЗ_ЗВУКА] В данном уроке мы рассмотрим один из основных инструментов гибкого планирования — карты историй. А также узнаем, как с их помощью можно спланировать график выпуска релизов продукта и так называемого минимального жизнеспособного продукта (MVP). Карты историй (story mapping) являются инструментом, помогающим в осмыслении функциональности продукта, способов его использования. А также помогают в расстановке приоритетов при поставке продукта, то есть при планировании релиза. Этот метод декомпозиции обеспечивает эволюционное понимание продукта, начиная с полного охвата всех требований и завершая погружением до детальных историй пользователей. Карты историй содержат каркас из элементов, которые будут составлять продукт. Этот каркас покрывает крупные наборы функций (feature sets), которые должны быть реализованы в течение проекта. Карты историй позволяют командам планировать релиз, представляя требования при помощи пользовательских историй. Карты историй составляют все эти истории упорядоченными по горизонтали и отражают сложность реализации по вертикали. Следующий пример представляет собой определение пользовательских историй для систем электронной почты и организует их следующим образом: группы задач (жёлтые карточки), главные задачи (голубые карточки) и подчинённые функции (оранжевые карточки). Очень полезно комбинировать пользовательские истории с картами историй для управления требованиями и планированиями релизов. Вот пять основных преимуществ карты историй. Первым реализуется то, что действительно важно. Карты историй позволяют командам выделить приоритетные по важности требования и именно с них начать реализацию будущего проекта. Когда есть карты историй, команда может выделить наиболее важные требования и выполнять задачи в соответствии с приоритетными особенностями системы. Эти особенности могут охватывать некий бизнес-процесс целиком, а не какую-то отдельно взятую функцию. На примере систем электронной почты: релиз A включает в себя все главные функции простой почтовой системы. Последующие релизы улучшают функциональность по частям. Следуя данному подходу, команды могут валидировать систему, а бизнес-процессы работать на высоком уровне, в то время как последующие итерации вносят в них улучшения. Второе: можно дробить большие требования на маленькие куски. Пользовательские истории и карты историй нравятся мне затем, что заставляют быть кратким в описании. Пачка карточек в любом случае предпочтительнее 100-страничного документа. Если бизнес-требование слишком сложное, чтобы изложить его на одной карточке, просто разбейте его на две. Карты историй позволяют вам организовать требования в виде групп, а затем реализовать из меньшими релизами. Третье: можно откладывать менее важное на другой релиз. Поскольку требования определяются малыми порциями, становится легче отложить менее важное на будущие релизы. Выделяя самые важные требования и откладывая менее важные на потом, команда может намного успешнее реализовывать продукт, отвечающий нуждам заказчика, нежели выпускать частичный продукт, напичканный бантиками. Четвертое: улучшается коммуникация с заказчиком. Карты историй помогают также улучшить коммуникацию с заказчиком, поскольку каждое требование соотносится с конкретными шагами процесса и релизами. Заказчик понимает, какая функциональность будет реализована в каждом из релизов. Если заказчик хочет, чтобы некая функция была реализована раньше, он может просто поменять приоритеты на карте. Визуализируется сценарий разработки продукта или системы. Если вы передали мне 100-страничное техническое задание и попросили его утвердить, какова вероятность успеха? Обычно где-то странице к десятой я начну читать по диагонали и скорее всего пропущу важное требование, за что понесу ответ на стадии разработки. Этот подход не имеет смысла, потому что в текстовом виде трудно соотнести требования с системой. С картой историй однако фокус уменьшается, и заказчик может визуально понять, какие требования войдут в первый релиз, какие во второй и последующие. Фокусируясь на релизах, заказчик может уделить больше внимания соответствующим требованиям. В примере с почтой во время релиза A заказчик может сосредоточиться на высокоприоритетных особенностях, которые войдут в начальный релиз. К преимуществам карт историй относится также то, что когда общий контекст продукта не берется во внимание, agile-проекты могут увязнуть в деталях, и станет невозможно связать компоненты вместе друг с другом, чтобы создать сквозную ценность для бизнеса. Story mapping помогает избежать распространенной проблемы увязания в деталях историй пользователя и риска потерять смысл общей картины. Недостатком можно назвать то, что story mapping может стать громоздкой практикой, если продукт очень большой, и может потребоваться строительство ряда карт историй, которые охватывают большую программу работ. Хотя карты историй иллюстрируют поток, они не анализируют и не иллюстрируют зависимости между требованиями. Хотя они могут быть использованы, чтобы помочь облегчить этот анализ. Процесс построения карты историй может быть описан как последовательность шагов. Определить ключевые виды деятельности, которые должен поддерживать продукт. Каждый вид деятельности записать на отдельной карточке. Для карточек видов деятельности используется один цвет. Расположить их по порядку использования слева направо. Хотя последовательность выполнения активностей пользователем будет меняться, как правило, существует общая ежедневная последовательность, которая может быть использована. Эти активности, как правило, слишком велики, чтобы реализовать в одной итерации разработки. После расположения пользовательских активностей в логическом порядке, необходимо определить отдельные задачи, которые составляют каждую активность. Эти задачи должны быть отдельными частями работы для тех пользователей, кто использует продукт. Необходимо записать каждую задачу на отдельной карточке, используя различные цвета в зависимости от деятельности. Расположить задачи в одной строке в логическом, последовательном порядке под соответствующим видом деятельности. Опять же, часто не будет строгой последовательности, которой необходимо следовать каждый раз, но будет общий логический порядок выполнения задач. Это отражается последовательностью карточек задач на карте. Проверить активности и задачи с помощью экспертов в данной области и других заинтересованных сторон. Задать им вопрос: составили ли они полную картину того, что должен обеспечить продукт. Обновить и изменить активности и задачи по мере необходимости. Добавить подзадачи ниже задач, еще раз, используя карточки различных цветов. Часто они должны охватывать альтернативные пути постановки задач или должны иметь дело с исключениями или потенциальными проблемами при выполнении задач. Добавить эти нижние задачи сверху вниз в логическом порядке, основываясь на приоритете пользователя. Эти подзадачи находятся на уровне истории пользователя, и их будет много. Просмотр верхнего ряда подзадач по всей карте обеспечит обзор минимального возможного жизнеспособного продукта. То есть набор функций, которые должны быть присущи продукту, чтобы имелось какое-либо значение для бизнеса вообще. Этот горизонтальный обзор историй обеспечивает логическую отправную точку для выпуска и итерационного клонирования. В то время как вертикальное положение истории пользователя показывает ее относительный приоритет в общей картине. Проверить карту историй с помощью заинтересованных сторон и обновить ее по необходимости. Хранить карту историй, чтобы обеспечить обзор большой картины всего продукта. Указать, когда истории завершены на карте историй таким образом, чтобы был виден общий прогресс. При наличии проработанной карты истории становится достаточно просто выделить так называемый MVP — минимальный жизнеспособный продукт, minimum viable product. Это упрощенная версия проекта, содержащая только критически важные функции, без которых запуск не имеет смысла. MVP — это продукт, который обладает исключительно минимальным набором свойств и функций, которых достаточно для сбора обратной связи для последующих улучшений этого продукта. Разработка MVP ведется не компонент за компонентом, а целиком — от более простого продукта к более сложному. MVP позволяет снизить риски и учиться на ошибках за счет итеративной и инкрементальной разработки. Давайте сравним пример результатов итерации на слайде. Какой способ разработки принесет пользу быстрее, если пользователь хочет добраться из пункта А в пункт Б? Очевидно, что в данном примере в качестве MVP выступает скейтборд, а не колесо. MVP обычно разрабатывается полтора-два месяца и нужен для того, чтобы открыть проект небольшой аудитории и проверить его жизнеспособность. После запуска MVP, как правило, выясняется, что часть запланированного функционала не нужна. Но появляются другие жизненно необходимые функции. Цель раннего запуска MVP — сэкономить пять-шесть месяцев и деньги на разработку всего функционала продукта, выявить интерес к проекту у реальных пользователей и в случае необходимости скорректировать курс. Для того чтобы выяснить, какие возможности продукта должны войти в MVP, а какие можно отложить, необходимо составить полный список функций, которые вы считаете важными, и задать вопрос применительно к каждому пункту этого списка: «Могу ли я сделать эту возможность через неделю после запуска?» Если есть хоть один шанс из 100, что этот пункт можно отложить, он не входит в MVP, и его нужно отложить. Среди примеров компаний, начинавших свой путь к успеху с MVP, можно выделить Uber, Snapchat, Foursquare и другие. Теперь, когда мы ориентируемся, как agile-проекты планируются на макроуровне, давайте перейдем к деталям планирования на микроуровне, а именно к бэклогу и тем самым пользовательским историям. Это мы и рассмотрим на следующих уроках.
