Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!

КакобъединитьСкрами Канбан

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

Как объединить Скрам и Канбан

Дополните Скрам-доску визуализацией всего процесса

Визуализация поможет Команде в двух направлениях. Во-первых, вы увидите, как на самом деле выглядит процесс разработки, а не упрощённую доску задач из колонок To Do, In Progress и Done. Во-вторых, вместе с текущими задачами вы отобразите на доске технический долг — очередь из незавершённых фич, которая накапливается после каждого Спринта. Так у вас появится возможность ею управлять.

Команда, которая составила Скрам-доску на картинке, визуализировала путь фичи от идеи до релиза. Это хорошая практика, которая даёт понимание, за какое время мы выходим в релиз, где заканчивается зона ответственности нашей Команды и на каком участке есть зависимости от других команд.

Как объединить Скрам и Канбан

Ограничьте количество одновременно выполняемых задач

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

Чтобы исправить эту ситуацию, возьмите из Канбана ограничения по количеству задач в работе. Тогда разработчикам из нашего примера, прежде чем взять новую задачу, придётся помочь тестировщикам. Поэтому к концу Спринта больше задач будет в статусе Done.

Помните, в Канбане мы говорим: «Stop starting! Start finishing!» Сфокусируйтесь на завершении задач, а не на начале новых.

Как объединить Скрам и Канбан
Как объединить Скрам и Канбан

Сделайте правила игры понятными для всех

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

Как объединить Скрам и Канбан

Позаимствуйте метрики из Канбана

Узнайте скорость реализации фич с помощью метрик Wip, Cycle Time, Throughput.

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

Как объединить Скрам и Канбан

Приоритезируйте Бэклог с помощью Cost of Delay

В Канбане есть хорошая практика: оценивать задачи с помощью Cost of Delay. Этот термин означает стоимость нереализации фичи. То есть сколько денег мы потеряем, если не сделаем эту фичу через неделю, месяц или год.

Такой подход полезен Владельцу Продукта. Оценив каждую фичу с помощью финансов, легко их приоритезировать.

Простые инструменты Канбана дают отличный эффект для Скрам-команды и выводят её работу на новый уровень. Попробуйте применить эти пять правил, и вы быстро заметите результат.

Алексей Пикулев Аккредитованный тренер по Канбану

Поделиться
Вотсапнуть
Отправить
Ещё по теме
Перевод статьи Томаса Сандберга: http://www.thinkcode.se/blog/2016/06/22/cucumber-antipatterns Это расшифровка и изложение подкаста, в котором участвовали Aslak Hellesøy, Matt Wynne и Steve Tooke из Cucumber Ltd, они обсуждали BDD: инструмент Cucumber и анти-паттерны, которые встречали. Я изменил порядок описанных шаблонов, перефразировал некоторые части и добавил несколько своих мыслей. Официальный подкаст доступен по ссылке. Он стоит того, чтобы потратить на него своё время.Cucumber спроектирован как инструмент взаимодействия для создания живой документации, которую можно автоматизировать и которая описывает желаемое поведение системы. Поведение системы описывается на языке Gherkin. Если вы не знакомы с Gherkin, почитайте сейчас немного о нем. Дальнейшая часть предполагает, что вы знакомы с Gherkin и его формат Допустим/Когда/Тогда не выглядит для вас странным.

Анти-паттерн «Плохое взаимодействие»

Cucumber — это инструмент для взаимодействия и должен быть использован для взаимодействия во время создания программного обеспечения.

Неверное время написания feature-файлов

Наверное, худший анти-паттерн при использовании Gherkin — писать feature-файлы после того как был написан код. Так часто бывает, если вы только начинаете использовать Cucumber и BDD. На самом деле сценарии нужно писать до того, как вы взялись за ПО. Это позволит полноценно использовать сценарии для разработки и документирования то, что было написано. Почему следует писать на Gherkin до того как написан софт? Документация желаемого поведения — это способ убедиться в том, что все согласны с тем, что должно делать ПО. Когда вы достигли согласия и у вас есть общее понимание проблемы — это хороший момент для начала реализации и создания кода. Если писать код до того, как все пришли к общему пониманию, то позже его точно нужно будет переделывать. Cucumber — инструмент тестирования, который позволяет проверять предположения и понимание проблемы до того, как будет написан код, решающий эту проблему. Инструмент позволяет прояснить желаемое поведение и решает неоднозначности, которые ранее не были обнаружены. Конкретные примеры, которые появятся еще до реализации решения, проверят, одинаковое ли у всех понимание. У владельца продукта или бизнес-аналитика, разработчика, тестировщика свои взгляд на проблему. Понимание этих разных взглядов до написания кода увеличивает шансы создания чего-то, что на самом деле нужно конечному пользователю.

