Я на той же стороне — скрам хорош исключительно в непредсказуемой продуктовой разработке. У нас юрфирмы некоторые по скраму пытаются научить работать. Хотя он им во-о-бще велосити это никак не ложится по их процессам. Это если детальные требования имеет смысл прорабатывать. Не уверен, что таких людей можно считать ПМами не по должности, а по квалификации.
Корпоративный тренинг Agile and Scrum Fundamentals
- На самом деле, работает (есть реальные примеры в Сигме), но только если заказчик сам готов работать по этой модели и доверяет команде со стороны подрядчика.
- Кроме понимания «Зачем нужны эти конкретные данные?
- В украинском IT все описанные проблемы подпирают костылями.
- Ни один из этих исходов не является позитивным.
- На конференции разберут Agile-трансформацию очередного банка, юридической фирмы или даже завода, который успешно и под аплодисменты стал работать по Scrum.
- Планирование спринта – это митинг, на котором владелец продукта и команда имеют возможность удостовериться, что все всё точно понимают.
Регрессионная спираль смерти вас все равно нагонит. Вы можете облегчить боль за счет хорошего покрытия модульными тестами и облегченного тестирования в регрессии (например, по чеклистам вместо тестовых сценариев). Я каждый раз смотрю на список тем докладов и задаю себе вопрос о практической применимости для меня лично и для людей, которых я знаю. Все философствования и идеи консультанты давно описали у себя в блогах, поэтому с ними я давно знаком.
Когда Scrum не работает. Пять основных проблем его применения
Команда опять встречается с product owner, а также со stakeholder, в том числе и с генеральным директором, чтобы показать результат. Это особенно важно для скрам-мастеров и владельцев продукта. Конечно, стоит настоять на том, чтобы контактами не злоупотребляли и применяли их только если задачу нельзя будет решить, не посоветовавшись. В качестве результата встречи, как вариант, может быть список процессов, которые надо обязательно внедрить в следующем спринте, а также список тех, которые срочно необходимо исключить. Показатель «динамика производительности» на следующей ретроспективе покажет, на сколько инновации были полезны и к чему привели.
Как учитывать отпуск в планировании?
Вместо единицы, двойки и тройки команда могла бы использовать цифры 100, 200 и 300. Как видно из примера, тестировщик смог отстоять свою оценку, аргументируя ее предыдущим опытом. У тестировщика «не замылен глаз» и иногда его точка зрения может заставить программистов задуматься о нюансах на этапе оценки задач.
Ролі та відповідальності у Scrum
Нужно только учесть, что у некоторых из них выполнение таких задач будет занимать больше времени, чем могло бы у коллеги — и это нормально. Если так получилось, что одна команда работает на нескольких проектах, то процесс переключений необходимо построить таким образом, чтоб минимизировать потери. Поэтому, основная идея тренинга – помочь компании или проекту быстрее понять, зачем и какие измерения нужны, как их внедрить и интерпретировать. Тренинг структурирует теоретическую подготовку в области измерений и вырабатывает эффективный подход к практическому применению измерений. Что важно, вырабатывается понимание выгод измерений для бизнеса, заказчика, проектной команды. Общая направленность на практическое применение.
Дальше ничего не происходило, и в последний день перед Sprint Review все story points переместились в «завершенное». Scrum церемонии сами по себе не являются метриками, но то, насколько качественно происходят встречи, будет важным показателем здоровья команды. В Agile мире мы отдаем преимущество прогнозированию “к дате”, ибо объем задач, обычно, растет.
Задач в спринте может быть много, у каждой есть приоритет, поставленный product owner. Если команда понимает, что есть риск не успеть сделать все задачи из спринта, она фокусируется на задачах с более высоким приоритетом (на более важных для рroduct owner). Scrum пытается научить команду давать осязаемые оценки своей продуктивности, выбрать самостоятельно объем работ на итерацию и сделать его успешно. Во-первых, появляется предсказуемость для представителей бизнеса.
Об этом мы рассказывали не раз в докладе “Code Review”, запись которого можно найти в материалах выступлений. По поводу стабильности на машине разработчика – тут все зависит от его стиля разработки. Если он работает, разбивая задачу на законченные куски, то с чего тут взяться нестабильности?
Product owner обладает видением того, какой продукт необходимо получить на выходе, поэтому его присутствие на планировании обязательно. На обзоре спринта команда демонстрирует готовые части продукта, т.е. Все то, что соответствует определению «Сделано» и находится в колонке «Done».
Результат очевиден и предсказуем – спринт будет завален. К примеру, давление кого-то из топ-менеджмента на предмет «мы должны это сделать, у нас контракт, дедлайн и т.д.» А команда не умеет говорить «нет» или же ее не слышат. Другая крайность – команда слишком оптимистична в своих оценках и не видит потенциальных рисков, или просто не хочет/не может увидеть реальный объем работ. Причём, гвоздём в крышку гроба скрама здесь будет именно fixed scope.
Количество баллов, как правило, называется динамикой производительности (скорость скрам-команды или Velocity). Основная цель скрам-мастера и команды – наращивать динамику из спринта в спринт. Итак, когда-то давно мне очень нравилась одна фишка – мы собирались на встречи, участвовали в различных Agile мероприятиях и везде были реальные проблемы от реальных людей.
Если работа отдела связана с ежедневным выполнением срочных задач вне планирования, эта методика им не подойдет. Например, финансовый департамент в Watsons после неудачной работы по Scrum начал работу по «Канбан», где задачи постоянно попадают в список выполнения в порядке приоритетов. Новая методика отличается от обычного делегирования задач между подчиненными и руководителем. Главное отличие — четкий дедлайн и работа в команде. Потом нужно привыкнуть к тому, что начальника фактически не будет, а вся ответственность распределена среди всех членов команды.
Для выплаты технического долга должны создаваться такие же задачи на спринт как и для других элементов бэклога. Фиксированный буфер приведет к тому, что работа может быть недоделана либо занята часть времени из основного времени спринта. Ни один из этих исходов не является позитивным. Вина тестировщика в том, что он не “обеспечил качество” в процессе разработки.