Забавная холивар-книга в стиле дневника менеджера, драматически прошедшегося по всем граблаям и слабостям (настоящим и мнимым) скрам при его внедрении в компании. Вызвала небольшую бурю в профильных agile-сообществах.

User story (пользовательская история) - это краткое описании функции, выполняемой продуктом, с точки зрения персоны (пользователя с определенными характеристиками). Записывается по формуле "Как (персона пользователя) я (действие/цель), чтобы (результат)".

Job story - это описание функции, выполняемой продуктом, с точки зрения контекста ситуации, в которой оказался пользователь, и его мотивации, а не персоны. Записывается по формуле "Когда (описание ситуации), я (мотивация), чтобы (результат).

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

См. также Use case vs. user story

Дополняя свой пост 3-летней давности тезисами из публикации Alexander Tvar "Как писать User Story".

У хорошей юзер стори как правило:
- один actor
- одно действие
- одна ценность (value / impact)

При написании user story имеет смысл перейти с понятия ценности (value) на влияние (impact). История не обязательна должна иметь ценность, но обязательно должна оказывать влияние на актора, указанного в истории.

Классический INVEST-критерий оценки удачной юзер стори:
- Independent. Reduced dependencies = easier to plan
- Negotiable. Details added via collaboration
- Valuable
- Estimable. Too big or too vague = not estimable
- Small. Can be done in less than a week by the team
- Testable. Good acceptance criteria

В дополнение к теме об управлении изменениями.

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

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

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

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

Читать дальше →