Всем привет, давно меня не было, настроения ни читать ни писать на приходило. Но вот восстановил привычку читать хотя бы одну статью в день. И по запросу студентов нашёл статья про акроним SPIDR. Если коротко, то он описывает основные способы декомпозиции пользовательских историй. Spike, Paths, Interface, Data, Rules. В целом, на курсе мы со студентами разбираем все эти подходы, просто не используем акроним. А для тех, кто впервые с этим столкнулся, вот ссылка на статью https://www.google.com/amp/s/blogs.itemis.com/en/spidr-five-simple-techniques-for-a-perfectly-split-user-story%3fhs_amp=true #article #Agile

И вторая статья сразу в догонку. Много вопросов всегда вызывает оформление проектных решений и то, какие разделы должны быть в таком документе. Коллеги из БКС поделились своим шаблоном архитектурного решения, которое по сути сводит внутри себя требования, в том числе бизнес требования, предложения по их реализации и техническое описание реализации. Шаблон очень достойный, особенно, если вы проектируете сложные системы с высокой ценой ошибки. В Agile выдержать такой уровень детализации, конечно, практически невозможно, но к нему надо стремиться, возможно, в формате описания базы знаний постфактум. Ну и бонусом можно считать сам шаблон в виде файла, ознакомиться однозначно стоит.
https://habr.com/ru/company/bcs_company/blog/651765/ #article

Всем хорошей среды! Очень короткое и очень толковое видео про асинхронность в REST https://www.youtube.com/watch?v=3D2kYmEa8rk

Доброго всем вечера! Продолжаем тему REST. Наткнулся на прекрасный ликбез по тому, как спроектировать API и что надо не забыть!
https://levelup.gitconnected.com/restful-api-patterns-81930c43e494
#article

Знаете, сколько статей попадается, где начали за здравие, а закончили за упокой?
Вот например: https://rb.ru/opinion/work-with-stakeholders/
Вроде все неплохо, как ВЛАДЕЛЬЦУ ПРОДУКТА работать со стейкхолдерами. Читаем: проект, устав, RACI матрица и вообще про продакта забыли. Просто самый обычный бизнес-анализ. Вроде бы все неплохо описано, но обманутые ожидания очень сильно портят впечатления
#article

Привет, нашёл интересную статью про работу аналитика с реальными кейсами, да еще и с ошибками, таким готовы делиться не всегда. https://habr.com/ru/company/surfstudio/blog/651785/
#article

#breakfront_tooltips

Выложу и тут свою памятку для погружения в новый проект.

Всем привет! Если вы все еще можете использовать Confluence - то вот вам cookbook от ребят из Тинькова, самое ценное, кстати, в конце. https://habr.com/ru/amp/post/495038/ #article

Доброго вечера! Прочитал неплохую вводную статью про PlantUML. Если не работали с этим инструментом, то рекомендую прочесть, а если работали, тоже гляньте, ребята разбирают не самую частую Activity диаграмму. https://habr.com/ru/post/661931/
#article

Всем привет! Прочитал интересую сводную статью, что значит работать по Agile. С точки зрения техники - написано очень хорошо, разложены составляющие, все ок. Есть одна проблема. Если это все соединить вместе это не будет Agile.
Agile - это не про инкремент и итерации, это про эволюцию, про возможность учиться на ошибках. Инкремент и итерация - это инструменты. Самое главное, что нужно помнить про Agile - это то, что он должен быть в голове у вас и у вашей команды. Если что-то не получилось, это не обязательно потому, что вы криворукие бездари, возможно, надо попробовать это сделать по-другому. А может быть - этого вообще не надо было делать?
Инкремент нужен для того, чтобы как можно раньше понять, что этого не нужно делать. А итерации - чтобы то, что все таки делать нужно, допилить именно в ту сторону, которую нужно.
Кросс-функциональная команда нужна, потому что мы все разные, и на проблему мы смотрим по-разному. Именно поэтому нужно, чтобы на проблему посмотрели и дизайнер и аналитик и разработчик и тестировщик. Каждый из них привнесет что-то свое и каждый позволит не упустить что-то важное.
Самое главное - что нельзя работать по Agile. Надо быть Agile - быть готовым меняться и подстраиваться. #article #agile

Для всех любителей BPMN Денис Котов выпустил новый цикл видео, смотрим, учимся у мастера!

Новый цикл видосов про бпмн - разбор конкретных, небольших, кейсов. Накиньте лайков плиз :) https://youtu.be/2_FuORr1W-o

🌐 Попробуйте новый евро-азиатский формат! 🌐

