К основному контенту

User Stories as a thinking tool

Автор: Алексей Кривицкий.

Сегодня, благодаря книге Майка Кона и куче статей, термин user stories (по-русски "пользовательские истории" или просто "истории") стал насколько популярен, что его стали использовать повсеместно, заменяя им такие привычные нашему уху термины как "требование", "фича", "задача", и прочее.

Это, без сомнений, подчёркивает то, что Agile прочно входит в наши дома (офисы), укоряняется в наших умах (и, дай Бог, в умах наших менеджеров и заказчиков). Становится неотъемлемой частью профессии, гордо именуемой "разработчик программного обеспечения" (читать без иронии и сарказма).

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


Давайте рассмотрим пример. Предположим, что речь идёт о системе аналогичной Gooogle Сalendar, где пользователи могут управлять своими событиями.
Есть такое требование:

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

Имея сноровку, это требование можно довольно быстро привести к виду историй, который пропагандирует Майк Кон: As as a [user], I can [do], so that [value]:

  • Как владелец календаря, я могу просмотреть события своего календаря в виде списка, отсортированного по времени (по возрастанию) с тем, чтобы знать своё расписание.

    Детали: Отображаемые данные должны содержать краткое описание события, место, дату и время начала, длительность.
Вспомнив, про концепцию Card Conversation Confirmation (предлагаемую экспишниками, в частности Роном Джеффриз), мы, можем добавить тесты - критерии приёмки истории. Но не суть. Сейчас не об этом.

Вопрос в следующем. Является ли описанная история настоящей историей?

Формально - да. Формат и размер делают ещё очень схожей с тем, что называют user stories. Но тут есть один важный ньюнс.

Давайте рассмотрим другую историю:

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

    Детали: Отображаемые данные должны содержать краткое описание события, место, дату и время начала, длительность.
На сколько эта история отличается от предыдущей? С первого взгляда - довольно сильно. В первой мы говорили про web view в виде списка. Тут мы говорим про email. Наверное, можно придумать ещё десяток способов отображения расписания...

Так что же пользователю нужно на самом деле?
(Заказчик): Знать своё расписание.
(Мы): Зачем?
(Заказчик): Затем, чтобы видеть все спланированные события наперёд.
(Мы): Зачем нужно видеть спланированные события наперёд?
(Заказчик): Затем, чтобы не пропускать события или заблаговременно измененять свои планы, не подводя других людей.
(Мы): Зачем это нужно?
(Заказчик): Ну, так ведут себя серьёзные и деловые люди!
(Мы): Ага!!

Значит цель пользователя на самом деле является: а) не пропускать свои события; б) иметь возможность заблаговременно изменять свои планы:

  • Как пользователь, я хочу не пропускать свои события и иметь возможность заблаговременно изменять свои планы.
Что изменилось по сравнению с предыдущими двумя историями? Эта история - ни слова не говорит про программное обеспечение. Её можно решить вообще без компьютера, завёв карманный календарик, ведя расписание на настенном календаре или заведя секретаршу.

- Так чем же отличается эта история от приведённого сначала требования и двух других историй?
- Она описывает проблему, а не решение.
- И что эта так важно?
- О да! Говоря о проблеме, мы склонны совместно с профессионалами предметной области найти более интересные решения, о которых мы сначала даже и не подозревали. Более креативные и свежие решения. Так зачем себя ограничивать, выбирая изначально всего лишь один вариант решения проблемы?
Встаёт более философский вопрос. А что если проблему можно будет решить вообще без программного обеспечения? Разве это так уж и плохо?
В принципе, нет. Ведь наша задача - помогать решать проблемы наших заказчиков (клиентов, пользователей).

Итог


Когда вы пишите истории, пытайтесь найти проблему, которую вы намерены решить. Опишите её в истории. Если вы догадываетесь на фазе написания истории о хорошем способе её решения (к примеру отсылать email с расписание), допишите это явно ("как вариант решения ...")в истории, но отдельно от поставленной проблемы.

Если к вам приходят истории, написанные вашими заказчиками, бизнес аналитиками или ещё кем-то, потратьте время, поговорив с ним и найдя проблему. Они вам за это будут благодарны, поверьте. Five Whys (техника "пяти почему"), которую я продемонстрировал выше, почти всегда даст вам нужный результат. Главное объяснить, что вы задаёте глупые вопросы не потому что вы глупы :)

Старайтесь выделять проблемы из решений. Храните их и управляйте ими отдельно. В Скраме для складирования проблем служит Product Backlog, для управления решениями - Sprint Backlog.

Побочные эффекты


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

--------

Удач! Не бойтесь экспериментировать и пробовать новое.
"Anyone who has never made a mistake has never tried anything new" (Einstein)

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations


Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко.


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

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

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn)
Перевод с английского


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

Какие проекты лучше всего подходят для применения Agile

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.



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

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

Об agile по-русски: User Stories, часть 1

«Разработка ПО - это игра изобретательности и кооперации»
Элистер Коуберн (1)
О чем эта статья? Это одна из статей серии «Про agile по-русски» (см. сноску внизу про значение термина «agile»), идея которых поделиться опытом использования agile принципов (2) в разработке программного обеспечения. Основная суть этих подходов – кооперация между всеми членами проекта и адаптивность процесса разработки к неизбежным изменениям. Также важным аспектом Agile является принятие человеческого фактора в проекте как неотъемлемой части и более того – как наиважнейшей причиной прогресса. Agile акцентирует важность поддержания человеческих отношений и учета человеческих особенностей для успеха проекта.Эта статья рассказывает о применении «userstories» («пользовательских историй») - одной из практик agile. Далее для краткости я буду называть их просто «историями». Для кого эта статья? Эта статья для профессионалов по разработке программного обеспечения: менеджеров продуктов, менеджеров верхнего и среднег…