Доброе утро!
Вчера был вебинар, на котором разобрали особенности работы с интеграциями и собрали на miro-доске все ключевые моменты.
Важные моменты:
👉 User Stories в miro и в jira по интеграциям могут различаться
👉 При работе с интеграциями не надо сразу погружаться в технические детали
👉 Есть несколько вариантов структуры документации в Confluence
👉 Минимум два шаблона документации, которые можно применять для интеграций
👉 Важное про порядок: аналитика и документация, БД, конфигурация, авторизация запросов, детальные Use Case с указанием методов из документации, маппинг данных
👉 Открыли запись в поток практического курса Интеграции 🔑 2 активных месца работы на проекте раз в неделю, 6 месяцев доступа к курсу и пополнение вашего резюме минимум 6 хард-скиллами 😉
Для тех, кто не смог подключиться вчера или отключился раньше - сегодня проводим повтор!
🔑 Интеграции: как планировать и ставить задачи в Jira + Confluence
🗓 18 мая в 16:00 Мск
👉 ЗАРЕГИСТРИРОВАТЬСЯ
Новосибирск, Казахстан, Бали и другие города, я про вас помню ❤️
Вчера был вебинар, на котором разобрали особенности работы с интеграциями и собрали на miro-доске все ключевые моменты.
Важные моменты:
👉 User Stories в miro и в jira по интеграциям могут различаться
👉 При работе с интеграциями не надо сразу погружаться в технические детали
👉 Есть несколько вариантов структуры документации в Confluence
👉 Минимум два шаблона документации, которые можно применять для интеграций
👉 Важное про порядок: аналитика и документация, БД, конфигурация, авторизация запросов, детальные Use Case с указанием методов из документации, маппинг данных
👉 Открыли запись в поток практического курса Интеграции 🔑 2 активных месца работы на проекте раз в неделю, 6 месяцев доступа к курсу и пополнение вашего резюме минимум 6 хард-скиллами 😉
Для тех, кто не смог подключиться вчера или отключился раньше - сегодня проводим повтор!
🔑 Интеграции: как планировать и ставить задачи в Jira + Confluence
🗓 18 мая в 16:00 Мск
👉 ЗАРЕГИСТРИРОВАТЬСЯ
Новосибирск, Казахстан, Бали и другие города, я про вас помню ❤️
❤4
❗️Начинаем через 15 минут❗️
📹 Интеграции: как планировать и ставить задачи в Jira + Confluence
Присоединяйтесь по ссылке.
📹 Интеграции: как планировать и ставить задачи в Jira + Confluence
Присоединяйтесь по ссылке.
Друзья, всем привет! 🙌
Недавно мы рассказывали вам про технику формирования требований к ПО в формате User stories.
Напоминаем, что шаблон User story выглядит следующим образом:
1. Как (роль),
2. я хочу (выполнять задачу),
3. чтобы (достичь цель).
Например:
Как пользователь приложения для доставки продуктов, я хочу, чтобы приложение определяло мою геопозицию самостоятельно, чтобы мне не пришлось вводить адрес доставки вручную.
Но недостаточно просто формулировать историю по шаблону, ведь она всё равно может оставаться сложной для понимания. Важно, чтобы проектной команде было удобно оценивать историю в часах, планировать её в работу, проектировать и сравнивать конечный результат с изначально заявленным.
Для того, чтобы передавать в разработку истории, с которыми удобно работать, проверяйте их на соответствие определённым правилам или критерям.
Поговорим об INVEST-критерях для User stories 🌚 #hardGetAnalyst
Недавно мы рассказывали вам про технику формирования требований к ПО в формате User stories.
Напоминаем, что шаблон User story выглядит следующим образом:
1. Как (роль),
2. я хочу (выполнять задачу),
3. чтобы (достичь цель).
Например:
Как пользователь приложения для доставки продуктов, я хочу, чтобы приложение определяло мою геопозицию самостоятельно, чтобы мне не пришлось вводить адрес доставки вручную.
Но недостаточно просто формулировать историю по шаблону, ведь она всё равно может оставаться сложной для понимания. Важно, чтобы проектной команде было удобно оценивать историю в часах, планировать её в работу, проектировать и сравнивать конечный результат с изначально заявленным.
Для того, чтобы передавать в разработку истории, с которыми удобно работать, проверяйте их на соответствие определённым правилам или критерям.
Поговорим об INVEST-критерях для User stories 🌚 #hardGetAnalyst
👍4🌚1
Шаблон User Story и INVEST-критерии помогают написать историю так, чтобы она была одинаково понятна для всех участников процесса разработки. Благодаря этому оценить и реализовать ее получится гораздо эффективнее.
Согласно критериям, пользовательская история должна быть:
🔹Независимой
Independent
🔹Обсуждаемой
Negotiable
🔹Ценной
Valuable
🔹Оцениваемой
Estimable
🔹Масштабируемой
Sized Appropriately или Small
🔹Тестируемой
Testable
Разберём каждый критерий подробнее.
1️⃣ Независимая
Пользовательская история должна быть автономной в реализации. Это значит, что её проектирование не должно пересекаться с другими историями.
Например, вам нужно спроектировать функциональность для регистрации пользователя в приложении. Вы сформулировали две истории:
🔸Как пользователь приложения, я хочу иметь возможность указать свои ФИО, чтобы создать личный кабинет в приложении.
🔸Как пользователь приложения, я хочу иметь возможность указать свой номер телефона, чтобы создать личный кабинет в приложении.
В описанных историях сложно определить, с какой истории начать разработку, но зато очевидно, что эти истории похожи по логике реализации и пересекаются по функциональности: пользователь хочет указывать персональные данные при регистрации. А значит их можно объединить в одну:
👍 Как пользователь приложения, я хочу иметь возможность указать свои личные данные, чтобы создать личный кабинет в приложении.
2️⃣ Обсуждаемая
Пользовательская история — это результат коллективной работы проектной команды. Поэтому историю нужно записывать так, чтобы команде было что обсуждать.
❗️История не должна содержать точные указания на то, как её нужно реализовывать.
История должна включать только цель планируемых изменений и их ожидаемый результат.
👎 Как пользователь приложения, я хочу указывать для входа в личный кабинет адрес электронной почты, который интегрирован с личным кабинетом, чтобы быстрее авторизоваться.
👍 Как пользователь приложения, я хочу иметь возможность авторизоваться с помощью электронной почты, чтобы быстрее попадать в личный кабинет.
Согласно критериям, пользовательская история должна быть:
🔹Независимой
Independent
🔹Обсуждаемой
Negotiable
🔹Ценной
Valuable
🔹Оцениваемой
Estimable
🔹Масштабируемой
Sized Appropriately или Small
🔹Тестируемой
Testable
Разберём каждый критерий подробнее.
1️⃣ Независимая
Пользовательская история должна быть автономной в реализации. Это значит, что её проектирование не должно пересекаться с другими историями.
Например, вам нужно спроектировать функциональность для регистрации пользователя в приложении. Вы сформулировали две истории:
🔸Как пользователь приложения, я хочу иметь возможность указать свои ФИО, чтобы создать личный кабинет в приложении.
🔸Как пользователь приложения, я хочу иметь возможность указать свой номер телефона, чтобы создать личный кабинет в приложении.
В описанных историях сложно определить, с какой истории начать разработку, но зато очевидно, что эти истории похожи по логике реализации и пересекаются по функциональности: пользователь хочет указывать персональные данные при регистрации. А значит их можно объединить в одну:
👍 Как пользователь приложения, я хочу иметь возможность указать свои личные данные, чтобы создать личный кабинет в приложении.
2️⃣ Обсуждаемая
Пользовательская история — это результат коллективной работы проектной команды. Поэтому историю нужно записывать так, чтобы команде было что обсуждать.
❗️История не должна содержать точные указания на то, как её нужно реализовывать.
История должна включать только цель планируемых изменений и их ожидаемый результат.
👎 Как пользователь приложения, я хочу указывать для входа в личный кабинет адрес электронной почты, который интегрирован с личным кабинетом, чтобы быстрее авторизоваться.
👍 Как пользователь приложения, я хочу иметь возможность авторизоваться с помощью электронной почты, чтобы быстрее попадать в личный кабинет.
❤9🔥5👏3
В прошлый раз разобрали два критерия пользовательских историй – Независимость и Обсуждаемость.
Продолжаем со следующими двумя ⤵️
3️⃣ Ценная
Карточку истории можно назвать ценной, если она действительно приносит пользу заинтересованным лицам. Поэтому, создавая историю, нужно думать о её ценности для пользователей и заказчиков.
Зачастую ценность заключается в:
🔹уменьшении затрат бизнеса;
🔹увеличении его доходов;
🔹оптимизации процессов;
🔹улучшении сервиса для пользователя
и так далее.
Если при отказе от реализации истории не изменится ровным счётом ничего, то эту историю можно отложить, либо вообще от неё отказаться.
👎 Как пользователь приложения службы доставки посылок, я хочу указывать для входа в личный кабинет данные паспорта, чтобы у компании были данные о моих документах.
👍 Как пользователь приложения службы доставки посылок, я хочу иметь возможность указать паспортные данные в профиле, чтобы получать свои посылки без документов.
Продолжаем со следующими двумя ⤵️
3️⃣ Ценная
Карточку истории можно назвать ценной, если она действительно приносит пользу заинтересованным лицам. Поэтому, создавая историю, нужно думать о её ценности для пользователей и заказчиков.
Зачастую ценность заключается в:
🔹уменьшении затрат бизнеса;
🔹увеличении его доходов;
🔹оптимизации процессов;
🔹улучшении сервиса для пользователя
и так далее.
Если при отказе от реализации истории не изменится ровным счётом ничего, то эту историю можно отложить, либо вообще от неё отказаться.
👎 Как пользователь приложения службы доставки посылок, я хочу указывать для входа в личный кабинет данные паспорта, чтобы у компании были данные о моих документах.
👍 Как пользователь приложения службы доставки посылок, я хочу иметь возможность указать паспортные данные в профиле, чтобы получать свои посылки без документов.
❤4🤣3
4️⃣ Оцениваемая
История должна быть доступной для оценки затрачиваемых для неё ресурсов: усилий проектной команды в человекочасах.
❗️Не рекомендуется, чтобы одна пользовательская история превышала 80 часов разработки — большие и трудозатратные истории менее гибкие к изменениям.
Их границы могут со временем расширяться засчёт добавления новых требований, влияния изменений других процессов и так далее.
Проектной команде будет сложно оценить размер истории, если:
🔹ей не хватает знаний о предметной области или технологиях проектирования;
🔹история слишком объёмная.
Отслеживайте, чтобы в историях, которые вы описываете, не было «слепых пятен» или длинных конструкций.
👎 Как пользователь администраторского ПО, я хочу указывать статьи ДДС, проводки, а также коррекспондирующие счета в разделе «Бухгалтерия» для грамотного проведения оплат внутри системы.
👍 Как пользователь администраторского ПО, я хочу фиксировать движение денежных средств внутри компании, согласно Федеральному закону о бухгалтерском учёте.
В первой истории указана специализированная терминология. По сути, каждую указанную единицу нужно описывать отдельной историей. Но вторая история даёт ссылку на законодательство, в котором указаны все правила и сущности, на основании которых следует реализовать историю.
🤖Кстати, часть истории с указанием цели в этом случае можно опустить, ведь соблюдение законодательства уже является целью.
История должна быть доступной для оценки затрачиваемых для неё ресурсов: усилий проектной команды в человекочасах.
❗️Не рекомендуется, чтобы одна пользовательская история превышала 80 часов разработки — большие и трудозатратные истории менее гибкие к изменениям.
Их границы могут со временем расширяться засчёт добавления новых требований, влияния изменений других процессов и так далее.
Проектной команде будет сложно оценить размер истории, если:
🔹ей не хватает знаний о предметной области или технологиях проектирования;
🔹история слишком объёмная.
Отслеживайте, чтобы в историях, которые вы описываете, не было «слепых пятен» или длинных конструкций.
👎 Как пользователь администраторского ПО, я хочу указывать статьи ДДС, проводки, а также коррекспондирующие счета в разделе «Бухгалтерия» для грамотного проведения оплат внутри системы.
👍 Как пользователь администраторского ПО, я хочу фиксировать движение денежных средств внутри компании, согласно Федеральному закону о бухгалтерском учёте.
В первой истории указана специализированная терминология. По сути, каждую указанную единицу нужно описывать отдельной историей. Но вторая история даёт ссылку на законодательство, в котором указаны все правила и сущности, на основании которых следует реализовать историю.
🤖Кстати, часть истории с указанием цели в этом случае можно опустить, ведь соблюдение законодательства уже является целью.
👍5🔥3🤩1
5️⃣ Масштабируемая
Истории должны иметь масштаб (или размер), подходящий для использования на разных этапах разработки и для разных целей.
🔹 Истории высокого уровня реализуются для достижения бизнес-целей. Обычно они формулируются заказчиком и в таком виде поступают к аналитику.
🔹 Истории среднего уровня направлены на достижение целей заинтересованных лиц. Чаще всего формулируются пользователями.
🔹 Истории низкого уровня максимально детализированы. И именно их следует передавать в работу разработчикам.
Низкий уровень истории чаще всего появляется после декомпозиции историй среднего и высокого уровня.
Истории должны иметь масштаб (или размер), подходящий для использования на разных этапах разработки и для разных целей.
🔹 Истории высокого уровня реализуются для достижения бизнес-целей. Обычно они формулируются заказчиком и в таком виде поступают к аналитику.
🔹 Истории среднего уровня направлены на достижение целей заинтересованных лиц. Чаще всего формулируются пользователями.
🔹 Истории низкого уровня максимально детализированы. И именно их следует передавать в работу разработчикам.
Низкий уровень истории чаще всего появляется после декомпозиции историй среднего и высокого уровня.
🔥7👍3
Разберём примеры историй по уровням ⤵️
История высокого уровня:
🔸 Как директор компании, я хочу увеличить выручку компании от продажи товаров для отдыха, чтобы иметь больше возможностей для бизнеса.
Такую историю нельзя передавать в разработку, потому что вариаций решения для достижения бизнес-цели множество.
История среднего уровня:
🔸 Как пользователь, я хочу иметь возможность оплачивать покупки в приложении различными способами, чтобы выбирать удобный для меня способ оплаты в момент времени.
Такая история уже говорит о том, что именно необходимо внедрить – возможность оплатить покупки в приложении различными способами. Но какими?
История низкого уровня:
🔸 Как пользователь, я хочу иметь возможность оплачивать покупку наличными, чтобы оплачивать заказ в момент его получения.
🔸 Как пользователь, я хочу иметь возможность оплачивать покупку банковской картой, чтобы произвести оплату в момент оформления заказа.
Эти истории уже можно оценить для проектирования, а значит задача по масчштабированию до уровня разработки выполнена успешно ☑️
История высокого уровня:
🔸 Как директор компании, я хочу увеличить выручку компании от продажи товаров для отдыха, чтобы иметь больше возможностей для бизнеса.
Такую историю нельзя передавать в разработку, потому что вариаций решения для достижения бизнес-цели множество.
История среднего уровня:
🔸 Как пользователь, я хочу иметь возможность оплачивать покупки в приложении различными способами, чтобы выбирать удобный для меня способ оплаты в момент времени.
Такая история уже говорит о том, что именно необходимо внедрить – возможность оплатить покупки в приложении различными способами. Но какими?
История низкого уровня:
🔸 Как пользователь, я хочу иметь возможность оплачивать покупку наличными, чтобы оплачивать заказ в момент его получения.
🔸 Как пользователь, я хочу иметь возможность оплачивать покупку банковской картой, чтобы произвести оплату в момент оформления заказа.
Эти истории уже можно оценить для проектирования, а значит задача по масчштабированию до уровня разработки выполнена успешно ☑️
❤9
6️⃣ Тестируемая
Команда должна хорошо представлять, как проверить исполнимость истории. Нетестируемые истории (те, что нельзя проверить) по большей части возникают для нефункциональных требований.
👎 Как пользователь, я не хочу долго ждать создания личного кабинета, чтобы быстрее приступать к оформлению заказа в приложении.
👍 Как пользователь, я хочу, чтобы личный кабинет создавался не дольше двух секунд, чтобы быстрее приступать к оформлению заказа в приложении.
Первую историю проблематично тестировать из-за формулировки «долго», потому что каждый может тракотовать долготу по своему. Вторую историю мы сможем протестировать, а значит, она будет соответствовать последнему INVEST-критерию.
Подведём итог.
При формировании пользовательских историй старайтесь соблюсти два правила:
🔑 Стройте историю по шаблону:
Как [роль], я хочу [выполнить задачу], чтобы [достичь цель];
🔑 Соблюдайте INVEST-критерии в формулировке.
Благодаря этому вы и ваша команда сможете грамотно оценить и спланировать работу в проектировании ПО 😊
Команда должна хорошо представлять, как проверить исполнимость истории. Нетестируемые истории (те, что нельзя проверить) по большей части возникают для нефункциональных требований.
👎 Как пользователь, я не хочу долго ждать создания личного кабинета, чтобы быстрее приступать к оформлению заказа в приложении.
👍 Как пользователь, я хочу, чтобы личный кабинет создавался не дольше двух секунд, чтобы быстрее приступать к оформлению заказа в приложении.
Первую историю проблематично тестировать из-за формулировки «долго», потому что каждый может тракотовать долготу по своему. Вторую историю мы сможем протестировать, а значит, она будет соответствовать последнему INVEST-критерию.
Подведём итог.
При формировании пользовательских историй старайтесь соблюсти два правила:
🔑 Стройте историю по шаблону:
Как [роль], я хочу [выполнить задачу], чтобы [достичь цель];
🔑 Соблюдайте INVEST-критерии в формулировке.
Благодаря этому вы и ваша команда сможете грамотно оценить и спланировать работу в проектировании ПО 😊
🔥8🤩2
Друзья, всем привет!😊
Недавно мы рассказывали вам про INVEST-критерии для грамотной формулировки пользовательских историй (user stories). Предлагаем вам закрепить полученные знания и пройти КВИЗ 👀💡
Представьте, что вам необходимо проверить пользовательские истории, которые сформулировал ваш коллега-аналитик 🦸♀️🦸
Ознакомьтесь с условиями каждого вопроса и укажите, соответствует ли история заданному критерию.
Пока коллега несёт вам документацию, предлагаем отмотать сообщения выше и вспомнить про каждый из критериев 😉
Начинаем через два часа ⏰💥 #quizGetAnalyst
Недавно мы рассказывали вам про INVEST-критерии для грамотной формулировки пользовательских историй (user stories). Предлагаем вам закрепить полученные знания и пройти КВИЗ 👀💡
Представьте, что вам необходимо проверить пользовательские истории, которые сформулировал ваш коллега-аналитик 🦸♀️🦸
Ознакомьтесь с условиями каждого вопроса и укажите, соответствует ли история заданному критерию.
Пока коллега несёт вам документацию, предлагаем отмотать сообщения выше и вспомнить про каждый из критериев 😉
Начинаем через два часа ⏰💥 #quizGetAnalyst
👍3🔥2
1️⃣ Внимательно изучите историю:
🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.
🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.
2️⃣ Проверим выполнимость критерия масштабируемости.
Вы уже знаете, что в разработку рекомендуется передавать истории низкого уровня, которые максимально детализированы.
Вернёмся к нашей истории про хранение персональных данных:
🔸 Как пользователь, я хочу, чтобы мои персональные данные хранились в системе в зашифрованном виде, чтобы предотвратить утечку данных.
Вы уже знаете, что в разработку рекомендуется передавать истории низкого уровня, которые максимально детализированы.
Вернёмся к нашей истории про хранение персональных данных:
🔸 Как пользователь, я хочу, чтобы мои персональные данные хранились в системе в зашифрованном виде, чтобы предотвратить утечку данных.
Укажите, к какому уровню масштабируемости относится эта история.
Постарайтесь определить, достаточно ли информации указано для того, чтобы разработчик смог спроектировать конкретное решение.
Постарайтесь определить, достаточно ли информации указано для того, чтобы разработчик смог спроектировать конкретное решение.
Anonymous Quiz
25%
Высокий уровень
70%
Средний уровень
6%
Низкий уровень
И финальный вопрос (в чём сила?) 👀
3️⃣ Внимательно изучите историю:
🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.
3️⃣ Внимательно изучите историю:
🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.
😁1
💥 БОНУСНЫЙ ВОПРОС для самых умниц
(то есть для всех вас) 😊🖤
Представьте, что в бэклоге продукта две истории:
🔸 Как пользователь, я хочу привязывать банковскую карту к профилю, чтобы удобнее оплачивать заказы в приложении;
🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.
(то есть для всех вас) 😊🖤
Представьте, что в бэклоге продукта две истории:
🔸 Как пользователь, я хочу привязывать банковскую карту к профилю, чтобы удобнее оплачивать заказы в приложении;
🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.
Друзья, очень важно не забывать, что история может совсем не соотвествовать INVEST-критериям (не надо так), а может соответствовать только части из них.
Разберём на примере:
🔹 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных
☝️ История явно не выполняет критерий оцениваемости, потому что нет информации о том, каким способом необходимо зашифровать номер банковской карты.
✌️Но эту историю можно протестировать, банально проведя анализ того, какие данные указывает клиент и как они отображаются в системе и на интерфейсе пользователя.
Задача бизнес- и системного аналитика как раз и заключается в том, чтобы сформировать конечное пользовательское требование в истории так, чтобы все INVEST-критерии были учтены.
Поэтому очень круто, что мы можем ошибаться на этапе обучения, чтобы потом меньше ошибаться на реальных проектах, верно? 🙃
Вот такие вот дела. Как вам КВИЗ, кстати?
Если такой формат для закрепления материала понравился, ставьте реакции – будем почаще запускать 😊
Разберём на примере:
🔹 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных
☝️ История явно не выполняет критерий оцениваемости, потому что нет информации о том, каким способом необходимо зашифровать номер банковской карты.
✌️Но эту историю можно протестировать, банально проведя анализ того, какие данные указывает клиент и как они отображаются в системе и на интерфейсе пользователя.
Задача бизнес- и системного аналитика как раз и заключается в том, чтобы сформировать конечное пользовательское требование в истории так, чтобы все INVEST-критерии были учтены.
Поэтому очень круто, что мы можем ошибаться на этапе обучения, чтобы потом меньше ошибаться на реальных проектах, верно? 🙃
Вот такие вот дела. Как вам КВИЗ, кстати?
Если такой формат для закрепления материала понравился, ставьте реакции – будем почаще запускать 😊
🔥13👍9