Бизнес создает сценарии в изоляции

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

Разработчики и тестировщики пишут сценарии без общения с бизнесом

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

Сценарии слишком верхнеуровневы

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

Анти-паттерн «Нет живой документации»

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

Плохая документация

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

Случайные детали

Бывает, что вместо хорошей истории пользователя перегружают слишком большим объемом информации и случайными деталями. Так бывает, если автор пишет скорее текст, а не документацию желаемого поведения. Например, Когда я логинюсь как Мэтт, мой пароль — пароль, подтверждение пароля — пароль, я проверяю баланс своего счёта Тогда я вижу $100 Цель этого сценария — проверить баланс, поэтому логин и пароль Мэтта не важны. Но они появляются в документации, потому что автору нужны значения для авто-теста. Проблема с такими случайными деталями в том, что они замутняют суть сценария. Становится сложно понять, что мы на самом деле пытаемся протестировать. В этом случае читатель должен угадать: мы тестируем функциональность ввода пароля или мы тестируем баланс банковского счета? Или тестируем и то, и то в одном сценарии? Детали о паролях и о балансе банковского счета делают цель этого сценария неясной.

Сложно сказать, что вы тестируете

Вы тестируете одно правило или вы тестируете несколько правил в одном сценарии? В этом случае появляются 2 проблемы:
  • Тестирование нескольких вещей в за один раз
  • Не создается понятная документация для проверки желаемого поведения
В такой ситуации придется искать между строчками, о чем же на самом деле этот сценарий. Более того, такой сценарий может быть бессмысленным: он расфокусирован и нацелен одновременно на всё сразу.

Неудачное название сценария

Удачное название сценария говорит читателю, о чем он. Отсутствие название заставляет читателя гадать. Если название пытается суммировать полное поведение сценария, оно становится скучным и читатель теряет интерес. Например: Сценарий: Зарегистрироваться, залогиниться, перейти на экран баланса, выйти Хороший вариант — это подытоживание сути сценария в его названии. Например так: Сценарий: Проверка баланса Название показывает, что любые детали обо всём остальном случайны и должны быть удалены. Если для автоматизации необходим пароль, он может быть добавлен на уровне автоматизации. Хороший алгоритм для названий может быть использование метафоры «Друзья»: Это когда... Вот примеры:
  • Это когда баланс положительный
  • Это когда у меня есть овердрафт на моём счёте
  • Это когда я меняю свой пароль
Затем описывается поведение в сценарии при помощи Допустим/Когда/Тогда

Не используется описательная часть feature-файла

Первая часть в feature-файле называется описательной частью. Вы можете написать туда все, что хотите. Вы можете её не заполнять или добавить туда полезные детали. Когда вы не заполняете описательную часть или добавляете туда пользовательский сценарий как тот, что ниже — это два разных анти-паттерна. Как пользователь, Я хочу проверить свой счёт и я знаю какой у меня баланс на нём Этот пользовательский сценарий не добавляет вам никакой дополнительной информации и поэтому довольно бесполезен. Вместо этого поместите полезную информацию для читателя в начале файла. Опишите бизнес-правила, абстрактные правила которые мы дополним примерами. Например: После того как вы сняли деньги, это снятие должно появиться в списке транзакций. Формат, в котором вы описываете бизнес-правила не имеет значения. Опишите их при помощи списка, если вам так больше нравится. Примеры, которые будут следовать ниже, уточнят их. Описательная часть — это также место, где можно поместить вопросы или какие-то элементы неопределенности. Относитесь к feature-файлу как к живой документации, куда вы помещаете найденные правила и неотвеченные вопросы, известные неизвестные. Это текущее понимание фичи. Здесь есть и то, что мы уже знаем и то, что нам ещё неизвестно.

Ошибки новичков

Дальше приведены ошибки, которые обычно совершают новички.

Куча деталей по UI

Система используется через пользовательский интерфейс (UI). Иногда это приводит к сценариям, в которых говорится о переходе по определенному url, клику по линку, поиску элементов, использующих определенные селекторы css и тд. На самом деле все это не говорит нам о цели использования программы.

Детали UI дают две проблемы:

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

Описание действий через личные местоимения

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

Документирование скучных сценариев

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

Вечное хранение всех сценариев

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

Нет четкого разделения между Допустим/Когда/Тогда