Друзья!
Мы запустили прием докладов на конференцию Analyst Days EU-1. United.

✅ Конференция пройдёт 2 октября в Ереване.

❗️ Конференция охватывает европейский и азиатский регионы, а потому мы ожидаем много спикеров из разных городов и стран. Тем более этому способствует безвизовый режим в Армении.
Кроме того, перечень рассматриваемых тематик существенно расширен.

Веб сайт: https://analystdays.eu/ru/index

Языки докладов: английский и русский.

Присоединяйтесь к нашему англоязычному чату: https://t.iss.one/analystdayseu

P.S. Конференция будет проходить совместно с конференцией по обеспечению качества ПО - SQA Days EU-2, которая пройдет на той же площадке 30 сентября - 1 октября.
При желании Вы можете посетить обе конференции.

Всем привет, короткий ликбез про бизнес-правила - все по полочкам и с примером! #article https://habr.com/ru/post/659045/

Доброго всем вечера! Меня давно не было, но у меня есть оправдание. Даже целых три, хвастаюсь:
1. В понедельник 16 мая мы с ребятами из Отус запустили новый формат обучения для выпускников нашей школы: разработчиков, тестировщиков и конечно же аналитиков. А к ним добавили ребят, которые хотя быть тим лидами и даже продакта нашли. Все как в настоящей жизни, будем все вместе пилить приложение. Что получится - расскажу позднее.
2. Впервые провел собственный, созданный с нуля оффлайн тренинг по бизнес-анализу. Получилось даже не комом, ребята остались довольны, но жду обратной связи, как они смогут применить знания на практике. Так что, если кто то еще хочет послушать меня лично - обращайтесь)
3. Ну и самое главное, но не относящееся к работе, 17 числа у меня родился сын, так что теперь времени на канал станет еще немного меньше.
Но я обещаю, что буду стараться писать!

Всем доброго утра!
Знаете, есть такой анекдот:
В 3 года, если ребенок упал, споткнувшись о скамейку, то он говорит, что виновата скамейка, не может же он быть виноват.
В 5 лет - у ребенка уже есть самокритика и он говорит, что виноват сам.
А есть люди, у которых и в 40 лет в их жизни во всем виновата скамейка.
К чему это я?
Прочитал чудесную статью https://habr.com/ru/post/661695/.
Вроде про ТЗ, но на самом деле про извечную боль, когда ты в проекте вместе профессионала натыкаешься на вот такого человека, у которого виновата скамейка.
Статья про то, как стараться справиться с такими людьми, если они попались на твоем пути и о том, что всегда нужно быть не просто сухим профессионалом, а еще и человеком и следовать не только букве контракта, но и включать эмпатию.
На своем опыте могу подтвердить, что это работает. многие люди это ценят и очень благодарны, когда ты помогаешь их проект отвернуть от провала или даже небольшой ошибки.
#article

Доброе утро. Короткая и толковая статья о том,как связаны Agile и Lean https://scrumtrek.ru/blog/agile-scrum/8644/lean-agile-raznitsa/
#article

Доброго субботнего вечера. Немного про MVP. Многие про это слышали, кто то даже делал. Но многие понимают MVP не совсем правильно, это не поделка просто для проверки гипотезы, ее проверять базово лучше вообще без разработки, например, примитивным лендингом на условной Тильде. И это не навороченный интерфейс с красивыми анимашками и мощной поддержкой. MVP - это продукт выполняющий базово одну или функции, закрывающие конкретные боли пользователей. Одну, но очень хорошо! Иначе шансов на успех будет не много. Подробнее про это можно почитать в вот в этой статье: https://telegra.ph/CHto-takoe-MVP-i-kak-sozdat-minimalno-zhiznesposobnyj-produkt-05-27
#article

Всем привет! Кажется, я понял, кем я хочу стать когда вырасту. Если честно работа с оптимизацией бизнес-процессов всегда привлекала меня, еще с самого начала моей карьеры в ИТ, когда я оптимизировал процессы на уровне внедрения систем электронного документооборота. Тогда я часто получал по шапке за свои "предложения по оптимизации", ибо они были либо очень дороги, либо упрощая жизнь конечным пользователям делали процессы дороже в эксплуатации. Для работы бизнес архитектором нужен реально крутой и глубокий опыт бизнес-анализа, наработкой которого я сейчас и занимаюсь. Ну а вам рекомендую вот эту статью: https://habr.com/ru/company/T1Holding/blog/646509/ #article

Пример крутой пользовательской истории и Job Story