Автор: Алексей Кривицкий.
Сегодня, благодаря книге Майка Кона и куче статей, термин user stories (по-русски "пользовательские истории" или просто "истории") стал насколько популярен, что его стали использовать повсеместно, заменяя им такие привычные нашему уху термины как "требование", "фича", "задача", и прочее.
Это, без сомнений, подчёркивает то, что Agile прочно входит в наши дома (офисы), укоряняется в наших умах (и, дай Бог, в умах наших менеджеров и заказчиков). Становится неотъемлемой частью профессии, гордо именуемой "разработчик программного обеспечения" (читать без иронии и сарказма).
Но тут есть ряд "но", на которых я бы хотел заострить внимание тех, кому приходится писать истории, обучать своих заказчиков этой технике либо просто иметь с ними дело в повседневной проф. жизни.
Давайте рассмотрим пример. Предположим, что речь идёт о системе аналогичной Gooogle Сalendar, где пользователи могут управлять своими событиями.
Есть такое требование:
Имея сноровку, это требование можно довольно быстро привести к виду историй, который пропагандирует Майк Кон: As as a [user], I can [do], so that [value]:
Вопрос в следующем. Является ли описанная история настоящей историей?
Формально - да. Формат и размер делают ещё очень схожей с тем, что называют user stories. Но тут есть один важный ньюнс.
Давайте рассмотрим другую историю:
Так что же пользователю нужно на самом деле?
(Заказчик): Знать своё расписание.
(Мы): Зачем?
(Заказчик): Затем, чтобы видеть все спланированные события наперёд.
(Мы): Зачем нужно видеть спланированные события наперёд?
(Заказчик): Затем, чтобы не пропускать события или заблаговременно измененять свои планы, не подводя других людей.
(Мы): Зачем это нужно?
(Заказчик): Ну, так ведут себя серьёзные и деловые люди!
(Мы): Ага!!
Значит цель пользователя на самом деле является: а) не пропускать свои события; б) иметь возможность заблаговременно изменять свои планы:
- Так чем же отличается эта история от приведённого сначала требования и двух других историй?
- Она описывает проблему, а не решение.
- И что эта так важно?
- О да! Говоря о проблеме, мы склонны совместно с профессионалами предметной области найти более интересные решения, о которых мы сначала даже и не подозревали. Более креативные и свежие решения. Так зачем себя ограничивать, выбирая изначально всего лишь один вариант решения проблемы?
Встаёт более философский вопрос. А что если проблему можно будет решить вообще без программного обеспечения? Разве это так уж и плохо?
В принципе, нет. Ведь наша задача - помогать решать проблемы наших заказчиков (клиентов, пользователей).
Итог
Когда вы пишите истории, пытайтесь найти проблему, которую вы намерены решить. Опишите её в истории. Если вы догадываетесь на фазе написания истории о хорошем способе её решения (к примеру отсылать email с расписание), допишите это явно ("как вариант решения ...")в истории, но отдельно от поставленной проблемы.
Если к вам приходят истории, написанные вашими заказчиками, бизнес аналитиками или ещё кем-то, потратьте время, поговорив с ним и найдя проблему. Они вам за это будут благодарны, поверьте. Five Whys (техника "пяти почему"), которую я продемонстрировал выше, почти всегда даст вам нужный результат. Главное объяснить, что вы задаёте глупые вопросы не потому что вы глупы :)
Старайтесь выделять проблемы из решений. Храните их и управляйте ими отдельно. В Скраме для складирования проблем служит Product Backlog, для управления решениями - Sprint Backlog.
Побочные эффекты
Описание проблем обычно намного компактнее, чем описание возможных решений. Эта одна из причин, по которой в Agile проектах входной документации намного меньше, чем в традиционных проектах.
--------
Удач! Не бойтесь экспериментировать и пробовать новое.
"Anyone who has never made a mistake has never tried anything new" (Einstein)
Сегодня, благодаря книге Майка Кона и куче статей, термин user stories (по-русски "пользовательские истории" или просто "истории") стал насколько популярен, что его стали использовать повсеместно, заменяя им такие привычные нашему уху термины как "требование", "фича", "задача", и прочее.
Это, без сомнений, подчёркивает то, что Agile прочно входит в наши дома (офисы), укоряняется в наших умах (и, дай Бог, в умах наших менеджеров и заказчиков). Становится неотъемлемой частью профессии, гордо именуемой "разработчик программного обеспечения" (читать без иронии и сарказма).
Но тут есть ряд "но", на которых я бы хотел заострить внимание тех, кому приходится писать истории, обучать своих заказчиков этой технике либо просто иметь с ними дело в повседневной проф. жизни.
Давайте рассмотрим пример. Предположим, что речь идёт о системе аналогичной Gooogle Сalendar, где пользователи могут управлять своими событиями.
Есть такое требование:
- Система должна предоставлять возможность отображения событий календаря пользователя в виде списка, отсортированного по времени (по возрастанию). Отображаемые данные каждого события должны содержать краткое описание события, место, дату и время начала, длительность.
Имея сноровку, это требование можно довольно быстро привести к виду историй, который пропагандирует Майк Кон: As as a [user], I can [do], so that [value]:
- Как владелец календаря, я могу просмотреть события своего календаря в виде списка, отсортированного по времени (по возрастанию) с тем, чтобы знать своё расписание.
Детали: Отображаемые данные должны содержать краткое описание события, место, дату и время начала, длительность.
Вопрос в следующем. Является ли описанная история настоящей историей?
Формально - да. Формат и размер делают ещё очень схожей с тем, что называют user stories. Но тут есть один важный ньюнс.
Давайте рассмотрим другую историю:
- Как владелец календаря, я могу получать расписание своих событий по электронной почте с тем, чтобы знать своё расписание.
Детали: Отображаемые данные должны содержать краткое описание события, место, дату и время начала, длительность.
Так что же пользователю нужно на самом деле?
(Заказчик): Знать своё расписание.
(Мы): Зачем?
(Заказчик): Затем, чтобы видеть все спланированные события наперёд.
(Мы): Зачем нужно видеть спланированные события наперёд?
(Заказчик): Затем, чтобы не пропускать события или заблаговременно измененять свои планы, не подводя других людей.
(Мы): Зачем это нужно?
(Заказчик): Ну, так ведут себя серьёзные и деловые люди!
(Мы): Ага!!
Значит цель пользователя на самом деле является: а) не пропускать свои события; б) иметь возможность заблаговременно изменять свои планы:
- Как пользователь, я хочу не пропускать свои события и иметь возможность заблаговременно изменять свои планы.
- Так чем же отличается эта история от приведённого сначала требования и двух других историй?
- Она описывает проблему, а не решение.
- И что эта так важно?
- О да! Говоря о проблеме, мы склонны совместно с профессионалами предметной области найти более интересные решения, о которых мы сначала даже и не подозревали. Более креативные и свежие решения. Так зачем себя ограничивать, выбирая изначально всего лишь один вариант решения проблемы?
Встаёт более философский вопрос. А что если проблему можно будет решить вообще без программного обеспечения? Разве это так уж и плохо?
В принципе, нет. Ведь наша задача - помогать решать проблемы наших заказчиков (клиентов, пользователей).
Итог
Когда вы пишите истории, пытайтесь найти проблему, которую вы намерены решить. Опишите её в истории. Если вы догадываетесь на фазе написания истории о хорошем способе её решения (к примеру отсылать email с расписание), допишите это явно ("как вариант решения ...")в истории, но отдельно от поставленной проблемы.
Если к вам приходят истории, написанные вашими заказчиками, бизнес аналитиками или ещё кем-то, потратьте время, поговорив с ним и найдя проблему. Они вам за это будут благодарны, поверьте. Five Whys (техника "пяти почему"), которую я продемонстрировал выше, почти всегда даст вам нужный результат. Главное объяснить, что вы задаёте глупые вопросы не потому что вы глупы :)
Старайтесь выделять проблемы из решений. Храните их и управляйте ими отдельно. В Скраме для складирования проблем служит Product Backlog, для управления решениями - Sprint Backlog.
Побочные эффекты
Описание проблем обычно намного компактнее, чем описание возможных решений. Эта одна из причин, по которой в Agile проектах входной документации намного меньше, чем в традиционных проектах.
--------
Удач! Не бойтесь экспериментировать и пробовать новое.
"Anyone who has never made a mistake has never tried anything new" (Einstein)