Ответили же — в пределах спринта команда решает. Чтобы уменьшит количество кардинальных изменений в рамках одного спринта надо хорошо грумить беклог на вертикальные кусочки.
Как выяснилось выше, некоторые даже не дают себе труда разобраться в том, что из себя представляет методология. Хотя бы на уровне основных понятий. :) Но при этом делают выводы космического масштаба. Разумеется, им можно втюхать любой карго культ и назвать чем угодно.
Team — это "команда", значит Team lead — это "вожд команды", для разделения прориаммеров и тестеров используется слово discipline. Но раз суествует team, то должен быть кто-то кто ей управляет. То есть еще есть и team team lead. А теперь интересно, как разделятся ответственность между team lead и discipline lead?
Повышение качества может даже экономить средства в долгосрочной перспективе. Не сделанный баг не надо воспроизводить, репортить, опять воспроизводить на разработческой машине, тестировать, триажить и т.д… Также учтите, что пока баг живет, на него снова и снова натыкаются новые люди, и часть этих шагов повторяются
Agile — не конкретная методология а понятие расплывчатое — просто некоторый набор ценностей. SCRUM является одним из фреймворков/методологий поддерживающим ценности agile.
Если больше 12 вообще не стоит мучать ни себя ни команду натягивая на нее Scrum или наоборот. Всему свой инструмент.
Если больше 12 — рекомендуют рабить на мелкие команды и внутри них применять SCRUM а снаружи уже пользоваться чем-то для координации. Например, авторы SCRUM развивают Nexus есть еще SAfE
Я такого никогда не делал, но как мне кажется, чисто по ощущениям, для начала надо, чтобы у вас был какой-нибудь чувак с презентационными скилами чтобы продать изменения бизнесу. То есть в какие проблемы для бизеса выливаются проблемы разработки и какими изменениями их достичь.
Например, одинаковый приоритет задач — все равно, что отсутствие приоритета. Внедрение единого беклога и единого PO может сделать разработку более предсказуемой — как электронная очередь в сбербанке. Дыры в безопасности — риски потерь денег (тут чувак красочно расписывает какие-нибудь примеры точно такого же бизнеса как ваш) и т.д.
Дальше надо понять с кем можно говорить, кто может менять процесс и какие части трудно изменить, какие нет.
У вас есть люди которые говорят ярко и доступно и умеют договариваться и в курсе ваших проблем?
Ктоме вас лично кто-то понимает ситуцию и также недоволен происодящим?
А не кажется ли посетителям сайта, что скрам — это попытка непрограммистов управлять программистами без понимания их запросов? :)
В скраме команда самоуправляема, и встроенны механизмы обратной связи от разработчиков — каждый день задается вопрос, не мешает ли что разработке, по окончанию спринта устраивают ретроспективу.
Development Team Size
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.
Как часто допускается вносит изменения в ТЗ?
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team
У скрама есть автор, автор написал Scrum guide и книжки. То есть, по крайне мере, можно понять, что вкладывает в это понятие автор, а что является дополнением.
Так же это "что-то организовано" может быть набором вариантов, из которых можно выбрать подходящий вам.
Ну вот для вас и ваших менеджеров из учета следует давление. А это не везде так. Когда понимают, что если давят по времени падает качество некоторые не давят
Мне кажется, khim и VolCh, во-первых, находятся в режиме спора (то есть для них главное скорее переспорить или выразить эмоции от принятого у них стиля менеджемента, чем узнать, как в Scrum что-то организовано). Во-вторых, не хотят слышать что бывает по другому и что подход к работе меняется :)
Там не написано про противоположности, а про то, что нужно стать уникальным. И за счет глобализации получить достаточную востребованность — среди семи миллиардов человек найдется достаточно большая толпа кому нужет садовник-визажист :)
Ответили же — в пределах спринта команда решает. Чтобы уменьшит количество кардинальных изменений в рамках одного спринта надо хорошо грумить беклог на вертикальные кусочки.
Как выяснилось выше, некоторые даже не дают себе труда разобраться в том, что из себя представляет методология. Хотя бы на уровне основных понятий. :) Но при этом делают выводы космического масштаба. Разумеется, им можно втюхать любой карго культ и назвать чем угодно.
Это как раз одна вещей, которая сильно улучшает ваимодействие между людьми — называть одно и то же одними и теми же словами :)
Definition of done это как раз про договоренность команды что она считает правильным и как комуницировать между разнми стадиями разработки.
Еще иногда бывает, что на ретроспективе команда решает автоматизировать проверку каких-то критериев.
Team — это "команда", значит Team lead — это "вожд команды", для разделения прориаммеров и тестеров используется слово discipline. Но раз суествует team, то должен быть кто-то кто ей управляет. То есть еще есть и team team lead. А теперь интересно, как разделятся ответственность между team lead и discipline lead?
Повышение качества может даже экономить средства в долгосрочной перспективе. Не сделанный баг не надо воспроизводить, репортить, опять воспроизводить на разработческой машине, тестировать, триажить и т.д… Также учтите, что пока баг живет, на него снова и снова натыкаются новые люди, и часть этих шагов повторяются
Agile — не конкретная методология а понятие расплывчатое — просто некоторый набор ценностей. SCRUM является одним из фреймворков/методологий поддерживающим ценности agile.
Если больше 12 — рекомендуют рабить на мелкие команды и внутри них применять SCRUM а снаружи уже пользоваться чем-то для координации. Например, авторы SCRUM развивают Nexus есть еще SAfE
Я довольно давно занимаюсь разработкой, но вот в таком тоне со мной никто ни разу не говорил.
Я???
Я такого никогда не делал, но как мне кажется, чисто по ощущениям, для начала надо, чтобы у вас был какой-нибудь чувак с презентационными скилами чтобы продать изменения бизнесу. То есть в какие проблемы для бизеса выливаются проблемы разработки и какими изменениями их достичь.
Например, одинаковый приоритет задач — все равно, что отсутствие приоритета. Внедрение единого беклога и единого PO может сделать разработку более предсказуемой — как электронная очередь в сбербанке. Дыры в безопасности — риски потерь денег (тут чувак красочно расписывает какие-нибудь примеры точно такого же бизнеса как ваш) и т.д.
Дальше надо понять с кем можно говорить, кто может менять процесс и какие части трудно изменить, какие нет.
У вас есть люди которые говорят ярко и доступно и умеют договариваться и в курсе ваших проблем?
Ктоме вас лично кто-то понимает ситуцию и также недоволен происодящим?
Удалось ли вам прочитать хотя бы те цитаты, которые я привел? Хотя бы выделенное жирным ;)
Там есть про рекомендуемый размер комаднды.
Посмотрите в скрам гайд.
Задача SM — чтобы процесс соблюдался, а не писать ТЗ.
Задача PO — чтобы продукт был клёвый — управление беклогом и приоритетами.
Никаких ТЗ в скраме нет, как собирать требования, в какой форме их представлять — не ограничивается. Скрам про управление процессом разработки.
В Agile духе писать User Stories.
Если вы хотите разобраться — читайте гайд — он написан понятным языком и хорошо структурирован.
В скраме команда самоуправляема, и встроенны механизмы обратной связи от разработчиков — каждый день задается вопрос, не мешает ли что разработке, по окончанию спринта устраивают ретроспективу.
Никаких менеджеров в скраме нет.
http://www.scrumguides.org/scrum-guide.html#team
Development Team Size
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team
У скрама есть автор, автор написал Scrum guide и книжки. То есть, по крайне мере, можно понять, что вкладывает в это понятие автор, а что является дополнением.
Так же это "что-то организовано" может быть набором вариантов, из которых можно выбрать подходящий вам.
Ну вот для вас и ваших менеджеров из учета следует давление. А это не везде так. Когда понимают, что если давят по времени падает качество некоторые не давят
кто знает, кто знает
Мне кажется, khim и VolCh, во-первых, находятся в режиме спора (то есть для них главное скорее переспорить или выразить эмоции от принятого у них стиля менеджемента, чем узнать, как в Scrum что-то организовано). Во-вторых, не хотят слышать что бывает по другому и что подход к работе меняется :)
Эффект воздействия описан здесь извините, это видео :), но зато ссылка воспроизведет нужный кусочек
Наверное, об этом было бы написано в книжке "Лень в стиле фанк", но потенциальным авторам было лень ее написать.
Там не написано про противоположности, а про то, что нужно стать уникальным. И за счет глобализации получить достаточную востребованность — среди семи миллиардов человек найдется достаточно большая толпа кому нужет садовник-визажист :)