Привет всем!
Меня зовут Анастасия. В роли бизнес-аналитика я оказалась примерно тогда же, когда эта роль появилась в ИТ. Больше 20 лет проектирую функциональность ИТ-систем и процессы. До БА работала в роли тестировщика, а еще раньше - разработчика. Сейчас продолжаю карьеру и занимаюсь менторством. Помогаю аналитикам любого уровня решать их кейсы и расти в профессии. Подробнее по ссылке.
Этот канал - попытка поделиться прочитанным и увиденным в сфере бизнес-анализа в ИТ, чтобы вам было проще ориентироваться в потоках информации.
На аватарке канала изображение от storyset на Freepik
Меня зовут Анастасия. В роли бизнес-аналитика я оказалась примерно тогда же, когда эта роль появилась в ИТ. Больше 20 лет проектирую функциональность ИТ-систем и процессы. До БА работала в роли тестировщика, а еще раньше - разработчика. Сейчас продолжаю карьеру и занимаюсь менторством. Помогаю аналитикам любого уровня решать их кейсы и расти в профессии. Подробнее по ссылке.
Этот канал - попытка поделиться прочитанным и увиденным в сфере бизнес-анализа в ИТ, чтобы вам было проще ориентироваться в потоках информации.
На аватарке канала изображение от storyset на Freepik
❤4
Спринт
Джейк Кнапп, Брейден Ковитц, Джон Зерацки. Год выхода: 2016
Книга долго находилась в моем листе ожидания. Оказалась она в этом листе во времена моего погружения в практики гибкой разработки. Когда добралась до чтения, то обнаружилось, что речь пойдет вовсе не о спринтах как их понимают ИТ-команды в Agile. Здесь термин "продукт" используется в значении "товар, любая услуга", а не в значении "услуга через ИТ-приложение".
О чем книга? О проверке гипотез за 5 рабочих дней по заданному фреймворку под названием "Спринт". Фреймворк строится на использовании прототипов и по сути похож на технику "Волшебник страны ОЗ", в которой доступными средствами за очень короткое время имитируется работа продукта или фичи.
Что может быть полезно? В "Спринте" описаны задачи по дням недели. Не уверена, что в каждом проекте будет просто соблюдать такой хронометраж, но может быть полезна описанная логика движения от формулировки проблем к протестированному решению. Авторы дают рекомендации по выполнению задач каждого дня от организации рабочего места и фасилитации встреч до критериев качества результатов. Приведены конкретные примеры из проектов для медицинской клиники, для робота-дворецкого, для Slack и некоторых других. Прототипы в этих проектах не обязательно веб-приложения или что-то их заменяющее, в книге есть примеры переоборудования помещений, продажи фич через буклет, имитации функций робота…
Кому может быть полезно? Книга может быть интересна, если вы начинаете знакомиться с проверкой гипотез через функциональные прототипы и хотите изучить конкретные случаи применения. "Спринт" вряд ли увлечет тех, кто не погружен в продуктовые исследования или наоборот погружен в них давно и всерьез.
#книжки
Джейк Кнапп, Брейден Ковитц, Джон Зерацки. Год выхода: 2016
Книга долго находилась в моем листе ожидания. Оказалась она в этом листе во времена моего погружения в практики гибкой разработки. Когда добралась до чтения, то обнаружилось, что речь пойдет вовсе не о спринтах как их понимают ИТ-команды в Agile. Здесь термин "продукт" используется в значении "товар, любая услуга", а не в значении "услуга через ИТ-приложение".
О чем книга? О проверке гипотез за 5 рабочих дней по заданному фреймворку под названием "Спринт". Фреймворк строится на использовании прототипов и по сути похож на технику "Волшебник страны ОЗ", в которой доступными средствами за очень короткое время имитируется работа продукта или фичи.
Что может быть полезно? В "Спринте" описаны задачи по дням недели. Не уверена, что в каждом проекте будет просто соблюдать такой хронометраж, но может быть полезна описанная логика движения от формулировки проблем к протестированному решению. Авторы дают рекомендации по выполнению задач каждого дня от организации рабочего места и фасилитации встреч до критериев качества результатов. Приведены конкретные примеры из проектов для медицинской клиники, для робота-дворецкого, для Slack и некоторых других. Прототипы в этих проектах не обязательно веб-приложения или что-то их заменяющее, в книге есть примеры переоборудования помещений, продажи фич через буклет, имитации функций робота…
Кому может быть полезно? Книга может быть интересна, если вы начинаете знакомиться с проверкой гипотез через функциональные прототипы и хотите изучить конкретные случаи применения. "Спринт" вряд ли увлечет тех, кто не погружен в продуктовые исследования или наоборот погружен в них давно и всерьез.
#книжки
👍2❤1
Сколько раз вы слышали или говорили что-то вроде: «Наши заказчики сами не знают, чего хотят»? Действительно ли они не знают? Как найти тех, кто знает? Записала свои мысли и пару советов тут
Дзен | Статьи
Цена термина "заказчик"
Статья автора «ПроБА» в Дзене ✍: Однажды на вебинаре я рассказывала о работе с заинтересованными сторонами (стейкхолдерами) и заметила как сложно слушателям принимать, что заинтересованные стороны -
👍3
Пролистала больше десятка профессиональных блогов. Из кучи контента (советов начинающим, рекламы консалтинга, продвижения курсов) выбрала пару статей, которые показались интересными
#что_почитать
#что_почитать
Дзен | Статьи
Что почитать?
Статья автора «ПроБА» в Дзене ✍: Пролистала больше десятка профессиональных блогов.
👍2
Оффлайн часть конференции Flow Думаю, видео докладов появятся в сети рано или поздно, поэтому не буду пересказывать. Рассказывать о каких-то неудачностях тоже не буду, их и без меня все заметят. Поделюсь самым ценным и неповторимым - впечатлениями.
День первый запомнился двумя докладами о требованиях. Сначала Сергей Нужненко напомнил, что гибкость методологий не отменяет ни требований, ни актуальности инженерии требований. А чуть позже Юрий Куприянов рассказал, что требования настолько плотно связаны с решением, что и требований никаких по сути нет, а есть придумывание решения вместе с заказчиком. Забавно, что я нашла с чем согласиться в обеих точках зрения.
📌То, что уже лет 10 профессионалам интересно обсуждать существуют ли требования, это своего рода признак, что имеется потребность как-то называть и обрабатывать вид информации, которая есть в их работе. Есть продукт, а значит есть и критерии его успеха, и ожидаемые характеристики, даже если они записаны новым способом или не записаны вовсе - это не означает, что их нет.
📌Верно и то, аналитик по сути проектирует решение на уровне, который ему доверила команда. Как сложно критерии успеха полностью “отвязать” от решения знает любой, кто пытался описать взаимодействие пользователя с решением и не использовать фраз вида “пользователь должен войти в систему и нажать кнопку”.
День второй произвел впечатление докладами по UX. День завершал доклад Дмитрия Сатина, в докладе оказался не просто рассказ о методике исследования пользователей, но и тезис Анализ без UX ⇒ Непонятые пользователи ⇒ Большие проблемы, а значит аналитикам нужно уметь исследовать опыт своих пользователей. Тема интересна не только мне, судя по тому, как участники еще почти час после доклада задавали вопросы и не отпускали спикера. Я сформулировала свои соображения, как мне казалось, в остроумный вопрос, но когда смогла добраться до микрофона, Дмитрий уже ответил на столько вопросов и столько информации прозвучало, что сил оставалось только поделиться наблюдением, какие неожиданные результаты получаются из навыков анализа в сочетании с навыками UX. Навык UX помогает видеть как неэффективно выглядят некоторые задачи с точки зрения пользовательского опыта и еще как эта неэффективность в итоге приведет к провалу вместо достижения целей. Когда аналитику поручают задачу, мало кто из руководителей ожидает услышать, что задача не поможет достичь целей и лучше ее не делать…
В общем полезными были эти два дня. #конференции
День первый запомнился двумя докладами о требованиях. Сначала Сергей Нужненко напомнил, что гибкость методологий не отменяет ни требований, ни актуальности инженерии требований. А чуть позже Юрий Куприянов рассказал, что требования настолько плотно связаны с решением, что и требований никаких по сути нет, а есть придумывание решения вместе с заказчиком. Забавно, что я нашла с чем согласиться в обеих точках зрения.
📌То, что уже лет 10 профессионалам интересно обсуждать существуют ли требования, это своего рода признак, что имеется потребность как-то называть и обрабатывать вид информации, которая есть в их работе. Есть продукт, а значит есть и критерии его успеха, и ожидаемые характеристики, даже если они записаны новым способом или не записаны вовсе - это не означает, что их нет.
📌Верно и то, аналитик по сути проектирует решение на уровне, который ему доверила команда. Как сложно критерии успеха полностью “отвязать” от решения знает любой, кто пытался описать взаимодействие пользователя с решением и не использовать фраз вида “пользователь должен войти в систему и нажать кнопку”.
День второй произвел впечатление докладами по UX. День завершал доклад Дмитрия Сатина, в докладе оказался не просто рассказ о методике исследования пользователей, но и тезис Анализ без UX ⇒ Непонятые пользователи ⇒ Большие проблемы, а значит аналитикам нужно уметь исследовать опыт своих пользователей. Тема интересна не только мне, судя по тому, как участники еще почти час после доклада задавали вопросы и не отпускали спикера. Я сформулировала свои соображения, как мне казалось, в остроумный вопрос, но когда смогла добраться до микрофона, Дмитрий уже ответил на столько вопросов и столько информации прозвучало, что сил оставалось только поделиться наблюдением, какие неожиданные результаты получаются из навыков анализа в сочетании с навыками UX. Навык UX помогает видеть как неэффективно выглядят некоторые задачи с точки зрения пользовательского опыта и еще как эта неэффективность в итоге приведет к провалу вместо достижения целей. Когда аналитику поручают задачу, мало кто из руководителей ожидает услышать, что задача не поможет достичь целей и лучше ее не делать…
В общем полезными были эти два дня. #конференции
👍2
BABOK и Инженерия требований
В блоге IIBA встретилась статья о том, что, аналитики работают с требованиями, но не всегда знают, что есть отдельная дисциплина посвященная требованиям. Если читать только BABOK, то можно упустить важные вещи. Прокомментировала от себя и получилось многобукв, поэтому детали пришлось оставить в Дзене
В блоге IIBA встретилась статья о том, что, аналитики работают с требованиями, но не всегда знают, что есть отдельная дисциплина посвященная требованиям. Если читать только BABOK, то можно упустить важные вещи. Прокомментировала от себя и получилось многобукв, поэтому детали пришлось оставить в Дзене
Дзен | Статьи
О паре заблуждений в работе аналитика
Статья автора «ПроБА» в Дзене ✍: Хочу поделиться статьей о заблуждениях в работе аналитика. Добавила немного и от себя (со значком 🔎).
👍2
Как неудачное обозначение времени может оставить пользователя голодным
Приходилось вам работать над функционалом, где нужно показать на экране дату и время? Спорили с командой как это лучше сделать? Я живо вспомнила этот опыт как только увидела расписание в поезде. Фото прилагаю.
Ехала по маршруту, на котором некоторые станции находятся в разных часовых поясах. В этом расписании воплотили все, о чем аналитики часто говорят: и пересчитали время в часовой пояс станции, и показали сдвиг относительно UTC, и добавили сдвиг относительно Москвы… Тем не менее я весь маршрут ошибалась временем остановки, потому что забывала пересчитать время следующей станции относительно часового пояса предыдущей. Надеялась скоро купить еду на станции, а оказывалось, что еще часок нужно потерпеть или уже час как проехали :)
Когда внутри поезда движешься от станции к станции, не очень важно в каком часовом поясе каждая из них, а важно сколько часов и минут до следующей. Вариант на фото явно создан для встречающих на вокзалах, а не для тех, кто внутри вагона.
В следующий раз, когда будете обсуждать как показать дату и время, попробуйте «встать в тапки пользователя» и эмулировать контекст. Иначе казалось бы грамотное решение может кого-то оставить голодным :)
Приходилось вам работать над функционалом, где нужно показать на экране дату и время? Спорили с командой как это лучше сделать? Я живо вспомнила этот опыт как только увидела расписание в поезде. Фото прилагаю.
Ехала по маршруту, на котором некоторые станции находятся в разных часовых поясах. В этом расписании воплотили все, о чем аналитики часто говорят: и пересчитали время в часовой пояс станции, и показали сдвиг относительно UTC, и добавили сдвиг относительно Москвы… Тем не менее я весь маршрут ошибалась временем остановки, потому что забывала пересчитать время следующей станции относительно часового пояса предыдущей. Надеялась скоро купить еду на станции, а оказывалось, что еще часок нужно потерпеть или уже час как проехали :)
Когда внутри поезда движешься от станции к станции, не очень важно в каком часовом поясе каждая из них, а важно сколько часов и минут до следующей. Вариант на фото явно создан для встречающих на вокзалах, а не для тех, кто внутри вагона.
В следующий раз, когда будете обсуждать как показать дату и время, попробуйте «встать в тапки пользователя» и эмулировать контекст. Иначе казалось бы грамотное решение может кого-то оставить голодным :)
👍7👎1🔥1
#книжки
Метод McKinsey. Использование техник ведущих стратегических консультантов для решения личных и деловых задач
Итан Расиел. Год выхода: 2012
Недавно оценила еще одну книгу. Издание 2012 года, некоторые инструменты с тех пор заметно больше развились, а методы, которые автор называет «причудливыми», уже получили распространение. Особенно занимательно выглядят примеры из начала карьеры автора в 1989 году. Тем не менее ход мысли при идентификации проблем бизнеса и поиске решений не слишком изменился с тех пор. Я даже удивилась как мало по моим ощущениям изменилось во взаимодействии с заказчиками, 90% примеров совершенно из сегодняшнего дня.
О чем книга? Тезисно расскажу о полезном. Детально лучше читать в самой книге, в ней всего 150 страниц. Текст построен так, что можно выбирать любой раздел в любой части книги и будет понятно, о чем речь.
📍Показан принцип поиска решения в McKinsey. Метод со сложной аббревиатурой MECE - Mutually Exclusive, Collectively Exhaustive. Его применение начинается с составления перечня проблем и анализа зависимостей между ними. Затем от списка проблем идет переход к формированию исходной гипотезы.
📍Хорошо рассказано об инструментах работы с фактами и почему с ними важно работать. Предложенная проблема не всегда очевидна и «есть только один способ узнать насколько реальна проблема, решить которую вам предложили, - это копать глубже». В книге много полезных советов о том как очертить границы при работе с фактами и не оказаться перед задачей «выпарить океан, чтобы добыть ложку соли».
📍Бизнес-аналитикам будут интересны практические рекомендации по проведению исследований: проблемных интервью, мозговых штурмов, сессий с клиентами. Десятка два страниц о подготовке презентации решения и проведения встречи-презентации с клиентами.
Кому может быть полезно? Бизнес-аналитикам любого уровня опыта будет полезно. Опытным — разложить опыт «по полочкам», начинающим — научиться видеть те «полочки», куда постепенно ляжет опыт.
Метод McKinsey. Использование техник ведущих стратегических консультантов для решения личных и деловых задач
Итан Расиел. Год выхода: 2012
Недавно оценила еще одну книгу. Издание 2012 года, некоторые инструменты с тех пор заметно больше развились, а методы, которые автор называет «причудливыми», уже получили распространение. Особенно занимательно выглядят примеры из начала карьеры автора в 1989 году. Тем не менее ход мысли при идентификации проблем бизнеса и поиске решений не слишком изменился с тех пор. Я даже удивилась как мало по моим ощущениям изменилось во взаимодействии с заказчиками, 90% примеров совершенно из сегодняшнего дня.
О чем книга? Тезисно расскажу о полезном. Детально лучше читать в самой книге, в ней всего 150 страниц. Текст построен так, что можно выбирать любой раздел в любой части книги и будет понятно, о чем речь.
📍Показан принцип поиска решения в McKinsey. Метод со сложной аббревиатурой MECE - Mutually Exclusive, Collectively Exhaustive. Его применение начинается с составления перечня проблем и анализа зависимостей между ними. Затем от списка проблем идет переход к формированию исходной гипотезы.
📍Хорошо рассказано об инструментах работы с фактами и почему с ними важно работать. Предложенная проблема не всегда очевидна и «есть только один способ узнать насколько реальна проблема, решить которую вам предложили, - это копать глубже». В книге много полезных советов о том как очертить границы при работе с фактами и не оказаться перед задачей «выпарить океан, чтобы добыть ложку соли».
📍Бизнес-аналитикам будут интересны практические рекомендации по проведению исследований: проблемных интервью, мозговых штурмов, сессий с клиентами. Десятка два страниц о подготовке презентации решения и проведения встречи-презентации с клиентами.
Кому может быть полезно? Бизнес-аналитикам любого уровня опыта будет полезно. Опытным — разложить опыт «по полочкам», начинающим — научиться видеть те «полочки», куда постепенно ляжет опыт.
👍4
Причины использовать Process Mining
#что_почитать
Хочу поделиться статьей The Top 10 Reasons Business Analysts Should Leverage Process Mining.
Тема Process Mining уже давно «на хайпе». Кажется, перед нами еще одна технология, которая лишит нас работы, автор довольно спокойно рассуждает об этом.
О чем статья? Речь о роли Process Mining в бизнес-анализе, не о том как работает анализ цифровых следов.
📍Автор считает, что как и генеративные ИИ, Process Mining неизбежно изменит работу бизнес-аналитика. Вопрос только в том, чтобы найти правильное применение этой технологии.
📍Process Mining много обсуждается, но его реальное применение пока не развито. Считается, что этот инструмент заменит традиционный анализ процессов, в реальности, он его только дополнит.
📍Последние 30 с лишним лет мы автоматизировали процессы, где-то выполняя документирование, а где-то нет. В результате многие процессы, решения, бизнес правила и клиентские пути глубоко спрятаны в системах. За пределами «видимости» невозможно применять традиционные техники, чтобы проанализировать правила, процессы и пути.
📍С другой стороны, Process Mining поможет с процессами в рамках систем, но не поможет понять взаимодействие человека с человеком. Для этого по-прежнему нужны старые добрые интервью, опросы, воркшопы и пр.
📍Автор указал 10 полезностей от использования Process Mining. Здесь я сохраню интригу и адресую вас к самой статье. Если вам интересно получить перевод всех 10 пунктов, то дайте знать в коментариях и я вернусь к этой теме.
Дополню от себя. Мне еще ни разу не повезло участвовать в задачах с применением Process Mining. Думаю причины как раз те, из-за которых в статье написано, что «реальное применение пока не развито»
📍Process Mining начинается со сбора данных. При этом далеко не каждая система пишет адекватные логи, которые можно связать с экземплярами процесса.
📍Применение Process Mining имеет высокую цену. Понадобится настроить и систему, где автоматизирован процесс, и саму платформу, которая процесс отслеживает. Понадобится привлечь аналитиков и разработчиков, которые выполнят эту задачу, и занять инфраструктуру. Это целесообразно только для процессов где ожидаемый эффект превысит эти затраты.
📍Руководители, методологи и исполнители не всегда действительно хотят детально отслеживать свой процесс. Не видят ценности и опасаются кардинальных перемен.
#что_почитать
Хочу поделиться статьей The Top 10 Reasons Business Analysts Should Leverage Process Mining.
Тема Process Mining уже давно «на хайпе». Кажется, перед нами еще одна технология, которая лишит нас работы, автор довольно спокойно рассуждает об этом.
О чем статья? Речь о роли Process Mining в бизнес-анализе, не о том как работает анализ цифровых следов.
📍Автор считает, что как и генеративные ИИ, Process Mining неизбежно изменит работу бизнес-аналитика. Вопрос только в том, чтобы найти правильное применение этой технологии.
📍Process Mining много обсуждается, но его реальное применение пока не развито. Считается, что этот инструмент заменит традиционный анализ процессов, в реальности, он его только дополнит.
📍Последние 30 с лишним лет мы автоматизировали процессы, где-то выполняя документирование, а где-то нет. В результате многие процессы, решения, бизнес правила и клиентские пути глубоко спрятаны в системах. За пределами «видимости» невозможно применять традиционные техники, чтобы проанализировать правила, процессы и пути.
📍С другой стороны, Process Mining поможет с процессами в рамках систем, но не поможет понять взаимодействие человека с человеком. Для этого по-прежнему нужны старые добрые интервью, опросы, воркшопы и пр.
📍Автор указал 10 полезностей от использования Process Mining. Здесь я сохраню интригу и адресую вас к самой статье. Если вам интересно получить перевод всех 10 пунктов, то дайте знать в коментариях и я вернусь к этой теме.
Дополню от себя. Мне еще ни разу не повезло участвовать в задачах с применением Process Mining. Думаю причины как раз те, из-за которых в статье написано, что «реальное применение пока не развито»
📍Process Mining начинается со сбора данных. При этом далеко не каждая система пишет адекватные логи, которые можно связать с экземплярами процесса.
📍Применение Process Mining имеет высокую цену. Понадобится настроить и систему, где автоматизирован процесс, и саму платформу, которая процесс отслеживает. Понадобится привлечь аналитиков и разработчиков, которые выполнят эту задачу, и занять инфраструктуру. Это целесообразно только для процессов где ожидаемый эффект превысит эти затраты.
📍Руководители, методологи и исполнители не всегда действительно хотят детально отслеживать свой процесс. Не видят ценности и опасаются кардинальных перемен.
Что почитать про Process Mining & Task Mining?
#что_почитать
Если вам интересно еще больше погрузиться в тему, то делюсь ресурсами, которые встретила в разных уважаемых источниках, пока готовила предыдущий пост:
📍Книга, которую рекомендовали в докладе о Process Mining на Flow: Van der Aalst, W.P.M. Process Mining: Discovery Conformance and Enhancement of Business Processes. Springer, Heidenberg, 2011
📍Статья из 2018 года, но вполне актуальная Process Mining: технология анализа процессов или способ визуализации хаоса?
📍Статья Интеллектуальная автоматизация: с чего начать?
#что_почитать
Если вам интересно еще больше погрузиться в тему, то делюсь ресурсами, которые встретила в разных уважаемых источниках, пока готовила предыдущий пост:
📍Книга, которую рекомендовали в докладе о Process Mining на Flow: Van der Aalst, W.P.M. Process Mining: Discovery Conformance and Enhancement of Business Processes. Springer, Heidenberg, 2011
📍Статья из 2018 года, но вполне актуальная Process Mining: технология анализа процессов или способ визуализации хаоса?
📍Статья Интеллектуальная автоматизация: с чего начать?
BPMS.ru
Process Mining: технология анализа процессов или способ визуализации хаоса? - BPMS.ru
Оригинал статьи на портале PROКАЧЕСТВО Автор: Андрей Коптелов Одно из следствий автоматизации бизнес-процессов – возникновение больших массивов данных. А что будет, если их проанализировать? Можно получить реальную карту бизнес-процессов вашей организации.…
👍1
Об ошибках в работе аналитика
#что_почитать
Делюсь статьей 5 Ways to Avoid Repeating Past Project Mistakes и своими примерами к перечисленным в ней частым ошибкам аналитиков. В статье сформулировано пять таких ошибок:
🔸Неправильно понимают свою роль в команде
🔸Поздно привлекают заинтересованные стороны к задаче
🔸Слишком рано занимаются совершенствованием документации
🔸Держат в фокусе “что”, а не “почему”
🔸Допускают разрастание границ задачи
Прокомментировала каждый тезис «от себя», получилась статья в Дзене
#что_почитать
Делюсь статьей 5 Ways to Avoid Repeating Past Project Mistakes и своими примерами к перечисленным в ней частым ошибкам аналитиков. В статье сформулировано пять таких ошибок:
🔸Неправильно понимают свою роль в команде
🔸Поздно привлекают заинтересованные стороны к задаче
🔸Слишком рано занимаются совершенствованием документации
🔸Держат в фокусе “что”, а не “почему”
🔸Допускают разрастание границ задачи
Прокомментировала каждый тезис «от себя», получилась статья в Дзене
Дзен | Статьи
Об ошибках в работе аналитика
Статья автора «ПроБА» в Дзене ✍: Делюсь статьей 5 Ways to Avoid Repeating Past Project Mistakes в продолжение темы заблуждений в работе аналитика тут.
👍2❤1
Может ли Agile-коуч писать плохие пользовательские истории?
#user_story #agile
Майк Кон, автор книги ”Пользовательские истории: гибкая разработка программного обеспечения”, выложил для подписчиков своего блога богатый материал. Это примеры пользовательских историй, которые описывают функциональность ранней версии сайта Scrum Alliance. Они были созданы в начале 2004 года. Конечно, я запаслась переводом, чтобы использовать в учебных заданиях. Делюсь с вами частью материала. Выложила 7 страниц разных пользовательских историй на Яндекс.Диск.
Автор прокомментировал так: «Некоторые из них хорошие, некоторые не очень. Не смотря на это я даю полный набор, как демонстрацию того, что я считал тогда подходящим началом бэклога продукта для этого сайта.»
Вот несколько примеров. Как считаете, какие из них не очень хорошие?
📍Я как пользователь сайта, могу читать новости на домашней странице чтобы быть в курсе новостей agile.
📍Я как пользователь сайта, имею доступ к старым новостям, которых уже нет на домашней странице, для того чтобы просматривать то, что я помню из прошлого или то, о чем мне сообщили другие.
📍Я как пользователь сайта, могу отправлять новости редактору по эл.почте, чтобы их рассмотрели к публикации. (Заметка: это может быть просто ссылка на почту редактора)
📍Я как редактор сайта, могу указать такие даты на новости: Дата начала публикации, Дата зачисления в «старые новости», дата окончания публикации (Start Publishing Date, Old News Date, Stop Publishing Date соответственно), таким образом статьи публикуются в и в течении соответствующих дат. Эти даты означают когда новость начинает отображаться на сайте, когда она перестает отображаться на домашней странице и когда она будет удалена с сайта (может не быть удалена никогда).
📍Я как пользователь сайта могу подписаться на ленту новостей RSS, таким образом я легко буду информирован.
📍Я как редактор сайта, могу назначать приоритет новостям, чтобы обозначить какие статьи я хочу наиболее явно отобразить на сайте.
#user_story #agile
Майк Кон, автор книги ”Пользовательские истории: гибкая разработка программного обеспечения”, выложил для подписчиков своего блога богатый материал. Это примеры пользовательских историй, которые описывают функциональность ранней версии сайта Scrum Alliance. Они были созданы в начале 2004 года. Конечно, я запаслась переводом, чтобы использовать в учебных заданиях. Делюсь с вами частью материала. Выложила 7 страниц разных пользовательских историй на Яндекс.Диск.
Автор прокомментировал так: «Некоторые из них хорошие, некоторые не очень. Не смотря на это я даю полный набор, как демонстрацию того, что я считал тогда подходящим началом бэклога продукта для этого сайта.»
Вот несколько примеров. Как считаете, какие из них не очень хорошие?
📍Я как пользователь сайта, могу читать новости на домашней странице чтобы быть в курсе новостей agile.
📍Я как пользователь сайта, имею доступ к старым новостям, которых уже нет на домашней странице, для того чтобы просматривать то, что я помню из прошлого или то, о чем мне сообщили другие.
📍Я как пользователь сайта, могу отправлять новости редактору по эл.почте, чтобы их рассмотрели к публикации. (Заметка: это может быть просто ссылка на почту редактора)
📍Я как редактор сайта, могу указать такие даты на новости: Дата начала публикации, Дата зачисления в «старые новости», дата окончания публикации (Start Publishing Date, Old News Date, Stop Publishing Date соответственно), таким образом статьи публикуются в и в течении соответствующих дат. Эти даты означают когда новость начинает отображаться на сайте, когда она перестает отображаться на домашней странице и когда она будет удалена с сайта (может не быть удалена никогда).
📍Я как пользователь сайта могу подписаться на ленту новостей RSS, таким образом я легко буду информирован.
📍Я как редактор сайта, могу назначать приоритет новостям, чтобы обозначить какие статьи я хочу наиболее явно отобразить на сайте.