Так ведь Scrum (и Agile вообще) как раз и задумывался как мини водопад!
В Kanban WIP-лимит явно прописан. В Scrum, во-первых, количество задач ограничено емкостью спринта (velocity), а во-вторых, предполагается, что команда фокусируется на важных задачах в спринте, а не бросается работать над всем сразу.
Если же "на QA или продактов сразу вываливается большой объем работы по приёмке", то дело скорей всего в другом. Важный и неотъемлемый принцип Agile -- это автоматическое непрерывное тестирование всего вообще, и это тестирование есть ответственность команды. В идеале, продакт может посмотреть на состояние приемочных тестов (acceptance test) и убедиться, что система работает так, как задумывалась. Много времени это не должно же занимать. QA же должен заниматься тестированием того, что команда не может автоматизировать сама, а не просто проверять работу за программистами.
Понятно, что на практике идеал никогда не достижим, но нельзя недостижимостью идеала оправдывать сваливание в другую крайность, когда команда не делает свою работу.
Предположим, есть рецепт пирога. В нем указаны ингредиенты и последовательность действий.
В некоторых пределах можно менять и соотношения в составе, и порядок действий.
Но если выкинуть важный ингредиент или не поставить в печку, то получится фигня.
Смысл церемоний не в том, чтобы их обязательно проводить и обязательно какой-то определенной длины, а в том, что они задают моменты времени, когда команда останавливается на мгновение и соображает, в правильную сторону ли она двигается, нужные ли задачи решает, приносит ли пользу бизнесу, и так далее.
Возможно, маркетинг. Размер, форма, положение водяного знака может меняться в зависимости от настроения и скидок. Пересоздать итоговое видео с другим знаком -- это очень быстро по сравнению с созданием исходного. Хранить исходную копию дешевле, чем все остальное.
Книга покрывает все темы кроме, разве что, worktree. Будете понимать, что как работает (на случай, если надо руками сделать), и продолжать счастливо работать в GUI.
P.S. А вот gitbook и gitmagic читать не советую 😀 очень плохо и размыто написаны были. Хотя тут субъективно может быть.
Так ведь Scrum (и Agile вообще) как раз и задумывался как мини водопад!
В Kanban WIP-лимит явно прописан. В Scrum, во-первых, количество задач ограничено емкостью спринта (velocity), а во-вторых, предполагается, что команда фокусируется на важных задачах в спринте, а не бросается работать над всем сразу.
Если же "на QA или продактов сразу вываливается большой объем работы по приёмке", то дело скорей всего в другом. Важный и неотъемлемый принцип Agile -- это автоматическое непрерывное тестирование всего вообще, и это тестирование есть ответственность команды. В идеале, продакт может посмотреть на состояние приемочных тестов (acceptance test) и убедиться, что система работает так, как задумывалась. Много времени это не должно же занимать. QA же должен заниматься тестированием того, что команда не может автоматизировать сама, а не просто проверять работу за программистами.
Понятно, что на практике идеал никогда не достижим, но нельзя недостижимостью идеала оправдывать сваливание в другую крайность, когда команда не делает свою работу.
Предположим, есть рецепт пирога. В нем указаны ингредиенты и последовательность действий.
В некоторых пределах можно менять и соотношения в составе, и порядок действий.
Но если выкинуть важный ингредиент или не поставить в печку, то получится фигня.
Смысл церемоний не в том, чтобы их обязательно проводить и обязательно какой-то определенной длины, а в том, что они задают моменты времени, когда команда останавливается на мгновение и соображает, в правильную сторону ли она двигается, нужные ли задачи решает, приносит ли пользу бизнесу, и так далее.
Более того, SMB 2, 3, 3.11 считают подписи разными способами.
Для полноты добавлю замечательную статью на английском, которая хорошо дополняет официальную документацию от Microsoft.
https://davenport.sourceforge.net/ntlm.html
В оригинале по ссылке написано:
Revenue это все же выручка, а не прибыль (которая profit).
Думаю, что так будет работать. Но это примерно то же самое, как перешивать mac-адрес при старте каждой ОС из комментария выше. Там автор отвечает.
Красивые умные слова ради красивых умных слов.
А есть ли у этого всего хоть какие-то клинические исследования эффективности?
Тэг "личный опыт" я видел, конечно 😀
Возможно, маркетинг. Размер, форма, положение водяного знака может меняться в зависимости от настроения и скидок. Пересоздать итоговое видео с другим знаком -- это очень быстро по сравнению с созданием исходного. Хранить исходную копию дешевле, чем все остальное.
Как раз это мы и не можем предполагать. Одинаковые ресурсы доступны в обоих случаях, в сколько использовалось -- этого мы не знаем.
Из общих знаний можно предположить, что Питон ест больше памяти, но опять же нет данных сказать точно.
Но ведь из таблиц этот вывод нельзя никак сделать! Мы не знаем ничего о использовании памяти и ядер процессора.
Если Locust вдруг уперся в свою производительность, то мы не померяли от Go все, что могли бы, и разница с Python, возможно, ещё больше.
Выглядит разумно при условии, что есть достаточное количество таких тестовых сценариев, и что эти сценарии покрывают нужные ситуации.
Как так получилось? Это потому, что все пользователи могут создавать новые наименования товаров (а не только использовать готовые)?
Как заказчик (и вы) планировал проверять, что новая система делает то, что нужно, или хотя бы то же самое, что и старая?
Другими словами, как было устроено тестирование этого всего?
Мне кажется, что статья так и не раскрыла, почему из excel-файла нельзя было получить нужную информацию.
Нет, по привычке скорее. Не знал (не видел), что есть перевод.
Если английский не проблема, то рекомендую прочитать Pro Git https://git-scm.com/book/en/v2 от начала до конца.
Книга покрывает все темы кроме, разве что, worktree. Будете понимать, что как работает (на случай, если надо руками сделать), и продолжать счастливо работать в GUI.
P.S. А вот gitbook и gitmagic читать не советую 😀 очень плохо и размыто написаны были. Хотя тут субъективно может быть.
Думаю, вопрос был не про канал , а про бота. Почему конфиг выдает бот? Какая проблема решается с помощью бота?
Это банк или биржа такое требует?