Мне кажется, вы никогда не работали по Agile. То что вы описываете приводит к Waterfall и одному стори-пойнту равному 40 часам.
Для решения всех указанных вами нюансов есть выработанные практики - три амиго, груминг и планирование. Я захожу иногда на эти ваши стендапы и ужасаюсь статусам "я хожу на встречи и пишу аналитику, сегодня тоже буду ходить на встречи и писать аналитику".
Другое дело когда сессия трёх амиго разрастается до встреч из 30 людей которые слушают перепалку двух людей которые ничего не шарят.
Agile и полноценная документация вещи противоречащие друг другу.
Поэтому: - документацию можно и нужно автоматизировать, писать системную документацию к постоянно меняющейся системе руками грех, - из опыта - удобнее всего когда требования выдаются устно, а аналитик пишет пользовательскую документацию где-то у себя в сторонке, - API каждого модуля должно быть описано полностью, без этого не будет работать SemVer
Вопрос от разработчика которому "отдают" требования: с моей точки зрения в задачу аналитика так же входит презентация требований. Как вы доносите какие изменения в каких модулях нужно внести в нашем много-сервисном мире?
Я как-то раз проводил эксперимент. Поняв, что вакансий на Angular и Vue гораздо меньше и что от реакта никуда не деться, я начал посылать резюме на проекты на реакте. Часть собеседований сидел с серьезной миной, часть - с улыбкой во весь рот. Во всех случаях я говорил что реакт терпеть не могу и поэтому в работе его избегаю, но на вопросы ответить смогу.
Как показал эксперимент, при наличии базовых знаний технологии, пройти собес "на улыбке" ответив "не знаю" на большинство вопросов очень даже реально.
Эволюция, к сожалению, не значит что программисты становятся лучше. Эволюция это процесс адаптации к окружающему миру. И те, кто не смог адаптироваться действительно вымрут.
Разработчик углубившийся в системный анализ это уже архитектор )
Но есть замечание по поводу "лучшая нотация - BPMN 2.0" - а какие ещё нотации вы знаете? Свимлейны не отвечают на вопрос "чем эта часть процесса регулируется" и какие ресурсы нужны. Так же они не дают представления о системе как нечто целом.
Что думаете об IDEF0? DFD? UML? Мне кажется, BPMN стал популярен как и React - его популяризировали.
Мне кажется, составление представления о системе в разных разрезах - основной навык системного аналитика. И тут только одним инструментом описания не обойтись. Правда, присмотритесь к IDEF, его 25 лет создавали в ВМС США. А bpmn вырос из IDEF3.
достаточно описанных в контракте функциональных и нефункциональных требований.
Мне кажется, вы никогда не работали по Agile. То что вы описываете приводит к Waterfall и одному стори-пойнту равному 40 часам.
Для решения всех указанных вами нюансов есть выработанные практики - три амиго, груминг и планирование. Я захожу иногда на эти ваши стендапы и ужасаюсь статусам "я хожу на встречи и пишу аналитику, сегодня тоже буду ходить на встречи и писать аналитику".
Другое дело когда сессия трёх амиго разрастается до встреч из 30 людей которые слушают перепалку двух людей которые ничего не шарят.
Agile и полноценная документация вещи противоречащие друг другу.
Поэтому:
- документацию можно и нужно автоматизировать, писать системную документацию к постоянно меняющейся системе руками грех,
- из опыта - удобнее всего когда требования выдаются устно, а аналитик пишет пользовательскую документацию где-то у себя в сторонке,
- API каждого модуля должно быть описано полностью, без этого не будет работать SemVer
Добрый день из 2024-го.
А как вы спустя столько лет, справляетесь с простоями отдельных дисциплин которые RUP неизбежно вызывает?
И почему именно RUP? IBM отправила RUP на пенсию давным давно.
If you see this in 2019 - buy Z-series one.
Вопрос от разработчика которому "отдают" требования: с моей точки зрения в задачу аналитика так же входит презентация требований. Как вы доносите какие изменения в каких модулях нужно внести в нашем много-сервисном мире?
Я применил советы и стажер уже учит синьоров через месяц.
В каждой шутке есть доля шутки.
Я как-то раз проводил эксперимент. Поняв, что вакансий на Angular и Vue гораздо меньше и что от реакта никуда не деться, я начал посылать резюме на проекты на реакте. Часть собеседований сидел с серьезной миной, часть - с улыбкой во весь рот. Во всех случаях я говорил что реакт терпеть не могу и поэтому в работе его избегаю, но на вопросы ответить смогу.
Как показал эксперимент, при наличии базовых знаний технологии, пройти собес "на улыбке" ответив "не знаю" на большинство вопросов очень даже реально.
Поэтому только тестовые задания, только хардкор.
Для меня это выглядит как попытаться одеться красиво в холостяцкой берлоге чтобы создать впечатление внутреннего благополучия.
Пока с изнанки и для внутреннего использования будут всё те же интерфейсы из 90-х - какой-нибудь SAP или Lotus 123, обмануть клиентов не получится.
А опираться на стабильность веба - такое себе.
Банковский софт не должен быть красивым - банковский софт должен быть понятным, удобным и надёжным.
Эволюция...
Эволюция, к сожалению, не значит что программисты становятся лучше. Эволюция это процесс адаптации к окружающему миру. И те, кто не смог адаптироваться действительно вымрут.
Разработчик углубившийся в системный анализ это уже архитектор )
Но есть замечание по поводу "лучшая нотация - BPMN 2.0" - а какие ещё нотации вы знаете? Свимлейны не отвечают на вопрос "чем эта часть процесса регулируется" и какие ресурсы нужны. Так же они не дают представления о системе как нечто целом.
Что думаете об IDEF0? DFD? UML? Мне кажется, BPMN стал популярен как и React - его популяризировали.
Мне кажется, составление представления о системе в разных разрезах - основной навык системного аналитика. И тут только одним инструментом описания не обойтись. Правда, присмотритесь к IDEF, его 25 лет создавали в ВМС США. А bpmn вырос из IDEF3.