Начинающим сложно понять разницу между Допустим, Когда и Тогда. Проблема в том, что с технической точки зрения между ними нет разницы, Cucumber использует их одинаково. Разница все-таки есть:
  • Допустим — это контекст о прошлом
  • Когда — это действие которое изменяет систему, настоящее
  • Тогда — это ожидаемый результат, ближайшее будущее
Попробуем проследить разницу с помощью метафоры «поход в театр». Вы сидите на стуле и занавес опущен. За занавесом готовятся множество работников, они расставляют вещи по местам. Это Допустим. Вы настраиваете вашу систему, создавая начальные объекты, подготавливаете базу данных, переходите на конкретную страницу и так далее. Занавес поднимается и начинается пьеса. Вещи появляются, одна вещь ведет к другой. Актеры начинают перемещаться и произносить свой текст. Это Когда. Запускается важное событие, которое нам важно в определенном контексте. Одно событие на сцене ведёт к другому, ожидаемому результату. Это происходит как результат того, что сделал актер. Это Тогда. Видимое изменение, которое мы хотим подтвердить. Надеюсь, при помощи это метафоры Допустим и Когда проще понять. Но возможно часть Тогда менее ясна.
  • Прошлое, подготовка — Допустим
  • Настоящее, действие — Когда
  • Ближайшее будущее, ожидаемый результат — Тогда

Несколько Когда

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

Обоюдоострый меч

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

Структура сценария

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

Множество Тогда в одном и том же сценарии

Это не обязательно анти-паттерн. Например, если что-то возвращается в розничной системе:
  • Пользователю должны вернуться деньги
  • Список товаров должен обновиться
  • Финансовая система должна быть обновлена
  • На склад должно быть отправлено сообщение о том, что нужно забрать возврат
Это всё связано и проверка их одновременно может быть хорошей идеей. В то же время, это является результатом одновременно четырех различных бизнес-правил, поэтому разделение их на четыре разных сценария может сделать бизнес-правила более явными и, возможно, поможет понять систему лучше. Разделение также позволит команде разработки реализовать эти правила инкрементально. Бывают примеры, когда связанные операции невозможно разделить на сценарии. Например, снятие денег с банковского счёта:
  • Пользователь должен получить свои деньги из банкомата, допустим 5000р
  • Со счета пользователя должны быть сняты 5000р
Эти результаты зависят друг от друга и не могут быть разделены на разные сценарии. Банку не понравится, если пользователи получат деньги без их списания со счёта. С другой стороны, что тоже правда, большинство пользователей не будут рады, если с их счета деньги будут списаны, а наличные они не получат.

Фотки из отпуска

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

Заключение

Когда вы используете Cucumber и BDD, вы можете сделать кучу ошибок. Однако, если вы их совершите, конец света не произойдет. Возможно вы совершите больше ошибок, но это жизнь. Вы живёте и вы учитесь. Сейчас вы вооружены знанием о некоторых анти-паттернах. Если вы вспомните ошибку, которую вы совершили и хотите этим поделиться, используйте комментарии ниже. Или пришлите нам письмо.
На тренингах Алексея Пикулева спрашивают, почему срочная работа — это плохо. Объясняем на примере очереди в аэропорте. Представьте, что вы стоите в Шереметьево в огромной очереди на регистрацию. Самолет через полтора часа, очередь еле ползёт. Работают три окошка регистрации, рядом пустует проход для пассажиров бизнес-класса, девушка за стойкой скучает. Вдруг подбегает менеджер с компанией людей, опаздывающих на свой рейс, и «втыкает» их в начало очереди. Он решил свою проблему, но представьте недовольство людей. Более того, из-за них теперь вы опаздываете на свой рейс и просите менеджера провести вас вне очереди. Впередистоящие пассажиры вас ненавидят. Что происходит: нормальная работа сбилась из-за малого количества стоек регистрации и действий менеджера. Это означает, что авиакомпания не умеет управлять потоком задач и использовать ресурсы на максимум. Какие последствия: получается замкнутый круг. Решение срочных задач сбивает налаженную работу, из-за чего возникают новые авралы. Это стресс для сотрудников, постоянное недовольство пассажиров, ухудшение репутации компании. Как исправить: искать системное решение проблемы. В этом помогут инструменты Канбана вроде системных диаграмм или техники «5 почему». Возможно, авиакомпании стоит открыть больше стоек регистрации или сделать так, чтобы люди могли зарегистрироваться самостоятельно. Гибкие подходы — это не прихоть, это продуманная организация работы. Замените очереди в аэропорту на поток задач в вашей компании — ничего не изменится. Канбан поможет наладить и то, и другое.
Комментарии
Подпишитесь на нас:
Телеграм Группа в фейсбуке