Если команды компонентные это зависимость на между командами, а не на нижнем уровне. Можно делать гибриды — достаточно простые правки бекэнда могут делать фронтендеры и мерджить после ревью бекендом. В остальных случаях зависимостями надо управлять в любом случае. Надо пересмотреть видео выше — там есть разные варианты.
Я так понимаю, управление зависимостями — это просто уровень выше чем скрам. См. тут, например.
То есть скрам просто описывает нижний уровень организационной декомпозиции, а остальное описывают другие процессы.
Отсюда же и ограничение на размер команд.
Я думаю, управление ограниченным количеством чего угодно есть свойство человеческого мышленгия. Например когда ходил в детстве в походы, мой руководитель говорил, что оптимальное число тургруппы тоже в районе 8 человек.
ярко выраженной специализацией (допустим, код и дезигн)
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.
Никогда не работал в геймдеве. Нельзя ли разделить на команды так, чтобы каждая команда могла параллельно работать над чем-то целостным, включающим в себя дизайн и код?
Непонятно, почему отмена итераций -> субьет процесса управления процессом, а, например, замена комитментов на форекасты -> субъект процесса :). К тому же, когда вы меняете процесс управления процессом — это опосредованное управление процессом :).
Мне кажется, уже схоластика пошла какая-то. Я за этим вижу форму игры ПБВНДН
Меня устраивает роль объекта управления, но не устраивает когда субъекты управления перекладывают на меня свою ответственность за результат их управления.
Какая кому разница, что вас не устраивает, если вы объект? И самое главное какая для вас польза жаловаться на хабр и не пытаться изменить не устраивающий вас процесс доступными способами.
а предложения по улучшению процессов
Во-первых, как только вы вносите какие-то предложения, вы становитесь субъектом — так как сами пытаетесь внести какие-то изменения в процесс.
типа «давайте работать, а не митинги проводить» встречают «железный» аргумент: «у нас XYZ, а по нему митинги нужно проводить».
Во-вторых, для того, чтобы контрагрументировать железный аргумент, надо знать и понимать XYZ. Это если вам хочется что-то изменить. А если не хочется, то зачем вообще вносить предложения?
— Нет, профессор, ответственность работает не так, — Гарри заговорил таким голосом, словно он объяснял что-то ребёнку, который наверняка ничего не поймёт. Мальчик отвёл от неё взгляд и уставился куда-то в стену справа от неё. — Когда проводишь анализ ошибок, нет никакого смысла винить ту часть системы, которую всё равно не удастся изменить в следующий раз — это всё равно, что прыгнуть со скалы и обвинить гравитацию. Гравитация в следующий раз будет совершенно такой же. Нет смысла пытаться возложить ответственность на тех людей, которые всё равно не изменят своего поведения. И если вы посмотрите на дело с такой стороны, то поймёте, что обвинять имеет смысл только самого себя, потому что именно вы и есть тот единственный человек, чьи действия вы можете изменить, возлагая на него ответственность
Например, если у вас менеджер, верящий в XYZ и вы не можете это изменить, стоит это использовать.
Даже если ваше объяснение настолько ясно, что исключает всякое ложное толкование, всё равно найдется человек, который поймет вас неправильно.
Если вы уверены, что ваш поступок встретит всеобщее одобрение, кому-то он обязательно не понравится. — Третий закон Чизхолма
Ну какое-то количество совещаний должно быть же. Надо координировать работу. Мой рецепт — когда в течение нескольких дней в рамках daily scrum говоришь, что задача не продвинулась, так как часто отвлекали, то они сами что-нибудь придумывают :)
И даже, если бы я такое сказал, про до 17:00 скорее всего ответ был бы конструктивный, а не хамский.
У SM, как я понял, тут мета-роль — организовать процесс так, чтобы команда выработала этот критерий. Организовать ретро так, чтобы всем было понятно что проблема есть.
нам нет нужды разбираться в методологиях управления разработки, мы объекты этих методологий, а не субъекты.
Это ваш выбор, но вы почему-то здесь распрашиваете про методологии и о них рассуждаете. Значит это вам почему-то интересно и роль объекта вас не устраивает.
Если бы вы разобрались раньше, у вашего начальника появилось бы второе аргументированное мнение по поводу процесса, у вашего скрам-мастера была бы возможность узнать что-то новое, а у вас получить более устраивающий вас процесс.
Но если вы хотите быть объектом, то пожалуйста, стойте куда вас поставят и говорите себе, что ничего изменить нельзя, или это не ваше дело, или что виноват скрам-мастер или тупой начальник.
имлид разрабточиков в роли Scrum master, чрезмерно влияет на тестировщика в проекте из-за чего выбор сценария тестирования разработчиком приводит к проблемам
Являются ли эти проблемы проблемами для самого тим лида?
Есть ли какой-то Acceprtance Criteria в PBI и кем он вырабатывается?
Ответом на это является инкрементность и итеративность.
Скрам как фрэймворк, безусловно, поддерживает итеративность и инкрементность
Скрам тут — ни к селу, ни к городу.
Вам же надо будет выбрать какой-то процесс или придумать свой, чтобы поддерживать инрементность?
F# но не поддерживает отрицаетльные числа
Если команды компонентные это зависимость на между командами, а не на нижнем уровне. Можно делать гибриды — достаточно простые правки бекэнда могут делать фронтендеры и мерджить после ревью бекендом. В остальных случаях зависимостями надо управлять в любом случае. Надо пересмотреть видео выше — там есть разные варианты.
Разбиение на команды, это не данность. Можно перейти к feature teams.
Я так понимаю, управление зависимостями — это просто уровень выше чем скрам. См. тут, например.
То есть скрам просто описывает нижний уровень организационной декомпозиции, а остальное описывают другие процессы.
Я думаю, управление ограниченным количеством чего угодно есть свойство человеческого мышленгия. Например когда ходил в детстве в походы, мой руководитель говорил, что оптимальное число тургруппы тоже в районе 8 человек.
есть модуль оператор чтобы не оборачивать все лямбдами
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.
Никогда не работал в геймдеве. Нельзя ли разделить на команды так, чтобы каждая команда могла параллельно работать над чем-то целостным, включающим в себя дизайн и код?
Было бы интересно более детальное мнение. Например, какие основные ошибки допустил автор.
Непонятно, почему отмена итераций -> субьет процесса управления процессом, а, например, замена комитментов на форекасты -> субъект процесса :). К тому же, когда вы меняете процесс управления процессом — это опосредованное управление процессом :).
Мне кажется, уже схоластика пошла какая-то. Я за этим вижу форму игры ПБВНДН
Какая кому разница, что вас не устраивает, если вы объект? И самое главное какая для вас польза жаловаться на хабр и не пытаться изменить не устраивающий вас процесс доступными способами.
Во-первых, как только вы вносите какие-то предложения, вы становитесь субъектом — так как сами пытаетесь внести какие-то изменения в процесс.
Во-вторых, для того, чтобы контрагрументировать железный аргумент, надо знать и понимать XYZ. Это если вам хочется что-то изменить. А если не хочется, то зачем вообще вносить предложения?
— Нет, профессор, ответственность работает не так, — Гарри заговорил таким голосом, словно он объяснял что-то ребёнку, который наверняка ничего не поймёт. Мальчик отвёл от неё взгляд и уставился куда-то в стену справа от неё. — Когда проводишь анализ ошибок, нет никакого смысла винить ту часть системы, которую всё равно не удастся изменить в следующий раз — это всё равно, что прыгнуть со скалы и обвинить гравитацию. Гравитация в следующий раз будет совершенно такой же. Нет смысла пытаться возложить ответственность на тех людей, которые всё равно не изменят своего поведения. И если вы посмотрите на дело с такой стороны, то поймёте, что обвинять имеет смысл только самого себя, потому что именно вы и есть тот единственный человек, чьи действия вы можете изменить, возлагая на него ответственность
Например, если у вас менеджер, верящий в XYZ и вы не можете это изменить, стоит это использовать.
Да, это мой опыт.
Ура, вы изобрели feature toggle!
Ну какое-то количество совещаний должно быть же. Надо координировать работу. Мой рецепт — когда в течение нескольких дней в рамках daily scrum говоришь, что задача не продвинулась, так как часто отвлекали, то они сами что-нибудь придумывают :)
И даже, если бы я такое сказал, про до 17:00 скорее всего ответ был бы конструктивный, а не хамский.
У SM, как я понял, тут мета-роль — организовать процесс так, чтобы команда выработала этот критерий. Организовать ретро так, чтобы всем было понятно что проблема есть.
Это ваш выбор, но вы почему-то здесь распрашиваете про методологии и о них рассуждаете. Значит это вам почему-то интересно и роль объекта вас не устраивает.
Если бы вы разобрались раньше, у вашего начальника появилось бы второе аргументированное мнение по поводу процесса, у вашего скрам-мастера была бы возможность узнать что-то новое, а у вас получить более устраивающий вас процесс.
Но если вы хотите быть объектом, то пожалуйста, стойте куда вас поставят и говорите себе, что ничего изменить нельзя, или это не ваше дело, или что виноват скрам-мастер или тупой начальник.
Тут уже более частная тема — можно ли вообще повысить качество разработки за короткий срок.
Вам же надо будет выбрать какой-то процесс или придумать свой, чтобы поддерживать инрементность?
SCRUM — это про процесс — организацию и коммуникацию.
https://martinfowler.com/bliki/FlaccidScrum.html
Найдите, пожалуйста, определения, что такое техническое задание, User Story и Product Backlog item и посмотрите различия.