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

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). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Основополагающие принципы Agile-манифеста

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

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

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

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.