Методология Lean Agile в действии

Пример студенческого портала

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

Встреча заинтересованных сторон

Повестка дня

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

Стив (команда разработчиков): Добро пожаловать… Мы хотим, чтобы встреча была более продуктивной и результативной. Когда мы предлагаем функции, которые вы хотите получить, мы можем использовать следующий формат как стандартный способ выражения: кто (вы), какая функция (вы хотите), и (почему вы хотите её получить)… Эти функции будут зафиксированы как пользовательские истории, которые будут использоваться как инструмент коммуникации на протяжении всего проекта.

Затем мы провели мозговой штурм и составили список пользовательских историй от разных заинтересованных сторон:

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

Представитель академического отдела: добавить информацию о курсе, изменить информацию о курсе, удалить информацию о курсе …

Администратор портала: резервная копия информации о курсе, изменение статуса студенческого аккаунта

Теперь у нас есть несколько карточек, которые можно организовать в строки и столбцы

Приоритизация предложенных функций

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

Мы получили дополнительную информацию от конечных пользователей на встрече:

• Академический: студент должен быть зачислен на полный рабочий день
• Администратор: студент должен предоставить правильные учетные данные для входа
• Академический: курс не заполнен
• Академический: необходимо выполнить все предварительные требования к курсу
• Администратор: курс, выбранный для добавления в расписание, не должен конфликтовать со временем другого курса
• Разработчик: какие другие функции вы хотите объединить в список вместе с этой функцией в целевой системе?
• Студент: отменить курсы, посмотреть расписание, редактировать расписание.

3C пользовательской истории

Хорошие пользовательские истории — это гораздо больше, чем просто утверждения. Стандартная пользовательская история состоит из трёх частей, обычно называемых тремя C. Первый «C» каждой пользовательской истории должен соответствовать стандартному формату: «Я как [роль], хочу [что-то сделать], чтобы [получить выгоду]», что является минимальным содержанием пользовательской истории, которое нужно поместить на карточку. Второй «C» — это «разговоры», которые представляют собой обсуждение между конечными пользователями, владельцем проекта и командой разработчиков. В этих обсуждениях фиксируются устные разговоры, а также многие другие полезные сведения, такие как электронные письма, макеты или любые другие связанные материалы проекта. Последний «C» — это подтверждение, которое представляет собой критерии приемки, используемые для подтверждения того, что пользовательская история была правильно реализована и успешно доставлена.

Позвольте мне немного подробнее объяснить, как разработать часть подтверждения пользовательской истории. Здесь мы используем наиболее известный шаблон, называемый Gherkin, который использует формулу Given-When-Then для руководства написанием тестов приемки для пользовательской истории:

• (Дано.. и) некоторый контекст
• (Когда.. и) выполняется некоторое действие
• (Тогда.. и) выполнить некоторые действия

Инструменты, такие как Cucumber и фреймворки тестирования Jbehave, поощряют использование шаблона Given/Then/Then для проведения автоматизированного тестирования, хотя он также может использоваться исключительно как эвристика независимо от того, будет ли использоваться инструмент.

Давайте соберем всю информацию по пользовательской истории «записаться на курс» и представим ее в формате 3Cs:

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

Разбиение эпика на пользовательские истории

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

Горизонтальное разделение

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

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

Существует большое количество успешных реализаций на основе многоуровневой архитектуры, таких как Ruby on Rails и архитектура на основе веб-сервисов.

Пользовательские истории и горизонтальное разделение

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

Вертикальное разделение

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

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

Горизонтальное разделение эпика по цели

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

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

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

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

Общее хранилище пользовательских историй

Давайте создадим эти пользовательские истории в UeXceler:

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

• Если учетные данные учетной записи студента введены неправильно три раза, это запустит пользовательскую историю «сброс пароля»;
• И если новый студент еще не зарегистрировался в учетной записи студента, он/она может запустить пользовательскую историю «создание новой учетной записи студента» на экране входа.

1. Как студент, я хочу войти в студенческий портал, чтобы…
2. Как администратор портала, я хочу проверить, что человек, который вошел в систему, является зарегистрированным студентом, чтобы…
3. Как руководитель курса, я хочу проверить пригодность перед тем, как разрешить добавление выбранного курса в расписание студента, чтобы…

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

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

Разделы случаев использования

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

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

Разделение эпика на сценарии

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

1. Как руководитель курса, я хочу проверить требования к предварительным знаниям перед тем, как разрешить добавление выбранного курса в расписание студента, чтобы…
2. Как руководитель курса, я хочу проверить наличие курса перед тем, как разрешить добавление курса в расписание студента, чтобы…
3. Как руководитель курса, я хочу проверить доступность временного интервала студента перед тем, как разрешить добавление выбранного курса в расписание студента, чтобы…

Разделение эпика на задачи

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

1. Проверить статус квоты курса
2. Проверить предварительные требования к курсу
3. Проверить временной интервал

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