все зависит от того, что идет после завершения данного подпроцесса, если у нас далее идет разделение на сильно разнящиеся подпроцессы - то иногда удобнее иметь три раздельных завершения.
НО при этом еще раз подчеркну, что ваш вариант решения - тоже приемлимый (фиксировать различные варианты через артифакты)
Да, есть разные подходы, через фиксацию результата артефактом - тоже приемлемый вариант.
Но иногда правильнее иметь несколько завершающих событий, т.к это может быть подпроцессом и в зависимости от результата - далее будут осуществляться разные сценарии. В примере статьи, возможно, это не очень очевидно, т.к схемы сильно упрощены
Если команда зрелая и ответственная и вдруг по какой-либо причине они решили, что кнопка не будет работать какое то время и выкатились в прод - необходимо фиксировать тех. долг., а не писать в доке "мы так хотели"
Но вообще - выкатываться в прод заведомо зная про багу - плохая практика
Хочу попробовать посмотреть на описанную тему под другим углом:
у Тинька есть функционал, где на карте можно посмотреть наличность в банкоматах.
В 2022 году столкнулся с тем, что хотел снять валюту в их банкоматах, в приложении на картах показывало что наличка есть, но по факту не было. Информация о наличии/отсутствии налички в банкоматах была с сильной задержкой по времени (возможно, там кэширование данных или неактуальные данные - не знаю). В общем была боль, объедить весь город миллионник опираясь на данные в приложении что в банкоматах есть наличка, но так и не получить данную наличность... Да, тот день 2022 года был статистическим выбросом.
Так вот, к чему это я... Выше я описал боль, с которой мне пришлось в прошлом столкнуться. Не планируется ли в Альфе предиктивно предсказывать в том числе Черных лебедей? Возможно ли вообще собрать такую модельку, которая более или менее будет адекватно обрабатывать статистические выбросы? В обычные дни вроде более менее проблемы нет, если в одном банкомате деньги закончились, можно проехать условные 500 метров и снять деньги в соседнем банкомате (да, тоже не всем удобно, но решение проблемы есть), а вот как быть с "Черными лебедями"...
Про доп нагрузку - полностью поддерживаю. При этом иногда люди, о которых вы писали в предыдущем комментарии или действительно не замечают этого, либо делают вид, что не замечают этого
Про необходимость софт скиллов не могу полностью согласиться, т.к , на мой взгляд, софты важны вне зависимости от наличия/отсутствия документации)
к сожалению, не всем понятно, что с документацией лучше, чем без нее. Как пример, в моей прошлой статье (https://habr.com/ru/companies/alfa/articles/853396/) почитать комментарии, где несколько человек утверждало, что документация не нужна - это породило у меня идею свести аргументы в отдельную статью....
Что касается вашего предложения по анализу зависимости документации от проектов - интересная идея для будущих статей, спасибо)
Глобально , да - читают документацию чаще, чем пишут (также как и код). Поэтому документация больше для читателя, чем для писателя
Здесь тоже согласен, документаций может быть насколько видов. Например, пользователю системы не нужно знать какие запросы отправляются при нажатии на зелёную кнопочку, но важно чтобы при нажатии на эту кнопочку происходило событие (например, публикация комментария). При этом разработчику важно знать какой запрос должен отправляться при нажатии на ту же самую зелёную кнопочку.
"...из опыта - удобнее всего когда требования выдаются устно, а аналитик пишет пользовательскую документацию где-то у себя в сторонке..." - удобно, наверное, да, тк можно распараллелить разработку и аналитику.
Но есть нюанс, как говорится.... "Устную постановку задач" часто встречал, но также часто потом это стреляло в ногу, что у разных людей в голове вырисовывалась разная итоговая реализация и аналитика (которая писалась "в сторонке"). Как итог - аналитика выкидывалась в мусорку, тк переделывать код долго==дорого -> что приводит к bus-фактору и остальным пунктам из данной статьи....
Касаемо agile - все хорошо работает, если процесс выстроен, что не всегда получается... здесь, вероятнее всего, проблема именно планирования. Если грамотно спланировать, то по agile документация отлично работает. Аналитик должен минимум на 1-2 спринта идти впереди команды разработки - сначала делается документация, в последующих спринтах по полноценной документации - пишется код - строго по документации. Если в ходе написания кода разработчик находит неточности (если аналитик ошибся или поленился воспроизвести весь сценарий "вручную" до автоматизации), то уведомляет об этом аналитика и документация актуализируется - таким образом получается и agile работает и документация в проекте актуальная со всеми вытекающими :)
все зависит от того, что идет после завершения данного подпроцесса, если у нас далее идет разделение на сильно разнящиеся подпроцессы - то иногда удобнее иметь три раздельных завершения.
НО при этом еще раз подчеркну, что ваш вариант решения - тоже приемлимый (фиксировать различные варианты через артифакты)
Все зависит от контекста
Да, есть разные подходы, через фиксацию результата артефактом - тоже приемлемый вариант.
Но иногда правильнее иметь несколько завершающих событий, т.к это может быть подпроцессом и в зависимости от результата - далее будут осуществляться разные сценарии. В примере статьи, возможно, это не очень очевидно, т.к схемы сильно упрощены
BPMN - хорошее дополнение тестового описания, одно не исключает другое)
Где-то используются BPMS движки
"... Серьёзные проблемы действительно редки... " - но зато их цена может быть очень высокой:)
Пример с ЖКХ - огонь:)
Не совсем понял вопрос "А как делать документацию". Для этого написано множество книг.
Почитайте, например, Вигерса
Описанный вами кейс - описание незрелой команды.
Если команда зрелая и ответственная и вдруг по какой-либо причине они решили, что кнопка не будет работать какое то время и выкатились в прод - необходимо фиксировать тех. долг., а не писать в доке "мы так хотели"
Но вообще - выкатываться в прод заведомо зная про багу - плохая практика
Альфа большая, за всю компанию не готов ответить, но OponAPI точно используется
Тех долг тоже необходимо фиксировать не на словах, а "на бумаге", если фиксации не было - значит и тех долг закрыт не будет (забудут/забьют)
Про текущего работодателя в статье и комментариях - ни слова. В статье обобщён предыдущий опыт
Верхнеуровневые описания требований по итогу можно интерпретировать по разному и в итоге будет расхождение между желаемым и реализованными.
Пример верхе уровневых требований и как и могут представить разные люди - на картинке ниже
Для этого и нужно делать хорошо сразу)
Есть такое высказывание, которое мне нравится: "Я слишком ленивый, чтобы делать плохо. Все равно переделывать придётся. Лучше сразу сделать хорошо"
По поводу agile - вы правильно ответили, что вам кажется:) все выше описанное было в рамках продуктовых команд, работающих по agile.
Но глобально я с вами согласен, если команда в целом - довольно зрелая и каждый член команды - ответственный, то таких проблем быть не должно.
Но реальность, зачастую, другая
Хочу попробовать посмотреть на описанную тему под другим углом:
у Тинька есть функционал, где на карте можно посмотреть наличность в банкоматах.
В 2022 году столкнулся с тем, что хотел снять валюту в их банкоматах, в приложении на картах показывало что наличка есть, но по факту не было. Информация о наличии/отсутствии налички в банкоматах была с сильной задержкой по времени (возможно, там кэширование данных или неактуальные данные - не знаю). В общем была боль, объедить весь город миллионник опираясь на данные в приложении что в банкоматах есть наличка, но так и не получить данную наличность...
Да, тот день 2022 года был статистическим выбросом.
Так вот, к чему это я... Выше я описал боль, с которой мне пришлось в прошлом столкнуться. Не планируется ли в Альфе предиктивно предсказывать в том числе Черных лебедей? Возможно ли вообще собрать такую модельку, которая более или менее будет адекватно обрабатывать статистические выбросы? В обычные дни вроде более менее проблемы нет, если в одном банкомате деньги закончились, можно проехать условные 500 метров и снять деньги в соседнем банкомате (да, тоже не всем удобно, но решение проблемы есть), а вот как быть с "Черными лебедями"...
Про доп нагрузку - полностью поддерживаю. При этом иногда люди, о которых вы писали в предыдущем комментарии или действительно не замечают этого, либо делают вид, что не замечают этого
Про необходимость софт скиллов не могу полностью согласиться, т.к , на мой взгляд, софты важны вне зависимости от наличия/отсутствия документации)
Интересный тест с глухонемым программистом
В целом согласен, объём документации зависит от многих факторов.
Вданной статье был посыл в целом необходимости документации.
к сожалению, не всем понятно, что с документацией лучше, чем без нее. Как пример, в моей прошлой статье (https://habr.com/ru/companies/alfa/articles/853396/) почитать комментарии, где несколько человек утверждало, что документация не нужна - это породило у меня идею свести аргументы в отдельную статью....
Что касается вашего предложения по анализу зависимости документации от проектов - интересная идея для будущих статей, спасибо)
Глобально , да - читают документацию чаще, чем пишут (также как и код). Поэтому документация больше для читателя, чем для писателя
Здесь тоже согласен, документаций может быть насколько видов. Например, пользователю системы не нужно знать какие запросы отправляются при нажатии на зелёную кнопочку, но важно чтобы при нажатии на эту кнопочку происходило событие (например, публикация комментария). При этом разработчику важно знать какой запрос должен отправляться при нажатии на ту же самую зелёную кнопочку.
Согласен, разработка для внешнего заказчика без документации - опасна
"...из опыта - удобнее всего когда требования выдаются устно, а аналитик пишет пользовательскую документацию где-то у себя в сторонке..." - удобно, наверное, да, тк можно распараллелить разработку и аналитику.
Но есть нюанс, как говорится.... "Устную постановку задач" часто встречал, но также часто потом это стреляло в ногу, что у разных людей в голове вырисовывалась разная итоговая реализация и аналитика (которая писалась "в сторонке"). Как итог - аналитика выкидывалась в мусорку, тк переделывать код долго==дорого -> что приводит к bus-фактору и остальным пунктам из данной статьи....
Касаемо agile - все хорошо работает, если процесс выстроен, что не всегда получается... здесь, вероятнее всего, проблема именно планирования.
Если грамотно спланировать, то по agile документация отлично работает. Аналитик должен минимум на 1-2 спринта идти впереди команды разработки - сначала делается документация, в последующих спринтах по полноценной документации - пишется код - строго по документации. Если в ходе написания кода разработчик находит неточности (если аналитик ошибся или поленился воспроизвести весь сценарий "вручную" до автоматизации), то уведомляет об этом аналитика и документация актуализируется - таким образом получается и agile работает и документация в проекте актуальная со всеми вытекающими :)