Учусь ли я после 9+ лет в анализе и чему?
Учиться — это акутально, нужно всегда и никогда не поздно.
IT — это та сфера, которая быстро развивается и не стоит на месте. С того времени, когда она только стала популярна в мире, многое уже поменялось. Каждый час появляются новые подходы, практики, методики, теории, которые нужно проверять и исследовать. Поэтому в любой профессии в IT всегда будет чему поучиться, каким бы опытом или багажом специалист не обладал.
Моя точка зрения такая, что учиться нужно всегда.
Я продолжаю учиться публичным выступлениям, ораторскому искусству, навыку доносить информацию, мысли, потому что через софты можно расширять свою зону ответственности, хард-скиллы. И увеличивать область применения hard скиллов аналитических.
Еще учусь организаторским способностям с точки зрения организации встреч, мастер-классов.
Ну и всегда возникают какие-то новые подходы или методологии, которые требуют изучения как в анализе, так и в разработке в целом. То есть могут появляться новые подходы в разработке, как в свое время появились дизайн-мышление, JTBD, важно умение адаптировать гибкие подходы под конкретный тип бизнеса.
Учиться приходится как софтовым, так и хардовым навыкам, но эффективнее смотреть на чужой опыт плюс ретроспектировать собственный 😉
Учиться — это акутально, нужно всегда и никогда не поздно.
IT — это та сфера, которая быстро развивается и не стоит на месте. С того времени, когда она только стала популярна в мире, многое уже поменялось. Каждый час появляются новые подходы, практики, методики, теории, которые нужно проверять и исследовать. Поэтому в любой профессии в IT всегда будет чему поучиться, каким бы опытом или багажом специалист не обладал.
Моя точка зрения такая, что учиться нужно всегда.
Я продолжаю учиться публичным выступлениям, ораторскому искусству, навыку доносить информацию, мысли, потому что через софты можно расширять свою зону ответственности, хард-скиллы. И увеличивать область применения hard скиллов аналитических.
Еще учусь организаторским способностям с точки зрения организации встреч, мастер-классов.
Ну и всегда возникают какие-то новые подходы или методологии, которые требуют изучения как в анализе, так и в разработке в целом. То есть могут появляться новые подходы в разработке, как в свое время появились дизайн-мышление, JTBD, важно умение адаптировать гибкие подходы под конкретный тип бизнеса.
Учиться приходится как софтовым, так и хардовым навыкам, но эффективнее смотреть на чужой опыт плюс ретроспектировать собственный 😉
❤🔥10🔥1
Forwarded from Лариса Дансарунова, Author @ithumanwork
This media is not supported in your browser
VIEW IN TELEGRAM
🔥4
Всем привет-привет!
Надеюсь, у всех был продуктивный понедельник. Он уже заканчивается, а я только выхожу на связь. Думаю, вы заметили, откуда я вещаю 😁
Вот таким вот не слишком уж необычным образом пытаюсь ввести себя в продуктивное русло, чего и всем желаю.
Как у вас?
👍 — тип-топ
🥲 — дайте ещё шашлыка
Надеюсь, у всех был продуктивный понедельник. Он уже заканчивается, а я только выхожу на связь. Думаю, вы заметили, откуда я вещаю 😁
Вот таким вот не слишком уж необычным образом пытаюсь ввести себя в продуктивное русло, чего и всем желаю.
Как у вас?
👍 — тип-топ
🥲 — дайте ещё шашлыка
👍8😢3
Из чего состоит техническое собеседование для БА?
Техническое собеседование или оценка навыков бизнес-аналитика проводится в 3-4 основных форматах:
Диалог или разговор об опыте
Распространенный и простой формат. Начинается с первых минут собеседования, когда интервьюер первым вопросом задает тон. Спрашивают про опыт, просят рассказать про непростые ситуации на проектах и то, как вы из них выходили. И как только вы начинаете приближаться к интересному, начинаются уточняющие вопросы с углублением в тему. Время от времени переводят тему на используемые инструменты или практики, спрашивают какие выводы сделаны из опыта. Такой вот способ понять с чем вы сталкивались в прошлом и как выходили из реальных конфликтов, понимали ли ценность, которую нужно было преследовать.
Формат экзамена
Знаком нам всем со школы. Похоже на вопрос-ответ, но в строгих и стрессовых обстоятельствах. Сухо гоняют по теоретическим вопросам и не дают никакой обратной связи. Дал академическое определение — молодец. Не дал — понятно, идем дальше. Причем при таком формате вопросы часто абсолютно никак не связаны с опытом, а только с теорией.
Кейс-интервью
Используется реже, а иногда не совсем умело. Вам предложат обобщенные вводные данные и озвучат цель, а вот как дойти до этой цели предстоит придумать и при этом рассуждать вслух. Вводных не хватает и первым делом, нужно их выявить и только потом планировать действия, которые приведут к решению.
Решение задач онлайн или применение спец. платформ для решения задач в режиме реального времени
Используется крайне редко, потому как затратнее. Приглашают в кабинет или зум-комнату, дают область для работы и условия задач. В случае аналитиков, задачи моделирования процессов «под присмотром» интервьюеров. Причем нотация моделирования может быть строго задана изначально.
Это основные форматы технических собеседований.
Если пост наберет 20 реакций, дальше расскажу какие темы и вопросы точно будут на технических собеседованиях для бизнес-аналитика 😉
Техническое собеседование или оценка навыков бизнес-аналитика проводится в 3-4 основных форматах:
Диалог или разговор об опыте
Распространенный и простой формат. Начинается с первых минут собеседования, когда интервьюер первым вопросом задает тон. Спрашивают про опыт, просят рассказать про непростые ситуации на проектах и то, как вы из них выходили. И как только вы начинаете приближаться к интересному, начинаются уточняющие вопросы с углублением в тему. Время от времени переводят тему на используемые инструменты или практики, спрашивают какие выводы сделаны из опыта. Такой вот способ понять с чем вы сталкивались в прошлом и как выходили из реальных конфликтов, понимали ли ценность, которую нужно было преследовать.
Формат экзамена
Знаком нам всем со школы. Похоже на вопрос-ответ, но в строгих и стрессовых обстоятельствах. Сухо гоняют по теоретическим вопросам и не дают никакой обратной связи. Дал академическое определение — молодец. Не дал — понятно, идем дальше. Причем при таком формате вопросы часто абсолютно никак не связаны с опытом, а только с теорией.
Кейс-интервью
Используется реже, а иногда не совсем умело. Вам предложат обобщенные вводные данные и озвучат цель, а вот как дойти до этой цели предстоит придумать и при этом рассуждать вслух. Вводных не хватает и первым делом, нужно их выявить и только потом планировать действия, которые приведут к решению.
Решение задач онлайн или применение спец. платформ для решения задач в режиме реального времени
Используется крайне редко, потому как затратнее. Приглашают в кабинет или зум-комнату, дают область для работы и условия задач. В случае аналитиков, задачи моделирования процессов «под присмотром» интервьюеров. Причем нотация моделирования может быть строго задана изначально.
Это основные форматы технических собеседований.
Если пост наберет 20 реакций, дальше расскажу какие темы и вопросы точно будут на технических собеседованиях для бизнес-аналитика 😉
👍37
Кто я для кого я пишу?
В феврале вас было ровно на 124 человека меньше, а в посте «обо мне» не было моей фотографии. Вы подписались на мой канал, возможно, не зная меня, видели меня только на кружочках или до сих пор не понимаете кто ведет этот канал. Пора исправлять.
Меня зовут Лариса. Я бизнес аналитик в ИТ индустрии. Наставник в Яндекс.Практикуме и эксперт в Эйч.
Мой опыт:
Работала в заказной, продуктовой разработке и консалтинге. В сферах edtech, medtech, fintech, e-commerce, govtech. Развивала как отдельных аналитиков, так и отдел анализа. Нанимала ит-специалистов и сама не раз искала работу, поэтому понимаю как устроен найм в ИТ компаниях и как строить траекторию поиска, чтобы попасть в компанию мечты.
Пишу для тех, кто заинтересован подходами бизнес анализа и готов применять их в своей работе, про то, как устроен рынок труда в ИТ, как вести поиски работы и готовиться к собеседованиям на позиции аналитиков.
Я в цифрах:
10+ опыта в ИТ
> 7-ми команд запустила
> 20 человек в управлении
> 100 консультаций на Эйч
> 200 часов консультаций собственной практики
Я в названиях:
EPAM, ВТБ, TeDo ex.PWC, LetuTech — компании, где работала
Альфа-Банк, Epam Systems (Грузия), Mind Box, Anderson Lab, e.l.f Beauty (Британия), X5 и др. — компании, куда помогла трудоустроиться своим менти
GetMentor, Эйч — где я ментор
DUMP — где я спикер
Связь со мной — @ldansarunova
В феврале вас было ровно на 124 человека меньше, а в посте «обо мне» не было моей фотографии. Вы подписались на мой канал, возможно, не зная меня, видели меня только на кружочках или до сих пор не понимаете кто ведет этот канал. Пора исправлять.
Меня зовут Лариса. Я бизнес аналитик в ИТ индустрии. Наставник в Яндекс.Практикуме и эксперт в Эйч.
Мой опыт:
Работала в заказной, продуктовой разработке и консалтинге. В сферах edtech, medtech, fintech, e-commerce, govtech. Развивала как отдельных аналитиков, так и отдел анализа. Нанимала ит-специалистов и сама не раз искала работу, поэтому понимаю как устроен найм в ИТ компаниях и как строить траекторию поиска, чтобы попасть в компанию мечты.
Пишу для тех, кто заинтересован подходами бизнес анализа и готов применять их в своей работе, про то, как устроен рынок труда в ИТ, как вести поиски работы и готовиться к собеседованиям на позиции аналитиков.
Я в цифрах:
10+ опыта в ИТ
> 7-ми команд запустила
> 20 человек в управлении
> 100 консультаций на Эйч
> 200 часов консультаций собственной практики
Я в названиях:
EPAM, ВТБ, TeDo ex.PWC, LetuTech — компании, где работала
Альфа-Банк, Epam Systems (Грузия), Mind Box, Anderson Lab, e.l.f Beauty (Британия), X5 и др. — компании, куда помогла трудоустроиться своим менти
GetMentor, Эйч — где я ментор
DUMP — где я спикер
Связь со мной — @ldansarunova
👍10🔥7
Хорошие, плохие требования
На тему плохих, хороших требований хочется порассуждать с двух сторон или двух «шляп», если вы меня понимаете.)
Когда я размышляю как человек со своими идеями, то в голову приходят банальная адекватность и практическая применимость, например:
— Однозначность: хорошие требования должны быть четкими и однозначными. Это позволяет избежать двусмысленностей и недоразумений на всех этапах проекта.
— Достоверность: требования должны быть основаны на реальных потребностях бизнеса и клиентов. Их цель – точно отражать задачи и ожидания заказчика.
— Измеримость: хорошие требования могут быть измерены и проверены на соответствие. Они должны быть конкретными и недвусмысленными.
— Полнота: важно учесть все необходимые детали и особенности требований, чтобы избежать дополнительных корректировок и уточнений в будущем.
— Гибкость: хорошие требования должны быть гибкими и адаптивными к изменениям. Часто требования могут меняться в процессе работы над проектом, и важно иметь возможность быстро и эффективно их корректировать.
Но, надевая вторую «шляпу» эксперта, вспоминаешь про проф. литературу и сухие правила.
Кто помнит свойства требования, пишите в комментарии — обсудим.)
На тему плохих, хороших требований хочется порассуждать с двух сторон или двух «шляп», если вы меня понимаете.)
Когда я размышляю как человек со своими идеями, то в голову приходят банальная адекватность и практическая применимость, например:
— Однозначность: хорошие требования должны быть четкими и однозначными. Это позволяет избежать двусмысленностей и недоразумений на всех этапах проекта.
— Достоверность: требования должны быть основаны на реальных потребностях бизнеса и клиентов. Их цель – точно отражать задачи и ожидания заказчика.
— Измеримость: хорошие требования могут быть измерены и проверены на соответствие. Они должны быть конкретными и недвусмысленными.
— Полнота: важно учесть все необходимые детали и особенности требований, чтобы избежать дополнительных корректировок и уточнений в будущем.
— Гибкость: хорошие требования должны быть гибкими и адаптивными к изменениям. Часто требования могут меняться в процессе работы над проектом, и важно иметь возможность быстро и эффективно их корректировать.
Но, надевая вторую «шляпу» эксперта, вспоминаешь про проф. литературу и сухие правила.
Кто помнит свойства требования, пишите в комментарии — обсудим.)
👍5
Золотой кандидат
Сегодня настроение рассказать о предпосылках моей менторской программы по поиску работы для аналитиков.
Был 20-ый год. Я впервые систематически стала принимать участие в найме сотрудников в мои команды.
Тогда набирали не только аналитиков, это была больша-а-а-ая команда по ма-а-а-аленькой фиче в мобильном приложении синего банка.
Десятками отсматривала резюме, с единицами, но каждый день проводила собеседования. Еще верила в мифическую и повсеместную конструктивность и думала, что резюме — это все что нужно для понимания подойдет человек в мою команду или нет. Наивно, правда?
И вот мы сидим с Product Owner в зуме и ждем кандидата, на которого возложили надежды. Нам так понравилось его резюме, казалось — это идеальный кандидат. Разработчик, который работал в fintech, лидировал трех других разработчиков, умеет проводить Agile-события и тд. Не кандидат, а золото.
После 10 минут мы поняли — фейк. Он не мог связать двух слов: ни про Agile, ни про себя и свой опыт. Причем буквально! Это не та история, где человек разволновался и не мог понять чего от него ждут. Человек написал все популярные слова в резюме, но на самом деле этим не занимался.
Отличная иллюстрация почему сейчас при откликах или приглашениях в первую очередь опрашивают HR. Они служат в том числе для того, чтобы понять сможете вы подтвердить свой опыт хотя бы рассказом или нет. И только после формального аппрува допустят до руководителя.
Сегодня настроение рассказать о предпосылках моей менторской программы по поиску работы для аналитиков.
Был 20-ый год. Я впервые систематически стала принимать участие в найме сотрудников в мои команды.
Тогда набирали не только аналитиков, это была больша-а-а-ая команда по ма-а-а-аленькой фиче в мобильном приложении синего банка.
Десятками отсматривала резюме, с единицами, но каждый день проводила собеседования. Еще верила в мифическую и повсеместную конструктивность и думала, что резюме — это все что нужно для понимания подойдет человек в мою команду или нет. Наивно, правда?
И вот мы сидим с Product Owner в зуме и ждем кандидата, на которого возложили надежды. Нам так понравилось его резюме, казалось — это идеальный кандидат. Разработчик, который работал в fintech, лидировал трех других разработчиков, умеет проводить Agile-события и тд. Не кандидат, а золото.
После 10 минут мы поняли — фейк. Он не мог связать двух слов: ни про Agile, ни про себя и свой опыт. Причем буквально! Это не та история, где человек разволновался и не мог понять чего от него ждут. Человек написал все популярные слова в резюме, но на самом деле этим не занимался.
Отличная иллюстрация почему сейчас при откликах или приглашениях в первую очередь опрашивают HR. Они служат в том числе для того, чтобы понять сможете вы подтвердить свой опыт хотя бы рассказом или нет. И только после формального аппрува допустят до руководителя.
👍5
Очень хороший пример интересных проектов, когда аналитик расширяет свои навыки.)
https://habr.com/ru/articles/803983/
https://habr.com/ru/articles/803983/
Хабр
Что делать, если твой заказчик — весы, или Как заговорить на одном языке с бытовой техникой
Меня зовут Алексей Плаксин, я системный аналитик в компании KODE и сейчас расскажу вам, как делал реверс-инжиниринг бытовой техники. Однажды к нам пришел крупный бренд бытовой техники, который в том...
👍1
Техническое собеседование для БА: какие вопросы и темы?
Вы молодцы — поставили больше 20 реакций на прошлый пост, а я пишу продолжение.
Вопросы для БА можно разделить на 4 группы:
Определение бизнес-требований
Могут подобрать банальные вопросы из разряда:
— Какие методики и инструменты вы используете/знаете для сбора и анализа бизнес-требований?
— Как вы определяете приоритеты бизнес-требований и каким образом они связаны с целями бизнеса?
— Как вы взаимодействуете с заказчиками и заинтересованными сторонами для выявления и уточнения бизнес-требований?
— Какие действия вы предпринимаете, если бизнес-требования конфликтуют друг с другом или с техническими ограничениями?
Тут же могут быть вопросы про виды стандартов или документации.
Умение работать с базами данных
Здесь хотят знать ваш уровень владения SQL, понимание структуры БД и моделирования. Спросят, например:
— Какие СУБД вы использовали?
— Какие типы соединений (join) в SQL вы знаете и в каких случаях их следует применять?
— Каким образом вы оптимизируете запросы к базам данных для улучшения производительности?
— Приходилось ли строить модели данных?
Моделирование процессов
Вопросы, направленные на понимание того, сколько нотаций вы знаете, сколькими из них владеете, действительно ли умеете моделировать.
— Какие инструменты вы используете для моделирования бизнес-процессов?
— Какие нотации вы знаете для моделирования бизнес-процессов и в каких случаях их следует использовать?
— Как вы проводите анализ и оптимизацию бизнес-процессов на основе моделей?
— Как вы обеспечиваете взаимодействие между заинтересованными сторонами в процессе моделирования бизнес-процессов?
Жизненный цикл ПО
Блок неоднозначный и широкий. Сюда попадают вопросы, несвязаные с предыдущими темами, но напрямую указывают на понимание процесса разработки, архитектуры и роли БА в этих вещах. Например:
— Какую роль бизнес-аналитик играет в процессе создания архитектуры ПО?
— Какие методологии разработки ПО вы знаете и применяли?
— Каким образом вы взаимодействуете с другими членами команды при проектировании архитектуры?
— Какова роль бизнес-аналитика в процессе внедрения разработанного ПО?
ВАЖНО!
Все примеры вопросов подходят только уровня Стажер или Джун. Для более высоких грейдов вопросы более точечные и включают названия конкретных инструментов или методов.
И давайте снова будем друг другу полезны.
Если пост наберет 50 реакций, расскажу какие темы и вопросы точно будут для Миддлов 😉
Вы молодцы — поставили больше 20 реакций на прошлый пост, а я пишу продолжение.
Вопросы для БА можно разделить на 4 группы:
Определение бизнес-требований
Могут подобрать банальные вопросы из разряда:
— Какие методики и инструменты вы используете/знаете для сбора и анализа бизнес-требований?
— Как вы определяете приоритеты бизнес-требований и каким образом они связаны с целями бизнеса?
— Как вы взаимодействуете с заказчиками и заинтересованными сторонами для выявления и уточнения бизнес-требований?
— Какие действия вы предпринимаете, если бизнес-требования конфликтуют друг с другом или с техническими ограничениями?
Тут же могут быть вопросы про виды стандартов или документации.
Умение работать с базами данных
Здесь хотят знать ваш уровень владения SQL, понимание структуры БД и моделирования. Спросят, например:
— Какие СУБД вы использовали?
— Какие типы соединений (join) в SQL вы знаете и в каких случаях их следует применять?
— Каким образом вы оптимизируете запросы к базам данных для улучшения производительности?
— Приходилось ли строить модели данных?
Моделирование процессов
Вопросы, направленные на понимание того, сколько нотаций вы знаете, сколькими из них владеете, действительно ли умеете моделировать.
— Какие инструменты вы используете для моделирования бизнес-процессов?
— Какие нотации вы знаете для моделирования бизнес-процессов и в каких случаях их следует использовать?
— Как вы проводите анализ и оптимизацию бизнес-процессов на основе моделей?
— Как вы обеспечиваете взаимодействие между заинтересованными сторонами в процессе моделирования бизнес-процессов?
Жизненный цикл ПО
Блок неоднозначный и широкий. Сюда попадают вопросы, несвязаные с предыдущими темами, но напрямую указывают на понимание процесса разработки, архитектуры и роли БА в этих вещах. Например:
— Какую роль бизнес-аналитик играет в процессе создания архитектуры ПО?
— Какие методологии разработки ПО вы знаете и применяли?
— Каким образом вы взаимодействуете с другими членами команды при проектировании архитектуры?
— Какова роль бизнес-аналитика в процессе внедрения разработанного ПО?
ВАЖНО!
Все примеры вопросов подходят только уровня Стажер или Джун. Для более высоких грейдов вопросы более точечные и включают названия конкретных инструментов или методов.
И давайте снова будем друг другу полезны.
Если пост наберет 50 реакций, расскажу какие темы и вопросы точно будут для Миддлов 😉
❤41
Выложила видео на Ютуб
Резюме бизнес аналитика: разбираю резюме опытного аналитика и даю рекомендации.
Благодарю Веронику за предоставленные резюме на РУ и EN версии.
Полезные тайминги:
1:00 — резюме на русском
2:25 — желаемая должность
5:00 — опыт работы
10:02 — достижения
17:30 — совмещения работ
29:34 — про нерелевантный опыт
32:25 — образование
34:08 — навыки
38:53 — резюме на английском
Смотреть тут — https://youtu.be/n_RbTQ58VXA?si=YZWxAqJeWRDQ_8P1&t=3
Резюме бизнес аналитика: разбираю резюме опытного аналитика и даю рекомендации.
Благодарю Веронику за предоставленные резюме на РУ и EN версии.
Полезные тайминги:
1:00 — резюме на русском
2:25 — желаемая должность
5:00 — опыт работы
10:02 — достижения
17:30 — совмещения работ
29:34 — про нерелевантный опыт
32:25 — образование
34:08 — навыки
38:53 — резюме на английском
Смотреть тут — https://youtu.be/n_RbTQ58VXA?si=YZWxAqJeWRDQ_8P1&t=3
❤10🥰1
Эфиру быть
Всем привет-привет, хорошего, продуктивного дня.
У меня вчера был прямой эфир в Карьерном центре Яндекс.Практикума. Проводила тестовое техническое собеседование для БА. Было много вопросов, разбирали почему могут отказывать, сколько отказов можно получать, из-за чего они появляются на горизонте, как HR могут скрывать некоторые вещи, о которых мы можем догадываться и многое другое.
На этом фоне я подумала, может быть, нам с вами тоже провести такой эфир.
Оставляйте вопросы по трудоустройству в комментариях. Разберём на эфире 26 мая в 18:00.
Всем привет-привет, хорошего, продуктивного дня.
У меня вчера был прямой эфир в Карьерном центре Яндекс.Практикума. Проводила тестовое техническое собеседование для БА. Было много вопросов, разбирали почему могут отказывать, сколько отказов можно получать, из-за чего они появляются на горизонте, как HR могут скрывать некоторые вещи, о которых мы можем догадываться и многое другое.
На этом фоне я подумала, может быть, нам с вами тоже провести такой эфир.
Оставляйте вопросы по трудоустройству в комментариях. Разберём на эфире 26 мая в 18:00.
❤9🔥1
Forwarded from Лариса Дансарунова, Author @ithumanwork
This media is not supported in your browser
VIEW IN TELEGRAM
🔥4❤🔥1
Критерии приемки или Acceptance Criteria
Вижу посты про критерии приемки, но почему-то все пишут только про US. Расскажу на каких еще уровнях работы БА они могут возникать.
Acceptance criteria или критерии приемки определяют условия, необходимые выполнить, чтобы считать определенный процесс, функциональность или продукт завершенным и готовым для передачи заказчику или другому пользователю.
В рамках жизненного цикла ПО между этапами «Тестирование» и «Внедрение» проводят серию встреч по его сдаче. Может происходить по предусмотренному формату в виде ПСИ, для которых пишутся ПМИ и акты приема-передачи ПО, а могут — упрощенные форматы.
https://babok-school.ru/blog/programma-i-metodika-ispitanyi-as/
В актах или ПМИ и прописывают общие критерии или условия, которым должно соответствовать ПО или отдельные функции.
Следующий уровень — работа с требованиями и их постановкой в виде задач разработчикам (непосредственно программистам).
В таком случае, критерии могут принимать формат DOR (definition of ready) или DOD (definition of done).
https://babok-school.ru/blog/definition-concepts-and-acceptance-criteria-from-babok/
И третий уровень работ — работа с User Story.
https://habr.com/ru/companies/X5Tech/articles/723742/
А вот подходов к написанию критериев приемки для US пока существует два:
1. Сценарно-ориентированный или подход по Геркину (https://systems.education/acceptance_criteria_userstory#script)
2. Чек-листы. Простой список правил или условий, которые должны быть выполнены для того, чтобы посчитать US выполненной и корректно работающей.
Вижу посты про критерии приемки, но почему-то все пишут только про US. Расскажу на каких еще уровнях работы БА они могут возникать.
Acceptance criteria или критерии приемки определяют условия, необходимые выполнить, чтобы считать определенный процесс, функциональность или продукт завершенным и готовым для передачи заказчику или другому пользователю.
В рамках жизненного цикла ПО между этапами «Тестирование» и «Внедрение» проводят серию встреч по его сдаче. Может происходить по предусмотренному формату в виде ПСИ, для которых пишутся ПМИ и акты приема-передачи ПО, а могут — упрощенные форматы.
https://babok-school.ru/blog/programma-i-metodika-ispitanyi-as/
В актах или ПМИ и прописывают общие критерии или условия, которым должно соответствовать ПО или отдельные функции.
Следующий уровень — работа с требованиями и их постановкой в виде задач разработчикам (непосредственно программистам).
В таком случае, критерии могут принимать формат DOR (definition of ready) или DOD (definition of done).
https://babok-school.ru/blog/definition-concepts-and-acceptance-criteria-from-babok/
И третий уровень работ — работа с User Story.
https://habr.com/ru/companies/X5Tech/articles/723742/
А вот подходов к написанию критериев приемки для US пока существует два:
1. Сценарно-ориентированный или подход по Геркину (https://systems.education/acceptance_criteria_userstory#script)
💩 Given (Дано): чёткое описание контекста, состояние системы в начальный момент времени💩 When (Когда): действие, которое выполняет пользователь или система💩 Then (Тогда): ожидаемый результат
2. Чек-листы. Простой список правил или условий, которые должны быть выполнены для того, чтобы посчитать US выполненной и корректно работающей.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Эфир
Друзья, напоминаю о сегодняшнем эфире, где разбираю ваши вопросы.
Будем общаться в комментариях под этим постом.
В 18:00 начинаем.
Друзья, напоминаю о сегодняшнем эфире, где разбираю ваши вопросы.
Будем общаться в комментариях под этим постом.
В 18:00 начинаем.
❤4
Друзья мои!
Вчера мне очень понравилось с вами общаться.) Это был полезный для вас и приятный для меня эфир. 😊
Думаю, мы еще не раз проведем интересные вечера подобным образом. Нам еще столько всего нужно обсудить😂🤣
Но есть и не очень хорошие новости. К сожалению, я не могу найти запись🥹 Однако, это мой косяк. И я решила, что просто запишу серию видео с ответами на вопросы, которые мы вчера обсуждали. Буду выкладывать их тут и на своем youtube как обычно, поэтому не расстраиваемся, все поправимо.)
Вчера мне очень понравилось с вами общаться.) Это был полезный для вас и приятный для меня эфир. 😊
Думаю, мы еще не раз проведем интересные вечера подобным образом. Нам еще столько всего нужно обсудить😂🤣
Но есть и не очень хорошие новости. К сожалению, я не могу найти запись🥹 Однако, это мой косяк. И я решила, что просто запишу серию видео с ответами на вопросы, которые мы вчера обсуждали. Буду выкладывать их тут и на своем youtube как обычно, поэтому не расстраиваемся, все поправимо.)
❤12