Меня устраивает роль объекта управления, но не устраивает когда субъекты управления перекладывают на меня свою ответственность за результат их управления.
Какая кому разница, что вас не устраивает, если вы объект? И самое главное какая для вас польза жаловаться на хабр и не пытаться изменить не устраивающий вас процесс доступными способами.
а предложения по улучшению процессов
Во-первых, как только вы вносите какие-то предложения, вы становитесь субъектом — так как сами пытаетесь внести какие-то изменения в процесс.
типа «давайте работать, а не митинги проводить» встречают «железный» аргумент: «у нас XYZ, а по нему митинги нужно проводить».
Во-вторых, для того, чтобы контрагрументировать железный аргумент, надо знать и понимать XYZ. Это если вам хочется что-то изменить. А если не хочется, то зачем вообще вносить предложения?
— Нет, профессор, ответственность работает не так, — Гарри заговорил таким голосом, словно он объяснял что-то ребёнку, который наверняка ничего не поймёт. Мальчик отвёл от неё взгляд и уставился куда-то в стену справа от неё. — Когда проводишь анализ ошибок, нет никакого смысла винить ту часть системы, которую всё равно не удастся изменить в следующий раз — это всё равно, что прыгнуть со скалы и обвинить гравитацию. Гравитация в следующий раз будет совершенно такой же. Нет смысла пытаться возложить ответственность на тех людей, которые всё равно не изменят своего поведения. И если вы посмотрите на дело с такой стороны, то поймёте, что обвинять имеет смысл только самого себя, потому что именно вы и есть тот единственный человек, чьи действия вы можете изменить, возлагая на него ответственность
Например, если у вас менеджер, верящий в XYZ и вы не можете это изменить, стоит это использовать.
Даже если ваше объяснение настолько ясно, что исключает всякое ложное толкование, всё равно найдется человек, который поймет вас неправильно.
Если вы уверены, что ваш поступок встретит всеобщее одобрение, кому-то он обязательно не понравится. — Третий закон Чизхолма
Ну какое-то количество совещаний должно быть же. Надо координировать работу. Мой рецепт — когда в течение нескольких дней в рамках daily scrum говоришь, что задача не продвинулась, так как часто отвлекали, то они сами что-нибудь придумывают :)
И даже, если бы я такое сказал, про до 17:00 скорее всего ответ был бы конструктивный, а не хамский.
У SM, как я понял, тут мета-роль — организовать процесс так, чтобы команда выработала этот критерий. Организовать ретро так, чтобы всем было понятно что проблема есть.
нам нет нужды разбираться в методологиях управления разработки, мы объекты этих методологий, а не субъекты.
Это ваш выбор, но вы почему-то здесь распрашиваете про методологии и о них рассуждаете. Значит это вам почему-то интересно и роль объекта вас не устраивает.
Если бы вы разобрались раньше, у вашего начальника появилось бы второе аргументированное мнение по поводу процесса, у вашего скрам-мастера была бы возможность узнать что-то новое, а у вас получить более устраивающий вас процесс.
Но если вы хотите быть объектом, то пожалуйста, стойте куда вас поставят и говорите себе, что ничего изменить нельзя, или это не ваше дело, или что виноват скрам-мастер или тупой начальник.
имлид разрабточиков в роли Scrum master, чрезмерно влияет на тестировщика в проекте из-за чего выбор сценария тестирования разработчиком приводит к проблемам
Являются ли эти проблемы проблемами для самого тим лида?
Есть ли какой-то Acceprtance Criteria в PBI и кем он вырабатывается?
Ответом на это является инкрементность и итеративность.
Скрам как фрэймворк, безусловно, поддерживает итеративность и инкрементность
Скрам тут — ни к селу, ни к городу.
Вам же надо будет выбрать какой-то процесс или придумать свой, чтобы поддерживать инрементность?
Ответили же — в пределах спринта команда решает. Чтобы уменьшит количество кардинальных изменений в рамках одного спринта надо хорошо грумить беклог на вертикальные кусочки.
Как выяснилось выше, некоторые даже не дают себе труда разобраться в том, что из себя представляет методология. Хотя бы на уровне основных понятий. :) Но при этом делают выводы космического масштаба. Разумеется, им можно втюхать любой карго культ и назвать чем угодно.
Team — это "команда", значит Team lead — это "вожд команды", для разделения прориаммеров и тестеров используется слово discipline. Но раз суествует team, то должен быть кто-то кто ей управляет. То есть еще есть и team team lead. А теперь интересно, как разделятся ответственность между team lead и discipline lead?
Повышение качества может даже экономить средства в долгосрочной перспективе. Не сделанный баг не надо воспроизводить, репортить, опять воспроизводить на разработческой машине, тестировать, триажить и т.д… Также учтите, что пока баг живет, на него снова и снова натыкаются новые люди, и часть этих шагов повторяются
Agile — не конкретная методология а понятие расплывчатое — просто некоторый набор ценностей. SCRUM является одним из фреймворков/методологий поддерживающим ценности agile.
Если больше 12 вообще не стоит мучать ни себя ни команду натягивая на нее Scrum или наоборот. Всему свой инструмент.
Если больше 12 — рекомендуют рабить на мелкие команды и внутри них применять SCRUM а снаружи уже пользоваться чем-то для координации. Например, авторы SCRUM развивают Nexus есть еще SAfE
Какая кому разница, что вас не устраивает, если вы объект? И самое главное какая для вас польза жаловаться на хабр и не пытаться изменить не устраивающий вас процесс доступными способами.
Во-первых, как только вы вносите какие-то предложения, вы становитесь субъектом — так как сами пытаетесь внести какие-то изменения в процесс.
Во-вторых, для того, чтобы контрагрументировать железный аргумент, надо знать и понимать XYZ. Это если вам хочется что-то изменить. А если не хочется, то зачем вообще вносить предложения?
— Нет, профессор, ответственность работает не так, — Гарри заговорил таким голосом, словно он объяснял что-то ребёнку, который наверняка ничего не поймёт. Мальчик отвёл от неё взгляд и уставился куда-то в стену справа от неё. — Когда проводишь анализ ошибок, нет никакого смысла винить ту часть системы, которую всё равно не удастся изменить в следующий раз — это всё равно, что прыгнуть со скалы и обвинить гравитацию. Гравитация в следующий раз будет совершенно такой же. Нет смысла пытаться возложить ответственность на тех людей, которые всё равно не изменят своего поведения. И если вы посмотрите на дело с такой стороны, то поймёте, что обвинять имеет смысл только самого себя, потому что именно вы и есть тот единственный человек, чьи действия вы можете изменить, возлагая на него ответственность
Например, если у вас менеджер, верящий в XYZ и вы не можете это изменить, стоит это использовать.
Да, это мой опыт.
Ура, вы изобрели feature toggle!
Ну какое-то количество совещаний должно быть же. Надо координировать работу. Мой рецепт — когда в течение нескольких дней в рамках daily scrum говоришь, что задача не продвинулась, так как часто отвлекали, то они сами что-нибудь придумывают :)
И даже, если бы я такое сказал, про до 17:00 скорее всего ответ был бы конструктивный, а не хамский.
У SM, как я понял, тут мета-роль — организовать процесс так, чтобы команда выработала этот критерий. Организовать ретро так, чтобы всем было понятно что проблема есть.
Это ваш выбор, но вы почему-то здесь распрашиваете про методологии и о них рассуждаете. Значит это вам почему-то интересно и роль объекта вас не устраивает.
Если бы вы разобрались раньше, у вашего начальника появилось бы второе аргументированное мнение по поводу процесса, у вашего скрам-мастера была бы возможность узнать что-то новое, а у вас получить более устраивающий вас процесс.
Но если вы хотите быть объектом, то пожалуйста, стойте куда вас поставят и говорите себе, что ничего изменить нельзя, или это не ваше дело, или что виноват скрам-мастер или тупой начальник.
Тут уже более частная тема — можно ли вообще повысить качество разработки за короткий срок.
Вам же надо будет выбрать какой-то процесс или придумать свой, чтобы поддерживать инрементность?
SCRUM — это про процесс — организацию и коммуникацию.
https://martinfowler.com/bliki/FlaccidScrum.html
Найдите, пожалуйста, определения, что такое техническое задание, User Story и Product Backlog item и посмотрите различия.
Ответили же — в пределах спринта команда решает. Чтобы уменьшит количество кардинальных изменений в рамках одного спринта надо хорошо грумить беклог на вертикальные кусочки.
Как выяснилось выше, некоторые даже не дают себе труда разобраться в том, что из себя представляет методология. Хотя бы на уровне основных понятий. :) Но при этом делают выводы космического масштаба. Разумеется, им можно втюхать любой карго культ и назвать чем угодно.
Это как раз одна вещей, которая сильно улучшает ваимодействие между людьми — называть одно и то же одними и теми же словами :)
Definition of done это как раз про договоренность команды что она считает правильным и как комуницировать между разнми стадиями разработки.
Еще иногда бывает, что на ретроспективе команда решает автоматизировать проверку каких-то критериев.
Team — это "команда", значит Team lead — это "вожд команды", для разделения прориаммеров и тестеров используется слово discipline. Но раз суествует team, то должен быть кто-то кто ей управляет. То есть еще есть и team team lead. А теперь интересно, как разделятся ответственность между team lead и discipline lead?
Повышение качества может даже экономить средства в долгосрочной перспективе. Не сделанный баг не надо воспроизводить, репортить, опять воспроизводить на разработческой машине, тестировать, триажить и т.д… Также учтите, что пока баг живет, на него снова и снова натыкаются новые люди, и часть этих шагов повторяются
Agile — не конкретная методология а понятие расплывчатое — просто некоторый набор ценностей. SCRUM является одним из фреймворков/методологий поддерживающим ценности agile.
Если больше 12 — рекомендуют рабить на мелкие команды и внутри них применять SCRUM а снаружи уже пользоваться чем-то для координации. Например, авторы SCRUM развивают Nexus есть еще SAfE
Я довольно давно занимаюсь разработкой, но вот в таком тоне со мной никто ни разу не говорил.